Input constraints for unlocking transactions in blockchain

Abstract

An untrusted deterministic state machine may be implemented using a blockchain infrastructure, and the state machine may run concurrently over multiple blockchain transactions. An unlock transaction constraint is determined, the unlock transaction constraint constraining the unlock transaction to include transaction input, the transaction input referencing an output of a previous transaction. A redeemable transaction is created to include a transaction output and a transaction locking script, the transaction output including an amount, the transaction locking script including the unlock transaction constraint, where unlocking the amount depends on execution of at least one unlock script of the unlock transaction that satisfies the unlock transaction constraint. The redeemable transaction may be verified at a node of the blockchain network.

Description

[0001] This application is a divisional application of a patent application with Chinese Application No. 201880056017.5 (PCT International Application No. PCT / IB2018 / 056431), filing date of August 24, 2018, and title of "Input Constraints for Unlocking Transactions in Blockchain". Technical Field

[0002] The present invention mainly relates to a computer-implemented method for processing blockchain transactions, specifically to implementing state machines within the structure of blockchain transaction processing, including trustless, deterministic, and concurrent state machines. The present invention also utilizes cryptographic and mathematical techniques to enhance the security associated with electronic transfers via a blockchain network. The present invention is particularly applicable to, but not limited to, use in methods and apparatuses for processing and trading in smart contract transactions and implementing state machines using such smart contract transactions. Background Art

[0003] As used herein, the term "Blockchain" may refer to any one of several types of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and their variants. It should be noted that the present invention is not limited to use with a specific blockchain; alternative blockchain implementations and protocols (including non-commercial applications) also fall within the scope of the present invention.

[0004] A blockchain is a peer-to-peer electronic ledger that is implemented as a computer-based, decentralized distributed system consisting of blocks, which in turn can consist of transactions and other information. In some examples, a "blockchain transaction" refers to an input message encoding a structured collection of field values including a set of data and conditions, where satisfying the set of conditions is a prerequisite for writing the field set to the blockchain data structure. A blockchain system or blockchain network can include multiple blockchain nodes and a set of operations. Blockchain nodes can be used to perform some or all of the operations in the set of operations. Various blockchain nodes can be implemented as computer hardware, computer software, or a combination of both operated by node operators, where the node operators can be independent and unrelated to other node operators. Each blockchain node may maintain a copy of the blockchain ledger or a portion thereof. The set of operations may include creating transactions, propagating transactions, reading the blockchain ledger, evaluating the blockchain ledger, generating (mining) new blocks for proposals to the blockchain ledger, communicating with other blockchain nodes, and providing wallet functionality to users to manage blockchain assets.

[0005] A blockchain ledger can be decentralized as there is no single blockchain node or entity that decides when to modify the ledger. Instead, each blockchain node can be programmed with knowledge of the blockchain protocol rules and can verify that the blockchain ledger and the actions of other blockchain nodes are consistent with those rules. The term "Blockchain" can refer to the fact that a blockchain ledger consists of a series of chained blocks, each represented as a data structure in computer memory, readable by computer processes and transmissible as data transfers. A block can include one or more transactions, also represented as a data structure in computer memory, readable by computer processes and transmissible as data transfers. These blocks can be chained because each new block formally added to the blockchain contains an immutable reference to the immediately preceding block, which can contain an immutable reference to its immediately preceding block, and so on.

[0006] One of the rules of the blockchain protocol can be that once a block is added to the blockchain, it cannot be changed; that is, it is immutable, and the only possible modification to the blockchain ledger can be the addition of new blocks. Since blockchain nodes can generally be programmed with it, they do not modify the blocks in their copies of the blockchain ledger but only add blocks, and even then, only after running a verification process on the proposed block to ensure it complies with the blockchain protocol. Since these blocks are immutable once added to the ledger, the transactions within the blocks can also be immutable.

[0007] When a blockchain node creates a transaction, it can create a data object containing the details of the transaction and can propagate that data object in a peer-to-peer manner to other blockchain nodes it can connect to. Some blockchain nodes collect one or more transactions, form a data structure corresponding to a block, perform some calculations to verify the transactions placed in the block, solve a puzzle, place the solution to the puzzle in the data structure, and attempt to propagate the block to other blockchain nodes. The puzzle can be in the form of a nontrivial computation specific to the data of the transaction and the current state of the blockchain ledger, such as the number of blocks in the ledger and the number of the last added block.

[0008] By making the puzzle depend on transactions, a Rogue Blockchain Node may not be able to propagate pre-formed blocks. By solving a non-trivial puzzle, a Rogue Blockchain Node may not be able to simply inject a block into the blockchain network, but may require the blockchain node to perform some important computational tasks to prove that it has made an effort (in fact, showing that the solution to the puzzle is "proof of work"). Preferably, in the blockchain protocol, the proof of work is non-trivial, but it is easy to verify that the puzzle has been solved and the work has been done. This means that other blockchain nodes do not necessarily have to trust the blockchain node that proposes to add a new data block to the ledger. If verified by another blockchain node, 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. When other blockchain nodes perform the same verification, they can also conclude that the block is valid and should be added to the blockchain ledger, so they can add the block to their copy of the blockchain ledger. If a blockchain node determines that the proposed new block is invalid, it can choose not to add it to its copy of the blockchain ledger and not propagate it. Since the validity of the blockchain is based on consensus, if most nodes agree that a transaction is valid, then the transaction can be considered valid.

[0009] The blockchain system can operate in such a way that node owners and operators do not have to trust other node owners and operators. Instead, the protocol can make it computationally infeasible to perform certain operations not allowed by the protocol, such as modifying earlier blocks, proposing new blocks without the corresponding proof of work, or including invalid transactions. When it is computationally infeasible to perform operations not allowed by the blockchain protocol in a way that other nodes do not notice, specific trust may not be required.

[0010] To include a transaction in a block written to the blockchain, (1) the mining blockchain node will verify the transaction, (2) the mining blockchain node will attempt to propagate the block containing the transaction, and (3) other nodes will verify the validity of the block and the validity of the transactions in the block. Since the mining blockchain node will be programmed or configured with these rules in mind, it is unlikely that the mining blockchain node will include unverifiable transactions in a block, because such a block will not be accepted by other nodes and the mining node will not gain any benefits. For some blockchain systems, one of the benefits of such mining is that if the block is accepted, the block is allowed to include "reward" transactions, where a specified amount of value is assigned to the operator of the node without a corresponding reduction in value from other entities.

[0011] Transactions in a blockchain network contain various data elements, such as transaction values, transaction times, and / or other data elements. In a decentralized distributed ledger system, the ledger is public, so anyone can view the ledger and transactions. In a blockchain ledger, there may be a genesis transaction that initiates the blockchain and attributes certain value units to that genesis transaction. In the examples in this article, the value unit is a specific type of value unit, but other variations are possible.

[0012] Transactions other than the genesis transaction and distribution transactions involve "unlocking" the value of one or more existing transactions in the blockchain ledger, and when such a transaction is added to the blockchain ledger, it can in turn be transferred. Each untransferred transaction publicly specifies the requirements for unlocking the value of that transaction. A simple requirement might be "you must first prove you are Alice, and then you can unlock this". Alice might then create a new transaction to "unlock" the value of that transaction, where Alice's new transaction proves it is from Alice and has a pointer to the previous transaction. Distribution transactions have a transaction value, but distribution transactions do not "unlock" the previous transaction. Of course, for Alice's transaction to be accepted by the blockchain network, it cannot point to a transaction that has already been transferred, but must actually prove that Alice created the transaction.

[0013] According to the blockchain protocol, and thus according to the protocol of blockchain nodes, if a transaction points to the output of a previous transaction that has already been transferred, that transaction is invalid; i.e., the ledger contains a valid existing transaction input that points to the output of the previous transaction. To prevent any interloper from creating a new transaction input to "unlock" the value represented by the unspent transaction output (UTXO) of the previous transaction, each transaction output includes data representing the requirements for any claimant presenting such a transaction, and since the UTXO can be immutable, this data cannot be changed. Of course, transferred transactions can also be immutable.

[0014] In the example above, Alice may have created an unlocking transaction such that the value in the previous transaction that only she can unlock can be transferred to Bob. That is, there will now be a new untransferred transaction that only Bob can unlock and thus unlock. The unlocking transaction created by Alice may include data corresponding to the requirement: "Anyone can freely point to this transaction and thus unlock all its values if they can provide enough information to prove that they know Bob's private key." Assuming Bob is careful, Bob will be the only person who can create a valid transaction that can unlock this transaction. In fact, Bob owns the value and is the only person who can unlock it. Note that this does not require Bob to trust any operator of the blockchain node, nor does it require him to trust any other party capable of creating transactions. What Bob needs to trust is that rogue parties cannot take over most of the blockchain node completely.

[0015] In a particular case, one transaction completely unlocks a previous untransferred transaction, and this one transaction can be completely transferred by a later transaction, or not transferred at all. In general, a transaction has one or more inputs and one or more outputs, where each input references the output of a previous transaction (and this output has a redeemable value), and each output has a redeemable value (which remains untransferred until it is transferred / referenced by the input of a future transaction). The output of a transaction is the redeemable unit of the transaction because it is either completely transferred or not transferred at all. In some examples described herein, a transaction is said to be "transferred", and it should be understood that in the case where a transaction has multiple transaction outputs, this description can cover the case where less than all transaction outputs can be transferred. With respect to unlocking a transaction output, the description of "unlocking a transaction" can cover the case where the output of a transaction having only one output is transferred.

[0016] When a transaction can have multiple outputs, different transaction outputs of this transaction can be transferred at different times. When a transaction is created, its outputs can be considered untransferred. Each output is transferred by the input of a subsequent transaction, or remains untransferred. If the input of a transaction attempts to unlock the output of a previous transaction after the output of the previous transaction has been transferred, the blockchain node will reject it as an invalid transaction.

[0017] In the case where a party Alice controls a UTXO with a value of X and only wants to unlock a part (Y) of this transaction output, Alice can specify a new transaction with multiple outputs, one with a transaction output having a value of Y (which can only be transferred by Bob), and the other with a transaction output having a value of X - Y (which can only be transferred by Alice). In fact, the original transaction output is completely transferred, but there are new transaction outputs that "make a change" for Alice's transaction.

[0018] The input quantity of a transaction and the output quantity 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 should not exceed the sum of the values of the outputs of the previous transaction that the current transaction's inputs can transfer, and in some cases (except for some exceptions) will be smaller. For genesis transactions and distribution transactions, the sum of the output values can be greater than the sum of the input values, or no inputs may be required at all, but for regular transactions, if the sum of their output values exceeds the sum of the input values, the transaction will be invalid. For some transactions, the sum of their output values may be less than the sum of their input values. This can be a Coinbase Transaction that is added to a block and has a redeemable output equal to the sum of the transaction fees of all the other transactions included in the block (i.e., the sum of the differences between all the inputs and outputs of all the included transactions), as well as a distribution for creating a new block.

[0019] Each output of a transaction includes constraints that must be satisfied in order to unlock the value of that output. In some blockchain protocols, the constraints are embedded in a "locking script" that specifies the data and script commands that define those constraints. The locking script acts as an encumbrance on the value represented in the transaction output because another participant cannot "unlock" the value represented in the transaction output unless they can "unlock" the locking script of that transaction output.

[0020] Each input of an unlocking transaction unlocks the output of a previous transaction. The "unlocking script" of an unlocking transaction input determines whether that unlocking transaction unlocks the output of the previous transaction. Thus, a valid transaction specifies at least one input, and each input of a valid unlocking transaction includes a pointer to the output of the previous transaction (the transaction being transferred) and an unlocking script that "unlocks" the locking script. Blockchain nodes operating according to the corresponding blockchain protocol can execute the locking script and the unlocking script together to verify the transaction input. In a particular system, the script is stack-based, and the verifying blockchain node can start with an empty stack, execute the unlocking script, which can leave data objects on the stack, and then execute the locking script, which can use the data objects on the stack.

[0021] When the verifying blockchain node combines the locking script and the unlocking script and executes the combination, the result after execution can be "TRUE" or "FALSE". In some cases, the execution of the script ends with a false result before the script is fully executed. For example, assume that for a given script execution, there are two values that are always equal in a valid script execution, regardless of what else happens in the script. If, midway through the execution of the script, a comparison is made between these two values and they are not equal, the execution of the script stops immediately after that comparison and returns a false result. The rest of the script does not need to be executed.

[0022] If a blockchain node validates a combination of a locking script and an unlocking script, executes the combination, and the result is true (i.e., the unlocking script contains everything required to unlock the transaction output), then the validating blockchain node will validate the transaction as valid (assuming other requirements are met, such as correct timestamp, correct format, not pointing to a previously spent transaction output, etc.). If the validating blockchain node validates the transaction as valid, the transaction can be propagated. Other blockchain nodes can perform the same calculations to conclude that the transaction is valid. In this way, a valid transaction with inputs that only point to UTXOs and an unlocking script that unlocks the UTXOs can be propagated and eventually become part of a block that ultimately becomes part of the ledger.

[0023] On the other hand, if a rogue node attempts to propagate an invalid transaction, other nodes may find the transaction invalid and not propagate it.

[0024] Once a transaction is valid and accepted by the blockchain, its content cannot be changed. This means that the locking script is fixed when the transaction is created. However, the unlocking script does not have to be fixed at that time because the unlocking script is included in a later unlocking transaction and does not need to be created until the later unlocking transaction is created.

