Blockchain tokens

Abstract

To provide an improved method of sending digital tokens using blockchain transactions.SOLUTION: A token transaction comprises a first token output, and the first token output comprises a first token locking script and a first token amount. The first token locking script comprises a variable component and a constant component, where the variable component comprises a first payment address embedded in a payment template and the constant component comprises a token mechanics sub-component.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to methods for transmitting (e.g., issuing, transferring, dividing, exchanging, redeeming) tokens using blockchain transactions. [Background technology]

[0002] Blockchains enable the transfer of underlying digital assets using transactions. These digital assets are often called "cryptocurrencies" or "native tokens," which are digital assets that are unique to a particular blockchain. As an illustrative example, the digital asset on 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 an additional data field within a transaction. This additional data, called "token data," is interpreted as a token by users of the blockchain or a specific token protocol. That is, users agree that a transaction, or more specifically, the output portion of a transaction containing specific token data (e.g., a token protocol flag followed by a quantity), will be interpreted and used as a token. The owner of the output (usually the user of the address where the output is locked) owns the token. The token can then be used, sold, traded, etc. for a specific purpose according to the specific token protocol. For example, a movie theater ticket may issue a token to a user, who may pay for the token in exchange for seeing a movie at the theater, or a bank may issue a token in exchange for a customer's U.S. dollar deposit, which the bank may use for recurring payments. The customer may then use the token for regular payments, which a third party may later exchange for U.S. dollars at the bank. Summary of the Invention

[0004] As discussed above, previous attempts to create tokens using blockchains typically involved defining the token in an additional data field of a transaction by including the token data in output script code or an additional, separate, non-pausable output. These tokens are distinct from the underlying digital asset (itself comprised of its native token) of the blockchain on which the token is created. That is, transactions involving tokens according to these previous schemes used the underlying digital asset (or "native token") as normal, but also created a new token in an additional data structure. The new token was unrelated to the native token. Separating the newly created tokens from their native tokens required burdensome and unnecessary coordination to achieve, something all recent attempts have failed to achieve, ultimately preventing the tokens from reaching their intended mass adoption.

[0005] According to one aspect of the present disclosure, a computer-implemented method for transmitting digital tokens using blockchain transactions is provided. Each token is represented by a single unit of a unique unit of a blockchain-based digital asset. The method includes generating a first token transaction and transmitting the first token transaction to a blockchain network. The first 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 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, which, when executed with an input script for a spending transaction including all but the spending transaction itself plus amounts locked in previous transaction outputs being spent and their respective locking scripts, is configured to perform the following operations: A first operation includes obtaining one or more data pairs from an input script of the spending transaction, each data pair including: i) at least a respective payment address included in a respective locking script of an output of the spending transaction, and ii) a corresponding amount of the underlying digital asset locked by the respective locking script of that output. Another operation includes verifying whether one or more outputs of the spending transaction include: a) a respective payment script template including a predetermined payment address, or b) a respective locking script including a respective variable component including a respective payment address other than the predetermined payment address, followed by the constant component.Another operation includes verifying, for one or more outputs of the spending transaction, whether a total amount of the underlying digital assets locked by a respective locking script of the one or more outputs equals an amount of the first token, and the token mechanics subcomponent is configured to fail during execution if any of the verification steps fails.

[0006] Unlike previous token attempts, the newly issued tokens of the present invention are the underlying digital asset tokens themselves; that is, the native tokens themselves are converted into new types of tokens. These new tokens no longer perform their normal functions as native tokens unless they are converted into the underlying digital asset under specific conditions encoded into them at the time of their issuance.

[0007] In order for a token to be spent, assigned, or otherwise transmitted and function as a token, a successful spend transaction must have its next output have a locking script of the same form as the previous (called UTXO*) transaction output being spent. That is, like the token transaction output being spent, the spend transaction, in order to be sent successfully, must include an output with a locking script that has the same constant component of the new token output. This constant portion cannot be changed or omitted during the token's lifetime until its redemption.

[0008] This constant part is the code part of the token, and among its various behaviors, it transforms the nature of the token by: 1) self-immutability, 2) its own ineliminability, and 3) most importantly, preserving the token amount, i.e., it locks the tokens and ensures that their amount (in whole or in part) is not leaked as miner fees (if the total output amount is less than the total input amount) or spent outside of its own smart-locking script output (unless redeemed to a specific address encoded into it at issuance).

[0009] Simply put, it changes the nature of the native token by making it unusable and enforcing a new definition.

