Block recognition

Abstract

To provide a computer-implemented method.SOLUTION: A method includes a step of receiving a first transaction, the transaction specifying a first set of constraints on a second transaction to transfer control of a digital asset, the first set of constraints including constraints that cause the second transaction to contain a dataset from a blockchain network, and a second set of constraints, on the second transaction, including a constraint of including a block that includes the first transaction, the block being included in a blockchain associated with the blockchain network. The method also includes: a step of verifying that the first set of constraints and the second set of constraints are satisfied; and a step of transferring control of the digital asset based on the verifying step.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] This invention generally relates to distributed ledger technology including blockchain transactions, and more particularly to the introduction of fields from the blockchain, block headers, blocks, and blockchain transactions into transaction scripts. While not limited, this invention is particularly suitable for use in blockchain state-based transactions. [Background technology]

[0002] In this specification, the term “blockchain” is used to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known use of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. “Bitcoin” may be referred to for convenience and illustrative purposes as a useful use of the technology described herein, but Bitcoin is only one of many uses to which the technology described herein 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, but also includes non-commercial applications that fall within the scope of the present invention. For example, the technology described herein may offer the advantages of using blockchain implementations and other cryptocurrencies that have restrictions similar to Bitcoin with respect to constraints that can be encoded within cryptocurrency transactions, regardless of whether or not a cryptocurrency exchange occurs.

[0003] As used in this specification, “digital asset” is a unit of resource managed by a blockchain. A digital asset is a unit of resource managed by a blockchain. In some embodiments, a digital asset may be used as a cryptocurrency, but it is assumed that a digital asset may be used in other contexts, additionally or alternatively, as embodied. Note that while the present invention is applicable to the control of digital assets, it is inherently technical and usable in other contexts utilizing blockchain data structures, and does not necessarily involve the transfer of digital assets. When used in this disclosure, “digital asset” 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 to which control is transferred may, in this example, be a collection of multiple digital assets, and the collection itself is a digital asset. Similarly, a transaction may subdivide and / or combine these multiple inputs to produce one or more outputs, for example, the number of inputs and the number of outputs may differ. 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 group), and a single transaction may contain multiple types of tokens (e.g., shares in one or more different groups).

[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 within a blockchain transaction. A blockchain-based computer program may include rules that can process inputs to produce a result, which can then be used to perform an action depending on that result. If the lock script has access to both the unlock and the previous transaction, the blockchain can be used 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 can be written in natural language, smart contracts are computer programs designed to automate the execution of machine-readable contract or agreement clauses.

[0005] In some embodiments, interaction with a specific entity can be encoded in a specific step within a smart contract, while the smart contract can otherwise be automatically executed and self-executed. In some examples, automatic execution represents the execution of a smart contract that is successfully executed to enable the transfer of a UTXO. In such examples, it should be noted that the “entity” that can produce 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 activated without verifying that the data source (e.g., the entity that generated the unlock transaction) has access to a cryptographic secret (e.g., a secret asymmetric key, a symmetric key, etc.). Also in such examples, self-execution represents the execution of an unlock transaction by a verification node on the blockchain network, subject to constraints. In some examples, “unlocking” a UTXO is used in a technical sense to mean generating an unlock transaction that references and executes the UTXO as activated. Unlocking a UTXO is traditionally known as using the UTXO.

[0006] Blockchain transaction outputs include a lock script and information about ownership of a digital asset, such as Bitcoin. A lock script, often also called an encumbrance, "locks" a digital asset by specifying conditions that must be met in order to transfer a UTXO. For example, a lock script might require that certain data be provided within an unlock script in order to unlock the associated digital asset. A lock script is also known as a "scriptPubKey" in Bitcoin. Techniques that require a lock party to provide data to unlock a digital asset include embedding a hash of the data within the lock script. However, this becomes problematic when the data is indeterminate (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 within a block, or the contents of a block header), then when the lock script is generated, the data does not exist, and there are no opcodes within the blockchain to query the state of the blockchain to retrieve that data. Therefore, a lock script cannot request a specific block header, a specific state of the blockchain, or a transaction to be placed within a specific block of the blockchain. [Overview of the Initiative]

[0008] Therefore, it is desirable to provide a method and apparatus for improving blockchain technology in one or more of the above-described embodiments. Accordingly, according to the present invention, a method as defined in the appended claims is provided.

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

[0010] Accordingly, according to the present invention, methods (and corresponding systems) as defined in the appended claims may be provided. The methods may be described as blockchain data constraint methods. A computer-implemented method includes: (i) receiving a first transaction at a node in a blockchain network, which includes a first script specifying a set of constraints for a second transaction, the set of constraints including the constraint that a dataset obtained by the node includes information obtained from a blockchain associated with the blockchain network; (ii) obtaining the second transaction, which includes a second script that, as a result of being executed, causes the node to obtain the dataset; and (iii) verifying the second transaction by executing the first script and the second script.

[0011] As detailed below, computer-based methods and electronic devices are configured to implement constraints on data within the unlock script to require the blockchain to be in a specific state before the unlock script can be used to unlock the lock script and access the digital assets of the transaction. By implementing constraints on the lock script to require the unlock script to include a block header, blockchain, or block header chain, and by introducing such data into the unlock script at runtime, transactions can be based on the state of the blockchain.

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

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

[0014] The constraint set may include the constraint that the dataset contains the third transaction from a block in the blockchain.

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

[0016] A node may determine whether the constraint that a third transaction is included in a block is satisfied by, at least, the encoding of a transaction within the block, which is identified at least partially by the block header, based on the hash value of the third transaction. Alternatively, a node may determine whether the constraint that a third transaction is included in a block is satisfied by, at least, verifying that the hash value of the third transaction is equal to the hash value stored in the block header.

[0017] The constraint set may include a constraint that the data set includes a block header chain including a block header order set, the block header order set includes a plurality of block headers, and the block header order set specifies an order associated with the plurality of block headers.

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

[0019] The constraint set may include a constraint that the data set is obtained from the public blockchain of the blockchain network.

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

[0021] The verification of the second transaction may be successfully executed 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 of the first transaction, and the second transaction is an unlock script of the first script.

[0023] A computer-based method may further include a step of transferring a digital asset, at least in part, based on the results of verification. Accordingly, according to the present invention, a method (and corresponding system) as defined in the appended claims may be provided. The method may be described as a blockchain state verification method. A computer-based method includes (i) receiving a first transaction at a node in a blockchain network, the first transaction specifying at least a) a first constraint set for a second transaction, the first constraint set including one or more constraints causing the second transaction to include a dataset from the blockchain, and b) a second constraint set for the second transaction, the second constraint set including one or more constraints associated with data items of the dataset, and (ii) storing the second transaction on the blockchain as a result of verifying that the first constraint set and the second constraint set are satisfied.

[0024] As detailed below, computer-based methods and electronic devices are configured to implement constraints on data within the unlock script in order to require the blockchain to be in a specific state before the unlock script becomes available to unlock the lock script, and to coordinate access to the digital assets of the transaction in those states. By implementing constraints on the lock script in order to require the unlock script to include a block header, blockchain, or 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 dataset may be received by the node during the second transaction.

[0026] The method performed by the computer may further include the step of activating the second transaction as a result of the verification step.

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

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

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

[0030] The first constraint set may include the constraint that the dataset includes a block header chain which includes a block header sequence set, the block header sequence set includes a plurality of block headers, and the block header sequence set specifies the sequence associated with the plurality of block headers.

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

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

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

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

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

[0036] A node may determine whether the constraint that a dataset is received from a public blockchain is satisfied by receiving, at least, in a second transaction, a first blockset containing the block preceding the block received from the blockchain network, and a second blockset containing the block following the block received from the blockchain network. Alternatively, a node may determine whether the constraint that a dataset is received from a public blockchain is satisfied by verifying, at least, that the first blockset is chained to the block received from the blockchain network. Alternatively, a node may determine whether the constraint that a dataset is received from a public blockchain is satisfied by verifying, at least, that the second blockset is chained to the block received from the blockchain network. Alternatively, a node may determine whether the constraint that a dataset is received from a public blockchain is satisfied by verifying, at least, that the first and second blocksets are valid. Alternatively, a node may determine whether the constraint that a dataset is received from a public blockchain is met by verifying that each block in the first and second blocksets has a mining difficulty value greater than a predetermined value.

[0037] Accordingly, according to the present invention, methods (and corresponding systems) as defined in the appended claims may be provided. The methods may be described as blockchain state recognition methods. A computer-implemented method includes (i) receiving a first transaction at a node in a blockchain network, the first transaction specifying at least a) a first set of constraints for a second transaction, the first set of constraints including one or more constraints causing the second transaction to include a dataset from the 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 containing the first transaction, the block being included in a blockchain associated with the blockchain network; and (ii) recording the second transaction in the blockchain network as a result of the success of a step verifying that the first set of constraints and the second set of constraints are satisfied.

[0038] The dataset may be received by the node during the second transaction.

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

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

[0041] The first constraint set may include the constraint that the dataset includes a block header chain which includes a block header sequence set, the block header sequence set includes a plurality of block headers, and the block header sequence set specifies the sequence associated with the plurality of block headers.

[0042] The set of characteristics of the blockchain network may be provided to the nodes 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 in the blockchain of the blockchain network.

[0044] The first set of constraints may include the constraint that the second transaction contains a timestamp for the block. Additional or alternative, the step of verifying the constraint that the second transaction contains a timestamp for the block may be based, at least in part, on a set of blockchain network properties.

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

[0046] The first and second constraint sets may be included in the transaction's lock script.

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

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

[0049] A computer-implemented method may further include a step of activating a second transaction as a result of a step of verifying that a first set of constraints and a 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 sensitive information. Thus, according to the present invention, a method (and corresponding system) as defined in the appended claims may be provided. The method may be described as a blockchain data constraint method. A computer-implemented method includes the steps of: (i) receiving a first transaction associated with a digital asset at a node in a blockchain network, the first transaction comprising a first script specifying a set of constraints for a second transaction to transfer control of the digital asset, the set of constraints comprising the constraint that the dataset obtained by the node includes information obtained from a blockchain associated with the blockchain network; (ii) obtaining the second transaction, the second transaction comprising a second script which, as a result of execution, causes a node to obtain the dataset; and (iii) activating the second transaction by executing the first script and the second script.

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

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

[0052] The constraint set may include the constraint that the dataset contains the third transaction from a block in the blockchain.

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

[0054] A node may determine whether the constraint that a third transaction is included in a block is satisfied by, at least, the encoding of a transaction within the block, which is identified at least partially by the block header, based on the hash value of the third transaction. Alternatively, a node may determine whether the constraint that a third transaction is included in a block is satisfied by, at least, verifying that the hash value of the third transaction is equal to the hash value stored in the block header.

[0055] The first constraint set may include the constraint that the dataset includes a block header chain which includes a block header sequence set, the block header sequence set includes a plurality of block headers, and the block header sequence set specifies the sequence associated with the plurality of block headers.

[0056] A node may determine whether the constraint that a second script contains a block header chain is satisfied by selecting block header pairs based on an order associated with at least a number of block headers, where each block header pair includes a first block header and a second block header. Alternatively, a node may determine whether the constraint that a second script contains a block header chain is satisfied by verifying, for at least a block header pair, that the hash of the first block header of the block header pair is equal to the hash value stored in the second block header of the block header pair.

[0057] The constraint set may include the constraint that the dataset is obtained from a public blockchain on a blockchain network.

[0058] One or more properties of the blockchain network may be provided to the node before the first and second scripts are executed.

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

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

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

[0062] Accordingly, according to the present invention, methods (and corresponding systems) as defined in the appended claims may be provided. The methods may be described as blockchain state verification methods. A computer-implemented method includes: (i) receiving a first transaction associated with a digital asset at a node in a blockchain network, wherein the first transaction specifies 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 causing the second transaction to include a dataset from the blockchain; and b) a second set of constraints for the second transaction, the second set of constraints including one or more constraints associated with data items 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, at least in part based on the verifying step.

[0063] The dataset may be received by the node during the second transaction.

[0064] The method performed by the computer may further include the step of activating the second transaction as a result of the verification step.

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

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

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

[0068] The first constraint set may include the constraint that the dataset includes a block header chain which includes a block header sequence set, the block header sequence set includes a plurality of block headers, and the block header sequence set specifies the sequence associated with the plurality of block headers.

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

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

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

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

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

[0074] A node may determine whether the constraint that a dataset is received from a public blockchain is satisfied by receiving, at least, in a second transaction, a first blockset containing the block preceding the block received from the blockchain network, and a second blockset containing the block following the block received from the blockchain network. Alternatively, a node may determine whether the constraint that a dataset is received from a public blockchain is satisfied by verifying, at least, that the first blockset is chained to the block received from the blockchain network. Alternatively, a node may determine whether the constraint that a dataset is received from a public blockchain is satisfied by verifying, at least, that the second blockset is chained to the block received from the blockchain network. Alternatively, a node may determine whether the constraint that a dataset is received from a public blockchain is satisfied by verifying, at least, that the first and second blocksets are valid. Alternatively, a node may determine whether the constraint that a dataset is received from a public blockchain is met by verifying that each block in the first and second blocksets has a mining difficulty value greater than a predetermined value.

