Restriction on input of unlock transaction in blockchain

Abstract

To provide a method, system, and storage medium for implementing a state machine inside a blockchain transaction processing structure.SOLUTION: In a system, a transaction is executable in a blockchain ledger, an unlocking transaction constraint for constraining an unlocking transaction is determined so as to include a transaction input that refers to an output of a previous transaction, a redeemable transaction is generated so as to include a transaction output including a quantity and a transaction locking script, the transaction locking script includes the unlocking transaction constraint, the unlocking of the quantity is conditioned on execution of at least one unlocking script of an unlocking transaction satisfying the unlocking transaction constraint, and the redeemable transaction is validated at nodes of a blockchain network.SELECTED DRAWING: Figure 25

Description

Technical Field

[0001] The present invention generally relates to a method for processing blockchain transactions implemented by a computer, and more particularly to implementing a state machine within the structure of blockchain transaction processing, including trustless, deterministic, and concurrent state machines. The present invention further utilizes cryptographic and mathematical techniques to implement security with respect to electronic transfers occurring on a blockchain network. The present invention is particularly suitable for use in a method and apparatus for processing and performing smart contract transactions and for executing a state machine using such smart contract transactions, but is not limited thereto.

Background Art

[0002] As used herein, the term "blockchain" can represent any of several types of electronic, computer-based distributed ledgers, including consensus-based blockchain and transaction chain technologies, permissioned / permissionless ledgers, shared ledgers, and variations thereof. The most widely known use of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. For convenience and for purposes of explanation, examples of "Bitcoin" may be referred to as useful applications described in the present specification, but Bitcoin is only one of many applications to which the technology described in the present 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 the present disclosure provides the advantage of utilizing blockchain implementations that have similar limitations to Bitcoin with respect to constraints that can be encoded within a transaction, 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, where a block is composed of transactions and other information. In some examples, a "blockchain transaction" refers to an input message that encodes a structured set of field values including data and a set of conditions, where satisfaction of the set of conditions is a prerequisite for the set of fields to be written to the blockchain data structure. A blockchain system or blockchain network may include a plurality of blockchain nodes and a set of operations. A blockchain node can be set to execute 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 a node operator, and the node operator may be independent and unrelated to other node operators. Each blockchain node can hold a copy of, or a portion of, the blockchain ledger. The set of operations includes creation of transactions, propagation of transactions, reading of the blockchain ledger, evaluation of the blockchain ledger, generation (mining) of new blocks for proposed additions to the blockchain ledger, communication with other blockchain nodes, and provision of a wallet function for users to manage blockchain assets.

[0004] The 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 using knowledge of the rules of the blockchain protocol to verify the blockchain ledger and verify that the actions of other blockchain nodes conform to those rules. The term "blockchain" can refer to the fact that the blockchain ledger consists of a series of chained blocks that can each be represented as a data structure in computer memory, are readable by a computer process, and are transmissible as data transmissions. A block contains one or more transactions, can be represented as a data structure in computer memory, is readable by a computer process, and is transmissible as a data transmission. Blocks can be chained such that each new block that is officially added to the blockchain contains an immutable reference to the previous block, and the previous block can contain an immutable reference to the block before 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 thing that can be changed in the blockchain ledger is the addition of new blocks. Since blockchain nodes can be programmed as such as a rule, a blockchain node cannot modify a block in its copy of the blockchain ledger and can only add blocks, and furthermore, can only add a block after performing a verification process on the proposed block to ensure compliance with the blockchain protocol. Since such a block is immutable once added to the ledger, the transactions within the block can also be immutable.

[0006] When creating a transaction, a blockchain node may create a data object containing the details of the transaction and typically propagate the data object in a peer-to-peer manner to other blockchain nodes to which the blockchain node is connected. Some blockchain nodes operate as "miners", collecting one or more transactions, forming a data structure corresponding to a block, performing some calculations to verify the transactions included in the block, solving a puzzle, putting the solution of the puzzle into the data structure, and attempting to convey the block to other blockchain nodes. This puzzle may be in the form of a non-trivial calculation specific to the transaction data and the current state of the blockchain ledger, such as, for example, the number of blocks in the ledger and data from the last added block.

[0007] By making the puzzle transaction-dependent, an unauthorized blockchain node may be unable to propagate pre-created blocks. By solving a non-trivial puzzle, an unauthorized blockchain node may not be able to simply inject blocks into the blockchain network, but may require performing important computational tasks to prove that the blockchain node has provided effort (in fact, showing a solution to a difficult problem is "proof-of-work"). Preferably, in the blockchain protocol, proof-of-work is not easy, but it is easy to verify that the puzzle has been solved and the work has been done. That is, other blockchain nodes do not necessarily have to trust the blockchain node that proposes to add a new block to the ledger. When verified by other blockchain nodes, that blockchain node can add the new block to the end of its copy of the blockchain ledger and propagate the new block to other blockchain nodes. Since other blockchain nodes perform similar verifications and can also conclude that the block is valid and should be added to the blockchain ledger, the new block can be added to the copy of the blockchain ledger of the blockchain node. If a blockchain node determines that the proposed new block is not valid, it does not have to add the new block to its copy of the blockchain ledger and does not have to propagate it. Since the validity of the blockchain is consensus-based, a transaction may be considered valid if the 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 impossible to perform certain operations not permitted by the protocol, such as modifying previous blocks, proposing new blocks without the corresponding proof-of-work, or including invalid transactions. Specific trust may not be required if it is computationally infeasible to perform operations not permitted by the blockchain protocol in a way that would not be noticed by other nodes.

[0009] To include a transaction in a block written to the blockchain, (1) a mining blockchain node verifies the transaction, (2) the mining blockchain node attempts to propagate the block containing the transaction, and (3) other nodes verify the validity of the block and the validity of the transactions within the block. Since mining blockchain nodes are programmed or configured with these rules in mind, it is unlikely that a mining blockchain node will include a transaction that fails verification in a block, and such a block will not be accepted by other nodes, and the mining node will not be able to gain an advantage. One such advantage of mining for some blockchain systems is that when a block is accepted, the block is allowed to include "distributed" transactions, and a certain amount of value is allocated to the operator of that node without requiring a corresponding decrease in value from some other entity. In this way, a successful miner can be rewarded by the value generated with the block. Additionally, as described below, a transaction includes a transaction fee. The transaction fee also reaches the miner controlling the mining blockchain node, and it is necessary to confirm that the transaction is valid for the miner to receive compensation.

[0010] Transactions in a blockchain network include various data elements such as transaction values, transaction times, and / or other data elements. In a decentralized distributed ledger system, since the ledger is public, 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 its genesis transaction. In the examples herein, for illustrative purposes, the unit of value is a cryptocurrency, although other variations are possible.

[0011] Transactions other than the genesis transaction and the distribution transaction involve the "unlocking" of one or more existing transactions on the blockchain ledger, and when such a transaction is added to the blockchain ledger, the transaction can be transferred. 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 to "unlock" the value of that transaction. Here, Alice's new transaction proves that it came from Alice and has a pointer to the previous transaction. For a distribution transaction, there is a transaction value, but the distribution transaction does not "unlock" the previous transaction. Of course, for Alice's transaction to be accepted by the blockchain network, it cannot reference already transferred transactions and Alice must actually prove that she created it.

[0012] By the blockchain protocol and thus by the consensus of the blockchain nodes, a transaction is not valid if it refers to the outputs of previous transactions that have already been transferred, i.e., if the ledger contains valid existing transaction inputs that refer to the outputs of previous transactions. To prevent an interloper from generating new transaction inputs that "unlock" the value represented by a previous UTXO, each transaction output contains data representing the requirements imposed on the claimant who generates such a transaction. Since the UTXO is immutable, that data cannot be changed. Of course, transferred transactions can also be immutable.

[0013] In the above example, Alice might have created an unlocking transaction. As a result, she would be able to transfer the value in the previous transaction, which only she had the ability to unlock, to Bob. That is, there would now be a new untransferred transaction that only Bob has the ability to unlock, thereby unlocking it. The unlocking transaction created by Alice might contain data corresponding to the requirement that "anyone can freely point to this transaction and, if they can provide enough information to prove that they know Bob's private key, they can unlock all of the value". Assuming Bob is prudent, he would be the only person able to create a valid transaction that unlocks that transaction. In fact, Bob owns that value and he is the only one who can unlock it. Note that this means Bob does not need to trust the operator of the blockchain node or other parties who have the ability to create transactions. What Bob needs to trust is that a malicious party cannot completely control a majority of the blockchain nodes.

[0014] In certain cases, one transaction exactly unlocks one previous unspent transaction completely, and one transaction is either completely spent by a later transaction or not spent at all. In the general case, a transaction has one or more inputs and one or more outputs, each input references the output of a previous transaction (and that output has a redeemable value), and each output has a redeemable value (which remains unspent until transferred / referenced by an input of a future transaction). The output of a transaction is a redeemable unit of that transaction, and either all of it is transferred or none of it is transferred. Note that in the examples described herein, a transaction may be said to be "spent", and when a transaction has outputs of multiple transactions, it includes the case where a number of outputs less than all of the outputs of that transaction are transferred. In contrast to unlocking a transaction output, the case of "unlocking a transaction" may include the case where the output of a transaction having 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 not to be transferred. Each output is either transferred by an input of a later transaction or remains untransferred. If a transaction has an input attempting to unlock the output of a previous transaction after the output of the previous transaction has already been transferred, the blockchain node rejects it as an invalid transaction.

[0016] If one party, Alice, controls a UTXO with a value of X and only wants to unlock a portion Y of that transaction output, Alice can specify a new transaction with multiple outputs, one transaction output with a value of Y that can only be transferred by Bob, and one transaction output with a value of X - Y that can only be transferred by Alice. In effect, the original transaction output is fully transferred, but there are new transaction outputs that "make a change" to 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, for a transaction to be valid, 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, except for some exceptions and in some cases, it may be smaller. In the case of the genesis transaction and the distribution transaction, the sum of the output values can be larger than the sum of the input values. Or, if there are no inputs required at all, but in the case of a normal transaction, if the sum of the output values exceeds the sum of the input values, the transaction becomes invalid. In some transactions, the sum of the output values may be smaller than the sum of the input values. In this case, the successful miner adds the difference as a transaction fee transaction, and then the miner settles and creates a reason to process the transaction. In the Bitcoin protocol, this is a Coinbase transaction, which is added to the block and has a reimbursable 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 transactions included), plus the distribution for creating a new block.

[0018] Each output of a transaction contains constraints that must be satisfied in order 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 functions as collateral for the value represented within the transaction output. In this case, other actors cannot "unlock" the value represented within the transaction output unless they can "unlock" the lock script of the transaction output.

[0019] Each input to an unlock transaction unlocks the output of a previous transaction. The "unlock script" of an unlock transaction input determines whether the unlock transaction can unlock the output of the previous transaction. Thus, a valid transaction specifies at least one input, and each input of a valid unlock transaction contains a pointer to the output of the previous transaction (the output being transferred) and an unlock script that "unlocks" the lock script. A blockchain node operating according to the corresponding blockchain protocol may execute the lock script and the unlock script together in order to verify the transaction input. In a particular system, the script is stack-based, and the verification blockchain node starts with an empty stack, executes the unlock script which may leave data objects on the stack, and then executes the lock script which may use the data objects on the stack.

[0020] When a verification blockchain node combines a lock script and an unlock script and executes the combination, the result after execution will be either "TRUE (true)" or "FALSE (false)". In some cases, before the script is fully executed, the execution of the script may end with a FALSE result. For example, assume that for the execution of a particular script, there are two values that are always equal for the execution of a valid script, regardless of what happens in the script. During the execution of that script, a comparison is made between these two values, and if they are not equal, the execution of the script stops immediately after that comparison and can return a FALSE result. There is no need to execute the remaining script.

[0021] When a verification blockchain node combines a lock script and an unlock script, executes the combination, and the result is TRUE (i.e., the unlock script contains everything necessary to unlock the transaction output), the verification blockchain node verifies that the transaction is valid (assuming other requirements are met, such as an appropriate timestamp, appropriate format, not referring to a transferred transaction output, etc.). When the verification blockchain node verifies that the transaction is valid, the node 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 referring only to UTXOs and an unlock script that unlocks those UTXOs is propagated and may ultimately become part of a block that eventually becomes part of the ledger.

[0022] On the other hand, if a malicious node attempts to propagate an invalid transaction, other nodes can determine that it is invalid and do not have to propagate it.

[0023] Once a transaction is valid and accepted into the blockchain, its content cannot be changed. That is, the lock script is determined at the time of transaction creation. However, the unlock script is included within a later unlock transaction and does not necessarily need to be created until the later unlock transaction is created, so it is not always determined at that time.

[0024] Typically, the unlock script to be verified is not created by just anyone, but only by a party that has been given the right to unlock the output of a previous transaction. As in the above example, the lock script is "anyone can freely point to this transaction output if they can provide information sufficient to prove they know Bob's private key, thereby unlocking all the stipulated values." and the unlock script might be in the form of "Bob signs the transaction with his private key and the result here is ABCCC." Subsequently, the verification blockchain node processes these two statements and may reach a conclusion of TRUE or FALSE. This process works well when 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 who does not know Bob's private key to generate a valid signature. As a result, value can be transferred in a trustless system. Since it is cryptographically difficult for the sender of the transaction that Bob is trying to unlock to form a valid and verifiable result that will be accepted by the consensus of the blockchain nodes without first knowing Bob's private key, there is no need to trust the system or Bob.

[0025] The blockchain node can easily verify that Bob has signed the transaction and can verify that the signature is the only requirement of the lock script. Of course, there may be malicious nodes that do not verify where other nodes verify and verify where other nodes do not verify. However, unless the malicious nodes can overwhelm the honest nodes on the blockchain network, the malicious nodes cannot push invalid transactions or stop the propagation or mining of valid transactions.

[0026] When a node executes the unlock script of the transaction input and the corresponding lock script of the previous transaction input, evaluates each of them to TRUE, and other verification conditions (if applicable) are met, the transaction is valid as far as that node is concerned. Next, that node propagates the verified transaction to other network nodes, and as a result, the miner nodes can choose to include the transaction in the block. Therefore, in order to write a transaction to the blockchain, (1) it must be verified by the node receiving the transaction, (2) relayed to other nodes in the network (only if the transaction is verified), (3) added to a new block constructed by the miner, (4) propagated as part of the proposed block, and (5) accepted by the consensus of the nodes as an addition to the public ledger of past transactions.

