A protocol for validating blockchain transactions

Abstract

To provide a computer-implemented method and a calculation device that validate transactions for recording in a blockchain.SOLUTION: A method applies a protocol that validates each received transaction 152. A protocol is configured to include a termination opcode in an output script of the transaction. The termination opcode, when executed by a node, is configured to terminate execution of the output script and not invalidate a transaction merely by including the termination opcode in the output script. The protocol is configured to not include any instance of the termination opcode in the input script of a transaction, and to cause a node to invalidate a transaction when any instance of the termination opcode is included in the input script.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] This disclosure describes a protocol for validating blockchain transactions. Related to the implementation of [Background technology]

[0002] A blockchain is a form of distributed data structure in which multiple nodes in a peer-to-peer (P2P) network each maintain a duplicate copy of the blockchain. A blockchain contains a chain of blocks of data, with each block containing one or more transactions. Each transaction points backward to the previous transaction in the sequence, leading back to the genesis block at the beginning of the blockchain. Transactions can be submitted to the network for inclusion in new blocks. New blocks are produced by a process known as "mining," which involves multiple competing mining nodes each performing "proof of work," i.e., solving a cryptographic puzzle based on a pool of pending transactions waiting to be included in a block.

[0003] Traditionally, transactions within a blockchain are used to transfer digital assets, i.e., data that acts as a store of value. However, blockchains can also be used to layer additional functionality on top of the blockchain. For example, blockchain protocols allow for the storage of additional user data in the output of a transaction. Modern blockchains increase the maximum amount of data that can be stored within a single transaction, allowing more complex data to be incorporated. For example, it may be used to store electronic documents or even audio or video data within the blockchain.

[0004] Each node in the network may have one, two, or all three roles: forwarding, mining, and storage. Forwarding nodes propagate transactions throughout the network's nodes. Mining nodes mine transactions into blocks. Storage nodes each store their own copies of mined blocks in the blockchain. To record a transaction on the blockchain, a party sends the transaction to one of the network's nodes to be propagated. Mining nodes that receive a transaction can compete to mine the transaction into a new block. Each node is configured to adhere to the same node protocol, which may include one or more conditions for a transaction to be valid. Invalid transactions will not be propagated or mined into a block. Assuming the transaction is validated and thereby accepted into the blockchain, the transaction (including any user data) remains stored as an immutable public record at each node in the P2P network.

[0005] Miners who successfully solve a proof-of-work puzzle and create the latest block are typically rewarded with a new transaction, called a "generation transaction," that creates a new amount of digital assets. Proof-of-work incentivizes miners not to cheat the system by including double-spending transactions in their blocks, because doing so requires a large amount of computer resources to mine the block, and blocks containing double-spending attempts are likely not accepted by other nodes.

[0006] In an “output-based” model (often called a UTXO-based model), the data structure of a given transaction contains one or more inputs and one or more outputs. Any usable output contains an element specifying the amount of digital assets, often called a UTXO (“unspent transaction output”). The output may further contain a locking script that specifies the conditions for redeeming the output. Each input contains a pointer to such an output in a preceding transaction and may further contain an unlocking script to unlock the locking script of the pointed-to output. We then consider a pair of transactions, called the first and second transactions (or “target” transactions). The first transaction contains at least one output specifying the amount of digital assets and a locking script that defines one or more conditions for unlocking the output. The second, target, transaction contains at least one input containing a pointer to the first transaction’s output and an unlocking script to unlock the first transaction’s output.

[0007] In such a model, when a second target transaction is sent to the P2P network to be propagated and recorded in the blockchain, one validity condition applied by each node would be that the unlocking script satisfies all of one or more conditions defined in the locking script of the first transaction. Another would be that the output of the first transaction has not yet been redeemed by another preceding valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate it and will not include it in mining blocks to be recorded in the blockchain.

[0008] Another type of transaction model is the account-based model, where each transaction determines the amount to be transferred not by referencing the UTXO of a transaction that precedes it in the sequence of past transactions, but rather by referencing absolute account balances. The current state of every account is stored separately to the blockchain and is constantly updated by miners.

[0009] Blockchain protocols may use a scripting language for transactions. A script is essentially a list of elements, which may be data or instructions. The instructions are referred to in the literature as script words, opcodes, commands, or functions. Opcodes (short for operation code) perform predefined operations on the data in the script. Summary of the Invention

[0010] One such opcode is OP_RETURN. In the original blockchain protocol, the purpose of OP_RETURN was to terminate script execution, not invalidate the transaction containing the script. However, this led to malicious attacks when OP_RETURN was included in the input script of a transaction. Specifically, any input script of a transaction containing OP_RETURN could be used to unlock the output script of a previous transaction. Therefore, in existing blockchain protocols, the protocol was modified so that the opcode OP_RETURN represents a provably unspendable transaction output, allowing for data storage on the blockchain. In existing protocols, the OP_RETURN opcode is used to terminate script execution and simultaneously invalidate the transaction. However, this resulted in a loss of functionality within the blockchain because a transaction with OP_RETURN in its input script could not produce a 'TRUE' (or valid) execution result when executed with any unlocking script.

[0011] According to one aspect disclosed herein, a computer-implemented method for validating transactions for recording in a blockchain is provided, the method including: receiving one or more transactions at a node of a blockchain network; and, for each received transaction, applying a transaction validation protocol, the protocol configured to allow a termination opcode to be included in the transaction's output script, the termination opcode being configured, when executed by the node, to a) terminate execution of the output script and b) not invalidate the transaction based solely on the inclusion of the termination opcode in the output script; and the protocol configured to disallow any instance of the termination opcode from being included in the transaction's input script, the disallowing including the node at least invalidating the transaction if any instance of the termination opcode is included in the input script.

[0012] For each of a plurality of transactions, including the target transaction, at least some nodes in the network are configured to propagate each transaction, provided that the transaction is valid, and at least some nodes are configured to record each transaction in that node's copy of the blockchain, provided that the transaction is valid. The validity of the transaction is subject to the above protocol, according to which, when a particular opcode is invoked, the script only terminates and, importantly, the transaction is not invalidated. For example, the validity of a transaction may depend on the top element of the stack.

[0013] For simplicity, hereinafter, the terminating opcode will be referred to as “OP_RETURN.” However, the present disclosure is not limited to opcodes with such a particular label. More generally, although embodiments will be described with reference to “OP_RETURN” in a blockchain scripting language, similar teachings can be implemented using any opcode that, when invoked by a script engine (e.g., a script interpreter), performs a specific function, which terminates script execution while not invalidating the transaction. References to first and second instances of an opcode should be interpreted as instances of the same type of opcode.

[0014] The protocol restores transaction functionality by allowing input scripts to be validly executed when executed together with output scripts, while preventing fraudulent attacks by ensuring that an input script with OP_RETURN cannot be used to unlock any output scripts.

[0015] A node is configured to validate or invalidate transactions it processes based on the above protocol. That is, when a node processes a transaction, if OP_RETURN is included in the transaction's output script (or more than one output script), then OP_RETURN, if called, will result in the output script terminating. The inclusion of OP_RETURN in an output script does not invalidate the transaction; a transaction may be invalidated for other reasons. On the other hand, if OP_RETURN is included in a transaction's input script, then the node is configured to always invalidate the transaction. Here, the inclusion of OP_RETURN in any input script will result in the transaction being invalidated. In some examples, before executing a script, the node scans for any instances of OP_RETURN in the input script, and if any such instances are present, the node is configured to invalidate the transaction, i.e., before executing the input script.

[0016] Each type of node in a blockchain network may implement the same protocol. A node in a blockchain network may be, for example, a mining node, a forwarding node, or a storage node, each having one or more of the same functions, as described below. For example, if a node is a forwarding node, the forwarding node may only forward a transaction to one or more nodes in the blockchain network, provided that the transaction is valid according to the protocol, including at least the condition that the OP_RETURN opcode is not present in any input script of the transaction. [Brief explanation of the drawings]

[0017] To promote an understanding of 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. [Figure 2] 1 illustrates schematically some examples of transactions that can be recorded on a blockchain. [Figure 3] FIG. 1 is a schematic block diagram of another system for implementing a blockchain. [Figure 4] FIG. 1 is a schematic block diagram of the node software for executing transactions. [Figure 5a] Here is an example of an initiation transaction TxIn, where each input contains a commitment r from a player: [Figure 5b] An example oracle transaction, TxOracle, is shown, where output 0 transfers digital assets to a party and output 1 generates a random number. [Figure 6a] An example of an off-block script interpreter jumping to outpoint address 1 in output 0 of a composite function transaction. [Figure 6b] An example of a compound function transaction incorporating multiple possible jumps between outpoints is given. [Figure 7] This is an example of unpacking a loop from the synthesis script function for the Euclidean algorithm for inputs a=105 and b=28. [Figure 8] An example of elliptic curve point multiplication with inputs 5,G, where the alt stack (shown shaded) is shown alongside the main stack. DETAILED DESCRIPTION OF THE INVENTION

[0018] FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 includes a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes multiple nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer's computing equipment, with different ones of the nodes 104 belonging to different peers. Each 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). Each node also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks; electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs; and / or optical media such as optical disk drives.

