Computer-implemented methods, devices, computer program products, and storage media for sending digital tokens using blockchain transactions

Abstract

Computer-implemented methods, devices, computer program products, and storage media for sending digital tokens using blockchain transactions. A token transaction includes a first token output including a first token locking script and a first token quantity, where the first token locking script includes a variable component and a constant component, where the variable component includes a first pay-to address embedded in a pay-to template, and where the constant component includes a token mechanism subcomponent.

Description

[0001] This application is a divisional application of Chinese application number 202180066069.2 (corresponding to PCT international application number PCT / EP2021 / 055905), filed on March 9, 2021, entitled "Computer-implemented method, apparatus, computer program product and storage medium for sending digital tokens using blockchain transactions". Technical Field

[0002] This disclosure relates to a method for sending (e.g., issuing, transferring, splitting, exchanging, redeeming) tokens using blockchain transactions. Background Technology

[0003] Blockchain allows the transfer of underlying digital assets using transactions. These digital assets, often referred to as "native tokens," are digital assets inherent to a specific blockchain.

[0004] Another type of digital asset that can be transferred using blockchain is a "token." In a blockchain technology environment, tokens are typically created and defined using additional data fields within transactions. Blockchain users, or users of a specific token protocol, interpret this additional data, called "token data," as the token. That is, users agree to interpret and use a transaction containing specific token data (e.g., a token protocol identifier followed by a quantity), or more specifically, the output portion of a transaction, as a token. Whoever owns the output (usually meaning the output is locked to a user's address) owns the token. The token can then be used, sold, and traded for a specific purpose according to the specific token protocol. For example, movie tickets can be issued to users who then pay for the tokens in exchange for watching a movie at a theater; or a bank can issue tokens in exchange for its customers' dollar deposits, which customers can use in periodic payments, and then a third party can exchange them back for dollars at the bank. Summary of the Invention

[0005] As mentioned above, previous attempts to create tokens using blockchain involved defining the token in an additional data field of a transaction, typically by including the token data in the unexecuted portion of the output script code, or even in a separate unspent output attached to the transaction. These tokens differ from the underlying digital asset of the blockchain on which the tokens are created (which itself is composed of its native token). That is, according to these previous schemes, the transaction containing the token uses the underlying digital asset (or "native token") normally, while simultaneously creating a new token in the additional data structure. This new token is unrelated to the original native token.

[0006] Separating newly created tokens from their native counterparts requires cumbersome and unnecessary coordination, and all recent attempts to achieve this coordination have failed, ultimately preventing the tokens from achieving the expected large-scale adoption.

[0007] According to one aspect provided herein, a computer-implemented method for sending digital tokens using blockchain transactions is provided. Each token is represented by a single unit of the underlying digital asset's native unit in the blockchain. The method includes: generating a first token transaction, and transmitting the first token transaction to the blockchain network. The first token transaction includes a first token output, and the first token output includes a first token locking script and a first token quantity. 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 mechanism subcomponent, which, when executed with an input script for a spending transaction, includes all of the spending transactions except itself, and corresponding locking scripts and quantities locked in previous transaction outputs being spent, the token mechanism subcomponent being configured to perform the following operation. A first operation includes: obtaining one or more data pairs from the input script of the spending transaction, each data pair including i) at least a corresponding payment address included in the corresponding locking script of the spending transaction output, and ii) a corresponding quantity of the underlying digital asset locked by the corresponding locking script of the output. Another operation includes: verifying that one or more outputs of the spending transaction include corresponding locking scripts, the locking scripts including a) a corresponding payment script template including a predetermined payment address, or b) a corresponding variable component including a corresponding payment address other than the predetermined payment address, followed by the constant component. Another operation includes: for one or more outputs of the spending transaction, verifying that the total amount of the underlying digital assets locked by the corresponding locking scripts of the one or more outputs is equal to the first token quantity. The token mechanism sub-component is configured to become invalid during execution if any of the verification steps fails.

[0008] Unlike previous token attempts, the newly issued tokens according to this invention are the underlying digital asset token itself. That is, the native token itself is transformed into a new token type. These new tokens no longer perform their usual functions as the native token unless converted back to the underlying digital asset at the time of issuance according to certain specific conditions encoded within them.

[0009] In order to spend, allocate, or otherwise transfer tokens and thus enable the tokens to function, a successful spending transaction must have in its subsequent outputs the output of the previous transaction being spent (called UTXO). A locking script with the same format. That is, in order for the token transaction output to be successfully transmitted, the spending transaction must include an output with a locking script, which has the same constant components as the new token output. These constant components cannot be changed or omitted throughout the token's lifetime, prior to redemption.

[0010] The constant portion is the code portion of the token, which, in its various operations, is used to convert the properties of the token from one transaction to another: 1) its own immutability; 2) its own impossibility of omission; and 3) most importantly, to maintain the token quantity, that is, to lock the token so that its quantity (in whole or in part) is not spent anywhere except in its own smart lock script format output (unless redeemed to a specified address, self-encoded at the time of issuance).

[0011] In short, the constant portion prevents the native token from being used properly when executing the newly defined token, thereby changing the nature of the native token.

[0012] This results in each individual unit of the underlying digital asset now representing a redefined single token, and its normal functionality being suspended. The owner of one or more tokens cannot move those tokens to another user unless the locking script contains identical constant components, which will execute the new token mechanism. The only components that can be changed in the locking script are variable components, which can be standard templates responsible for transferring ownership (e.g., used in the same way as the native tokens of the underlying asset), meaning enabling the current owner to move some or all of the one or more tokens to a subsequent owner based on addresses contained in such standard templates.

[0013] In other words, unlike previous attempts that relied on metadata attachments to represent tokens, according to this scheme, the token of the present invention is a single unit of the underlying digital asset, which has been reconfigured to be used as a different entity and operate according to different rules (self-encoded).

[0014] As described above, a token can be converted back to the underlying digital asset, i.e., reused as the native token, if and only if the token satisfies the specific conditions encoded in the script constants section above (e.g., moving to a predetermined redemption address). In other words, only hard-coded users or institutions (i.e., entities with control over the redemption address) have the ability to convert the token back to the nature of a regular underlying digital asset, thereby restoring its original functionality. Attached Figure Description

[0015] To aid in understanding embodiments of this disclosure and to show how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which: Figure 1 An exemplary token transaction is illustrated schematically; Figure 2 An exemplary token locking script is illustrated schematically; Figure 3A and Figure 3B This schematically illustrates the difference between regular token transactions and atomic swap token transactions; and Figure 4 This schematically illustrates an exemplary process from token issuance to redemption. Detailed Implementation

[0016] Embodiments of the present invention relate to the creation and transmission of blockchain transactions. While those skilled in the art will be familiar with blockchain technology itself, a brief overview of blockchain is provided first before describing the embodiments in detail.

[0017] Blockchain is a form of distributed database (or ledger) that serves as a record of all valid transactions transmitted to a blockchain network.

[0018] Valid transactions broadcast on a blockchain network are recorded on the blockchain in the form of blocks. Blockchain transactions are used to transfer custody (i.e., ownership) of a certain amount of digital assets. Many different blockchains exist, and this invention is not limited to any particular implementation. Among other things, each transaction includes at least one input and at least one output. Inputs include references to the unspent transaction outputs (UTXOs) of previous transactions. A transaction uses an unspent transaction output (UTXO) as input and assigns its value to a new output. Outputs typically include locking conditions that lock the value of the output, requiring certain data (e.g., a set of signatures or other information) to be provided in the input of a new subsequent transaction in order to unlock it. Outputs can also be used to post data (e.g., text, images, etc.) into a ledger. Transaction inputs typically include digital signatures that sign at least a portion of the transaction. Therefore, the transaction chain includes a digital signature chain that depicts the entire history of valid exchanges of digital assets, tracing back to their creation.

[0019] A blockchain begins with the "genesis block," which is the first block ever created. Every block on the blockchain references previous blocks, tracing back to the genesis block. That is, the nth block references the (n-1)th block, the (n-1)th block references the (n-2)th block, and so on, until the genesis block.

[0020] 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 previous blocks built upon which the current block is constructed, and a means of verifying the "proof-of-work" required to accept the block as valid. This verification means is the answer to a hash puzzle unique to each block. The hash puzzle in each block is difficult to solve, but once a valid solution is found, the rest of the network can easily verify that the solution is correct. Any given block has multiple valid solutions, and for a block requiring a solution, only one of these solutions needs to be found.

[0021] A Merkle tree is a data structure in the form of a hash tree. In a blockchain environment, transactions are hashed to form leaf nodes of the tree. Pairs of leaf nodes are concatenated and hashed to form nodes at higher levels of the tree. This process is repeated until only one node remains, called the root node or Merkle root.

[0022] A hash function is a function that transforms a data string of arbitrary length into a fixed-length unique (in fact, with a zero probability of collision) value called a hash value or hash digest. Hash is a one-way function, meaning it's infeasible to determine the input data by looking at the hash value produced by the input data. On the other hand, it's very straightforward to run the same input data through the same hash function and regenerate the same hash. Some blockchain protocols use the SHA-256 hash algorithm, while others use the SHA-256 hash algorithm twice, meaning that candidate block headers are passed twice using the same hash algorithm.

[0023] The candidate block header (combined with other data, as described below) is hashed until the result is less than another value (called the target value), thus finding a valid proof-of-work. The target value is automatically adjusted by the blockchain protocol; therefore, it takes an average of 10 minutes for the blockchain network to find a valid proof-of-work.

[0024] To change the hash value, additional information must be added to the candidate block header. Typically, two "random number segments" are used to change the values ​​to be hashed, thus altering the generated hash value. The first random number segment is contained within the block header itself, and the second random number segment is contained within the "Coinbase transaction." A Coinbase transaction is a transaction created and included in the candidate block. Each field includes a counter parameter that can be incremented. The hash function iterates through all values ​​of the first random number segment, then increments (or otherwise modifies) the second random number segment, and then iterates through all permutations of the first random number segment again. Incrementing the second random number segment involves recalculating the Merkle root when modifying the hash of the Coinbase transaction contained in the Merkle tree.

