Script-based blockchain interaction

Abstract

To request that an unlocked script of a transaction in a blockchain includes a block header, a blockchain, or a chain of block headers.SOLUTION: A method includes receiving, at a node in a blockchain network, a first transaction associated with a digital asset. The first transaction includes a first script that specifies a set of constraints on a second transaction to transfer control of the digital asset, and the set of constraints includes a constraint that a set of data obtained by the node includes information obtained from a blockchain associated with the blockchain network. The method obtains the second transaction. The second transaction includes a second script that, as a result of being executed, causes the node to obtain the set of data. The method further validates the second transaction by executing the first and second scripts.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates generally to distributed ledger technology, including blockchain transactions, and in particular to generating infusion of fields from blockchains, block headers, blocks, and blockchain transactions into transaction scripts. The present invention is particularly, but not exclusively, suitable for use in transactions based on the state of a blockchain. [Background technology]

[0002] The term "blockchain" is used herein 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. Although "Bitcoin" may be referenced for convenience and purposes of explanation as a useful application of the technology described in this disclosure, Bitcoin is only one of many applications to which the technology described in this disclosure may be applied. However, it should be noted that the present invention is not limited to use with the Bitcoin blockchain and alternative blockchain implementations and protocols, and also includes non-commercial applications that are encompassed within the scope of the present invention. For example, the technology described in this disclosure may provide the benefits of utilizing blockchain implementations and other cryptocurrencies that have similar restrictions to Bitcoin with respect to constraints that can be encoded into cryptocurrency transactions, regardless of whether or not a cryptocurrency exchange occurs.

[0003] As used herein, a "digital asset" is a unit of a resource managed by a blockchain. A digital asset may be used as a cryptocurrency in some embodiments, but it is envisioned that digital assets may additionally or alternatively be used in other contexts in embodiments. It is noted that the present invention is applicable to control of digital assets, but is technical in nature and may be used in other contexts that utilize blockchain data structures and need not include the transfer of digital assets. A "digital asset," as used in this disclosure, may represent one or more digital assets. For example, a transaction may have multiple inputs, each of which may represent a different digital asset. The digital asset over which control is transferred may be, in this example, a collection of multiple digital assets, the collection itself being a digital asset. Similarly, a transaction may subdivide and / or combine these multiple inputs to generate one or more outputs, resulting in, for example, a different number of inputs and a different number of outputs. In one embodiment, the cryptocurrency is a token-based cryptocurrency. Here, each token represents a share of an asset (e.g., a share of a pool) and a single transaction may involve multiple types of tokens (e.g., shares in one or more different pools).

[0004] This disclosure describes technical aspects of 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 may include rules that can process inputs to generate an outcome. The outcome may then cause an action to be performed that is dependent on the outcome. If lock scripts are accessible to both unlocks and previous transactions, blockchain can be utilized to enable highly flexible and complex blockchain-based computer programs. One area of ​​current research is the use of blockchain-based computer programs for the implementation of "smart contracts." Unlike traditional contracts that may be written in natural language, smart contracts are computer programs designed to automate the execution of the terms of a machine-readable contract or agreement.

[0005] In embodiments, interactions with specific entities may be encoded in specific steps within a smart contract, while the smart contract may be otherwise self-executing and self-enforcing. In some examples, self-execution refers to the execution of a smart contract that is successfully executed to allow the transfer of a UTXO. Note that in such examples, an "entity" that can cause the transfer of a UTXO is an entity that can generate an unlock script without being required to prove knowledge of any secret. In other words, an unlock transaction can be validated without verifying that the source of the data (e.g., the entity that generated the unlock transaction) has access to a cryptographic secret (e.g., a private asymmetric key, a symmetric key, etc.). Also, in such examples, self-enforcing refers to the validating nodes of a blockchain network being caused to enforce the unlock transaction according to the constraints. In some examples, "unlocking" a UTXO is used in a technical sense to refer to generating an unlock transaction that references the UTXO and executes as valid. Unlocking a UTXO is traditionally known as using a UTXO.

[0006] Blockchain transaction outputs include a lock script and information regarding the ownership of a digital asset, such as Bitcoin. A lock script, which may also be called an encumbrance, "locks" a digital asset by specifying conditions that must be met in order to transfer the UTXO. For example, a lock script may require that certain data be provided within the unlock script to unlock the associated digital asset. A lock script is also known as a "scriptPubKey" in Bitcoin. Techniques for requiring a locking party to provide data to unlock a digital asset include embedding a hash of the data inside the lock script. However, this is problematic if the data is undetermined (e.g., unknown and not fixed) when the lock script is generated.

[0007] Furthermore, if a lock script is based on aspects of the blockchain itself (e.g., other transactions in the block, or the contents of the block header), the data does not exist when the lock script is generated, and there are no opcodes in the blockchain to query the state of the blockchain to obtain that data. Thus, a lock script cannot request a particular block header, cannot request a particular state of the blockchain, and cannot request that a transaction be placed in a particular block of the blockchain. Summary of the Invention

[0008] It is therefore desirable to provide a method and apparatus that enhances blockchain technology in one or more of the above aspects.According to the present invention there is therefore provided a method as defined in the accompanying claims.

[0009] As described in more detail below, computer-implemented methods and electronic devices are configured to enforce constraints on data in the unlocking script to require the unlocking script to include a block header, a blockchain, or a chain of block headers. By enforcing such constraints on data in the unlocking script, and by inserting such data into the unlocking script at runtime, transactions can be based on aspects of the blockchain.

[0010] Therefore, according to the present invention, there may be provided a method (and corresponding system) as defined in the appended claims. The method may be described as a blockchain data constraint method. The computer-implemented method includes: (i) receiving, at a node in a blockchain network, a first transaction including a first script specifying a set of constraints on a second transaction, the set of constraints including a constraint that a data set obtained by the node includes information obtained from a blockchain associated with the blockchain network; (ii) obtaining the second transaction, the second transaction including a second script that, as a result of execution, causes the node to obtain the data set; and (iii) validating the second transaction by executing the first script and the second script.

[0011] As described in more detail below, a computer-implemented method and electronic device is configured to implement constraints on data in the unlock script to require the blockchain to be in a particular state before the unlock script can be used to unlock the lock script and access the digital assets of the transaction. By enforcing constraints on a lock script to require the unlock script to include a block header, a blockchain, or a block header chain, and by introducing such data into the unlock script at runtime, transactions can be based on the state of a blockchain.

[0012] The set of constraints may include a constraint that the dataset includes a block header of a block of the blockchain.

[0013] A node may determine whether a constraint that a dataset includes a block header of a block of a blockchain is satisfied by at least verifying that the block header has a predefined size. Additionally or alternatively, a node may determine whether a constraint that a dataset includes a block header of a block of a blockchain is satisfied by at least verifying that the block header includes a mining difficulty value that is greater than or equal to a mining difficulty value. Additionally or alternatively, a node may determine whether a constraint that a dataset includes a block header of a block of a blockchain is satisfied by at least verifying that a hash of the block header is less than or equal to a target value calculated from a mining difficulty value included in the block header.

[0014] The set of constraints may include a constraint that the dataset includes a third transaction from a block of the blockchain.

[0015] The dataset may include a block header of the block of the blockchain. Additionally or alternatively, the set of constraints may include a constraint that the third transaction is included in the block. Additionally or alternatively, the node may determine whether the constraint that the third transaction is included in the block is satisfied based at least in part on the block header of the block of the blockchain.

[0016] The node may determine whether the constraint that the third transaction is included in the block is satisfied based at least in part on the encoding of the transaction in the block identified by the block header based on at least a hash value of the third transaction. Additionally or alternatively, the node may determine whether the constraint that the third transaction is included in the block is satisfied by verifying that at least a hash value of the third transaction is equal to the hash value stored in the block header.

[0017] The set of constraints may include a constraint that the dataset includes a block header chain that includes a block header ordered set, the block header ordered set including a plurality of block headers, the block header ordered set specifying an order associated with the plurality of block headers.

[0018] The node may determine whether the constraint that the second script includes a block header chain is satisfied by selecting a block header pair based at least in part on an order associated with the plurality of block headers, the pair of block headers including a first block header of the pair of block headers and a second block header of the pair of block headers. Additionally or alternatively, the node may determine whether the constraint that the second script includes a block header chain is satisfied by verifying that, for at least the block header pair, a hash of the first block header of the pair of block headers equals a hash value stored in the second block header of the pair of block headers.

[0019] The set of constraints may include a constraint that the dataset be obtained from a public blockchain of a blockchain network.

[0020] One or more characteristics of the blockchain network may be provided to the node prior to executing the first script and the second script.

[0021] Verification of the second transaction may be performed successfully without verifying that the entity that generated the second transaction has access to the secret information.

[0022] The first script may be a lock script for the first transaction and the second transaction is an unlock script for the first script.

[0023] The computer-implemented method may further include transferring the digital assets based at least in part on the result of the verification. Thus, according to the present invention, there may be provided a method (and corresponding system) as defined in the appended claims. The method may be described as a blockchain status verification method. The computer-implemented method includes: (i) receiving, at a node in a blockchain network, a first transaction, the first transaction specifying at least: a) a first constraint set for a second transaction, the first constraint set including one or more constraints that cause the second transaction to include a dataset from a blockchain; and b) a second constraint set for the second transaction, the second constraint set including one or more constraints associated with a data item of the dataset; and (ii) causing the second transaction to be stored in the blockchain as a result of verifying that the first constraint set and the second constraint set are satisfied.

[0024] As described in more detail below, computer-implemented methods and electronic devices are configured to implement constraints on data in the unlock script to require the blockchain to be in certain states before the unlock script can be used to unlock the lock script, and to regulate access to the digital assets of the transactions in those states. By enforcing constraints on a lock script to require that the unlock script include a block header, a blockchain, or a block header chain, and by introducing such data into the unlock script at runtime, the outcome of a transaction can be based on the state of the blockchain.

[0025] The data set may be received at the node in a second transaction.

[0026] The computer-implemented method may further include validating the second transaction as a result of the verifying step.

[0027] Validation of the second transaction may be successfully performed without verifying that the entity that generated the second transaction has access to the private information.

[0028] The first set of constraints may include a constraint that the dataset includes a block header of a block of the blockchain.

[0029] The first set of constraints may include a constraint that the dataset includes a third transaction from a block of the blockchain.

[0030] The first set of constraints may include a constraint that the dataset includes a block header chain that includes a block header ordered set, the block header ordered set including a plurality of block headers, the block header ordered set specifying an order associated with the plurality of block headers.

[0031] The second set of constraints may include constraints on values ​​of data items of the data set.

[0032] The second set of constraints may include constraints derived from one or more values ​​associated with data items of the data set.

[0033] The first set of constraints may be included in a locking script of the first transaction.

[0034] The second set of constraints may be included in a locking script of the first transaction.

[0035] The first set of constraints may include a constraint that the data set is received from a public blockchain.

[0036] The node may determine whether the constraint that the dataset is received from a public blockchain is satisfied by receiving, in the second transaction, at least a first block set including blocks before the block received from the blockchain network and a second block set including blocks after the block received from the blockchain network. Additionally or alternatively, the node may determine whether the constraint that the dataset is received from a public blockchain is satisfied by at least verifying that the first block set is chained to the blocks received from the blockchain network. Additionally or alternatively, the node may determine whether the constraint that the dataset is received from a public blockchain is satisfied by at least verifying that the second block set is chained to the blocks received from the blockchain network. Additionally or alternatively, the node may determine whether the constraint that the dataset is received from a public blockchain is satisfied by at least verifying that the first block set and the second block set are valid. Additionally or alternatively, the node may determine whether the constraint that the dataset is received from a public blockchain is satisfied by verifying that at least each block in the first blockset and the second blockset has a mining difficulty value greater than a predetermined value.

[0037] Therefore, according to the present invention, there may be provided a method (and corresponding system) as defined in the appended claims. The method may be described as a blockchain state awareness method. The computer-implemented method includes: (i) receiving, at a node in a blockchain network, a first transaction, the first transaction specifying at least: a) a first constraint set for a second transaction, the first constraint set including one or more constraints for the second transaction to include a dataset from a blockchain network; and b) a second constraint set for the second transaction, the second constraint set including a constraint that the dataset includes a block including the first transaction, the block being included in a blockchain associated with the blockchain network; and (ii) causing the second transaction to be recorded in the blockchain network as a result of a successful verification that the first constraint set and the second constraint set are satisfied.

[0038] The data set may be received at the node in a second transaction.

[0039] The first set of constraints may include a constraint that the dataset includes a block header of a block of the blockchain.

[0040] The first set of constraints may include a constraint that the dataset includes a third transaction from a block of the blockchain.

[0041] The first set of constraints may include a constraint that the dataset includes a block header chain that includes a block header ordered set, the block header ordered set including a plurality of block headers, the block header ordered set specifying an order associated with the plurality of block headers.

[0042] The set of properties of the blockchain network may be provided to the node as a result of the step of verifying that the first set of constraints and the second set of constraints are satisfied.

[0043] The set of properties of a blockchain network may include a corresponding timestamp associated with each block of a blockchain of the blockchain network.

[0044] The first set of constraints may include a constraint that the second transaction includes a timestamp for the block. Additionally or alternatively, verifying the constraint that the second transaction includes a timestamp for the block may be based, at least in part, on a set of characteristics of the blockchain network.

[0045] The first set of constraints may include a constraint that the data set includes a block header. Additionally or alternatively, the second set of constraints may include a constraint that the second transaction includes an identifier of the first transaction. Additionally or alternatively, the second set of constraints may include a constraint that the identifier of the first transaction is associated with a value of the block header.

[0046] The first and second sets of constraints may be included in a locking script of the transaction.

[0047] The first transaction may specify a third set of constraints for the second transaction, the third set of constraints including constraints on values ​​of data items of the data set.

[0048] The first transaction may specify a third set of constraints for the second transaction, the third set of constraints including constraints derived from one or more values ​​associated with data items of the dataset.

[0049] The computer-implemented method may further include validating the second transaction as a result of the step of verifying that the first and second constraint sets are satisfied, where the second transaction is successfully executed without verifying that the entity that generated the second transaction has access to the secret information. Thus, according to the present invention, a method (and corresponding system) may be provided as defined in the accompanying claims. The method may be described as a blockchain data constraint method. The computer-implemented method includes: (i) receiving, at a node in a blockchain network, a first transaction associated with a digital asset, the first transaction including a first script that specifies a set of constraints for a second transaction for transferring control of the digital asset, the set of constraints including a constraint that a data set obtained by the node includes information obtained from a blockchain associated with the blockchain network; (ii) obtaining the second transaction, the second transaction including a second script that, as a result of execution, causes the node to obtain the data set; and (iii) validating the second transaction by executing the first and second scripts.

[0050] The set of constraints may include a constraint that the dataset includes a block header of a block of the blockchain.

[0051] A node may determine whether a constraint that a dataset includes a block header of a block of a blockchain is satisfied by at least verifying that the block header has a predefined size. Additionally or alternatively, a node may determine whether a constraint that a dataset includes a block header of a block of a blockchain is satisfied by at least verifying that the block header includes a mining difficulty value that is greater than or equal to a mining difficulty value. Additionally or alternatively, a node may determine whether a constraint that a dataset includes a block header of a block of a blockchain is satisfied by at least verifying that a hash of the block header is less than or equal to a target value calculated from a mining difficulty value included in the block header.

[0052] The set of constraints may include a constraint that the dataset includes a third transaction from a block of the blockchain.

[0053] The dataset may include a block header of the block of the blockchain. Additionally or alternatively, the set of constraints may include a constraint that the third transaction is included in the block. Additionally or alternatively, the node may determine whether the constraint that the third transaction is included in the block is satisfied based at least in part on the block header of the block of the blockchain.

