Restrictions on input of unlock transactions in blockchain

Abstract

To provide a state machine computer implementation method, a system, and a computer-readable storage medium in the structure of a block chain transaction processing including a trustless deterministic parallel state machine.SOLUTION: A process for a trustless and deterministic state machine (2500) includes: verifying that the lock script of the output of a preceding transaction matches the lock script of the output of an unlocked transaction (2508); extracting the current state among a set of possible states from a serialized preceding transaction (2510); acquiring one or more inputs placed on a stack as the result of execution of the lock script (2512); applying a state rule set in order to determine the next state to the set of possible states of the trustless deterministic state machine on the basis of the current state and the one or more inputs (2514); and verifying that the next state is embedded in the unlocked transaction (2516).SELECTED DRAWING: Figure 25

Description

[Technical field]

[0001] The present invention relates generally to computer-implemented methods of processing blockchain transactions, and more particularly to implementing state machines within the framework of blockchain transaction processing, including trustless, deterministic, and concurrent state machines. The present invention further utilizes cryptographic and mathematical techniques to implement security for electronic transfers made on a blockchain network. The present invention is particularly suited for, but not limited to, use in methods and apparatus for processing and conducting smart contract transactions and executing state machines using such smart contract transactions. [Background technology]

[0002] As used herein, the term "blockchain" may refer to any of several types of electronic, computer-based distributed ledgers, including consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. For convenience and purposes of illustration, reference may be made to examples of "Bitcoin" as useful applications described herein, but Bitcoin is only one of many applications to which the technology described in this disclosure may be applied. However, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols, including non-commercial applications, are also within the scope of the present invention. For example, the technology described in this disclosure provides the advantage of utilizing a blockchain implementation that has similar restrictions as Bitcoin with respect to the constraints that may be encoded within a transaction, regardless of whether or not a cryptocurrency exchange occurs.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system composed of blocks, which in turn are composed of transactions and other information. In some examples, a "blockchain transaction" refers to an input message that encodes a structured collection of field values ​​that include data and a set of conditions, where satisfaction of the set of conditions is a precondition for the set of fields to be written to the blockchain data structure. A blockchain system or network may include multiple blockchain nodes and a set of operations. A blockchain node may be configured to perform some or all of the set of operations. The various blockchain nodes may be implemented as computer hardware, computer software, or a combination of both operated by node operators, which may be independent and unrelated to other node operators. Each blockchain node may hold a copy of the blockchain ledger, or a portion thereof. The set of operations includes creating transactions, propagating transactions, reading the blockchain ledger, evaluating the blockchain ledger, generating new blocks for proposed additions to the blockchain ledger (mining), communicating with other blockchain nodes, and providing wallet functionality for users to manage their blockchain assets.

[0004] A blockchain ledger may be decentralized because there is no single blockchain node or entity that determines when the ledger is modified. Instead, blockchain nodes are each programmed with knowledge of the rules of the blockchain protocol and can validate the blockchain ledger and verify that the behavior of other blockchain nodes is consistent with those rules. The term "blockchain" may refer to the fact that a blockchain ledger includes a series of chained blocks, each of which may be represented as a data structure in computer memory, readable by a computer process, and transmittable as a data transmission. A block includes one or more transactions and may be represented as a data structure in computer memory, readable by a computer process, and transmittable as a data transmission. Blocks may be chained such that each new block that is officially added to the blockchain includes an immutable reference to the block immediately preceding it, which may include an immutable reference to the block immediately preceding it, and so on.

[0005] One of the rules of the blockchain protocol is that once a block is added to the blockchain, it cannot be changed, i.e., it is immutable and the only changeable thing in the blockchain ledger is the addition of new blocks. A blockchain node can be programmed as such as a rule so that it cannot modify blocks in its copy of the blockchain ledger, but can only add blocks, and further, can only add blocks after running a validation process on the proposed block to ensure that it complies with the blockchain protocol. Because such blocks are immutable once added to the ledger, the transactions within the block can also be immutable.

[0006] When a blockchain node creates a transaction, it may create a data object containing the details of the transaction and propagate the data object, typically in a peer-to-peer manner, to other blockchain nodes to which it may connect. Some blockchain nodes may act as "miners" and collect one or more transactions, form a data structure corresponding to a block, perform some calculations to verify the transactions put in the block, solve a puzzle, put the solution of the puzzle into the data structure, and attempt to communicate the block to other blockchain nodes. The puzzle may be in the form of a non-trivial calculation specific to the data of the transaction and the current state of the blockchain ledger, such as, for example, the number of blocks in the ledger and the data from the last added block.

[0007] By making the puzzle dependent on transactions, a dishonest blockchain node may not be able to propagate a pre-created block. By solving a non-trivial puzzle, a dishonest blockchain node may not be able to simply inject a block into the blockchain network, but may require the blockchain node to perform a non-trivial computational task to prove that it has provided effort (effectively, showing a solution to a hard problem is a "proof-of-work"). Preferably, in a blockchain protocol, proof-of-work is not easy, but it is easy to verify that the puzzle has been solved and work has been done. That is, other blockchain nodes do not necessarily have to trust the blockchain node proposing to add a new block to the ledger. If verified by other blockchain nodes, that blockchain node can add a new block to the end of its own copy of the blockchain ledger and propagate the new block to other blockchain nodes. Since other blockchain nodes will also perform similar verification, they can also conclude that the block is valid and should be added to the blockchain ledger, so the new block can be added to the blockchain node's copy of the blockchain ledger. If a blockchain node determines that a proposed new block is not valid, it may not add the new block to its copy of the blockchain ledger and may not propagate it. Since blockchain validity is based on consensus, a transaction may be considered valid if a majority of nodes agree that the transaction is valid.

[0008] A blockchain system may operate such that node owners and operators do not necessarily trust other node owners and operators. Instead, the protocol may make it computationally infeasible to perform certain operations not permitted by the protocol, such as amending a previous block, proposing a new block without a corresponding proof-of-work, or including an invalid transaction. Certain trust may not be required if it is computationally infeasible to perform operations not permitted by the blockchain protocol in a way that would go unnoticed by other nodes.

[0009] To include a transaction in a block that is written to the blockchain, (1) a mining blockchain node validates the transaction, (2) the mining blockchain node attempts to propagate the block that contains the transaction, and (3) other nodes validate the validity of the block and the transactions within the block. Because mining blockchain nodes are programmed or configured with these rules in mind, a mining blockchain node is unlikely to include in a block a transaction that fails validation, and such a block will not be accepted by other nodes and the mining node will not earn any profits. One such advantage of mining over some blockchain systems is that if a block is accepted, it is allowed to include a "distribution" transaction, where a certain amount of value is assigned to the operator of that node without requiring a corresponding reduction in value from some other entity. In this way, successful miners can be rewarded by the value generated with the block. Additionally, as explained below, transactions include a transaction fee. The transaction fee also reaches the miner who controls the mining blockchain node, and the miner must ensure that the transaction is valid in order to be compensated.

[0010] Transactions in a blockchain network include various data elements, such as a transaction value, a transaction time, and / or other data elements. In a decentralized distributed ledger system, the ledger is public so that anyone can view the ledger and see the transactions. In a blockchain ledger, there may be a genesis transaction that starts the blockchain and assigns some unit of value to the genesis transaction. In the examples herein, for purposes of illustration, the unit of value is a cryptocurrency, although other variations are possible.

[0011] Transactions other than genesis and distribution transactions involve the “unlocking” of one or more existing transactions on the blockchain ledger and can transfer such transactions when such transactions are added to the blockchain ledger. Each untransferred transaction publicly specifies the requirements necessary to unlock the value of that transaction. A simple requirement is “you must first prove that you are Alice, then you can unlock it”. Alice can then generate a new transaction that “unlocks” the value of that transaction. Now, Alice’s new transaction proves that it came from Alice and has a pointer to its previous transaction. For distribution transactions, although they have transaction value, distribution transactions do not “unlock” previous transactions. Of course, for Alice’s transaction to be accepted into the blockchain network, it cannot reference a transaction that has already been transferred, but must actually prove that Alice created it.

[0012] By the blockchain protocol, and therefore by the consensus of the blockchain nodes, a transaction is not valid if it points to an output of a previous transaction that has already been transferred, i.e. if the ledger contains a valid existing transaction input that points to an output of a previous transaction. To prevent an interloper from generating a new transaction input that "unlocks" a value represented by a previous UTXO, each transaction output contains data that represents the requirements imposed on the claimant generating such a transaction. Since UTXOs are immutable, that data cannot be changed. Of course, transferred transactions can also be immutable.

[0013] In the above example, Alice may have created an unlock transaction, which would allow her to transfer to Bob the value in the previous transaction that only she had the ability to unlock. That is, there is now a new untransferred transaction that only Bob has the ability to unlock, thereby unlocking it. The unlock transaction created by Alice may contain data that corresponds to the requirement that "anyone can freely point to this transaction and unlock all of its value if they can provide enough information to prove that they know Bob's private key." Assuming Bob is careful, he is the only person who can create a valid transaction that unlocks the transaction. In fact, Bob owns the value, and only Bob can unlock it. Note that this does not require Bob to trust the operators of the blockchain nodes, or any other parties with the ability to create transactions. What Bob needs to trust is that a dishonest party cannot take complete control of a majority of the blockchain nodes.

[0014] In certain cases, a transaction may fully unlock exactly one prior untransferred transaction, and a transaction may be fully or not at all transferred by a later transaction. In the general case, a transaction may have one or more inputs and one or more outputs, where each input references an output of a prior transaction (and that output has redeemable value), and each output has redeemable value (remaining untransferred until transferred / referenced by an input of a future transaction). The outputs of a transaction are the redeemable units of that transaction, all of which may be transferred or none of which may be transferred. Note that in the examples described herein, a transaction may be said to be "transferred," which may include the case of transferring fewer than all of the outputs of the transaction if the transaction has outputs of multiple transactions, and "unlocking a transaction," as opposed to unlocking a transaction output, may include the case where an output of a transaction with only one output is transferred.

[0015] If a transaction can have multiple outputs, different transaction outputs of that transaction can be transferred at different times. When a transaction is created, its outputs may be considered untransferred. Each output may be transferred by an input of a later transaction or remain untransferred. If a transaction has an input that attempts to unlock an output of a previous transaction after that output has already been transferred, blockchain nodes will reject it as an invalid transaction.

[0016] If one party, Alice, controls a UTXO with value X, and wants to unlock only a portion of that transaction output, Y, then Alice can specify a new transaction with multiple outputs, one transaction output with value Y that can only be transferred by Bob, and one transaction output with value XY that can only be transferred by Alice. Effectively, the original transaction outputs are transferred in their entirety, but there is a new transaction output that "modifies" Alice's transaction.

[0017] The number of inputs to a transaction and the number of outputs of that transaction do not have to be the same. However, to be a valid transaction, the sum of the values ​​specified in the outputs of the current transaction must not exceed the sum of the values ​​of the outputs of the previous transaction that can be transferred by the inputs of the current transaction, and may be less, with some exceptions. In the case of genesis and distribution transactions, the sum of the values ​​of the outputs can be greater than the sum of the values ​​of the inputs. Or, in the case of a regular transaction that does not require any inputs, the transaction is invalid if the sum of the values ​​of its outputs exceeds the sum of the values ​​of its inputs. In some transactions, the sum of the values ​​of the outputs can be less than the sum of the values ​​of the inputs. In this case, a successful miner adds a transaction fee transaction for the difference, which then creates a reason for the miner to liquidate and process the transaction. In the Bitcoin protocol, this is a coinbase transaction, which is added to a block and has a redeemable output equal to the sum of the transaction fees of all other transactions included in the Bitcoin block (i.e., the sum of the differences between all inputs and outputs of all included transactions) plus a distribution for creating a new block.

[0018] Each output of a transaction contains constraints that must be satisfied to unlock the value of that output. In some blockchain protocols, the constraints are embedded in a "lock script" that specifies the data and script commands that define what these constraints are. The lock script acts as collateral for the value represented in the transaction output. In this case, other actors cannot "unlock" the value represented in the transaction output unless they can "unlock" the transaction output's lock script.

[0019] Each input to an unlock transaction unlocks the output of the previous transaction. The "unlock script" of an unlock transaction input determines whether the unlock transaction unlocks the output of the previous transaction. Thus, a valid transaction specifies at least one input, and each input of a valid unlock transaction includes a pointer to the output of the previous transaction (the output to be transferred) and an unlock script that "unlocks" the lock script. A blockchain node operating according to a corresponding blockchain protocol may execute the lock script and the unlock script together to validate a transaction input. In certain systems, the scripts are stack-based, and a validating blockchain node starts with an empty stack, executes the unlock script that may leave a data object on the stack, and then executes the lock script that may use the data object on the stack.

[0020] When a validating blockchain node combines a lock script and an unlock script and executes that combination, the result after execution will be either "TRUE" or "FALSE". In some cases, a script execution may end with a FALSE result before the script is fully executed. For example, suppose that a particular script execution has two values ​​that are always equal in a valid script execution, regardless of what happens in the script. In the middle of that script execution, a comparison is made between those two values, and if they are not equal, the script execution can stop immediately after that comparison and return a FALSE result. The rest of the script does not need to be executed.

[0021] A validating blockchain node combines the lock script and the unlock script, executes the combination, and if the result is TRUE (i.e., the unlock script contains everything necessary to unlock the transaction outputs), the validating blockchain node verifies that the transaction is valid (assuming other requirements are met, such as proper timestamp, proper format, not pointing to a transaction output that has already been transferred, etc.). If the validating blockchain node verifies that the transaction is valid, it may propagate the transaction. Other blockchain nodes may perform the same calculation to conclude that the transaction is valid. In this way, a valid transaction with inputs that point only to UTXOs and an unlock script that unlocks those UTXOs may propagate and eventually become part of a block that eventually becomes part of the ledger.

[0022] On the other hand, if a dishonest node tries to propagate a dishonest transaction, other nodes will determine that it is dishonest and will not propagate it.

[0023] Once a transaction is valid and accepted into the blockchain, its contents cannot be changed: the lock script is finalized when the transaction is created, but the unlock script is not necessarily finalized at that time, since it is contained within a later unlock transaction and does not need to be created until the later unlock transaction is created.