[0025] When a valid proof-of-work hash of a block (i.e., a candidate block header hashed to a value less than the target value) is found, the new block is broadcast to the rest of the blockchain network. Other nodes on the network accept a new block only if all transactions in the new block are valid and have not yet been included in the block. Each block has a timestamp and references the hash of its previous block, thus forming a blockchain, hence the term "blockchain".

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

[0027] As shown in the table below, a transaction consists of a set of data fields. The raw form of a transaction consists of a set of serialized data fields, typically represented in hexadecimal.

[0028]

[0029] A transaction has one or more inputs, each referencing the output of a previous transaction. Each input can reference a different output of the same previous transaction, or outputs of different transactions, or a combination thereof. Each input contains an unlock script (sometimes called "ScriptSig") that, if it contains the correct data, will unlock the referenced output. The output of the current transaction can then spend (i.e., allocate to that output) the unlocked outputs of previous transactions, or more precisely, the amount of digital assets previously locked to that output. The unlocked amount of digital assets can be spent all at a single output or distributed across multiple outputs of the current transaction.

[0030] A transaction also has one or more outputs that collectively allocate the total amount of digital assets unlocked by the inputs. Typically, the sum of the output values ​​is less than the sum of the input values. Outputs can be either spendable or non-spendable. Spendable outputs contain a locking script (sometimes called a "ScriptPubKey") that defines one or more conditions that must be met before an input to a subsequent transaction can unlock the asset. Non-spendable outputs do not contain a locking script that can unlock the asset. In other words, non-spendable outputs contain locking scripts that would cause the execution of the locking script to fail.

[0031] 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 portion of the following description will relate to Alice sending tokens to Bob. However, it should be noted that this is for illustrative purposes only. These embodiments are equally applicable to Bob sending tokens to a third party (e.g., a merchant). Furthermore, the token issuer, i.e., the party that initially issues the tokens (e.g., Alice), will also be involved. Additionally, at least a portion of the following description will refer to a "first token transaction." Unless the context otherwise requires, the first token transaction can be created by any of Alice, Bob, or the token issuer.

[0032] Figure 4 An exemplary system is illustrated, comprising multiple parties such as a token issuer, Alice, Bob, and a merchant. While the term "party" can be used to refer to a user (e.g., Alice), a party can take other forms, such as a group of users including a company or other form of organization. It is also 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 autonomous entities are sometimes referred to in the art as "agents."

[0033] Although not shown in the figures, each party operates its respective computer equipment. The computer equipment of each party includes a corresponding processing unit, which includes one or more processors, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computer equipment of each party also 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 cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media like SSDs, flash memory, or EEPROMs, and / or optical media like optical disc drives. The memory on each party's computer equipment stores software, including corresponding instances of at least one client application configured to run on the processing unit. It should be understood that any action attributed herein to a given party can be performed by software running on the processing unit of the respective computer equipment. The computer equipment of each party includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The computer equipment of a given party may also include one or more other network resources, such as cloud computing resources accessed through the user terminal.

[0034] Client applications can initially be provided to any given party's computer device via, for example, a suitable computer-readable storage medium downloaded from a server, or via a removable storage device such as a removable SSD, flash key, removable EEPROM, removable disk drive, floppy disk or tape, optical disc such as a CD or DVD ROM, or a removable optical drive.

[0035] A token issuer is the party that issues one or more tokens to an initial recipient (e.g., Alice). An initial token transaction generated by the token issuer can be used to issue one or more tokens to Alice, or Alice can generate the initial token transaction herself. For example, the token issuer and Alice can agree on the number of tokens to be issued to Alice (and any other applicable contractual conditions), and Alice can then effectively issue tokens to herself by moving one or more tokens to another party (e.g., Bob).

[0036] Alice (or the token issuer) generates the initial token transaction. This token transaction includes one or more inputs and one or more outputs. Transaction fees are not always required. As with all blockchain transactions, the token transaction includes inputs used to unlock the outputs of previous transactions. For the initial token transaction, the referenced outputs of the previous transaction must include at least the quantity of the underlying asset reconfigured as the token. Figure 4 As shown, the initial token quantity is 1000, therefore the referenced output must have a value of at least 1000 units of the underlying asset. It should be understood that this number is arbitrarily chosen, and generally any number can be used as the initial token quantity.

[0037] The initial token transaction includes a first token output. This first token output locks an initial token quantity (1000 underlying asset units). Specifically, the first token output includes a first token locking script that locks the initial underlying asset unit quantity to the same number of newly defined tokens. This first token locking script includes variable components and constant components. In other words, the variable components are one part (i.e., a portion) of the first token locking script, while the constant components are another part (i.e., a portion). As the names suggest, the variable components may differ in different token transactions, while the constant components will remain unchanged.

[0038] The variable component is part of the token locking script, allowing tokens to be moved to another party. The variable component includes a payment template containing (e.g., surrounding) a payment address. The payment address may be based on the recipient's public key. For example, the payment address may be a public key hash (PKH) address, i.e., a hash (or double hash) of a public key. If the initial token transaction is generated by the token issuer, the payment address will be linked to Alice. If Alice generates the initial token transaction, the payment address will be chosen by Alice. Alice may choose to link to another address of her own, or she may choose to link to an address of another party such as Bob or a merchant. The payment address can be considered a sub-component of the variable component. The variable component may include one or more additional constant quantum components. For example, the variable component may include one or more constant opcodes for creating a payment to public key hash (P2PKH) format output.

[0039] The constant component includes a token mechanism sub-component, referred to simply as the "token sub-component," which is a constant component of the constant component. The token sub-component is part of the first token locking script and can reuse the underlying digital asset as a token, for example, converting 1000 units of the underlying asset 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. Furthermore, the token sub-component is configured to cause the execution of the token locking script to fail upon verification failure. That is, if any verification step fails, the execution of the token locking script and the execution of the unlocking script for the spending transaction input will fail.

[0040] The token sub-component requires that the input of the spending transaction (specifically, the unlock script) include certain data for effective execution. This input to the spending transaction is referred to as the spending input. Specifically, the unlock script of the spending input must include at least a portion of the spending transaction data, i.e., spending transaction data other than the unlock script itself (some parts are left as is, while only the results of other parts are hashed). From now on, this data is referred to as... Hash preimage (Because its hash is used as input in the ECDSA verification formula), or simply called original image The preimage includes fields of the spending transaction and the transaction being spent, as well as data items generated (hash-processed) based on these transaction fields. In other embodiments, all data fields of the spending transaction are included verbatim in the unlock script of the spending input.

[0041] The token subcomponent is configured to, upon execution, obtain, from the unlock script of the spending input, excluding... original image One or more data pairs other than those specified in the transaction. Each data pair includes at least the payment address of the locking script for the spending transaction and the corresponding quantity of the underlying digital asset locked by the locking script. In some examples, the spending transaction contains only one output, i.e., one locking script. In this case, the token subcomponent obtains one data pair. In other examples, the spending transaction contains multiple outputs, i.e., multiple locking scripts. In this case, the token subcomponent obtains multiple data pairs.

[0042] The required data can be obtained by parsing the unlock script from the cost input and extracting the data pairs. This may require including the data pairs in the unlock script at predefined locations. A more detailed discussion is provided below.

[0043] After obtaining one or more data pairs, the token subcomponent is configured to verify that one or more outputs of the spending transaction have a specific format. At least one output of the spending transaction must include a predetermined payment address (only as part of a predetermined standard payment template) or any address (as part of a predetermined standard payment template), but must also be followed by a constant component of the token output (i.e., an identical constant component). The token subcomponent can determine and verify that multiple 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 can also verify that the spending transaction includes one or more outputs that do not contain a predetermined payment address (only having its corresponding standard template) or any payment address (having its corresponding standard template), followed by a constant component of the token output.

[0044] The token subcomponent is also configured to verify that the sum of the output lock values ​​for spending transactions (including a predetermined payment address or any payment address followed by a constant component) equals the initial token quantity (i.e., is the same as it). The output of a spending transaction containing a predetermined payment address or a constant component can be referred to as a smart token output. The token subcomponent verifies that the total number of tokens locked in the smart token output equals the initial token quantity, thereby preventing leakage back to the original format or any other usage format.

[0045] For example, consider a scenario where the spending transaction contains a single smart token output (the first output of the spending transaction). The token subcomponent is configured to verify that the first output of the spending transaction has a first locking script in a specific format, or more precisely, containing specific data. Specifically, the first locking script must contain a predetermined payment address (as part of a payment template) or any payment address (as part of a payment template), followed by a constant component of the token locking script. Only one of these two addresses is required, but if both addresses are missing, the verification will fail. This verification process is feasible because the token subcomponent has already obtained the first locking script of the spending transaction from the unlocking script of the spending input. Therefore, the token subcomponent can search for the predetermined payment address or the constant component in the first locking script.

[0046] As described above, the spending transaction may contain multiple outputs. Some additional outputs may also be smart token outputs or may be used for different purposes. In this case, the token subcomponent is configured to verify that multiple outputs of the spending transaction contain a predetermined payment address or any payment address, followed by a constant component of the token transaction (i.e., a constant component of the token locking script). Depending on the implementation, the token subcomponent may be configured to verify that each of the multiple outputs of the spending transaction includes a predetermined payment address or a constant component. In other examples, the token subcomponent may be configured to verify that some, but not all, of the multiple outputs contain a predetermined payment address or a constant component. For example, the token subcomponent may verify that a predetermined number of outputs of the spending transaction contain constant components, such as the first two outputs (i.e., the two logically first outputs in the spending transaction).

[0047] In an example where the spending transaction includes a single smart token output, the token sub-component is configured to verify that a first quantity of the underlying digital asset locked by the first locking script of the spending transaction is equal to the initial token quantity (i.e., 1000 units of the underlying asset). In this document, the first output with the first locking script is the logically first output in the spending transaction.

