Blockchain token

Abstract

The token transaction includes a first token output, the first token output including a first token locking script and a first token amount, the first token locking script including a variable component and a constant component, the variable component including a first payment address embedded in a payment template, and the constant component including a token mechanics subcomponent.

Description

Technical Field

[0001] The present disclosure relates to a method for transmitting tokens (e.g., issuing, transferring, splitting, exchanging, redeeming) using blockchain transactions.

Background Art

[0002] A blockchain enables the transfer of underlying digital assets using transactions. This digital asset is often referred to as a "cryptocurrency" or "native token". It is a digital asset unique to a particular blockchain. As an example to aid understanding, the digital asset of the Bitcoin blockchain is known as Bitcoin.

[0003] Another type of digital asset that can be transferred using a blockchain is a "token". In the context of blockchain technology, a token is typically created and defined using additional data fields within a transaction. This additional data, called "token data", is interpreted as a token by a user of the blockchain or a user of a particular token protocol. That is, the user agrees that the output portion of a transaction, more specifically a particular token data (e.g., a token protocol flag, followed by a quantity), is interpreted as and used as a token. The owner of the output (usually meaning the user of the address where the output is locked) owns the token. Thereafter, the token can be used, sold, traded, etc. for a particular purpose according to a particular token protocol. For example, a cinema issues a token to a user, and the user pays the price of the token in exchange for watching a movie at the cinema, or a bank issues a token in exchange for a customer's US dollar deposit, which is used for regular payments, and the customer can use it for normal payments and later a third party can exchange it for US dollars at the bank.

Summary of the Invention

[0004] As described above, in previous attempts to create tokens using blockchain, it typically involves defining the token in an additional data field of a transaction by including the token data in the output script code or another additional non-pausable output. These tokens are different from the digital assets (which are themselves composed of their native tokens) that underlie the blockchain on which the tokens are created. That is, transactions containing tokens according to these previous schemes created new tokens in an additional data structure while using the underlying digital assets (or "native tokens") as usual. The new tokens were independent of the native tokens. To separate the newly created tokens from their native tokens, all recent attempts have failed to achieve this without imposing a large and unnecessary adjustment burden, ultimately preventing the widespread adoption of the intended tokens.

[0005] According to one aspect disclosed in this specification, a computer-implemented method for sending digital tokens using blockchain transactions is provided. Each token is represented by a single unit of a unique unit of the digital asset underlying the blockchain. The method includes generating a first token transaction and sending the first token transaction to a blockchain network. The first token transaction includes a first token output, and the first token output includes a first token locking script and an amount of the first token. The first token locking script includes a variable component and a constant component. The variable component includes a first payment address embedded in a payment template. The constant component includes a token mechanics sub-component, and the token mechanics sub-component is an input script of a spending transaction, and when the input script is executed together with an input script that includes the amount locked in a previous transaction output that has been spent and the respective locking scripts, in addition to all of the spending transaction itself, it is configured to perform the following operations. The first operation is to obtain one or more data pairs from the input script of the spending transaction, and each data pair includes i) at least each payment address included in the respective locking script of the output of the spending transaction, and ii) the corresponding amount of the underlying digital asset locked by the respective locking script of its output. Another operation includes verifying whether one or more outputs of the spending transaction include respective locking scripts that include a) respective payment script templates including a predetermined payment address or b) respective variable components including respective payment addresses other than the predetermined payment address and the subsequent constant component.Another operation includes verifying, for one or more outputs of the expenditure transaction, whether the total amount of the underlying digital assets locked by the respective locking scripts of the one or more outputs is equal to the amount of the first token. The token mechanics sub-component is configured to fail during execution if any of the verification steps fails.

[0006] Unlike previous token attempts, the newly issued tokens according to the present invention are the underlying digital asset tokens themselves. That is, the native tokens themselves are converted into a new type of token. These new tokens no longer perform their normal functions as native tokens unless they are converted into the underlying digital assets under specific conditions encoded in themselves at the time of their issuance.

[0007] For a token to be spent, allocated, or otherwise transferred so that it can function as a token, the expenditure transaction that should succeed must have, in its next output, a locking script in the same format as the previous expenditure output (called UTXO*) that is being spent. That is, similar to the token expenditure output being spent, the expenditure transaction must include an output with a locking script having the same constant components of the new token output in order to be sent normally. This constant part cannot be changed or omitted until its redemption during the token's validity period.

[0008] This constant part is the code part of the token, and among its various operations, to transform the nature of the token, 1) self-immutability, 2) impossibility of its own omission, and 3) most importantly, preservation of the token amount, that is, it locks the token and its amount (in whole or in part) leaks as a miner fee (if the total output amount is less than the total input amount) or is not spent except in the form of an output of a unique smart locking script (unless it is redeemed to a specific address encoded in itself at the time of issuance).

[0009] Put simply, while making it impossible to use native tokens in a normal way, a newly defined thing is implemented to change its nature.

[0010] As a result, each single unit of the underlying digital asset represents a redefined single token, having the effect of stopping its normal function. Continuing with the example of the Bitcoin blockchain, a single Satoshi is redefined as a single token. The owner of the token cannot transfer the token to another user unless the locking script contains exactly the same constant components, thereby implementing new token mechanics. The only variable component that can be changed in the locking script is a standard template that is involved in the transfer of ownership, i.e., enabling the current owner to transfer part or all of the token to the next owner according to the address included in such a standard template (e.g., used in the same way as the native token of the original asset).

[0011] In other words, unlike previous attempts that rely on attaching metadata to represent tokens, according to this scheme, the tokens of the present invention are single units of the underlying digital asset that are reconfigured to function as separate entities and operate according to different rules (encoded in themselves).

[0012] As described above, the token can be reconverted into the underlying digital asset. That is, it can be used again as a native token only if the token meets certain conditions encoded in the constant part of the script, e.g., movement to a predetermined repayment address. That is, only the hard-coded user or institution (i.e., the entity that controls the repayment destination) can restore the token to the nature of the normal underlying digital asset and restore its original function. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] To aid understanding of embodiments of the present disclosure and to show how such embodiments may be implemented, reference is made, by way of example only, to the accompanying drawings.

Figure 1

Figure 2

Figure 3

Figure 4

DETAILED DESCRIPTION OF THE INVENTION

[0014] Embodiments of the present invention involve the creation and transfer of blockchain transactions. Those skilled in the art are proficient in the blockchain technology itself, but before explaining the embodiments themselves in detail, a brief overview of the blockchain is first provided.

[0015] A blockchain is in the form of a distributed database (or ledger) and functions as a record of all valid transactions that have been transferred to the blockchain network so far.

[0016] Valid transactions broadcast on the blockchain network are recorded in the blockchain in block units by miners (also called mining nodes). Blockchain transactions are used for the management of the amount of digital assets, that is, for transferring ownership. An exemplary blockchain is the Bitcoin blockchain, and its digital asset is called Bitcoin. There are many different blockchains, and the present invention is not limited to a specific implementation. Each transaction includes, among other things, at least one input and at least one output. The input includes a reference to an unspent transaction output (UTXO) from a previous transaction. The transaction uses the unspent transaction output (UTXO) as an input and distributes its value to a new output. The output usually includes a lock condition that locks the value of the output, and in order to unlock the lock, it is necessary to provide specific data (for example, a series of signatures or other information) to the input of the new next transaction. The output can also be used to write data (for example, text, image, etc.) to the ledger. The input of a transaction usually includes a digital signature that signs at least a part of the transaction. Therefore, a series of transactions includes a series of digital signatures that map the entire history of the valid exchange of digital assets until its creation.

[0017] The blockchain starts from the "genesis block", which is the first block among those created so far. Each block of the blockchain refers to the previous block going back to the genesis block. That is, the nth block refers to the (n - 1)th block, the (n - 1)th block refers to the (n - 2)th block, and so on back to the genesis block.