[0024] Typically, the verifying unlock script is not created by anyone, but only by a party authorized to unlock the output of a previous transaction. As in the above example, the lock script might be of the form "Anyone can freely point to this transaction output, thereby unlocking all predefined values, if they can provide enough information to prove that they know Bob's private key," and the unlock script might be of the form "Bob signs the transaction with his private key, where the result is ABCCC." A validating blockchain node may then process these two statements and reach a TRUE or FALSE conclusion. This process works well if it is easy to verify that ABCCC is a valid signature, easy for Bob (or anyone else who knows Bob's private key) to generate such a signature, and very difficult for anyone else to generate a valid signature without knowing Bob's private key. The result is a transfer of value in a trustless system. The originator of the transaction for which Bob is trying to unlock the lock does not need to trust the system, or even trust Bob, since it is cryptographically difficult to form a valid, verifiable result that would be accepted by consensus of the blockchain nodes without first knowing Bob's private key.

[0025] Blockchain nodes can easily verify that Bob signed the transaction and that the signature is the only requirement of the lock script. Of course, there can be dishonest nodes that don't validate where other nodes do and may validate where other nodes don't, but unless the dishonest nodes can overwhelm the good nodes on the blockchain network, they cannot push invalid transactions or stop valid transactions from propagating or being mined.

[0026] If a node executes the unlock script of a transaction input and the corresponding lock script of the previous transaction input, and each of them evaluates to TRUE, and other validation conditions (if applicable) are met, then the transaction is valid as far as that node is concerned. That node then propagates the validated transaction to other network nodes, which results in a miner node being able to choose to include the transaction in a block. Thus, in order for a transaction to be written to the blockchain, it must (1) be validated by the node receiving it, (2) be relayed to other nodes in the network (only if the transaction was validated), (3) be added to a new block constructed by the miner, (4) be propagated as part of a proposed block, and (5) be accepted by node consensus as an addition to the public ledger of past transactions.

[0027] A transaction may be considered confirmed when enough blocks have been added to the blockchain to make it effectively irreversible. Because transactions are immutable, blockchain protocols can block unilateral reversals of transactions. Of course, if Alice transfers value X to Bob and Alice requests the value X back, Alice can get the value X if Bob agrees. In this case, the Alice-to-Bob-for-X transaction cannot be reversed or cancelled, but there is a new transaction initiated by Bob: the Bob-to-Alice-for-X transaction.

[0028] Once a transaction is included in a block, it is considered immutable, and once a block is committed to the blockchain, it is considered immutable. There may be a short period during which a fork exists in the blockchain and there is some ability to roll back the blockchain, but generally, the longer the time, the less likely a rollback is. Here, unless otherwise noted, we assume that transactions and blocks are immutable after they are fully committed to the blockchain.

[0029] One way to ensure immutability is through the use of cryptographic techniques. For example, there are cryptographic operations, such as hashes and digital signatures, that take as their input some data sequence and provide an output data sequence that corresponds in some way to the input data sequence. The operations may be such that for a given cryptographic output (e.g., a hash or digital signature) generated from a given cryptographic input (e.g., a transaction or block), it is computationally infeasible or impossible, using the available computational resources, to find a different cryptographic input that results in the same cryptographic output. Thus, if the cryptographic input matches the cryptographic output, the verifier can assume that it was the cryptographic input, and not some other modified cryptographic input, that was used to generate the cryptographic output.

[0030] In a blockchain network, where nodes do not need to trust each other, transactions may be so verified and blocks may be so verified, and unverifiable transactions and blocks may be ignored and unused, and transactions and blocks may be considered to be effectively immutable, which may be a consequence of the assumption that if a hash or digital signature correctly corresponds to a transaction or block, then the transaction or block has not been altered from its origin.

[0031] Some blockchain nodes store the entire ledger, while others store only unspent transaction outputs (e.g., in the Bitcoin ledger, UTXOs). UTXOs correspond to redeemable value, and each UTXO preferably has a locking script that does not allow anyone other than the “owner” of that value to easily generate a verifiable unlocking script. Of course, this is not a requirement, but it is expected that any UTXO for which a verifiable unlocking script can be easily generated by anyone will be quickly transferred in a transaction that transfers that value to another UTXO that can only be redeemed by the person who first noticed it. As a result, blockchains can be used to transfer control of cryptocurrency value. More generally, digital assets and transaction records from one participant of a blockchain system to another, including transferred transaction outputs and UTXOs, can be recorded in a public, immutable ledger, making it easy to verify the flow of digital assets and prevent double unlocking of those digital assets.

[0032] In an embodiment, a "digital asset" refers to binary data associated with usage rights. Examples of digital assets include Bitcoin, ether, and Litecoin. As used herein, a "digital asset" may refer to one or more digital assets. For example, a transaction may have multiple inputs, each of which may represent a different digital asset. The digital asset for which control is transferred, in this example, may be a collection of multiple digital assets, with the collection itself being a digital asset. Similarly, a transaction may subdivide and / or combine these multiple inputs to generate one or more outputs, e.g., with a different number of inputs and a different number of outputs.

[0033] In one embodiment, the cryptocurrency is a token-based cryptocurrency, where each token represents a share of an asset (e.g., a stock in a company), and a single transaction includes multiple types of tokens (e.g., stock in one or more different companies). In some embodiments, the digital assets are non-tokenized, such as, for example, Bitcoin. As a result, for example, there is no identifier of the digital asset identified in the blockchain, but rather, control of the digital asset is demonstrated through the ability to generate valid transactions that become recorded on the blockchain. However, it is noted that some blockchain implementations may use tokenized digital assets, for example, such that the digital asset is specifically identifiable using information recorded on the blockchain. While digital assets may be used as cryptocurrency in some embodiments, it is contemplated that in embodiments the digital assets may additionally or alternatively be usable in other contexts. It is noted that the present invention, while applicable to control of digital assets, may be used in other contexts that are technical in nature and utilize blockchain data structures without necessarily involving the transfer of digital assets.

[0034] A transaction may contain lock and unlock scripts, which may form a computational object. Once committed to the blockchain, a transaction may become immutable and its functionality may be used beyond simply the immutable transfer of control over a digital asset in the form of cryptocurrency. In addition to transferring value, immutable transactions may be used to perform other operations, such as notarizing the recording of an event, implementing smart contracts where the rights and obligations of parties are encoded in the transaction, and transferring value according to the terms of the smart contract according to the blockchain protocol.

[0035] In the Bitcoin platform, scripts are written using a stack-based scripting language, although other approaches may be used instead. In some examples, a "stack-based scripting language" refers to a programming language that supports a variety of stack-based or stack-oriented execution models and operations. When executing instructions of a stack-based scripting language, a processor (such as part of a blockchain node) stores data in a first-in-first-out data structure called a stack. The processor may push values ​​onto the top of the stack or pop values ​​off the top of the stack. Various operations performed on the stack may result in pushing or popping one or more values ​​from the top of the stack, performing operations on the values, or changing the order of elements on the stack (this may be equivalent to two pop operations and two pushes, with the first push popping the first item). For example, the OP_EQUAL operation may pop the top two items from the stack, compare them, and push the result (1 if they are equal, 0 if they are not equal) onto the top of the stack. Other operations performed on stacks, such as OP_PICK, may allow an item to be selected from a position other than the top of the stack. In some scripting languages ​​used by some of the embodiments of the present invention, there may be at least two stacks: a main stack and an alternate stack. Some operations in the scripting language can move an item from the top of one stack to the top of another. For example, executing an OP_TOALTSTACK operation causes the processor to move a value from the top of the main stack to the top of the alternate stack. Note that stack-based scripting languages ​​are not limited to operating strictly in a last-in, first-out (LIFO) manner in some cases. For example, a stack-based scripting language may support an operation to copy or move the nth item in a stack to the top (e.g., OP_PICK and OP_ROLL in Bitcoin, respectively).Scripts written in stack-based scripting languages ​​can be pushed onto a logical stack, which can be implemented using any suitable data structure, such as a vector, a list, or a stack.

[0036] Scripts included in transactions can be used to implement smart contracts where the terms of the agreement are encoded into the script. For example, a statement of the form "If Bob pays Carol X and Dave gives permission to the transaction, then Alice pays Bob half of X" can be encoded as part of a locking script that evaluates to TRUE only if there is (among other things) a prior transaction in which Bob paid Carol and a prior transaction in which Dave encoded his permission. As used here, "prior transaction" refers to a transaction that has already been added to the blockchain, not necessarily a prior transaction whose output the unlocking transaction unlocks. In effect, a smart contract can represent a machine-executable program that contains rules that define inputs for producing outcomes, which can result in the execution of actions that depend on those outcomes.

[0037] In addition to transferring value, a transaction may also transfer other objects of value or possessory rights. For example, a transaction may transfer a nominal cryptocurrency value, but may contain data equivalent to the assertion that "whoever can unlock this transaction is also the rightful owner of the house and land at 123 Marley Circle." Possession rights may be obscured in the public records to the same effect. For example, a transaction may contain data equivalent to the assertion that "whoever can unlock this transaction is also the rightful owner of a particular property consigned under consignment number 12345 held at Central Bank of Trust." Here, this is referred to as a token, which represents and causes the transfer of a real-world entity through the blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. Thus, tokens can function as identifiers that allow real-world items to be referenced from the blockchain.

[0038] In some embodiments, interactions with certain entities are encoded in certain steps within a smart contract, and the smart contract may otherwise be self-executing and self-enforcing automatically. In some examples, self-executing refers to the execution of a smart contract that is executed to allow the transfer of a UTXO. In such examples, "any entity" that can unlock a UTXO refers to an entity that can generate an unlock script without being required to prove knowledge of any secret. In other words, an unlock script may be generated without verifying that the source of the data has access to a cryptographic secret (e.g., a private asymmetric key, a symmetric key, etc.). Also, in such examples, self-enforcement occurs as a result of a validating node of the blockchain network validating the unlock transaction according to the constraints of the smart contract. In some examples, "unlocking" a UTXO refers to generating an unlock transaction output that references the UTXO and executes as valid. A side effect of unlocking such a transaction output is that the blockchain network can process the lock and unlock scripts to validate the new transaction, i.e., the unlock transaction. If valid, the output of the previous transaction is considered to have been transferred. There is a reason for a party to create such an unlocking transaction by including a particular value in the transaction output, allowing anyone to unlock that output, and thus the steps of the smart contract are executed by others operating blockchain nodes, rather than by the participants of the smart contract.

[0039] The scripts that form the lock and unlock scripts recorded as part of a transaction may be immutable, so the lock script typically cannot be changed and cannot reference parts of future transactions that it references as they may be unknown at the time the transaction is finalized. The unlock script of a transaction input may reference parts of the output of the previous transaction that the transaction input points to, or previous transactions in the blockchain other than the previous transaction. This may limit how the transaction can be used.

[0040] In one or more of these aspects, it would be desirable to provide additional and improved methods and systems for using blockchain technology.According to the present invention there is therefore provided a system and / or method as defined in the accompanying claims. Summary of the Invention

[0041] In various embodiments of the computer-implemented method, the method comprises: determining a first set of constraints on a first use transaction output; determining a second set of constraints on a second spending transaction output; generating an initial transaction, the initial transaction comprising: at least one initial lock script including the first and second constraint sets; at least one usable value, and using the at least one usable value includes: the first set of constraints is satisfied, at least in part, by verifying that the usage transaction includes the first usage transaction output; and the second set of constraints is satisfied, at least in part, by verifying that the usage transaction includes the second usage transaction output; and having a node of a blockchain network verify the initial transaction; Includes.

[0042] The locking script in the first use transaction output may be a duplicate of the locking script in the second use transaction output.

[0043] The locking script in the first use transaction output may be different from the locking script in the second use transaction output.

[0044] The locking script in the first use transaction output may include at least a portion of at least one initial locking script.

[0045] Execution of the at least one initial locking script may include selecting the at least one portion from a plurality of portions of the at least one initial locking script.

[0046] Execution of an unlock script for the use transaction may result in the at least one initial lock script receiving data corresponding to one of the first use transaction output or the second use transaction output.

[0047] The data may have an index value, and execution of the at least one initial locking script may determine if a first set of constraints is satisfied if the index value is a first index value, and execution of the at least one initial locking script may determine if a second set of constraints is satisfied if the index value is a second index value.

[0048] The data may include a new locking script. As a result of receiving the data, the first use transaction output may be constrained to include the new locking script.

[0049] At least one initial locking script may include a constraint on the source of the data.

[0050] The method may further include determining a usable value of the first use transaction output.

[0051] The initial transaction may encode a contract that has multiple states.

[0052] A usage transaction may include multiple input values ​​corresponding to multiple states.

[0053] A first set of constraints may constrain a first use transaction output to have a first state, and a second set of constraints constrain a second use transaction output to have a second state.

[0054] Further, there is provided a computer-implemented method comprising: determining a use transaction constraint that constrains use transactions to include use transaction inputs that reference outputs of previous transactions; generating an available transaction, the available transaction comprising: A spendable transaction output, including a spendable amount; and an available transaction lock script including a usage transaction constraint, where usage of the available amount is conditioned on execution of at least one unlock script of a usage transaction that satisfies the usage transaction constraint; and having the enabled transaction validated at nodes of the blockchain network.

[0055] The use transaction constraint may further constrain the use transaction input to contain a particular hash value.

[0056] A particular hash value may encode an identifier that references the output of a previous transaction.

[0057] The use transaction constraint may further constrain the use transaction's lock script to include a set of script elements replicated from the available transaction lock script.

[0058] An enabling transaction may encode a contract that has multiple states.

[0059] The method may further include determining a usable value of the output of the usage transaction.

[0060] The use transaction constraint may include a particular lock script element from an output of a previous transaction. As a result of the use transaction input including the particular lock script element, execution of at least one unlock script may satisfy the use transaction constraint.

[0061] A particular lock script element may encode a cryptographic key for a particular entity.

[0062] The usage transaction constraint may be a first usage transaction constraint, the method further comprising: determining a second usage transaction constraint to further constrain the usage transactions; generating a second available transaction, the second available transaction comprising: A second usable amount; and and a second available transaction lock script including a second usage transaction constraint, and using the second available amount may further include a step in which execution of the at least one unlock script satisfies the second usage transaction constraint.

[0063] The available transaction lock script may be a first available transaction lock script, and the at least one unlock script may include a first unlock script and a second unlock script. The first usage transaction constraint may constrain the first unlock script to include at least a portion of the first available transaction lock script. The second usage transaction constraint may constrain the second unlock script to include at least a portion of the second available transaction lock script.

[0064] At least a portion of the first available transaction lock script may include an encryption key associated with a first entity, and at least a portion of the second available transaction lock script may include an encryption key associated with a second entity different from the first entity.

[0065] A use transaction constraint may further constrain a use transaction to constrain the output of the use transaction.

[0066] A use transaction constraint may encode another contract that is distinct from the contract: using the available amount may be conditional on other contracts being implemented in the output of the use transaction.

[0067] Further, there is provided a computer-implemented method comprising: Generating a blockchain transaction, the blockchain transaction comprising: a state machine that is in a first state and has a set of allowed state transitions; encoding a set of script elements to be executed to cause the use transaction to encode a state machine according to a set of allowed state transitions, to obey restrictions on the inputs to the use transaction, or to obey restrictions on the outputs of the use transaction; and having the blockchain transaction validated by nodes of the blockchain network.

[0068] The set of allowed state transitions may include state transitions that can be implemented independently and in parallel in separate blockchain transactions.

[0069] The set of script elements may subject the use transaction to restrictions on the outputs of the use transaction, which may require that a first output of the use transaction exhibit a state corresponding to the first output according to the set of allowed state transitions, and that a second output of the use transaction exhibit a state corresponding to the second output according to the set of allowed state transitions.

[0070] The state corresponding to the first output and the state corresponding to the second output may be the same.

[0071] The state corresponding to the first output and the state corresponding to the second output may be different states.

[0072] The script element set may subject the use transaction to restrictions on the inputs of the use transaction, which may require that the inputs to the use transaction point to another state machine encoded in another blockchain transaction.

[0073] A restriction on an input may require that the input reference a state machine in a first state and that the input reference another state machine in another state different from the first state.

[0074] A first transition from a first state to a second state may be within the set of allowed state transitions. A second transition from another state to the second state may be within the set of allowed state transitions.

[0075] A set of script elements may subject a use transaction to restrictions on the inputs of the use transaction. The restrictions on the inputs may describe a set of conditions for advancing a state machine. The set of conditions for advancing a state machine may depend on the state of another state machine.

[0076] The other state machine may be encoded in another blockchain transaction. The other transaction may encode a set of conditions for advancing the other state machine. The other set of conditions for advancing the other state machine may depend on the state of the state machine.

[0077] A set of script elements may subject a use transaction to restrictions on the output of the use transaction. The output restrictions may require the use transaction to incorporate a set of smart contract elements into the output.

[0078] The set of elements for a smart contract may be obtained from another blockchain transaction.

[0079] A set of script elements may subject a use transaction to both restrictions on the inputs of the use transaction and restrictions on the outputs of the use transaction.

[0080] Further, there is provided a computer-implemented method comprising: generating, at a node of the blockchain network, a blockchain transaction having a transaction output usable by a first use transaction input of a first use transaction; inserting a first set of script elements into the blockchain transaction, the first set of script elements being capable of constraining the first use transaction to include a first use transaction script element set corresponding to an operation of the state machine; and inserting into the blockchain transaction a second set of script elements that may constrain a second set of used transaction script elements that correspond to allowed state machine state transitions that include states implementable with different blockchain transactions that may be independently processed in parallel by the blockchain network. The blockchain transaction may include a first output having a first locking script, the first transaction output value may include a second output having a second locking script and a second transaction output value, and the first set of script elements is part of the first locking script.

[0081] A spend transaction may include an unlock script that, when executed by a transaction validator with the lock script of the output of a previous transaction, cause the node to at least store in a memory accessible to the transaction validator values ​​representing fields of the use transaction when predetermined validation tests are satisfied, executing the locking script of the output of the previous transaction and inserting a first set of script elements into the use transaction, where the first set of script elements forms part of the use transaction locking script of the first output of the use transaction and conforms to requirements dictated by the previous transaction locking script, the first set of script elements corresponding to state machine operations, and inserting a second set of script elements into the use transaction, where the second set of script elements forms part of the use transaction locking script and conforms to requirements dictated by the previous transaction locking script and corresponds to allowed state machine state transitions including states implementable using different blockchain transactions that can be processed independently in parallel by the blockchain network.

[0082] A use transaction may include an input and an output, where the input references an output of a previous transaction. The use transaction includes an unlock script, where the unlock script, when executed by a transaction verifier with a previous transaction lock script of an output of the previous transaction, satisfies a predefined validation test, where the unlock script executes the lock script and inserts data corresponding to additional state machines into the use transaction as use transaction inputs and / or use transaction outputs based on allowed state machine state transitions, such that when the number of use transaction inputs and / or use transaction outputs used in the use transaction is sufficient for the number of state machine transitions, the node at least stores values ​​representing fields of the use transaction in memory accessible to the transaction verifier.

[0083] The permissible state machine state transition includes: generating, for the use transaction, a first transaction output corresponding to a first subsequent state; inserting into the use transaction a first transaction output value of the first transaction output sufficient to cause the first transaction output to be an input of a first subsequent transaction that references the first transaction output; inserting into the first transaction output of the use transaction a third set of script elements, where the third set of script elements is a portion of a first locking script that constrains the first subsequent transaction to assume the first subsequent state; generating, for the use transaction, a second transaction output corresponding to a second subsequent state; inserting a second transaction output value of the second transaction output sufficient to cause the transaction output to become an input of a second subsequent transaction that references the transaction output; inserting a fourth set of script elements into the second transaction output, where the fourth set of script elements is part of a second locking script that constrains the second subsequent transaction to take the second subsequent state; and inserting a fifth set of script elements into the first transaction output or the second transaction output, where the fifth set of script elements is part of the first locking script or the second locking script that imposes a constraint that the first subsequent transaction and the second subsequent transaction are distinct, thereby including a branching transaction from one initial state to two subsequent states.

[0084] The first locking script can constrain the first subsequent transaction to have a first state. The second locking script can constrain the second subsequent transaction to have a second state. The use transaction can include three or more transaction output values ​​corresponding to a divergence of three or more states. The use transaction can include three or more transaction input values ​​corresponding to a fusion of three or more states. The first locking script and the second locking script can constrain the first subsequent transaction and the second subsequent transaction to have the same state.

[0085] Typically, a usage transaction may include N transaction input values ​​and N transaction output values, where N may be 1, 2, 3, or more.

[0086] The permissible state machine state transitions can include a merging transaction from two initial states to one subsequent state by inserting a first transaction input of a first predecessor state into the use transaction, inserting a second transaction input of a second predecessor state into the use transaction, and inserting a merging state into the use transaction that is a permissible transition from the first and second predecessor states according to a state transition matrix.

[0087] The allowed state machine state transitions can be hard-coded into the first transaction input and / or the second transaction input by inserting into the first transaction input a first reference to a first previous transaction having a first predecessor state, into the second transaction input a second reference to a second previous transaction having a second predecessor state, and into the use transaction a first transaction output in a fused state, where state transition matrices are available for the first previous transaction and the second previous transaction.

[0088] The allowed state machine state transitions can include parallel operation from a number N of initial states to N successor states by inserting a first transaction input with a first predecessor state into the use transaction, inserting a second transaction input with a second predecessor state into the use transaction, inserting a first reference to a first previous transaction having the first predecessor state into the first transaction input, inserting a second reference to a second previous transaction having the second predecessor state into the second transaction input, inserting a first transaction output with a first postdecessor state into the use transaction, inserting a third set of script elements into the first transaction output, where the third set of script elements is part of a first locking script that constrains the first postdecessor transaction to assume the first postdecessor state, inserting a second transaction output with a second postdecessor state into the use transaction, and inserting a fourth set of script elements into the second transaction output, where the fourth set of script elements is part of a second locking script that constrains the second postdecessor transaction to assume the second postdecessor state, where N is 2 or greater.

[0089] The state machine operations may be encoded for smart contracts implemented using the blockchain.

[0090] The transactions may be divided by any constraints. The method may include, at a node of a blockchain network, generating a first transaction, the first transaction including a first output having a first usable value and a first locking script, the first transaction including a second output having a second usable value and a second locking script, including in the first locking script a first set of constraints on a first selected transaction output, the first set of constraints being satisfied by a first unlocking script if the first selected transaction output should be validated to spend the first usable value, and including in the second locking script a second set of constraints on a second selected transaction output, the second set of constraints being satisfied by a second unlocking script if the second selected transaction output should be validated to spend the second usable value, the first set of constraints or the second set of constraints imposing constraints on the locking script of a use transaction having the first selected transaction output or the second selected transaction output as a use transaction output.

[0091] The first selected transaction output can be an output of a first use transaction and the second selected transaction output can be an output of a second use transaction different from the first use transaction. The first constraint set can be different from the second constraint set and different from the constraints on the transaction inputs of the first transaction. The first constraint set and the second constraint set can each include a common constraint set. A constraint on the lock script of the use transaction can require that the lock script of the use transaction includes a reference to at least one field of the use transaction for the use transaction to be valid. Another constraint on the lock script requires that the lock script of the use transaction includes a copy of a portion of the first lock script and / or a copy of a portion of the second lock script for the use transaction to be valid.

[0092] The first selected transaction output may be an output of the first use transaction. The second selected transaction output may be an output of the second use transaction. The first unlock script may include a field of the first transaction, a field of the first selected transaction, and a field of the second use transaction. The first lock script may include a first comparison of the extracted fields of the first transaction and a second comparison of the extracted fields of the first use transaction.

[0093] The first and second constraint sets may each include a common constraint set, whereby the two constrained usage transaction output locking scripts are constrained by the common constraint set. The first and / or second constraint sets may include constraints on a hash of a portion of the first locking script and / or a hash of a portion of the second locking script and / or a size of the portion of the first locking script and / or a size of the portion of the second locking script.

[0094] The first set of constraints and / or the second set of constraints may include any reference to input data. Each of the multiple outputs of the first transaction may be constrained by a different constraint that is applied to an output of the multiple outputs.

[0095] The transactions may have any interdependencies with the constraints embodied, such as by a computer-implemented method, comprising: generating, at a node of a blockchain network, a first spendable transaction, the first spendable transaction including a first spendable output having a first spendable value and a first locking script; including, in the first locking script, a first set of constraints on the spend transaction, the first set of constraints being satisfied by the spend transaction's first unlocking script if the spend transaction is to be valid for spending the first spendable output; including, in the first constraint set, a first spend transaction constraint requiring that a first spend transaction output of the spend transaction include a first spend transaction output locking script to include a first set of smart contract script instructions; and including, in the first constraint set, a second spend transaction constraint requiring that the spend transaction include a second set of smart contract script instructions and requiring that the spend transaction include a use transaction input that references the second spendable transaction output.

[0096] The first smart contract script instruction set may include script instructions copied from the first locking script and / or script instructions corresponding to a new smart contract that is different from the smart contract implemented in the first locking script.

[0097] The first set of constraints may be that the first use transaction output locking script includes a reference to a second useable transaction output, and that the second set of smart contract script instructions includes a reference to an output of the first useable transaction.

[0098] The method may include providing in a first set of constraints a first parallel constraint requiring the use transaction to include a first use transaction input that references the first available transaction, a second parallel constraint requiring the use transaction to include a second use transaction input that references the second available transaction output, a third parallel constraint requiring the first use transaction output locking script to include in the first smart contract script instruction set at least a first script instruction set determined at least in part by the first locking script, and a fourth parallel constraint requiring the second use transaction output locking script to include a second smart contract script instruction set determined at least in part by the locking script of the second available transaction output.

[0099] The first set of constraints may include a first parallel constraint requiring the use transaction to include a first use transaction input that references the first usable transaction, a second parallel constraint requiring the use transaction to include a second use transaction input that references the second usable transaction output, a third parallel constraint requiring the first use transaction output locking script to include in the first smart contract script instruction set at least a first set of script instructions copied from the first locking script, and a fourth parallel constraint requiring the second use transaction output locking script to include a second set of smart contract script instructions copied from the locking script of the second usable transaction output.

[0100] Further, there is provided a computer-implemented method comprising: determining a first set of constraints on the first unlocking transaction output; determining a second set of constraints on the second unlocking transaction output; generating an initial transaction, the initial transaction comprising: at least one initial lock script including the first and second constraint sets; at least one redeemable value, wherein unlocking the at least one redeemable value comprises: the first set of constraints is satisfied, at least in part, by verifying that the unlock transaction includes the first unlock transaction output; and the second set of constraints is satisfied, at least in part, by verifying that the unlock transaction includes the second unlock transaction output; and having a node of a blockchain network verify the initial transaction; It is desirable to provide a computer-implemented method comprising:

[0101] The locking script in the first unlock transaction output may be a duplicate of the locking script in the second unlock transaction output.

[0102] The locking script in the first unlock transaction output may be different from the locking script in the second unlock transaction output.

[0103] The locking script in the first unlock transaction output may include at least a portion of the at least one initial locking script.

[0104] Execution of the at least one initial locking script may include selecting the at least one portion from a plurality of portions of the at least one initial locking script.

[0105] Execution of an unlock script of the unlock transaction may result in the at least one initial unlock script receiving data corresponding to one of the first unlock transaction output or the second unlock transaction output.

[0106] The data may have an index value, and execution of the at least one initial locking script may determine if a first set of constraints is satisfied if the index value is a first index value, and execution of the at least one initial locking script may determine if a second set of constraints is satisfied if the index value is a second index value.

[0107] The data may include the new lock script. As a result of receiving the data, the first unlock transaction output may be constrained to include the new lock script.

[0108] At least one initial locking script may include a constraint on the source of the data.

[0109] The method may further include determining a redeemable value of the first unlocked transaction output.

[0110] The initial transaction may encode a contract that has multiple states.

[0111] An unlock transaction may include multiple input values ​​corresponding to multiple states.

[0112] A first set of constraints may constrain the first unlock transaction output to have a first state, and a second set of constraints constrain the second unlock transaction output to have a second state.

[0113] Further, there is provided a computer-implemented method comprising: determining an unlocking transaction constraint that constrains unlocking transactions to include unlocking transaction inputs that reference outputs of previous transactions; generating a redeemable transaction, the redeemable transaction comprising: a redeemable transaction output that includes a redeemable amount; and a redeemable transaction locking script including an unlock transaction constraint, wherein unlocking of the redeemable amount is conditioned on execution of at least one unlock script of an unlock transaction that satisfies the unlock transaction constraint; and having the redeemable transaction verified at a node of the blockchain network.

[0114] The unlock transaction constraint may further constrain the unlock transaction input to contain a particular hash value.

[0115] A particular hash value may encode an identifier that references the output of a previous transaction.

[0116] The unlock transaction constraint may further constrain the locking script of the unlock transaction to include a set of script elements replicated from the redeemable transaction locking script.

[0117] A redeemable transaction may encode a contract that has multiple states.

[0118] The method may further include determining a redeemable value of the output of the unlocking transaction.

[0119] The unlock transaction constraint may include a particular lock script element from the output of a previous transaction. As a result of the unlock transaction input including the particular lock script element, execution of at least one unlock script may satisfy the unlock transaction constraint.

[0120] A particular lock script element may encode a cryptographic key for a particular entity.

[0121] The unlocking transaction constraint may be a first unlocking transaction constraint, the method further comprising: determining a second unlock transaction constraint to further constrain the unlock transaction; generating a second redeemable transaction, the second redeemable transaction comprising: A second redeemable amount; and and a second redeemable transaction locking script including a second unlock transaction constraint, and unlocking the second redeemable amount may further include a step in which execution of the at least one unlock script satisfies the second unlock transaction constraint.

[0122] The redeemable transaction locking script may be a first redeemable transaction locking script, and the at least one unlocking script may include a first unlocking script and a second unlocking script. The first unlocking transaction constraint may constrain the first unlocking script to include at least a portion of the first redeemable transaction locking script. The second unlocking transaction constraint may constrain the second unlocking script to include at least a portion of the second redeemable transaction locking script.

[0123] At least a portion of the first redeemable transaction lock script may include a cryptographic key associated with a first entity, and at least a portion of the second redeemable transaction lock script may include a cryptographic key associated with a second entity different from the first entity.

[0124] The unlocking transaction constraint may further constrain the unlocking transaction to constrain the output of the unlocking transaction.

[0125] The unlocking transaction constraint may encode another contract that is distinct from the contract: unlocking the redeemable amount may be conditional on another contract being implemented in the output of the unlocking transaction.

[0126] Further, there is provided a computer-implemented method comprising: Generating a blockchain transaction, the blockchain transaction comprising: a state machine that is in a first state and has a set of allowed state transitions; encoding a set of script elements to be executed to cause the unlock transaction to encode a state machine according to a set of allowed state transitions, obey restrictions on the inputs to the unlock transaction, or obey restrictions on the outputs of the unlock transaction; and having the blockchain transaction validated by nodes of the blockchain network.

[0127] The set of allowed state transitions may include state transitions that can be implemented independently and in parallel in separate blockchain transactions.

[0128] The set of script elements may subject the unlock transaction to restrictions on outputs of the unlock transaction, which may require that a first output of the unlock transaction exhibit a state corresponding to a first output according to a set of allowed state transitions, and that a second output of the unlock transaction exhibit a state corresponding to a second output according to the set of allowed state transitions.

[0129] The state corresponding to the first output and the state corresponding to the second output may be the same.

[0130] The state corresponding to the first output and the state corresponding to the second output may be different states.

[0131] The script element set may subject the unlock transaction to restrictions on the inputs of the unlock transaction, which may require that the inputs to the unlock transaction point to another state machine encoded in another blockchain transaction.

[0132] A restriction on an input may require that the input reference a state machine in a first state and that the input reference another state machine in another state different from the first state.

[0133] A first transition from a first state to a second state may be within the set of allowed state transitions. A second transition from another state to the second state may be within the set of allowed state transitions.

[0134] A set of script elements may subject the unlock transaction to restrictions on the inputs of the unlock transaction. The restrictions on the inputs may describe a set of conditions for evolving a state machine. The set of conditions for evolving a state machine may depend on the state of another state machine.

[0135] The other state machine may be encoded in another blockchain transaction. The other transaction may encode a set of conditions for advancing the other state machine. The other set of conditions for advancing the other state machine may depend on the state of the state machine.

[0136] The set of script elements may subject the unlock transaction to restrictions on the output of the unlock transaction. The output restrictions may require the unlock transaction to incorporate a set of smart contract elements into the output.

[0137] The set of elements for a smart contract may be obtained from another blockchain transaction.

[0138] A set of script elements may cause an unlock transaction to obey both restrictions on the inputs of the unlock transaction and restrictions on the outputs of the unlock transaction.

[0139] Further, there is provided a computer-implemented method comprising: generating, at a node of the blockchain network, a blockchain transaction having a transaction output that is transferable by a first unlocking transaction input of a first unlocking transaction; inserting a first set of script elements into the blockchain transaction, the first unlocking transaction being constrained to include a first set of unlocking transaction script elements corresponding to an operation of the state machine; and inserting a second set of script elements into the blockchain transaction that may constrain a second set of unlocking transaction script elements that correspond to allowed state machine state transitions that include states implementable with different blockchain transactions that may be independently processed in parallel by the blockchain network. The blockchain transaction may include a first output having a first locking script, the first transaction output value may include a second output having a second locking script and a second transaction output value, and the first set of script elements may be part of the first locking script.

[0140] The unlock transaction may include an unlock script that, when executed by a transaction validator with the lock script of the output of the previous transaction, Meet the specified verification tests, may cause the node to at least store in a memory accessible to the transaction validator values ​​representing fields of the unlock transaction when executing the locking script of the output of the previous transaction to insert a first set of script elements into the unlock transaction, where the first set of script elements may form part of the unlock transaction locking script of the first output of the unlock transaction and conform to requirements dictated by the previous transaction locking script, the first set of script elements corresponding to state machine operations, and inserting a second set of script elements into the unlock transaction, where the second set of script elements forms part of the unlock transaction locking script and conforms to requirements dictated by the previous transaction locking script and corresponds to allowed state machine state transitions including states implementable using different blockchain transactions that can be processed independently in parallel by the blockchain network.

[0141] The unlock transaction may include an input and an output, where the input references an output of a previous transaction. The unlock transaction includes an unlock script, which when executed by a transaction verifier with a previous transaction lock script of an output of a previous transaction satisfies a predefined validation test, where the unlock script executes the lock script and inserts data corresponding to additional state machines into the unlock transaction as unlock transaction inputs and / or unlock transaction outputs based on allowed state machine state transitions, such that when the number of unlock transaction inputs and / or unlock transaction outputs used in the unlock transaction is sufficient for the number of state machine transitions, the node at least stores values ​​representing fields of the unlock transaction in memory accessible to the transaction verifier.

[0142] The permissible state machine state transitions include generating, for the unlock transaction, a first transaction output corresponding to a first subsequent state, inserting into the unlock transaction a first transaction output value of the first transaction output sufficient to cause the first transaction output to be an input of a first subsequent transaction that references the first transaction output, inserting into the first transaction output of the unlock transaction a third set of script elements, where the third set of script elements may be a portion of a first locking script that constrains the first subsequent transaction to assume the first subsequent state, generating, for the unlock transaction, a second transaction output corresponding to a second subsequent state, inserting into the unlock transaction a first transaction output value of the first transaction output sufficient to cause the first transaction output to be an input of a first subsequent transaction that references the first transaction output, inserting a second transaction output value of the second transaction output sufficient to cause the first transaction output to become an input of a second subsequent transaction that references the second transaction output, inserting a fourth set of script elements into the second transaction output, where the fourth set of script elements may be part of a second locking script that constrains the second subsequent transaction to take a second subsequent state, and inserting a fifth set of script elements into the first transaction output or the second transaction output, where the fifth set of script elements may be part of the first locking script, or a second locking script that imposes a constraint that the first and second subsequent transactions are distinct, thereby comprising a branching transaction from one initial state to two subsequent states.

[0143] The first locking script can constrain the first subsequent transaction to have a first state. The second locking script can constrain the second subsequent transaction to have a second state. The unlocking transaction can include three or more transaction output values ​​corresponding to a divergence of three or more states. The unlocking transaction can include three or more transaction input values ​​corresponding to a union of three or more states. The first locking script and the second locking script can constrain the first subsequent transaction and the second subsequent transaction to have the same state.

[0144] Typically, an unlock transaction may include N transaction input values ​​and N transaction output values, where N may be 1, 2, 3, or more.

[0145] The permissible state machine state transitions can include a merging transaction from two initial states to one subsequent state by inserting a first transaction input of a first predecessor state into the unlock transaction, inserting a second transaction input of a second predecessor state into the unlock transaction, and inserting a merging state into the unlock transaction that is a permissible transition from the first and second predecessor states according to a state transition matrix.

[0146] The allowed state machine state transitions can be hard-coded into the first transaction input and / or the second transaction input by inserting into the first transaction input a first reference to a first previous transaction having a first predecessor state, into the second transaction input a second reference to a second previous transaction having a second predecessor state, and into the unlock transaction a first transaction output in the fused state, where state transition matrices are available for the first previous transaction and the second previous transaction.

[0147] The allowed state machine state transitions can include parallel operation from a number N of initial states to N successor states by inserting a first transaction input with a first predecessor state into the unlock transaction, inserting a second transaction input with a second predecessor state into the unlock transaction, inserting a first reference to a first previous transaction having the first predecessor state into the first transaction input, inserting a second reference to a second previous transaction having the second predecessor state into the second transaction input, inserting a first transaction output with a first postdecessor state into the unlock transaction, inserting a third set of script elements into the first transaction output, where the third set of script elements is a portion of a first locking script that constrains the first postdecessor transaction to take the first postdecessor state, inserting a second transaction output with a second postdecessor state into the unlock transaction, and inserting a fourth set of script elements into the second transaction output, where the fourth set of script elements is a portion of a second locking script that constrains the second postdecessor transaction to take the second postdecessor state, where N is 2 or greater.

[0148] The state machine operations may be encoded for smart contracts implemented using the blockchain.

[0149] The transactions may be divided by any constraints. The method may include, at a node of a blockchain network, generating a first transaction, the first transaction including a first output having a first redeemable value and a first locking script, the first transaction including a second output having a second redeemable value and a second locking script, including in the first locking script a first set of constraints on a first selected transaction output, the first set of constraints being satisfied by the first unlocking script if the first selected transaction output should be valid for unlocking the first redeemable value, and including in the second locking script a second set of constraints on a second selected transaction output, the second set of constraints being satisfied by the second unlocking script if the second selected transaction output should be valid for using the second redeemable value, the first set of constraints or the second set of constraints imposing constraints on the locking script of an unlocking transaction having the first selected transaction output or the second selected transaction output as an output of the unlocking transaction.

[0150] The first selected transaction output can be an output of a first unlock transaction and the second selected transaction output can be an output of a second unlock transaction that is different from the first unlock transaction. The first set of constraints can be different from the second set of constraints and different from the constraints on the transaction inputs of the first transaction. The first and second sets of constraints can each include a common set of constraints. A constraint on the lock script of the unlock transaction can require that the lock script of the unlock transaction include a reference to at least one field of the unlock transaction for the unlock transaction to be valid. Another constraint on the lock script requires that the lock script of the unlock transaction include a copy of a portion of the first lock script and / or a copy of a portion of the second lock script for the unlock transaction to be valid.

[0151] The first selected transaction output may be an output of the first unlocking transaction. The second selected transaction output may be an output of the second unlocking transaction. The first unlocking script may include fields of the first transaction, fields of the first selected transaction, and fields of the second unlocking transaction. The first unlocking script may include a first comparison of the extracted fields of the first transaction and a second comparison of the extracted fields of the first unlocking transaction.

[0152] The first and second constraint sets may each include a common constraint set, whereby the locking scripts of the outputs of the two constrained unlock transactions may be constrained by the common constraint set. The first and / or second constraint sets may include constraints on a hash of a portion of the first locking script and / or a hash of a portion of the second locking script and / or a size of the portion of the first locking script and / or a size of the portion of the second locking script.

[0153] The first set of constraints and / or the second set of constraints may include any reference to input data. Each of the multiple outputs of the first transaction may be constrained by a different constraint that is applied to an output of the multiple outputs.

[0154] The transactions may have any interdependencies with the constraints embodied, such as by a computer-implemented method, comprising: generating, at a node of a blockchain network, a first redeemable transaction, the first redeemable transaction including a first redeemable output having a first redeemable value and a first locking script; including, in the first locking script, a first set of constraints for the unlocking transaction, the first set of constraints being satisfied by the first unlocking script of the unlocking transaction if the unlocking transaction is to be valid for unlocking the first redeemable output; including, in the first constraint set, a first unlocking transaction constraint that requires a first unlocking transaction output of the unlocking transaction to include a locking script of an output of the first unlocking transaction to include the first set of smart contract script instructions; and including, in the first constraint set, a second unlocking transaction constraint that requires the unlocking transaction to include a second set of smart contract script instructions and that requires the unlocking transaction to include an unlocking transaction input that references the second redeemable transaction output.

[0155] The first smart contract script instruction set may include script instructions copied from the first locking script and / or script instructions corresponding to a new smart contract that is different from the smart contract implemented in the first locking script.

[0156] The first set of constraints may be that the locking script of the output of the first unlocking transaction includes a reference to the second redeemable transaction output, and that the second set of smart contract script instructions includes a reference to the output of the first redeemable transaction.

[0157] The method may include providing in a first set of constraints a first parallel constraint requiring the unlock transaction to include a first unlocking transaction input that references the first redeemable transaction, a second parallel constraint requiring the unlock transaction to include a second unlocking transaction input that references a second redeemable transaction output, a third parallel constraint requiring a locking script of an output of the first unlocking transaction to include at least a first set of script instructions in the first smart contract script instruction set determined at least in part by the first locking script, and a fourth parallel constraint requiring a locking script of an output of the second unlocking transaction to include a second set of smart contract script instructions determined at least in part by the locking script of the second redeemable transaction output.

[0158] The first set of constraints may include a first parallel constraint requiring that the unlock transaction include a first unlocking transaction input that references the first redeemable transaction, a second parallel constraint requiring that the unlocking transaction include a second unlocking transaction input that references the second redeemable transaction output, a third parallel constraint requiring that the locking script of the output of the first unlocking transaction include at least a first set of script instructions copied from the first locking script in the first smart contract script instruction set, and a fourth parallel constraint requiring that the locking script of the output of the second unlocking transaction include a second set of smart contract script instructions copied from the locking script of the second redeemable transaction output.

[0159] It is also desirable to provide a system including a processor and a memory including executable instructions which, upon execution by the processor, cause the system to perform any of the methods described above.

[0160] It is also desirable to provide a non-transitory computer readable storage medium having executable instructions stored thereon which, when executed by a processor of a computer system, cause the computer system to perform at least any of the methods described above. [Brief description of the drawings]

[0161] These and other aspects of the invention will be apparent from and elucidated by the embodiments described hereinafter. Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] 1 illustrates a blockchain environment in which various embodiments may be implemented. [Diagram 2] 2 illustrates an example of a blockchain node that may be used in the blockchain environment of FIG. [Diagram 3] 3 illustrates an example of a transaction that may be stored in a blockchain ledger used by the blockchain nodes of FIG. [Figure 4] Here are some examples of blockchain transactions specific to the Bitcoin blockchain environment: [Diagram 5] 13 shows an example script for implementing an OP_GENSIG script for generating a signature. [Figure 6] 13 shows an example script for implementing the OP_PREVTXINJECTION script for injecting a previous transaction corresponding to the input of an unlock transaction. [Figure 7] 13 shows an example script for implementing the OP_SELFTXINJECTION script for injecting a previous transaction that corresponds to the input being signed. [Figure 8] 13 shows an example script for implementing an OP_SPENDINGTXINJECTION script for injecting a serial unlock transaction into a lock script. [Figure 9]An example of a pair of transactions is shown, one with the value to be transferred and another representing the unlocking of that value. [Figure 10] An example of multiple transactions is shown, where a transaction has multiple inputs from other transactions and multiple outputs that can be transferred by future transactions. [Figure 11] 1 illustrates an example of generating a signature from a set of serialized transaction fields according to one embodiment. [Figure 12] 1 shows an example of an unlock transaction, including an unlock script that contains a copy of a portion of the unlock transaction. [Figure 13] Shows unlock transaction and previous transaction. [Figure 14] 13 is a flow chart of an example lock script that imposes constraints on the lock script of an unlock transaction. [Figure 15] Some examples of more specific steps corresponding to the steps in FIG. 14 are shown below. [Figure 16] Here is an example to verify an unlock script. [Figure 17] Here is an example of a lock script that imposes a set of constraints on its inputs: [Figure 18] 13 is a flow chart of an example of a lock script that imposes constraints on the inputs of an unlock transaction. [Figure 19] Here are some examples of input constraints: [Figure 20] An example of a constraint is shown in the context of the process shown in FIG. [Figure 21] Shows script constraint interlocks. [Figure 22] 1 shows an example of a state machine implemented using blockchain transactions. [Figure 23] We show examples of how state machine logic can be encoded in blockchain transactions. [Figure 24]1 illustrates an example of an unreliable deterministic state machine, according to one embodiment. [Diagram 25] 1 is a flowchart illustrating an example of a process for a trustless deterministic state machine in accordance with various embodiments. [Figure 26] 1 shows a state machine that uses a state transition matrix having certain characteristics. [Figure 27] 1 shows an example of a transaction that can be used to implement a state machine. [Figure 28] An example of partial branching of a smart contract using blockchain transactions is shown. [Figure 29] 1 is an example of a pseudo-code sequence for branching processing. [Diagram 30] An example of the creation of a new smart contract from a smart contract using a blockchain transaction is shown. [Diagram 31] 1 is an example pseudocode sequence for enforcing a smart contract in an unlock transaction. [Diagram 32] 1 shows an example of a fusion operation for a smart contract that uses blockchain transactions. [Diagram 33] 1 is a pseudo-code sequence as an example of a fusion process with weak dependencies. [Diagram 34] 1 is a pseudo-code sequence as an example of a fusion process with strong dependencies. [Diagram 35] 1 shows an example of parallel processing operation for a smart contract that uses blockchain transactions. [Diagram 36] 1 is an example pseudo-code sequence for a parallel transaction barrier process. [Figure 37] We provide an example of how parts of a smart contract can be executed using blockchain transactions in parallel paths, complying with contract barriers. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0162] Referring first to Figure 1, an example of a blockchain network 100 associated with a blockchain according to one embodiment of the present disclosure is shown. In this embodiment, the blockchain network 100 includes blockchain nodes, which may be implemented as peer-to-peer distributed electronic devices each executing instances of software and / or hardware that perform operations according to a blockchain protocol agreed upon in whole or in part among operators of the blockchain nodes. In some examples, these distributed electronic devices are simply referred to as "nodes," such as node 102 in Figure 1. One example of a blockchain protocol is the Bitcoin protocol.