[0010] This has the effect of causing each single unit of the underlying digital asset to represent a redefined single token and ceasing its normal function. Continuing with the Bitcoin blockchain example, a single Satoshi is redefined as a single token. A token owner cannot transfer their token to another user unless the locking script contains the exact same constant components, thereby enforcing new token mechanics. The only variable components that can be changed in the locking script are those involved in the transfer of ownership, i.e., variable components that may be standard templates (e.g., used in the same manner as the underlying asset's native token) that allow the current owner to transfer some or all of their tokens to the next owner according to the address contained in such standard template.

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

[0012] As mentioned above, the tokens can be converted back into the underlying digital assets, i.e., can be used again as native tokens, only if they meet certain conditions encoded in the above constants portion of the script, e.g., by moving to a predetermined redemption address. This means that only a hardcoded user or authority (i.e., the entity that controls the redemption destination) can convert the tokens back into the proper underlying digital asset properties and restore their original functionality. [Brief explanation of the drawings]

[0013] To assist in understanding embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 illustrates an example token transaction in schematic form. [Figure 2] FIG. 2 illustrates an example token locking script in schematic form. [Figure 3] Figures 3A and 3B show a schematic diagram of the difference between a regular token transaction and an atomic swap token transaction. [Figure 4] FIG. 4 illustrates an example flow of a token from issuance to redemption. DETAILED DESCRIPTION OF THE INVENTION

[0014] Embodiments of the present invention involve the creation and transfer of blockchain transactions. Those skilled in the art will be familiar with blockchain technology itself, but before describing the embodiments themselves in detail, a brief overview of blockchain will first be provided.

[0015] A blockchain is a form of distributed database (or ledger) that acts as a record of every valid transaction that has ever been transferred to a blockchain network.

[0016] Valid transactions broadcast on a blockchain network are recorded in blocks by miners (also called mining nodes) on the blockchain. Blockchain transactions are used to transfer control, i.e., ownership, of the value of a digital asset. An exemplary blockchain is the Bitcoin blockchain, and the digital asset is called Bitcoin. Many different blockchains exist, and the present invention is not limited to any particular 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. A transaction uses the unspent transaction output (UTXO) as an input and distributes its value to a new output. The output typically includes a locking condition that locks the value of the output; to unlock it, specific data (e.g., a series of signatures or other information) must be provided as an input to the new, upcoming transaction. The output can also be used to write data (e.g., text, images, etc.) to the ledger. The input of a transaction typically includes a digital signature that signs at least a portion of the transaction. Thus, a series of transactions includes a series of digital signatures that map the entire history of valid exchanges of digital assets leading up to their creation.

[0017] A blockchain begins with a "genesis block," the first block ever created. Each block in the blockchain references the previous block, going back to the genesis block. That is, the nth block references the n-1th block, the n-1th block references the n-2th block, and so on, all the way back to the genesis block.

[0018] A block contains an ordered list of blockchain transactions and a block header. The block header contains a Merkle root (generated by hashing the ordered list of blockchain transactions into a Merkle tree), a timestamp, a reference to the previous block on which the current block is built, and a means of verifying the "proof of work" required for other miners to accept the block as valid. The means of verification is the answer to a hash puzzle unique to each block. The blockchain protocol, run by mining nodes in a blockchain network, uses a hashing 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 process of "mining" is essentially a race to find an answer that "solves" the current block to become the next block. While solving each block's hash puzzle is difficult, once a valid solution is found, it is very easy to verify that the solution is correct with the rest of the network. 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] Below is a brief description of the process that attempts to mine a new block into the blockchain. When a blockchain transaction is sent to a mining node, it is first verified according to the blockchain network's consensus rules. If the transaction is valid, it is added to a pool of unconfirmed transactions. This pool is sometimes called a "mempool." The mempool acts as a temporary storage location for transactions that will 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 may be included in more than one mempool.

[0020] Miners take the transactions intended for inclusion in the next block, hash them into a Merkle tree structure, and include the resulting Merkle root in a candidate block header. Miners then hash this candidate block header in an attempt to find a valid proof-of-work. A Merkle tree is a tree-like data structure of hash values. In the context of blockchain, transactions are hashed to form leaf nodes of the tree. Pairs of leaf nodes are concatenated and then hashed to form nodes in higher layers of the tree. Pairs of nodes within that layer are concatenated and hashed to form nodes even higher in 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 (effectively 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 produced 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 hashing algorithm, and some protocols use the SHA-256 hashing algorithm twice, meaning that candidate block headers are passed through the same hashing algorithm twice.

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

[0023] To change the hash value, a mining node must add additional information to the candidate block header. Typically, a mining node uses two "nonce fields" to change the value to hash and 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 revisits all permutations of the first nonce field. Incrementing the second nonce field involves recalculating the Merkle root as it changes the hash of the coinbase transaction included in the Merkle tree.

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

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

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

[0027] [Table 1]

[0028] A transaction has one or more inputs, each of which references the output of a previous transaction. Each input may reference a different output of the same previous transaction, or 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 it contains the correct data. The unlocked output of the previous transaction, or the amount of digital assets previously locked to that output, is spent (i.e., allocated) by the output of the current transaction. The unlocked amount of digital assets may be spent in its entirety by one output or may be spread across two or more outputs of the current transaction.

[0029] A transaction also has one or more outputs, which share the total value of the digital assets unlocked by the inputs. Typically, the sum of the output values ​​is less than the sum of the input values, and the difference is paid as a fee to the mining node that records the transaction in a new block. Outputs can be either spendable or unspendable. Spendable outputs include a locking script (sometimes called a "ScriptPubKey") that defines one or more conditions that must be met before they can be unlocked by inputs in a later transaction. Unspendable outputs do not include an unlockable locking script; that is, unspendable outputs include a locking script that causes the locking script to fail to execute.

[0030] Embodiments of the present invention allow a first party (we'll call her "Alice") to send one or more tokens to a second party (we'll call him "Bob"). At least some of the following descriptions will refer to the first party, Alice, sending the tokens to the second party, Bob. However, this is for illustrative purposes only. These embodiments also apply when the second party, Bob, sends the tokens to a third party, e.g., a merchant. In addition, reference will be made to the token issuer, i.e., the party that originally issued the token, e.g., to Alice. Also, at least some of the following descriptions will refer to a "first token transaction." Unless the context requires otherwise, the first token transaction may be initiated by either Alice, Bob, or the token issuer.

[0031] Figure 4 shows an example system including several parties, e.g., a token issuer, Alice, Bob, and a merchant. The term "party" may be used to mean a user (e.g., Alice), but a party may take other forms, e.g., a collection of users, such as a business or other type of organization. It also does not exclude that a party may be an autonomous entity, i.e., an entity that takes a predetermined action based on one or more conditions. Such autonomous entities are sometimes referred to in the art as "agents."

[0032] Although not shown, each party operates a respective computing device. Each party's computing device includes a respective processing device, including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each party's computing device further includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. This memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as optical disk drives. The memory on each party's computing device stores software, including a respective instance of at least one client application, configured to run on the processing device. It will be understood that any actions attributed to a particular party herein may be performed using software running on the processing device of the respective computing device. Each party's computing device includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable terminal such as a smartwatch. A particular party's computing device 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 to any party's computing device on a suitable computer readable medium, for example downloaded from a server or on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD-ROM or removable optical drive.

[0034] A token issuer is a party that issues tokens to an initial recipient, e.g., Alice. Tokens may be issued to Alice using a first token transaction generated by the token issuer, or Alice may generate the first token transaction herself. For example, the token issuer and Alice may agree on the number of tokens to be issued to Alice (and other applicable terms and conditions), and then Alice may transfer one or more tokens to another party, e.g., Bob, effectively issuing tokens to herself.

[0035] Alice (or a token issuer) generates a 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 for recording the token transaction in a block. Because a transaction fee is not always required, such a fee payment is not required. Like all blockchain transactions, a token transaction includes an input to unlock the output of a previous transaction. For a first token transaction, the referenced output of the previous transaction must contain at least the amount of the underlying asset to be reconstituted as a token. As shown in FIG. 4, the amount of the first token is 1000, so the referenced output must have a value of at least 1000 units of the underlying asset. This number is chosen arbitrarily, and any number can generally be used as the amount of the first token. For simplicity, the unit of the underlying asset is referred to as a Satoshi. This is a specific unit of the Bitcoin blockchain, but this is not intended to limit all embodiments.

[0036] The first token transaction includes a first token output. The first token output locks a first token amount (1000 Satoshi). That is, the first token output includes a first token locking script that locks the first Satoshi amount to a newly defined token amount of the same. The first token locking script includes a variable component and a constant component. In other words, the variable component is one partition (i.e., portion) of the first token locking script, and the constant component is another partition (i.e., portion) of the first token locking script. As the names suggest, the variable component can change between token transactions, while the constant component remains the same.

[0037] The mutable component is part of the token locking script that allows a token to be transferred to another party. The mutable component includes a payment template that includes (e.g., surrounds) a payment address. The payment address may be based on the receiving party's public key. For example, the payment address may be a public key hash (PKH) address, i.e., a 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 may select another address linked to herself or an address linked to another party, such as Bob or a merchant. The payment address may be treated as a subcomponent of the mutable component. The mutable component may include one or more additional constant subcomponents. For example, the mutable component may include one or more constant opcodes for creating a pay-to-public-key-hash (P2PKH) formatted output.

[0038] The quorum component includes a token mechanics subcomponent (hereinafter referred to as the "token subcomponent"), which is a quorum subcomponent of the quorum component. The token subcomponent is a portion of the first token locking script that reuses the underlying digital asset as a token. For example, 1000 Satoshis into 1000 tokens. The token subcomponent is configured to obtain data from the spending transaction input and perform at least two validation steps. Furthermore, the token subcomponent is configured to fail execution of the token locking script if the validation fails. That is, if any validation step fails, the execution of the token locking script fails along with the unlocking script from the spending transaction input.

[0039] To be valid, the token subcomponent requires that the spend transaction input (specifically, the input's unlocking script) contain certain data. The spend transaction input is also referred to as the spend input. In particular, the spend input's unlocking script must contain at least a portion of the spend transaction, i.e., the unlocking script itself, as well as the spend transaction data (some parts intact and only the hashed result of other parts). Hereafter, this data is referred to as the hash preimage (because its hash serves as input to the ECDSA verification formula), or simply the preimage. The preimage includes the spend transaction and spent fields, as well as data items generated (hashed) based on these transaction fields. In other embodiments, all data fields of the spend transaction are literally included in the spend input's unlocking script.

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

[0041] The required data may be obtained by parsing the payment entry unlocking script and extracting the data pairs, which may require including the data pairs in the unlocking script at predetermined locations, as further detailed below.

[0042] Upon obtaining one or more data pairs, the token subcomponent is configured to verify that the output of the spend transaction is in a specific format. At least one output of the spend 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 subcomponent may determine and verify that two or more outputs of the spend transaction include any payment address embedded in a predetermined standard payment template followed by a constant component of the token output. The spend transaction may verify that the spend transaction 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 subcomponent is also configured to verify that the sum of the value locked by the output of a spending transaction that together includes either the given payment address or any payment address and a subsequent constant component is equal to (i.e., the same as) the amount of the first token. The output of a spending transaction that includes either the given payment address or the constant component may be referred to as a smart token output. The token subcomponent verifies that the sum of the tokens locked by the smart token output is equal to the amount of the first token, thereby preventing their reversion to their origin or other forms of use.

[0044] For example, consider the case where a spend transaction includes a single smart token output (the first output of the spend transaction). The token subcomponent is configured to verify that the first output of the spend transaction has a first locking script that takes a specific format or contains specific 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 a constant portion of the token locking script. Only one of the two is required; if both are missing, the verification fails. This verification process is possible because the token subcomponent obtains the first locking script of the spend transaction from the unlocking script of the spend input. Thus, the token subcomponent can search for the first locking script for the predetermined payment address or constant component.

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

[0046] In an example where a spend transaction includes one smart token output, the token subcomponent is configured to verify that a first amount of the underlying digital asset locked by a first locking script of the spend transaction is equal to a first token amount (i.e., 1000 Satoshis), where the first output with the first locking script is the output that logically appears first in the spend transaction.

[0047] If the spending 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 subcomponent is configured to verify that the sum of the first amount and the second amount equals the first token amount, where the second output is the output that logically appears second in the spending transaction. Generally, if the spending transaction includes multiple outputs that include either a predetermined payment address or a constant component, the token subcomponent verifies that the sum of the respective amounts equals the initial token amount.

[0048] This process may be repeated for any number of outputs of the spend transaction. A spend transaction may be permitted to include outputs locking amounts of digital assets that may result in a total digital asset amount greater than the amount of the first token locked by all of the spend transaction's outputs. In this case, the token subcomponent is configured to verify that a predetermined number of smart token outputs of the spend transaction, taken together, lock an amount of digital assets equal to the amount of the first token, without taking into account amounts locked by non-smart token outputs. The non-smart token output may be a fee change output or an atomic swap output. For example, the total amount locked by the first two outputs of a token transaction must equal the amount of the first token, while a third output (e.g., a fee change output) may lock an additional amount funded by additional inputs. Note that the third output is used for illustrative purposes. Fee change outputs are further described below. For now, suffice it to say that a fee change output (or another type of "additional output") is permitted only if it is not a token output, i.e., does not include a constant component of the token locking script.

[0049] The quorum component of the token locking script may include a predetermined payment address. That is, the predetermined payment address may be hard-coded into the quorum component and therefore must be included in the first locking script for a spending transaction. The predetermined payment address may be a redemption address, an address where some or all of the tokens are transferred to be redeemed for something other than tokens, such as a FIAT currency token.

[0050] As mentioned above, the unlocking script for a spend entry of a spend transaction may include a raw image, which may include one, some, or all of the fields in the table below.

[0051] [Table 2]

[0052] It should be noted that the particular 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 particular blockchain being used to implement the invention.

[0053] In these examples, the token subcomponent may be configured to obtain the token locking script (i.e., the input's scriptCode) and initial token amount (i.e., the value of the output spent by the input) of the first token transaction by extracting them from the preimage. Because the sizes of all data fields in the preimage except for the scriptCode are known, the token subcomponent can extract the required fields by parsing and extracting the data in predetermined positions.

[0054] As shown in Table 2, the pre-image may contain hashes of the outputs of the spend transaction (hashOutputs). This is a hash of each output: the value locked by the locking script and the locking script itself. So, if the spend transaction contains one output, hashOutputs contains the hash of one value concatenated with one locking script. If the spend transaction contains two outputs, each value-locking script pair is concatenated and hashed to form hashOutputs. The token subcomponent may extract hashOutputs from the pre-image, for example, by parsing and extracting data at specific locations.

[0055] The unlocking script for a 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 may be configured to generate its own version of hashOutputs, i.e., generate a 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 may be done to verify that a spending user, e.g., Alice or Bob, included the correct data pairs in the unlocking script for a spending transaction.

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

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

[0058] In general, the token subcomponent may be configured to generate a digital signature (e.g., an ECDSA signature) using a pre-image from an unlocking script and a private key. The private key is included in the unlocking script for the spending transaction. The token subcomponent then verifies that the digital signature is a valid signature when verified against the public key corresponding to the generated pre-image (i.e., the pre-image generated by the token subcomponent) and the private key. The public key is also included in the unlocking script for the spending transaction. The digital signature is only valid if the two pre-images match exactly. The private key used is made public by being recorded on the blockchain and therefore is a "dummy" The signature check should be performed using a private key, i.e., one that, if revealed, would not compromise the security of other data or blockchain transactions. In general, however, any private key can be used, e.g., any random key. This signature check can be performed by utilizing the OP_CHECKSIG opcode to verify the signature. OP_CHECKSIG is an opcode that will only succeed (i.e., execute successfully) if the signature is for the current transaction, which in this case is the spend transaction.

[0059] Returning to the output of spend transactions, the token subcomponent may be configured to verify that the output of spend transactions (specifically their respective locking scripts) includes respective payment addresses of a predetermined type or format. Preferably, each payment address must be of the same type as the payment addresses included in the variable component of the token transaction. More preferably, the payment addresses must be PKH addresses. This may be verified based solely on the payment address itself, or based on the payment address and one or more additional data items, such as one or more opcodes or other data on either side of the payment address. For example, P2PKH outputs include certain additional data that may be checked at the output.

[0060] The token subcomponent of the constant component has been described. The constant component may include a constant data subcomponent (hereinafter referred to as the "data subcomponent" for short). In general, the data subcomponent may include any data to be stored in each token output. For example, the data subcomponent may include a token protocol identifier, e.g., a flag indicating that the token is of a particular protocol, e.g., that the token represents a FIAT currency. Additionally or alternatively, the data subcomponent may include a transaction identifier (TxID) of the transaction (referred to as a "token issuance transaction") to be recorded on the blockchain. Similarly, the token issuance transaction may generally include any data, such as a token issuance agreement and / or initial token amount issued by the token issuer. The data subcomponent may be included after an OP_RETURN opcode or code performing an equivalent function.

[0061] The above description primarily relates to initial token transactions and spending transactions. The following describes in detail spending transactions, which are themselves token transactions. The spending transaction will be referred to as the "first token transaction" so that the term "spending transaction" can be reserved for later transactions that refer to the output of the first token transaction.

[0062] A 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 inputs 104 themselves do not include the input value 108. Rather, the inputs 104 include pointers (e.g., TXID and VOUT) to the unspent transaction outputs (UTXOs) of the previous output that locked the values ​​108, referred to as input values ​​108. However, for purposes of illustration, the values ​​108 unlocked by the respective unlocking scripts 110 are shown. Each output 106 includes an output value 112 and a locking script 114.

[0063] The output 106 of the first token transaction 100 will be described first, as it has already been described above with reference to a spending transaction. The token transaction 100 includes a first token output ("redeem / token output"). The first token output is shown in Figure 2. As shown in Figure 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 subcomponent 206 and, in this example, a constant data subcomponent 208.

[0064] The variable component 202 includes payment addresses for each of the parties to which a first token amount (e.g., 700 tokens) has been assigned. The token subcomponent 206 is configured to perform some or all of the validation steps described above. For example, the token subcomponent 206 is configured to verify that the total amount of digital assets to be locked by a predetermined number of output transactions (e.g., one or two) of spending transactions equals the first token amount (700 tokens). The token subcomponent 206 of the first token output 200 is also configured to verify that the input of a subsequent spending transaction attempting to unlock the first token output 200 includes either a regular payment template including a redemption payment address or the entire format of the first token output 200 including the variable component 202 and the constant component 204. In general, the token subcomponent 206 may be configured to perform any of the validation techniques described above.

[0065] The first token transaction 100 may also include a second token output. The second token output may also include a respective variable component and a respective constant component. 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 subcomponent of the second token output is configured to perform the same verification steps as the token subcomponent 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 may have two or more outputs, each of which may be used (unlocked) by a different spending transaction. For example, the token subcomponent of the second token output may be configured to verify that the total amount of digital assets locked by the outputs of a predetermined number (e.g., one or two) of spending transactions is equal to the second token amount (300).

[0066] The first token transaction 100 may include any number of token outputs to attempt to spend, as long as the sum of the respective token amounts exactly equals the amount (1000 tokens) locked in the first token output (referenced by the TXID field of the transaction's input).

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

[0068] Additionally or alternatively, the first token trade 100 may include an atomic swap output, which is described below.

[0069] In the example of FIG. 1 , the first token transaction 100 includes a token input. A token input is equivalent to a spend input, as detailed above. More specifically, a token input references a token output of a previous token transaction, e.g., an initial token transaction. In this example, the referenced token output locks 1000 tokens. The token input includes everything else in the first token transaction 200, including a respective data pair for each output 106 of the first token transaction 200. 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 (“Redeem / Token Output,” “Token Output (Split),” and “Fee Change / Atomic Swap”)). The values ​​112 and payment addresses may be paired such that the amount of the first token (700) is followed by the payment address from the first token output locking script, 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 to unlock the referenced token output, i.e., a signature corresponding to the payment address included in the mutable component of the referenced token output. When Alice transfers the token, her signature is included in the input for the spending transaction. In some cases, instead of just a 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 references the output of a separate, previous, regular, non-token transaction output and includes a fee paid to the mining node for including the first token transaction 100 in a block. The fee payment input includes at least one digital signature, depending on 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 of 1,000 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 the additional task of making a payment (for the token). In this example, Bob funds the transaction by including his signature in the fee / "token buy" input, and the "fee modify" / "atomic swap" output is locked to Bob, i.e., it contains a payment address linked to Bob, e.g., a hash of a public key owned by Bob.

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

[0072] Figures 3A and 3B illustrate the concept of atomic swaps in more detail. Solid arrows indicate required inputs and outputs, while dashed arrows indicate optional inputs and outputs. Inputs to the transaction are shown on the left side of the diagram, and transaction outputs are shown on the right. Figure 3A schematically illustrates a transaction similar to Figure 1. This example token transaction includes a fee payment input to fund the transaction fee (the fee taken by the mining node to record the transaction in a block), along with a token input generated by Alice that unlocks the token output of the previous token transaction. The token transaction also includes a fee change output to pay Alice the change locked in her address in the usual payment format (the change specified in the output to be the difference between the fee input payment and the transaction fee), along with a token output sent to Bob locked in Bob's address contained in token format, such as 200.

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

[0074] Figure 4 shows an example flow of tokens from issuance to redemption. The flow generally runs from top to bottom. As an optional first step, a legal contract is created between the token issuer and the initial recipient, Alice. The contract may specify the terms of the tokens, including how they are redeemed, and the initial token amount (e.g., 1,000). The token issuer may then 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 them to another user, such as Bob, or to herself. In Figure 4, Alice sends all of her tokens to Bob. That is, all of the tokens are allocated to one token output that is sent to Bob's payment address. Next, Bob creates a token transaction with two token outputs. The first token output sends 300 tokens to a merchant's payment address. The second token output sends 700 tokens to Bob's payment address, which may be another of Bob's payment addresses. The merchant then redeems the 300 tokens by sending them 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 200 tokens. Note that in each transaction, the amount of tokens received matches the amount of tokens sent.

[0075] Having generally described embodiments of the present invention above, a specific implementation of the present invention will now be described. This particular example will be described primarily in terms of tokens representing fiat currencies; i.e., the tokens are fiat-pegged tokens. However, this is only one of many use cases for the present invention. Furthermore, this example is intended to be implemented using the Bitcoin blockchain. However, in general, any output-based (e.g., UTXO-based) blockchain may be used, of which the Bitcoin blockchain is one specific example.

[0076] According to this example, the tokens are represented using Bitcoin, and more specifically, Bitcoin's base unit called a Satoshi or Satoshi unit. The token output may include a single Satoshi representing a single token (e.g., a utility token for an event, a movie ticket, a bus ticket, etc.) that is indivisible and cannot be divided during its lifecycle. Alternatively, the token output may include multiple Satoshis representing an envelope of multiple tokens (e.g., a token pegged to the US dollar where each token represents 1 US cent).

[0077] The token output contains a variable part and a constant part. The variable part is the same as a regular Bitcoin payment template that transfers ownership of Bitcoins (i.e., Satoshis) through the use of ECDSA. The constant part cannot be changed or omitted throughout the lifetime of the token.

[0078] Regardless of the fact that each Satoshi can represent something cheaper or more expensive than itself, each Satoshi represents a token and ceases to function normally. Alice cannot transfer the token to Bob unless she keeps this exact template as the locking script for 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 at tokens that use metadata to interpret the output as a token output. This invention fundamentally changes the mechanism of Satoshis for normal use as Bitcoin.

[0080] The variable part is intentionally at the very beginning of the token locking script, and is usually just a payment template, e.g., a P2PKH template. This provides maximum compatibility with existing blockchain client applications and browsers, and allows for the use of the template (wrapped in a template). Payment addresses can be searched and identified using current methods.

[0081] The token mechanics enforce at least three conditions. First, spending a token is only possible if the next UTXO has the exact same locking script as the spent UTXO, except for the new ownership address. Second, spending by a transaction with a regular Bitcoin locking script template (e.g., P2PKH, P2PK, etc.) will fail unless the transaction is a P2PKH with a predefined redemption address. The predefined redemption address is included in the contract issued to Alice and hard-coded into the token locking script. If the token issuer sets the redemption address to an address linked to itself, this means that only the issuer can revert the Satoshis representing the asset to be used as normal Satoshis by releasing the asset represented, e.g., USD, gold, etc. This makes the token permissionless. Third, when moving tokens, the amount of satoshis in the token output of the current unspent token output (UTXO) must be exactly the same as the amount of satoshis in the token output of the spending transaction (e.g., redemption or next token transaction) or split into two or more sets of tokens (whose total amount must equal the original amount of the UTXO). For example, tokens can be split into two outputs of a spending transaction, and the locking scripts of the two outputs are identical (except for the address of the variable part) to the locking script of the UTXO being used.

[0082] The state carried by these stateful transactions is the owning address, which is updated with every hop, and (in the case of token envelopes only) the token amount, which can be reduced by splitting.

[0083] The constant data part has two fields. One field contains the token protocol identifier, e.g., the token protocol flag for fiat-pegged tokens. The identifier is used to specify the type of token. The second field is a pointer to a specific transaction (TxID) that carries a) the initial issuance agreement (e.g., between the issuer and the client) along with all legal terms, conditions, licenses, and any other necessary information related to the token's attributes and issuance, and b) the predetermined exact balance of Satoshis to be converted into tokens in a subsequent transaction (becoming an issuance transaction). The constant data field is placed after the OP_RETURN opcode as a simple data appendage to avoid any attempt to execute it as part of the script code during script evaluation. That is, the constant data is preferably included at the end of the locking script, immediately following the OP_RETURN opcode, for maximum compatibility with apps and browsers that look up OP_RETURN transactions.

[0084] Regarding the transaction structure itself, the output of a token transaction can be one of three types: i) a regular output for redemption, ii) a token output, or iii) a regular output used for fee modifications, atomic swaps, etc.

