Lock script propagation

Abstract

A method for forcing a lock script to be propagated throughout a chain of blockchain transactions, the method including generating a primary transaction including a primary lock script configured, when executed by an unlock script of an auxiliary transaction, to verify that the unlock script includes a message generated based on the auxiliary transaction and to verify, based on the message, that an output of the auxiliary transaction includes the auxiliary lock script. The auxiliary lock script is configured to verify that an unlock script of a second primary transaction includes a message generated based on the second primary transaction, to verify that the unlock script of the second primary transaction includes a data item that includes one or more lock scripts of the primary transaction, and to verify, based on the message and the data item, that an output of the second primary transaction includes the primary lock script.

Description

[Technical field]

[0001] The present disclosure relates to a method for enforcing a locking script to be propagated across an entire chain of blockchain transactions, and a method for verifying that the locking script has been enforced across an entire chain of blockchain transactions. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network") and made publicly available. The blockchain includes a chain of data blocks, with each block including one or more transactions. Each transaction, other than the so-called "coinbase transaction," points to a preceding transaction in the sequence, which may span one or more blocks, back to one or more coinbase transactions. Coinbase transactions are further described below. Transactions submitted to the blockchain network are included in new blocks. New blocks are created by a process often called "mining," which involves multiple nodes each competing to perform a "proof-of-work," i.e., solving a cryptographic puzzle based on a pool of ordered, validated pending transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of blocks may be accomplished through mere publication of block headers.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: to transfer digital assets (i.e., some digital tokens), to order a set of entries in a virtual ledger or registry, to receive and process timestamp entries, and / or to chronologically order index pointers. A blockchain may also be leveraged to layer additional functionality on top of the blockchain. For example, a blockchain protocol may allow for the storage of additional user data or indexes to data in a transaction. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, and therefore more complex data can be incorporated. For example, this may be used to store electronic documents on the blockchain, or to store audio or video data.

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

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are typically rewarded with a new transaction called a "coinbase transaction" that distributes an amount of digital assets, i.e., some number of tokens. Detection and rejection of invalid transactions is enforced by the actions of competing nodes, who act as agents of the network and are incentivized to report and thwart fraud. Widespread publication of information allows users to continuously audit node performance. By mere publication of block headers, participants can ensure the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any usable output includes an element that specifies an amount of a digital asset derivable from the preceding sequence of transactions. A usable output is sometimes called a UTXO (an “unspent transaction output”). An output may further include a locking script that specifies a condition for future redemption of the output. A locking script is a predicate that defines the condition required to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such output in a preceding transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Thus, considering a pair of transactions, we refer to them as a first transaction and a second transaction (or “target” transaction). The first transaction includes at least one output that specifies an amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input that includes a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when the 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 the one or more conditions defined in the locking script of the first transaction, and another is that the output of the first transaction has not yet been redeemed by another prior valid transaction. A node that finds the target transaction invalid according to any of these conditions will neither propagate it (as a valid transaction, although it may propagate to register the invalid transaction) nor include it in a new block to be recorded in the blockchain.

[0008] Another type of transaction model is the account-based model. In this case, each transaction defines the amount to be transferred by referencing absolute account balances, not by referencing the UTXO of the preceding transaction in the sequence of past transactions. The current state of every account is stored and constantly updated by nodes separately from the blockchain. Summary of the Invention

[0009] It is commonly known that conditions can be enforced on fields of a spending transaction, i.e., a transaction that uses (unlocks, assigns, transfers, etc.) an 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 spending transaction. It should be noted that the term "spending 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 imply that the current transaction is related to a financial transaction.

[0010] One reason one might want to apply conditions to the field of a spending transaction is to ensure that the spending transaction has an output that contains the same locking script as the previous transaction. In this way, one can ensure that the spending transaction applies the same condition to the next spending transaction; i.e., the n-1th transaction contains a locking script that forces the nth transaction to contain the same locking script, and therefore 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 real-world objects, or objects in a virtual world. This is advantageous, as it means that each transfer of tokens follows the same rules.

[0011] Previous attempts to force a chain of transactions to contain the same lock script suffer from at least one of the following problems. First, some attempts require the verifier to trace back to the first transaction in the chain (e.g., the "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 lock script included in the most recent transaction is the same as the lock script that was included in the first transaction and all other transactions in the chain. This consumes the verifier's resources (in terms of both computational resources, 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 transfer of tokens) to ensure that the next transaction is created correctly. This introduces security vulnerabilities by relying on a third party and increases the number of parties that must interact with each other, reducing efficiency. Third, some attempts to force a chain of transactions to contain the same lock script require that the most recent transaction in the chain includes each previous transaction in the chain, which creates a transaction bloat problem. This is problematic for both transmitting and storing transactions. Fourth, some attempts are susceptible to replay attacks, which are described below.

[0012] It is therefore desirable to implement a mechanism that forces a chain of transactions to contain the same locking script that solves one, some, or all of the identified problems.

[0013] According to one aspect disclosed herein, a computer-implemented method is provided for enforcing a lock script to be propagated throughout a chain of blockchain transactions. The method includes the steps of: generating a first primary transaction executed by a first party and including a first output, the first output including a primary locking script; the primary locking script configured, when executed by a first unlocking script of a first auxiliary transaction, to i) verify that the first unlocking script includes a first message generated based on the first auxiliary transaction; and ii) verify, based on the first message, that the first output of the first auxiliary transaction includes the auxiliary locking script; and the auxiliary locking script, when executed by a first unlocking script of a second primary transaction, to i) verify that the first unlocking script of the second primary transaction includes a second message generated based on the second primary transaction; ii) verify that the first unlocking script of the second primary transaction includes a first data item that includes one or more locking scripts of the first primary transaction; and iii) verify, based on the second message and the first data item, that the first output of the second primary transaction includes the primary locking script.

[0014] The term "primary transaction" is used herein to refer to a transaction in a chain of transactions that are forced to include the same locking script, referred to as the "primary locking script." For example, the primary locking script may include data related to the token, such as a title to a property. The term "auxiliary transaction" is used to refer to a transaction that is used to enforce conditions on a primary transaction, namely that the primary transaction must include the primary locking script. These conditions are enforced, at least in part, by the "auxiliary locking script" that is included in each auxiliary transaction.

[0015] An auxiliary transaction acts as a bridge between successive primary transactions: the first auxiliary transaction uses (i.e., unlocks) the output of the first primary transaction, and the second primary transaction uses (i.e., unlocks) the output of the first auxiliary transaction. The primary locking script imposes conditions on the next auxiliary transaction. For example, the primary locking script forces the next auxiliary transaction to include the auxiliary locking script. The auxiliary locking script imposes conditions on the next primary transaction. For example, the auxiliary locking script forces the next primary transaction to include the primary locking script.

[0016] In some examples, the first primary transaction is the first primary transaction in the chain, i.e., the first transaction that includes the primary locking script. This may be created, for example, by the token issuer that issues the token. In other examples, the first primary transaction is not the first primary transaction, i.e., there is at least one other previous primary transaction in the chain of transactions that includes the primary locking script. For example, in this example, the first primary transaction may be created by the transferor of the token.

[0017] According to another aspect disclosed herein, a computer-implemented method is provided for verifying that a lock script has been enforced across a chain of blockchain transactions, the method comprising: obtaining a second primary transaction executed by a second party, the second primary transaction including a first input and a first output, the first input including a second message generated based on the second primary transaction, the first auxiliary transaction including a first input that unlocks a first output of the first primary transaction, the first data item including one or more lock scripts of the first primary transaction, the first output of the first primary transaction including the primary lock script, the first output of the first auxiliary transaction including the auxiliary lock script, and the first output of the second primary transaction including the primary lock script. The method further includes the steps of verifying that the first primary transaction has been recorded on the blockchain and verifying that the primary locking script of the first primary transaction is configured, when executed by a first unlocking script of the first auxiliary transaction, to: i) verify that the first unlocking script includes a first message generated based on the first auxiliary transaction, and ii) verify, based on the first message, that a first output of the first auxiliary transaction includes the auxiliary locking script, which, when executed by a first unlocking script of a second primary transaction, is configured to: i) verify that the first unlocking script includes a second message, ii) verify that the first unlocking script includes the first data item, and iii) verify, based on the second message and the first data item, that a first output of the second primary transaction includes the primary locking script, thereby verifying that the primary locking script has been enforced across the first primary transaction and the second primary transaction.

[0018] The second party obtains (e.g., receives from the first party) a second primary transaction. The second primary transaction may be the second primary transaction in the chain of transactions, or may be a later transaction. That is, the second transaction may generally be the nth transaction in the chain of transactions. The second primary transaction includes a primary lock script in its output. The second primary transaction has an input that uses the output of the first auxiliary transaction, and thus meets the requirements of the auxiliary lock script. The first auxiliary transaction uses the output of the first primary transaction, and thus meets the requirements of the primary lock script. Thus, if the first auxiliary transaction succeeds in unlocking the primary lock script of the first primary transaction, and the second primary transaction succeeds in unlocking the auxiliary lock script of the first auxiliary transaction, then the second primary transaction necessarily includes a primary lock script. This depends on the correct primary lock script being included in the chain of transactions.

[0019] The second party verifies that the first primary transaction has been recorded on the blockchain and is therefore a valid transaction. The second party also verifies that the primary locking script is correct, e.g., it forces the auxiliary transaction to include the auxiliary locking script, and then forces the next primary transaction to include the same primary locking script. For example, this can be achieved by ensuring that the primary locking script includes a hash puzzle based on the hash of the auxiliary locking script. In this case, the hash puzzle can only be solved (and therefore the primary locking script is unlocked) if the auxiliary transaction includes the auxiliary locking script.

[0020] The second party may then generate a second auxiliary transaction and a third primary transaction. The second auxiliary transaction is necessary to unlock the primary locking script of the second primary transaction. The second auxiliary transaction also forces the third primary transaction to include the primary locking script. Each next transaction in the chain is forced to include the primary locking script in the same way.

[0021] Note that in effect, two lock scripts are forced to be propagated: a primary lock script that is forced to be included in the output of each primary transaction, and an auxiliary lock script that is forced to be included in the output of each auxiliary transaction. [Brief description of the drawings]

[0022] To aid in understanding embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] 1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Diagram 3] 1 illustrates a schematic of an exemplary system for propagating lock scripts. [Figure 4] FIG. 1 is a schematic diagram of an exemplary token protocol transaction structure. [Diagram 5] FIG. 2 is a schematic diagram of a chain of transactions with one input and one output. [Figure 6] 1 illustrates a schematic of the transaction bloat problem. [Figure 7] FIG. 2 is a schematic diagram of a chain of transactions with two inputs and two outputs. [Figure 8] FIG. 1 is a schematic diagram illustrating how an exemplary token protocol prevents transaction bloat. [Figure 9] 1 illustrates a schematic diagram of an exemplary issue transaction. [Figure 10] 1 illustrates an exemplary auxiliary transaction. [Figure 11] 1 illustrates generally an exemplary primary transaction for transferring a token from Alice to Bob. [Figure 12] 4 illustrates a schematic example of another auxiliary transaction. [Figure 13] 1 illustrates an example of a primary transaction transferring a token from Bob to Charlie. [Figure 14] 4 illustrates an exemplary format of an nth primary transaction. [Figure 15] 4 illustrates an exemplary format of an nth auxiliary transaction. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0023] 1. Exemplary System Overview FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may be comprised of a packet-switched network 101, which is typically a wide area internetwork such as the Internet. The packet-switched network 101 includes multiple blockchain nodes 104, which 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.

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

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