[0019] The blockchain 150 includes a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple nodes in the P2P network 160. Each block 151 in the chain includes one or more transactions 152, where transaction in this context refers to a type of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain typically uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 includes at least one input and at least one output. Each output specifies a quantity representing an amount of digital assets belonging to a user 103, and the output is cryptographically locked to that user (requiring that user's signature to unlock and thereby redeem or spend). Each input points backward to the output of the preceding transaction 152, thereby linking the transactions together.

[0020] At least some of the nodes 104 act as transfer nodes 104F, which transfer and thereby propagate transactions 152. At least some of the nodes 104 act as miners 104M, which mine minor blocks 151. At least some of the nodes 104 act as storage nodes 104S (often referred to as "full copy" nodes), with each node storing its own copy of the same blockchain 150 in its respective memory. Each miner node 104M also maintains a pool 154 of transactions 152 waiting to be mined into a block 151. A given node 104 may be a transfer node 104, a miner 104M, a storage node 104S, or any combination of two or all of these.

[0021] For a given current transaction 152j, its (each) input contains a pointer that references the output of the preceding transaction 152i in the sequence of transactions, specifying that this output is redeemed or "spent" in the current transaction 152j. In general, a preceding transaction can be any transaction in the pool 154 or any block 151. While a preceding transaction 152i does not necessarily need to exist at the time the current transaction 152j is created or even sent to the network 106, a preceding transaction 152i does need to exist and be verified for the current transaction to be valid. Thus, "preceding" in this context refers to preceding in the logical order linked by the pointer, not necessarily the time of creation or transmission in the chronological order, 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 can also be referred to as a preceding transaction or a previous transaction.

[0022] The input of the current transaction 152j also includes the signature of user 103a, and the output of the previous transaction 152i is locked to that user. The output of the current transaction 152j can then be cryptographically locked to new user 103b. Thus, the current transaction 152j can transfer the amount defined by the input of the previous transaction 152i to the new user 103b defined by the output of the current transaction 152j. In some cases, a transaction 152j may have multiple outputs to divide the input amount among multiple users (one of which may be the original user 103a to effect the change). In some cases, a transaction may have multiple inputs, collecting amounts from multiple outputs of one or more previous transactions and redistributing them into one or more outputs of the current transaction.

[0023] The above is sometimes called an "output-based" transaction protocol, and sometimes called an Unspent Transaction Output (UTXO) type protocol (the outputs are called UTXOs). A user's total balance is not determined by any one number stored in the blockchain 151; instead, the user needs a special "wallet" application 105 to collate the values ​​of all of that user's UTXOs, which may be spread across many different transactions 152 in the blockchain 151.

[0024] Another type of transaction protocol is sometimes called an "account-based" protocol, as part of an account-based transaction model. In an account-based system, each transaction determines the amount to be transferred not by referencing the UTXO of a previous transaction backward in the sequence of past transactions, but rather by referencing an absolute account balance. The current state of every account is stored and constantly updated by miners distributed across the blockchain. In such a system, transactions are ordered using the account's running transaction tally (also called "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may be signed in the transaction. This data field can indicate a previous transaction, for example, if the previous transaction ID is included in the data field.

[0025] In either type of transaction protocol, when a user 103 wishes to enact a new transaction 152j, he / she sends the new transaction from his / her computer terminal 102 to one of the nodes 104 of the P2P network 106 (which today is usually a server or a data center, but could in principle be another user terminal). This node 104 checks whether the transaction is valid according to a node protocol applied by each node 104. The details of the node protocol will form the overall transaction model and correspond to the type of transaction protocol used by the blockchain 150 in question. The node protocol typically requires the nodes 104 to check that the cryptographic signature of the new transaction 152j matches an expected signature that depends on the transaction 152i that precedes it in the ordered sequence of transactions 152. In the output-based case, this may involve checking that the user's cryptographic signature included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i that the new transaction consumes; the condition typically includes at least checking that the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the new transaction's input points. In some transaction protocols, the condition may be defined, at least in part, by custom script included in the input and / or output. Alternatively, it may be resolved solely by the node protocol, or a combination of these. In either case, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106.At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, and forwarding the new transaction 152j to one or more further nodes 104, etc. In this way, the new transaction is propagated throughout the network of nodes 104.

[0026] In the output-based model, the definition of whether a given output (e.g., a UTXO) is spent is whether it can still be validly redeemed by the input of another forward transaction 152j, according to the node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to spend or redeem has not yet been consumed / redeemed by another valid transaction. Again, if not valid, the transaction 152j is not propagated or recorded in the blockchain. This protects against double spends, where a consumer attempts to spend the same transaction output multiple times. On the other hand, the account-based model protects against double spends by maintaining account balances. Again, because there is a defined order of transactions, an account balance has one defined, single state at a time.

[0027] In addition to validation, at least some of the nodes 104M also compete to be the first to create a block of transactions in a process known as mining, which is supported by "proof of work." Mining nodes 104M add new transactions to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid block 151 of transactions 152 from the pool of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value so that, when the nonce is concatenated with the pool of transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition may be that the hash output has a predetermined number of leading zeros. A property of a hash function is that it has an unpredictable output for a given input. This search can only be performed by brute force and therefore consumes a significant amount of processing resources at each node 104M attempting to solve the puzzle.

[0028] The first miner 104M to solve the puzzle will announce it to the network 106, providing its solution as a proof, which can then be easily checked by other nodes 104 in the network (given the solution to the hash, it is easy to check that it matches the hash output). The pool of transactions 154 for which the winner solved the puzzle will then be recorded as a new block 151 in the blockchain 150 by at least some of the nodes 104 acting as storage nodes 104S, based on checking the winner's announced solution at each such node. A block pointer 155 is also assigned to the new block 151n, which points backward to the previously generated block 151n-1 in the chain. The new block Proof-of-work helps reduce the risk of double spends because a great deal of effort is expended to create 151, and mining nodes 104M are incentivized not to allow double spends to be included in their blocks because any block containing double spends is likely to be rejected by other nodes 104. Once generated, block 151 cannot be modified because it is recognized and maintained at each of the storage nodes 104S in the P2P network 106 according to the same protocol. Block pointers 155 also impose a sequential order on blocks 151. Transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106, thus providing an immutable public ledger of transactions.

[0029] Note that the various miners 104M competing to solve the puzzle at any given time may do so based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they began searching for a solution. Whoever solves each puzzle first determines which transactions 152 will be included in the next new block 151n, updating the current pool 154 of unmined transactions. Miners 104M then continue competing to produce blocks from the newly determined unsolved pool 154, and so on. There is also a protocol for resolving possible “forks,” which occur when two miners 104M solve their puzzles within a very short time of each other, resulting in the propagation of inconsistent views of the blockchain. In essence, whichever prong of the fork extends the longest becomes the final blockchain 150.

[0030] In most blockchains, winning miners 104M are automatically rewarded with a special type of new transaction that creates a new quantity of digital assets that does not exist anywhere (as opposed to a regular transaction that transfers a quantity of digital assets from one user to another). Thus, the winning node is said to have "mined" a quantity of digital assets. This special type of transaction is often called a "generation" transaction. It automatically forms part of a new block 151n. This reward incentivizes miners 104M to participate in proof-of-work. A regular (non-generation) transaction 152 specifies an additional transaction fee in one of its outputs, further rewarding the winning miner 104M who produces the block 151n containing that transaction.

[0031] Due to the computational resources involved in mining, typically each of the miner nodes 104M takes the form of at least one server, including one or more physical server units, or even an entire data center. Each transfer node 104M and / or storage node 104S may also take the form of a server or a data center. However, in principle, any given node 104 could take the form of a user terminal or a group of user terminals networked together.

[0032] The memory of each node 104 stores software 400 configured to run on the processing unit of the node 104 to perform a respective role or roles and process transactions 152 according to the node protocol. It will be understood that any action attributed to a node 104 herein may be performed by software 400 running on the processing unit of the respective computer equipment. Additionally, the term "blockchain" as used herein is a general term that refers to a general type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0033] Also connected to the network 101 are multiple parties 103, each with their own computer equipment 102, who assume the role of consuming users. These parties act as payers and payees in transactions, but do not necessarily participate in mining or propagating transactions on behalf of other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and its / her respective computer equipment 102a, and a second party 103b and its / her respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may exist and participate in the system, but are not shown for convenience. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to herein as Bob, but it will be understood that this is not a limitation and that any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0034] The computer equipment 102 of each party 103 includes a respective processing unit 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 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks; electronic media such as SSDs, flash memory, or EEPROMs; and / or optical media such as optical disk drives. The memory in 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 unit. It will be understood that any action attributed to a given party 103 herein may be performed using software running on the processing unit of the respective computer equipment 102. The computing equipment 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources, that are accessed via the user terminal.

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

[0036] The client application 105 includes at least a "wallet" functionality, which has two main functions. One of these is to allow each user party 103 to create, sign, and send transactions 152 to be propagated throughout the network of nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets he or she currently owns. In an output-based system, this second function involves reconciling the amounts defined in the outputs of various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.