[0025] In a typical case, a validating unlocking script cannot be created by just anyone, but only by the party authorized to unlock the previous transaction output. As shown in the above example, the locking script might be "If anyone can provide enough information to prove they know Bob's private key, then anyone can freely point to the transaction output and thus unlock all of its stated values", and the form of the unlocking script might be "Bob has signed the transaction with his private key, resulting in: ABCCC". Then the validating blockchain node can process these two statements and come to a true or false conclusion. This process works well when it is easy to verify that ABCCC is a valid signature, Bob (or someone else who knows Bob's private key) can easily generate such a signature, and it is difficult for others to generate a valid signature without knowing Bob's private key. Thus, value can be transferred in a trustless system. The initiator of the transaction that Bob will unlock does not need to trust the system or trust Bob because it is computationally difficult to form a valid and verifiable result that is consistently accepted by blockchain nodes without first knowing Bob's private key.

[0026] Blockchain nodes can easily verify that Bob signed the transaction and that the signature is the only requirement of the locking script. Of course, there may be rogue nodes that do not verify where other nodes verify and may verify where other nodes do not verify, but as long as the rogue nodes cannot overwhelm the well-behaved nodes on the blockchain network, the rogue nodes cannot push invalid transactions or prevent the propagation or mining of valid transactions.

[0027] If a node is executing the unlocking script of a transaction input and the corresponding locking script of the previous transaction input, and evaluates each script to true, and meets other verification conditions (if applicable), then the transaction is valid with respect to that node. The node then propagates the verified transaction to other network nodes, which can then choose to include the transaction in a block. Thus, in order for a transaction to be written to the blockchain, the transaction must (1) be verified by the nodes receiving the transaction, (2) be relayed (but only if the transaction is verified) to other nodes in the network, (3) be added to a newly constructed block, (4) be propagated as part of the proposed block, and (5) be accepted by the nodes' consensus as an addition to the public ledger of past transactions.

[0028] A transaction can be considered confirmed when a sufficient number of blocks have been added to the blockchain such that the transaction is effectively irreversible. Since transactions are immutable, the blockchain protocol can prevent unilateral reversal of a transaction. Of course, if Alice transfers the value X to Bob and Alice wants the value X back, if Bob agrees, she can have it. In this case, the Alice-to-Bob-for-X transaction is not reversed or cancelled, but rather Bob initiates a new transaction, the Bob-to-Alice-for-X transaction.

[0029] Once a transaction is included in a block, the transaction is considered immutable, and once a block is committed to the blockchain, the block is considered immutable. Forks in the blockchain can occur for a short time and there is some ability to roll back the blockchain, but generally, the longer the time that has passed, the less likely any rollback becomes. In this article, unless otherwise stated, it is assumed that transactions and blocks are immutable after being fully committed to the blockchain.

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

[0031] In a blockchain network where not every node needs to trust each other, transactions can be verified, blocks can be verified, and unverifiable transactions and blocks can be ignored and not used. It can be considered that transactions and blocks are effectively immutable, which may be the result of the following assumption: if the hash or digital signature correctly corresponds to a transaction or block, then the transaction or block has not been modified from its original content.

[0032] Some blockchain nodes may store the entire ledger, while other nodes may only store unspent transaction outputs (UTXOs). A UTXO corresponds to a redeemable value, and preferably, each UTXO has a locking script for which it is difficult for anyone other than the "owner" of the value to generate a verifiable unlocking script. Of course, this is not a requirement, but it can be expected that any UTXO for which anyone can easily generate a verifiable unlocking script can be quickly transferred in a transaction that transfers its value to another UTXO that can only be redeemed by the first person to notice it. Thus, the blockchain can be used to transfer control of digital assets from one participant in the blockchain system to another participant, and the transaction record, including the transferred transaction output and UTXO, can be recorded in a public, immutable ledger, facilitating verification of the flow of digital assets and preventing double unlocking of these digital assets.

[0033] In an embodiment, a "digital asset" refers to binary data associated with a right of use. As used herein, a "digital asset" can refer to one or more digital assets. For example, a transaction may have multiple inputs, and each of these inputs can represent a different digital asset. In this example, the digital asset whose control is transferred can be a collection of multiple digital assets, and the collection itself is a digital asset. Similarly, a transaction can subdivide and / or combine multiple inputs to produce one or more outputs, such that, for example, the number of inputs and outputs can be different.

[0034] In an embodiment, a token represents a share of an asset (e.g., a share of a company), and a single transaction involves multiple types of tokens (e.g., shares of one or more different companies). In some embodiments, a digital asset is untokenized, such that, for example, there is no identifier of the digital asset on the blockchain, and control of the digital asset is demonstrated by the ability to generate a valid transaction recorded on the blockchain. However, it should be noted that some blockchain implementations may use tokenized digital assets, and thus, for example, information recorded on the blockchain can be used to unambiguously identify the digital asset. Although in some embodiments a digital asset can be used as a particular type of digital asset, it is contemplated that in embodiments the digital asset can additionally or alternatively be used in other contexts. Note that while the present invention is applicable to the control of digital assets, it is inherently technical and can be used in other contexts that utilize blockchain data structures and do not necessarily involve the transfer of digital assets.

[0035] A transaction contains a locking script and an unlocking script, which can form a computational object. Once submitted to the blockchain, a transaction may become immutable, and the uses of this property may extend beyond the immutable transfer of control of digital assets. In addition to transferring value, immutable transactions can be used to implement other operations, such as a notarized record of an event, the implementation of a smart contract (wherein the rights and obligations of the parties can be encoded in the transaction), and the transfer of value according to the terms of a smart contract, in accordance with the blockchain protocol.

[0036] The script is written using a stack - based scripting language, but other methods can also 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 (e.g., part of a blockchain node) stores data on a first - in, last - out (LIFO) 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. Various operations performed on the stack can cause one or more values to be pushed or popped from the top of the stack, operate on them, and change the order of elements on the stack (which can be equivalent to two pop operations and two push operations, with the first push being the first item popped). For example, the OP_EQUAL operation may pop the top two items from the stack, compare them, and push the result (e.g., 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 selecting an item from a location other than the top of the stack. In some scripting languages employed in some of these embodiments, there can be at least two stacks: a main stack and an alternate 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, executing the OP_TOALTSTACK operation causes the processor to move a value from the top of the main stack to the top of the alternate stack. It should be noted that in some cases, a stack - based scripting language may not be limited to strictly last - in - first - out (LIFO) - style operations. For example, a stack - based scripting language can support operations to copy or move the nth item in the stack to the top (e.g., OP_PICK and OP_ROLL, respectively). A script written using a stack - based scripting language can be pushed onto a logical stack, which can be implemented using any suitable data structure (such as a vector, list, or stack).

[0037] Using the script included in a transaction, a smart contract can be implemented, where the terms of the contract are encoded into the script. An example could be "If Bob has paid Carol X and Dave has granted permission for the transaction, then Alice will pay Bob half of X", and this can be encoded as part of a locking script that evaluates to true only when (among other conditions) there is a prior transaction where Bob paid Carol and a prior transaction where Dave encoded his permission. As used herein, a "prior transaction" can refer to any transaction that has been added to the blockchain, not necessarily the previous transaction with an output unlocked by an unlocking transaction. In fact, a smart contract can represent a machine - executable program that includes rules defining inputs to produce results, and then actions can be taken based on those results.

[0038] In addition to value transfers, a transaction may also transfer objects or ownership interests of other values. For example, a transaction may include data corresponding to the following assertion: "The person who can unlock this transaction is also the legal owner of the house and land at Marley Circle No. 123." The ownership interests may be obfuscated in public records with the same effect. For example, a transaction may include data corresponding to the following assertion: "The person who can unlock this transaction is also the legal owner of certain properties held under Trust No. 12345 at Central Trust Bank." In this document, this is referred to as a token, which represents and enables the transfer of real-world entities through the blockchain. Potentially sensitive or secret items can be represented by tokens with no discernible meaning or value. Thus, tokens can be used as identifiers that allow real-world items to be referenced from the blockchain.

[0039] In some embodiments, the interaction with a specific entity is encoded at a specific step in a smart contract, and the smart contract can additionally be self-executing and self-enforcing automatically. In some examples, self-executing refers to the activation of the smart contract, executing the smart contract to effect the transfer of UTXOs. Note that in such examples, "any entity" that can unlock a UTXO refers to an entity that can create an unlocking script without demonstrating knowledge of some secret. In other words, the unlocking transaction can be verified without verifying whether the data source has access to cryptographic secrets (e.g., private asymmetric keys, symmetric keys, etc.). Additionally, in such examples, self-enforcement occurs because the verification nodes of the blockchain network verify the unlocking transaction according to the constraints of the smart contract. In some examples, "unlocking" a UTXO refers to creating an unlocking transaction output that references the UTXO and serves as a valid execution. A side effect of unlocking such a transaction output is that the blockchain network can process the locking script and the unlocking script to verify the new transaction, i.e., the unlocking transaction. If valid, the previous transaction output is considered transferred. By including a certain value in the transaction output and making it such that anyone can unlock the output, parties have an incentive to create such unlocking transactions, and thus it is likely that the steps of the smart contract will be executed, if not by the participants in the smart contract, then by others operating the blockchain nodes.

[0040] The scripts that form the locking script and the unlocking script recorded as part of a transaction can be immutable, so the locking script generally cannot be modified or reference parts of future transactions, as these may be unknown when the transaction is fixed. The unlocking script of a transaction input can refer to the part of a previous transaction output pointed to by the transaction input of the blockchain or a previous transaction other than the previous one. This may limit how the transaction can be used.

[0041] It is desired to provide additional features, as well as improved methods and systems, for using blockchain technology in one or more of these aspects. Accordingly, the present invention provides a system and / or method as defined in the appended claims. Summary of the Invention

[0042] In various embodiments of a computer-implemented method, the method includes: determining a first set of constraints on a first spent transaction output; determining a second set of constraints on a second spent transaction output; creating an initial transaction to include: at least one initial locking script that includes the first set of constraints and the second set of constraints; and at least one spendable value, wherein spending at least one spendable value depends on: the first set of constraints being at least partially satisfied by verifying that the spending transaction includes the first spent transaction output; and the second set of constraints being at least partially satisfied by verifying that the spending transaction includes the second spent transaction output; and causing the initial transaction to be verified at a node of a blockchain network.

[0043] The locking script in the first spent transaction output can be a copy of the locking script in the second spent transaction output.

[0044] The locking script in the first spent transaction output can be different from the locking script in the second spent transaction output.

[0045] The locking script in the first spent transaction output can include at least a portion of at least one initial locking script.

[0046] Execution of at least one initial locking script can select at least a portion from multiple portions of at least one initial locking script.

[0047] Execution of the unlocking script of the spending transaction can cause at least one initial locking script to receive data corresponding to one of the first spent transaction output or the second spent transaction output.

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

[0049] The data can include a new locking script. As a result of receiving the data, the first spent transaction output can be constrained to include the new locking script.

[0050] At least one initial locking script can include a constraint on a data source.

[0051] The above method can further include determining the spendable value of the first spent transaction output.

[0052] The initial transaction can encode a contract having multiple states.

[0053] A spend transaction may include multiple input values corresponding to multiple states.

[0054] A first set of constraints may constrain a first spend transaction output to have a first state. A second set of constraints constrains a second spend transaction output to have a second state.

[0055] There is also a desire to provide a computer-implemented method that includes: determining spend transaction constraints for a constrained spend transaction to include spend transaction inputs that reference previous transaction outputs; creating a spendable transaction that includes: a spendable transaction output that includes a spendable amount; and a spendable transaction locking script that includes the spend transaction constraints, wherein spending the spendable amount depends on the execution of at least one unlocking script of a spend transaction that satisfies the spend transaction constraints; and causing the spendable transaction to be verified at a node of a blockchain network.

[0056] The spend transaction constraints may also constrain the spend transaction inputs to include a specific hash value.

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

[0058] The spend transaction constraints may also constrain the locking script of the spend transaction to include a set of script elements copied from the spendable transaction locking script.

[0059] The spendable transaction may encode a contract having multiple states.

[0060] The above method may also include determining a spendable value of an output of the spend transaction.

[0061] The spend transaction constraints may include specific locking script elements from a previous transaction output. As a result of the spend transaction inputs including the specific locking script elements, the execution of at least one unlocking script may satisfy the spend transaction constraints.

[0062] The specific locking script elements may encode an encryption key of a specific entity.

[0063] The spend transaction constraints may be a first spend transaction constraint; and the above method may also include: determining a second spend transaction constraint to further constrain the spend transaction; and creating a second spendable transaction that includes: a second spendable amount; and a second spendable transaction locking script that includes the second spend transaction constraints, wherein spending the second spendable amount may also depend on the execution of at least one unlocking script that satisfies the second spend transaction constraints.

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

[0065] At least a portion of the first spend transaction locking script can include an encryption key associated with a first entity. At least a portion of the second spend transaction locking script can include an encryption key associated with a second entity different from the first entity.

[0066] The spend transaction constraint can also constrain the spend transaction to constrain the output of the spend transaction.

[0067] The spend transaction constraint can encode another contract different from the above contract. The spendable amount may depend on another contract executed in the output of the spend transaction.

[0068] It is also desirable to provide a computer-implemented method that includes creating a blockchain transaction that encodes: a state machine in a first state and having a set of permitted state transitions; and a set of script elements to be executed to cause the spend transaction to: encode the state machine according to the set of permitted state transitions; and comply with a restriction on the input of the spend transaction or comply with a restriction on the output of the spend transaction; and cause the blockchain transaction to be verified by nodes in the blockchain network.

[0069] The set of permitted state transitions can include state transitions that can be independently and simultaneously implemented in different blockchain transactions.

[0070] The set of script elements can cause the spend transaction to comply with a restriction on the output of the spend transaction. The restriction on the output may require: a first output of the spend transaction to indicate a state corresponding to the first output that complies with the set of permitted state transitions; and a second output of the spend transaction to indicate a state corresponding to the second output that complies with the set of permitted state transitions.

[0071] The state corresponding to the first output and the state corresponding to the second output can be the same.

[0072] The state corresponding to the first output and the state corresponding to the second output can be different states.

[0073] The set of script elements can cause the spend transaction to comply with a restriction on the input of the spend transaction. The restriction on the input may require an input to the spend transaction to indicate another state machine encoded in another blockchain transaction.

[0074] The restrictions on the input may require the input to reference a state machine in a first state and another state machine in another state different from the first state.

[0075] A first transition from the first state to the second state may be within the set of allowed state transitions. A second transition from the other state to the second state may be within the set of allowed state transitions.

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

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

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

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

[0080] A set of script elements may cause a spending transaction to comply with the restrictions on the input of the spending transaction and the restrictions on the output of the spending transaction.

[0081] There is also a desire to provide a computer-implemented method that includes: creating, at a node in a blockchain network, a blockchain transaction having a transaction output that can be spent by a first spending transaction input of a first spending transaction; inserting a first set of script elements that constrain the first spending transaction into the blockchain transaction to include a first set of spending transaction script elements corresponding to operations of a state machine; and inserting a second set of script elements into the blockchain transaction, the second set of script elements constraining a second set of spending transaction script elements corresponding to a permitted state machine state transition, the state machine state transition including states that can be implemented using different blockchain transactions that can be processed simultaneously and independently by the blockchain network. The blockchain transaction may include a first output having a first locking script, and the first transaction output value may include a second output having a second locking script and a second transaction output value, where the first set of script elements is part of the first locking script.

[0082] A spend transaction may include an unlocking script that, when executed by a transaction verifier using a previous transaction output locking script, will satisfy a predetermined verification test and will cause the node, when executing the previous transaction output locking script, to store at least the values of the fields representing the spend transaction in a memory accessible to the transaction verifier, insert a first set of script elements into the spend transaction, where the first set of script elements forms part of the spend transaction locking script of the first output of the spend transaction and is consistent with the requirements specified by the previous transaction locking script, and where the first set of script elements corresponds to an operation of a state machine, and insert a second set of script elements into the spend transaction, where the second set of script elements forms part of the spend transaction locking script, is consistent with the requirements specified by the previous transaction locking script, and corresponds to a permitted state machine state transition that includes states that may be implemented using different blockchain transactions that may be processed simultaneously but independently by the blockchain network.

[0083] A spend transaction may include inputs and outputs, where the inputs reference previous transaction outputs, and where the spend transaction includes an unlocking script that, when executed by a transaction verifier using the previous transaction locking script of a previous transaction output, will satisfy a predetermined verification test, where the unlocking script causes the node, when executing the locking script, to store at least the values of the fields representing the spend transaction in a memory accessible to the transaction verifier, and insert data corresponding to additional state machines into the spend transaction, as spend transaction inputs and / or spend transaction outputs, based on permitted state machine state transitions, such that the number of spend transaction inputs and / or spend transaction outputs used in the spend transaction is sufficient for multiple state machine transitions.

[0084] Permitted state machine state transitions can include a forking transition from an initial state to two subsequent states by creating a first transaction output corresponding to the first subsequent state for a spending transaction, inserting a first transaction output value of the first transaction output in the spending transaction, sufficient to make the first transaction output an input to a first subsequent transaction that references the first transaction output, inserting a third set of script elements in the first transaction output of the spending transaction, wherein the third set of script elements is part of a first locking script that constrains the first subsequent transaction to assume the first subsequent state, creating a second transaction output corresponding to the second subsequent state for the spending transaction, inserting a second transaction output value of the second transaction output in the spending transaction, sufficient to make the second transaction output an input to a second subsequent transaction that references the second transaction output, inserting a fourth set of script elements in the second transaction output, wherein the fourth set of script elements is part of a second locking script that constrains the second subsequent transaction to assume the second subsequent state, and inserting a fifth set of script elements in the first transaction output or the second transaction output, wherein the fifth set of script elements is part of the first locking script or the second locking script, imposing different constraints on the first subsequent transaction and the second subsequent transaction.

[0085] The first locking script can constrain the first subsequent transaction to have a first state, and the second locking script can constrain the second subsequent transaction to have a second state. The spending transaction can include three or more transaction output values corresponding to a fork of three or more states. The spending transaction can include three or more transaction input values corresponding to a merge of three or more states. The first locking script and the second locking script can constrain the first subsequent transaction and the second subsequent transaction to have the same state.

[0086] Typically, a spending transaction can include N transaction input values and N transaction output values, where N is 1, 2, 3 or more.

[0087] Permitted state machine state transitions can include a merging transition from two initial states to a subsequent state by inserting a first transaction input for a first previous state in the spending transaction, inserting a second transaction input for a second previous state in the spending transaction, and inserting a merged state in the spending transaction, which is a permitted transition from the first previous state and the second previous state according to a state transition matrix.

[0088] Permitted state machine state transitions can be hard-coded into the first transaction input and / or the second transaction input by inserting a first reference to a first previous transaction having the first previous state in the first transaction input, inserting a second reference to a second previous transaction having the second previous state in the second transaction input, and inserting a first transaction output for the merged state in the spending transaction, wherein the state transition matrix is available for the first previous transaction and the second previous transaction.

[0089] Permitted state machine state transitions can include parallel operations from N (where N is two or more) initial states to N subsequent states by inserting a first transaction input for a first previous state in a spend transaction, inserting a second transaction input for a second previous state in the spend transaction, inserting a first reference to a first previous transaction having the first previous state in the first transaction input, inserting a second reference to a second previous transaction having the second previous state in the second transaction input, inserting a first transaction output for a first subsequent state in the spend transaction, inserting a third set of script elements in the first transaction output, where the third set of script elements is part of a first locking script that constrains a first subsequent transaction to present the first subsequent state, inserting a second transaction output for a second subsequent state in the spend transaction, and inserting a fourth set of script elements in the second transaction output, where the fourth set of script elements is part of a second locking script that constrains a second subsequent transaction to present the second subsequent state.

[0090] The operations of the state machine can be encoded as smart contracts implemented using a blockchain.

[0091] Transactions can be split using arbitrary constraints. The method can include creating a first transaction at a node in a blockchain network, where the first transaction includes a first output having a first spendable value and a first locking script, and the first transaction includes a second output having a second spendable value and a second locking script, where the first locking script includes a first set of constraints on a first selected transaction output, where if the first selected transaction output is valid for spending the first spendable value, a first unlocking script will satisfy the first set of constraints, and the second locking script includes a second set of constraints on a second selected transaction output, where if the second selected transaction output is valid for spending the second spendable value, a second unlocking script will satisfy the second set of constraints, and where the first set of constraints or the second set of constraints impose a constraint on the locking script of a spend transaction that has the first selected transaction output or the second selected transaction output as a spend transaction output.

[0092] The first selected transaction output can be an output of a first spending transaction, and the second selected transaction output can be an output of a second spending transaction different from the first spending transaction. The first set of constraints can be different from the second set of constraints and different from the constraints on the transaction inputs of the first transaction. The first set of constraints and the second set of constraints can each include a common set of constraints. The constraints on the locking script of the spending transaction can require that, for the spending transaction to be valid, the locking script of the spending transaction includes a reference to at least one field of the spending transaction. Another constraint requirement for the locking script is that, for the spending transaction to be valid, the locking script of the spending transaction includes a copy of a portion of the first locking script and / or a copy of a portion of the second locking script.

[0093] The first selected transaction output can be an output of a first spending transaction, the second selected transaction output can be an output of a second spending transaction, the first unlocking script can include fields of the first transaction, fields of the first selected transaction, and fields of the second spending transaction, and wherein the first locking 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 spending transaction.

[0094] The first set of constraints and the second set of constraints can each include a common set of constraints, whereby the two constrained spending transaction output locking 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 locking script and / or a hash of a portion of the second locking script, and / or a constraint on the size of a portion of the first locking script and / or the size of a portion of the second locking script.

[0095] The first set of constraints and / or the second set of constraints can include an optional reference to input data. Each of the multiple outputs of the first transaction can be constrained by different constraints imposed on the outputs of the multiple outputs.

[0096] A transaction can be merged with arbitrary constraints or have interdependencies, for example, using a computer-implemented method that includes creating, at a node in a blockchain network, a first spendable transaction, where the first spendable transaction includes a first spendable output having a first spendable value and a first locking script that includes a first set of constraints on the spending transaction, where, if the spending transaction is valid for spending the first spendable output, the first unlocking script of the spending transaction will satisfy the first set of constraints, and the first set of constraints includes a first spending transaction constraint that requires the first spending transaction output of the spending transaction to include a first spending transaction output locking script to contain a first set of smart contract script instructions, and the first set of constraints includes a second spending transaction constraint that requires the spending transaction to contain a second set of smart contract script instructions and requires the spending transaction to include a spending transaction input that references a second spendable transaction output.

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

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

[0099] The method described above may include providing, in the first set of constraints, a first parallel constraint that requires the spend transaction to include a first spend transaction input that references a first spendable transaction, a second parallel constraint that requires the spend transaction to include a second spend transaction input that references a second spendable transaction output, a third parallel constraint that requires the first spend transaction output locking script to include at least a first set of script instructions in the first set of smart contract script instructions, the first set of script instructions being at least partially determined by the first locking script, and a fourth parallel constraint that requires the second spend transaction output locking script to include a second set of smart contract script instructions, the second set of smart contract script instructions being at least partially determined by the locking script of the second spendable transaction output.

[0100] The method described above may include providing, in the first set of constraints, a first parallel constraint that requires the spend transaction to include a first spend transaction input that references a first spendable transaction, a second parallel constraint that requires the spend transaction to include a second spend transaction input that references a second spendable transaction output, a third parallel constraint that requires the first spend transaction output locking script to include at least a first set of script instructions in the first set of smart contract script instructions, the first set of script instructions being at least partially determined by the first locking script, and a fourth parallel constraint that requires the second spend transaction output locking script to include a second set of smart contract script instructions, the second set of smart contract script instructions being at least partially determined by the locking script of the second spendable transaction output.

[0101] The first set of constraints may include a first parallel constraint that requires a spending transaction to include a first spending transaction input that references a first spendable transaction, a second parallel constraint that requires the spending transaction to include a second spending transaction input that references a second spendable transaction output, a third parallel constraint that requires the first spending transaction output locking script to include a first set of at least script instructions copied from the first locking script in a first set of smart contract script instructions, and a fourth parallel constraint that requires the second spending transaction output locking script to include a second set of smart contract script instructions copied from the locking script of the second spendable transaction output.

[0102] It is also desirable to provide a computer-implemented method that includes: determining a first set of constraints on a first unlocked transaction output; determining a second set of constraints on a second unlocked transaction output; creating an initial transaction to include: at least one initial locking script that includes the first set of constraints and the second set of constraints; and at least one redeemable value, wherein unlocking at least one redeemable value depends on: the first set of constraints being at least partially satisfied by verifying that the unlocking transaction includes the first unlocked transaction output; and the second set of constraints being at least partially satisfied by verifying that the unlocking transaction includes the second unlocked transaction output; and causing the initial transaction to be verified at a node of a blockchain network.

[0103] The locking script in the first unlocked transaction output may be a copy of the locking script in the second unlocked transaction output.

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

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

[0106] Execution of at least one initial locking script may select at least a portion from multiple portions of at least one initial locking script.

[0107] Execution of the unlocking script of the unlocking transaction may cause at least one initial locking script to receive data corresponding to one of the first unlocked transaction output or the second unlocked transaction output.

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

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

[0110] At least one initial locking script may include constraints on a data source.

[0111] The method described above may further include determining a redeemable value of a first unlocking transaction output.

[0112] An initial transaction may encode a contract having multiple states.

[0113] An unlocking transaction may include multiple input values corresponding to multiple states.

[0114] A first set of constraints may constrain a first unlocking transaction output to have a first state. A second set of constraints constrains a second unlocking transaction output to have a second state.

[0115] There is also a desire to provide a computer-implemented method that includes: determining unlocking transaction constraints that constrain an unlocking transaction to include unlocking transaction inputs that reference a previous transaction output; creating a redeemable transaction that includes: a redeemable transaction output that includes a redeemable amount; and a redeemable transaction locking script that includes the unlocking transaction constraints, wherein unlocking the redeemable amount depends on the execution of at least one unlocking script of the unlocking transaction that satisfies the unlocking transaction constraints; and causing the redeemable transaction to be verified at a node of a blockchain network.

[0116] The unlocking transaction constraints may further constrain the unlocking transaction inputs to include a specific hash value.

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

[0118] The unlocking transaction constraints may further constrain the locking script of the unlocking transaction to include a set of script elements copied from the redeemable transaction locking script.

[0119] A redeemable transaction may encode a contract having multiple states.

[0120] The method described above may further include determining a redeemable value of an output of the unlocking transaction.

[0121] The unlocking transaction constraints may include specific locking script elements from a previous transaction output. As a result of the unlocking transaction inputs including the specific locking script elements, the execution of at least one unlocking script may satisfy the unlocking transaction constraints.

[0122] The specific locking script elements may encode an encryption key of a specific entity.

[0123] The unlocking transaction constraint may be a first unlocking transaction constraint; and the method may further include: determining a second unlocking transaction constraint to further constrain the unlocking transaction; and creating a second redeemable transaction, which includes: a second redeemable amount; and a second redeemable transaction locking script including the second unlocking transaction constraint, wherein unlocking the second redeemable amount may also depend on the execution of at least one unlocking script that satisfies the second unlocking transaction constraint.

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

[0125] At least a part of the first redeemable transaction locking script may include an encryption key associated with a first entity. At least a part of the second redeemable transaction locking script may include an encryption key associated with a second entity different from the first entity.

[0126] The unlocking transaction constraint may also constrain the unlocking transaction to constrain the output of the unlocking transaction.

[0127] The unlocking transaction constraint may encode another contract different from the above contract. Unlocking the redeemable amount may depend on the execution of another contract in the output of the unlocking transaction.

[0128] There is also a desire to provide a computer-implemented method that includes creating a blockchain transaction that encodes: a state machine in a first state and having a set of permitted state transitions; and a set of script elements to be executed to cause the unlocking transaction: to encode the state machine according to the set of permitted state transitions; and to comply with a restriction on the input of the unlocking transaction or comply with a restriction on the output of the unlocking transaction; and to cause the blockchain transaction to be verified by nodes in the blockchain network.

[0129] The set of permitted state transitions may include state transitions that can be independently and simultaneously implemented in different blockchain transactions.

[0130] The set of script elements may cause the unlocking transaction to comply with a restriction on the output of the unlocking transaction. The restriction on the output may require: a first output of the unlocking transaction to indicate a state corresponding to the first output that complies with the set of permitted state transitions; and a second output of the unlocking transaction to indicate a state corresponding to the second output that complies with the set of permitted state transitions.

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

[0132] The state corresponding to the first output and the state corresponding to the second output can be different states.

[0133] A set of script elements can make an unlocking transaction comply with the restrictions on the input of the unlocking transaction. The restrictions on the input may require an input to the unlocking transaction to indicate another state machine encoded in another blockchain transaction.

[0134] The restrictions on the input may require the input to reference a state machine in a first state and another state machine in another state different from the first state.

[0135] A first transition from a first state to a second state can be within a set of permitted state transitions. A second transition from another state to the second state can be within the set of permitted state transitions.

[0136] A set of script elements can make an unlocking transaction comply with the restrictions on the input of the unlocking transaction. The restrictions on the input can state a set of conditions for advancing a state machine. The set of conditions for advancing the state machine can depend on the state of another state machine.

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

[0138] A set of script elements can make an unlocking transaction comply with the restrictions on the output of the unlocking transaction. The restrictions on the output may require the unlocking transaction to incorporate a set of elements of a smart contract into the output.

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

[0140] A set of script elements can make an unlocking transaction comply with the restrictions on the input of the unlocking transaction and the restrictions on the output of the unlocking transaction.

[0141] It is also desirable to provide a computer-implemented method that includes: creating, at a node in a blockchain network, a blockchain transaction having a transaction output that can be unlocked by a first unlock transaction input of a first unlock transaction; inserting a first set of script elements that constrain the first unlock transaction into the blockchain transaction to include a first set of unlock transaction script elements corresponding to operations of a state machine; and inserting a second set of script elements into the blockchain transaction, the second set of script elements constraining a second set of unlock transaction script elements corresponding to a permitted state machine state transition that includes states that can be implemented using different blockchain transactions that can be processed simultaneously but independently by the blockchain network. The blockchain transaction can include a first output having a first locking script, and the first transaction output value can include a second output having a second locking script and a second transaction output value, wherein the first set of script elements is part of the first locking script.

[0142] The unlock transaction can include an unlock script that, when executed by a transaction verifier using a previous transaction output locking script, will satisfy a predetermined verification test and will cause the node, when executing the previous transaction output locking script, to store at least the value of a field representing the unlock transaction in a memory accessible to the transaction verifier. Insert the first set of script elements into the unlock transaction, where the first set of script elements forms part of the unlock transaction locking script of the first output of the unlock transaction and is consistent with the requirements specified by the previous transaction locking script, and where the first set of script elements corresponds to operations of a state machine, and insert the second set of script elements into the unlock transaction, where the second set of script elements forms part of the unlock transaction locking script, is consistent with the requirements specified by the previous transaction locking script, and corresponds to a permitted state machine state transition that includes states that can be implemented using different blockchain transactions that can be processed simultaneously but independently by the blockchain network.

[0143] The unlock transaction can include inputs and outputs, where the inputs reference a previous transaction output, and where the unlock transaction includes an unlock script that, when executed by a transaction verifier using the previous transaction locking script of the previous transaction output, will satisfy a predetermined verification test, where the unlock script causes the node, when executing the locking script, to store at least the value of a field representing the unlock transaction in a memory accessible to the transaction verifier, and insert data corresponding to an additional state machine into the unlock transaction based on a permitted state machine state transition as unlock transaction inputs and / or unlock transaction outputs such that the number of unlock transaction inputs and / or unlock transaction outputs used in the unlock transaction is sufficient for multiple state machine transitions.

[0144] Permitted state machine state transitions can include a forked transition from an initial state to two subsequent states by creating a first transaction output corresponding to the first subsequent state for an unlock transaction, inserting a first transaction output value of the first transaction output in the unlock transaction, sufficient to make the first transaction output an input to a first subsequent transaction referencing the first transaction output, inserting a third set of script elements in the first transaction output of the unlock transaction, wherein the third set of script elements is part of a first locking script that constrains the first subsequent transaction to assume the first subsequent state, creating a second transaction output corresponding to the second subsequent state for the unlock transaction, inserting a second transaction output value of the second transaction output in the unlock transaction, sufficient to make the second transaction output an input to a second subsequent transaction referencing the second transaction output, inserting a fourth set of script elements in the second transaction output, wherein the fourth set of script elements is part of a second locking script that constrains the second subsequent transaction to assume the second subsequent state, and inserting a fifth set of script elements in the first transaction output or the second transaction output, wherein the fifth set of script elements is part of the first locking script or the second locking script, imposing different constraints on the first subsequent transaction and the second subsequent transaction.

[0145] The first locking script can constrain the first subsequent transaction to have a first state and the second locking 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 a fork of three or more states. The unlock transaction can include three or more transaction input values corresponding to a merge of three or more states. The first locking script and the second locking script can constrain the first subsequent transaction and the second subsequent transaction to have the same state.

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

[0147] Permitted state machine state transitions can include a merged transition from two initial states to a subsequent state by inserting a first transaction input for a first previous state in the unlock transaction, inserting a second transaction input for a second previous state in the unlock transaction, and inserting a merged state in the unlock transaction that is a permitted transition from the first previous state and the second previous state according to a state transition matrix.

[0148] Permitted state machine state transitions can be hard - coded into the first transaction input and / or the second transaction input by inserting a first reference to a first previous transaction having the first previous state in the first transaction input, inserting a second reference to a second previous transaction having the second previous state in the second transaction input, and inserting a first transaction output for the merged state in the unlock transaction, wherein the state transition matrix is available for the first previous transaction and the second previous transaction.

[0149] Authorized state machine state transitions can include parallel operations from N (where N is two or more) initial states to N subsequent states by inserting a first transaction input for a first previous state into an unlock transaction, inserting a second transaction input for a second previous state into the unlock transaction, inserting a first reference to a first previous transaction having the first previous state into the first transaction input, inserting a second reference to a second previous transaction having the second previous state into the second transaction input, inserting a first transaction output for a first subsequent state into the unlock transaction, inserting a third set of script elements into the first transaction output, where the third set of script elements is part of a first locking script that constrains a first subsequent transaction to assume a first subsequent state, inserting a second transaction output for a second subsequent state into the unlock transaction, and inserting a fourth set of script elements into the second transaction output, where the fourth set of script elements is part of a second locking script that constrains a second subsequent transaction to assume a second subsequent state.

[0150] The operations of the state machine can be encoded as a smart contract implemented using a blockchain.

[0151] A transaction can be split using any constraints. The method can include creating a first transaction at a node in a blockchain network, where the first transaction includes a first output having a first redeemable value and a first locking script, and the first transaction includes a second output having a second redeemable value and a second locking script, where the first locking script includes a first set of constraints on a first selected transaction output, where if the first selected transaction output is valid for unlocking the first redeemable value, a first unlock script will satisfy the first set of constraints, and the second locking script includes a second set of constraints on a second selected transaction output, where if the second selected transaction output is valid for unlocking the second redeemable value, a second unlock script will satisfy the second set of constraints, and where the first set of constraints or the second set of constraints impose a constraint on the locking script of an unlock transaction that has the first selected transaction output or the second selected transaction output as an unlock transaction output.

[0152] The first selected transaction output can be the output of the first unlocking transaction, and the second selected transaction output can be the output of a second unlocking transaction different from the first unlocking transaction. The first set of constraints can be different from the second set of constraints and different from the constraints on the transaction inputs of the first transaction. The first set of constraints and the second set of constraints can each include a common set of constraints. The constraints on the locking script of the unlocking transaction can require that, for the unlocking transaction to be valid, the locking script of the unlocking transaction includes a reference to at least one field of the unlocking transaction. Another constraint requirement for the locking script is that, for the unlocking transaction to be valid, the locking script of the unlocking transaction includes a copy of a portion of the first locking script and / or a copy of a portion of the second locking script.

[0153] The first selected transaction output can be the output of the first unlocking transaction, the second selected transaction output can be the output of the second unlocking transaction, the first unlocking script can include fields of the first transaction, fields of the first selected transaction, and fields of the second unlocking transaction, and wherein the first locking 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 unlocking transaction.

[0154] The first set of constraints and the second set of constraints can each include a common set of constraints, whereby the two constrained unlocking transaction output locking 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 locking script and / or a hash of a portion of the second locking script, and / or a constraint on the size of a portion of the first locking script and / or the size of a portion of the second locking script.

[0155] The first set of constraints and / or the second set of constraints can include an optional reference to input data. Each of the multiple outputs of the first transaction can be constrained by different constraints imposed on the outputs of the multiple outputs.

[0156] A transaction can be combined with arbitrary constraints or have interdependencies, such as using a computer-implemented method that includes creating, at a node in a blockchain network, a first redeemable transaction, where the first redeemable transaction includes a first redeemable output having a first redeemable value and a first locking script that includes a first set of constraints on an unlocking transaction, where, if the unlocking transaction is valid for unlocking the first redeemable output, the first unlocking script of the unlocking transaction will satisfy the first set of constraints, the first set of constraints including a first unlocking transaction constraint that requires the first unlocking transaction output of the unlocking transaction to include a first unlocking transaction output locking script to include a first set of smart contract script instructions, and the first set of constraints including a second unlocking transaction constraint that requires the unlocking transaction to include a second set of smart contract script instructions and requires the unlocking transaction to include an unlocking transaction input that references a second redeemable transaction output.

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

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

[0159] The above method may include providing a first parallel constraint in the first set of constraints, the first parallel constraint requiring that the unlock transaction includes a first unlock transaction input referencing a first redeemable transaction, a second parallel constraint, the second parallel constraint requiring that the unlock transaction includes a second unlock transaction input referencing a second redeemable transaction output, a third parallel constraint, the third parallel constraint requiring that the first unlock transaction output locking script includes at least a first set of script instructions in the first set of smart contract script instructions, the first set of script instructions being at least partially determined by the first locking script, and a fourth parallel constraint, the fourth parallel constraint requiring that the second unlock transaction output locking script includes a second set of smart contract script instructions, the second set of smart contract script instructions being at least partially determined by the locking script of the second redeemable transaction output.

[0160] The above method may include providing a first parallel constraint in the first set of constraints, the first parallel constraint requiring that the unlock transaction includes a first unlock transaction input referencing a first redeemable transaction, a second parallel constraint, the second parallel constraint requiring that the unlock transaction includes a second unlock transaction input referencing a second redeemable transaction output, a third parallel constraint, the third parallel constraint requiring that the first unlock transaction output locking script includes at least a first set of script instructions in the first set of smart contract script instructions, the first set of script instructions being at least partially determined by the first locking script, and a fourth parallel constraint, the fourth parallel constraint requiring that the second unlock transaction output locking script includes a second set of smart contract script instructions, the second set of smart contract script instructions being at least partially determined by the locking script of the second redeemable transaction output.

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

[0162] The present disclosure also provides a computer-implemented method, including: determining an unlocking transaction constraint for constraining an input of an unlocking transaction, the constraint being imposed on (1) a reference of the input of the unlocking transaction, or (2) a portion of a previous transaction pointed to by the reference; creating a redeemable transaction, which is the previous transaction, the redeemable transaction including a transaction output and a transaction locking script, the transaction output including a redeemable amount, and the transaction locking script including the unlocking transaction constraint; and validating the redeemable transaction at a node of a blockchain network.

[0163] Wherein, unlocking the redeemable amount depends on fulfillment of the execution of the unlocking transaction constraint, the execution being performed by a verifier on a node of the blockchain network for the execution of: an unlocking script of the unlocking transaction, the unlocking script leaving the serialized content of the unlocking transaction on a stack; and then, the transaction locking script.

[0164] And wherein, the execution includes: verifying that the unlocking script contains certain data; extracting, from the input of the unlocking transaction included in the serialized content of the unlocking transaction on the stack, a reference to an output of the redeemable transaction; determining the constraint, including, if the constraint is imposed on a portion of the previous transaction, using the reference to cause injection of the previous transaction, after which the constraint can be applied to a field of the previous transaction; and verifying the determined constraint.

[0165] Optionally, the unlocking transaction constraint further constrains the input of the unlocking transaction to include a specific hash value.

[0166] Optionally, the specific hash value encodes an identifier that references the previous transaction output.

[0167] It is also desirable to provide a system, comprising: a processor; and a memory including executable instructions that, as a result of being executed by the processor, cause the system to perform any of the claimed methods.

[0168] It is also desirable to provide a non-transitory computer-readable storage medium storing executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to perform at least any of the claimed methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0169] With reference to the embodiments described herein, these and other aspects of the invention will become apparent and be elucidated. Embodiments of the invention will now be described only by way of example and with reference to the drawings, in which:

[0170] Figure 1 Shows a blockchain environment in which various embodiments can be implemented.

[0171] Figure 2 Shows an example of a blockchain node that can be used in the Figure 1 blockchain environment.

[0172] Figure 3 Shows an example of a transaction that can be stored in the Figure 2 blockchain ledger used by a blockchain node.

[0173] Figure 4 Shows an example of a blockchain transaction.

[0174] Figure 5 Shows an example script for implementing an OP_GENSIG script for generating a signature.

[0175] Figure 6 Shows an example script for implementing an OP_PREVTXINJECTION script for injecting the previous transaction corresponding to the input of an unlocking transaction.

[0176] Figure 7 Shows an example script for implementing an OP_SELFTXINJECTION script for injecting the previous transaction corresponding to a signed input.

[0177] Figure 8 Shows an example script for implementing an OP_SPENDINGTXINJECTION script for injecting a serialized unlocking transaction into a locking script.

[0178] Figure 9 Shows an example of a pair of transactions, where one is a transaction with a value to be transferred and the other is a transaction representing the unlocking of that value.

[0179] Figure 10Shows an example of multiple transactions, where a transaction has multiple inputs from other transactions and multiple outputs that can be transferred by future transactions.

[0180] Figure 11 Shows an example of generating a signature from a serialized set of transaction fields according to an embodiment.

[0181] Figure 12 Shows an example of an unlocking transaction that includes an unlocking script that includes a copy of a portion of the unlocking transaction.

[0182] Figure 13 Shows an unlocking transaction and a previous transaction.

[0183] Figure 14 Is a flowchart of an example of a locking script that imposes constraints on the locking script of an unlocking transaction.

[0184] Figure 15 Shows corresponding to Figure 14 Some examples of more specific steps corresponding to the steps.

[0185] Figure 16 Shows an example of verifying an unlocking script.

[0186] Figure 17 Shows an example of a locking script that imposes a set of constraints on an input.

[0187] Figure 18 Is a flowchart of an example of a locking script that imposes constraints on the input of an unlocking transaction.

[0188] Figure 19 Shows an example of an input constraint.

[0189] Figure 20 Shows in Figure 18 Examples of constraints in the context of the process shown.

[0190] Figure 21 Shows an interlocking script constraint.

[0191] Figure 22 Shows an example of a state machine implemented using blockchain transactions.

[0192] Figure 23 Shows an example of how state machine logic is encoded in a blockchain transaction.

[0193] Figure 24 Shows an example of a trustless deterministic state machine according to an embodiment.

[0194] Figure 25 Is a flowchart showing examples of processing for a trustless deterministic state machine according to various embodiments.

[0195] Figure 26 A state machine using a state transition matrix with certain characteristics is shown.

[0196] Figure 27 An example of a transaction that can be used to implement a state machine is shown.

[0197] Figure 28 An example of using a part of a blockchain transaction fork smart contract is shown.

[0198] Figure 29 Is an example pseudocode sequence for fork processing.

[0199] Figure 30 An example of creating a new smart contract from a smart contract using a blockchain transaction is shown.

[0200] Figure 31 Is an example pseudocode sequence for enforcing a smart contract in an unlock transaction.

[0201] Figure 32 An example of a merge operation of a smart contract using a blockchain transaction is shown.

[0202] Figure 33 A pseudocode sequence as an example of a merge process with weak dependencies.

[0203] Figure 34 Is a pseudocode sequence as an example of a merge process with strong dependencies.

[0204] Figure 35 An example of a parallel processing operation of a smart contract using a blockchain transaction is shown.

[0205] Figure 36 Is a pseudocode sequence as an example of parallel transaction barrier processing.

[0206] Figure 37 An example of how to execute a part of a smart contract according to a contract barrier using a blockchain transaction in a concurrent path is shown. DETAILED DESCRIPTION

[0207] First, reference will be made to Figure 1 , Figure 1 which shows an exemplary blockchain network 100 associated with a blockchain according to an embodiment of the present invention. In this embodiment, the blockchain network 100 includes blockchain nodes that may be implemented as peer-to-peer distributed electronic devices, each node running an instance of software and / or hardware that performs operations following a blockchain protocol that is agreed upon, in whole or in part, among the operators of the nodes. In some examples, these distributed electronic devices are simply referred to as "nodes" (e.g.Figure 1 Node 102 in

[0208] Node 102 may include any suitable computing device (e.g., a server in a data center, a client computing device such as a desktop computer, laptop computer, tablet computer, smartphone, etc.), be composed of multiple computing devices in a distributed system of a computing resource service provider, or be any suitable electronic client device. Node 102 may have an input to receive data messages or objects representing a proposed transaction such as transaction 104. Node 102 may query the information it maintains, such as an understanding of the transaction status.

[0209] As Figure 1 shown, some nodes 102 may be communicatively connected to one or more other nodes 102. As for which nodes 102 can communicate with which other nodes, these details do not need to be determined centrally. It is sufficient that the active nodes in the blockchain network 100 can communicate with one or more other nodes 102 assuming the message is a message that the blockchain protocol indicates should be forwarded, such that a message passed from one node 102 to another node 102 can propagate in the blockchain network 100 (or some significant portion thereof). One such message can be the publication of a transaction proposed by one of the nodes 102A, and then the message will propagate along a path such as path 106. Another such message may be the publication of a new block proposed to be included in the blockchain.

[0210] Figure 2 illustrates an example of a blockchain node 202 that can be used as a Figure 1 node in a blockchain network in a blockchain environment. As shown, the blockchain node 202 is shown to include a processor 204, a program memory 206, a storage of blockchain rules and protocol details 208, a peer list 210, a storage of application variables 212, a communication interface 214, and a storage of the blockchain ledger 216. The blockchain ledger 216 contains data corresponding to the blocks in the blockchain, such as blocks 221, 222, 223 that contain data corresponding to transactions, such as block 222 having transactions 230(1)-(4). Except for block 223, the above blocks may be cryptographically immutable because subsequent blocks depend on values computed on the block when it 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 block, representing the storage of transactions that may be variable and may not have been committed to the blockchain yet.

[0211] The blockchain node 202 communicates through the communication interface 214, which can be implemented as one or more of wired or wireless communications. The blockchain ledger 216 can be a complete copy or a part of the blockchain ledger of the blockchain network. Some blockchain nodes may only maintain untransferred transactions, while other nodes may maintain the entire ledger. In this way, the ledger is a distributed ledger because each node can have its own copy. Preferably, the nodes only modify their copies according to the rules of the protocol, and for all nodes that fully follow these rules, their copies should sometimes be the same as those of other nodes, saving some propagation time for blocks and transactions. The blockchain node should include the ability to verify the blocks it receives and the transactions in these blocks. The rules of the blockchain protocol may be that if a blockchain node determines that a block of a transaction is invalid, then the blockchain node does not propagate the block or the transaction to other nodes. According to this rule, valid and verified blocks and transactions can propagate through the blockchain network, while invalid blocks and transactions may not propagate.

[0212] Some nodes in the blockchain network can be blockchain nodes that perform operations of collecting transactions and creating transaction blocks so that new blocks can be submitted to the blockchain. This blockchain node may be expected to perform some operations that are both complex (to prevent rogue nodes from easily creating inappropriate blocks) and data-dependent on the included transactions (so that rogue nodes cannot perform complex operations in advance), and the performance of these tasks can be easily verified by other nodes. Since the above other nodes verify the work of this blockchain node, after verification, the other nodes receive the block into their blockchain copies and propagate it. This submits the new block to the distributed ledger of the blockchain. In some examples, a block is a group of transactions, usually marked with a timestamp and the "fingerprint" (such as a hash) of the previous block. In this way, each block is linked to the previous block, thus creating a "chain" that links the blocks in the blockchain. In an embodiment, a valid block can be added to the blockchain through the consensus of nodes in the blockchain network. Also in some examples, the blockchain includes a list of verified blocks.

[0213] In an embodiment, as described in the present invention, at least some nodes serve as verification nodes for verifying transactions. In some examples, the blockchain attests to values in the form of digital assets, and the transactions of the blockchain together provide a chain from the genesis transaction (initiating the blockchain) or an allocation transaction to subsequent transactions. The end of a portion of the chain will be an untransferred transaction or a portion thereof, and each transaction on the blockchain designates one or more outputs, some of which may be transferred and some not, where the output includes a specification of the value of the output and the requirements for someone to "unlock" the output by inserting a valid transaction (i.e., a transaction that at least meets the specified requirements), which will extend that portion of the chain. As used herein, an unspent transaction output may be referred to as (Unspent Transaction Output, abbreviated as UTXO). Unlocking a UTXO may also be referred to as spending a UTXO in the art.

[0214] The requirements for someone to unlock a UTXO may be specified in the locking script of the UTXO. A valid unlocking transaction may be (i) designating one or more previous UTXOs as inputs to the transaction, where the designation may be with a pointer to the UTXO, (ii) meeting the requirements of the locking script for each UTXO, and (iii) having inputs such that the sum of the values of all the UTXOs pointed to by these inputs is less than or equal to the sum of the values of all the outputs of the transaction. Data representing meeting the requirements of the locking script may be referred to as an unlocking script. The verification node may process the unlocking script, followed by the locking script, and the output of the process is either an invalid result or a verification of the unlocking transaction.

[0215] The process may be a stateless process, so that if a node runs the unlocking script and the locking script, the result is a verification, and this verification will be the result for other nodes. Thus, an unlocking transaction that meets the locking script of a previous transaction output that already exists on the blockchain but has not been transferred may be propagated and ultimately submitted to the blockchain. The node creating the unlocking transaction to be submitted, in turn, specifies in its own locking script the requirements for anyone to unlock the output value of the new transaction. The process may be considered stateless because the scripts do not need to reference things outside the scripts, nor do they depend on variables or other states outside these scripts, except for some minor exceptions. Thus, the unlocking script and the locking script may be evaluated separately.

[0216] In other variations, the blockchain system may include functionality that allows external data to be included in the script evaluation process. In this case, the external data may be controlled and / or protected by ensuring that when the unlocking script and the locking script are evaluated using the external data, the evaluation is consistent among the nodes performing the evaluation.

[0217] Figure 3 is shown that may be stored in byFigure 2 An example of transaction 300 in the blockchain ledger used by a blockchain node. Other variations with similar functionality are also possible. The data elements or fields of the transaction can be as Figure 3 shown and can include other fields in addition to those described in the present invention. As shown, there is a blockchain version field 302, which has a value indicating the blockchain protocol version of transaction 300. The #vin field 304 indicates how many transaction inputs (described below) exist in transaction 300. Other fields may exist and are not shown, but for each transaction input (shown as an example Vin[y]310 herein), there can be a set of fields that includes the transaction identification (TxID) 311 of the previous transaction, a pointer 312 to one of the outputs of that previous transaction (the transaction that provides the transaction output to match the transaction input 310), where the TxID 311 and the pointer 312 together form a pointer 313 that references the output of the previous transaction. As used herein, the term "previous transaction" when used in the context of the current or this transaction can refer to a specific previous transaction (or transactions) that has a transaction output that is referenced (and "transferred") by the current or this transaction. In the example, the current or this transaction can be referred to as an "unlocking transaction".

[0218] In some blockchain implementations, there is no centralized mechanism for assigning unique TxID values, but rather there is a decentralized mechanism for generating unique TxIDs for transactions, such as by generating a hash of the content of the transaction itself. Since a valid transaction cannot have exactly the same content as another valid transaction, each valid transaction can have a unique hash for its TxID (except for an extremely low probability of hash collisions). However it is implemented, it is assumed herein that each transaction has a unique transaction identification. Due to the nature of hashing, once the TxID is generated from the content of the transaction, that content cannot be changed and the TxID remains valid for that transaction.

[0219] As Figure 3 shown, the set of fields of the transaction input Vin[y]310 also includes an unlocking script length field 314 (Unlocking_Script_Length field) that indicates the length of the subsequent script, an unlocking script field 315 that contains the unlocking script of vin[y]310, which "unlocks" the corresponding locking script of the transaction output pointed to by the pointer 313, and a sequence # field 316 that can be used to constrain transaction 300.

[0220] Although Figure 3Only one transaction input and one transaction output are explicitly shown, but multiple transaction inputs and multiple transaction outputs are also possible. After the transaction input, there may be a #vout field 320, which may indicate how many transaction outputs exist in the transaction 300 (also explained below). For each transaction output (shown as an example Vout[x] 330 herein), there may be a set of fields, which includes an output value field 332 indicating the transaction value provided by the transaction output Vout[x] 330, a locking script length field (Locking_Script_Lengthfield) 334 indicating the length of the subsequent script, and a locking script field (Locking_Scriptfield) 336 containing the locking script of the transaction output Vout[x] 330. As explained, the transaction value of the transaction output can be "transferred" by anyone who can create an unlocking transaction with a transaction input that has an unlocking script, which, when verified using the unlocking script and the locking script, can be verified as true by a blockchain node. Other fields may follow the transaction output fields, such as a lock time field 338, which may restrict the transaction 300 from being inactive until a specified future time or before a specified future block. In the case where each transaction input of the unlocking transaction points to the corresponding transaction output of the previous transaction and the previous transaction output includes a transaction value, the transaction input does not need to include a field indicating the transaction value.

[0221] Figure 4 An example of a blockchain transaction 400 is shown. In this example, the blockchain transaction 400 includes the data elements or fields shown, and may include additional fields other than those shown or described in the present invention. The transaction 400 includes an nVersion field 402 having a value indicating the version of the transaction 400. The #vin field 404 may indicate how many transaction inputs exist in the transaction 400. For each transaction input, such as the transaction input Vin[y] 410, there may be a set of fields, which includes a hash 411 referencing the previous transaction, a pointer n 412 pointing to a specific output of the previous transaction, a scriptSigLen field 414 indicating the length of the subsequent unlocking script, a scriptSig field 415 containing the unlocking script of the transaction input Vin[y] 410, and an nSequence field 416 that can be used to constrain the transaction 400.

[0222] After a transaction input, there may be a #vout field 420, which indicates how many transaction outputs exist in the transaction 400, and for each transaction output (one is shown as an example Vout[x] 430 herein), there may be a set of fields, including an nValue field 432 indicating the transaction value provided by the transaction output Vout[x] 430, a scriptPubKeyLen field 434 indicating the length of the subsequent locking script, and a scriptPubKey field 436 containing the locking script for the transaction output Vout[x] 430. The transaction 440 may also be shown with an nLockTime field 438, which may constrain the transaction 400 to be inactive until a specified future time or before a specified future block.

[0223] Operation code

[0224] In an example scripting language, there may be a set of operation codes (OP codes for short), which may appear as script instructions in a script (such as a locking script or an unlocking script). In the present invention, various script operation codes and keywords are referenced to perform various operations. However, it is contemplated that other blockchain technologies may implement different sets of instructions, and thus the operation codes described in the present invention should be regarded as illustrative of the operations performed by the operation codes.

[0225] Some embodiments of the present invention operate under the assumption that the script system or other systems for implementing the described set of instructions allow more than 200 instructions (e.g., more than 200 operation codes) in a single script. Similarly, some embodiments of the present invention also assume that the functions provided by the operation codes referenced by the present invention exist and are enabled in the system that executes the operation code script / instruction set. Examples of the operation codes referenced in the present invention include:

[0226] · OP_ADD, pops the top two items from the stack, adds them together, and pushes the result onto the stack

[0227] · 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

[0228] · OP_BIGMODADD, pops the top three items from the stack, performs a modular addition on the first and second items,

[0229] performs a modular operation on the third item, and pushes the result onto the stack

[0230] · OP_BIGMODINVERSE, pops the top two items from the stack, performs a modular negative exponentiation of the first item modulo the second item, and pushes the result onto the stack

[0231] ·OP_BIGMODMUL pops the top three items from the stack, performs modular multiplication on the first and second items,

[0232] performs a modulo operation on the third item, and pushes the result onto the stack

[0233] ·OP_CAT pops the top two items from the stack, concatenates these two items and pushes the result onto the stack

[0234] ·OP_CHECKSIG pops two items from the stack, uses the first as the public key and the second as the signature, checks whether the popped signature is a valid signature, if valid, pushes 1 (true) onto the stack, otherwise pushes 0 (false) onto the stack

[0235] ·OP_CHECKSIGVERIFY has the same function as OP_CHECKSIG, but OP_

[0236] VERIFY is then executed

[0237] ·OP_DIV pops two items from the stack, divides the second item by the first item, and pushes the result onto the stack

[0238] ·OP_DUP pushes a copy of the top item on the stack onto the stack, thus duplicating the top item ·OP_ELSE, if the previous OP_IF or OP_NOTIF or OP_ELSE has not been executed, these statements will be executed; otherwise, if the previous OP_IF or OP_NOTIF or OP_ELSE has been executed, these statements will not be executed

[0239] ·OP_ENDIF ends the if / else block

[0240] ·OP_EQUAL reads the top two items on the stack, if these two items are exactly equal, pushes 1 onto the stack, otherwise pushes 0

[0241] ·OP_EQUALVERIFY is the same as OP_EQUAL, but then runs OP_VERIFY

[0242] ·OP_FROMALTSTACK places the input on the top of the main stack and removes it from the alternate stack

[0243] ·OP_HASH256 where the input is hashed twice: first using SHA-256 and then using RIPEMD-160

[0244] ·OP_IF, if the top stack value is not false, executes the statement and removes the top stack value

[0245] ·OP_MUL, multiply the first two items on the stack

[0246] ·OP_NOTIF, if the top stack value is false, execute the statement and remove the top stack value

[0247] ·OP_OVER, copy the second item on the stack and push it onto the top of the stack

[0248] ·OP_ROLL, where the item at depth n in the stack is moved to the top

[0249] ·OP_SUBSTR, return a part of a string

[0250] ·OP_SWAP, where the first two items on the stack are swapped

[0251] ·OP_TOALTSTACK, place the input on the top of the alternate stack and remove it from the main stack

[0252] ·OP_VERIFY, if the top stack value is not true, mark the transaction as invalid.

[0253] Some of the above operation codes may be basic operation codes supported by blockchain nodes. For ease of description, other codes are referred to as operation codes in this article, but they are usually implemented as small scripts composed of multiple basic operation codes. For example, OP_BIGMOD is referred to as an operation code, but it can be implemented using a series of operation codes to perform the function of dividing the first two items on the stack and returning the remainder. OP_BIGMODADD, OP_BIGMODINVERSE, and OP_BIGMODMUL can be represented in a straightforward manner using similar sequences of operation codes.

[0254] OP_GENSIG: In the present invention, the reference to OP_GENSIG should be regarded as a shorthand for the operations corresponding to the OP_GENSIG script described herein. The OP_GENSIG script for generating a transaction signature, which signature may be pushed onto the stack or used. The OP_GENSIG script begins with the assumption that the inputs pushed onto the main (last-in, first-out) stack in sequence are <SIGHASH Type> (indicating which fields of the transaction will be used in the hash), the message value <m>(Serialized collection of spent transaction fields of the transaction), private key (For message values <m>perform hashing) and numbers <k>(a random or pseudo-random number used to mask / protect the private key; "mask number").

[0255] < / k> < / m> Figure 5 Shows the input and output of the OP_GENSIG script. In the OP_GENSIG script, the first line results in a number <k>Copied to the alternate stack, and then <k>Multiply by the elliptic curve generator <PubK G> to produce 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) modulo n. Finally, the fourth line of the script encodes r and s in DER format and associates with <sighashtype>Connection

[0256] The type of signature hash can be represented by the byte-encoded value SIGHASH Type. 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 SIGHSH type value can be SIGHASH_ALL, SIGHASH_NONE, SIGHSH_SIGNAL, SIGHASH_ANYONECANPAY, or some combination of two or more of them. In an embodiment, the SIGHASH_ALL type means that all fields in the transaction, except for the input script, will be included in the serialization (and thus hashed and signed). In an embodiment, the SIGHASH_NONE type indicates that the output does not need to be signed, which may allow others to update the transaction. In an embodiment, the SIGHSH_SIGNAL type indicates that the input is signed, but the sequence number is masked, so that others can create a new version of the transaction that will use the same hash (assuming the hashed fields have not changed), but the only signed output is the output at the same position as the input.

[0257] In an embodiment, the SIGHASH_ANYONECANPAY type is combined with other types and indicates that the input including SIGHASH_ANYONECANPAY is signed, but other inputs do not need to be signed. The SIGHASH Type value can be represented by a number indicating the SIGHASH Type. For example, in some implementations, SIGHASH_ALL is represented by a byte with a value of 1 (e.g., binary "0000001"), SIGHASH_NONE is represented by a byte with a value of 2 (e.g., binary "0000010"), SIGHASH_NONE is represented by a byte with a value of 3 (e.g., binary "0000011"), and SIGHASH_ANYONECANPAY is represented by a byte with a value of 80 (e.g., binary "01010000"). In some implementations, the combined SIGHASH Type value is performed by binary addition of the individual byte values. In some examples, the set of transaction fields determined by the SIGHASH Type refers to a subset of the corresponding transaction to be serialized determined by the SIGHASH Type value. For example, for the SIGHASH Type of SIGHASH_ANYONECANPAY, only one transaction input is included in the signature.

[0258] By requiring that the unlocking script includes SIGHASH, the locking script can verify that the serialized set of unlocking transaction fields provided by the unlocking script is indeed the source of the SIGHASH, and in turn, using the OP code OP_CHECKSIG, the locking script can verify that the SIGHASH Type value provided by the unlocking script matches the signature hash of the unlocking transaction. The locking script can perform this operation because when it is executed by a transaction verifier, that transaction verifier is capable of performing the OP_CHECKSIG operation and placing the signature of the actual unlocking transaction on the stack.

[0259] OP_DERENCODE: In the present invention, a reference to OP_DERENCODE should be considered as a shorthand for an operation corresponding to popping the first two items from the stack, encoding them in DER format, and pushing the result onto the stack.

[0260] OP_ECPMULT: In the present invention, a reference to OP_ECPMULT should be considered as a shorthand for an operation corresponding to popping two items from the stack, performing an elliptic curve point multiplication (also known as an elliptic curve scalar multiplication) on those two items, and pushing the result onto the stack.

[0261] OP_ECPX: A reference to OP_ECPX should be considered as a shorthand for an operation corresponding to popping two items from the stack, using the first item as the modulus n, the second item as the elliptic curve point K, calculating the x coordinate of K modulo n, and pushing the result onto the stack.

[0262] OP_PREVTXINJECTION: In the present invention, a reference to OP_PREVTXINJECTION should be considered as a shorthand for an operation corresponding to the injection of the previous transaction corresponding to the input X of the unlocking transaction. Figure 6 The input and output of the OP_PREVTXINJECTION script are shown.

[0263] OP_SELFTXINJECTION: In the present invention, a reference to OP_SELFTXINJECTION should be considered as a shorthand for an operation corresponding to the injection of the previous transaction corresponding to the signed input. Fig. Figure 7 The input and output of the OP_SELFTXINJECTION script are shown.

[0264] OP_SPENDINGTXINJECTION: In the present invention, a reference to OP_SPENDINGTXINJECTION should be considered as a shorthand for the operation corresponding to injecting a serialized unlocking transaction into a locking script. Any entity that provides a SIGHASH Type value and a set of unlocking transaction fields determined according to the SIGHASH Type can unlock the transaction output. This may be a useful feature. Figure 8 Shows the input and output of the OP_SPENDINGTXINJECTION script.

[0265] OP_EXTRACTTXID: In the present invention, a reference to OP_EXTRACTTXID should be regarded as a shorthand for the operation corresponding to taking a transaction ID and a transaction ID position as inputs and outputting the extracted transaction ID. The input of OP_EXTRACTTXID is a serialized transaction and a value X indicating the input index, and the output is the 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 may include fields of variable length, and the change in length is indicated by other fields in the serialized transaction.

[0266] Figure 9 Shows an example of a pair of transactions. A blockchain node 902 that validates transactions can have a transaction validator 904, which can be a stateless stack-based transaction validator that outputs a true or false result 906 based on whether its input is valid. In other variations, the transaction validator is not necessarily stateless and / or can reference external trusted data or state. The guidance herein can also apply to blockchain systems that do not use stack-based transaction validators.

[0267] The input to the transaction validator 904 can be the locking script 910 of the output (the transferred transaction output) from a previous transaction 912 and the unlocking script 920 of the input (the transaction input for unlocking) of the unlocking transaction 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 locking script 910 can be the locking script of one of the multiple transaction outputs of the previous transaction 912, and the unlocking script 920 can be the unlocking script of one of the multiple transaction inputs of the unlocking transaction 922.

[0268] Using a stateless stack-based transaction verifier, the locking script 910 and the unlocking script 920 can be processed separately without relying on variables or other state outside of these scripts, with some minor exceptions. As a result, the locking script 910 can refrain from referencing fields of the previous transaction outside of the locking script 910 itself. The locking script 910 also cannot reference fields of the unlocking transaction 922 because the unlocking transaction 922 does not exist when the previous transaction 912 and the locking script 910 are created and become immutable.

[0269] For the unlocking script 920 to be stateless, it also cannot operate directly on fields of the unlocking transaction 922. The stateless quality can be useful because it ensures that given the same locking script 910 and the same unlocking script 920, any properly programmed blockchain node will arrive at the same result 906. One exception is that the script may have the ability to reconcile signatures in one of the scripts with the signature generated for the entire transaction. In an embodiment, the script can use OP_CHECKSIG for this purpose.

[0270] In a stack-based operation, the transaction verifier executes the unlocking script by processing each opcode in the script in sequence. Some opcodes cause processing, some cause data to be pushed onto or popped from the stack, or some combination. Once the execution of the unlocking script is complete, there may be remaining data on the stack. If the execution of the unlocking script has no script errors or opcodes that terminate execution, the transaction verifier executes the locking script, which can use the data present on the stack. In cases where the locking script and the unlocking script can be written using the same set of opcodes, this effectively resembles executing a single script that consists of the concatenation of the unlocking script and the locking script. However, checking for script errors at the end of the execution of the opcodes of the unlocking script and before the execution of the opcodes of the locking script can prevent issues caused by a malformed unlocking script.

[0271] Once 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 regarded as verification that the unlocking script has effectively unlocked the locking script. In this regard, the unlocking script meets all the requirements of the locking script.

[0272] Figure 10 Shows an example of multiple transactions and multiple inputs / outputs. As shown, the previous transaction 1002 has two transaction outputs, Vout[0] 1004 with its locking script 1006 and Vout[1] 1014 with its locking script 1016, and their corresponding transaction output values, as well as other fields not shown (such as the transaction inputs of the previous transaction 1002). The unlocking transaction 1020 is shown as having two transaction inputs, Vin[0] 1024 (with its unlocking script 1026 and a pointer 1028 to its corresponding previous transaction output) and Vin[1] 1034 (with its unlocking script 1036 and a pointer 1038 to its corresponding previous transaction output). In this example, the previous transaction output corresponding to Vin[0] is Vout[0] of the previous transaction 1002 (previous transaction 1), and the previous transaction output corresponding to Vin[1] is some output (not shown) of another transaction (previous transaction 2).

[0273] To verify the unlocking transaction 1020, the blockchain node 1042 with the transaction verifier 1044 outputs a true or false result 1046 based on whether all of its inputs are valid. In this case, there can be multiple inputs for unlocking the transaction 1020, so each input is verified by processing the unlocking script of the transaction input and the locking script of the corresponding transaction output pointed to by the pointer of the input.

[0274] Using the ability to have multiple outputs and multiple inputs, the value of one transaction can be transferred through multiple other transactions, and the redeemable value in a new transaction can come from multiple previous transactions. As mentioned above, the locking script can impose constraints on what must be included in the unlocking script through signatures and other cryptographic techniques.

[0275] One such constraint might be that the unlocking script must contain some arbitrary data. Some constraints might be "weak constraints" or more general constraints, such as the unlocking script must contain some data that is 4 bytes in length, or some specific number of bytes, without constraining those bytes to any specific value. A stronger or more specific constraint might be that when the data is hashed, the data must produce a specific hash value. The latter constraint generally requires the data to have a specific length and a specific value of the data, because it is almost impossible for someone to determine different values that would result in the same hash. This constraint can be implemented in the script by pushing the data onto the stack by the unlocking script, or pushing the hash of the data onto the stack, having the locking script push the required hash onto the stack, then executing the OP_EQUAL, and then the OP_VERIFY opcode. If the two pushed items match, these opcodes will return true, and if they don't match, they will return false. In a more general case, constraints can be imposed that require the presence of certain data or data with certain characteristics.

[0276] An example of a weak constraint is that the unlocking script must include certain data, which may contain a serialized set of unlocking transaction fields, without necessarily requiring these fields to be any particular values. In this way, the locking script can constrain the script of the unlocking script that unlocks the output of that locking script to include the fields of the unlocking transaction from which the unlocking script originated. This effectively allows the locking script to operate on the fields of the unlocking transaction left on the stack by the unlocking script. Another example of a weak constraint is that the unlocking script must contain certain data that may be obtained from a specified location, but there is no constraint on the value of the data. This allows some weak constraints to be imposed even if the value of the data is determined only after the locking script is immutable.

[0277] The operations of the constraints and the data of the constraints may include elements of a "smart contract". A smart contract defines the terms and conditions of the contract, regarding who can do what, when they can do it, and who gets paid when. In the unlocking script or other parts of the unlocking transaction, the terms and conditions can be expressed as constraints (weak or strong), and these terms and conditions of the smart contract can be enforced by the blockchain protocol. Thus, as in the example above, only Bob can unlock the value of the locked transaction output (because only an unlocking script created by Bob can unlock that transaction output), there may be constraints such as only after permission is granted by one party and after a specific time and only after another transaction output is spent, and then the transaction output can be spent.

[0278] Figure 8 OP_SPENDINGTXINJECTION is shown, which is an abbreviation of the operation code of the script that encodes the constraints for the injection of a serialized set of unlocking transaction fields. The locking script may include the operation code OP_GENSIG (which will cause a signature to be generated), followed by the operation code OP_CHECKSIG (which will cause the signature to be checked to see if it is a valid signature for the unlocking transaction). For OP_GENSIG to produce a valid signature, it must have certain elements as inputs: a SIGHASHType element, the hash of the serialized set of unlocking transaction fields (corresponding to a particular set of SIGHASH Type elements), a private key, and a masking number (e.g., a random or pseudo-random number used to mask / protect the private key). By including a hash operation code, a private key, and a random number in the locking script, this effectively constrains the unlocking script to provide the SIGHASH Type and the serialized set of unlocking transaction fields.

[0279] Figure 11 A process for generating a signature from a serialized set of transaction fields is shown. This can be done by a blockchain node that creates the transaction or other transaction generator. As Figure 11 As shown, 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 the SIGHASH Type 1112 and provides the signer's private key. The blockchain client / node can determine the fields to be used or modified for the serialized transaction 1110 from the SIGHASH Type 1112. Before generating the hash, some fields may be modified (instead of setting them to zero). In Figure 11 the example of Figure 11 , the SIGHASH Type is set to be equal to SIGHASH_NONE|SIGHASH_ANYONECANPAY, so the selected fields are the fields shown by the modified serialized transaction 1114.

[0280] The blockchain client / node generates the hash of the modified serialized transaction 1114 (e.g., performs a double SHA-256 hash), thereby producing the message m 1116. The blockchain client / node processing the serialized transaction 1110 selects a number k 1118, which is typically a random number or a pseudo-random number, in order to mask / protect the private key. In the present invention, the number k is sometimes referred to as the "mask number". The blockchain client / node creates a signature 1124 (in this example, a DER-encoded electronic signature) based on the set of signature inputs 1120 from the SIGHASH Type 1112, the message m 1116, the signer's private key 1122, and the number k 1118. The signature 1124 and the SIGHASH Type 1112 can then be used in the unlocking script.

[0281] Figure 12 An example of the unlocking transaction 1200 is shown, which includes an unlocking script 1203 that includes a copy of the unlocking transaction (e.g., a serialized set of the fields of the unlocking transaction). As Figure 12 As shown, one of the transaction inputs is Vin[z]. The input Vin[z] has a hash which is the TxID of the previous transaction, and the output number n of that previous transaction. Together these form a pointer 1202 to a specific output of a specific previous transaction which will be unlocked by Vin[z]. The transaction input Vin[z] has an unlocking script 1203 which in turn has a number of components or sub-scripts 1206, 1208, 1210, 1212. The unlocking script 1203 includes a serialized version 1206 of the previous transaction Z. Also shown is a serialized version 1208 of a previous transaction Z′ which is a transaction with an output transferred from the previous transaction Z serialized in the same way. Although not shown, additional previous transactions may be included. The unlocking script 1203 also includes a SIGHASH_TYPE byte 1210 to indicate which fields of the unlocking transaction 1200 have been included.

[0282] The locking script of the previous transaction uses OP_GENSIG and OP_CHECKSIG to constrain the unlocking script to include the unlocking transaction, and uses the TxID of the previous transaction and OP_EQUALVERIFY to constrain the unlocking script to include the serialized version 1206 of the previous transaction Z. The TxID of the previous transaction Z can be extracted from the fields of the unlocking transaction and the previous transaction Z can be injected. Since the previous Tx Z itself includes the TxID of the previous transaction Z′, that TxID can be extracted, and so on.

[0283] The serialized set of transaction fields of the unlocking transaction does not include the unlocking script of the unlocking transaction itself; otherwise there would be a causality problem. In some embodiments, the signature hash of a transaction can exclude some pre-determined fields. The SIGHASH Type can refer to the set of fields extracted from the transaction before serialization and hashing.

[0284] The locking script of the previous transaction can impose the requirement on the unlocking transaction that for the unlocking transaction to be valid, the unlocking script of the unlocking transaction needs to include copies of some or all of the fields of the unlocking transaction and references to one or more previous transactions that the unlocking transaction unlocks. Of course, the fields of the unlocking transaction can be variable when the unlocking transaction is created. However, the locking script of the previous transaction can impose constraints on the fields of the unlocking transaction because if those fields of the unlocking transaction that are part of the unlocking script of the unlocking transaction do not meet these constraints, the unlocking transaction may not verify when the unlocking script is executed. Fields that are not part of the unlocking script (such as fields that do not contain a SIGHASH Type value or are set to zero) may not be constrained by the locking script. Also, not all fields included in the serialized unlocking transaction need to be constrained. For example, the locking script may only constrain one of the multiple fields of the serialized unlocking transaction included in the unlocking script.

[0285] Different outputs of a previous transaction can have different sets of constraints applied, perhaps constraints on different inputs and outputs of different unlocking transactions. Using this technique, a blockchain node can create a transaction using such a locking script, and the locking script can also perform other checks such that as the created transaction output is transferred, the transaction unlocking the transaction output, etc., may necessarily carry various data elements and states.

[0286] Figure 12 Transactions can be extended to implement a state machine with fairly complex functionality. As described above, the locking script can access data that is only available after the locking script has been created and finalized during verification. This data can include details of the fields of the unlocking transaction being verified and details of the previous transaction containing the locking script (and potentially other previous transactions known to the blockchain node creating the unlocking transaction at that time). This allows the state of the state machine to be represented in the script and allows states and state transitions to be implemented and occur within the trustless scope of the blockchain environment. In other words, the state machine can be implemented using transactions verified by blockchain nodes that are not necessarily trusted, by treating the transactions like other transactions processed by the blockchain network. In some examples, "trustless" refers to the property that any entity can create a valid unlocking transaction as long as the constraints are met, and the entity does not need to be trusted. However, in some cases, an entity may need to interact with a determined source to obtain the required inputs. In some embodiments, one or more inputs can be obtained from an undetermined source (e.g., from serialized previous transactions).

[0287] In a blockchain network, a transaction has some input values (determined by the transaction output values of the previous transactions unlocked by the transaction inputs) and some output values. For it to be valid, the sum of the outputs cannot exceed the sum of the inputs (except for allocation transactions and genesis transactions, which may be reserved in this specification), and, the outputs may be less than the inputs. When implementing a trustless deterministic state machine using a blockchain network, the initial state of the state machine will be in a transaction containing sufficient value to provide a rationale for transactions including state transitions corresponding to the state machine.

[0288] In general, the locking script of a previous transaction can be used to implement a state machine such that the unlocking transaction represents a state transition of the state machine, where the locking script constrains the content of the unlocking transaction, specifically constraining the content and nature of the various transaction outputs of the unlocking transaction. Thus, the locking script of the previous transaction output can effectively specify what each transaction output of the unlocking transaction needs to look like. The locking script can require different characteristics for different unlocking transaction outputs (e.g., by requiring that Vout[0] of the unlocking transaction includes certain data and script elements), and Vout[1] of the unlocking transaction includes certain other data and other script elements.

[0289] Any entity that provides the SIGHASH Type and the set of unlocking transaction fields used by a particular SIGHASH Type can unlock a transaction output. In this way, some parties will have an incentive to spread the content of a transaction by unlocking the transaction and forwarding details from the locking script. As noted above, in some examples, "unlocking" a transaction output means creating an unlocking transaction that references the transaction output and can be evaluated as valid, which can result in the transfer of the transaction output.

[0290] Using the techniques and apparatus described above, transactions can be created on a blockchain ledger that includes scripts implementing smart contracts, scripts capable of implementing state machines, and scripts that can reference fields of the current transaction, a previous transaction having an output transferred by the current transaction, and possibly other previous transactions. With these tools, the transaction flow can execute self-replicating scripts for use in smart contracts or other purposes.

[0291] Figure 13 An unlocking transaction 1320 and a previous transaction 1310 are shown. In this example, the unlocking transaction has an input Vin[0] 1322 that references the previous transaction and a transaction output Vout[x] 1314 of the previous transaction. For the unlocking transaction to be considered valid, the constraints of the locking script of Vout[x] must be satisfied. As noted above, some constraints may be simple, such as the simple requirement that the unlocking script of the unlocking transaction input pointing to the locking script must be able to provide a valid signature signed by the public key appearing on the locking script. However, as described herein, the locking script can provide more complex constraints.

[0292] For example, the locking script of Vout[x] 1314 of the previous transaction 1310 can impose specific constraints on the output of the unlocking transaction. In this example, the locking script of Vout[x] 1314 imposes a set of constraints (constraint set 1) on the output Vout[0] 1324 of the unlocking transaction 1320 and a set of constraints (constraint set 2) on the output Vout[0] 1326 of the unlocking transaction 1320. In a particular case, constraint set 1 and constraint set 2 are the same and both only require that the locking scripts of the outputs Vout[0] 1324 and Vout[1] 1326 be the same as the locking script of Vout[x] 1314 of the previous transaction 1310.

[0293] In a more general case, the constraints may be more than just the requirement to copy the locking script. Additionally, the sets of constraints can differ from output to output of the unlocking transaction. The constraints can be the number of outputs the unlocking transaction can have, the value of each output, and certain things required in the locking script of the unlocking transaction output.

[0294] Output constraints for the injection unlock transaction

[0295] Figure 14 A flowchart of an example of part 1400 of the locking script of the previous transaction that imposes constraints on the locking script of an unlocking transaction. This example can be executed by a stack-based verifier that processes the unlocking script of the output of the unlocking transaction, which can leave data on the stack and then process the locking script of the output of the previous transaction to perform the process. Since the processing of the unlocking script can leave data on the stack and since the unlocking script can leave, for example, the serialized content of the unlocking transaction (including details of the locking script of the unlocking transaction) on the stack, these details can be available at verification time.

[0296] In step 1402 of the above process, the verifier verifies that the unlocking script contains certain data, and the verifier can perform other verifications that do not need to be done on a per-output basis. Examples of such data can include a serialized set of unlocking transaction fields, the serialized previous transaction, a reference to the previous transaction, etc. In step 1404, the verifier checks if these constraints are met, and if not, stops at step 1406, invalidating the unlocking transaction. Otherwise, the process continues at step 1408, where the verifier determines if there are any unlocking transaction outputs to check. For the first pass, the verifier can set index i = 0, and when there are no more outputs to check, go to another processing flow at step 1410.

[0297] For each index of the output, the verifier performs steps 1412, 1414, and 1416, then increments i (step 1418) and returns to step 1408 until there are no more indexes to consider. In another variant, the verifier can loop through a set of indexes to be checked, where the set of indexes does not necessarily include all values of i and / or does not necessarily include them and in ascending order to verify them, rather than incrementing the index by 1 and verifying each output. In such a variant, step 1418 is correspondingly different, looping through the indexes i of the outputs in the particular set of indexes being checked.

[0298] In step 1412, the verifier extracts the locking script of Vout[i] of the unlocking transaction. This can be achieved using the OP_SUBSTR operation on the stack content. Next, in step 1414, the verifier determines the constraints on the locking script of Vout[i] of the unlocking transaction based on the locking script of the previous transaction output. In step 1416, the verifier then verifies these constraints. In this way, the locking script of the output of the previous transaction transferred by the input of the unlocking transaction can impose constraints on the output of this unlocking transaction.

[0299] The locking script of the output of the previous transaction constrains the output of the unlocking transaction to allow the previous transaction locking script to specify the rules regarding how the output of the unlocking transaction can be transferred. These constraints can be hardcoded in the locking script of the previous transaction output, or the constraint can be determined based on data present in the unlocking script of the input of the unlocking transaction that refers to the previous transaction output.

[0300] Figure 15 illustrates some examples of more specific steps corresponding to Figure 14 steps 1402 and 1414. An example of a verifier performing step 1402 is to perform step 1502, where the verifier determines that some portion of the data in the unlocking script (or elsewhere) in the unlocking transaction input is from a determined source. The determined source can be the serialization of the unlocking transaction or the serialization of a previous transaction. Alternatively or additionally, the verifier can perform step 1504 and perform some other verification of the unlocking transaction data details.

[0301] Regarding the specific constraints that the locking script of the output of the previous transaction can impose on the locking script of the output of the unlocking transaction, there is step 1506, where the locking script of the output Vout[i] of the unlocking transaction must be equal to the data from a certain determined source ("== " refers to the equality test). Another example is step 1508, where the locking script of the output Vout[i] of the unlocking transaction must be equal to the data hardcoded into the locking script of the output of the previous transaction. Step 1510 covers the case of imposing another constraint on the output Vout[i] of the unlocking transaction based on data from a determined source, and step 1512 covers the case of imposing another constraint on Vout[i] based on the hardcoded data of the locking script of the output of the previous transaction.

[0302] In some cases, instead of using all the data from the above sources or hardcoded, the hash of the data can be used, in which case a comparison is made between the hashes.

[0303] The data to be used can come from the previous transaction, such as from the data hardcoded into the locking script of the output of the previous transaction, or it can be data from a previous transaction of the previous transaction (or a reference to the previous transaction, two links away from the unlocking transaction) (i.e., the transaction whose one or more outputs were transferred by the previous transaction). In this way, the data used can come from any transaction in the chain from the previous transaction to its distribution transaction (such as a coinbase transaction).

[0304] Figure 16 illustrates an example of this. For Figure 14 Step 1402 in process 1400 (where verification is that the unlocking script has certain data) can perform steps 1602, 1604, 1608, 1610, and 1612 to verify that the unlocking script of the unlocking transaction has a reference to a transaction in the transaction chain.

[0305] In step 1602, the verifier extracts the transaction identifier (TxID) from the input of the unlocking transaction, and the verifier can do so if it is available in the unlocking script. The verifier can then verify in step 1604 that the unlocking script also contains a serialized copy of the previous transaction of that TxID. If not, the verifier can invalidate the transaction, but if so, in step 1608, the verifier extracts TxID from the previous transaction TxID′, and then in step 1610 verifies that the previous transaction contains a serialized copy of the transaction referenced by TxID′ or a reference thereto. This chain can continue n times, where in step 1612, the verifier verifies that the transaction referenced by TxID (n -1) ′ (n - 1 primes) contains a serialized copy of the transaction referenced by TxID n ′ (n primes).

[0306] In Figure 16 , steps 1614 and 1616 involve extracting the locking script of the transaction copy referenced by TxID n ′ and verifying the constraint that the locking script of the output Vout[i] of the unlocking transaction is equal to the extracted locking script of the transaction referenced by TxIDn′.

[0307] The constraint can be applied to a subset of the locking script of the output, rather than the entire locking script. The constraint can be determined from a subset of the data, rather than the entire data. For example, one subset may require showing "Pay-to-Public-Key-Hash", and another subset may require showing "Pay to Bob".

[0308] Assume that the locking script of the output of the unlocking transaction can consist of two parts ( <x> <y>) is represented, where <x>and <y>String concatenation operations can be used for extraction so that the constraints can be applied separately to <x>And <y>。Example is <x>constrained to <PubK A>, while <y>Is constrained to OP_CHECKSIG. In this way, the entire locking script is constrained to <PubK A>OP_CHECKSIG. Constraints derived from the data in the unlocking script can also be used.

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

[0310] The constraints can correspond to indices that reference various outputs. In one case, the constraints are repeated for each index, but in other cases, some structure can be provided. For example, the indices of the constraints can be used in conditional statements to select a set of constraints, such as "if index == 0: then constraint A, else constraint B".

[0311] If the set of indices is hard-coded, the result of the part of the script that uses the indices can be fixed. Instead of or in addition to constraints on the outputs of the unlocking transaction, there can also be constraints on the inputs of the unlocking transaction.

[0312] Input constraints for the injection unlock transaction

[0313] One use of having a locking script constrain the inputs of an unlocking transaction is to allow the locking script to encode a dependence on a transaction with specific properties (e.g., the constrained input must reference that transaction). This is different from constraining the outputs of the unlocking transaction because the outputs are variable while the inputs can be references to pre-existing immutable UTXOs on the blockchain. In other words, the outputs can be modified to match the constraints, while inputs that match these constraints must be found.

[0314] Constraints on unlocking transaction inputs can fall into two general types: (1) constraints directly on the references of the inputs (i.e., the transaction TxID field, and optionally the output pointer field), and (2) constraints on the fields of the previous transaction that the reference in the input points to.

[0315] Figure 17 Shows a previous transaction 1710 and an unlocking transaction 1720, where the previous transaction 1710 has an input Vin[y] 1712 and an output Vout[x] 1714, and the unlocking transaction 1720 has inputs Vin[0] 1722 and Vin[1] 1723 and an output Vout[0] 1724. The locking script of Vout[x] 1714 imposes a set of constraints (constraint set 1) on the input Vin[0] 1722 and a set of constraints (constraint set 2) on the input Vin[0] 1723. The constraint sets may include constraints on the unlocking script, references, or other parts of the input. The constraint sets can be the same or different, or there are more than two inputs, some of which are the same and some are different.

[0316] In part, these constraints can reference certain parts of the unlocking transaction, for example, by using the OP_SPENDINGTXINJECTION script to inject a serialized set of unlocking transaction fields as data into the unlocking script.

[0317] Figure 18 Is a flowchart of an example of part 1800 of the locking script of a previous transaction that imposes constraints on the inputs of an unlocking transaction. This example can be executed by a verifier that processes the unlocking script of the output of the unlocking transaction, which can leave data (including details of the unlocking transaction) on the stack, and then processes the locking script of the output of the previous transaction to execute the process.

[0318] In step 1802 of this process, the verifier verifies that the unlocking script contains certain data, and the verifier can perform other validations that do not need to be done on a per-output basis. In step 1804, the verifier checks if these constraints are met, and if not, stops at step 1806, invalidating the unlocking transaction. Otherwise, the process continues at step 1808, where the verifier determines if there are any unlocking transaction inputs to check. For the first pass, the verifier can set the index i = 0, and when there are no more inputs to check, goes to another processing flow at step 1810.

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

[0320] Other examples of input constraints are shown in Figure 19 by elements 1902, 1904, 1906, 1910, 1912, and 1914. Since the TxID may be a one-to-one mapping with the transaction, this means that the constraint may be that a specific transaction must be referenced in the input. The transaction on which the locking script depends can be created first, allowing the locking script to use its own TxID in the constraints on the input of the unlocking transaction.

[0321] Constraints can be placed on the fields of the previous transaction corresponding to the reference in the input. Before placing constraints on the fields of the previous transaction, the corresponding previous transaction can be caused to be injected by using the TxID in the input. The constraint can reference an input different from the input that is unlocking the output of the previous transaction, which previous transaction has the locking script imposing the constraint.

[0322] Figure 20 Examples of constraints in the context of steps 1802 and 1814 in process 1800 are shown in Figure 18 In Figure 20 steps 2002, 2004, 2014, and 2016 can be performed. In step 2002, the verifier extracts the transaction identifier (TxID) from the input of the unlocking transaction, and the verifier can do so if it is available in the unlocking script. The verifier can then verify in step 2004 that the unlocking script also contains a serialized copy of the previous transaction of that TxID. In step 1614, the verifier extracts a set of one or more fields from the previous transaction, and in step 1616 verifies some constraint on the set of the extracted fields.

[0323] Figure 21 Interlocking script constraints are shown. As shown, the input of unlock transaction (unlock transaction 1) 2106 can reference the previous transaction (previous transaction 1) 2102 and the previous transaction 2104 (previous transaction 2). In particular, the input Vin[0] of unlock transaction 1 points to Vout[0] of previous transaction 1, as indicated by arrow 2110. Thus, if unlock transaction 1 is valid, Vout[0] of previous transaction 1 can be unlocked. Similarly, the input Vin[1] of unlock transaction 1 points to the output[0] of previous transaction 2, as indicated by arrow 2112. Such references may be normal references of an unlock transaction with multiple inputs that reference multiple previous transactions.

[0324] To reference a previous transaction, these transactions should already exist and be immutable before the unlock transaction is created. Nevertheless, the previous transactions can apply mutually dependent locking script constraints on the unlock transaction. By constraining the set of inputs of the unlock transaction, mutually dependent locking scripts can be achieved, which can provide concurrency in the environment of a trustless deterministic state machine.

[0325] The locking script 2120 of the output Vout[0] of previous transaction 1 has a constraint on the input Vin[1] of unlock transaction 1, which requires that the pointer 2122 of the input (e.g., its reference to the previous transaction and the output of the previous transaction) is a reference to previous transaction 2 and Vout[0] of previous transaction 2. The locking script 2124 of the output Vout[0] of previous transaction 2 has a constraint on the input Vin[0] of unlock transaction 1, which requires that the pointer 2126 of the input (e.g., its reference to the previous transaction and the output of the previous transaction) is a reference to previous transaction 1 and Vout[0] of previous transaction 1.

[0326] Since the TxID of a transaction is unknown before the transaction is completed, the transaction locking script cannot directly specify the TxID that the unlock transaction unlock script must reference, but this can basically be achieved by the locking script extracting the pointer of the input (including the TxID of the previous transaction with the locking script), injecting the fields of the previous transaction using the TxID, and verifying whether a certain field of the previous transaction is equal to what it should be. In other words, if the previous transaction has a field set to a certain value, and the locking script of the previous transaction obtains the TxID from the unlock transaction input, injects any transaction referenced by the TxID, checks the field set to the specific value and the field not set to the specific value, then the unlock transaction input must point to a different previous transaction. Thus, by checking the specific value, the locking script of the previous transaction output can determine whether the unlock transaction input references the previous transaction output.

[0327] In this way, the previous transaction 1 indicates that its first output can only be transferred by a transaction that unlocks the first output of a specific transaction (the previous transaction 2), and the previous transaction 2 indicates that its first output can only be transferred by a transaction that unlocks the first output of the previous transaction 1.

[0328] Mutually dependent locking scripts allow multiple smart contracts to place conditions on each other. For example, smart contract 1 might be "Alice agrees to contribute 1 BTC to Carol, but only if Bob contributes 2 BTC to Carol", and smart contract 2 might be "Bob agrees to contribute 2 BTC to Carol, provided that Alice agrees to contribute 1 BTC to Carol". For this to be effective, the unlocking transaction must unlock both smart contracts.

[0329] As described above, the locking script can encode dependencies into transactions with certain properties, and these properties can include the fields of the transaction. This means that the locking script may depend on a transaction with a specific locking script.

[0330] For example, in Figure 21 the illustration of, the locking script #1 (of Vout[0] of the previous transaction 1) constrains Vin[1] of transaction 1 to reference the locking script 2124 (of Vout[0] of the previous transaction 2), and the locking script #3 2124 constrains Vout[0] of transaction 1 to reference the locking script #1 of Vout[0] of the previous transaction 1. In this article, this can be called a locking script that encodes the dependency on another locking script.

[0331] Implementing mutually dependent locking scripts can create a causal race condition where the first locking script encodes a dependency on the second locking script, while the second locking script encodes a dependency on the first locking script, because one of the previous transaction 1 and the previous transaction 2 may pre-exist the other. If locking script A hard-codes a dependency onto locking script B, then locking script B must be known and fixed, which makes it impossible for locking script B to hard-code a dependency on the unknown locking script A. This can be solved by having a determinable dependency in at least one of the locking scripts.

[0332] As an example, locking script A depends on locking script X and will provide locking script X in unlocking script A, and locking script B depends on locking script Y that will be provided in unlocking script B. When the unlocking transaction is created, both locking script A and locking script B are known, enabling unlocking script A of the unlocking transaction to include locking script B as its data, and enabling unlocking script B of the unlocking transaction to include locking script A as its data.

[0333] In some variations, for an unlock transaction input to be verified, its unlock script must reference previous transaction 1 and previous transaction 2. In other variations, it is sufficient for the unlock script to reference any two (or more) previous transactions that have the same lock script as previous transaction 1.

[0334] In some variations, the requirement may be exclusive, rather than mandating that the unlock script reference a specific previous transaction or a set of multiple previous transactions, as the requirement can be that the unlock script does not reference a specific previous transaction or a set of multiple previous transactions. Combinations of these variations are also possible, effectively implementing Boolean logic on the previously referenced transactions. For example, the requirement may be that for an unlock transaction input to be verified, its unlock script must reference previous transaction 1 and previous transaction 2, not reference previous transaction 1, and must reference previous transaction B or previous transaction C. Other logical expressions are also possible.

[0335] State machine

[0336] Using the techniques described above, a state machine can be implemented using blockchain transactions, where the transactions have states and are encoded using a state machine structure (e.g., via a transition matrix and permitted next states). An unlock transaction can unlock the output of such a blockchain transaction, effectively causing a state transition of the state machine.

[0337] Figure 22 An example 2200 of a state machine implemented using blockchain transactions is shown. Specifically, Figure 22 A state machine that transitions from a first state to a second state using blockchain transactions is depicted. In some examples, the state transition of the state machine is interpreted as determining the next state given (1) the current state, (2) one or more inputs 2226, and (3) a set of state rules 2206. Figure 22 Example 2200 shows a previous transaction 2202 with 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 accept an input 2226 from a determined source. In combination with the first state 2228A, the input 2226 can be used to reference the set of state rules 2206 to determine a second state 2228B embedded in the parameters of the unlock transaction 2204.

[0338] In an embodiment, the set of state rules 2206 includes a state transaction matrix, which can be represented by the constraints imposed by the lock script on the unlock transaction 2204. In such an embodiment, the constraints can be parameterized by the current state and the input from which the next state is determined. The constraints can include checks to ensure that the unlock transaction 2204 includes an output that includes a next state value in a specific field.

[0339] In an embodiment, the current state is represented as a parameter embedded in a transaction, such as part of a locking script for an output of the transaction, and the unlocking transaction 2204 can have a next state value that is also embedded in the unlocking transaction 2204. The next state value can be the current state relative to a set of field values of the unlocking transaction 2204, which, as described above, can be accessible when the unlocking transaction 2204 is created.

[0340] In some embodiments, among the parameters determined when creating the unlocking transaction 2204, at least one input is provided as external data. For security reasons, these parameters come from a determined source. This can provide a determined state transition. Finally, by using a script of a self-replicating locking script, an embodiment of a trustless, deterministic state machine can be created. By further allowing different locking scripts to be imposed on different transaction inputs and outputs of a transaction, a concurrent trustless, deterministic state machine can be implemented.

[0341] Figure 23 This is illustrated. In this example, the trustless deterministic state machine system 2300 can include a previous transaction 2302 in a first state 2328A ("S1") in 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 can be encoded in a locking script for an output of the previous transaction 2302. The current state 2328A can be embedded in a lock time field or can be embedded in the locking script. The next state (S2 2328B in this example) is encoded in a locking script for an output of the unlocking transaction that unlocks the output of the previous transaction to effect the state transition.

[0342] As can be seen in the example 2300, the unlocking transaction 2304 takes the input 2326 in its unlocking script and the first state 2328A ("S1") embedded in the set of field values of the previous transaction 2302 as inputs, and determines an appropriate second state 2328B ("S2") from the set of state rules 2306. It can also be seen from the example 2300 that the state transition matrix now provides new states 2330B ("S4" or "S5") that are possible for the next state transition from the second state 2328B. Note that the set of state rules 2306 can be encoded as a switch statement or other conditional statement (e.g., "if-then-else") parameterized by the current state and one or more input parameters. The current state S2 2328B can be embedded in a lock time field or can be embedded in the locking script. The next state (S2 2328B in this example) is encoded in a locking script for an output of the unlocking transaction that unlocks the output of the previous transaction to effect the state transition.

[0343] In an embodiment, in a self-replicating locking script, each possible state is represented in 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 locking script of the transaction output is copied to each unlocking transaction that attempts to transfer control of the digital asset to the next transaction, which must be linked to the current transaction output. This process can be repeated until a termination condition is met. Since the input is not fixed and may be indeterminate data, the state of the state machine can be changed based on a particular external input. Thus, the indeterminate data provides an input that may affect the next state.

[0344] In an illustrative example, Alice lends some money to Bob, and Bob agrees to pay Alice back. As described in the present invention, a trustless, deterministic state machine can be implemented as a smart contract to represent the payment made by Bob to Alice. For example, the smart contract can be constructed such that Bob pays Alice every month for the next three months, and if the payment is missed, Bob's debt enters the debt collection phase. Thus, as long as Bob makes the monthly payment, the current state remains in the repayment state. However, if an external entity provides an input indicating that Bob has missed a payment, the state transitions to the missed payment state. In the unpaid state, Alice can release the transaction and hand it over to a debt collector, and thus the trustless deterministic state machine switches to the debt collection state. In the debt collection state, the debt collector will collect the debt from Bob. Variations of the scripts described herein can be used to create such a smart contract.

[0345] In another example, Alice is a very charitable person and donates one unit of digital assets every month. Her rule may be that anyone can apply for the digital assets, but only one unit can be applied for each month. Alice creates a smart contract in the manner described in the present invention and seeds it with an initial pool of 3 units of digital assets. Alice can construct a script that allows any entity to obtain 1 unit of digital assets per month. The remaining portion of the digital assets is copied to subsequent smart contracts.

[0346] Figure 24 An unlocking script and a locking script of an exemplary trustless deterministic state machine of the present invention are shown.

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

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

[0349] In step 2502, the system receives an unlocking transaction. The system first runs the unlocking script of the unlocking transaction input, which causes the serialized previous transaction and the input embedded in the locking script to be placed on the stack. These inputs may be retrieved in 2512. In 2504, the system executing process 2500 determines whether a termination condition is met. In an embodiment, the termination condition is a condition that, once met, causes the end of the state machine transition. If the termination condition is met, the system executing process 2500 proceeds to 2506, and thus the self-replication and / or propagation of the trustless deterministic state machine stops.

[0350] In step 2508, the system verifies that the previous transaction output locking script matches the unlocking transaction output locking script. If the locking scripts do not match, the verification fails and the unlocking transaction may not be verifiable. Otherwise, if the locking scripts match, then in 2510, the system extracts the current state of 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 executing the locking script. Then, in 2514, the system applies the 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 other state-related data, if applicable) is embedded in the unlocking transaction. The system can also apply any remaining constraints specified in the locking script. After successfully completing the operations from 2502 to 2516, the process ends at 2518, and thus the system executing the process can consider the unlocking transaction valid. Note that one or more of the operations performed in steps 2502 to 2518 can be performed in various orders and combinations, including in parallel.