[0018] A block contains an ordered list of blockchain transactions and a block header. The block header includes a Merkle root generated by hashing the ordered list of blockchain transactions into a Merkle tree, a timestamp, a reference to the block before which the current block is built, and means to verify the "proof of work" required for other miners to accept the block as valid. The verification means is the answer to a hash puzzle unique to each block. The blockchain protocol executed by the mining nodes of the blockchain network uses a hash algorithm that requires these miners to pre - construct their candidate blocks before attempting to solve the puzzle. Without the correct answer, a new block cannot be submitted to the network. The "mining" process is basically a process of competing to find the answer to "solve" the current block in order to get to the next block. It is difficult to solve the hash puzzle of each block, but once a valid solution is found, it is very easy for the rest of the network to confirm that the solution is correct. There are multiple valid solutions for any block, and only one of the solutions needs to be found for the block to be solved.

[0019] The following briefly describes the process of attempting to mine a new block onto the blockchain. When a blockchain transaction is sent to a mining node, it is first verified according to the consensus rules of the blockchain network. If the transaction is valid, it is added to the pool of unconfirmed transactions. This pool is sometimes called the "mempool". The mempool functions as a temporary storage place for the transactions to be mined into the next block. Each mining node has its own mempool, and if a particular transaction is broadcast to multiple mining nodes, it can be included in two or more mempools.

[0020] Miners obtain transactions intended to be included in the next block, hash them into a Merkle tree structure, and include the resulting Merkle root in the candidate block header. Next, the miner attempts to hash this candidate block header to find a valid proof of work. A Merkle tree is a data structure in the form of a tree of hash values. In the context of a blockchain, transactions are hashed to form the leaf nodes of the tree. Pairs of leaf nodes are concatenated and then hashed to form the nodes of the upper layers of the tree. Pairs of nodes within that layer are concatenated and hashed to form the nodes of an even higher layer of the tree. This process is repeated until only one node remains, called the root node or Merkle root.

[0021] A hash function is a function that converts a string of data of any length into a fixed-length unique (virtually zero collision probability) value called a hash value or hash digest. A hash is a one-way function, meaning that it is impossible to determine what the input data was by looking at the hash value generated from it. On the other hand, it is trivial to run the same input data through the same hash function and reproduce the same hash. Some blockchain protocols use the SHA-256 hash algorithm, and some protocols use the SHA-256 hash algorithm twice. That is, the candidate block header passes through the same hash algorithm twice.

[0022] A valid proof of work is found by hashing the candidate block header (combined with other data as described below) until the result is less than another value called the target value. The target value is automatically adjusted by the blockchain protocol so that it takes an average of 10 minutes for the blockchain network to find a valid proof of work.

[0023] To change the hash value, the mining node must add additional information to the candidate block header. Usually, the mining node uses two "nonce fields" to change the value to be hashed and thus change the resulting hash value. The first nonce field is included in the block header itself, and the second nonce field is included in the "coinbase transaction". The coinbase transaction is a transaction created by the mining node and included in the candidate block. Each field contains an incrementable counter parameter. The hash function iterates through all values of the first nonce field, then increments (or changes) the second nonce field and then examines all permutations of the first nonce field again. Incrementing the second nonce field involves recomputing the Merkle root when changing the hash of the coinbase transaction included in the Merkle tree.

[0024] When the mining node finds a valid proof-of-work hash for the block (i.e., a candidate block header that hashes to a value smaller than the target value), it broadcasts the new block to the rest of the blockchain network. Other nodes on the network accept this new block only if all the transactions within the block are valid and not already included in the block. All blocks are timestamped, and a series of blocks are generated because each block references the hash of the block preceding it, hence the term "blockchain".

[0025] Blockchain transactions are explained in more detail. The following table is a schematic diagram of the structure of a typical transaction according to some blockchain protocols. It will be understood that different blockchain protocols may use different transaction structures. Therefore, the following explanation is provided for context only and is not intended to limit all embodiments.

[0026] As shown in the table, a transaction consists of a series of data fields. In its raw form, a transaction consists of a serialized series of data fields, usually represented in hexadecimal.

[0027]

Table 1

[0028] A transaction has one or more inputs, and each input references the output of a previous transaction. Each input can reference a different output of the same previous transaction, an output from a different transaction, or a combination thereof. Each input contains an unlocking script (sometimes called a "ScriptSig") that unlocks the referenced output if the correct data is included. The unlocked output of a previous transaction or the amount of digital assets previously locked to that output is used (i.e., allocated) by the output of the current transaction. The amount of unlocked digital assets can be used in its entirety by one output or distributed among two or more outputs of the current transaction.

[0029] A transaction also has one or more outputs that together distribute the total amount of digital assets unlocked by the inputs. Usually, the total of the output values is less than the total of the input values, and the difference is paid as a fee to the mining node that records the transaction in a new block. An output can be either a spendable output or an unspendable output. A spendable output contains a locking script (sometimes called a "ScriptPubKey") that defines one or more conditions that must be met to be unlocked by an input of a later transaction. An unspendable output does not contain a lockable locking script. That is, a non-consumable output contains a locking script that fails to execute the locking script.

[0030] Embodiments of the present invention enable a first party (referred to as "Alice") to send one or more tokens to a second party (referred to as "Bob"). At least a part of the following description refers to the first party, Alice, sending tokens to the second party, Bob. However, this is for illustrative purposes only. These embodiments also apply when the second party, Bob, sends tokens to a third party, such as a merchant. Additionally, reference is made to the issuer of the tokens, i.e., the party that initially issued the tokens to, for example, Alice. Also, at least a part of the following description refers to a "first token transaction". Unless otherwise required by the context, the first token transaction can be created by any of Alice, Bob, or the token issuer.

[0031] Figure 4 shows an exemplary system including several parties, such as a token issuer, Alice, Bob, and a merchant. The term "party" can be used to mean a user (e.g., Alice), but a party can take other forms, such as a collection of users in the form of a company or other forms of organizations. Also, it is not excluded that a party can be an autonomous entity, i.e., an entity that performs a predetermined action based on one or more conditions. Such an autonomous entity may be referred to as an "agent" in the art.

[0032] Although not shown, each party operates its respective computer device. Each party's computer device includes a respective processing device that includes one or more processors, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each party's computer device further includes a memory, i.e., a computer-readable storage device in the form of a non-transitory computer-readable medium. This memory may include one or more memory media, such as magnetic media like hard disks, SSDs, electronic media like flash memory or EEPROMs, and / or optical media like optical disk drives, and may include one or more memory units using such media. The memory on each party's computer device stores software that includes respective instances of at least one client application arranged to operate on the processing device. It will be understood that any operation attributed to a particular party herein may be performed using software operating on the processing device of the respective computer device. Each party's computer device includes at least one user terminal, such as a desktop or laptop computer, a tablet, a smartphone, or a wearable terminal such as a smartwatch. The computer device of a particular party may also include one or more other network resources, such as cloud computing resources, accessed via the user terminal.

[0033] The client application is first provided on a suitable computer-readable medium for any party's computer device, such as downloaded from a server or provided on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD-ROM, or a removable optical drive.

[0034] The token issuer is the party that issues tokens to the first recipient, e.g., Alice. The tokens can be issued to Alice using a first token transaction generated by the token issuer or Alice herself can generate the first token transaction. For example, the token issuer and Alice agree on the number of tokens to be issued to Alice (and other applicable contractual conditions), and then Alice can effectively issue the tokens to herself by transferring one or more tokens to another party, e.g., Bob.

[0035] Alice (or the token issuer) generates the first token transaction. A token transaction includes one or more inputs and one or more outputs. Optionally, one of the inputs can be used as a fee payment to pay a mining node a fee for recording the token transaction in a block. Since a transaction fee is not always required, such a fee payment is not mandatory. Similar to all blockchain transactions, a token transaction includes an input for unlocking the lock of the output of a previous transaction. In the case of the first token transaction, the referenced output of the previous transaction must include at least the amount of the original asset that is to be reconstituted as a token. As shown in Figure 4, since the amount of the first token is 1000, the referenced output must have a value of at least 1000 units of the original asset. This number is arbitrarily selected and generally any number can be used as the amount of the first token. For the sake of brevity, the unit of the original asset is called Satoshi. This is a particular unit of the Bitcoin blockchain, but this does not limit all embodiments.