[0163] The nodes 102 may comprise any suitable computing device (e.g., a server in a data center, a client computing device such as a desktop computer, a laptop computer, a tablet computer, a smart phone, etc.), of a plurality of computing devices in a distributed system of a computer resource service provider, or of any suitable electronic client device. The nodes 102 may have an input for receiving data messages or objects representing proposed transactions, such as transactions 104. The nodes 102 may query information they hold, such as an understanding of the state of a transaction.

[0164] As shown in FIG. 1, some nodes 102 may be communicatively coupled to one or more other nodes of the nodes 102. As to which nodes 102 may communicate with which other nodes, these details need not be determined centrally. An active node in the blockchain network 100 may communicate with one or more other nodes 102. As a result, a message passed from one node 102 to another node 102 may propagate throughout the entire blockchain network 100 (or a significant part of it), assuming that the message is a message that the blockchain protocol indicates should be forwarded. One such message is the announcement of a proposed transaction by one of the nodes 102A, which propagates along a path such as path 106. Such a message may be the announcement of a new block proposed for inclusion in the blockchain.

[0165] FIG. 2 illustrates an example of a blockchain node 202 that may be used in a blockchain environment as a node in the blockchain network of FIG. 1. As illustrated, blockchain node 202 includes a processor 204, program memory 206, storage 208 for blockchain rules and protocol details, list of peers 210, storage 212 for application variables, communication interface 214, and storage 216 for a blockchain ledger. Blockchain ledger 216 includes data corresponding to blocks in the blockchain, such as blocks 221, 222, and 223, which include data corresponding to transactions, such as block 222 having transactions 230(1)-(4). With the exception of block 223, blocks may be cryptographically immutable in that subsequent blocks rely on values ​​calculated based on the block when it becomes immutable, and any modifications to an immutable block may be easily recognized by other blockchain nodes as an invalid block. Block 223 is illustrated as an open box, representing storage of a transaction that may be mutable and has not yet been committed to the blockchain.