[0085] As an example, Alice may request that a legally authorized entity 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 (1,000 in this case). The contract's terms, conditions, and licenses describe the action Alice requires (e.g., sending the corresponding amount of fiat currency to the entity) and are signed by the entity with an ALL|ANYONECANPAY flag or other flags to allow Alice to add her signature. Once 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 Alice's behalf to her payment address. Alice can spend / spend / send the tokens all at once or in parts. Subsequent holders can redeem the tokens at their discretion, making them approval-free.

[0086] Returning to the constant part of the token output, it roughly contains two parts: the first part implements OP_PUSH_TX and is responsible for accessing the fields of the current transaction within the script execution, and the second part is the token logic.

[0087] The sighash preimage was explained above. OP_PUSH_TX performs an ECDSA signature of the preimage corresponding to the current transaction, i.e., a spending transaction that unlocks the token output pushed into the unlocking script for access within the executed script. OP_PUSH_TX ultimately calls OP_CHECKSIG to verify the signature. This internal ECDSA signature is done using any publicly accessible private key pair (one ephemeral pair, one constant pair), so it should be independent of the one used for the token-owning relay. OP_CHECKSIG also acts as a validator in this case, as when called, it constructs its own preimage for ECDSA verification from the actual previous and current transaction fields. It therefore fails or succeeds depending on whether the actual fields are identical (or not) to those pushed into the unlocking script.