[0036] The first token transaction includes a first token output. The first token output locks the amount of the first token (1000 Satoshi). That is, the first token output includes a first token locking script that locks the amount of the first Satoshi into a newly defined token of the same amount. The first token locking script includes a variable component and a constant component. In other words, the variable component is one section (i.e., part) of the first token locking script, and the constant component is another section (i.e., part) of the first token locking script. As its name indicates, the variable component can vary between token transactions, while the constant component remains the same.

[0037] The variable component is part of the token locking script that enables the transfer of the token to another party. The variable component includes a payment template that includes (e.g., encloses) a payment address. The payment address can be based on the public key of the receiving party. For example, the payment address can be a PKH (public key hash) address, i.e., the hash (or double hash) of the public key. If the first token transaction is generated by the token issuer, the payment address is linked to Alice. If Alice generates the first token transaction, the payment address is selected by Alice. Alice can select another address linked to herself or an address linked to another party, e.g., Bob or a merchant. The payment address can be treated as a sub-component of the variable component. The variable component can include one or more additional constant sub-components. For example, the variable component can include one or more constant opcodes for creating an output in P2PKH (pay-to-public-key-hash) format.

[0038] The constant component includes a token mechanics sub-component (hereinafter abbreviated as "token sub-component") that is a constant sub-component of the constant component. The token sub-component is part of the first token locking script that reuses the underlying digital asset as a token. For example, 1000 Satoshi is made into 1000 tokens. The token sub-component is configured to obtain data from the input of the spending transaction and perform at least two verification steps. Further, the token sub-component is set to fail the execution of the token locking script if the verification fails. That is, if any of the verification steps fails, the execution of the token locking script fails together with the unlocking script from the input of the spending transaction.

[0039] For the token sub-component to execute effectively, it is necessary for the input of the spending transaction (specifically, the unlocking script of the input) to contain specific data. The input of the spending transaction is also called the spending input. In particular, the unlocking script of the spending input must contain at least part of the spending transaction, that is, in addition to the unlocking script itself, spending transaction data (some parts remain as they are and some parts are just hashed). Hereinafter, this data is called the hash preimage (or simply the preimage) because its hash functions as the input to the ECDSA verification formula. The preimage includes the fields of the spending transaction and the used ones, and the data items generated (hashed) based on these transaction fields. In other embodiments, all data fields of the spending transaction are literally included in the unlocking script of the spending input.

[0040] The token sub-component is configured to obtain, when executed, in addition to the preimage, one or more data pairs from the unlocking script of the spending input. Each data pair includes at least the payment address of the locking script of the spending transaction and the corresponding amount of the underlying digital asset locked by that locking script. In some examples, the spending transaction includes only one output, i.e., only one locking script. In that case, the token sub-component obtains one data pair. In other examples, the spending transaction includes multiple outputs, i.e., multiple locking scripts. In that case, the token sub-component obtains multiple data pairs.

[0041] The required data can be obtained by parsing the unlocking script of the payment input and extracting the data pairs. This may require including the data pairs in the unlocking script at a predetermined location. A more detailed description is provided below.

[0042] Upon obtaining one or more data pairs, the token sub-component is configured to verify whether the output of the spending transaction is in a specific format. At least one output of the spending transaction must include either only a predetermined payment address that is part of a predetermined standard payment template or any address that is part of a predetermined standard payment template followed by a constant component of the token output (i.e., the same constant component). The token sub-component may determine and verify whether two or more outputs of the spending transaction include any payment address embedded in a predetermined standard payment template, followed by a constant component of the token output. The spending transaction may verify that it includes one or more outputs that do not include a predetermined payment address (only its corresponding standard template) or any payment address (its corresponding standard template) followed by a constant component of the token output.

[0043] The token sub-components are also configured to verify that the sum of the values locked by the output of a spending transaction, which together include either a predetermined payment address or any payment address and subsequent constant components, is equal to (i.e., the same as) the amount of the first token. The output of a spending transaction that includes either a predetermined payment address or a constant component may be referred to as a smart token output. The token sub-components prevent the reverse flow of those tokens to their original or other forms of use in order to verify that the total amount of tokens locked by the smart token output is equal to the amount of the first token.

[0044] For example, consider the case where a spending transaction includes a single smart token output (the first output of the spending transaction). The token sub-components are configured to verify that the first output of the spending transaction takes a particular form or has a first locking script that includes particular data. Specifically, the first locking script must include either a predetermined payment address (as part of a payment template) or an arbitrary payment address (as part of a payment template) followed by the constant part of the token locking script. Only one of the two is required, but if both are missing, the verification fails. This verification process is possible because the token sub-components obtain the first locking script of the spending transaction from the unlocking script of the spending input. Thus, the token sub-components can search for the first locking script for the predetermined payment address or constant component.

[0045] An expenditure transaction may include multiple outputs as described above. Some of the additional outputs may be smart token outputs or they can be used for different purposes. In this case, the token sub-component is configured to verify whether two or more outputs of the expenditure transaction include either a predetermined payment address or a constant component of a token transaction, i.e., any payment address followed by a constant component of a token locking script. Depending on the implementation, the token sub-component may be configured to verify whether all of the multiple outputs of the expenditure transaction include a predetermined payment address or a constant component. In other examples, the token sub-component may be configured to verify whether some, but not all, of the multiple outputs include a predetermined payment address or a constant component. For example, the token sub-component may verify whether a predetermined number of outputs of the expenditure transaction, e.g., the first two outputs, i.e., the two outputs that logically appear first in the expenditure transaction, include a constant component.

[0046] In an example where the expenditure transaction includes one smart token output, the token sub-component is configured to verify whether the first amount of the underlying digital asset locked by the first locking script of the expenditure transaction is equal to the first token amount (i.e., 1000 Satoshi). Here, the first output having the first locking script is the output that logically appears first in the expenditure transaction.

[0047] When the expenditure transaction includes multiple outputs, e.g., a second output having a second locking script that locks a second amount of the digital asset, the token sub-component is configured to verify whether the sum of the first amount and the second amount is equal to the amount of the first token. Here, the second output is the output that logically appears second in the expenditure transaction. Generally, when the expenditure transaction includes multiple outputs that include either a predetermined payment address or a constant component, the token sub-component verifies whether the sum of each amount is equal to the amount of the initial token.

[0048] This process can be repeated for any number of outputs of the spending transaction. The spending transaction may be permitted to include an output that locks an amount of digital assets that can result in a total of digital assets greater than the amount of the first token locked by all of the outputs of the spending transaction. In this case, the token subcomponents are configured to verify together whether a given number of smart token outputs of the spending transaction lock an amount of digital assets equal to the amount of the first token, and the amount locked by non-smart token outputs is not considered. The non-smart token output can be a fee change output or an atomic swap output. For example, the total amount locked by the first two outputs of the token transaction must be equal to the amount of the first token, while the third output (e.g., a fee change output) can lock an additional amount funded by additional inputs. Note that the third output is used for illustrative purposes. The fee change output will be further described below. For now, it suffices to say that it is only permitted if the fee change output (or another type of "additional output") is not a token output, i.e., does not contain the constant component of the token locking script.

[0049] The constant component of the token locking script may include a predetermined payment address. That is, since the predetermined payment address can be hardcoded into the constant component, it must be included in the first locking script of the spending transaction. The predetermined payment address can be a repayment address, something other than a token, e.g., an address to which a portion or all of the tokens are transferred for repayment for a FIAT currency token.

