Constraint injection of unlocking transaction bytecode

Abstract

To provide a method and system for controlling validation of blockchain transactions.SOLUTION: The blockchain network 100 is comprised of nodes 102 running instances of a blockchain protocol. At least some of the nodes are validating nodes that validate the transaction 104. A node receives a first transaction. The first transaction includes a first script and causes the node to obtain a set of field values as a result of execution. A second transaction has been obtained and the second transaction has been validated. The second transaction includes a second script and causes the node to create a signature based at least in part on a set of field values provided as a result of execution of the first script. The transaction is verified by executing the first script and the second script.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates generally to distributed ledger technologies, including blockchain transactions, and more particularly to inducing the injection of fields from blockchain transactions into unlocking transaction scripts. The present invention utilizes cryptographic and mathematical techniques to enforce security associated with electronic transfers made on blockchain networks. The present invention is particularly suited for use in, but not limited to, smart contracts and state machines. [Background technology]

[0002] In this document, the term "blockchain" is used to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction-chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. For convenience and purposes of explanation, "Bitcoin" may be referenced as a useful application of the technology described in this disclosure, but Bitcoin is only one of many applications to which the technology described in this disclosure may be applied. However, it should be noted that the present invention is not limited to use with the Bitcoin blockchain. Alternative blockchain implementations and protocols, including non-commercial applications, are also within the scope of the present invention. For example, the present technology provides advantages over utilizing a blockchain implementation that has similar restrictions as Bitcoin regarding the constraints that can be encoded in a transaction, regardless of whether a cryptocurrency exchange occurs.

[0003] A blockchain is a peer-to-peer, electronic ledger implemented as a computer-based, decentralized, distributed system composed of blocks, which in turn comprise transactions and other information. In some embodiments, a "blockchain transaction" is a set of data and conditions A transaction refers to an input message that encodes a structured collection of field values, including the following: Satisfying a set of conditions is a prerequisite for a set of fields to be written to a blockchain data structure. For example, in Bitcoin, each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output. In some implementations, the transfer of control of a digital asset can be performed by reassociating at least a portion of the digital asset from a first entity to a second entity. Each block contains a hash of the previous block, and blocks are chained together to create a permanent, immutable record of all transactions written since the blockchain's inception. Transactions contain small programs, known as scripts, embedded within the transaction's inputs and outputs, which specify how and by whom the transaction's outputs can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] That is, stack-based scripting languages ​​can utilize stacks. With stacks, values ​​can be pushed onto the top of the stack or popped off the top of the stack. Various operations performed on stacks can result in pushing or popping one or more values ​​onto or off the top of the stack. For example, the OP_EQUAL operation pops the top two items from the stack, compares them, and pushes the result (1 if equal, 0 if not) onto the top of the stack. Other operations performed on stacks, such as OP_PICK, can cause an item to be selected from a position other than the top of the stack. In some scripting languages ​​used by some of the embodiments, there can be at least two stacks: a main stack and an alternate stack. Some operations in the scripting language can move an item from the top of one stack to the top of another stack. For example, OP_TOALTSTACK moves a value from the top of the main stack to the top of the alternate stack.

[0005] A transaction must be "validated" before it can be written to the blockchain. Network nodes (miners) work to ensure each transaction is valid, and invalid transactions are rejected from the network. One node can have a different standard for validity than another. Validity in the blockchain is based on consensus, so a transaction is considered valid if a majority of nodes agree that it is valid. A software client installed on a node performs this validation work on a transaction, partially referencing the unspent transaction (UTXO), by executing UTXO locking and unlocking scripts. A transaction is valid according to the node if the execution of the locking and unlocking scripts evaluates to TRUE and other validation conditions, if applicable, are met. Validated transactions are propagated to other network nodes, where miner nodes can choose to include the transaction in the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be verified by the first node that receives it. If the transaction is verified, the node relays it to other nodes in the network. The transaction must then ii) be added to a new block constructed by miners, and iii) be mined, i.e., added to a public ledger of past transactions. A transaction is considered confirmed when enough blocks have been added to the blockchain to make the transaction effectively irreversible. Summary of the Invention

[0006] This disclosure describes technical aspects related to one or more blockchain-based computer programs. A blockchain-based computer program is a machine-readable, executable program recorded in a blockchain transaction. A blockchain-based computer program contains rules that can process inputs to produce results, and then actions can be taken depending on those results. Blockchains can be used to enable highly flexible and complex smart contracts when locking scripts have access to both unlocking and previous transactions. One area of ​​current research is the use of blockchain-based computer programs to implement "smart contracts." Unlike traditional contracts, which may be written in natural language, smart contracts can be computer programs designed to automate the execution of the terms of a machine-readable contract or agreement.

[0007] In embodiments, interactions with specific entities may be encoded in specific steps in a smart contract, but the smart contract may otherwise be automatically executed and self-enforced. In some examples, automatic execution refers to the execution of a smart contract that successfully executes to enable the transfer of a UTXO. Note that in such examples, the “entity” that can cause the transfer of a UTXO refers to an entity that can create the unlocking script without being required to prove knowledge of some secret. In other words, the unlocking transaction can be verified without verifying that the source of the data (e.g., the entity that created the unlocking transaction) has access to a cryptographic secret (e.g., a private asymmetric key, a symmetric key, etc.). Also, in such examples, self-enforcement refers to validating nodes in a blockchain network that are configured to enforce the unlocking transaction according to constraints. In some embodiments, "unlocking" a UTXO (also known as "spending" a UTXO) is used in the technical sense to refer to creating an unlocking transaction that references the UTXO and executes it as valid.

[0008] The output of a blockchain transaction includes a locking script and information about the ownership of a digital asset, such as Bitcoin. A locking script, also referred to as an encumbrance, "locks" a digital asset by specifying conditions that must be met to transfer a UTXO. For example, a locking script could require that certain data be provided in an unlocking script to unlock the associated digital asset. A locking script is also known as a "scriptPubKey" in Bitcoin. Techniques for requiring a party to provide data to unlock a digital asset include embedding a hash of the data within the locking script. However, this creates problems if the data is undetermined (e.g., unknown and inconsistent) at the time the locking script is created.

[0009] It would therefore be desirable to provide improved methods and systems that improve blockchain technology in one or more of these aspects.Therefore, in accordance with the present invention, there is provided a method and corresponding system as defined in the accompanying claims.

[0010] The present invention may be described as a verification method / system and / or a control method / system for controlling the verification of blockchain transactions. In some embodiments, a verified blockchain transaction results in the recording of the transaction in the blockchain, which, in some applications, may result in the exchange or transfer of a digital asset via the blockchain. A digital asset is a unit of a resource managed by the blockchain. In some embodiments, a digital asset may be used as cryptocurrency, although embodiments contemplate that digital assets may additionally or alternatively be used in other contexts. Note that while the present invention is applicable to the control of digital assets, it is technical in nature and may be used in other contexts utilizing blockchain data structures that do not necessarily involve the transfer of digital assets. As described below, the present invention may also be described as a security method / system for a new, improved, and advantageous way of performing operations via a blockchain network or platform.

[0011] As described in more detail below, in one embodiment, a locking script may be given access to certain fields of an unlocking transaction by receiving as input a set of field values ​​of the unlocking transaction and a signature hash (SIGHASH) type from the unlocking script of the unlocking transaction, and performing signature creation and verification operations.

[0012] As described in more detail below, in one embodiment, the locking script may be given access to a set of fields in the previous transaction such that the serialized previous transaction is included in the unlocking script of the unlocking transaction by constraining a transaction identifier (ID) extracted from a predetermined field of the unlocking transaction. In accordance with this embodiment, a method may be provided for injecting a serialized previous transaction into the locking script of a blockchain transaction by obtaining as input a first set of field values ​​corresponding to a first transaction and a second set of field values ​​corresponding to another transaction, extracting a transaction identifier from the first set of field values, and determining that the other transaction corresponds to the transaction identifier based on the second set of field values.

[0013] As described in more detail below, in one embodiment, the locking script and unlocking script may be configured to enable secure provision of pending data from either determined or undetermined sources. To protect data from pending sources from modification, the data may be embedded in a serialized previous transaction. Note that even if the data is present in a serialized previous transaction, it is still considered pending in the sense that the locking script does not constrain the data to be a predetermined value. To protect data from determined sources from modification, a public key from the determined source may be included in the locking script. The data may then be used to modify the public key, which may then be used to verify the signature of signed data using the modified private key. In accordance with this embodiment, a method may be provided for obtaining pending data and a second value, and verifying that the pending data is associated with a data source based on the data and the second value provided in the unlocking script.

[0014] As described in more detail below, in one embodiment, a parameterized smart contract may be created by extracting constraint parameters from a previous transaction and applying the constraint parameters to fields of the unlocking transaction. The parameterized smart contract may be embodied through a locking script having constraints parameterized by secure, pending data provided in the unlocking script of the unlocking transaction from a determined or pending source. In accordance with this embodiment, a method may be provided for obtaining the pending data. From the data, a set of constraints to apply to the rebinding of the digital asset may be determined, and the digital asset is rebound with the second entity according to the constraint set.

[0015] As described in more detail below, in one embodiment, a smart contract is created to be self-replicating until a termination condition is reached. In accordance with this embodiment, a method may be provided to check that the termination condition is met, and, if the termination condition is not met, to check that the locking script of the previous transaction matches the locking script of the unlocking transaction.

[0016] As described in more detail below, in one embodiment, a parameterized, self-replicating smart contract may be used to create a trustless, deterministic state machine. In accordance with this embodiment, a method may be provided for validating a self-replicating locking script and determining a next state of the trustless deterministic state machine based at least in part on input from a determined source and the current state of the trustless deterministic state machine.

[0017] The novel techniques described and suggested in this disclosure extend the functionality of blockchains without disrupting their properties, which guarantee the integrity of data stored within blockchain data structures. For example, the techniques improve the field of computation, particularly digital record validation, where conditions for validation are defined smart contracts embedded within the records, by utilizing the blockchain network to set and enforce criteria for recombining digital assets. Additionally, the techniques described and suggested in this disclosure may improve the functionality of blockchain networks by enabling blockchain transactions to function as state machines, allowing the functionality of computer programs to depend on the states recorded within those state machines.

[0018] Furthermore, the techniques described and suggested in this disclosure may necessarily be rooted in computer technology to overcome problems specifically stemming from blockchain technology (e.g., Bitcoin scripts), which have been specifically designed to limit functionality for security reasons. For example, scripts do not natively support complex flow-control functionality, such as loop generation. One advantage of this limitation is that programs have predictable execution times. Another significant advantage of limiting scripts to linear or tree-like decision tasks is that it avoids infinite loops, which can be used as a means to launch exploits such as denial of service (DoS) attacks. Thus, while the security of blockchain transfers / exchanges is enhanced and maintained, mechanisms must be found to implement functionality not permitted or provided by the language itself. The present invention provides an advancement in this regard, addressing, at least in part, the current limitations of blockchain transactions through the implementation of a self-replicating and self-replicating blockchain transaction locking script. Thus, the present invention provides a technical solution to a technical problem and offers advantages in terms of security, improved control over the exchange / transfer of digital assets via blockchain, and extension of current blockchain-related functionality.

[0019] Therefore, in accordance with the present invention, there is provided a computer-implemented method (and corresponding system) as defined in the accompanying claims. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: i) receiving, at a node in a blockchain network, a first transaction for transferring control of a digital asset, the first transaction including at least a first script including a set of field values ​​for the first transaction, and executing the first script to cause the node to obtain the set of field values; ii) obtaining a second transaction, the second transaction associated with the digital asset and including the second script, and executing the second script to cause the node to generate at least a signature based at least in part on the set of field values ​​provided as a result of executing the first script; and iii) verifying the first transaction by executing the first script and the second script.

[0020] Validating the first transaction can be successfully performed without verifying that the entity that created the first transaction has access to the confidential information.

[0021] The first script may further include a private cryptographic key of the asymmetric key pair. Additionally or alternatively, the second script may further cause the node to create a signature based at least in part on the private cryptographic key and the mask number. Additionally or alternatively, verifying the first transaction may further include verifying that the signature is associated with the public cryptographic key of the asymmetric key pair.

[0022] The first script may further specify a signature hash type. Additionally or alternatively, the field value set may be based, at least in part, on the signature hash type.

[0023] The signature hash type may be a value that indicates which field values ​​from the set of field values ​​of the first transaction should be included in the signature.

[0024] The second script may be a locking script that imposes a set of conditions for validating the first transaction. Additionally or alternatively, execution of the locking script may cause the node to validate the first transaction by determining whether the set of conditions is met.

[0025] The first script may be an unlocking script for satisfying a condition set in the second script.

[0026] Digital assets can be associated with unspent transaction outputs in a blockchain network.

[0027] A node may be a computing device that is communicatively coupled to at least one other node in a blockchain network.

[0028] A blockchain network can consist of distributed electronic devices that run instances of a blockchain protocol.

[0029] The first script and the second script may be written using a Turing incomplete instruction set.

[0030] The first script and the second script are written using a Turing complete instruction set.

[0031] A first script may include a set of fields, causing the node to make a set of fields available as input to a second script as a result of the execution of the first script.

[0032] It is also desirable to provide a system including a processor and a memory containing executable instructions that, upon execution by the processor, cause the system to perform any of the claimed methods.

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

[0034] Therefore, in accordance with the present invention, there is provided a computer-implemented method (and corresponding system) as defined in the accompanying claims. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: i) receiving, at a node in a blockchain network, a first transaction for transferring control of a digital asset, the method executing to cause the node to acquire at least a first set of field values ​​corresponding to the first transaction and a second set of field values ​​corresponding to the specific transaction; ii) acquiring a second transaction, the second transaction associated with the digital asset and including a second script, the method executing to cause the node to acquire at least the first and second sets of field values ​​associated with the specific transaction provided as a result of executing the first script, extracting a transaction identifier from the first set of field values, and verifying that the specific transaction corresponds to the transaction identifier based at least in part on the second set of field values; and iii) verifying the first transaction by executing the first and second scripts.