[0351] Note that in the context of describing the disclosed embodiments, unless otherwise specified, an expression using executable instructions (also referred to as code, application, agent, etc.) to perform an operation that is not typically performed alone (e.g., data transfer, calculation, etc.) indicates that the instruction is being executed by a machine so that the machine performs the specified operation.

[0352] State machine as a blockchain transaction

[0353] Using the above techniques and devices, a state machine can be implemented using blockchain transactions. The state machine can be operated by changing the state along a state transition matrix from one state to another. Some state diagrams can be very complex and have multiple paths. In such cases, some of the calculations performed by the state machine can be carried out simultaneously with other calculations. As described below, the state machine can be operated using blockchain transactions and, in part, simultaneously.

[0354] As described below, a trustless deterministic state machine can be implemented using the locking script and unlocking script of a blockchain transaction. The locking script contains constraints that can be imposed on the unlocking script, and thus it can require that certain data be injected into the unlocking script of the unlocking transaction input, such as serialized fields of the unlocking transaction itself, serialized fields of the previous transaction containing the locking script being executed, current state values, inputs from a determined source (optional), and a state transition matrix defining a set of flow conditions and operations of the state machine, and specify how to calculate the next state from the current state and other inputs. One locking script constraint for the unlocking transaction can be that the unlocking transaction must replicate the locking script in one of its outputs, thus propagating the state machine.