[0037] An instance of a client application 105 on each computing device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This allows the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact one, some, or all of the storage nodes 104 to query the blockchain 150 for any transactions to which the respective party 103 is a recipient (or, indeed, to inspect other parties' transactions in the blockchain 150, since, in embodiments, the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet functionality on each computing device 102 is configured to form and send transactions 152 according to a transaction protocol. Each node 104 executes software 400 configured to validate transactions 152 according to the node protocol and, in the case of a forwarding node 104F, forward the transactions 152 for propagation throughout the network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol, together with a given node protocol, implements a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150 (although a transaction protocol may allow different subtypes of transactions within it). The same node protocol is used by all nodes 104 in the network 106 (although it handles different transaction subtypes differently according to rules defined for that subtype, and different nodes may take on different roles and therefore implement different corresponding aspects of the protocol).

[0038] As described above, the blockchain 150 includes a chain of blocks 151, each of which includes a set of one or more transactions 152 created by the proof-of-work process, as described above. Each block 151 also includes a block pointer 155 that points back to blocks 151 previously created in the chain, establishing a sequential order for the blocks 151. The blockchain 150 also includes a pool of valid transactions 154 awaiting inclusion in a new block by the proof-of-work process. Each transaction 152 includes a pointer to a preceding transaction, establishing an order for the series of transactions (note: a series of transactions 152 is allowed to diverge). The chain of blocks 151 leads back via various paths to the genesis block (Gb) 153, which was the first block in the chain. Initially, one or more original transactions 152 pointed to the genesis block 153, not to a preceding transaction.

[0039] When a given party 103, such as Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she forms the new transaction (using the wallet functionality in her client application 105) according to the associated transaction protocol. She then sends the transaction 152 from her client application 105 to one of one or more forwarding nodes 104F to which she is connected. For example, this could be the forwarding node 104F that is closest or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, it processes it according to the node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which will be described in more detail shortly. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or may be determined by a combination of the script and the node protocol.

[0040] Provided that the newly received transaction 152j passes the tests that qualify it as valid (i.e., it is "validated"), any storage node 104S that receives the transaction 152j will add the newly validated transaction 152 to a pool 154 in the copy of the blockchain 150 that it maintains. Additionally, any forwarding node 104F that receives the transaction 152j will propagate the validated transaction 152 onward to one or more other nodes 104 in the P2P network 106. Because each forwarding node 104F applies the same protocol, assuming the transaction 152j is valid, this means that it will soon be propagated throughout the P2P network 106.

[0041] Once admitted to pool 154 in the copy of blockchain 150 maintained on one or more storage nodes 104, miner nodes 104M begin competing to solve a proof-of-work puzzle for the latest version of pool 154 that contains new transaction 152j. (Other miners 104M may still try to solve the puzzle based on their old view of pool 154, but whoever gets there first will determine where the next new block 151 ends and the new pool 154 begins, and eventually, someone will solve the puzzle for the part of pool 154 that contains Alice's transaction 152j.) Once proof-of-work is done for pool 154 that contains new transaction 152j, it becomes part of one of the blocks 151 in blockchain 150 in an immutable way. Because each transaction 152 contains a pointer back to the previous transaction, the order of transactions is also immutably recorded.

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

[0043] Figure 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following description will be made with reference to an output-based protocol or "UTXO"-based protocol. However, this is not a limitation on all possible implementations.

[0044] In the UTXO-based model, each transaction (“Tx”) 152 includes a data structure containing one or more inputs 202 and one or more outputs 203. Each output 203 may contain an unspent transaction output (UTXO), which can be used as the source of input 202 for another new transaction (if the UTXO has not yet been redeemed). A UTXO specifies a quantity of a digital asset (store of value) and may also include, among other information, the transaction ID of the transaction from which it came. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. 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 submitted to the miner 104M.

[0045] Suppose Alice 103a wishes to create transaction 152j to transfer the amount of digital asset in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes the amount of digital asset locked for Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the next-most transaction in the pool 154. Tx1 can point back to some preceding (i.e., earlier) transaction that still has unspent output 203 locked for Alice.

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

[0047] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, here labeled UTXO0. Each UTXO includes a value specifying the quantity of the digital asset represented by the UTXO and a locking script that defines a condition that must be satisfied by the unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the quantity to a particular party (a payee included in the transaction). That is, the locking script defines an unlocking condition, typically including a condition that the unlocking script in the input of the subsequent transaction include a cryptographic signature of the party to whom the preceding transaction is locked.

[0048] A locking script (also known as 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). A locking script specifies what information is required to consume the transaction output 203, for example, Alice's signature criteria. An unlocking script appears in the transaction output. An unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the locking script's criteria. For example, it could include Bob's signature. An unlocking script appears in the transaction input 202.

[0049] In the example shown, UTXO0 in output 203 of Tx0 is the UTXO of the locking script [Checksig P A ], which means that Alice's signature, Sig P, must be present for UTXO0 to be redeemed (or more precisely, for any subsequent transaction that attempts to redeem UTXO0 to be valid). A [Checksig P A] is the public key P from Alice's public-private key pair. A The Tx1 input 202 includes a pointer back to Tx1 (e.g., by utilizing its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). The Tx1 input 202 includes an index that identifies UTXO0 within Tx0 to identify it among any other possible outputs of Tx0. The Tx1 input 202 further includes an unlocking script that contains Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of the data. <Sig P A (sometimes called a "message" in cryptography). What data (or "message") needs to be signed by Alice to provide a valid signature can be determined by the locking script, by the node protocol, or a combination of these.

[0050] When a new transaction Tx1 arrives at node 104, the node applies its node protocol, which involves running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions set out in the locking 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, "||" denotes concatenation, "<>" means to put data on top of the stack, and "[]" is a function composed by the unlocking script (in this example, a stack-based language). Equivalently, the scripts may be executed one after the other on a common stack rather than concatenating the scripts. In either case, when executed together, the scripts will require Alice's public key P to be included in the locking script in the output of Tx0. A , to authenticate that the locking script in the input of Tx1 contains Alice's signature signing the expected portion of the data. To perform this authentication, the expected portion of the data itself (the "message") must also be included in Tx0. In an embodiment, the signed data includes the entirety of Tx0 (thus specifying the signed portion of the data in plaintext, without requiring that individual elements be included, since they are already inherently present).

[0051] The details of authentication with public-private cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message by encrypting it with her private key, then, given Alice's public key and the message in plaintext (unencrypted), another entity, such as node 104, can authenticate that the encrypted version of that message was signed by Alice. Signatures typically involve hashing the message, signing the hash, and tagging this as a signature on a clear version of 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, part of a transaction, etc., may, in embodiments, mean signing a hash of that portion of data or part of a transaction.

[0052] If the unlocking script of Tx1 satisfies one or more conditions specified in the locking script of Tx0 (in the illustrated example, Alice's signature is provided in Tx1 and authenticated), the node 104 considers Tx1 valid. If it is a storage node 104S, this means adding it to the pool 154 of transactions awaiting proof-of-work. If it is a forwarding node 104F, it forwards transaction Tx1 to one or more other nodes 104 in the network 106, so that it will be propagated throughout the network. Once Tx1 is validated and included in the blockchain 150, it marks the UTXO 0 from Tx0 as spent. Note that Tx1 can only be valid if it consumes unspent transaction outputs 203. If it attempts to consume outputs that have already been consumed by another transaction 152, Tx1 will be invalid even if all other conditions are met. Thus, the node 104 must ensure that the UTX 0 referenced in the preceding transaction Tx0 is not spent. O This requires also checking whether a UTXO 203 has already been spent (whether it already forms a valid input for another valid transaction). This is one reason why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given node 104 may maintain a separate database that marks which UTXOs 203 have been spent in which transactions 152, but what ultimately determines whether a UTXO is spent is whether it already forms a valid input for another valid transaction in the blockchain 150.

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

[0054] Note that the UTXO-based transaction model requires that a given UTXO be spent in its entirety; it is not possible to "keep" part of the amount bounded by a UTXO while spending another part. However, a UTXO amount can be divided among multiple outputs of subsequent transactions. For example, the amount bounded by UTXO0 in Tx0 can be divided among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob all of the amount bounded by UTXO0, she can use the remaining amount to give herself change or pay another party in the second output of Tx1.

[0055] In practice, Alice typically needs to include a fee for the winning miner because, today, the generation transaction reward alone is typically not enough to incentivize mining. If Alice did not include a fee for the miner, Tx0 would likely be rejected by the miner nodes 104M, and thus, while technically valid, it would still not be propagated and included in the blockchain 150 (the miner protocol does not force miners 104M to accept transaction 152 if they do not wish to). In some protocols, the mining 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 indicated by input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the winning miner 104. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference automatically goes to the winning miner 104M. However, it is not necessarily excluded that a miner's fee could alternatively or additionally be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0056] Alice and Bob's digital assets consist of the unspent UTXOs locked to them in any transaction 152 anywhere on the blockchain 150. Thus, a given party's 103 assets are typically distributed across the UTXOs of various transactions 152 throughout the blockchain 150. There is no single number that defines a given party's 103 total balance stored anywhere in the blockchain 150. It is the role of the wallet function in the client application 105 to aggregate together the value of all the various UTXOs locked to each party that have not yet been spent in another forward transaction. This can be done by querying the copy of the blockchain 150 stored on some storage node 104S, such as the storage node 104S closest to or best connected to each party's computing equipment 102.

[0057] Note that script code is often expressed diagrammatically (i.e., not in a strict language). For example, one might say [Checksig P A ] = OP_DUP OP_HASH160 <H(P A )> OP_EQUALVERIFY OP_CHECKSIG implies [Checksig P A] where "OP_..." denotes a specific opcode in the Script language. OP_CHECKSIG (also called "Checksig") is a Script opcode that takes two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any occurrence of the signature ('sig') is removed from the script, but additional conditions, such as a hash puzzle, remain in the transaction that is verified by the 'sig' input. As another example, OP_RETURN is a Script language opcode for generating an unspendable output of a transaction that can store metadata within the transaction, thereby immutably recording the metadata to the blockchain 150. For example, the metadata could include a document that is desired to be stored on the blockchain.

[0058] signature P A is a digital signature. In an embodiment, it is based on ECDSA using the elliptic curve secp256k1. A digital signature signs specific data. In an embodiment, for a given transaction, the signature signs some of the transaction inputs and all or some of the transaction outputs. The specific parts of the outputs it signs depend on the SIGHASH flag, which is a 4-byte code included at the end of the signature that selects which outputs are signed (and is therefore determined at the time of signing).

[0059] Locking scripts are often called "scriptPubKey" to denote the fact that each transaction contains the public key of the locked party. Unlocking scripts are often called "scriptSig" to denote the fact that they provide the corresponding signature. However, more generally, it is not required in all applications of blockchain150 that the condition for redeeming a UTXO include verifying the signature. More generally, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0060] Verification Protocol FIG. 4 illustrates example node software 400 that may execute on each node 104 of the P2P network 106 in an example UTXO or output-based model. The node software 400 includes a protocol engine 401, a script engine 402, a stack 403, an application-level decision engine 404, and a set of one or more blockchain-related function modules (not shown). In any given node 104, these may include any one, two, or all three of a mining module, a forwarding module, and a storage module (depending on the node's role or roles). The script engine 402 may include a script interpreter configured to execute the script by interpreting portions of the script as data elements or functions acting on those data elements and / or by pushing or reading data elements from the stack 403. Alternatively, the script engine 402 may employ other forms of execution, such as just-in-time (JIT) compilation. In general, the term "execute" is used herein in its broadest sense to mean running a script in some manner (as opposed to the narrower sense of running compiled machine code instructions). Therefore, "executing" may include interpretations in this context. Note also that "opcode" in this context does not refer to the opcode of an individual machine code instruction, but rather to a higher-level command that is mapped to a specific function by the script engine 402 in each node 104.

[0061] The protocol engine 401 is configured to recognize the various fields of the transaction 152 and process them according to the node protocol. m ) is received and it is followed by another preceding transaction 152m-1 (Tx m-1) output (e.g., UTXO), the protocol engine 401 m The protocol engine 401 also identifies the unlocking script in the Tx m Based on the pointer in the input of Tx m-1 It identifies and searches for Tx m-1 If the transaction is not already on the blockchain 150, the node can either download it from its own pool 154 of pending transactions or m-1 If Tx is already on the blockchain 150, then Tx is obtained from the copy of block 151 in the blockchain 150 stored in each node or other nodes 104. m-1 In any case, the script engine 401 retrieves the specified Tx m-1 The script engine 402 identifies the locking script in the output of the script engine 402 and passes it to the script engine 402.

[0062] Therefore, the script engine 402 executes the Tx m-1 Locking scripts and Tx m and an unlocking script from the corresponding input. For example, Tx1 and Tx2 are shown in FIG. 4, but the same could apply to any pair of transactions, such as Tx0 and Tx1. The script engine 402 executes the two scripts together as described above, which may include placing data on the stack 403 and popping data from the stack 403 according to the stack-based scripting language used (e.g., Script).

[0063] By executing the scripts together, the script engine 402 determines whether the unlocking script satisfies one or more criteria defined in the locking script, i.e., whether the locking script "unlocks" the contained output. The script engine 402 returns the result of this determination to the protocol engine 401. If the script engine 402 determines that the unlocking script satisfies one or more criteria specified in the corresponding locking script, it returns the result "true." Otherwise, it returns the result "false."

[0064] In the output-based model, a "true" result from the script engine 402 is one of the conditions for the validity of the transaction. Typically, there are also one or more additional protocol-level conditions evaluated by the protocol engine that must be satisfied; for example, Tx m The total amount of digital assets designated by the output of Tx does not exceed the total amount designated by its input, and m-1 The specified output of the transaction Tx has not already been consumed by another valid transaction. The protocol engine evaluates the result from the script engine 402 along with one or more protocol-level conditions and executes the transaction Tx only if they are all true. m The protocol engine outputs an indication of whether the transaction is valid to the application level decision engine 404. Tx m Only under conditions where Tx is actually verified, the decision engine 404 m Each node may choose to control one or both of the mining and transmitting modules to perform its respective blockchain-related functions. This involves transferring Tx to the node's respective pool 154 for mining into blocks 151. m The mining module 405M may add a Tx to another node 104 in the P2P network 106. mNote, however, that in embodiments, the decision engine 404 will not choose to forward or mine an invalid transaction, but this does not necessarily mean that it will conversely trigger the mining or forwarding of a valid transaction simply because it is valid. Optionally, in embodiments, the decision engine 404 may apply one or more additional conditions before triggering one or both of these functions. For example, if the node is a mining node 104M, the decision engine may only choose to mine a transaction if the transaction is both valid and has sufficient mining fees remaining.

[0065] It should also be noted that the terms “true” and “false” in this context are not necessarily limited to returning a result expressed solely in the form of a single binary digit (bit), although this is certainly one possible implementation. More generally, “true” refers to any state that indicates a success or positive outcome, and “false” refers to any state that indicates a failure or negative outcome. For example, in an account-based model (not shown in FIG. 4), a “true” result could be indicated by an implicit protocol-level verification of the signature by node 104 combined with an additional positive output of the smart contract (the overall result is considered to convey true if both individual results are true).

[0066] According to some embodiments, one condition for a valid transaction is that its unlocking script cannot contain any instance of the OP_RETURN opcode or any other such termination opcode that does not mark the transaction as invalid. Protocol engine 401 and / or script engine 402 are configured to detect the presence of such opcodes in a transaction's unlocking script. Upon detecting a termination opcode in a transaction's unlocking script, such as Tx2, protocol engine 401 is configured to mark the transaction as invalid. When a termination opcode is detected in the unlocking script, the transaction is immediately marked as invalid and the script is never executed.

[0067] In additional or alternative embodiments, the node software includes off-chain functionality 405, where the protocol engine 401, script engine 402, and application-level decision engine 404 may be referred to as “on-chain” functionality. On-chain does not mean that the functionality is actually contained within blocks 151. Rather, it means that the functionality is integrated as part of a protocol for validating transactions that are propagated through network 106 and mined into blocks 151. Conversely, off-chain means that the functionality serves a purpose other than validating blocks. In some examples, the purpose may be to generate new transactions, generate template scripts that include complex functions, or perform computations on data obtained from (or resulting from) transaction Tx.

[0068] In these embodiments, the script engine 402 is configured to provide a data element from the stack 403 (e.g., from the top of the stack) to the off-chain function 405. The script engine 402 is configured to read a data element from the stack 403 when invoking OP_RETURN in the locking script of a transaction, Tx1, shown in FIG. 4 . The off-chain function 405 is configured to generate a result based on the data element (or otherwise perform an operation on the data element). In some examples, a data element is read from the stack 403 and recorded in an “off-chain stack,” where the “off-chain stack” is a stack that is not used for purposes of validating transactions. The data element can be read from the stack 403 and provided to the off-chain function each time OP_RETURN is invoked by the script engine 402. The off-chain function 405 can be configured to generate a new transaction using the data element recorded in the off-chain stack. In another example, the off-chain function 405 is configured to use the data element as a reference to a locking script in Tx1. As shown in FIG. 4, Tx1 includes multiple locking scripts 1 through n. The off-chain function 405 interprets the data element as an address or index of a locking script (e.g., as an index of the third locking script) and executes that locking script. Additionally or alternatively, the addressed locking script may be added to a script template stored in memory.

[0069] As detailed above, a transaction must meet several requirements to be valid, i.e., to be propagated throughout the blockchain and mined therein. Embodiments of the present invention relate to implementing modifications to the protocol that specifies the conditions for transaction validity. The modifications to the conditions for transaction validity relate to the inclusion of a particular type of operation code (opcode) in the transaction.

[0070] Blockchain protocols use scripting languages ​​that contain two types of elements: data and opcodes. Data in a script may be, for example, a number, a public key, a signature, or a hash value. Opcodes are functions that operate on the data in the script. In scripting languages, scripts are executed from one end to the other (usually from left to right) and utilize a data structure called a "stack." Data is always pushed onto (i.e., placed on) the stack. Opcodes can pop data off the stack (i.e., pop data from the stack), perform operations on the data, and then optionally "push" new data onto the stack. The stack-based scripting language commonly used in many blockchains is simply called Script. The following is described in terms of the Script language's opcodes.

[0071] Stack-based scripting languages ​​will be familiar to those skilled in the art. The following examples show how exemplary scripts might be implemented. Specifically, exemplary validation and unlocking scripts are shown.

[0072] An example script is:<Bob’s signature><Bob’s public key> OP_DUP OP_HASH<Bob’s public address> Includes OP_EQUALVERIFY and OP_CHECKSIG. The script works from left to right.

[0073]

number

[0074]

number

[0075]

number

[0076]

number

[0077]

number

[0078]

number

[0079]

number

[0080] One particular opcode is the OP_RETURN opcode. In the original blockchain protocol, OP_RETURN had one primary function: to terminate the execution of a script. This means that anything following the OP_RETURN opcode will never be executed, and the final state of the stack will be exactly the same as it was at the time the OP_RETURN acted. For example, the script [ <x>OP_RETURN <y>] is executed, the script element <y>was never executed, and the script remained on top of the (main) stack. <x>and ends.

[0081] However, this protocol was vulnerable to two attacks: 1) Any locking script that begins with OP_RETURN can be redeemed using the unlocking script [OP_1], or an unlocking script with the same effect, where the top stack item is 'truthy'. 2) Any locking script can be redeemed using the unlocking script [OP_1 OP_RETURN] because the locking script is not executed (i.e., it follows OP_RETURN).