[0050] As described above, the unlocking script of the spending input of the spending transaction may include the preimage. The preimage may include one, some, or all of the fields in the following table.

[0051]

Table 2

[0052] Note that the specific structure of the preimage is included for illustrative purposes, and other structures may be used. For example, the size of the data fields may vary depending on the specific blockchain used to implement the present invention.

[0053] In these examples, the token sub-components can be configured to obtain them by extracting the token locking script of the first token transaction (i.e., the input scriptCode) and the initial token amount (i.e., the value of the output used by the input) from the preimage. Since the sizes of all data fields of the preimage except scriptCode are known, the token sub-components can extract the necessary fields by parsing and extracting the data at predetermined positions.

[0054] As shown in Table 2, the preimage may include the hash of the outputs (hashOutputs) of the spending transaction. This is the hash of each output, i.e., the value locked by the locking script and the locking script itself. Therefore, if the spending transaction includes one output, hashOutputs includes the hash of one value concatenated with one locking script. If the spending transaction includes two outputs, each pair of value locking scripts is concatenated and hashed to form hashOutputs. The token sub-components can extract hashOutputs from the preimage, for example, by parsing and extracting data at specific positions.

[0055] The unlocking script for the spending transaction includes one or more data pairs as described above. Recall that each data pair includes a value and a locking script. The token subcomponent can be configured to generate its own version of hashOutputs, i.e., generate the hash of one or more data pairs, and verify that the generated hash is equal to the hash extracted from the preimage (i.e., hashOutputs). This can be done to verify that the spending user, e.g., Alice or Bob, included the correct data pairs in the unlocking script for the spending transaction.

[0056] In some examples, the token subcomponent can be configured to verify whether the preimage included in the unlocking script for the spending transaction was correctly generated, i.e., whether the data fields of the preimage correspond to the actual data fields of the spending transaction. This is necessary when the system's users cannot be trusted to correctly generate spending transactions. To do this, the token subcomponent generates its own version of the expected preimage of the spending transaction, e.g., one that includes all of the data fields of Table 2. Then, the token subcomponent can verify whether the preimage extracted from the unlocking script for the spending transaction matches the preimage generated by the token subcomponent.

[0057] One way to verify whether the preimage included in the unlocking script for the spending transaction is correct is to use a pseudo opcode known in the art as OP_PUSH_TX. However, an equivalent opcode, or more generally, any equivalent code that performs a function equivalent to OP_PUSH_TX, may be used instead.

[0058] Generally, the token sub-component can be configured to generate a digital signature (e.g., an ECDSA signature) using the preimage from the unlocking script and the private key. The private key is included in the unlocking script of the spending transaction. Next, the token sub-component verifies whether the generated digital signature is a valid signature when verified against the generated preimage (i.e., the preimage generated by the token sub-component) and the public key corresponding to the private key. The public key is also included in the unlocking script of the spending transaction. The digital signature is valid only if the two preimages exactly match. Since the private key used is made public by being recorded on the blockchain, a "dummy" private key, i.e., one that does not compromise the security of other data or blockchain transactions when made public, should be used. However, generally, any private key, e.g., any random key, can be used. This signature check can be performed by utilizing the OP_CHECKSIG opcode to verify the signature. OP_CHECKSIG is an opcode that succeeds (i.e., executes normally) only if the signature is for the current transaction, i.e., the spending transaction in this case.

[0059] Returning to the output of the spending transaction, the token sub-component can be configured to verify whether the output of the spending transaction (specifically their respective locking scripts) contains a payment address of a predetermined type, i.e., format. Each payment address preferably should be of the same type as the payment address included in the variable component of the token transaction. More preferably, the payment address must be a PKH address. This can be verified based on the payment address itself only or based on the payment address and one or more additional data items, e.g., one or more opcodes or other data on either side of the payment address. For example, a P2PKH output contains specific additional data that can be checked in the output.

[0060] The token sub-components of the constant component have been described. The constant component may include a constant data sub-component (hereinafter abbreviated as "data sub-component"). Generally, the data sub-component may include any data to be stored in each token output. For example, the data sub-component may include a token protocol identifier, e.g., a flag indicating that the token is of a specific protocol, e.g., a flag indicating that the token represents FIAT currency. In addition or alternatively, the data sub-component may include a transaction identifier (TxID) of a transaction recorded on the blockchain (referred to as "token issuance transaction"). Similarly, the token issuance transaction may generally include any data, e.g., a token issuance contract and / or an initial token amount issued by the token issuer. The data sub-component may be included after the OP_RETURN opcode or code performing an equivalent function.

[0061] The above description is mainly related to initial token transactions and spending transactions. Hereinafter, spending transactions that are token transactions themselves will be described in detail. A spending transaction refers to the "first token transaction" so that the term "spending transaction" can be reserved for transactions subsequent to referring to the output of the first token transaction.

[0062] The first token transaction will be described with reference to FIG. 1. As shown in FIG. 1, the first token transaction 100 includes a transaction identifier (Token TxID), one or more inputs 104, and one or more outputs 106. Each input 104 includes an input value 108 and an unlocking script 110. Note that FIG. 1 is a schematic diagram. The input 104 itself does not include the input value 108. Rather, the input 104 includes a pointer (e.g., TXID and VOUT) to an unspent transaction output (UTXO) of a previous output, and the previous output locks a value 108 called the input value 108. However, the value 108 unlocked by each unlocking script 110 is shown for the purpose of explanation. Each output 106 includes an output value 112 and a locking script 114.

[0063] Regarding the output 106 of the first token transaction 100, since it has already been described above with reference to the expenditure transaction, it will be described first. The token transaction 100 includes a first token output ("repayment / token output"). The first token output is shown in FIG. 2. As shown in FIG. 2 and as already described above, the first token output 200 includes a variable component 202 and a constant component 204. The constant component 204 includes a token mechanics sub-component 206 and, in this example, a constant data sub-component 208.

[0064] The variable component 202 includes the respective payment addresses of the parties to whom the amount of the first token (e.g., 700 tokens) is assigned. The token sub-component 206 is configured to perform some or all of the above-described verification steps. For example, the token sub-component 206 is configured to verify whether the total amount of digital assets to be locked by the output of a predetermined number (e.g., 1 or 2) of expenditure transactions is equal to the amount of the first token (700 tokens). The token sub-component 206 of the first token output 200 is also set to verify whether the input of the expenditure transaction after attempting to unlock the first token output 200 includes either a normal payment template including the repayment payment address or the entire format of the first token output 200 including the variable component 202 and the constant component 204. Generally, the token sub-component 206 can be configured to perform any of the above-described verification techniques.

[0065] The first token transaction 100 may also include a second token output. The second token output also includes respective variable components and respective constant components. The variable component of the second token output may include a different payment address compared to the variable component 202 of the first token output 200. The token sub-components of the second token output are configured to perform the same verification steps as the token sub-components 206 of the first token output 200, except that the verification is for a different spending transaction, i.e., a transaction having an input that references the second token output. That is, the first token transaction 100 has two or more outputs, and each of those outputs can be used (unlocked) by a different spending transaction. For example, the token sub-components of the second token output are configured to verify whether the total amount of digital assets locked by a predetermined number (e.g., 1 or 2) of outputs of the spending transaction is equal to the amount (300) of the second token.

[0066] The first token transaction 100 may include any number of token outputs that attempt to be used, as long as the sum of the amounts of the respective tokens is exactly equal to the amount (1000 tokens) locked by the first token output (referenced by the TXID field of the input of the transaction).

[0067] The first token transaction 100 may include a fee change output. With this output, a fee change (X - δ) can be returned to the fee change payment address. In the example of FIG. 1, a fee payment input having an input value (X) is used to pay the transaction fee (δ).

[0068] In addition or alternatively, the first token transaction 100 may include an atomic swap output. The atomic swap output will be described below.