[0026] Each block 151 also contains a block pointer 155 that points to a previously created block 151 in the chain to define an order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer back to a previous transaction to define an order for the sequence of transactions (Note: a sequence of transactions 152 can branch). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0027] Each of the blockchain nodes 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 in this specification is not intended to be limited to any particular blockchain, protocol, or model. This refers to an ordered set of transactions that the node 104 has accepted as valid, for which the node 104 is obligated not to accept other transactions that attempt to use the same output.

[0028] For a given current transaction 152j, its input (or each input) contains a pointer that references an output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "used" in the current transaction 152j. Using or redeeming does not necessarily mean the transfer of a financial asset, although that is certainly one common use. More generally, using may be described as consuming an output or allocating it to one or more outputs in another, forward transaction. In general, a preceding transaction may be any transaction in the ordered set 154 or any block 151. Although a preceding transaction 152i must exist and be validated for a current transaction to be valid, a preceding transaction 152i does not necessarily have to exist when the current transaction 152j is created or sent to the network 106. Thus, "preceding" herein refers to something that precedes it in a logical sequence linked by a pointer, and not necessarily to a time of creation or transmission in a time sequence, and therefore does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A preceding transaction 152i is also referred to as an antecedent transaction or a predecessor transaction.

[0029] The input of the current transaction 152j also includes 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 defined in the input of the preceding transaction 152i to the new user or entity 103b, as defined in the output of the current transaction 152j. In some cases, the transaction 152j can have multiple outputs to split the input amount among multiple users or entities (one of which can be the original user or entity 103a to give the change). In some cases, the transaction can also have multiple inputs to pool amounts from multiple outputs of one or more preceding transactions and redistribute them to one or more outputs of the current transaction.

[0030] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wants to enact a new transaction 152j (manually or by an automated process adopted by the party), the enacting party transmits the new transaction from its computer terminal 102 to a recipient. The enacting party or recipient eventually transmits this transaction to one or more of the blockchain nodes 104 of the network 106 (which is currently typically a server or a data center, but could in principle be other user terminals). It is not excluded that the party 103 enacting the new transaction 152j transmits the transaction directly to one or more of the blockchain nodes 104 and in some examples does not transmit it to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied at each of them. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking that the cryptographic signature or other authorization of the party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i that the new transaction uses (or "assigns"), which condition typically includes at least checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the preceding transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the preceding transaction 152i. Alternatively, it may be fixed solely by the blockchain node protocol or by a combination of these.In any event, 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 then forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0031] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is whether it has been validly redeemed by the input of another forward transaction 152j 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 is trying to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless it is flagged as invalid and propagated for a warning) or recorded in the blockchain 150. This prevents double-spending, where a transactor tries to allocate the output of the same transaction multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Again, because the transaction order is defined, account balances are always in a single defined state.

[0032] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process commonly referred to as mining, which is supported by "proof of work." 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. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by trying to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated and hashed with a representation of the ordered pool 154 of pending transactions, the output of the hash satisfies a predefined condition. For example, the predefined condition could be that the output of the hash has a certain predefined 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 it has an unpredictable output for its input. This search can therefore only be performed in a brute force manner, consuming a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

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

[0034] 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 not-yet-published transactions 154 at any given time, depending on when they started 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, the current pool of not-yet-published transactions 154 is updated. The blockchain nodes 104 then continue competing to create blocks from the newly defined, ordered pool of not-yet-published transactions 154, and so on. There are also protocols to resolve any "forks" that may occur if two blockchain nodes 104 solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to propagate between the nodes 104. In essence, whichever prong of the fork grows the longest will be the deterministic blockchain 150. Note that this does not affect users or agents of the network, since the same transactions appear in both forks.

[0035] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate the additional amount of accepted digital assets in a new special type of transaction that distributes an additional defined amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another). This special type of transaction is usually called a "coinbase transaction," but may also be referred to as an "initiation transaction" or "generation transaction." This typically forms the first transaction of a new block 151n. The proof of work indicates the intention of the node constructing the new block to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturity period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generative) 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 the "transaction fee" and is explained below.

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

[0037] 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 process transactions 152 in accordance with the blockchain node protocol. It will be understood that any action 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 at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0038] Also connected to the network 101 are computer devices 102 of multiple parties 103 each acting in the role of consuming users. 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 of transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0039] 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 referred to as "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 fulfill the role required of a blockchain node. Instead, each party 103 may interact with the blockchain network 106, thereby utilizing the blockchain 150 by connecting (i.e., communicating) with the blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes, namely, a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that there may be many more such parties 103 and their respective computer devices 102 and they may 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 is referred to herein as Alice and the second party 103b is referred to as Bob, although it will be understood that this is not limiting and that any reference to Alice or Bob herein may be replaced with "first party" and "second party," respectively.

[0040] The computer equipment 102 of each party 103 comprises a respective processing device including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment 102 of each party 103 further comprises a 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 memories or EEPROMs, and / or optical media such as optical disk drives. The memory on the computer equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 configured to run on the processing device. It will be understood that any action attributed to a given party 103 herein may be performed using software running on the processing device of the respective computer equipment 102. The computer 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 smart watch. The computing equipment 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources accessed via a user terminal.

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

[0042] The client application 105 comprises at least a "wallet" functionality. It has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign) and send transactions 152 to one or more Bitcoin nodes 104 for propagation across the network of blockchain nodes 104 and thereby inclusion in the blockchain 150. The other is to report to each party the amount of digital assets that it currently owns. In an output-based system, this second function involves reconciling the amounts defined in the outputs of the various transactions 152 scattered across the blockchain 150 that belong to that party.

[0043] It should be noted that various client functions may be described as being integrated into a given client application 105, but are not necessarily limited thereto; instead, any client functionality described herein may be implemented in a suite of two or more separate applications that interface, for example, via an API, or one that is a plug-in to the other. More generally, client functions may be implemented at the application layer or a lower layer, such as an operating system, or any combination thereof. The following description is given with respect to client application 105, but will be understood to be non-limiting.

[0044] An instance of a client application or software 105 on each computing device 102 is operatively 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 in which the respective party 103 is a recipient (or, in an embodiment, actually 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 formulate and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and forward the transactions 152 to propagate them across the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol goes with a given node protocol, and together they 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.

[0045] When a given party 103, for example Alice, wishes to send a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction (using a wallet function in Alice's client application 105) according to the associated transaction protocol. Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which Alice is connected. For example, this may be the blockchain node 104 that is 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 includes first checking if the newly received transaction 152j meets certain conditions to be "valid", examples of which are described in more detail below. In some transaction protocols, the conditions for validation may be configurable per transaction 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 defined by a combination of the script and the node protocol.

[0046] Provided that the newly received transaction 152j passes the tests 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 to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that, assuming the transaction 152j is valid, it will be propagated immediately throughout the network 106.

[0047] 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 for the latest version of each pool 154 that contains 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 whichever node solves it first defines the set of transactions contained in the latest block 151. Eventually, the blockchain node 104 will have solved the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that contains the new transaction 152j, it universally becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 contains a pointer back to the previous transaction, the order of the transactions is also immutably recorded.

[0048] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views on which instance is "valid" until one 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 another instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one not published in block 151).

[0049] An alternative type of transaction protocol operated by some blockchain networks may be called an "account-based" protocol, as part of the account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, not by referencing the UTXO of the preceding transaction in the sequence of past transactions. The current state of every account is stored and constantly updated by the nodes of the network separately from the blockchain. In such a system, transactions are ordered using the running transaction tally (also called the "position") of the account. This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field in the transaction may also be signed. This data field may point to a previous transaction, for example if a previous transaction ID is included in the data field.

[0050] 2. UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. It is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). In the following, it is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0051] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which may be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value that specifies an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also include a transaction ID of the underlying transaction, among other information. The transaction data structure may also include a header 201 that may include indicators indicating the size of the input field(s) 202 and output field(s) 203. The header 201 may also include an ID of the transaction. In an embodiment, 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 that is submitted to the node 104.

[0052] Suppose Alice 103a wants to create a transaction 152j that transfers an amount of the digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". It takes the amount of the digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean 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 to any previous (i.e., earlier) transaction that still has an unspent output 203 locked to Alice.

[0053] The preceding transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 by the time Alice creates the new transaction Tx1, or at least by the time Alice 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 be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be created and submitted to the network 106 together, or even Tx0 may 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 the transactions in a sequence defined by transaction pointers (e.g., which transactions point to which other transactions) specified in the transactions. They may similarly be replaced with "predecessor" and "successor," or "antecedent" and "descendant," "parent" and "child," etc. This does not necessarily imply the order of their creation, transmission to the network 106, or arrival at any given blockchain node 104. Nevertheless, a subsequent transaction (a later transaction or "child") that points to a preceding transaction (an earlier transaction or "parent") is not validated unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be buffered for a certain amount of time to wait for the parent or discarded, depending on the node protocol and / or node behavior.

[0054] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines a condition that an unlocking script in the input 202 of the following transaction must satisfy in order for the following transaction to be validated and thus the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines an unlocking condition that includes a condition that an unlocking script in the input of the following transaction includes a cryptographic signature of the party to whom the preceding transaction is locked.