[0027] In order to make a transaction effectively irreversible, when a sufficient number of blocks have been added to the blockchain, the transaction may be considered confirmed. Since the transaction is immutable, the blockchain protocol can block a unilateral reversal of the transaction. Of course, if Alice transfers value X to Bob and Alice requests the return of that value X, if Bob agrees, Alice can obtain value X. In this case, the Alice-to-Bob-for-X transaction is not 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, the transaction is considered immutable, and once the block is committed to the blockchain, the block is considered immutable. There may be a short period where there is a fork in the blockchain and some ability to roll back the blockchain, but generally, the longer the time, the less likely a rollback is to occur. Here, unless otherwise specified, it is assumed that transactions and blocks are immutable after being fully committed to the blockchain.

[0029] One way to guarantee immutability is by using cryptography. For example, there are cryptographic operations such as hashing and digital signatures that take in some data sequence as their input and provide a corresponding output data sequence in some way. The operation may be such that it is computationally infeasible or impossible to find different cryptographic inputs that will result in the same cryptographic output for a given cryptographic output (e.g., a hash or digital signature) generated from a given cryptographic input (e.g., a transaction or block). Thus, a verifier can assume that if a cryptographic input is consistent with a cryptographic output, the cryptographic input, and not some other modified cryptographic input, was used to generate the cryptographic output.

[0030] In a blockchain network, if each node does not need to trust each other, transactions may be verified as such, blocks may be verified as such, unverifiable transactions and blocks may be ignored and become unused, and transactions and blocks may be considered substantially immutable, which can be a result of the assumption that a transaction or block has not been altered from its original state if the hash or digital signature correctly corresponds to the transaction or block.

[0031] Among blockchain nodes, some store the entire ledger, while others store only unused transaction outputs (e.g., UTXO in the Bitcoin ledger). UTXO corresponds to redeemable value, and each UTXO preferably has a lock script such that others than the "owner" of that value cannot easily generate a verifiable unlock script. Of course, this is not a necessary condition, but UTXOs for which a verifiable unlock script can be easily generated by anyone are expected to be quickly transferred in a transaction that transfers their value to another UTXO that can only be redeemed by the first person to notice it. As a result, the blockchain can be used to transfer control of cryptocurrency value. More generally, digital assets and transaction records from one participant to another in a blockchain system, including transferred transaction outputs and UTXOs, can be recorded in a publicly available immutable ledger, which makes it easier 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 related to a right of use. Examples of digital assets include Bitcoin, ether, and Litecoin. As used herein, "digital asset" may refer to one or more digital assets. For example, a transaction may have multiple inputs, and each of these inputs may represent a different digital asset. The digital asset whose control is transferred may, in this example, be a collection of multiple digital assets, and the collection itself is a digital asset. Similarly, a transaction can subdivide and / or combine these multiple inputs to generate one or more outputs, for example, such that the number of inputs and the number of outputs are different.

[0033] In one embodiment, the cryptocurrency is a token-based cryptocurrency, each token representing a share of an asset (e.g., a share of a company), and a single transaction includes multiple types of tokens (e.g., shares of one or more different companies). In some embodiments, for example, like Bitcoin, the digital asset is non-tokenized. As a result, for example, there is no identifier for the digital asset identified within the blockchain; rather, control of the digital asset is demonstrated through the ability to generate a valid transaction that will be recorded on the blockchain. However, note that some blockchain implementations can use tokenized digital assets such that, for example, the digital asset is specifically identifiable using the information recorded on the blockchain. A digital asset can be used as a cryptocurrency in some embodiments, but in embodiments, it is intended that the digital asset can be used additionally or alternatively in other contexts. The present invention is applicable to the control of digital assets, but is essentially technical and can be used in other contexts that utilize blockchain data structures without necessarily involving the transfer of digital assets.

[0034] A transaction includes a lock script and an unlock script, which can form computational objects. Once committed to the blockchain, a transaction may become immutable, and its functionality can be used beyond simply the immutable transfer of control over digital assets in the form of cryptocurrency. Immutable transactions can be used to perform other operations, such as in addition to the transfer of value, the notarization of events, the implementation of smart contracts where the rights and obligations of parties are encoded in the transaction, and the transfer of value in accordance with the conditions of smart contracts according to the blockchain protocol.

[0035] In the Bitcoin platform, scripts are written using a stack - based scripting language, but other approaches may be used instead. In some examples, a "stack - based scripting language" refers to a programming language that supports various 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 - last - out data structure called a stack. The processor can push a value onto the top of the stack or pop a value from the top of the stack. The various operations performed on the stack can, as a result, push or pop one or more values from the top of the stack, perform operations on the values, or change the order of elements on the stack (this can be equivalent to two pop operations and two push operations where the first push pops the first item). For example, the OP_EQUAL operation can pop the top two items from the stack, compare them, and push the result (1 if equal, 0 if not equal) onto the top of the stack. Other operations performed on the stack, such as OP_PICK, can allow items to be selected from positions other than the top of the stack. In some of the scripting languages used by some embodiments of the present invention, there may be at least two stacks, namely, a main stack and an alternative stack. Some operations of the scripting language can move an item from the top of one stack to the top of another stack. For example, when executing the OP_TOALTSTACK operation, the processor moves a value from the top of the main stack to the top of the alternative stack. It should be noted that stack - based scripting languages are not, in some cases, strictly limited to operating only in a last - in - first - out (LIFO) manner. For example, a stack - based scripting language may support operations that copy or move the nth item in the stack to the top (such as OP_PICK and OP_ROLL in Bitcoin, respectively).Scripts written in a stack-based scripting language can be pushed onto a logical stack that can be implemented using any suitable data structure such as vectors, lists, or stacks.

[0036] Smart contracts can be implemented using the scripts included in a transaction, where the terms of the contract are encoded in the script. For example, in the form "If Bob pays X to Carol and Dave gives permission for the transaction, then Alice pays half of X to Bob", which can be encoded as part of a lock script that evaluates to TRUE only if (among other things) there are prior transactions where Bob paid Carol and Dave encoded permission. The "prior transactions" used here refer to transactions that have already been added to the blockchain and not necessarily to the transactions before the unlock transaction has an output that it unlocks. In fact, smart contracts can represent machine-executable programs that include rules defining the inputs for generating results, thereby causing the execution of actions that depend on those results.

[0037] In addition to the transfer of value, a transaction may transfer other objects or rights of possession of value. For example, a transaction may transfer nominal cryptocurrency value but may also contain data corresponding to a claim such as "the person who can reverse this transaction is also the rightful owner of the house and land at Marley Circle 123". The right of possession may also be unclear in the public record in the same sense. For example, a transaction may contain data corresponding to a claim such as "the person who can unlock this transaction is also the rightful owner of a specific property entrusted with the commission number 12345 held by the Central Bank of Trust". Here, this is represented and caused by a token that represents the transfer of real-world entities via the blockchain. Potentially confidential or secret items can be represented by tokens that have no identifiable meaning or value. Thus, a token can function as an identifier that enables real-world items to be referenced from the blockchain.

[0038] In some embodiments, the interaction with a particular entity is encoded in a particular step within the smart contract, which would otherwise be automatically self-executing and self-enforcing. In some examples, the self-execution represents the execution of the smart contract to enable the transfer of UTXOs. In such examples, the “any entity” that can unlock the UTXO represents an entity that can generate an unlock script without being required to prove any secret knowledge. In other words, the unlock script can be generated without verifying that the source of the data has access to cryptographic secrets (private asymmetric keys, symmetric keys, etc.). Also, in such examples, self-enforcement occurs as a result of the verification nodes of the blockchain network verifying the unlock transaction according to the constraints of the smart contract. In some examples, the “unlock” of the UTXO represents generating an unlock transaction output that references and executes the UTXO as valid. A secondary effect of unlocking such a transaction output is that the blockchain network can process the lock script and the unlock script to verify a new transaction, namely the unlock transaction. If valid, the output of the previous transaction is considered transferred. By including a particular value in the transaction output such that anyone can unlock the output, there is a reason for a party to create such an unlock transaction, and thus the steps of the smart contract are executed not by the participants of the smart contract but by others operating the blockchain nodes.

[0039] Scripts that form lock scripts and unlock scripts recorded as part of a transaction can be immutable, so lock scripts usually cannot be changed and reference parts of future transactions may be unknown when the transaction is finalized and thus cannot be referenced. The unlock script of a transaction input can reference the output part of the previous transaction that the transaction input points to, or a previous transaction within the blockchain other than the previous transaction. This may limit how a transaction can be used.

[0040] In one or more of these aspects, it is desirable to provide additional features and improved methods and systems for using blockchain technology. Accordingly, according to the present invention, a system and / or method as defined in the appended claims is provided.

Summary of the Invention

[0041] In various embodiments of a computer-implemented method, the method comprises determining a first set of constraints for a first used transaction output; determining a second set of constraints for a second used transaction output; generating an initial transaction, wherein the initial transaction comprises at least one initial lock script including the first set of constraints and the second set of constraints; and at least one usable value, wherein using the at least one usable value at least partially verifies that the first set of constraints is satisfied by verifying that the used transaction includes the first used transaction output; and A step, on the condition that by verifying that the usage transaction at least partially includes the second usage transaction output, the second set of constraints is satisfied; Causing the initial transaction to be verified at a node of the blockchain network; Including.

[0042] The lock script in the first usage transaction output may be a copy of the lock script in the second usage transaction output.

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

[0044] The lock script in the first usage transaction output may include at least a part of at least one initial lock script.

[0045] The execution of the at least one initial lock script may select the at least a part from a plurality of parts of the at least one initial lock script.

[0046] As a result of the execution of the unlock script of the usage transaction, the at least one initial lock script may receive data corresponding to one of the first usage transaction output or the second usage transaction output.

[0047] The data may have an index value. On the condition that the index value is the first index value, the execution of the at least one initial lock script may determine whether the first set of constraints is satisfied. On the condition that the index value is the second index value, the execution of the at least one initial lock script may determine whether the second set of constraints is satisfied.

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

[0049] At least one initial lock script may include constraints on the source of the data.

[0050] The method may further include determining the spendable value of the first spent transaction output.

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

[0052] The spent transaction may include multiple input values corresponding to multiple states.

[0053] The first set of constraints may constrain the first spent transaction output to have a first state. The second set of constraints constrains the second spent transaction output to have a second state.

[0054] Furthermore, a method implemented by a computer, determining a spent transaction constraint that constrains a spent transaction to include a spent transaction input that references the output of a previous transaction; generating a spendable transaction, the spendable transaction including: a spendable transaction output including a spendable amount; and a spendable transaction lock script including the spent transaction constraint, wherein spending the spendable amount is conditional on execution of at least one unlock script of a spent transaction that satisfies the spent transaction constraint; causing the spendable transaction to be verified at a node of a blockchain network.

[0055] The usage transaction constraint may further constrain the usage transaction input to include a specific hash value.

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

[0057] The usage transaction constraint may further constrain the lock script of the usage transaction to include a set of script elements replicated from the usable transaction lock script.

[0058] The usable transaction may encode a contract having multiple states.

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

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

[0061] The specific lock script element may encode the cryptographic key of a specific entity.

[0062] The usage transaction constraint may be a first usage transaction constraint, and the method may further determining a second usage transaction constraint to further constrain the usage transaction; and generating a second usable transaction, where the second usable transaction has a second usable amount; and Including a second usable transaction lock script including second usage transaction constraints, and using the second usable amount may further include a step that is conditional on the execution of at least one unlock script satisfying the second usage transaction constraints.

[0063] The usable transaction lock script may be a first usable 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 constraints may restrict the first unlock script so as to include at least a part of the first usable transaction lock script. The second usage transaction constraints may restrict the second unlock script so as to include at least a part of the second usable transaction lock script.

[0064] At least a part of the first usable transaction lock script may include a cryptographic key associated with the first entity. At least a part of the second usable transaction lock script may include a cryptographic key associated with a second entity different from the first entity.

[0065] The usage transaction constraints may further restrict the usage transaction so as to restrict the output of the usage transaction.

[0066] The usage transaction constraints may encode another contract distinct from the contract. Using the usable amount may be conditional on the other contract being implemented within the output of the usage transaction.

[0067] Furthermore, a method implemented by a computer, The step of generating a blockchain transaction, wherein the blockchain transaction A state machine in a first state and having a set of allowable state transitions, Encoding a set of script elements to be executed to cause a usage transaction to encode a state machine according to a set of permitted state transitions, to comply with restrictions on inputs to the usage transaction, or to comply with restrictions on outputs of the usage transaction; and causing a blockchain transaction to be verified by a node of a blockchain network. It is desirable to provide a method including these steps.

[0068] The set of permitted state transitions may include state transitions that can be implemented independently and in parallel in another blockchain transaction.

[0069] The set of script elements may cause the usage transaction to comply with restrictions on the outputs of the usage transaction. The restrictions on the outputs may require that the first output of the usage transaction indicates a state corresponding to the first output according to the set of permitted state transitions, and that the second output of the usage transaction indicates a state corresponding to the second output according to the set of permitted 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 set of script elements may cause the usage transaction to comply with restrictions on the inputs of the usage transaction. The restrictions on the inputs may require that an input to the usage transaction indicates another state machine encoded within another blockchain transaction.

[0073] The restrictions on the inputs may require that the input references a state machine in a first state and another state machine in another state different from the first state.

[0074] The first transition from the first state to the second state may be within the range of the allowable state transition set. The second transition from another state to the second state may be within the range of the allowable state transition set.

[0075] The set of script elements may cause the usage transaction to comply with restrictions on the input of the usage transaction. The restrictions on the input may describe a set of conditions for advancing the state machine. The set of conditions for advancing the state machine may depend on the state of another state machine.

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

[0077] The set of script elements may cause the usage transaction to comply with restrictions on the output of the usage transaction. The restrictions on the output may require that the usage transaction incorporate an element set of the smart contract into the output.

[0078] The element set of the smart contract may be obtained from another blockchain transaction.

[0079] The set of script elements may cause the usage transaction to comply with both restrictions on the input of the usage transaction and restrictions on the output of the usage transaction.

[0080] Furthermore, a method implemented by a computer, generating, at a node of a blockchain network, a blockchain transaction having a transaction output usable by a first usage transaction input of the first usage transaction; Inserting a first set of script elements into a blockchain transaction that can constrain a first usage transaction to include a first set of transaction script elements corresponding to the operation of the state machine. Inserting a second set of script elements into a blockchain transaction that can constrain a second set of transaction script elements corresponding to an allowable state machine state transition including a state implementable using different blockchain transactions that can be processed independently in parallel by the blockchain network. The blockchain transaction can include a first output having a first lock script, and the first transaction output value can include a second output having a second lock script and a second transaction output value. The first set of script elements is part of the first lock script.