[0035] The second set of field values ​​may be in a canonicalized format.

[0036] A node may determine that a particular transaction corresponds to the transaction identifier by creating a hash of the second set of field values. Additionally or alternatively, a node may determine that a particular transaction corresponds to the transaction identifier by verifying that the hash matches the transaction identifier.

[0037] A particular transaction may be associated with control of the digital assets being transferred.

[0038] A particular transaction may be associated with a second digital asset that is different from the digital asset being transferred.

[0039] Validating the first transaction may succeed without verifying that the entity that created the first transaction has access to the confidential information.

[0040] The node may be a validating node of the blockchain network.

[0041] Validating the first transaction may further include adding the first transaction to a blockchain in the blockchain network as a result of successfully validating the first transaction.

[0042] The second script may be a locking script that imposes a set of conditions for validating the first transaction. Additionally or alternatively, execution of the locking script may cause the node to validate the first transaction by determining whether the set of conditions is met.

[0043] The first script may be an unlocking script for satisfying a condition set in the second script.

[0044] The first script may specify a signature hash type. Additionally or alternatively, the second script may be further executed to cause the node to obtain the signature hash type provided as a result of execution of the first script.

[0045] The second script may further result in the node determining, based at least in part on the signature hash type, that the particular transaction is a member of a set of transactions related to the first transaction.

[0046] The second script may also be executed to cause the node to determine that a particular transaction corresponds to the second transaction based at least in part on the signature hash type.

[0047] It is also desirable to provide a system including a processor and a memory containing executable instructions that, upon execution by the processor, cause the system to perform any of the claimed methods.

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

[0049] Therefore, in accordance with the present invention, there may be provided a computer-implemented method (and corresponding system) as defined in the accompanying claims. The computer-implemented method may be described as a blockchain data constraining method. The computer-implemented method may include: i) receiving, at a node in a blockchain network, a first transaction for transferring control of a digital asset, the first transaction including a first script and including at least a first value, the first value including data at least in part not constrained by a second script, and a second value; ii) obtaining a second transaction, the second transaction associated with the digital asset and, upon execution, causing the node to obtain at least the first value and the second value as a result of executing the first script and to verify that the data is associated with a particular source based at least in part on the first value and the second value; and iii) verifying the first transaction by executing the first script and the second script.

[0050] The second script may be a locking script that includes a set of conditions for validating the second transaction. Additionally or alternatively, the first script may be an unlocking script for satisfying the set of conditions of the locking script.

[0051] Validating the first transaction may be performed without verifying that the entity that created the first transaction has access to the confidential information.

[0052] A failure to validate that the data is associated with the data source may result in a failure to validate the first transaction.

[0053] The identity of the particular source may not be constrained by the second script.

[0054] The particular transaction may be a particular source of the data. Additionally or alternatively, the first value may be a set of field values ​​for the particular transaction. Additionally or alternatively, the second value may include a transaction identifier associated with the particular transaction. The second script may verify that the data is associated with the data source by verifying that the particular transaction corresponds to the transaction identifier.

[0055] The second script may verify that a particular transaction corresponds to the transaction identifier by verifying that the transaction identifier matches a hash of a set of fields for the particular transaction.

[0056] A first script may include a set of fields for a particular transaction, causing the node to make the set of fields for the particular transaction available as input to a second script as a result of execution of the first script.

[0057] The particular transaction may be the second transaction.

[0058] The data may be encoded in a field of a particular transaction.

[0059] The second script may constrain the identity of a particular source.

[0060] The second value may be a signature. Additionally or alternatively, the second script may further cause the node to obtain a public key associated with the data source and, additionally or alternatively, create a modified public key based, at least in part, on the public key and the data. Additionally or alternatively, the second script may verify that the data is associated with the data source based, at least in part, on the modified public key.

[0061] The modified public key may be created by performing elliptic curve point multiplication on the public key by the value of the data.

[0062] It is also desirable to provide a system including a processor and a memory containing executable instructions that, upon execution by the processor, cause the system to perform any of the claimed methods.

[0063] It is also desirable to provide a non-transitory computer-readable storage medium having stored thereon executable instructions that, when executed by a processor of the computer system, cause the computer system to perform at least any of the methods described in the claims. Therefore, in accordance with the present invention, a computer-implemented method (and corresponding system) may be provided as defined in the accompanying claims. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: i) receiving, at a node in a blockchain network, a first transaction for transferring control of a digital asset, the first transaction including a first script, which, when executed, causes the node to acquire at least a first set of data and field values ​​for the first transaction; ii) receiving a second transaction, the second transaction including a second script, which, when executed, causes the node to determine at least a set of constraints based, at least in part, on data provided as a result of executing the first script, and to validate the set of constraints for the first transaction based, at least in part, on the first set of field values; and iii) transferring control of the digital asset in accordance with the set of constraints as a result of executing the first script and the second script.

[0064] Transferring control of the digital asset can be performed without verifying that the entity that created the first transaction has access to the confidential information.

[0065] The identity of the source of the data may not be constrained by the second script.

[0066] The second script may constrain the identity of the source of the data.

[0067] The second script may include the public key of a particular data source that can be used to verify the data.

[0068] Verifying the data may include creating a modified public key based at least in part on the public key and the data, and additionally or alternatively determining that the data is associated with the data source based at least in part on the modified public key.

[0069] The set of constraints may be derived, at least in part, from a set of parameters in the data.

[0070] Satisfying a set of constraints may be a condition for recombining at least a portion of the digital assets.

[0071] Transferring control of a digital asset may include rebinding the digital asset from the first entity to the second entity.

[0072] The identity of the second entity may be determined based at least in part on a set of constraints.

[0073] The source of the data may be a second transaction. Additionally or alternatively, the data includes a second set of field values ​​of the second transaction. Additionally or alternatively, execution of the second script may cause the set of constraints to be derived at least in part from the second set of field values.

[0074] The identity of the second entity may be determined based at least in part on a set of constraints.

[0075] The constraint set may further cause at least a portion of the digital asset to be reassociated with a third entity.

[0076] It is also desirable to provide a system including a processor and a memory containing executable instructions that, upon execution by the processor, cause the system to perform any of the claimed methods.

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

[0078] Therefore, in accordance with the present invention, there may be provided a computer-implemented method (and corresponding system) as defined in the accompanying claims. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: i) receiving, at a node in a blockchain network, a first transaction for transferring control of a digital asset, the first transaction including a first script, which, upon execution, causes the node to acquire at least a first set of field values ​​for the first transaction, the first set of field values ​​including a third script, and a second set of field values ​​for a second transaction, the second set of field values ​​including a copy of the second script; ii) acquiring a second transaction, the second transaction including a second script, which, upon execution, causes the node to acquire at least the first set of field values ​​for the third script and determine that the copy of the second script matches the third script, upon determining that the termination condition is not satisfied; and iii) transferring control of the digital asset as a result of executing the first script and the second script.

[0079] The second transaction may be a transaction associated with a digital asset. Additionally or alternatively, the first transaction may be a transaction that rebinds at least a portion of a digital asset from a first entity to a second entity.

[0080] The first script may be an unlocking script for satisfying a condition set in the second script.

[0081] The second script may be a locking script that imposes a set of conditions for validating the first transaction.

[0082] The third script may be a locking script that imposes a set of conditions for validation of future transactions.

[0083] Transferring control of a digital asset may include rebinding the digital asset from a first entity to a second entity.

[0084] Determining that the termination condition is not met may include determining that the amount of the digital assets associated with the second transaction is sufficient to recombine at least a portion of the digital assets.

[0085] The third script may be embedded in the field values ​​of the first set of field values.

[0086] A blockchain network can consist of distributed electronic devices that run instances of a blockchain protocol.

[0087] Transferring control of the digital asset can be performed without verifying that the entity that created the first transaction has access to the confidential information.

[0088] The second script may further cause the node to verify that the first transaction satisfies additional constraints as a further condition for transferring control of the digital asset.

[0089] The first transaction and the second transaction may be members of a set of repeating smart contracts associated with the digital asset.

[0090] A set of iterating smart contracts can be terminated by an exit condition.

[0091] It is also desirable to provide a system including a processor and a memory containing executable instructions that, upon execution by the processor, cause the system to perform any of the claimed methods.

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

[0093] Therefore, in accordance with the present invention, there may be provided a computer-implemented method (and corresponding system) as defined in the accompanying claims. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: i) receiving, at a node in a blockchain network, a first transaction for transferring control of a digital asset, the first transaction including a first script that, upon execution, causes the node to acquire at least a first set of field values ​​for the first transaction, a second set of field values ​​for the second transaction, and an input; ii) acquiring a second transaction, the second transaction including a second script including a set of rules that, upon execution, causes the node to at least verify that the second script matches a third script embedded in the first set of field values, determine a current state based at least in part on the second set of field values, and determine a next state based at least in part on the current state, the input, and the set of rules, and verify that the next state is included in the first set of field values; and iii) transferring control of the digital asset as a result of executing the first script and the second script.

[0094] The second script may constrain the identity of the input source.

[0095] Any of the claimed methods may further include the step of verifying the cryptographic secrecy of the input source.

[0096] The rule set may be a state transition matrix.

[0097] The third script may be a locking script that imposes a set of conditions for the validation of future transactions.

[0098] The second script may further cause the node to determine that an exit condition is not met.

[0099] The input may be embedded in a second set of field values.

[0100] The termination condition may be that the digital asset associated with the second transaction is of insufficient size to be transferred.

[0101] The current state may indicate the state of the second transaction.

[0102] The next state may indicate the state of the first transaction in the validation.

[0103] Any of the claimed methods may further include receiving a third transaction. Additionally or alternatively, any of the claimed methods may further include obtaining a fourth script from the first transaction, the fourth script being capable of causing the node, upon execution, to determine a next state and another state different from the current state based at least in part on the next state, the second input, and the rule set.

[0104] The current state and the next state may be members of the set of possible states for the first and second transactions.

[0105] Transferring control of a digital asset may include rebinding the digital asset from a first entity to a second entity.

[0106] It is also desirable to provide a system including a processor and a memory containing executable instructions that, upon execution by the processor, cause the system to perform any of the claimed methods.

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

[0108] Therefore, in accordance with the present invention, there may be provided a computer-implemented method (and corresponding system) as defined in the accompanying claims. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: i) receiving, at a node in a blockchain network, at least a first transaction to be validated, the first transaction including at least a set of field values ​​for the first transaction and including a first script that, when executed, causes the node to obtain the set of field values; ii) obtaining a second transaction, the second transaction being validated and including a second script that, when executed, causes the node to at least generate a signature based at least in part on the set of field values ​​provided as a result of execution of the first script; and iii) verifying the first transaction by executing the first script and the second script.

[0109] Validating the first transaction can be successfully performed without verifying that the entity that created the first transaction has access to the confidential information.

[0110] The first script may further include a private encryption key of the asymmetric key pair. Additionally or alternatively, the second script may further cause the node to create a signature based at least in part on the private encryption key and the mask number. Additionally or alternatively, verifying the first transaction may further include verifying that the signature is associated with the public encryption key of the asymmetric key pair.

[0111] The first script may further specify a signature hash type. Additionally or alternatively, the field value set may be based at least in part on the signature hash type.

[0112] The signature hash type may be a value that indicates which field values ​​from the set of field values ​​of the first transaction should be included in the signature.

[0113] The second script may be a locking script that imposes a set of conditions for validating the first transaction. Additionally or alternatively, execution of the locking script may cause the node to validate the first transaction by determining whether the set of conditions is met.

[0114] The first script may be an unlocking script for satisfying a condition set in the second script.

[0115] Validating the first transaction may result in the transfer of the unspent transaction output.

[0116] A node may be a computing device that is communicatively coupled to at least one other node in a blockchain network.

[0117] A blockchain network can consist of distributed electronic devices that run instances of a blockchain protocol.

[0118] The first script and the second script may be written using a Turing-incomplete instruction set.

[0119] The first and second scripts are written using a Turing-complete instruction set.

[0120] A first script may include a set of fields, causing the node to make a set of fields available as input to a second script as a result of the execution of the first script.

[0121] It is also desirable to provide a system including a processor and a memory containing executable instructions that, upon execution by the processor, cause the system to perform any of the claimed methods.

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

[0123] Therefore, in accordance with the present invention, there may be provided a computer-implemented method (and corresponding system) as defined in the accompanying claims. The computer-implemented method may be described as a blockchain data constraint method. The method may include: i) receiving, at a node in a blockchain network, a first transaction, the first transaction including a first script that, upon execution, causes the node to acquire at least a first set of field values ​​corresponding to the first transaction and a second set of field values ​​corresponding to the particular transaction; ii) acquiring a second transaction, the second transaction being verified and, upon execution, causes the node to acquire at least the first set of field values ​​and the second set of field values ​​associated with the particular transaction provided as a result of execution of the first script, extract a transaction identifier from the first set of field values, and determine that the particular transaction corresponds to the transaction identifier based at least in part on the second set of field values; and iii) verifying the first transaction by executing the first script and the second script.

[0124] The second set of field values ​​may be in a normalized format.

[0125] A node may determine that a particular transaction corresponds to the transaction identifier by creating a hash of the second set of field values. Additionally or alternatively, a node may determine that a particular transaction corresponds to the transaction identifier by verifying that the hash matches the transaction identifier.

