Atomic Swap Token Trading

Abstract

A computer-implemented method for transferring tokens using a blockchain, comprising: generating a transaction comprising an input, an output locked to a public key of a receiving party, and an output locked to a public key of a sending party, the input referencing an output of an issuance transaction or an output of a transaction that forms part of a chain of one or more transactions that link to the issuance transaction; sending the transaction to the receiving party; receiving a funded transaction from the receiving party; verifying that the output locked to the public key of the sending party locks a predetermined amount of digital assets, and if so, generating a signed transaction by including a signature among the inputs of the funded transaction, where the signature corresponds to a first public key of the sending party; and sending the signed transaction to a blockchain network.

Description

[Technical Field]

[0001] The present disclosure relates to methods for sending and receiving (i.e., transacting) tokens using a blockchain. [Background technology]

[0002] A blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained and publicly published at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network"). A blockchain comprises a chain of blocks of data, each block comprising one or more transactions. Each transaction, other than so-called "coinbase transactions," points backward to a preceding transaction in a sequence that may span one or more blocks, leading back to one or more coinbase transactions. Coinbase transactions are further described below. Transactions submitted to a blockchain network are included in new blocks. New blocks are often created by a process called "mining," which involves multiple nodes each competing to perform a solution to a cryptographic puzzle based on a "proof of work," i.e., a representation of a defined set of ordered and validated pending transactions awaiting inclusion in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of blocks may be achieved through the mere publication of block headers.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: carrying digital assets (i.e., several digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchains may also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for the storage of additional user data or indexes to data within transactions. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, and therefore, increasingly more complex data can be incorporated. For example, this may be used to store electronic documents, or audio or video data, within the blockchain.

[0004] Nodes in the blockchain network (often called "miners") perform a distributed transaction registration and validation process, described in more detail below. Briefly, during this process, nodes validate transactions and insert them into block templates, from which they attempt to identify valid proof-of-work solutions. Once a valid solution is found, a new block is propagated to other nodes in the network, thus allowing each node to record a new block on the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network to be propagated. Nodes receiving the transaction may compete to find a proof-of-work solution that incorporates the validated transaction into a new block. Each node is configured to execute the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or incorporated into blocks. Assuming the transaction is validated and thereby accepted on the blockchain, the transaction (including any user data) then remains registered and indexed as such at each of the nodes in the blockchain network as an immutable public record.

[0005] The node that successfully solves the proof-of-work puzzle and creates the latest block is typically awarded a new transaction, called a "coinbase transaction," that distributes a certain amount of digital assets, i.e., some number of tokens. Detection and rejection of invalid transactions is enforced by the actions of competing nodes, which act as agents of the network and are encouraged to report and block fraudulent activity. Widespread publication of information allows users to continuously audit node behavior. The mere publication of block headers allows participants to guarantee the continued validity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any consumable output comprises an element specifying an amount of a digital asset derivable from an evolving series of transactions. A consumable output is sometimes called a UTXO (“unspent transaction output”). The output may further comprise a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that specifies the conditions necessary to activate and transfer a digital token or digital asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such output in a preceding transaction and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, a pair of transactions is considered, referred to as a first transaction and a second transaction (or “target” transaction). The first transaction comprises at least one output that specifies an amount of a digital asset and comprises a locking script that specifies one or more conditions for unlocking the output. The second target transaction comprises at least one input comprising a pointer to the output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of one or more conditions specified in the locking script of the first transaction. Another criterion is that the output of the first transaction has not already been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will neither propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in the new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction specifies the amount to be transferred by reference to absolute account balances rather than by referencing backwards the UTXO of a preceding transaction in a sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes separate from the blockchain. [Prior art documents] [Patent documents]

[0009] [Patent Document 1] UK Patent Application No. GB2112930.9 [Patent Document 2] UK Patent Application No. GB2206039.6 Summary of the Invention [Problem to be solved by the invention]

[0010]

[0003] Several token protocols of varying complexity exist on blockchains, whereby tokens are transferred from one party to another using blockchain transactions. Most token protocols are not interactive when trading tokens. Thus, situations may arise where one party can transfer tokens to another party without receiving compensation in return, or at least without receiving compensation simultaneously with transferring the tokens. Similarly, a party may transfer assets to a token holder but not receive tokens in return, or at least not simultaneously with transferring the tokens. The present application aims to solve these problems. [Means for solving the problem]

[0011] According to one aspect disclosed herein, there is provided a computer-implemented method for transferring tokens using a blockchain, the blockchain comprising a token issuance transaction, the token issuance transaction comprising token data and an output locked to a public key issuing party, the method being executed by a sending party to generate a first transaction, the first transaction comprising: i) a first input that references an output of the token issuance transaction or an output of a previous transaction that forms part of a chain of one or more previous transactions linking to the token issuance transaction, the referenced output being locked to a first public key of the sending party; ii) a first output locked to a public key of a receiving party, the first output comprising the token data; and iii) a second output locked to the public key of the sending party; and sending the first transaction to a receiving party, the receiving party receiving the first input that references the output of the token issuance transaction or an output of a previous transaction that forms part of a chain of one or more previous transactions linking to the token issuance transaction. the first output references an output of a previous transaction that forms part of a chain of one or more previous transactions that reference the one or more respective outputs of the one or more respective funding transactions; verifying that the first output is locked to the public key of the receiving party, and if so, generating a funded first transaction by including one or more respective inputs in the first transaction that reference the one or more respective outputs of the one or more respective funding transactions, wherein the one or more respective outputs are locked to the one or more respective public keys of the receiving party; receiving the funded first transaction from the receiving party; verifying that the second output locked to the public key of the sending party locks a predetermined amount of digital assets, and if so, generating a signed first transaction by including a signature in the first input of the funded first transaction, wherein the signature corresponds to the first public key of the sending party;and transmitting the signed first transaction.

[0012] According to another aspect disclosed herein, there is provided a computer-implemented method for accepting transferred tokens using a blockchain, the blockchain comprising a token issuance transaction, the token issuance transaction comprising token data and an output locked to a public key issuing party, the method being executed by a receiving party, the method comprising: receiving a first transaction from a sending party; verifying that the first transaction comprises a first input that references an output of the token issuance transaction or an output of a previous transaction that forms part of a chain of one or more previous transactions linking to the token issuance transaction, wherein the referenced output is locked to a first public key of the sending party; and verifying that the first output of the first transaction is locked to the public key of the receiving party; and including one or more respective inputs in the first transaction that reference one or more respective outputs of one or more respective funding transactions. generating a funded first transaction by using a cryptographic algorithm based on a cryptographic algorithm, wherein one or more respective outputs are locked to one or more respective public keys of a receiving party, the funded first transaction comprising a second output locked to the public key of the receiving party, the second output comprising token data; and transmitting the funded first transaction to a sending party, wherein the sending party is configured to verify that the one or more respective funded transactions are on the blockchain and that the second output of the funded first transaction is locked to the public key of the sending party locking a predetermined amount of digital assets, and if so, generate a signed first transaction by including a signature in a first input of the funded first transaction, the signature corresponding to the first public key of the sending party, and transmit the signed first transaction to one or more nodes of the blockchain network and / or the receiving party.

[0013] Embodiments of the present disclosure provide an interactive process for transferring (i.e., transacting) tokens using blockchain. A transaction involves interaction between both parties, i.e., the sender and the receiver. A transaction can occur only when both parties perform several actions and checks. This makes the transaction atomic, which in this context creates a fully fair transaction. The sending party sends a token transaction ("first transaction") to the receiving party token. At this point, the token transaction is incomplete. The receiving party performs one or more checks (i.e., validations) and, if they pass, funds the token transaction ("funded first transaction") and returns the funded transaction back to the sending party. The sending party performs one or more checks on the funded transaction and, if they pass, signs the token transaction ("signed first transaction"). The signed transaction is then sent to the blockchain network. Once sent to the network, the receiving party receives the token (because the token transaction includes an output locked to the receiving party and containing the token data), and the sending party is paid for the transfer (because the token transaction includes an output locked to the sending party).

[0014] It is commonly known that conditions may be enforced on fields of a consuming transaction, i.e., a transaction that consumes (unlocks, allocates, transfers, etc.) the output of a previous transaction. For example, the previous transaction may include a locking script that imposes a condition on one or more outputs of the consuming transaction. Note that the term "consuming transaction" is used in the art to mean a current transaction that unlocks at least one output of at least one previous transaction, and does not necessarily mean that the current transaction involves a monetary transaction.

[0015] One reason for wanting to enforce conditions on fields of a consuming transaction is to ensure that a consuming transaction has an output that contains the same locking script as the previous transaction. That way, a consuming transaction can ensure that the next consuming transaction enforces the same condition. That is, the n-1th transaction contains a locking script that forces the nth transaction to contain the same locking script, which in turn forces the n+1th transaction to contain the same locking script. In this way, a chain of transactions is created, whereby each transaction contains the same locking script. This may be used, for example, in the context of digital tokens that represent ownership of objects in the real world as well as virtual worlds. This is advantageous because it means that each transfer of the token is subject to the same rules.

[0016] Previous attempts at forcing a chain of transactions to contain the same locking script suffer from at least one of the following problems. First, some attempts require a verifier to trace back to the first transaction in the chain (e.g., an “issuance transaction”) to ensure that the first transaction was created correctly (e.g., by a particular authority such as a token issuer) or that the locking script included in the most recent transaction is the same as the locking script included in the first transaction and every other transaction in the chain. This consumes the verifier's resources (both in terms of computational resources and time and effort) in validating the most recent transaction in the chain. Second, some attempts require a third party to be involved in the creation and / or validation of the next transaction in the chain (e.g., a token transfer) to ensure that the next transaction is created correctly. This undermines the trustless nature of blockchains by relying on third parties and increases the number of parties that must interact with each other, which reduces efficiency. Third, as explained below, some attempts at forcing a chain of transactions to contain the same locking script require that the most recent transaction in the chain contain every previous transaction in the chain, thus introducing the transaction bloat problem. This is problematic for both transmission and storage of transactions. Fourth, some attempts are susceptible to replay attacks.

[0017] Previous attempts to impose conditions on future spend transactions involve injecting spend transactions into the stack of a blockchain scripting engine to convey business logic on transactions being validated by blockchain nodes. One technique for forcing an unlocking script to include such a message is known in the art as PUSHTX, which is a pseudo-opcode, i.e., a combination of opcodes configured to perform a specific function. PUSHTX is described in UK Patent Application No. GB2112930.9.

[0018] The so-called PUSHTX mechanism embeds (i.e., injects) a copy of the sighash field of the consuming transaction into its unlocking script. Leveraging the opcode OP_CHECKSIG, validation logic in the locking script (of the parent transaction) can be developed to ensure that the injected copy corresponds to the consuming transaction. It is also possible to inject the ancestors of the transaction, but this requires embedding all fields of the ancestors (including the unlocking script) in the unlocking script of the consuming transaction. In some cases, this technique may not be appropriate. For example, repeated injection of parent transactions gives a transaction whose size rapidly grows as the unlocking script accumulates all previous transactions.

[0019] The present disclosure provides a mechanism for imposing structure (i.e., conditions, constraints, etc.) on a consuming transaction and / or its ancestors without pushing the consuming transaction onto a stack. This allows conditions to be imposed on some or all token transactions while simultaneously solving the transaction bloat problem. Embodiments of the present disclosure also solve one or more of the other problems previously described.

[0020] A locking script (called an "enforcing locking script") is used to enforce conditions (i.e., constraints, restrictions, etc.) on future transactions, i.e., consuming transactions, that attempt to unlock the output containing the enforcing locking script. A locking script includes at least two subscripts, i.e., portions of the overall locking script. The first portion (called a "commitment subscript" or "concise transaction integrity mechanism") is used to verify that the transaction commitment (i.e., a string) provided in the consuming transaction's unlocking script is the binding commitment of (a sighash serialization of) the consuming transaction. In some examples, the transaction commitment is a hash digest or digital signature generated based on the consuming transaction. The second portion (called a "constraint subscript") is used to verify that the consuming transaction (i.e., the committed transaction) satisfies one or more constraints. This is done without requiring the consuming transaction (or fields of the consuming transaction) to be included in the consuming transaction's unlocking script. In other words, the effect is that a sighash serialization of the consuming transaction does not need to be included in the consuming transaction's unlocking script. Instead, the unlocking script contains that commitment, and its size is short and independent of the transaction size.