[0355] Figure 26 A state machine using a state transition matrix 2600 with certain characteristics is shown. State S1 is highlighted to indicate the current state. The state machine can transition to any state along state transitions (as indicated by the arrows). In the state transition matrix, there may be possible transitions along S1 - S2 - S3 - S4 - S8 - S12, but a transition from state S1 may also require being in state S5. Similarly, state S5 transitions to S6 and S9. The transition from state S9 to state S10 can be conditional or blocked because the state transition may not occur until a transition from state S6 to state S7 occurs simultaneously. The transition to state S8 can occur as a merger of state S4 and state S7.

[0356] Each of these states can be entered by the state machine represented by a blockchain transaction output, and each transition is handled by a single path of the transaction output. When the unlocking transaction input unlocks the previous transaction output, the state transition occurs (as Figure 22 or Figure 23 shown). However, using the inputs and outputs of blockchain transactions, parallel processing of states can be achieved. This can be useful when a smart contract needs to be executed in multiple concurrent steps. During the contract process, tasks can sometimes be executed simultaneously during the contract process. For example, a contract for building a house may have different completion stages for tiling work and different completion stages for landscaping, which may be executable in parallel. By allowing concurrency in smart contracts, different segments of the contract can be executed independently of each other asynchronously.

[0357] Figure 26 Many requirements for such processing are shown. One requirement is the creation of multiple paths from one state. This could be a fork of a smart contract. Suppose the smart contract starts at S1. A fork of the smart contract may create two state machines, one in state S2 and one in state S5. Another requirement may be the cloning of a smart contract so that two identical state machines run in parallel, each in the same state. For example, a smart contract may require multiple instances of the S2 - S3 - S4 steps. This could also be a cloning of a smart contract, which is a special case of a fork where two or more new transaction outputs have the same state.