[0069] In the example of FIG. 1, the first token transaction 100 includes a token input. The token input is equivalent to the expenditure input detailed above. More specifically, the token input refers to the token output of a previous token transaction, such as the initial token transaction. In this example, the referenced token output locks 1000 tokens. The token input includes all of the first token transaction except for each of the outputs 106 of the first token transaction 200, including the respective data pairs for each output 106. That is, in this example, the token input includes three values (700, 300, X-δ) and three corresponding payment addresses (one from each of the token locking scripts (“repayment / token output”, “token output (split)”, “fee change / atomic swap”)). The value 112 and the payment address can be paired such that the payment address from the first token output locking script follows the amount of the first token (700), followed by the amount of the second token (300), the corresponding payment address from the second output locking script, and so on. The token input also includes a signature for unlocking the referenced token output, that is, a signature corresponding to the payment address included in the variable component of the referenced token output. When Alice transfers a token, Alice's signature is included in the input of the expenditure transaction. In some examples, instead of just the payment address, the entire locking script can be included in the input (i.e., as part of the data pair).

[0070] As shown in FIG. 1, the first token transaction 100 includes a fee payment input. The fee payment input refers to the output of an individual previous normal non-token transaction output and includes the fee paid to the mining node to include the first token transaction 100 in a block. The fee payment input includes at least one digital signature according to the requirements of the referenced output. In some examples, the digital signature is generated by the owner of the token output referenced by the token input of the first token transaction 100. For example, if Alice sends 700 out of 1000 tokens to Bob and 300 tokens to a merchant, Alice funds the transaction. In that case, Alice's signature is included in the fee payment input. However, it is not excluded that a different party, such as Bob, can fund the transaction by unlocking a UTXO locked to Bob. In this case, Bob's signature is included in the fee payment input. The atomic swap output is as described above, and the miner's fee payment input has an additional task of payment (for the token). In this example, Bob funds the transaction by including his signature in the fee / “token purchase” input, and the “fee change” / “atomic swap” output is locked to Bob. That is, the “fee change” / “atomic swap” output includes a payment address linked to Bob, for example, the hash of the public key owned by Bob.

[0071] To enforce the atomic swap, Alice creates a complete transaction excluding the fee / “token purchase” payment input. Next, Bob creates and adds the fee / “token purchase” payment input. One way to do this is for Alice to sign her inputs (i.e., token inputs) and the two corresponding outputs with a sighash flag (e.g., ALL|ANYONECANPAY) that allows another party to add an input. Next, Bob adds an input with a different sighash flag (e.g., ALL - finalizes the entire transaction and does not allow further additions).

[0072] Figures 3A and 3B show the concept of atomic swap in more detail. Solid arrows indicate essential inputs and outputs, and dashed arrows indicate optional inputs and outputs. Inputs to the transaction are shown on the left side of the figure, and outputs of the transaction are shown on the right side. Figure 3A schematically shows a transaction similar to that of Figure 1. This exemplary token transaction includes a token input generated by Alice that unlocks the token output of the previous token transaction, along with a fee payment input for funding the transaction fee (the fee taken by the mining node to record the transaction on the block). The token transaction also includes a fee change output that pays the change, specified at the output as the difference between the fee input payment and the transaction fee, to Alice locked to her address in the normal payment format, along with a token output that is sent to Bob locked to Bob's address included in token form such as 200.

[0073] Figure 3B shows an exemplary atomic swap transaction. Bob's token output is generated in the same way as in Figure 3A. Alice regenerates the token input to unlock the token output of the previous token transaction, but this time she signs the transaction with the "ALL / ANYONECANPAY" sighash flag. This means that Alice's signature signs this one input, i.e., all outputs other than the input spending token output signed with the sighash flag. The remaining inputs are excluded. This sighash flag allows anyone to fund the transaction, but they cannot change the destinations and amounts, as anyone can add or remove other inputs. This allows Bob to add only his payment input, which also includes the miner's fee. Bob includes his signature and signs with the "ALL" sighash flag. This means that Bob's signature signs all inputs and outputs, protecting all elements from further possible changes. In this example, the second output is added by Bob's input and will be paid to Alice. This has the effect of enforcing the atomic swap, so the tokens are sent to Bob only if Bob pays Alice the price of the tokens. If Bob is not satisfied with any element of the transaction, he simply does not provide his signature, so the tokens do not move to Bob's address and Alice does not receive payment. Similarly, Bob cannot change the inputs and outputs created and signed by Alice, so it is guaranteed that Alice will receive the tokens only if the payment conditions set by Alice are met.

[0074] Figure 4 shows an exemplary flow of tokens from issuance to redemption. The flow generally goes from top to bottom. As an arbitrary first step, a legal contract is created between the token issuer and Alice, the initial recipient. The contract may define the trading conditions of the tokens, including how the tokens are to be redeemed, and the amount of the initial tokens (e.g., 1000). Thereafter, the token issuer may create a first token transaction and send the tokens to Alice. Alternatively, Alice may create a first token transaction and send some or all of it to another user, such as Bob, or to Alice herself. In Figure 4, Alice sends all of the tokens to Bob. That is, all of the tokens are assigned to one token output that is sent to Bob's payment address. Next, Bob creates a token transaction having two token outputs. The first token output sends 300 tokens to the merchant's payment address. The second token output sends 700 tokens to Bob's payment address, which may be another payment address of Bob. Next, the merchant redeems 300 tokens, that is, by sending the tokens to the redemption payment address. Next, Bob first redeems 500 tokens and sends the remaining 200 tokens to another payment address linked to Bob. Finally, Bob redeems the 200 tokens. Note that in each transaction, the amount of tokens received matches the amount of tokens sent.

[0075] The embodiments of the present invention have been generally described above. Next, specific implementations of the present invention will be described. This specific example will be mainly described from the perspective of tokens representing fiat currency. That is, the tokens are legally pegged tokens. However, this is only one of many use cases of the present invention. Furthermore, this example is intended to be implemented using the Bitcoin blockchain. However, generally, any output-based (e.g., UTXO-based) blockchain may be used, and the Bitcoin blockchain is one specific example among them.

[0076] According to this example, the token is represented using Bitcoin, more specifically the basic unit of Bitcoin called Satoshi or Satoshi unit. The token output can include a single Satoshi representing a single token (e.g., a utility token such as an event, a movie theater ticket, a bus ticket, etc.). Therefore, this token cannot be divided and cannot be split during its life cycle. Or, the token output can include multiple Satoshis representing an envelope of multiple tokens (e.g., a token pegged to the US dollar where 1 token represents 1 US dollar cent).

[0077] The token output includes a variable part and a constant part. The variable part is the same as a normal Bitcoin payment template that transfers ownership of Bitcoin (i.e., Satoshi) through the use of ECDSA. The constant part cannot be changed or omitted throughout the token's validity period.

[0078] Despite the fact that each Satoshi represents a token and its normal functionality is disabled, it can represent something cheaper or more expensive than 1 Satoshi itself. Alice cannot transfer the token to Bob unless she holds this exact template as the locking script in her next token transaction. Only the ownership address of the variable part can be changed.

[0079] Note that this is not the same as previous attempts to interpret the output as a token output using metadata. The present invention fundamentally changes the mechanism of Satoshi regarding its normal use as Bitcoin.

[0080] The variable part is intentionally at the very beginning of the token locking script and is nothing more than a normal payment template, e.g., a P2PKH template. This provides maximum compatibility with existing blockchain client applications and browsers, and enables the payment address (wrapped in the template) to be searched for and identified in the current way. to be searched for and identified in the current way.