[0054] The node may determine whether the constraint that the third transaction is included in the block is satisfied based at least in part on the encoding of the transaction in the block identified by the block header based on at least a hash value of the third transaction. Additionally or alternatively, the node may determine whether the constraint that the third transaction is included in the block is satisfied by verifying that at least a hash value of the third transaction is equal to the hash value stored in the block header.

[0055] The first set of constraints may include a constraint that the dataset includes a block header chain that includes a block header ordered set, the block header ordered set including a plurality of block headers, the block header ordered set specifying an order associated with the plurality of block headers.

[0056] The node may determine whether the constraint that the second script includes a block header chain is satisfied by selecting a block header pair based at least in part on an order associated with the plurality of block headers, the pair of block headers including a first block header of the pair of block headers and a second block header of the pair of block headers. Additionally or alternatively, the node may determine whether the constraint that the second script includes a block header chain is satisfied by verifying that, for at least the block header pair, a hash of the first block header of the pair of block headers equals a hash value stored in the second block header of the pair of block headers.

[0057] The set of constraints may include a constraint that the dataset be obtained from a public blockchain of a blockchain network.

[0058] One or more characteristics of the blockchain network may be provided to the node prior to executing the first script and the second script.

[0059] Validation of the second transaction may be successfully performed without verifying that the entity that generated the second transaction has access to the private information.

[0060] The first script may be a lock script for the first transaction and the second transaction is an unlock script for the first script.

[0061] The computer-implemented method may further include transferring the digital assets based at least in part on a result of the verification.

[0062] Therefore, according to the present invention, there may be provided a method (and corresponding system) as defined in the appended claims. The method may be described as a blockchain status verification method. The computer-implemented method includes: (i) receiving, at a node in a blockchain network, a first transaction associated with a digital asset, the first transaction specifying at least: a) a first set of constraints for a second transaction to transfer control of the digital asset, the first set of constraints including one or more constraints that cause the second transaction to include a dataset from a blockchain; and b) a second set of constraints for the second transaction, the second set of constraints including one or more constraints associated with a data item of the dataset; (ii) verifying that the first set of constraints and the second set of constraints are satisfied; and (iii) reassociating the digital asset based at least in part on the verifying step.

[0063] The data set may be received at the node in a second transaction.

[0064] The computer-implemented method may further include validating the second transaction as a result of the verifying step.

[0065] Validation of the second transaction may be successfully performed without verifying that the entity that generated the second transaction has access to the private information.

[0066] The first set of constraints may include a constraint that the dataset includes a block header of a block of the blockchain.

[0067] The first set of constraints may include a constraint that the dataset includes a third transaction from a block of the blockchain.

[0068] The first set of constraints may include a constraint that the dataset includes a block header chain that includes a block header ordered set, the block header ordered set including a plurality of block headers, the block header ordered set specifying an order associated with the plurality of block headers.

[0069] The second set of constraints may include constraints on values ​​of data items of the data set.

[0070] The second set of constraints may include constraints derived from one or more values ​​associated with data items of the data set.

[0071] The first set of constraints may be included in a locking script of the first transaction.

[0072] The second set of constraints may be included in a locking script of the first transaction.

[0073] The first set of constraints may include a constraint that the data set is received from a public blockchain.

[0074] The node may determine whether the constraint that the dataset is received from a public blockchain is satisfied by receiving, in the second transaction, at least a first block set including blocks before the block received from the blockchain network and a second block set including blocks after the block received from the blockchain network. Additionally or alternatively, the node may determine whether the constraint that the dataset is received from a public blockchain is satisfied by at least verifying that the first block set is chained to blocks received from the blockchain network. Additionally or alternatively, the node may determine whether the constraint that the dataset is received from a public blockchain is satisfied by at least verifying that the second block set is chained to blocks received from the blockchain network. Additionally or alternatively, the node may determine whether the constraint that the dataset is received from a public blockchain is satisfied by at least verifying that the first block set and the second block set are valid. Additionally or alternatively, the node may determine whether the constraint that the dataset is received from a public blockchain is satisfied by verifying that at least each block in the first blockset and the second blockset has a mining difficulty value greater than a predetermined value.

[0075] Therefore, according to the present invention, there may be provided a method (and corresponding system) as defined in the appended claims. The method may be described as a blockchain state awareness method. The computer-implemented method includes: (i) receiving, at a node in a blockchain network, a first transaction associated with a digital asset, the first transaction specifying at least: a) a first set of constraints for a second transaction for transferring control of the digital asset, the first set of constraints including one or more constraints for the second transaction to include a dataset from a blockchain network; and b) a second set of constraints for the second transaction, the second set of constraints including a constraint that the dataset includes a block including the one transaction, the block being included in a blockchain associated with the blockchain network; (ii) verifying that the first set of constraints and the second set of constraints are satisfied; and (iii) transferring control of the digital asset based at least in part on the verifying step.

[0076] The data set may be received at the node in a second transaction.

[0077] The first set of constraints may include a constraint that the dataset includes a block header of a block of the blockchain.

[0078] The first set of constraints may include a constraint that the dataset includes a third transaction from a block of the blockchain.

[0079] The first set of constraints may include a constraint that the dataset includes a block header chain that includes a block header ordered set, the block header ordered set including a plurality of block headers, the block header ordered set specifying an order associated with the plurality of block headers.

[0080] The set of properties of the blockchain network may be provided to the node as a result of the step of verifying that the first set of constraints and the second set of constraints are satisfied.

[0081] The set of properties of a blockchain network may include a corresponding timestamp associated with each block of a blockchain of the blockchain network.

[0082] The first set of constraints may include a constraint that the second transaction includes a timestamp for the block. Additionally or alternatively, verifying the constraint that the second transaction includes a timestamp for the block may be based, at least in part, on a set of characteristics of the blockchain network.

[0083] The first set of constraints may include a constraint that the data set includes a block header. Additionally or alternatively, the second set of constraints may include a constraint that the second transaction includes an identifier of the first transaction. Additionally or alternatively, the second set of constraints may include a constraint that the identifier of the first transaction is associated with a value of the block header.

[0084] The first and second sets of constraints may be included in a locking script of the transaction.

[0085] The first transaction may specify a third set of constraints for the second transaction, the third set of constraints including constraints on values ​​of data items of the data set.

[0086] The first transaction may specify a third set of constraints for the second transaction, the third set of constraints including constraints derived from one or more values ​​associated with data items of the dataset.

[0087] The computer-implemented method may further include validating a second transaction as a result of verifying that the first set of constraints and the second set of constraints are satisfied, where the second transaction is successfully executed without verifying that the entity that generated the second transaction has access to the secret information.

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

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

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

[0091] According to the present invention, there may be provided an electronic device including an interface device, a processor coupled to the interface device, and a memory coupled to the processor, the memory storing computer executables that, when executed, configure the processor to perform a method as described herein.

[0092] According to the present invention, a computer readable storage medium may be provided that includes computer executable instructions that, when executed, configure a processor to perform the methods described herein.

[0093] These and other aspects of the invention will be apparent from and will be taught with reference to the embodiments described hereinafter, by way of example only, and with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0094] [Figure 1] FIG. 1 illustrates a diagram of an example blockchain network in which various embodiments may be implemented. [Diagram 2] FIG. 1 illustrates a diagram of an exemplary electronic device that can function as a node in a blockchain network, according to one embodiment. [Diagram 3] FIG. 1 illustrates a diagram of an example embodiment of a transaction associated with a script-based blockchain interaction. [Figure 4] FIG. 1 illustrates an example problem with accessing a blockchain associated with script-based blockchain interaction that is solved by an embodiment. [Diagram 5] FIG. 1 illustrates an example problem with accessing blocks in a blockchain associated with script-based blockchain interaction, as solved by one embodiment. [Figure 6] FIG. 1 illustrates a diagram of an exemplary environment in which data is verified to be a block header for script-based blockchain interactions, according to one embodiment. [Figure 7] 1 illustrates a flowchart of an exemplary process for verifying that data is a block header in a script-based blockchain interaction, according to one embodiment. [Figure 8] FIG. 1 illustrates a diagram of an exemplary environment in which data is verified to be a block header of a previous block for script-based blockchain interactions, according to one embodiment. [Figure 9] 1 illustrates a flowchart of an example process for verifying that data is a block header of a previous block in a script-based blockchain interaction, according to one embodiment. [Figure 10] FIG. 1 illustrates a diagram of an exemplary environment in which data is verified to be a block header chain for script-based blockchain interactions, according to one embodiment. [Figure 11] 1 illustrates a flowchart of an exemplary process for verifying that data is a block header chain in a script-based blockchain interaction, according to one embodiment. [Figure 12] FIG. 1 illustrates a diagram of an exemplary environment in which data represents a Merkle tree of usable block headers in a script-based blockchain interaction, according to one embodiment. [Figure 13] FIG. 1 illustrates a diagram of an exemplary environment in which transactions are verified for inclusion in block headers for script-based blockchain interactions, according to one embodiment. [Figure 14] 1 illustrates a flowchart of an exemplary process for verifying that a transaction is included in a block header in a script-based blockchain interaction, according to one embodiment. [Figure 15] FIG. 1 illustrates an example environment diagram illustrating how problems with accessing a blockchain associated with script-based blockchain interaction can be solved using the methods described herein, according to one embodiment. [Figure 16] FIG. 1 illustrates a diagram of an example embodiment showing a blockchain state associated with a script-based blockchain interaction, according to one embodiment. [Figure 17] FIG. 1 illustrates an example embodiment in which the state of the blockchain is verified in a script-based blockchain interaction, according to one embodiment. [Figure 18] 1 illustrates a flowchart of an example process for checking a blockchain state in a script-based blockchain interaction, according to one embodiment. [Figure 19] FIG. 1 illustrates an example problem with lock scripts in script-based blockchain interactions solved by one embodiment. [Figure 20] FIG. 1 illustrates an example diagram of data access by an unlock script in a script-based blockchain interaction, according to one embodiment. [Figure 21] FIG. 1 illustrates a diagram of an exemplary environment in which a signature is generated from a consecutive set of transaction fields in a script-based blockchain interaction, according to one embodiment. [Figure 22] 1 illustrates a flowchart of an exemplary process in which a signature results in the introduction of a consecutive set of unlocking transactions in a script-based blockchain interaction, according to one embodiment. [Figure 23] FIG. 1 illustrates an example problem with lock scripts in script-based blockchain interactions solved by one embodiment. [Figure 24] FIG. 1 illustrates a diagram of an exemplary environment in which the introduction of a previous successive transaction is triggered in a script-based blockchain interaction, according to one embodiment. [Diagram 25] FIG. 13 illustrates a diagram of an example set of fields made available depending on the signature hash type in a script-based blockchain interaction, according to one embodiment. [Figure 26] FIG. 1 illustrates an example diagram of extracting transaction identifiers from successive transactions in a script-based blockchain interaction, according to one embodiment. [Figure 27] 1 illustrates a flowchart of an exemplary process that results in the introduction of a previous consecutive transaction in a script-based blockchain interaction, according to one embodiment. [Figure 28] FIG. 1 illustrates a diagram of an exemplary environment in which blockchain state is used for script-based blockchain interactions, according to one embodiment. [Figure 29] 1 illustrates a flowchart of an example process for using blockchain state in script-based blockchain interactions, according to one embodiment. [Diagram 30]FIG. 1 illustrates a diagram of an example implementation of using blockchain state in script-based blockchain interactions, according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0095] Reference is first made to Figure 1. Figure 1 illustrates, in diagram form, an example blockchain network 100 associated with a blockchain in which various embodiments may be implemented. The blockchain network 100 operates under a blockchain protocol, and distributed electronic devices running instances of the blockchain protocol may participate in the blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be, for example, the Bitcoin protocol.

[0096] The electronic devices that execute the blockchain protocol and form the nodes 102 of the blockchain network 100 may be of various types, including, for example, computers such as desktop computers, laptop computers, tablet computers, servers, mobile devices such as smartphones, wearable computers such as smart watches, or other electronic devices.

[0097] The nodes 102 of the blockchain network 100 are coupled to each other using suitable communication technologies, which may include wired and wireless communication technologies. Such communication follows a protocol associated with the blockchain. For example, if the blockchain is the Bitcoin blockchain, the Bitcoin protocol may be used. The nodes 102 maintain a global ledger of all transactions on the blockchain. Thus, the global ledger is a distributed ledger. Each node 102 may store a full or partial copy of the global ledger. Transactions by nodes 102 that affect the global ledger are verified by other nodes 102. As a result, the validity of the global ledger is maintained. When the blockchain is a proof-of-work based blockchain, blocks are also verified by checking the proof-of-work submitted with the block.

[0098] At least some of the nodes 102 act as miners 104 of the blockchain network 100. The blockchain network 100 of FIG. 1 is a proof-of-work blockchain in which miners 104 perform costly computations to facilitate transactions on the blockchain. For example, a proof-of-work blockchain may require miners to solve a cryptographic problem. In Bitcoin, the miners 104 discover a nonce. The resulting block header is hashed with double SHA-256 to a number less than a value determined by the current mining difficulty. The hashing power required for the proof-of-work algorithm means that a transaction is considered effectively irreversible after a certain number of blocks have been mined on it. The miners 104 who solve the cryptographic problem generate a new block of the blockchain and broadcast the new block to the other nodes 102. The other nodes 102 verify that the miners 104 have indeed solved the cryptographic problem and thus established sufficient proof-of-work before accepting that the block should be added to the blockchain. Other nodes 102 also verify that the block itself is valid (e.g., that the transactions and the block header of the block are valid) before allowing the block to be added to the blockchain. A block is added to the blockchain (i.e., to the distributed global ledger) by consensus of the nodes 102.

[0099] Blocks generated by miners 104 include transactions that have been broadcast to the blockchain by nodes 102. For example, a block may include a transaction from an address associated with one of the nodes 102 to an address associated with another of the nodes 102. In this way, a block serves as a record of transactions from one address to another. The party that requested a transaction to be included in a block proves that they are authorized to initiate the transfer (e.g., in the case of Bitcoin, to transfer Bitcoins) by signing the request with a private key that corresponds to their public key. Only if the request is validly signed may the transfer be added to the block.

[0100] In Bitcoin, there is a one-to-one correspondence between public keys and addresses; that is, each public key is associated with a single address. Thus, references herein to transferring digital assets to or from a public key (e.g., paying an address associated with a public key) and transferring digital assets to or from an address associated with a public key refer to a common action.

[0101] Some of the nodes 102 may not act as miners, but instead participate as validating nodes. Validating a transaction may involve checking signatures or other conditions specified in a locking script, verifying references to valid UTXOs, etc. The example of FIG. 1 includes six nodes 102, two of which participate as miners 104. In practice, the number of nodes 102 or miners 104 may be different. In many blockchain networks, the number of nodes 102 and miners 104 may be much higher than the number shown in FIG. 1.

[0102] 2 illustrates, in block diagram form, an example electronic device 200 that may function as a node (e.g., a node such as one of the nodes 102 described in connection with FIG. 1) in a blockchain network (e.g., a blockchain network such as the blockchain network 100 described in connection with FIG. 1), according to one embodiment. The example electronic device 200 may function as a node, such as one of the nodes 102 described in connection with FIG. 1, in a blockchain network such as the blockchain network described in connection with FIG. 1. In one embodiment, the blockchain network is a peer-to-peer blockchain network.

[0103] The electronic device may take a variety of forms including, for example, a desktop computer, a laptop computer, a tablet computer, a server, a mobile device such as a smartphone, a wearable computer such as a smart watch, or another type of form.