[0088] The token logic converts Bitcoin Satoshis into tokens. To do this, the code needs access to the value (amount) of Satoshis in previous transactions (i.e., unspent outputs containing tokens) and the value of Satoshis in the current transaction (i.e., the spend transaction) to control 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 the pre-image pushed into the current (spend) transaction's unlocking script is verified to be the same as the actual current transaction's pre-image, it is parsed to extract all of the relevant fields, including the scriptCode and value of the outputs spent by this input, as well as hashOutputs. While the value (i.e., amount) and locking script of the previous UTXO (i.e., what was spent) are provided intact in the pre-image, only the hash result of the newly created output's locking script (combined with these new values) is available. Therefore, these new output's locking scripts and their corresponding values ​​should be placed next to the pre-image in the spend transaction's unlocking script, which is then verified against the hashOutputs field of the pre-image previously proven to be identical to the one OP_CHECKSIG would construct if invoked.

[0090] Once all locking scripts for the previous and next outputs of a transaction and all of their values ​​(ie amounts) are accessible by the executing code, token rules can be enforced.

[0091] The following example 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 allowed: 1. Redemption function: Used to define a hard-coded address that can redeem the token's properties back to its Satoshi proper, i.e., the underlying digital asset. 2. Dividing the token amount into at most two possible outputs. 3. A third optional output having a P2PKH format for receiving change from miner fee payments with additional inputs or 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) Redemption: A standard P2PKH template with the required hard-coded redemption address, or b) Token Relay: Smart Token Locking script identical to previous output format It is used only for this purpose. 2. The second output is optional for the tokenization case and therefore is of type Smart Token only. In addition, a) If present, the sum of the amount of that output and the amount of the first output must equal the amount in the UTXO being spent. b) Otherwise, the amount of the first output must equal the amount in the UTXO being spent. 3. The third output is a standard P2PKH template only (address optional), which, if present, is used for modifying the token operation payment (i.e., done with additional inputs).