[0048] If the spending transaction includes multiple outputs, such as a second output of a second locking script with a second quantity of locked digital assets, the token subcomponent is configured to verify that the sum of the first quantity and the second quantity equals the initial token quantity. In this document, the second output is the logically second output to appear in the spending transaction. Typically, if the spending transaction includes multiple outputs containing a predetermined payment address or constant components, the token subcomponent verifies that the sum of their respective quantities equals the initial token quantity.

[0049] This process can be repeated for any number of outputs of the spending transaction. It is permissible for the spending transaction to include outputs that lock a quantity of digital assets, resulting in the sum of digital assets locked by all outputs of the spending transaction being greater than the initial token quantity. In this case, the token sub-component is configured to verify that a predetermined number of smart token outputs of the spending transaction together lock a quantity of digital assets equal to the initial token quantity, regardless of the quantity locked by non-smart token outputs. Non-smart token outputs can be fee-changing outputs or atomic swap outputs. For example, the total number of tokens locked by the first two outputs of the token transaction must be equal to the initial token quantity, while a third output (e.g., a fee-changing output) can lock an additional quantity funded by additional inputs. It should be noted that the third output is for illustrative purposes. Fee-changing outputs will be discussed in detail below. It can now be stated that this is only permitted if the fee-changing output (or a different type of "additional output") is not a token output (i.e., does not contain a constant component of the token locking script).

[0050] The constant component of the token locking script may contain a predetermined payment address. That is, the predetermined payment address may be hard-coded into the constant component and therefore must be included in the first locking script of the spending transaction. The predetermined payment address may be a redemption address, such as an address where some or all of the tokens can be moved to redeem something other than the tokens (e.g., fiat currency).

[0051] As mentioned above, the unlock script for the cost input of a cost transaction may include a preimage. The preimage may include one, some, or all of the fields shown in the table below.

[0052]

[0053] It should be noted that this particular structure, including the preimage, is for illustrative purposes only, and other structures may be used. For example, the size of the data fields may vary depending on the specific blockchain used to implement this invention.

[0054] In these examples, the token subcomponent can be configured to obtain the token locking script (i.e., the input scriptCode) and the initial token quantity (i.e., the output value of the input cost) for the initial token transaction by extracting them from the preimage. Since the size of all data fields in the preimage (except scriptCode) is known, the token subcomponent can extract the required fields by parsing and extracting data at predetermined locations.

[0055] As shown in the table above, the preimage can include the hash(hashOutput) of the outputs of the spending transactions. 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 contains a single output, the hashOutput contains the hash of a value concatenated with a locking script. If the spending transaction contains two outputs, each value is hashed after being concatenated with the locking script to form the hashOutput. The token sub-component can extract the hashOutput from the preimage by parsing and extracting data from specific locations.

[0056] As mentioned above, the unlock script for a spending transaction contains one or more data pairs. It's important to remember that each data pair includes a value and a locking script. The token subcomponent can be configured to generate its own version of hashOutput, i.e., generate a hash of one or more data pairs, and then verify that the generated hash is equal to the hash extracted from the preimage (i.e., hashOutput). This may be done to confirm that the spending user (e.g., Alice or Bob) included the correct data pairs in the unlock script for the spending transaction.

[0057] In some examples, the token subcomponent can be configured to verify that the preimage included in the unlocking script of the spending transaction has been correctly generated, i.e., that the data fields of the preimage correspond to the actual data fields of the spending transaction. This is necessary if it cannot be assumed that the system user can correctly generate the spending transaction. To this end, the token subcomponent generates its own expected version of the preimage for the spending transaction, for example, a preimage containing all the data fields in the table above. The token subcomponent can then verify whether the preimage extracted from the unlocking script of the spending transaction matches the preimage generated by the token subcomponent.

[0058] One way to verify that the preimage contained in the unlock script of a spent transaction is correct is to use a pseudo-opcode known in the art as OP_PUSH_TX. However, any equivalent opcode can be used instead, or more colloquially, any equivalent code that performs the same function as OP_PUSH_TX.

[0059] Typically, the token subcomponent can be configured to generate a digital signature (e.g., an ECDSA signature) using a preimage and a private key from an unlocking script. The private key is contained in the unlocking script for the spending transaction. The token subcomponent then verifies that the digital signature is valid when verifying against the generated preimage (i.e., the preimage generated by the token subcomponent) and the public key corresponding to the private key. The public key is also contained in the unlocking script for the spending transaction. The digital signature is valid only if the two preimages match exactly. Since the private key used is publicly available because it is recorded on the blockchain, a "virtual" private key should be used—that is, a private key that will not compromise the security of other data or blockchain transactions if disclosed. However, any private key can generally be used, such as any random key. This signature check can be performed by verifying the signature using the OP_CHECKSIG opcode. OP_CHECKSIG is an opcode that will only succeed (i.e., execute successfully) if the signature is used in the current transaction (i.e., the spending transaction in this example).

[0060] Returning to the output of the spending transaction, the token sub-component can be configured to verify that one or more outputs of the spending transaction (specifically, their corresponding locking scripts) contain a corresponding payment address of a predetermined type (i.e., format). Preferably, the corresponding payment address must be of the same type as the payment address contained in the variable component of the token transaction. More preferably, the payment address must be a PKH address. This can be verified based solely on the payment address itself, or it can be verified based on the payment address and one or more additional data items (e.g., one or more opcodes or other data flanking the payment address). For example, a P2PKH output includes certain additional data that can be examined in the output.

[0061] The token subcomponents of the constant component have been discussed above. The constant component may also include a constant data subcomponent (referred to as the "data subcomponent"). Typically, the data subcomponent may contain any data to be stored in each token output. For example, the data subcomponent may include a token protocol identifier, such as a flag indicating that the token belongs to a specific protocol, or an indication that the token represents fiat currency. Additionally or alternatively, the data subcomponent may include a transaction identifier (TxID) of a transaction recorded on the blockchain (referred to as a "token issuance transaction"). Similarly, the token issuance transaction may typically contain any data, such as the token issuance contract issued by the token issuer and / or the initial number of tokens. The data subcomponent may be included after the OP_RETURN opcode or a code that performs an equivalent function.

[0062] The above description primarily concerns the initial token transaction and the spending transaction. The spending transaction, which is itself a token transaction, will be described in more detail below. The spending transaction will be referred to as the "first token transaction" in order to reserve the term "spending transaction" for subsequent transactions that reference the output of the first token transaction.

[0063] Combining Figure 1 Describe the first token transaction. For example... Figure 1 As shown, 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 unlock script 110. It should be noted that... Figure 1 This is a schematic diagram. Input 104 itself does not contain input value 108. Instead, input 104 contains pointers to previously output unspent transactional outputs (UTXOs) (e.g., TXID and VOUT), which are locked to value 108, now referred to as input value 108. However, the value 108 unlocked by the corresponding unlock script 110 is shown for illustrative purposes. Each output 106 includes output value 112 and lock script 114.

[0064] First, we will describe output 106 of the first token transaction 100, since it has already been described in conjunction with the spending transaction above. Token transaction 100 includes at least the first token output (“exchange / token output”). The first token output is as follows: Figure 2 As shown. Figure 2 As shown and as described above, the first token output 200 includes a variable component 202 and a constant component 204. The constant component 204 includes a token mechanism subcomponent 206, and in this example, also includes a constant data subcomponent 208.

[0065] Variable component 202 contains the corresponding payment address of the party to which the first token quantity (e.g., 700 tokens) is allocated. Token subcomponent 206 is configured to perform some or all of the verification steps described above. For example, token subcomponent 206 is configured to verify that the total amount of digital assets locked by a predetermined number (e.g., one or two) of the outputs of a spending transaction equals the first token quantity (700 tokens). Token subcomponent 206 of the first token output 200 is also configured to verify that inputs to subsequent spending transactions attempting to unlock the first token output 200 include a regular payment template with a redemption payment address or the full format of the first token output 200 including variable component 202 and constant component 204. Typically, token subcomponent 206 can be configured to perform any of the verification techniques described above.

[0066] The first token transaction 100 may also include a second token output. The second token output further includes corresponding variable components and corresponding constant components. Compared to the variable component 202 of the first token output 200, the variable component of the second token output may contain a different payment address. The token sub-component of the second token output is configured to perform the same verification steps as the token sub-component 206 of the first token output 200, except that the verification is now a different spending transaction (i.e., a spending transaction with inputs referencing the second token output). In other words, the first token transaction 100 may have multiple outputs, each of which may be spent (unlocked) by a different spending transaction. For example, the token sub-component of the second token output is configured to verify that the total amount of digital assets locked by a predetermined number (e.g., one or two) of the outputs of the spending transaction is equal to the number of second tokens (300).

[0067] The first token transaction 100 can contain any number of token outputs, and attempts to spend them as long as the sum of their corresponding token counts is exactly equal to the value locked in the first token output (1000 tokens) (referenced by the TXID field in the transaction input).

[0068] The first token transaction 100 may include a fee change output. This output enables the fee change (X-δ) to be returned to the fee change payment address. Figure 1 In the example shown, the input payment transaction fee (δ) is paid using the fee payment input with the input value (X).

[0069] Additionally or alternatively, the first token transaction 100 may include atomic swap outputs. These atomic swap outputs will be described below.

[0070] exist Figure 1In the example shown, the first token transaction 100 includes token inputs. These token inputs are equivalent to the spending inputs described in detail above. More specifically, the token inputs reference token outputs from a previous token transaction (e.g., the initial token transaction). In this example, the referenced token outputs lock 1000 tokens. The token inputs include the entire contents of the first token transaction except for themselves, including corresponding data pairs for each output 106 of the first token transaction 200. That is, in this example, the token inputs include three values ​​(700, 300, X-δ) and three corresponding payment addresses, each address from each locking script for the token (“Exchange / Token Output”, “Token Output (Split)”, “Fee Change / Atomic Swap”). Values ​​112 and payment addresses can be paired such that a first token quantity (700) is followed by a payment address from the first token output locking script, followed by a second token quantity (300) and a 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 (i.e., a signature corresponding to the payment address contained in the variable component of the referenced token output). If Alice is moving tokens, Alice's signature will be included in the input of the spending transaction. In some examples, the entire locking script may be included in the input (i.e., as part of a data pair), not just the payment address.