[0166] The blockchain nodes 202 communicate via a communication interface 214, which may be implemented as one or more of wired or wireless communication. The blockchain ledger 216 may be a complete copy or a portion of the blockchain ledger of the blockchain network. Some blockchain nodes maintain only untransferred transactions, while others maintain the entire ledger. In this way, the ledger is a distributed ledger since each node can have its own copy. Nodes preferably only modify their own copy according to the rules of the protocol, and for all nodes that follow those rules fully, their copy should be the same as other nodes, except sometimes for some propagation time for blocks and transactions. Blockchain nodes must include the functionality to validate blocks they receive and the transactions within those blocks. The rules of the blockchain protocol state that if a blockchain node determines that a block of transactions is invalid, it will not propagate the block or transaction to other nodes. The rules state that blocks and transactions that are valid and have been verified to be valid may propagate through the blockchain network, but invalid blocks and transactions will not.

[0167] Some of the nodes in the blockchain network may be miner nodes that perform operations to collect transactions and create blocks of transactions so that new blocks can be committed to the blockchain. Miner nodes may be expected to perform some operations that are complex (to prevent dishonest nodes from easily generating improper blocks) and dependent on the data of the transactions they contain (so that dishonest nodes cannot perform complex operations in advance). The performance of these tasks is easily verified by other nodes. These other nodes validate the work of the miner nodes and, upon validation, accept and propagate the block to their copy of the blockchain. This commits the new block to the distributed ledger of the blockchain. In some examples, a block is a group of transactions, often marked with a timestamp and a "fingerprint" (such as a hash) of the previous block. In this way, each block is linked to the previous block, creating a "chain" that links the blocks of the blockchain. In embodiments, valid blocks may be added to the blockchain by consensus of the nodes in the blockchain network. Also, in some examples, the blockchain includes a list of validated blocks.

[0168] In one embodiment, at least some of the nodes operate as validating nodes that validate transactions as described in this disclosure. In some examples, a blockchain provides proof of value in the form of digital assets, and transactions on the blockchain provide a chain from a genesis transaction (which starts the blockchain) or from a distribution transaction that generates a newly "mined" digital asset as the reason for the participation of a miner node operator, to subsequent transactions. At the end of one portion of the chain are untransferred transactions, or portions thereof, and each transaction on the blockchain specifies one or more outputs. Some of these outputs may be transferred, and some may not. Here, an output includes a specification of the value of that output, and the requirements needed to "unlock" the output by inserting a valid transaction (i.e., one that at least meets the specified requirements) that extends that portion of the chain. As used herein, an unspent transaction output may be referred to as a UTXO. Unlocking a UTXO is also known as spending a UTXO.

[0169] The requirements necessary to unlock a UTXO may be specified in the UTXO's locking script. A valid unlocking transaction (i) may specify one or more previous UTXOs as inputs to the transaction, which may be by pointers to the UTXOs, (ii) may have inputs that satisfy the requirements of the locking script for each UTXO, and (iii) may have inputs such that the sum of the values ​​of all UTXOs pointed to by these inputs is less than or equal to the sum of the values ​​of all outputs of the transaction. The data representing the satisfaction of the requirements of the locking script is called the unlocking script. A validating node may process the locking script following the unlocking script, and the output of that processing is either an invalid result or a validation of the unlocking transaction.

[0170] If a node executes an unlock script and a lock script, the result of which is a validation that can result in other nodes, then the process is a stateless process. Thus, an unlock transaction that satisfies the lock script of a previous transaction's output on the blockchain that has not yet been transferred may propagate and eventually be committed to the blockchain. The node that created the committed unlock transaction may specify in its own lock script the requirements necessary to unlock the value of the new transaction's output. This process can be considered stateless in that the scripts do not need to refer to any references outside of the scripts and, with some minor exceptions, do not depend on variables or other state outside of those scripts. As a result, the unlock script and the lock script can be evaluated in isolation.

[0171] In other variations, the blockchain system may include functionality that allows for the inclusion of external data in the script evaluation process. In such cases, the external data may be controlled and / or secured in such a way that when the unlock script and the lock script are evaluated using the external data, the evaluation is consistent across the nodes performing the evaluation.

[0172] FIG. 3 illustrates an example of a transaction 300 stored in a blockchain ledger used by the blockchain nodes of FIG. 2. Other variations with similar functionality are possible. The data elements or fields of the transaction may be as shown in FIG. 3 or may include additional fields other than those described in this disclosure. As shown, there is a Blockchain Version field 302 having a value indicating the blockchain protocol version of the transaction 300. A #vin field 304 indicates the number of transaction inputs (described below) present in the transaction 300. Other fields are present and are not shown, but for each transaction input (shown here as Vin[y] 310 for illustrative purposes), there may be a set of fields including a transaction ID (TxID) 311 of the previous transaction, a pointer 312 to one of the outputs of the previous transaction (the transaction that provides a transaction output that matches the transaction input 310), where the TxID 311 and the pointer 312 together form a pointer 313 that references the output of the previous transaction. As used herein, when used in the context of a current or present transaction, the term "prior transaction" may refer to a particular prior transaction that has a transaction output that is referenced (and "transferred") by the current transaction. In an example, the current transaction may be referred to as an "unlocking transaction."

[0173] In some blockchain implementations, there is no centralized mechanism for assigning unique TxID values, but instead a decentralized mechanism for generating a unique TxID for a transaction by generating a hash of the contents of the transaction itself. Since a valid transaction cannot have the exact same contents as any other valid transaction, each valid transaction can have a unique hash for the TxID (barring the astronomically low probability of a hash collision). However, we assume here that each transaction has a unique transaction ID. Because of the nature of the hash, once a TxID is generated from the contents of a transaction, none of that content can be changed and the TxID remains valid for that transaction.

[0174] As shown in FIG. 3, the field set for transaction input Vin[y] 310 includes an Unlocking_Script_Length field 314 that indicates the length of the script that follows, an Unlocking_Script field 315 that contains an unlocking script for vin[y] 310 that “unlocks” the corresponding locking script of the transaction output pointed to by pointer 313, and a Sequence# field 316 that can be used to constrain the transaction 300.

[0175] 3 explicitly shows only one transaction input and one transaction output, there can be one or more of each. Following the transaction input, there may be a #vout field 320 that can indicate the number of transaction outputs (also described below) present in the transaction 300. For each transaction output (shown here as an exemplary Vout[x] 330), there may be a set of fields including an Output Value field 332 indicating the transaction value provided by this transaction output Vout[x] 330, a Locking_Script_Length field 334 indicating the length of the following script, and a Locking_Script field 336 containing the locking script for this transaction output Vout[x] 330. In this way, the transaction value of this transaction output can be "transferred" by anyone who can create an unlock transaction with a transaction input with an unlock script that can be verified as TRUE by a blockchain node when verifying using the unlock script and the lock script. The transaction output field may be followed by other fields, such as a Lock Time field 338 that constrains the transaction 300 to be inactive before a specified future time or before a specified future block. If each transaction input of an unlock transaction points to a corresponding transaction output of an output of a previous transaction, and the output of the previous transaction contains a transaction value, the transaction input does not need to include a field indicating that transaction value.

[0176] FIG. 4 illustrates an example of a blockchain transaction 400 specific to a Bitcoin blockchain environment. In this example, the blockchain transaction 400 includes the data elements or fields shown and may include additional fields other than those shown or described in this disclosure. The transaction 400 includes an nVersion field 402 having a value indicating the version of the transaction 400. A #vin field 404 may indicate the number of transaction inputs present in the transaction 400. For each transaction input, such as transaction input Vin[y] 410, there may be a series of fields including a hash 411 that references the previous transaction, a pointer n 412 that points to a particular output of the previous transaction, a scriptSigLen field 414 that indicates the length of the unlock script that follows, a scriptSig field 415 that contains the unlock script for that transaction input Vin[y] 410, and an nSequence field 416 that may be used to constrain the transaction 400.

[0177] Following the transaction inputs is a #vout field 420 indicating how many transaction outputs are present in the transaction 400, and for each transaction output (here shown as an exemplary Vout[x] 430), there may be a series of fields including an nValue field 432 indicating the transaction value provided by this transaction output Vout[x] 430, followed by a scriptPubKeyLen field 434 indicating the length of the lock script, and a scriptPubKey field 436 containing the lock script for this transaction output Vout[x] 430. The transaction 440 may also be shown with an nLockTime field 438, which may constrain the transaction 400 to not be active before a specified future time or before a specified future block.

[0178] OP Code In an example scripting language, such as that used by many Bitcoin blockchain nodes, there may be a set of operation codes that appear within the script as script instructions, such as lock script and unlock script. In this disclosure, various script op codes and keywords are referenced to perform various operations. However, it is contemplated that other blockchain technologies may implement different instruction sets, and thus the op codes set forth in this disclosure should be considered illustrative of the operations performed by the op codes.

[0179] Certain embodiments of the present disclosure operate under the assumption that a scripting system or other system for implementing the described instruction set allows for more than 200 instructions (e.g., more than 200 opcodes) in a single script. Likewise, certain embodiments of the present disclosure further assume that the functionality provided by the opcodes referred to in this disclosure is present and possible in the system executing the opcodes, scripts / instruction sets. Examples of operation codes referred to in this disclosure include the following: OP_ADD Pops the top two items from the stack, adds them, and pushes the result onto the stack.

[0180] OP_BIGMOD Pops the top two items from the stack, divides the second item by the first, and pushes the remainder onto the stack.

[0181] OP_BIGMODADD Pop the top three items from the stack, add modulo the first and second items, modulo the third item, and push the result onto the stack.

[0182] OP_BIGMODINVERSE Pops the top two items from the stack, performs a modulo negative exponentiation of the second item modulo the first item, and pushes the result onto the stack.

[0183] OP_BIGMODMUL Pop the top 3 items from the stack, modulo multiply the first and second items, modulo the third item, and push the result onto the stack.

[0184] OP_CAT Pops the top two items from the stack, concatenates the two items, and pushes the result onto the stack.

[0185] OP_CHECKSIG Pops two items from the stack, uses the first item as the public key and the second item as the signature, checks if the signature just popped is a valid signature, and if it is valid, pushes 1 (TRUE) onto the stack, otherwise pushes 0 (FALSE) onto the stack.

[0186] OP_CHECKSIGVERIFY Has the same functionality as OP_CHECKSIG, but OP_VERIFY is executed afterwards.

[0187] OP_DIV Pops two items from the stack, divides the second item by the first, and pushes the result onto the stack.

[0188] OP_DUP Duplicates the top item on the stack by pushing a copy of the top item onto the stack.

[0189] OP_ELSE These statements are executed if the preceding OP_IF, OP_NOTIF, or OP_ELSE was not executed. If the preceding OP_IF, OP_NOTIF, or OP_ELSE was executed, these statements are not executed if the previous OP_IF, OP_NOTIF, or OP_ELSE was executed.

[0190] OP_ENDIF Ends an if / else block.