[0093] Note that the P2PKH template is a transaction output script, and when VarInt (which specifies the length of the next script) 0x19 is pushed into the preceding unlocking script, its 25-byte length results in a hexadecimal representation of "0x76a914+PKH+0x88ac", where PKH is the public key hash address.

[0094] Example pseudocode for enforcing these rules is provided.

[0095] [Table 3] JPEG2025129155000005.jpg220157JPEG2025129155000006.jpg102157

[0096] The code below shows a working example implementation in the Bitcoin scripting language. In this implementation, the unlocking script parameters were used in the same order (left to right) as in the pseudocode function definition above. This means that the leftmost was pushed onto the stack first. The hardcoded redemption function address was placed to be the first field in the "constant code" portion of the locking script, and therefore pushed onto the stack immediately after the unlocking script data (not considering the variable portion that performs ECDSA signature verification).

[0097] Note that this script implementation is optimized for space rather than time (as current fee payments in Bitcoin depend only on TX size).

[0098] [Table 4] JPEG2025129155000008.jpg223157JPEG2025129155000009.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, there is provided a computer-implemented method for transmitting digital tokens using blockchain transactions, each token represented by a single unit of a unique denomination of a blockchain underlying digital asset, the method including: generating a first token transaction; and transmitting 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 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, the constant component including a token mechanics subcomponent; and an input script for a spending transaction, the input script including amounts and respective locking scripts locked in previous transaction outputs being spent in addition to all but the spending transaction itself. when executed together, the token mechanics subcomponent is configured to: obtain one or more data pairs from an input script of the spending transaction, each data pair including i) at least a respective payment address included in a respective locking script of an output of the spending transaction, and ii) a corresponding amount of the underlying digital asset locked by the respective locking script of the output; verify that one or more outputs of the spending transaction include a) a respective payment script template including a predetermined payment address or b) a respective locking script including a respective variable component including a respective payment address other than the predetermined payment address followed by the constant component; and verify that, for one or more outputs of the spending transaction, a 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; wherein the token mechanics subcomponent is configured to fail during execution if any of the verification steps fails.