[0126] A particular transaction may be associated with control of the digital assets transferred as a result of validating the first transaction.

[0127] A particular transaction may be associated with a second digital asset that is different from the digital asset transferred as a result of the validation of the first transaction.

[0128] Validating the first transaction may be successful without verifying that the entity that created the first transaction has access to the confidential information.

[0129] The node may be a validating node of the blockchain network.

[0130] Validating the first transaction may further include adding the first transaction to a blockchain of the blockchain network as a result of successfully validating the first transaction.

[0131] The second script may be a locking script that imposes a set of conditions for validating the first transaction. Additionally or alternatively, execution of the locking script may cause the node to validate the first transaction by determining whether the set of conditions is met.

[0132] The first script may be an unlocking script for satisfying a condition set in the second script.

[0133] The first script may specify a signature hash type. Additionally or alternatively, the second script may be further executed to cause the node to obtain the signature hash type provided as a result of execution of the first script.

[0134] The second script may also, as a result of execution, cause the node to determine that the particular transaction is a member of a set of transactions related to the first transaction based at least in part on the signature hash type.

[0135] The second script may also be executed to cause the node to determine that a particular transaction corresponds to the second transaction based at least in part on the signature hash type.

[0136] It is also desirable to provide a system including a processor and a memory containing executable instructions that, upon execution by the processor, cause the system to perform any of the claimed methods.

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

[0138] Therefore, in accordance with the present invention, there may be provided a method (and corresponding system) as defined in the accompanying claims. The method may be described as a blockchain data constraint method. The method may include: i) receiving, at a node in a blockchain network, a first transaction for transferring control of a digital asset, the first transaction including a first script and including at least a first value, the first value including data at least in part not constrained by a second script, and a second value; ii) obtaining a second transaction, the second transaction being validated and executed to cause the node to obtain at least the first value and the second value as a result of executing the first script and to verify that the data is associated with a particular source based at least in part on the first value and the second value; and iii) validating the first transaction by executing the first script and the second script.

[0139] The second script may be a locking script that includes a set of conditions for validating the second transaction. Additionally or alternatively, the first script may be an unlocking script for satisfying the set of conditions of the locking script.

[0140] Validating the first transaction may be performed without verifying that the entity that created the first transaction has access to the confidential information.

[0141] A failure to validate that the data is associated with the data source may result in a failure to validate the first transaction.

[0142] The identity of the particular source may not be constrained by the second script.

[0143] The particular transaction may be a particular source of the data. Additionally or alternatively, the first value may be a set of field values ​​for the particular transaction. Additionally or alternatively, the second value may include a transaction identifier associated with the particular transaction. The second script may verify that the data is associated with the data source by verifying that the particular transaction corresponds to the transaction identifier.

[0144] The second script, when executed, may verify that a particular transaction corresponds to the transaction identifier by verifying that the transaction identifier matches a hash of a set of fields for the particular transaction.

[0145] A first script may include a set of fields for a particular transaction, causing the node to make the set of fields for the particular transaction available as input to a second script as a result of execution of the first script.

[0146] The particular transaction may be the second transaction.

[0147] The data may be encoded in a field of a particular transaction.

[0148] The second script may constrain the identity of a particular source.

[0149] The second value may be a signature. Additionally or alternatively, the second script may further cause the node to obtain a public key associated with the data source and, additionally or alternatively, create a modified public key based, at least in part, on the public key and the data. Additionally or alternatively, the second script, upon execution, may verify that the data is associated with the data source based, at least in part, on the modified public key.

[0150] The modified public key may be created by performing an elliptic curve point multiplication on the public key with the value of the data.

[0151] It is also desirable to provide a system including a processor and a memory containing executable instructions that, upon execution by the processor, cause the system to perform any of the claimed methods.

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

[0153] Therefore, in accordance with the present invention, there may be provided a method (and corresponding system) as defined in the accompanying claims. The method may be described as a blockchain data constraint method. The method may include: i) receiving, at a node in a blockchain network, a first transaction to be validated, the first transaction including a first script that, upon execution, causes the node to obtain at least a first set of data and field values ​​for the first transaction; ii) obtaining a second transaction, the second transaction including a second script that, upon execution, causes the node to determine at least a set of constraints based, at least in part, on data provided as a result of execution of the first script, and to verify the set of constraints for the first transaction based, at least in part, on the first set of field values; and iii) transferring control of the digital asset in accordance with the set of constraints as a result of execution of the first script and the second script.

[0154] Validating the first transaction may be performed without verifying that the entity that created the first transaction has access to the confidential information.

[0155] The identity of the source of the data may not be constrained by the second script.

[0156] The second script may constrain the identity of the source of the data.

[0157] The second script may include the public key of a particular data source that can be used to verify the data.

[0158] Verifying the data may include creating a modified public key based at least in part on the public key and the data, and additionally or alternatively determining that the data is associated with the data source based at least in part on the modified public key.

[0159] The set of constraints may be derived, at least in part, from a set of parameters in the data.

[0160] Satisfying a set of constraints may be a condition for recombining at least a portion of the digital assets.

[0161] Validating the first transaction may include reassociating the digital asset from the first entity to the second entity.

[0162] The constraint set may further allow at least a portion of the digital asset to be reassociated with a third entity.

[0163] The identity of the second entity may be determined based at least in part on a set of constraints.

[0164] The source of the data may be a second transaction. Additionally or alternatively, the data includes a second set of field values ​​of the second transaction. Additionally or alternatively, execution of the second script may cause the set of constraints to be derived at least in part from the second set of field values.

[0165] The identity of the second entity may be determined based at least in part on a set of constraints.

[0166] The constraint set may further allow at least a portion of the digital asset to be reassociated with a third entity.

[0167] It is also desirable to provide a system including a processor and a memory containing executable instructions that, upon execution 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 having stored thereon executable instructions which, when executed by a processor of a computer system, cause the computer system to perform at least any of the claimed methods.

[0169] Therefore, according to the present invention, there is provided a method (and corresponding system) as defined in the accompanying claims. The method may be described as a blockchain data constraint method. The method may include: i) receiving, at a node in a blockchain network, a first transaction to be verified, the first transaction including a first script, which, upon execution, causes the node to acquire at least a first set of field values ​​for the first transaction, the first set of field values ​​including a third script, and a second set of field values ​​for a second transaction, the second set of field values ​​including a copy of the second script; ii) acquiring a second transaction, the second transaction including a second script, which, upon execution, causes the node to acquire at least the first set of field values ​​for the third script and determine that the copy of the second script matches the third script, upon determining that the termination condition is not satisfied; and iii) verifying the first transaction as a result of executing the first script and the second script.

[0170] The first script may be an unlocking script for satisfying a condition set in the second script.

[0171] The second script may be a locking script that imposes a set of conditions for validating the first transaction.

[0172] The third script may be a locking script that imposes a set of conditions for the validation of future transactions.

[0173] The second transaction may be a transaction associated with a digital asset. Additionally or alternatively, the first transaction may be a transaction that rebinds at least a portion of a digital asset from a first entity to a second entity.

[0174] Validating the first transaction may include reassociating the digital asset from the first entity to the second entity.

[0175] Determining that the termination condition is not satisfied may include determining that the amount of the digital assets associated with the second transaction is sufficient to recombine at least a portion of the digital assets.

[0176] The third script may be embedded in the field values ​​associated with the first set of field values.

[0177] A blockchain network can consist of distributed electronic devices that run instances of a blockchain protocol.

[0178] Validating the first transaction may be performed without verifying that the entity that created the first transaction has access to the confidential information.

[0179] The second script may further cause the node to verify that the first transaction satisfies additional constraints as a further condition for validating the first transaction.

[0180] The first transaction and the second transaction may be members of a set of iterating smart contracts associated with the digital asset.

[0181] A set of iterating smart contracts can be terminated by an exit condition.

[0182] It is also desirable to provide a system including a processor and a memory containing executable instructions that, upon execution by the processor, cause the system to perform any of the claimed methods.

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

[0184] Therefore, in accordance with the present invention, there is provided a method (and corresponding system) as defined in the accompanying claims. The method may be described as a blockchain data constraint method. The method may include: i) receiving, at a node in a blockchain network, a first transaction to be validated, the first transaction including a first script that, upon execution, causes the node to acquire at least a first set of field values ​​for the first transaction, a second set of field values ​​for a second transaction, and an input; ii) acquiring a second transaction, the second transaction including a second script including a rule set that, upon execution, causes the node to at least verify that the second script matches a third script embedded in the first set of field values, determine a current state based at least in part on the second set of field values, and determine a next state based at least in part on the current state, the input, and the rule set, and verify that the next state is included in the first set of field values; and iii) validating the first transaction as a result of executing the first script and the second script.

[0185] The second script may constrain the identity of the input source.

[0186] Any of the claimed methods may further include the step of verifying the cryptographic secrecy of the input source.

[0187] The rule set may be a state transition matrix.

[0188] The third script may be a locking script that imposes a set of conditions for the validation of future transactions.

[0189] The second script may further cause the node to determine that an exit condition is not met.

[0190] The input may be embedded in a second set of field values.

[0191] The termination condition may be that the digital asset associated with the second transaction is of insufficient size to be transferred.

[0192] Validating the first transaction may include reassociating the digital asset from the first entity to the second entity.

[0193] The current state may indicate the state of the second transaction.

[0194] The next state may indicate the state of the first transaction in the validation.

[0195] Any of the claimed methods may further include receiving a third transaction. Additionally or alternatively, any of the claimed methods may further include obtaining a fourth script from the first transaction, the fourth script being capable of causing the node, upon execution, to determine a next state and another state different from the current state based at least in part on the next state, the second input, and the rule set.

[0196] The current state and the next state may be members of the set of possible states for the first and second transactions.

[0197] It is also desirable to provide a system including a processor and a memory containing executable instructions that, upon execution by the processor, cause the system to perform any of the claimed methods.

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

[0199] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter, embodiments of the invention will now be described, by way of example only, and reference will be made to the accompanying drawings, in which: [Figure 1] FIG. 1 illustrates a blockchain environment in which various embodiments may be implemented. [Figure 2] FIG. 2 illustrates an example of a trustless, deterministic state machine according to one embodiment. [Figure 3] FIG. 3 illustrates an example of a problem related to locking scripts that is solved by one embodiment. [Figure 4] FIG. 4 shows an example of data accessible to an unlocking script according to one embodiment. [Figure 5] FIG. 5 shows an example of creating a signature from a set of serialized transaction fields according to one embodiment. [Figure 6]FIG. 6 is a flow chart illustrating an example of causing injection of a set of serialized unlocking transaction fields according to one embodiment. [Figure 7] FIG. 7 illustrates another example of a problem related to locking scripts that is solved by one embodiment. [Figure 8] FIG. 8 illustrates an example of causing the injection of a serialized previous transaction according to one embodiment. [Figure 9] FIG. 9 shows an example of a set of fields available depending on the signature hash type, according to one embodiment. [Figure 10] FIG. 10 illustrates an example of extracting a transaction identifier from a serialized transaction according to one embodiment. [Figure 11] FIG. 11 is a flowchart of an example of causing the injection of a serialized previous transaction according to one embodiment. [Figure 12] FIG. 12 illustrates an example of unsecure provision of undetermined data from an undetermined source, according to one embodiment. [Figure 13] FIG. 13 illustrates an example of securely providing undetermined data from a determined source, according to one embodiment. [Figure 14] FIG. 14 illustrates an example of secure provision of pending data from a pending source into a locking script according to one embodiment. [Figure 15] FIG. 15 is a flow chart illustrating an example of securely providing pending data into a locking script according to one embodiment. [Figure 16]FIG. 16 illustrates an example of a parameterized smart contract, according to one embodiment. [Figure 17] FIG. 17 is a flow chart illustrating an example of parameterized smart contract execution, according to one embodiment. [Figure 18] FIG. 18 illustrates an example of the problem of smart contract duplication solved by one embodiment. [Figure 19] FIG. 19 illustrates an example of a solution to the problem of smart contract duplication, according to one embodiment. [Figure 20] FIG. 20 illustrates another example of the problem of smart contract duplication solved according to one embodiment. [Figure 21] FIG. 21 illustrates an example of a self-replicating smart contract, according to one embodiment. [Figure 22] FIG. 22 is a flowchart illustrating an example of a self-replicating smart contract with an exit condition, according to one embodiment. [Figure 23] FIG. 23 illustrates an example of a problem involving next state determination that is solved by one embodiment. [Figure 24] FIG. 24 shows an example of a trustless, deterministic state machine according to one embodiment. [Figure 25] FIG. 25 is a flow chart illustrating an example of a trustless, deterministic state machine, according to one embodiment. [Figure 26] FIG. 26 illustrates a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0200] Referring initially to FIG. 1 , an example of a blockchain and associated blockchain network 100 is shown in accordance with one embodiment of the present disclosure. In this embodiment, the example blockchain network 100 is made up of peer-to-peer distributed electronic devices running instances of a blockchain protocol. In some embodiments, the distributed electronic devices are referred to as nodes 102. One example of a blockchain protocol is the Bitcoin protocol.

[0201] Node 102 may be comprised of any suitable computing device (e.g., a server in a data center, a client computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), multiple computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device such as computing device 2600 of FIG. 26).

[0202] In one embodiment, one or more nodes 102 are communicatively coupled to one or more other nodes 102. Such communicative coupling may include one or more of wired or wireless communication. In an embodiment, nodes 102 each maintain at least a portion of a "ledger" of all transactions in the blockchain. As such, the ledger is a distributed ledger. Transactions processed by a node that affect the ledger are verifiable by one or more other nodes so that the integrity of the ledger is maintained.