[0055] A lock script (commonly 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 lock script specifies what information is needed to use the transaction output 203, e.g. the need for Alice's signature. An unlock script appears in the transaction's output. An unlock script (commonly called scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

[0056] That is, in the illustrated example, UTXO0 in output 203 of Tx0 must have Alice’s signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for a subsequent transaction that attempts to redeem UTXO0 to be valid). A Requires lock script [Checksig P A ]. [Checksig P A ] is the public key P of Alice's public-private key pair.A Tx1's input 202 includes a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, to identify UTXO0 among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that includes Alice's cryptographic signature, created by Alice applying her private key of 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 defined by the lock script, or by the node protocol, or by a combination of these.

[0057] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check if the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts: <Sig P A > <P A > || [Checksig P A ] Here, "||" represents concatenation, "<...>" means to put data on the stack, and "[...]" are functions that are composed in the lock script (a stack-based language in this example). Equivalently, the scripts could be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, the scripts will create Alice's public key P as contained in the lock script in the output of Tx0. A, to authenticate that the unlock script in Tx1's input contains Alice's signature signing the expected portion of the data. In order to perform this authentication, the expected portion of the data itself (the "message") must also be included. In an embodiment, the data to be signed includes the entirety of Tx1 (i.e., a separate element specifying the signed portion of the plaintext data does not need to be included, as that is already inherently present).

[0058] The details of public-private cryptographic authentication 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 plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature to the message, allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular portion of data or part of a transaction, etc., may, in embodiments, mean signing a hash of that portion of data or part of a transaction.

[0059] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (i.e., in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 to be valid. This means that the blockchain node 104 will add Tx1 to the ordered pool 154 of pending transactions. The blockchain node 104 will also forward the transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that the transaction Tx1 is propagated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as spent. Note that Tx1 can only be valid if it uses unspent transaction outputs 203. If it attempts to use an output that has already been used by another transaction 152, Tx1 will be invalid even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been spent (i.e., whether it already formed a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined 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 has been spent is whether it already formed a valid input to another valid transaction in the blockchain 150.

[0060] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another ground of invalidity in most transaction models, so such a transaction will not be propagated or included in block 151.

[0061] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. Part of the amount defined as spent in the UTXO cannot be "left" while another part is spent. However, it is possible to split the amount from the UTXO among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob all of the amount defined in UTXO0, she can use a reminder to give the remainder to herself in the second output of Tx1 or to pay another party.

[0062] In practice, Alice would also typically need to include a fee for any Bitcoin node 104 that successfully includes Alice's transaction 104 in a block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and thus may not be propagated and included in the blockchain 150, even if it is technically valid (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not want 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(s) 202 of a given transaction 152 and the total amount specified in the output(s) 203 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose 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 used) by the 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 the UTXOs 203 of transaction 152 itself.

[0063] 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. No number is stored anywhere in the blockchain 150 that defines the total balance of a given party 103. The role of the wallet function in the client application 105 is to collate together all the values ​​of the various UTXOs that are locked to the respective party and that have not yet been used in another onward transaction. This can be done by querying the copy of the blockchain 150 stored in any of the Bitcoin nodes 104.

[0064] Note that scripting code is often represented generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to represent a particular function. "OP_..." refers to a particular opcode in the scripting language. As an example, OP_RETURN is an opcode in the scripting language that creates an unusable output of a transaction that can store data in the transaction when preceded by OP_FALSE at the beginning of the lock script, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

[0065] Typically, the input for a transaction is a public key P AIn an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific portion of the 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 that are signed depends on the SIGHASH flag, which is a four-byte code that is typically included at the end of the signature (and is therefore fixed at the time of signing) to select which outputs are signed.

[0066] A lock script may typically be referred to as a "scriptPubKey", referring to the fact that each transaction contains the public key of the party being locked. An unlock script may typically be referred to as a "scriptSig", referring to the fact that it 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 includes authenticating the signature. More generally, any condition or conditions may be defined using a scripting language. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0067] 3. Side Channels As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 120b, respectively, may include additional communication capabilities. This additional functionality allows Alice 103a (at the instigation of either party or a third party) to establish a separate side channel 107 with Bob 103b. The side channel 107 allows for the exchange of data apart 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 (yet) being registered on the blockchain network 106 or progressing on the chain 150 until one of the parties chooses to broadcast the transaction 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.

[0068] 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 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or over a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, anywhere in this specification, the side channel 107 referred to may include any link or links over one or more networking technologies or communication media for exchanging data "off-chain", i.e., apart 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 information or particular pieces of data, etc., over the side channel 107, this does not necessarily mean that all of these pieces of data must be transmitted over the exact same link or the same type of network.

[0069] 4. Forcing Lock Script Propagation FIG. 3 illustrates an exemplary system 300 for forcing propagation of a lock script, i.e., forcing each transaction in a chain of transactions to include the same lock script. The system 300 includes a first party (e.g., Alice 103a) and a second party (e.g., Bob 103b). The system 300 may also include one or more additional parties, e.g., Charlie 103c. The system 300 also includes one or more blockchain nodes 104 of a blockchain network 106. Note that the first and second parties are referred to as Alice 103a and Bob 103b throughout the following description, but this is merely for convenience. That is, the first and second parties are not necessarily configured to perform some or all of the actions described above as being performed by Alice 103a and Bob 103b in connection with FIGS. 1 and 2, although this is of course optional. More generally, both the first party and the second party may be configured to perform some or all of the actions described above as being performed by Alice 103a and / or Bob 103b in relation to Figures 1 and 2. It will be understood that any operations described as being performed by Alice 103a, Bob 103b, or Charlie 103c are performed by their respective computing devices.

[0070] An embodiment of the present invention may be used to ensure that lock scripts are propagated throughout the chain of blockchain transactions. In general, the protocol relies on two types of transactions: primary transactions and auxiliary transactions. Each primary transaction includes a respective primary lock script that applies a condition to each auxiliary transaction that attempts to unlock the respective primary lock script. Each primary lock script is the same, i.e., it has the same format, contains the same data, and implements the same functionality. Each auxiliary transaction includes a respective auxiliary lock script that applies a condition to each primary transaction that attempts to unlock the respective auxiliary lock script. Each auxiliary lock script is the same.

[0071] A first party, Alice 103a, may be responsible for generating the issuing transaction. The issuing transaction is the first primary transaction in a chain of transactions. The issuing transaction may also be referred to as the first primary transaction. In examples where the primary transaction includes token-related data, Alice 103a may be the issuer of the token. In other examples, a different party may initiate the token chain.

[0072] The first primary transaction includes one or more inputs and one or more outputs. For example, the input of the primary transaction may be used to unlock the output of one of Alice's previous transactions and thus may include the data needed to do so, e.g., Alice's signature and public key. The output of the first primary transaction (e.g., the first output) includes the primary locking script, i.e., an instance of the same primary locking script that will be propagated throughout future transactions. Another output of the first primary transaction (e.g., the second output) may specify a spending condition, e.g., it may be locked to a public key owned by Alice 103a or a different party. For example, the second output may include a pay-to-public-key-hash (P2PKH) output.

[0073] The primary locking script is configured to apply several conditions to the transaction (in this case the first auxiliary transaction) that is attempting to unlock the primary locking script. One of the conditions applied to the auxiliary transaction is that the unlocking script of the first auxiliary transaction must include a first message based on the first auxiliary transaction itself. That is, the first message is based on one, some, or all of the fields of the first auxiliary transaction. Some of the fields may be in raw form, and some may be obfuscated, e.g., hashed. One technique for forcing the inclusion of such a message in the unlocking script is known in the art as PUSHTX, which is a combination of pseudo-opcodes, i.e., opcodes configured to perform a particular function. PUSHTX is described in https: / / xiaohuiliu.medium.com / op-push-tx-3d3d279174c1. Another example is described in UK patent application GB2112930.9. By forcing the inclusion of the first message in the unlock script, certain checks can be made on the first auxiliary transaction. This message is sometimes called the sighash preimage because it is a preimage that is hashed before signing as part of the blockchain signing protocol. In other words, by forcing the inclusion of the first message in the unlock script, certain conditions can be enforced on the first auxiliary transaction. One condition that can be enforced is that the output (e.g., the first output) of the first auxiliary transaction contains an auxiliary lock script (described below).

[0074] As an example of how to apply this condition, the primary locking script may include a sub-script configured to implement a hash puzzle based on a hash of the auxiliary locking script. That is, the hash puzzle is configured to include a hash of the auxiliary locking script and can only be solved if a pre-image for the hash is provided, such that the sub-script is unlocked, where the pre-image is the auxiliary locking script. Thus, the primary locking script may be configured to extract a locking script (e.g., the first locking script) from the first message, hash the extracted locking script, and verify that it hashes to a hash of the auxiliary locking script included as part of the primary locking script.

[0075] Alice 103a may create the first auxiliary transaction, which may be generated by a different party. The first auxiliary transaction includes an input including the first message and an output including the auxiliary lock script, as described above. The auxiliary lock script is configured to apply several conditions to the transaction (in this case the second primary transaction) that is trying to unlock the auxiliary lock script. One of the conditions applied to the second primary transaction is that the unlock script of the second primary transaction (e.g., the first unlock script) must include a second message based on the second primary transaction. That is, the second message is based on one, some, or all of the fields of the second primary transaction. Some of the fields may be in raw form and some may be obfuscated, e.g. hashed. Another condition applied to the second primary transaction is that the unlock script must also include a data item that includes one, some, or each lock script of the first primary transaction, and thus the first data item must include the primary lock script. That is, the first data item must include at least the primary locking script. In some examples, the first data item must also include a second locking script of the first primary transaction, described below. Using the second message and the first data item, the auxiliary locking script forces the second primary transaction to include the primary locking script in its output (e.g., the first output). Thus, the primary locking script is propagated between primary transactions. Because the primary locking script forces the auxiliary transaction to include the auxiliary locking script, the auxiliary locking script is also propagated between auxiliary transactions. Thus, any data (e.g., token-related data) included as part of the primary locking script or auxiliary locking script is propagated between primary or auxiliary transactions, respectively.

[0076] As described above, the first primary transaction may include a second output. The auxiliary locking script may be configured to force the second output of the first primary transaction to be used by the input of the second primary transaction. That is, in these examples, the second output of the first primary locking script and the first output of the first auxiliary transaction must be used by the respective inputs of the second primary transaction rather than as separate transactions.

[0077] One option for applying this condition is to force the inclusion of the first auxiliary transaction in the first unlocking script of the second primary transaction. That is, a second data item is included in the unlocking script of the second primary transaction, which second data item includes the first auxiliary transaction, for example in serialized form. The auxiliary locking script is configured to extract from the second message a transaction identifier for each of the outputs used by the first input of the second primary transaction. Similarly, the auxiliary locking script is configured to extract from the second data item a transaction identifier for each of the outputs used by the first input of the first auxiliary transaction. The auxiliary transaction is configured to force the extracted transaction identifiers to be the same.

[0078] In these examples, the second primary transaction includes a second input configured to unlock the second output of the first primary transaction, thus creating a linked chain of transactions. Note that transactions may be linked in this manner without the constraint described above that the output of the first primary transaction and the output of the first auxiliary transaction be used by the same second primary transaction. However, there are advantages (described below) to having this condition enforced within the script.

[0079] In some examples, additional verification may be performed by the auxiliary lock script to verify that the first data item (i.e., the data item that includes the lock script of the first primary transaction) is correct. The first primary transaction has, or is at least associated with, a transaction identifier that is generated by hashing the transaction with a hash function, e.g., SHA256 or SHA512. Any suitable hash function may be used. The first unlock script of the second primary transaction may include a third data item that includes a midstate that applies a hash function to the first primary transaction. Those skilled in the art will be familiar with midstates themselves. In general, once data is hashed (e.g., with a SHA-based hash function), the data is divided into blocks. A series of calculations is performed using the first set of blocks to generate a first midstate. A series of calculations is performed using the first midstate and the second set of blocks to generate a second midstate, and so on until all blocks have been calculated to obtain a hash digest. In other words, the hash function does not include a single operation. Rather, the input to the hash function is split into blocks (e.g., 64 bytes for SHA256) and these blocks are processed in order. The mid-state is the internal state after processing one or more of these blocks. A mid-state is generated after each block is processed. The mid-state computed after processing the nth block depends on all previous blocks but not on any subsequent blocks. An example of the inner workings of the SHA256 hash function can be seen at https: / / qvault.io / cryptography / how-sha-2-works-step-by-step-sha-256 / .

[0080] This disclosure recognizes that by providing a mid-state generated by applying a hash function to a first portion of the first primary transaction that does not include the lock script, the first data item (i.e., the lock script) can be used to continue the calculations within the script to generate a candidate transaction identifier for the first primary transaction. If the candidate transaction identifier matches the actual transaction identifier for the first primary transaction, then the first data item must include the actual lock script (and thus the primary lock script) for the first primary transaction.

[0081] The auxiliary lock script may also be configured to force the second primary transaction to include the transaction identifier of the first primary transaction in the chain. For example, the second primary transaction may be required to include a transaction identifier in the second output. If the first primary transaction is the first transaction in the chain, then each subsequent transaction, including the second primary transaction, is forced to include the transaction identifier of the first primary transaction. In these examples, the first primary transaction (e.g., the first primary transaction) does not include its own transaction identifier because it is based entirely on the first primary transaction. Each subsequent primary transaction may be forced to include the transaction identifier of the first primary transaction.

[0082] The second primary transaction may be generated by Alice 103a or a different party. As described above, the second primary transaction may include a first input using a first output of the first auxiliary transaction and a second input using a second output of the first primary transaction. The second primary transaction may also include a first input that includes a primary locking script. The second primary transaction may include a second output that is unlocked by, for example, a second output of the next primary transaction. The second output may be locked to the public key of the second party, Bob 103b. The second output may include a transaction identifier of the first primary transaction.

[0083] Alice 103a is configured to cause the first primary transaction to be submitted to one or more blockchain nodes 104. For example, Alice 103a may herself send the first primary transaction to the blockchain network 106, or Alice 103a may send the first primary transaction to the blockchain network via an intermediary, such as Bob 103b. Similarly, Alice 103a may be configured to cause the first auxiliary transaction and / or the second primary transaction to be submitted to one or more blockchain nodes 104.

[0084] In some examples, Alice 103a may send the second primary transaction to Bob 103b. Alice 103a may also send a Merkle proof to Bob 103b, which may be used to verify that the first primary transaction was recorded in the blockchain 150.

[0085] Thus far, the first primary transaction has been primarily described as the first primary transaction. However, the first primary transaction may generally be the nth primary transaction, in which case the second primary transaction described above would be the n+1th primary transaction. Similarly, in this example, there is an n-1th primary transaction. In this case, Alice 130a may or may not be responsible for generating the issuing transaction.

[0086] Continuing with this example, the first primary transaction may include a first input that references a first output of a previous auxiliary transaction. Like the first auxiliary transaction, the first output of the previous auxiliary transaction includes an auxiliary lock script (i.e., an instance of the same exact auxiliary script). The previous auxiliary transaction also has an input that references a first output of the previous primary transaction. The first output of the previous primary transaction includes a primary lock script. In this example, the previous primary transaction may be the first primary transaction or may be a different primary transaction in the chain of primary transactions.

[0087] The auxiliary locking script of the previous auxiliary transaction is configured to perform the above-described checks (i.e., apply the same conditions) on the first primary transaction as the auxiliary locking script of the first auxiliary transaction does on the second primary transaction, e.g., to force the first primary transaction to include a primary locking script.

[0088] In these examples, when the second primary transaction has a parent primary transaction (i.e., the first primary transaction) and a grandparent primary transaction (i.e., a previous primary transaction), the auxiliary lock script of the first primary transaction is configured to force the unlock script of the second primary transaction to include a fourth data item that includes one, some, or each lock script of the previous primary transaction, which includes the primary lock script. Using the second message (i.e., a message generated based on the second primary transaction) and the fourth data item included in the unlock script of the second primary transaction, the auxiliary lock script verifies that the primary lock script included in the first output of the second primary transaction is the same as the primary lock script included in the previous primary transaction. This verifies that the same primary lock script is passed from one primary transaction to the next primary transaction and to the next primary transaction. In other words, it proves that the primary lock script of the previous primary transaction has been executed.

[0089] The mid-state generated by applying a hash function (e.g., SHA256) to the previous primary transaction may be used to verify that the fourth data item is correct. That is, additional verification may be performed by the auxiliary lock script to verify that the fourth data item (i.e., the data item containing the lock script of the previous primary transaction) is correct. The previous primary transaction has, or is at least associated with, a transaction identifier generated by hashing the transaction with a hash function, e.g., SHA256. The first unlock script of the second primary transaction may include a fifth data item containing a mid-state that applies the hash function to the previous primary transaction. The auxiliary lock script may generate a candidate transaction identifier for the previous primary transaction using the fourth data item and the fifth data item. If the candidate transaction identifier matches the actual transaction identifier of the previous primary transaction, then the fourth data item must contain the actual lock script (and thus the primary lock script) of the previous primary transaction.

[0090] The first primary transaction may include a second input that uses a second output of a previous primary transaction. A condition may be applied by an auxiliary lock script that is included in the previous auxiliary lock script.

[0091] The prior primary transaction and / or the prior auxiliary transaction may be generated by Alice 103a or may be generated by a different party, such as Bob 103b or Charlie 103c. Similarly, while the above description is generally described with respect to Alice 103a generating the first primary transaction, the first auxiliary transaction, and the second primary transaction, any one or more of these transactions may instead be generated by Bob 103b or Charlie 103c.

[0092] A party, for example Bob 103b, may obtain a primary transaction with the intention of verifying that the primary transaction was generated correctly. For example, Bob 103b may obtain a second primary transaction from Alice 103a. The second primary transaction has been described above. Briefly summarized, the second primary transaction has a first output including a primary locking script, and a first input (i.e., the first input's unlock script) including at least a second message (generated based on the second primary transaction) and a first data item including one, some, or each locking script of the first primary transaction. One of the locking scripts includes the primary locking script. In the following example, the first input of the second primary transaction also includes a first auxiliary transaction.

[0093] Bob 103b verifies that the first primary transaction has been recorded on the blockchain 150 and is therefore a valid transaction. One option for doing so is to obtain a Merkle proof (i.e., a set of hashes) that can be used together with the transaction identifier of the first primary transaction to compute a candidate block header. If the candidate block header matches the block header of blockchain block 151, Bob 103b can be sure that the block contains the first primary transaction. Another option is to request confirmation from blockchain node 104.

[0094] As described above, the unlock script for the second primary transaction may include a third data item (the mid-state of the hash function applied to a portion of the first primary transaction). Bob 103b may use the first data item and the third data item to generate a candidate transaction identifier for the first primary transaction and perform a Merkle proof using the candidate transaction identifier.

[0095] Bob 103b also verifies that the primary locking script included in the first primary transaction is correct, in the sense that the primary locking script is configured to require that the first auxiliary transaction includes the auxiliary locking script. Bob 103b may explicitly verify the primary locking script, i.e., check that it includes the correct functions, etc. As a more efficient option, as described above, the primary locking script may include a hash of the auxiliary locking script as part of the hash puzzle. Thus, in order to solve the hash puzzle, the auxiliary transaction must include the auxiliary locking script. Bob 103b may therefore verify that the primary locking script includes a hash of the auxiliary locking script. For example, the hash may be known in advance by Bob 103b, e.g., it may be sent by Alice 103a or the party that generated the first primary transaction.

[0096] As an optional check, Bob 103a may verify that the second primary transaction includes (e.g., in the second output) the transaction identifier of the first transaction in the chain of primary transactions, which may be the first primary transaction.

[0097] Upon performing the validation, Bob 103b may generate a second auxiliary transaction and a third primary transaction. For example, this may be used to transfer tokens to Charlie 103c. The second auxiliary transaction takes the same format as the first auxiliary transaction. The second auxiliary transaction has a first input that uses the first output of the second primary transaction, i.e., an output that includes the primary locking script. To do so, it includes a third message generated based on some or all fields of the second auxiliary transaction. The second auxiliary transaction has a first input that includes the auxiliary locking script. Bob 103b transmits the second auxiliary transaction to the blockchain network 106, either directly or via a different party.

[0098] Bob 103b also generates a third primary transaction. The third primary transaction is similar to the second primary transaction. It includes a first input that uses the first output of the second primary transaction. The first input of the third primary transaction includes a third message generated based on some or all fields of the third primary transaction. In this example, the first input includes a sixth data item that includes the second auxiliary transaction and the first data item (i.e., each lock script of the first primary transaction) and one, some, or each lock script of the second primary transaction. The third primary transaction may include a second output locked to Charlie's 103c's public key. The third primary transaction may include a second input that uses the second output of the second primary transaction. Bob 103b transmits the second primary transaction to the blockchain network 106, directly or through a different party.

[0099] 5. Blockchain Node Validated Tokens In this section, detailed examples of the above-mentioned embodiments have been described. It should be understood that some of the features presented in this section are optional. This example focuses on the use case where the transactions are token transactions, i.e., they include token-related data. This is only an exemplary use case and can generally be used for other applications that require a provable transaction chain without the need to verify every transaction back to issuance.

[0100] This section describes a token protocol that meets the four requirements. 1. Token transaction verifiers do not need to trace back to the token issuance transaction, thus improving efficiency. 2. Once a token is issued, no trusted third party is involved in the transfer of the token between two users, thus improving security and usability. 3. The size of a token transaction is constant, independent of the number of historical transactions, thus improving storage. 4. This solution is not susceptible to replay attacks, i.e. tokens cannot be copied, thus improving security.

[0101] Tokens that are script-enforced without the need for a verifier or third party to execute the token rules are known as "minor-validated" tokens, or "blockchain-node-validated" tokens. This application discloses, to the best of applicant's knowledge, the first minor-validated token protocol on a blockchain 150.

[0102] The protocol uses the following building blocks: A script snippet that verifies that the same opcode appeared in each of the two grandparent locking scripts in the transaction chain, and that these locking scripts were executed; A script snippet that enforces that both next child locking scripts in a transaction chain contain the same opcode, A script snippet that implements partial SHA256, An auxiliary transaction that passes validation data from one token transaction to its spend transaction (to avoid self-references), and A non-renewable unique token ID (UTID) For simplicity, we assume this is the issuing transaction ID.

[0103] The protocol is presented below in steps, describing one part of the solution at a time. Each iteration of the solution creates a problem that is solved by the next iteration of the solution, eventually resulting in a complete solution. Spending transaction Tx n+1 From the perspective of the Tx n+1Explains how a Tx can be determined to be a valid token transaction. n+1 The following terms are used to refer to transactions related to:

number

[0104] These transactions and their relationships are shown in Figure 4. Assume that the grandparent, parent, and auxiliary transactions have all been accepted by the miner. n+1 is the last seen transaction.

[0105] 5.1. Transaction Structure The protocol considers the last three transactions in the token chain. For each transaction, there is an auxiliary transaction. Auxiliary transactions are necessary to avoid transaction bloat and self-references. A schematic diagram of the transaction structure is shown in Figure 4, where the transaction chain is defined as a chain of second inputs and outputs. This is explained in more detail below.

[0106] In transaction serialization, all inputs appear first, then all outputs. Inputs and outputs appear in the order of their indexes. The following discussion removes transaction encoding from consideration and focuses only on unlock and lock scripts. Note that when referring to an unlock script, one may also refer to the outpoint that corresponds to that unlock script. This is to avoid confusion with the "inputs" to a function.

[0107] Consider a single chain of transactions, such as a representation of a non-fungible token (NFT). Assume there is no splitting or combining of tokens, creating a transaction Directed Acyclic Graph (DAG). Also assume there are no other inputs or outputs that can be added.

[0108] Notation A predefined opcode with an OP prefix is ​​denoted as OP_CODE, and a combination of predefined opcodes without a prefix is ​​denoted as, for example, CODE. An opcode or combination of opcodes that depends on a variable such as a public key is denoted in parentheses, for example, CODE(PK). A configuration of an opcode combination is denoted as CODE1+CODE2.

[0109] 5.3. Push Transactions and Their Derivatives TransactionTx n+1 sighash preimage m n+1 is given as input, Tx n The combination of opcodes labeled PUSHTX in the lock script evaluates to TRUE. Under the hood, the opcodes are the sighash preimage m n+1 The final opcode, OP_CHECKSIG, evaluates to TRUE if a signature with the corresponding public key is input, and the signature is then added to the transaction message m extracted from the transaction itself. n+1 This is in response to.

[0110] Transaction message m n+1 Tx n+1 and Tx n Areas of particular interest are:

number

[0111] The superscript A indicates that the transaction is an auxiliary transaction.

[0112] Including PUSHTX means that the current transaction Tx n+1The sighash preimage of is provable to be on the stack. This means that any of these fields can have conditions applied to them, such as containing a specific combination of opcodes or serial numbers. If these conditions are not met, the spend transaction is not valid.

[0113] dSHA256(Tx n )=TxID n If so, Tx n and TxID n (m n+1 (taken from) is given as input, Tx n The combination of opcode PUSHTXPARENT in the lock script evaluates to TRUE, where dSHA256 is the double SHA256 hash function. Internally, the opcode is passed to the serialized transaction Tx n Calculate the hash of TxID and use the result as the n where the transaction ID is extracted from the outpoint in the sighash preimage that was input to PUSHTX. This evaluates to TRUE if the two values ​​are the same. To ensure that what is pushed onto the stack is indeed the parent transaction of the current transaction, PUSHTXPARENT contains a PUSHTX from which to extract the outpoint. Since PUSHTX contains all outpoints, a parent transaction may be pushed even if it does not correspond to an outpoint of the input in which it appears.

[0114] Serialized transaction message Tx n is constructed from a variety of fields. Areas of particular interest are: 1.Tx n lock script(s); and 2. Outpoint TxID n-1 .

[0115] The implication of including PUSHTXPARENT in combination with PUSHTX is that any fields in the serialized parent transaction can have conditions applied to them, as described above.

[0116] Similarly, dSHA256(Tx n-1 )=TxID n-1 If so, Tx n-1 and TxID n-1 (Tx n ) is given as input, Tx n The combination of opcodes PUSHTXGRANDPARENT in the lock script in evaluates to TRUE. Similar to PUSHTXPARENT and PUSHTX, Tx n is the input given to PUSHTXPARENT to ensure that this is indeed the grandparent transaction. This can be repeated to push any ancestor transactions, as long as the links are iterative via PUSHTXPARENT, PUSHTXGRANDPARENT, etc.

[0117] SHA256 hash function A hash function maps data of any size m to data of a fixed size. If the input data is longer than 447 bits, the SHA256 hash function runs

number

[0118] The calculation of the above steps can be performed up to the jth iteration and stopped. Remaining preimage PPI = m j+1 ||…||m l and midstate mid=CF(m j ,mid j-1 ), can be stored and the computation can continue later. A further "partial SHA" computation, denoted h = partialSHA256(PPI, mid), outputs the same as SHA256(m).

[0119] 5.5. Partial SHA256 on Opcode The computation of the first j iterations is performed off-chain. The last (lj) iterations are performed in script and require the implementation of the computation in opcodes. These opcodes, PARTIALSHA256, return TRUE if h=partialSHA256(PPI,mid) given h and the remaining preimage PPI and midstate mid as input. Internally, the opcode computes the remaining iterations of the SHA256 hash function given PPI and mid as input. It compares this result to h. If they are the same, this set of opcodes returns TRUE.

[0120] In this case, it amounts to computing a partial SHA256 of the serialized transaction which is hashed and compared to the given TxID. As mentioned above, the input appears first in the serialized transaction. This means that the partial SHA256 computation can be used to edit the first input of the serialized transaction in the unlock script which is needed as an input to PUSHTXPARENT or PUSHTXGRANDPARENT.

[0121] Compile the first unlock script of the serialized transaction using partial SHA256. We abuse the notation above to denote the computation of the first j iterations of the SHA256 hash function up to the end of the first input. n,0 ,IV). In other words, writing it like this is n,0 This does not mean that the cryptographic algorithm is only 512 bits (and the first iteration of the SHA256 hash calculation). It is likely to be much longer.

[0122] 5.6. Task 1: Proof of Execution and Propagation The first problem we consider is the so-called “back to genesis” problem, which arises when a token validator wants to prove that a token transaction they received is part of a chain of transactions that leads back to the issuing transaction.

[0123] Using PUSHTX alone, issuers can force any child transactions into a specific format, including any of their children, grandchildren, etc. For example, they may require that a serial number be included in each future transaction. However, validators must explicitly validate all transactions back to the issuing transaction. This increases proof length and validation time with every transfer.

[0124] To avoid the need to validate each transaction back to genesis, a trusted token processor could be a witness to each transfer. This solves the back-to-genesis problem, but reduces usability by creating performance bottlenecks and security risks. It also incurs communication and infrastructure costs. Additionally, this defeats the goal of having minor validated tokens. A trusted token processor could also process the entire transfer, removing the complexity of scripting and the cost of PUSHTX.

[0125] Consider a simple chain of transactions containing one input and one output, as shown in Figure 5.

[0126] Tx n-1 and Tx n If all (in this case one) lock scripts in are identical, i.e., Tx n The first lock script in n-1 If the first lock script in the same, sighash preimage m n+1 defines a PROOFOFEXECUTION that evaluates to TRUE when given as input. The same function in the opcode is n and ls n-1 We label this proof-of-execution as we need the script snippet to guarantee that it will be executed with. If the lock script contains variables, such as a public key, it is not expected to stay the same and is ignored. Opcodes include: 1.m n+1 Transaction Tx n+1 If m is a sighash preimage of n+1 PUSHTX takes as input and outputs TRUE. 2.Tx n is TxID n If the hash preimage of Tx n and m n+1Outpoint TxID from n PUSHTXPARENT takes an INT and outputs TRUE. 3.Tx n-1 is TxID n-1 If the hash preimage of Tx n FromTx n-1 and TxID n-1 PUSHTXGRANDPARENT takes a value and outputs TRUE. 4.Tx n-1 and T n If the lock scripts in n-1 ls from n-1 The opcode in Tx n ls from n The opcode to compare with the opcode in and output TRUE. 5. An opcode that ensures that parent and grandparent transactions have only one input and one output.

[0127] Therefore, a script containing PROOFOFEXECUTION is n+1 ,Tx n ,Tx n-1 ) is used to unlock the Tx n and Tx n+1 If all (in this case one) lock scripts in are identical, i.e. Tx n The first lock script in n+1 For example, if the first lock script in the sighash preimage m n+1 defines a PROOFOFPROPAGATION that evaluates to TRUE when given as input. The same function in the opcode is n Run it with ls n+1 We label it proof-of-propagation because we need the script snippet to guarantee that it will be executed. As with PROOFOFEXECUTION, if the lock script contains variables such as the public key, they are ignored. The opcode PROOFOFPROPAGATION contains: 1.m n+1 Transaction Tx n+1 If m is a sighash preimage of n+1 PUSHTX takes as input and outputs TRUE. 2.Tx n is TxID n If the hash preimage of Tx n and m n+1 Outpoint TxID from n PUSHTXPARENT takes an INT and outputs TRUE. 3.Tx n ls from n The opcode in m n+1 ls from n+1 The opcode to compare with the opcode in the first lock script and output TRUE if the opcode in the first lock script is the same. 4. An opcode that ensures that a child transaction has only one input and one output.

[0128] Therefore, a script containing PROOFOFPROPAGATION is n+1 ,Tx n ) to unlock it.

[0129]

number

[0130] Tx for all n>3 n Lock script in ls n If is s1, the unlock script uses n =(m n+1 ,Tx n ,Tx n-1 ), where: m n+1 =Tx n+1 sighash preimage of, Tx n = serialized parent transaction, and Tx n-1 = Serialized grandparent transaction.

[0131] If n=2, the unlock script uses n = (m2, Tx1). Tx0 has no associated lock script because Tx1 is the issue. Tx1 is the first transaction in which this lock script appears.

[0132] ls n The combination of opcode s1 in the lock script ls n The opcode s1 in n-1 and ls n+1 Note that we prove that it is also included in

[0133] Both PROOFOFEXECUTION and PROOFOFPROPAGATION look for the existence of s1 that contains themselves. In other words, a lock script that contains both of these sets of opcodes is part of the input to both sets of opcodes.

[0134] Tx n+1 If contains the above opcode, Tx n+1 It can be proved by induction that must be linked to issuing transaction Tx1.

[0135] proposition: Tx1 to Tx2, each having at least one input and one output n Consider the set of transactions up to Tx n Suppose that satisfies the following conditions: Tx n One of the inputs is the lock script ls n Tx including s1 n-1 Use the output of Tx n is accepted by the miners, Then, Tx n is linked to the issuing transaction Tx1.

[0136] Proof: This claim can be proved by induction. When n=2, Tx n Once accepted by the miner, it is clear that it is linked to Tx1 by the outpoint of Tx2. Base case n=3: Tx2 contains a lock script ls2 = s1, and an unlock script us2 = (m3, Tx2, Tx1) in Tx3. If Tx3 is accepted by the miner, it must be a grandchild of Tx1, due to the terms of use of s1, and therefore linked to the issuing transaction. nth case: Assume that the nth case is true. n+1th case: lock script ls n = Transaction Tx with output including s1 n Given Tx n+1 If is accepted by the minor, ls n A transaction Tx that uses an output having n+1 is linked to the issuing transaction Tx1 via a chain of transactions if the following three conditions are met: ls n = s1, Tx n+1 Tx n Use that output of Tx n+1 is accepted by miners; To unlock the output, use n =(m n+1 ,Tx n ,Tx n-1 ls n = s1, so by PROOFOFEXECUTION, ls n-1= s1, and by PROOFOFPROPAGATION ls n+1 = s1. Therefore, Tx n-1 teeth: Lock script ls n-1 = s1, This is Tx n Used by n ls n (A link is required to use the Tx n is accepted by the miner (Tx n+1 (if so).

[0137] Therefore, Tx n is linked to Tx1. n+1 Tx n Since it is a child of Tx n Therefore, Tx n+1 is linked to Tx1.

[0138] We prove that each transaction in the chain includes all previous transactions, resulting in the transaction bloat problem, as shown in Figure 6.

[0139] proposition: Transactions Tx1 to Tx2 that satisfy the above assertion n Consider a set of n transactions Tx n includes all transactions going back to issue Tx1.

[0140] Proof: TransactionTx n The unlock script is Tx n-1 This is true for all n >= 3. Therefore, for a given Tx nFor each of these transactions, Tx n includes all transactions going back to issuance.

[0141] 5.7. Challenge 2: Partial SHA256 hash function When solving problem 1, in order to execute PROOFOFPROPAGATION and PROOFOFEXECUTION, Tx n ls n , Tx n Outpoint transaction ID TxID n-1 , and us from parent and grandparent transactions n Tx at the input to n-1 ls n-1 Only the unlock scripts for the parent and grandparent transactions are needed. You do not need the unlock scripts for the parent and grandparent transactions. Think about how you want to edit these parts of the transaction.

[0142] Consider a chain of transactions with two inputs and two outputs, as shown in Figure 7. The additional input and output correspond to the P2PKH (PK) script. The first unlock script is edited to introduce a second input and output so that PROOFEXECUTION can still use the grandparent transaction using the second outpoint. After explaining the solution below, we will explicitly show why the nth transaction will not include all transactions up to the issuance. Roughly speaking, this is because the unlock script data, which is part of the transaction that carries information about the previous transaction, is not propagated. By computing the hash of the transaction off-chain (to compare with the TxID), we prevent the data from being propagated.

[0143] TxID n =SHA256(partialSHA256(PPI n ,mid n)), then Tx n+1 TxID from the second outpoint in n and PPIs n and mid n defines PUSHTXPARTIALPARENT which evaluates to TRUE when given as input.

[0144] TxID n-1 =SHA256(partialSHA256(PPI n-1 ,mid n-1 )), then Tx n TxID from the second outpoint in n-1 and PPIs n-1 and mid n-1 defines PUSHTXPARTIALGRANDPARENT which evaluates to TRUE when given as input.

[0145] As mentioned above, the partial SHA256 calculation allows the editing of the first inputs of the parent and grandparent transactions in these two opcodes, respectively. Thus, the input us n-1,0 and us n-2,0 us n,0 Secondly, PPI n The PPI contains the second unlock script and both lock scripts of the parent transaction. n-1 contains two locking scripts of the grandparent transaction. A second unlocking script in the parent transaction allows the extraction of the grandparent transaction ID. The locking scripts are extracted as input to the execution of PROOFOFPROPAGATION and PROOFOFEXECUTION.

[0146] Redefine PROOFOFPROPAGATION and PROOFOFEXECUTION to include PUSHTXPARTIALPARENT and PUSHTXPARTIALGRANDPARENT instead of PUSHTXPARENT and PUSHTXGRANDPARENT, respectively. Redefinition means that the script n and Tx n-1 Instead of PPI n or PPIs n-1 This means extracting the opcodes in the required lock script from the . Therefore, a script containing PROOFOFEXECUTION is (m n+1 ,PPI n ,mid n ,PPI n-1 ,mid n-1 ) and the script containing PROOFPROPAGATION is unlocked by (m n+1 ,PPI n ,mid n ) to unlock it.

[0147] Additionally, PROOFOFPROPAGATION and PROOFOFEXECUTION are redefined to include opcodes that compare opcodes in multiple sets of lock scripts, rather than just one set of lock scripts. As mentioned above, that is, Tx n The opcodes in the first lock script in n+1 or Tx n-1Now we also compare the opcodes in the second set of lock scripts in these transactions. These opcodes return TRUE if the first set of lock scripts contains the same opcode and the second set of lock scripts contains the same opcode. This also means that instead of checking for one input and one output in each transaction, we ensure that there are only two inputs and two outputs in each transaction. Further references to these opcodes will refer to these new definitions. Define the set of opcodes with the redefined opcodes to be s2:

number

[0148] lock script ls n,0 = s2 for all n, us n,0 =(m n+1 ,mid n ,PPI n ,mid n-1 ,PPI n-1 ), where: m n+1 =Tx n+1 sighash preimage of, mid n =CF(us n-1,0 ,IV). PPI n =us n-1,1 ||ls n,0 ||ls n,1 ||pad n , mid n-1 =CF(us n-2,0 ||us n-2,1 ,IV). PPI n-1 =ls n-1,0 ||ls n-1,1 ||pad n-1 .

[0149] Each unlock script contains only these five components, which are proven to have a fixed length. n-1,0 , us n-2,0 has been redacted with a partial SHA256 calculation.

[0150] proposition: Tx n Let be a transaction in the transaction chain defined above with two inputs and two outputs. Let Tx n The size of is less than a constant for all n, i.e., len(Tx n ) <= const.

[0151] Proof: len(Tx n It is easy to show that ) does not depend on n. In serialized transactions and sighash preimages, most fields have clear bounds on their size.

[0152] Sighash preimage: Excluding lock and unlock scripts, the limits are: 4+32+32+32+4+9+8+4+32+4+4=165 bytes.

[0153] Note that because our solution needs to check the lock script, we need to replace the last 32 bytes (which are the output of the hash function) with its preimage. This means that, excluding the lock script, the upper bound is: 4+32+32+32+4+9+8+4+8vout+4+4=149 bytes, where in our case vout has value 2. 9 is a VarInt and can therefore be anything from 1 to 9 bytes. The lock script being used (parent lock script ls n-1 ) and the lock script in the current transaction ls n,vout was excluded.

[0154] Specifically, the unlock and lock scripts have the sizes given in the table below. [Table 1]

[0155] Excluding the lock and unlock scripts, the maximum size of a serialized transaction is (4+9+9+4+vin(32+4+9+4)+vout(8+9)) = 158 bytes. where vin and vout are the number of inputs and outputs, respectively, each having the value 2. Note that each of the 9 bytes represents a VarInt field, which can be between 1 and 9 bytes and can be different for each input or output.

[0156] Using the above table, including the lock and unlock scripts, the size of a serialized transaction is len(Tx n )=711+5len(s2)+len(mid n-1 )+len(mid n-2 ) become a part-time worker.

[0157] TransactionTx n All fields in depend on the length of script s2 and the lengths of the mid-states of the parent and grandparent transactions, both of which are constant length. Thus, we obtain an upper bound on the size of a transaction that is independent of n.

[0158] Note: There is duplication in the unlock script, with s2 appearing four times. This can be mitigated by taking it as input once and duplicating the data. The result is a size of (711+2len(s2)+len(mid n-1 )+len(mid n-2 )) bytes are obtained.

[0159] The nth transaction Tx is created by editing the first unlock script of the parent and grandparent transactions from the current transaction. n does not include all transactions up to issue Tx1. As shown in Figure 8, the first input only contains the second unlock script and the two outputs of the two previous transactions, and does not contain any information about the previous transactions.

[0160] This would reintroduce the transaction bloat problem, so we n-1,0 and us n-1,1 Note that you cannot swap out points that correspond to n,0 In order to be edited in, the unlock script containing the previous transaction us n-1,0 must appear first.

[0161] While solving the bloat problem, it introduced the following self-referential problem: each round of the compression function processes 64 bytes and must be written in opcodes. The function CF() requires more than 64 bytes based on the existing opcode.

[0162] lock script ls n,0 is mid n and PPIs n It contains multiple compression function rounds defined as partialSHA256(), which takes as input the PPI n To illustrate the self-reference problem, consider the best case scenario that can be implemented in 65 bytes: n Assume that initially it contains only one round of SHA256() so that it has a length of 65 bytes.

[0163] PPI n To process 65 bytes, the PPI nThe opcode in the PPI requires two rounds of SHA256(). n The length of increases to 130 bytes. At this point, the PPI n In order to process this, three rounds of SHA256() must be done in the opcode, i.e. PPI n is actually 195 bytes. It is immediately clear that there is a self-referencing problem.

[0164] This is not a problem, since the length of PUSHTXPARENT does not vary depending on the preimage length: the opcode OP_HASH256 can handle preimages of any length and still be calculated using a single opcode.

[0165] 5.8. Solution: Auxiliary Transactions As shown in Figure 4, Tx n-1 Use the first output of Tx n The lock script in the auxiliary transaction is called Tx n The inclusion of this transaction results in the partial SHA256 hash function not being used as input to itself.

[0166] dSHA256(Tx A n )=TxID A n In the case of m n+1 and Tx A n Given as input, the set of opcodes PUSHTXAUXILIARY evaluates to TRUE, where TxID A n m n+1 The first out point is extracted.

[0167] Opcodes PUSHTXAUXILIARY include: 1.m n+1 Take as input m n+1Transaction Tx n+1 PUSHTX outputs TRUE if the sighash is a preimage of 2.m n+1 FromTx A n and TxID A n Take, Tx A n is TxID A n PUSHTXPARENT returns TRUE if the hash preimage is

[0168] Therefore, a script containing PUSHTXAUXILIARY should be written as follows: n+1 ,Tx A n ) to unlock it.

[0169] Define the script s3 as follows:

number

[0170] ls as shown in Figure 1 A n The lock script with =s3 is us n,0 =(m n+1 ,Tx A n ,mid n ,PPI n ,mid n-1 ,PPI n-1 ), where: m n+1 =Tx n+1 sighash preimage of, Tx A n = serialized auxiliary transaction, mid n =partialSHA256(us n-1,0 ,IV). PPI n =us n-1,1 ||ls n,0||ls n,1 ||pad n , mid n-1 =partialSHA256(us n-2,0 ||us n-2,1 ,IV), and PPI n-1 =ls n-1,0 ||ls n-1,1 ||pad n-1 .

[0171] Also, hash(ls A n )=hash(s3), then ls A n Define the set of opcodes HASHPUZZLE that evaluate to TRUE when given as input, where hash(s3) is a fixed constant within HASHPUZZLE.

[0172] Scripts A Define as follows:

number

[0173] Lock script ls for all n n,0 s A If you redefine it to be, the unlock script will A n =m A n where m A n Tx A n This is a sighash preimage of.

[0174] This lock script is A n contains the opcode defined above. n,0By forcing unlocking the hash puzzle in, there is no need to change the definitions of PROOFOFEXECUTION and PROOFOFPROPAGATION, and auxiliary transactions have the correct format in each transfer without having to be explicitly checked. All auxiliary transactions are automatically forced.

[0175] Finally, the lock script ls n,1 As mentioned above, P2PKH(PK n ).

[0176] The partial SHA256 hash function is not included in the partial preimage PPI. This is because the ls A n The self-referencing problem was resolved without introducing any new issues.

[0177] 5.9. Start the Protocol An issue transaction does not have a grandparent transaction. This introduces a special case that requires an amendment to s3. An issue transaction can be identified in at least two ways: 1. Validate the signature on the transaction from a public key owned by the issuer. 2. Give each token a unique token ID (UTID).

[0178] To avoid introducing a specific issuer, we choose the second method, where the UTID is defined to be the TxID of the issuing transaction TxID1. n+1 UTID in Tx n When present in m n+1 defines an opcode UTIDPRESENT that evaluates to TRUE when given as input. n UTID and TxID in n TxID from the second out point to n-1 If and are equivalent, m n+1We also define an opcode, DEFINEUTID, that evaluates to TRUE when given as input. Note that this is only true when n=2, since UTID=TxID1. This means that UTID does not exist in Tx1. Instead, it is true that UTID does not exist in Tx for all n>2. n must be present in the lock script.

[0179] Also, us n,1 Out points to and from us A n It also defines SAMEOUTPOINT, which evaluates to TRUE if, given an outpoint to , they contain the same TxID.

[0180] Let script s be defined as follows:

number

[0181] UTIDPRESENT is executed and if it outputs 1 (i.e., n>2), the "if" statement containing PROOFOFPROPAGATION is executed. UTIDPRESENT is executed and if it outputs 0 (i.e., n=2), the "else" statement containing DEFINEUTID is executed.

[0182] Unlock script us n,0 =(m n+1 ,Tx A n ,mid n ,PPI n ,mid n-1 ,PPI n-1 ) as shown in Figure 1. A n Refine the lock script with =s. This, along with the other unlock scripts, remains unchanged from the previous unlock script. The only changes to the lock script are: ls n,0includes hash(s) rather than hash(s3) as the fixed data for the hash puzzle; OP_RETURN <utid>ls with additional n,1 . Note that there are overlaps with opcodes in each set of opcodes, such as PUSHTX and PUSHTXPARTIALPARENT in both PROOFOFPROPAGATION and PROOFOFEXECUTION, which utilize the same functionality and may duplicate any necessary information for efficiency.

[0183] The two output TxIDs of the parent transaction n-1 ||0, TxID n-1 Enforces that ||1 is used in the auxiliary and current transactions, respectively. If outputs are not forced to be used in this manner, it is possible to fork the transaction chain and still appear to follow the protocol correctly. This could introduce an attack vector where an attacker could easily spend the first output without the second output.

[0184] Currently, Tx n Must be used with the second output of Tx A n Since the output of is locked, it is possible to burn a token by using the second output without the first. This cannot be prevented in the script without reintroducing the self-referential problem, since the auxiliary transaction (which contains the partial SHA256 hash function in the opcode) becomes part of the second unlock script. Therefore, the partial SHA256 hash function must process itself in the opcode, which is a self-referential problem. Tx n Since a signature is required to spend the second output of , if a token is burned in this way, the signature proves it.

[0185] It is also possible to burn tokens by using an auxiliary transaction with a second output, but this reintroduces the transaction size increase and the self-referencing problem of partial SHA256. However, our solution is that PROOFEXECUTION is m n+1 This is prevented by requiring an Out Point to be extracted only from a second Out Point in a transaction, and by ensuring that the transaction is only valid if the second Out Point is not an auxiliary transaction.

[0186] As mentioned above, m n+1 by requesting PROOFEXECUTION to extract an out-point from the second out-point in Tx A n The out point of Tx n This forces the Tx n and Tx n-1 A lock script in a Tx transaction is issued if and only if the lock script in the Tx transaction contains the same set of opcodes and the same UTID defined as the TxID of the issuing transaction. A n This is because the opcode in the lock script returns TRUE. This is because the second outpoint is Tx n This only applies when this is the second output of Tx and any other outpoint does not contain the same opcode and UTID. A n The output of Tx n It must be used together with the second output of , otherwise it is invalid.

[0187] Script s is an example of the auxiliary locking script described above. A is an example of the primary locking script discussed above. The subscript A means that the primary locking script applies a condition to the auxiliary transaction.

[0188] 5.10. Token Transfer Protocol Consider the issuance of a token by issuer I to Alice 103a, followed by two transfers of the token, first to Bob 103b, who then transfers it to Charlie 103c. 1. The issuer creates Tx1, where ls 1,0 =s and ls 1,1 =P2PKH(PK A ), defined in Section 3.3, pays the token to Alice's public key. 2. Alice creates an auxiliary transaction Tx as defined in Section 3.4. A 1 and Tx2 as defined in Section 3.3 and send them to Bob. 3. Bob validates the transaction using the following steps: 4. Bob, Tx A 2 and Tx3 and send them to Charlie. 5. Charlie validates the transaction using the following steps:

[0189] Further transfers are performed in the same manner as the transfer to Charlie.

[0190] 5.11.Validator Steps for n Transfers 1. Transaction Tx n and Tx n-1 Receive the Merkle proof of Tx n Using the data in the TxID n-1 and verify that the Merkle proof is valid. 2.Tx n-1 Extract the hash of the auxiliary lock script from the hash puzzle in and verify that it corresponds to its known hash. 3. Extract the UTID and verify that it is signed, either with a list of valid UTIDs from the issuer or with the signature on the issuance transaction.

[0191] Note that there are steps that a validator takes, but this is similar to any exchange of cash internally, such as only accepting paper notes if they have the correct markings, or only accepting blockchain transactions if they contain a P2PPK for the correct public key, etc. This is a miner validates tokens given a correctly issued transaction, and any transfers should always produce another valid token without any effort from the validator.

[0192] 5.12. Detailed Protocol Examples Consider the issuance of a token by issuer I to Alice 103a, and two transfers of the token, first to Bob 103b, who then transfers it to Charlie 103c. Further transfers are performed in the same way as the transfer to Charlie 103c.

[0193] issue 1. The issuer creates a transaction with an optional output that requires a signature, representing a token like that in Figure 9, and sends it to Alice. The UTID of this token is TxID1. This transaction includes a P2PKH output that requests that Alice 103a unlock the output. The other output enforces that the auxiliary transaction includes the correct function in the output.

[0194] Token Transfer 2. Alice 103a creates an auxiliary transaction that uses the first output of Tx1, as shown in Figure 10. This transaction is A and enforces that the UTID is present in the next transaction and is only used in the same transaction as the P2PKH output from Tx1. 3. To transfer this token to Bob 103b, Alice 103a generates and sends the transaction shown in Figure 11. Bob 103b accepts it if it passes validation (detailed above). 4. Bob generates an auxiliary transaction that uses the second output of Tx2, as shown in FIG. 5. To transfer this token to Charlie 103c, Bob 103b generates and sends to Charlie 103c the transaction shown in Figure 13. If it passes validation (detailed above), Charlie 103c accepts it.

[0195] Further transfers are performed in the same manner and in the same format as the transactions of FIGS.

[0196] The general format of the nth token transfer is shown in Figure 14. Auxiliary transaction Tx A n-1 is shown in FIG.

[0197] 6. Further notes Other variations or use cases of the disclosed techniques may become apparent to one of ordinary skill in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0198] 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 understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is not 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.

[0199] 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, a network entity 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).

[0200] 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, on those other blockchain networks, a "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.

[0201] Even more generally, any reference above to the term “Bitcoin node” 104 may be replaced with the term “network entity” or “network element”, where such entity / element is 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 the same manner as described above with reference to blockchain node 104.

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

[0203] <Statement 1> A computer-implemented method for enforcing a lock script to be propagated throughout a chain of blockchain transactions, the method being executed by a first party, 1. A method comprising: generating a first primary transaction including a first output, the first output including a primary locking script; the primary locking script configured, when executed by a first unlocking script of a first auxiliary transaction, to: i) verify that the first unlocking script includes a first message generated based on the first auxiliary transaction; and ii) verify, based on the first message, that the first output of the first auxiliary transaction includes the auxiliary locking script; and the auxiliary locking script configured, when executed by a first unlocking script of a second primary transaction, to: i) verify that the first unlocking script of the second primary transaction includes a second message generated based on the second primary transaction; ii) verify that the first unlocking script of the second primary transaction includes a first data item that includes one or more locking scripts of the first primary transaction; and iii) verify, based on the second message and the first data item, that the first output of the second primary transaction includes the primary locking script.