[0101] A spend transaction includes at least one output with a first locking script format. A spend transaction may include two or more outputs, such as a second and a third output, each with a different locking script format. For a transaction to be successful, all locking scripts of the new outputs of these spend transactions must have the same smart token format as the output of the previous transaction being spent or a standard payment template with a predetermined redemption address. The only exception is any output (e.g., the last output), whose locking script must be a standard payment template with an optional address used, for example, for receiving changes from miner fee payments or atomic swap payments, if necessary. The input of a spend transaction should include a data pair for each output and a hash preimage of the entire transaction, and the hash result serves as the input for the ECDSA validation formula. The token mechanics subcomponent is configured to operate based on this assumption. If the assumption is not met, the token mechanics subcomponent's execution will fail, making any token manipulation impossible.

[0102] This also applies if the spending transaction has any additional miner fee-modifying outputs that do not include the constant component of the first token locking script of the output being attempted to be spent: the Native Tokens locked in such any outputs are not part of the newly defined token reserve from one transaction to another.

[0103] Some of the spending transactions are included in the input script in their raw form, while other parts are included as the result of their hashing.

[0104] Each payment address can be embedded in a payment template.

[0105] In embodiments, 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 is configured to: verify whether the first output of the spending transaction includes a) a respective payment script template including a predetermined payment address or b) a first locking script including a respective variable component including a respective payment address other than the predetermined payment address, followed by the constant component; if present, verify whether the second output of the spending transaction includes a) a respective standard payment script template including a predetermined payment address or b) a second locking script including a respective variable component including any address other than the predetermined payment address, followed by the constant component; and if the second output is present, verify 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 embodiments, the token mechanics component may be configured to: if the first locking script of the spend transaction does not include the standard payment script template including a predetermined payment address, verify that the first locking script includes a respective variable component including a payment address other than the predetermined payment address and a subsequent constant component that is identical to a corresponding constant component of the first token locking script of a previous transaction being spent; and / or if the second locking script of the spend transaction exists, verify that the second locking script includes a respective variable component including any payment address and a subsequent constant component that is identical to a corresponding constant component of the first token locking script of a previous transaction being spent.

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

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