[0081] The usage transaction can include an unlock script. The unlock script, when executed by a transaction validator using the lock script of the output of the previous transaction, Meet a predetermined verification test, execute the lock script of the output of the previous transaction, insert a first set of script elements into the using transaction, where the first set of script elements forms part of the using transaction lock script of the first output of the using transaction and conforms to the requirements indicated by the previous transaction lock script, the first set of script elements corresponds to the operation of the state machine, and, insert a second set of script elements into the using transaction, where the second set of script elements forms part of the using transaction lock script and conforms to the requirements indicated by the previous transaction lock script, when corresponding to an admissible state machine state transition including a state implementable using different blockchain transactions that can be processed independently in parallel by the blockchain network, cause the node to store at least a value representing a field of the using transaction in memory accessible by the transaction verifier.

[0082] The using transaction can include inputs and outputs, where the inputs reference the outputs of the previous transaction. The using transaction includes an unlock script. When the unlock script is executed by the transaction verifier using the previous transaction lock script of the output of the previous transaction, it meets a predetermined verification test, where the unlock script executes the lock script and inserts data corresponding to an additional state machine into the using transaction as using transaction inputs and / or using transaction outputs based on an admissible state machine state transition, such that when the number of using transaction inputs and / or using transaction outputs used in the using transaction is sufficient for the number of state machine transitions, cause the node to store at least a value representing a field of the using transaction in memory accessible by the transaction verifier.

[0083] The allowable state machine transition generates, for a use transaction, a first transaction output corresponding to a first subsequent state, inserts 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 to a first subsequent transaction that references the first transaction output, inserts into the first transaction output a third set of script elements, where the third set of script elements is part of a first lock script that constrains the first subsequent transaction to take the first subsequent state, generates, for the use transaction, a second transaction output corresponding to a second subsequent state, inserts into the use transaction a second transaction output value of the second transaction output sufficient to cause the second transaction output to be an input to a second subsequent transaction that references the second transaction output, inserts into the second transaction output a fourth set of script elements, where the fourth set of script elements is part of a second lock script that constrains the second subsequent transaction to take the second subsequent state, and inserts into the first transaction output or the second transaction output a fifth set of script elements, where the fifth set of script elements is part of the first lock script or part of the second lock script that imposes a constraint by which the first subsequent transaction and the second subsequent transaction are distinguished, thereby allowing for a branch transaction from one initial state to two subsequent states.

[0084] The first lock script can restrict the first subsequent transaction to have the first state. The second lock script can restrict the second subsequent transaction to have the second state. The used transaction can include three or more transaction output values corresponding to the branches of three or more states. The used transaction can include three or more transaction input values corresponding to the fusion of three or more states. The first lock script and the second lock script can restrict the first subsequent transaction and the second subsequent transaction to have the same state.

[0085] Generally, the used transaction may include N transaction input values and N transaction output values, where N is 1, 2, 3, or more.

[0086] The allowable state machine state transition can include a merging transaction from two initial states to one subsequent state by inserting the first transaction input of the first previous state into the used transaction, inserting the second transaction input of the second previous state into the used transaction, and inserting a fusion state that is an allowable transition from the first previous state and the second previous state according to the state transition matrix into the used transaction.

[0087] The allowable state machine state transition can be hard-coded into the first transaction input and / or the second transaction input by inserting a first reference to the first previous transaction having the first previous state into the first transaction input, inserting a second reference to the second previous transaction having the second previous state into the second transaction input, and inserting the first transaction output of the fusion state into the used transaction. Here, the state transition matrix is available for the first previous transaction and the second previous transaction.

[0088] The allowable state machine transition inserts the first transaction input of the first pre-stage state into the usage transaction, inserts the second transaction input of the second pre-stage state into the usage transaction, inserts a first reference to the first previous transaction having the first pre-stage state into the first transaction input, inserts a second reference to the second previous transaction having the second pre-stage state into the second transaction input, inserts the first transaction output of the first post-stage state into the usage transaction, inserts a third set of script elements into the first transaction output, where the third set of script elements is part of a first lock script that constrains the first post-stage transaction to take the first post-stage state, inserts the second transaction output of the second post-stage state into the usage transaction, inserts a fourth set of script elements into the second transaction output, where the fourth set of script elements is part of a second lock script that constrains the second post-stage transaction to take the second post-stage state, whereby it can include parallel operations from the number N of initial states to N subsequent states. N is 2 or more.

[0089] The operation of the state machine may be encoded for a smart contract implemented using a blockchain.

[0090] A transaction can be divided by any constraints. The method includes the steps of generating, at a node of a blockchain network, a first transaction, where the first transaction includes a first output having a first usable value and a first lock script, and the first transaction further includes a second output having a second usable value and a second lock script; including in the first lock script a first set of constraints for a first selected transaction output, where the first set of constraints is to be satisfied by a first unlock script if the first selected transaction output is to be verified for using the first usable value; including in the second lock script a second set of constraints for a second selected transaction output, where the second set of constraints is to be satisfied by a second unlock script if the second selected transaction output is to be verified for using the second usable value, and the first set of constraints or the second set of constraints imposes a constraint on a lock script of a using transaction having the first selected transaction output or the second selected transaction output as a using transaction output.

[0091] The first selected transaction output can be the output of the first spent transaction, and the second selected transaction output can be the output of a second spent transaction different from the first spent transaction. The first set of constraints can be different from the second set of constraints and can be different from the constraints on the transaction inputs of the first transaction. The first set of constraints and the second set of constraints can each include a common set of constraints. Constraints on the lock script of a spent transaction can require that the lock script of the spent transaction include a reference to at least one field of the spent transaction for the spent transaction to be valid. Another constraint on the lock script can require that the lock script of the spent 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 spent transaction to be valid.

[0092] The first selected transaction output can be the output of the first spent transaction. The second selected transaction output can be the output of the second spent transaction. The first unlock script can include fields of the first transaction, fields of the first selected transaction, and fields of the second spent transaction. The first lock script can include a first comparison of the extracted fields of the first transaction and a second comparison of the extracted fields of the first spent transaction.

[0093] The first set of constraints and the second set of constraints can each include a common set of constraints. Thereby, two constrained spent transaction output lock scripts are constrained by the common set of constraints. The first set of constraints and / or the second set of constraints can include a hash of a portion of the first lock script and / or a hash of a portion of the second lock script and / or a constraint on the size of a portion of the first lock script and / or the size of a portion of the second lock script.

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

[0095] A transaction can incorporate an interdependence with any constraints, such as by a method implemented by a computer. The method includes generating, at a node of a blockchain network, a first usable transaction, where the first usable transaction includes a first usable output having a first usable value and a first lock script; including, in the first lock script, a first constraint set for the using transaction, where the first constraint set is satisfied by a first unlock script of the using transaction if the using transaction is to be valid for using the first usable output; including, in the first constraint set, a first using transaction constraint that requires the first using transaction output of the using transaction to include a first using transaction output lock script for including the first smart contract script instruction set; and including, in the first constraint set, a second using transaction constraint that requires the using transaction to include a second smart contract script instruction set and requires the using transaction to include a using transaction input that references a second usable transaction output.

[0096] The first smart contract script instruction set can include script instructions replicated from the first lock script and / or script instructions corresponding to a new smart contract different from the smart contract implemented within the first lock script.

[0097] The first constraint set may be that the first spent transaction output lock script includes a reference to the second spendable transaction output, and that the second smart contract script instruction set includes a reference to the output of the first spendable transaction.

[0098] The method may include the step of providing a first parallel constraint that, within the first constraint set, requires that the spent transaction include a first spent transaction input that references the first spendable transaction, a second parallel constraint that requires that the spent transaction include a second spent transaction input that references the second spendable transaction output, a third parallel constraint that requires that the first spent transaction output lock script include at least a first script instruction set determined by the first lock script at least partially within the first smart contract script instruction set, and a fourth parallel constraint that requires that the second spent transaction output lock script include a second smart contract script instruction set determined at least partially by the lock script of the second spendable transaction output.

[0099] The first constraint set may include a first parallel constraint that requires that the spent transaction include a first spent transaction input that references the first spendable transaction, a second parallel constraint that requires that the spent transaction include a second spent transaction input that references the second spendable transaction output, a third parallel constraint that requires that the first spent transaction output lock script include at least a first script instruction set replicated from the first lock script in the first smart contract script instruction set, and a fourth parallel constraint that requires that the second spent transaction output lock script include a second smart contract script instruction set replicated from the lock script of the second spendable transaction output.

[0100] Furthermore, a method implemented by a computer, comprising: determining a first set of constraints for a first unlock transaction output; determining a second set of constraints for a second unlock transaction output; generating an initial transaction, the initial transaction comprising: at least one initial lock script including the first set of constraints and the second set of constraints; at least one redeemable value, wherein unlocking the at least one redeemable value is conditional on: at least partially verifying that an unlock transaction includes the first unlock transaction output, thereby satisfying the first set of constraints; and at least partially verifying that the unlock transaction includes the second unlock transaction output, thereby satisfying the second set of constraints; causing the initial transaction to be verified at a node of a blockchain network; It is desirable to provide a method implemented by a computer including the above.

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

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

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

[0104] Execution of the at least one initial lock script may select the at least a portion from a plurality of parts of the at least one initial lock script.

[0105] As a result of execution of the unlock script of the unlock transaction, the at least one initial lock script may receive data corresponding to one of the first unlock transaction output or the second unlock transaction output.

[0106] The data may have an index value. Execution of the at least one initial lock script may determine whether a first set of constraints is satisfied, on condition that the index value is a first index value. Execution of the at least one initial lock script may determine whether a second set of constraints is satisfied, on condition that the index value is a second index value.

[0107] The data may include a 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] The at least one initial lock script may include constraints on the source of the data.

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

[0110] The initial transaction may encode a contract having a plurality of states.

[0111] The unlock transaction may include a plurality of input values corresponding to a plurality of states.

[0112] The first set of constraints may constrain the first unlock transaction output to have a first state. The second set of constraints constrains the second unlock transaction output to have a second state.

[0113] Furthermore, a method implemented by a computer, determining an unlock transaction constraint that constrains an unlock transaction to include an unlock transaction input that references the output of a previous transaction; generating a redeemable transaction, the redeemable transaction including a redeemable transaction output that includes a redeemable amount, and a redeemable transaction lock script that includes the unlock transaction constraint, wherein unlocking of the redeemable amount is conditional on execution of at least one unlock script of an unlock transaction that satisfies the unlock transaction constraint; causing a node in a blockchain network to verify the redeemable transaction.

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

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

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

[0117] The redeemable transaction may encode a contract having multiple states.

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

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

[0120] The specific lock script element may encode the cryptographic key of a specific entity.

[0121] The unlock transaction constraint may be a first unlock transaction constraint, and the method may further include determining a second unlock transaction constraint to further constrain the unlock transaction; and generating a second redeemable transaction, the second redeemable transaction including a second redeemable amount; and a second redeemable transaction lock script including the second unlock transaction constraint, wherein unlocking the second redeemable amount may further be conditional on the execution of at least one unlock script satisfying the second unlock transaction constraint.

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

[0123] At least a part of the first repayable transaction lock script may include a cryptographic key associated with the first entity. At least a part of the second repayable transaction lock script may include a cryptographic key associated with a second entity different from the first entity.

[0124] The unlock transaction constraint may further constrain the unlock transaction so as to constrain the output of the unlock transaction.

[0125] The unlock transaction constraint may encode another contract distinct from the contract. Unlocking the repayable amount may be conditional on other contracts being implemented within the output of the unlock transaction.

[0126] Furthermore, a method implemented by a computer, A step of generating a blockchain transaction, the blockchain transaction is A state machine in a first state and having a set of allowable state transitions, Encoding, in the unlock transaction, a set of script elements to be executed to cause the state machine to be encoded according to the set of allowable state transitions, to conform to restrictions on the input to the unlock transaction, or to conform to restrictions on the output of the unlock transaction; and Causing the blockchain transaction to be verified by a node of the blockchain network. It is desirable to provide a method including the step.

[0127] The set of allowable state transitions may include state transitions that can be implemented independently and in parallel in another blockchain transaction.

[0128] The script element set may cause the unlock transaction to comply with restrictions on the output of the unlock transaction. The restrictions on the output may require that the first output of the unlock transaction indicates a state corresponding to the first output according to the set of allowable state transitions, and that the second output of the unlock transaction indicates a state corresponding to the second output according to the set of allowable 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 cause the unlock transaction to comply with restrictions on the input of the unlock transaction. The restrictions on the input may require that the input to the unlock transaction indicates another state machine encoded within another blockchain transaction.

[0132] The restrictions on the input may require that the input references a state machine in a first state and another state machine in another state different from the first state.

[0133] The first transition from the first state to the second state may be within the scope of the set of allowable state transitions. The second transition from another state to the second state may be within the scope of the set of allowable state transitions.

[0134] The script element set may cause the unlock transaction to comply with restrictions on the input of the unlock transaction. The restrictions on the input may describe a set of conditions for evolving the state machine. The set of conditions for evolving the state machine may depend on the state of another state machine.

[0135] Other state machines may be encoded within other blockchain transactions. Other transactions may encode a set of conditions for advancing other state machines. Other sets of conditions for advancing other state machines may depend on the state of the state machine.

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

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

[0138] The set of script elements may cause the unlock transaction to comply with both restrictions on the input of the unlock transaction and restrictions on the output of the unlock transaction.

[0139] Furthermore, a method implemented by a computer, generating, at a node of a blockchain network, a blockchain transaction having a transaction output transferable by a first unlock transaction input of the first unlock transaction; inserting, into the blockchain transaction, a first set of script elements that can constrain the first unlock transaction to include a first set of unlock transaction script elements corresponding to the operation of the state machine; Providing a method that includes inserting into a blockchain transaction a second set of script elements that can constrain a second set of unlock transaction script elements corresponding to an admissible state machine state transition including a state implementable using different blockchain transactions that can be processed independently in parallel by a blockchain network. The blockchain transaction can include a first output having a first lock script, and the first transaction output value can include a second output having a second lock script and a second transaction output value. The first set of script elements can be part of the first lock script.