[0204] <Statement 2> A step of generating a first auxiliary transaction, the first auxiliary transaction referring to a first output of the first primary transaction, the first auxiliary transaction including a first input including a first message, and a first output including an auxiliary lock script; The method according to claim 1,

[0205] <Statement 3> The method of statement 1 or statement 2, wherein the primary locking script includes a hash of an auxiliary locking script, the first message includes a candidate auxiliary locking script, and verifying that the first output of the first auxiliary transaction includes the auxiliary locking script includes: the primary locking script hashing the candidate auxiliary locking script and verifying that the hash of the candidate auxiliary locking script matches the hash of the auxiliary locking script.

[0206] <Statement 4> A method according to any of the preceding statements, wherein the first primary transaction includes a second output, and the auxiliary lock script is configured, when executed by the first unlock script of the second primary transaction, to verify that iii) the second output of the first primary transaction is unlocked by the second input of the second primary transaction.

[0207] <Statement 5> The auxiliary lock script is configured, when executed by the first unlock script of the second primary transaction, to iv) verify that the first unlock script of the second primary transaction includes a second data item that includes the first auxiliary transaction, and said verifying that the second output is unlocked by the second input of the second primary transaction includes: a) extracting from the second message a transaction identifier for each of the second outputs unlocked by the second input of the second primary transaction; b) extracting from the second data item a transaction identifier for each of the first outputs unlocked by the first input of the first auxiliary transaction; and c) verifying that the respective transaction identifiers extracted during step a) match the respective transaction identifiers extracted during step b).