[0021] Some embodiments of the present disclosure employ succinct non-interactive zero-knowledge arguments (SNARKs) to prove off-chain that a transaction's structure is constrained according to its business logic. This generates short (concise) proofs that can be embedded as part of an unlocking script and verified on-chain. The constraining subscript portion of the executing locking script (which contains the logic for verifying the proofs) may be large, but it is of constant size and independent of the size of the spend transaction. This, along with short commitments, solves the transaction bloat problem mentioned above. As already explained, these embodiments require more than simply applying a general-purpose SNARK. Direct application would require the validation algorithm to receive the spend transaction being validated as input, thus reintroducing the bloat problem. To overcome this, SNARKs are combined with a succinct transaction integrity mechanism that can be verified on-chain. A specific instantiation of this type of integrity check uses so-called "dummy signatures," as described in UK Patent Application No. GB2206039.6. The resulting mechanism in these embodiments is called REFTX, which stands for "reference transaction."

[0022] REFTX (in contrast to PUSHTX) is not limited by the expressive power of blockchain scripting languages ​​for imposing structure on spend transactions or their ancestors. In fact, REFTX operates largely off-chain. Furthermore, REFTX (due to its use of general-purpose SNARKs) allows for the enforcement of a rich class of constraints. The only requirement is that such constraints can be expressed as a program that can be verified by a SNARK. This covers almost any feasible computation that can be thought of.

[0023] The REFTX mechanism may be used to implement a non-fungible token (NFT) scheme whereby the transfer of ownership of a tokenized asset is governed by locking. Ownership transfer is controlled by an NFT program that imposes constraints on previous transactions to ensure that spend transactions can be traced back to an issuance or mint transaction involving the token.

[0024] To assist in understanding embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Brief explanation of the drawings]

[0025] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded in a blockchain. [Figure 3] FIG. 1 illustrates a schematic diagram of an exemplary system for enforcing conditions on blockchain transactions. [Figure 4] FIG. 1 illustrates a schematic diagram of an example in which a first transaction enforces a condition on a second transaction. [Figure 5] FIG. 1 illustrates generally some exemplary transactions for issuing and minting blockchain-based tokens. [Figure 6] FIG. 10 is a schematic diagram illustrating two funding transactions and some example transactions for trading tokens, where PK1, PK2 are controlled by the receiver, PK3 is controlled by the sender, and f indicates the fee to the miner. [Figure 7] FIG. 10 is a schematic diagram illustrating some exemplary transactions for trading tokens with a fee of 1% of the transaction. [Figure 8]FIG. 10 illustrates schematically some example transactions for minting two replica tokens, where the root of the token hash tree is hard-coded in the token program that enables the transfer. [Figure 9] FIG. 2 is a schematic diagram of an exemplary hash tree for encoding different versions of a replica token. [Figure 10] FIG. 10 illustrates schematically several example transactions for trading unburnable tokens, where a unique funding UTXO txid′||0 is unlocked using the same public key to which the tokens are sent. DETAILED DESCRIPTION OF THE INVENTION

[0026] 1. Example System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, i.e., typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104 that may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0027] Each blockchain node 104 comprises a peer computing device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises one or more processors, e.g., processing devices comprising one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs), as well as other devices such as application-specific integrated circuits (ASICs). Each node also comprises memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0028] A blockchain 150 comprises a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in a distributed network or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may be a pruned version of the data, so long as each blockchain node 150 stores the block header (described below) for each block 151. Each block 151 in the chain comprises one or more transactions 152, with a transaction in this context referring to a type of data structure. The nature of that data structure depends on the type of transaction protocol used as part of the transaction model or methodology. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 comprises at least one input and at least one output. Each output specifies as a property an amount representing a quantity of a digital asset, one example of a property being the user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or spent). Each input points backward to the output of a preceding transaction 152, thereby linking the transactions.

[0029] Each block 151 also has a block pointer 155 that points back to previously created blocks 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than coinbase transactions) has a pointer back to an earlier transaction to define an order for the series of transactions (note that the series of transactions 152 is allowed to diverge). The chain of blocks 151 goes all the way back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 early in the chain 150 pointed to the genesis block 153 rather than to a preceding transaction.

[0030] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and that the node 104 is obligated not to accept any other transactions attempting to consume the same output.

[0031] For a given current transaction 152j, the (or each) input comprises a pointer to the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming does not necessarily imply a transfer of financial assets, although that is certainly one common application. More generally, consuming can be described as consuming an output, i.e., allocating it to one or more outputs in another transaction onward. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. The previous transaction 152i does not necessarily need to exist at the time the current transaction 152j is created and even transmitted to the network 106, but the previous transaction 152i must exist and be valid for the current transaction to be valid. Thus, "preceding" herein refers to a predecessor in a logical sequence linked by a pointer, not necessarily to a time of creation or transmission in a temporal sequence, and therefore does not necessarily preclude a transaction 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A predecessor transaction 152i may equally be referred to as an antecedent transaction or a predecessor transaction.

[0032] The input of the current transaction 152j also comprises an input authorization, e.g., the signature of the user 103a to whom the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j can transfer the amount specified in the input of the preceding transaction 152i to the new user or entity 103b as specified in the output of the current transaction 152j. In some cases, a transaction 152j may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a for providing change). In some cases, a transaction may also have multiple inputs to aggregate the amount from multiple outputs of one or more preceding transactions and redistribute it among one or more outputs of the current transaction.

[0033] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to institute a new transaction 152j (either manually or through an automated process employed by the party), the instituting party transmits the new transaction from its computer terminal 102 to a recipient. The instituting party or recipient ultimately transmits this transaction to one or more of the blockchain nodes 104 (which today are typically servers or data centers, but could in principle be other user terminals) of the network 106. It is not excluded that the party 103 instituting the new transaction 152j may, in some instances, transmit the transaction directly to one or more of the blockchain nodes 104 rather than to the recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to the blockchain node protocol applied at each of the blockchain nodes 104. Blockchain node protocols typically require a blockchain node 104 to check that a cryptographic signature in a new transaction 152j matches an expected signature that depends on a previous transaction 152i in an ordered sequence of transactions 152. In such output-based transaction protocols, this may comprise checking that a cryptographic signature or other authorization of a party 103 included in the input of the new transaction 152j matches a condition specified in the output of a previous transaction 152i that the new transaction consumes (or “allocates”), which condition typically comprises at least checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the new transaction's input is linked. The condition may be specified at least in part by a script included in the output of the previous transaction 152i.Alternatively, it may simply be fixed by the blockchain node protocol alone, or may result from a combination of these. Either way, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol, and so forward the new transaction 152j onto one or more additional nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0034] In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is whether it has yet been validly redeemed by the input of another transaction 152j forward according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not already been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless flagged as invalid and propagated to warn) or recorded in the blockchain 150. This protects against double spend, whereby a transactor attempts to allocate the same transaction output more than once. On the other hand, the account-based model protects against double spend by maintaining an account balance. Again, because there is a defined order of transactions, the account balance always has a defined single state.

[0035] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions, in a process supported by "proof of work," commonly referred to as mining. At the blockchain nodes 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that, when the nonce is concatenated with a representation of the ordered pool 154 of pending transactions and hashed, the output of the hash satisfies a predetermined condition. For example, the predetermined condition might be that the output of the hash has some predetermined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle; other types are not excluded. A property of a hash function is that the hash has an output that is unpredictable given its input. Therefore, this search can only be performed by brute force, and therefore consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0036] The first blockchain node 104 to solve the puzzle announces this to the network 106 and provides the solution as a proof, which can then be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to check that the solution satisfies the conditions on the hash output). The first blockchain node 104 accepts the block and therefore propagates it to threshold consensus of other nodes enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. A block pointer 155, which points back in the chain to the previously created block 151n-1, is also assigned to the new block 151n. The significant amount of effort required to create the proof-of-work solution, e.g., in the form of a hash, signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously validated transaction, commonly known as double spending. Once created, blocks 151 cannot be modified after they are recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on the blocks 151. This therefore provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106.

[0037] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be doing so based on different snapshots of the pool of unissued transactions 154 at any given time, depending on when they began searching for a solution or the order in which transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unissued transactions 154 is updated. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool of unissued transactions 154, and so on. The protocol also exists to resolve any "forks" that may occur, which are cases where two blockchain nodes 104 solve their puzzles within a very short time of each other, such that conflicting views of the blockchain are propagated between the nodes 104. In essence, whichever prong of the fork grows the longest becomes the final blockchain 150. Note that when the same transaction appears in both forks, this should not affect users or agents of the network.

[0038] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate additional accepted amounts of digital assets in a new special type of transaction that distributes a specified additional quantity of digital assets (as opposed to an agent-to-user transaction that transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is typically called a “coinbase transaction,” but may also be called an “initiation transaction” or “generation transaction.” It typically forms the first transaction of a new block 151n. The proof of work signals the node’s intent to construct the new block to comply with protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generational) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and is explained below.

[0039] Due to the resources involved in transaction validation and publishing, at least each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 may also take the form of a user terminal or a group of user terminals networked together.

[0040] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective one or more roles and to process transactions 152 in accordance with the blockchain node protocol. It will be understood that any actions attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer or in a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0041] Also connected to the network 101 are computing devices 102 of a plurality of parties 103 each acting as a consuming user. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as accumulating entities that accumulate copies of the blockchain 150 (e.g., obtain copies of the blockchain from blockchain nodes 104).

[0042] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on top of the blockchain network 106. Users of the blockchain network (often called “clients”) may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the required roles of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) a blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It is understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0043] The computing equipment 102 of each party 103 comprises a respective processing unit comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing equipment 102 of each party 103 further comprises memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. This memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 configured to execute on the processing unit. It will be understood that any action attributed herein to a given party 103 may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources, that are accessed via the user terminal.

[0044] The client application 105 may be initially provided to the computing equipment 102 of any given party 103 on one or more suitable computer-readable storage media, for example downloaded from a server, or may be provided on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive.

[0045] The client application 105 comprises at least a "wallet" function. It has two main functionalities. One of these is to enable each party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which then propagate throughout the network of blockchain nodes 104 and thereby be included in the blockchain 150. The other is to report back to each party the amount of digital assets that they currently own. In an output-based system, this second functionality comprises reconciling the amounts specified in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0046] Note: While various client functionalities may be described as being integrated within a given client application 105, this is not necessarily limiting; instead, any client functionality described herein may instead be implemented within a set of two or more separate applications that interface via, for example, an API, or one plugged into the other. More generally, client functionality may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described with respect to client application 105, it will be appreciated that this is not limiting.

[0047] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or, in embodiments, to truly inspect other parties' transactions in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions, in part through its public visibility). The wallet function on each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and to forward transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is used with a given node protocol to jointly implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0048] When a given party 103, for example, Alice, wants to submit a new transaction 152j to be included in the blockchain 150, Alice organizes the new transaction according to the relevant transaction protocol (using a wallet function in her client application 105). Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This comprises first checking whether the newly received transaction 152j meets some conditions for being “valid,” examples of which will be described in more detail shortly. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be specified by a combination of the script and the node protocol.