[0082] To mitigate the above attack, subsequent protocols (existing protocols) have modified the function of OP_RETURN so that it terminates the execution of the script and causes the execution to fail. This is achieved by first marking the script as invalid and then terminating execution. The advantage of this is that OP_RETURN can be used to produce provably unconsumable output, since no locking script containing OP_RETURN can result in a 'TRUE' execution when executed in conjunction with any unlocking script. A 'TRU' execution (i.e., the top element on the stack represents a true result, e.g., a value of 1) is required for the transaction to be valid.

[0083] This nature of existing protocols has had two major implications for the use of blockchain: 1) Data Storage - Any data following an OP_RETURN is never executed by miners or validators. This means that it can be of any type and format without needing to be compatible with the constraints of stack-based scripting languages. For example, the usual 520-byte limit on data elements that applies to scripts does not apply if preceded by an OP_RETURN. 2) Pruning - Since any OP_RETURN outputs are provably unspendable, there is still no real incentive for miners to retain data about these outputs. This forces miners to selectively prune (i.e., not retain) OP_RETURN UTXO data or metadata.

[0084] The new protocol implemented by nodes according to embodiments of the present invention imposes at least two conditions on the use of OP_RETURN: 1) OP_RETURN is allowed to be included in the output script of a valid transaction. 2) OP_RETURN is not allowed to be included in the input script of a valid transaction.

[0085] Then, according to an embodiment, the function of OP_RETURN is to terminate the execution of the script without invalidating the transaction, i.e., when OP_RETURN is called, the script is stopped and the stack is left unchanged.

[0086] When validating a transaction, a node does not invalidate a transaction based solely on the presence of OP_RETURN in an output script in the transaction's outputs 203. Conversely, a node invalidates a transaction based solely on the presence of OP_RETURN in an input script in the transaction's inputs 202. If a transaction has more than one input, it is sufficient for only one of those inputs to have an input script that includes OP_RETURN for the node to invalidate the transaction. If the locking script includes OP_RETURN, the transaction was never executed and is invalidated without execution.

[0087] Referring to FIG. 1, a first party, Alice 103a, can generate a transaction that includes one or more inputs and / or one or more outputs. As shown in FIG. 2, each input may have an unlocking script to unlock the locking script from a previous transaction. Each output may have a locking script that locks an amount of digital assets to a respective second party, e.g., Bob 103b, which is unlocked by the unlocking script of a later transaction. Alice 103a sends the transaction to a node in the P2P network. A forwarding node 104F checks the transaction for validity before propagating it to one or more other forwarding nodes or to a mining node 104M. Alternatively, the mining node 104M may receive the transaction directly from Alice 103a. Each node determines whether the transaction is valid based at least on the above protocol. If the transaction meets the protocol's requirements in terms of the use of OP_RETURN (and one or more other requirements of the protocol), the transaction is propagated across the network and / or mined against the blockchain.

[0088] In some embodiments, OP_RETURN may only be allowed in a transaction's locking script. Similarly, in some embodiments, OP_RETURN may only be disallowed from a transaction's unlocking script. As described above, each transaction includes one or more inputs, each of which can have an unlocking script, and one or more outputs, each of which can have a locking script. The unlocking script of a given transaction unlocks the locking script of any previous transactions.

[0089] When implementing the protocol, if a node validates a transaction, it means that the transaction does not contain any OP_RETURN in any input script, while other conditions are met. Validating a transaction results in a non-empty, non-zero result in the stack after executing the combination of the unlocking script from the transaction and the locking script from a different transaction. Validating a transaction may additionally or alternatively result in the node forwarding the transaction to one or more nodes in the network, such as miners, who will mine it against the blockchain. Another outcome of validating a transaction is that, if the node is a miner, the miner will mine (i.e., record) the transaction in a block on the blockchain.

[0090] The protocol defined herein advantageously prevents fraudulent attacks and maintains compatibility with existing functionality of the blockchain (i.e., data storage applications). Fraudulent attacks are prevented by ensuring that OP_RETURN cannot be present in a transaction's unlocking script. Existing functionality requires that OP_RETURN be present before OP_RETURN in the transaction's output (e.g., locking script). <0> This can be achieved by including: <0> is any element that is zero that is pushed onto the stack. For example, a zero opcode, OP_0, may precede an OP_RETURN. This allows provably unspendable transaction outputs to be added to the transaction's locking script, for example, by [OP_0 OP_RETURN<arbitrary data> ]. The arbitrary data may be, for example, one or more of image data, text data, video data, and audio data. As an example, a video file or a legal document may be included in the output of the transaction.

[0091] An additional benefit of OP_RETURN being able to be effectively executed when in an output script is that it provides off-block (or off-chain) functionality, as described below.

[0092] Script elements in the locking script before OP_RETURN is called (those executed before OP_RETURN) are available as input to off-chain functions. In other words, when a locking script is executed, there will be data left on at least one stack (e.g., the Main stack or the Alt stack). This data can be read from the stack and fed to functions for off-chain purposes.

[0093] For example, the function can create a new transaction based on data read from the stack. Data may be read from the stack and stored on a "return" stack, i.e., a stack separate from the Main and Alt stacks.

[0094] As another example, data left on the stack may be used as a reference for another part of the transaction. For example, the data could be interpreted by a function as the index (or address) of an output within the transaction. The function can then execute the locking script contained in the referenced output. In this sense, the function acts as an "off-chain script interpreter" that identifies and executes locking scripts. This can be used to create off-chain loops.

[0095] Creating a new transaction In some embodiments, the function is configured to generate a new transaction based on the data element. The new transaction can be generated and sent any time after the initial transaction is executed. The function can generate a transaction based on the data element directly or by first performing an operation on the data element. The new transaction can be sent to one or more nodes 104 of the blockchain network 106 for propagation throughout the network and / or recording in the blockchain.