[0208] <Statement 6> The first primary transaction has a respective transaction identifier generated by applying a hash function to the first primary transaction, the first unlock script of the second primary transaction includes a third data item, the third data item including a mid-state of the hash function applied to the first primary transaction, and the auxiliary lock script, when executed by the first unlock script of the second primary transaction, is configured to: iv) generate candidate transaction identifiers based on the first data item and the third data item and verify that the candidate transaction identifiers match the respective transaction identifiers of the first primary transaction.

[0209] <Statement 7> The method of any of the preceding statements, wherein the auxiliary lock script is configured, when executed by the first unlock script of the second primary transaction, to v) verify that the second primary transaction includes a particular transaction identifier.

[0210] <Statement 8> A step of generating a second primary transaction, the second primary transaction referring to the first output of the first auxiliary transaction and including a first input including a second message and a first data item, the second primary transaction including a first output including a primary lock script; The method according to any of the preceding statements, including

[0211] <Statement 9> A method as described in any of the preceding statements, including sending the first auxiliary transaction and the second primary transaction to a second party.

[0212] <Statement 10> A method according to statement 9, comprising the step of sending a Merkle proof to a second party to prove that the first primary transaction was recorded in a block of the blockchain.

[0213] <Statement 11> The method according to any of the preceding statements, wherein the primary locking script and / or the auxiliary locking script includes data regarding token ownership.