[0109] In embodiments, the input script of the spend transaction may include a sighash preimage, the preimage including the first token locking script and the amount of the first token, and the token mechanics subcomponent is configured to extract from the preimage both the first token locking script and the amount of the first token of the output being spent to perform the verifying step.

[0110] The first token locking script included in the input of the spend transaction is the locking script of the output being attempted to be spent, and is the same as the one currently running. The amount of the first token included in the input of the spend transaction is the value held in the output being attempted to be spent.

[0111] In embodiments, the pre-image may include a hash of the concatenation of one or more data pairs, each data pair including a respective payment address from a respective locking script of the spending transaction and a corresponding amount locked by the respective locking script, and the token mechanics subcomponent is configured to extract the hash of the concatenation of the one or more data pairs from the pre-image, generate a hash based on the one or more data pairs, and verify that the generated hash is equal to the extracted hash.

[0112] Depending on the form of the output of the spending transaction, one or more of the one or more "corresponding amounts" may be native tokens, e.g., outputs for any change or "atomic swap" payment receipts, and one or more of the corresponding amounts may be redefined tokens, e.g., for redemptions or token outputs.

[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 the previous output locking script's input address and amount pair from the preimage.

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

[0115] In embodiments, the token mechanics subcomponent may be configured to generate a pre-image of the spend transaction data and verify that the generated pre-image of the spend transaction data is equal to the pre-image included in the input of the spend transaction.

[0116] In embodiments, the input for the spending transaction may include a dummy private key and a corresponding dummy public key, and the token mechanics subcomponent is configured to verify that the generated preimage of the spending transaction is equal to the preimage included in the input for the spending transaction by generating a digital signature using the dummy private key and a hash of the preimage included in the input for the spending transaction, and verifying that 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 the particular signing algorithm to generate an ECDSA signature, a temporary dummy private key may be required.

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

[0119] In embodiments, the token mechanics subcomponent may be configured to verify that the respective payment address included in the locking script of each of the spend transactions is of the same type as the first payment address included in the variable component of the first token output.

[0120] Additionally, the token mechanics subcomponent may be configured to verify that each output of the spend transaction includes a respective payment script template of the same type as the payment script template included in the first token output, e.g., a P2PKH locking script.

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

[0122] In embodiments, the amount of the first token may comprise a single unit of the underlying digital asset.

[0123] In embodiments, the amount of the first token may include multiple units of the underlying digital asset.

[0124] In embodiments, the constant component includes a data subcomponent that may include one or both of a token protocol identifier and an identifier of a token issuance transaction that includes one or both of: i) an issuance agreement between a token issuer and an initial token recipient; and ii) an initial token amount.

[0125] A constant immutable data subcomponent may be placed after the OP_RETURN opcode.

[0126] In an embodiment, the spending transaction may include a third output including a third locking script and a corresponding third amount, and the token mechanics subcomponent is configured to verify that the third locking script includes a respective payment address for a given payment type template, e.g., a PKH address for a P2PKH payment template, and the respective corresponding amount.

[0127] In embodiments, the first token transaction includes a first token input that spends a respective token output of a prior token transaction, the first token input including all but itself of the first token transaction, the respective amounts and respective locking scripts of the respective prior token transactions that were spent, and at least one or more data pairs, each data pair including at least a payment address included in the respective locking script of the first token transaction and a corresponding amount of the underlying digital asset locked by the respective locking script.

[0128] In embodiments, the first token transaction includes a second token output, the second token output including a second token locking script and a second token amount, the second token locking script including a respective variable component and a respective constant component, the respective variable components including a second payment address, and the respective constant components matching the constant component of the first token locking script.

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

[0130] In embodiments, 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 linked to the first party.

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

[0132] According to another aspect of the present disclosure, a memory including one or more memory units; There is provided a computing device including: 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, when present on the processing device, to perform the method of any of the above-described embodiments.

[0133] According to another aspect of the disclosure herein, there is provided a computer program embodied on a computer readable storage device, the computer program being configured to perform the method of any of the above-described embodiments when executed on a computing device.