[0096] As an example, the function may generate at least some of the inputs (e.g., public keys, signatures, random variables) for the new transaction. Additionally or alternatively, the function may generate at least some of the outputs (e.g., amounts of digital assets to transfer) for the new transaction.

[0097] The new transaction may include an output with a locking script. That locking script may contain a portion of a script that should be executed before OP_RETURN is called. At least part of the locking script may be based on a data element provided to an off-chain function. Again, when OP_RETURN is called, the locking script will terminate and a new data element will be left on the stack. This data element may be read from the stack and provided to an off-chain function, for example, to generate further transactions. This allows a loop of transactions to be constructed, where each further transaction is based on a data element resulting from the execution of the locking script of the preceding transaction.

[0098] In the blockchain script example, there are two stacks: the Main Stack and the Alt Stack. When validating a transaction, the script is executed on the stack. During execution, nothing other than the predefined script can write to the stack. However, it is recognized in this case that it is possible to use an external function (or agent) to read data from the stack immediately after execution has finished. Below, we describe the use of a third stack: an off-chain stack called the "Return Stack." The function of the Return Stack is to read and record data from the Main Stack and Alt Stack after the script has executed, e.g., to link the blockchain to the outside world. The data stored on the Return Stack is then sent off-chain. They can be fed into chain functions to provide additional functionality, for example, to the next script execution, to generate new transactions, or for some other off-chain computation. Although the term "stack" is used, any data store configured to store data read from the main or alt stack may be used.

[0099] Use Case - Craps Below, an example simulating a casino game called Craps is provided to illustrate the interaction between the return stack and blockchain transactions. This example involves two entities: the casino, Charlie, and the player, Alice. Each of these can be a party 103. In this simplified example, the game of Craps is played as follows: one player, the 'shooter', takes two dice and throws them on the craps table, or presses the 'roll' button if playing online craps.

[0100] When the first number is rolled, there are three possible outcomes: 1. Natural - A 'natural' means the result of the roll is either 7 or 11. If this happens, the player wins and rolls the dice again. 2. Craps - A 2 (also known as Snake Eyes), 3, or 12 is rolled. When this happens, the player loses. However, the round is not over and the player rolls the dice again. 3. Point - The player rolls a 4, 5, 6, 8, 9, or 10. In a real casino, the dealer marks the 'point' (the number rolled) on the table. In online craps games, there is a small button that appears when a point is established. It is usually white and says 'On'. The player must roll the dice again, hoping to land on the same number again. It does not have to be the same dice combination as before. As long as the total is the same, the player wins. If the player rolls a 7, the player is 'sevens out' and they lose, ending that betting round.

[0101] To simplify the game further, in this example we will assume that the outcomes "Natural" and "Craps" end the game. Consider the following initial transactions made by Alice and Charlie:

[0102]

number

[0103] Remarks for TX0: 1) TX0 has two inputs: Alice's bet and Charlie's bet. 2) TX0 has two outputs: each output represents one die. The two outputs can be combined into one. However, having two outputs emphasizes that there are two dice, and that more than one person "throws" the dice. 3) Alice is assumed to be the only player who throws the dice. That is, she knows the private keys for both PK1 and PK2. To allow other players to cast, PK2 can be replaced with a public key of their choice. 4) To prevent Alice from cheating, her public key can be replaced with a 2-out-of-2 MultiSig, which requires signatures from both Alice and Charlie. 5) There are two OP_IFs for each output. If the top stack value is not false, the statement is executed. The top stack value is removed. a. The first one is to check the validity of the signature. If it is true, proceed to "throwing". If it is not true, Charlie can claim the output. Note that Charlie is assumed to be trusted by the players. If not, a lock time can be implemented to ensure that Alice has priority to claim the output. b. The second is to check the validity of the random string provided in the unlocking script. This can be a check on the prefix of the string through a hash puzzle. For example: i. [CHECK_RANDOM_STRING]:="get_first_4_bytes OP_HASH<pre-determined hash value> OP_EQUAL” c. If the random string is not valid, Charlie can claim the output. 6) Assuming the random string is valid and indeed random, the script "OP_HASH <6> OP_MOD generates numbers in the range {0,1,2,3,4,5} with approximately equal probability. These results represent the six possible outcomes from a die roll {1,2,3,4,5,6}.

[0104] To simulate a dice roll, Alice needs to construct two unlocking scripts. She then passes this incomplete transaction TX1 to Charlie, who completes it by adding two random strings.

[0105]

number

[0106] Penalty kick betpool Assume that is controlled by the casino and Charlie is trusted to provide two new random strings. Once TX1 is verified, one execution of the script will look like this:

[0107]

number

[0108] Existing versions of OP_RETURN terminate the script and invalidate the transaction when OP_RETURN is called. However, as implemented by the node in the embodiment described herein, OP_RETURN will mark the transaction as "valid" and leave a number on the stack after execution but before the stack is cleared. The number left on the stack will be read and stored on the return stack.

[0109]

number

[0110] Each result corresponds to a new transaction. By interpreting the results from the return stack, we can build an outcome transaction: Natural - This transaction simply pays Alice the winnings from the outputs in TX1. Craps - The transaction redeems the output in TX1: this pays Charlie. Points - The transaction creates another transaction similar to TX1, which allows Alice to roll the dice again.

[0111] Note that in this example use case, a "natural transaction" or "craps transaction" ends the game, but a "points transaction" keeps the game going. Most importantly, the output of the first throw (the sum of a and b) is stored on the return stack. In other words, the result is the data element that is read from the stack and stored on the return stack. The output of the second throw is then compared to a + b. If they are equal, a transaction will be created for Alice to claim her winnings. Otherwise, another transaction, such as TX0, will be created for Alice to roll the dice again.

[0112] In summary, by having a return stack, we can simulate complex while-loops. Note that this loop exists off-chain and playing craps is just one example of how this loop can be implemented. The use of a return stack can be generalized to many other applications, as demonstrated in the following examples:

[0113] Use Case - Jury Selection This example describes a method for using a group of N participants to achieve random number generation (RNG) in a blockchain script. The method involves a minimum of two transactions: a) Initiating (first) transaction Tx In - Each participant adds their input to and signs an initiation transaction, which includes a public commitment r to a secret value s. This transaction pays the digital asset to an oracle. b) Oracle (Second) Transaction - The oracle (off-chain function) generates a transaction by obtaining a secret value s from each player, and the locking script for that transaction combines the secret values ​​of all N players to generate a random number R. N (first data element) and lock the digital asset to the public key according to that number.

[0114] Random numbers generated in Oracle transaction locking script R N can be used to determine the terms of the next redemption transaction to consume these digital assets. N Because it is provably pseudorandom, it can be used to create other off-chain processes, such as lab experiments that require a seed for a deterministic process. In particular, provably fair jury selection in criminal proceedings could take advantage of this solution.

[0115] The use of provably fair random numbers in off-chain jury selection, generated by on-chain locking scripts, can be further enhanced by introducing a return stack to execute such locking scripts and generate the final random number R. N to an off-chain interpreter.

[0116] A court could be responsible for selecting a jury to participate in criminal proceedings, and the selection should be random so that the jury cannot be 'packed' or unfairly biased in any way. The court could operate hardware and software capable of executing an off-chain return stack. Furthermore, the court could read data from the blockchain, execute transaction scripts, and store the results of these executions in a local return stack. The court-defined procedure for selecting jurors from a pool of N possible jurors is derived from random numbers generated using the on-chain method described above. However, the court need not be involved in the generation process itself, but rather act as a third-party observer of the blockchain, in which case the RNG process could be operated by another third party, such as a lottery company.

[0117] Each time a jury is selected for a criminal trial, the following process occurs: 1) The court requests an on-chain RNG process from service provider T: a. Initial transaction Tx with N participants In is organized and broadcast by T, and b. Oracle Transaction Tx Oracle is generated and broadcast by T. 2) The court In and Tx Oracle is extracted from the blockchain. 3) The court will use the unlocking script to Oracle Run the locking script: a. Tx In The unlocking script is generated by extracting all r values ​​from b. The unlocking script is Oracle is taken out from 4) Top (Main) Stack Item R N (first data element) is copied and stored on the court's return stack. 5) The court's return stack (off-chain stack) is used to select the jury, for example, items from the stack are fed into an off-chain function that takes successive hashes of the random number RN and maps the result to the ID of the eligible citizen.

[0118] To achieve step 4, OP_RETURN is Tx Oracle must be included in the locking script so that it can be used to terminate script execution in step 3. OP_RETURN also terminates transaction execution but does not invalidate the transaction, ensuring that the top stack item is reset to R when script execution is finished. N If OP_RETURN were to invalidate the transaction, the court interpreter would encounter an error at the end, rather than the desired random number.

[0119] The transactions involved in this scenario are shown in Figures 5a and 5b. In step 3 of the jury selection process, the court determines the commitments r1,...,r N The list of initial transactions Tx In and use them as unlocking scripts: [unlocking script] = <r1> <r2>... <r N >

[0120]

number

[0121] The first line of this locking script is used to check that the committed r value is consistent with the initiating transaction. The second line then uses the secret s value, as committed by the r value, to generate a random number R during script execution. N Finally, the third line is just a call to OP_RETURN, which ends the script execution and places R on the top of the main stack. N Leave.

[0122] In step 3 of the jury selection process, the court runs the locking and unlocking scripts above together and either returns a random number RN or the execution fails. If the execution completes successfully, the court can read the random value from the top of the main stack and store it in the return stack of their local machine.

[0123] And this value R N is used to select a jury in a provably fair manner. The entire process can be repeated each time jury selection is required, with Tx In and Tx Oracle The generation of the can be controlled by a court or outsourced to a third party.

[0124] The main advantage of this approach is transparency: the public would be able to read the transactions on-chain and see for themselves that the process is indeed random and unbiased.

[0125] Composite Function In some embodiments, a first transaction (hereinafter referred to as the preceding transaction) may have multiple outputs, each of which may include a locking script (some of which may be the same or different). Each output is referenced by an output address (OA), hereinafter referred to as an output address. This address may be a number that indexes the position of the output in the transaction. At least one of the outputs has a locking script that includes an output address that references a different one of the outputs. For example, the locking script may include a number (e.g., 2) or an opcode (e.g., OP_2), which, when combined with OP_RETURN, can be interpreted as the address of the second output (e.g., the second in the list of outputs).

[0126] A second transaction (hereafter referred to as a new or further transaction), generated sometime after the first transaction, includes one or more inputs, each of which has an unlocking script. At least one of these unlocking scripts references an output of the preceding transaction (hereafter referred to as the first or main output). The first output need not be the first in the output list of the previous output; the label "first" is merely used to indicate that the output is the first one to be invoked.