[0140] An unlock transaction can include an unlock script. When the unlock script is executed by a transaction validator using the lock script of the output of a previous transaction, it satisfies a predetermined verification test, executes the lock script of the output of the previous transaction, inserts a first set of script elements into the unlock transaction, where the first set of script elements forms part of the unlock transaction lock script of the first output of the unlock transaction and may conform to the requirements indicated by the previous transaction lock script, the first set of script elements corresponds to the operation of the state machine, and inserts a second set of script elements into the unlock transaction, where the second set of script elements forms part of the unlock transaction lock script and conforms to the requirements indicated by the previous transaction lock script, and when corresponding to an admissible state machine state transition including a state implementable using different blockchain transactions that can be processed independently in parallel by a blockchain network, a node may be caused to store at least a value representing a field of the unlock transaction in memory accessible to the transaction validator.

[0141] An unlock transaction can include an input and an output, where the input references the output of a previous transaction. The unlock transaction includes an unlock script. When the unlock script is executed by a transaction validator using the previous transaction lock script of the output of the previous transaction, it satisfies a predetermined verification test. Here, the unlock script executes the lock script and inserts data corresponding to an additional state machine into the unlock transaction as an unlock transaction input and / or an unlock transaction output based on an allowable state machine state transition. As a result, 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 is caused to store at least a value representing a field of the unlock transaction in a memory accessible by the transaction validator.

[0142] For an unlock transaction, the allowable state machine transition generates a first transaction output corresponding to a first subsequent state, inserts a first transaction output value of the first transaction output sufficient to cause the first transaction output to be input to a first subsequent transaction that references the first transaction output into the unlock transaction, inserts a third set of script elements into the first transaction output of the unlock transaction, where the third set of script elements may be part of a first lock script that constrains the first subsequent transaction to take the first subsequent state, generates a second transaction output corresponding to a second subsequent state for the unlock transaction, inserts a second transaction output value of the second transaction output sufficient to cause the second transaction output to be input to a second subsequent transaction that references the second transaction output into the unlock transaction, inserts a fourth set of script elements into the second transaction output, where the fourth set of script elements may be part of a second lock script that constrains the second subsequent transaction to take the second subsequent state, and inserts 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 lock script or part of the second lock script that imposes constraints that distinguish the first subsequent transaction and the second subsequent transaction, thereby allowing for a branching transaction from one initial state to two subsequent states.

[0143] The first lock script can constrain the first subsequent transaction to have a first state. The second lock script can constrain the second subsequent transaction to have a second state. The unlock transaction can include three or more transaction output values corresponding to branches of three or more states. The unlock transaction can include three or more transaction input values corresponding to the merging of three or more states. The first lock script and the second lock script can constrain the first subsequent transaction and the second subsequent transaction to have the same state.

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

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

[0146] The admissible state machine state transition 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 previous transaction having a first previous state, inserting into the second transaction input a second reference to a previous transaction having a second previous state, and inserting into the unlock transaction a first transaction output of the fused state, where the state transition matrix is available for the first previous transaction and the second previous transaction.

[0147] The allowable state machine transition inserts the first transaction input of the first pre-stage state into the unlock transaction, inserts the second transaction input of the second pre-stage state into the unlock transaction, inserts a first reference to the first previous transaction having the first pre-stage state into the first transaction input, inserts a second reference to the second previous transaction having the second pre-stage state into the second transaction input, inserts the first transaction output of the first post-stage state into the unlock transaction, inserts a third set of script elements into the first transaction output, where the third set of script elements is part of a first lock script that constrains the first post-stage transaction to take the first post-stage state, inserts the second transaction output of the second post-stage state into the unlock transaction, inserts a fourth set of script elements into the second transaction output, where the fourth set of script elements is part of a second lock script that constrains the second post-stage transaction to take the second post-stage state, whereby it can include a parallel operation from the number N of initial states to N subsequent states. N is 2 or more.

[0148] The operation of the state machine may be encoded for a smart contract implemented using a blockchain.

[0149] A transaction can be split by any constraints. The method includes, at a node of a blockchain network, generating a first transaction, where the first transaction includes a first output having a first redeemable value and a first lock script, and the first transaction further includes a second output having a second redeemable value and a second lock script; including in the first lock script a first set of constraints for a first selected transaction output, where the first set of constraints should be satisfied by a first unlock script if the first selected transaction output is to be valid for unlocking the first redeemable value; including in the second lock script a second set of constraints for a second selected transaction output, where the second set of constraints should be satisfied by a second unlock script if the second selected transaction output is to be valid for using the second redeemable value, and the first set of constraints or the second set of constraints impose constraints on a lock script of an unlock transaction having the first selected transaction output or the second selected transaction output as an output of the unlock transaction.

[0150] The first selected transaction output can be the output of the first unlock transaction, and the second selected transaction output can be the output of a second unlock transaction different from the first unlock transaction. The first set of constraints can be different from the second set of constraints and can be different from the constraints on the transaction inputs of the first transaction. The first set of constraints and the second set of constraints can each include a common set of constraints. The constraints 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 can require that the lock script of the unlock transaction include a partial copy of the first lock script and / or a partial copy of the second lock script for the unlock transaction to be valid.

[0151] The first selected transaction output can be the output of the first unlock transaction. The second selected transaction output can be the output of the second unlock transaction. The first unlock script can include fields of the first transaction, fields of the first selected transaction, and fields of the second unlock transaction. The first lock script can include a first comparison of the extracted fields of the first transaction and a second comparison of the extracted fields of the first unlock transaction.

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

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

[0154] A transaction can incorporate an interdependence with any constraints, such as by a method implemented by a computer. The method includes steps of: generating, at a node of a blockchain network, a first repayable transaction, the first repayable transaction including a first repayable output having a first repayable value and a first lock script; including, in the first lock script, a first set of constraints for an unlock transaction, the first set of constraints being satisfied by a first unlock script of the unlock transaction if the unlock transaction is to be valid for unlocking the first repayable output; including, in the first set of constraints, a first unlock transaction constraint requiring that an output lock script of the first unlock transaction includes a lock script of an output of the first unlock transaction for the first unlock transaction output to include a first smart contract script instruction set; including, in the first set of constraints, a second unlock transaction constraint requiring that the unlock transaction includes a second smart contract script instruction set and that the unlock transaction input includes an unlock transaction input that references a second repayable transaction output.

[0155] The first smart contract script instruction set can include script instructions replicated from the first lock script and / or script instructions corresponding to a new smart contract different from the smart contract implemented within the first lock script.

[0156] The first set of constraints can be that the output lock script of the first unlock transaction includes a reference to the second repayable transaction output and that the second smart contract script instruction set includes a reference to the output of the first repayable transaction.

[0157] The method may include the step of providing: a first parallel constraint that requires, within a first set of constraints, that an unlock transaction include a first unlock transaction input that references a first repayable transaction; a second parallel constraint that requires that the unlock transaction include a second unlock transaction input that references a second repayable transaction output; a third parallel constraint that requires that a lock script of an output of the first unlock transaction include at least a first set of script instructions determined by a first lock script at least partially within a first smart contract script instruction set; and a fourth parallel constraint that requires that a lock script of an output of the second unlock transaction include a second set of smart contract script instructions determined at least partially by a lock script of the second repayable transaction output.

[0158] The first set of constraints may include: a first parallel constraint that requires that an unlock transaction include a first unlock transaction input that references a first repayable transaction; a second parallel constraint that requires that the unlock transaction include a second unlock transaction input that references a second repayable transaction output; a third parallel constraint that requires that a lock script of an output of the first unlock transaction include at least a first set of script instructions replicated from a first lock script in a first smart contract script instruction set; and a fourth parallel constraint that requires that a lock script of an output of the second unlock transaction include a second set of smart contract script instructions replicated from a lock script of the second repayable transaction output.

[0159] Also, it is desirable to provide a system including a processor and a memory including executable instructions that cause the system to execute any of the above methods as a result of execution by the processor.

[0160] Also, it is desirable to provide a non-transitory computer-readable storage medium storing executable instructions, which, as a result of being executed by a processor of a computer system, cause the computer system to execute at least any of the above-described methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0161] These and other aspects of the present invention will become apparent from the embodiments described herein and will be described. Next, embodiments of the present invention will be described by way of example only, with reference to the accompanying drawings:

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figure 32

Figure 33

Figure 34

Figure 35

Figure 36

Figure 37

Embodiments for Carrying Out the Invention

[0162] First, referring to FIG. 1, an example of a blockchain network 100 associated with a blockchain according to an embodiment of the present disclosure is shown. In this embodiment, the blockchain network 100 includes blockchain nodes that can be implemented as peer-to-peer distributed electronic devices each executing an instance of software and / or hardware that performs operations according to a blockchain protocol that is wholly or partially agreed upon among operators of the blockchain nodes. In some examples, these distributed electronic devices are simply referred to as "nodes", such as node 102 in FIG. 1. An example of a blockchain protocol is the Bitcoin protocol.

[0163] Node 102 can comprise any suitable computing device (e.g., a server in a data center, a desktop computer, a laptop computer, a tablet computer, a client computing device such as a smartphone, etc.) by a plurality of computing devices within a distributed system of computer resource service providers or by any suitable electronic client device. Node 102 can have an input for receiving data messages or objects representing proposed transactions, such as transaction 104. Node 102 can query about the information they hold, for example, regarding the 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 among the nodes 102. Regarding which node 102 can communicate with which other node, these details do not need to be determined centrally. Active nodes within the blockchain network 100 can communicate with one or more other nodes 102. As a result, assuming that the message is a message indicating that the blockchain protocol should transfer it, the message passed from one node 102 to another node 102 can propagate throughout the blockchain network 100 (or a significant portion thereof). 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 can be the announcement of a new block proposed for inclusion in the blockchain.

[0165] FIG. 2 shows an example of a blockchain node 202 that can be used in a blockchain environment as a node within the blockchain network of FIG. 1. As shown, the blockchain node 202 includes a processor 204, a program memory 206, a storage device 208 for blockchain rules and protocol details, a list of peers 210, a storage device 212 for application variables, a communication interface 214, and a storage device 216 for the blockchain ledger. The blockchain ledger 216 includes data corresponding to blocks 221, 222, 223, such as blocks 222 having transactions 230(1)-(4), which contain data corresponding to transactions. Except for block 223, the blocks can be cryptographically immutable in that subsequent blocks depend on values calculated based on the block when the block becomes immutable, and any modification to an immutable block can be easily recognized as an invalid block by other blockchain nodes. Block 223 is shown as an open box representing the storage of transactions that may be changeable and have not yet been committed to the blockchain.

[0166] The blockchain node 202 communicates via a communication interface 214 that can be implemented as one or more of wired or wireless communications. The blockchain ledger 216 may be a complete copy or a part of the blockchain ledger of the blockchain network. Some of the blockchain nodes maintain only untransferred transactions, while others maintain the entire ledger. In this way, since each node can have its own copy, the ledger is a distributed ledger. Nodes preferably modify only their own copies according to the rules of the protocol, and for all nodes that fully comply with those rules, their copies should, except for a certain propagation time for blocks and transactions, be the same as those of other nodes. The blockchain node should include a function to verify the received blocks and the transactions within those blocks. According to the rules of the blockchain protocol, if a blockchain node determines that a block of transactions is invalid, it does not propagate the block or the transaction to other nodes. According to this rule, valid blocks and transactions that have been confirmed to be valid may propagate through the blockchain network, but invalid blocks and transactions do not propagate.

[0167] Some of the nodes within a blockchain network may be miner nodes that perform operations of collecting transactions and creating blocks of transactions so as to be able to commit new blocks to the blockchain. The miner nodes may be expected to perform some operation that is complex (to avoid an improper node from easily generating an inappropriate block) and that depends on the data of the transactions included (so that an improper node cannot perform a complex operation in advance). The performance of these tasks can be easily verified by other nodes. These other nodes verify the work of the miner nodes, and upon verification, accept the blocks into their copy of the blockchain and propagate it. Thereby, new blocks are committed to the distributed ledger of the blockchain. In some examples, a block is a group of transactions and is often marked with the timestamp and "fingerprint" (such as a hash) of the previous block. In this way, each block is linked to the previous block, and a "chain" is generated that links the blocks of the blockchain. In embodiments, a valid block may be added to the blockchain by consensus of the nodes within the blockchain network. Also, in some examples, the blockchain includes a list of verified blocks.

[0168] In one embodiment, at least some of the nodes operate as verification nodes that verify transactions as described in this disclosure. In some examples, the blockchain attests to value in the form of digital assets, and the transactions of the blockchain provide a chain from a genesis transaction (which starts the blockchain) or a distribution transaction that newly "mines" digital assets for which a miner node operator participates, to subsequent transactions. The end of one part of the chain is an unspent transaction, or a portion thereof, and each transaction on the blockchain specifies one or more outputs. Some of these outputs may be transferred and some may not be. Here, an output includes a specification of the value of that output and the requirements necessary to "unlock" that output by inserting a valid transaction (i.e., one that meets at least the specified requirements) that extends the relevant part of the chain. As used herein, an unspent transaction output may be referred to as a UTXO. Unlocking a UTXO is also known as using the UTXO.

[0169] The requirements necessary to unlock a UTXO can be specified within the lock script of the UTXO. A valid unlock transaction can (i) specify one or more previous UTXOs as inputs to the transaction, where the specification may be by pointer to the UTXO, (ii) meet the requirements of the lock script for each UTXO, and (iii) 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 satisfaction of the lock script requirements is called an unlock script. The verification node can process the lock script following the unlock script, and the output of that processing is either an invalid result or verification of the unlock transaction.

[0170] If a process where a node executes an unlock script and a lock script, and the result can be verified as the result at other nodes, then the process is a stateless process. Therefore, an unlock transaction that satisfies the lock script of the output of a previous transaction on a blockchain that has not yet been transferred can be propagated and ultimately committed to the blockchain. The node that creates the unlock transaction to be committed can specify in its own lock script the requirements necessary to unlock the value of the output of the new transaction. This process can be considered stateless because the script does not need to refer to references outside the script and, with some minor exceptions, does not depend on variables or other states outside those scripts. As a result, the unlock script and the lock script can be evaluated separately.

[0171] In other variations, the blockchain system may include a feature that allows external data to be included in the script evaluation process. In such cases, the external data can be controlled and / or secured in a way that ensures consistency among the nodes executing the evaluation when the unlock script and the lock script are evaluated using the external data.

[0172] Figure 3 shows an example of a transaction 300 stored in the blockchain ledger used by the blockchain node of Figure 2. Other variations with similar functionality are possible. The data elements or fields of the transaction may be as shown in Figure 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 transaction 300. The #vin field 304 indicates the number of transaction inputs (described below) present in transaction 300. There are other fields not shown, but for each transaction input (here shown as Vin[y] 310 by way of example), there may be a set of fields including a transaction ID (TxID) 311 of the previous transaction and a pointer 312 to one of the outputs of the previous transaction (the transaction that provided the transaction output that matches transaction input 310), where both the TxID 311 and the pointer 312 together form a pointer 313 to the output of the previous transaction. As used herein, in the context of a current (or present) transaction, the term "previous transaction" may refer to a particular previous transaction having a transaction output that is referenced (and "transferred") by the current transaction. In an example, the current transaction may be referred to as an "unlock transaction".