[0358] Another useful feature is the generation of new contracts. For example, the smart contract represented by Figure 26 the state transition matrix 2600 could be such that in state S3, a party to the smart contract will create a separate contract that can be associated with the smart contract but may not be part of the smart contract and / or may be created after the smart contract is created. This can be referred to as spawning in this article. The new contract can be different from the one initially provided Figure 26 The original smart contract of the state transition diagram.

[0359] Merging is the combination of two state machines or two smart contracts, as in the case of states S4 and S7. As described below, different paths can be executed concurrently, such as S2 - S3 - S4 and S5 - S6 - S7. Using these elements, a concurrent trustless deterministic state machine can be easily implemented in a blockchain environment.

[0360] Figure 27 An example of a transaction with one input Vin[0] and two outputs Vout[0] and Vout[1] is shown. By unlocking the output of this transaction, two independent transactions will be recorded in the blockchain ledger, and the creators of these transactions will be compensated with a certain value (not shown) provided to them by this transaction. As shown, the locking script of the previous transaction output (pointed to by Vin[0]) requires that the unlocking transaction unlocking this output contains states S2 and S5. To unlock the output of the unlocking transaction containing state S2 ( Figure 27 Vout[0] in), the future unlocking transaction will be constrained to include the next state based on the current state S2. The same is true for state S5.