[0191] OP_EQUAL Reads the top two items on the stack and pushes a 1 onto the stack if the two items are exactly equal, and a 0 otherwise.

[0192] OP_EQUALVERIFY Same as OP_EQUAL, but runs OP_VERIFY afterwards.

[0193] OP_FROMALTSTACK Puts the input on the top of the main stack and removes it from the alternate stack.

[0194] OP_HASH256 The input is hashed twice, first with SHA-256 and then with RIPEMD-160.

[0195] OP_IF If the top stack value is not False, the statement is executed and the top stack value is removed.

[0196] OP_MUL Multiplies the top two items on the stack.

[0197] OP_NOTIF If the top stack value is False, the statements are executed and the top stack value is removed.

[0198] OP_OVER Copies the second item in the stack and pushes it onto the top of the stack.

[0199] OP_ROLL The nth item in the stack is moved to the top.

[0200] OP_SUBSTR Returns a section of a string.

[0201] OP_SWAP Swap the top two items on the stack.

[0202] OP_TOALTSTACK Puts the input onto the top of the alternate stack and removes it from the main stack.

[0203] OP_VERIFY Mark the transaction as invalid if the top stack value is not true.

[0204] Some of the opcodes above may be base opcodes supported by a blockchain node, while others, which for clarity of exposition will be referred to here as opcodes, are typically implemented as small scripts composed of multiple base opcodes. For example, OP_BIGMOD, which will be referred to as an opcode, might be implemented using a sequence of opcodes to perform the function of dividing the top two items on the stack and returning the remainder. OP_BIGMODADD, OP_BIGMODINVERSE, and OP_BIGMODMUL could easily be expressed as a sequence of similar opcodes.

[0205] OP_GENSIG In this disclosure, references to OP_GENSIG should be considered as shorthand for the operation corresponding to the OP_GENSIG script described herein. The OP_GENSIG script may also be pushed onto the stack or used to generate a transaction signature. The OP_GENSIG script first pushes inputs onto the main (last-in, first-out) stack, which are then<SIGHASH Type> (indicating which fields of the transaction should be used in the hash), the message value <m>(double SHA256 of the serialized set of used transaction fields of the transaction), private key (Message value <m>hashing), and a number <k>(A random or pseudorandom number used to mask / protect a private key; assume it is a "mask number").

[0206] Figure 5 shows the input and output of the OP_GENSIG script. In the OP_GENSIG script, the first line is a number. <k>Copy to the alternative stack, then use the elliptic curve generator<PubK G> Against <k>to generate an elliptic curve point K on the top of the main stack. The second line of the script computes r from the x-coordinate of K modulo n and pushes a copy of r onto the alternate stack. The third line of the script computes s=k -1 Determine (m+r×a) mod n. Finally, line 4 of the script encodes r and s in DER format,<SIGHASH Type> Concatenate to.

[0207] The type of signature hash can be indicated by a SIGHASH Type, which is a byte-encoded value. The SIGHASH Type value specifies the set of fields to be extracted from the transaction before it is serialized (e.g., canonicalized) and hashed. In some examples, the SIGHASH Type value can be SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, SIGHASH_ANYONECANPAY, or a combination of two or more of these. In one embodiment, the type SIGHASH_ALL indicates that all fields in the transaction, except for the input script, are included in the serialization (and therefore will be hashed and signed). In one embodiment, the type SIGHASH_NONE indicates that outputs do not need to be signed so that others can update the transaction. In one embodiment, the type SIGHASH_SINGLE indicates that the input is signed, but the sequence number is blank. Thus, others can create new versions of the transaction that use the same hash (assuming the fields being hashed are unchanged), but the only outputs that are signed are those in the same position as the input.

[0208] In one embodiment, the type SIGHASH_ANYONECANPAY is combined with other types to indicate that the input containing SIGHASH_ANYONECANPAY is signed, but other inputs need not be signed. SIGHASH Type values ​​may be represented by a numeric value indicating the SIGHASH Type. For example, in some implementations, SIGHASH_ALL is represented by a byte having a value of 1 (e.g., binary "00000001"), SIGHASH_NONE is represented by a byte having a value of 2 (e.g., binary "000000010"), SIGHASH_SINGLE is represented by a byte having a value of 3 (e.g., binary "000000011"), and SIGHASH_ANYONECANPAY is represented by a byte having a value of 80 (e.g., binary "01010000"). In some implementations, the combination of SIGHASH Type values ​​is performed by a binary addition of the respective byte values. In some instances, the set of transaction fields determined by a SIGHASH Type represents a subset determined by the SIGHASH Type value of the corresponding transaction being serialized. For example, a SIGHASH Type of SIGHASH_ANYONECANPAY means that only one transaction input is included in the signature.

[0209] By requiring the inclusion of a SIGHASH in the unlock script, the lock script can verify that the set of serialized unlock transaction fields provided by the unlock script is indeed the source of the SIGHASH, and then use the opcode OP_CHECKSIG to verify that the SIGHASH Type value provided by the unlock script matches the signature hash of the unlock transaction. The lock script is able to do this because, when it is executed by the transaction verifier, the transaction verifier can then perform an OP_CHECKSIG operation and put the signature of the actual unlock transaction on the stack.

[0210] OP_DERENCODE In this disclosure, references to OP_DERENCODE should be considered as shorthand for the operation corresponding to popping the top two items from the stack, encoding them in DER format, and pushing the result onto the stack.

[0211] OP_ECPMULT In this disclosure, references to OP_ECPMULT should be considered as a shorthand for the operation corresponding to popping two items from the stack, performing elliptic curve point multiplication (also called elliptic curve scalar multiplication) of those two items, and pushing the result onto the stack.

[0212] OP_ECPX In this disclosure, references to OP_ECPX should be considered as shorthand for the operation corresponding to popping two items from a stack, using the first item as the modulus n and the second item as an elliptic curve point K, computing the x-coordinate of K modulo n, and pushing the result onto the stack.

[0213] OP_PREVTXINJECTION In this disclosure, references to OP_PREVTXINJECTION should be considered as a shorthand for the operation corresponding to the injection of a previous transaction corresponding to input X of an unlock transaction. Figure 6 shows the inputs and outputs of the OP_PREVTXINJECTION script.

[0214] OP_SELFTXINJECTION In this disclosure, references to OP_SELFTXINJECTION should be considered as a shorthand for the operation corresponding to the injection of a previous transaction corresponding to the input being signed. Figure 7 shows the inputs and outputs of the OP_SELFTXINJECTION script.

[0215] OP_SPENDINGTXINJECTION In this disclosure, references to OP_SPENDINGTXINJECTION should be considered as a shorthand for the operation corresponding to injecting a serialized unlock transaction into a lock script. An entity that provides a SIGHASH Type value and an unlock transaction field set determined according to the SIGHASH Type can unlock the transaction output. This is a convenience feature. Figure 8 shows the inputs and outputs of the OP_SPENDINGTXINJECTION script.

[0216] OP_EXTRACTTXID In this disclosure, references to OP_EXTRACTTXID should be considered as shorthand for the corresponding operation that takes a transaction ID and a transaction ID position as input and outputs an extracted transaction ID. The inputs to OP_EXTRACTTXID are a serialized transaction and a value X indicating an input index, and the output is the transaction identifier associated with the transaction input at that index in the serialized transaction. The script may need to parse the serialized transaction to extract the transaction ID because serialized transactions contain a variable length field with a length variance indicated by other fields in the serialized transaction.

[0217] 9 shows an example pair of transactions. A blockchain node 902 validating a transaction may have a transaction verifier 904. The transaction verifier 904 may be a stateless stack-based transaction verifier that outputs a TRUE or FALSE result 906 depending on whether its inputs are valid. In other variations, the transaction verifier is not necessarily stateless and / or may reference external authoritative data or state. The teachings herein may also be applied to blockchain systems that do not use a stack-based transaction verifier.

[0218] The inputs to the transaction verifier 904 may be a lock script 910 from the output of a previous transaction (Previous Tx) 912 (the transaction output being transferred) and an unlock script 920 of an unlocking transaction (Unlocking Tx) 922 (the transaction input that performs the unlocking). Although not shown, each transaction may include other fields. In the more general case, each transaction may have multiple inputs and / or multiple outputs, in which case the lock script 910 may be a lock script for one of the transaction outputs of the previous transaction 912 and the unlock script 920 may be an unlock script for one of the transaction inputs of the unlocking transaction 922.

[0219] In a stateless stack-based transaction verifier, the lock script 910 and the unlock script 920 are processed independently, with some minor exceptions, and do not depend on variables or other state outside of these scripts. As a result, the lock script 910 does not need to reference fields of previous transactions outside of the lock script 910 itself. The lock script 910 also cannot reference fields of the unlock transaction 922, because the lock transaction 922 did not exist when the previous transaction 912, and therefore the lock script 910, was created and made immutable.

[0220] The unlock script 920 also cannot operate directly on the fields of the unlock transaction 922 because it is stateless. The stateless quality can be useful in that it guarantees that a properly programmed blockchain node will reach the same result 906 given the same lock script 910 and the same unlock script 920. One exception to this is that a script can check the signature of one script against the signature generated from the entire transaction. In one embodiment, the script can use OP_CHECKSIG for this purpose.

[0221] In stack-based operations, the transaction verifier executes the unlock script by processing each opcode in the script in turn. Some opcodes are processed as a result, some result in data being pushed onto the stack, or popped off the stack, or some combination. When the unlock script finishes executing, there may be data remaining on the stack. If the unlock script execution is free of script errors or execution-terminating opcodes, the transaction verifier may execute the lock script and use the data present on the stack. If the lock script and the unlock script can be written using the same set of opcodes, this is effectively similar to executing a single script that contains the concatenation of the unlock script followed by the lock script. However, checking for script errors at the end of the execution of the unlock script's opcodes and before the execution of the lock script's opcodes can prevent problems caused by a malformed unlock script.

[0222] When the script execution is complete, the result remaining on the top of the stack becomes the result of the verification. If TRUE is on the top of the stack, this can be considered a verification that the unlock script actually unlocks the lock script. In this regard, the unlock script meets all of the requirements of a lock script.

[0223] 10 shows an example of multiple transactions and multiple inputs and outputs. As shown, a previous transaction (Previous Tx1) 1002 has two transaction outputs, Vout[0] 1004 with a lock script 1006 and Vout[1] 1014 with a lock script 1016, and their corresponding transaction output values, as well as transaction inputs to the previous transaction 1002, among other fields not shown. An unlocking transaction (Unlocking Tx1) 1020 is shown with two transaction inputs, Vin[0] 1024 (with an unlock script 1026 and a pointer 1028 to the corresponding output of the previous transaction) and Vin[1] 1034 (with an unlock script 1036 and a pointer 1038 to the corresponding output of the previous transaction). In this example, the corresponding previous transaction output for Vin[0] is Vout[0] of a previous transaction (Previous Tx1) 1002, while the corresponding previous transaction output for Vin[1] is some output of another transaction (Previous Tx2) (not shown).

[0224] To validate the unlock transaction 1020, a blockchain node 1042 with a transaction verifier 1044 outputs a TRUE or FALSE result 1046 depending on whether all its inputs are valid. In this case, since multiple inputs may exist for unlocking the transaction 1020, each input is validated by processing the unlock script of the transaction input and the lock script of the corresponding transaction output to which the input's pointer points.

[0225] Because it can have multiple outputs and multiple inputs, the value of one transaction can be transferred by multiple other transactions, and the value redeemable in a new transaction can come from more than one previous transaction. As explained above, the locking script can impose constraints on what should be in the unlocking script via signatures and other cryptographic techniques.

[0226] One such constraint may be that the unlock script must contain some arbitrary data. Some constraints may be "weak" or more general, such as that the unlock script must contain data that is 4 bytes long, or that it must contain a certain number of bytes without constraining the bytes to a specific value. A stronger or more specific constraint may be that the data must produce a certain hash value when hashed. This latter constraint typically requires that the data be of a certain length and a value that is unique to the data, since it is nearly impossible for someone to determine different values ​​that will produce the same hash. Constraints may be implemented in the script by the unlock script pushing its data onto a stack, or a hash of its data onto a stack, and the lock script pushing the required hash onto the stack, then running OP_EQUAL, then OP_VERIFY opcodes, which return True if the two pushed items match, or False if they do not match. In the more general case, constraints may be imposed that require certain data to be present, or that require data to be present with certain characteristics.

[0227] An example of a weak constraint is when an unlock script must contain certain data that may constitute the set of serialized unlock transaction fields, without necessarily requiring those fields to be certain values. In this way, a lock script can constrain the script of the unlock script that unlocks the output of the lock script to contain the fields of the unlock transaction from where the unlock script came. This allows the lock script to effectively perform operations on the fields of the unlock transaction that the unlock script leaves on the stack. Another example of a weak constraint is when an unlock script must contain certain data that may come from specified locations, but there are no constraints on the values ​​of the data. This allows some weak constraints to be imposed, even though the values ​​of the data will not be determined until after the lock script is immutable.

[0228] Constraint operations and constraint data may contain elements of a "smart contract". A smart contract defines the terms of an agreement: who can do what, when they can do it, and who, when, and what gets paid. Smart contract conditions can be enforced by the blockchain protocol, where the conditions can be expressed as weak or strong constraints on the unlock script or other parts of the unlock transaction. So, as in the example above, if only Bob can unlock the value of a locked transaction output (because only an unlock script that only Bob can create unlocks that transaction output), then the transaction output can be used only if authorized by one party, after a certain amount of time has passed, and only after the other transaction output has been used.

[0229] FIG. 8 shows OP_SPENDINGTXINJECTION, an abbreviation of the opcode for a script that encodes a constraint to cause injection of a serialized set of unlock transaction fields. A lock script may include opcode OP_GENSIG, which results in generating a Bitcoin signature, followed by opcode OP_CHECKSIG, which results in the signature being checked as a valid signature for an unlock transaction. For OP_GENSIG to generate a valid signature, it must have the following specific input elements: a SIGHASH type element, a set of serialized unlock transaction fields (a specific set corresponding to the SIGHASH type element), a private key, and a mask number (e.g., a random or pseudorandom number used to mask / protect the private key). By including the hash opcode, private key, and random number in the lock script, this effectively constrains the unlock script to provide a SIGHASH type and a set of serialized unlock transaction fields.

[0230] FIG. 11 illustrates a procedure for generating a signature from a set of serialized transaction fields. This may be done by a blockchain node creating a transaction or by some other generator of transactions. As shown in FIG. 11, a serialized transaction 1110 (i.e., a transaction represented as a series of data objects in a particular format) includes a set of transaction field values. The signer of the serialized transaction 1110 selects a SIGHASH Type 1112 and provides the signer's private key. From the SIGHASH Type 1112, the blockchain client / node can determine which fields of the serialized transaction 1110 or modified fields should be used. Some of the fields may be modified (except set to zero) before the hash is generated. In the example of FIG. 11, the SIGHASH Type is set equal to SIGHASH_NONE|SIGHASH_ANYONECANPAY, and thus the fields selected are the fields indicated by the modified serialized transaction 1114.

[0231] The blockchain client / node generates a hash of the modified serialized transaction 1114 (e.g., performs a double SHA-256 hash), resulting in message m 1116. The blockchain client / node processing the serialized transaction 1110 selects a number k 1118, typically a random or pseudorandom number, to mask / protect the private key. The number k is referred to as the "mask number" during this disclosure. The blockchain client / node then generates a signature 1124 (in this example, a DER encoded EC signature) from a set of signing inputs 1120 from the SIGHASH Type 1112, the message m 1116, the signer's private key 1122, and the number k 1118. The signature 1124 and the SIGHASH Type 1112 can then be used in the unlock script.

[0232] FIG. 12 shows an example of an unlock transaction 1200 that includes an unlock script 1203 that includes a copy of the unlock transaction (e.g., a serialized set of unlock transaction fields). As shown in FIG. 12, one of the transaction inputs is Vin[z]. Input Vin[z] has a hash that is the previous transaction TxID, and the number of outputs n of the previous transaction. Together, these form a pointer 1202 to the specific output of the specific previous transaction that Vin[z] should unlock. Transaction input Vin[z] has an unlock script 1203, which also has several components or subscripts 1206, 1208, 1210, 1212. Unlock script 1203 includes a serialized version 1206 of Previous TxZ. Also shown is a serialized version 1208 of Previous TxZ', which is a transaction with the outputs transferred by Previous TxZ serialized in the same way. Additional previous transactions can be included, although not shown. The unlock script 1203 also includes a SIGHASH_TYPE byte 1210 to indicate which fields of the unlock transaction 1200 were included.

[0233] The previous transaction's lock script uses OP_GENSIG and OP_CHECKSIG to include the unlock transaction in the unlock script, and the previous transaction's TxID and OP_EQUALVERIFY to include a serialized version of Previous TxZ 1206 in the unlock script. The TxID of Previous TxZ can be extracted from a field in the unlock transaction and Previous TxZ can be inserted. Previous TxZ itself contains the TxID of Previous TxZ' so that its TxID can be extracted, and so on.

[0234] The set of serialized transaction fields for an unlock transaction does not include the unlock script of the unlock transaction itself; otherwise, causality issues arise. In some embodiments, for example in the Bitcoin blockchain environment, the signature hash of a transaction can exclude some predefined fields. The SIGHASH Type may indicate which set of fields is extracted from the transaction before it is serialized and hashed.

[0235] The locking script of the previous transaction may impose a requirement on the unlocking transaction that, for the unlocking transaction to be valid, the unlocking script of the unlocking transaction must include copies of some or all of the fields of the unlocking transaction and references to one or more of the previous transactions that the unlocking transaction unlocks. Of course, the fields of the unlocking transaction are mutable when the unlocking transaction is created. However, the locking script of the previous transaction may impose constraints on the fields of the unlocking transaction in that if a field of the unlocking transaction that is part of the unlocking transaction's unlocking script does not satisfy the constraint, the unlocking transaction does not have to validate it when the locking script is executed. Fields that are not part of the unlocking script (such as fields that are not included by a SIGHASH Type value or are not set to zero) may not need to be constrained by the locking script. Also, not all of the fields included in the serialized unlocking transaction require constraints. For example, the locking script may only constrain one of many fields of the serialized unlocking transaction that are included in the unlocking script.

[0236] Different outputs of a previous transaction may apply different sets of constraints, possibly for different inputs and outputs of different unlocking transactions. Using such techniques, a blockchain node may generate a transaction using such a locking script, which may perform further checks such that the generated transaction output is transferred and the transaction unlocking the transaction output may necessarily carry different data elements and states.