[0081] The token mechanics enforce at least three conditions. First, the use of a token is only possible if the next UTXO has exactly the same locking script as the UTXO that was used, except for the new ownership address. Second, spending by a transaction with a normal Bitcoin locking script template (e.g., P2PKH, P2PK, etc.) fails unless it is a P2PKH that includes a predetermined repayment payment address. The predetermined repayment payment address is included in the contract issued to Alice and hardcoded in the token locking script. If the token issuer sets the repayment address to an address linked to itself, this means that only the issuer can release the Satoshi representing the asset back to its original normal Satoshi use, for example, by releasing the represented asset such as US dollars, gold, etc. This makes the token permissionless. Third, when moving a token, the amount of Satoshi in the token output of the current unspent token output (UTXO) must be exactly the same as the amount of Satoshi in the token output of the spending transaction (e.g., repayment or next token transaction) or split into a set of two or more tokens (the total amount of which must equal the original amount of the UTXO). For example, a token can be split into two outputs of a spending transaction, and the locking scripts of the two outputs are identical to the locking script of the UTXO being used (except for the address of the variable part).

[0082] The state advanced in these stateful transactions is the ownership address updated per hop and (only in the case of the token envelope) the amount of the token, which can decrease by splitting.

[0083] The constant data part has two fields. One field contains a token protocol identifier, e.g., the token protocol flag of a Fiat pegged token. The identifier is used to specify the type of the token. The second field is a pointer to a special transaction (TxID), which carries a) the initial issuance contract with all the legal regulations, conditions, licenses and any other necessary information related to the attributes and issuance of the token (e.g., between the issuer and the client), and b) a predetermined exact Satoshi balance to be converted into the token in a subsequent transaction (which becomes the issuance transaction). The constant data field is placed behind the OP_RETURN opcode as just a data attachment, and an attempt at execution as part of the script code is avoided during script evaluation. That is, the constant data is preferably included at the end of the locking script and immediately after the OP_RETURN opcode for maximum compatibility of applications and browsers that perform searches in OP_RETURN transactions.

[0084] Regarding the transaction structure itself, the output of a token transaction can be one of three types: i) a normal output for repayment, ii) a token output, or iii) a normal output used for fee change, atomic swap, etc.

[0085] As an example, Alice may request a legally authorized entity to issue 1,000 tokens on her behalf and provide the entity with her payment address. The entity creates a contract in the form of a spendable transaction containing a pre - allocated amount of Satoshis corresponding to the requested amount (in this case 1,000). The terms, conditions, and licenses of the contract describe the actions required by Alice (e.g., sending a corresponding amount of fiat currency to the entity) and are signed by the entity with a flag such as ALL|ANYONECANPAY so that Alice can add her signature. When Alice signs the contract, publishes it to the blockchain, and performs the required action described (sending the fiat amount), the entity issues the tokens on her behalf to her payment address. Alice can use / spend / send the tokens all at once or in part. Since subsequent owners can optionally redeem the tokens, the tokens become non - approval - required.

[0086] Returning to the constant part of the token output, the constant part roughly consists of two parts. The first part performs OP_PUSH_TX and is involved in accessing the fields of the current transaction within script execution. The second part is the token logic.

[0087] The sighash preimage has been described above. OP_PUSH_TX performs a spending transaction that unlocks the token output pushed into the unlocking script for access within the executed script, i.e., the ECDSA signature of the preimage corresponding to the current transaction. OP_PUSH_TX ultimately calls OP_CHECKSIG for signature verification. This internal ECDSA signature should be independent of what is used for the token ownership relay as it is performed using any publicly accessible private key pair (one ephemeral pair, one constant pair). Also, in this case, OP_CHECKSIG functions as a validator as it constructs a unique preimage for ECDSA verification from the actual previous and current transaction fields when called. Thus, it fails or succeeds depending on whether the actual fields are the same as (or not the same as) those pushed into the unlocking script.

[0088] The token logic converts Bitcoin Satoshis into tokens. To do this, the code needs access to the Satoshi value (amount) of the previous transaction (i.e., the unspent output containing the token) and the Satoshi value of the current transaction (i.e., the spending transaction) to control the spending of Satoshis. The code also needs access to the previous and current locking scripts to control the format of the output locking script.

[0089] Once it is verified that the preimage pushed to the unlocking script of the current (spending) transaction is the same as the preimage of the actual current transaction, it is parsed to extract all relevant fields including the scriptCode, value, and hashOutputs of the output being spent by this input. The values (i.e., amounts) and locking scripts of the previous UTXOs (i.e., those being spent) are provided as-is in the preimage, but only the result of the hash of the locking script of the newly created output (combined with their new values) is available. Therefore, the locking scripts of these new outputs and their corresponding values should be placed next to the preimage in the unlocking script of the spending transaction that is next verified against the hashOutputs field of the preimage, which has been previously proven to be the same as what OP_CHECKSIG constructs when called.

[0090] Once all locking scripts and their values (i.e., amounts) for the previous and next outputs of the transaction are made accessible by the running code, the token rules can be enforced.

[0091] The following exemplary rules may be enforced. It will be understood that other additional or alternative rules may be enforced depending on the particular use case. In this example, the following are permitted. 1. Repayment function: Used to define a hardcoded address that can return the nature of the token to that of Satoshi, i.e., the underlying digital asset. 2. Splitting the token amount into a maximum of two possible outputs. 3. A P2PKH format for receiving a change from miner fee payments by an additional input or a third optional output for receiving money by the token seller in the case of an "atomic swap".

[0092] More specifically, the rules are as follows. 1. The first output of the token transaction is a) Repayment: A standard P2PKH template that includes a hard-coded repayment address that is required, or b) Token Relay: A smart token locking script identical to the previous output format is used only for. 2. The second output is optional for the case of token splitting and is thus only of the smart token type. Additionally, a) If it exists, the sum of the amount of that output and the amount of the first output must be equal to the amount in the spent UTXO. b) Otherwise, the amount of the first output must be equal to the amount in the spent UTXO. 3. The third output is only of the standard P2PKH template (the address is arbitrary). If it exists, it is used for changes in the payment of token operations (i.e., made using additional inputs).

[0093] Note that the P2PKH template is the transaction output script, and when pushed into the unlocking script preceded by VarInt (specifying the length of the next script) 0x19, it becomes "0x76a914+PKH+0x88ac" in hexadecimal format due to its 25-byte length. PKH is the public key hash address.

[0094] Pseudo-code examples for implementing these rules are provided.

[0095]

Table 3

[0096] The following code shows an actual exemplary implementation in the Bitcoin Script language. In this implementation, unlocking script parameters were used in the same order (left to right) as the above pseudocode function definition. This means that the leftmost was first pushed onto the stack. The hardcoded payback function address is placed to be the first field of the "constant code" part of the locking script, so it is pushed onto the stack immediately after the unlocking script data (when not considering the variable part that performs ECDSA signature verification).

[0097] Note that the implementation of this script is optimized for space rather than time (since the current fee payment in Bitcoin depends only on the TX size).

[0098] [Table 4] JPEG0007690565000007.jpg223157JPEG0007690565000008.jpg117157

[0099] Conclusion It will be understood that the above embodiments have been described for purposes of illustration.

[0100] More generally, according to one aspect disclosed herein, a computer-implemented method for sending digital tokens using blockchain transactions is provided, where each token is represented by a single unit of a unique unit of a digital asset underlying the blockchain, the method comprising generating a first token transaction and sending the first token transaction to a blockchain network, the first token transaction including a first token output, the first token output including a first token locking script and an amount of the first token, the first token locking script including a variable component and a constant component, the variable component including a first payment address embedded in a payment template, the constant component including a token mechanics sub-component, the token mechanics sub-component being an input script of a spending transaction, the input script being executed with an input script that includes, in addition to all of the spending transaction itself, the amounts locked in previous transaction outputs that have been spent and their respective locking scripts, and obtaining one or more data pairs from the input script of the spending transaction, each data pair including i) at least the respective payment address included in the locking script of the output of the spending transaction and ii) the corresponding amount of the underlying digital asset locked by the respective locking script of the output, and verifying that one or more outputs of the spending transaction include either a) each payment script template including a predetermined payment address or b) each locking script including a respective variable component including a respective payment address other than the predetermined payment address and the subsequent constant component, and verifying that, for one or more outputs of the spending transaction, the total amount of the underlying digital asset locked by the respective locking script of the one or more outputs is equal to the amount of the first token, the token mechanics sub-component being configured to fail during execution if any of the verification steps fail.