[0071] like Figure 1 As shown, the first token transaction 100 includes a fee payment input. This fee payment input references the output of a previous, different, regular non-token transaction. The fee payment input includes at least one digital signature, depending on the requirements of the output it references. 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 can fund the transaction. In this case, Alice's signature is included in the fee payment input. However, it is not excluded that another party (e.g., 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. In this example, Bob funds the transaction by including his signature in the fee / “token purchase” input, while 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, such as a hash of a public key owned by Bob.

[0072] To perform the atomic swap, Alice creates a complete transaction except for the fee / “token purchase” payment input. Bob then creates and adds the fee / “token purchase” payment input. One way to do this is for Alice to sign her input (i.e., the token input) and two corresponding outputs with a sighash flag (e.g., ALL|ANYONECANPAY), which allows the other party to add the input. Bob then adds the input with a different sighash flag (e.g., ALL, completing the entire transaction and disallowing any further additions).

[0073] Figure 3A and Figure 3B The concept of atomic swaps is explained in more detail. Solid arrows indicate mandatory inputs and outputs, while dashed arrows indicate optional inputs and outputs. The left side of the diagram shows the inputs of a transaction, and the right side shows the outputs. Figure 3A It schematically shows the relationship with Figure 1 A similar transaction. This exemplary token transaction includes a token input generated by Alice to unlock a token output from a previous token transaction, and may also include a fee payment input for paying transaction fees. The token transaction also includes a token output sent to Bob, wherein the token output is locked to an address contained in a token format (e.g., 200); and a fee change output, wherein the fee change output pays Alice in a regular payment format a change locked to her address (the change specified in its output is the difference between the fee input payment and the transaction fee).

[0074] Figure 3B An example of an atomic swap transaction is shown. Bob's token output is used in conjunction with... Figure 3AThe same method is used. Alice generates token inputs again to unlock token outputs from the previous token transaction, but this time she signs the transaction using the 'ALL / ANYONECANPAY' sighash flag. This means Alice's signature signs all outputs, but only this one input (i.e., the input that spends the token output signed with that sighash flag). The rest of the inputs are excluded. This sighash flag allows anyone to add or remove other inputs, so anyone can add funds to the transaction but cannot change where or how much goes. This allows Bob to only add his payment input. Bob has a signature, and he signs it using the 'ALL' sighash flag. This means Bob's signature signs all inputs and outputs, thus protecting all elements from any further possible modification. In this example, the second output is paid to Alice, thereby adding Bob's input. This has the effect of performing an atomic swap, so the token is sent to Bob if and only if Bob pays Alice with the token. If Bob is not satisfied with any component of the transaction, he will not provide a signature, so the tokens will not be moved to his address, and Alice will not receive the payment. Similarly, since Bob cannot modify the inputs and outputs that Alice creates and signs, Alice can ensure that Bob will only receive the tokens if the payment conditions set by Alice are met.

[0075] Figure 4 An exemplary process from token issuance to redemption is illustrated. The process is typically top-down. As an optional first step, a legal contract is drafted between the token issuer and the initial recipient, Alice. This contract may specify various terms and conditions of the token, including how to redeem it and the initial number of tokens (e.g., 1000). The token issuer can then create an initial token transaction and send the tokens to Alice. Alternatively, Alice can create an initial token transaction and send some or all of the tokens to another user (e.g., Bob), or even to herself. Figure 4 In the transaction, Alice sends all tokens to Bob; that is, all tokens are allocated to a single token output sent to Bob's payment address. Bob then creates a token transaction with 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 can be another of Bob's payment addresses. The merchant then redeems its 300 tokens, i.e., by sending the tokens to the redemption payment address. Bob then initially redeems 500 tokens as well, while sending the remaining 200 tokens to another payment address linked to Bob. Finally, Bob redeems 200 tokens. It's important to note that in each transaction, the number of incoming tokens matches the number of outgoing tokens.

[0076] The embodiments of the present invention have been generally described above. Specific implementations of the invention will now be described. This particular example is based primarily on representative... legal The tokenization of currency describes it as follows: a token is associated with... legal A token pegged to a currency. However, this is just one of many possible use cases for this invention. However, any output-based blockchain (e.g., UTXO-based) can generally be used.

[0077] Token outputs may include a single unit of underlying asset representing a single token (e.g., a utility token for an event, movie ticket, bus ticket, etc.). Therefore, the token is indivisible and cannot be split during its lifetime. Alternatively, token outputs may include multiple units of underlying asset representing a bundle of multiple tokens (e.g., a token pegged to the US dollar represents a token worth 1 cent).

[0078] The token output consists of a variable portion and a constant portion. The variable portion is identical to a regular payment template, which uses ECDSA to transfer ownership of the digital asset. The constant portion cannot be changed or omitted throughout the token's lifecycle.

[0079] Currently, each unit of the underlying asset represents a token and ceases its normal functioning, although it could represent something cheaper or more expensive than the underlying asset itself. Alice cannot move any tokens to Bob unless she retains the template as a locking script in subsequent token transactions. Only the ownership address of the variable section can be changed.

[0080] It should be noted that this differs from previous tokenization attempts that used metadata to interpret outputs as tokenized outputs. This invention fundamentally changes the mechanism by which the underlying asset unit is used as a digital asset in its conventional application.

[0081] The variable section is intentionally placed at the beginning of the token locking script, and is simply a regular payment template (e.g., a P2PKH template). This provides maximum compatibility with existing blockchain client applications and browsers, and allows payment addresses (encapsulated in the template) to be searched and located in the current manner.

[0082] The token mechanism enforces at least three conditions. First, token spending is only possible if the next UTXO has the exact same locking script as the UTXO being spent (except for the new ownership address). Second, spending of transactions using regular locking script templates (e.g., P2PKH, P2PK, etc.) fails unless the template is a P2PKH containing a pre-determined redemption payment address. The pre-determined redemption payment address is included in the contract sent 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 has the ability to restore the underlying asset units representing the asset to their original regular use as underlying asset units, such as by releasing the represented assets like dollars, gold, etc., which makes the token permissionless. Third, when moving tokens, the number of underlying asset units in the token output of the current unspent token output (UTXO) must be exactly the same as the number of underlying asset units in the token output of the spending transaction (e.g., redemption or subsequent token transaction), or split into two or more groups of tokens whose sum must equal the original number of the UTXO. For example, a token can be split into two outputs of a spending transaction, and the locking scripts for these two outputs are the same as the locking script for the UTXO being spent (except for the address of the variable part).

[0083] The state pushed into these stateful transactions is the ownership address updated with each bounce and (only in the case of token bundles) the number of tokens, where tokens can be reduced by splitting.

[0084] The constant data section has two fields. One field contains a token protocol identifier, such as the token protocol flag for a token pegged to fiat currency. This identifier is used to specify the token type. The second field is a pointer to a special transaction (TxID), which contains: a) the initial issuance contract (e.g., the initial issuance contract between the issuing entity and the customer) and all its legal terms, conditions, licenses, and any other necessary information related to the token attributes and issuance; and b) the exact balance of the underlying asset units that are scheduled to be converted into the token in a subsequent transaction (issuance transaction) with token output.

[0085] Constant data fields are placed after the OP_RETURN opcode as a data appendix to avoid being attempted to be executed as part of the script code during script evaluation. In other words, constant data is preferably included at the end of the locking script, immediately after the OP_RETURN opcode, to maximize compatibility with applications and browsers that perform searches on OP_RETURN transactions.

[0086] In terms of the transaction structure itself, the output of a token transaction can take one of the following three types: i) regular output for redemption; ii) token output; or iii) regular output for fee changes, atomic swaps, etc.

[0087] For example, Alice can request a legally authorized entity to issue 1000 tokens on her behalf and provide that entity with her payment address. The entity creates a protocol in the form of a spendable transaction, where the pre-allocated number of underlying asset units corresponds to the requested number (1000 in this example). The terms, conditions, and permissions of the protocol specify the actions Alice requires (e.g., transferring a corresponding amount of fiat currency to the entity) and are signed by the entity, for example, with the ALL|ANYONECANPAY flag, allowing Alice to add her signature. Once Alice has signed and published the protocol to the blockchain, and performed the specified required actions (transferring a certain amount of fiat currency), the entity issues tokens on her behalf to her payment address. Alice can now use / spend / transfer all or a portion of the tokens at once. Subsequent holders can freely redeem the tokens, thus the tokens are permissionless.

[0088] Returning to the constants section of the token output, it roughly consists of two parts. The first part implements OP_PUSH_TX, which is responsible for accessing the fields of the current transaction during script execution. The second part is the token logic.

[0089] The above describes the sighash preimage. OP_PUSH_TX performs an ECDSA signature on the preimage corresponding to the current transaction (i.e., the spending transaction that unlocks the token output), which has been pushed into the unlock script for access within the executed script. OP_PUSH_TX ultimately calls OP_CHECKSIG to verify the signature. This internal ECDSA signature is performed using any publicly accessible private-public key pair (a temporary key pair and a constant key pair), so the private-public key pair should be unrelated to the one used for the token ownership transfer. Furthermore, in this example, OP_CHECKSIG acts as the verifier because, at the time of the call, it constructs its own ECDSA verification preimage from the actual previous and current transaction fields. Therefore, it will either fail or succeed depending on whether the actual fields are the same as those pushed into the unlock script.

[0090] The token logic converts the underlying asset into tokens. To do this, the code needs access to the underlying asset value (quantity) of previous transactions (i.e., unspent outputs containing tokens) and the underlying asset value of the current transaction (i.e., the spending transaction) to control the spending of the underlying asset. The code also needs access to previous and current locking scripts to control the format of the output locking scripts.