[0237] The transactions in FIG. 12 can be expanded to implement state machines with significant complex functionality. As mentioned above, the lock script, when validated, has access to data that is only available after the lock script has been created and finalized. That data can include details of the fields of the unlock transaction being validated, and details of the previous transaction that includes the lock script (and possibly other previous transactions known to the blockchain node creating the unlock transaction at the time). This allows the state of the state machine to be represented in the script, and states and state transitions to be implemented and occur within the trustless confines of the blockchain environment. In other words, the state machine can be implemented by treating transactions just like any other transaction processed by the blockchain network, with transactions validated by blockchain nodes that are not necessarily trusted. In some instances, "trustless" refers to the property that any entity can create a valid unlock transaction as long as constraints are met, and that entity does not need to be trusted. However, in some cases, an entity may need to interact with a determined source to obtain the required inputs. In some embodiments, one or more inputs may be obtained from an undetermined source, such as a serialized previous transaction.

[0238] In a blockchain network, a transaction has some value of its inputs (determined by the transaction output values ​​of the transaction before the transaction inputs unlock) and some value of its outputs. To be valid, the sum of the outputs cannot exceed the sum of the inputs (except for distribution and genesis transactions, which may be excluded in this description), and to be included in a miner node, the outputs may be smaller than the inputs to provide a reason for the operator of the miner node to participate. When implementing a trustless deterministic state machine using a blockchain network, the initial state of the state machine may be present in a transaction that contains enough value to provide a miner with a reason to include the transaction corresponding to the state transition of the state machine.

[0239] In the general case, the unlock script of a previous transaction can be used in implementing the state machine. The unlock transaction then represents a state transition of the state machine, with the lock script constraining the content of the unlock transaction, and in particular the content and nature of the various transaction outputs of the unlock transaction. Thus, the lock script of the output of the previous transaction can, in effect, specify what each transaction output of the unlock transaction should look like. The lock script can require different characteristics of different unlock transaction outputs, for example, by requiring that Vout[0] of the unlock transaction contain certain data and script elements, and that Vout[1] of the unlock transaction contain certain other data and other script elements.

[0240] An entity that provides a SIGHASH Type and the unlock transaction field set that a particular SIGHASH Type uses can unlock a transaction output. Thus, some parties have reason to propagate the contents of a transaction by unlocking and transferring details from a lock script. As noted above, in some instances, "unlocking" a transaction output represents creating an unlock transaction that references the transaction output and may evaluate as valid, thereby resulting in the transfer of the transaction output.

[0241] Using the techniques and apparatus described above, transactions can be created on a blockchain ledger that includes scripts that implement smart contracts, that can implement state machines, and that can reference fields of the current transaction, previous transactions whose outputs are transferred by the current transaction, and possibly other previous transactions. These features allow transaction flows to be forced to execute self-replicating scripts for use in smart contracts and the like.

[0242] FIG. 13 shows an unlock transaction 1320 and a previous transaction 1310. In this example, the unlock transaction has an input Vin[0] 1322 that references the previous transaction and the transaction output Vout[x] 1314 of the previous transaction. For the unlock transaction to be considered valid, constraints of the lock script of Vout[x] must be satisfied. As mentioned above, some constraints may be simple. For example, a simple requirement that the unlock script of an unlock transaction input that points to a lock script must be able to provide a valid signature signed by a public key that appears in the lock script. However, as described herein, the lock script can provide more complex constraints.

[0243] For example, the lock script of Vout[x] 1314 of the previous transaction 1310 may impose constraints on the outputs of the unlock transaction in particular. The lock script of Vout[x] 1314 in this example imposes a set of constraints (Constraint Set1) on output Vout[0] 1324 of the unlock transaction 1320 and a set of constraints (Constraint Set2) on output Vout[0] 1326 of the unlock transaction 1320. In the particular case, Constraint Set1 and Constraint Set2 are identical, simply requiring that both the lock scripts of outputs Vout[0] 1324 and Vout[1] 1326 be the same as the lock script of Vout[x] 1314 of the previous transaction 1310.

[0244] In the more general case, constraints may go beyond the requirement to simply copy the lock script. Furthermore, the constraint set may vary from unlock transaction output to output. These constraints may be to require the number of outputs that an unlock transaction can have, the value of each output, and specific content of the lock script of the unlock transaction's outputs.

[0245] Constraints on the output of injected unlocking transactions 14 is a flow chart of an example portion 1400 of a lock script of a previous transaction that imposes constraints on the lock script of the unlock transaction. This example may be performed by a stack-based verifier that processes the unlock script of the output of the unlock transaction, which may leave data on the stack, and then processes the lock script of the output of the previous transaction to perform this processing. Because the processing of the unlock script may leave data on the stack, and the unlock script may leave the serialized contents of the unlock transaction on the stack, including, for example, details of the lock script of the unlock transaction, these details are available during verification.

[0246] In step 1402 of the process, the verifier verifies that the unlock script contains certain data, and the verifier may perform other validations that do not have to be done for each output. Examples of such data may include a serialized set of unlock transaction fields, a serialized previous transaction, a reference to a previous transaction, etc. In step 1404, the verifier checks whether these constraints are met, and if not, stops in step 1406 and invalidates the unlock transaction. Otherwise, processing continues in step 1408, where the verifier determines whether there are any unlock transaction outputs to check. The first time, the verifier may set index i=0, and if there are no more outputs to check, it moves to another processing flow in step 1410.

[0247] For each index of an output, the verifier performs steps 1412, 1414, and 1416, then increments i (step 1418) and returns to step 1408 until there are no more indexes to consider. In another variation, instead of incrementing the index by one and validating each output, the verifier loops through a set of indexes where the set does not necessarily include all values ​​of i and / or does not necessarily include and check them in an additive order. In such a variation, step 1418 would differ accordingly, looping through index i for outputs in the particular set of indexes being checked.

[0248] In step 1412, the verifier extracts the lock script of Vout[i] of the unlock transaction. This can be implemented using an OP_SUBSTR operation on the stack contents. Then, in step 1414, the verifier determines what constraints there are on the lock script of Vout[i] of the unlock transaction based on the lock script of the output of the previous transaction. In step 1416, the verifier then verifies these constraints. In this way, the lock script of the output of the previous transaction that is transferred by the input of the unlock transaction can impose constraints on the output of the unlock transaction.

[0249] The locking script of the output of the previous transaction constrains the output of the unlocking transaction such that the locking script of the previous transaction can dictate the rules about how to transfer the output of the unlocking transaction. These constraints can be hard-coded in the locking script of the output of the previous transaction, or the constraints can be determined based on data present in the unlocking script of the input of the unlocking transaction that points to that output of the previous transaction.

[0250] Figure 15 shows some examples of more specific steps corresponding to steps 1402 and 1414 of Figure 14. One example of a verifier performing step 1402 is to perform step 1502, where the verifier determines that some of the data in the unlock script (or elsewhere) in the input of the unlock transaction came from a determined source. The determined source may be a serialization of the unlock transaction or a previous transaction that was serialized. Alternatively, or in addition, the verifier may perform step 1504 and perform some other validation of the details of the unlock transaction data.

[0251] Regarding specific constraints that the locking script of the output of the previous transaction may impose on the locking script of the output of the unlocking transaction, there is step 1506, where the locking script of the output of the unlocking transaction Vout[i] must be equal to data from some determined source ("==" represents a test of equality). Another example is step 1508, where the locking script of the output of the unlocking transaction Vout[i] must be equal to data hard-coded into the locking script of the output of the previous transaction. Step 1510 covers the case where another constraint is imposed on the output of the unlocking transaction Vout[i] based on data from a determined source, and step 1512 covers the case where another constraint is imposed on Vout[i] based on hard-coded data from the locking script of the output of the previous transaction.

[0252] In some cases, instead of using the complete range of data from the source or hard-coded, a hash of the data can be used, in which case the comparison is done hash-to-hash.

[0253] The data to be used may be from the previous transaction, for example hardcoded in the locking script of the previous transaction's outputs, or it may be from a transaction preceding the previous transaction (or a reference to a preceding transaction, one of the two links emanating from the unlocking transaction (i.e. a transaction whose one or more of its outputs was transferred by the previous transaction). In this way, the data used can come from any transaction in the chain from the previous transaction to its distribution transaction (for example a Coinbase transaction in the Bitcoin protocol).

[0254] An example of this is shown in Figure 16. For step 1402 in process 1400 of Figure 14 (where the verification is that the unlock script has specific data), steps 1602, 1604, 1608, 1610, and 1612 can be performed to verify that the unlock script of the unlock transaction has a reference to a transaction in the transaction chain.

[0255] In step 1602, the verifier extracts the transaction ID (TxID) from the input of the unlock transaction. This can be done if the TxID is available in the unlock script. The verifier can then verify in step 1604 that the unlock script also contains a serialized copy of the previous transaction for that TxID. If not, the verifier can invalidate the transaction, but if it does, in step 1608, the verifier extracts the TxID from the previous transaction TxID' and then verifies in step 1610 that the previous transaction contains a copy of or a reference to the serialized transaction referenced by TxID'. This chain can continue n times, where in step 1612, the verifier extracts the TxID from the previous transaction TxID'. (n-1) Verify that the transaction referenced by '(n-1 dash) contains a copy of the serialized transaction referenced by TxIDn' (n dash).

[0256] In FIG. 16, steps 1614 and 1616 are n ', and extract the lock script for the output Vout[i] of the unlock transaction, TxID n ' is equal to the extracted lock script of the transaction referenced by

[0257] Constraints can be applied to a subset of an output's lock script, rather than the entire lock script. Constraints can be determined from a subset of the data, rather than the entire data. For example, one subset might require that "Pay-to-Public-Key-Hash" appear, while another subset might require that "Pay-to-Bob" appear.

[0258] The lock script for the output of the unlock transaction is <x> <y>It can be expressed in two parts, where <x>and <y>teeth, <x>and <y>can be extracted using a string concatenation operation so that the constraints are applied to each one individually. For example, <x>teeth<PubK A> Constrained by <y>is constrained by OP_CHECKSIG. In this way, the overall locking script is<PubK A> Constrained by OP_CHECKSIG. It is also possible to use constraints derived from data in the unlock script.

[0259] Using these techniques, a locking script of an output of a previous transaction can impose constraints on an unlocking transaction attempting to unlock that output. In particular, the constraints can be constraints on the set of outputs that the unlocking transaction has, and the constraints can be different for different outputs and can be different from the locking script of the previous transaction.

[0260] Constraints can correspond to indices that refer to various outputs. In some cases, constraints are repeated for each index, but in other cases, some structure can be provided. For example, the index of a constraint can be used in a conditional statement to select a set of constraints, such as "if index==0: constraint A els constraint B".

[0261] If a set of indexes is hard-coded, the results of the parts of the script that use the indexes may be fixed. Instead of, or in addition to, constraints on the outputs of the unlock transaction, there may also be constraints on the inputs of the unlock transaction.

[0262] Constraints on the input of injected unlock transactions One use of having a locking script that constrains the inputs of an unlocking transaction is to allow the locking script to encode a dependency on a transaction that has certain properties (e.g., the constrained inputs must reference that transaction). This differs from constraining the outputs of an unlocking transaction in that the outputs are mutable; on the other hand, the inputs may be references to existing immutable UTXOs on the blockchain. In other words, the outputs can be changed to match the constraints, while on the other hand, you must find inputs that match those constraints.

[0263] Constraints on the inputs of an unlocking transaction fall into two general types: (1) constraints placed directly on the input's references (i.e., the transaction TxID field and, optionally, the output pointer field) and (2) constraints on fields of the previous transaction that the references in the input point to.

[0264] 17 shows a previous transaction 1710 and an unlock transaction 1720, where the previous transaction 1710 has an input Vin[y] 1712 and an output Vout[x] 1714, and the unlock transaction 1720 has inputs Vin[0] 1722 and Vin[1] 1723 and an output Vout[0] 1724. The lock script for Vout[x] 1714 imposes a constraint set (Constraint Set1) on the input Vin[0] 1722 and a constraint set (Constraint Set2) on the input Vin[0] 1723. The constraint sets can include constraints on the unlock script, references, or other parts of the inputs. The constraint sets can be the same, different, or there can be more than one input, some the same and some different.

[0265] In part, these constraints can reference parts of the unlock transaction by having the unlock script inject a set of serialized unlock transaction fields as data, such as by using the OP_SPENDINGTXINJECTION script.

[0266] 18 is a flow chart of an example of a portion 1800 of a locking script of a previous transaction that imposes constraints on the inputs of an unlocking transaction. This example may be performed by a verifier that processes the unlocking script of the output of an unlocking transaction. The verifier performs this by leaving data containing the details of the unlocking transaction on a stack, and then processing the locking script of the output of the previous transaction.

[0267] In step 1802 of the process, the verifier verifies that the unlock script contains certain data; the verifier may perform other validations that do not need to be done for each output. In step 1804, the verifier checks whether these constraints are met, and if not, stops at step 1806 and invalidates the unlock transaction. Otherwise, processing continues at step 1808, where the verifier determines whether there are any unlock transaction inputs to check. The first time, the verifier may set index i=0, and if there are no more inputs to check, it moves to another processing flow at step 1810.

[0268] For each index of the input, the verifier performs steps 1812, 1814, and 1816, then increments i (step 1818) and returns to step 1808 until there are no more indexes to consider (or the verifier loops through a set of indexes, not necessarily all indexes and / or not necessarily in increasing order; in these cases, step 1818 is accordingly different, looping while checking inputs through index i). In step 1812, the verifier extracts a reference to the previous transaction and its own unlocking output from the unlocking transaction input Vin[i]. This can be implemented using an OP_SUBSTR operation on the stack contents. Next, in step 1814, the verifier determines, based on the lock script of the output of the previous transaction, what constraints should be on the reference, or use the reference to cause the injection of the previous transaction, after the constraints are applicable to the fields of the previous transaction. In step 1816, the verifier then verifies these constraints. In this way, a locking script on the output of a previous transaction that is transferred by an input of an unlocking transaction can impose constraints on that input of the unlocking transaction.

[0269] Other examples of input constraints are shown in Figure 19 by elements 1902, 1904, 1906, 1910, 1912, and 1914. Since TxIDs may be mapped one-to-one with transactions, this may mean that the constraint is that a particular transaction must be referenced in the input. The transaction that the lock script depends on is created first, so that the lock script can use its own TxID in the constraint on the input of the unlock transaction.

[0270] Constraints can be placed on fields of a previous transaction that correspond to references in an input. This may be possible by using the TxID in the input to trigger injection of the corresponding previous transaction before imposing the constraint on the field of the previous transaction. The constraint can reference a different input than the input that unlocks the output of the previous transaction whose lock script imposes the constraint.

[0271] FIG. 20 shows examples of constraints associated with steps 1802 and 1814 in process 1800 of FIG. 18. In FIG. 20, steps 2002, 2004, 2014, and 2016 may be implemented. In step 2002, the verifier extracts a transaction ID (TxID) from the input of the unlock transaction. This can be done if the TxID is available in the unlock script. The verifier may then verify in step 2004 that the unlock script also contains a copy of the serialized previous transaction for that TxID. In step 1614, the verifier extracts one or more sets of fields from the previous transaction and in step 1616 verifies any constraints on the extracted set of fields.

[0272] 21 illustrates interlocking script constraints. As shown, a previous transaction (Previous Tx1) 2102 and a previous transaction (Previous Tx2) 2104 may be referenced by inputs of an unlocking transaction (Unlocking Tx1) 2106. In particular, as indicated by arrow 2110, input Vin[0] of Unlocking Tx1 points to Vout[0] of Previous Tx1. Thus, if Unlocking Tx1 is valid, it can unlock Vout[0] of Previous Tx1. Also, as indicated by arrow 2112, input Vin[1] of Unlocking Tx1 points to Vout[0] of Previous Tx2. Such references may be conventional references for unlocking transactions with multiple inputs that reference multiple previous transactions.

[0273] In order to reference previous transactions, these transactions must already exist and be immutable before the creation of the unlocking transaction. Nonetheless, previous transactions can apply interdependent locking script constraints to the unlocking transaction. By imposing constraints on the set of inputs of the unlocking transaction, interdependent locking scripts can be implemented, which can provide concurrency, especially in the context of trustless deterministic state machines.

[0274] The lock script 2120 for output Vout[0] of Previous Tx1 has a constraint on input Vin[1] of Unlocking Tx1 that requires input pointer 2122 (e.g., a reference to the previous transaction and the output of the previous transaction) to be a reference to Previous Tx2 and Vout[0] of Previous Tx2. The lock script 2124 for output Vout[0] of Previous Tx2 has a constraint on input Vin[0] of Unlocking Tx1 that requires input pointer 2126 (e.g., a reference to the previous transaction and the output of the previous transaction) to be a reference to Previous Tx1 and Vout[0] of Previous Tx1.

[0275] Since the TxID of a transaction is not known until the transaction finishes, the transaction lock script cannot directly specify the TxID that the unlock transaction unlock script should reference, but essentially it can do this by the lock script extracting a pointer to an input (which contains the TxID of the previous transaction that has the lock script), and using that TxID to inject into a field of the previous transaction, and verify that some field of the previous transaction is equal to an expected value. In other words, if the previous transaction has a field set to a certain value, and the lock script of the previous transaction gets the TxID from the unlock transaction input, injects the transaction that that TxID references, and checks that that field is set to a certain value, if the field is not set to that certain value, then it must be the case that the unlock transaction input points to a different previous transaction. So by checking for a certain value, the lock script of the output of the previous transaction can verify if the unlock transaction input references the output of the previous transaction.

[0276] Thus, Previous Tx1 states that its first output can only be transferred by a transaction (Previous Tx2) that also unlocks the first output of a particular transaction, and Previous Tx2 states that its first output can only be transferred by a transaction that also unlocks the first output of Previous Tx1.

[0277] Interdependent locking scripts, among other things, allow for multiple smart contracts that set conditions on each other. For example, smart contract 1 could be "Alice agrees to contribute 1 BTC to Carol, but only if Bob contributes 2 BTC to Carol" and smart contract 2 could be "Bob agrees to contribute 2 BTC to Carol, but only if Alice agrees to contribute 1 BTC to Carol". To be valid, an unlock transaction must unlock both smart contracts.

[0278] As mentioned above, a lock script can encode a dependency on a transaction that has certain properties, and those properties can include fields of that transaction. This means that it is possible to make a lock script dependent on a transaction that has a particular lock script.