[0127] When the unlocking script executes, the locking script for the first output is referenced and executed. The locking script for the first output contains at least one output address (OA) (i.e., a data element that can be interpreted as an output address) of an output of the same transaction. The output may be the same output (i.e., the first output) or a different output (e.g., the second output). Here, the second output can mean the second output in the list of outputs of the previous transaction, but the second output does not necessarily mean that. The label "second" is simply used to indicate that the output is the second one to be invoked. The locking script for the first output also contains at least an OP_RETURN opcode. The locking script may also contain additional data elements or opcodes.

[0128] Because OP_RETURN is configured to terminate script execution without invalidating the transaction, when OP_RETURN is called, the output address of the second output will remain on the stack. In some cases, an output address in a locking script is immediately followed by OP_RETURN, meaning there is no data element or opcode between the output address and OP_RETURN. The off-chain function is configured to read the data element left on the stack and interpret it as the output address of one output (in this case, the second output).

[0129] The function can then execute the locking script of the second output. Note that, unlike the normal execution of a locking script, the locking script of the second output is not executed along with the unlocking script. This is because the function is "off-chain," and therefore the purpose of executing the locking script is not to validate transactions with the intent of submitting them to the blockchain network for mining into the blockchain. Instead, one advantage is to build scripts for implementation in, for example, locking scripts or smart contracts.

[0130] The locking script for the second output might contain, for example, the output address of the third output followed by OP_RETURN. Again, "third" is used as a label to distinguish the first and second transactions and does not imply the order of the outputs in the preceding transaction. However, it does not exclude that the first, second, and third outputs are part of an ordered set of outputs in the preceding transaction. In this case, when the locking script for the second output is executed, the output address of the third output is pushed onto the stack. The output address may be a number or other data element that the function is configured to interpret as the output address of one of the outputs, in this case the third output. An off-chain function may then use the third output address to reference the locking script for the third output.

[0131] The process of executing locking scripts can be repeated one or more times. Whenever OP_RETURN is called, the data element at the top of the stack is interpreted as the output address of one of the outputs. One or more outputs of a prior transaction may be executed multiple times. This process may end when each of the locking scripts for each of the outputs has been executed. In some instances, not all outputs of a prior transaction are referenced by either the unlocking script of the second transaction or the outputs of the first transaction.

[0132] Each time a locking script is referenced, the lock can be copied into a script template, i.e., the "to-be-executed script." When the off-chain function finishes executing all referenced locking scripts, the script template contains the contents of the referenced locking scripts except for the OP_RETURN opcode in these locking scripts. In other words, the script template has the script with all loops unpacked, which can be used to build locking scripts without using OP_RETURN for new transactions.

[0133] In other words, given a first transaction that includes multiple outputs, and a second transaction that references one of the outputs in the first transaction, the following steps may be performed:

[0134] Step 1: Check if OP_RETURN exists in the locking script of the referenced output. If so, extract all locking scripts from the first transaction and index them accordingly.

[0135] Step 2: Assuming OP_RETURN is present, copy the locking script and any locking scripts referenced by the unlocking script into the script to be executed.

[0136] Step 3: Run the script you want to run.

[0137] Step 4: When OP_RETURN is called, the first element on the stack is consumed.

[0138] Step 5: Assuming the first element consumed is a valid index, the locking script referenced by the element consumed by OP_RETURN in step 4 is now copied to the beginning of the script to be executed.

[0139] Step 6: Keep running.

[0140] As an example, the first transaction might have the following locking script: Locking script 1: [function 1] OP_2 OP_RETURN Locking script 2: [function 2] Locking Script 3: OP_1 OP_RETURN

[0141] The second transaction may have an unlocking script for locking script 3:x.

[0142] Thus, there are three locking scripts in the first transaction and one unlocking script in the second transaction that references the third output of the first transaction. Functions 1 and 2 are functions within each locking script; for example, they can push data onto the stack and / or act on data. Locking script 3 executes first, causing functions 1 and 2 to execute, locking script 1 (which contains function 1), and then locking script 2 (which contains function 2).

[0143] To perform a transaction: 1. x is pushed onto the stack. 2. Locking script 3 is executed. 3. Locking script 1 is called. 4. Function 1 is executed. 5. Locking script 2 is called. 6. Function 2 is executed. 7. Execution ends.

[0144] When OP_RETURN is called, the unlocking script is not re-executed, nor are any other unlocking scripts executed. Locking script execution is off-chain.

[0145] The off-chain function acts as an off-block (or off-chain) script interpreter. Such an interpreter can help users build complex scripts for implementation in locking scripts and smart contracts. On-chain, OP_RETURN is configured to terminate script execution without invalidating the transaction when called during any validation of a transaction. The off-chain, off-block script interpreter adds a new feature to OP_RETURN. The new feature uses OP_RETURN to build complex script functions, including loops. Some blockchain scripting languages ​​do not allow loops. Therefore, any loops in the built functions will be unpacked before they are put into the locking script.

[0146] Off-chain functions use a single transaction with multiple outpoints (outpoint and output are used interchangeably). The off-block definition of OP_RETURN allows jumping from one outpoint to another within a transaction, and the outpoint index given by the top item on the stack is used to indicate the outpoint to jump to. This is shown in Figures 6a and 6b and can be explained as follows:

[0147] Each outpoint of a transaction contains a locking script. For each outpoint, this locking script can be thought of as a single function. Each outpoint is referenced by a unique OA, which is the index of the outpoint in the transaction.

[0148] There is one outpoint, which can be thought of as the 'main' function, that is executed first. This could be the last outpoint of a transaction, for example.

[0149] Note that transaction outpoints are indexed starting from 0, which is a special value normally reserved for scripts that will fail if followed by OP_RETURN. For simplicity, we will assume below that outpoints are indexed starting from 1.

[0150] When an OP_RETURN is executed, the off-block script interpreter jumps to the OA given by the top item of the stack, adds the opcode of the locking script to its instruction set, and continues execution as before. Apart from popping the top item, the Main and Alt stacks remain unchanged.

[0151] As shown in Figure 6a and Figure 6b, the script interpreter performs the following tasks: ·input: <oa> Operator: OP_RETURN Output: [Locking SCRIPT from <oa> ], <oa>is consumed.

[0152] It is important to emphasize that, apart from the execution of OP_RETURN, the script interpreter is the same as the script interpreter validating the transaction. The above configuration allows for the interpretation of the transaction as a template for a composite function within the script. If the function were compilable, it might be written out with a single outpoint where all loops would have to be unpacked, resulting in long, complex code. However, in embodiments of the present invention, all logic is contained within separate outpoints of the transaction, which can be significantly smaller in size. This logic is easily contractible and more closely related to the previous one. More specifically, this improves code readability, reduces the code base, and enables unit testing.

[0153] Transactions in this format, when unused, are stored in a UTXO set, which can be thought of as a universal 'memory' for Bitcoin in terms of logging data for future reference. Transactions contain everything needed to construct composite functions; no other high-level language is required. This allows for universal agreement on sets of composite functions. This is particularly useful for functions that are likely to be repeated in many applications, such as elliptic curve point multiplication, described below.

[0154] This also allows a UTXO set to be used as a distributed repository for Turing complete code snippets. Besides storing a set of useful composite functions, this repository can be used to outsource the processing of computations that are difficult to perform but easy to verify. Solutions to such computations can then be transferred on the blockchain, in which case digital assets can be redeemed by providing a verifiable, accurate solution in a script. Another possible use case is using a UTXO set as a distributed repository for smart contracts.

[0155] To avoid spending such a transaction in the UTXO set, transaction creator Alice can add OP_CHECKSIGVERIFY (requiring her signature) to the beginning of the locking script. This section can be safely ignored when interpreting the script. Alternatively, a partial transaction can be constructed as described above that contains an outpoint but no inputs, which is sufficient to define the function. Once the composite function has been used to Alice's satisfaction, the transaction is complete and can be submitted or discarded.

[0156] Use Case - Euclidean Algorithm As an example, a transaction TX_[Euclidean_algorithm] could be generated that contains the Euclidean algorithm and has two outgoing points. The transaction inputs are left blank to highlight the outgoing points.

[0157]

number

[0158] The Euclidean algorithm takes two inputs (a, b) and outputs the greatest common divisor (GCD) of a and b. For simplicity, we assume that a > b.

[0159] By design, Note that whenever "OP_RETURN" is called, the off-block interpreter replaces these two items with the entire script saved in the ith outpoint. The loop feature also replaces "OP_RETURN" with the entire script saved in the ith outpoint. This is achieved by having "OP_RETURN". In this use case, the final outpoint of the transaction is the main function and is called first. <1> Any call to "OP_RETURN" "OP_TUCK OP_MOD OP_DUP OP_IF <1> OP_RETURN OP_ENDIF” An example of this is shown in Figure 7. Its implementation is as follows, step by step:

[0160] 1) This input is first pushed onto the stack. 2) Main function <1> OP_RETURN OP_DROP" is called. 3)" <1> OP_RETURN” is “OP_TUCK OP_MOD OP_DUP OP_IF <1> OP_RETURN OP_ENDIF”. 4) "OP_TUCK OP_MOD OP_DUP OP_IF" is executed. 5) If the input is non-zero, then " in the if statement <1> Go to "OP_RETURN" 6)" <1> OP_RETURN” is “OP_TUCK OP_MOD OP_DUP OP_IF <1> OP_RETURN OP_ENDIF”. 7) "OP_TUCK OP_MOD OP_DUP OP_IF" is executed. 8) If the input is non-zero, then " in the if statement <1> Go to "OP_RETURN" 9)" <1> OP_RETURN” is “OP_TUCK OP_MOD OP_DUP OP_IF <1> OP_RETURN OP_ENDIF”. 10) "OP_TUCK OP_MOD OP_DUP OP_IF" is executed. 11) If the input is zero, go directly to "OP_ENDIF" to close the if statement in step 9. 12) Go to "OP_ENDIF" and close the if statement in step 6. 13) Go to "OP_ENDIF" to close the if statement in step 3. 14) Return to the Main function and proceed to "OP_DROP". 15) The result is left on the top of the stack.

[0161] Use Case - Elliptic Curve Point Multiplication For simplicity, this use case involves three functions, abbreviated as [DECIMAL_TO_BINARY], [POINT_ADD], and [POINT_DOUBLE].

[0162]

number

[0163] [POINT_ADD] consumes the first two elements P1 and P2 in the stack and pushes the point addition of P1 and P2 onto the stack.

[0164] [POINT_DOUBLE] is compatible with OP_DUP [POINT_ADD], consuming the first element P in the stack and pushing point 2P onto the stack.

[0165] TX_[POINT_MUL] is a transaction containing a complex script function for elliptic curve point multiplication.

[0166]

number

[0167] The Main function is represented by the last outpoint of the transaction above, and takes two inputs (a, G) and outputs a G. An example is shown in Figure 8. Whenever OP_RETURN is encountered, " OP_RETURN" is replaced with the entire script from the ith outpoint. A step-by-step explanation of what the script does is as follows. In this case, it is assumed that the input (a,G) is pushed onto the stack, and G is the first element in the stack:

[0168] The Main function (outpoint 6) is called. 1) Push G onto the ALT stack. 2) Call [DECIMAL_TO_BINARY] to get the binary representation of a. 3) Move G back out of the ALT stack. 4) Push a 0 onto the ALT stack. This 0 helps identify when the bottom of the ALT stack has been reached. 5) First, look at the first (least significant) bit of a. If it is 1, push G onto the ALT stack. 6) Then push a 1 onto the ALT stack, which indicates that there is a non-zero element next to it on the ALT stack. 7) Outpoint 4 is continuously called until it encounters 2 on the Main stack (indicating the end of the binary sequence). 8) Out point 4, double that point and if the binary bit is 1, push the result onto the ALT stack, followed by a 1 (as explained in step 6). 9) Once out point 4 is complete, there will be a list of points in the ALT stack to be added together. 10) Move the first point from the ALT stack to the Main stack, call out point 5, and start adding points. 11) When the end of the ALT stack is reached, the expected results will be on the Main stack.

[0169] It will be understood that the above embodiments are described by way of example only. For clarity, the embodiments are not limited to opcodes having particular names. Rather, the embodiments are limited to opcodes having particular functions. The term "OP_RETURN" is used for brevity.

[0170] According to a first embodiment of the teachings disclosed herein, there is provided a computer-implemented method for validating transactions for recording in a blockchain, the method including: receiving one or more transactions at a node of a blockchain network; and, for each received transaction, applying a transaction validation protocol, the protocol configured to allow a termination opcode to be included in the transaction's output script, the termination opcode being configured, when executed by the node, to a) terminate execution of the output script and b) not invalidate the transaction based solely on the inclusion of the termination opcode in the output script; and the protocol configured to disallow any instance of the termination opcode from being included in the transaction's input script, the disallowing including the node at least invalidating the transaction if any instance of the termination opcode is included in the input script.

[0171] That is, a transaction is not invalidated purely because of the presence of a termination opcode in the output script. In other words, a transaction is not invalidated based on the termination opcode in the output script itself, but may be invalidated for other reasons, as discussed above.

[0172] According to a second optional embodiment, when a method according to the first embodiment is provided, the output script may be a locking script included in the transaction and the input script may be an unlocking script included in the transaction for unlocking the locking script of a previous transaction.

[0173] According to a third optional embodiment, when a method according to the first or second embodiment is provided, the protocol may be configured to invalidate a transaction based on a combination of an instance of a termination opcode and at least one data element when the output script includes a combination of an instance of the termination opcode preceded by at least one data element. In some instances, for a transaction to be invalidated based on the combination, an instance of a termination opcode must be immediately preceded by at least one data element, i.e., at least one data element and the termination opcode are adjacent elements of the output script. Provably non-consumable outputs enable data storage (e.g., of contracts, media files, documents, etc.) in the blockchain. A data element can be any element of a script (eg, a function, a string, an opcode, etc.).

[0174] According to a fourth optional embodiment, where a method according to the third embodiment is provided, at least one data element may include one or both of: a zero opcode; or a representation of a zero value to create a provably non-consumable output of the transaction.

[0175] According to a fifth optional embodiment, when a method according to any of the first to fourth embodiments is provided, the protocol may be configured to not allow any opcodes to be included in the input script of a transaction, which not allowing includes the node at least invalidating the transaction if any opcode is included in the input script.

[0176] According to a sixth optional embodiment, when a method according to any of the first to fifth embodiments is provided, verifying may include at least one of: the combination of the output script and the input script, after execution by the node, results in a non-empty, non-zero result; the node forwarding the transaction to one or more nodes of the network for recording in the blockchain; and the node recording the transaction on the blockchain.

[0177] According to a seventh optional embodiment, when there is provided a method according to any of the first to sixth embodiments, the method may include executing a transaction on a blockchain network according to a protocol, the first transaction including at least a first output including a first locking script in a stack-based scripting language, the first locking script including a portion of the first locking script to be executed before a first instance of a termination opcode is executed, and the second transaction including a first unlocking script that references the first output in the first transaction, and the method may include, upon executing the first portion of the termination opcode: terminating execution of the first locking script but not invalidating the first transaction; reading a first data element from the at least one stack, the first data element being generated during execution of the portion of the first locking script and the first unlocking script; and providing the first data element to an off-chain function upon reading from the at least one stack, the function being configured to generate a result based on at least the first data element.

[0178] According to an eighth optional embodiment, when a method according to the seventh embodiment is provided, the step of reading the first data element may include recording the first data element in an off-chain stack, and the step of providing may include providing the first data element to an off-chain function upon reading from at least one off-chain stack.

[0179] According to a ninth optional embodiment, when a method according to the seventh or eighth embodiment is provided, the generating step may include a step of consequently generating another transaction in the blockchain network.

[0180] According to a tenth optional embodiment, when a method according to the ninth embodiment is provided, the step of generating another transaction may include the step of generating an input for the another transaction, the input being based on at least the first data element.

[0181] According to an eleventh optional embodiment, when a method according to the ninth or tenth embodiment is provided, the method may include a step of transmitting another transaction to one or more nodes of the blockchain network.

[0182] According to a twelfth optional embodiment, when there is provided a method according to any of the ninth to eleventh embodiments, the method may include executing a third transaction in the blockchain network, the third transaction including at least a second output including a second locking script in a stack-based scripting language, the second locking script including a portion of the second locking script to be executed before the second instance of the termination opcode is executed, and another transaction including a second unlocking script that references the second output in the third transaction; The method may include, upon executing a second portion of the termination opcode of the other transaction: terminating execution of the second locking script but not invalidating the other transaction; reading a second data element from the at least one stack, the second data element being generated during execution of the second locking script portion and the second unlocking script; and providing the second data element, upon reading from the at least one stack, to an off-chain function, the function configured to generate a different result based on at least the second data element.

[0183] According to a thirteenth optional embodiment, where a method according to the seventh embodiment is provided, the first transaction may include multiple outputs, each output including a respective locking script, each of the multiple outputs being referenced by a respective output address, the first data element being the output address that references a second of the multiple outputs, the first output being referenced in the unlocking script of the second transaction; and the off-chain function, when invoking the first instance of the termination opcode, uses the output address loaded from the stack to reference the locking script of the second output.

[0184] According to a fourteenth optional embodiment, when a method according to the thirteenth embodiment is provided, the method may include a step of executing the unlocking script and the first locking script, the step including pushing an output address of the second output onto a stack.

[0185] According to a fifteenth optional embodiment, when a method according to the fourteenth embodiment is provided, the method may include a step of copying the unlocking script and the first locking script to a script template before executing the unlocking script and the first locking script, the script template including the scripts to be executed.

[0186] According to a sixteenth optional embodiment, when a method according to the fifteenth embodiment is provided, the method may include the step of copying the second output locking script to the beginning of the script template when calling the first instance of the termination opcode.

[0187] According to a seventeenth optional embodiment, when a method according to any of the thirteenth to sixteenth embodiments is provided, the method may include the step of executing a locking script on the second output.

[0188] According to an eighteenth optional embodiment, when a method according to the seventeenth embodiment is provided, the locking script for the second output may include a portion of the script to be executed before the second instance of the termination opcode, the portion including an output address referencing a third of the plurality of outputs; Executing the locking script of the second output may include pushing an output address of a third output onto the stack; The function is configured so that when it calls the second instance of the termination opcode, it uses the output address loaded from the stack to reference the locking script on the third output.

[0189] According to a nineteenth optional embodiment, when a method according to the eighteenth embodiment is provided, the method may include the step of copying the locking script of the third output to the beginning of the script template when calling the second instance of the termination opcode.

[0190] According to a twentieth optional embodiment, when a method according to the eighteenth or nineteenth embodiment is provided, the first, second, and third outputs may be listed in order among the multiple outputs.

[0191] According to a 21st optional embodiment, when a method according to the 18th or 19th embodiment is provided, the first, second, and third outputs may not be listed in that order among the multiple outputs.

[0192] According to a twenty-second optional embodiment, when a method according to any of the thirteenth to twenty-first embodiments is provided, the method may comprise the step of executing a locking script of the referenced output and performing an operation of pushing an output address of the respective output onto an off-chain stack; the function is configured to use the output address loaded from the stack to reference the locking script for the next of the multiple outputs when calling each respective instance of the termination opcode for that output; The operation is repeated until each locking script referenced by another locking script in the multiple outputs has been executed.

[0193] According to a twenty-third optional embodiment, when a method according to the twenty-second embodiment is provided, the method may include a step of copying one of the locking scripts to the beginning of the script template each time the locking script is executed.

[0194] According to a twenty-fourth optional embodiment, when a method according to the twenty-third embodiment is provided, the method may include a step of using the script template as a locking script of another transaction, wherein the locking script of the other transaction does not include an instance of a termination opcode.

[0195] According to a twenty-fifth optional embodiment, when a method according to any of the thirteenth to twenty-fourth embodiments is provided, one or more of the locking scripts may have respective functions, and executing the respective locking scripts may include executing the respective functions.

[0196] According to a twenty-sixth optional embodiment, when a method according to the twenty-fifth embodiment is provided, each function may be configured to operate on data in an off-chain stack each time the respective function is executed.

[0197] According to a twenty-seventh optional embodiment, when a method according to any of the thirteenth to twenty-sixth embodiments is provided, the method may include the step of retrieving all locking scripts from the first transaction and indexing them by their output addresses if the first locking script includes an instance of a termination opcode.

[0198] According to a twenty-eighth optional embodiment, when a method according to any of the thirteenth to twenty-seventh embodiments is provided, each output address in each locking script may be a respective data element, and the function may be configured to interpret the respective data element as an output address.

[0199] According to a 29th embodiment of the teachings disclosed herein, there is provided a computer program embodied in a computer-readable storage device, the program being configured to perform the method of any of the 1st to 28th embodiments when executed on a node of a blockchain network.

[0200] According to a 30th embodiment of the teachings disclosed herein, there is provided a computing device, the device including: a memory including one or more memory units; and a processing device including one or more processing units, the memory storing code configured to be executed by the processing device, the code configured, when executed by the processing device, to perform a method of any of the first to twenty-eighth embodiments.

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