[0173] In some blockchain implementations, there is no centralized mechanism for assigning unique TxID values. Instead, there is 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 exactly the same content as any other valid transaction, each valid transaction can have (except for the astronomically low probability of a hash collision) a hash that is unique to the TxID. However, here it is assumed that each transaction has a unique transaction ID. Due to the nature of hashes, once the TxID is generated from the content of the transaction, none of that content can be changed and the TxID remains valid for that transaction.

[0174] As shown in FIG. 3, the set of fields for a transaction input Vin[y] 310 includes an Unlocking_Script_Length field 314 indicating the length of the following script, an Unlocking_Script field 315 including the unlocking script for vin[y] 310 that "unlocks" the corresponding lock script of the transaction output indicated by the pointer 313, and a Sequence# field 316 that can be used to constrain the transaction 300.

[0175] Figure 3 explicitly shows only one transaction input and one transaction output, but one or more are possible for each. Following the transaction input, there may be a #vout field 320 that can indicate the number of transaction outputs (also described below) present within transaction 300. For each transaction output (here shown as exemplary Vout[x] 330), there may be a series of fields including an Output Value (output value) field 332 that indicates the transaction value provided by this transaction output Vout[x] 330, a Locking_Script_Length field 334 that indicates the length of the following script, and a Locking_Script field 336 that includes the locking script for this transaction output Vout[x] 330. Thus, the transaction value of this transaction output can be "transferred" by anyone who can create an unlock transaction having a transaction input with an unlock script that the blockchain node can verify as TRUE when performing verification using the unlock script and the locking script. After the transaction output fields, there may follow other fields such as a Lock Time field 338 that restricts the transaction 300 from being active before a specified future time or before a specified future block. Each transaction input of an unlock transaction refers to the corresponding transaction output of the output of the previous transaction, and if the output of the previous transaction includes a transaction value, the transaction input need not include a field indicating that transaction value.

[0176] Figure 4 shows an example of a blockchain transaction 400 that is specific to the 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 fields shown or described in the present disclosure. Transaction 400 includes an nVersion field 402 having a value indicating the version of transaction 400. The #vin field 404 can indicate the number of transaction inputs present within 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 indicates a specific output of the previous transaction, a scriptSigLen field 414 that indicates the length of the subsequent unlock script, a scriptSig field 415 that includes the unlock script for that transaction input Vin[y] 410, and an nSequence field 416 that can be used to limit transaction 400.

[0177] Following the transaction inputs, there is a #vout field 420 that indicates the number of transaction outputs present within transaction 400, and for each transaction output (here shown as exemplary Vout[x] 430), there may be a series of fields including an nValue field 432 that indicates the transaction value provided by this transaction output Vout[x] 430, a scriptPubKeyLen field 434 that indicates the length of the subsequent lock script, and a scriptPubKey field 436 that includes the lock script for this transaction output Vout[x] 430. Transaction 440 may also be shown with an nLockTime field 438 that can restrict transaction 400 from being active before a specified future time or before a specified future block.

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

[0179] Certain embodiments of the present disclosure operate under the assumption that a script system or other system for implementing the described instruction set allows for more than 200 instructions (e.g., more than 200 OP codes) in a single script. Similarly, certain embodiments of the present disclosure further assume that the functionality provided by the opcodes referred to in the present disclosure exists and is possible in the system that executes the opcode, script / instruction set. Examples of the operation codes referred to in the present 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 item, and pushes the remainder onto the stack.

[0181] OP_BIGMODADD Pops the top three items from the stack, modulo adds the first and second items, modulo divides by the third item, and pushes the result onto the stack.

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

[0183] OP_BIGMODMUL Pops the top three items from the stack, modulo multiplies the first and second items, modulo divides by the third item, and pushes 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 whether the popped signature is a valid signature, and if valid, pushes 1 (TRUE) onto the stack, and if not, pushes 0 (FALSE) onto the stack.

[0186] OP_CHECKSIGVERIFY Has the same function as OP_CHECKSIG, but OP_VERIFY is executed later.

[0187] OP_DIV Pops two items from the stack, divides the second item by the first item, 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 or OP_NOTIF or OP_ELSE was not executed. If the preceding OP_IF or OP_NOTIF or OP_ELSE was executed, or if the immediately preceding OP_IF, OP_NOTIF, OP_ELSE was executed, these statements are not executed.

[0190] OP_ENDIF Ends the if / else block.

[0191] Read the first two items on the OP_EQUAL stack and push 1 onto the stack if the two items are exactly equal, and 0 otherwise.

[0192] OP_EQUALVERIFY is the same as OP_EQUAL, but then executes OP_VERIFY.

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

[0194] OP_HASH256 The input is hashed twice, first by SHA-256 and then by 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 Multiply the top two items on the stack.

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

[0198] OP_OVER Copy the second item on the stack and push it onto the top of the stack.

[0199] OP_ROLL The top n items on the stack are moved to the top.

[0200] OP_SUBSTR Returns a section of a string.

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

[0202] OP_TOALTSTACK Places the input on top of the alternative stack and removes it from the main stack.

[0203] OP_VERIFY If the top stack value is not true, mark the transaction as invalid.

[0204] Some of the above OP codes may be basic OP codes supported by blockchain nodes, while others are referred to here as OP codes for clarity, but are typically implemented as a small script composed of multiple basic OP codes. For example, OP_BIGMOD is referred to as an OP code, but may be implemented using a series of OP codes to perform the function of dividing the top two items on the stack and returning the remainder. OP_BIGMODADD, OP_BIGMODINVERSE, OP_BIGMODMUL can be easily expressed as a sequence of similar OP codes.

[0205] OP_GENSIG In this disclosure, references to OP_GENSIG should be regarded as abbreviations for the operations corresponding to the OP_GENSIG script described herein. The OP_GENSIG script that generates the signature of a transaction can also be pushed onto or used on the stack. The OP_GENSIG script first takes the inputs pushed onto the main (last-in, first-out) stack in order: <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 transaction fields used in the transaction), private key (Message value <m>used for the hash of), and the numbers <k>(A random or pseudo-random number used to mask / protect the 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 it to the alternative stack and then for the elliptic curve generator <PubK G> <k>Multiply to generate the elliptic curve point K at the top of the main stack. The second line of the script calculates 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 determines s = k -1 (m + r×a) mod n. Finally, the fourth line of the script encodes r and s in DER format and concatenates them to <SIGHASH Type>.

[0207] The type of the signature hash can be indicated by SIGHASH Type, which is a byte - encoded value. The SIGHASH Type value specifies the set of fields to be extracted from the transaction before serialization (e.g., normalization) and hashing. 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 the input script, are included in the serialization (and thus hashed and signed). In one embodiment, the type SIGHASH_NONE indicates that the output does 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 a new version of the transaction using the same hash (assuming the hashed fields are not changed), but the signed output is only the output at the same position as the input.

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

[0209] By requiring the inclusion of SIGHASH in the unlock script, the lock script can verify that the set of serialized unlock transaction fields provided by the unlock script is actually the source of the SIGHASH, and then use the OP code 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 can do this when executed by a transaction validator, as the transaction validator can then execute the OP_CHECKSIG operation and place the signature of the actual unlock transaction on the stack.

[0210] OP_DERENCODE In the present disclosure, references to OP_DERENCODE should be regarded as an abbreviation for an 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 the present disclosure, references to OP_ECPMULT should be regarded as an abbreviation for an operation corresponding to popping two items from the stack, performing an elliptic curve point multiplication (also called elliptic curve scalar multiplication) on these two items, and pushing the result onto the stack.

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

[0213] OP_PREVTXINJECTION In the present disclosure, references to OP_PREVTXINJECTION should be regarded as an abbreviation for an operation corresponding to the injection of the previous transaction corresponding to the input X of the unlock transaction. Figure 6 shows the input and output of the OP_PREVTXINJECTION script.

[0214] OP_SELFTXINJECTION In the present disclosure, references to OP_SELFTXINJECTION should be regarded as an abbreviation for an operation corresponding to the injection of the previous transaction corresponding to the signed input. Figure 7 shows the input and output of the OP_SELFTXINJECTION script.

[0215] OP_SPENDINGTXINJECTION In the present disclosure, references to OP_SPENDINGTXINJECTION should be regarded as an abbreviation for an operation corresponding to injecting a serialized unlock transaction into a lock script. An entity that provides a SIGHASH Type value and a set of unlock transaction fields determined according to the SIGHASH Type can unlock a transaction output. This is a convenient feature. FIG. 8 shows the inputs and outputs of the OP_SPENDINGTXINJECTION script.

[0216] OP_EXTRACTTXID In the present disclosure, references to OP_EXTRACTTXID should be regarded as an abbreviation for an operation corresponding to obtaining a transaction ID and a transaction ID position as inputs and outputting the extracted transaction ID. The input to OP_EXTRACTTXID is a value X indicating a serialized transaction and an input index, and the output is a transaction identifier associated with the transaction input at that index in the serialized transaction. This script may need to parse the serialized transaction to extract the transaction ID. Because the serialized transaction contains a variable-length field with a length distribution indicated by other fields within the serialized transaction.

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

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

[0219] In a stateless stack-based transaction validator, the lock script 910 and the unlock script 920 are processed independently, with some minor exceptions, and do not depend on variables or other states external to these scripts. As a result, the lock script 910 does not need to reference fields of previous transactions external to the lock script 910 itself. The lock script 910 also cannot reference fields of the unlock transaction 922 because there was no lock transaction 922 when the lock script 910 was created and made immutable, i.e., the lock script 910 was created before the lock transaction 922 existed.

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

[0221] In a stack-based operation, the transaction validator executes the unlock script by processing each OP code in the script in order. Some OP codes are processed as a result, and some result in data being pushed onto or popped from the stack, or some combination. When the execution of the unlock script is complete, there may be data remaining on the stack. If there are no script errors or OP codes that end the execution during the execution of the unlock script, the transaction validator can 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 OP codes, this is substantially similar to executing a single script that includes the concatenation of the unlock script and the subsequent lock script. However, performing a script error check at the end of the execution of the OP codes of the unlock script and before the execution of the OP codes of the lock script can prevent problems caused by an improper unlock script.

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

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

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

[0225] Since 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 described above, the lock script can impose constraints on what should be within the unlock script via signatures and other cryptographic techniques.

[0226] One such constraint could be that the unlock script must contain some arbitrary data. Among the constraints, there could be "weak constraints" or more general constraints, such as a constraint that the unlock script must contain data of a 4-byte length, or a constraint that contains a certain number of bytes without constraining the bytes to a specific value. That the data must generate a specific hash value when hashed can be a stronger or more specific constraint. This latter constraint typically requires that the data be of a specific length and be a value unique to that data. Because it is almost impossible for someone to determine different values that produce the same hash. The constraints can be implemented in the script by having the unlock script push that data or the hash of that data onto the stack, the lock script push the required hash onto the stack, then execute the OP_EQUAL, and then execute the OP_VERIFY opcode. Those opcodes return True if the two pushed items match and False if they do not. In a more general case, constraints can be imposed that require the presence of specific data or data with specific characteristics.

[0227] An example of a weak constraint is that the unlock script must contain certain data that can potentially form a set of serialized unlock transaction fields without necessarily requiring those fields to be of specific values. In this way, the lock script can constrain the script of the unlock script that unlocks the output of the lock script to include 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 the unlock script must contain certain data that can potentially be obtained from a specified location, but there are no constraints on the value of the data. This allows some weak constraints to be imposed even if the value of the data is not determined until after the lock script has become immutable.

[0228] The operations of the constraints and the data of the constraints may include elements of a "smart contract". A smart contract is something that defines the terms of a contract, such as who can do what, when they can do it, and who, when, and what is paid. If the terms can be expressed as weak or strong constraints on the unlock script or other parts of the unlock transaction, the terms of the smart contract can be enforced by the blockchain protocol. Thus, as in the example above, for instance, if only Bob can unlock the value of a locked transaction output (because only the unlock script that Bob can create can unlock that transaction output), the transaction output can be used only after a certain amount of time has passed and only after another transaction output has been used, if permitted by one of the parties.

[0229] Figure 8 shows the OP code abbreviation for a script that encodes the constraints for causing an OP_SPENDINGTXINJECTION, i.e., the injection of a set of serialized unlock transaction fields. The lock script may include the OP code OP_GENSIG (which results in generating a Bitcoin signature) and the subsequent OP code OP_CHECKSIG (which results in the signature being checked as a valid signature for the unlock transaction). For OP_GENSIG to generate a valid signature, it must have, as 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 pseudo-random number used to mask / protect the private key). By including a hash OP code, a private key, and a random number in the lock script, this effectively constrains the unlock script to provide the SIGHASH type and the set of serialized unlock transaction fields.

[0230] Figure 11 shows 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 other generators of the transaction. As shown in Figure 11, the serialized transaction 1110 (i.e., a transaction represented as a series of data objects in a specific format) includes a set of field values of the transaction. The signer of the serialized transaction 1110 selects a SIGHASH Type 1112 and provides the signer's private key. The blockchain client / node can determine from the SIGHASH Type 1112 which fields or modified fields of the serialized transaction 1110 should be used. Some of the fields may be modified (other than setting to zero) before the hash is generated. In the example of Figure 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., by performing a double SHA-256 hash), resulting in a message m1116. The blockchain client / node processing the serialized transaction 1110 typically selects a number k1118, which is typically a random or pseudo-random number, to mask / protect the private key. The number k is referred to as the "mask number" at the time of this disclosure. Next, the blockchain client / node generates a signature 1124 (in this example, a DER-encoded EC signature) from a set of signature inputs 1120 from the SIGHASH Type 1112, the message m1116, the signer's private key 1122, and the number k1118. Next, the signature 1124 and the SIGHASH Type 1112 can be used in an unlock script.

[0232] Figure 12 shows an example of an unlock transaction 1200 that includes an unlock script 1203 containing a copy of the unlock transaction (such as a set of serialized unlock transaction fields). As shown in Figure 12, one of the transaction inputs is Vin[z]. The input Vin[z] has a hash that is the previous transaction TxID and the number of outputs n of the previous transaction. Combining these forms a pointer 1202 to a specific output of a specific previous transaction that Vin[z] is to unlock. The transaction input Vin[z] has an unlock script 1203, which also has several components or subscripts 1206, 1208, 1210, 1212. The 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 having an output transferred by the serialized Previous TxZ in the same way. Although not shown, additional previous transactions can be included. Also, the unlock script 1203 includes a SIGHASH_TYPE byte 1210 to indicate which fields of the unlock transaction 1200 are included.

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