[0091] Once the preimage in the unlock script of the current (spending) transaction is verified to be identical to the actual preimage of the current transaction, it will be parsed to extract all relevant fields, including scriptCode and the cost of the output for that input value ,as well as hashOutput While the locking script and the value (i.e., the quantity) of the previous UTXO (i.e., the UTXO being spent) are provided as is in the preimage, only the hashed result of the locking scripts (combined with the new values) for all newly created outputs is available. Therefore, the locking scripts for these new outputs and their corresponding values ​​should be placed next to the preimage in the unlocking script of the spending transaction, and then hashed according to the preimage. hashOutput The field was verified, and it had previously been proven that the field was the same as the field constructed by OP_CHECKSIG when it was called.

[0092] Once the executing code has access to all the lock scripts and their values ​​(i.e., quantities) output by previous and subsequent transactions, the token rules can be executed.

[0093] The following exemplary rules can be executed. It should be understood that other additional or alternative rules can be implemented depending on the specific use case. In this example, the following are allowed: 1. Exchange Function -- Used to define a hard-coded address that can convert the token's nature back into the underlying digital asset.

[0094] 2. The number of tokens can be divided into at most two possible outputs.

[0095] 3. The third optional output has a P2PKH format and is used to receive changes, either by appending inputs or, in the case of an "atomic swap," for the token seller to receive currency.

[0096] More specifically, the rules are: 1. The first output of a token transaction is used only for: a) Redemption -- Standard P2PKH template, including a hard-coded redemption address, or b) Token Transfer -- Smart Token Locking Script with the same output format as before.

[0097] 2. The second output is optional for token splitting and can only be a smart token type. Additionally: a) If a second output exists, the sum of its number and the number of the first output must be equal to the number of UTXOs being spent.

[0098] b) Otherwise, the number of the first outputs must be equal to the number of UTXOs being spent.

[0099] 3. The third output is simply a standard P2PKH template (the address can be any address). If the third output exists, it is used to change the payment for token operations (i.e., completed by appending input).

[0100] It should be noted that the P2PKH template is a transaction output script. When the unlock script before VarInt (specifying the length of the following script) 0x19 is pushed in, its hexadecimal form is "0x76a914 + PKH + 0x88ac" because its length is 25 bytes. PKH is the public key hash address.

[0101] Exemplary pseudocode for enforcing these rules is now provided.

[0102] redemption_PKH = 25daa25932d355826ce60881978f79621f1dfcd9 / / Push onto the stack before the function code. function token (sighashPreimage, amountOne, PKH_One, amountTwo, PKH_Two, amountChange, PKH_Change) { / / Verify that the original image is correct assert (validate( sighashPreimage ) ); / / Analyze the preimage len = sizeof( sighashPreimage ); / / Since the script size range is known, VarInt has a '0xfd' prefix, followed by two bytes containing the size value. / / Skip the '0xfd' prefix to the actual script length VarInt = sighashPreimage[105:107]; / / scriptCode is the previously output locking script scriptCode = sighashPreimage[ 107: 107+VarInt ]; value = sighashPreimage[len - 52 : len - 44]; hashOutputs = sighashPreimage [ len - 40 : len - 8 ]; First Script; / / The first output script may be P2PKH (in the case of exchange), or, except for the PKH address, it may be exactly the same as the script in the previous TX. if(PKH_One != redemption_PKH){ / / Read the constant portion from scriptCode, followed by the new address (after: "76a914" +PKH) / / Rebuild the entire script using the data section, only replacing the new owner address. / / 23 is the length of the first 3 opcodes and the address. FirstScript = concatenate( VarInt, “76a914”, PKH_One, scriptCode[ 23:]); } else { / / A redemption can be a part of a split, but it must be the first output. / / I am "88ac"; FirstScript = concatenate(“1976a914”, PKH_One, “88ac”); / / In the case where P2pKHVarInt is 0x19 } NextScripts = concatenate( amountOne, FirstScript ); / / A second optional output for splitting tokens (if present, may be only a smart token output) / / Allows splitting tokens with no value (0) - can be used for proof if (PKH_Two){ NextScripts = concatenate (NextScripts, amountTwo, VarInt, “76a914”,PKH_Two, scriptCode[ 23 : ] ); assert( value == ( amountOne + amountTwo ) ); } else { assert(value == amountOne); } The following content and code involve the use of scriptThe actual exemplary implementation of the language. In some exemplary implementations, the order in which the unlock script parameters are used is the same as the order (from left to right) in the pseudocode function definition above, meaning that the leftmost parameter is pushed onto the stack first. The hard-coded address of the redemption function is set to the first field of the "constant code" section of the locking script, and therefore is pushed onto the stack immediately after the unlock script data (excluding the variable section for ECDSA signature verification).

[0103] It should be noted that some of the exemplary script implementations are space-optimized rather than time-optimized.

[0104] / / Template for 'Variable Data' section (P2PKH), followed by the redemption address and preimage extraction. OP_DUP OP_HASH160 2f2ec98dfa6429a028536a6c9451f702daa3a333 OP_EQUALVERIFY OP_CHECKSIG OP_VERIFY 25daa25932d355826ce60881978f79621f1dfcd9OP_7 OP_ROLL OP_DUP / / Implementation of OP_PUSH_TX OP_HASH256 OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 00 OP_CAT4091de8968a1066ab9c6f292823ab43111fb1d0630f3f087e7e42f03533f92a2 d779753ff4a0922831cf7fd3692ec96055665621e97adc95a8a45766e3e0c26a OP_ADD 119ef8f4f04e6864c0608c6d71018e00fb2d17049a8750644299c78b547c2924OP_MUL 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffffff00 OP_TUCK OP_MOD OP_2DUP OP_SWAP OP_2 OP_DIV OP_GREATERTHAN OP_IF OP_SUB OP_ELSEOP_NIP OP_ENDIF OP_SIZE OP_DUP 25 OP_ADD 30 OP_SWAP OP_CAT 022100c7a2f4a156ecd42ba9326b31a86c61225dec5a71c3238408f360a9d2f3cf0be002 OP_CAT OP_SWAP OP_CATOP_SWAP OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUBOP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IFOP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIFOP_ENDIF OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CATOP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT 41 OP_CAT 03ea9a8e84d865bcd6fc0d1354816bc2eb423a6adf80e42654f1edc101ed033ce3 OP_CHECKSIGVERIFY / / Parse the sighash preimage into 4 related fields: VarInt (length), scriptCode, value (amount to be spent), and hashOutputs (or the hash with output, and the corresponding number of matches). 68 OP_SPLIT OP_NIP OP_3 OP_SPLIT 17 OP_SPLIT OP_NIP OP_OVER OP_1 OP_SPLIT OP_NIP 00 OP_CAT 17 OP_SUB OP_SPLIT OP_8 OP_SPLIT OP_4 OP_SPLIT OP_NIP20 OP_SPLIT OP_DROP / / Prepare the first output quantity OP_10 OP_ROLL OP_8 OP_NUM2BIN OP_DUP / / Construct the first output script based on the address (smart token locking script or standard 'P2PKH' for redemption) OP_11 OP_ROLL OP_DUP OP_8 OP_ROLL OP_EQUAL OP_NOTIF OP_6 OP_PICK 76a914 OP_CAT OP_SWAP OP_CAT OP_5 OP_PICK OP_CAT OP_ELSE 1976a914 OP_SWAP OP_CAT 88ac OP_CAT OP_ENDIF / / Pair the first output script with the number of scripts you prepared earlier (cascade) OP_CAT / / Construct a second optional smart output (if it exists) / / Enforce the immutability of the token quantity (for two cases - splitting or simple transfer) OP_8 OP_PICK OP_IF OP_9 OP_PICK OP_8 OP_NUM2BIN OP_CAT OP_5 OP_PICK 76a914 OP_CATOP_9 OP_PICK OP_CAT OP_5 OP_PICK OP_CAT OP_CAT OP_3 OP_ROLL OP_ROT OP_9 OP_PICK OP_ADD OP_NUMEQUALVERIFY OP_ELSE OP_3 OP_ROLL OP_ROT OP_NUMEQUALVERIFY OP_ENDIF / / Construct a third optional standard P2PKH output for changes (if it exists) OP_4 OP_PICK OP_IF OP_5 OP_PICK OP_8 OP_NUM2BIN OP_CAT 1976a914 OP_5 OP_PICK OP_CAT 88ac OP_CAT OP_CAT OP_ENDIF / / Verify all new outputs and their corresponding amounts passed to the unlock script (at the top of the stack). / / Yes, that's correct - their hash results are the same as the hashOutputs field from the preimage (right after the top of the stack). / / In the very first step, it was proven that it was consistent with the actual spending transaction.

[0105] OP_HASH256 OP_EQUAL / / Constant data section.

[0106] OP_RETURN 27ed5442ab151b32db7b586d433879d84af3398a 723c903d83cdce9f32246a451652f4b4f469ef78d630bf0f22770cb16bbc187b in conclusion It should be understood that the above embodiments are described by way of example only.

[0107] More generally, according to one aspect disclosed herein, a computer-implemented method for sending digital tokens using blockchain transactions is provided, wherein each token is represented by a single unit of underlying digital asset native units of the blockchain, wherein the method includes: generating a first token transaction; and transmitting the first token transaction to a blockchain network; wherein the first token transaction includes a first token output, the first token output including a first token locking script and a first token quantity, wherein the first token locking script includes a variable component and a constant component, wherein the variable component includes a first payment address embedded in a payment template, wherein the constant component includes a token mechanism sub-component, and wherein, when executed together with an input script for a spending transaction, the input script includes all of the spending transactions except itself, and corresponding locking scripts and the quantity locked in the output of the previous transaction being spent, the token mechanism sub-component being configured to: obtain one or more data pairs from the input script of the spending transaction, each data pair including: i) at least one corresponding payment address, which is included in the corresponding locking script of the spending transaction output, and ii) The corresponding quantity of the underlying digital assets is locked by the corresponding locking script of the output; verifying one or more outputs of the spending transaction includes a corresponding locking script, the locking script including: a) a corresponding payment script template, which includes a predetermined payment address, or b) a corresponding variable component, which includes a corresponding payment address other than the predetermined payment address, followed by the constant component; and, for one or more outputs of the spending transaction, verifying that the total amount of the underlying digital assets locked by the corresponding locking script of the one or more outputs is equal to the first token quantity; and wherein, if any verification step fails, the token mechanism subcomponent is configured to fail during execution.