[0361] In this way, transaction outputs can have states and impose constraints on the states that unlocking transactions can be in. Thus, blockchain transactions can be processed according to the Figure 26 state diagram shown, and the unlocking of transaction outputs corresponds to state transitions in the state diagram. To prevent someone from creating a transaction with multiple inputs and unlocking the two outputs of the shown transaction, the locking script can check for this and prohibit it. The rules for generating valid transactions (e.g., how many outputs are required) can be hard - coded as values in the smart contract or as parameters that can be provided after the smart contract is created.

[0362] Using blockchain transaction forks and cloning smart contracts

[0363] Forking can be used when a state needs to transition to two or more (not necessarily unique) next states simultaneously. Sometimes, smart contracts can be processed without all possible concurrency, but in cases of concurrency, forking can initiate it. As described above, the locking script of the output of a smart contract transaction on the blockchain ledger can "impose" requirements on the inputs of the unlocking transaction and / or the locking script of the output of the unlocking transaction on the blockchain ledger. Cloning may be a specific type of forking where the next set of states may all be the same state. In terms of unlocking transactions, multiple outputs can be constrained to replicate the transition matrix and embed their respective next states.

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

[0365] Since a given unlocking transaction may have multiple outputs, some of which may be irrelevant to the state machine or related to multiple unrelated state machines, it may be more practical to embed the next state in the locking script of the transaction rather than in a common field (such as the lock time field) for all outputs. A subset of the output locking scripts that are constrained was described above.