[0234] The set of serialized transaction fields of an unlock transaction does not include the unlock script of the unlock transaction itself. Otherwise, problems of causality would arise. In some embodiments, for example, in a Bitcoin blockchain environment, the signature hash of a transaction can exclude some predetermined fields. The SIGHASH Type may represent which set of fields is extracted from the transaction before being serialized and hashed.

[0235] The lock script of the previous transaction can impose on the unlock transaction the requirement that, for the unlock transaction to be valid, the unlock script of the unlock transaction must include a copy of some or all of the fields of the unlock transaction and a reference to one or more of the transactions before the one that the unlock transaction unlocks. Of course, the fields of the unlock transaction can be changed when the unlock transaction is created. However, the lock script of the previous transaction can impose constraints on the fields of the unlock transaction in that the unlock transaction does not have to verify at the time of execution of the lock script if the fields of the unlock transaction that are part of the unlock script of the unlock transaction do not meet the constraints. Fields that are not part of the unlock script (such as fields not included by the SIGHASH Type value or not set to zero) do not have to be constrained by the lock script. Also, not all fields included in the serialized unlock transaction need to require constraints. For example, the lock script may only constrain one of many fields of the serialized unlock transaction included in the unlock script.

[0236] Different outputs of a previous transaction can potentially apply different sets of constraints to different inputs and outputs of different unlock transactions. Using such techniques, a blockchain node can generate a transaction using such a lock script, which can perform additional checks such that the generated transaction output can be transferred and the transaction unlocking that output can necessarily carry various data elements and states.

[0237] The transaction of FIG. 12 can be extended to implement a state machine with fairly complex functionality. As described above, the lock script can access data that is only available after the lock script has been created and finalized at verification time. That data can include details of the fields of the unlocking transaction being verified, and details of previous transactions including the lock script (and other previous transactions known to the blockchain node creating the unlocking transaction at that time may also be possible). This allows the state of the state machine to be represented within the script, the states and state transitions to be implemented, and to occur within the trustless scope of the blockchain environment. In other words, the state machine can be implemented by processing transactions in the same way as other transactions processed by the blockchain network, using transactions that are verified by potentially untrusted blockchain nodes. In some examples, "trustless" represents the property that any entity can create a valid unlocking transaction as long as the 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 necessary inputs. In some embodiments, one or more inputs can be obtained from an undetermined source such as a serialized previous transaction.

[0238] In a blockchain network, a transaction has some values of its inputs (determined by the transaction output values of the transaction before the transaction inputs are unlocked), and some values of its outputs. For it to be valid, the total of the outputs cannot exceed the total of the inputs (excluding distribution transactions and genesis transactions which may be excluded in this explanation), and also, for it to be incorporated into a miner node, the outputs may be made 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 exist within transactions that contain sufficient value to provide a reason to the miner for including the transactions corresponding to the state transitions of the state machine.

[0239] In a general case, the unlock script of the previous transaction can be used when implementing the state machine. As a result, the unlock transaction represents the state transition of the state machine by a lock script that constrains the content of the unlock transaction, particularly 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 substantially specify how each transaction output of the unlock transaction needs to be. The lock script can require different characteristics of different unlock transaction outputs, for example, by requiring that Vout[0] of the unlock transaction contains specific data and script elements, and that Vout[1] of the unlock transaction contains specific other data and other script elements.

[0240] An entity that provides a SIGHASH Type and the set of unlock transaction fields used by a particular SIGHASH Type can unlock a transaction output. In this way, some parties have a reason to propagate the content of a transaction by unlocking and transferring details from a lock script. As described above, in some examples, "unlocking" a transaction output means creating an unlock transaction that can reference and evaluate the transaction output, thereby causing a transfer of the transaction output.

[0241] Using the techniques and apparatus described above, a transaction can be created on a blockchain ledger that includes a script implementing a smart contract, can implement a state machine, and can reference the fields of the current transaction, the previous transaction having the outputs transferred by the current transaction, and optionally other previous transactions. These capabilities enable a transaction flow to enforce a self-replicating script, such as used in a smart contract.

[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, the constraints of the lock script for Vout[x] must be satisfied. As described above, some constraints may be simple. For example, a simple requirement is that the unlock script of the unlock transaction input referring to the lock script must provide a valid signature signed by the public key appearing in the lock script. However, as described herein, a lock script can provide more complex constraints.

[0243] For example, the lock script of Vout[x]1314 of the previous transaction 1310 can impose constraints on the output of the unlock transaction, particularly. The lock script of Vout[x]1314 in this example imposes a series of constraints (Constraint Set1) on the output Vout[0]1324 of the unlock transaction 1320 and a series of constraints (Constraint Set2) on the output Vout[0]1326 of the unlock transaction 1320. In certain cases, Constraint Set1 and Constraint Set2 are the same, and both simply require that the lock scripts of the outputs Vout[0]1324 and Vout[1]1326 are the same as the lock script of Vout[x]1314 of the previous transaction 1310.

[0244] In a more general case, the constraints may go beyond simply copying the lock script. Furthermore, the constraint sets can vary from output to output of the unlock transaction. These constraints can require the number of outputs the unlock transaction can have, the values of each output, and the specific content of the lock scripts of the outputs of the unlock transaction.

[0245] Constraints on the Outputs of the Injected Unlock Transaction Figure 14 is a flowchart of an example of a portion 1400 of a lock script of a transaction before imposing constraints on the unlock transaction lock script. This example may be executed by a stack-based validator that processes the unlock script of the output of the unlock transaction, which can leave data on the stack, and then processes the lock script of the output of the previous transaction to perform this process. Since the processing of the unlock script can leave data on the stack, and since the unlock script can leave, for example, the serialized content of the unlock transaction, including details of the lock script of the unlock transaction, on the stack, these details are available at verification time.

[0246] In step 1402 of the process, the validator verifies that the unlock script contains certain data, and the validator may perform other verifications that do not need to be done for each output. Examples of such data may include a set of serialized unlock transaction fields, the serialized previous transaction, a reference to the previous transaction, etc. At step 1404, the validator checks whether these constraints are met, and if not, stops at step 1406 and invalidates the unlock transaction. Otherwise, the process proceeds to step 1408, where the validator determines whether there is an unlock transaction output to be checked. For the first time, the validator may set the index i = 0, and if there are no more outputs to be checked, moves to another processing flow at step 1410.

[0247] For each index of the output, the verifier executes 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 one by one and verifying each output, the verifier loops through a set of indexes, which may not necessarily include all values of i and / or may not include them in an additional order, and does not check them. In such a variation, step 1418 is different accordingly and loops through index i for the outputs within the specific set of indexes being checked.

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

[0249] The unlock script of the output of the previous transaction constrains the output of the unlock transaction so that the previous transaction lock script can indicate rules regarding how to transfer the output of the unlock transaction. These constraints can be hard-coded in the unlock script of the output of the previous transaction, or can be determined based on data present in the unlock script of the input of the unlock transaction that refers to that output of the previous transaction.

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

[0251] There is step 1506 regarding certain constraints that the lock script of the output of the previous transaction can impose on the lock script of the output of the unlock transaction, and the lock script of the output Vout[i] of the unlock transaction must be equal to the data from some determined source ("==" represents an equivalence test). Another example is step 1508, where the lock script of the output Vout[i] of the unlock transaction must be equal to the data hardcoded in the lock script of the output of the previous transaction. Step 1510 covers the case where another constraint is imposed on the output Vout[i] of the unlock transaction based on the data from the determined source, and step 1512 covers the case where another constraint is imposed on Vout[i] based on the data hardcoded from the lock script of the output of the previous transaction.

[0252] In some cases, instead of using the full range of data from the source or hardcoded data, the hash of the data can be used. In this case, the comparison is made from hash to hash.

[0253] The data to be used may be from a previous transaction, for example, hardcoded in the unlock script of the output of the previous transaction, or from a transaction preceding the previous transaction (or a reference to a preceding transaction, two links out of the unlock transaction (i.e., the transaction to which one or more of its outputs were transferred by the previous transaction)). In this way, the data to be used can be obtained from any transaction in the chain from the previous transaction to its distribution transaction (e.g., the Coinbase transaction of the Bitcoin protocol).

[0254] Figure 16 shows an example of this. For step 1402 in process 1400 of FIG. 14 (the verification is that the unlock script has specific data), steps 1602, 1604, 1608, 1610, and 1612 are executed 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. Next, in step 1604, the verifier can verify that the unlock script also includes a copy of the serialized previous transaction of that TxID. If not, the verifier can invalidate the transaction, but if so, in step 1608, the verifier extracts the TxID from the previous transaction TxID', and then in step 1610, verifies that the previous transaction includes a copy or reference to the serialized transaction referenced by TxID'. This chain can continue n times, where in step 1612, the verifier is the 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 extract the lock script for a copy of the transaction referenced by TxID n ' and verify the constraint that the lock script of the unlock transaction's output Vout[i] is equal to the extracted lock script of the transaction referenced by TxID n '.

[0257] The constraint can apply to a subset of the output's lock script rather than the entire lock script. The constraint can be determined from a subset of the data rather than the entire data. For example, one subset may require that "Pay-to-Public-Key-Hash" appears, and another subset may require that "Pay-to-Bob" appears.

[0258] The lock script of the unlock transaction's output is <x> <y>Suppose it can be expressed in two parts. Here, <x>and <y>is <x>and <y>It can be extracted using a string concatenation operation so that constraints are applied individually. For example, <x>is restricted to <PubK A>, <y>It is restricted by OP_CHECKSIG. In this way, the overall lock script is restricted by <PubK A>OP_CHECKSIG. It is also possible to use the constraints derived from the data within the unlock script.

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

[0260] The constraints can correspond to indices that reference various outputs. In some cases, the constraints are repeated for each index, while in other cases, some structures can be provided. For example, the index of the 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 series of indices are hardcoded, the result of the part of the script using those indices can be fixed. Instead of, or in addition to, the constraints on the outputs of the unlock transaction, there can also be constraints on the inputs of the unlock transaction.

[0262] Constraints on the inputs of the injected unlock transaction One use of having a lock script that constrains the inputs of an unlock transaction is to enable the lock script to encode dependencies on transactions that have certain properties (e.g., the constrained inputs must reference that transaction). This is different from constraining the outputs of an unlock transaction in that the outputs are variable. 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 meet the constraints, while the inputs that meet those constraints must be found.

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

[0264] Figure 17 shows a previous transaction 1710 and an unlock transaction 1720. 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 of Vout[x]1714 imposes a constraint set (Constraint Set1) on input Vin[0]1722 and a constraint set (Constraint Set2) on input Vin[0]1723. The constraint sets can include constraints on the unlock script, references, or other parts of the input. The constraint sets can be the same, different, or there can be two or more inputs, some of which are the same input and some of which are different inputs.

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

[0266] Figure 18 is a flowchart of an example of a portion 1800 of a lock script of a previous transaction that imposes constraints on the inputs of an unlock transaction. This example may be executed by a verifier that processes the unlock script of the output of the unlock transaction. The verifier leaves data containing details of the unlock transaction on the stack and then processes the lock script of the output of the previous transaction to perform this processing.

[0267] In step 1802 of the process, the verifier verifies that the unlock script contains certain data, and the verifier may perform other verifications that are not necessary 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, the process proceeds to step 1808, where the verifier determines whether there are unlock transaction inputs to be checked. On the first pass, the verifier can set the index i = 0, and if there are no more inputs to be checked, moves to another processing flow at step 1810.

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

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

[0270] Constraints can be set on fields of the previous transaction corresponding to a reference during input. This may be possible by using the TxID in the input to cause an injection of the corresponding previous transaction before imposing constraints on the fields of the previous transaction. The constraint can reference an input different from the input that unlocks the output of the previous transaction that has the lock script imposing the constraint.

[0271] Figure 20 shows an example of constraints related to steps 1802 and 1814 in process 1800 of FIG. 18. In FIG. 20, steps 2002, 2004, 2014, and 2016 can be performed. In step 2002, the verifier extracts a transaction ID (TxID) from the inputs of the unlock transaction. This can be done if the TxID is available in the unlock script. Next, in step 2004, the verifier can verify that the unlock script also includes a serialized copy of the previous transaction for that TxID. In step 1614, the verifier extracts one or more field sets from the previous transaction, and in step 1616, verifies any constraints on the extracted field sets.

[0272] Figure 21 shows interlock script constraints. As shown here, previous transaction (Previous Tx1) 2102 and previous transaction 2104 (Previous Tx2) may be referenced by the inputs of unlocking transaction (Unlocking Tx1) 2106. In particular, as indicated by arrow 2110, the input Vin[0] of Unlocking Tx1 points to Vout[0] of Previous Tx1. Thus, if Unlocking Tx1 is valid, Vout[0] of Previous Tx1 can be unlocked. Also, as indicated by arrow 2112, the 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] To reference previous transactions, these transactions must already exist and be immutable before the unlocking transaction is created. Nevertheless, the previous transactions can apply interdependent lock script constraints to the unlocking transaction. By imposing constraints on the set of inputs of the unlocking transaction, an interdependent lock script can be implemented, which can provide parallelism, among other things, in the context of a trustless deterministic state machine.

[0274] The lock script 2120 of the output Vout[0] of Previous Tx1 has a constraint on the input Vin[1] of Unlocking Tx1 that requires the 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 of the output Vout[0] of Previous Tx2 has a constraint on the input Vin[0] of Unlocking Tx1 that requires the 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 is complete, a transaction lock script cannot directly specify the TxID that an unlocking transaction unlock script should reference. Basically, however, the lock script extracts an input pointer (including the TxID of the previous transaction that has the lock script), executes this, uses that TxID to inject into the fields of the previous transaction, and can verify that some fields of the previous transaction are equal to the expected values. In other words, the previous transaction has fields set to certain values, the lock script of the previous transaction obtains the TxID from the unlocking transaction input, injects the transaction that the TxID references, checks that the fields are set to the specific values, and if the fields are not set to that specific value, the unlocking transaction input must refer to a different previous transaction. Thus, by checking for specific values, the lock script of the output of the previous transaction can confirm whether the unlocking 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) whose first output also unlocks the first output of a specific 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 lock scripts enable, among other things, multiple smart contracts that condition each other. For example, smart contract 1 is "Alice agrees to donate 1 BTC to Carol only if Bob donates 2 BTC to Carol", and smart contract 2 is "Bob agrees to donate 2 BTC to Carol only if Alice agrees to donate 1 BTC to Carol". For it to be valid, the unlocking transaction must unlock both smart contracts.