[0203] In one embodiment, at least some of the nodes 102 are miner nodes that perform complex computations, such as solving cryptographic problems. Miner nodes that solve the cryptographic problems create new blocks for the blockchain and broadcast the new blocks to other nodes 102. The other nodes 102 verify the miner nodes' work and, upon verification, accept the block into the blockchain (e.g., by adding the block to the blockchain's distributed ledger). In some embodiments, a block is a group of transactions, often marked with a timestamp and a "fingerprint" (e.g., a hash) of the previous block. In this way, each block becomes linked to the previous block, thereby creating a "chain" that links blocks in the blockchain. In embodiments, valid blocks are added to the blockchain by consensus of the nodes 102. In some embodiments, the blockchain also includes a list of validated blocks.

[0204] In one embodiment, at least some of nodes 102 operate as validating nodes that validate transactions as described in this disclosure. In some embodiments, a transaction includes proof of ownership of a digital asset (e.g., a number of bitcoins) and data providing conditions for the acceptance or transfer of ownership / control of the digital asset. In some embodiments, an “unlocking transaction” refers to a transaction that reassociates (e.g., transfers ownership or control of) at least a portion of a digital asset, represented by an unspent transaction output (UTXO) of a previous transaction, to an entity associated with a blockchain address. In some embodiments, a “previous transaction” refers to a transaction that includes a UTXO referenced by the unlocking transaction. In some embodiments, a transaction includes a “locking script” that encumbers the transaction with conditions that must be met before ownership / control can be transferred (“unlocked”). In some embodiments, a blockchain address is an alphanumeric string associated with an entity to which control of at least a portion of a digital asset is being transferred / reassociated. In some blockchain protocols implemented in some embodiments, there is a one-to-one correspondence between public keys associated with entities and blockchain addresses. Validation of a transaction may include verification of one or more conditions specified in the locking script and / or unlocking script.If the transaction 104 is successfully validated, the validating node adds the transaction 104 to the blockchain and distributes it to the nodes 102.

[0205] Figure 2 illustrates an example embodiment 200 consistent with the present disclosure. Specifically, Figure 2 illustrates a previous blockchain transaction 202 that encodes a first state 206 and an unlocking blockchain transaction 204 that encodes a second state 208. In the example embodiment 200, the first state 206 at a first time is represented as a parameter embedded in the previous blockchain transaction 202. Further details regarding parameterizing constraints can be found in the discussion of Figure 16. The unlocking blockchain transaction 204 includes a parameter that represents the second state 208.

[0206] In exemplary embodiment 200, transactions 202 and 204 are sets of field values ​​that include one or more inputs and one or more outputs. In some embodiments, the inputs and outputs reflect the intent to rebind at least a portion of a digital asset from at least one entity to at least another entity. In exemplary embodiment 200, previous blockchain transaction 202 is the most current, confirmed transaction included in the blockchain. In exemplary embodiment 200, unlocking blockchain transaction 204 is a transaction in the immediate future that has not yet been confirmed and not yet included in the blockchain. Each input of unlocking blockchain transaction 204 receives an output of previous blockchain transaction 202.

[0207] Some blockchain technologies, such as Bitcoin, use the elliptic curve digital signature algorithm (ECDSA) as the mathematical scheme for digital signatures. In embodiments, ECDSA is the cryptographic digital signature used to protect UTXOs from being obtained by unauthorized entities. Elliptic curve digital signatures (ECDSA) in Bitcoin typically appear with a signature hash flag (SIGHASH type) appended to the end. However, it is contemplated that the techniques of this disclosure can be used with blockchain technologies that do not implement the SIGHASH type. In such blockchain technologies, ECDSA is contemplated to comply with the signature creation principles of the particular blockchain technology.

[0208] In embodiments, the SIGHASH type refers to the set of fields extracted from the transaction before it is serialized (e.g., canonicalized) and hashed. For example, the SIGHASH type may affect which fields of the transaction are included in the signature. In some embodiments, the SIGHASH type may be one or more of SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, or SIGHASH_ANYONECANPAY. In one embodiment, the type SIGHASH_ALL indicates that all fields in the transaction are hashed and signed except for the input script. In one embodiment, the type SIGHASH_NONE indicates that the output does not need to be signed, allowing others to update the transaction. In one embodiment, the type SIGHASH_SINGLE indicates that the input is signed but the sequence number is blank, allowing others to create a new version of the transaction, only with the signed output in the same position as the input. In one embodiment, the type SIGHASH_ANYONECANPAY is combined with other types to indicate that inputs containing SIGHASH_ANYONECANPAY are signed, but other inputs do not need to be signed. SIGHASH types may be represented by a value that indicates the SIGHASH type. For example, in some implementations, SIGHASH_ALL is represented by a byte with a value of 1, SIGHASH_NONE is represented by a byte with a value of 2, SIGHASH_SINGLE is represented by a byte with a value of 3, and SIGHASH_ANYONECANPAY is represented by a byte with a value of 80. In some implementations, combining SIGHASH types is performed by adding the values ​​of the bytes together.

[0209] In some embodiments, the set of transaction fields determined by the SIGHASH type refers to a subset of the corresponding transaction encoded in bytes as determined by the SIGHASH type. For example, for a SIGHASH type of SIGHASH_ANYONECANPAY, only one transaction input is included in the signature.

[0210] In one embodiment, ECDS is represented by a pair of 256-bit numbers (r, s) encoded in distinguished encoding rules (DER) format. However, it should be noted that the techniques of this disclosure can be used with other encoding formats, such as basic encoding rules (BER) or canonical encoding rules (CER). The parameters used in ECDSA are K (the elliptic curve point with coordinates (x, y)), k (a 256-bit number, typically random to protect the private key), G (the base point on an elliptic curve with order n, n × G = 0, where 0 represents the identity elliptic curve point and n is a large prime number used as a parameter in an elliptic curve finite field), r (one of the 256-bit numbers in the ECDS), s (the other of the 256-bit numbers in the signature), and k. -1 (The modular multiplicative inverse of k, i.e., k -1 k≡1 mod n), m (the message / data being signed, resized to 256 bits in an embodiment by a hash function), and a (a private key, e.g., a 256-bit number). In this embodiment, the ECDS is created as follows:

[0211] First, an elliptic curve point K is determined by multiplying k with a generator. K=k×G

[0212] Next, a point x is determined from K, and the first 256-bit number in the ECDS, r, is determined according to the following formula: r=x mode n

[0213] Next, the second of the 256-bit numbers in the ECDS is determined according to the following formula: s=k -1 (m+r×a)mod n

[0214] Finally, (r, s) is encoded in DER format. Given the signature (r, s), the message / data m, and the public key A corresponding to the private key a, the signature can be verified. To verify the signature, we use ν=s -1 ×(m×G+r×y) is calculated. If v=r, the signature is valid.

[0215] Bitcoin uses a scripting system called "Script." Throughout this disclosure, various script operation codes and keywords are referenced to perform various operations. However, it is contemplated that other blockchain technologies may implement different instruction sets, and therefore, the operation codes described in this disclosure are not intended to be specific operation codes in a script, but rather are intended to be illustrative of the operations performed by the operation codes. In some embodiments, the scripting system is a Turing-incomplete instruction set (e.g., lacking support for loops, recursion, goto statements, etc.). In other embodiments, the scripting system is a Turing-complete instruction set.

[0216] Certain embodiments of the present disclosure operate under the assumption that the scripting system or other system for implementing the described instruction set allows for more than 200 instructions (e.g., operation codes) in a single script. Similarly, certain embodiments of the present disclosure further assume the following: The functionality provided by the operation codes referred to in this disclosure is present and available in the system that executes the operation code script / instruction set; and / or The required functionality can be achieved by the creation of customized functions written to provide the desired behavior. These customized functions can be written to implement the functionality of op_codes that exist in the language but are disabled, or they can be "new" op_codes that provide specific functionality not natively provided in the scripting language itself.

[0217] Examples of operation codes referenced in this disclosure include: OP_ECPX, returns the x coordinate of an elliptic curve point OP_ADD, add the top two items to the stack OP_BIGMOD, returns the remainder after subtracting the top two items from the stack OP_BIGMODADD, performs a modulus addition of the top two items of the stack modulus to the third item of the stack OP_BIGMODINVERSE, which performs a modulus negative exponent operation OP_BIGMODMUL, performs a modulus multiplication of the top two items of the stack modulus on the third item of the stack OP_CAT, concatenates the top two items in the stack OP_CHECKSIG, pops the public key and signature from the stack and verifies it against the signature in the transaction field according to the SIGHASH type. Returns 1 if the signature is valid, 0 otherwise. OP_CHECKSIGVERIFY, which works like OP_CHECKSIG but runs OP_VERIFY afterwards OP_DERENCODE, encodes the top two items of the stack in DER format OP_DUP, duplicate the top item of the stack OP_ECPMULT, which performs elliptic curve point multiplication (also referred to as elliptic curve scalar multiplication) on the top two items of the stack These statements are executed if OP_ELSE, the preceding OP_IF, OP_NOTIF, or OP_ELSE was not executed, otherwise these statements are not executed if the preceding OP_IF, OP_NOTIF, or OP_ELSE was executed. OP_ENDIF, ends an if / else block OP_EQUAL, returns 1 if the inputs are exactly equal, 0 otherwise OP_EQUALVERIFY , similar to OP_EQUAL, but followed by OP_VERIFY OP_FROMALTSTACK, puts the input on top of the main stack and removes it from the alternate stack OP_HASH256, where the input is hashed twice, first using SHA-256 and then using RIPEMD-160 OP_IF, if the top stack value is not False, the statement is executed and the top stack value is removed. OP_MUL, multiplies the top two items on the stack OP_NOTIF, if the value at the top of the stack is false, the statement is executed and the value at the top of the stack is removed. OP_ROLL, an item n items deep in the stack is moved to the top OP_SUBSTR, returns a section of a string OP_SWAP, the top two items on the stack are swapped OP_TOALTSTACK, puts the input on top of the alternate stack and removes it from the main stack OP_VERIFY, which marks the transaction as invalid if the value at the top of the stack is not true

[0218] In one embodiment, an ECDS creation script can be created using the operation code, OP_GENSIG, which can be extended to create a signature creation script, OP_GENSIG, by adding a SIGHASH byte to the end. [Table 1]

[0219] In the above script,<SIGHASH Byte> ,message <m>Secret Key , and number <k>are entered into the main stack (last-in first-out) in the above order.<PubK G> OP_ECPMULT" <k>is copied to the alternate stack, and <k>is an elliptic curve generator<PubK G> to create the elliptic curve point K on the top of the main stack. <n>OP_BIGMOD OP_DUP OP_TOALTSTACK" computes r from the x-coordinate of K modulus n. A copy of r is pushed onto the alternate stack. <n>OP_BIGMODMUL <n>OP_BIGMODADD OP_FROMALTSTACK OP_SWAP OP_FROMALTSTACK <n>OP_BIGMODINVERSE <n>OP_BIGMODMUL" execution, k -1 Calculate s from (m+r×a) mod n. Finally, the execution of the script operation "OP_DERENCODE OP_SWAP OP_CAT" is encoded in DER format and<SIGHASH Byte> This produces r and s concatenated with . In this disclosure, this script is referred to as OP_GENSIG. Therefore, references to OP_GENSIG in embodiments of this disclosure should be considered as a shorthand for the operations performed in the above script.

[0220] Figure 3 is an example 300 illustrating a problem related to blockchain transactions that is solved by one embodiment of the present disclosure. In the example 300, which is the embodiment shown in Figure 3, the locking script 306 in the previous transaction 302 cannot directly read fields in the unlocking transaction 304. As noted, in some embodiments, the previous transaction 302 is the most recent, confirmed transaction included in the blockchain. Similarly, in some embodiments, the unlocking transaction 304 is a future transaction that has not yet been confirmed and has not yet been included in the blockchain. This represents an attempt to reassociate at least a portion of the digital assets controlled by the previous transaction 302.

[0221] As described above, in some embodiments, the locking script 306 is a script that secures a transaction by specifying conditions that must be met to transfer an output. More specifically, an executing locking script 306, upon execution by a validating node of a blockchain system, is configured to accept data from an executed unlocking script, perform predetermined operations based on the data, and return a result indicating whether execution of the unlocking script successfully “unlocked” the locking script (i.e., satisfied the conditions set therein). In some embodiments, the locking script 306 defines one or more data constraints that must be satisfied (e.g., by data provided via the unlocking script) for successful validation of the transaction. For example, the locking script 306 may require predetermined data provided in the unlocking script to unlock the digital asset associated with the previous transaction 302.

[0222] 4 depicts an example 400 illustrating that the unlocking script 408 of the present disclosure has access to fields of the unlocking transaction 404 in one embodiment (e.g., a set of unlocking transaction fields determined depending on the SIGHASH type) different from the locking script 406 of the previous transaction 402. In some embodiments, the previous transaction 402 is similar to the previous transaction 302 of FIG. 3. In some embodiments, the unlocking transaction 404 is similar to the unlocking transaction 304. In some embodiments, the locking script 406 has similar characteristics to the locking script 306 of FIG. 3.

[0223] In some embodiments, the unlocking script 408 is an executable script placed at the input of a transaction that attempts to satisfy a set of conditions placed on the output of the transaction by the locking script. The unlocking script is also known as a "scriptSig." As described above, the unlocking script 408 has been designed to provide a set of unlocking transaction fields determined according to the SIGHASH type as input to the unlocking script, thereby providing the unlocking script with access to the fields of the unlocking transaction. Further details regarding the content and structure of serialized transactions are found in the description of FIG. 5 below. Note that in embodiments, transactions 402 and 404 include additional fields. For example, in some embodiments, "nVersion" refers to the version of the blockchain protocol, "#vin" refers to the count of the number of inputs in the transaction, "hash" refers to the pay-to-public-key-hash of the entity to which the digital asset is being recombined, "#vout" refers to the count of the number of outputs in the transaction, "nValue" refers to the amount of unspent digital asset remaining, and "nLockTime" refers to the timestamp of when the transaction becomes final.