[0214] <Statement 12> The method according to any of the preceding statements, wherein the first primary transaction is a first primary transaction in a chain of blockchain transactions.

[0215] <Statement 13> The method described in Statement 11 and Statement 12, wherein the first party is the issuer of the token.

[0216] <Statement 14> The method according to statement 12 or statement 13 when subordinate to statement 7, wherein the particular transaction identifier is the respective transaction identifier of the first primary transaction.

[0217] <Statement 15> The method of any of the preceding statements, wherein the first primary transaction includes a first counter value, and the auxiliary locking script, when executed by the first unlocking script of the second primary transaction, is configured to verify that the second primary transaction includes a second counter value, the second counter value being an iteration of the counter value.

[0218] <Statement 16> The first primary transaction is not an initial transaction in the chain of blockchain transactions, the first primary transaction includes a first input that references a first output of a previous auxiliary transaction that includes an auxiliary lock script, the previous auxiliary transaction includes a first input that references a first output of a previous primary transaction that includes the primary lock script, and the auxiliary lock script, when executed by the first unlock script of the second primary transaction, is configured to: vi) verify that the first unlock script of the second primary transaction includes a fourth data item that includes one or more lock scripts of the previous primary transaction; and vii) verify that the first output of the second primary transaction includes the primary lock script based on the second message and the fourth data item. The method of any of statements 1 to 11.