[0279] 21, lock script #1 (of Vout[0] of Previous Tx1) constrains Vin[1] of Unlocking Tx1 to reference lock script #2124 (of Vout[0] of Previous Tx2), and lock script #3 2124 constrains Vout[0] of Unlocking Tx1 to reference lock script #1 of Vout[0] of Previous Tx1. Here, this can be referred to as a lock script encoding a dependency on another lock script.

[0280] Implementing interdependent lock scripts can create causal race conditions, where the first lock script encodes a dependency on the second lock script, and the second lock script encodes a dependency on the first lock script, because it is possible for one of Previous Tx1 and Previous Tx2 to exist before the other. If lock script A hard-codes a dependency on lock script B, lock script B must already be known and determined, and it is not possible for lock script B to hard-code a dependency on unknown lock script A. This can be addressed by having a determinable dependency in at least one of the lock scripts.

[0281] For example, lock script A depends on lock script X, which is provided in unlock script A, and lock script B depends on lock script Y, which is provided in unlock script B. When an unlock transaction is created, both lock script A and lock script B are known, so that the unlock script A of the unlock transaction can include lock script B as its data, and the unlock script B of the unlock transaction can include lock script A as its data.

[0282] In some variants, to validate an unlock transaction input, its unlock script must reference Previous Tx1 and Previous Tx2. In other variants, it is sufficient for the unlock script to reference two (or more) previous transactions that have the same lock script as Previous Tx1.

[0283] In some variations, instead of imposing a requirement that the unlock script reference a particular previous transaction or set of previous transactions, the requirement may be exclusive in that the requirement may be that the unlock script not reference a particular previous transaction or set of previous transactions. Combinations of these variations are also possible, effectively implementing Boolean logic as to what previous transactions are referenced. For example, to validate an unlock transaction input, the unlock script must have references to Previous Tx1 and Previous Tx2, no reference to Previous TxA, and must have a reference to either Previous TxB or Previous TxC. Other logical expressions may be possible.

[0284] State Machine Using the above techniques, a state machine can be implemented using blockchain transactions, where transactions have states and are encoded by a state machine structure, such as by a transaction matrix, and are allowed to have next states. An unlock transaction can unlock the output of such a blockchain transaction, effectively triggering a state transition in the state machine.

[0285] FIG. 22 illustrates an example state machine 2200 implemented using blockchain transactions. Specifically, FIG. 22 illustrates a state machine that transitions from a first state to a second state using blockchain transactions. In some examples, the state machine's state transitions are described as determining a next state given (1) a current state, (2) one or more inputs 2226, and (3) a state rule set 2206. The example 2200 of FIG. 22 illustrates a previous transaction 2202 having a state rule set 2206 and a first state 2228A embedded in the parameters. In some embodiments, an unlock transaction 2204 is created to accept the input 2226 from a determined source. The input 2226, in combination with the first state 2228A, may be usable to reference the state rule set 2206 to determine a second state 2228B embedded in the parameters of the unlock transaction 2204.

[0286] In an embodiment, the state rule set 2206 includes a state transaction matrix that can be represented by constraints on the unlock transaction 2204 imposed by the lock script. In such an embodiment, the constraints can be parameterized by the inputs for which the current state and next state are determined. The constraints can include a check to make sure that the unlock transaction 2204 includes an output that includes the next state value in a particular field.

[0287] In an embodiment, the current state is expressed as a parameter embedded in the transaction, such as part of the locking script of the transaction's output, and the unlock transaction 2204 may have a next state value embedded in the unlock transaction 2204. The next state value may be the current state for the set of field values ​​of the unlock transaction 2204 and may be accessible when the unlock transaction 2204 is generated, as described above.

[0288] In some embodiments, at least one input is provided as external data within parameters that are determined when the unlock transaction 2204 is generated. To be secure, such parameters come from a determined source. This can provide deterministic state transitions. Finally, by using self-replicating lock scripts, an embodiment of a trustless deterministic state machine can be created. Furthermore, by allowing different lock scripts to be imposed on different transaction inputs and outputs of a transaction, concurrent trustless deterministic state machines can be implemented.

[0289] FIG. 23 illustrates this point. In this example, a trustless deterministic state machine system 2300 may include a previous transaction 2302 in a first state 2328A ("S1") in a state rule set 2306. The state rule set 2306 provides two possible states 2330A ("S2" or "S3") for the next state. The state rule set 2306 may be encoded in a lock script of the output of the previous transaction 2302. The current state 2328A may be embedded in a Lock time field or may be embedded in the lock script. The next state, in this example S2 2328B, is encoded in a lock script of the output of an unlock transaction that unlocks the output of the previous transaction and executes the state transition.

[0290] As seen in example 2300, an unlock transaction 2304 takes as inputs the inputs 2326 in its unlock script and a first state 2328A ("S1") embedded in the set of field values ​​of a previous transaction 2302, and determines an appropriate second state 2328B ("S2") from a state rule set 2306. Additionally, as seen in example 2300, a state transition matrix provides a possible new state 2330B ("S4" or "S5") for the next state transition from the second state 2328B. Note that the state rule set 2306 may be encoded as a switch statement or other conditional statement (e.g., "if-then-else") parameterized by the current state and one or more inputs. The current state, S2 2328B, may be embedded in the Lock time field or in the lock script. The next state, in this example S2 2328B, is encoded in the lock script of the output of the unlock transaction, which unlocks the output of the previous transaction and performs the state transition.

[0291] In an embodiment, each possible state is represented in a self-replicating locking script with a set of rules for state changes, such as a state transition matrix, and a particular transaction output represents the state machine in a particular state. In such an embodiment, the locking script of the transaction output is replicated to all unlocking transactions that seek to transfer control of the digital asset to a next transaction that must be linked to the current transaction output. This process may be repeated until a termination condition is met. The state of the state machine can change based on certain external inputs, since the inputs are not set in stone and may be pending data. Thus, the pending data provides inputs that can affect the next state.

[0292] As an illustrative example, Alice lends funds to Bob, and Bob agrees to pay Alice back. A trustless deterministic state machine, as described in this disclosure, can be implemented as a smart contract that represents payments that Bob makes to Alice. For example, a smart contract can be constructed such that Bob makes a payment to Alice every month for the next three months, and that a default on a payment will cause Bob's debt to enter a collection phase. Thus, as long as Bob pays every month, the current state remains in a payment state. However, if an external entity provides an input indicating that Bob has defaulted on a payment, the state branches to a delinquent state. In the delinquent state, Alice can release the transaction and hand it over to a debt collector, which causes the trustless deterministic state machine to switch to a debt collection state. In the debt collection state, the debt collector collects the debt from Bob. Such a smart contract can be created using variations of the scripts described herein.

[0293] In another example, Alice is a very charitable person who donates one unit of digital assets per month. Her rules allow anyone to claim the digital assets, but only one unit per month. Alice creates a smart contract in the manner described in this disclosure and seeds it with an initial pool of three units of digital assets. Alice can construct a script that allows any entity to obtain one unit of digital assets per month. The remainder of the digital assets are replicated to subsequent smart contracts.

[0294] FIG. 24 illustrates an unlock script and a lock script for an example trustless deterministic state machine of the present disclosure.

[0295] FIG. 25 is a flow chart illustrating an example of a process 2500 for a trustless deterministic state machine, according to various embodiments. An example of a script to perform this is the script of FIG. 24. Some or all of the process 2500 (or any other processes described, or variations and / or combinations of these processes) may be implemented under the control of one or more computer systems comprised of executable instructions and / or other data, collectively executing on one or more processors. The executable instructions and / or other data may be stored in a non-transitory computer-readable storage medium (e.g., a computer program persistently stored on a magnetic, optical, or flash medium). These instructions may be executed as part of a blockchain transaction validation process.

[0296] For example, some or all of process 2500 may be performed by a validator node in an example blockchain network, such as the example blockchain network 100 of FIG. 1. Such a validator node may include any suitable computing device (e.g., a server in a data center, a client computing device, multiple computing devices in a distributed system of a computational resource service provider, or any suitable electronic client device). Process 2500 includes a series of operations in which a lock script of a self-replicating smart contract is verified, a current state is obtained from a serialized previous transaction, input is obtained from an unlock script, and a next state is determined based at least in part on a set of state rules.

[0297] At step 2502, the system receives an unlock transaction. The system begins by executing the unlock script of the unlock transaction input, which places the serialized previous transaction and the inputs embedded in the lock script on a stack. These inputs can be obtained at 2512. At 2504, the system executing process 2500 determines whether an exit condition is met. In an embodiment, the exit condition is a condition that, upon completion, terminates the state machine transition. If the exit condition is met, the system executing process 2500 proceeds to 2506, whereby the trustless deterministic state machine stops self-replication and / or state propagation.

[0298] In step 2508, the system verifies that the lock script of the output of the previous transaction matches the lock script of the output of the unlock transaction. If the lock scripts do not match, the verification may fail and the unlock transaction may not be verified. Alternatively, if the lock scripts match, in 2510, the system extracts a current state of the set of possible states from the serialized previous transaction. In 2512, the system obtains one or more inputs that were placed on the stack as a result of the execution of the lock script. Then, in 2514, the system applies a set of state rules to determine a next state of the set of possible states of the trustless deterministic state machine based on the current state and the one or more inputs. In 2516, the system may verify that the next state (e.g., state variables and other state-related data, if applicable) is embedded in the unlock transaction. The system may also apply any remaining constraints as specified in the lock script. After the operations of 2502-2516 are successfully completed, the process ends in 2518 and the unlock transaction may be considered valid by the system executing the process. It should be noted that one or more of the operations performed in steps 2502-2518 may be performed in various orders and combinations, including in parallel.

[0299] In the context of describing the disclosed embodiments, unless otherwise specified, use of language referring to executable instructions (also called code, applications, agents, etc.) that perform actions that the "instructions" do not normally perform alone (e.g., transmitting data, performing calculations, etc.) means that the instructions are executed by a machine, thereby causing the machine to perform the specified actions.

[0300] State Machines as Blockchain Transactions Using the techniques and apparatus described above, a state machine can be implemented using blockchain transactions. The state machine can be operated by having states change from state to state along a state transition matrix. Some state diagrams can be very complex and have multiple paths. In such cases, some of the calculations that the state machine performs can be performed in parallel with other calculations. As described herein, the state machine can operate using blockchain transactions and can operate partially in parallel.

[0301] As will be described in more detail, a trustless deterministic state machine can be implemented using a lock script and an unlock script of a blockchain transaction. The lock script includes constraints that can be imposed on the unlock script and therefore can require injection of specific data into the unlock script of the unlock transaction inputs, such as serialized fields of the unlock transaction itself, serialized fields of the previous transaction that includes the lock script being executed, the current state value, inputs from determined sources (optional), and a state transition matrix that defines a set of flow conditions and operations of the state machine and specifies how to calculate the next state from the current state and other inputs. One of the constraints of the lock script in the unlock transaction is that the unlock transaction must replicate the lock script in one of its outputs and propagate the state machine.

[0302] FIG. 26 illustrates a state machine using a state transition matrix 2600 with certain characteristics. State S1 is highlighted to indicate the current state. The state machine can transition to any state along the state transitions indicated by the arrows. In the state transition matrix, transitions can occur along S1-S2-S3-S4-S8-S12, but state S5 may also require a transition from S1. Similarly, state S5 transitions to S6 and S9. The transition from state S9 to state S10 may be conditional or have a barrier, in the sense that the state transition must not occur until the transition from state S6 to state S7, which occurs in parallel, has occurred. The transition to state S8 may occur as a merger from state S4 and state S7.

[0303] Each of these states is initiated by a state machine represented by a blockchain transaction output, and each transition is processed by a single pass of the transaction output, with an unlock transaction input unlocking the output of the previous transaction resulting in a state transition as shown in Figure 22 or Figure 23. However, parallel processing of states can be achieved using blockchain transaction inputs and outputs. This is useful when a smart contract needs to be executed in multiple parallel steps. During the course of a contract, work may be allowed to be executed in parallel. For example, a contract to build a house may have various stages of completing the tile work and various stages of completing the landscaping work, which can occur in parallel. By allowing parallel execution within a smart contract, different fragments of the contract can be executed asynchronously and independently of each other.

[0304] Figure 26 shows a number of needs for such processing. One is to generate multiple paths from one state. This could be smart contract branching. Suppose a smart contract starts at state S1. Branching this smart contract could generate two state machines, state S2 and state S5. Another need is smart contract cloning, to have two identical state machines, each at the same state and operating in parallel. For example, a smart contract may require multiple instances of steps S2-S3-S4. This could be smart contract cloning, where two or more new transaction outputs have the same state, which is a special case of branching.

[0305] Another useful feature is the spawning of new contracts. For example, the smart contract represented by the state transition matrix 2600 of FIG. 26 may be such that in state S3, some party to the smart contract creates a separate contract that may be bound to the smart contract but is not part of the smart contract and / or may be created after the smart contract is created. This may be referred to herein as spawning. This new contract may differ from the initial smart contract originally provided in the state transition diagram of FIG. 26.

[0306] A fusion is when two state machines or two smart contracts merge, as in the case of state S4 and state S7. As explained below, different paths can be executed in parallel, such as S2-S3-S4, S5-S6-S7. Using these elements, parallel trustless deterministic state machines can be easily implemented in a blockchain environment.

[0307] FIG. 27 shows an example of a transaction with one input Vin[0] and two outputs Vout[0] and Vout[1]. By unlocking the output of this transaction, two independent transactions are placed on the blockchain ledger, and the creators of these transactions are compensated by some value offered to them by this transaction (not shown). As shown in the figure, the lock script of the output of the previous transaction (pointed to by Vin[0]) requires that the unlock transaction that unlocks that output includes states S2 and S5. To unlock the output of the unlock transaction that includes state S2 (Vout[0] in FIG. 27), future unlock transactions are constrained to include the next state based on the current state being S2. Similarly for the S5 state.

[0308] In this way, transaction outputs can have states and constraints can be placed on what states an unlocking transaction can be in. This allows blockchain transactions to implement processing according to a state diagram such as that shown in Figure 26, where unlocking a transaction output corresponds to a state transition in the state diagram. To avoid the case where someone creates one transaction with multiple inputs and unlocks both outputs of the transaction shown, a locking script can check that transaction and disallow it. The rules of how a valid transaction is generated, how many outputs are required, etc. are encoded in the smart contract as hardcoded values ​​or parameters provided after the smart contract is created.

[0309] Forking and cloning smart contracts using blockchain transactions Branching is used when a state needs to transition to two or more (not necessarily unique) next states in parallel. A smart contract may be able to process without all possible concurrency, but if concurrency should exist, branching may initiate it. As mentioned above, the locking script of the output of a smart contract transaction on the blockchain ledger may "impose" requirements on the input of an unlocking transaction and / or on the locking script of the output of an unlocking transaction on the blockchain ledger. Cloning may be a specific type of branching where a set of next states may all be the same state. For an unlocking transaction, multiple outputs may be constrained to duplicate the transition matrix and populate each next state.

[0310] Branching / cloning can be achieved by applying trustless deterministic state machine constraints to a set of outputs. As mentioned above, a set of indices allows different constraints to be applied to different outputs. This set of indices can be hard-coded in the transition matrix or provided as part of the input to the verification process.

[0311] Because a given unlock transaction may have multiple outputs, some of which may be unrelated to the state machine or may be associated with multiple unrelated state machines, it is more practical to embed the next state in the lock script of the transaction rather than embedding it in a field common to all outputs, such as the Lock time field. Constraining the subset of the lock script of the outputs is discussed above.

[0312] Figure 28 shows how scripts relate to a fork operation. As shown, a state machine 2810 is implemented using a previous transaction 2820 and an unlock transaction 2830. The lock script of the previous transaction 2820 constrains the unlock transaction 2830 to have at least two outputs, each requiring a subsequent unlock transaction to have an output in a specified state (and be a separate transaction). This allows these states S2, S3 to execute independently and, where possible, in parallel.

[0313] Using state machines, subtasks help enable smart contracts to execute in parallel at faster speeds. Multiple states may be used to process subtasks, and concurrency may be provided by having separate transaction threads, since one state machine may typically only be used in a single state at a time. State machines can branch by creating multiple transaction locking scripts. Based on the current state from the output of the previous transaction, an unlocking transaction may be constrained to have two or more outputs with locking scripts, as shown in FIG. 28. To prevent the branch from becoming irredeemable and terminating prematurely, each output value should be checked to ensure there are enough funds to continue the state machine.

[0314] As indicated by the dashed arrows, input Vin[0] of unlock transaction 2830 points to a previous transaction 2820 and that transaction's output Vout[0]. The lock script for Vout[0] contains a current state ("S1"), a transition matrix for the state machine, and constrains Vout[x] of unlock transaction 2830 to be a next state ("S3") and Vout[y] of unlock transaction 2830 to be another next state ("S2"), each constrained to convey the state transition matrix, and possibly other constraints.

[0315] The output lock script for the previous transaction is<Current State><Transition Matrix><other script> while the lock script of the output of the unlock transaction is <nextstate> <transitionmatrix><other script>Instead of replicating the entire lock script, only a subset of the lock script may be replicated, and the other subset may be constrained to include state.

[0316] Instead of storing the state in a lock script, you can store the state of the state machine in a field of the transaction. This field cannot be used for other purposes, such as the Lock time field. In fact, you can use another unused transaction field. This works for a single state, and also works if you need to store multiple states, but that can be more complicated.

[0317] 29 illustrates an example of pseudocode that may be executed to perform a forking or cloning process. This pseudocode may be implemented using the OP code described herein. This pseudocode may be executed by a processor of a blockchain node that generates transactions and / or validates transactions. In some embodiments, a portion of the script is from an unlock script and a portion of the script is from a lock script.

[0318] In the pseudocode of FIG. 29, the previous transaction, the unlock transaction, and optional inputs are injected so that the lock script can access them. A check for an exit condition may then be performed. If the smart contract is not exiting, the processor extracts the lock script of the previous transaction and the current state of the previous transaction, which can be done using the techniques described herein. The processor then loops through the outputs of the unlock transaction, and for each of them, extracts its lock script and checks the transaction matrix in the previous transaction lock script to determine whether it matches the transaction matrix in the lock script of the unlock transaction output being processed. If they do not match, the processor treats it as a script failure and does not validate the unlock transaction. If they match, the processor determines the next state of the state machine from the extracted current state, state transition matrix, optional inputs, and output index values. The processor then checks the determined next state against the next state of the unlock transaction output being processed. If they do not match, the processor treats it as a script failure, stops, and does not validate the unlock transaction. If there are any other constraints to be checked, they can be checked at this time. If all constraints are satisfied, the script passes.

[0319] Worker spawning smart contract The previous section described the ability to branch and clone smart contracts. This section details the ability to force a new smart contract to exist within an unlocking transaction, which can be a completely different state machine, or a completely different type of smart contract that is not a state machine.