[0075] Accordingly, according to the present invention, methods (and corresponding systems) as defined in the appended claims may be provided. The methods may be described as blockchain state recognition methods. A computer-implemented method includes: (i) receiving a first transaction associated with a digital asset at a node in a blockchain network, 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 causing the second transaction to include a dataset from the 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 containing the first 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 at least in part based on the verifying step.

[0076] The dataset may be received by the node during the second transaction.

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

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

[0079] The first constraint set may include the constraint that the dataset includes a block header chain which includes a block header sequence set, the block header sequence set includes a plurality of block headers, and the block header sequence set specifies the sequence associated with the plurality of block headers.

[0080] The set of characteristics of the blockchain network may be provided to the nodes 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 in the blockchain of the blockchain network.

[0082] The first set of constraints may include the constraint that the second transaction contains a timestamp for the block. Additional or alternative, the step of verifying the constraint that the second transaction contains a timestamp for the block may be based, at least in part, on a set of blockchain network properties.

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

[0084] The first and second constraint sets may be included in the transaction's lock script.

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

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

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

[0088] Furthermore, it is desirable to provide a system that includes a processor and a memory containing executable instructions that cause the system to perform any of the methods described above as a result of execution by the processor.

[0089] Furthermore, it is desirable to provide a non-temporary computer-readable storage medium that stores executable instructions, wherein the executable instructions, as a result of being executed by the processor of the computer system, cause the computer system to perform at least one of the methods described above.

[0090] Furthermore, it is desirable to provide a system that includes a processor and a memory containing executable instructions that cause the system to perform any of the methods described above as a result of execution by the processor.

[0091] According to the present invention, an electronic device may be provided. The electronic device includes an interface device, a processor coupled to the interface device, and a memory coupled to the processor. The memory stores a computer executable that, when executed, configures the processor to perform the method described herein.

[0092] The present invention may provide a computer-readable storage medium which, when executed, includes computer-executable instructions that configure a processor to perform the method described herein.

[0093] The above-described and other aspects of the present invention are evident from the embodiments described herein and are taught with reference to those embodiments. Embodiments of the present invention are described below with reference to the accompanying drawings, merely as examples. [Brief explanation of the drawing]

[0094] [Figure 1] This diagram shows an exemplary blockchain network in which various embodiments can be implemented. [Figure 2] A diagram of an exemplary electronic device that can function as a node in a blockchain network, according to one embodiment, is shown. [Figure 3] The diagram shows an exemplary embodiment of a transaction associated with a script-based blockchain interaction. [Figure 4] A diagram illustrates an exemplary problem associated with accessing a blockchain related to script-based blockchain interaction, which is solved by one embodiment. [Figure 5] A diagram illustrates an exemplary problem associated with accessing blocks within a blockchain, related to script-based blockchain interaction, as solved by one embodiment. [Figure 6] A diagram of an exemplary environment is shown, according to one embodiment, in which data is verified to be block headers for script-based blockchain interaction. [Figure 7] A flowchart of an exemplary process, according to one embodiment, for verifying that data is a block header in a script-based blockchain interaction is shown. [Figure 8] A diagram of an exemplary environment is shown, according to one embodiment, in which data is verified to be the block header of the previous block for script-based blockchain interaction. [Figure 9] A flowchart illustrating an exemplary process, according to one embodiment, for verifying that data is the block header of the previous block in a script-based blockchain interaction is shown. [Figure 10] A diagram of an exemplary environment is shown, according to one embodiment, in which data is verified to be a block header chain for script-based blockchain interaction. [Figure 11] A flowchart of an exemplary process, according to one embodiment, for verifying that data is a block header chain in a script-based blockchain interaction is shown. [Figure 12] The diagram shows an exemplary environment in which data, according to one embodiment, represents a Merkle tree of available block headers in a script-based blockchain interaction. [Figure 13] A diagram of an exemplary environment is shown, according to one embodiment, in which a transaction is verified to be included in the block header for script-based blockchain interaction. [Figure 14] A flowchart illustrating an exemplary process, according to one embodiment, for verifying that a transaction is included in the block header of a script-based blockchain interaction is shown. [Figure 15] A diagram of an exemplary environment is shown illustrating how, according to one embodiment, the method described herein can resolve issues associated with accessing a blockchain related to script-based blockchain interaction. [Figure 16] A diagram illustrating an exemplary embodiment showing the state of a blockchain associated with a script-based blockchain interaction, according to one embodiment, is shown. [Figure 17] The diagram shows an exemplary embodiment in which the state of the blockchain is checked in a script-based blockchain interaction according to one embodiment. [Figure 18] A flowchart illustrating an exemplary process for checking the state of a blockchain in a script-based blockchain interaction according to one embodiment is shown. [Figure 19] This diagram illustrates an exemplary problem associated with lock scripts in script-based blockchain interactions, as solved by one embodiment. [Figure 20] This diagram illustrates an exemplary data access using an unlock script in a script-based blockchain interaction, according to one embodiment. [Figure 21] The diagram shows an exemplary environment in which a signature is generated from a sequence of transaction fields in a script-based blockchain interaction, according to one embodiment. [Figure 22] This diagram illustrates an exemplary process in which a signature, according to one embodiment, results in the introduction of a sequence of unlock transactions in a script-based blockchain interaction. [Figure 23] This diagram illustrates an exemplary problem associated with lock scripts in script-based blockchain interactions, as solved by one embodiment. [Figure 24] This diagram illustrates an exemplary environment in which the introduction of a previous sequence of transactions is triggered in a script-based blockchain interaction according to one embodiment. [Figure 25] This diagram shows an example of a fieldset that is made available depending on the signature hash type in a script-based blockchain interaction according to one embodiment. [Figure 26] This diagram shows an example of extracting a transaction identifier from a series of transactions in a script-based blockchain interaction according to one embodiment. [Figure 27] This diagram shows an exemplary process flowchart that results in the introduction of a series of previous transactions in a script-based blockchain interaction according to one embodiment. [Figure 28] The diagram shows an exemplary environment in which the state of the blockchain is used for script-based blockchain interaction, according to one embodiment. [Figure 29] A flowchart illustrating an exemplary process using the blockchain state in a script-based blockchain interaction according to one embodiment is shown. [Figure 30]A diagram illustrates an exemplary implementation of using blockchain state in a script-based blockchain interaction according to one embodiment. [Modes for carrying out the invention]

[0095] First, refer to Figure 1. Figure 1 shows an exemplary blockchain network 100 associated with a blockchain, in diagrammatic form, in which various embodiments can be implemented. The blockchain network 100 operates under a blockchain protocol, and decentralized electronic devices running an instance of the blockchain protocol may participate in the blockchain network 100. Such decentralized 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 nodes 102 of the blockchain network 100 may be of various types, including, for example, computers such as desktop computers, laptop computers, tablet computers, and servers; mobile devices such as smartphones; wearable computers such as smartwatches; or other electronic devices.

[0097] Nodes 102 of the blockchain network 100 are connected to each other using appropriate communication technologies, which may include wired and wireless communication technologies. Such communication follows the protocol associated with the blockchain. For example, if the blockchain is a Bitcoin blockchain, the Bitcoin protocol may be used. 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 blockchain, blocks are also verified by checking the proof-of-work submitted with the block.

[0098] At least some of the nodes 102 will act as miners 104 on the blockchain network 100. The blockchain network 100 in Figure 1 is a proof-of-work blockchain where miners 104 perform costly calculations to facilitate transactions on the blockchain. For example, a proof-of-work blockchain may require miners to solve a cryptographic problem. In Bitcoin, miner 104 discovers a nonce. As a result, the block header is hashed by double SHA-256 to a number smaller than the value determined by the current mining difficulty. The hashing power required for a proof-of-work algorithm means that after a certain number of blocks have been mined on it, the transaction is considered virtually irreversible. The miner 104 that solves the cryptographic problem generates a new block on the blockchain and broadcasts the new block to the other nodes 102. The other nodes 102 verify that miner 104 has actually solved the cryptographic problem and thus provided 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 (for example, that the transaction and block header of the block are valid) before allowing the block to be added to the blockchain. The block is added to the blockchain (i.e., the distributed global ledger) by consensus of all nodes 102.

[0099] A block generated by miner 104 contains transactions broadcast to the blockchain by node 102. For example, a block may contain a transaction from an address associated with one of node 102 to an address associated with another node 102. In this way, a block functions as a record of transactions from one address to another. Parties requesting a transaction to be included in a block prove that they are authorized to initiate the transfer (for example, transferring Bitcoin in the case of Bitcoin) by signing the request with their private key corresponding to their public key. Only if the request is validly signed may the transfer be added to the block.

[0100] In the case of Bitcoin, there is a one-to-one correspondence between a public key and an address. That is, each public key is associated with a single address. Therefore, references in this specification to transferring a digital asset to or from a public key (e.g., paying to the address associated with the public key) and transferring a digital asset to or from the address associated with the public key represent common actions.

[0101] Some of the Node 102 do not need to act as miners and may instead participate as verification nodes. Transaction verification may involve checking other conditions specified in the signature or lock script, verifying references to valid UTXOs, etc. The example in Figure 1 includes six Node 102, two of which participate as Miner 104. In practice, the number of Node 102 and Miner 104 may differ. In many blockchain networks, the number of Node 102 and Miner 104 may be much greater than the number shown in Figure 1.

[0102] Figure 2 shows, in block diagram form, an exemplary electronic device 200 that can function as a node (for example, one of the nodes 102 described in relation to Figure 1) in a blockchain network (for example, a blockchain network like blockchain network 100 described in relation to Figure 1). The exemplary electronic device 200 may function as one of the nodes 102 described in relation to Figure 1 in a blockchain network like the blockchain network described in relation to Figure 1. In one embodiment, the blockchain network is a peer-to-peer blockchain network.

[0103] Electronic devices may take various forms, including, for example, desktop computers, laptop computers, tablet computers, servers, mobile devices such as smartphones, wearable computers such as smartwatches, or other types of devices.

[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 containing machine-readable instructions and data for performing the functions described in this specification. For example, the memory may contain processor-executable instructions that, when executed by the processor 210, cause the electronic device to perform the methods described in this specification. The processor-executable instructions may contain 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 relation to Figure 1). For example, the instructions may contain instructions for implementing the Bitcoin protocol.

[0105] Memory 220 may store the global ledger or a portion thereof of the blockchain network (for example, the blockchain network 100 described in relation to Figure 1). In other words, memory 220 may store all the blocks of the blockchain, or a portion of a block such as the most recent block, or a portion of the information within some of the blocks.

[0106] Although memory 220 is shown as a single block in Figure 2, in reality, the electronic device 200 may include multiple memory components. These 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. Furthermore, although memory 220 is shown separately from the processor 210, the processor 210 may include built-in memory.

[0107] As shown in Figure 2, the processor 210 may include a secure area such as a Trusted Execution Environment (TEE). The TEE 250 is an independent execution environment that provides the electronic device 200 with additional security such as independent execution, trusted application integrity, and asset confidentiality. The TEE 250 provides an execution space that ensures that computer instructions and data loaded within 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, instructions and data executed within the TEE 250 are protected from access and manipulation from the rest of the electronic device 200 and from external parties such as the owner of the electronic device. Data and calculations within the TEE 250 are secured from parties operating the node containing the TEE 250 (e.g., node 102 as described in relation to Figure 1).

[0108] TEE250 may operate by instantiating a secure execution environment (also referred to in this specification as an "enclave") and then adding memory pages one by one, while simultaneously hashing the added memory pages cumulatively. In one embodiment, the hashing of 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 therefore be verified by any remote machine, ensuring that the enclave is executing an approved algorithm. This verification may be performed by comparing hashes. Once fully constructed, the enclave is fixed. It is possible to execute code within TEE250 and to send secrets to the code, but once the enclave is locked, the code cannot be modified. The final hash may be signed with an attestation key and made available for verification by the data owner before the data owner sends any secrets to the enclave.

[0109] TEE250 may be used to protect the authenticity and integrity of encryption keys stored within TEE250. For example, TEE250 may be used for generating and storing private key shares. TEE250 is intended to ensure that no member can directly obtain information about private key shares or other private key shares held within TEE250 through member-to-member or inter-enclave communications. The protocol is robust against compromises of a threshold enclave. Furthermore, TEE250 may enable remote attestation. Remote attestation may be used by a node (for example, one of the nodes 102 described in relation to Figure 1) to prove to other nodes that TEE250 is reliable and executing approved computer executable instructions for the protocol implemented by the blockchain network 100. Remote attestation may be provided by TEE250 by executing a specific code piece and, within the enclave, by transmitting a hash of the code signed with the enclave's internal attestation key.