[0366] Figure 28 Illustrated is how the script is related to the forking operation. As shown, the state machine 2810 is implemented using the previous transaction 2820 and the unlocking transaction 2830. The locking script of the previous transaction 2820 constrains the unlocking transaction 2830 to have at least two outputs, each output requiring the subsequent unlocking transaction to have an output in a specified state (and be a separate transaction). This can allow those states S2, S3 to be executed independently and possibly simultaneously.

[0367] With a state machine, subtasks can become useful for enabling faster concurrent smart contracts. To handle subtasks, multiple states can be used, and since a state machine can typically only be in a single state at a time, concurrency can be provided by having independent transaction threads. The state machine can fork by creating multiple transaction locking scripts. Based on the current state from the output of the previous transaction, the unlocking transaction can be constrained to have two or more outputs with locking scripts (as Figure 28 shown). To prevent the fork from becoming irredeemable and stopping prematurely, each output value should be checked to ensure there is sufficient funds to continue the state machine.

[0368] As shown by the dashed arrow, the input Vin[0] of the unlocking transaction 2830 points to the previous transaction 2820 and the output Vout[0] of that transaction. The locking script of Vout[0] includes the current state ("S1"), the transition matrix of the state machine, and constrains Vout[x] of the unlocking transaction 2830 to be in the next state ("S3") and Vout[y] of the unlocking transaction 2830 to be in another next state ("S2"), each state also being constrained to carry the state transition matrix and possibly other constraints.

[0369] The locking script of the previous transaction output can include the concatenation of <current state><transition matrix><other scripts>, while the locking script of the output of the unlocking transaction can include the concatenation of <next state><transition matrix><other scripts>. Only a subset of the locking script can be copied instead of the entire locking script, while another subset may be constrained to include the state.

[0370] The state of the state machine can be stored in a transaction field (such as the lock time field) that may not be used for other purposes, rather than in the locking script. In fact, different unused transaction fields can be used. This applies to a single state and also to cases where multiple states need to be stored, although the latter may be more complex.

[0371] Figure 29 Example pseudocode that can be executed to implement a fork or clone process is shown. The pseudocode can be implemented using the opcode described herein. The pseudocode can be executed by a processor of a blockchain node that creates and / or validates transactions. In some embodiments, a part of the script comes from the unlocking script and a part of the script comes from the locking script.

[0372] In Figure 29 the pseudocode, the previous transaction, the unlocking transaction, and optional inputs are injected so that the locking script can access them. Then, termination conditions may be checked. If the smart contract does not terminate, the processor extracts the previous transaction locking script and the previous transaction current state, which can be done using the techniques described herein. Then, the processor loops through the outputs of the unlocking transaction, and for each unlocking transaction output, extracts its locking script and checks the transition matrix in the previous transaction locking script to determine if it matches the transition matrix in the locking script of the unlocking transaction output being processed. If they do not match, the processor treats it as a script failure, stops, and does not verify the unlocking transaction. If they match, the processor determines the next state of the state machine based on the extracted current state, state transition matrix (optionally an input), and output index value. Then, the processor checks the determined next state against the next state in the unlocking transaction output being processed. If they do not match, the processor treats it as a script failure, stops, and does not verify the unlocking transaction. If there are other optional constraints to check, these constraints can be checked at this time. If all constraints are met, the script passes.

[0373] Worker production smart contract

[0374] In the previous section, the ability to fork and clone smart contracts was described. This section details the ability to force a new smart contract to appear in the unlocking transaction, which can be another completely different state machine or a completely different type of smart contract that may not be a state machine.

[0375] Figure 30 Illustrates an example of constraints for a new smart contract that enforces it as a state machine. As shown, the locking script of the output of the previous transaction provides constraints on the output of the unlocking transaction, such that the locking script of the output of the unlocking transaction must be equal to the desired new smart contract script, or the hash of the locking script must be equal to the hash of the desired new smart contract script. The new smart contract script or hash can be hardcoded in the locking script of the output of the previous transaction, or securely provided as a parameter through the unlocking script of the input of the unlocking transaction. Multiple new smart contracts in the unlocking transaction output can be enforced by having the corresponding constraints as described above for each new smart contract in the locking script.