[0049] Provided that the newly received transaction 152j passes the test to be considered valid (i.e., it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this then means that the transaction 152j will soon be propagated throughout the entire network 106, assuming the transaction 152j is valid.

[0050] Once accepted into the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle on the latest version of their respective pool of 154 that includes the new transaction 152. (Recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools 154 of transactions, but whoever gets there first defines the set of transactions that will be included in the latest block 151. Eventually, the blockchain node 104 solves the puzzle for the part of the ordered pool 154 that includes Alice's transaction 152j.) Once proof-of-work has been done for the pool 154 that includes the new transaction 152j, the new transaction 152j immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer back to earlier transactions, so that the order of transactions is also immutably recorded.

[0051] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore may have competing views of which instance is "valid" before an instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it shall accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the instance not published in block 151).

[0052] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol as part of the account-based transaction model. In the account-based case, each transaction specifies the amount to be transferred by reference to an absolute account balance rather than by referencing backward the UTXO of a transaction that precedes it in the sequence of past transactions. The current state of every account is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction account (also called its "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed with a transaction. This data field may point backward to a previous transaction, for example, if the data field contains a previous transaction ID.

[0053] 2. UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not intended to limit all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented in other exemplary blockchain networks.

[0054] In the UTXO-based model, each transaction (“Tx”) 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO) that can be used as a source for the input 202 of another new transaction (if the UTXO has not already been redeemed). A UTXO contains a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO came. The transaction data structure may also comprise a header 201, which may comprise indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0055] For example, Alice 103a wishes to create transaction 152j to transfer a certain amount of digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes a certain amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least some of this to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are arbitrary labels only. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 can point backward to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0056] The preceding transaction Tx0 may already be valid and included in a block 151 of the blockchain 150 at the time Alice creates her new transaction Tx1, or at least by the time she submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and submitted to the network 106 together, or Tx0 may even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of transactions in the sequence, as defined by transaction pointers specified in the transactions (e.g., which transactions point backward to which other transactions). They may be equivalently substituted for “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” or the like. It does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (descendant transaction or “child”) that points to a preceding transaction (ancestor transaction or “parent”) is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, an orphan may be discarded or may be buffered for some time to wait for its parent.

[0057] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script that specifies the condition that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which the locking script is included). That is, the locking script typically specifies an unlocking condition that comprises the condition that the unlocking script in the input of the subsequent transaction comprises the cryptographic signature of the party to which the preceding transaction is locked.