[0110] The TEE250 may include a secure random number generator. This secure random number generator resides within the TEE's enclave and can be used to generate a secret key, a random challenge, or other random data. The TEE250 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] TEE250 may be implemented using various platforms such as a Trusted Platform Module (TPM) or Intel Software Guard Extensions (SGX). SGX supports, for example, remote attestation. Remote attestation allows an enclave to retrieve signed statements from a processor running a particular enclave by a given hash of a member known as a quote. A third-party attestation service, such as Intel Attestation Service (IAS), can certify that these certified 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 the lock script of a blockchain transaction (Tx) using unconfirmed data provided in the unlock script of another transaction. For example, when used in conjunction with a signature check opcode (e.g., OP_CHECKSIG) in the Bitcoin protocol, which uses a sequence of 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 method described herein verifies various transactions using one or more digital signature schemes. 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 constitute a valid signature without requiring the reconstruction of private keys and without requiring any party to disclose their key share to another party. For example, in a two-party ECDSA scheme, there are two parties, and both need to reconstruct their private keys.

[0114] This ECDSA scheme includes various mechanisms that can be used by nodes, such as node 102 as described in relation to Figure 1, to identify fraudulent or uncooperative 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 divided into parts, each provided for participation in its own unique part. These parts may be necessary to reconstruct the secret. VSS may be used by nodes to identify fraudulent nodes or members if inconsistent shares are provided to different nodes, or if shares are sent secretly to nodes, unlike hidden (blind) shares in which shares are broadcast to all nodes. Inconsistent shares may be identified by any of the nodes. Secret sharing can be made verifiable by including auxiliary information that enables nodes to verify that their shares are consistent.

[0115] The transmission of malicious shares to individual nodes (i.e., shares different from broadcasted hidden shares) can be identified by the intended receiving nodes of the shares. Identification of malicious shares being secretly transmitted to nodes can be made publicly verifiable using Publicly Verifiable Secret Sharing (PVSS) techniques. Such techniques can avoid potential delays in identifying the malicious sender that may occur when PVSS is not used and the recipient of the malicious share is offline or disconnected from the core of the network when the malicious share is transmitted.

[0116] Fraudulent activities, such as providing conflicting shares to different nodes, can be resolved by a network designed to prevent malicious activity. For example, if a node is identified as a malicious party by other nodes, a number of nodes may cooperate to penalize the malicious party. For example, a node may take action relating to digital assets (digital currency, tokens, or other stakes or values) deposited into the blockchain network by a fraudulent party. For example, the blockchain network may burn them by transferring the digital currency, tokens, stakes or values ​​to an unredeemable address. Alternatively, the blockchain network may confiscate such digital assets by reaching a consensus with other nodes to reject them. Nodes that are not fraudulent may prevent fraudulent activity by cooperating to remove fraudulent nodes (for example, by effectively invalidating key shares, by preventing nodes from participating in parliamentary protocols, or by resharing private keys and not allocating shares to fraudulent nodes).

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

[0118] For example, if all nodes possess a TEE, retrieving the secrets stored within the enclave can only be achieved through physical access to the nodes, and only with considerable effort and expense, provided the TEE's maker is not corrupt. Such maker-level corruption is expected to be manageable. For instance, if a maker attempts to falsely claim that a large number of public keys correspond to a sincere TEE, they could gain direct access to the private key share and launch an attack. However, such an attack might require a sufficient number of key shares for the maker to generate valid signatures without assistance from other nodes. This could mean accumulating a large portion of the entire stake, which could be extremely expensive. Furthermore, executing the attack could destroy a large portion of the value of the stake held.

[0119] When a TEE is used, it is useful to intend the robustness of the protocol against "corrupted nodes." A corrupted node is one in which the external hardware of the TEE contains errors, but the integrity of the TEE is not compromised. A corrupted node may have control over what information the enclave receives and does not receive. In particular, a corrupted node may shut down, i.e., refrain from participating in the protocol. If the information provided to the protocol needs to be signed with a private key secretly held within the enclave (if the corresponding public key was authenticated during attestation), the private key is as trustworthy as the enclave itself. Therefore, a corrupted node cannot send arbitrary (authenticated) information to the protocol and can only try to disrupt it by shutting down or by attempting to trick the enclave into malfunctioning, for example by providing outdated information. Next, on a corrupted node, a successful attack may require collecting enough partial signatures to generate a complete signature.

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

[0121] Figure 3 illustrates an exemplary embodiment 300 of a transaction associated with a script-based blockchain interaction in graphic form. The exemplary embodiment 300 shown in Figure 3 illustrates a blockchain transaction 302 prior to encoding a first state 306 of the blockchain, and an unlock blockchain transaction 304 encoding a second state 308 of the blockchain. In the exemplary embodiment 300, the current state 306 at the first time is represented as a parameter embedded in the preceding transaction 302. In one embodiment, the unlock transaction 304 includes a parameter representing the next state 308.

[0122] In 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 intention to transfer control of a digital asset from at least one entity to at least one other entity. In exemplary embodiment 300, previous transaction 302 is the most current confirmed transaction included in the blockchain. In exemplary embodiment 300, 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 unlock transaction 304 receives the output of previous transaction 302.

[0123] Several blockchain technologies, like Bitcoin, use the elliptic curve digital signature algorithm (ECDSA) as a function for digital signatures. In embodiments, ECDSA is a cryptographic digital signature used to ensure that a UTXO is transferred only to its rightful owner. In Bitcoin, the elliptic curve digital signature (ECDS) typically appears with a signature hash flag (SIGHASH type) appended to the end. However, the technology of this disclosure is intended to be usable with blockchain technologies that do not implement the SIGHASH type. In such blockchain technologies, the ECDS is intended to conform to the signature generation principle of the specific blockchain technology.

[0124] In some embodiments, the SIGHASH type represents the set of fields to be extracted from a transaction before it is serialized (e.g., canonicalized) and hashed. For example, the SIGHASH type can influence which fields of a transaction are included in the signature. In some examples, the SIGHASH type can be one or more of SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, or SIGHASH_ANYONECANPAY. In one embodiment, type SIGHASH_ALL indicates that all fields in the transaction, except for the input script, should be hashed and signed. In one embodiment, type SIGHASH_NONE indicates that the output does not need to be signed. This may allow others to update the transaction. In one embodiment, 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 remains in the same position as the input. In one embodiment, the type SIGHASH_ANYONECANPAY is combined with other types to indicate that inputs containing SIGHASH_ANYONECANPAY are to be signed, but other inputs do not need to be signed. A SIGHASH type can be represented by a value that indicates the SIGHASH type. For example, in some implementations, SIGHASH_ALL is represented by a byte with the value 1, SIGHASH_NONE is represented by a byte with the value 2 (e.g., "00000010"), SIGHASH_SINGLE is represented by a byte with the value 3 (e.g., "00000011"), and SIGHASH_ANYONECANPAY is represented by a byte with the value 80 (e.g., "01010000"). Combining SIGHASH types is performed in some embodiments by adding the byte values ​​together.

[0125] In some cases, the transaction fieldset determined by the SIGHASH type represents a subset of the corresponding transaction, encoded in bytes, as determined by the SIGHASH type. For example, with the SIGHASH type 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 distinguished encoding rules (DER) format. However, it should be noted that the technology 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 the ECDSA are K (an elliptic curve point with coordinates (x,y)), k (a 256-bit number, usually random to protect the secret key), G (a base point on an elliptic curve of degree n, n × G = 0, where 0 represents the identity elliptic curve point and n is a large prime number used as a parameter within the finite field of the elliptic curve), r (one of the 256-bit numbers in the ECDS), s (the other of the 256-bit numbers in the signature), k -1 (The modular reciprocal of k, i.e., k l k = l mod n), m (signed message / data, which in this embodiment is resized to 256 bits by a hash function), a (private key, e.g., a 256-bit number). In this embodiment, the ECDS is generated as follows:

[0127] First, the elliptic curve point K is determined by multiplying k by the generator: K = k × G. Next, the point x is determined from K, and the first 256-bit number r in the ECDS is determined according to the equation r = x mod n. Next, the second 256-bit number s in the ECDS is determined by the equation s = k lIt is determined according to (m+r×a) mod n. Finally, (r,s) is encoded in DER format. Given the signature (r,s), 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 The expression ×(m×G+r×y) is calculated. If v=r, the signature is valid.

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

[0129] Certain embodiments of this disclosure operate under the assumption that the description system or other system implementing the described instruction set allows for more than 200 instructions (e.g., opcodes) in a single script, which is a violation limit in certain implementations of Bitcoin. Similarly, certain embodiments of this disclosure further assume that the functionality provided by the opcodes referenced in this disclosure exists and is enabled within 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 an elliptic curve point. OP_ADD: Adds the top two items in the stack. OP_BIGMOD: Returns the remainder after dividing the top two items in the stack. OP_BIGMODADD: Performs the modulo operation on the third item in the stack of the modulo sum of the top two items in the stack. OP_BIGMODINVERSE: Performs modulo operations on negative exponents. OP_BIGMODMUL: Performs the modulo of the third item in the stack, which is the modulo product of the top two items in 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. 1 is returned if the signature is valid, otherwise 0 is returned. OP_CHECKSIGVERIFY: This has the same functionality as OP_CHECKSIG, but OP_VERIFY is executed afterward. OP_DERENCODE: Encodes the top two items in the stack in DER format. OP_DUP: Duplicates the top stack item. OP_ECPMULT: Performs elliptic curve multiplication of the top two items in the stack. OP_ELSE: If the preceding OP_IF, OP_NOTIF, or OP_ELSE is not executed, these statements are executed; otherwise, if the preceding OP_IF, OP_NOTIF, or OP_ELSE is executed, these statements are not executed. OP_ENDIF: Exits the if / else block. OP_EQUAL: Returns 1 if the inputs are exactly equal, otherwise returns 0. OP_EQUALVERIFY: Same as OP_EQUAL, but OP_VERIFY is executed afterwards. OP_FROMALTSTACK: Places the input on top of the main 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 statement is executed and the top value is removed. OP_NOTIF: If the top value is false, the statement is executed and the top value is removed. OP_ROLL: The item at n item depth in the stack is moved to the top. OP_SUBSTR: Returns a section of a string. OP_SWAP: The top two items in the stack are swapped. OP_TOALTSTACK: Places the input on top of the alternate stack and removes it from the main stack. OP_VERIFY: Marks the transaction invalid if the top stack value is not true.

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