[0104] The electronic device 200 includes a processor 210, a memory 220, and an interface device 230. These components may be directly or indirectly coupled to each other and may communicate with each other. For example, the processor 210, the memory 220, and the interface device 230 may communicate with each other via a bus 240. The memory 220 stores a computer software program including machine-readable instructions and data for performing functions described herein. For example, the memory may include processor-executable instructions that, when executed by the processor 210, cause the electronic device to perform the methods described herein. The processor-executable instructions may include instructions that, when executed by the processor 210, cause the electronic device to implement a protocol associated with a blockchain network (e.g., the blockchain network 100 described in connection with FIG. 1). For example, the instructions may include instructions for implementing the Bitcoin protocol.

[0105] Memory 220 may store a global ledger of a blockchain network (e.g., blockchain network 100 described in connection with FIG. 1 ) or a portion thereof. That is, memory 220 may store all blocks of the blockchain, or portions of blocks, such as recent blocks, or portions of information in some blocks.

[0106] 2, in practice, electronic device 200 may include multiple memory components. The memory components may be of various types, including, for example, RAM, HDD, SSD, flash drive, etc. Different types of memory may be suitable for different purposes. Additionally, while memory 220 is shown separate from processor 210, processor 210 may include internal memory.

[0107] As shown in FIG. 2, the processor 210 may include a secure domain such as a Trusted Execution Environment (TEE). The TEE 250 is an isolated execution environment that provides additional security to the electronic device 200, such as isolated execution, trusted application integrity, and asset confidentiality. The TEE 250 provides an execution space that ensures that computer instructions and data loaded inside the TEE 250 are protected in terms of confidentiality and integrity. The TEE 250 may be used to protect the integrity and confidentiality of critical resources, such as cryptographic keys. The TEE 250 is implemented at least partially at the hardware level. As a result, the instructions and data executed within the TEE 250 are protected against access and manipulation from the rest of the electronic device 200 and from external parties, such as the owner of the electronic device. The data and computations within the TEE 250 are secured from the party that operates the node that includes the TEE 250 (e.g., node 102 described in connection with FIG. 1).