[0278] As described above, lock scripts can encode dependencies on transactions with specific properties, and those properties can include fields of the transaction. This means that it is possible to make a lock script dependent on a transaction with a specific lock script.

[0279] For example, in the example of Figure 21, lock script #1 (of Vout[0] of Previous Tx1) restricts Vin[1] of Unlocking Tx1 to reference lock script 2124 (of Vout[0] of Previous Tx2), and lock script #3 2124 restricts Vout[0] of Unlocking Tx1 to reference lock script #1 of Vout[0] of Previous Tx1. Here, this can be called a lock script that encodes a dependency on another lock script.

[0280] Implementing mutually dependent 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. This is because one of Previous Tx1 and Previous Tx2 may 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 impossible for lock script B to hard-code a dependency on an unknown lock script A. This can be addressed by having determinable dependencies in at least one of the lock scripts.

[0281] For example, lock script A depends on lock script X, where lock script X is provided within unlock script A, and lock script B depends on lock script Y provided within unlock script B. When an unlock transaction is created, since both lock script A and lock script B are known, 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 variations, to verify the unlock transaction input, the unlock script must reference Previous Tx1 and Previous Tx2. In other variations, it is sufficient for the unlock script to reference two (or more) previous transactions with the same lock script as Previous Tx1.

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

[0284] State machine Using the above techniques, a state machine can be implemented using blockchain transactions. Here, the transaction has a state, is encoded by a state machine structure such as a transaction matrix, and the next state is allowed. An unlock transaction can unlock the output of such a blockchain transaction and effectively cause a state transition of the state machine.

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

[0286] In embodiments, the set of state rules 2206 may include a state transition matrix that can be represented by constraints imposed on the unlock transaction 2204 by a lock script. In such embodiments, the constraints may be parameterized by the current state and the input that determines the next state. The constraints may include checks to ensure that the unlock transaction 2204 includes an output that includes the next state value in a particular field.

[0287] In embodiments, the current state is represented as a parameter embedded in the transaction, such as part of the lock script of the output of the transaction, 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 with respect to a 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 unlock transaction 2204 is generated. For security, such parameters are derived from a determined source. This can provide deterministic state transitions. Finally, embodiments of a trustless deterministic state machine can be created by using the script of a self-replicating lock script. Additionally, by enabling different lock scripts to be imposed on different transaction inputs and outputs of a transaction, a concurrent trustless deterministic state machine 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”) within a set of state rules 2306. The set of state rules 2306 provides two possible states 2330A (“S2” or “S3”) for the next state. The set of state rules 2306 may be encoded within the lock script of the output of the previous transaction 2302. The current state 2328A may be embedded in a Lock time field or in the lock script. The next state, S2 2328B in this example, is encoded within the lock script of the output of an unlock transaction that unlocks the output of the previous transaction to effect the state transition.

[0290] As seen in Example 2300, unlock transaction 2304 takes as input input 2326 within its unlock script and first state 2328A ("S1") embedded in the set of field values of previous transaction 2302, and determines appropriate second state 2328B ("S2") from state rule set 2306. Further, as seen in Example 2300, the state transition matrix provides new state 2330B ("S4" or "S5") possible for the next state transition from second state 2328B. Note that 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 unlock script. The next state, in this example S2 2328B, is encoded within the unlock script of the output of the unlock transaction that unlocks the output of the previous transaction and performs the state transition.

[0291] In an embodiment, each possible state is represented within a self-replicating unlock script by a set of rules for state changes, such as a state transition matrix, and a particular transaction output represents a state machine in a particular state. In such an embodiment, the unlock script of the transaction output is replicated to all unlock transactions that attempt to transfer control of the digital asset to the next transaction that must be linked to the current transaction output. This process may be repeated until an end condition is met. Since the inputs are not determined and may be undetermined data, the state of the state machine can be changed based on particular external inputs. Thus, the undetermined data provides an input that can affect the next state.

[0292] As an example for illustration, Alice lends money to Bob, and Bob agrees to repay Alice. A trustless deterministic state machine, as described in the present disclosure, can be implemented as a smart contract representing the payments that Bob makes to Alice. For example, the smart contract can be constructed such that Bob makes payments to Alice every month for the next three months, and if he fails to make a payment, his debt enters the collection stage. Thus, as long as Bob makes monthly payments, the current state remains the repayment state. However, if an external entity provides an input indicating that Bob has failed to make a payment, the state branches to the delinquent state. In the delinquent state, Alice can release the transaction and hand it over to a debt collector, as a result of which the trustless deterministic state machine switches to the debt collection state. In the debt collection state, the debt collector recovers 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 and donates one unit of digital assets every month. Under her rules, anyone can claim digital assets, but only one unit per month. Alice creates a smart contract in the manner described in the present disclosure and seeds it with an initial pool of three units of digital assets. Alice can construct a script such that any entity can obtain one unit of digital assets per month. The remaining portion of the digital assets is replicated to subsequent smart contracts.

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

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

[0296] For example, part or all of process 2500 can be executed by a verification node in an exemplary blockchain network, such as exemplary blockchain network 100 of FIG. 1. Such a verification node can 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 computing resource service provider, or any suitable electronic client device). Process 2500 includes a series of operations in which the lock script of a self-replicating smart contract is verified, the current state is obtained from a previous transaction that has been serialized, inputs are obtained from the unlock script, and the next state is determined based at least in part on a set of state rules.

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

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

[0299] In the context of describing the disclosed embodiments, unless otherwise specified, the use of the expression "instructions" with respect to executable instructions (also referred to as code, applications, agents, etc.) that perform operations that typically do not execute alone (e.g., sending data, calculations, etc.) means that the instructions are executed by a machine and thereby cause the machine to perform the specified operations.

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

[0301] As will be described in more detail, a trustless deterministic state machine can be implemented using the lock script and unlock script of a blockchain transaction. The lock script contains the constraints that can be imposed on the unlock script and thus requires the injection of specific data into the unlock script of the unlock transaction, such as the serialized fields of the unlock transaction itself, the serialized fields of the previous transaction including the lock script being executed, the current state value, the input (optional) from the determined source, and the state transition matrix defining a series of flow conditions and operations of the state machine, and defines 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] Figure 26 shows a state machine that uses a state transition matrix 2600 with specific 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 that state transition matrix, it is possible to transition along S1 - S2 - S3 - S4 - S8 - S12, but a transition from S1 may also be required at state S5. 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 should 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 states S4 and S7.

[0303] Each of these states is initiated by a state machine represented by a blockchain transaction output, each transition is processed by a single path of the transaction output, and when an unlock transaction input unlocks the output of the previous transaction, a state transition as shown in Figure 22 or Figure 23 occurs. However, parallel processing of states can be achieved using the inputs and outputs of blockchain transactions. This is convenient when it is necessary to execute a smart contract in multiple parallel steps. During the process of a contract, it may be possible to execute operations in parallel. For example, in a contract to build a house, there are various stages of tile work completion and various stages of landscaping work completion, but these can be done in parallel. By enabling parallel execution within a smart contract, different fragments of the contract can be executed asynchronously and independently of each other.

[0304] Figure 26 shows many requirements for such processing. One is to generate multiple paths from one state. This can be a fork in a smart contract. Assume that a smart contract starts in state S1. The fork of this smart contract can generate two state machines, one in state S2 and the other in state S5. Another requirement is the duplication of a smart contract, which has two identical state machines that are in the same state and operate in parallel. For example, a smart contract may require multiple instances of the steps S2 - S3 - S4. This can be a special case of a fork, the cloning of a smart contract where two or more new transaction outputs have the same state.

[0305] Another useful feature is the creation of a new contract. For example, the smart contract represented by the state transition matrix 2600 in Figure 26 may be such that in state S3, some party to the smart contract can create a separate contract that can be associated with, but is not part of, the smart contract and / or can be created after the smart contract is created. In this specification, this can be called spawning. This new contract can be different from the original smart contract first provided in the state transition diagram of Figure 26.

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

[0307] Figure 27 shows an example of a transaction having one input Vin[0] and two outputs Vout[0] and Vout[1]. By unlocking the outputs of this transaction, two independent transactions are placed on the blockchain ledger, and the creators of these transactions will be compensated by some value (not shown) presented to them by this transaction. As shown in the figure, the lock script of the output of the previous transaction (referred 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 including state S2 (Vout[0] in Figure 27), a future unlock transaction is constrained to include the next state based on the current state being S2. The same applies to state S5.

[0308] In this way, a transaction output can have a state, and constraints can be imposed on what state an unlock transaction can be in. Thereby, blockchain transactions can implement processing according to a state diagram as shown in Figure 26, and the unlocking of a transaction output corresponds to a state transition in the state diagram. To avoid a situation where someone creates one transaction having multiple inputs and unlocks both outputs of the shown transaction, the lock script can check that transaction and disallow it. Rules for how valid transactions are generated, the number of required outputs, etc. are encoded in the smart contract as hard-coded values or parameters provided after the smart contract is created.

[0309] Branching and Cloning of Smart Contracts Using Blockchain Transactions Branching is used when a state needs to transition in parallel to two or more (not necessarily unique) next states. A smart contract may be able to handle without all possible parallelism, but if parallelism should exist, branching may initiate it. As described above, the lock script of the output of a smart contract transaction on the blockchain ledger can "impose" requirements on the input of the unlock transaction and / or on the lock script of the output of the unlock transaction on the blockchain ledger. Cloning may be a specific type of branching where the set of next states may all be the same state. For unlock transactions, multiple outputs may be constrained to replicate the transition matrix and embed each respective next state.

[0310] Branching / cloning can be achieved by applying the constraints of a trustless deterministic state machine to the set of outputs. As described above, a series of indexes can enable applying different constraints to different outputs. This series of indexes can be hardcoded within the transition matrix or provided as part of the input to the verification process.

[0311] A given unlock transaction may have multiple outputs, some of which may be unrelated to the state machine or may be related to multiple unrelated state machines. So, it is more practical to embed the next state in the lock script of the transaction rather than in a field common to all outputs such as the Lock time field. Regarding constraining a subset of the lock script of the output, it is as described above.

[0312] Figure 28 shows how a script relates to a branching operation. As shown, the 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 of which requires that subsequent unlock transactions have the outputs in the specified state (and are separate transactions). This allows these states S2, S3 to be executed independently and, if possible, in parallel.

[0313] Using a state machine helps enable smart contracts for sub - tasks to execute faster and in parallel. Multiple states may be used to process sub - tasks, and since a single state machine can typically be used in only a single state at a time, concurrency can be provided by having separate transaction threads. A state machine can be branched by creating multiple transaction lock scripts. Based on the current state from the output of the previous transaction, the unlock transaction can be constrained to have two or more outputs with lock scripts, as shown in Figure 28. To prevent the branch from becoming insolvent and stopping prematurely, each output value should be checked to ensure there is sufficient funds to continue the state machine.

[0314] As indicated by the dashed arrow, the input Vin[0] of the unlock transaction 2830 refers to the previous transaction 2820 and its output Vout[0]. The lock script of Vout[0] includes the current state ("S1") and a transition matrix for the state machine, constraining the Vout[x] of the unlock transaction 2830 to be the next state ("S3") and the Vout[y] of the unlock transaction 2830 to be another next state ("S2"), each being constrained to convey the state transition matrix and possibly including other constraints in some cases.

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

[0316] Instead of storing the state in the lock script, the state of the state machine can be stored in a field of the transaction. This field cannot be used for other purposes such as the Lock time field. In practice, another unused transaction field can be used. This operates in a single state and can also operate when multiple states need to be stored, but it may be more complex.

[0317] Figure 29 shows an example of pseudocode that can be executed to perform a branching or cloning process. This pseudocode can be implemented using the OP codes described herein. This pseudocode can be executed by a processor of a blockchain node that generates and / or verifies transactions. In some embodiments, part of the script is from the unlock script and part of the script is from the lock script.

[0318] In the pseudocode of FIG. 29, the previous transaction, unlock transaction, and optional inputs are injected so that the lock script can access them. Then, a check of the end condition may be performed. If the smart contract has not ended, 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. Next, the processor loops through the outputs of the unlock transaction and for each of them extracts its lock script and checks the transaction matrix within the previous transaction lock script to determine whether it matches the transaction matrix within 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 verify the unlock transaction. If they match, the processor determines the next state of the state machine from the extracted current state, state transition matrix, optionally inputs, and output index value. Next, the processor 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, halts, and does not verify the unlock transaction. If there are any other optional constraints to be checked, they can be checked at this time. If all constraints are met, the script passes.

[0319] Worker spawning smart contract In the previous section, the ability to fork and clone smart contracts was described. In this section, the functionality of forcing a new smart contract to exist within an unlock transaction is detailed. The unlock transaction can be a smart contract that is not a completely different state machine or a completely different type of smart contract but is not a state machine.

[0320] An example of a constraint to enforce 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 places a constraint on the output of the unlock transaction such that the unlock transaction output lock script must be equal to the desired new smart contract script, or the hash of the output lock script must be equal to the hash of the desired new smart contract script. The new smart contract script or hash is hardcoded in the lock script of the output of the previous transaction or is securely provided as a parameter via the unlock script of the input of the unlock transaction. Multiple new smart contracts in the unlock transaction output can be enforced by having corresponding constraints within the lock script for each new smart contract as described above.

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

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

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

[0324] From a state machine perspective, the state machine can instantiate a new and different state machine to execute in parallel with the calling state machine. To apply this approach to a state machine, the lock script for this operation may be similar to that of a fork / clone operation, but instead of checking each new state machine instance for equivalence in that lock script, the existence of a new smart contract may be checked. The equivalence check can be performed over a variety of different value ranges, including the set of serialized transaction fields for the transaction, the lock script bytecode, or hashes of these.

[0325] Figure 30 shows the creation of a new smart contract. As shown here, the state machine 3010 is implemented using the previous transaction 3020 and the 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 the subsequent unlock transaction have the output in a specified state (and be a separate transaction). Specifically, as shown, the input Vin[0] of the unlock transaction 3030 unlocks Vout[0] of the previous transaction 3020, and the unlock transaction 3030 can be constrained such that Vout[x] has a transition matrix and is in state S4, while Vout[y] can be constrained to have a new smart contract.

[0326] In this approach, a 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 described above, the new smart contract does not necessarily have to be a state machine itself, in which case the resulting smart contract may not have a field for state values.

[0327] As indicated by the dashed arrow in Figure 30, the input Vin[0] of the unlock transaction 3030 refers to the previous transaction 3020 and its output Vout[0]. This can be in the form of the TxID of the previous transaction 3020 and an integer value set to "0" to refer to the output Vout[0]. The lock script of Vout[0] includes the current state ("S3") and the transition matrix of the state machine, and constrains the Vout[x] of the unlock transaction 3030 to be in the next state of the state machine ("S4"), and the Vout[y] of the unlock transaction 3030 to be a new smart contract ("NSC"), and possibly other constraints.

[0328] As an example, a pseudo-code of an example of an operator creation process and a process of forcibly making a new smart contract exist in an unlock transaction can be shown in FIG. 31.

[0329] Merging of smart contracts When it is necessary to merge two or more states into the same next state, state fusion or combination can be used. In some cases, if not required by the smart contract, state machines operating in parallel may be in the same state but may not be merged. For example, in the state diagram of FIG. 26, S4 and S7 can transition to S8 separately and remain as two separate transactions.

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

[0331] Each merging 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 merged or an entirely new smart contract. In either case, multiple checks may be performed. Each of the smart contracts can be checked as a valid input to the unlock transaction. This can be done by verification using the previous transaction.

[0332] As shown in FIG. 32, Vin[0] represents the previous transaction 3220 and its output Vout[0], while Vin[1] represents the previous transaction 3222 and its output Vout[0]. The lock scripts of both Vout[0]s constrain the Vout[x] of the unlock transaction 3230 to have the next state S8 and the state transition matrix. These constraints can be enforced by the lock script of the previous transaction 3222 that checks that the new smart contract is the output of the unlock transaction.

[0333] To achieve this with a parallel state machine, a transaction can use multiple inputs with inputs for each state machine to be combined. In the state machine transition matrix, constraints can be added to check the states of all the combined independent state machines. If one of the combined state machines is not in a converging state, the transaction may be rejected. To ensure the combining operation, constraints can be added to the state machine to confirm that there are two unlock scripts based on the state of the unlock transaction. For each script, a check can be performed to confirm that each script is in the correct state required for the transition. As described elsewhere in this specification, mutually dependent lock constraints can also be used.

[0334] FIG. 33 shows a pseudo-code sequence as an example of a process for fusing smart contracts in an unlock transaction with weak dependencies. In the fusion, a transition occurs from a series of current states (not necessarily unique states) to a shared next state. For an unlock transaction, the set of its inputs can unlock a set of lock scripts that share the constraint that the same output replicates the transition matrix and embeds 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 FIGS. 32 and 33 can occur with weak dependencies. The lock script can include other constraints such as interdependencies, branching, and the creation of new smart contracts. As an example of a weak dependency, if the fusion occurs accidentally, lock script 1 may be a branching from state A to states X and Y, and lock script 2 may be a normal transition from state B to state X. These two lock scripts happen to constrain the output of the unlock transaction to include state X.

[0336] In the pseudocode sequence of FIG. 33, a processor that processes the script according to the pseudocode sequence may inject the previous transaction, the unlock transaction, and optionally some input data, and check the termination condition before proceeding. Next, the processor extracts the previous transaction lock script and the unlock transaction lock script. Next, the processor checks 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, may abort. From there, the processor extracts the current state value of the previous transaction, and then determines the next state from that and the transaction matrix and the input (if used), 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] Figure 34 shows a pseudo-code sequence as an example of a process for fusing smart contracts in an unlock transaction having explicit dependencies. In explicit dependencies, there may be multiple state machines, and it is not sufficient for them to have the same next state for the same output. Additionally, they may be distinct and separate state machines. The fusion according to FIGS. 32 and 34 can occur due to explicit dependencies. In the case of strong constraints, the unlock transaction may be required to refer to two or more distinct fused state machines.