[0376] As described above, a new smart contract that can be a state machine is created. The new smart contract 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 independently (e.g., check the new state and then the transition matrix values), or together.

[0377] Although not shown in Figure 30 a new smart contract may not be a state machine. In this case, a next state value may or may not be required, but the equality check of the script or its hash can be used to verify the new smart contract.

[0378] Using the new smart contract from the current state transition in the previous transaction and the output of the unlocking transaction, a new smart contract can be generated. In the example shown, the first set of outputs of the unlocking transaction is constrained to replicate the state transition matrix and embed the next (multiple) state, and the second set of outputs is constrained to contain the new smart contract. The output of the unlocking transaction can be constrained to contain a new locking script, and by using multiple indexes, different constraints can be applied to different outputs. The new smart contract set can be hardcoded in the transition matrix, or provided as part of the input.

[0379] From the perspective of a state machine, the state machine can instantiate a new different state machine to execute concurrently with the calling state machine. To apply this approach to a state machine, the locking script for this operation may be similar to the locking script for a fork / clone operation, but instead of checking equality in the locking script of each new state machine instance, the existence of the new smart contract can be checked. The equality check can be performed on a series of different values, including the serialized set of transaction fields of the transaction, the locking script bytecode, or the hash of these values.

[0380] Figure 30 Shows the generation of a new smart contract. As shown, the state machine 3010 is implemented using the previous transaction 3020 and the unlocking transaction 3030. The locking script of the output Vout[0] of the previous transaction 3020 constrains the unlocking transaction 3030 to have at least two outputs (Vout[x] and Vout[y]), and each output requires the subsequent unlocking transaction to have an output in a specified state (and is a separate transaction). Specifically, as shown, in order for the input Vin[0] of the unlocking transaction 3030 to unlock Vout[0] of the previous transaction 3020, the unlocking transaction 3030 can be constrained such that Vout[x] has a transformation matrix and is in state S4, while also constraining Vout[y] to have a new smart contract.

[0381] Using this method, the new smart contract can be processed in parallel with the state machine. Although not explicitly shown, the new smart contract can be a second state machine. As described above, the new smart contract itself does not need to be a state machine, and in this case, the resulting smart contract may not have a state value field.

[0382] As Figure 30 shown by the dashed arrow in, the input Vin[0] of the unlocking transaction 3030 points to the previous transaction 3020 and the output Vout[0] of that transaction. This can be in the form of the TxID of the previous transaction 3020 and an integer value set to "0" to point to the output Vout[0]. The locking script of Vout[0] includes the current state ("S3"), the transformation matrix of the state machine, and constrains Vout[x] of the unlocking transaction 3030 to a state machine in the next state ("S4"), constrains Vout[y] of the unlocking transaction 3030 to a new smart contract (abbreviated as "NSC"), and possibly other constraints.

[0383] As an example, the pseudocode for the worker generation process and an example of the process that forces the new smart contract to appear in the unlocking transaction can be as Figure 31 shown.

[0384] Merged smart contract

[0385] In cases where two or more states need to be merged into the same next state, the merging or joining of states can be used. In some cases, concurrently running state machines may find themselves in the same state, but they will not be merged if the smart contract does not require it. For example, using Figure 26 the state diagram of, S4 and S7 may each transition to S8 and remain as two separate transactions.

[0386] Figure 32 Shows the merge operation of the state machine 3210. In this case, the unlock transaction 3230 (input Vin[0] and Vin[1] and output Vout[x]) unlocks the outputs Vout[0] of the previous transaction 3220 and the previous transaction 3222. Using these techniques, a smart contract can branch out by instantiating a new instance of itself or instantiating a different smart contract, and multiple smart contracts (the same or different) can be merged through their corresponding state machines to form a single smart contract.

[0387] Each merge unlock transaction can have a lock script. This lock script continues to execute a single smart contract. This can be one of the smart contracts being merged or an entirely new smart contract. In any case, many checks can be performed. Each smart contract can be checked as a valid input to the unlock transaction. This can be performed by using the verification of the previous transaction.

[0388] As Figure 32 shown, Vin[0] points to the previous transaction 3220 and its output Vout[0], while Vin[1] points to the previous transaction 3222 and its output Vout[0]. The lock scripts of the two 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 implemented by checking the new smart contract as the output of the unlock transaction through the lock script 3222 of the previous transaction.

[0389] To implement this using concurrent state machines, a transaction can use multiple inputs, with one input for each state machine that needs to be joined. In the state machine transition matrix, constraints can be added to check the states of all the joined independent state machines. If one of the joined state machines is not in a state that allows convergence, the transaction may be rejected. To ensure the join operation, constraints can be added to the state machine based on the states in the unlock transaction to check for the existence of two unlock scripts. Each script can be checked to ensure that it is in the correct state required for the transition. As explained elsewhere in this document, mutually dependent lock constraints can also be used.

[0390] Figure 33 Shows a pseudocode sequence that serves as an example of the process of merging smart contracts in an unlock transaction with weak dependencies. For the merge, a transition occurs from a set of current states (not necessarily unique states) to a shared set of next states. In terms of the unlock transaction, its set of inputs can unlock a set of lock scripts that share the same output and must copy the transition matrix and embed the constraints for the same next state. For weak dependencies, there may be multiple state machines that happen to have the same next state for the same output.

[0391] According to Figure 32 and Figure 33 Merges can occur with weak dependencies. The locking scripts can include other constraints such as mutual dependencies, forks, generating new smart contracts, etc. As an example of weak dependencies, in the case where a merge happens to occur, locking script 1 can be a fork from state A to states X and Y, while locking script 2 can be a normal transition from state B to state X. These two locking scripts happen to constrain the output of the unlocking transaction to include state X

[0392] In Figure 33 the pseudocode sequence, the processor that processes the script according to this pseudocode sequence can inject the previous transaction, the unlocking transaction, and optionally some input data, and check the termination condition before proceeding. Then the processor extracts the previous transaction locking script and the unlocking transaction locking script. Next, the processor can check whether the transition matrix in the previous transaction locking script is equal to the transition matrix in the unlocking transaction locking script, and if not, abort. The processor extracts the current state value of the previous transaction from it, and from this current state value, as well as from the transition matrix and the input (if used), determines the next state, and checks the next state to determine whether it matches the next state in the unlocking transaction locking script. Optionally, other constraints can be checked here.

[0393] Figure 34 The pseudocode sequence is shown as an example of the process of merging smart contracts in an unlocking transaction with explicit dependencies. For explicit dependencies, there may be multiple state machines, and it may not be sufficient that they happen to have the same next state for the same output, but in addition, they may be specific different state machines. According to Figure 32 and Figure 34 the merge can occur with explicit dependencies. Under strong constraints, the unlocking transaction may need to point to two or more specific merge state machines.

[0394] In Figure 34 the pseudocode sequence, the processor that processes the script according to this pseudocode sequence can inject the previous transaction, the unlocking transaction, and optionally some input data, and check the termination condition before proceeding. Then the processor extracts the unlocking transaction locking script. Next, the processor can loop through the set of input indices, extract their corresponding previous transaction locking scripts, and check whether the transition matrix in the corresponding previous transaction locking script is equal to the transition matrix in the unlocking transaction locking script, and if not, abort. The processor extracts the current state value of the previous transaction from it and appends it to the current state list, and then repeats for the other inputs. Based on the current state, as well as the transition matrix and the input (if used), the processor determines the next state and checks the next state to determine whether it matches the next state in the unlocking transaction locking script. Optionally, other constraints can be checked here.

[0395] Parallel smart contract / barrier

[0396] As described above, two or more smart contracts can be combined into one smart contract with weak or strong constraints. It may also be useful to have two or more smart contracts that can be executed in parallel. This may not just be concurrent processing, as the constraint may be that two concurrent paths must pass through an unlocking transaction. This can also be used for a "barrier" in a concurrent state machine, where a particular transition is not allowed to occur until another transition occurs elsewhere in the state machine.

[0397] Figure 35 A parallel processing operation is shown. In this case, the unlocking transaction 3530 has two inputs (Vin[0], Vin[1]), one input for each of the previous transactions 3520 and 3530, and two outputs (Vout[x], Vout[y]), each output for continuing a separate smart contract. The unlocking transaction 3530 contains an unlocking script that interprets the script containing each of the previous transactions of the smart contract. Additionally, the locking script for each smart contract may be required to continue execution. With parallel smart contracts, each contract cannot transition independently, but rather all contracts (as defined in the locking script) need to occur simultaneously.

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

[0399] An unlocking transaction can be created to facilitate this functionality, which includes multiple inputs and outputs. Each state machine required in the barrier (either in the transition or involved in the constraint) can be included in its own unlocking script. For each state machine undergoing a transition, a locking script can be used. In Figure 26 the example shown, the transition from state S9 to S10 is allowed, but only if the transition from S6 to S7 occurs simultaneously. To this end, there are two unlocking scripts in the unlocking transaction, one for the state machine in state S6 and one for the state machine in state S9. The unlocking transaction has two locking scripts, one for the state machine still in S7 and one for the state machine now in S10.

[0400] Figure 36 is a pseudocode sequence that serves as an example of using a barrier in a parallel state machine that requires parallel transaction input / output. In this example, each previous transaction is checked according to the script of the pseudocode sequence to see if it has the same locking script as in the unlocking transaction. In this example, a locking script is set to match the first previous transaction, and so on. Next, the current state is extracted from the two previous transactions according to the script of the pseudocode sequence, the inputs of the two state machines are read, and any barriers set for the two state transitions are checked.

[0401] Back to Figure 35 , various dependencies are shown using 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 (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 (previous transaction 3522). This may just be two dependencies, one being the dependency that Vin[0] must reference Vout[0] of transaction 3520, and the other being the dependency that Vin[1] must reference Vout[0] of transaction 3522.

[0402] The locking script of Vout[0] of the previous transaction 3520 imposes Dependency #5, which requires that Vout[x] has state = S8 and has a transition matrix for state machine 1, and imposes Dependency #6, which requires that Vout[y] has state = S8 and has a transition matrix for state machine 2. The locking script of Vout[0] of the previous transaction 3522 imposes Dependencies #7 and #8 in a similar manner. In some examples, it may be a constraint of some other form of smart contract rather than a constraint of a state machine. Since the two (or more) previous transaction outputs constrain the two (or more) unlocking transaction outputs, a parallel smart contract can be provided.

[0403] A barrier may be different from a merge. A barrier can be a situation where the transitions from a set of current states (not necessarily the only states) are constrained to occur simultaneously. In terms of an unlocking transaction, its set of inputs can unlock a set of mutually dependent locking scripts, all of which can apply their respective constraints to the set of outputs. The mutually dependent locking scripts may be a requirement as well as a shared set of next states, although it may or may not be necessary. The mutually dependent locking scripts can be embedded in the transition matrix such that certain transitions require this mutual dependence.

[0404] Figure 37 A state diagram showing use cases for a barrier / parallel smart contract is presented. Suppose Alice and Bob are learning to dance and taking dance classes. As a way to keep track of the progress of dance students, their progress can be recorded using a state machine. First, there may be a state machine between levels that contains the states regarding the overall dance ability of their various dance types. This is reflected in states S1, S3, S5, and finally S6. The states of these levels develop in sequence until the student reaches the highest level supported by the dance club. To move to the next level (e.g., from S1 to S3), the student may need to learn several dance types. Smaller embedded state machines (e.g., S2 and S4) can be used to monitor each dance type. In this use case, the following operations can exist:

[0405] 1) Fork or clone - This can be used at point S1 and point S5, indicating the start of a new level, from which there can be a fork into multiple state machines, one for each dance type.

[0406] 2) Worker generation - This may be used at some point when a particular dance type requires more classes or a different assessment compared to the other dance types provided.

[0407] 3) Merge - This process can be used at point S3 and point S6 when the student reaches a new level. For the new level, each student needs to be evaluated in the final state S4 of the embedded dance state machine.

[0408] 4) Parallel transaction / barrier - This can be used to constrain state transitions between one state machine and another. In the case of this use case, we can assume that the transition between S2 and S4 needs to occur simultaneously because you cannot dance a single type of dance in a single class.

[0409] Therefore, the specification and the drawings should be regarded as illustrative rather than restrictive. However, it is obvious that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims. Similarly, other variations are within the scope of the invention. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, the specific embodiments shown in the drawings have been described in detail above. However, it should be understood that it is not intended to limit the invention to one or more specific forms disclosed, but rather the aim is to cover all modifications, alternative constructions, and equivalents falling within the scope of the invention as defined by the appended claims.

[0410] Unless otherwise specified herein or clearly contradicted by the context, in the context of describing the disclosed embodiments (particularly in the context of the following claims), the use of the terms "a", "an", "the", and similar referents should be understood to cover both the singular and the plural. Unless otherwise specified, the terms "comprising", "having", "including", and "containing" should be understood as open-ended terms (i.e., meaning "including but not limited to"). The term "connected", without modification, refers to a physical connection and should be understood to include, in whole or in part, being incorporated in, connected to, or joined together, even if something intervenes. Unless otherwise specified, references to numerical ranges in this disclosure are merely intended to be used as a shorthand method for referring separately to each individual numerical value falling within the range, and each individual numerical value is incorporated into the specification as if it were separately recited. Unless otherwise specified or contradicted by the context, the use of the term "set" (e.g., "a set of items") or "subset" should be understood to include a non-empty set of one or more members. Further, unless otherwise specified or contradicted by the context, the term "subset" of a corresponding set does not necessarily denote a proper subset of the corresponding set, but the subset and the corresponding set may be equal.

[0411] Unless otherwise expressly specified or clearly contradicted by the context, connective language such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, or C" is understood, in context, as usually being used to mean that an item, term, etc., can be A or B or C, or any non-empty subset of the set A and B and C. For example, in an illustrative example of a set having three members, the connective phrases "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, B}, {A, C}, {B, C}, {A, B, C}. Thus, such connective language does not generally imply that a particular embodiment requires the presence of at least one of A, at least one of B, and at least one of C.

[0412] Unless otherwise specified or clearly contradicted by the context, the operations of the process may be performed in any suitable order. The process (or variations and / or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executed jointly on one or more processors. The code may be stored, for example, in the form of a computer program on a computer-readable storage medium, the computer program including a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory.

[0413] Unless otherwise specified, any and all uses of examples or exemplary language (e.g., "such as") provided are only intended to better illustrate embodiments of the present invention and do not limit the scope of the present invention. No language in the specification should be construed as indicating that any non-claimed element is essential for practicing the present invention.

[0414] Embodiments of the present invention are described, including the best mode known to the inventors for practicing the present invention. Variations of these embodiments will become apparent to those of ordinary skill in the art upon reading the foregoing specification. The inventors expect skilled artisans to appropriately employ such variations, and the inventors intend to practice embodiments of the present invention in a manner different from that specifically described. Accordingly, the scope of the present invention includes all modifications and equivalents of the subject matter recited in the appended claims as permitted by applicable law. In addition, unless otherwise specified or clearly contradicted by the context, any combination of the above elements in all possible variations thereof is included within the scope of the present invention.

[0415] All references cited (including publications, patent applications, and patents) are incorporated herein by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in full.

[0416] It should be noted that the above embodiments illustrate rather than limit the present invention. Without departing from the scope of the present invention as defined by the appended claims, those skilled in the art will be able to design many alternative embodiments. In the claims, any reference signs in parentheses shall not be construed as limiting the claims. The words "comprising", "comprises", etc. do not exclude the presence of other elements and steps as a whole, even though these elements and steps are not listed in any claim or specification. In this specification, "comprises" means "includes or consists of", and "comprising" means "including or consisting of". The singular reference to an element does not exclude the plural reference to these elements, and vice versa. The present invention can be implemented by means of hardware including several different elements, as well as by means of a suitably programmed computer. In the apparatus claims listing several devices, several of these devices can be embodied by the same component of the hardware. It is an established fact that listing certain methods in mutually different dependent claims does not mean that the combination of these methods cannot achieve beneficial effects.< / y> < / x> < / y> < / x> < / y> < / x> < / y> < / x> < / sighashtype> < / k> < / k> < / m>

Claims

1. A computer-implemented method, comprising: Determining an unlocking transaction constraint for constraining an input of an unlocking transaction, the constraint being (1) imposed on a reference of the input of the unlocking transaction or (2) imposed on a portion of a previous transaction pointed to by the reference; Creating a redeemable transaction, which is the previous transaction, the redeemable transaction comprising: A transaction output, the transaction output including a redeemable amount, and A transaction locking script, the transaction locking script including the unlocking transaction constraint; and verifying the redeemable transaction at a node of a blockchain network; Wherein unlocking the redeemable amount depends on satisfaction of the execution of the unlocking transaction constraint, the execution being performed by a verifier on a node of the blockchain network for the execution of: The unlocking script of the unlocking transaction, the unlocking script leaving the serialized content of the unlocking transaction on the stack and then, The transaction locking script; And wherein the execution includes: Verifying that the unlocking script contains certain data, Extracting a reference to the output of the redeemable transaction from the input of the unlocking transaction included in the serialized content of the unlocking transaction on the stack, Determining the constraint, which includes, if the constraint is imposed on a portion of the previous transaction, using the reference to cause injection of the previous transaction, after which the constraint can be applied to fields of the previous transaction, and, Verifying the determined constraint.

2. The computer-implemented method according to claim 1, wherein the unlocking transaction constraint further constrains the input of the unlocking transaction to include a specific hash value.

3. The computer-implemented method according to claim 2, wherein the specific hash value encodes an identifier referring to the previous transaction output.

4. A system, comprising: A processor; And A memory including executable instructions that, when executed by the processor, cause the system to perform the computer-implemented method according to any one of the preceding claims.

5. A non-transitory computer-readable storage medium storing executable instructions that, when executed by a processor of a computer system, cause the computer system to at least perform the computer-implemented method according to any one of claims 1 to 3.

Images