[0108] A spending transaction includes at least one output, which includes a first locking script format. A spending transaction may include multiple outputs, such as a second and third output, each with a corresponding locking script format. For a transaction to succeed, all locking scripts for the new outputs of these spending transactions must have the same smart token format as the outputs of the previous transaction being spent, or a standard payment template containing a predetermined redemption address. The only exception is optional outputs (e.g., the last output), whose locking scripts must be a standard payment template containing an arbitrary address, e.g., for receiving atomic swap payments. The inputs to a spending transaction should contain data pairs for each output and a sighash preimage of the entire transaction, the hashed result of which serves as input to the ECDSA verification formula. The token mechanism subcomponent is configured to operate based on this assumption—if this assumption is not met, the execution of the token mechanism subcomponent will fail, making any token operations impossible.

[0109] This is also the case if the spending transaction has additional optional outputs that do not include the constant component of the first token locking script of the output being attempted to be spent. The native token locked in such optional outputs is not part of the retention amount of the newly defined token transferred from one transaction to another.

[0110] Some parts of the spending transaction are included in the input script in their original form, while others are included as the result of hash processing.

[0111] Each payment address can be embedded in the payment template.

[0112] In some embodiments, the spending transaction may include a first output and a second output, the first output including a first locking script and the second output including a second locking script, wherein the token mechanism sub-component is configured to: verify that the first output of the spending transaction includes the first locking script, the first locking script including: a) a corresponding payment script template including a predetermined payment address, or b) a corresponding variable component including a corresponding payment address other than the predetermined payment address, followed by the constant component; verify that the second output of the spending transaction (if present) includes the second locking script, the second locking script including: a) a corresponding standard payment script template including a predetermined payment address, or b) a corresponding variable component including any address other than the predetermined payment address, followed by the constant component; and, if the second output exists, verify that 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 first token quantity.

[0113] In some embodiments, the token mechanism component may be configured to: if the first locking script of the spending transaction does not include the standard payment script template containing a predetermined payment address, then verify that the first locking script includes a corresponding variable component containing a payment address other than the predetermined payment address, followed by the constant component, which is the same as the corresponding constant component of the first token locking script of the previous transaction being spent; and / or, if the second locking script of the spending transaction exists, then verify that the second locking script includes a corresponding variable component containing any payment address, followed by the constant component, which is the same as the corresponding constant component of the first token locking script of the previous transaction being spent.

[0114] In some embodiments, the constant component may include the predetermined payment address.

[0115] In other words, the predetermined address is hardcoded in the constant part.

[0116] In some embodiments, the input script for the spending transaction may include a sighash preimage, wherein the preimage includes the first token locking script and the first token quantity, wherein the token mechanism subcomponent is configured to extract the first token quantity and the first token locking script of the output being spent from the preimage to perform the verification step.

[0117] The first token locking script included in the input of the spending transaction is the locking script of the output of the attempted spending transaction, and is the same as the locking script being executed at that time. The first token quantity included in the input of the spending transaction is the value retained in the output of the attempted spending transaction.

[0118] In some embodiments, the preimage may include a concatenated hash of one or more data pairs, each data pair including a corresponding payment address from a corresponding locking script of the spending transaction and a corresponding quantity locked by the corresponding locking script, wherein the token mechanism subcomponent is configured to: extract the concatenated hash of one or more data pairs from the preimage; generate a hash based on the one or more data pairs; and verify that the generated hash is equal to the extracted hash.

[0119] Depending on the format of the spending transaction output, one or more of the "corresponding quantities" can be native tokens, such as outputs of optional change or "atomic swap" payment receptions, and one or more of the corresponding quantities can be redefined tokens, such as those used for exchange or token outputs.

[0120] In some embodiments, the one or more data pairs used to generate the hash may be either obtained from the input script or constructed by obtaining the input address and quantity pairs of the previous output locking script from the preimage.

[0121] Any reference to "hash" can be equivalent to "double sha256 hash". Generally, any hash function can be used as long as the same hash function is used throughout.

[0122] In some embodiments, the token mechanism subcomponent may be configured to: generate a preimage of the spending transaction data; and verify that the generated preimage of the spending transaction data is equal to the preimage contained in the input of the spending transaction.

[0123] In some embodiments, the input of the spending transaction may include a dummy private key and a corresponding dummy public key, wherein the token mechanism sub-component is configured to: verify that the preimage generated by the spending transaction is equal to the preimage contained in the input of the spending transaction by generating a digital signature using the dummy private key and the hash of the preimage contained in the input of the spending transaction; and verify that the digital signature is a valid signature when verifying the hash of the dummy public key and the preimage generated by the spending transaction.

[0124] Depending on the specific signature algorithm used to generate an ECDSA signature, a virtual private temporary key may be required.

[0125] For example, the token mechanism sub-component may include an OP_PUSH_TX pseudo-opcode implementation configured to perform the verification on the generated preimage.

[0126] In some embodiments, the token mechanism sub-component may be configured to: verify that the corresponding payment address included in the corresponding locking script of the spending transaction is of the same type as the first payment address included in the variable component of the first token output.

[0127] In addition, the token mechanism subcomponent can be configured to verify that one or more outputs of the spending transaction include a corresponding payment script template of the same type as the payment script template contained in the first token output, such as a P2PKH locking script.

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

[0129] In some embodiments, the first token quantity may include a single unit of the underlying digital asset.

[0130] In some embodiments, the first token quantity may include multiple units of the underlying digital asset.

[0131] In some embodiments, the constant component may include a data sub-component, wherein the data sub-component includes one or both of the following: a token protocol identifier; an identifier for a token issuance transaction, wherein the token issuance transaction includes one or both of the following: i) an issuance contract between a token issuer and an initial token recipient, ii) an initial number of tokens.

[0132] Constant, immutable data subcomponents can be placed after the OP_RETURN opcode.

[0133] In some embodiments, the spending transaction may include a third output, which includes a third locking script and a corresponding third quantity, wherein the token mechanism subcomponent is configured to verify that the third locking script includes a corresponding payment address and its corresponding quantity in a predetermined payment type template. For example, a PKH address in a P2PKH payment template.

[0134] In some embodiments, the first token transaction may include a first token input that spends a corresponding token output of a previous token transaction, wherein the first token input includes: all the contents of the first token transaction except itself, and a corresponding value and a corresponding locking script of the output of the previous token transaction being spent; and at least one or more data pairs, each data pair including at least a payment address included in the corresponding locking script of the first token transaction and a corresponding quantity of the underlying digital asset locked by the corresponding locking script.

[0135] In some embodiments, the first token transaction may include a second token output, wherein the second token output includes a second token locking script and a second token quantity, wherein the second token locking script includes a corresponding variable component and a corresponding constant component, wherein the corresponding variable component includes a second payment address, and wherein the corresponding constant component matches the constant component of the first token locking script.

[0136] In some embodiments, the first token transaction may include a third output, wherein the third output includes a third payment address.

[0137] In some embodiments, the first token input may include a first signature generated by a first party, wherein the first token transaction includes a second input, the second input including a second signature generated by a second party, wherein the first token transaction includes a payment output, the payment output including a payment address included in a payment template, wherein the payment address is linked to the first party.

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

[0139] According to one aspect disclosed herein, a computer-implemented method for sending digital tokens using blockchain transactions is provided, wherein each token is represented by one or more units of an underlying digital asset in the native units of the blockchain, wherein the method includes: generating a first token transaction; and transmitting the first token transaction to a blockchain network; wherein the first token transaction includes a first token output, the first token output controlling a first quantity of the digital asset, the first token output including a constant component containing a token mechanism script configured to, when executed together with inputs of a spending transaction including one or more outputs, each output including a corresponding payment address and controlling a corresponding quantity of the digital asset: extracting each payment address and corresponding quantity from the inputs of the spending transaction; verifying that each output of the spending transaction includes the constant component or includes a predetermined redemption address; verifying that the sum of the corresponding quantities equals the first quantity of the digital asset; and, if any verification step fails, execution fails.

[0140] In some embodiments, the first token output further includes a variable component, wherein the variable component includes a first payment address.

[0141] In some embodiments, the first payment address is a payment to a public key hash (P2PKH) address.

[0142] In some embodiments, the token mechanism script is configured as follows: Verify that each payment address contained in the corresponding output of the spending transaction is of the same type as the first payment address contained in the variable component of the first token output.

[0143] In some embodiments, the input to the spending transaction includes a sighash preimage, and the token mechanism script is configured to extract the first amount of the digital asset from the sighash preimage.

[0144] In some embodiments, the sighash preimage includes a concatenated hash of one or more data pairs, each data pair including a corresponding payment address from a corresponding output of the spending transaction and a corresponding quantity locked by the corresponding output, and wherein the token mechanism script is configured to: extract the concatenated hash of the one or more data pairs from the preimage; generate a hash based on the one or more data pairs extracted from the input; and verify that the generated hash is equal to the extracted hash.

[0145] In some embodiments, the one or more data pairs used to generate the hash are either obtained from the input or constructed by obtaining the payment address and quantity of the first token output from the preimage.

[0146] In some embodiments, the token mechanism script is configured to: generate a preimage of the spending transaction; and verify that the generated preimage is equal to the sighash preimage contained in the input of the spending transaction.

[0147] In some embodiments, the input of the spending transaction includes a virtual private key and a corresponding virtual public key, and the token mechanism script is configured to verify that the generated preimage is equal to the preimage contained in the input by generating a digital signature using the hash of the virtual private key and the preimage contained in the input; and verifying that the digital signature is a valid signature when verifying the hash of the virtual public key and the generated preimage.