[0338] In the pseudo-code sequence of FIG. 34, a processor that processes the script according to the pseudo-code sequence can inject the previous transaction, the unlock transaction, and optionally some input data, and check the termination condition before proceeding with the processing. Next, the processor extracts the unlock transaction lock script. Next, the processor loops through a series of input indices to extract the corresponding previous transaction lock script, checks whether 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 the 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 whether the next state matches the next state in the unlock transaction lock script. Optionally, other constraints can be checked here.

[0339] Parallel Smart Contract / Barrier As described above, two or more smart contracts can be fused into one smart contract with weak or strong constraints. It is also useful to have two or more smart contracts that can be executed in parallel. This can be more than parallel processing in that there is a constraint that two parallel paths must pass through one unlock transaction. This can also be used for a "barrier" within a parallel state machine, where certain transitions are not allowed to occur until another transition occurs elsewhere within the state machine.

[0340] Figure 35 shows a parallel processing operation. In this case, the 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 each of the separate smart contracts. The unlock transaction 3530 includes an unlock script that includes each of the previous transactions of the smart contract. Additionally, a lock script for each smart contract may be required to continue its execution. When using parallel smart contracts, each contract cannot transition independently, but instead all contracts (defined within the lock script) need to be done in parallel.

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

[0342] To facilitate this function, an unlock transaction can be created that includes multiple inputs and outputs. Each of the state machines (transitioning or related to constraints) required for the barrier may be included in its own unlock script. A lock script may be used for each state machine that executes a transition. In the example shown in FIG. 26, the transition from state S9 to S10 is allowed, but is only allowed 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. Next, the unlock transaction has two lock scripts. One is for the state machine that remains in S7, and the other is for the state machine that is currently in S10.

[0343] FIG. 36 is a pseudo-code sequence as an example for using a barrier in a parallel state machine that requires parallel transaction inputs / outputs. In this example, the script according to the pseudo-code sequence checks that each of the previous transactions has the same lock script as the lock script within the unlock transaction. In this example, one lock script is set to match the first previous transaction, etc. Next, the script according to the pseudo-code sequence extracts the current state from both of the previous transactions, reads the inputs of both state machines, and checks the barriers set for both state transitions.

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

[0345] The lock script of Vout[0] of the previous transaction 3520 imposes Dependency #5 which requires that Vout[x] has state = S8 and has the transition matrix of state machine 1, and imposes Dependency #6 which requires that Vout[y] has state = S8 and has the 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, other forms of constraints of smart contracts may be used. The outputs of two (or more) previous transactions can provide parallel smart contracts as they constrain two (or more) unlock transaction outputs.

[0346] A barrier may be different from a fusion. A barrier is the case where the transitions from a series of current states (not necessarily a unique state) are restricted to occur in parallel. For an unlock transaction, the set of its inputs may be to unlock a set of mutually dependent lock scripts, and all of them may apply their respective constraints to the set of outputs. The mutually dependent lock scripts may be a set of requirements and shared next states, but may not be required if possible. The mutually dependent lock scripts can be embedded in the transition matrix such that a particular transition requires this mutual dependency.

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

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

[0349] (2) Worker spawning. This can be used when a particular type of dance requires more lessons or when a different evaluation is provided compared to other dance types.

[0350] (3) Merge. This process can be used at points S3 and S6 when a student reaches a new grade. In the new grade, it is necessary to evaluate each student in the final state S4 of the embedded dance state machine.

[0351] (4) Parallel Transaction / Barrier. It can be used to restrict state transitions within one state machine by another state machine. In the case of this usage example, it can be assumed that the transitions between S2 and S4 need to occur in parallel. This is because it is not possible to execute one dance type in one lesson.

[0352] Therefore, the present specification and drawings should be considered in an illustrative rather than a restrictive sense. However, it will be apparent that various modifications and changes can be made to it without departing from the scope of the invention as set forth in the claims. Similarly, other variations are within the scope of the present disclosure. Accordingly, the disclosed technology readily accepts various modifications and alternative configurations, some of which are illustrated in the drawings and described in detail above. However, there is no intention to limit the invention to the specific forms disclosed, and on the contrary, it is intended to cover all changes, alternative configurations, and equivalents within the scope of the invention as defined in the appended claims.

[0353] The use of the terms “a” and “an” and “the” and similar reference terms in the context of describing the disclosed embodiments (in particular, in the context of the following claims) is to be construed to include both the singular and the plural forms, unless otherwise indicated or clearly contradicted. The terms “comprising,” “having,” “including,” and “include” are to be construed as open-ended terms (i.e., meaning “including, but not limited to”) unless otherwise indicated. The term “connected” is to be construed to mean either physically connected without modification or, where there is some intervening element, partially or wholly contained within, attached to, or coupled to, whether or not there is physical contact. The recitation of a range of values herein is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated, as if each separate value were individually recited. The term “set” (e.g., “a set of items”) or “subset” is to be construed as a non-empty set consisting of one or more components, unless otherwise noted or clearly contradicted by the context, and further, the term “subset” of a corresponding set is not necessarily to denote a proper subset of the corresponding set, but the subset and the corresponding set may be equal, unless otherwise noted or clearly contradicted by the context.

[0354] Conjunctive words such as phrases in the form of "at least one of A, B, and C" or "at least one of A, B, or C" are understood in the context generally used, unless otherwise specified or clearly inconsistent with the context, and indicate that an item, term, etc. can be any non-empty subset of A, B, or C, or a set of A, B, and C. For example, in an example for the description of a set having three components, "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 conjunctive words are generally not intended to mean that a particular embodiment requires at least one of A, at least one of B, and at least one of C for each to exist.

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

[0356] The use of any examples provided, or of illustrative language (e.g., "such as") is intended only to better clarify embodiments of the present invention and does not limit the scope of the present invention unless otherwise claimed. No usage of words in this specification should be construed as indicating that any element not claimed is essential for the practice of the present invention.

[0357] Embodiments of the 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 those skilled in the art to use such variations as appropriate, and the inventors intend for the embodiments of the disclosure to be practiced in ways other than those specifically described. Accordingly, the scope of the disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Further, any combination of any of the above-described elements in all possible variations thereof is included in the scope of the disclosure unless otherwise indicated or clearly contradicted by context.

[0358] All references, including the publications, patent applications, and patents cited, are incorporated herein by reference in their entirety to the same extent as if each reference were individually and specifically incorporated by reference as a reference.

[0359] The above embodiments do not limit the present invention but illustrate it. It should be noted 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 enclosed in parentheses shall not be construed as limiting the claims. The terms "comprising", "comprises", etc. do not exclude the presence of elements or steps other than those listed in any of the claims or the entire specification. In this specification, "having", "comprising" (comprising, comprises) means "having", "comprising", "consisting of" (including, includes, consisting of). The singular form of an element does not exclude the plural form of such an element, and vice versa. The present invention can be implemented by means of several distinct elements of hardware and by a computer appropriately programmed. In apparatus claims listing several means, some of these means can 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 advantageously.

Explanation of Signs

[0360] 100 Blockchain network 102 Node 106 Path< / transitionmatrix> < / nextstate> < / y> < / x> < / y> < / x> < / y> < / x> < / y> < / x> < / k> < / k> < / k> < / m> < / m>

Claims

1. 1. A computer-implemented method comprising: determining a use transaction constraint, the use transaction constraint being such that an unlock script of a use transaction is: a serialized version of the use transaction, including a set of unlock transaction fields for the use transaction; and A serialized version of the previous blockchain transaction, and generating an available transaction, the available transaction comprising: Spendable transaction outputs, including the spendable amount; and an enable transaction lock script including said enable transaction constraint; and using the available amount is conditioned on at a validating node that at least one unlock script of the usage transaction is executed and the available transaction lock script satisfies the usage transaction constraint; having the enabled transaction validated at a node of a blockchain network; 23. A computer-implemented method comprising:

2. The usage transaction constraint instructs the validator node to: generating a signature based on a hash of the serialized set of unlock transaction fields, a private key included in the locking script of the output of the previous blockchain transaction, a random or pseudo-random number included in the locking script of the output of the previous blockchain transaction, and a SIGHASH Type byte included in the unlocking script, the SIGHASH Type byte indicating which fields of the spend transaction are included in the serialized set of spend transaction fields; appending said SIGHASH Type to said generated signature; Verifying that the signature is valid using a public key included in a lock script of the output of the previous blockchain transaction and corresponding to the private key; verifying that the signature hash of a field of an actual usage transaction is indicated by the SIGHASH Type appended to the generated signature; verifying that the transaction identifier of the previous blockchain transaction extracted from the serialized set of the unlock transaction field and a hash of a serialized version of the previous blockchain transaction match; 2. The computer-implemented method of claim 1, wherein the unlock script for the use transaction is constrained to include a serialized version of the use transaction that includes the set of unlock transaction fields of the use transaction and a serialized version of the previous blockchain transaction.

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

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

5. The computer-implemented method of claim 1 , wherein the use transaction constraint further constrains the use transaction's locking script to include a set of script elements replicated from the available transaction locking script.

6. The computer-implemented method of claim 1 , wherein the enabling transaction encodes a contract having multiple states.

7. 7. The computer-implemented method of claim 6, wherein the use transaction constraint encodes another contract different from the contract, and usage of the available amount is conditional on the other contract being incorporated into an output of the use transaction.

8. The computer-implemented method of any one of claims 1 to 7, further comprising determining a usable value of an output of the usage transaction.

9. the use transaction constraint is a first use transaction constraint, the method comprising: determining a second usage transaction constraint that further constrains the usage transaction; generating a second available transaction, the second available transaction comprising: A second usable amount, and a second enabled transaction lock script including the second enabled transaction constraint; and Further comprising:

9. The computer-implemented method of claim 1, wherein using the second available amount is further conditioned on the at least one unlock script being executed and satisfying the second usage transaction constraint.

10. The available transaction lock script is a first available transaction lock script, and the at least one unlock script of the use transaction includes a first unlock script and a second unlock script, and has the following features: the first usage transaction constraint constrains the first unlock script to include at least a portion of the first available transaction lock script; and the second usage transaction constraint constrains the second unlock script to include at least a portion of the second available transaction lock script; 10. The computer-implemented method of claim 9, further comprising one or both of:

11. 11. The computer-implemented method of claim 10, wherein at least a portion of the first available transaction lock script includes an encryption key associated with a first entity, and / or at least a portion of the second available transaction lock script includes an encryption key associated with a second entity different from the first entity.

12. The computer-implemented method of any one of claims 1 to 11, wherein the use transaction constraint further constrains the use transaction to constrain outputs of the use transaction.

13. 1. A system comprising: A processor; a memory containing executable instructions that, upon execution by the processor, cause the system to perform a computer-implemented method according to any one of claims 1 to 12; A system including:

14. 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 at least perform a computer-implemented method according to any one of claims 1 to 12.

Images