[0058] A locking script (also called scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A locking script specifies what information is needed to consume the transaction output 203, for example, Alice's signature requirements. An unlocking script appears in the transaction's output. An unlocking script (also called scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, it may include Bob's signature. An unlocking script appears in the transaction's input 202.

[0059] So, in the illustrated example, UTXO0 in Tx0's output 203 must contain Alice's signature Sig P for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A Locking script [Checksig P A]. [Checksig P A ] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's transaction ID, TxID0. Tx1's input 202 comprises a pointer that points backward into Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 comprises an index that identifies UTXO0 within Tx0 to distinguish it among any other possible outputs of Tx0. Tx1's input 202 comprises an unlocking script that comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be specified by a locking script, or by a node protocol, or a combination of these.

[0060] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which comprises running the locking script and the unlocking script together to check whether the unlocking script satisfies a condition specified in the locking script (where this condition may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where "||" denotes concatenation, "<...>" denotes location data on the stack, and "[...]" is a function provided by the locking script (a stack-based language in this example). Equivalently, the scripts may be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, the scripts will create a locking script containing Alice's public key P as included in the locking script in the output of Tx0. A , which authenticates that the unlocking script in Tx1's input contains Alice's signature signing the expected portion of the data. The expected portion of the data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (so there is no need to include a separate element in the clear specifying the signed portion of the data, as it is already inherently present).

[0061] The details of authentication via public-private cryptography are well known to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the message in plaintext, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically comprises hashing the message, signing the hash, and tagging this as a signature on the message, thus allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular piece of data or part of a transaction or the like can, in embodiments, mean signing a hash of that piece of data or part of a transaction.

[0062] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (so, in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, so that transaction Tx1 propagates throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as having been spent. Note that Tx1 can only be valid if it consumes unspent transaction outputs 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 is invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 is already spent (i.e., whether it already forms a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a prescribed order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

[0063] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this is another ground for invalidity in most transaction models. Therefore, such a transaction is not propagated or included in block 151.

[0064] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it is not possible to "leave behind" a fraction of the amount specified in the UTXO as spent while another fraction is consumed. However, the amount from a UTXO can be divided among multiple outputs of a subsequent transaction. For example, the amount specified in UTXO0 in Tx0 can be divided among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount specified in UTXO0, she can use the remainder to give herself change in the second output of Tx1 or to make a payment to another party.

[0065] In practice, Alice is also typically required to include a fee for any Bitcoin node 104 that successfully includes her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and, therefore, while technically valid, may not be propagated or included in the blockchain 150 (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not wish to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that issues the transaction. For example, a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated (or consumed) by node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in one of transaction 152's UTXOs 203 itself.

[0066] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 across the blockchain 150. There is no single number stored somewhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to collate together the values ​​of all the various UTXOs locked to each party and that have not yet been spent in another transaction onward. The wallet function can do this by querying a copy of the blockchain 150 as stored in any of the Bitcoin nodes 104.

[0067] Note that script code is often expressed generally (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. As an example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of a locking script, can accumulate data within the transaction, thereby creating a non-consumable output of the transaction that can immutably record the data in the blockchain 150. For example, the data may comprise a document that is desired to be accumulated in the blockchain.

[0068] Typically, the input for a transaction is a public key P AIn embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific portion of the outputs it signs depends on the SIGHASH flag, which is a four-byte code typically included at the end of the signature to select which outputs are signed (and therefore fixed at the time of signing).

[0069] A locking script may be referred to as a "scriptPubKey," typically referring to the fact that the locking script comprises the public key of the party to which the respective transaction is locked. An unlocking script may be referred to as a "scriptSig," typically referring to the fact that the unlocking script provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating the signature. More generally, a scripting language may be used to specify any condition or conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0070] 3. Side Channels As shown in FIG. 1 , the client application on each of Alice's and Bob's computing devices 102 a, 102 b, respectively, may include additional communication functionality. This additional functionality allows Alice 103 a to establish (at the prompting of either the first party or a third party) a separate side channel 107 with Bob 103 b. The side channel 107 allows for the exchange of data separately from the blockchain network. Such communication may be referred to as “off-chain” communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this manner may be referred to as sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0071] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 107 may be established over a variety of networks, such as a local area network, such as a mobile cellular network, or a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. Generally, a side channel 107 as referenced elsewhere herein may comprise any one or more links, via one or more networking technologies or communications media, for exchanging data “off-chain,” i.e., separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Thus, it should be noted that when it is said that Alice and Bob exchange several pieces of information or data, or the like, over the side channel 107, this does not necessarily imply that all these pieces of data must be transmitted over exactly the same links, or even the same type of network.

[0072] 4. SNARK Let P(x;w)=b∈{0,1} be a binary program that takes a bit string x (an instance) as public input and another bit string w (a witness) as private input, and outputs a decision bit b. We say that P executes correctly if b=1.

[0073] A succinct non-interactive argument system of knowledge (SNARK) that pre-processes for the correct execution of a program P is the triplet algorithm SNARK:=(Setup, Prove, Verify) as follows: Setup(λ,P)→(ek,vk): Given a security parameter λ and a description of a program P, output a pair of evaluation and verification keys. Prove(ek,x,w)→π: Given an evaluation key, a public input x, and a secret input w, output a proof π. Verify(vk,x,π)→b∈{accept,reject}: Given a verification key, a public input x, and a proof π, either accept or reject the proof.

[0074] A SNARK is complete if, for any public / secret input pair (x, w) that P accepts, the verifier always accepts the proof π produced by the prover SNARK.prove. A SNARK is sound if, for all public inputs x for which there is no secret input w that P accepts, the verifier rejects with extremely high probability any proof π for x. More formally, for all probabilistic polynomial-time algorithms A (that capture potentially cheating provers),

[0075]

number

[0076] The scheme is sound if it holds. Note that the verification key must be honestly generated using the setup algorithm. In addition, a proof is said to be knowledge-sound if it is possible to efficiently compute (extract) a witness (up to some negligible error - knowledge error) from a valid proof π and the randomness used by a (possibly cheating) prover A to generate π.

[0077] A proof is "short." This means that the proof is logarithmic in the size of the secret input w. More specifically, recall that the proof is poly(λ)polylog(|w|) in size, where λ is the security parameter. In addition to a short proof, a system has succinct verification (sometimes called perfectly succinct) if the verifier running time is "fast." That is, it is logarithmic in both the size of the program P and the size of the secret input w. Thus, if the running time takes poly(λ)polylog((|x| + |w|) steps.

[0078] 4.1 On-chain SNARK Verification Embodiments of the present disclosure may utilize SNARK schemes that can be verified on-chain, i.e., during script execution. For a given SNARK scheme, there exists a script [SNARK Verification] that implements the verifier SNARK.verify. For example, for pairing-based SNARKs, the verifier consists of evaluating a small number of pairings over an elliptic curve. The pairings may be implemented using a set of finite field arithmetic opcodes built into the BSV scripting language. For hash-based SNARKs, the verifier may be implemented primarily using the opcode OP_SHA256.

[0079] In either case, the verification script takes as input the proof π, the public input x, and the verification key vk, and pushes either 1 (accept) or 0 (reject) onto the top of the stack.

[0080] Therefore, if accept←SNARK.verify(vk,x,π), then <π> <x> <vk>Requires [SNARK verification] to push "True" onto the top of the stack; otherwise, it pushes "False" (either 0 or negative 0).

[0081] 5. Succinct Transaction Integrity - STI Mechanism The STI mechanism is a binding commitment of a transaction. The STI mechanism has two algorithms: STI:=(commit, verify). commit(tx) → τ tx ∈{0,1} λ : For an input transaction, a commitment tag τ of size λ is generated. tx Output. verify(tx,τ tx ) → {accept,reject}: For input commitment key, transaction, and tag, either accept or reject.

[0082] The mechanism is complete if accept ← verify(tx, commit(tx)). It is binding if it is infeasible to create two transactions with the same tag. Thus, for any probabilistic algorithm A, the following holds:

[0083]

number

[0084] The STI mechanism checks the integrity of the consuming transaction succinctly, which means that neither the size of the script verifying the integrity of the consuming transaction nor the independent variables of the script depend on the size of the consuming transaction.

[0085] 5.1 On-chain concise verification Embodiments of the present disclosure may utilize STI mechanisms that can be verified on-chain, i.e., during script execution.

[0086] The STI mechanism needs to be simple in the following sense: i. STI.verify(stx,τ tx ) accepts if and only if <τ tx The parent transaction's locking script contains a subroutine called [STI validation] that pushes "true" onto the stack, where stx represents the consuming transaction. ii. The size of [STI verification] is independent of the size of the spending transaction. Specifically, |[STI verification]|∈O(λ), where λ is a security parameter. iii. The size of the tag is independent of the size of the consumption transaction. Specifically, |τ tx |∈O(λ).

[0087] Commitment tag τ tx To verify that ≠ 0, the spend transaction tx cannot be pushed onto the stack, otherwise it would violate either the second or third property above.

[0088] 5.1.2 Exemplary On-Chain STI Mechanism UK Patent Application No. GB2206039.6 describes a "dummy signature mechanism" that involves generating a "dummy" ECDSA signature on the secp256k1 curve with a signing key sk set to 1 and an ephemeral key k, i.e., sk=k=1. The message is hashed before signing, so that when SHA256 is viewed as a random function, it obtains the binding property.

[0089] In this case, the output of STI.commit is the result of the above process, i.e., τ tx ←STI.commit(tx):=ECDSA.sign(sk:=1,k:=1,SHA256(tx)) is set to the signature generated according to

[0090] The corresponding validation script is defined as follows: [STI Validation]:= <g>OP_CHECKSIGVERIFY

[0091] Therefore, <τ tx > [STI verification] validates τ as a valid commitment tag for a spending transaction. tx Either accept the request or reject it and abort any further logic execution.

[0092] Note that what is passed as input to the ECDSA signing algorithm is a SIGHASH serialization of the spent transaction tx. Depending on the SIGHASH byte, some fields of tx will not be signed, and therefore its integrity cannot be guaranteed.

[0093] 6. Enforcement of Constraints This section describes embodiments of the present disclosure that enable constraints to be enforced on consumption transactions. Figure 3 illustrates an example system 300 for implementing these embodiments. The example system 300 includes a first party, a second party, and one or more blockchain nodes 104 of a blockchain network 10. In this example, the first party is shown as Alice 103a and the second party is shown as Bob 103b. It will be appreciated that this is merely for convenience.

[0094] Alice 103a is configured to generate a first transaction, where the first transaction includes a first output comprising a first locking script. The first locking script comprises logic for enforcing a condition on a second transaction generated by Bob 103b, where the second transaction includes a first input comprising a first unlocking script. The first input of the second transaction references the first output of the first transaction. Note that "first," "second," etc. are used merely as labels and do not necessarily mean, for example, that the first output is the initial, logically first, output of the transaction, although this is one possible example.

[0095] The first locking script (also called the executive locking script) comprises a first subscript (also called the commitment subscript) and a second subscript (also called the constraint subscript). The commitment subscript may comprise a commitment key used to verify the transaction commitment. The constraint subscript comprises a verification key used to verify the constraint proof. The transaction commitment and constraint proof are provided in the unlocking script of the second (consuming) transaction, generated by Bob 103b, which is used to unlock the executive locking script. Note that Alice 103a may generate the executive locking script herself or may receive it from a third party.

[0096] The transaction commitment generated by Bob 103b is a commitment to a second transaction. It is generated based on the second transaction. The commitment subscript is configured to verify that the transaction commitment is generated based on the second transaction. In some examples, a commitment key is used to verify the transaction commitment. The commitment key may be a public key, and the transaction commitment may be a digital signature generated using a private key corresponding to the public key. In some examples, the private key is the integer 1. A signature generated using a private key set equal to 1 is referred to herein as a "dummy signature."

[0097] Once the commitment subscript verifies that the transaction commitment is indeed generated based on the second transaction, it may supply the transaction commitment to the constraining subscript, which may then use the transaction commitment as part of its input validation of the constraint proof.

[0098] The constraint proof generated by Bob 103b provides verifiable proof that the second (committed) transaction satisfies one or more constraints. The constraints may be hard-coded by a constraint subscript. The constraint subscript is configured to use a verification key to verify that the constraint proof does prove that the constraints are satisfied. In some examples, the constraints may be hard-coded by public inputs, i.e., inputs that appear in the locking script and are pushed onto the stack during execution. It is not excluded that public inputs may also be included in the unlocking script of the second transaction. In these examples, the constraint subscript may use the public inputs to verify that the constraint proof provides proof that the second transaction satisfies the constraints.

[0099] In some examples, the verification key has a corresponding evaluation key, and Bob 103b uses the evaluation key to generate the constraint proof. In these examples, the constraint subscriber may use the verification key to verify that the constraint proof was generated using the evaluation key. Alice 103a may send the evaluation key to Bob 103b.

[0100] Proofs and proof verification may utilize non-interactive zero-knowledge verification algorithms, also known as SNARKs. Any suitable SNARK may be used. Constrained proofs may be generated using a SNARK proof algorithm. Proofs may be verified using a SNARK verification algorithm. Thus, in these examples, the constrained subscript is configured to implement the SNARK verification algorithm. Bob 103b runs the proof algorithm off-chain, for example, using an evaluation key.

[0101] In general, the constraints enforced by the execution locking script may impose limits on one or more inputs of the second transaction and / or one or more outputs of the second transaction, which may include imposing limits on the number of inputs and / or outputs, the form of the inputs and / or outputs, and / or the content of the inputs and / or outputs.

[0102] As an example, the second transaction may be required to have an output that includes some or all of the executive locking script. The output of the second transaction may be required to include an exact copy of the executive locking script. Alternatively, at least some of the executive locking script may be ignored or swapped with alternative data. For example, the executive locking script may comprise one or more variables (e.g., a public key and / or a public key hash), and such variables may be replaced with alternative variables of the same type. For example, a public key may be swapped with a different public key.

[0103] As another example, one of the constraints enforced may be that the second transaction has an input that references a particular output of a particular previous transaction, or any output of a particular previous transaction. Additionally or alternatively, one of the constraints enforced may be that the second transaction backward links to a particular previous transaction through one or more previous transactions. In other words, the second transaction must belong to a chain of transactions that has a given ancestor. In the context of tokens, the second transaction may be required to backward link to a token minting transaction or token issuance transaction that comprises token metadata, e.g., an NFT, that defines the token.

[0104] In some examples, the token issuance transaction comprises the token metadata for the first time. The first transaction may be a token minting transaction that enforces the terms of the token protocol via an enforcement locking script and transfers ownership of the token to a particular party (e.g., Alice 103a or Bob 103b). The second transaction may be a token transfer transaction that transfers ownership of the token to another party (e.g., Bob 103b). Alternatively, the first transaction may be a token transfer transaction that is linked backward to the token minting transaction.

[0105] The execution locking script may include a transfer subscript. The transfer subscript may be locked to a public key or a public key hash and may require that the unlocking script of the second transaction include a signature corresponding to the public key. For example, the transfer subscript may comprise a pay-to-public-key (P2PK) script or a pay-to-public-key-hash (P2PKH) script. In the context of a token, the public key may be associated with the new recipient (owner) of the token, e.g., Bob 103b. In this case, Bob 103b may generate a signature based on the second transaction using a private key corresponding to his public key and include that signature in the unlocking script of the second transaction.

[0106] In some examples, the second transaction includes an output locked to a particular public key, e.g., a public key associated with Alice 103a or Bob 103b. In the context of tokens, this may be used to facilitate a fair transaction, such that Alice 103a is guaranteed payment for transferring tokens to Bob 103b.

[0107] Similarly, a second transaction may be required to include an output locked to the same public key to which the output referenced by the input of the second transaction is locked. In other words, the second transaction has an input that references a previous output, where that previous output is locked to a public key. The output of the second transaction shall be locked to the same public key. In the context of tokens, this may be used to ensure that tokens cannot be burned.

[0108] In some examples, the second transaction may be required to include an output that locks a predetermined amount or percentage of a native blockchain token (i.e., the digital asset underlying the blockchain, such as BSV). For example, the second transaction may include an output that locks a first amount (e.g., to a public key controlled by Bob 103b). The second transaction may be required to include an output that locks a second amount, which is either a predetermined amount or a predetermined percentage of the first amount. The second amount may be locked to a public key controlled by Alice 103a or a different party. In this example, the public key to which the second amount is locked may be fixed by an enforcement locking script, such that any future spend transactions lock an amount of the digital asset to the fixed public key. In the context of tokens, this may be used to enforce that royalties are paid to the token issuer. As described in the following sections, embodiments of the present disclosure may be used to issue a range of tokens, including limited edition tokens and unburnable tokens.

[0109] 7. Simple Enforcement of Constraints - The REFTX Mechanism This section describes an example implementation of the embodiment described above in Section 7.

[0110] 7.1 Constraints as NP predicates Let P be a program (constraint) that will prove proper execution on public inputs (stx, y) and secret input w, where stx denotes a spend transaction. The predicates that will be shown to hold are: predicate

[0111]

number

[0112] : "Given a public string y, I know a witness w such that P((y,stx);w)=1, where stx is a consuming transaction."

[0113] predicate

[0114]

number

[0115] always relates to the consuming transaction stx, never to an arbitrary (possibly off-chain) transaction.

[0116] In some ways, the general predicate

[0117]

number

[0118] may be instantiated. For example (stated informally): A program P with an explicit public string y contains: "The string y is the field "Field" of the consumption transaction stx." A consuming transaction may also be replaced by its i-th ancestor: "Let y:=(y',i), then the string y' is the field 'Field' of the i-th ancestor consuming transaction stx." Or a more complex statement such as "Given a string y:=(y1,y2), a consuming transaction stx has two outputs, the locking script of the first output is a P2PK with public key y1, and the locking script of the second output includes y2 as op-return data."

[0119] Programs with an empty public string y include: · "The consumption transaction stx has three output points." "The locking script of the first output of a consuming transaction stx is identical to the locking script of the transaction referenced in that first output point."

[0120] 7.2 Concise Proofs of Predicates As currently defined, the above predicate (parameterized using program P)

[0121]

number

[0122] defines a spending transaction stx as part of its public input. This means that the on-chain SNARK verifier also takes stx as input, and therefore assumes it is on the stack (no succinctness). Another problem is that we need to ensure that a transaction tx such that P((y,tx);w)=1 is a spending transaction stx and not something else.

[0123] The SNARK scheme is set up to prove the correct execution of an augmented program that takes the transaction as a private input (which solves the first problem) and the STI commitment tag τ as a public input (which is sufficient to solve the second problem).

[0124] Enhanced Program

[0125]

number

[0126] : 1. Gadget STI (τ;(tx,w STI Check that ))=1. 2. P((y,tx);w P )=1. 3. If both checks pass, output 1. Otherwise, output 0.

[0127] Gadget STI (τ;(tx,w STI )) allows checking the correct generation of the STI commit algorithm in zero-knowledge. Gadget if and only if STI.commit(tx)=τ STI (τ;(tx,w STI ))=1 A special value w such that STI Together with,,we take a tag,τ,as a public input and a transaction,tx,as a private input.

[0128] Enhanced Program

[0129]

number

[0130] is a wrapper for a base program P. Thus, given P, its augmentation

[0131]

number

[0132] Also known.

[0133] 7.3 Validation Script The consuming transaction stx is a predicate

[0134]

number

[0135] The script to verify that P is indeed satisfied (also called the REFTX script) is defined as follows:

[0136]

number

[0137] The REFTX script is an example of an execution locking script, as described in Section 6. The STI verification script is an example of a commitment subscript, as described above. SNARK verification

[0138]

number

[0139] is an example of the constraint subscript discussed above.

[0140] where:

[0141]

number

[0142] is the statement "I

[0143]

number

[0144] As defined, if either the STI script fails for the input tag τ or the SNARK verification script fails, this script includes OP_VERIFY to mark the transaction as invalid.

[0145] Recall from above that the description of the preprocessing SNARK verification algorithm SNARK.verify (using the corresponding script [SNARK Verification]) is independent of the program being verified. Indeed, when you input the corresponding verification key into the verifier, all you know is that P is being verified. Indeed, the program

[0146]

number

[0147] To ensure that

[0148]

number

[0149] Verification key for

[0150]

number

[0151] is hard-coded. So the REFTX script above contains:

[0152]

number

[0153] This is similar to hard-coding the public key in the P2PK script to ensure funds are sent to the correct address.

[0154] If y is empty, the REFTX script does not connect with OP_CAT (because the public input to program P is just tag τ).

[0155] If the logic required for y is expensive to prove in zero-knowledge, it may be done in-script. For example, hashing a transaction field y will be faster in script (with a single opcode) than off-chain in zero-knowledge, since it forces the prover to use expensive gadgets (to hash). The prover will only need to prove in zero-knowledge that indeed y is part of the transaction.

[0156] Verification script [SNARK verification

[0157]

number

[0158] ] and proof

[0159]

number

[0160] does not depend (i.e., only logarithmically) on the size of the witness transaction. Moreover, the succinct property of the STI mechanism guarantees that the description of τ and its validation script [STI validation] is also independent of the consuming transaction stx. Combining these two observations, it can be seen that the size of [enforce constraint P] is independent of the size of the consuming transaction stx.

[0161] 7.4 REFTX with dummy signatures When the dummy signature technique described in Section 5.1.2 is used as the STI mechanism, the REFTX script is interpreted as follows:

[0162]

number

[0163] However, G := (x, y) is the base point of the Bitcoin curve secp256k1 (having a basic field

[0164]

Number

[0165] and degree n < p), and τ is a dummy signature. Note that the overhead of the STI mechanism in the script is only 66 bytes (hard-coded base point + two opcodes).

[0166] Enhanced program when the STI commit algorithm is set to a dummy signature

[0167]

Number

[0168] <所 The gadget in STI is the generation of an ECDSA signature using a dummy key, as done in the Bitcoin protocol.<所

[0169] Enhanced program

[0170]

Number

[0171] is more complex than program P because it includes an STI gadget (which checks the proper generation of the STI tag). In the case of the dummy signature scenario, this cost is dominated by checking the appropriate SHA256 hash.

[0172] The script [executing constraint P] takes an input

[0173]

Number

[0174] , vk, y, τ, if we output 1 on the top of the stack, the predicate

[0175]

number

[0176] is guaranteed to be true (with extremely high probability).

[0177]

number

[0178] Remember that is always relative to the consuming transaction stx.

[0179] 8. Transactions validated by miners This section describes embodiments of the present disclosure that can be used to implement a miner-enabled token protocol using the techniques described in Sections 6 and 7 above.

[0180] We begin by defining a non-fungible token (NFT) scheme as a triplet algorithm. NFT:=(Mint,TransferOwnership,ValidateTransfer)

[0181] Some previous NFT schemes have the problem that they rely on off-chain validation and malicious users can disrupt the chain of ownership by not complying with the transaction format. This problem is prevented if the task of validation is moved to miners (i.e., blockchain nodes 104).

[0182] To enable miner validation without introducing any transaction bloat, the REFTX mechanism is utilized.

[0183] 8.1 Transfer and Token Activation Algorithm ValidateTransfer It is implemented in a script and executed as part of the normal validation of the transaction. S→R The issuance of tk enables the ownership transfer of token tk from sender S to receiver R. The first output of the transaction is locked using the following script: [PK R Enable transfer of tk to ]:=[P2PK PK R ][constraint P NFT Execution]

[0184] The P2PK part of the script ensures that the tokens are controlled by the recipient R. The rest of the script is the REFTX mechanism described above, which is used by the NFT program P. NFT By executing the appropriate execution of transaction tx S→R is linked to the issuance transaction tx0. An example program is provided below.

[0185] AlgorithmTransferOwnerShip To transfer token tk, sender S executes transaction tx S→R shall be linked to the issuance transaction. Off-chain steps: 1) The sender sends a transaction tx S→R The sender then correctly generates the script [PK R Enable tk transfer to tx S→R The sender generates the unlocking script as follows: 2) Penalty kick S This means that the transaction is signed using the signature key corresponding to the signature σ S Give. 3) TX S→R Generate an STI tag τ for (sighash). 4) Evaluation key (created when minting)

[0186]

number

[0187] program for the above public input STI tag τ using

[0188]

number

[0189] Proof π for the satisfiability of NFT Generate. 5) TX S→R In the first input unlocking script, the signature σ S , explicit public input y, STI tag τ, and proof π NFT Embed.

[0190] FIG. 4 illustrates an exemplary transaction for transferring ownership of token tk.

[0191] 8.2 Optimized script for transfer activation By using dummy signatures as the STI mechanism, the P2PK script and the constraint enforcement subroutine of the transfer validation script can be merged into a single sub-script. The recipient public key PK is used instead of a dummy public key in the enforcement constraint script. R is used.

[0192] The following script saves a few opcodes over the script from the previous section.

[0193]

number

[0194] 8.3 Example NFT Program This section contains two example NFT programs:

[0195]

number

[0196] Explain.

[0197] 8.3.1 Program 1 Given the following (informally stated) program P NFT Consider the following. “Given a transaction tx as input, then its first output point either references the issuing transaction tx0, or references an on-chain non-coinbase transaction parent_tx for which this statement is true.”

[0198] The recursive nature of the statement, i.e., P NFT Note that if an input transaction to does not consume an issuance transaction, then its parent transaction, or one of its ancestors, must consume the issuance transaction. This ensures that the chain of ownership is respected.

[0199] Issuers using the issuing transaction identifier txid0 must use the following enhanced program:

[0200]

number

[0201] Recursive SNARK evaluation key for

[0202]

number

[0203] and the verification key

[0204]

number

[0205] Generate.

[0206] Enhanced Program

[0207]

number

[0208] : Public Input: τ tx , y:=h vk :=hash(vk) / / Transaction tag and hash of the verification key Secret Input: tx, w STI ,w P :=(vk,parent_tx,parent_txid,τ parent_tx ,π) code: 1. Gadget STI (τ tx ;(tx,w STI Check that ))=1. 2. Program P NFT Check that w outputs 1 as follows: P Using a. Check parent_txid=SHA256d(parent_tx). b. Check that the first output point of tx is parent_txid||0. c. If parent_txid≠txid0 (hardcoded issuance id), do the following: i. STI.commit(parent_tx)=τ parent_tx Check. ii. SNARK.verify((vk,τ parent_tx ),π)=1. iii. h vk Check =Hash(vk). 3. If the above two steps pass, output 1. Otherwise, output 0.

[0209] Program P explained in step 2 NFT has the issuing transaction id txid0 hardcoded (already on-chain) in its description. The reason for passing the verification key vk as witness and its hash as public input is a technicality inherited from recursive SNARKs: the size of the verification key for any program is strictly larger than the size of its public input. Hence, a program's verification key cannot be part of the program's public input. This is usually solved by passing its hash (of a fixed size) and relying on collision resistance to ensure the correct key is used to verify the proof internally. The hash used, Hash, can be a convenient algorithm for zero-knowledge. The base program P NFT is the STI tag τ for the parent transaction parent_tx Check that the input τ is appropriate (Step 2.ci). parent_tx The proof is verified against the parent transaction, and therefore against another, augmented

[0210]

number

[0211] This is needed because it is required to make sure that the script is indeed validating the following: The latter is guaranteed by the binding property of the STI mechanism.

[0212] 8.3.2 Program 2 Alternatively, the script can include the following statement for the consuming transaction:

[0213]

number

[0214] may be proved.

[0215] "Given a transaction tx as input, then its first output point either to the issuing transaction tx0, or to an on-chain non-coinbase transaction parent_tx whose first output is locked using the same script as the first output of tx, and this script is [P2PK PK R ][constraint P' NFT [The following sentences are omitted:]"

[0216]

number

[0217] The definition of REFTX script [constraint P'] refers to the statement itself. NFT There is no circularity problem here, and the statement is well-defined. The reason is that only the script "template" is checked, not the variables (indeed, the statement P' NFT does not state that the verification key vk must specifically be 1). More specifically, the only point at which the circularity problem can arise is in the script for the SNARK verifier SNARK.verify. However, for fixed SNARK schemes, the exact steps of the verification algorithm are known, and therefore the exact opcodes snark_opcodes:={SNARK.Verify opcodes} that describe such algorithm are known and are what are checked. Recall that a preprocessing SNARK verifier checks one program or another using different verification keys.

[0218] The (augmented) program is defined as follows: Enhanced Program

[0219]

number

[0220] : Public Input: τ tx / / Transaction tag Secret Input: tx, w STI , w P :=(parent_tx,parent_txid) code: 1. Gadget STI (τ tx ;(tx,w STI Check that ))=1. 2. Program P' NFT Check that outputs 1 as follows: a. Check parent_txid=SHA256d(parent_tx). b. Check that the first output point of tx is parent_txid||0. c. If parent_txid≠txid0 (hardcoded issuance id), do the following: i. The locking scripts for the first output of tx and parent_tx are equal (using the hard-coded variable PK R (Except for P2PK PK R ][constraint P' NFT Note that this involves checking that the hard-coded verification keys in both scripts are equal. 3. If the above two steps pass, output 1. Otherwise, output 0.

[0221] Difference from the first program: better efficiency on the part of the prover. The task of validating previous transfers from users is delegated to miners. The resulting program

[0222]

number

[0223] is much easier to prove than the previous program, mainly because the SNARK verification gadget (which is costly to emulate in zero-knowledge) is replaced with a byte comparison.

[0224]

number

[0225] Also, because recursion is no longer required, the verification key is not an input to the program, and the parameters of the SNARK scheme are lighter than those used when recursion is required (to obtain the same level of security). The lighter parameters are the main source of efficiency.

[0226] 8.4 Minting The minting mechanism described in this section transforms the scheme from Section 8.1 into a truly atomic swap (a transaction between two parties with no third party involved). The issuer is still required to verify the authenticity of the token, but the issuer's presence can be dispensed with when trading tokens between two users.

[0227] Step 1 - Issuance Transaction The original owner (issuer) creates an issuance transaction tx0 with a (non-fungible) token tk embedded as OP_RETURN data. That person then shares the token under their control with a public key PK Issuer Upload tx0 to the blockchain as a regular P2PK transaction.

[0228] Step 2 - Key generation for the NFT program Issuers using the issuing transaction identifier txid0 must implement the enhanced program outlined in Section 8.3.

[0229]

number

[0230] Generate a SNARK evaluation key ek and verification key vk for one of the

[0231] Step 3 - Mint transaction tx →Issuer Generation of Issuers can use the scripts [STI Validation] and [SNARK Validation]

[0232]

number

[0233] ] using the validation script [Constraint P NFT The issuer then issues: ·program

[0234]

number

[0235] The evaluation key ek and verification key vk corresponding to · Verification script.

[0236] This is called a mint transaction, tx →Issuer The token is generated by trading a public key PK, which is controlled by the issuer. I After this transaction is confirmed in the blockchain, the minting process is concluded and the tokens are ready to be traded. In this example, the issuer funds the issuance and mint transactions.

[0237] FIG. 5 shows an example transaction for minting a token.

[0238] program

[0239]

number

[0240] When using , when transferring tokens from the issuer to the first recipient, the issuer must ensure that the proof is a "mint transaction tx →Issuer The issuer can generate the certificate themselves and use it in the program.

[0241]

number

[0242] The invention can be supplied in a tester for

[0243] How can receiver R be sure that receiver R owns token tk? One possibility is that receiver R has already received the token tk from issuing transaction tx0 or minted transaction tx →Issuer Until R executes transaction tx S→R Another possibility is for a trusted party to attest to the origin, but this does not give an atomic transaction. This section describes alternative mechanisms to avoid relying on either of these.

[0244] Implicitly, tk is an augmented program

[0245]

number

[0246] via the verification key vk of [constraint P NFT Since it is hard-coded in the execution of each transaction tx S→R appears in , where

[0247]

number

[0248] denotes one of the programs described in Section 8.3.

[0249] (i) Proof π NFT is enabled (tx S→R appears on-chain, which is guaranteed by the miner), and (ii) the verification key vk is the correct key, i.e., the key vk generated by the issuer during the minting process. S→R is assumed to be chained to tx0.

[0250] The receiver R receives the tx S→R When verifying this, the following two checks are performed: 1) The receiver R sends tx S→R Embedded script in [PK R Check the format of the P2PK file. R The receiver R can do so because the opcodes that form [enforce constraint P] and [enforce constraint P] are well known. 2) Recipient R receives recipient R's public key PK R And check that the correct verification key vk is embedded in the script. The correct verification key is the mint transaction tx →Issuer The user can verify the issuer's public PK I can be used to identify the mint transaction.

[0251] If the check passes, the receiver R can proceed to make a payment of the tokens to the sender.

[0252] This implementation of the minting process involves a receiver R minting two transactions from the blockchain, i.e., the last one tx instead of the entire chain. S→R and the first one tx →Issuer This allows you to simply obtain the mint transaction.

[0253] The issuer's public key PK embedded in the mint transaction I gives the token authenticity.

[0254] 8.5 Completely fair dealing This section describes how to replace the algorithm TransferOwnerShip by an interactive process, SwapOwnershipByBitcoins, that is fair to both parties. In this process, both parties agree on the amount that the token is worth in terms of the native blockchain token (e.g., Bitcoin). Then, a transaction, tx, with two outputs is created: S⇔R is created. First output: Output tx from the previous section S→R Locking script [PK R [Activate transfer tk to]. Second output: Sender public key PK S P2PK output with an agreed amount of digital assets locked by the

[0255] The steps for SwapOwnershipByBitcoins are as follows: 1. A sender S issues a transaction tx (with no inputs yet). S⇔R and sends it to the recipient R via an off-chain channel (which does not need to be private or authenticated). 2. Receiver R performs the checks described in Section 8.5. If Receiver R is satisfied, she adds the inputs to fund the transaction and signs the transaction with her corresponding Bitcoin signing key. To sign, Receiver R uses the flag SIGHASH_ALL|ANYONECANPAY to include all outputs (especially the first output that transfers tokens to her) in the message signature. Receiver R then sends the funded and signed transaction to the sender. 3. The sender checks that the output point included by the receiver is valid and has sufficient funds. If so, the sender executes the first output point's unlocking script (σ) to transfer the token tk to the receiver (as described in steps (2)-(5) of algorithm TransferOwnerShip in Section 8.1). S ,τ,π NFT )

[0256] Figure 6 shows an example transaction for conducting a fair trade. Tokens are traded in units of 9 native blockchain digital assets. There may be many funding transactions that can be funded from different public keys / addresses.

[0257] 8.6 Usage Fees The issuer may impose a royalty to be paid to the issuer on each transaction of the token, which may be a fixed amount or a percentage of the amount for which the NFT is traded. NFTroyalty is a trading transaction tx S⇔R Check that it has at least two outputs. The second output (new) is the public key PK, which is controlled by the issuer, that it is hard-coded in the program itself. Issuer Transfer units of the underlying digital asset to

[0258] NFT transactions are fully fair swap tx S⇔R (see Section 8.5), or unilateral swap tx S→R Figure 7 shows that an NFT transaction can be S⇔R The following illustrates the royalty when P NFT can be any program for the NFT. For example, it can be a program described in Section 8.3. The issuer can choose the augmented program in the minting process.

[0259]

number

[0260] Generate evaluation / verification keys for

[0261] Program P NFTroyalty : Public Input: At least NFT transaction stx (i.e., tx S→R or tx S⇔R either Secret input: w P code: 1. TX S⇔R Check that has three outputs. 2. Program P NFT Check that w outputs 1. P Using 3. If parent_txid≠txid0, check the following: a. Check that the value of the first output is a fixed fraction of the value of the second output. (Alternatively, check that it is at least a constant value.) b. PK in it Issuer Check that the third output is locked using P2PK with 4. If the above checks pass, output 1. Otherwise, output 0.

[0262] 8.7 Limited Edition This section describes NFTs, a method for trading replicas of the same token. The number of replicas N of a given token tk is finite, and its specific value (the token's scarcity) is configured by the issuer.

[0263] A replica may be an exact copy; for example, an artist may mint N copies of the same digital piece of artwork and sell them individually. Alternatively, replicas may be bound together, but each slightly different, like concert tickets with numbered seats. The value of a replica then depends on its type. In the concert ticket example, seats closer to the stage are considered more valuable.

[0264] The replicas of a token tk are defined as triplets. tk (i) :=(tk,i,replica_specific_field)

[0265] The first field indicates the token they are replicating, the second field is a serial number (counter), and the third field can be used to fill in any replica-specific information needed (it can be empty).

[0266] In some examples, the issuer may simply mint N replicas of the token in parallel (as in Section 0). However, this means that each replica will have a different verification key, making transactions cumbersome (users will need to recognize many keys and somehow know which key to use to transact the i-th replica). This section shows how a single verification key should be used to control all replicas.

[0267] Step 1 - Issuance Transaction The issuer issues N different issuance transactions.

[0268]

number

[0269] Create the ith issuance transaction.

[0270]

number

[0271] is the i-th replica tk embedded as OP_RETURN data. (i) Includes.

[0272] Step 2 - Key generation for the NFT program The issuer then creates a Merkle Tree T tk Identifiers in

[0273]

number

[0274] and the root of this tree is rt tk For simplicity, let N=2 for some n. n (If N is not a power of 2, the issuer must n Fill the last leaf of the tree with dummy data so that you get N leaves, where n is n-1 <log2(N)<nのようなものである。)

[0275] Program P NFTwithReplicas governs the trading of token replicas. It is the NFT transaction tx(tx:=tx S→R or tx:=tx S⇔R The first output point of the token tree T tk It also enforces that the same replica serial number i is embedded in the unlocking scripts of tx and tx_parent. These are the same as those in the program P from Section 8.3. NFT ,

[0276]

number

[0277] There are only two differences regarding

[0278] algorithm

[0279]

number

[0280] checks for Merkle tree membership. If element txid is in tree T tk The circuit for checking whether a leaf belongs to a replica is well known. It takes four inputs: the intended leaf txid, the leaf index i (the replica's serial number), and a Merkle proof.

[0281]

number

[0282] (certification path), and the root of the tree, rt tk It then uses that information to

[0283]

number

[0284] Recalculate the route as rt tk =rt' tk Outputs 1 only if

[0285] Authentication path

[0286]

Number

[0287] is the sibling leaf (when indexing the leaves from 0 to N - 1, the sibling leaf is the (i - 1)-th leaf if i is odd and the (i + 1)-th leaf otherwise), and all intermediate hashes H required to traverse the tree from bottom to top j (1 ≤ j < n). The algorithm uses the sibling leaves and intermediate hashes to repeatedly hash to the root

[0288]

Number

[0289] and recompute it. The j-th bit of index i is used to determine the position of the input up to the hash in the j-th iteration

[0290] Enhanced program

[0291]

Number

[0292] : Public input: τ tx Secret input:

[0293]

Number

[0294] Code: 1. Gadget STI (τ tx ;(tx, w STI Check that ))=1. 2. Program P' NFTwithReplicas Check that outputs 1 as follows: a. Check parent_txid=SHA256d(parent_tx). b. Check that the first output point of tx is parent_txid||0. c.i tx =i parent_tx and i tx , i parent_tx Check that these are embedded in the unlocking scripts of tx and tx_parent, respectively. d.

[0295]

number

[0296] (Parent is not a replica - hardcoded root rt tk ), do the following: i. The locking scripts for the first output of tx and parent_tx are equal (using the hard-coded variable PK R (Except for P2PK PK R ][constraint P' NFT Note that this involves checking that the hard-coded verification keys in both scripts are equal. 3. If the above two steps pass, output 1. Otherwise, output 0.

[0297] Token Tree T tk Any suitable hash function may be used to generate {circumflex over (x)}.

[0298] Step 3 – Generate Mint Transactions The issuer then passes the validation script [Constraint P NFTwithReplicas Execute [] and generate N mint transactions, each consuming one of the mint transactions.

[0299]

number

[0300] After all transactions are confirmed in the blockchain, N replicas of the token can be traded independently. To trade the i replica, a regular user would

[0301]

number

[0302] Start from.

[0303] Figure 8 shows an example transaction for minting two replicas. The root of the token tree is hard-coded in the NFT program that enables the transfer.

[0304] 8.7.1 Revision Replicas minted together are said to belong to a particular version. The publisher can also mint new versions as time evolves. To provide ordering among versions, the token tree for the jth version contains the root of the j-1th token tree (the empty leaf in the first version) as its first leaf. Figure 9 illustrates this process.

[0305] Honestly generated minted transactions always share the issuer's public key, PK, for all versions. I Since the token is locked using , counterfeit revisions are detected. Only the issuer can initiate transactions with each revision.

[0306] 8.8 Auction-friendly NFTs This section describes designing NFTs that are minted and then bid by buyers. Once the auction ends, the issuer transfers the tokens to the buyer with the higher bid. From that point on, transfers between regular users are just atomic swaps, as we've already explained.

[0307] The interaction between the buyer and issuer occurs offline in a manner similar to a fully atomic swap.

[0308] 8.8.1 Submitting a Bid Buyer R issues a funded NFT transaction tx along with buyer R's bid. Issuer⇔R The buyer R sends it to the issuer. To create this transaction, the buyer uses the ID txid0 of the issue transaction tx0 that is already on-chain.

[0309] 8.8.2 Selection of Winners The issuer goes through the full list of received bids and selects the winner (usually the one with the higher bid). The issuer is satisfied with the transaction (i.e., tx Issuer⇔Winner If the funding transaction behind the winner has sufficient funds, it will transfer the tokens to the winner.

[0310] On-chain TX Issuer⇔Winner appears, other transactions tx Issuer⇔R becomes invalid for R≠ winners, so everyone whose bid is not selected still keeps their assets unspent.

[0311] 8.8.3 Miner Activation Threshold Price The issuer may set a price below which no bids can be made. For example, the price may be set at least as much as it takes to fund the issuance transaction tx0. Depending on the token, this will vary.

[0312] The issuer may delegate checking that the funding transaction behind the bid is appropriate to the miner by including such a check in the NFT program executed using the SNARK. Thus, this program also checks the NFT transaction tx S⇔R Check whether the second output of has a value higher than some threshold price given as input when the first output point refers to an issuance transaction.

[0313] Program P NFTauction : Public input: At least NFT transaction tx S⇔R and starting bid price threshold_price Secret input: w P code: 1. Program P NFT Check that w outputs 1. P Using 2. If parent_txid=txid0 (hardcoded issuance id), check that the value of the second output is greater than or equal to threshold_price. 3. If the above two steps pass, output 1. Otherwise, output 0.

[0314] As in the previous section, P NFT is an arbitrary program for NFTs. The threshold price is part of the unlocking script as it is passed as a public input, and therefore can be enforced to be greater than a fixed value for some use cases using the opcode OP_GREATERTHANOREQUAL and by hard-coding the value into the locking script.

[0315] Another option is to use the program P auction The solution is to hard-code the threshold price into the metric itself.

[0316] 8.9 Unburnable Tokens The NFT described in Section 8.1 allows the transfer of tokens to meaningless outputs. For example, the current owner S transfers a locked tx using OP_0 OP_RETURN. S→R The first output of the program P NFT This disrupts the chain that is proven using such a scheme. This means that tokens traded using such a scheme may be burned, which may be undesirable in some scenarios. To explicitly prevent token burning, the second instantiation of the NFT program described in Section 8.3

[0317]

number

[0318] Use P' NFT But the first output of the spend transaction is also locked using the same script to check that the verification key is the same, so the strategy described in the previous paragraph is not possible with this scheme. However, the token can only be burned by sending it to a public key for which it is widely believed that no one has the signing key.

[0319] Our Program P unburntNFT This program informally describes the design of

[0320]

number

[0321] In addition to checking that outputs 1 (see Section 8.3), we also verify that the recipient knows the signing key, which is the transaction of the type tx S⇔R The program also checks that the token is sent to the public key PK R The first output of the funding transaction is locked using a P2PK with a public key matching the UTXO. The ability to unlock such a UTXO ensures that the recipient knows the signing key. Therefore, no tokens are burned in the transaction. Figure 10 shows an example transaction for generating a non-burnable token.

[0322] 9. Completely fair dealing This section describes embodiments of the present disclosure that enable atomic (fully fair) token transactions. These embodiments may be implemented independently of or in conjunction with the embodiments described in Sections 6-8 above. In other words, the token protocol may or may not utilize the executive locking script described above or the REFTX technique described above. In at least some examples, an executive locking script (e.g., a locking script described as part of the REFTX technique) may be used to lock at least one output of each token transaction, e.g., an output containing token data. However, more generally, the protocol for implementing fully fair transactions may be used with any token protocol.

[0323] These embodiments are described with reference to the exemplary system 300 of Figure 3. Alice 103a acts as the sending party, and Bob 103b acts as the receiving party. Here, "sending" and "receiving" are discussed in terms of tokens, i.e., Alice 103a is sending a token to Bob 103b. In Figure 3, Tx1 is the first token transaction used to transfer the token to Bob 103b. Tx2 may be a second token transaction used by Bob 103b to transfer to a different party.

[0324] Token issuance transactions are not shown in FIG. 3. Token issuance transactions are created by a token issuer and submitted to the blockchain network 106. In some examples, Alice 103a may act as the token issuer. The token issuance transaction initially issues a token and includes associated token data. The token data may specify the rules of the token, i.e., what the token can be used and / or redeemed. The token may be non-fungible.

[0325] Alice 103a begins by creating a first token transaction. Here, "first" is used merely as a label and does not necessarily imply that it is the first token transaction (i.e., the first token transaction to transfer tokens from a token issuance transaction), although that is an option. The first token transaction includes an input that references either the output of the token issuance transaction or the output of a token transaction that links back to the token issuance transaction. That is, there may be a chain of one or more token transactions recorded on the blockchain starting with the token issuance transaction, where each later token transaction in the chain references an earlier token transaction in the chain. The first token transaction also includes an output locked to Bob's public key (the "first output") and an output locked to Alice's public key (the "second output"). The first output includes token data, e.g., the same token data as the token issuance transaction.

[0326] Alice 103a sends a first token transaction to Bob 103b. Bob 103b verifies that the input of the first token transaction links back to the token issuance transaction. That is, the input either references the output of the token issuance transaction or references the output of a transaction that is part of a chain of token transactions starting with the token issuance transaction. If the referenced output is a transaction later in the chain, Bob 103b may trace back along the entire chain of transactions to the token issuance transaction. Alternatively, other techniques may be used, such as verifying a constraint proof (contained in the referenced transaction or the first token transaction) that the referenced transaction is linked back to the token issuance transaction. Bob 103b also verifies that the first output is locked, at least in part, to his public key (which may be locked to another public key and / or by one or more additional constraints).

[0327] Upon verifying that the inputs of the first token transaction are linked to the token issuance transaction and that the first output is locked to his public key, Bob 103b funds the first token transaction. That is, Bob 103b adds one or more respective inputs to the first token transaction that reference respective unspent transaction outputs controlled by Bob 103b, e.g., locked to Bob's public key. Bob 103b includes in each input the respective data needed to unlock each unspent transaction output. Typically, this includes a digital signature generated using the respective private key corresponding to the respective public key used to lock the respective output. A transaction including Bob's input is called a funded token transaction.

[0328] Bob 103b sends the funded token transaction to Alice 103a. Alice 103a verifies that the output locked to her public key controls an agreed-upon amount of digital assets, e.g., Satoshi. Alice 103a may also verify that one or more respective transactions referenced by one or more respective inputs of Bob (i.e., inputs added by Bob 103b) are on the blockchain 150. Alice 103a may also verify that the referenced outputs are unspent. Note that Alice 103a does not necessarily have to do so, and the transaction will not be accepted on the blockchain 150 as if the outputs were unspent.

[0329] Upon verifying that the referenced transaction is on-chain, Alice 103a signs the funded transaction. That is, she includes her signature in the first input of the funded token transaction, which references the issuance token transaction or a transaction in the chain of transactions that links to the token issuance transaction. Because only Alice 103a can generate this signature, the token transaction can be submitted to the blockchain 150 only when Alice 103a is satisfied that all checks are complete. Alice 103a may send the signed token transaction to the blockchain network 106 herself, or may send it through a different party, such as Bob 103b. At a later point in time, Bob 103b may perform equivalent actions to Alice 103a to transfer the token to another party, e.g., Charlie. That is, Bob 103b may generate a second token transaction with an input referencing the output of the token transaction locked to Bob's public key, and may run the same interactive protocol described above with Charlie.

[0330] As mentioned above, the tokens being traded may be part of a protocol that utilizes the executive locking script described above. That is, the input of the first token transaction may reference an output that is locked using the executive locking script. In that case, Alice 103a generates a transaction commitment and constraint proof and includes the commitment and proof in the unlocking script of the input of the first token transaction to unlock the referenced output. The process of generating the transaction commitment and constraint proof is described above. The commitment and proof may be included in the input at any suitable time, for example, before sending the first token transaction to Bob 103b, or after receiving the funded token transaction from Bob 103b and before signing the funded token transaction.

[0331] Similarly, the output of the first token transaction locked to Bob's public key may be locked using an execution locking script, which would require Bob 103b to generate a transaction commitment and constraint proof when trading the token with Charlie.

[0332] In some examples, Bob 103a may verify that the execution locking script that forms part of the output referenced by the input of the first token transaction comprises a particular verification key, e.g., the verification key included in the issuance transaction.

[0333] In some instances, the execution locking script for the referenced transaction may be the REFTX script described above, e.g., [PK S where PK S is Alice's public key (i.e., the public key of the sending party). Similarly, the execution locking script for the first token transaction is the REFTX script, e.g., [PK R where PK R is Bob's public key (i.e., the receiving party's public key).

[0334] An example of the fair trade protocol described in this section is provided in Section 8.5 above and shown in Figure 6.

[0335] An exemplary interaction according to these embodiments may be summarized as follows: 1. The sender sends a token transaction to the receiver (the token transaction contains the zero-knowledge proof in the unlocking script as input, and the output to pay the sender). 2. The recipient must obtain the [PK S The script checks that the recipient contains the appropriate verification key. The recipient also receives Bob's public key, PK R However, the script [PK S If so, the receiver will fund the token transaction to pay the sender. The receiver will then send the funded token transaction to the sender. 3. The sender confirms that the funding transaction is on-chain and that the second output of the token transaction is Alice’s public key, PK S and only then can it be locked by adding its signature to the PK S Enable tk transfer to unlock scripts.

[0336] The sender signs in the last step, and the receiver performs some checks in the second step. Only the sender can unlock the P2PK subscript of the Enable Transfer script. It doesn't matter when the zk proof is included; it can be done by either the sender or the prover in any step.

[0337] A more general interaction according to these embodiments may be summarized as follows: 1. The sender sends a token transaction to the receiver. 2. The receiver checks that the referenced input transaction is linked to the issue transaction and that only Bob can unlock the first output of the token transaction (i.e., Bob controls the tokens after the transfer is completed), and if so, funds the token transaction. 3. The sender checks that the funding transaction is on-chain and that the funds are sent to Alice's public key, and only then unlocks the referenced output by adding its signature.

[0338] The Recipient may perform any suitable checks in step 2. For example, the Recipient may check for the existence of all intermediate transactions that trace back to the issuing transaction.

[0339] 10. Further Special Notes Given the disclosure herein, other variations or uses of the disclosed techniques may become apparent to those skilled in the art. The scope of the present disclosure is limited not by the described embodiments, but only by the appended claims.

[0340] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be appreciated that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 as described above.

[0341] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, issuing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, network entities may perform the function of propagating and / or storing blocks without creating and issuing blocks (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0342] In other embodiments of the present invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of creating, issuing, propagating, and storing blocks 151 of the blockchain 150. For example, in these other blockchain networks, "node" may be used to refer to a network entity that is configured to create and issue blocks 151 but not store and / or propagate those blocks 151 to other nodes.

[0343] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," with such entity / element configured to perform some or all of the roles of creating, issuing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in a similar manner as described above with reference to blockchain node 104.

[0344] Some embodiments are described with respect to a blockchain network implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and in general, embodiments may use any type of suitable consensus mechanism, such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a specific example, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The node that is chosen is often called a validator. Blockchain nodes can look up their tokens for some time to have the opportunity to become a validator. Generally, the node that locks the largest stake for the longest period of time has the best chance of becoming the next validator.

[0345] It will be appreciated that the above embodiments have been described by way of example only. More generally, a method, apparatus, or program according to any one or more of the following statements may be provided:

[0346] Statement 1. A computer-implemented method for transferring tokens using a blockchain, the blockchain comprising a token issuance transaction, the token issuance transaction comprising token data and an output locked to a public key issuing party, the method being performed by a sending party; generating a first transaction, the first transaction comprising: i) a first input that references an output of the token issuance transaction or an output of a previous transaction that forms part of a chain of one or more previous transactions that link to the token issuance transaction, the referenced output being locked to a first public key of a sending party; ii) a first output locked to the public key of a receiving party, the first output comprising token data; and iii) a second output locked to the public key of the sending party; sending a first transaction to a receiving party, wherein the receiving party is configured to verify that the first input references an output of the token issuance transaction or an output of a previous transaction that forms part of a chain of one or more previous transactions that link to the token issuance transaction, verify that the first output is locked to the receiving party's public key, and if so, generate a funded first transaction by including one or more respective inputs in the first transaction that reference one or more respective outputs of the one or more respective funding transactions, wherein the one or more respective outputs are locked to the one or more respective public keys of the receiving party; receiving a funded first transaction from a receiving party; verifying that the second output locked to the sending party's public key locks a predetermined amount of digital assets, and if so, generating a signed first transaction by including a signature in a first input of the funded first transaction, the signature corresponding to the sending party's first public key; sending the signed first transaction to one or more nodes of the blockchain network and / or a receiving party; Equipped with.

[0347] Statement 2. The method of claim 1, comprising verifying that one or more respective funding transactions are on a blockchain, wherein said generation of a signed first transaction is conditioned on said verification.

[0348] Statement 3. The method of claim 1 or claim 2, wherein the referenced output comprises an enforcement locking script, the enforcement locking script comprising a commitment subscript and a constraint subscript comprising a verification key, the enforcement locking script configured such that when executed together with an unlocking script for a blockchain transaction, the unlocking script comprises a transaction commitment and a constraint proof, the commitment subscript is configured to verify that the transaction commitment corresponds to the blockchain transaction, and the constraint subscript is configured to use the verification key to verify that the constraint proof provides proof that the committed blockchain transaction satisfies one or more constraints, the method comprising: generating a transaction commitment based on the first transaction or the funded first transaction; generating a constraint proof based on the first transaction or the first funded transaction, the constraint proof providing proof that the first transaction or the first funded transaction satisfies one or more constraints; Including the transaction commitment and constraint proof in an unlocking script of the first transaction or the first input of the funded first transaction; Equipped with.

[0349] Statement 4. The method of claim 3, wherein the first input constraint subscript and / or unlocking script comprises a public input, and the constraint subscript is configured to use both the verification key and the public input to verify that the constraint proof provides proof that the committed blockchain transaction satisfies one or more constraints.

[0350] Statement 5. The method of claim 3 or claim 4, wherein the commitment subscript comprises a commitment key, and the commitment subscript is configured to use the commitment key to verify that the transaction commitment corresponds to the first transaction or the funded first transaction.

[0351] Statement 6. The method of claim 3 or any claim dependent on claim 3, wherein the commitment subscript is configured to provide a transaction commitment proof to the constraint subscript, and the constraint subscript is configured to use the verification key, the public input, and the transaction commitment to verify that the constraint proof provides proof that the first transaction or the funded first transaction satisfies one or more constraints.

[0352] Statement 7. The method of claim 3 or any claim dependent on claim 3, wherein the constrained subscript is configured to use the verification key to verify that the constrained proof has been generated using an evaluation key corresponding to the verification key, and the method comprises generating a constraining proof based on the evaluation key.

[0353] Statement 8. The method of claim 3 or any claim dependent on claim 3, wherein the commitment subscript comprises a non-interactive zero-knowledge verification algorithm configured to verify that a constraint proof has been generated to satisfy the specified program, and the method comprises generating a constraint proof to satisfy the specified program.

[0354] Statement 9. The method of claim 3 or any claim dependent on claim 3, wherein the transaction commitment comprises a digital signature, the commitment key comprises a public key, and the commitment subscript is configured to verify that the digital signature signs a message based on the first transaction or the first funded transaction, and the method comprises generating a digital signature based on the first transaction or the first funded transaction.

[0355] Statement 10. The method of claim 9, wherein the public key corresponds to a private key set equal to 1.

[0356] Statement 11. The method of claim 3 or any claim dependent on claim 3, wherein at least one of the one or more constraints is that the committed blockchain transaction comprises an input that references a token issuance transaction, or that the committed blockchain references a transaction that forms part of a chain of one or more transactions that link to the token issuance transaction.

[0357] Statement 12. The method of claim 3 or any claim dependent on claim 3, wherein at least one of the one or more constraints is that a transaction referenced by an input of the committed blockchain transaction comprises a valid constraint proof linking the transaction to a token issuance transaction, or the transaction is a token issuance transaction.

[0358] STATEMENT 13. The method of claim 3 or any claim dependent on claim 3, wherein the executing locking script comprises a transfer subscript, the transfer subscript comprises a target public key or a hash thereof, and the transfer subscript is configured to verify that the first input unlocking script comprises a signature corresponding to the sending party's first public key.

[0359] Statement 14. The method of claim 3 or any claim dependent on claim 3, comprising including an execution locking script in the second output of the first blockchain transaction.

[0360] Statement 15. The method of claim 3 or any claim dependent on claim 3, wherein at least one of the one or more constraints is that the committed blockchain transaction comprises some or all of an executive locking script.

[0361] Statement 16. A computer-implemented method for accepting transferred tokens using a blockchain, the blockchain comprising a token issuance transaction, the token issuance transaction comprising token data and an output locked to a public key issuing party, the method being performed by a receiving party; receiving a first transaction from a sending party; verifying that the first transaction comprises a first input that references an output of the token issuance transaction or an output of a previous transaction that forms part of a chain of one or more previous transactions that link to the token issuance transaction, wherein the referenced output is locked to a first public key of the sending party; verifying that the first output of the first transaction is locked to the receiving party's public key; generating a funded first transaction by including one or more respective inputs in a first transaction that reference one or more respective outputs of the one or more respective funding transactions, wherein the one or more respective outputs are locked to one or more respective public keys of a receiving party, the funded first transaction comprising a second output locked to the public key of the receiving party, the second output comprising token data; sending the funded first transaction to a sending party, wherein the sending party is configured to verify that the one or more respective funded transactions are on the blockchain, verify that a second output of the funded first transaction is locked to the sending party's public key and locks a predetermined amount of digital assets, and if so, generate a signed first transaction by including a signature in a first input of the funded first transaction, where the signature corresponds to the sending party's first public key, and send the signed first transaction to one or more nodes of the blockchain network and / or the receiving party; Equipped with.

[0362] Statement 17. The method of claim 16, receiving a signed first transaction from a sending party; sending the signed first transaction to one or more nodes of the blockchain network; Equipped with.

[0363] Statement 18. The method of claim 16 or claim 17, wherein the first output locked to the receiving party's public key is included by the receiving party in the funded first transaction.

[0364] Statement 19. The method of claim 16 or any claim dependent on claim 16, wherein the referenced output comprises an enforcement locking script, the enforcement locking script comprising a commitment subscript and a constraint subscript comprising a verification key, the enforcement locking script configured such that when executed together with an unlocking script for a blockchain transaction, the unlocking script comprises a transaction commitment and a constraint proof, the enforcement locking script is configured to verify that the commitment subscript verifies that the transaction commitment corresponds to the blockchain transaction, and the constraint subscript is configured to use the verification key to verify that the constraint proof provides proof that the committed blockchain transaction satisfies one or more constraints, and the method: and verifying that the verification key corresponds to a particular verification key, wherein the generation of the funded first transaction is conditional on the verification key corresponding to the particular verification key.

[0365] Statement 20. A computer device, a memory comprising one or more memory units; a processing device comprising one or more processing units; wherein the memory stores code configured to run on the processing device, the code being configured to perform the method of any of claims 1 to 19 when on the processing device.

[0366] Statement 21. A computer program embodied on a computer-readable storage and configured to perform the method of any of claims 1 to 19 when executed on one or more processors.

[0367] According to another aspect disclosed herein, a method may be provided that comprises actions of a sending party and a receiving party.

[0368] According to another aspect disclosed herein, a system may be provided that includes computer equipment of a sending party and a receiving party. [Explanation of symbols]

[0369] 100 systems 101 Packet Switched Network 102 Computer terminals, computer equipment and devices 103 Users, Entities, Parties, and Agents 103a First Party, Alice 103b Second Party, Bob 104 Blockchain nodes, Bitcoin nodes 105 Client Applications, Software 106 Peer-to-peer (P2P) networks, decentralized networks, blockchain networks 107 Side Channel 150 Blockchain 151 blocks 152 transactions 153 Genesis Block 154 Ordered Sets, Ordered Pools 155 Block Pointer 201 Header 202 Input, input field 203 Outputs, Output Fields, and UTXOs 300 System< / g> < / vk> < / x>

Claims

1. 1. A computer-implemented method for transferring tokens using a blockchain, the blockchain comprising a token issuance transaction, the token issuance transaction comprising token data and an output locked to a public key issuing party, the method being performed by a sending party; generating a first transaction comprising: i) a first input that references an output of the token issuance transaction or an output of a previous transaction that forms part of a chain of one or more previous transactions that link to the token issuance transaction, wherein the referenced output is locked to a first public key of the sending party; ii) a first output locked to a public key of a receiving party, wherein the first output comprises token data; and iii) a second output locked to the public key of the sending party; sending the first transaction to a receiving party, wherein the receiving party is configured to verify that the first input references the output of the token issuance transaction or the output of an earlier transaction that forms part of the chain of one or more earlier transactions that link to the token issuance transaction, verify that the first output is locked to the public key of the receiving party, and if so, generate a funded first transaction by including one or more respective inputs in the first transaction that reference one or more respective outputs of one or more respective funding transactions, wherein the one or more respective outputs are locked to one or more respective public keys of the receiving party; receiving the funded first transaction from the receiving party; verifying that the second output locked to the public key of the sending party locks a predetermined amount of digital assets, and if so, generating a signed first transaction by including a signature in the first input of the funded first transaction, the signature corresponding to the first public key of the sending party; sending the signed first transaction to one or more nodes of a blockchain network and / or to the receiving party; A computer-implemented method comprising:

2. 2. The method of claim 1, comprising verifying that the one or more respective funding transactions are on the blockchain, and wherein the generation of the signed first transaction is conditioned on the verification.

3. the referenced output comprises an enforcement locking script, the enforcement locking script comprises a commitment subscript and a constraint subscript comprising a verification key, the enforcement locking script is configured such that when executed together with an unlocking script for a blockchain transaction, the unlocking script comprises a transaction commitment and a constraint proof, the commitment subscript is configured to verify that the transaction commitment corresponds to the blockchain transaction, and the constraint subscript is configured to use the verification key to verify that the constraint proof provides proof that a committed blockchain transaction satisfies one or more constraints, and the method generating a transaction commitment based on the first transaction or the funded first transaction; generating a constraint proof based on the first transaction or the funded first transaction, the constraint proof providing proof that the first transaction or the funded first transaction satisfies the one or more constraints; including the transaction commitment and the constraint proof in an unlocking script of the first transaction or the first input of the funded first transaction; The method of claim 1 or 2, comprising:

4. 4. The method of claim 3, wherein the constraint subscript and / or the unlocking script of the first input comprises a public input, and wherein the constraint subscript is configured to use both the verification key and the public input to verify that the constraint proof provides proof that the committed blockchain transaction satisfies the one or more constraints.

5. 5. The method of claim 3 or 4, wherein the commitment subscript comprises a commitment key, and the commitment subscript is configured to use the commitment key to verify that the transaction commitment corresponds to the first transaction or the funded first transaction.

6. 10. The method of claim 3 or any one dependent on claim 3, wherein the commitment subscript is configured to provide a transaction commitment proof to the constraint subscript, and the constraint subscript is configured to use the verification key, public input, and the transaction commitment to verify that the constraint proof provides proof that the first transaction or the funded first transaction satisfies the one or more constraints.

7. 3. The method of claim 3 or any one dependent on claim 3, wherein the constrained subscript is configured to use the verification key to verify that the constrained proof has been generated using an evaluation key corresponding to the verification key, the method comprising generating the constraining proof based on the evaluation key.

8. 3. A method according to claim 3 or any one dependent on claim 3, wherein the commitment subscript comprises a non-interactive zero-knowledge verification algorithm configured to verify that the constraint proof has been generated to satisfy a particular program, the method comprising the step of generating the constraint proof to satisfy the particular program.

9. 10. The method of claim 3 or any one dependent on claim 3, wherein the transaction commitment comprises a digital signature, a commitment key comprises a public key, the commitment subscript is configured to verify that the digital signature signs a message based on the first transaction or the funded first transaction, and the method comprises generating a digital signature based on the first transaction or the funded first transaction.

10. 10. The method of claim 9, wherein the public key corresponds to a private key set equal to 1.

11. 10. The method of claim 3 or any one dependent on claim 3, wherein at least one of the one or more constraints is that the committed blockchain transaction comprises an input that references the token issuance transaction or that the committed blockchain references a transaction that forms part of a chain of one or more transactions that link to the token issuance transaction.

12. 10. The method of claim 3 or any one dependent on claim 3, wherein at least one of the one or more constraints is that a transaction referenced by an input of the committed blockchain transaction comprises a valid constraint proof linking the transaction to the token issuance transaction or is the token issuance transaction.

13. 4. A method according to claim 3 or any one dependent on claim 3, wherein the executing locking script comprises a transfer subscript, the transfer subscript comprises a target public key or a hash thereof, and the transfer subscript is configured to verify that the unlocking script of the first input comprises a signature corresponding to the first public key of the sending party.

14. 4. The method of claim 3 or any one dependent on claim 3, comprising including the execution locking script in the second output of a first blockchain transaction.

15. 3. The method of claim 3 or any one dependent on claim 3, wherein at least one of the one or more constraints is that the committed blockchain transaction comprises some or all of the executive locking script.

16. 1. A computer-implemented method for accepting transferred tokens using a blockchain, the blockchain comprising a token issuance transaction, the token issuance transaction comprising token data and an output locked to a public key issuing party, the method being performed by a receiving party; receiving a first transaction from a sending party; verifying that the first transaction comprises a first input that references an output of the token issuance transaction or an output of a previous transaction that forms part of a chain of one or more previous transactions that link to the token issuance transaction, wherein the referenced output is locked to a first public key of the sending party; verifying that a first output of the first transaction is locked to the receiving party's public key; generating a funded first transaction by including one or more respective inputs in the first transaction that reference one or more respective outputs of one or more respective funding transactions, wherein the one or more respective outputs are locked to one or more respective public keys of the receiving party, the funded first transaction comprising a second output locked to the public key of the receiving party, the second output comprising token data; sending the funded first transaction to the sending party, wherein the sending party is configured to verify that the one or more respective funded transactions are on the blockchain, verify that a second output of the funded first transaction is locked to the sending party's public key and locks a predetermined amount of digital assets, and if so, generate a signed first transaction by including a signature in the first input of the funded first transaction, where the signature corresponds to the sending party's first public key, and send the signed first transaction to one or more nodes of a blockchain network and / or the receiving party; A computer-implemented method comprising:

17. receiving the signed first transaction from the sending party; sending the signed first transaction to one or more nodes of the blockchain network; The method of claim 16, comprising:

18. 18. The method of claim 16 or 17, wherein the first output locked to the public key of the receiving party is included by the receiving party in the funded first transaction.

19. the referenced output comprises an enforcement locking script, the enforcement locking script comprises a commitment subscript and a constraint subscript comprising a verification key, the enforcement locking script is configured such that when executed together with an unlocking script for a blockchain transaction, the unlocking script comprises a transaction commitment and a constraint proof, the commitment subscript is configured to verify that the transaction commitment corresponds to the blockchain transaction, and the constraint subscript is configured to use the verification key to verify that the constraint proof provides proof that a committed blockchain transaction satisfies one or more constraints, and the method comprises:

17. The method of claim 16 or any one dependent on claim 16, comprising verifying that the verification key corresponds to a specific verification key, and wherein the generation of the funded first transaction is conditional on the verification key corresponding to the specific verification key.

20. A computer device comprising: a memory comprising one or more memory units; a processing device comprising one or more processing units; 20. A computing device comprising: a processor; a memory for storing code configured to execute on the processor; and a processor configured to execute the method of any one of claims 1 to 19.

21. 20. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 19 when executed on one or more processors.

Images