[0224] FIG. 5 illustrates one embodiment 500 of how a serialized set of transaction fields is formed. As shown in FIG. 5, a serialized transaction 510 (i.e., a transaction represented as a series of bytes in a specific format) includes a set of transaction field values. A signer selects a SIGHASH type and a number k at 512. This number k is typically a random or pseudo-random number to mask / protect the private key and is therefore sometimes referred to as a "mask number" in this disclosure. A modified copy of transaction 514 is an example of a set of serialized transaction 510 fields selected according to the specified SIGHASH type (e.g., SIGHASH_NONE+ANYONECANPAY in embodiment 500). The signer hashes the modified copy of transaction 514 (e.g., with a double SHA-256 hash), resulting in message m 516. The signer then creates a signature using the SIGHASH type, the message m, the signer's private key, and the number k, such as in the manner described above in connection with FIG.

[0225] The following table shows one example of a typical unlocking and locking script whereby the expected signature of entity A specified in the unlocking script is checked against entity A's public key using the OP_CHECKSIG operation code. [Table 2]

[0226] Thus, with the signature creation understanding of FIG. 5, the following table shows an example of an unlocking script and a locking script when portions of the procedure shown in example 500 are moved into the unlocking script. [Table 3]

[0227] The unlocking script may be further modified to include the step of calculating the message m within the unlocking script. [Table 4]

[0228] However, note that, except for the SIGHASH type and the set of unlocking transaction fields determined depending on the SIGHASH type, other operations of the procedure can be moved to the locking script. [Table 5]

[0229] Therefore, in the locking script, "OP_HASH256< / n> < / n> < / n> < / n> < / n> < / k> < / k> < / k> <k>By moving the operation "OP_GENSIG", the unlocking script will include the SIGHASH type and a set of unlocking transaction fields determined depending on the SIGHASH type to be valid.

[0230] In this way, the serialized previous transaction is injected into the locking script. The following table shows how the locking and unlocking scripts execute the procedure for each step of the example 500 and verify the transaction. [Table 6]

[0231] In this disclosure, the above script may be referred to as OP_UNLOCKINGTXINJECTION. Accordingly, references to OP_UNLOCKINGTXINJECTION in embodiments of the present disclosure should be considered as a shorthand for the operation performed by the above script. Note, however, that any entity that provides a SIGHASH type and a set of unlocking transaction fields determined according to the SIGHASH type can receive the transaction output. However, this becomes a useful feature, as explained in more detail below. As noted above, in some embodiments, receiving a transaction output refers to creating an unlocking transaction that references the transaction output and evaluates to be valid, thereby causing the transaction output to be received.

[0232] 6 is a flowchart illustrating one example of a process 600 for injecting a set of unlocking transaction fields determined according to a SIGHASH type, according to one embodiment, according to various embodiments. Some or all of process 600 (or any other described process, or variations and / or combinations of these processes) may be performed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions that collectively execute 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 may be persistently stored on a magnetic, optical, or flash medium).

[0233] For example, some or all of process 600 may be performed by a validator node in a blockchain network, such as the example blockchain network 100 of FIG. 1. Such a validator node may be comprised of any suitable computing device (e.g., a server in a data center, a client computing device, multiple computing devices in a distributed system of a computational resource service provider, or any suitable electronic client device, such as computing device 2600 of FIG. 26). Process 600 includes a series of operations in which a system performing process 600 jointly executes the locking script and unlocking script of an unvalidated transaction in the manner described in FIG. 5, and thereby obtains a SIGHASH type and transaction field value set, creates a signature, and verifies the signature.

[0234] At 602, the system obtains an unvalidated transaction from an entity seeking to rebind at least a portion of a digital asset. The unvalidated transaction includes a locking script and an unlocking script. The unlocking script is executed by the system before executing the locking script. The unlocking script may be similar to the unlocking script shown in Tables 5 and 6 above and specifies a SIGHASH type and includes a serialized set of fields of the unvalidated transaction. As a result, at 604 and 606, the system executing process 600 obtains the SIGHASH type and the serialized set of transaction field values ​​of the unvalidated transaction from the unlocking script and places them in the main stack. Once execution of the unlocking script completes successfully, the system begins execution of the locking script using the state of the main stack (and, in some implementations, the state of the alternate stack) upon completion of execution of the unlocking script. The locking script may be similar to the locking script shown in Tables 5 and 6 above.

[0235] At 608, in accordance with the locking script, the system creates a signature using at least the SIGHASH type, the set of transaction field values ​​placed on the main stack as a result of executing the unlocking script, and the private key associated with the public key pair. At 610, in accordance with the locking script, the system successfully verifies the signature against the public key of the key pair. In this way, the set of transaction fields is injected into the locking script by the unlocking script. Note that operations 602-610 may be performed in various orders and combinations depending on the implementation, and that some of the operations may be performed in parallel with other operations of process 600.

[0236] FIG. 7 is an example 700 illustrating a problem related to blockchain transactions that is solved by one embodiment of the present disclosure. That is, in the example 700 shown in FIG. 7, the locking script 706 cannot read the inputs of the transaction in which it is embedded, and therefore cannot directly read fields of the previous transaction. In some embodiments, the transaction 704 is similar to the unlocking transaction 304 of FIG. 3, which represents an attempt to rebind at least a portion of the digital assets controlled by the previous transaction. As mentioned above, in some embodiments, the locking script 706, similar to the locking script 306 of FIG. 3, is a script that secures a transaction by specifying conditions that must be met to transfer an output.

[0237] Figure 8 illustrates an embodiment 800 in which an unlocking script 808 includes a serialized previous transaction by extracting a transaction ID and performing constraint checking. Specifically, Figure 8 illustrates an unlocking transaction 804 having an unlocking script 808 that utilizes output from a previous transaction 802A-802B. As can be seen, the unlocking script 808 causes the serialized previous transaction to be retrieved. In some embodiments, the serialized previous transaction references an unmodified version of the field value set of the previous transaction.

[0238] The embodiment shown in Figure 8 can be understood by observing that the transaction ID is the double SHA-256 of the serialized transaction, and that transaction IDs have a one-to-one mapping to transactions. Therefore, by applying the constraints shown in Table 7 below, transactions can be injected into the unlocking script. [Table 7]

[0239] Embodiments of the present disclosure further improve this injection by causing the injection of not only any serialized transaction, but also one or more serialized previous transactions (e.g., previous transactions 802A-802B) referenced in the input of the unlocking transaction 804. As discussed above with reference to Figure 7, a set of unlocking transaction fields determined depending on the SIGHASH type can be injected into the locking script via the unlocking script 806. Figure 9 then shows which fields are included in the serialized transaction depending on the specified SIGHASH type.

[0240] Figure 9 shows an example 900 of the set of fields that are available in a serialized transaction depending on the specified SIGHASH type. Note, however, that Figure 9 is intended to be illustrative, and that in various embodiments, there are more SIGHASH types than are shown in Figure 9. As shown in Figure 9, for different SIGHASH types, different sets of previous transaction IDs are included in the set of unlocking transaction fields that is determined depending on the SIGHASH type (note that the "hash" field represents the transaction ID in big endian format). In some embodiments, the transaction ID of the previous transaction that embeds the locking script is always available, regardless of which SIGHASH type is specified.

[0241] Thus, certain fields can be ensured to be present in the set of determined unlocking transaction fields by constraining the SIGHASH type in the following manner: First, duplicate the SIGHASH type. Then, push the SIGHASH type onto the stack (e.g., SIGHASH_ALL). Finally, call OP_EQUALVERIFY. As can be seen in FIG. 9, SIGHASH_ALL (as shown in unlocking transaction 904A) includes hashes, which represent the transaction IDs of previous transactions y and z, as described above. In contrast, SIGHASH_ALL+ANYONECANPAY (as shown in unlocking transaction 904B) includes only the hash of the immediately preceding transaction y. In some embodiments, unlocking transactions 904A-904B are similar to unlocking blockchain transaction 204 of FIG. 3, representing an attempt to rebind at least a portion of the digital assets controlled by previous transactions (e.g., transactions y and / or x). Extracting the transaction ID can be accomplished by parsing the serialized transaction using a substring operation code until the desired field is reached, as shown in FIG.