[0202] (Appendix 1) 1. A computer-implemented method for validating transactions for recording in a blockchain, comprising: receiving one or more transactions at a node of a blockchain network; and, for each received transaction, applying a protocol to validate the transaction; the protocol is configured to allow a termination opcode to be included in the output script of the transaction, the termination opcode being configured, when executed by the node, to a) terminate execution of the output script, and b) not invalidate the transaction based solely on the inclusion of the termination opcode in the output script; and the protocol is configured to disallow any instance of the termination opcode from being included in an input script of the transaction, the disallowing including the node at least invalidating the transaction if any instance of the termination opcode is included in the input script. (Appendix 2) 2. The method of claim 1, wherein the output script is a locking script included in the transaction, and the input script is an unlocking script included in the transaction for unlocking a locking script of a previous transaction. (Appendix 3) The protocol is: 3. The method of claim 1 or 2, wherein the output script is configured to invalidate the transaction based on a combination of an instance of the termination opcode and at least one data element if the combination includes an instance of the termination opcode preceded by at least one data element. (Appendix 4) The at least one data element is: Zero opcode; or a representation of a zero value to create a provably unspendable output of said transaction; 4. The method of claim 3, comprising one or both of: (Appendix 5) The protocol is: 5. The method of any one of claims 1 to 4, wherein the method is configured to disallow any opcodes from being included in the input script of the transaction, the disallowing including the node at least invalidating the transaction if any opcode is included in the input script. (Appendix 6) The verifying step includes: yielding a non-empty, non-zero result after execution by said node of the combination of said output script and said input script; the node forwarding the transaction to one or more nodes of the network for recording in the blockchain; and the node recording the transaction on the blockchain; 6. The method of any one of claims 1 to 5, comprising at least one of: (Appendix 7) executing a transaction on the blockchain network according to the protocol, wherein a first transaction includes at least a first output including a first locking script in a stack-based scripting language, the first locking script including a portion of the first locking script to be executed before a first instance of the termination opcode is executed; and a second transaction including a first unlocking script that references the first output in the first transaction; When the method executes the first portion of the termination opcode: terminating execution of the first locking script but not invalidating the first transaction; reading a first data element from at least one stack, the first data element being generated during execution of the portion of the first locking script and the first unlocking script; and providing the first data element to an off-chain function upon reading from the at least one stack, the function configured to generate a result based on at least the first data element; 7. The method of any one of appendices 1 to 6, comprising: (Appendix 8) 8. The method of claim 7, wherein the step of reading the first data element includes recording the first data element in an off-chain stack, and wherein the step of providing provides the first data element to the off-chain function upon reading from the at least one off-chain stack. (Appendix 9) 9. The method of claim 7 or 8, wherein the generating step includes a step of generating, as a result, another transaction on the blockchain network. (Appendix 10) 10. The method of claim 9, wherein generating the another transaction includes generating an input for the another transaction, the input based on at least the first data element. (Appendix 11) 11. The method of claim 9 or 10, comprising sending the other transaction to one or more nodes of the blockchain network. (Appendix 12) executing a third transaction on the blockchain network, the third transaction including at least a second output including a second locking script in the stack-based scripting language, the second locking script including a portion of the second locking script to be executed before a second instance of the termination opcode is executed, and the other transaction including a second unlocking script that references the second output in the third transaction; When the method executes the second part of the termination opcode of the other transaction, it comprises: terminating execution of the second locking script but not invalidating the other transaction; reading a second data element from the at least one stack, the second data element being generated during execution of the portion of the second locking script and the second unlocking script; and providing the second data element to the off-chain function upon reading from the at least one stack, the function configured to generate another result based on at least the second data element; 12. The method of any one of appendices 9 to 11, comprising: (Appendix 13) the first transaction includes a plurality of outputs, each output including a respective locking script, each of the plurality of outputs referenced by a respective output address, the first data element being an output address that references a second of the plurality of outputs, the first output being referenced in the unlocking script of the second transaction; and 8. The method of claim 7, wherein when the off-chain function invokes the first instance of the termination opcode, it references a locking script for the second output using the output address loaded from the stack. (Appendix 14) 14. The method of claim 13, comprising executing the unlocking script and the first locking script, the step including pushing the output address of the second output onto the stack. (Appendix 15) 15. The method of claim 14, further comprising copying the unlocking script and the first locking script to a script template before executing the unlocking script and the first locking script, the script template including the script to be executed. (Appendix 16) 16. The method of claim 15, further comprising copying the locking script of the second output to the beginning of the script template when invoking the first instance of the termination opcode. (Appendix 17) 17. The method of any one of claims 13 to 16, further comprising executing the locking script of the second output. (Appendix 18) the locking script for the second output includes a portion of a script to be executed before a second instance of the termination opcode, the portion including an output address that references a third one of the plurality of outputs; executing the locking script for the second output includes pushing the output address for the third output onto the stack; 18. The method of claim 17, wherein the function is configured to reference a locking script for the third output using the output address loaded from the stack when calling the second instance of the termination opcode. (Appendix 19) 19. The method of claim 18, further comprising copying the locking script of the third output to the beginning of the script template when invoking the second instance of the termination opcode. (Appendix 20) 20. The method of claim 18 or claim 19, wherein the first, second, and third outputs are listed in order in the plurality of outputs. (Appendix 21) 20. The method of claim 18 or 19, wherein the first, second, and third outputs are not listed in that order in the plurality of outputs. (Appendix 22) executing a locking script for the referenced output and performing an operation to push an output address of the respective output onto the off-chain stack; the function is configured to use the output address loaded from the stack to reference a locking script for a next one of the plurality of outputs when invoking the respective instance of the termination opcode for the respective output; 22. The method of any one of claims 13 to 21, wherein the operation is repeated until each locking script in the plurality of outputs that is referenced by another locking script has been executed. (Appendix 23) copying one of the locking scripts to the beginning of the script template each time the locking script is executed. 23. The method of claim 22, comprising: (Appendix 24) 24. The method of claim 23, further comprising using the script template as a locking script for another transaction, wherein the locking script for the other transaction does not include an instance of the termination opcode. (Appendix 25) 25. The method of any one of claims 13 to 24, wherein one or more of the locking scripts have a respective function, and executing the respective locking script includes executing the respective function. (Appendix 26) 26. The method of claim 25, wherein the respective functions are configured to operate on data in the off-chain stack at the time the respective functions are executed. (Appendix 27) 27. The method of any one of claims 13 to 26, comprising extracting all locking scripts from the first transaction and indexing them by their output addresses if the first locking script includes an instance of the termination opcode. (Appendix 28) 28. The method of any one of claims 13 to 27, wherein each output address in each locking script is a respective data element, and the function is configured to interpret the respective data element as an output address. (Appendix 29) A computer program embodied in computer-readable storage, the computer program being configured to, when executed on the nodes of the blockchain network, perform the method of any preceding clause. (Appendix 30) a memory including one or more memory units; and a processing device comprising one or more processing units; wherein the memory stores code configured to be executed on the processing unit, the code being configured, when executed on the processing unit, to perform a method according to any one of claims 1 to 28. < / oa> < / oa> < / oa> < / r1> < / x> < / y> < / y> < / x>

Claims

1. 1. A computer-implemented method for validating transactions for recording in a blockchain, comprising: receiving one or more transactions at a node of a blockchain network; and, for each received transaction, applying a protocol to validate the transaction; wherein the protocol is configured to disallow any instance of a termination opcode from being included in an input script of the transaction, the disallowing including the node at least invalidating the transaction if any instance of the termination opcode is included in the input script.

2. The method of claim 1 , wherein the protocol is configured to allow a termination opcode to be included in an output script of the transaction.

3. The protocol is:

3. The method of claim 2, wherein the output script is configured to invalidate the transaction based on a combination of an instance of the termination opcode and the at least one data element if the combination includes at least one data element preceded by the instance of the termination opcode.

4. The at least one data element is: zero opcode; or a representation of a zero value to create a provably unspendable output of said transaction; 4. The method of claim 3, comprising one or both of:

5. The protocol is:

2. The method of claim 1, wherein the node is configured to disallow any opcodes from being included in the input script of the transaction, the disallowing including the node at least invalidating the transaction if any opcodes are included in the input script.

6. The verifying step includes: yielding a non-empty, non-zero result after execution by said node of a combination of an output script and said input script; the node forwarding the transaction to one or more nodes of the network for recording in the blockchain; and the node recording the transaction on the blockchain; The method of claim 1 , comprising at least one of:

7. executing a transaction on the blockchain network according to the protocol, wherein a first transaction includes at least a first output including a first locking script in a stack-based scripting language, the first locking script including a portion of the first locking script to be executed before a first instance of the termination opcode is executed; and a second transaction including a first unlocking script that references the first output in the first transaction; The method, upon executing the first instance of the termination opcode, includes: terminating execution of the first locking script but not invalidating the first transaction; reading a first data element from at least one stack, the first data element being generated during execution of a portion of the first locking script and the first unlocking script; and providing the first data element to an off-chain function as it is read from the at least one stack, the function configured to generate a result based on at least the first data element; 3. The method of claim 2, comprising:

8. 8. The method of claim 7, wherein the generating step includes the step of generating another transaction in the blockchain network as a result.

9. 10. The method of claim 8, further comprising transmitting the other transaction to one or more nodes of the blockchain network.

10. the first transaction includes a plurality of outputs, each output including a respective locking script, each of the plurality of outputs referenced by a respective output address, the first data element being an output address that references a second output of the plurality of outputs, the first output being referenced in an unlocking script of the second transaction; and 8. The method of claim 7, wherein the off-chain function references a locking script for the second output using the output address read from the stack when calling the first instance of the termination opcode.

11. 11. The method of claim 10, further comprising executing the unlocking script and the first locking script, the step including pushing the output address of the second output onto the stack.

12. 12. The method of claim 11, further comprising the step of copying the unlocking script and the first locking script to a script template before executing the unlocking script and the first locking script, the script template including the scripts to be executed.

13. 11. The method of claim 10, further comprising executing the locking script of the second output.

14. the locking script for the second output includes a portion of script to be executed before a second instance of the termination opcode, the portion including an output address that references a third output of the plurality of outputs; executing the locking script of the second output includes pushing the output address of the third output onto the stack; 14. The method of claim 13, wherein the function is configured to use the output address loaded from the stack to reference a locking script for the third output when invoking the second instance of the termination opcode.

15. Executing a locking script of the referenced output and performing an operation to push the output address of each output onto the off-chain stack; the function is configured to use the output address read from the stack to reference a locking script for a next one of the plurality of outputs when invoking the respective instance of the termination opcode for the respective output; 11. The method of claim 10, wherein the operation is repeated until each locking script in the plurality of outputs that is referenced by another locking script has been executed.

16. each time one of the locking scripts is executed, copying the locking script to the beginning of the script template; and using the script template as a locking script for another transaction; and the locking script of the other transaction does not include an instance of the termination opcode.

17. 11. The method of claim 10, further comprising the step of: if the first locking script includes an instance of the termination opcode, extracting all locking scripts from the first transaction and indexing them by their output addresses.

18. 11. The method of claim 10, wherein each output address in each locking script is a respective data element, and the function is configured to interpret the respective data element as an output address.

19. 10. A computer program embodied in computer-readable storage, the computer program being configured to perform the method of claim 1 when executed on the node of the blockchain network.

20. a memory including one or more memory units; and a processing device comprising one or more processing units; 10. A computing device comprising: a memory storing code configured to be executed by the processor, the code configured, when executed by the processor, to perform the method of claim 1.

Images