[0132] In the script shown in Table 1 above,<SIGHASH Byte> ,message <m>Secret Key , and numerical values <k>In the order described above (for example, after inserting 4 items, the number <k> The first element is at the top of the stack, followed by the private key.< / k> < / k> Next, the message <m>,lastly<SIGHASH Byte> (The following is followed) It is then entered into the main stack (for example, the last card played first).

[0133] Script operations "OP_DUP OP_TOALTSTACK" <pubkg>The execution of "OP_ECPMULT" is numerical. <k>Copy it to the alternate stack. <k>This is an elliptic curve generator.<PubK G> This is multiplied by the value to generate the elliptic curve point K at the top of the main stack.

[0134] Script operation "OP_ECPX" <n>The execution of "OP_BIGMOD OP_DUP OP_TOALTSTACK" causes r to be calculated from the x-coordinate of K modulo 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>The execution of "OP_BIGMODMUL" 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> Connect them together.

[0136] In this disclosure, this script is referred to as OP_GENSIG. Therefore, references to OP_GENSIG in embodiments of this disclosure should be considered as abbreviations for the operations performed by the script described above.

[0137] Figure 4 illustrates in diagrammatic form an exemplary problem 400 associated with access to the blockchain in relation to script-based blockchain interaction, which is resolved by one embodiment. In the exemplary problem 400 shown in Figure 4, a lock script 406 within transaction 402 (for example, a previous transaction such as the previous transaction 302 described in relation to Figure 3 or an unlock transaction 304) cannot access blockchain 404.

[0138] As described above, in some embodiments, transaction 402 is the most current (most recent) 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 some of the digital assets controlled by a previous transaction, which have not yet been confirmed and are not yet included in the blockchain.

[0139] In some embodiments, the lock script 406 is a script that prevents a transaction by specifying conditions that must be met in order to transfer an output. Specifically, the execution of the lock script 406, as a result of execution by a verification node of the blockchain system, receives data from the executed unlock script, performs a specific operation based on that data, and returns a result indicating whether the execution of the unlock script successfully "unlocked" the lock script (i.e., whether the set of conditions set within the lock script was met). In some embodiments, the lock script 406 defines one or more data constraints that must be met (for example, by the data provided by the unlock script) in order for the transaction verification to succeed. For example, the lock script 406 may require that certain data be provided within the unlock script in order to unlock the digital asset associated with transaction 402.

[0140] As illustrated in Exemplary Problem 400, the lock script 406 of transaction 402 cannot query blockchain 404 and determine, for example, the number of blocks. The lock script 406 of transaction 402 also cannot query any blocks of blockchain 404, including the first block 408 (also called the "genesis block"), any of the internal blocks of blockchain 404 (e.g., block 410), or the last block 412 of blockchain 404. The method described herein enables the lock script 406 of transaction 402 to query any blocks of blockchain 404, including the first block 408, an internal block (e.g., block 410), or the last block 412.

[0141] Figure 5 illustrates in diagrammatic form an exemplary problem 500 associated with accessing blocks in a blockchain in relation to script-based blockchain interaction, which is solved by one embodiment. In the exemplary problem 500 shown in Figure 5, a lock script 506 in transaction 502 (for example, a previous transaction such as previous transaction 502 described in relation to Figure 3, or an unlock transaction such as unlock transaction 304 described in relation to 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 described above, in some embodiments, transaction 502 is the most current (most recent) confirmed transaction included in the blockchain. Similarly, in some embodiments, transaction 502 is a future transaction representing an attempt to transfer control of at least some of the digital assets controlled by a previous transaction, which have not yet been confirmed and are not yet included in the blockchain.

[0143] In some embodiments, as described in this specification, the lock script 506 is a script that prevents a transaction by specifying conditions that must be met in order to transfer the output. As shown in Exemplary Problem 500, the lock script 506 of transaction 502 cannot query block 504 of the blockchain, for example, to determine the block number, or to access a particular transaction. As shown in Exemplary Problem 500, the lock script 506 of transaction 502 cannot query block 504 of the blockchain, cannot query the block header 508 of block 504, and cannot query the transactions of block 504. Block 504 is transaction 502 (transaction Tx of transaction 510 of block 504) i In one embodiment, including (shown as 512), the lock script 506 for transaction 502 is for transaction Tx i 512 cannot be queried (for example, a transaction containing lock script 506 cannot be queried). The method described herein enables lock script 506 of transaction 502 to query block 504 of the blockchain, query the block header 508 of block 504, query transaction 510 of block 504, and query transaction Txi512 of transaction 510 of block 504 (for example, enabling lock script to query a transaction containing lock script 506).

[0144] Figure 6 graphically illustrates an exemplary environment 600 according to one embodiment, in which data is verified to be a block header for script-based blockchain interaction. A block header is part of a blockchain block that contains data about the block. For example, a block header 602 is 80 bytes of data having the first 4 bytes to store the blockchain implementation version ("nVersion"), the next 32 bytes (or 256 bits) to store the hash of the previous block on the blockchain ("HashPrevBlock"), the next 32 bytes to store the hash of the Merkle tree of the block's transactions ("HashMerkleRoot", which is detailed in this specification), the next 4 bytes to store the block's generation time ("nTime"), the next 4 bytes to store the block's 32-bit mining difficulty value ("nBits"), and the last 4 bytes to store the block's random seed ("nNonce").

[0145] As can be seen from the diagram, if block header 602 is data used as input to a lock script (for example, provided as an unlock script), then by encoding the constraints on block header 602 into the lock script, the unlock script data must contain a valid block header; otherwise, it is not a valid unlock script. The three constraints on a block header like 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 specific mining difficulty value, and (iii) the double SHA256 of the block header must be less than or equal to the mining difficulty value. Each of these constraints is described here as a separate script, and details of the links between scripts (e.g., branch constraints and stack maintenance) are omitted for the sake of clarity.

[0146] The three scripts are combined into a single script, with the details of the links between them omitted, and this is within the unlock script. <data>This is an example of an OP_CHECKBLOCKVERIFY script that verifies that a block header is valid. In the illustrated example, the three scripts return true or false, but when they are linked together into a single script to generate the OP_CHECKBLOCKVERIFY script, OP_VERIFY is appended to the end of each script by default. As is conceivable, 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 the unlock script. <data>It is shown as follows.

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

[0149] In 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 in 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 (performed by the 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 the following two additional opcodes.

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

[0152] Figure 7 shows a flowchart illustrating an exemplary process 700 in which data is verified to be a block header in a script-based blockchain interaction, according to one embodiment. Part or all of the process 700 is executable under the control of one or more computer systems consisting of executable instructions and / or other data, and can be implemented as executable instructions executed jointly by one or more processors. The executable instructions and / or other data can be stored in a non-temporary computer-readable storage medium (e.g., a computer program permanently stored in a magnetic, optical, or flash medium). The exemplary process 700 may be executed by a node such as one of the nodes 102 described in relation to Figure 1, in a blockchain network such as the blockchain network 100 described in relation to Figure 1. That is, a node such as one of the nodes 102 described in relation to Figure 1 may execute the exemplary process 700 which verifies that data is a block header in a script-based blockchain interaction described in relation to Figure 7. Such nodes may consist of any suitable computing device (for example, a server in a data center, a client computing device, multiple 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 relation to Figure 2).

[0153] In step 702 of the exemplary process 700, the system <data>The system receives the following: In step 704 of the exemplary process 700, the system starts the OP_CHECKBLOCKVERIFY script as described above in relation to Figure 6. In step 706 of the exemplary process 700, the system executes the script shown in Table 2 above, for example, <data>Verify that the size is 80 bytes. Step 708 of the exemplary process 700 determines whether the previous script (the script shown in Table 2 above) passed or not.

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

[0155] If, in step 708 of the exemplary process 700, it is determined that the previous script passed, then in step 710 of the exemplary process 700, the system executes, for example, the script shown in Table 3 above. <data>The "nBits" field is verified to be equal to or greater than the blockchain mining difficulty. Step 712 of the exemplary process 700 determines whether the previous script (for example, the script shown in Table 3 above) passed.

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

[0157] If, in step 712 of the exemplary process 700, it is determined that the previous script passed, then in step 714 of the exemplary process 700, the system executes, for example, the script shown in Table 4 above. <data>The SHA256 is verified to be below the required target. Step 716 of the exemplary process 700 determines whether the previous script (for example, the script shown in Table 4 above) passed.

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

[0159] If, in step 716 of the exemplary process 700, it is determined that the previous script passed, then in step 720 of the exemplary process 700, <data>This is not a valid block header, and the lock script release will succeed.

[0160] It should be noted that one or more of the operations performed in the exemplary process 700 shown in Figure 7 may be performed in various orders and combinations, including parallel execution.

[0161] Figure 8 graphically illustrates an exemplary environment 800 according to one embodiment in which data is verified to be the block header of the previous block for a script-based blockchain interaction. As described in this specification, a block header is part of a blockchain block that contains data about the block. Part of a block header is the hash of the previous block header ("HashPrevBlock"). If a first block header is provided as input to a lock script (e.g., provided as part of an unlock script) and a second block header intended for the next block in the blockchain is also provided as input to a lock script (e.g., provided as part of an unlock script), then by encoding the constraint within 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> Provided as shown below, in step 810, the second block header 808 is data for the unlock script (<Data 2> Provided as shown as: In step 806, a script like the OP_CHECKBLOCKVERIFY script described above in relation to Figures 6 and 7 is provided as:<Data 1> It is used to verify that it is a block header. In step 812, a script like the OP_CHECKBLOCKVERIFY script described above in relation to Figures 6 and 7 is used.<Data 2> This is used to verify that it is a block header.

[0163] Step 814, the first block header<Data 1> The double SHA256 of the second block header<Data 2> A script is executed to verify that it is equal to the HashPrevBlock. (First block header)<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 given value is shown in Table 5. The script shown in Table 5 is:<Data 1> but<Data 2> This is an example of an OP_CHECKCHAINVERIFY script that verifies that the preceding block is valid. As is conceivable, other implementations of the OP_CHECKCHAINVERIFY script may be implemented and are considered to be within the scope of this disclosure. It should be noted that 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 in which the OP_CHECKCHAINVERIFY script is used in combination with other scripts, the final OP_EQUAL opcode of the script is changed to an OP_EQUALVERIFY opcode. [Table 5] [Table 5]

[0164] Figure 9 shows a flowchart illustrating an exemplary process 900 in one embodiment for verifying that data is the block header of the previous block in a script-based blockchain interaction. Part or all of the process 900 is executable under the control of one or more computer systems consisting of executable instructions and / or other data, and can be implemented as executable instructions executed jointly by one or more processors. The executable instructions and / or other data can be stored in a non-temporary computer-readable storage medium (e.g., a computer program permanently stored in a magnetic, optical, or flash medium). The exemplary process 900 may be executed by a node in a blockchain network, such as the blockchain network 100 described in relation to Figure 1, such as one of the nodes 102 described in relation to Figure 1. That is, a node such as one of the nodes 102 described in relation to Figure 1 may execute the exemplary process 900 for verifying that data is the block header of the previous block in a script-based blockchain interaction described in relation to Figure 9. Such nodes may consist of any suitable computing device (for example, a server in a data center, a client computing device, multiple 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 relation to Figure 2).

[0165] In step 902 of the exemplary process 900, the system has two intended block headers.<Data 1> and<Data 2> The system receives the following: In step 904 of the exemplary process 900, the system performs the OP_CHECKCHAINVERIFY process as described above in relation to Figure 8.<Data 1> and<Data 2> The system starts with the following: In step 906 of the exemplary process 900, the system executes the OP_CHECKCHAINVERIFY script as described above in relation to Figures 6 and 7.<Data 1> By performing this against,<Data 1> Verify that it is a block header.

[0166] In step 908 of the example process 900, the previous script (for example,<Data 1> It is determined whether the OP_CHECKBLOCKVERIFY script (for the above) passed (i.e., whether the OP_CHECKBLOCKVERIFY script returned true). If it is determined in step 908 of exemplary process 900 that the previous script did not pass, then in step 910 of exemplary process 900,<Data 1> teeth<Data 2> It's not the block before it, and therefore the unlocking of the lock script fails.

[0167] In step 908 of the exemplary process 900, if it is determined that the previous script passed, then in step 912 of the exemplary process 900, the system executes the OP_CHECKBLOCKVERIFY script as described above in relation to Figures 6 and 7.<Data 2> By performing this against,<Data 2> Verify that it is a block header.

[0168] In step 914 of the example process 900, the previous script (for example,<Data 2> It is determined whether the OP_CHECKBLOCKVERIFY script (for the above) passed (i.e., whether the OP_CHECKBLOCKVERIFY script returned true). If it is determined in step 914 of exemplary process 900 that the previous script did not pass, then in step 916 of exemplary process 900,<Data 2> This is not a valid block header, and in step 922 of the exemplary process 900,<Data 1> teeth<Data 2> It's not the block before it, and therefore the unlocking of the lock script fails.

[0169] If, in step 914 of the exemplary process 900, it is determined that the previous script passed, then in step 918 of the exemplary process 900, the system<Data 1> double SHA256<Data 2> Verify that it is equal to the "HashPrevBlock" field.

[0170] In step 920 of the exemplary process 900,<Data 1> double SHA256<Data 2> It is determined whether it is equal to the "HashPrevBlock" field. In step 920 of the exemplary process 900,<Data 1> double SHA256<Data 2> If it is determined that the "HashPrevBlock" field is not equal, in step 922 of the exemplary process 900,<Data 1> teeth<Data 2> It's not the block before it, and therefore the unlocking of the lock script fails.

[0171] In step 920 of the exemplary process 900,<Data 1> double SHA256<Data 2> If it is determined to be equal to the "HashPrevBlock" field, in step 924 of the exemplary process 900,<Data 1> teeth<Data 2> This is the block before the lock script, and therefore the unlocking of the lock script is successful.

[0172] It should be noted that one or more of the operations performed in the exemplary process 900 shown in Figure 9 may be performed in various orders and combinations, including parallel execution.

[0173] Figure 10 graphically illustrates an exemplary environment 1000 according to one embodiment, in which data is verified to be block headers for script-based blockchain interaction. The exemplary environment 1000 shown in Figure 10 is an extension of the operation described in relation to Figures 8 and 9. In the exemplary environment 1000 shown in Figure 10, the double SHA256 of the first block header 1002 of block header chain 1010 (i.e., chain of block headers) is compared to the HashPrevBlock of the second block header 1004 of block header chain 1010, the double SHA256 of the second block header 1004 of block header chain 1010 is compared to the HashPrevBlock of the third block header 1006 of block header chain 1010, and so on until the double SHA256 of the second to last block (not shown) of block header chain 1010 is compared to the HashPrevBlock of the last block header 1008 of block header chain 1010.

[0174] Exemplary environment 1000 demonstrates 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 in this specification as OP_CHECKBLOCKCHAINVERIFY.

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

[0176] Table 7 shows an example implementation of OP_CHECKBLOCKCHAINVERIFY, which repeats the operation of OP_CHECKCHAINVERIFY for a large number of blocks. In the example implementation of OP_CHECKBLOCKCHAINVERIFY shown in Table 7, the repeated part is through the block header. <d-1>The range of values ​​for each loop (for example, <d>For each block header <d-1>To cover the loops (of which there are) and preserve and maintain their order, an alternative stack is used to perform the OP_CHECKCHAINVERIFY operation for each block header pair. [Table 7] [Table 7]

[0177] Figure 11 shows a flowchart illustrating an exemplary process 1100 in which data is verified to be a block header chain in a script-based blockchain interaction, according to one embodiment. Part or all of the process 1100 is executable under the control of one or more computer systems consisting of executable instructions and / or other data, and can be implemented as executable instructions executed jointly by one or more processors. The executable instructions and / or other data can be stored in a non-temporary computer-readable storage medium (e.g., a computer program permanently stored in a magnetic, optical, or flash medium). The exemplary process 1100 may be executed by a node such as one of the nodes 102 described in relation to Figure 1, in a blockchain network such as the blockchain network 100 described in relation to Figure 1. That is, a node such as one of the nodes 102 described in relation to Figure 1 may execute the exemplary process 1100 which verifies that data is a block header chain in a script-based blockchain interaction described in relation to Figure 11. Such nodes may consist of any suitable computing device (for example, a server in a data center, a client computing device, multiple 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 relation to Figure 2).

[0178] In step 1102 of the exemplary process 1100, the system<Data 1> ~<Data n> The system receives an ordered set. In step 1104 of the exemplary process 1100, the system starts the OP_CHECKBLOCKCHAINVERIFY script on the ordered dataset, as described above in relation to Figure 10.

[0179] In step 1106 of the exemplary process 1100, the system selects a first data item from the ordered dataset (for example) based at least partially on the order of the ordered dataset.<Data 1> ) selects a second data item (e.g., ) in step 1108 of the exemplary process 1100, based at least partially on the order of the ordered dataset.<Data 2> ) is selected. In one embodiment, the system verifies that the first and second data items are valid block headers using the OP_CHECKBLOCKVERIFY script described above, for example in relation to Figures 6 and 7.

[0180] In step 1110 of the exemplary process 1100, the system verifies that the first data item is the block preceding the second data item by performing OP_CHECKCHAINVERIFY on the first and second data items as shown in Table 5, as described in relation to Figures 8 and 9.

[0181] In step 1112 of the exemplary process 1100, it is determined whether the OP_CHECKCHAINVERIFY script passed for the first and second data items (i.e., whether the first data item is the block header preceding the block header in the second data item).

[0182] If, in step 1112 of exemplary process 1100, it is determined that the OP_CHECKCHAINVERIFY script failed for the first and second data items, then in step 1114 of exemplary process 1100, the first data item is not a block header preceding the block header in the second data item, and in step 1116 of exemplary process 1100, the ordered dataset is not a valid block header chain.

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

[0184] If, in step 1118 of exemplary process 1100, it is determined that there is more data in the ordered dataset, then in step 1120 of exemplary process 1100, the second data item becomes the first data item in exemplary process 1100; in step 1122 of exemplary process 1100, the new second data item is selected from the ordered dataset, at least partially based on the data order; and in step 1110 of exemplary process 1100, the system verifies that the new first data item is the 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, as described in relation to Figures 8 and 9.

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

[0186] It should be noted that one or more of the operations performed in the exemplary process 1100 shown in Figure 11 may be performed in various orders and combinations, including parallel execution.

[0187] FIG. 12 shows an exemplary environment 1200 in a script-based blockchain interaction according to one embodiment, in a graphical form, showing a Merkle tree of available block headers. A Merkle tree (also referred to as a "binary hash tree") is a data structure used to verify a set of transactions within a block. A Merkle tree is a binary tree that contains cryptographic hashes of transactions. However, by repeatedly hashing and concatenating the 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, the Merkle tree 1204 is generated by (i) calculating the hash of each of the transactions of the block, (ii) selecting pairs of the hashes, concatenating them together, (iii) calculating the hash of the concatenated value, and (iv) repeating the process at successive upper levels of the tree until a final hash value ("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, the hash 1208 of the transaction is calculated. As used herein, a transaction is referred to as T A and the hash 1208 of transaction 1206 is referred to as H(T A ). Similarly, transaction (T B ) has hash 1212 H(T B ). To generate hash 1216, the left value is concatenated with the right value before being hashed 1214. Thus, hash 1216 is H(H(T A ) + H(T B )). Here, the "+" operator is overloaded in this case to represent concatenation (e.g., if 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] Exemplary environment 1200 also shows a Merkle branch. A Merkle branch is a set of nodes in a Merkle tree, coupled with the Merkle root, and can be used to verify that the data for a particular leaf node (i.e., a particular transaction) exists 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, the hash 1220 of the transaction is computed. Next, the hash 1224 of the next level of the Merkle tree is computed. However, as mentioned above, the hash 1224 of the next level of the Merkle tree requires the hash 1222 of another transaction (e.g., the transaction that is one of the pair of transactions 1218 in the Merkle tree). This hash 1222 is the first node in the Merkle branch.

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

[0192] Figure 13 graphically illustrates an exemplary environment 1300 in which a transaction is verified to be included in a block header for script-based blockchain interaction, according to one embodiment. As described in this specification, a block header is part of a blockchain block that contains data about the block. Part of the block header is the Merkle root of a Merkle tree ("HashMerkleRoot") which cannot verify transactions within the block. If a block header is provided as input to a lock script (e.g., as an unlock script) along with the Merkle branches of a transaction, then the HashMerkleRoot of the block header is not a valid unlock script if the HashMerkleRoot of the block header is not the same as the computed Merkle root computed from the Merkle branches and the transaction, by encoding the constraint that the HashMerkleRoot of the block header is the same as the computed Merkle root computed from the Merkle branches and the transaction.

[0193] In step 1304, the first block header 1302 contains data for the unlock script (<Data 1> It is provided as shown. In step 1306, a script like the OP_CHECKBLOCKVERIFY script described above in relation to Figures 6 and 7 is provided as follows:<Data 1> This is used to verify that it is a block header. In step 1308, HashMerkleRoot is extracted from a valid block header.

[0194] In step 1312, Merkle branch 1310 is data for the unlock script (<Data 2> Provided as (indicated as). Merkle branches 1310, which may be about 10, 11, or 12, though not shown in this specification, are provided in an encoded form indicating whether a particular node is a left input to a concatenation operation or a right input to a concatenation operation, as described in this specification.

[0195] Table 8 shows an exemplary implementation of OP_CALCMERKLEROOT, where Merkle branch 1310 is pair <hash1> 、 <x1> 、 <hash2> 、 <x2>... <hash d >, <x d > and value <d>It is provided in an encoding format that includes a set of . Here, <d>This indicates how many pairs are in the set of pairs, and each <hash i > is a hash of values ​​from the Merkle tree, and each <x i > is a value indicating whether it is left-connected or right-connected (for example, 0 or 1). In the example implementation of OP_CALCMERKLEROOT shown in Table 8, <x i The value 1 inside > indicates left connectivity. <x i The value 0 inside > indicates right concatenation. [Table 8] [Table 8]

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

[0197] In step 1320, the script is:<Data 1> The HashMerkleRoot extracted from is<Data 2> and<Data 3> This is executed to verify that it is the same as the Merkle root calculated from the OP_CALCMERKLEROOT script that was executed against it.<Data 1> The HashMerkleRoot extracted from is<Data 2> and<Data 3> An example script that verifies that the calculated Merkle root is the same as is shown in Table 9. The script shown in Table 9 is a block header.<Data 1> The block<Data 3> Includes the transaction<Data 2> This is an example of an OP_CHECKBLOCKTXVERIFY script that verifies using the Merkle branch. As is conceivable, 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 operation is omitted for the sake of clarity. [Table 9] [Table 9]

[0198] Figure 14 shows a flowchart of an exemplary process 1400 in which a transaction is included in the block header of a script-based blockchain interaction, according to one embodiment. Part or all of the process 1400 is executable under the control of one or more computer systems consisting of executable instructions and / or other data, and can be implemented as executable instructions executed jointly by one or more processors. The executable instructions and / or other data can be stored in a non-temporary computer-readable storage medium (e.g., a computer program permanently stored in a magnetic, optical, or flash medium). The exemplary process 1400 may be executed by a node such as one of the nodes 102 described in relation to Figure 1, of a blockchain network such as the blockchain network 100 described in relation to Figure 1. That is, a node such as one of the nodes 102 described in relation to Figure 1 may execute the exemplary process 1400 which verifies that a transaction is included in the block header of a script-based blockchain interaction described in relation to Figure 14. Such nodes may consist of any suitable computing device (for example, a server in a data center, a client computing device, multiple 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 relation to Figure 2).

[0199] In step 1402 of the exemplary process 1400, the system, as described above in relation to Figure 13.<Data 1> ,<Data 2> , and<Data 3> The system receives the following: In step 1402 of the exemplary process 1400, the system executes the OP_CHECKBLOCKTXVERIFY script as described above in relation to Figure 13.<Data 1> ,<Data 2> , and<Data 3> Start with respect to.

[0200] In step 1406 of the exemplary process 1400, the system uses the OP_CHECKBLOCKVERIFY script as described above in relation to Figures 6 and 7,<Data 1> Verify that it is a valid block header.

[0201] In step 1408 of the exemplary process 1400,<Data 1> It is determined whether the OP_CHECKBLOCKVERIFY script passed or failed. In step 1408 of the example process 1400,<Data 1> If the OP_CHECKBLOCKVERIFY script for is determined to have failed, then in step 1410 of the exemplary process 1400<Data 1> This is not a valid block header, and in step 1412 of the exemplary process 1400,<Data 3> The transaction is<Data 1> It cannot be proven that it is inside a block that has a block header inside.

[0202] In step 1408 of the exemplary process 1400,<Data 1> If the OP_CHECKBLOCKVERIFY script for is determined to have passed, in step 1414 of the exemplary process 1400, the system, as described above in relation to Figure 13,<Data 1> Extract the HashMerkleRoot field from it. In step 1416 of the exemplary process 1400, the system, as described above in relation to Figure 13.<Data 2> and<Data 3> Calculate the Merkle root from this.

[0203] In step 1418 of the exemplary process 1400, the system, as described above in relation to Figure 13,<Data 1> The HashMerkleRoot extracted from is<Data 2> and<Data 3> Verify that it is equal to the Merkle root calculated from [the given formula].

[0204] In step 1420 of the exemplary process 1400,<Data 1> The HashMerkleRoot extracted from is<Data 2> and<Data 3> It is determined whether or not it is equal to the Merkle root calculated from. In step 1420 of the exemplary process 1400,<Data 1> The HashMerkleRoot extracted from is<Data 2> and<Data 3> If it is determined that the Merkle root calculated from is not equal, then in step 1412 of the exemplary process 1400,<Data 3> The transaction is<Data 1> It cannot be proven that it is inside a block that has an internal block header.

[0205] In step 1420 of the exemplary process 1400,<Data 1> The HashMerkleRoot extracted from is<Data 2> and<Data 3> If it is determined to be equal to the Merkle root calculated from, in step 1422 of the exemplary process 1400,<Data 3> The transaction is<Data 1> It is proven that it is inside a block that has an internal block header.

[0206] It should be noted that one or more of the operations performed in the exemplary process 1400 shown in Figure 14 may be performed in various orders and combinations, including parallel execution.

[0207] Figure 15 graphically illustrates an exemplary environment 1500 in which, according to one embodiment, problems associated with accessing the blockchain associated with script-based blockchain interaction can be resolved using the method described herein. In the exemplary environment 1500, a lock script 150 in transaction 1502 (for example, a previous transaction such as the previous transaction 302 described in relation to Figure 3 or an unlock transaction 304) 6 It is possible to query blockchain 1504 using one or more of the methods described in relation to Figures 6-14. ru This contrasts with the exemplary problem 400 described in relation to Figure 4. Similarly, in the exemplary environment 1500, the lock script 1506 within transaction 1502 can query block 1508 of blockchain 1504 using one or more of the methods described in relation to Figures 6-14. ru This is in contrast to the exemplary problem 500 described in relation to Figure 5. In one embodiment, transaction 1510 of block 1508 is the same as transaction 1502 (for example, transaction Tx i (That is.)

[0208] Figure 16 graphically illustrates an exemplary environment 1600 representing the state of a blockchain associated with a script-based blockchain interaction according to one embodiment. The blockchain includes all blocks since the blockchain was initiated. In exemplary environment 1600, the block header of the first block 1604 of blockchain 1602 is the record of state 1606 of blockchain 1602 in the smallest nTime (e.g., the most recent or first in time). Using the method described herein, a transaction lock script can query blockchain 1602, query the first block 1604, and query the state 1606 of blockchain 1602 in the smallest nTime. Using the method described herein, a transaction lock script can query blockchain 1602, query block 1608 of blockchain 1602 (which may be a block containing a transaction), and therefore query the state 1610 of blockchain 1602 in the nTime of the block. Using the method described herein, a transaction lock script can query blockchain 1602, query the latest block 1612 of blockchain 1602, and therefore query the state 1614 of blockchain 1602 at nTime of the latest block (for example, query the current state of the blockchain). The use of such state queries is illustrated in detail in Figures 17 and 18.

[0209] Figure 17 graphically illustrates an exemplary environment 1700 in which the state of the blockchain is verified in a script-based blockchain interaction according to one embodiment. As described in this specification, a block header is part of a blockchain block that contains data about the block. Part of the block header is the Merkle root of a Merkle tree ("HashMerkleRoot") which cannot verify transactions within the block. If a block header is provided as input to a lock script (e.g., as an unlock script) along with the Merkle branches of a transaction, then the HashMerkleRoot of the block header is not a valid unlock script if the HashMerkleRoot of the block header is not the same as the computed Merkle root computed from the Merkle branches and the transaction, by encoding the constraint that the HashMerkleRoot of the block header is the same as the computed Merkle root computed from the Merkle branches and the transaction.

[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. This includes, but is not limited to, checking the block headers of one or more blocks of the blockchain, checking the relationships between one or more blocks of the blockchain, checking the number of blocks in the blockchain, checking one or more transactions within a single block of the blockchain, or checking multiple transactions within multiple blocks of the blockchain.

[0211] In step 1708, block header 1706 contains data for the unlock script (<Data 1> It is provided as shown. In one embodiment, a script such as the OP_CHECKBLOCKVERIFY script described above in relation to Figures 6 and 7 is provided as<Data 1> It is used to verify that it is a block header. In step 1712, as described above in relation to Figures 13 and 14, Merkle branch 1710 is used for data for the unlock script (<Data 2> It is provided as shown. In step 1716, transaction 1714 provides data for the unlock script (<Data 3> It is provided as shown. In one embodiment, Merkleroot is Merkleroot<Data 2> and transactions<Data 3> Therefore, it is calculated using the OP_CALCMERKLEROOT script described above, in relation to Figures 13 and 14.

[0212] In step 1718, the OP_CHECKBLOCKTXVERIFY script is executed.<Data 1> The HashMerkleRoot extracted from it is as shown in Table 9 above.<Data 2> and<Data 3> This is executed to verify that it is the same as the Merkle root calculated from the OP_CALCMERKLEROOT script that was executed against it.

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

[0214] In the example environment 1700, in step 1704, the script uses a verification script like the OP_CHECKBLOCKCHAINVERIFY mentioned above to check the block header.<Data 1> However, it is used to verify that it is the block header of a block that is part of the public blockchain, and not a block that was specially generated to mimic a public blockchain. In one embodiment, the script, as described above, uses the block header<Data 1> However, it 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 Blockchain 1702 or with the complete or partial block header chain.

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

[0216] As with step 1718 described above, it should be noted that step 1722 provides an example of the type of script that can be executed in an exemplary environment such as environment 1700, where the state of the blockchain is confirmed in a script-based blockchain interaction according to one embodiment. Step 1722 provides a second set of constraints associated with a dataset from the blockchain, which is introduced into a transaction using an opcode, as described above in relation to step 1718. In one embodiment, the second set of constraints includes constraints on the values ​​of data items in the dataset (i.e., constraints that data items in the dataset are less than, equal to, or greater than a value, for example). 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, perform action "A", otherwise perform action "B"). As is conceivable, 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 this disclosure.

[0217] In step 1704, block header<Data 1> However, if the script used to verify that the block header is for a block that is part of the public blockchain and not a block specifically generated to mimic a public blockchain block passes, then in step 1718, the OP_CHECKBLOCKTXVERIFY script will execute.<Data 1> The HashMerkleRoot extracted from is<Data 2> and<Data 3> Step 1722 verifies that it is the same as the Merkle root calculated from the OP_CALCMERKLEROOT script executed against it, and if the script used to verify other aspects of the transaction passes, then step 1724 the lock script succeeds. In one embodiment, step 1704 introduces a third set of constraints associated with a dataset from the blockchain, which is introduced into the transaction using an opcode (e.g., the constraint that the block is a block on a public blockchain).

[0218] It should be noted that, as described above, the script used in step 1722 to verify other aspects of the transaction includes a second set of constraints associated with a dataset from the blockchain, which is introduced into the transaction using an opcode. Thus, the second set of constraints includes, in one embodiment, but not limited to, verification of numerous aspects of the transaction, including the transferee, the transferor, the amount of the transaction, or other aspects of the transaction. Furthermore, it should be noted that the script used in step 1722 to verify other aspects of the transaction 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 in step 1722 to verify other aspects of the transaction, and which includes constraints from the second set of constraints, may include constraints for verifying the nTime of a block, verifying the number of transactions in a block, determining the amount of time elapsed between two blocks, determining the minimum block height, or determining other such aspects of the blockchain environment. It should also be noted that branching conditions can be introduced by not including the “verify” opcode at the end of the script, which is used to verify other aspects of the transaction in step 1722 (for example, Alice can be released if there are more than 1000 transactions in the block, and Bob can be released if there are not more than 1000 transactions in the block). An example of a branching condition is detailed below in relation to Figure 30.

[0219] One issue associated with step 1704 is the block header.<Data 1> However, in some embodiments, a script used to verify that a block is a block header for a block that is part of the public blockchain, rather than a block specifically generated to mimic a block of the public blockchain, could computationally be very easy to use to generate a block specifically to mimic a block of the public blockchain. For example, the unlock script might require data to be included in the block header (for example, the unlock script is not just a block header).<Data 1> Consider the lock scripts in Table 10 (which may include the above). [Table 10] [Table 10]

[0220] In a Bitcoin implementation, if the mining difficulty (nBits) is set to the minimum value, the data could be the block header of a block in the public blockchain, but it could also be a completely unrelated block, as generating a block at minimum mining difficulty does not require a massive amount of computing power. To prevent this implementation, lock script generators should make the constraints on their lock scripts sufficiently difficult. As a result, the cost of the computing power required to generate an alternative blockchain that mimics the public blockchain will be significantly greater than the value of what can be unlocked. In Bitcoin, this can be achieved by increasing the mining difficulty (for example, in the scripts described in relation to Figures 6 and 7 in Table 3) or by requiring a longer chain of block headers (for example, in the scripts described in relation to Figures 10 and 11 in Table 6).

[0221] Table 11 shows an example of a script used to verify other aspects of a transaction, such as in step 1724 (i.e., to determine whether aspects of the second set of constraints and / or the first set of constraints are satisfied). The example script used to verify other aspects of a transaction shown in Table 11 uses data<Data 1> Transaction<Data 3> It is a block header that includes and is subject to the constraint that the transaction is paid to Bob's public key. It should be noted that,<Scriptto Check Output of Data 3 is to P2KH of Bob> The phrase " is omitted here for explanatory purposes. [Table 11] [Table 11]

[0222] Figure 18 shows a flowchart illustrating an exemplary process 1800 for checking the state of a blockchain in a script-based blockchain interaction according to one embodiment. Part or all of the process 1800 is executable under the control of one or more computer systems consisting of executable instructions and / or other data, and can be implemented as executable instructions executed jointly by one or more processors. The executable instructions and / or other data can be stored in a non-temporary computer-readable storage medium (e.g., a computer program permanently stored in a magnetic, optical, or flash medium). The exemplary process 1800 may be executed by a node such as one of the nodes 102 described in relation to Figure 1, in a blockchain network such as the blockchain network 100 described in relation to Figure 1. That is, a node such as one of the nodes 102 described in relation to Figure 1 may execute the exemplary process 1800 for checking the state of a blockchain in a script-based blockchain interaction described in relation to Figure 18. Such nodes may consist of any suitable computing device (for example, a server in a data center, a client computing device, multiple 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 relation to Figure 2).

[0223] In step 1802 of the exemplary process 1800, the system proceeds as described above in relation to Figure 17.<Data 1> ,<Data 2> , and<Data 3> Receive.

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

[0225] In step 1806 of the exemplary process 1800,<Data 1> It is determined whether or not it is a block on a public blockchain. In step 1806 of the exemplary process 1800,<Data 1> If it is determined that it is not a block on the public blockchain, in step 1808 of the example process 1800,<Data 3> The transaction is<Data 1> The block is not proven to have a block header, and in step 1810 of the exemplary process 1800, the lock script fails.

[0226] In step 1806 of the exemplary process 1800,<Data 1> If it is determined that it is a block on the public blockchain, in step 1812 of the exemplary process 1800, the system uses the OP_CHECKBLOCKTXVERIFY script as shown in the example in Table 9,<Data 3> The transaction<Data 1> It verifies that the data is in a block that has a block header. As described 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 met. In one embodiment, OP_CHECKBLOCKTXVERIFY is used to verify that a dataset contains a transaction and that the transaction is 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] In step 1814 of the exemplary process 1800, it is determined whether OP_CHECKBLOCKTXVERIFY passed or failed. If OP_CHECKBLOCKTXVERIFY did not pass in step 1814 of the exemplary process 1800, in step 1816 of the exemplary process 1800,<Data 3> The transaction is<Data 1> If the block is not within a block that has a block header, the lock script will fail in step 1810 of the exemplary process 1800.

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

[0229] Step 1820 of the exemplary process 1800 determines whether one or more other aspects of the transaction are to be validated. If step 1820 of the exemplary process 1800 determines that one or more other aspects of the transaction are not to be validated, then step 1810 of the exemplary process 1800 fails to release the lock script.

[0230] If, in step 1820 of the exemplary process 1800, it is determined that one or more other aspects of the transaction need to be verified, then in step 1822 of the exemplary process 1800, the release of the lock script is successful.

[0231] It should be noted that one or more of the operations performed in the exemplary process 1800 shown in Figure 18 may be performed in various orders and combinations, including parallel execution.

[0232] Figure 19 illustrates an exemplary problem 1900 associated with lock scripts in script-based blockchain interactions, which is resolved by one embodiment. In the exemplary problem, namely 1900 shown in Figure 19, the lock script 1906 in the previous transaction 1902 cannot directly read the fields of the unlock transaction 1904.

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

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

[0235] Figure 20 shows, in diagrammatic form, an exemplary environment 2000 that illustrates data access by an unlock script in script-based blockchain interactions, according to one embodiment. Figure 20 shows an exemplary environment 2000 in which an unlock script 2008, different from the unlock script 2006 of the previous transaction 2002 of the present disclosure in one embodiment, has access to fields of the unlock transaction 2004 (e.g., a set of unlock transaction fields determined according to the SIGHASH type). 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 input 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 "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 configuration of consecutive transactions will be apparent in the description of FIG. 21 below.

[0237] FIG. 21 shows, in diagrammatic form, an exemplary environment 2100 in which, according to one embodiment, a signature is generated from a continuous set of transaction fields in a script-based blockchain interaction. As shown in FIG. 21, a continuous transaction 2110 (i.e., a transaction represented as a series of bytes in a particular format) includes a set of field values of the transaction. The signer selects, at 2112, a SIGHASH type and a numeric value k. The numeric value k is typically random or pseudo-random in order to mask / protect the private key and is thus sometimes referred to in this disclosure as a "mask number". A modified copy of the transaction 2114 is an example of a set of fields of the continuous transaction 2110 selected according to the specified SIGHASH type (e.g., SIGHASH_NONE+ANYONECANPAY in the exemplary environment 2100). The signer hashes the modified copy of the transaction 2114 (e.g., by performing OP_HASH256), resulting in a message m2116. The signer then generates a signature as described above in connection with FIG. 3, using the SIGHASH type, the message m, the signer's private key (e.g., a), and the numeric value k.

[0238] Table 12 shows an example of a standard unlock and unlock script. Thereby, the supposed signature of entity A specified within the unlock script is checked against the public key of entity A using the OP_CHECKSIG opcode. [Table 12]

Table 12

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

Table 13

[0240] The unlock script can be further modified to include a step to calculate message m within the unlock script, as shown in Table 14. [Table 14] [Table 14]

[0241] However, apart from the SIGHASH type and the set of 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 behavior of "OP_GENSIG", the unlock script is made to include a SIGHASH type and a set of unlock transaction fields determined according to the SIGHASH type in order to be valid.

[0243] Thus, consecutive previous transactions are introduced into the lock script. Table 16 shows how the lock script and unlock script execute the procedures for each step in the exemplary environment 2100 and verify the transactions. [Table 16] [Table 16]

[0244] However, it should be noted that any entity that provides a SIGHASH type and a set of unlock transaction fields determined according to the SIGHASH type can receive the transaction output. This can be a useful feature of the method described herein. For example, one implementation of a smart contract may 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. One implementation requires some interaction with the contract. Another implementation executes the contract automatically without any interaction with the contract.

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

[0246] In one embodiment, the smart contract includes a value that functions as a signal detectable by a computer system to cause another computer system to verify the transaction. That is, a verifying entity is guided to verify the transaction by providing a contingent that can be obtained when the verification of the transaction associated with the smart contract is performed, which is at least a portion of the digital assets. For example, a smart contract is generated associated with 1.0 digital assets, 0.9 digital assets are passed to a designated recipient, and the remaining 0.1 digital assets are made claimable by the verifying entity. In this way, the smart contract is executed. Other ways in which an entity influences an entity to obtain a transaction output and / or execute a smart contract are considered to be within the scope of this disclosure.

[0247] As used in this specification, a smart contract has both automatic execution and self-execution properties. The automatic execution property of a smart contract is a combination of two elements. The first element of the automatic execution property of a smart contract is that any entity can effectively unlock the lock script. When any entity can effectively 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 specific hash). However, it should be noted that this first element of the automatic execution property of a smart contract is limited as described in this specification. The second element of the automatic execution property of a smart contract is that the smart contract is automatic in the sense that it can motivate other parties to unlock the lock script (e.g., by a Bitcoin reward as described in this specification). The self-execution property of a smart contract is also a combination of two elements. The first element of the self-enforcement property of smart contracts is that constraints may be imposed on a contiguous set of unlock transaction fields, and these constraints are reflected within the unlock transactions. The second element of the self-enforcement property of smart contracts is that constraints within the lock script are enforced by the blockchain network.

[0248] FIG. 22 shows in flowchart form an exemplary process 2200 in which a signature results in the introduction of a continuous set of unlock transactions in script-based blockchain interactions. Some or all of the exemplary process 2200 may be executable under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions executed jointly by one or more processors. The executable instructions and / or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program permanently stored on magnetic, optical, or flash media). The exemplary process 2200 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 an exemplary process 2200 that introduces a continuous set of unlock transaction fields into script-based blockchain interactions described in connection with FIG. 22. Such a node may be configured by any suitable computing device (e.g., by a server in a data center, by a client computing device, by multiple computing devices in a distributed system of a computing resource service provider, or by a suitable electronic client device such as the computing device 200 described in connection with FIG. 2).

[0249] The exemplary process 2200 includes a series of operations. Here, the system executing the exemplary process 2200 executes an unlock script and a lock script for an unverified transaction in connection with the method described in FIG. 21, resulting in obtaining a set of SIGHASH type and transaction field values, generating a signature, and verifying the signature.

[0250] In step 2202 of the exemplary process 2200, the system obtains an unverified transaction from an entity requesting the transfer of control of a digital asset. The unverified transaction includes a lock script and an unlock script. The unlock script is executed by the system before the lock script is executed. The unlock script may be similar to the unlock scripts shown in Tables 15 and 16 above and indicates a SIGHASH type and a contiguous set of fields for the unverified transaction. In step 2204 of the exemplary process 2200, the system performing the exemplary process 2200 obtains the indicated SIGHASH type, and in step 2206 of the exemplary process 2200, obtains a contiguous set of transaction field values ​​for the unverified transaction. In one embodiment, once the execution of the unlock script is 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 the unlock script was completed. The lock script may be similar to the lock scripts shown in Tables 15 and 16 above.

[0251] In step 2208 of the exemplary process 2200, according to the lock script, the system generates a signature using at least the SIGHASH type, the set of transaction field values ​​placed on the main stack as a result of executing the unlock script, and the private key associated with the public-private key pair. In step 2210 of the exemplary process 2200, according to the lock script, the system successfully verifies the signature against the public key of the key pair. In this way, the set of transaction fields is introduced into the lock script by the unlock script.

[0252] It should be noted that one or more of the operations performed in the exemplary process 2200 shown in Figure 22 may be performed in various orders and combinations, including parallel execution.

[0253] Figure 23 illustrates an exemplary problem 2300 associated with lock scripts in script-based blockchain interactions, which is resolved by one embodiment. In the exemplary problem 2300 shown in Figure 23, the lock script 2306 is unable to read the transaction input embedded in the field of the previous transaction, and as a result, it is unable to read the field directly.

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

[0255] Figure 24 graphically illustrates an exemplary environment 2400 in which the introduction of a sequence of previous transactions is triggered in a script-based blockchain interaction according to one embodiment. The exemplary environment 2400 shown in Figure 24 shows an unlock transaction 2404 having an unlock script 2408 that utilizes the output from previous transactions 2402A-02B. As can be seen from the figure, the unlock script causes the sequential previous transactions to be read. In some examples, the sequential previous transactions represent an unmodified version of the 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 a double SHA256 of a consecutive transaction, and that the transaction ID has a one-to-one mapping with the transaction. Therefore, the transaction can be introduced into the unlock script by applying the constraints shown in Table 17. [Table 17] [Table 17]

[0257] Embodiments of this disclosure are further enhanced not only by the introduction of arbitrary sequential transactions, but also by the introduction of one or more consecutive preceding transactions (e.g., preceding transactions 2404A-2B) referenced in the input of unlock transaction 2404. As described above with reference to Figure 21, the 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 sequential transactions depending on the SIGHASH type.

[0258] Figure 25 graphically illustrates an exemplary environment 2500 in one embodiment, where a set of fields is made available depending on the signature hash type in a script-based blockchain interaction. However, note that Figure 25 is for illustrative purposes only, and in various embodiments, there are more SIGHASH types than those shown in Figure 25. As shown in Figure 25, different SIGHASH types result in different sets of previous transaction IDs being 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] Therefore, a specific field can be made to exist within the determined set of unlock transaction fields by constraining the SIGHASH type in the following way: First, duplicate the SIGHASH type. Next, push the SIGHASH type onto the stack (e.g., SIGHASH_ALL). Finally, call OP_EQUALVERIFY. As can be seen in Figure 25, SIGHASH_ALL (shown with unlock transaction 2504A) contains hashes representing the transaction IDs of the previous transactions "y" and "z" as described above. In contrast, SIGHASH_ALL+ANYONECANPAY (shown with unlock transaction 2504B) contains only the hash of the immediately preceding transaction "y". In some embodiments, unlock transactions 2504A-2504B are similar to unlock transaction 1904 in Figure 19, representing an attempt to transfer control of at least some of the digital assets controlled by the previous transactions (e.g., transactions y and / or x). The extraction of the transaction ID can be achieved by parsing a series of transactions using substring opcodes until the desired field is reached, as shown in Figure 26.

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

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

[0262] However, it should be noted that any entity providing a SIGHASH type, a set of unlock transaction fields determined according to the SIGHASH type, and a preceding transaction can obtain the transaction output as described in this specification.

[0263] As another example, Table 19 shows a script that results in the introduction of a previous transaction corresponding to a signed input. The script shown in Table 19 is an example of an OP_SELFTXINJECTION script that results in the introduction of a previous transaction corresponding to a signed input. [Table 19] [Table 19]

[0264] Note that the SIGHASH type and the set of unlock transaction fields determined according to the SIGHASH type, and any entity providing a preceding transaction can receive the transaction output as described in this specification.

[0265] Figure 27 shows an exemplary process 2700 in flowchart form that, according to one embodiment, results in the introduction of a previous sequence of transactions in a script-based blockchain interaction. Part or all of the process 2700 is executable under the control of one or more computer systems consisting of executable instructions and / or other data, and can be implemented as executable instructions executed jointly by one or more processors. The executable instructions and / or other data can be stored in a non-temporary computer-readable storage medium (e.g., a computer program permanently 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 relation to Figure 1, in a blockchain network such as the blockchain network 100 described in relation to Figure 1. That is, a node such as one of the nodes 102 described in relation to Figure 1 may execute the exemplary process 2700 that introduces a previous sequence of transactions into the script-based blockchain interaction described in relation to Figure 27. Such nodes may consist of any suitable computing device (for example, a server in a data center, a client computing device, multiple 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 relation to Figure 2).

[0266] The exemplary process 2700 includes a series of actions, in which the system performing the exemplary process 2700 executes both an unlock script and a lock script for the unverified transaction, thereby obtaining the consecutive previous transactions corresponding to the transaction ID extracted from the unverified transaction.

[0267] In step 2702 of exemplary process 2700, the system obtains an unverified transaction from an entity requesting the transfer of control of a digital asset. The unverified transaction includes a lock script and an unlock script. The lock script and unlock script may be similar to the lock script and unlock script shown in Tables 18 and 19. That is, the lock script includes a set of instructions that take as input values ​​stored in the primary and alternate stacks by, for example, the unlock script. If the execution of the instruction set evaluates to true, the unverified transaction is successfully verified. Thus, the unlock script is executed before the lock script and sets values ​​in the primary and alternate stacks for use by the lock script. The unlock script for an unverified transaction in the embodiment of Figure 27 shows a consecutive set of the preceding transaction, SIGHASH type, and unlock transaction fields.

[0268] Later, as a result of executing the unlock script following the lock script, in step 2704 of exemplary process 2700, the system obtains a sequence of previous transactions, a SIGHASH type, and a sequence of unlock transaction fields specified in the unlock script. In step 2706 of exemplary process 2700, the system generates a signature for the sequence of field values ​​of the unverified transaction based on the SIGHASH. Note that the SIGHASH type affects which fields are used in signature generation, and the desired SIGHASH may depend on the specific previous transaction requested. For example, Table 18 shows lock and unlock scripts that extract previous transactions that do not necessarily have to contain the same lock script, utilizing the SIGHASH type SIGHASH_ALL. As shown in Figure 25, the SIGHASH_ALL type allows reading the inputs of other previous transactions of the unlock transaction. In contrast, Table 19 shows lock and unlock scripts that extract previous transactions that have the same lock script, utilizing the SIGHASH type SIGHASH_ALL|ANYONECANPAY. As shown in Figure 25, the SIGHASH type SIGHASH_ALL|ANYONECANPAY removes inputs from other previous transactions, except for the previous transaction that had signed inputs.

[0269] In step 2708 of the exemplary process 2700, the system verifies the previously generated signature. In step 2710 of the exemplary process 2700, the system generates a set of values ​​(i.e., a sequence of field values) that should match the transaction ID of the unlock transaction by performing a double SHA256 of the consecutive previous transactions obtained. Using a substring opcode, in step 2712 of the exemplary process 2700, the system extracts the transaction ID of the sequence of field values, and in 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 sequence of field values. Note that in various embodiments, matching does not necessarily require equivalence. 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., a value) or are complementary in some predetermined way and / or they satisfy one or more matching criteria. Typically, any method for determining whether or not to match may be used.

[0270] It should be noted that one or more of the operations performed in the exemplary process 2700 shown in Figure 27 may be performed in various orders and combinations, including parallel execution.

[0271] Figure 28 graphically illustrates an exemplary environment 2800 in which the state of the blockchain is used for script-based blockchain interaction according to one embodiment. As described in this specification, the block header is part of a blockchain block, containing data about the block.

[0272] As described in this specification, in step 2804, block header 2802 contains data for the unlock script (<Data 1> It is provided as shown. In one embodiment, a script such as the OP_CHECKBLOCKVERIFY script described above in relation to Figures 6 and 7 is provided as<Data 1> It is used to verify that it is a block header. In step 2808, as described above in relation to Figures 13 and 14, Merkle branch 2806 is data for the unlock script (<Data 2> It is provided as shown. In step 2812, transaction 2810 provides data for the unlock script (<Data 3> It is provided as shown. In one embodiment, Merkleroot is Merkleroot<Data 2> and transactions<Data 3> Therefore, it is calculated using the OP_CALCMERKLEROOT script described above, in relation to Figures 13 and 14.

[0273] In step 2814, the OP_CHECKBLOCKTXVERIFY script is executed.<Data 1> The extracted HashMerkleRoot is as shown in Table 9 above, as described in relation to Figures 13, 14, and 17.<Data 2> and<Data 3> This is executed to verify that it is the same as the Merkle root calculated from the OP_CALCMERKLEROOT script that was executed against it.

[0274] In step 2816, the OP_SELFTXINJECTION script is:<Data 3> The unlock script for the transaction is executed to verify that it includes a series of transactions containing lock scripts as shown in Tables 18 and 19, as described in relation to Figures 26, 27, and 28.

[0275] In step 2818, if the OP_CHECKBLOCKTXVERIFY script in step 2814 and the OP_SELFTXINJECTION in step 2816 are successful, then, as described above,<Data 1> A block with a block header is a transaction<Data 3> Including,<Data 3> It can be seen that the unlock script contains a sequence of 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 is 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. An example of such additional information is illustrated in the example shown in Figure 30.

[0276] In one embodiment, the script uses a verification script such as the OP_CHECKBLOCKCHAINVERIFY described above to check the block header<Data 1> However, it is used to verify that it is the block header of a block that is part of the public blockchain, and not a block that was specially generated to mimic a public blockchain. In one embodiment, the script, as described above, uses the block header<Data 1> However, it is used to verify that a block is a block header of a block that is part of a public blockchain, which may be provided with the blockchain or with the 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 relation to Figure 17. As described above, the script used to verify other aspects of the transaction may include, but is not limited to, verification of a number of aspects of the transaction, including the assignee, the transferor, the amount of transactions, or other aspects of the transaction. Furthermore, it should be 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 a block, the number of transactions in a block, the amount of time elapsed between two blocks, the minimum block height, or other aspects of the blockchain environment. Also noteworthy is that branching conditions can be introduced by not including the “verify” opcode used to verify other aspects of the transaction at the end of the script (for example, Alice can be released if there are more than 1000 transactions in the block, and Bob can be released if there are not more than 1000 transactions in the block). An example of a branching condition is described below in relation to Figure 30.

[0278] Although not shown within the exemplary environment 2800, in one embodiment, additional scripts for verifying other aspects of a transaction, such as the scripts shown in Table 11, which are described in association with Figure 17, may be executed as part of the exemplary environment 2800 shown in Figure 28.

[0279] Figure 29 shows an exemplary process 2900 in flowchart form that uses the state of the blockchain in a script-based blockchain interaction according to one embodiment. Part or all of the process 2900 is executable under the control of one or more computer systems consisting of executable instructions and / or other data, and can be implemented as executable instructions executed jointly by one or more processors. The executable instructions and / or other data can be stored in a non-temporary computer-readable storage medium (e.g., a computer program permanently stored in a magnetic, optical, or flash medium). The exemplary process 2900 may be executed by a node such as one of the nodes 102 described in relation to Figure 1, in a blockchain network such as the blockchain network 100 described in relation to Figure 1. That is, a node such as one of the nodes 102 described in relation to Figure 1 may execute the exemplary process 2900 that uses the state of the blockchain in a script-based blockchain interaction described in relation to Figure 29. Such nodes may consist of any suitable computing device (for example, a server in a data center, a client computing device, multiple 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 relation to Figure 2).

[0280] In step 2902 of the exemplary process 2900, the system proceeds as described above in relation to Figure 17.<Data 1> ,<Data 2> , and<Data 3> Receive.

[0281] In step 2904 of the exemplary process 2900, as described above in relation to Figure 17, OP_CHECKBLOCKCHAINVERIFY is used,<Data 1> Verify that it is a block on a public blockchain.

[0282] In step 2906 of the exemplary process 2900,<Data 1> It is determined whether or not it is a block on a public blockchain. In step 2906 of the exemplary process 2900,<Data 1> If it is determined that it is not a block on the public blockchain, in step 2908 of the exemplary process 2900,<Data 3> The transaction is<Data 1> It is not proven that the block has the block header, and in step 2910 of the exemplary 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 it is a block on the public blockchain, in step 2912 of the exemplary process 2900, the system uses the OP_CHECKBLOCKTXVERIFY script, as shown in the example in Table 9,<Data 3> The transaction<Data 1> Verify that it is inside a block that has a block header.

[0284] In step 2914 of the exemplary process 2900, it is determined whether OP_CHECKBLOCKTXVERIFY passed or not. If OP_CHECKBLOCKTXVERIFY did not pass in step 2914 of the exemplary process 2900, in step 2916 of the exemplary process 2900,<Data 3> The transaction is<Data 1> In step 2910 of the exemplary process 2900, the lock script is not in a block that has a block header and therefore cannot access the blockchain state.

[0285] If, in step 2914 of the exemplary process 2900, OP_CHECKBLOCKTXVERIFY is determined to have passed, then in step 2918 of the exemplary process 2900, the system uses an OP_SELFTXINJECTION script, such as the script shown in Table 19,<Data 3> Verify that the transaction includes a series of transactions in the lock script.

[0286] In step 2920 of the exemplary process 2900,<Data 3> It is determined whether the unlock script for the transaction within the lock script contains a sequence of transactions. In step 2920 of the example process 2900,<Data 3> If the unlock script for an internal transaction is determined not to contain a sequence of transactions in the lock script, then in step 2910 of the exemplary process 2900, the lock script will not have access to the blockchain state.

[0287] In step 2920 of the exemplary process 2900,<Data 3> If it is determined that the unlock script for a transaction within the lock script contains a sequence of transactions, then in step 2922 of the exemplary process 2900, the lock script can access the blockchain state.

[0288] It should be noted that one or more of the operations performed in the exemplary process 2900 shown in Figure 29 may be performed in various orders and combinations, including parallel execution.

[0289] Figure 30 graphically illustrates an exemplary implementation 3000 that uses blockchain state in a script-based blockchain interaction according to one embodiment. Exemplary implementation 3000 illustrates several aspects of the method described herein. In exemplary implementation 3000, they decide how long it will take for the block of the transaction containing their bet to be added to the public blockchain, based on the time difference between the block of the transaction containing their bet and the previous block. Each submits a single Bitcoin, and if the time difference is less than 10 minutes, two Bitcoins are given to Alice. Conversely, if the time difference is not less than 10 minutes, two Bitcoins are given to Bob.

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

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

[0292] Table 20 shows an exemplary lock script for this bet transaction 3002. The OP_EXTRACTTIME script used in the script shown in Table 20 is, as is not shown in this specification, a script for extracting time entries from block headers, similar to the script for extracting nBits shown in Table 3. [Table 20] [Table 20]

[0293] Therefore, this specification and the accompanying drawings should be interpreted as illustrative rather than restrictive. However, it is clear that various modifications can be made without departing from the broad spirit and scope of the invention as described in the claims.

[0294] Other variations are within the spirit of this disclosure. Thus, the disclosed art is subject to various variations and alternative configurations, though its particular illustrated embodiments are shown in the drawings and described in detail above. However, it should be understood that the invention is not limited to one or more specific forms disclosed; rather, all variations, alternative configurations and equivalents, as described in the appended claims, are intended to be encompassed within the spirit and scope of the invention.

[0295] In the context describing embodiments of the disclosure, the terms “a,” “an,” and “the,” and similar reference subjects (particularly in the context of the following claims), should be considered to cover both singular and plural unless otherwise specified or the context makes it more clearly contradictory. The terms “comprising,” “having,” “including,” and “containing” should be considered broad terms unless otherwise specified (i.e., meaning “including, but not limited to”). The term “connected” should be considered to be partially or entirely included, attached, or joined together when it refers to an unaltered physical connection, even if something is mediated. Details of value ranges in this specification are intended, unless otherwise specified in this specification, simply to serve as a simple and clear way of referring individually to each distinct value encompassed within the range, and each distinct value is incorporated into this specification as if it were individually detailed in this specification. The terms “set” (e.g., “set of items”) or “subset” should be understood as a non-empty set containing one or more components, unless otherwise noted or inconsistent with the context. Furthermore, unless otherwise noted or inconsistent with the context, the term “subset” of a corresponding set does not necessarily refer to 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 A, B, and C" is understood to be used to indicate that an item, after, etc. may be either A, B, or C, or any non-empty subset of the set A, B, and C, unless otherwise specified or unless it is particularly clearly inconsistent with the context. For example, in the example for describing a set having three components, the logical language "at least one of A, B, and C" or "at least one 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 not usually intended to mean that a particular embodiment must have at least one A, at least one B, and at least one C.

[0297] The operations of the processes described in this specification may be performed in any suitable order, unless otherwise specified in this specification or unless it is clearly inconsistent with the context. The processes described in this specification (or variations and / or combinations thereof) may be performed under the control of one or more computer systems consisting of executable instructions, and may be implemented in hardware, or in combination thereof, as code that runs collectively on one or more processors (e.g., executable instructions, one or more computer programs, or one or more applications). The code may be stored on a computer-readable storage medium in the form of a computer program containing multiple instructions that can be executed by one or more processors, for example. The computer-readable storage medium may be non-temporary.

[0298] The use of any and all illustrative or exemplary language (e.g., “like”) provided in this specification is intended solely to better illustrate embodiments of the invention and not to limit the scope of the invention unless otherwise specified. No language in this specification should be considered to indicate any non-claimed element essential to the practice of the invention.

[0299] The embodiments of this disclosure include the optimal modes known to the inventors for carrying out the invention, as described in this specification. Variations of these embodiments may become apparent to those skilled in the art who have read the foregoing description. The inventors expect that skilled artisans will appropriately utilize these variations, and the inventors intend that the embodiments of this disclosure will be carried out in ways different from those specifically described in this specification. Accordingly, the scope of this disclosure includes all variations and equivalents of the subject matter detailed in the appended claims, as permitted by applicable law. Furthermore, any combination of the elements described above in all possible variations thereof is included in the scope of this disclosure unless otherwise specifically stated in this specification or unless it is clearly inconsistent with the context.

[0300] It should be noted that, in the context of describing embodiments of the disclosure, unless otherwise specified, the use of expressions relating to executable instructions (also called code, applications, agents, etc.) that perform actions that “instructions” do not typically perform on their own (e.g., data transmission, calculations, etc.) indicates that the instructions are executed by a machine, thereby causing the machine to perform a specified operation.

[0301] It should be noted that the embodiments described above do not limit the invention, and those skilled in the art can devise numerous alternative embodiments without departing from the scope of the invention as defined by the appended claims. No reference numerals enclosed in parentheses in the claims should be considered limiting. The terms “comprising” or “comprises,” etc., do not exclude the existence of elements or steps other than those enumerated in any claim and specification as a whole. In this specification, “comprises” means “includes” or “consists of,” and “comprising” means “including” or “including of.” A singular reference to an element does not exclude the existence of multiple elements of that element, and vice versa. The invention may be carried out by hardware having multiple distinct elements or by a appropriately programmed computer. In claims for an apparatus that enumerates multiple means, these multiple means may be implemented by a single identical hardware element. The fact that certain quantities are described in different dependent claims does not mean that combinations of these quantities cannot be used advantageously. [Explanation of Symbols]

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

Claims

1. A method performed by a computer, i) A step of receiving a first transaction at a node in the blockchain network, wherein the first transaction includes a first script specifying a set of constraints for a second transaction, ii) A step of obtaining the second transaction, wherein the second transaction includes a second script, iii) A step of verifying the second transaction by executing the first script and the second script, Includes, The node, by executing the second script, retrieves a dataset from the blockchain associated with the blockchain network, and the dataset is as follows: The block header of the aforementioned blockchain block, Transactions from the aforementioned blockchain blocks, Block header chain, Includes at least one of the following: When the set of constraints includes a first constraint that the dataset contains block headers, the verification step determines that the second transaction is valid if the block headers included in the dataset satisfy the first condition. When the set of constraints includes a second constraint that the dataset contains a predetermined transaction, the verification step determines that the second transaction is valid if the transaction contained in the dataset satisfies the second condition. A method wherein, when the set of constraints includes a third constraint that the dataset includes a predetermined block header chain, the verification step determines that the second transaction is valid if the block header chain included in the dataset satisfies the third condition.

2. The method according to claim 1, wherein the first condition is that the block header included in the dataset has a predetermined size.

3. The method according to claim 1, wherein the first condition is that the block header included in the dataset contains a mining difficulty value that is equal to or greater than a predetermined mining difficulty value.

4. The method according to claim 1, wherein the first condition is that the hash of the block header included in the dataset is less than or equal to a target value calculated from the mining difficulty value included in the block header.

5. The method according to any one of claims 1 to 4, wherein the second condition is that the Merkle root extracted from the block header associated with the transaction included in the dataset is equal to the Merkle root calculated from the predetermined transaction and the predetermined Merkle branch.

6. The method according to any one of claims 1 to 5, wherein the set of constraints includes the first constraint and the third constraint, and the verification step determines that the second transaction is valid if the first condition and the second condition are met.

7. The method according to claim 5, wherein the Merkle root and the Merkle branch are represented in the form of hash values.

8. The method according to any one of claims 1 to 7, wherein the block header chain includes an ordered set of block headers, the ordered set of block headers includes a plurality of block headers, and the ordered set of block headers specifies the order associated with the plurality of block headers.

9. The third constraint is that, for any consecutive pairs of block headers in an ordered set of block headers, the hash of the first block header in the pair of block headers is equal to the hash value stored in the second block header in the pair of block headers, and the first block header precedes the second block header in the ordered set, the method according to claim 8.

10. The method according to any one of claims 1 to 9, wherein if the third constraint is satisfied, the verification step further determines that the dataset was obtained from a public blockchain of the blockchain network.

11. The method according to any one of claims 1 to 10, wherein one or more properties of the blockchain network are provided to the node before the first script and the second script are executed.

12. The method according to any one of claims 1 to 11, wherein the first script is a lock script for the first transaction, and the second script is an unlock script for the first script.

13. It is a system, Processor and A memory containing executable instructions that cause the system to perform a method performed by a computer according to any one of claims 1 to 12 as a result of execution by the processor, A system that includes this.

14. A non-temporary computer-readable storage medium storing executable instructions, wherein the executable instructions, as a result of being executed by the processor of a computer system, cause the computer system to perform at least one of the methods performed by a computer according to any one of claims 1 to 12.

Images