[0242] FIG. 10 illustrates an example 1000 of extracting a transaction ID in one embodiment of the present disclosure. Specifically, FIG. 10 illustrates that hash 1020, consisting of the transaction ID in big-endian format, is a substring of the serialized transaction 1010 that can be extracted by using a substring operation code in the script. In some embodiments, because some fields (e.g., #vin, scriptSigLen, scriptSig, scriptPubKeyLen, and scriptPubKey) are of variable byte length, the serialized transaction 1010 is first parsed to identify the location of hash 1020 before the transaction ID is extracted. However, it is contemplated that in implementations where the fields have fixed lengths, parsing may not be required.

[0243] Thus, in some embodiments, the previous transaction ID may be made accessible by constructing a locking script that causes the injection of a particular serialized previous transaction referenced in the unlocking transaction in the manner described with reference to Figure 6. For example, first the SIGHASH type constraint is determined, the transaction ID is extracted, and then the serialized previous transaction is duplicated and checked against the transaction ID extracted (according to the SIGHASH type) from the serialized field set of the unlocking transaction. Note that this process may be performed to cause the injection of multiple different serialized previous transactions. As an example, Table 8 shows a script that causes the injection of a previous transaction corresponding to input X of the unlocking transaction. [Table 8]

[0244] In the above script, OP_EXTRACTXID is an operation code / script that takes data including the transaction ID and the location of the transaction ID as input and output of the extracted transaction ID. In this disclosure, the above script may be referred to as OP_PREVTXINJECTION. Therefore, references to OP_PREVTXINJECTION in embodiments of the present disclosure should be considered as shorthand for the operation performed in the above script.

[0245] Note, however, that any entity that provides a SIGHASH type, a set of unlocking transaction fields determined according to the SIGHASH type, and a serialized previous transaction can obtain the transaction output, although this is a useful feature, as explained in more detail below.

[0246] As another example, Table 9 shows a script that causes the injection of a previous transaction corresponding to a signed input. [Table 9]

[0247] In this disclosure, the above script in Table 8, as well as the script in Table 8, may also be referred to as OP_SELFTXINJECTION. Therefore, references to OP_SELFTXINJECTION in embodiments of the present disclosure should be considered as shorthand for the operations performed in the above script.

[0248] Note also that any entity that provides a SIGHASH type, a set of unlocking transaction fields determined according to the SIGHASH type, and a serialized previous transaction can capture the transaction output. However, this is a useful feature, as explained in more detail below. As noted above, in some embodiments, capturing the transaction output means creating an unlocking transaction that references the transaction output and successfully validating the unlocking transaction.

[0249] 11 is a flowchart illustrating one example of a process 1100 for injecting serialized prior transactions, according to various embodiments. Some or all of process 1100 (or any other described process, or variations and / or combinations of these processes) may be performed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions that collectively execute on one or more processors. The executable instructions and / or other data may be stored in a non-transitory computer-readable storage medium (e.g., a computer program may be persistently stored on a magnetic, optical, or flash medium).

[0250] For example, some or all of process 1100 may be performed by a validator node in a blockchain network, such as the example blockchain network 100 of FIG. 1. Such a validator node may be comprised of any suitable computing device (e.g., a server in a data center, a client computing device, multiple computing devices in a distributed system of a computational resource service provider, or any suitable electronic client device, such as computing device 2600 of FIG. 26). Process 1100 includes a series of operations in which a system performing process 1100 executes the locking script and the locking script of an unvalidated transaction together, and thereby obtains a serialized previous transaction corresponding to the transaction ID extracted from the unvalidated transaction.

[0251] At 1102, the system obtains an unvalidated transaction from an entity seeking to rebind at least a portion of a digital asset. The unvalidated transaction includes a locking script and an unlocking script. The locking script and unlocking script may be similar to the locking script and unlocking script shown in Tables 8 and 9 above. That is, the locking script includes a set of instructions that take as input values ​​stored in the main stack and alternate stack, as per the unlocking script. Execution of the set of instructions successfully validates the unvalidated transaction if it evaluates to TRUE. Thus, the unlocking script executes before the locking script, setting values ​​in the main stack and alternate stack used by the locking script. The unlocking script of the unvalidated transaction in the embodiment of FIG. 11 includes a serialized previous transaction, a SIGHASH type, and a serialized set of unlocking transactions.

[0252] As a result of executing the locking script followed by the unlocking script, at 1104, the system obtains the serialized previous transaction, the SIGHASH type, and the serialized set of unlocking transaction fields included in the unlocking script. At 1106, the system creates a signature based on the serialized set of field values ​​of the unverified transaction based on the SIGHASH. Note that the SIGHASH type affects which fields are used in signature creation, and the desired SIGHASH may depend on the particular previous transaction sought. For example, Table 8 shows a locking script and an unlocking script for extracting previous transactions, but not necessarily previous transactions containing the same locking script, utilizing a SIGHASH type of SIGHASH_ALL. As shown in Figure 9, the SIGHASH_ALL type allows for the search of other previous transaction entries for the unlocking transaction. In contrast, Table 9 shows the locking and unlocking scripts for extracting previous transactions with the same locking script (i.e., previous transactions corresponding to the signed input), using a SIGHASH type of SIGHASH_ALL|ANYONECANPAY. As shown in Figure 9, the SIGHASH type of SIGHASH_ALL|ANYONECANPAY removes inputs of other previous transactions other than the previous transaction with the signed input.

[0253] At 1108, the system verifies the previously created signature and then, at 1110, creates a value that matches the unlocking transaction's transaction ID (i.e., the serialized set of field values) by performing a double SHA-256 of the obtained serialized previous transaction. Using the substring operation code, at 1112, the system extracts the transaction ID of the serialized set of field values, and at 1114, the system determines whether the transaction ID created by the double SHA-256 of the serialized previous transaction matches the transaction ID of the serialized set of field values. Note that in various embodiments, a match does not necessarily require equality. For example, two values ​​may match if they are mathematically equivalent without being equal. As another example, two values ​​may match if they correspond to a common object (e.g., value) or are complementary in some predetermined way, and / or they meet one or more match criteria. In general, any method for determining whether a match exists may be used. Also, note that one or more of the operations performed in 1102-1114 may be performed in various orders and combinations, including in parallel.

[0254] Figure 12 shows an example 1200 illustrating a problem associated with locking scripts that is solved by one embodiment of the present disclosure. That is, the example 1200 shown in Figure 12 illustrates a problem presented by providing pending data to a locking script. In some embodiments, the term "undetermined data" refers to data provided via an unlocking script that unlocks a locking script, of which the node executing the locking script does not have a prior indication.

[0255] In some embodiments, previous transaction 1202 is similar to previous transaction 302 in Figure 3. Similarly, in some embodiments, unlocking transaction 1204 is similar to 304. In some embodiments, blockchain 1224 consists of a set of blocks of transactions in a peer-to-peer electronic ledger. In embodiments, each block in blockchain 1224 contains a hash of the prior block so that the blocks are linked together (i.e., "chained"), creating a permanent, immutable record of all validated transactions in the blockchain.

[0256] In some embodiments, undetermined source 1222A may be an entity attempting to acquire the UTXO of a previous transaction 1202. Undetermined source 1222B may be the same as undetermined source 1222A, or may be a different entity than undetermined source 1222A. In either case, the node executing the locking script has no prior knowledge of undetermined source 1222A-1222B prior to executing the locking script.

[0257] In the embodiment 1200, the locking script 1206 is blank, allowing it to accept data without prior knowledge of the source of the data or what the data is. <d>" is determined at the time the unlocking transaction 1204 is created (e.g., by pending source 1222A). However, such locking scripts present security concerns because the unlocking transaction 1204 is subject to modification (in other words, is mutable), such as by pending source 1222B, before it is confirmed in the blockchain 1224 (at which point the unlocking transaction 1204 becomes immutable).

[0258] FIG. 13 illustrates an example 1300 illustrating how undetermined data from a determined source can be securely fed into a locking script 1306 in one embodiment of the present disclosure. That is, the example 1300 illustrated in FIG. 13 illustrates a problem presented in a situation where the node executing the locking script 1306 has prior knowledge of the source (e.g., determined source 1326). The prior knowledge provides the data, but not prior knowledge of what the data will be. In some embodiments, the previous transaction 1302 is similar to the previous transaction 302 of FIG. 3. Similarly, in some embodiments, the unlocking transaction 1304 is similar to 304. In some embodiments, the blockchain 1324 is similar to the blockchain 1224 of FIG. 12.

[0259] In embodiment 1300, the locking script 1306 is configured to cause a validating node executing the locking script 1306 to check whether the data provided in the unlocking script 1308 is provided by a determined data source. That is, the private key can be modified based on the data (d) to create a modified private key (a') by performing a multiplication by the data in the following manner: a'=a×d

[0260] The public key (A), which is the counterpart of the unmodified private key, can be similarly modified by performing elliptic curve point multiplication to produce the modified public key (A') in the following manner: A'=d×A

[0261] As a result, the locking script 1306 may be configured to cause the validating node to evaluate a signature signed using a public key (A) for the data source, with a private key modified based on the data. More specifically, a signature verification operation code may be included in the locking script 1306 to verify whether the signature (Sig A') signed using the modified private key corresponds to the modified public key and is therefore a valid signature. The verification may be performed, for example, using the OP_CHECKSIG operation code.

[0262] As can be seen in example 1300, execution of locking script 1306 causes the node to place a public key on the stack and then perform an elliptic curve point multiplication operation (OP_ECMULT) between the public key and the data placed in the stack by a previous execution of locking script 1308. The data can then be determined at the time the unlocking transaction is created by a source specified in the locking script (e.g., determined source 1326). Thus, the locking script has knowledge of the source providing the data, but not of what the data will become. Further execution of locking script 1306 results in a verification result for the signature of the data signed using the modified private key (e.g., OP_CHECKSIG returns TRUE if the values ​​match). This approach is secure because any changes to unlocking transaction 1304 invalidate it. However, the source of the data (determined source 1326) must be specified. The signature verification algorithm in ECDSA involves checking whether the signature, public key, and message have a specific mathematical relationship. The message can be any data. In Bitcoin, the validation operation code, OP_CHECKSIG, prevents any arbitrary data from being a message by restricting messages to those that are serialized transactions, while still allowing messages to be verified as coming from a particular source. Embodiments of the present disclosure provide an alternative solution to this restriction.

[0263] In some embodiments, the undetermined source 1322 is an entity that cannot change the data. In some embodiments, the determined source 1326 is an entity that is known at the time the locking script 1306 is created, and thus the locking script 1306 includes the public key of the determined source 1326.

[0264] Figure 14 shows an example 1400 illustrating how pending data can be securely provided from a pending source into a locking script 1406. Specifically, Figure 14 shows an unlocking transaction 1404 that executes a locking script based on the locking script described in conjunction with process 1100 of Figure 11. In some embodiments, previous transaction 1402 is similar to previous transaction 302 of Figure 3. Similarly, in some embodiments, unlocking transaction 1404 is similar to 304. In some embodiments, blockchain 1424 is similar to blockchain 1224 of Figure 12.

[0265] 13 in that the data in embodiment 1400 may be undetermined at the time locking script 1406 is created. The data in question may be embedded somewhere in the previous transaction 1402 and may therefore be extracted by parsing the serialized previous transaction, as described above in connection with FIGS. 8-11 above.

[0266] In this way, the node executing the locking script 1406 does not need to have prior knowledge of the entity providing the serialized previous transaction, nor does the node need to have prior knowledge of the previous transaction 1402. Furthermore, the previous transaction 1402, which is committed to the blockchain 1424, is already immutable at the time the unlocking transaction 1404 is created and is thereby protected from modification without causing the unlocking transaction 1404 to become invalid. However, the node executing the locking script 1406 does not have prior knowledge of the data, which was determined at the time the previous transaction 1402 was created.

[0267] In some embodiments, locking script 1406 is a script according to the script described with respect to process 1100 of Figure 11. In some embodiments, unlocking script 1408 is similar to the unlocking script described with respect to Figures 8-11. For example, as can be seen in example 1400, unlocking script 1408 includes at least one serialized previous transaction, a SIGHASH type, and a serialized set of unlocking transaction fields of unlocking transaction 1404.

[0268] Pending source 1422A is the entity that supplies the data encoded in the serialized previous transaction. Pending source 1422B is the entity that intercepts and attempts to modify unlocking transaction 1404. In some embodiments, pending sources 1422A-1422B may be the same or different entities. As can be seen in example 1400, the identity of pending source 1422A need not be known at the time locking script 1406 is created. Furthermore, the data also need not be known at the time locking script 1406 is created. Nevertheless, pending source 1422B is still prevented from modifying the data.

[0269] In embodiments, various fields of the previous transaction 1402, other than the locking script executed by the unlocking transaction 1404, can be used to store secure, pending data, including the amount of a digital asset in the output of the previous transaction 1402, or metadata encoded in the locking script of another output of the previous transaction 1402. Thus, an embodiment of example 1400 allows virtually any entity to embed data in the previous transaction, pay for some variation of the locking script 1406, and ensure that no other entity can change the data. This feature is useful in further embodiments described below.

[0270] 15 is a flowchart illustrating one example of a process 1500 for securely providing pending data, according to various embodiments. Some or all of process 1500 (or any other described process, or variations and / or combinations of these processes) may be performed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions collectively executing on one or more processors. The executable instructions and / or other data may be stored in a non-transitory computer-readable storage medium (e.g., a computer program persistently stored on magnetic, optical, or flash media).

[0271] For example, some or all of process 1500 may be performed by a validator node in a blockchain network, such as the example blockchain network 100 of FIG. 1. Such a validator node may be comprised of any suitable computing device (e.g., a server in a data center, a client computing device, multiple computing devices in a distributed system of a computational resource service provider, or any suitable electronic client device, such as computing device 2600 of FIG. 26). Process 1500 includes a series of operations in which an unvalidated transaction is received, pending data and a second value is obtained as a result of execution of an unlocking script, and the pending data is validated as associated with a trusted data source.

[0272] At 1502, the system obtains an unvalidated transaction from an entity seeking to rebind at least a portion of a digital asset. The unvalidated transaction includes a locking script and an unlocking script. The locking script and the unlocking script may be similar to the locking script and the unlocking script shown in Figures 13 and 14. Execution of the instruction set successfully validates the unvalidated transaction if it evaluates to TRUE. Thus, the unlocking script executes before the locking script and sets values ​​for the main stack and the alternate stack used by the locking script.

[0273] The unlocking script for unconfirmed transactions in the embodiment of FIG. 13 is <d>”), and the signature of the pending data signed using the modified private key (”<SigA’> ”). The modified private key is modified by multiplying the private key of a determined data source (e.g., “Bob”) by the value of the undetermined data using elliptic curve point multiplication. The private key would therefore be a point on the elliptic curve. As noted above, the term “undetermined” in this context means that the data is not specified or otherwise constrained by the locking script itself. Similarly, an “undetermined data source” is a data source whose identity is not specified or constrained by the locking script, while a “determined data source” has constrained its identity to be a particular data source within the locking script (e.g., by including the data source's public key). The unlocking script for an unvalidated transaction in the embodiment of FIG. 14 includes the serialized pending data of the previous transaction, the SIGHASH type, and a serialized set of unlocking transaction fields. In this way, the data source does not need to be specified or constrained by the locking script itself, since the data source is serialized pre-transaction.

[0274] As a result of executing the unlocking script followed by the locking script, at 1504 the system obtains the pending data and a value that can be used to verify the data using a determined or pending source associated with the data (e.g., a signature signed with the modified private key or a serialized set of unlocking transaction fields from which a transaction identifier can be extracted).

[0275] At 1506, the system verifies the data. For example, in the embodiment of Figure 13, the system verifies that the data is associated with a public key included in the locking script by modifying the public key with the data using elliptic curve point multiplication (as described above), and then verifies that the modified public key is associated with a signature created using a corresponding private key that was itself modified using elliptic curve point multiplication. As another example, in the embodiment of Figure 14, the system verifies that the data corresponds to a particular previous transaction by determining whether a serialized hash of the previous transaction matches a transaction ID extracted from the serialized set of unlocking transaction fields in the manner of process 1100 of Figure 11. Note that one or more of the operations performed in 1502-1506 may be performed in various orders and combinations, including in parallel.

[0276] FIG. 16 illustrates an example of a parameterizable smart contract 1600 according to one embodiment of the present disclosure. Specifically, FIG. 16 illustrates a previous transaction 1602 having a locking script 1606 that imposes constraints on the unlocking script 1608 of the unlocking transaction 1604. The embodiment illustrated in FIG. 16 can be understood by recalling that, in the discussion of FIGS. 3-6, this disclosure has described how a set of unlocking transaction fields determined according to the SIGHASH type can be injected into the locking script 1606. Recall further that, in the discussion of FIGS. 7-11, this disclosure has described how a set of unlocking transaction fields determined according to the SIGHASH type can be parsed using a substring operation code to extract the transaction ID before applying constraints so that a serialized previous transaction can be injected into the locking script 1606. This process can be extended to work with any field in the set of unlocking transaction fields.

[0277] Note that the locking script described in the context of Figures 6 and 11 does not impose restrictions on the particular entity creating the unlocking transaction. For example, the locking script does not require proof that a particular entity has access to a secret (e.g., a private key, a value that creates a particular hash, etc.). The embodiment of Figure 16 applies this concept to be non-discriminating with respect to the particular entity creating the unlocking transaction, but imposes certain constraints on how UTXOs can be claimed. In this way, the embodiment of Figure 16 is automatically executed and self-enforcing. In other words, if the conditions of the smart contract are not met (i.e., the specified constraints are not followed), validation fails and the contract is not executed.

[0278] In some embodiments, the smart contract in the locking script can be made interactive by imposing constraints (e.g., parameters) on the input of the unlocking transaction 1604 (e.g., requiring input from "Alice"). Because the unlocking script 1608 is an input source for the unlocking script 1606, in embodiments, the smart contract in the locking script 1606 can be parameterized using secure, undetermined data in the unlocking script 1608. In embodiments, the parameterized data is undetermined and secure in the manner described in connection with Figures 13-15 to protect the smart contract from modification. In embodiments, the parameterized data is undetermined.

[0279] This disclosure has described two methods for providing secure, pending data to a locking script (e.g., a smart contract). The first method is to obtain the secure, pending data from a determined source, as described in the context of FIGS. 13 and 15. The second method is to obtain the secure, pending data from a pending source (e.g., a previous transaction), as described in the context of FIGS. 14-15. In embodiments using the first method, the parameters would be determined by the entity creating the unlocking transaction and set when the unlocking transaction is created (e.g., in the unlocking script 1608). In embodiments using the second method, the parameters would be determined by the entity creating the previous transaction and set when the previous transaction is created (i.e., embedded in the serialized previous transaction). It is also noted that in embodiments, the first and second methods may be combined, such that one or more parameters may be embedded in the previous transaction and one or more other parameters may be embedded in the unlocking script of the unlocking transaction.

[0280] The following example is presented to illustrate how smart contracts can be created using these methods. In this example, a smart contract is created for or by Alice to transfer 70% of her income to savings and 30% of her income to her investment manager, Bob. Her savings account is associated with cryptographic public key A (PubK A), and her account with Bob is associated with cryptographic public key B (PubK B). Alice's employer executes this smart contract, causing Alice's income to be distributed in the manner described above on payday. Thus, Alice's income is automatically segregated as she desires.

[0281] In this example, the parameter is the amount of digital assets to be transferred as a result of smart contract execution. Execution of the smart contract causes the parameter to be extracted from the previous transaction 1602 before determining constraints on the output of the unlocking transaction 1604 according to the above criteria. Table 10 shows an example of an unlocking script and a locking script for implementing the above example. [Table 10-1] [Table 10-2]

[0282] 17 is a flowchart illustrating one example of a process 1700 for implementing parameterized smart contracts, according to various embodiments. Some or all of process 1700 (or any other described process, or variations and / or combinations of these processes) may be performed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions that collectively execute 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 may be persistently stored on a magnetic, optical, or flash medium).

[0283] For example, some or all of process 1700 may be performed by a validator node in a blockchain network, such as the example blockchain network 100 of Figure 1. Such a validator node may be comprised of any suitable computing device (e.g., a server in a data center, a client computing device, multiple computing devices in a distributed system of a computational resource service provider, or any suitable electronic client device, such as computing device 2600 of Figure 26). Process 1700 includes a series of operations in which constraints are extracted from parameters embedded in secure, pending data.

[0284] At 1702, the system executes a script that causes the injection of a serialized previous transaction (e.g., the serialized field values ​​of previous transaction 1602 of FIG. 16), a SIGHASH type, and a set of unlocking transaction fields determined according to the SIGHASH type (e.g., the field values ​​of unlocking transaction 1604). The script may be a variation of the script from Table 8 or Table 9. Note that process 1100 of FIG. 11 may not be required in its entirety for the parameterizable smart contracts of FIGS. 16 and 17, as the serialized previous transaction may not be required if parameters from a pending source are not required.

[0285] At 1704, the system extracts the parameters in a manner that depends on whether the source of the parameters is an undetermined source or a determined source. For example, extracting the parameters from data of a determined source may be performed by extracting the parameters from the unlocking script 1608 in the manner described in connection with Figure 13. As another example, extracting the parameters from data of an undetermined source may be performed by extracting the parameters from a serialized previous transaction in the manner described in connection with Figure 14. As yet another example, if some parameters are embedded in data of an undetermined source and some parameters are received from a determined source, a script can be written to combine the operations of Figures 13 and 14 to extract parameters from data coming from both the undetermined source and the determined source.

[0286] At 1706, the system derives constraints from the parameters. For example, in the example script of Table 10, the parameter is the amount to be paid to the smart contract, and deriving the constraints includes determining the payment amounts (e.g., 70% and 30%) to transfer to Alice and Bob's pay-to-public-key (P2PK) addresses. However, it is contemplated that the parameters and constraints that can be derived from the parameters can be numerous and varied beyond the above example.

[0287] At 1708, the system verifies the constraints against the set of unlocking transaction field values ​​determined according to the SIGHASH type. That is, the system verifies that the relevant subset of the unlocking transactions satisfies the constraints. If the relevant subset of the unlocking transactions satisfies the constraints, the unlocking transactions are validated as valid. Otherwise, if the relevant subset of the unlocking transactions does not satisfy the constraints, the unlocking transactions are deemed invalid. Note that one or more of the operations performed at 1702-1708 may be performed in various orders and combinations, including in parallel.

[0288] FIG. 18 illustrates an example 1800 of a problem associated with repeating smart contracts that is solved by embodiments of the present disclosure. That is, to create a transaction that repeats a known number of times (e.g., five times), a known number of unlocking transactions could be created in advance. While this may be manageable for a small number of transactions, for contracts with many repeated transactions, creating all of the unlocking transactions 1804A-1804N in advance would become cumbersome, and the scripts 1806A-1806N could become very large. For example, Alice has an amount of digital asset (e.g., Bitcoin) that has value that can be exchanged for goods or services. Alice has allocated this amount to be used by her son, Bob, to pay for his school lunches each day. The example 1800 of FIG. 18 illustrates that Alice could create unlocking transactions 1804A-1804N in advance for each of Bob's individual lunch transactions. However, as shown in FIG. 19, the present disclosure contemplates an alternative solution for Alice.

[0289] FIG. 19 illustrates an example 1900 of a self-replicating smart contract according to an embodiment of the present disclosure. As shown in FIG. 19, rather than creating a predetermined number of unlocking transactions to achieve a repeating contract, a self-replicating smart contract 1904 with a termination condition can be created based on the parameterizable smart contract described in connection with FIGS. 16-17. Thus, in the above example, Alice only needs to create one unlocking transaction to deplete the initial amount of digital assets in the previous transaction 1902. The unlocking transaction 1904A includes a script that causes the unlocking transaction 1904A to replicate itself into the next unlocking transaction. The script includes a termination condition that causes the unlocking transaction 1904N to stop replicating after the termination condition is met (e.g., after n occurrences).

[0290] In one possible implementation, future transactions are created in advance to create a chain of transactions for the contract, and the locking script of each transaction embeds the locking script of its successive transaction, as shown in Figure 20. However, for self-replicating unlocking transactions, to verify that the constraints of the unlocking transaction have not changed, it would be necessary to securely verify that the locking script of each previous transaction (e.g., smart contract) matches the locking script of the unlocking transaction.

[0291] FIG. 20 illustrates an example 2000 of a problem involving repeated transactions that is solved by an embodiment of the present disclosure. That is, the locking script of a previous transaction 2002 (locking script 0) incorporates the locking script of a first unlocking transaction 2004A (locking script 1), which itself incorporates the locking script of a second unlocking transaction 2004B (locking script 2), and so on up to the final unlocking transaction 2004N. When fully unfolded, it becomes clear that locking script 0 is not identical to locking script 1, which is not the same as locking script 2, and so on. Thus, example 2000 cannot be said to be self-duplicating because the locking scripts are not identical. This problem can be understood as stemming from self-referencing. That is, a locking script would need to embed a copy of itself, resulting in an unending and unravelable loop. Thus, the locking scripts will be undeterminable. Embodiment 2000 fixes the number of times (n) the loop can unravel before assigning a value to the nth locking script. Thus, n-1 locking scripts can embed n locking scripts, n-2 locking scripts can embed n-1 locking scripts, and so on. However, this results in n different locking scripts.

[0292] Figure 21 illustrates an example solution 2100 to the problems associated with a naive implementation of self-replicating transactions. Specifically, Figure 21 illustrates duplicating a smart contract that reduces the amount of digital assets sent to itself by one unit each time and also pays one unit of digital assets to Alice. That is, a previous transaction 2102 holds an initial amount X. A first unlocking transaction 2104A pays one unit of digital assets to a pay-to-public-key-hash (P2PKH) address belonging to Alice, outputs a new sum (X' = X - 1), and then replicates itself to a second unlocking transaction 2104B. In some embodiments, a P2PK or P2PKH can be used as an address to direct the transfer of digital assets to entities associated with the respective public keys. The second unlocking transaction 2104B again pays one unit of the digital asset to Alice, outputs a new sum (X" = X' - 1), and then replicates itself again.

[0293] Therefore, it can be seen that if the process continues regardless of the initial amount X, an unlocking transaction will eventually be created to output an unredeemable amount of the digital asset (e.g., zero). This can be intuitively understood by observing that each subsequent unlocking transaction has a smaller amount of the digital asset than the previous transaction, even without subtracting a minimum transaction fee in various blockchain protocols. As a result, the amount of output converges toward zero, at which point processing of the transaction becomes pointless. However, embodiments of the present disclosure include a solution to this problem by implementing a termination condition to avoid such unredeemable unlocking transactions.

[0294] 20 is to have locking script 1 receive first data (e.g., unlocking transaction data) and second data (e.g., previous transaction data), both of which have locking scripts embedded in them. In these embodiments, locking script 1 verifies that the locking scripts from the first data and the second data match. Then, if locking script 1 verifies that the second data (previous transaction data) has locking script 1 embedded in it, it verifies that the first data also has locking script 1 embedded in it.

[0295] The basic outline of such a script is shown in Table 11 below. [Table 11]

[0296] As can be seen from the above script, the locking script of the previous transaction 2102, the currently executing locking script that unlocks the UTXO, is validated against the locking script of the first unlocking transaction 2104A. The first unlocking transaction is the one that will be redeemed in the future if the current unlocking transaction is a previous transaction for another unlocking transaction (e.g., the second unlocking transaction 2104B). Thus, rather than creating a different unlocking transaction for each transaction, as shown in Figures 18 and 20, the script instead enforces that each locking script must be identical. If the locking script of the previous transaction 2102 is identical to the locking script that the second unlocking transaction 2104B attempts to unlock (e.g., the first unlocking transaction 2104A), the locking script is guaranteed to be genuine.

[0297] In embodiments, the termination condition avoids a situation in which a previous transaction has insufficient funds, but the locking script still validates, i.e., an unredeemable transaction. For example, the termination condition can be implemented to verify that sufficient digital assets exist to execute the next transaction, and if not, terminate validation. As a more specific example, if a first pool contains 365 units of digital assets, plus the amount required for each transaction fee (e.g., enough for one transaction per day for a year), the termination condition can verify that the number of remaining units is greater than the number required to complete the transaction. For example, as long as sufficient funds exist, the termination condition continues validating the transaction. Otherwise, if insufficient funds exist, the termination condition is met and validation is aborted. Thus, if there are insufficient funds on the 366th day, there is no need to validate the locking script for the 366th unlocking transaction, and the termination condition ensures that the locking script's self-replication terminates.

[0298] 22 is a flowchart illustrating one example of a process 2200 for a self-replicating smart contract with an exit condition, according to various embodiments. Some or all of process 2200 (or any other described process, or variations and / or combinations of those processes) may be implemented as executable instructions collectively running on one or more processors, performed under the control of one or more computer systems configured with executable instructions and / or other data. The executable instructions and / or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program persistently stored on magnetic, optical, or flash media).

[0299] For example, some or all of process 2200 may be performed by a validator node in a blockchain network, such as the example blockchain network 100 of Figure 1. Such a validator node may be comprised of any suitable computing device (e.g., a server in a data center, a client computing device, multiple computing devices in a distributed system of a computational resource service provider, or any suitable electronic client device, such as computing device 2600 of Figure 26). Process 2200 includes a series of operations in which, if a termination condition is not met, the locking scripts of the unlocking transaction and the previous transaction are verified to be identical, and other constraints are verified.

[0300] At 2202, the system receives an unverified transaction. The system begins by executing the unlocking script of the unverified transaction, and then begins executing the locking script of the previous (verified) transaction associated with the digital asset referenced by the unverified transaction. Process 2200 is shown as executing a variation of the example script of Table 11. For example, at 2204, the system executing process 2200 determines whether an exit condition is met. As mentioned above, in one implementation, the exit condition may be met when an insufficient amount of digital assets exists to complete the transaction. However, it is contemplated that other exit conditions are possible. For example, the exit condition may be time-based. The exit condition may be met if the unverified transaction is not validated before a certain date.

[0301] Once the termination condition is met, process 2200 ends and validation is complete at 2206. Otherwise, the system extracts a first locking script from the unvalidated transaction at 2208. Note that the first locking script is a locking script that is executed after the current unvalidated transaction is validated, such as when another unvalidated transaction attempts to transfer the UTXO of the current transaction.

[0302] At 2210, the system extracts a second locking script from the serialized previous transaction. In this embodiment, the second locking script is a copy of the currently executing locking script. At 2212, the system executing process 2200 determines whether the first locking script matches the second locking script (e.g., whether the two locking scripts are identical). If the locking scripts do not match, at 2214, the system determines that the unvalidated transaction failed validation and remains unvalidated.

[0303] Otherwise, at 2216, the system verifies any remaining constraints in the script (e.g., verifying the digital signature or other requirements of previous transactions). If there are no remaining constraints, or if all remaining constraints are successfully verified, then the transaction is successfully verified. After successful verification, the transaction may be added to the blockchain. Note that one or more of the operations performed at 2202-2216 may be performed in various orders and combinations, including in parallel.

[0304] FIG. 23 illustrates an example problem 2300 solved by one embodiment of the present disclosure. Specifically, FIG. 23 illustrates a state machine transitioning from a first state to a second state using blockchain transactions. In some examples, the state machine's state transitions are described as one or more inputs 2326 and a set of state rules 2306 that determine the next state, given the current state. The example 2300 in FIG. 23 illustrates a previous transaction 2302 having a state rule set 2306 and a first state 2328A embedded in its parameters. In some embodiments, an unlocking transaction 2304 is created to accept input 2326 from a determined source. The input 2326, in combination with the first state 2328A, can be used to reference the state rule set 2306 to determine a second state 2328B embedded in the parameters of the unlocking transaction 2304.

[0305] In an embodiment, the state rule set is a state-transition matrix and can be represented by constraints on the unlocking transaction 2304 in the manner described in connection with Figures 16 and 17. In such an embodiment, the constraints are parameterized by the current state and the inputs from which the next state is determined. The constraints include checks to ensure that the unlocking transaction 2304 contains next state values ​​in specific fields.

[0306] In embodiments, the current state is represented as a parameter embedded in the transaction, and the unlocking transaction 2304 has a next state value also embedded in the unlocking transaction 2304. The next state value is the current state for the smart contract in the set of field values ​​of the unlocking transaction 2304 and, as described above, is accessible when the unlocking transaction 2304 is created. In some embodiments, at least one input is provided as external data, with parameters determined at the time the unlocking transaction 2304 is created. To be secure, such parameters come from a determined source. This provides deterministic state transitions. Finally, by using the self-replicating smart contract script described above in connection with Figures 18-22, one embodiment of a trustless, deterministic state machine is created. In some examples, "trustless" refers to the property that any entity can create a valid unlocking transaction as long as constraints are met. However, in some cases, an entity may need to interact with a determined source to obtain the required inputs. It should be noted that although the various embodiments described in connection with Figures 23-25 ​​refer to obtaining inputs from determined sources, in some embodiments it is contemplated that one or more inputs may be obtained from an undetermined source, such as from a serialized previous transaction.

[0307] FIG. 24 illustrates an example trustless deterministic state machine 2400 according to one embodiment of the present disclosure. As shown in FIG. 24, example 2400 may include a previous transaction 2402 at a first state 2428A (“S1”) in a state rule set 2406. In example 2400, state rule set 2406 provides two possible states 2430A (“S2” or “S3”) for the next state. As can be seen in example 2400, an unlocking transaction 2404 takes as input the input 2426 in its unlocking script and the first state 2428A (“S1”) embedded in the field value set of the previous transaction 2402 to determine an appropriate second state 2428B (“S2”) from state rule set 2406. As can be further seen in example 2400, the state transition matrix now provides a possible new state 2430B ("S4" or "S5") for the next state transition from second state 2428B. Note that state rule set 2406 may be encoded as a switch statement or other conditional statement (e.g., "if-then-else") parameterized by the current state and one or more inputs.

[0308] In embodiments, each possible state is represented in a self-replicating locking script by a set of rules for state change, such as a state transition matrix, and a particular transaction represents a state machine in a particular state. In such embodiments, the transaction's locking script is replicated for every unlocking transaction that attempts to transfer control of a digital asset to the next transaction that must be linked to the current transaction. This process is repeated until a termination condition is met. Because the input is not fixed and can be pending data, the state of the state machine can be made to change based on certain external inputs. Thus, the pending data provides inputs that can affect the next state.

[0309] As one illustrative example, Alice lends some money to Bob, and Bob agrees to repay Alice. As described in this disclosure, a trustless, probabilistic state machine can be implemented as a smart contract that represents a transfer that Bob makes to Alice. For example, the smart contract can be constructed so that Bob makes monthly payments to Alice for the next three months, and if a payment is not made, Bob's debt enters the debt collection phase. Thus, as long as Bob makes monthly transfers, the current state remains in the repayment state. However, if an external entity provides input indicating that Bob did not remit, then the state branches to the missed transfer state. In the missed transfer state, Alice can release the transaction and hand it over to the debt collector. The trustless deterministic state machine then switches to the debt collection state. In the debt collection state, the debt collector collects the debt from Bob. Such a smart contract can be created using variations on the script of the embodiment shown in Figures 23-25.

[0310] In another example, Alice is a very charitable person and donates one unit of digital assets each month. Her rule is that anyone can claim the digital assets, but only one unit per month. Alice creates a smart contract in the manner described in this disclosure and seeds it with an initial pool of three units of digital assets. Alice can construct a script that allows any entity to earn one unit of digital assets per month. The remainder of the digital assets are replicated to subsequent smart contracts. The following table shows one example of an unlocking script and a locking script that implements the trustless deterministic state machine of this disclosure. [Table 12-1] [Table 12-2]

[0311] 25 is a flowchart illustrating one example of a process 2500 for a trustless, deterministic state machine, according to various embodiments. Some or all of process 2500 (or any other described process, or variations and / or combinations of these processes) may be performed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions collectively executing on one or more processors. The executable instructions and / or other data may be stored in a non-transitory computer-readable storage medium (e.g., a computer program may be persistently stored on magnetic, optical, or flash media).

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

[0313] At 2502, the system receives an unlocking transaction. The system begins by executing the unlocking transaction's unlocking script, which causes the serialized previous transaction and inputs embedded in the locking script to be placed on a stack. These inputs are retrieved at 2512. At 2504, the system executing process 2500 determines whether an exit condition is met. The exit condition may be an exit condition such as those described in connection with Figures 19-22. In an embodiment, the exit condition, when met, terminates the transition of the state machine. If the exit condition is met, the system executing process 2500 proceeds to 2506, whereupon the trustless, deterministic state machine stops self-replicating.

[0314] At 2508, the system verifies that the locking script of the previous transaction matches the locking script of the unlocking transaction, in the manner described at 2212 of FIG. 22 . If the locking scripts do not match, the verification fails, and the unlocking transaction is not enabled. Otherwise, if the locking scripts match, at 2510, the system extracts the current state of a set of possible states from the serialized previous transaction. At 2512, the system obtains the inputs placed on the stack as a result of the execution of the locking script. Next, at 2514, the system applies the state rule set to determine the next state of the set of possible states for the trustless, deterministic state machine based on the current state and the inputs. At 2516, the system verifies that the next state (e.g., state variables and other state-related data, if applicable) is embedded in the unlocking transaction. The system may also apply any remaining constraints as specified in the locking script. After the operations of 2502-16 are successfully completed, the process ends at 2500, whereupon the unlocking transaction may be considered valid by the system executing the process. Note that one or more of the operations performed in 2502-18 may be performed in various orders and combinations, including in parallel.

[0315] It is noted that in the context of describing the disclosed embodiments, unless otherwise specified, the use of language relating to executable instructions (also referred to as code, applications, agents, etc.) in which the "instructions" perform operations that they do not normally perform alone (e.g., transmitting data, performing calculations, etc.) means that the instructions are being executed by a machine, thereby causing the machine to perform the specified operations.

[0316] FIG. 26 is an exemplary simplified block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 may be used to implement any of the systems illustrated and described above. For example, the computing device 2600 may be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 26, the computing device 2600 may include one or more processors 2602 that may be configured to communicate with and operably couple to multiple peripheral subsystems via a bus subsystem 2604. The processor 2602 may be utilized for traversal of a decision tree in a random forest of a supervised model in embodiments of the present disclosure (e.g., to generate an evaluation of the inverse document frequency of various search terms). These peripheral subsystems may include a storage subsystem 2606, comprising a memory subsystem 2608 and a file / disk storage subsystem 2610, one or more user interface input devices 2612, one or more user interface output devices 2614, and a network interface subsystem 2616. Such storage subsystem 2606 may be used for temporary or long-term storage of information, such as details related to transactions described in this disclosure, a database of historical records described in this disclosure, and storage of decision rules for the supervisory models described in this disclosure.

[0317] The bus subsystem 2604 may provide a mechanism that allows the various components and subsystems of the computing device 2600 to communicate with each other as intended. While the bus subsystem 2604 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may serve as an interface for receiving data from other systems and transmitting data from the computing device 2600 to other systems. For example, the network interface subsystem 2616 may allow a data technician to connect the device to a wireless network so that the data technician can send and receive data while at a remote location, such as a user data center. The bus subsystem 2604 may be used to communicate data, such as details, search terms, etc., to the surveillance models of the present disclosure and to communicate output of the surveillance models to one or more processors 2602 and to merchants and / or creditors via the network interface subsystem 2616.

[0318] The user interface input devices 2612 may include one or more user input devices, such as a keyboard, a pointing device such as an integrated mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touchscreen integrated into a display, an audio input device such as a voice recognition system or a microphone, or other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600. The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as an audio output device. The display subsystem may be a flat-panel device such as a cathode ray tube (CRT), a liquid crystal display (LCD), a light-emitting diode (LED) display, or a projection or other display device. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. One or more user interface output devices 2614 may be used, for example, to present a user interface to facilitate user interaction with applications performing the processes and transformations described herein, where such interaction may be appropriate.

[0319] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data constructs that may provide the functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), which when executed by one or more processors, may provide the functionality of one or more embodiments of the present disclosure, may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 may additionally provide a repository for storing data used in accordance with the present disclosure. The storage subsystem 2606 may include a memory subsystem 2608 and a file / disk storage subsystem 2610.

[0320] The memory subsystem 2608 may have multiple memories, including a main random access memory (RAM) 2618 for storing instructions and data during program execution and a read-only memory (ROM) 2620 where fixed instructions may be stored. The file / disk storage subsystem 2610 may provide non-transitory, persistent (non-volatile) storage for program files and data files and may include hard disk drives, floppy disk drives with associated removable media, compact disk read-only memory drives (CD-ROMs), optical drives, removable media cartridges, and other similar storage media.

[0321] Computing device 2600 may include at least one local clock 2624. Local clock 2624 is a counter that represents the number of ticks that have elapsed since a particular start date and may be integrally located within computing device 2600.

[0322] Local clock 2624 is used to synchronize data transfers among processors and all subsystems contained therein for computing device 2600 at specific clock pulses, and may be used to coordinate synchronous operations between computing device 2600 and other systems within a data center. In one embodiment, local clock 2624 is an atomic clock. In another embodiment, local clock 2624 is a programmable interval timer.

[0323] Computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, computing device 2600 may include another device that may be connected to computing device 2600 via one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). A device that may be connected to computing device 2600 may include multiple ports configured to accept fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals that can be transmitted to computing device 2600 for processing via the ports connecting the device. Due to the ever-changing nature of computers and networks, the description of computing device 2600 shown in FIG. 26 is intended only as a specific example for purposes of describing a preferred embodiment of the device. Many other configurations are possible, having more or fewer components than the system shown in FIG. 26.

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