[0108] The TEE 250 may operate to instantiate a secure execution environment (also referred to herein as an "enclave") and then add memory pages one by one while cumulatively hashing the added memory pages. In one embodiment, the hashing of the memory pages is performed on a remote machine (e.g., the developer's machine or another machine). As a result, the remote machine determines and stores the expected hash. The contents of the enclave can thus be verified by any remote machine, ensuring that the enclave is running an approved algorithm. This verification may be performed by comparing hashes. Once the enclave is fully constructed, it is fixed. It is possible to run code within the TEE 250 and send secrets to the code, but once the enclave is locked, the code cannot be changed. The final hash may be signed with an attestation key and made available to the data owner to verify it before the data owner sends any secrets to the enclave.

[0109] The TEE 250 may be used to protect the authenticity and integrity of cryptographic keys stored within the TEE 250. For example, the TEE 250 may be used for generation and storage of private key shares. The TEE 250 is to ensure that no member can directly obtain information about the private key shares or other secret key shares held within the TEE 250 from inter-member or inter-enclave communications. The protocol is robust against a threshold of enclave compromise. Additionally, the TEE 250 may enable remote attestation. Remote attestation may be used by a node (e.g., a node such as one of the nodes 102 described in connection with FIG. 1) to attest to other nodes that the TEE 250 is authentic and is executing approved computer-executable instructions for the protocol implemented by the blockchain network 100. Remote attestation may be provided by the TEE 250 by executing a particular piece of code and sending a hash of the code inside the enclave, signed by the enclave's internal attestation key.

[0110] The TEE 250 may include a secure random number generator that is internal to the TEE's enclave and can be used to generate secret keys, random challenges, or other random data. The TEE 250 may also be configured to read data from and write data to external memory. Such data may be encrypted with a secret key held only within the enclave.

[0111] The TEE 250 may be implemented using various platforms such as a Trusted Platform Module (TPM) or Intel Software Guard Extensions (SGX). SGX, for example, supports remote attestation. Remote attestation allows an enclave to obtain signed statements from a processor running a particular enclave with a given has of members, known as a quote. A third-party attestation service such as the Intel Attestation Service (IAS) can certify that these attested statements originate from a genuine CPU that conforms to the SGX specification.

[0112] The present invention may provide a method (and corresponding system) configured to modify a cryptographic public key embedded in a lock script of a blockchain transaction (Tx) using uncommitted data provided in an unlock script of another transaction. For example, when used in conjunction with a signature check opcode (e.g., OP_CHECKSIG) in the Bitcoin protocol that uses successive transactions as messages, both the transaction and the data require authorization or authentication from the owner of the public key, which protects them from modification.

[0113] The methods described herein use one or more digital signature schemes to verify various transactions. The digital signature scheme may be an Elliptic Curve Digital Signature Algorithm (ECDSA) scheme. The digital signature may be a two-party ECDSA scheme. The digital signature may be a threshold ECDSA scheme. This scheme may be used to construct valid signatures without the need to reconstruct a private key and without the need for any party to disclose their key shares to another party. For example, in a two-party ECDSA scheme, there are two parties and both parties need to reconstruct a private key.

[0114] This ECDSA scheme includes various mechanisms that can be used by nodes, such as node 102 described in connection with FIG. 1, to identify dishonest or non-cooperative parties. For example, verifiable secret sharing (VSS) can be used to share the polynomials necessary for Shamir's Secret Sharing (SSS). SSS is a form of secret sharing in which the secret is split into parts and provided to each participant in its own unique part. These parts may be necessary to reconstruct the secret. VSS can be used by nodes to identify dishonest nodes or members if inconsistent shares are provided to different nodes, or if shares are transmitted secretly to nodes, unlike hidden (blind) shares, where shares are broadcast to all nodes. Inconsistent shares can be identified by any of the nodes. Secret sharing can be made verifiable by including auxiliary information that allows the nodes to verify their shares as consistent.

[0115] The transmission of fraudulent shares to individual nodes (i.e., shares that are different from the broadcasted hidden shares) can be identified by the intended recipients of the shares. The identification of fraudulent shares being transmitted in secret to nodes can be made publicly verifiable using techniques known as Publicly Verifiable Secret Sharing (PVSS). Such techniques can avoid possible delays in identifying fraudulent senders that may occur if PVSS is not used and the recipients of the fraudulent shares are offline or disconnected from the root of the network when the fraudulent shares are transmitted.

[0116] Misbehavior such as providing inconsistent shares to different nodes may be resolved by the network to prevent malicious behavior. For example, when a node is identified as a malicious party by other nodes, multiple nodes may cooperate to penalize the malicious party. For example, a node may take action related to digital assets (digital currency, tokens, or other stakes or value) deposited in the blockchain network by the malicious party. For example, the blockchain network may burn the digital currency, tokens, stakes, or value by transferring them to an unredeemable address. Alternatively, the blockchain network may confiscate such digital assets by reaching a consensus with other nodes to reject them. Non-misbehavior nodes may prevent misbehavior by cooperating to exclude the misbehavior node (e.g., by effectively invalidating the key share, e.g., by excluding the node from participating in the parliament protocol, or by re-sharing the private key and not allocating shares to the misbehavior node).

[0117] The ECDSA technique described above may be extended through the use of TEEs. For example, the threshold ECDSA signature technique based on Ibrahim et al. anticipates a strong form of adversary, referred to here as a Byzantine adversary. This type of adversary may behave arbitrarily. For example, they may not only refuse to participate in the signing process or stop a party midway, but may also pretend to participate honestly and transmit fraudulent information. However, by using a TEE and generating the data to be used for signing within an enclave of the TEE where the secret private key shares are stored, additional security may be provided since the enclave is highly unlikely to be compromised in any significant number. If each TEE is assigned more than one key share, for example, the number of potentially compromised TEEs may be reasonably expected not to approach the adversarial robustness threshold, assuming n is sufficiently large. This allows the protocol to be secure if it is resistant to a small proportion of fraudulent adversaries relative to the total number of key shares.

[0118] For example, if every node has a TEE, obtaining secrets stored in the enclave can only be achieved by physical access to the node, and only with great effort and expense, unless the manufacturer of the TEE is corrupt. Such manufacturer-level corruption is expected to be manageable. For example, if a manufacturer tries to falsely claim that a large number of public keys correspond to honest TEEs, they could gain direct access to the private key shares and launch an attack. However, such an attack may require a sufficient number of key shares for the manufacturer to be able to generate valid signatures without assistance from other nodes. This may mean accumulating a large portion of the total stake, which can be very expensive. Furthermore, carrying out an attack may destroy a large portion of the value of the stake held.

[0119] When a TEE is used, it is useful to intend the protocol robust against "corrupted nodes". A corrupted node is one whose hardware outside the TEE contains errors, but the integrity of the TEE is not compromised. A corrupted node may have control over what information the enclave does and does not receive. In particular, a corrupted node may suspend, i.e., refrain from participating in the protocol. If the information provided to the protocol needs to be signed by a private key kept secret within the enclave (if the corresponding public key was authenticated during attestation), the private key is as trustworthy as the enclave itself. Thus, a corrupted node cannot send arbitrary (authenticated) information to the protocol, but only tries to interfere by suspending or by trying to trick the enclave into behaving incorrectly, for example by providing outdated information. Then, with a corrupted node, a successful attack may require collecting a sufficient number of partial signatures to generate a complete signature.

[0120] In some embodiments, other threshold schemes may be used, including non-ECDSA signature schemes.

[0121] 3 illustrates, in diagram form, an example embodiment 300 of a transaction associated with a script-based blockchain interaction. The example embodiment 300 illustrated in FIG. 3 illustrates a previous blockchain transaction 302 that encodes a first state 306 of the blockchain, and an unlock blockchain transaction 304 that encodes a second state 308 of the blockchain. In the example embodiment 300, the current state 306 at the first time is represented as a parameter embedded in the previous transaction 302. In one embodiment, the unlock transaction 304 includes a parameter representing the next state 308.

[0122] In the exemplary embodiment 300, transactions 302 and 304 are field value sets that include one or more inputs and one or more outputs. In some embodiments, the inputs and outputs reflect an intent to transfer control of a digital asset from at least one entity to at least one other entity. In the exemplary embodiment 300, the previous transaction 302 is the most current confirmed transaction included in the blockchain. In the exemplary embodiment 300, the unlock transaction 304 is an intermediate future transaction that has not yet been confirmed and has not yet been included in the blockchain. Each of the inputs of the unlock transaction 304 receives an output of the previous transaction 302.

[0123] Some blockchain technologies use the elliptic curve digital signature algorithm (ECDSA) as a function for digital signatures, similar to Bitcoin. In an embodiment, ECDSA is a cryptographic digital signature used to ensure that UTXOs are transferred only to their legitimate owners. Elliptic curve digital signatures (ECDS) in Bitcoin typically appear with a signature hash flag (SIGHASH type) appended to the end. However, it is contemplated that the technology of the present disclosure can be used with blockchain technologies that do not implement the SIGHASH type. In such blockchain technologies, it is contemplated that the ECDS conforms to the signature generation principles of the particular blockchain technology.

[0124] In embodiments, the SIGHASH type represents a set of fields that should be 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 examples, 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 should be 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. This may allow others to update the transaction. In one embodiment, the type SIGHASH_SINGLE indicates that the input is signed, but the sequence number is blank. Thus, others can generate new versions of the transaction, but only the signed output is in the same location as the input. In one embodiment, the type SIGHASH_ANYONECANPAY is combined with other types to indicate that an input containing SIGHASH_ANYONECANPAY is to be signed, but other inputs need not be signed. A SIGHASH type may be represented by a value that indicates the SIGHASH type. For example, in some implementations, SIGHASH_ALL is represented by a byte having a value of 1, SIGHASH_NONE is represented by a byte having a value of 2 (e.g., "00000010"), SIGHASH_SINGLE is represented by a byte having a value of 3 (e.g., "00000011"), and SIGHASH_ANYONECANPAY is represented by a byte having a value of 80 (e.g., "01010000"). Combining SIGHASH types is performed in some embodiments by adding the byte values ​​together.

[0125] In some instances, the set of transaction fields determined by the SIGHASH type represents a subset of the corresponding transaction encoded into bytes as determined by the SIGHASH type. For example, with a SIGHASH type of SIGHASH_ANYONECANPAY, only one transaction input is included in the signature.

[0126] In one embodiment, the ECDS is represented by a pair of 256-bit numbers (r, s) encoded in the distinguished encoding rules (DER) format. However, it is 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 (an elliptic curve point with coordinates (x, y)), k (a 256-bit number, which is typically random to protect the private key), G (a base point on an elliptic curve with degree n, n×G=0, where 0 represents the identity elliptic curve point and n is a large prime number used as a parameter in the 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 ... r (a 256-bit number, which is typically random to protect the private key), s (a 256-bit number, which is typically random to protect the private key), s (a 256-bit number, which is typically random to protect the private key), s (a 256-bit number, which is typically random to protect the private key), s (a 256-bit number, which is typically random to protect the private key), s (a 256-bit number, which is typically random to protect the private key), s (a 256-bit number, which is typically random to protect the private key), s ( -1 (The modular inverse of k, that is, k l k=l mod n), m (the message / data being signed, in an embodiment this is resized to 256 bits by a hash function), and a (the private key, e.g. a 256 bit number). In an embodiment, the ECDS is generated as follows:

[0127] First, an elliptic curve point K is determined by multiplying k by a generator: K=k×G. Next, a point x is determined from K, and a first number r of 256-bit numbers in the ECDS is determined according to the formula r=x mod n. Next, a second number s of 256-bit numbers in the ECDS is determined according to the formula s=k. lThe signature is determined according to (m+r×a) mod n. Finally, (r,s) is encoded into 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, v=s -l × (m × G + r × y) is calculated. If v = r, then the signature is valid.

[0128] Bitcoin uses a script system called "Script." In this disclosure, various Script opcodes and keywords are referenced to perform various operations. However, it is contemplated that other blockchain technologies may implement different instruction sets, and thus the opcodes set forth in this disclosure are to be considered as descriptions of operations performed by opcodes other than the specific opcodes in Script. In some embodiments, the script system is a Turing incomplete instruction set (e.g., does not support loops, recursion, "goto" statements, etc.). In other embodiments, the script system is a Turing complete instruction set.

[0129] Certain embodiments of the present disclosure operate under the assumption that the described system or other systems implementing the described instruction set allow for more than 200 instructions (e.g., opcodes) in a single script, a limit that is violated in certain implementations of Bitcoin. Likewise, certain embodiments of the present disclosure further assume that the functionality provided by the opcodes referenced in this disclosure is present and enabled in the system executing the opcode script / instruction set. In some implementations of Bitcoin, one or more of these opcodes may be disabled or restricted by default.

[0130] Examples of opcodes referenced in this disclosure include: OP_ECPX: Returns the x-coordinate of the elliptic curve point. OP_ADD: Adds the top two items on the stack. OP_BIGMOD: Returns the remainder after dividing the top two items on the stack. OP_BIGMODADD: Performs a modulo sum of the top two items on the stack, modulo the third item on the stack. OP_BIGMODINVERSE: Performs a modulo negative exponent operation. OP_BIGMODMUL: Performs the modulo product of the top two items on the stack modulo the third item on the stack. OP_CAT: Concatenates the top two items in the stack. OP_CHECKSIG: The public key and signature are popped from the stack and verified against the signature in the transaction field according to the SIGHASH type. Returns 1 if the signature is valid, 0 otherwise. OP_CHECKSIGVERIFY: Same functionality as OP_CHECKSIG, but OP_VERIFY is run afterwards. OP_DERENCODE: Encode the top two items on the stack in DER format. OP_DUP: Duplicate the top stack item. OP_ECPMULT: Performs an elliptic curve multiplication of the top two items on the stack. OP_ELSE: If the preceding OP_IF or OP_NOTIF or OP_ELSE is not executed, then these statements are executed, otherwise if the preceding OP_IF or OP_NOTIF or OP_ELSE is executed, then these statements are not executed. OP_ENDIF: Ends an if / else block. OP_EQUAL: Returns 1 if the inputs are exactly equal, 0 otherwise. OP_EQUALVERIFY: Same as OP_EQUAL, but run OP_VERIFY afterwards. OP_FROMALTSTACK: Puts the input on the top of the primary stack and removes it from the alternate stack. OP_HASH256: The input is hashed twice, first with SHA-256 and then with RIPEMD-160. OP_IF: If the top value is not false, the statements are executed and the top value is removed. OP_NOTIF: If the top value is false, the statements are executed and the top value is removed. OP_ROLL: The item that is 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 the top of the alternate stack and removes it from the main stack. OP_VERIFY: Mark the transaction as invalid if the top stack value is not true.

[0131] In one embodiment, the ECDS generation script can be generated using the opcode and can be extended to generate the signature generation script OP_GENSIG by appending the SIGHASH type to the end. [Table 1] [Table 1]

[0132] In the above script shown in Table 1,<SIGHASH Byte> ,message <m>, Private key , and a number <k>will be inserted in the order mentioned above (e.g. after inserting 4 items, the number <k> is on the top of the stack, followed by the private key< / k> < / k> , followed by the message <m>,lastly<SIGHASH Byte> followed by , are entered into the main stack (e.g., last of the first out).

[0133] Script operation "OP_DUP OP_TOALTSTACK <pubkg>OP_ECPMULT" execution is a number <k>to the alternate stack, where <k>is an elliptic curve generator<PubK G> is multiplied against to generate the elliptic curve point K on the top of the main stack.

[0134] Script operation "OP_ECPX <n>Execution of "OP_BIGMOD OP_DUP OP_TOALTSTACK" causes r to be computed from the x coordinate of K mod n. A copy of r is pushed onto the alternate stack.

[0135] Script operation " <n>OP_BIGMODMUL <n>OP_BIGMODADD", OP_FROMALTSTACK OP_SWAP OP_FROMALTSTACK <n>" and "OP_BIGMODINVERSE <n>OP_BIGMODMUL" execution is k -l Calculate s from (m+r×a) mod n. Finally, execute the script operation "OP_DERENCODE OP_SWAP OP_CAT" to encode r and s in DER format.<SIGHASH Byte> and link it together.

[0136] In this disclosure, this script is referred to as OP_GENSIG, and therefore references to OP_GENSIG in embodiments of the present disclosure should be considered as a shorthand for the operations performed in the above script.

[0137] 4 illustrates in diagram form an example problem 400 with accessing a blockchain associated with script-based blockchain interaction solved by one embodiment. In the example problem 400 shown in FIG. 4, a lock script 406 in a transaction 402 (e.g., a previous transaction such as previous transaction 302 described in connection with FIG. 3 or unlock transaction 304) cannot access the blockchain 404.

[0138] As mentioned above, in some embodiments, transaction 402 is the most current confirmed transaction included in the blockchain. Similarly, in some embodiments, transaction 402 is a future transaction that represents an attempt to transfer control of at least a portion of a digital asset controlled by a previous transaction that has not yet been confirmed and is not yet included in the blockchain.

[0139] In some embodiments, the locking script 406 is a script that blocks a transaction by specifying conditions that must be met in order for an output to be transferred. In particular, execution of the locking script 406, as a result of execution by a validating node of the blockchain system, accepts data from an executed unlocking script, performs certain operations based on the data, and returns a result indicating whether execution of the unlocking script successfully "unlocked" the locking script (i.e., satisfied the conditions set in the locking script). In some embodiments, the locking script 406 defines one or more data constraints that must be satisfied (e.g., by data provided by the unlocking script) for the transaction to be successfully validated. For example, the locking script 406 may require that certain data be provided in the unlocking script in order to unlock the digital asset associated with the transaction 402.

[0140] As shown in example problem 400, locking script 406 of transaction 402 cannot query blockchain 404 to determine, for example, a block number. Locking script 406 of transaction 402 cannot query any block of blockchain 404, including the first block 408 (also called the “genesis block”) of blockchain 404, any of the interior blocks (e.g., block 410) of blockchain 404, or the last block 412 of blockchain 404. Methods described herein allow locking script 406 of transaction 402 to query any block of blockchain 404, including the first block 408, an interior block (e.g., block 410), or the last block 412 of blockchain 404.

[0141] Figure 5 illustrates in diagram form an example problem 500 with accessing blocks in a blockchain associated with script-based blockchain interaction solved by one embodiment. In the example problem 500 shown in Figure 5, a lock script 506 in a transaction 502 (e.g., a previous transaction such as previous transaction 502 described in connection with Figure 3 or an unlock transaction such as unlock transaction 304 described in connection with Figure 3) cannot access a block in the blockchain such as block 504 (i.e., the first block, an inner block, or the last block).

[0142] As mentioned above, in some embodiments, transaction 502 is the most current confirmed transaction included on the blockchain. Similarly, in some embodiments, transaction 502 is a future transaction that represents an attempt to transfer control of at least a portion of a digital asset controlled by a prior transaction that has not yet been confirmed and not yet included on the blockchain.

[0143] In some embodiments, as described herein, locking script 506 is a script that blocks a transaction by specifying conditions that must be met in order to transfer an output. As shown in example problem 500, locking script 506 of transaction 502 cannot query block 504 of the blockchain, such as to determine block numbers or to access a particular transaction. As shown in example problem 500, locking script 506 of transaction 502 cannot query block 504 of the blockchain, cannot query block header 508 of block 504, and cannot query transactions of block 504. If block 504 is not in the chain of transaction 502 (transaction Tx of transaction 510 of block 504), the transaction 510 of transaction 502 (transaction Tx of transaction 510 of transaction 510 of transaction 502) cannot query block 504 of the blockchain, such as to determine block numbers or access a particular transaction. i In one embodiment, the lock script 506 of transaction 502 includes a transaction Tx i The methods described herein allow the locking script 506 of transaction 502 to query block 504 of the blockchain, to query the block header 508 of block 504, to query transaction 510 of block 504, and to query transaction Txi 512 of transaction 510 of block 504 (e.g., to allow the locking script to query transactions that include the locking script 506).

[0144] 6 illustrates in diagram form an example environment 600 in which data is verified to be a block header for script-based blockchain interaction, according to one embodiment. A block header is a portion of a block of a blockchain that contains data about the block. For example, a block header 602 is 80 bytes of data with the first 4 bytes storing the blockchain implementation version ("nVersion"), the next 32 bytes (or 256 bits) storing a hash of the previous block of the blockchain ("HashPrevBlock"), the next 32 bytes storing a hash of the Merkle tree of the block's transactions ("HashMerkleRoot", which is described in more detail herein), the next 4 bytes storing the generation time of the block ("nTime"), the next 4 bytes storing a 32-bit mining difficulty value of the block ("nBits"), and the last 4 bytes storing a random seed for the block ("nNonce").

[0145] As can be seen, when block header 602 is data used as input to a lock script (e.g., provided as an unlock script), constraints on block header 602 are encoded into the lock script such that the unlock script data must contain a valid block header or it is not a valid unlock script. The three constraints on block headers such as block header 602 are: (i) it must be 80 bytes long; (ii) the nBits of the block header must be greater than or equal to a particular mining difficulty value; and (iii) the double SHA256 of the block header must be less than or equal to a mining difficulty value. Each of these constraints is described herein as a separate script, and the details of linking the scripts together (e.g., branching constraints and maintaining a stack) are omitted for ease of explanation.

[0146] The three scripts are joined together to form a single script, with the details of linking the scripts together omitted, which is <data>is a valid block header. In the illustrated example, the three scripts return true or false, but OP_VERIFY is typically added to the end of each script when linked together into a single script to create the OP_CHECKBLOCKVERIFY script. As contemplated, other implementations of the OP_CHECKBLOCKVERIFY script may be implemented and are considered to be within the scope of this disclosure.

[0147] In step 604, the intended block header is provided as an unlock script; <data>It is shown as:

[0148] In step 606, <data>A first script is executed which verifies that the size of is 80 bytes (eg, the first constraint). <data>The first script, which verifies that the size of is 80 bytes, is shown in Table 2. [Table 2] [Table 2]

[0149] At step 608, a second script is executed that verifies that the “nBits” field of the block header is greater than or equal to the block header mining difficulty value. The second script that verifies that the “nBits” field of the block header is greater than or equal to the block header mining difficulty value is shown in Table 3. It should be noted that the mining difficulty value “<0x1D00FFFF>” in the script shown in Table 3 is the minimum mining difficulty of the Bitcoin specification itself. In one embodiment, the mining difficulty value is provided as a data item of the unlock script. In one embodiment, a larger mining difficulty value (e.g., a value greater than 0x1D00FFF) is used as the target mining difficulty. In one embodiment, a smaller mining difficulty value (e.g., a value less than 0x1D00FFF) is used as the target mining difficulty. [Table 3] [Table 3]

[0150] In step 610, a third script is executed that verifies that the double SHA256 of the block header (implemented by opcode OP_HASH256 described above) is less than or equal to the indicated mining difficulty value. The third script that verifies that the double SHA256 of the block header is less than or equal to the indicated mining difficulty value is shown in Table 4. The third script shown in Table 4 introduces two additional opcodes:

[0151] OP_LBYTESHIFT: Performs a left byte shift on data of any size. OP_BIGLESSTHANOREQUAL: Interprets data of any size as a number and compares two numbers to determine if the first number is less than or equal to the second. [Table 4] [Table 4]

[0152] FIG. 7 illustrates in flow chart form an example process 700 for verifying that data is a block header in a script-based blockchain interaction, according to one embodiment. Some or all of the process 700 may be executed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions executing collectively 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 in a magnetic, optical, or flash medium). The example process 700 may be performed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may perform the example process 700 for verifying that data is a block header in a script-based blockchain interaction, as described in connection with FIG. 7. Such a node may comprise any suitable computing device (e.g., a server in a data center, a client computing device, a plurality of computing devices in a distributed system of a computing resource service provider, or a suitable electronic client device such as computing device 200 described in connection with FIG. 2).

[0153] In step 702 of the exemplary process 700, the system <data>In step 704 of the exemplary process 700, the system initiates the OP_CHECKBLOCKVERIFY script, as described above in connection with FIG. 6. In step 706 of the exemplary process 700, the system receives, for example, by executing the script shown in Table 2 above: <data>is 80 bytes in size. In step 708 of the exemplary process 700, it is determined whether the previous script (the script shown in Table 2 above) passed.

[0154] If, at step 708 of the exemplary process 700, it is determined that the previous script did not pass, then, at step 718 of the exemplary process 700, <data>is not a valid block header and the unlock script will fail.

[0155] If, at step 708 of the exemplary process 700, it is determined that the previous script passed, then, at step 710 of the exemplary process 700, the system performs a step 710 of the exemplary process 700, e.g., by executing the script shown in Table 3 above. <data>is greater than or equal to the blockchain mining difficulty. In step 712 of the example process 700, it is determined whether the previous script (e.g., the script shown in Table 3 above) passed.

[0156] If, at step 712 of the exemplary process 700, it is determined that the previous script did not pass, then, at step 718 of the exemplary process 700, <data>is not a valid block header and the unlock script will fail.

[0157] If, at step 712 of the exemplary process 700, it is determined that the previous script passed, then, at step 714 of the exemplary process 700, the system performs a step 714 of the exemplary process 700 to execute the script shown in Table 4 above. <data>is less than or equal to the required target. At step 716 of the exemplary process 700, it is determined whether the previous script (eg, the script shown in Table 4 above) passed.

[0158] If, at step 716 of the exemplary process 700, it is determined that the previous script did not pass, then, at step 718 of the exemplary process 700, <data>is not a valid block header and the unlock script will fail.

[0159] If, at step 716 of the exemplary process 700, it is determined that the previous script passed, then, at step 720 of the exemplary process 700: <data>is not a valid block header and the unlock script succeeds.

[0160] It is noted that one or more of the operations performed in the example process 700 illustrated in FIG. 7 may be performed in various orders and combinations, including in parallel.

[0161] FIG. 8 illustrates in diagram form an example environment 800 in which data is verified to be a block header of a previous block for script-based blockchain interaction, according to one embodiment. As described herein, a block header is a portion of a block of a blockchain that contains data about the block. Part of the block header is a hash of the previous block header ("HashPrevBlock"). If a first block header is provided as an input to a lock script (e.g., provided as part of an unlock script) and a second block header intended for a next block in the blockchain is also provided as an input to the lock script (e.g., provided as part of an unlock script), then by encoding a constraint in the lock script that the hash of the first block header is the HashPrevBlock of the second block, if the hash of the first block header is not the HashPrevBlock of the second block, then the two block headers are not a valid unlock script.

[0162] In step 804, the first block header 802 contains data for the unlock script (<Data 1> ) and in step 810, the second block header 808 contains the data for the unlock script (<Data 2> In step 806, a script such as the OP_CHECKBLOCKVERIFY script described above in connection with FIGS.<Data 1> is used to verify that the block header is a block header. In step 812, a script such as the OP_CHECKBLOCKVERIFY script described above in connection with Figures 6 and 7<Data 2> is used to verify that it is a block header.

[0163] In step 814, the first block header<Data 1> The double SHA256 of the second block header<Data 2> A script is run to verify that the first block header is equal to the HashPrevBlock.<Data 1> The double SHA256 of the second block header<Data 2> An example of a script that verifies that the HashPrevBlock is equal to the HashPrevBlock is shown in Table 5. The script shown in Table 5<Data 1> but<Data 2> 5 is an example of an OP_CHECKCHAINVERIFY script that verifies that a valid previous block of is a valid block of the current block. As contemplated, other implementations of the OP_CHECKCHAINVERIFY script may be implemented and are considered to be within the scope of this disclosure. Of note, the final opcode of the OP_CHECKCHAINVERIFY script shown in Table 5 is OP_EQUAL since a "true" value should remain on the stack after execution. In one embodiment where the OP_CHECKCHAINVERIFY script is used in conjunction with other scripts, the final OP_EQUAL opcode of the script is changed to an OP_EQUALVERIFY opcode. [Table 5] [Table 5]

[0164] FIG. 9 illustrates in flow chart form an example process 900 for verifying that data is a block header of a previous block in a script-based blockchain interaction, according to one embodiment. Some or all of the process 900 may be executed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions executing collectively 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 in a magnetic, optical, or flash medium). The example process 900 may be executed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may execute the example process 900 for verifying that data is a block header of a previous block in a script-based blockchain interaction described in connection with FIG. 9. Such a node may comprise any suitable computing device (e.g., a server in a data center, a client computing device, a plurality of computing devices in a distributed system of a computing resource service provider, or a suitable electronic client device such as computing device 200 described in connection with FIG. 2).

[0165] At step 902 of the exemplary process 900, the system detects two intended block headers:<Data 1> and<Data 2> In step 904 of the exemplary process 900, the system executes the OP_CHECKCHAINVERIFY process as described above in connection with FIG.<Data 1> and<Data 2> In step 906 of the exemplary process 900, the system executes the OP_CHECKCHAINVERIFY script as described above in connection with FIGS.<Data 1> By running<Data 1> Verify that is a block header.

[0166] In step 908 of the exemplary process 900, a previous script (e.g.,<Data 1> If, at step 908 of the example process 900, it is determined that the previous script did not pass, then, at step 910 of the example process 900,<Data 1> teeth<Data 2> block before it, and therefore the unlock script fails.

[0167] If, at step 908 of the example process 900, it is determined that the previous script passed, then, at step 912 of the example process 900, the system executes the OP_CHECKBLOCKVERIFY script as described above in connection with FIGS.<Data 2> By running<Data 2> Verify that is a block header.

[0168] In step 914 of the exemplary process 900, a previous script (e.g.,<Data 2> If, at step 914 of the example process 900, it is determined that the previous script did not pass, then, at step 916 of the example process 900,<Data 2> is not a valid block header, and in step 922 of the exemplary process 900,<Data 1> teeth<Data 2> block before it, and therefore the unlock script fails.

[0169] If, at step 914 of the exemplary process 900, it is determined that the previous script passed, then, at step 918 of the exemplary process 900, the system:<Data 1> The double SHA256 of<Data 2> Validate that the "HashPrevBlock" field of

[0170] In step 920 of the exemplary process 900,<Data 1> The double SHA256 of<Data 2> In step 920 of the exemplary process 900, it is determined whether the "HashPrevBlock" field of<Data 1> The double SHA256 of<Data 2> If it is determined that the “HashPrevBlock” field of the example process 900 is not equal to<Data 1> teeth<Data 2> block before it, and therefore the unlock script fails.

[0171] In step 920 of the exemplary process 900,<Data 1> The double SHA256 of<Data 2> If it is determined that the “HashPrevBlock” field of the example process 900 is equal to<Data 1> teeth<Data 2> before the block, and therefore the unlocking of the lock script is successful.

[0172] It is noted that one or more of the operations performed in the example process 900 illustrated in FIG. 9 may be performed in various orders and combinations, including in parallel.

[0173] FIG. 10 illustrates, in diagram form, an example environment 1000 in which data is verified to be a block header for script-based blockchain interaction, according to one embodiment. The example environment 1000 illustrated in FIG. 10 is an extension of the operations described in connection with FIGS. 8 and 9. In the example environment 1000 illustrated in FIG. 10, the double SHA256 of a first block header 1002 in a block header chain 1010 (i.e., a chain of block headers) is compared to the HashPrevBlock of a second block header 1004 in the block header chain 1010, the double SHA256 of the second block header 1004 in the block header chain 1010 is compared to the HashPrevBlock of a third block header 1006 in the block header chain 1010, and so on until the double SHA256 of a second through last block (not shown) in the block header chain 1010 is compared to the HashPrevBlock of the last block header 1008 in the block header chain 1010.

[0174] The example environment 1000 illustrates that the OP_CHECKCHAINVERIFY script shown in Table 5 can be generalized to additional blocks by repeating the script shown in Table 5 for each block pair. Such a script is referred to herein as OP_CHECKBLOCKCHAINVERIFY.

[0175] As an example, an OP_CHECKBLOCKCHAINVERIFY script may take as input parameters the number of block headers in the block header chain, and the block headers in the block header chain, and repeatedly run OP_CHECKCHAINVERIFY. Table 6 shows an example of how the script might be used to verify a chain of six block headers. [Table 6] [Table 6]

[0176] Table 7 shows an example of an implementation of OP_CHECKBLOCKCHAINVERIFY that repeats the operation of OP_CHECKCHAINVERIFY for multiple blocks. In the example implementation of OP_CHECKBLOCKCHAINVERIFY shown in Table 7, the repeated portion is <d-1>The value range of this loop (e.g., <d>For each block header <d-1>loop) and performs an OP_CHECKCHAINVERIFY operation on each of the block header pairs using an alternate stack to preserve and maintain order. [Table 7] [Table 7]

[0177] FIG. 11 illustrates in flow chart form an example process 1100 for verifying that data is a block header chain in a script-based blockchain interaction, according to one embodiment. Some or all of the process 1100 may be executed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions executing collectively 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 in a magnetic, optical, or flash medium). The example process 1100 may be executed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may execute the example process 1100 for verifying that data is a block header chain in a script-based blockchain interaction, as described in connection with FIG. 11. Such a node may comprise any suitable computing device (e.g., a server in a data center, a client computing device, a plurality of computing devices in a distributed system of a computing resource service provider, or a suitable electronic client device such as computing device 200 described in connection with FIG. 2).

[0178] In step 1102 of the exemplary process 1100, the system<Data 1> ~<Data n> In step 1104 of the example process 1100, the system launches the OP_CHECKBLOCKCHAINVERIFY script on the ordered data set, as described above in connection with FIG.

[0179] In step 1106 of the exemplary process 1100, the system selects a first data item (e.g.,<Data 1> At step 1108 of the exemplary process 1100, the system selects a second data item (e.g.,<Data 2> In one embodiment, the system verifies that the first data item and the second data item are valid block headers, for example, using the OP_CHECKBLOCKVERIFY script described above in connection with Figures 6 and 7.

[0180] At step 1110 of the example process 1100, the system verifies that the first data item is a block before the second data item by performing OP_CHECKCHAINVERIFY on the first data item and the second data item as shown in Table 5, as described in connection with Figures 8 and 9.

[0181] At step 1112 of the exemplary process 1100, it is determined whether the OP_CHECKCHAINVERIFY script for the first data item and the second data item passes (i.e., whether the first data item is a block header before a block header in the second data item).

[0182] If, at step 1112 of the exemplary process 1100, it is determined that the OP_CHECKCHAINVERIFY script for the first data item and the second data item do not pass, at step 1114 of the exemplary process 1100, the first data item is not a block header before a block header in the second data item, and at step 1116 of the exemplary process 1100, the ordered data set is not a valid block header chain.

[0183] If, at step 1112 of the exemplary process 1100, it is determined that the OP_CHECKCHAINVERIFY script for the first data item and the second data item passed, then, at step 1118 of the exemplary process 1100, it is determined whether there is more data in the ordered data set.

[0184] If, at step 1118 of the exemplary process 1100, it is determined that there is more data in the ordered data set, then, at step 1120 of the exemplary process 1100, the second data item becomes the first data item in the exemplary process 1100, and at step 1122 of the exemplary process 1100, a new second data item is selected from the ordered data set based at least in part on the data order, and at step 1110 of the exemplary process 1100, the system verifies that the new first data item is a block before the new second data item by performing OP_CHECKCHAINVERIFY on the new first data item and the new second data item as shown in Table 5, described in connection with Figures 8 and 9.

[0185] If, in step 1118 of the example process 1100, it is determined that there is no more data in the ordered data set, then the ordered data set is a valid block header chain.

[0186] It is noted that one or more of the operations performed in the example process 1100 illustrated in FIG. 11 may be performed in various orders and combinations, including in parallel.

[0187] 12 illustrates in diagram form an example environment 1200 showing a Merkle tree of usable block headers in a script-based blockchain interaction, according to one embodiment. A Merkle tree (also called a "binary hash tree") is a data structure used to verify a set of transactions in a block. A Merkle tree is a binary tree that contains cryptographic hashes of the transactions. However, by repeatedly hashing and concatenating data, a Merkle tree can be stored as a single hash value (e.g., a single 32-byte or 256-bit value).

[0188] In the exemplary environment 1200, a Merkle tree 1204 is generated by (i) computing a hash of each of the transactions in the block, (ii) selecting pairs of hashes and concatenating them together, (iii) computing a hash of the concatenated values, and (iv) repeating the process at successive higher levels of the tree until a final hash value (the "Merkle root") is generated. This Merkle root is then inserted into the block header as the "HashMerkleRoot" value.

[0189] For example, starting with transaction 1206, a hash 1208 of the transaction is calculated. As used herein, a transaction is a A and the hash 1208 of the transaction 1206 is H(T A Similarly, a transaction (T B ) is hash 1212H(T B ) to generate the hash 1216, the left value is concatenated with the right value before being hashed 1214. Thus, the hash 1216 is H(H(T A )+H(T B )), where the "+" operator is overloaded in this case to represent concatenation (e.g., H(T A ) is "1234" and H(T B ) is "5678", then H(T A )+H(T B ) is "12345678", and H(H(T A )+H(T B )) is the hash of "12345678").

[0190] The exemplary environment 1200 also shows a Merkle branch. A Merkle branch is a set of nodes in a Merkle tree, associated with the Merkle root, that can be used to verify that the data of a particular leaf node (i.e., a particular transaction) is in the Merkle tree. Given the Merkle root and a Merkle branch, the existence of a given transaction (e.g., transaction 1218) in the Merkle tree can be verified as follows: First, a hash 1220 of the transaction is computed. Then, a hash 1224 of the next level of the Merkle tree is computed. However, as discussed above, the hash 1224 of the next level of the Merkle tree requires a hash 1222 of another transaction (e.g., the transaction that is the counterpart of transaction 1218 in the Merkle tree). This hash 1222 is the first node in the Merkle branch.

[0191] Given hash 1224, the hash 1226 of the next level of the Merkle tree is computed. This computation requires hash 1216 of the other transaction (e.g., the other branch) of the Merkle tree. This hash 1216 is the second node in the Merkle branch. As one might imagine, at each level of the Merkle tree, the Merkle branch requires a hash of a set of transactions in the "other" branch of the tree. Thus, assuming that the branch to the left of hash 1230 is the branch containing transaction 2118 (which can be computed as described above), to compute hash 1230, the hash 1228 of the right branch, which is the other node in the Merkle branch, is needed. Finally, to compute the Merkle root, the hash 1232 of the entire right side of the Merkle tree is needed. The Merkle branches that can be used to verify that transaction 1218 is in the Merkle tree 1204 are hash 1230, hash 1228, hash 1216, and hash 1222. Since the tree has a depth of four, there are four nodes in the Merkle branch. It should be noted that the depth of a Merkle tree depends on the number of transactions in a block and is the log2 of the number of transactions (i.e., at 512 transactions, the tree has a depth of 9 and the Merkle branch verifies that the node has 9 nodes, at 1024 transactions, the tree has a depth of 10 and the Merkle branch verifies that the node has 10 nodes, at 2048 transactions, the tree has a depth of 11 and the Merkle branch verifies that the node has 11 nodes, and so on). For example, if the average number of transactions per block in a Bitcoin block is around 2000, then a standard block will have a Merkle tree of depth 11.

[0192] FIG. 13 illustrates in diagram form an example environment 1300 in which a transaction is validated for inclusion in a block header for script-based blockchain interaction, according to one embodiment. As described herein, a block header is a portion of a block of a blockchain that contains data about the block. Part of the block header is the Merkle root of the Merkle tree ("HashMerkleRoot"), which cannot validate transactions in the block. When a block header is provided as an input to a lock script (e.g., provided as an unlock script) along with the transaction's Merkle branch and transaction, by encoding a constraint that the block header's HashMerkleRoot is the same as the computed Merkle root computed from the Merkle branch and transaction, if the block header's HashMerkleRoot is not the same as the computed Merkle root, then the block header, Merkle branch, and transaction are not a valid unlock script.

[0193] In step 1304, the first block header 1302 contains data for the unlock script (<Data 1> In step 1306, a script such as the OP_CHECKBLOCKVERIFY script described above in connection with FIGS.<Data 1> is used to verify that it is a block header. In step 1308, the HashMerkleRoot is extracted from the valid block header.

[0194] In step 1312, the Merkle branch 1310 receives the data for the unlock script (<Data 2> The Merkle branches 1310, not shown herein but which may be around 10, 11, or 12, are provided in an encoding format that indicates whether a particular node is a left input to a concatenation operation or a right input to a concatenation operation, as described herein.

[0195] Table 8 shows an example implementation of OP_CALCMERKLEROOT, where the Merkle branch 1310 is the pair <hash1> 、 <x1> 、 <hash2> 、 <x2>, ..., <hash d >, <x d > and value <d>, where: <d>indicates how many pairs are in the set of pairs, and each <hash i > is a hash of the values ​​from the Merkle tree, <x i > is a value (e.g., 0 or 1) indicating left or right linkage. In the example implementation of OP_CALCMERKLEROOT shown in Table 8, <x i A value of 1 in > indicates left concatenation, <x i A value of 0 in the > indicates right concatenation. [Table 8] [Table 8]

[0196] In step 1316, transaction 1314 receives the data for the unlock script (<Data 3> In step 1318, the Merkle root is provided as the Merkle root<Data 2> and transactions<Data 3> It is calculated using the OP_CALCMERKLEROOT script, not shown here.

[0197] In step 1320, the script:<Data 1> The HashMerkleRoot extracted from<Data 2> and<Data 3> This is run to verify that the computed Merkle root from the OP_CALCMERKLEROOT script run on<Data 1> The HashMerkleRoot extracted from<Data 2> and<Data 3> An example of a script that verifies that the Merkle root calculated from<Data 1> The block<Data 3> Transactions of<Data 2> 9 is an example of an OP_CHECKBLOCKTXVERIFY script that verifies using a Merkle branch of . As contemplated, other implementations of the OP_CHECKBLOCKTXVERIFY script may be implemented and are considered to be within the scope of this disclosure. In the OP_CHECKBLOCKTXVERIFY script shown in Table 9, the OP_CHECKBLOCKVERIFY operations are omitted for ease of explanation. [Table 9] [Table 9]

[0198] FIG. 14 illustrates in flow chart form an example process 1400 for verifying that a transaction is included in a block header in a script-based blockchain interaction, according to one embodiment. Some or all of the process 1400 may be executed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions executing collectively 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 in a magnetic, optical, or flash medium). The example process 1400 may be performed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may perform the example process 1400 for verifying that a transaction is included in a block header in a script-based blockchain interaction, as described in connection with FIG. 14. Such a node may comprise any suitable computing device (e.g., a server in a data center, a client computing device, a plurality of computing devices in a distributed system of a computing resource service provider, or a suitable electronic client device such as computing device 200 described in connection with FIG. 2).

[0199] In step 1402 of the exemplary process 1400, the system performs a step 1402 as described above in connection with FIG.<Data 1> ,<Data 2> , and<Data 3> In step 1402 of the exemplary process 1400, the system initiates execution of the OP_CHECKBLOCKTXVERIFY script, as described above in connection with FIG.<Data 1> ,<Data 2> , and<Data 3> Start with.

[0200] In step 1406 of the exemplary process 1400, the system performs a check using the OP_CHECKBLOCKVERIFY script, as described above in connection with FIGS.<Data 1> is a valid block header.

[0201] In step 1408 of the exemplary process 1400,<Data 1> In step 1408 of the exemplary process 1400, it is determined whether the OP_CHECKBLOCKVERIFY script for<Data 1> If it is determined that the OP_CHECKBLOCKVERIFY script for<Data 1> is not a valid block header, and in step 1412 of the exemplary process 1400,<Data 3> The transaction is<Data 1> It is not proven that the block is in a block with a block header in

[0202] In step 1408 of the exemplary process 1400,<Data 1> If it is determined that the OP_CHECKBLOCKVERIFY script for passed, then in step 1414 of the example process 1400, the system performs a check to verify the OP_CHECKBLOCKVERIFY script for<Data 1> In step 1416 of the example process 1400, the system extracts the HashMerkleRoot field from<Data 2> and<Data 3> Calculate the Merkle root from

[0203] In step 1418 of the exemplary process 1400, the system performs the steps as described above in connection with FIG.<Data 1> The HashMerkleRoot extracted from<Data 2> and<Data 3> Verify that it is equal to the Merkle root computed from

[0204] In step 1420 of the exemplary process 1400,<Data 1> The HashMerkleRoot extracted from<Data 2> and<Data 3> In step 1420 of the exemplary process 1400, it is determined whether<Data 1> The HashMerkleRoot extracted from<Data 2> and<Data 3> If it is determined that the Merkle root is not equal to the Merkle root calculated from<Data 3> The transaction is<Data 1> It is not proven that the block is in a block with a block header in

[0205] In step 1420 of the exemplary process 1400,<Data 1> The HashMerkleRoot extracted from<Data 2> and<Data 3> If it is determined that the Merkle root is equal to the Merkle root calculated from<Data 3> The transaction is<Data 1> It is proved that the block is in a block with a block header in

[0206] It is noted that one or more of the operations performed in the example process 1400 illustrated in FIG. 14 may be performed in various orders and combinations, including in parallel.

[0207] FIG. 15 illustrates, in diagram form, an example environment 1500 illustrating how a problem with accessing a blockchain associated with script-based blockchain interaction may be solved using the methods described herein, according to one embodiment. In the example environment 1500, a lock script 1504 in a transaction 1502 (e.g., a previous transaction such as the previous transaction 302 described in connection with FIG. 3 or an unlock transaction 304) cannot query the blockchain 1504 using one or more of the methods described in connection with FIGs. 6-14. This is in contrast to the example problem 400 described in connection with FIG. 4. Similarly, in the example environment 1500, a lock script 1506 in a transaction 1502 cannot query a block 1508 of the blockchain 1504 using one or more of the methods described in connection with FIGs. 6-14. This is in contrast to the example problem 500 described in connection with FIG. 5. In one embodiment, a transaction 1510 in block 1508 is the same as transaction 1502 (e.g., transaction Tx i (It is.)

[0208] FIG. 16 illustrates in diagram form an example environment 1600 illustrating a blockchain state associated with script-based blockchain interaction, according to one embodiment. The blockchain includes all blocks since the blockchain began. In the example environment 1600, the block header of the first block 1604 of the blockchain 1602 is a record of the state 1606 of the blockchain 1602 at the smallest nTime (e.g., the most recent or the first in time). Using the methods described herein, the transaction locking script can query the blockchain 1602, query the first block 1604, and query the state 1606 of the blockchain 1602 at the smallest nTime. Using the methods described herein, the transaction locking script can query the blockchain 1602, query a block 1608 of the blockchain 1602 (which may be a block that contains a transaction), and thus query the state 1610 of the blockchain 1602 at the block's nTime. Using the methods described herein, a locking script of a transaction can query the blockchain 1602, query the latest block 1612 of the blockchain 1602, and therefore query the state 1614 of the blockchain 1602 at nTime of the latest block (e.g., query the current state of the blockchain). The use of such state queries is detailed in Figures 17 and 18.

[0209] FIG. 17 illustrates in diagram form an example environment 1700 in which the state of a blockchain is verified in a script-based blockchain interaction, according to one embodiment. As described herein, a block header is a portion of a block of a blockchain that contains data about the block. Part of the block header is the Merkle root of the Merkle tree ("HashMerkleRoot"), which cannot validate transactions in the block. When a block header is provided as input to a lock script (e.g., provided as an unlock script) along with a transaction's Merkle branch and transaction, by encoding a constraint that the block header's HashMerkleRoot is the same as the computed Merkle root computed from the Merkle branch and transaction, if the block header's HashMerkleRoot is not the same as the computed Merkle root, then the block header, Merkle branch, and transaction are not a valid unlock script.

[0210] In one embodiment, checking the state of the blockchain and / or verifying the state of the blockchain includes checking other aspects of the blockchain, including, but not limited to, checking a block header of one or more blocks of the blockchain, checking a relationship between one or more blocks of the blockchain, checking the number of blocks of the blockchain, checking one or more transactions in a single block of the blockchain, or checking multiple transactions in multiple blocks of the blockchain.

[0211] In step 1708, the block header 1706 contains the data for the unlock script (<Data 1> In one embodiment, a script such as the OP_CHECKBLOCKVERIFY script described above in connection with FIGS.<Data 1> is used to verify that the block header is a block header. In step 1712, as described above in connection with Figures 13 and 14, the Merkle branch 1710 receives the data for the unlock script (<Data 2> In step 1716, transaction 1714 receives the data for the unlock script (<Data 3> In one embodiment, the Merkle root is provided as the Merkle root<Data 2> and transactions<Data 3> , using the OP_CALCMERKLEROOT script as described above in connection with FIGS. 13 and 14.

[0212] In step 1718, the OP_CHECKBLOCKTXVERIFY script:<Data 1> The HashMerkleRoot extracted from the<Data 2> and<Data 3> This is run to verify that the computed Merkle root from the OP_CALCMERKLEROOT script run on

[0213] It should be understood that step 1718 illustrates an example of a type of script that may be executed in an environment such as the exemplary environment 1700, where the state of the blockchain is verified in a script-based blockchain interaction according to one embodiment. Step 1718 illustrates a first set of constraints that allow a data set from the blockchain to be introduced into a transaction using an opcode. In one embodiment, OP_CHECKBLOCKVERIFY is used to verify that the data set includes a block header, as described herein. In one embodiment, OP_CHECKBLOCKTXVERIFY (i.e., shown in step 1718) is used to verify that the data set includes a transaction, and that the transaction is included in the block header. As contemplated, the examples of constraints in the first set of constraints described herein are illustrative examples, and other types of constraints in the first set of constraints may be considered within the scope of the present disclosure. A second set of constraints is described below with respect to step 1722.

[0214] In the exemplary environment 1700, in step 1704, the script checks the block header using a verification script such as OP_CHECKBLOCKCHAINVERIFY described above.<Data 1> is a block header of a block that is part of a public blockchain, rather than a block that was specifically created to mimic the public blockchain.<Data 1> is used to verify that it is a block header of a block that is part of a public blockchain, which may be provided with the blockchain 1702 or with a complete or partial block header chain.

[0215] In the exemplary environment 1700, the script is used to validate other aspects of the transaction in step 1722. In step 1720, the transaction 1714 receives data (<Data 3> It should be noted that in some embodiments, for example, the OP_CHECKBLOCKTXVERIFY script in step 1718 may be provided as a transaction<Data 3> When consuming, the transaction in step 1720<Data 3> is the transaction in step 1716<Data 3> This is a copy of.

[0216] As with step 1718 above, it should be noted that step 1722 illustrates an example of a type of script that may be executed in an environment such as the exemplary environment 1700, where the state of the blockchain is verified in a script-based blockchain interaction according to one embodiment. Step 1722 illustrates a second set of constraints associated with a dataset from the blockchain that are introduced into the transaction using an opcode, as described above in connection with step 1718. In one embodiment, the second set of constraints includes constraints on values ​​of data items in the dataset (i.e., constraints that the data items in the dataset are less than, equal to, or greater than, for example, a value). In one embodiment, the second set of constraints includes constraints determined from the data (e.g., a constraint that if the number of transactions in the block associated with the block header is greater than 100, then perform action "A", otherwise perform action "B"). As contemplated, the examples of constraints in the second set of constraints described herein are illustrative examples, and other types of constraints in the second set of constraints may be considered within the scope of the present disclosure.

[0217] In step 1704, the block header<Data 1> is a block header for a block that is part of the public blockchain, rather than a block that was specifically generated to mimic a block on the public blockchain, passes, then in step 1718, the OP_CHECKBLOCKTXVERIFY script<Data 1> The HashMerkleRoot extracted from<Data 2> and<Data 3> If the script used to verify other aspects of the transaction passes in step 1722, then the lock script succeeds in step 1724. In one embodiment, step 1704 indicates a third set of constraints associated with the dataset from the blockchain that are introduced into the transaction with the opcode (e.g., a constraint that the block is a block of a public blockchain).

[0218] It should be noted that, as discussed above, the script used to validate other aspects of the transaction at step 1722 includes a second set of constraints associated with the data set from the blockchain that is introduced into the transaction using the opcode. Thus, the second set of constraints, in one embodiment, includes validation of multiple aspects of the transaction, including, but not limited to, the transferee, the transferor, the amount of the transaction, or other aspects of the transaction. Additionally, it should be noted that the script used to validate other aspects of the transaction at step 1722 may include aspects of the blockchain, aspects of the block header chain, aspects of the block, or other aspects of the blockchain environment. For example, the script used to validate other aspects of the transaction at step 1722 and including constraints of the second set of constraints may include constraints for validating nTime of a block, for validating the number of transactions in a block, for determining the amount of time elapsed between two blocks, for determining a minimum block height, or for determining other such aspects of the blockchain environment. Also note that by not including a "verify" opcode at the end of the script that is used to verify other aspects of the transaction in step 1722, branching conditions may be introduced (e.g., if there are more than 1000 transactions in the block, Alice can break, if there are not more than 1000 transactions in the block, Bob can break). Examples of branching conditions are detailed below in connection with FIG. 30.

[0219] One issue associated with step 1704, namely, block headers<Data 1> However, the script used to verify that the block header is for a block that is part of the public blockchain, rather than a block that was specifically generated to mimic a block on the public blockchain, can in some embodiments be computationally very easy to generate a block specifically to mimic a block on the public blockchain. For example, it requires data in the unlock script to be included in the block header (e.g., the unlock script is just a block header, not a block header).<Data 1> Consider the lock script in Table 10. [Table 10] [Table 10]

[0220] In a Bitcoin implementation, when the mining difficulty (nBits) is set to its minimum value, the data can be the block header of a block in the public blockchain, but it can also be a completely unrelated block, since it does not require a huge amount of computing power to generate a block at the minimum mining difficulty. To prevent this from happening, the lock script generator should make the constraints on the lock script difficult enough so that the cost of computing power required to generate an alternative blockchain that mimics the public blockchain becomes significantly greater than the value of what can be unlocked. In Bitcoin, this can be achieved by increasing the mining difficulty (e.g., in the scripts shown in Table 3 and described in connection with Figures 6 and 7) or by requiring a longer chain of block headers (e.g., in the scripts shown in Table 6 and described in connection with Figures 10 and 11).

[0221] Table 11 shows an example of a script that may be used to validate other aspects of a transaction as in step 1724 (i.e., to determine whether aspects of the second and / or first constraint sets are satisfied). In the example script used to validate other aspects of a transaction shown in Table 11, data<Data 1> is a transaction<Data 3> The block header contains the block number 0, and is constrained by the transaction being paid to Bob's public key.<Scriptto Check Output of Data 3 is to P2KH of Bob> " is omitted here for purposes of explanation. [Table 11] [Table 11]

[0222] FIG. 18 illustrates, in flow chart form, an exemplary process 1800 for verifying a blockchain state in a script-based blockchain interaction, according to one embodiment. Some or all of the process 1800 may be executed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions executing collectively 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 in a magnetic, optical, or flash medium). The exemplary process 1800 may be performed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may perform the exemplary process 1800 for verifying a blockchain state in a script-based blockchain interaction, as described in connection with FIG. 18. Such a node may comprise any suitable computing device (e.g., a server in a data center, a client computing device, a plurality of computing devices in a distributed system of a computing resource service provider, or a suitable electronic client device such as computing device 200 described in connection with FIG. 2).

[0223] In step 1802 of the exemplary process 1800, the system performs a step 1802 as described above in connection with FIG.<Data 1> ,<Data 2> , and<Data 3> Receive.

[0224] In step 1804 of the exemplary process 1800, as described above in connection with FIG. 17, OP_CHECKBLOCKCHAINVERIFY is used to:<Data 1> is a block on the public blockchain. As mentioned above, OP_CHECKBLOCKCHAINVERIFY is an example of a script that can be used to determine whether constraints on a dataset (e.g., the third set of constraints above) are satisfied.

[0225] In step 1806 of the exemplary process 1800,<Data 1> It is determined whether the block is a block of a public blockchain.<Data 1> If it is determined that is not a block of a public blockchain, then in step 1808 of the exemplary process 1800,<Data 3> The transaction is<Data 1> 18, the block is not certified as having the block header, and the lock script fails at step 1810 of the exemplary process 1800.

[0226] In step 1806 of the exemplary process 1800,<Data 1> If it is determined that the block is a public blockchain block, then in step 1812 of the exemplary process 1800, the system checks the block using an OP_CHECKBLOCKTXVERIFY script such as the example shown in Table 9:<Data 3> Transactions of<Data 1> OP_CHECKBLOCKTXVERIFY verifies that the transaction is in a block having a block header of 0. As mentioned above, OP_CHECKBLOCKTXVERIFY is an example of a script that can be used to determine whether constraints on a dataset (e.g., the first set of constraints described above) are satisfied. In one embodiment, OP_CHECKBLOCKTXVERIFY is used to verify that a dataset contains a transaction, and that the transaction is contained in a block identified by a block header. In one embodiment, OP_CHECKBLOCKVERIFY is used to verify that a dataset contains a block header.

[0227] At step 1814 of the exemplary process 1800, it is determined whether OP_CHECKBLOCKTXVERIFY passed. If at step 1814 of the exemplary process 1800, OP_CHECKBLOCKTXVERIFY did not pass, at step 1816 of the exemplary process 1800,<Data 3> The transaction is<Data 1> block header, the lock script fails at step 1810 of the example process 1800.

[0228] If OP_CHECKBLOCKTXVERIFY passes at step 1814 of the exemplary process 1800, then at step 1818 of the exemplary process 1800, the system verifies one or more other aspects of the transaction as described herein (i.e., verifies that the constraints of a second constraint set associated with the dataset are satisfied).

[0229] At step 1820 of the exemplary process 1800, it is determined whether one or more other aspects of the transaction are verified. If at step 1820 of the exemplary process 1800, it is determined that one or more other aspects of the transaction are not verified, then at step 1810 of the exemplary process 1800, the release of the lock script fails.

[0230] If, at step 1820 of the example process 1800, it is determined that one or more other aspects of the transaction are verified, then, at step 1822 of the example process 1800, the lock script is successfully released.

[0231] It is noted that one or more of the operations performed in the example process 1800 illustrated in FIG. 18 may be performed in various orders and combinations, including in parallel.

[0232] 19 illustrates in diagram form an example problem 1900 with a lock script in script-based blockchain interaction solved by one embodiment. In the example problem, 1900 shown in FIG. 19, a lock script 1906 in a previous transaction 1902 cannot directly read a field of an unlock transaction 1904.

[0233] As mentioned above, in some embodiments, the previous transaction 1902 is the most current confirmed transaction included in the blockchain. Similarly, in some embodiments, the unlock transaction 1904 is a future transaction that has not yet been confirmed and not yet included in the blockchain that represents an attempt to transfer control of at least a portion of the digital assets controlled by the previous transaction 1902.

[0234] It should be noted that in some embodiments, the lock script 1906 is a script that blocks a transaction by specifying conditions that must be met in order for an output to be transferred. In particular, execution of the lock script 1906, as a result of execution by a validating node of the blockchain system, accepts data from the executed unlock script, performs certain operations based on the data, and returns a result indicating whether execution of the unlock script successfully "unlocked" the lock script (i.e., satisfied the conditions set in the lock script). In some embodiments, the lock script 1906 defines one or more data constraints that must be satisfied (e.g., by data provided by the unlock script) for the transaction to be successfully validated. For example, the lock script 1906 may require that certain data be provided in the unlock script in order to unlock the associated digital asset of the previous transaction 1902.

[0235] FIG. 20 illustrates in diagram form an example environment 2000 illustrating data access by an unlock script in a script-based blockchain interaction, according to one embodiment. FIG. 20 illustrates an example environment 2000 illustrating that an unlock script 2008 has access to fields of an unlock transaction 2004 (e.g., a set of unlock transaction fields determined according to a SIGHASH type) that are different from an unlock script 2006 of a previous transaction 2002 of the present disclosure, according to one embodiment. In some embodiments, the previous transaction 2002 is similar to the previous transaction 1902 of FIG. 19. In some embodiments, the unlock transaction 2004 is similar to the unlock transaction 1904 of FIG. 19. In some embodiments, the lock script 2006 is similar to the lock script 1906 of FIG. 19.

[0236] In some embodiments, the unlock script 2008 is an executable script imposed on the inputs of a transaction that attempts to satisfy a set of conditions imposed on the output of the transaction by the lock script. The lock script is also known as a "scriptSig." As described above, the unlock script 2008 is designed to provide a set of unlock transaction fields determined according to the SIGHASH type as input to the lock script, thereby giving the lock script access to the fields of the unlock transaction. Further details regarding the content and structure of consecutive transactions can be found in the discussion of FIG. 21 below.

[0237] FIG. 21 illustrates in diagram form an example environment 2100 in which a signature is generated from a consecutive set of transaction fields in a script-based blockchain interaction, according to one embodiment. As shown in FIG. 21, a consecutive transaction 2110 (i.e., a transaction represented as a series of bytes in a particular format) includes a set of transaction field values. A signer selects a SIGHASH type and a number k at 2112. The number k is typically a random or pseudorandom 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 2114 is an example of a set of fields of the consecutive transaction 2110 selected according to a specified SIGHASH type (e.g., in the example environment 2100, it is SIGHASH_NONE+ANYONECANPAY). The signer hashes the modified copy of transaction 2114 (e.g., performs OP_HASH256), resulting in message m2116. The signer then generates a signature using the SIGHASH type, the message m, the signer's private key (eg, a), and the number k, as described above in connection with FIG.

[0238] Table 12 shows an example of a standard unlock and unlock script, whereby the expected signature of entity A specified in the unlock script is checked against entity A's public key using the OP_CHECKSIG opcode. [Table 12] [Table 12]

[0239] Thus, with an understanding of the signature generation in FIG. 21, Table 13 shows an example of an unlock and lock script when portions of the procedures shown in example environment 2100 are moved into the unlock script. [Table 13] [Table 13]

[0240] The unlock script can be further modified to include the step of calculating the message m in the unlock script as shown in Table 14. [Table 14] [Table 14]

[0241] However, except for the SIGHASH type and the setting of the unlock transaction fields determined according to the SIGHASH type, the other operations of the procedure can be moved to the lock script as shown in Table 15. [Table 15] [Table 15]

[0242] Therefore, in the lock script, "OP_HASH256< / d> < / d> < / hash2> < / x1> < / hash1> < / d> < / data> < / data> < / data> < / data> < / data> < / data> < / data> < / data> < / data> < / data> < / data> < / data> < / n> < / n> < / n> < / n> < / n> < / k> < / k> < / pubkg> < / m> <k>By moving the "OP_GENSIG" action, the unlock script is made to contain the SIGHASH type and a set of unlock transaction fields that are determined according to the SIGHASH type to be valid.

[0243] In this manner, the sequence of previous transactions is incorporated into the lock script. Table 16 shows how the lock and unlock scripts execute the procedures for each step of the exemplary environment 2100 to verify transactions. [Table 16] [Table 16]

[0244] However, note 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. This can be a useful feature of the methods described herein. For example, one implementation of a smart contract can allow the contract to be implemented as a blockchain transaction. This frees the creator of the contract and / or any other party from the contract and ensures that the contract is fulfilled without requiring these parties to trust each other and without requiring these parties to manage or monitor the contract. In one implementation, some interaction with the contract is required. In one implementation, the contract is executed automatically without interaction with the contract.

[0245] As mentioned above, the smart contract may be executed automatically (or partially automatically) since any entity that provides a SIGHASH type and a set of unlocking transaction fields determined according to the SIGHASH type may receive the transaction output. In one embodiment, this property may be restricted by imposing additional constraints on the unlocking transaction. As a result, only some entities that provide a SIGHASH type and a set of unlocking transaction fields determined according to the SIGHASH type may receive the transaction output. Furthermore, the smart contract may be coded such that entities that provide a SIGHASH type and a set of unlocking transaction fields determined according to the SIGHASH type may only obtain the transaction output in a particular manner.

[0246] In one embodiment, the smart contract includes a value that acts as a signal detectable by a computer system to cause another computer system to validate the transaction. That is, the validating entity is induced to validate the transaction by providing a contingent obtainable upon execution of the validation of at least a portion of the digital asset, the transaction associated with the smart contract. For example, a smart contract associated with a digital asset of 1.0 is generated such that 0.9 of the digital asset is delivered to a designated recipient and the remaining 0.1 of the digital asset is available for claim by the validating entity. In this manner, the smart contract is executed. As contemplated, other methods of influencing an entity to obtain a transaction output and / or execute a smart contract are contemplated within the scope of this disclosure.

[0247] As used herein, a smart contract has both an auto-executing property and a self-enforcing property. The auto-executing property of a smart contract is a combination of two elements. The first element of the auto-executing property of a smart contract is that any entity can validly unlock the lock script. When any entity can validly unlock the lock script, any entity can generate a valid unlock transaction that references the UTXO and / or the lock script. This is because there is no constraint requiring the entity to prove that it has knowledge of any secret (e.g., a private key, or a value that generates a particular hash). However, it should be noted that this first element of the auto-executing property of a smart contract is limited as described herein. The second element of the auto-executing property of a smart contract is that the smart contract is automatic in that it may motivate other parties to unlock the lock script (e.g., by a bitcoin reward as described herein). The self-enforcing property of a smart contract is also a combination of two elements. The first element of the self-enforcing property of smart contracts is that constraints may be imposed on a contiguous set of unlocking transaction fields and these constraints are then reflected in the unlocking transaction. The second element of the self-enforcing property of smart contracts is that constraints in the locking script are enforced by the blockchain network.

[0248] FIG. 22 illustrates, in flow chart form, an exemplary process 2200 in which a signature causes the introduction of a successive set of unlocking transactions in a script-based blockchain interaction, according to one embodiment. Some or all of the exemplary process 2200 may be implemented as executable instructions executing collectively on one or more processors 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 in a non-transitory computer-readable storage medium (e.g., a computer program persistently stored in a magnetic, optical, or flash medium). The exemplary process 2200 may be performed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may perform the exemplary process 2200 to cause the introduction of a successive set of unlocking transaction fields in a script-based blockchain interaction, as described in connection with FIG. 22. Such a node may comprise any suitable computing device (e.g., a server in a data center, a client computing device, a plurality of computing devices in a distributed system of a computing resource service provider, or a suitable electronic client device such as computing device 200 described in connection with FIG. 2).

[0249] Exemplary process 2200 includes a series of operations in which a system performing exemplary process 2200 executes an unlock script and a lock script of an unvalidated transaction in conjunction with the method described in Figure 21 to obtain the resulting SIGHASH type and set of transaction field values, generate a signature, and verify the signature.

[0250] At step 2202 of the exemplary process 2200, the system obtains an unvalidated transaction from an entity seeking to transfer control of a digital asset. The unvalidated transaction includes a lock script and an unlock script. The unlock script is executed by the system prior to executing the lock script. The unlock script may be similar to the unlock script shown in Tables 15 and 16 above, indicating a SIGHASH type and a contiguous set of fields of the unvalidated transaction. At step 2204 of the exemplary process 2200, the system executing the exemplary process 2200 obtains the indicated SIGHASH type, and at step 2206 of the exemplary process 2200, obtains a contiguous set of transaction field values ​​of the unvalidated transaction. In one embodiment, once execution of the unlock script has been successfully completed, the system begins executing the lock script using the state of the primary stack (or, in some implementations, the state of the alternate stack) at the time execution of the unlock script has been completed. The lock script may be similar to the lock script shown in Tables 15 and 16 above.

[0251] At step 2208 of example process 2200, in accordance with the lock script, the system generates a signature using at least the SIGHASH type and the set of transaction field values ​​placed on the main stack as a result of execution of the unlock script, and the private key associated with the public-private key pair. At step 2210 of example process 2200, in accordance with the lock script, the system successfully verifies the signature against the public key of the key pair. Thus, the set of transaction fields are introduced into the lock script by the unlock script.

[0252] It is noted that one or more of the operations performed in the example process 2200 illustrated in FIG. 22 may be performed in various orders and combinations, including in parallel.

[0253] 23 illustrates in diagram form an example problem 2300 with a lock script in script-based blockchain interaction solved by one embodiment. In the example problem 2300 illustrated in FIG. 23, a lock script 2306 cannot read a transaction input that is embedded in a field of a previous transaction, and as a result cannot read the field directly.

[0254] In some embodiments, transaction 2304 is similar to an unlock transaction described herein that represents an attempt to transfer control of at least a portion of a digital asset controlled by a previous transaction. As noted above, in some embodiments, lock script 2306 is a script that blocks a transaction by specifying conditions that must be met in order to transfer an output, similar to the lock scripts described herein.

[0255] 24 illustrates, in diagram form, an example environment 2400 in which the introduction of a previous successive transaction is triggered in a script-based blockchain interaction, according to one embodiment. The example environment 2400 illustrated in FIG. 24 illustrates an unlock transaction 2404 having an unlock script 2408 that utilizes an output from a previous transaction 2402A-02B. As can be seen, the unlock script causes the successive previous transaction to be retrieved. In some examples, the successive previous transaction represents an unmodified version of a set of field values ​​of the previous transaction.

[0256] The embodiment shown in Figure 24 can be understood by noting that the transaction ID is the double SHA256 of consecutive transactions, and that the transaction ID has a one-to-one mapping with transactions. Thus, transactions can be introduced into the unlock script by applying the constraints shown in Table 17. [Table 17] [Table 17]

[0257] Embodiments of the present disclosure are further enhanced by the introduction of not only any consecutive transactions, but also one or more consecutive previous transactions (e.g., previous transactions 2404A-02B) that are referenced in the input of the unlock transaction 2404. As discussed above with reference to Figure 21, a set of unlock transaction fields determined according to the SIGHASH type can be introduced into the lock script via the unlock script 2406. Figure 25 shows which fields are included in consecutive transactions depending on the SIGHASH type.

[0258] FIG. 25 illustrates in diagram form an example environment 2500 in which a set of fields are made available depending on the signature hash type in a script-based blockchain interaction, according to one embodiment. However, it is noted that FIG. 25 is intended for illustrative purposes, and in various embodiments, there are more SIGHASH types than those shown in FIG. 25. As shown in FIG. 25, different SIGHASH types cause different sets of previous transaction IDs to be included in the set of unlock transaction fields determined according to the SIGHASH type (note that the "hash" field represents the transaction ID in big endian format). In some embodiments, the transaction ID of the transaction prior to embedding the lock script is always available, regardless of which SIGHASH type is specified.

[0259] Thus, a particular field can be ensured to be present in the determined set of unlock transaction fields by constraining the SIGHASH type in the following manner: First, duplicate the SIGHASH type. Second, push the SIGHASH type onto the stack (e.g., SIGHASH_ALL). Finally, call OP_EQUALVERIFY. As can be seen in FIG. 25, SIGHASH_ALL (shown with unlock transaction 2504A) includes hashes of previous transactions "y" and "z," representing transaction IDs, as discussed above. In contrast, SIGHASH_ALL+ANYONECANPAY (shown with unlock transaction 2504B) includes only the hash of the immediately preceding transaction "y." In some embodiments, unlock transactions 2504A-B are similar to unlock transaction 1904 of FIG. 19, which represents an attempt to transfer control of at least a portion of a digital asset controlled by a previous transaction (e.g., transaction y and / or x). Extracting the transaction ID can be accomplished by parsing successive transactions using the substring opcodes until the desired field is reached, as shown in FIG.

[0260] FIG. 26 illustrates, in diagram form, an example environment 2600 in which a transaction identifier is extracted from consecutive transactions in a script-based blockchain interaction, according to one embodiment. In the example environment 2600 illustrated in FIG. 26, a hash 2620 containing a transaction ID in big endian format is a substring of the consecutive transaction 2610 that can be extracted using a substring opcode in the script. In some embodiments, because some fields (e.g., #vin, scriptSigLen, scriptSig, scriptPubKeyLen, and scriptPubKey) are of variable byte length, the consecutive transaction 1020 is first parsed to locate the hash 2620 before the transaction ID can be extracted. However, in implementations where the fields have fixed lengths, it is contemplated that parsing may not be necessary.

[0261] Thus, in some embodiments, the previous transaction ID may be made accessible by constructing a lock script that forces the introduction of a particular consecutive previous transaction referenced in the unlock transaction in the manner described with reference to FIG. 22. For example, first the SIGHASH type constraint is determined, the transaction ID is extracted, and then the consecutive previous transaction is duplicated and checked against the transaction ID extracted from the consecutive field set of the unlock transaction (according to the SIGHASH type). Note that this process may be performed to force the introduction of multiple different consecutive previous transactions. As an example, Table 18 represents a script that causes the introduction of a previous transaction corresponding to an input of transaction X. The script shown in Table 18 is an example of an OP_PREVTXINJECTION script, which causes the introduction of a previous transaction corresponding to input X of the unlock transaction. [Table 18] [Table 18]

[0262] However, it is noted that any entity that provides a SIGHASH type and a set of unlock transaction fields determined according to the SIGHASH type, and the consecutive previous transaction, can obtain transaction outputs as described herein.

[0263] As another example, Table 19 shows a script that causes the injection of a previous transaction that corresponds to the input being signed. The script shown in Table 19 is an example of an OP_SELFTXINJECTION script, which causes the injection of a previous transaction that corresponds to the input being signed. [Table 19] [Table 19]

[0264] Note that any entity that provides a SIGHASH type and a set of unlock transaction fields determined according to the SIGHASH type and the consecutive previous transaction can receive a transaction output as described herein.

[0265] FIG. 27 illustrates, in flow chart form, an exemplary process 2700 for causing the introduction of a previous consecutive transaction in a script-based blockchain interaction, according to one embodiment. Some or all of the process 2700 may be executed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions executing collectively 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 in a magnetic, optical, or flash medium). The exemplary process 2700 may be executed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may execute the exemplary process 2700 for causing the introduction of a previous consecutive transaction in a script-based blockchain interaction, as described in connection with FIG. 27. Such a node may comprise any suitable computing device (e.g., a server in a data center, a client computing device, a plurality of computing devices in a distributed system of a computing resource service provider, or a suitable electronic client device such as computing device 200 described in connection with FIG. 2).

[0266] Exemplary process 2700 includes a series of operations in which a system executing exemplary process 2700 executes both an unlock script and a lock script of an unvalidated transaction to obtain the resulting previous consecutive transaction corresponding to the transaction ID extracted from the unvalidated transaction.

[0267] At step 2702 of the exemplary process 2700, the system obtains an unvalidated transaction from an entity seeking to transfer control of a digital asset. The unvalidated transaction includes a lock script and an unlock script. The lock script and unlock script may be similar to the lock script and unlock scripts shown in Tables 18 and 19. That is, the lock script includes an instruction set that takes as input values ​​stored in the main stack and alternate stack by the unlock script, for example. Execution of the instruction set, if evaluated to true, successfully validates the unvalidated transaction. Thus, the unlock script is executed before the lock script and sets values ​​in the main stack and alternate stack for use by the lock script. The unlock script of the unvalidated transaction in the embodiment of FIG. 27 shows a consecutive set of previous transaction, SIGHASH type, and unlock transaction fields.

[0268] As a result of the execution of the unlock script followed by the lock script, at step 2704 of the exemplary process 2700, the system obtains a consecutive set of consecutive previous transactions, the SIGHASH type, and the unlock transaction fields specified in the unlock script. At step 2706 of the exemplary process 2700, the system generates a signature of the consecutive set of field values ​​of the unverified transaction based on the SIGHASH. Note that the SIGHASH type affects which fields are used in the signature generation, and the desired SIGHASH may depend on the particular previous transaction desired. For example, Table 18 shows a lock script and an unlock script that extract a previous transaction that is not necessarily a previous transaction that contains the same lock script, and utilizes a SIGHASH type of SIGHASH_ALL. As shown in FIG. 25, the SIGHASH_ALL type allows the unlock transaction to read other previous transaction inputs. In contrast, Table 19 shows a lock script and an unlock script that extract a previous transaction that has the same lock script, and utilizes a SIGHASH type of SIGHASH_ALL|ANYONECANPAY. As shown in FIG. 25, a SIGHASH type of SIGHASH_ALL|ANYONECANPAY removes inputs of other previous transactions except for the previous transaction whose input is being signed.

[0269] At step 2708 of the exemplary process 2700, the system verifies the previously generated signature. At step 2710 of the exemplary process 2700, the system generates a value (i.e., a consecutive set of field values) that should match the transaction ID of the unlock transaction by performing a double SHA256 of the obtained consecutive previous transactions. Using the substring opcode, at step 2712 of the exemplary process 2700, the system extracts the transaction ID of the consecutive set of field values, and at step 2714 of the exemplary process 2700, the system determines whether the transaction ID generated by the double SHA256 of the consecutive previous transactions matches the transaction ID of the consecutive set of field values. It is noted that in various embodiments, a match does not necessarily require equality. For example, two values ​​may match if they are not equal but are mathematically equivalent. 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 of determining whether or not a match is true may be used.

[0270] It is noted that one or more of the operations performed in the example process 2700 illustrated in FIG. 27 may be performed in various orders and combinations, including in parallel.

[0271] 28 illustrates in diagram form an example environment 2800 in which blockchain state is used for script-based blockchain interaction, according to one embodiment. As described herein, a block header is a portion of a block of a blockchain that contains data about the block.

[0272] As described herein, in step 2804, the block header 2802 contains data for the unlock script (<Data 1> In one embodiment, a script such as the OP_CHECKBLOCKVERIFY script described above in connection with FIGS.<Data 1> is used to verify that the block header is a block header. In step 2808, the Merkle branch 2806 receives the data for the unlock script (<Data 2> In step 2812, transaction 2810 receives the data for the unlock script (<Data 3> In one embodiment, the Merkle root is provided as the Merkle root<Data 2> and transactions<Data 3> , using the OP_CALCMERKLEROOT script as described above in connection with FIGS. 13 and 14.

[0273] In step 2814, the OP_CHECKBLOCKTXVERIFY script:<Data 1> The HashMerkleRoot extracted from is shown in Table 9 above, as described in connection with Figures 13, 14, and 17.<Data 2> and<Data 3> This is run to verify that the computed Merkle root from the OP_CALCMERKLEROOT script run on

[0274] In step 2816, the OP_SELFTXINJECTION script:<Data 3> 26, 27, and 28, is executed to verify that the unlock script of the transaction includes a successive transaction that includes a lock script as shown in Tables 18 and 19.

[0275] In step 2818, if the OP_CHECKBLOCKTXVERIFY script in step 2814 and the OP_SELFTXINJECTION in step 2816 were successful, then, as described above,<Data 1> A block with a block header of<Data 3> containing,<Data 3> It can be seen that the unlock script of includes successive transactions of the lock script, and that the lock script has access to the blockchain state. Such a lock script may have access to information, including, but not limited to, time (i.e., from the nTime field of one or more block headers), pseudorandom numbers (i.e., from nNonce or HashMerkleRoot, both of which are good sources of pseudorandom numbers), or other information, some or all of which may be used within the lock script. Examples of such additional information are described in the example shown in FIG. 30.

[0276] In one embodiment, the script checks the block header using a verification script such as OP_CHECKBLOCKCHAINVERIFY described above.<Data 1> is a block header of a block that is part of a public blockchain, rather than a block that was specifically created to mimic the public blockchain.<Data 1> is used to verify that it is a block header of a block that is part of a public blockchain, which may be provided with the blockchain or with a complete or partial block header chain.

[0277] In one embodiment, the script may also be used to verify other aspects of the transaction and / or the blockchain state, as described above in connection with FIG. 17. As described above, the script used to verify other aspects of the transaction may include verification of multiple aspects of the transaction, including, but not limited to, the assignee, the assignor, the amount of the transaction, or other aspects of the transaction. Additionally, it is noted that the script used to verify other aspects of the transaction may include aspects of the blockchain, aspects of the blockchain state, aspects of the block header chain, aspects of the block, or other aspects of the blockchain environment. For example, the script used to verify other aspects of the transaction may verify the nTime of the block, the number of transactions in the block, the amount of time elapsed between two blocks, the minimum block height, or other aspects of the blockchain environment. It is also noted that by not including a "verify" opcode at the end of the script that is used to verify other aspects of the transaction, a branching condition may be introduced (e.g., if there are more than 1000 transactions in the block, Alice can break, and if there are not more than 1000 transactions in the block, Bob can break). Examples of branching conditions are detailed below in connection with FIG. 30.

[0278] Although not shown in the exemplary environment 2800, in one embodiment, additional scripts for validating other aspects of a transaction, such as the scripts shown in Table 11, described in connection with FIG. 17, may be executed as part of the exemplary environment 2800 depicted in FIG.

[0279] FIG. 29 illustrates, in flow chart form, an example process 2900 for using a blockchain state in a script-based blockchain interaction, according to one embodiment. Some or all of the process 2900 may be executed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions executing collectively 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 in a magnetic, optical, or flash medium). The example process 2900 may be performed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may perform the example process 2900 for using a blockchain state in a script-based blockchain interaction, as described in connection with FIG. 29. Such a node may comprise any suitable computing device (e.g., a server in a data center, a client computing device, a plurality of computing devices in a distributed system of a computing resource service provider, or a suitable electronic client device such as computing device 200 described in connection with FIG. 2).

[0280] In step 2902 of the exemplary process 2900, the system performs a step 2902 as described above in connection with FIG.<Data 1> ,<Data 2> , and<Data 3> Receive.

[0281] In step 2904 of the exemplary process 2900, as described above in connection with FIG. 17, OP_CHECKBLOCKCHAINVERIFY is used to:<Data 1> is a block on the public blockchain.

[0282] In step 2906 of the exemplary process 2900,<Data 1> It is determined whether the block is a block of a public blockchain.<Data 1> If it is determined that is not a block of a public blockchain, then in step 2908 of the example process 2900,<Data 3> The transaction is<Data 1> , and in step 2910 of example process 2900, the lock script cannot access the blockchain state.

[0283] In step 2906 of the exemplary process 2900,<Data 1> If it is determined that the block is a public blockchain block, then in step 2912 of the example process 2900, the system checks the block using an OP_CHECKBLOCKTXVERIFY script such as the example shown in Table 9:<Data 3> Transactions of<Data 1> Verify that the byte is in a block with the block header

[0284] At step 2914 of the exemplary process 2900, it is determined whether OP_CHECKBLOCKTXVERIFY passed. If at step 2914 of the exemplary process 2900, OP_CHECKBLOCKTXVERIFY did not pass, at step 2916 of the exemplary process 2900,<Data 3> The transaction is<Data 1> , and so in step 2910 of example process 2900, the lock script cannot access the blockchain state.

[0285] If, at step 2914 of the example process 2900, it is determined that OP_CHECKBLOCKTXVERIFY passed, then, at step 2918 of the example process 2900, the system uses an OP_SELFTXINJECTION script, such as the script shown in Table 19, to:<Data 3> ,Verify that the transaction contains consecutive transactions of the lock script.

[0286] In step 2920 of the exemplary process 2900,<Data 3> It is determined whether the unlock script of the transaction in includes a successive transaction of the lock script.<Data 3> If it is determined that the unlock script of the transaction in does not include a successive transaction of the lock script, then at step 2910 of example process 2900, the lock script cannot access the blockchain state.

[0287] In step 2920 of the exemplary process 2900,<Data 3> If it is determined that the unlock script of the transaction in includes a successive transaction of the lock script, then at step 2922 of the example process 2900, the lock script can access the blockchain state.

[0288] It is noted that one or more of the operations performed in the example process 2900 illustrated in FIG. 29 may be performed in various orders and combinations, including in parallel.

[0289] FIG. 30 illustrates in diagram form an example implementation 3000 of using blockchain state in script-based blockchain interaction, according to one embodiment. The example implementation 3000 illustrates some aspects of the methodology described herein. In the example implementation 3000, based on the time difference between the block of transactions containing their bet and the previous block, they determine that they want to make a bet on how long it will take for the block of transactions containing their bet to be added to the public blockchain. Each submits a single bitcoin, and if the time difference is less than 10 minutes, two bitcoins go to Alice. Conversely, if the time difference is not less than 10 minutes, two bitcoins go to Bob.

[0290] Alice contributes her half of the bet transaction 3002 with Bitcoin 3004. Bob contributes his half of the bet transaction 3002 with Bitcoin 3006. The bet transaction 3002 states that if the time difference (t2-t1) is less than 10 minutes, Alice gets 2 Bitcoins 3008. Conversely, if the time difference (t2-t1) is not less than 10 minutes, Bob gets 2 Bitcoins.

[0291] Using the methods described herein, it can be determined whether the bet transaction 3002 is in block B2 having block header 3014. Similarly, using the methods described herein, it can be determined whether block B1 having block header 3012 is the immediately preceding block. Finally, it can be determined whether nTime of block header 3014 is less than 10 minutes after nTime of block header 3012. Thus, the two bitcoins 3008 can be transferred to either Alice or Bob.

[0292] Table 20 shows an example locking script for this bet transaction 3002. The OP_EXTRACTTIME script used in the script shown in Table 20 is a script for extracting a time entry from the block header, similar to the script for extracting nBits shown in Table 3, but not shown here, as would be expected. [Table 20] [Table 20]

[0293] Accordingly, the specification and accompanying drawings are to be regarded in an illustrative rather than a restrictive sense, however it will be apparent that various modifications may be made therein without departing from the broader spirit and scope of the invention as set forth in the claims.

[0294] Other variations are within the spirit of the disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It is to be understood, however, that the invention is not limited to the particular form or forms disclosed, but rather, all modifications, alternative constructions and equivalents are intended to be embraced within the spirit and scope of the invention, as defined by the appended claims.

[0295] The terms "a," "an," and "the," and similar referents in the context of describing the disclosed embodiments (particularly in the context of the claims that follow) should be considered to cover both the singular and the plural unless otherwise specified or clearly contradicted by context. The terms "comprising," "having," "including," "including," "comprising," "having," "including," and "containing" should be considered in their broad sense (i.e., meaning "including, but not limited to") unless otherwise specified. The term "connected," when referring to an unaltered physical connection, should be considered as being partially or wholly contained, attached, or joined together, even if there is something in between. The recitation of ranges of values ​​herein is intended to serve merely as a shorthand way of referring individually to each separate value encompassed in the range, and each separate value is incorporated herein as if it were individually recited herein. Use of the term "set" (e.g., "set of items") or "subset" should be construed as a non-empty collection that contains one or more members, unless otherwise noted or contradicted by context. Further, unless otherwise noted or contradicted by context, the term "subset" of a corresponding set does not necessarily indicate a proper subset of the corresponding set, although a subset and a corresponding subset may be equivalent.

[0296] Logical language such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C" are understood to be used to express that an item, following, etc. may be either A or B or C, or any non-empty subset of the set A, B, and C, unless otherwise stated or otherwise clearly contradicted by the context. For example, in the illustrative example of a set having three components, the logical language "at least one of A, B, and C" or "at least one of A, B, and C" represents any of the following sets: {A}, {B}, {C}, {A,B}, {A,C}, {B,C}, {A,B,C}. Thus, such logical language is generally not intended to imply that a particular embodiment requires that each of at least one A, at least one B, and at least one C be present.

[0297] The operations of the processes described herein may be performed in any suitable order unless otherwise indicated herein or clearly contradicted by context. The processes described herein (or variations and / or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that collectively execute on one or more processors, in hardware, or a combination thereof. The code may be stored in a computer readable storage medium, e.g., 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.

[0298] The use of any and all examples or exemplary language (e.g., "such as") provided herein is intended merely to better illuminate embodiments of the invention and is not intended to limit the scope of the invention unless specifically stated. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the invention.

[0299] The embodiments of the present disclosure are described herein and include the best modes known to the inventors for carrying out the invention. Variations of these embodiments may become apparent to those skilled in the art upon reading the foregoing description. The inventors expect that skilled artisans will take advantage of these variations as appropriate, and the inventors intend for the embodiments of the present disclosure to be carried out in ways other than as specifically described herein. 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. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed within the scope of the present disclosure unless otherwise indicated herein or clearly contradicted by context.

[0300] It should be noted that, in the context of describing embodiments of the disclosure, unless otherwise specified, the use of language relating to executable instructions (also referred to as code, applications, agents, etc.) that perform actions that the "instructions" do not normally perform alone (e.g., transmitting data, performing calculations, etc.) indicates that the instructions are executed by a machine, thereby causing the machine to perform the specified operation.

[0301] It should be noted that the above-described embodiments do not limit the present invention, and that those skilled in the art can devise numerous alternative embodiments without departing from the scope of the present invention, which is defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claims. The word "comprising" or "comprises" and the like does not exclude the presence of elements or steps other than those listed in any claim and in the specification as a whole. In this specification, "comprises" means "includes" or "consists of", and "comprising" means "including" or "including of". The singular reference of an element does not exclude the presence of a plurality of such elements and vice versa. The invention can be implemented by means of hardware comprising several distinct elements, or by means of a suitably programmed computer. In a device claim enumerating several means, these several means may be implemented by one and the same hardware element. The fact that certain quantities are recited in mutually different dependent claims does not indicate that a combination of these quantities cannot be used to advantage. [Explanation of symbols]

[0302] 100 Blockchain Networks 102 nodes 104 Minor< / k> < / m>

Claims

1. 1. A computer-implemented method for verifying a blockchain transaction, the method comprising: At a node in a blockchain network, receiving a first blockchain transaction associated with a digital asset, the first blockchain transaction including a first script that specifies a set of constraints for a second blockchain transaction to transfer control of the digital asset, the set of constraints including a constraint that a data set obtained by the node includes information obtained from a blockchain associated with the blockchain network; obtaining the second blockchain transaction, the second blockchain transaction including a second script that, when executed, causes the node to obtain the data set; verifying the second block chain transaction by executing the first script and the second script; 23. A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, wherein the set of constraints includes a constraint that the dataset includes block headers of blocks of the blockchain.

3. 3. The computer-implemented method of claim 2, wherein the node determines whether a constraint that the dataset includes the block header of the block of the blockchain is satisfied by verifying that the block header has a predetermined size.

4. 3. The computer-implemented method of claim 2, wherein the node determines whether the constraint that the dataset includes the block header of the block of the blockchain is satisfied by verifying that the block header includes a mining difficulty value that is greater than or equal to a mining difficulty value.

5. 3. The computer-implemented method of claim 2, wherein the node determines whether the constraint that the dataset includes the block header of the block of the blockchain is satisfied by verifying that a hash of the block header is less than or equal to a target value calculated from a mining difficulty value included in the block header.

6. 6. The computer-implemented method of claim 1, wherein the set of constraints includes a constraint that the dataset includes a third transaction from a block of the blockchain.

7. 7. The computer-implemented method of claim 1, wherein the set of constraints includes a constraint that the dataset includes a block header chain that includes a block header ordered set, the block header ordered set including a plurality of block headers, and the block header ordered set specifies an order associated with the plurality of block headers.

8. 8. The computer-implemented method of claim 1, wherein the set of constraints includes a constraint that the dataset is obtained from a public blockchain of the blockchain network.

9. 9. The computer-implemented method of claim 1, wherein one or more characteristics of the blockchain network are provided to the node prior to executing the first script and the second script.

10. 10. The computer-implemented method of claim 1, wherein the step of validating the second blockchain transaction is successfully performed without verifying that an entity that generated the second blockchain transaction has access to secret information.

11. 11. The computer-implemented method of claim 1, wherein the first script is a lock script for the first blockchain transaction and the second script is an unlock script for the first script.

12. transferring the digital assets based at least in part on a result of the verifying step; 12. The computer-implemented method of claim 1, further comprising:

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

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

Images