[0320] An example of a constraint for enforcing a new smart contract that is a state machine is shown in FIG. 30. As shown, the lock script of the output of the previous transaction constrains the output of the unlock transaction such that the output lock script of the unlock transaction must equal the desired new smart contract script, or the hash of the output lock script must equal the hash of the desired new smart contract script. The new smart contract script or hash is either hard-coded in the lock script of the output of the previous transaction, or securely provided as a parameter via the unlock script of the input of the unlock transaction. Multiple new smart contracts in the unlock transaction outputs can be enforced by having corresponding constraints in the lock script, as described above for each new smart contract.

[0321] A new smart contract is created, which may be a state machine as described above. This may be the same state machine as the previous transaction, or another completely different state machine. The new state and transition matrix may be checked. This may be done separately (e.g., check the new state, then check the transition matrix values) or in parallel.

[0322] Although not shown in Figure 30, the new smart contract may be other than a state machine. In such cases, the next state value may or may not be required, but the new smart contract may be verified using an equality check of the script or its hash.

[0323] A new smart contract can be generated with the transitions from the current state of the previous transaction and new smart contracts for the outputs of the unlock transaction. In the illustrated example, the first set of outputs of the unlock transaction is constrained to replicate the state transition matrix and embed the next state, and the second set of outputs is constrained to include the new smart contracts. The outputs of the unlock transaction can be constrained to include the new lock script, and by using multiple indexes, different constraints can be applied to different outputs. The set of new smart contracts can be hard-coded in the transition matrix or provided as part of the inputs.

[0324] From a state machine perspective, a state machine can instantiate a new, different state machine to run in parallel with the calling state machine. To apply this approach to state machines, the lock script for this operation may be similar to that of the fork / clone operation, but instead of each new state machine instance checked for equality in its lock script, it may check for the presence of a new smart contract. The equality check can be performed over a range of different values, including the serialized set of transaction fields for the transaction, the lock script bytecode, or a hash of these.

[0325] 30 illustrates the creation of a new smart contract. As shown, a state machine 3010 is implemented using a previous transaction 3020 and an unlock transaction 3030. The lock script of the output Vout[0] of the previous transaction 3020 constrains the unlock transaction 3030 to have at least two outputs, Vout[x] and Vout[y], each of which requires that a subsequent unlock transaction has an output in a specified state (and is a separate transaction). Specifically, as shown, for the input Vin[0] of the unlock transaction 3030 to unlock the Vout[0] of the previous transaction 3020, the unlock transaction 3030 may be constrained such that Vout[x] has a transition matrix and is in state S4, while Vout[y] has a new smart contract.

[0326] In this approach, the new smart contract can be processed in parallel with the state machine. Although not explicitly shown, the new smart contract can be a second state machine. As mentioned above, the new smart contract does not need to be a state machine itself, in which case the resulting smart contract may not have a field for the state value.

[0327] As indicated by the dashed arrows in Figure 30, the input Vin[0] of the unlock transaction 3030 points to a previous transaction 3020 and that transaction's output Vout[0]. This may be in the form of the TxID of the previous transaction 3020, and an integer value set to "0" to point to the output Vout[0]. The lock script for Vout[0] contains the current state ("S3") and a state machine transition matrix, constraining Vout[x] of the unlock transaction 3030 to be the next state state machine ("S4") and Vout[y] of the unlock transaction 3030 to be a new smart contract ("NSC"), and possibly other constraints.

[0328] As an example, pseudocode for an example of a worker creation process and a process for forcing a new smart contract into existence for an unlocking transaction can be shown in Figure 31.

[0329] Merging smart contracts State fusion or merging can be used when two or more states need to be fused to the same next state. In some cases, state machines running in parallel may be in the same state but not fused if not required by the smart contract. For example, in the state diagram of Figure 26, it is possible for S4 and S7 to transition to S8 separately and remain two separate transactions.

[0330] 32 illustrates the merging operation of state machine 3210. In this case, unlock transaction 3230 (with inputs Vin[0] and Vin[1], and output Vout[x]) unlocks Vout[0] of both previous transaction 3220 and previous transaction 3222. Using these techniques, a smart contract can branch by instantiating a new instance of itself or by instantiating a different smart contract, and multiple smart contracts, whether identical or not, can be fused to form a single smart contract via the corresponding state machines.

[0331] Each fused unlock transaction can have one lock script. This lock script continues the execution of a single smart contract. This can be either one of the smart contracts being fused or an entirely new smart contract. In either case, multiple checks may be performed. Each of the smart contracts can be checked as being valid inputs to the unlock transaction. This can be done by validation using the previous transaction.

[0332] 32, Vin[0] denotes the previous transaction 3220 and its output Vout[0], while Vin[1] denotes the previous transaction 3222 and its output Vout[0]. The locking scripts of both Vout[0] constrain Vout[x] of the unlocking transaction 3230 to have the next state S8 and state transition matrix. These constraints may be enforced by the locking script of the previous transaction 3222, which checks that the new smart contract is an output of the unlocking transaction.

[0333] To achieve this with concurrent state machines, the transaction can use multiple inputs with an input for each state machine that needs to be combined. Constraints can be added to check the state of all combined independent state machines in the state machine transition matrix. If one of the combined state machines is not in a convergent state, the transaction may be rejected. To ensure the combine operation, constraints can be added to the state machine to ensure there are two unlock scripts based on the state of the unlock transaction. For each script, a check can be performed to ensure each script is in the correct state required for the transition. Interdependent lock constraints can also be used, as described elsewhere herein.

[0334] FIG. 33 shows an example pseudocode sequence of the process of merging smart contracts in an unlocking transaction with weak dependencies. Merging involves transitions from a set of current states (not necessarily unique states) to a shared next state. For an unlocking transaction, the set of inputs can unlock a set of locking scripts that share the constraint that the same outputs duplicate the transition matrix and populate the same next state. In the case of weak dependencies, there may be multiple state machines with the same next state for the same output.

[0335] The fusion according to Figures 32 and 33 can occur with weak dependencies. Lock scripts can include other constraints such as interdependencies, branching, creation of new smart contracts, etc. As an example of a weak dependency, lock script 1 may be a branch from state A to state X and state Y, and lock script 2 may be a normal transition from state B to state X, if the fusion happens to occur. These two lock scripts constrain that state X happens to be included in the output of the unlock transaction.

[0336] In the pseudocode sequence of FIG. 33, a processor processing a script according to the pseudocode sequence may inject the previous transaction, the unlock transaction, and optionally some input data, and check for an exit condition before proceeding. Next, the processor extracts the previous transaction lock script and the unlock transaction lock script. Next, the processor may check that the transaction matrix in the previous transaction lock script is equal to the transaction matrix in the unlock transaction lock script, and if not, abort. From there, the processor extracts the current state value of the previous transaction, and from that and the transaction matrix and inputs (if used), determines the next state, and checks the next state to determine if it matches the next state in the unlock transaction lock script. Optionally, other constraints can be checked here.

[0337] FIG. 34 shows a pseudocode sequence as an example of a process for merging smart contracts in an unlocking transaction with explicit dependencies. With explicit dependencies, there may be multiple state machines, and it is not enough that they have the same next state for the same output, in addition they may be unique separate state machines. Merging according to FIG. 32 and FIG. 34 may occur due to explicit dependencies. In cases where there are strong constraints, the unlocking transaction may be required to point to two or more unique merging state machines.

[0338] In the pseudocode sequence of FIG. 34, a processor that processes a script according to the pseudocode sequence can inject the previous transaction, the unlock transaction, and optionally some input data, and check for an exit condition before proceeding. Next, the processor extracts the unlock transaction lock script. Next, the processor loops through the set of input indexes to extract the corresponding previous transaction lock script, checks if the transition matrix in the corresponding previous transaction lock script is equal to the transition matrix in the unlock transaction lock script, and aborts if not. From there, the processor extracts the current state value of the previous transaction, adds it to a list of current states, and repeats for other inputs. From the current state, and the transition matrix and inputs (if used), the processor determines the next state, and checks the next state to determine if it matches the next state in the unlock transaction lock script. Optionally, other constraints can be checked here.

[0339] Parallel Smart Contracts / Barriers As mentioned before, two or more smart contracts can be merged into one smart contract, with weak or strong constraints. It is also useful to have two or more smart contracts that can run in parallel. This can go beyond parallelism in that there is a constraint that two parallel paths must go through one unlock transaction. This can also be used for "barriers" in concurrent state machines, where a certain transition is not allowed to occur until another transition has occurred elsewhere in the state machine.

[0340] Figure 35 illustrates parallel processing operations. In this case, an unlock transaction 3530 has two inputs (Vin[0], Vin[1]), one for each of the previous transaction 3520 and the previous transaction 3530, and two outputs (Vout[x], Vout[y]) for continuing separate smart contracts, respectively. The unlock transaction 3530 includes an unlock script that includes each of the smart contract's previous transactions. Additionally, a lock script for each smart contract may be required to continue its execution. With parallel smart contracts, one cannot transition each contract independently, but instead must do all contracts (defined in the lock script) in parallel.

[0341] The previous examples branched smart contracts, merged two smart contracts, and provided parallel operation of two (or more) smart contracts. These can be used in combination with parallel smart contracts. A barrier may be used when a state transition has a logical relationship with another state transition. As an example, it may require another state machine to be in a particular state, or require input data from that state machine.

[0342] To facilitate this functionality, an unlock transaction can be created that contains multiple inputs and outputs. Each of the state machines required for the barrier (those that make a transition or those that are involved in a constraint) may be included in their own unlock script. For each state machine that performs a transition, a lock script may be used. In the example shown in Figure 26, the transition from state S9 to S10 is allowed, but only if the transition from S6 to S7 occurs in parallel. For the unlock transaction, there are two unlock scripts, one for the state machine in state S6 and one for the state machine in state S9. The unlock transaction then has two lock scripts, one for the state machine that remains in S7 and one for the state machine that is currently in S10.

[0343] Figure 36 is an example pseudocode sequence for using barriers in a concurrent state machine that requires parallel transaction input / output. In this example, the script following the pseudocode sequence checks that each of the previous transactions has a lock script identical to the lock script in the unlock transaction. In this example, one lock script is set to match the first previous transaction, and so on. The script following the pseudocode sequence then extracts the current state from both previous transactions, reads the inputs of both state machines, and checks the barriers set on both state transitions.

[0344] Returning to Fig. 35, various dependencies are shown with dashed arrows and numbered circles. Dependency #1 may be that Vin[0] must refer to the previous transaction 3520, dependency #2 may be that Vin[0] must refer to the first output (Vout[0]) of the specified transaction (previous transaction 3520), dependency #3 may be that Vin[1] must refer to the previous transaction 3522, and dependency #4 may be that Vin[1] must refer to the first output (Vout[0]) of the specified transaction (previous transaction 3522). This may simply be two dependencies, that is, that Vin[0] must refer to Vout[0] of transaction 3520 and that Vin[1] must refer to Vout[0] of transaction 3522.

[0345] The lock script of Vout[0] of the previous transaction 3520 imposes dependency #5, which requires Vout[x] to have state=S8 and a transition matrix of state machine 1, and imposes dependency #6, which requires Vout[y] to have state=S8 and a transition matrix of state machine 2. The lock script of Vout[0] of the previous transaction 3522 imposes dependencies #7 and #8 in a similar manner. In some examples, instead of state machine constraints, there may be other types of constraints on the smart contract. Two (or more) previous transaction outputs constrain two (or more) unlock transaction outputs, thus providing parallel smart contracts.

[0346] A barrier may be different from a fusion. A barrier is when transitions from a set of current states (not necessarily unique states) are constrained to occur in parallel. For an unlock transaction, the set of inputs may be to unlock a set of interdependent lock scripts, all of which may apply their respective constraints to a set of outputs. Interdependent lock scripts may be requirements and a set of shared next states, but may not be required if possible. Interdependent lock scripts can be embedded in the transition matrix such that certain transitions require this interdependency.

[0347] Figure 37 shows a state diagram for the barrier / parallel smart contract use case. Suppose Alice and Bob are learning to dance and go to dance lessons. As a way to maintain the progress of the dance students, their progress is recorded through the use of a state machine. First, there may be a state machine between grades, which contains states regarding overall dance ability for all dance types. This is represented by states S1, S3, S5, and finally S6. These grades progress sequentially until the student reaches the highest grade supported by the dance department. To progress to the next grade (e.g., S1-S3), the student may need to reach several types of dance. Each dance type may be monitored using smaller embedded state machines (e.g., S2 and S4). In this use case, the following operations are possible:

[0348] (1) fork and clone: ​​This is used at points S1 and S5 to indicate the start of a new class, whereby there may be branches into multiple state machines, one for each dance type.

[0349] (2) Worker spawning. This can be used when certain dance types require more lessons or are offered different grading than other dance types.

[0350] (3) Merge: This process can be used at points S3 and S6 when a student reaches a new grade, which requires evaluating each student at the final state S4 of the embedded dance state machine.

[0351] (4) Parallel Transaction / barrier. Can be used to constrain state transitions in one state machine by another. In this use case, we can assume that the transitions S2 and S4 need to happen in parallel, because we cannot run one dance type in one lesson.

[0352] Accordingly, the specification and drawings are to be regarded in an illustrative rather than restrictive sense. It will be apparent, however, that various modifications and changes can be made thereto without departing from the scope of the invention as set forth in the appended claims. Similarly, other variations are within the scope of the disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof have been shown in the drawings and have been described above in detail. It is to be understood, however, that there is no intention to limit the invention to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions and equivalents falling within the scope of the invention as defined in the appended claims.

[0353] The use of "a" and "an" as well as "the" and similar referential terms in the context of describing the disclosed embodiments (particularly in the context of the claims that follow) are intended to include both the singular and the plural, unless otherwise indicated or clearly contradicted. The terms "construction," "having," "include," and "include" are intended to be open-ended terms (i.e., meaning "including, but not limited to"), unless otherwise indicated. The term "connected," when referring to an unmodified physical connection, is intended to be understood as being partially or wholly contained within, attached to, or connected to, even if there is something intervening. Recitations of ranges of values ​​in this disclosure are merely intended to serve as a shorthand method of individually referring to each individual value included within a range, as if each individual value were individually recited, unless otherwise indicated. The term "set" (e.g., "set of items") or "subset" should be construed as a non-empty collection of one or more members, unless otherwise noted or contradicted by context, and further, unless otherwise noted or contradicted by context, the term "subset" of a corresponding set does not necessarily indicate a proper subset of the corresponding set, although a subset and a corresponding set may be equivalent.

[0354] Conjunctions such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, or C" are understood in their general usage context to indicate that an item, term, etc. may be any non-empty subset of A, B, or C, or the set of A, B, and C, unless specifically stated otherwise or clearly contradicted by context. For example, in the illustrative example of a set having three members, "at least one of A, B, and C" and "at least one of A, B, or C" refer to any of the following sets: {A}, {B}, {C}, {A}, {A, B}, {A}, {C}, {A, {B, C}}. Thus, such conjunctives are not generally intended to imply that a particular embodiment requires at least one of A, at least one of B, and at least one of C to each be present.

[0355] The operations of the described processes may be performed in any suitable order unless otherwise indicated or clearly contradicted by context. The described processes (or variations and / or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions and may be implemented by hardware or a combination thereof as code (e.g., executable instructions, one or more computer programs, or one or more applications) that collectively execute on one or more processors. The code may be stored in a computer-readable storage medium, for example in the form of a computer program that includes a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory.

[0356] Any examples provided, or the use of exemplary language (e.g., "such as"), are intended only to better illuminate embodiments of the invention and do not limit the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

[0357] The embodiments of the present disclosure are described, including the best mode known to the inventors for carrying out the invention. Variations of these embodiments may become apparent to those skilled in the art upon reading the foregoing description. The inventors expect that such variations will be utilized by those skilled in the art as appropriate, and the inventors intend that the embodiments of the present disclosure be practiced otherwise than as specifically described. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed within the scope of the present disclosure unless otherwise indicated or clearly contradicted by context.

[0358] All references, including cited publications, patent applications, and patents, are incorporated by reference herein to the same extent as if each reference was individually and specifically indicated to be incorporated by reference and set forth in its entirety.

[0359] It should be noted that the above-described embodiments are illustrative of the present invention rather than limiting it, and that those skilled in the art can design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, reference signs placed in parentheses shall not be construed as limiting the claims. The words "comprising", "comprises", and similar words do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "having", "comprising" and "comprises" mean "having", "including", "including", "consisting of". The singular form of an element does not exclude the plural form of such elements and vice versa. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. [Explanation of symbols]

[0360] 100 Blockchain Networks 102 nodes 106 Pass< / transitionmatrix> < / nextstate> < / y> < / x> < / y> < / x> < / y> < / x> < / y> < / x> < / k> < / k> < / k> < / m> < / m>

Claims

1. 1. A computer-implemented method comprising: determining an unlocking transaction constraint that constrains an input of an unlocking transaction, the constraint being (1) imposed on a reference of the input of the unlocking transaction or (2) imposed on a portion of a previous transaction pointed to by the reference; generating a redeemable transaction, the redeemable transaction being the previous transaction, comprising: A transaction output including a redeemable amount; and a transaction locking script including the unlock transaction constraint; and causing a node of a blockchain network to validate the redeemable transaction; Including, Unlocking the redeemable amount is conditional on execution satisfying the unlock transaction constraint, the execution being by a verifier at a node of a blockchain network: an unlock script for the unlock transaction, the unlock script leaving the serialized contents of the unlock transaction on a stack; and then The transaction locking script; and The implementation includes: verifying that the unlock script contains specific data; extracting a reference to an output of the redeemable transaction from an input of the unlock transaction contained in the serialized content of the unlock transaction on the stack; determining a constraint including causing an injection of the prior transaction using the reference if the constraint is imposed on a portion of the prior transaction, whereafter the constraint becomes applicable to a field of the prior transaction; verifying said determined constraints; 4. A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, wherein the unlock transaction constraint further constrains an input of the unlock transaction to include a particular hash value.

3. The computer-implemented method of claim 2 , wherein the particular hash value encodes an identifier that references the previous transaction output.

4. 1. A system comprising: A processor; a memory containing executable instructions which, upon execution by said processor, cause said system to perform a computer-implemented method according to any one of claims 1 to 3; A system including:

5. A non-transitory computer-readable storage medium having stored thereon executable instructions which, when executed by a processor of a computer system, cause the computer system to perform at least one of the computer-implemented methods of any one of claims 1 to 3.

Images