[0325] The use of the terms "a" and "an" and "the" and similar references in the context of describing the disclosed embodiments (particularly in the context of the claims that follow) are intended to cover both the singular and the plural unless otherwise indicated or clearly contradicted by context. The terms "comprising," "having," and "containing" are intended to be open-ended terms (i.e., meaning "including, but not limited to") unless otherwise specified. The term "connected" is intended to be unmodified, and when referring to a physical connection, is intended to be partially or wholly contained within, attached to, or joined together, even if there is some intervening component. Recitation of ranges of values ​​in this disclosure is merely intended to serve as a shorthand method of individually referring to each separate value falling within the range, unless otherwise indicated, and each separate value is incorporated into the specification as if it were individually recited. Use of the term "set" (e.g., "a set of items" or "subset") should be construed as a nonempty collection containing one or more members, unless the context indicates otherwise or contradicts. Furthermore, unless the context indicates otherwise or contradicts, the term "subset" with respect to a corresponding set does not necessarily indicate a proper subset of the corresponding set, although a subset and a corresponding set may be equivalent.

[0326] Conjunctive language, such as phrases of the form "at least one of A, B, and C" or "at least one of A, B and C," is understood in its commonly used context to indicate that an item, term, etc. may be either A or B or C, or any non-empty subset of the set A, B, and C, unless specifically stated otherwise or clearly contradicted by context. For example, in the illustrative example of a set having three members, the conjunctive language "at least one of A, B, and C" refers to any of the following sets: {A}, {B}, {C}, {A,B}, {A,C}, {A,B,C}. Thus, such conjunctive language is not generally intended to mean that a given embodiment requires that there be at least one A, at least one B, and at least one C, respectively.

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

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

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

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

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