[0101] The spending transaction includes at least one output that includes a first locking script format. The spending transaction may include two or more outputs, e.g., a second output and a third output each having a respective locking script format. For the transaction to succeed, all the locking scripts of the new outputs of these spending transactions must have the same smart token format as the outputs of the previous transaction being spent or have a standard payment template with a predetermined repayment address. The only exception is any output (e.g., the last output), whose locking script must be a standard payment template having, for example, an address used for miner fee payment change as required or for receiving atomic swap payments. The input of the spending transaction should include a data pair for each output and the sighash preimage of the entire transaction, and the result of that hash serves as the input to the ECDSA verification formula. The token mechanics subcomponent is configured to operate based on this assumption. If the assumption is not met, the execution of the token mechanics subcomponent fails and no token operations are possible.

[0102] This also applies when the spending transaction has an additional optional miner fee change output that does not include the constant component of the first token locking script of the output where the spending is attempted. Native tokens locked in such an optional output are not part of the reserved amount of newly defined tokens from one transaction to another.

[0103] Part of the spending transaction is included in the input script in raw form, while other parts are included as the result of their hashes.

[0104] Each payment address may be embedded in the payment template.

[0105] In an embodiment, the spending transaction includes a first output including a first locking script and a second output including a second locking script, and the token mechanics subcomponent verifies whether the first output of the spending transaction includes a first locking script including a) each payment script template including a predetermined payment address or b) each variable component including each payment address other than the predetermined payment address and the subsequent constant component, and when present, whether the second output of the spending transaction includes a second locking script including a) each standard payment script template including a predetermined payment address or b) each variable component including any address other than the predetermined payment address and the subsequent constant component, and when the second output exists, verifies whether the total amount of the digital assets locked by the first locking script and the second locking script of the spending transaction is equal to the amount of the first token.

[0106] In an embodiment, the token mechanics component verifies whether, when the first locking script of the spending transaction does not include the standard payment script template including the predetermined payment address, the first locking script includes each variable component including a payment address other than the predetermined payment address and a subsequent constant component identical to the corresponding constant component of the first token locking script of the previous transaction being spent, and / or when the second locking script of the spending transaction exists, whether the second locking script includes each variable component including any payment address and a subsequent constant component identical to the corresponding constant component of the first token locking script of the previous transaction being spent.

[0107] In an embodiment, the constant component may include a predetermined payment address.

[0108] That is, a predetermined address is hard-coded in the constant part.

[0109] In an embodiment, the input script of the expenditure transaction may include a sighash preimage, which includes the first token locking script and the amount of the first token, and the token mechanics sub-component is configured to extract both the first token locking script and the amount of the first token of the output being spent from the preimage in order to perform the verification step.

[0110] The first token locking script included in the input of the expenditure transaction is the locking script of the output for which the expenditure is being attempted and is identical to the one being executed at that time. The amount of the first token included in the input of the expenditure transaction is the value held in the output for which the expenditure is being attempted.

[0111] In an embodiment, the preimage may include a hash of a concatenation of one or more data pairs, each data pair including a respective payment address from a respective locking script of the expenditure transaction and a corresponding amount locked by the respective locking script, and the token mechanics sub-component is configured to extract the hash of the concatenation of the one or more data pairs from the preimage, generate a hash based on the one or more data pairs, and verify whether the generated hash is equal to the extracted hash.

[0112] Depending on the format of the output of the expenditure transaction, one or more of the one or more "corresponding amounts" may be native tokens, for example, outputs for any change or "atomic swap" payment receipt, and one or more of the corresponding amounts may be, for example, redefined tokens for repayment or token output.

[0113] In an embodiment, the one or more data pairs used to generate the hash may be obtained from the input script or constructed by obtaining a pair of an input address and an amount of the previous output locking script from the preimage.

[0114] References to "hash" may be equivalent to "double sha256 hash". In general, any hash function may be used as long as the same hash function is consistently used.

[0115] In an embodiment, the token mechanics subcomponent may be configured to generate a preimage of the spending transaction data and verify whether the generated preimage of the spending transaction data is equal to the preimage included in the input of the spending transaction.

[0116] In an embodiment, the input of the spending transaction may include a dummy private key and a corresponding dummy public key, and the token mechanics subcomponent may use the dummy private key and the hash of the preimage included in the input of the spending transaction to generate a digital signature to verify whether the generated preimage of the spending transaction is equal to the preimage included in the input of the spending transaction, and verify whether the digital signature is a valid signature when verified against the dummy public key and the hash of the generated preimage of the spending transaction.

[0117] For example, depending on a specific signature algorithm for generating an ECDSA signature, a temporary dummy private key may be required.

[0118] For example, the subcomponent of token mechanics may include an OP_PUSH_TX pseudo opcode implementation configured to perform the verification of the generated preimage.

[0119] In an embodiment, the token mechanics sub-component may be configured to verify that each payment address included in the respective locking script of the expenditure transaction is of the same type as the first payment address included in the variable component of the first token output.

[0120] In addition, the token mechanics sub-component may be configured to verify whether each output of the expenditure transaction includes a respective payment script template of the same type as the payment script template included in the first token output, for example, a P2PKH locking script.

[0121] In an embodiment, the type of the first payment address may be a public key hash address.

[0122] In an embodiment, the amount of the first token may include a single unit of the underlying digital asset.

[0123] In an embodiment, the amount of the first token may include a plurality of units of the underlying digital asset.

[0124] In an embodiment, the constant component includes a data sub-component, and the data sub-component includes a token protocol identifier and an identifier of a token issuance transaction, and the token issuance transaction may include one or both of an issuance contract between a token issuer and an initial token recipient and an initial token amount.

[0125] The constant immutable data sub-component may be placed after the OP_RETURN opcode.

[0126] In an embodiment, the expenditure transaction may include a third output including a third locking script and a corresponding third amount, and the token mechanics sub-component is configured to check whether the third locking script includes or verifies each payment address of a predetermined payment type template, for example, the PKH address of a P2PKH payment template, and a corresponding amount thereof.

[0127] In an embodiment, the first token transaction includes a first token input that spends each token output of previous token transactions. The first token input includes all but itself of the first token transaction, the amount and the locking script of each of the previous token transactions that have been spent, and at least one or more data pairs. Each data pair includes at least the payment address included in the locking script of the first token transaction and the corresponding amount of the underlying digital asset locked by the respective locking script.

[0128] In an embodiment, the first token transaction includes a second token output, the second token output includes a second token locking script and an amount of a second token, the second token locking script includes respective variable components and respective constant components, the respective variable components include a second payment address, and the respective constant components match the constant components of the first token locking script.

[0129] In an embodiment, the first token transaction includes a third output, and the third output may include a third payment address.

[0130] In an embodiment, the first token input includes a first signature generated by a first party, the first token transaction includes a second input, the second input includes a second signature generated by a second party, the first token transaction includes a payment output including a payment address included in a payment template, and the payment address is linked to the first party.

[0131] The payment output is linked to the first party for receiving payment from the second party for the tokens sold.

[0132] According to another aspect disclosed herein, a memory including one or more memory units, and a processing device including one or more processing units, wherein the memory stores code configured to be executed on the processing device, and the code is configured such that when on the processing device, any of the methods of the above-described embodiments is performed, a computer device including the processing device is provided.

[0133] According to another aspect disclosed herein, a computer program embodied on a computer-readable storage device, the computer program being configured such that when executed on a computer device, any of the methods of the above-described embodiments is performed, is provided.