[0148] In some embodiments, the constant component includes the predetermined redemption address.

[0149] In some embodiments, the constant component includes a data subcomponent, and the data subcomponent includes one or both of the following: a token protocol identifier; and an identifier for a token issuance transaction. The token issuance transaction includes one or both of the following: i) an issuance contract between the token issuer and the initial token recipient, and ii) an initial number of tokens.

[0150] In some embodiments, the first quantity of the digital assets includes a single unit of the underlying digital asset.

[0151] In some embodiments, the first quantity of the digital asset includes multiple units of the underlying digital asset.

[0152] In some embodiments, the spending transaction includes a first output and a second output, and wherein the token mechanism script is configured to verify that the sum of the quantities controlled by the first output and the second output equals the first quantity of the digital asset.

[0153] In some embodiments, the spending transaction includes an additional output that does not contain the constant component or the predetermined redemption address, and wherein the token mechanism script is configured to verify that the additional output includes a payment address in a predetermined payment template.

[0154] In some embodiments, the first token transaction includes a first token input that spends a corresponding token output of a previous token transaction, and wherein the first token input includes: a plurality of fields of the first token transaction, a corresponding amount of the previous token transaction output being spent, and a corresponding locking script; and one or more data pairs, each data pair including a payment address contained in the corresponding output of the first token transaction and a corresponding amount of the digital asset locked by the corresponding output.

[0155] In some embodiments, the first token input includes a first signature generated by a first party, wherein the first token transaction includes a second input, the second input including a second signature generated by a second party, and wherein the first token transaction includes a payment output, the payment output including a payment address linked to the first party.

[0156] In some embodiments, the token mechanism script is configured to: if the first output of the spending transaction does not include the predetermined redemption address, verify that the first output includes the same constant component as the constant component of the first token output of the previous transaction being spent; and / or, if the second output of the spending transaction exists, verify that the second output includes the same constant component as the constant component of the first token output of the previous transaction being spent.

[0157] According to one aspect disclosed herein, a computer-implemented method for sending digital tokens using blockchain transactions is provided, wherein each token is represented by one or more units of an underlying digital asset in native units of the blockchain, wherein the method includes: generating a first token transaction; and transmitting the first token transaction to a blockchain network; wherein the first token transaction includes a first token output, the first token output including a first token locking script and a first token quantity, wherein the first token locking script includes a constant component, wherein the constant component includes a token mechanism subcomponent, and wherein, when executed together with an input script for a spending transaction, the input script includes multiple fields of the spending transaction, and a quantity locked in a previous transaction output being spent, and a corresponding locking script, wherein the token mechanism subcomponent is configured to: from the The input script of the spending transaction obtains one or more data pairs, each data pair including i) at least a corresponding payment address included in the corresponding locking script of the output of the spending transaction, and ii) a corresponding quantity of the underlying digital assets locked by the corresponding locking script of the output; verifies that one or more outputs of the spending transaction include a corresponding locking script, the locking script including a) a predetermined payment address, or b) the constant component; and, for one or more outputs of the spending transaction, verifies that the total amount of the underlying digital assets locked by the corresponding locking script of the one or more outputs is equal to the first token quantity; and wherein the token mechanism sub-component is configured to become invalid during execution if any verification step fails.

[0158] In some embodiments, the spending transaction includes a first output containing a first locking script and a second output containing a second locking script, wherein the token mechanism sub-component is configured to: verify that the first output of the spending transaction includes the first locking script, the first locking script including: a) a predetermined payment address, or b) the constant component; if the second output of the spending transaction exists, verify that the second output of the spending transaction includes the second locking script, the second locking script including: a) a predetermined payment address, or b) the constant component; and if the second output exists, verify that 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 first token quantity.

[0159] In some embodiments, the token mechanism component is configured to: if the first locking script of the spending transaction does not include a predetermined payment address, verify that the first locking script includes the same constant component as the corresponding constant component of the first token locking script of the previous transaction being spent; and / or, if the second locking script of the spending transaction exists, verify that the second locking script includes the same constant component as the corresponding constant component of the first token locking script of the previous transaction being spent.

[0160] In some embodiments, the constant component includes the predetermined payment address.

[0161] In some embodiments, the input script for the spending transaction includes a sighash preimage, wherein the preimage includes the first token locking script and the first token quantity, wherein the token mechanism subcomponent is configured to: extract the first token quantity and the first token locking script of the output being spent from the preimage to perform the verification step.

[0162] In some embodiments, the preimage includes a concatenated hash of one or more data pairs, each data pair including a corresponding payment address from a corresponding locking script of the spending transaction and a corresponding quantity locked by the corresponding locking script, wherein the token mechanism subcomponent is configured to: extract the concatenated hash of one or more data pairs from the preimage; generate a hash based on the one or more data pairs; and verify that the generated hash is equal to the extracted hash.

[0163] In some embodiments, the one or more data pairs used to generate the hash are either obtained from the input script or constructed by obtaining the input address and quantity pairs of the previous output locking script from the preimage.

[0164] In some embodiments, the token mechanism subcomponent is configured to: generate a preimage of the spending transaction data; and verify that the generated preimage of the spending transaction data is equal to the preimage contained in the input of the spending transaction.

[0165] In some embodiments, the input of the spending transaction includes a virtual private key and a corresponding virtual public key, wherein the token mechanism subcomponent is configured to: verify that the preimage generated by the spending transaction is equal to the preimage contained in the input of the spending transaction by generating a digital signature using the virtual private key and the hash of the preimage contained in the input of the spending transaction; and verifying that the digital signature is a valid signature when verifying the hash of the virtual public key and the preimage generated by the spending transaction.

[0166] In some embodiments, the token mechanism sub-component is configured to verify that the corresponding payment address included in the corresponding locking script of the spending transaction is of the same type as the first payment address included in the variable component of the first token output.

[0167] In some embodiments, the first payment address is a public key hash address.

[0168] In some embodiments, the first token quantity comprises a single unit of the underlying digital asset.

[0169] In some embodiments, the constant component includes a data subcomponent, wherein the data subcomponent includes one or both of the following: a token protocol identifier; and an identifier for a token issuance transaction. The token issuance transaction includes one or both of the following: i) an issuance contract between the token issuer and the initial token recipient, and ii) an initial number of tokens.

[0170] In some embodiments, the spending transaction includes a third output, which includes a third locking script and a corresponding third quantity, wherein the token mechanism subcomponent is configured to verify that the third locking script includes a corresponding payment address and its corresponding quantity.

[0171] In some embodiments, the first token transaction includes a first token input that spends a corresponding token output of a previous token transaction, wherein the first token input includes: a plurality of fields of the first token transaction, a corresponding quantity of the output of the previous token transaction being spent, and a corresponding locking script; and at least one or more data pairs, each data pair including at least a payment address included in the corresponding locking script of the first token transaction and a corresponding quantity of the underlying digital asset locked by the corresponding locking script.

[0172] In some embodiments, the first token transaction includes a second token output, wherein the second token output includes a second token locking script and a second token quantity, wherein the second token locking script includes a corresponding variable component and a corresponding constant component, wherein the corresponding variable component includes a second payment address, and wherein the corresponding constant component matches the constant component of the first token locking script.

[0173] In some embodiments, the first token input includes a first signature generated by a first party, wherein the first token transaction includes a second input, the second input including a second signature generated by a second party, wherein the first token transaction includes a payment output, the payment output including a payment address, wherein the payment address is linked to the first party.

[0174] According to another aspect disclosed herein, a computer device is provided, comprising: a memory including one or more memory cells; and a processing means including one or more processing units, wherein the memory stores code configured to run on the processing means, the code being configured to execute any of the embodiments described above when run on the processing means.

[0175] According to another aspect disclosed herein, a computer program (computer program product) is provided, which is contained on a computer-readable storage medium and configured to perform any of the embodiments described above when run on a computer device.

[0176] According to another aspect disclosed herein, a token transaction is provided, the token transaction including a first token output, the first token output including a first token locking script and a first token quantity, wherein the first token locking script includes a variable component and a constant component, wherein the variable component includes a first payment address embedded in a payment template, wherein the constant component includes a token mechanism sub-component, and wherein, when executed together with an input script for a spending transaction, the input script includes all of the spending transactions except itself, and corresponding locking scripts and quantities locked in previous transaction outputs being spent, the token mechanism sub-component being configured to: obtain one or more data pairs from the input script of the spending transaction, each data pair including: i) at least one corresponding payment address included in the corresponding locking script of the spending transaction output, and ii) a corresponding quantity of the underlying digital asset locked by the corresponding locking script of the output; verify that one or more outputs of the spending transaction include corresponding locking scripts, the locking scripts including: a) a corresponding payment script template including a predetermined payment address, or b) The corresponding variable component includes a corresponding payment address other than the predetermined payment address, followed by the constant component; and, for one or more outputs of the spending transaction, verifying that the total amount of the underlying digital assets locked by the corresponding locking script of the one or more outputs is equal to the first token quantity; and wherein the token mechanism sub-component is configured to expire during execution if any verification step fails.

[0177] According to another aspect disclosed herein, a computer-readable storage medium is provided on which the aforementioned token transactions are stored.

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

Claims

1. A computer-implemented method for sending digital tokens using blockchain transactions, wherein each token is represented by one or more units of an underlying digital asset in the native units of the blockchain, wherein the method includes: Generate the first token transaction; as well as Transmit the first token transaction to the blockchain network; The first token transaction includes a first token output, which controls a first quantity of the digital asset. The first token output includes a constant component containing a token mechanism script, which is configured such that, when executed with the input of a spending transaction including one or more outputs, each output includes a corresponding payment address and controls a corresponding quantity of the digital asset. Extract each payment address and corresponding amount from the input of the spending transaction; Verify that each output of the spending transaction includes the constant component, or includes the pre-defined redemption address; Verify that the sum of the corresponding quantities equals the first quantity of the digital asset; and If any verification step fails, the execution fails.

2. The method according to claim 1, wherein, The first token output further includes a variable component, wherein the variable component includes a first payment address.