Claims

1. 1. A method comprising: receiving, at a node in the blockchain network, a first transaction to be verified; the first transaction includes a first script; causing the node to acquire a set of field values ​​as a result of being executed; Steps and obtaining a second transaction; The second transaction has been verified, and a second script that, when executed, causes the node to at least generate a signature based at least in part on the private encryption key and the mask number; Steps and verifying the first transaction by executing the first script and the second script; A method comprising:

2. The step of verifying the first transaction is successfully performed without verifying that the entity that created the first transaction has access to confidential information. The method of claim 1.

3. the private cryptographic key is of an asymmetric key pair; verifying the first transaction further comprises verifying that the signature is associated with a public cryptographic key of the asymmetric key pair; 3. The method according to claim 1 or 2.

4. The first script further specifies a signature hash type; and the set of field values ​​is based, at least in part, on the signature hash type; 4. The method according to any one of claims 1 to 3.

5. the signature hash type is a value indicating which field values ​​of the set of field values ​​of the first transaction should be included in the signature; The method of claim 4.

6. the second script is a locking script that imposes a set of conditions for validating the first transaction; Execution of the locking script causes the node to validate the first transaction by determining whether the set of conditions is met.

6. The method according to any one of claims 1 to 5.

7. The first script is an unlocking script for satisfying a condition set of the second script.

7. The method according to any one of claims 1 to 6.

8. validating the first transaction results in the transfer of an unspent transaction output of the second transaction.

8. The method according to any one of claims 1 to 7.

9. The node is a computing device that is communicatively coupled to at least one other node in the blockchain network.

9. The method according to any one of claims 1 to 8.

10. The blockchain network is composed of distributed electronic devices running instances of a blockchain protocol.

10. The method according to any one of claims 1 to 9.

11. the first script and the second script are written using a Turing-incomplete instruction set; 11. The method of claim 1, comprising:

12. the first script and the second script are written using a Turing complete instruction set; 11. The method according to any one of claims 1 to 10.

13. the first script includes a field set such that execution of the first script causes the node to make the field set available as input to the second script; 13. The method according to any one of claims 1 to 12.

14. 1. A system comprising: a processor; a memory containing executable instructions; The executable instructions, when executed by the processor, cause the system to perform the method of any one of claims 1 to 13. Memory and Including, the system.

15. A non-transitory computer-readable storage medium having executable instructions stored thereon, comprising:

14. A method according to claim 1, wherein when executed by a processor of a computer system, the method causes the computer system to carry out the method according to any one of claims 1 to 13. A non-transitory computer-readable storage medium.

Images