[0134] According to another aspect disclosed herein, a token transaction including a first token output is provided, the first token output including a first token locking script and an amount of the first token, the first token locking script including a variable component and a constant component, the variable component including a first payment address embedded in a payment template, the constant component including a token mechanics sub-component, the token mechanics sub-component being an input script of an expenditure transaction, the input script, when executed with the input script of the expenditure transaction, obtaining one or more data pairs from the input script of the expenditure transaction, each data pair including i) at least each payment address included in the respective locking script of the expenditure output, and ii) the corresponding amount of the underlying digital asset locked by the respective locking script of its output, verifying whether one or more outputs of the expenditure transaction include a respective payment script template including a predetermined payment address or a respective locking script including a respective variable component including a payment address other than the predetermined payment address and the subsequent constant component, and verifying, for one or more outputs of the expenditure transaction, whether the total amount of the underlying digital asset locked by the respective locking script of the one or more outputs is equal to the amount of the first token, the token mechanics sub-component being configured to fail during execution if any of the verification steps fails.

[0135] According to another aspect disclosed herein, a computer-readable storage medium storing the token transaction is provided.

[0136] Other variations or use cases of the disclosed technology may become apparent to those skilled in the art given the disclosure herein. The scope of the disclosure is not limited by the described embodiments, but only by the appended claims.

Claims

1. A computer-implemented method for sending digital tokens using blockchain transactions, where each token is represented by a single unit of a unique unit of the digital asset underlying the blockchain, the method comprising: generating a first token transaction; sending the first token transaction to a blockchain network; wherein the first token transaction includes a first token output, the first token output includes a first token locking script and an amount of the first token, the first token locking script includes a variable component and a constant component, the variable component includes a first payment address embedded in a payment template, the constant component includes a token mechanics sub-component, the token mechanics sub-component is an input script of a spending transaction, the input script, when executed with an input script including an amount locked in a previous output being spent and the respective locking script, includes at least a part of the spending transaction other than the input script of the spending transaction; obtaining one or more data pairs from the input script of the spending transaction, each data pair including: i) at least the respective payment address included in the respective locking script of the output of the spending transaction; and ii) the corresponding amount of the underlying digital asset locked by the respective locking script of the output; verifying whether one or more outputs of the spending transaction include respective locking scripts including a) respective payment script templates including a predetermined payment address or b) respective variable components including respective payment addresses other than the predetermined payment address and subsequent said constant components; verifying whether, for one or more outputs of the spending transaction, the total amount of the underlying digital asset locked by the respective locking scripts of the one or more outputs is equal to the amount of the first token; is configured to perform; the token mechanics sub-component is configured to fail during execution if any of the verification steps fails. A method.

2. The expenditure transaction includes a first output including a first locking script and a second output including a second locking script, and the token mechanics sub-component verifies whether the first output of the expenditure transaction includes a first locking script including a) each payment script template including a predetermined payment address or b) each variable component including each payment address other than the predetermined payment address and a subsequent constant component; when the second output exists, verifies whether the second output of the expenditure transaction includes a second locking script including a) each standard payment script template including a predetermined payment address or b) each variable component including any address other than the predetermined payment address and a subsequent constant component; when the second output exists, verifies whether the total amount of the digital assets locked by the first locking script and the second locking script of the expenditure transaction is equal to the amount of the first token; The method according to claim 1, which is configured to perform the above.

3. The token mechanics sub-component when the first locking script of the expenditure transaction does not include the standard payment script template including the predetermined payment address, verifies whether the first locking script includes each variable component including a payment address other than the predetermined payment address and a subsequent constant component identical to the corresponding constant component of the first token locking script of the previous transaction being spent, and / or when the second locking script of the expenditure transaction exists, verifies whether the second locking script includes each variable component including any payment address and a subsequent constant component identical to the corresponding constant component of the first token locking script of the previous transaction being spent; The method according to claim 2, which is configured to perform the above.

4. The method according to any one of claims 1 to 3, wherein the constant component includes the predetermined payment address.

5. The input script of the expenditure transaction includes a sighash preimage, which includes the first token locking script and the amount of the first token. The token mechanics subcomponent extracts both the first token locking script and the amount of the first token of the output being spent from the preimage in order to perform the verification step The method according to any one of claims 1 to 4, which is configured to perform **Claim 6** The preimage includes a hash of a concatenation of one or more data pairs, each data pair including a respective payment address from each locking script of the expenditure transaction and a corresponding amount locked by the respective locking script. The token mechanics subcomponent extracts the hash of the concatenation of the one or more data pairs from the preimage generates a hash based on the one or more data pairs verifies whether the generated hash is equal to the extracted hash The method according to claim 5, which is configured to perform **Claim 7** The one or more data pairs used to generate the hash are obtained from the input script or constructed by obtaining pairs of input addresses and amounts from the preimage of the previous output locking script. The method according to claim 6 **Claim 8** The token mechanics subcomponent generates a preimage of the data of the expenditure transaction verifies whether the generated preimage of the data of the expenditure transaction is equal to the preimage included in the input of the expenditure transaction The method according to any one of claims 5 to 7, which is configured to perform **Claim 9** The input of the expenditure transaction includes a dummy private key and a corresponding dummy public key. The token mechanics subcomponent verifies whether the generated preimage of the expenditure transaction is equal to the preimage included in the input of the expenditure transaction generates a digital signature using the dummy private key and the hash of the preimage included in the input of the expenditure transaction verifies whether the digital signature is a valid signature when verified against the dummy public key and the hash of the generated preimage of the expenditure transaction The method according to claim 8, which is configured to verify by performing **Claim 10** The token mechanics sub-component verifies that each payment address included in the respective locking script of the expenditure transaction is of the same type as the first payment address included in the variable component of the first token output. The method according to any one of claims 1 to 9, which is configured to perform the above. **Claim 11** The method according to any one of claims 1 to 9, wherein the type of the first payment address is a public key hash address. **Claim 12** The method according to any one of claims 1 to 11, wherein the amount of the first token includes a single unit of the underlying digital asset. **Claim 13** The method according to any one of claims 1 to 11, wherein the amount of the first token includes a plurality of units of the underlying digital asset. **Claim 14** The constant component includes a data sub-component, and the data sub-component includes a token protocol identifier, and an identifier of a token issuance transaction, the token issuance transaction including one or both of i) an issuance contract between a token issuer and an initial token recipient and ii) an initial token amount. The method according to any one of claims 1 to 13, which includes one or both of the above. **Claim 15** The expenditure transaction includes a third output including a third locking script and a corresponding third amount, and the token mechanics sub-component verifies whether the third locking script includes each payment address of a predetermined payment type template and each corresponding amount. The method according to claim 2, which is configured to perform the above. **Claim 16** The first token transaction includes a first token input that spends each token output of a previous token transaction, and the first token input includes at least a part of the first token transaction other than the first token input of the first token transaction, the respective amounts and respective locking scripts of the previous token transactions that have been spent, and at least one or more data pairs, each data pair including at least a payment address included in each locking script of the first token transaction and a corresponding amount of the underlying digital asset locked by the respective locking script. The method according to any one of claims 1 to 15, including

17. The first token transaction includes a second token output, the second token output includes a second token locking script and an amount of the second token, the second token locking script includes respective variable components and respective constant components, the respective variable components include a second payment address, and the respective constant components match the constant components of the first token locking script. The method according to claim 16.

18. The first token transaction includes a third output, the third output includes a third payment address. The method according to claim 17.

19. The first token input includes a first signature generated by a first party, the first token transaction includes a second input, the second input includes a second signature generated by a second party, and the first token transaction includes a payment output including a payment address included in a payment template, the payment address being linked to the first party. The method according to any one of claims 16 to 18.

20. A memory including one or more memory units, A processing device including one or more processing units, the memory storing code configured to be executed on the processing device, the code being configured such that when on the processing device, the method according to any one of claims 1 to 19 is performed. A processing device, A computer device including

21. A computer program embodied on a computer-readable storage device, the computer program being configured such that when executed on a computer device, the method according to any one of claims 1 to 19 is performed. A computer program.

Images