3. The method according to claim 2, wherein, The first payment address is the payment to the public key hash (P2PKH) address.

4. The method according to claim 2, wherein, The token mechanism script is configured as follows: Verify that each payment address included in the corresponding output of the spending transaction is of the same type as the first payment address included in the variable component of the first token output.

5. The method according to claim 1, wherein, The input to the spending transaction includes a sighash preimage, and the token mechanism script is configured to extract the first amount of the digital asset from the sighash preimage.

6. The method according to claim 5, wherein, The sighash preimage comprises a concatenated hash of one or more data pairs, each data pair including a corresponding payment address from a corresponding output of the spending transaction and a corresponding quantity locked by the corresponding output, wherein the token mechanism script is configured as follows: Extract the concatenated hash of the one or more data pairs from the preimage; A hash is generated based on the one or more data pairs extracted from the input; and Verify that the generated hash is equal to the extracted hash.

7. The method according to claim 6, wherein, The one or more data pairs used to generate the hash are either obtained from the input or constructed by obtaining the payment address and quantity of the first token output from the preimage.

8. The method according to claim 5, wherein, The token mechanism script is configured as follows: Generate the preimage of the cost transaction; and Verify that the generated preimage is equal to the sighash preimage contained in the input of the spending transaction.

9. The method according to claim 8, wherein, The input to the spending transaction includes a virtual private key and a corresponding virtual public key, and the token mechanism script is configured to verify that the generated preimage is equal to the preimage contained in the input in the following manner: A digital signature is generated using the virtual private key and the hash of the preimage contained in the input; as well as The digital signature is verified to be a valid signature when the hash of the virtual public key and the generated preimage is verified.

10. The method according to claim 1, wherein, The constant component includes the predetermined redemption address.

11. The method according to claim 1, wherein, The constant component includes a data sub-component, and the data sub-component includes one or both of the following: Token protocol identifier; The identifier of a token issuance transaction, wherein the token issuance transaction includes one or both of the following: i) an issuance contract between a token issuer and an initial token recipient, and ii) an initial number of tokens.

12. The method according to claim 1, wherein, The first quantity of the digital assets includes a single unit of the underlying digital asset.

13. The method according to claim 1, wherein, The first quantity of the digital assets includes multiple units of the underlying digital assets.

14. The method according to claim 1, wherein, The spending transaction includes a first output and a second output, wherein the token mechanism script is configured to verify that the sum of the quantities controlled by the first output and the second output equals the first quantity of the digital asset.

15. The method according to claim 1, wherein, The spending transaction includes an additional output that does not contain the constant component or the predetermined redemption address, and wherein the token mechanism script is configured to verify that the additional output includes a payment address in a predetermined payment template.

16. The method according to claim 1, wherein, The first token transaction includes a first token input, which consumes the corresponding token output of a previous token transaction, and wherein the first token input includes: The first token transaction's multiple fields, and the corresponding amount and corresponding locking script of the previous token transaction output being spent; and One or more data pairs, each data pair including a payment address contained in the corresponding output of the first token transaction and a corresponding quantity of the digital assets locked by the corresponding output.

17. The method according to claim 16, wherein, The first token input includes a first signature generated by a first party, wherein the first token transaction includes a second input, the second input including a second signature generated by a second party, and wherein the first token transaction includes a payment output, the payment output including a payment address linked to the first party.

18. The method according to claim 1, wherein, The token mechanism script is configured as follows: If the first output of the spending transaction does not include the predetermined redemption address, then verify that the first output includes the same constant component as the constant component of the first token output of the previous transaction that is being spent; and / or If a second output of the spending transaction exists, verify that the second output includes the same constant components as the constant components of the first token output of the previous transaction that is being spent.

19. A computer device, comprising: The memory includes one or more memory units; as well as A processing apparatus comprising one or more processing units, wherein the memory stores code configured to run on the processing apparatus, the code being configured to execute the method according to any one of claims 1 to 18 when run on the processing apparatus.

20. A computer program contained on a computer-readable storage medium and configured to perform the method according to any one of claims 1 to 18 when run on a computer device.

21. A computer-implemented method for sending digital tokens using blockchain transactions, wherein each token is represented by one or more units of an underlying digital asset in the native units of the blockchain, wherein the method includes: Generate the first token transaction; as well as Transmit the first token transaction to the blockchain network; The first token transaction includes a first token output, which includes a first token locking script and a first token quantity. The first token locking script includes a constant component, which includes a token mechanism sub-component. When executed with the input script of a spending transaction, the input script includes multiple fields of the spending transaction, the quantity locked in the output of the previous transaction being spent, and a corresponding locking script. The token mechanism sub-component is configured to: One or more data pairs are obtained from the input script of the spending transaction, each data pair including i) at least a corresponding payment address included in the corresponding locking script of the output of the spending transaction, and ii) a corresponding quantity of the underlying digital asset locked by the corresponding locking script of the output; Verifying one or more outputs of the spending transaction includes a corresponding locking script, the locking script including a) a predetermined payment address, or b) the constant component; and For one or more outputs of the spending transaction, verify that the total amount of the underlying digital assets locked by the corresponding locking script of the one or more outputs is equal to the number of the first tokens; and, The token mechanism sub-component is configured to expire during execution if any verification step fails.

22. The method of claim 21, wherein the spending transaction includes a first output containing a first locking script and a second output containing a second locking script, wherein the token mechanism sub-component is configured to: The first output of verifying the spending transaction includes a first locking script, which includes: a) the pre-defined payment address, or b) the constant component; If the second output of the spending transaction exists, verify that the second output of the spending transaction includes a second locking script, the second locking script including: a) a predetermined payment address, or b) the constant component; as well as If the second output exists, then verify that 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 first token quantity.

23. The method of claim 22, wherein the token mechanism component is configured to: If the first locking script of the spending transaction does not include a predetermined payment address, then verify that the first locking script includes the same constant component as the corresponding constant component of the first token locking script of the previous transaction being spent; and / or If the second locking script for the spending transaction exists, then verify that the second locking script includes the same constant component as the corresponding constant component of the first token locking script of the previous transaction being spent.

24. The method of claim 21, wherein the constant component includes the predetermined payment address.

25. The method of claim 21, wherein the input script for the spending transaction includes a sighash preimage, wherein the preimage includes the first token locking script and the first token quantity, wherein the token mechanism subcomponent is configured to: Extract the first token quantity of the output being spent and the first token locking script from the preimage to perform the verification step.

26. The method of claim 25, wherein the preimage comprises a concatenated hash of one or more data pairs, each data pair comprising a corresponding payment address from a corresponding locking script of the spending transaction and a corresponding quantity locked by the corresponding locking script, wherein the token mechanism subcomponent is configured to: Extract the hash of the concatenation of one or more data pairs from the preimage; Generate a hash based on the one or more data pairs; as well as Verify that the generated hash is equal to the extracted hash.

27. The method of claim 26, wherein the one or more data pairs used to generate the hash are either obtained from the input script or constructed by obtaining the input address and quantity pairs of a previous output locking script from the preimage.

28. The method of claim 25, wherein the token mechanism sub-component is configured to: Generate the preimage of the cost transaction data; and Verify that the preimage generated from the cost transaction data is equal to the preimage contained in the input of the cost transaction.

29. The method of claim 28, wherein the input of the spending transaction includes a virtual private key and a corresponding virtual public key, wherein the token mechanism sub-component is configured to: The preimage generated by the cost transaction is verified to be equal to the preimage contained in the input of the cost transaction in the following manner: A digital signature is generated using the virtual private key and the hash of the preimage contained in the input of the spending transaction; and The digital signature is verified to be a valid signature when the hash of the generated preimage for the virtual public key and the spending transaction is verified.

30. The method of claim 21, wherein the token mechanism sub-component is configured to: Verify that the corresponding payment address included in the corresponding locking script of the spending transaction is of the same type as the first payment address included in the variable component of the first token output.

31. The method of claim 21, wherein the type of the first payment address is a public key hash address.

32. The method of claim 21, wherein the first token quantity comprises a single unit of the underlying digital asset.

33. The method of claim 21, wherein the constant component comprises a data sub-component, wherein the data sub-component comprises one or both of the following: Token protocol identifier; The identifier of a token issuance transaction, wherein the token issuance transaction includes one or both of the following: i) an issuance contract between a token issuer and an initial token recipient, and ii) an initial number of tokens.

34. The method of claim 22, wherein the spending transaction includes a third output, the third output including a third locking script and a corresponding third quantity, wherein the token mechanism sub-component is configured to: The verification of the third locking script includes the corresponding payment address and its corresponding quantity.

35. The method of claim 21, wherein the first token transaction includes a first token input, the first token input spending a corresponding token output of a previous token transaction, wherein the first token input includes: The first token transaction has multiple fields, as well as the corresponding amount and corresponding locking script output by the previous token transaction that is being spent; as well as At least one or more data pairs, each data pair including at least the payment address included in the corresponding locking script of the first token transaction and the corresponding quantity of the underlying digital assets locked by the corresponding locking script.

36. The method of claim 35, wherein the first token transaction includes a second token output, wherein the second token output includes a second token locking script and a second token quantity, wherein the second token locking script includes a corresponding variable component and a corresponding constant component, wherein the corresponding variable component includes a second payment address, and wherein the corresponding constant component matches the constant component of the first token locking script.

37. The method of claim 35, wherein the first token input includes a first signature generated by a first party, wherein the first token transaction includes a second input, the second input including a second signature generated by a second party, wherein the first token transaction includes a payment output, the payment output including a payment address, wherein the payment address is linked to the first party.

38. A computer device, comprising: The memory includes one or more memory units; as well as A processing apparatus comprising one or more processing units, wherein the memory stores code configured to run on the processing apparatus, the code being configured to execute the method according to any one of claims 21 to 37 when run on the processing apparatus.

39. A computer program contained on a computer-readable storage medium and configured to perform the method according to any one of claims 21 to 37 when run on a computer device.

Images