[0219] <Statement 17> The method of statement 16, wherein the previous primary transactions have respective transaction identifiers generated by applying a hash function to the previous primary transaction, the first unlock script of the second primary transaction includes a fifth data item, the fifth data item including a mid-state of the hash function applied to the previous primary transaction, and the auxiliary lock script, when executed by the first unlock script of the second primary transaction, is configured to: vii) generate candidate transaction identifiers based on the fourth data item and the fifth data item and verify that the candidate transaction identifiers match the respective transaction identifiers of the previous primary transaction identifiers.

[0220] <Statement 18> The method according to statement 16 or statement 17, wherein the previous primary transaction is a first primary transaction in a chain of blockchain transactions, and the method includes a step of verifying that the first primary transaction was signed with a signature corresponding to a given public key.

[0221] <Statement 19> A method according to any of the preceding statements, comprising the step of submitting a first primary transaction to a blockchain network.

[0222] <Statement 20> A method according to any of the preceding statements, comprising submitting the first auxiliary transaction and / or the second primary transaction to a blockchain network.

[0223] <Statement 21> A computer-implemented method for verifying that a lock script has been enforced across an entire chain of blockchain transactions, the method being executed by a first party, comprising: obtaining a second primary transaction, the second primary transaction including a first input and a first output, the first input including a second message generated based on the second primary transaction, the first auxiliary transaction including a first input that unlocks a first output of the first primary transaction, the first data item including one or more lock scripts of the first primary transaction, the first output of the first primary transaction including the primary lock script, the first output of the first auxiliary transaction including the auxiliary lock script, and the first output of the second primary transaction including the primary lock script; Verifying that the first primary transaction has been recorded on the blockchain; verifying that the primary locking script of the first primary transaction is configured, when executed by the first unlocking script of the first auxiliary transaction, to: i) verify that the first unlocking script includes a first message generated based on the first auxiliary transaction; and ii) verify, based on the first message, that a first output of the first auxiliary transaction includes the auxiliary locking script, which, when executed by the first unlocking script of the second primary transaction, is configured to: i) verify that the first unlocking script includes a second message; ii) verify that the first unlocking script includes the first data item; and iii) verify, based on the second message and the first data item, that a first output of the second primary transaction includes the primary locking script, thereby verifying that the primary locking script has been enforced across the first primary transaction and the second primary transaction; The method includes:

[0224] <Statement 22> The method of statement 21, wherein the primary locking script includes a hash of the auxiliary locking script, the first message includes a candidate auxiliary locking script, and the primary locking script is configured, when executed by a first unlocking script of the first auxiliary transaction, to verify that a first output of the first auxiliary transaction includes the auxiliary locking script by hashing the candidate auxiliary locking script and verifying that the hash of the candidate auxiliary locking script matches the hash of the auxiliary locking script, and the primary locking script is configured to perform steps i) and ii), the above steps including the step of verifying that the primary locking script includes a hash of the auxiliary locking script as part of the hash puzzle.

[0225] <Statement 23> The method according to Statement 21 or Statement 22, wherein the step of verifying that the first primary transaction was recorded on the blockchain includes a step of obtaining a Merkle proof to prove that the first primary transaction was recorded on a block of the blockchain.

[0226] <Statement 24> The first primary transaction has a respective transaction identifier generated by applying a hash function to the first primary transaction, a first input of the second primary transaction includes a third data item, the third data item includes a mid-state of the hash function applied to the first primary transaction, and the step of verifying that the first primary transaction has been recorded on the blockchain includes the steps of generating a candidate transaction identifier based on the first data item and the third data item, and verifying that the Merkle proof is valid for the candidate transaction identifier. The method according to statement 23.

[0227] <Statement 25> A method according to Statement 23 or Statement 24, comprising the step of obtaining a first primary transaction, wherein the verification that the first primary transaction has been recorded on the blockchain is based on the obtained Merkle proof and the obtained first primary transaction.

[0228] <Statement 26> The method of statement 19 or any statement subordinate thereto, comprising the step of verifying that the second primary transaction includes a respective transaction identifier of the first primary transaction.

[0229] <Statement 27> A step of generating a second auxiliary transaction, the second auxiliary transaction including a first input that references the first output of the second primary transaction and includes a third message generated based on the second auxiliary transaction, and a first output that includes the auxiliary lock script; generating a third primary transaction, the third primary transaction including a first input that references the first output of the second auxiliary transaction and includes a fourth message generated based on the third primary transaction, the first data item, the second auxiliary transaction, and a sixth data item that includes one or more locking scripts of the second primary transaction, the third primary transaction including a first output that includes the primary locking script; The method described in statement 19 or any statement subordinate thereto, including:

[0230] <Statement 28> The method according to statement 27, wherein the auxiliary locking script is configured, when executed by the first unlocking script of the third primary transaction, to: vi) verify that the first unlocking script of the second primary transaction includes the third data item; and vii) verify, based on the third message and the sixth data item, that the first output of the third primary transaction includes the primary locking script.

[0231] <Statement 29> The method of statement 27 or statement 28, comprising the step of transmitting the second auxiliary transaction and the third primary transaction to a third party.

[0232] <Statement 30> A method according to statement 29, comprising a step of transmitting a Merkle proof to a third party to prove that the second primary transaction was recorded in a block of the blockchain.

[0233] <Statement 31> The method of statement 21 or any statement subordinate thereto, wherein the primary locking script and / or the auxiliary locking script contain data regarding token ownership, and the first primary transaction and / or the first auxiliary locking script are generated by a token issuer.

[0234] <Statement 32> The method of statement 27 or any statement subordinate thereto, including submitting the second auxiliary transaction and the third primary transaction to the blockchain.

[0235] <Statement 33> A computer device, a memory comprising one or more memory units; A processing device comprising one or more processing units, the memory storing code configured to be executed on the processing device, the code being configured, when on the processing device, to perform a method according to any of statements 1 to 29; 1. A computer device comprising:

[0236] <Statement 34> A computer program embodied in a computer-readable storage device and configured to execute the method according to any one of statements 1 to 32 when executed on one or more processors.

[0237] According to another aspect disclosed herein, a method may be provided that includes actions of a first party and a second party. According to another aspect disclosed herein, a method may be provided that includes actions of a blockchain node configured to process at least a first primary transaction and a first auxiliary transaction.

[0238] According to another aspect disclosed herein, a system may be provided that includes computer devices of a first party and a second party. According to another aspect disclosed herein, a blockchain node configured to process at least a first primary transaction and a first auxiliary transaction may be provided.< / utid>

Claims

1. 1. A computer-implemented method for enforcing a lock script to be propagated throughout a chain of blockchain transactions, the computer-implemented method being executed by a first party and comprising:

1. A method comprising: generating a first primary transaction including a first output, the first output including a primary locking script; the primary locking script, when executed by a first unlocking script of a first auxiliary transaction, configured to: i) verify that the first unlocking script includes a first message generated based on the first auxiliary transaction; and ii) verify, based on the first message, that the first output of the first auxiliary transaction includes the auxiliary locking script; the auxiliary locking script, when executed by a first unlocking script of a second primary transaction, configured to: i) verify that the first unlocking script of the second primary transaction includes a second message generated based on the second primary transaction; ii) verify that the first unlocking script of the second primary transaction includes a first data item that includes one or more locking scripts of the first primary transaction; and iii) verify, based on the second message and the first data item, that the first output of the second primary transaction includes the primary locking script.

2. generating the first auxiliary transaction, the first auxiliary transaction referencing the first output of the first primary transaction and including a first input comprising the first message and a first output comprising the auxiliary lock script; The method of claim 1 , comprising:

3. 2. The method of claim 1, wherein the primary locking script includes a hash of the auxiliary locking script, the first message includes a candidate auxiliary locking script, and wherein verifying that the first output of the first auxiliary transaction includes the auxiliary locking script includes: the primary locking script hashing the candidate auxiliary locking script and verifying that the hash of the candidate auxiliary locking script matches the hash of the auxiliary locking script.

4. 2. The method of claim 1, wherein the first primary transaction includes a second output, and the auxiliary locking script, when executed by the first unlocking script of the second primary transaction, is configured to: iii) verify that the second output of the first primary transaction is unlocked by a second input of the second primary transaction.

5. 5. The method of claim 4, wherein the auxiliary lock script is configured, when executed by the first unlock script of the second primary transaction, to: iv) verify that the first unlock script of the second primary transaction includes a second data item that includes the first auxiliary transaction; and wherein verifying that the second outputs are unlocked by the second input of the second primary transaction comprises: a) extracting from the second message a transaction identifier for each of the second outputs unlocked by the second input of the second primary transaction; b) extracting from the second data item a transaction identifier for each of the first outputs unlocked by the first input of the first auxiliary transaction; and c) verifying that the respective transaction identifiers extracted during step a) match the respective transaction identifiers extracted during step b).

6. 2. The method of claim 1, wherein the first primary transactions have respective transaction identifiers generated by applying a hash function to the first primary transactions, the first unlock script of the second primary transaction includes a third data item, the third data item including a mid-state of the hash function applied to the first primary transaction, and the auxiliary lock script, when executed by the first unlock script of the second primary transaction, is configured to: iv) generate candidate transaction identifiers based on the first data item and the third data item, and verify that the candidate transaction identifiers match the respective transaction identifiers of the first primary transactions.

7. 2. The method of claim 1, wherein the auxiliary locking script, when executed by the first unlocking script of the second primary transaction, is configured to: v) verify that the second primary transaction includes a particular transaction identifier.

8. generating the second primary transaction, the second primary transaction referencing the first output of the first auxiliary transaction and including a first input including the second message and the first data item, the second primary transaction including a first output including the primary lock script; The method of claim 1 , comprising:

9. The method of claim 1 , further comprising transmitting the first auxiliary transaction and the second primary transaction to a second party.

10. The method of claim 1 , wherein the primary locking script and / or the secondary locking script includes data regarding token ownership.

11. 2. The method of claim 1, wherein the first primary transaction is a first primary transaction in the chain of blockchain transactions.

12. The method of claim 7 , wherein the particular transaction identifier is a transaction identifier for each of the first primary transactions.

13. 2. The method of claim 1, wherein the first primary transaction includes a first counter value, and the auxiliary locking script, when executed by the first unlocking script of the second primary transaction, is configured to verify that the second primary transaction includes a second counter value, the second counter value being a repetition of the counter value.

14. 2. The method of claim 1, wherein the first primary transaction is not a first transaction in the chain of blockchain transactions, the first primary transaction includes a first input that references a first output of a previous auxiliary transaction that includes the auxiliary locking script, and the previous auxiliary transaction includes a first input that references a first output of a previous primary transaction that includes the primary locking script, and the auxiliary locking script, when executed by the first unlocking script of the second primary transaction, is configured to: vi) verify that the first unlocking script of the second primary transaction includes a fourth data item that includes one or more locking scripts of the previous primary transaction; and vii) verify, based on the second message and the fourth data item, that the first output of the second primary transaction includes the primary locking script.

15. 15. The method of claim 14, wherein the previous primary transactions have respective transaction identifiers generated by applying a hash function to the previous primary transactions, the first unlock script of the second primary transaction includes a fifth data item, the fifth data item including a mid-state of the hash function applied to the previous primary transactions, and the auxiliary lock script, when executed by the first unlock script of the second primary transaction, is configured to: viii) generate candidate transaction identifiers based on the fourth data item and the fifth data item, and verify that the candidate transaction identifiers match the respective transaction identifiers of the previous primary transactions.

16. 15. The method of claim 14, wherein the previous primary transaction is an initial primary transaction in the chain of blockchain transactions, the method comprising verifying that the initial primary transaction was signed with a signature corresponding to a predetermined public key.

17. 1. A computer-implemented method for verifying that a lock script has been enforced across an entire chain of blockchain transactions, the computer-implemented method being executed by a second party and comprising: obtaining a second primary transaction, the second primary transaction including a first input and a first output, the first input including a second message generated based on the second primary transaction, a first auxiliary transaction including a first input that unlocks a first output of the first primary transaction, and a first data item including one or more lock scripts of the first primary transaction, the first output of the first primary transaction including a primary lock script, the first output of the first auxiliary transaction including an auxiliary lock script, and the first output of the second primary transaction including the primary lock script; Verifying that the first primary transaction has been recorded on the blockchain; verifying that the primary locking script of the first primary transaction, when executed by a first unlocking script of the first auxiliary transaction, is configured to: i) verify that the first unlocking script includes a first message generated based on the first auxiliary transaction; and ii) verify, based on the first message, that a first output of the first auxiliary transaction includes an auxiliary locking script; wherein the auxiliary locking script, when executed by a first unlocking script of the second primary transaction, is configured to: i) verify that the first unlocking script includes the second message; ii) verify that the first unlocking script includes the first data item; and iii) verify, based on the second message and the first data item, that the first output of the second primary transaction includes the primary locking script, thereby verifying that the primary locking script has been enforced across the first primary transaction and the second primary transaction; A method comprising:

18. 18. The method of claim 17, wherein the primary locking script includes a hash of the auxiliary locking script, the first message includes a candidate auxiliary locking script, and the primary locking script, when executed by the first unlocking script of the first auxiliary transaction, is configured to verify that the first output of the first auxiliary transaction includes the auxiliary locking script by hashing the candidate auxiliary locking script and verifying that the hash of the candidate auxiliary locking script matches the hash of the auxiliary locking script, and wherein verifying that the primary locking script is configured to perform steps i) and ii) includes verifying that the primary locking script includes the hash of the auxiliary locking script as part of a hash puzzle.

19. A computer device comprising: a memory comprising one or more memory units; A processing device comprising one or more processing units, the memory storing code configured to be executed on the processing device, the code configured to execute the method of any one of claims 1 to 10 when present on the processing device; 1. A computer device comprising:

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

Images