[0134] According to another aspect disclosed herein, there is provided a token transaction including 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, the constant component including a token mechanics subcomponent, the token mechanics subcomponent obtaining one or more data pairs from an input script of a spend transaction, the input script including all of the rest of the spend transaction and amounts locked in previous transaction outputs being spent and respective locking scripts, each data pair being: i) a first token locking script for a respective locking script of the spend transaction output; and ii) a corresponding amount of the underlying digital asset locked by the locking script of each of its outputs; verifying whether one or more outputs of the spending transaction include a) a respective payment script template including the predetermined payment address or b) a respective locking script including a respective variable component including a respective payment address other than the predetermined payment address followed by the constant component; and verifying, for one or more outputs of the spending transaction, whether a total amount of the underlying digital asset locked by the locking script of each of the one or more outputs equals the amount of the first token; wherein the token mechanics subcomponent is configured to fail during execution if any of the verification steps fails.

[0135] According to another aspect of the present disclosure, there is provided a computer-readable storage medium having the token transactions stored thereon.

[0136] Other variations or uses of the disclosed techniques 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. 1. A computer-implemented method for transmitting digital tokens using a blockchain transaction, each token represented by one or more units of a unique unit of an underlying digital asset on the blockchain, the method comprising: generating a first token transaction; transmitting the first token transaction to a blockchain network; Including, the first 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 constant component, the constant component including a token mechanics subcomponent, the token mechanics subcomponent, when executed with an input script for a spend transaction, the input script including a plurality of fields of the spend transaction, and an input script including amounts locked in previous transaction outputs being spent and respective locking scripts; obtaining one or more data pairs from the input script of the spending transaction, each data pair including: i) at least a respective payment address included in a respective locking script of an output of the spending transaction; and ii) a corresponding amount of the underlying digital asset locked by the respective locking script of that output; verifying that one or more outputs of the spending transaction include a) a predetermined payment address or b) a respective locking script that includes the constant component; For one or more outputs of the spending transaction, verifying that the total amount of the underlying digital assets locked by a respective locking script of the one or more outputs is equal to the amount of the first token; configured to: The method, wherein the token mechanics subcomponent is configured to fail during execution if any of the validation steps fails.

2. 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: verifying whether the first output of the spending transaction includes a) a predetermined payment address or b) a first locking script that includes the constant component; If the second output exists, verifying whether the second output of the spending transaction includes a) a predetermined payment address or b) a second locking script that includes the constant component; If the second output exists, verifying 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; The method of claim 1 , configured to:

3. The token mechanics subcomponent includes: If the first locking script of the spending transaction does not include a predetermined payment address, verifying that the first locking script includes a constant component that is identical to a corresponding constant component of the first token locking script of a previous transaction being spent; and / or verifying that the second locking script for the spend transaction, if present, contains constant components that are identical to corresponding constant components of the first token locking script of the previous transaction being spent; The method of claim 2 , configured to:

4. The method of claim 1 , wherein the constant component comprises the predetermined payment address.

5. The input script of the spending transaction includes a sighash preimage, the preimage including the first token locking script and the amount of the first token, and the token mechanics subcomponent: extracting from said preimage both said first token locking script and the amount of said first tokens of said output being spent to perform said verifying step; 5. The method of claim 1, further comprising:

6. the pre-image comprises a hash of a concatenation of one or more data pairs, each data pair comprising a respective payment address from a respective locking script of the spend transaction and a corresponding amount locked by the respective locking script, and the token mechanics subcomponent comprises: extracting from the preimage a hash of the concatenation of the one or more data pairs; generating a hash based on the one or more data pairs; verifying that the generated hash is equal to the extracted hash; The method of claim 5 , configured to:

7. 7. The method of claim 6, wherein the one or more data pairs used to generate the hash are obtained from the input script or constructed by obtaining the previous output locking script's input address and amount pair from the preimage.

8. The token mechanics subcomponent includes: generating a pre-image of the spending transaction data; verifying that the generated preimage of the spending transaction data is equal to the preimage included in the spending transaction input; 8. The method of claim 5, further comprising:

9. The input for the spending transaction includes a dummy private key and a corresponding dummy public key, and the token mechanics subcomponent: whether the generated preimage of the spending transaction is equal to the preimage included in the input of the spending transaction; generating a digital signature using the dummy private key and a hash of the preimage included in the input of the spending transaction; verifying that the digital signature is a valid signature when verified against the dummy public key and a hash of the generated preimage of the spending transaction; The method of claim 8 , wherein the method is configured to verify by performing:

10. 10. The method of claim 1, wherein the amount of the first token comprises a single unit of the underlying digital asset.

11. The constant component includes a data subcomponent, the data subcomponent comprising: the token protocol identifier, and an identifier for a token issuance transaction, the token issuance transaction including one or both of: i) an issuance agreement between the token issuer and the initial token recipient; and ii) an initial token amount.

11. The method of claim 1, further comprising one or both of:

12. The spending transaction includes a third output including a third locking script and a corresponding third amount, and the token mechanics subcomponent: verifying that the third locking script includes each payment address and each corresponding amount; The method of claim 2 , configured to:

13. The first token transaction includes a first token input that spends a respective token output of a previous token transaction, the first token input comprising: a plurality of fields of the first token transaction, an amount of each of the previous token transactions spent, and a respective locking script; at least one or more data pairs, each data pair including at least a payment address included in a respective locking script of the first token transaction and a corresponding amount of the underlying digital asset locked by the respective locking script; 13. The method of any one of claims 1 to 12, comprising:

14. 14. The method of claim 13, wherein the first token transaction includes a second token output, the second token output including a second token locking script and a second token amount, the second token locking script including respective variable components and respective constant components, the respective variable components including a second payment address, and the respective constant components matching the constant components of the first token locking script.

15. 14. The method of claim 13, wherein 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 linked to the first party.

16. 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, when present on the processing device, to perform a method according to any one of claims 1 to 15; including computer equipment.

17. A computer program embodied on a computer readable storage device, the computer program being arranged to perform the method of any of claims 1 to 15 when executed on a computing device.

Images