Enforcing the injection of previous transaction bytecode into blockchain transactions

Abstract

This provides a method for injecting previously serialized transactions into a locking script. [Solution] A node in the blockchain network receives a first transaction to be verified. The first transaction includes a first script, which causes the node to obtain a first set of field values ​​corresponding to the first transaction and a second set of field values ​​corresponding to a specific transaction. The verified second transaction includes a second script, which causes the node to obtain a first set of field values ​​and a second set of field values ​​for a specific transaction provided as a result of executing the first script. The node extracts a transaction identifier from the first set of field values ​​and determines, based on the second set of field values, that a specific transaction corresponds to a transaction identifier.

Description

Technical Field

[0001] The present invention generally relates to distributed ledger technologies, including blockchain transactions. And more specifically, it relates to causing the injection of fields from blockchain transactions into unlocking transaction scripts. The present invention utilizes cryptographic and mathematical techniques to enforce the security associated with electronic transfers conducted on a blockchain network. The present invention is particularly suitable for use in, but not limited to, smart contracts and state machines.

Background Art

[0002] In this document, the term “blockchain” is used to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchains and transaction-chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and their variations. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. For convenience and illustrative purposes, “Bitcoin” may be referred to as a useful application of the technology described herein, but Bitcoin is only one of many applications 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. Alternative blockchain implementations and protocols, including non-commercial applications, are also within the scope of the present invention. For example, this technology offers advantages over using blockchain implementations that have similar restrictions to Bitcoin regarding the constraints that can be encoded within a transaction, regardless of whether or not a cryptocurrency exchange occurs.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized system composed of blocks, and further consists of transactions and other information. In some implementations, a "blockchain transaction" refers to an input message encoding a structured collection of field values, which include data and a set of conditions; satisfying the set of conditions is a prerequisite for the set of fields written to the blockchain data structure. For example, in Bitcoin, each transaction is a data structure encoding a transfer of control of digital assets between participants in the blockchain system, and includes at least one input and at least one output. In some implementations, the transfer of control of digital assets can be performed by reassociating at least a portion of the digital assets from a first entity to a second entity. Each block contains the hash of the previous block, and thus the blocks are chained together to create a persistent, immutable record of all transactions written since the blockchain's inception. A transaction contains a small program known as an embedded script within its input and output, which determines how and by whom the output of that transaction can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

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

[0005] For a transaction to be written to the blockchain, it must be "validated". Network nodes (miners) work to ensure that each transaction is valid, and invalid transactions are rejected from the network. One node may have a different standard of validity than other nodes. Validity in the blockchain is based on consensus, so a transaction is considered valid if the majority of nodes agree that it is valid. Software clients installed on nodes perform this validation work on transactions by partially referencing unused transactions (UTXOs) by executing locking and unlocking scripts for UTXOs. A transaction is valid by a node if the execution of the locking and unlocking scripts evaluates to TRUE, and other validation conditions are met, if applicable. Validated transactions are propagated to other network nodes, where miner nodes can choose to include the transaction in the blockchain. Therefore, for a transaction to be written to the blockchain, it must i) be verified by the first node that receives the transaction. If the transaction is verified, the node relays it to other nodes in the network. The transaction must then ii) be added to a new block built by miners, and iii) be mined, that is, added to the public ledger of past transactions. A transaction is considered confirmed when a sufficient number of blocks have been added to the blockchain, making the transaction effectively irreversible. [Overview of the project]

[0006] This disclosure describes technical aspects relating to one or more blockchain-based computer programs. A blockchain-based computer program is a machine-readable and executable program recorded within a blockchain transaction. A blockchain-based computer program can include rules that can process inputs to produce results, and then actions can be performed according to those results. By leveraging the blockchain, highly flexible and complex smart contracts can be enabled, provided that the locking script has access to both the unlocking and previous transactions. One area of ​​current research is the use of blockchain-based computer programs to implement “smart contracts”. Unlike traditional contracts, which would be written in natural language, smart contracts can be computer programs designed to automate the execution of the terms of a machine-readable contract or agreement.

[0007] In some embodiments, an interaction with a particular entity can be encoded in a specific step within a smart contract, which in turn may be self-enforced and otherwise automatically executed. In some embodiments, self-enforcement refers to the execution of a smart contract that is successfully executed to enable the transfer of a UTXO. In such embodiments, it should be noted that the “entity” that can produce the transfer of a UTXO refers to an entity that can create an unlocking script without being required to prove any secret knowledge. In other words, an unlocking transaction can be verified without verifying that the source of the data (e.g., the entity that created the unlocking transaction) has access to cryptographic secrets (e.g., a private asymmetric key, a symmetric key, etc.). Also in such embodiments, self-enforcement refers to a verification node in the blockchain network that is configured to execute the unlocking transaction according to constraints. In some embodiments, "unlocking" a UTXO (also known as "spending" a UTXO) is used in a technical sense, referring to the UTXO and creating an unlocking transaction to execute as valid.

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

[0009] Therefore, it is desirable to provide improved methods and systems for improving blockchain technology in one or more of these embodiments. Accordingly, according to the present invention, methods and corresponding systems as defined in the appended claims are provided.

[0010] The present invention may be described as a verification method / system and / or a control method / system for controlling the verification of blockchain transactions. In some embodiments, a verified blockchain transaction results in the recording of the transaction on the blockchain, which in some applications may result in the exchange or transfer of digital assets via the blockchain. A digital asset is a unit of resources managed by the blockchain. In some embodiments, a digital asset may be used as cryptocurrency, but in embodiments, it is considered that the digital asset may be additionally or alternatively usable in other contexts. It should be noted that while the present invention is applicable to the control of digital assets, it is essentially technical and may be used in other contexts that utilize the data structure of the blockchain without necessarily involving the transfer of digital assets. As described below, the present invention may also be described as a security method / system for new, improved, and advantageous ways of performing operations via a blockchain network or platform.

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

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

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

[0014] As will be described in more detail below, in one embodiment, a parameterized smart contract can be created by extracting constraint parameters from a previous transaction and applying the constraint parameters to the fields of the unlocking transaction. The parameterized smart contract can be embodied through a locking script that has constraints parameterized by the secure, undetermined data provided in the unlocking script of the unlocking transaction from a determined or undetermined source. According to this embodiment, a method for obtaining undetermined data can be provided. From the data, a set of constraints can be determined to apply to the recombination of the digital assets, and the digital assets are recombined with the second entity according to the set of constraints.

[0015] As will be described in more detail below, in one embodiment, the smart contract is written to be self-replicating until a termination condition is reached. According to this embodiment, a method may be provided to check whether the termination condition has been met. If the termination condition has not been met, it is checked whether the locking script of the previous transaction matches the locking script of the unlocking transaction.

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

[0017] The novel technologies described and implied in this disclosure extend the functionality of blockchain without disrupting the blockchain's property of guaranteeing the integrity of data stored within the blockchain data structure. For example, these technologies improve the field of computation, particularly the field of digital record verification, which involves defined smart contracts where conditions for verification are embedded in the record. This is achieved by utilizing the blockchain network to set and enforce criteria for recombining digital assets. In addition, the technologies described and implied in this disclosure can improve the functionality of blockchain networks by enabling blockchain transactions to function as state machines, allowing the functionality of computer programs to depend on the state recorded within such state machines.

[0018] Furthermore, the technologies described and implied in this disclosure may inevitably be rooted in computer technology to overcome problems particularly inherent in blockchain technology (e.g., Bitcoin scripts) that have been specifically designed to limit functionality for security reasons. For example, scripts do not inherently support complex flow control functionality, such as loops that occur. One advantage of this limitation is that the program has a predictable execution time. Another significant advantage of limiting scripts to linear or tree-like decision tasks is that this avoids infinite loops, which can be used as a means to initiate exploits such as denial of service (DoS or DDoS) attacks. Thus, the security of blockchain transfers / exchanges needs to be enhanced and maintained, but the mechanisms need to be found to implement functionality that is not permitted or provided by the language itself. In this regard, the present invention offers progress and, with the implementation of locking scripts for self-replicating and self-replicating blockchain transactions, addresses, at least in part, the current limitations of blockchain transactions. Accordingly, the present invention provides technical solutions to technical problems and offers advantages with respect to security, improved control over the exchange / transfer of digital assets via blockchain, and extensions of current blockchain-related functionality.

[0019] Therefore, according to the present invention, a computer implementation method (and a corresponding system) can be provided as defined in the appended claims. The computer implementation method can be described as a blockchain data constraint method. The computer implementation method may include: i) a step of receiving a first transaction for transferring control of a digital asset at a node in a blockchain network, the first transaction comprising at least a first script comprising a set of field values ​​for the first transaction, and causing the node to acquire the set of field values ​​as a result of execution; ii) a step of acquiring a second transaction, the second transaction being associated with a digital asset and comprising a second script, and causing the node to create at least a signature based at least in part on the set of field values ​​supplied as a result of execution of the first script; and iii) a step of verifying the first transaction by executing the first and second scripts.

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

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

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

[0023] The signature hash type can be a value indicating which field values of the field value set of the first transaction should be included in the signature.

[0024] The second script can be a locking script that imposes a set of conditions for verifying the first transaction. Additionally or alternatively, execution of the locking script can cause the node to verify the first transaction by determining whether the set of conditions is satisfied.

[0025] The first script can be an unlocking script for satisfying the set of conditions of the second script.

[0026] A digital asset can be associated with an unspent transaction output in a blockchain network.

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

[0028] A blockchain network can be composed of distributed electronic devices that execute an instance of a blockchain protocol.

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

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

[0031] By including a set of fields, the first script can cause the node to create a set of fields available as input to the second script as a result of the execution of the first script.

[0032] It is also desirable to provide a system including a processor and memory containing executable instructions which, as a result of execution by the processor, cause the system to perform any of the methods described in the claims.

[0033] It is also desirable to provide a non-temporary computer-readable storage medium that stores executable instructions thereon, which, 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 in the claims.

[0034] Therefore, according to the present invention, a computer implementation method (and corresponding system) as defined in the appended claims may be provided. The computer implementation method may be described as a blockchain data constraint method. The computer implementation method may include: i) a step of receiving a first transaction for transferring control of a digital asset at a node in a blockchain network, causing the node to acquire at least a first set of field values ​​corresponding to the first transaction and a second set of field values ​​corresponding to a particular transaction as a result of execution; ii) a step of acquiring a second transaction, the second transaction being associated with a digital asset and including a second script, causing the node to acquire at least a first and second set of field values ​​relating to a particular transaction supplied as a result of execution of the first script, extracting a transaction identifier from the first set of field values, and verifying that the particular transaction corresponds to a transaction identifier, at least based on the second set of field values; and iii) a step of verifying the first transaction by executing the first and second scripts.

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

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

[0037] Certain transactions can be associated with the control of the digital assets being transferred.

[0038] Certain transactions may be associated with a second digital asset that is different from the digital asset being transferred.

[0039] Verifying the first transaction can succeed without verifying that the entity that created the first transaction has access to the secret information.

[0040] A node can be a verification node in a blockchain network.

[0041] Verifying the first transaction may further include adding the first transaction to the blockchain in the blockchain network as a result of the successful verification of the first transaction.

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

[0043] The first script could be an unlocking script to satisfy the set of conditions in the second script.

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

[0045] The second script, as a result of further execution, may cause the node to determine, at least partially based on the signature hash type, whether a particular transaction is a member of the set of transactions associated with the first transaction.

[0046] The second script, as a result of further execution, may cause the node to determine, at least partially, based on the signature hash type, that a particular transaction corresponds to the second transaction.

[0047] It is also desirable to provide a system including a processor and memory containing executable instructions which, as a result of execution by the processor, cause the system to perform any of the methods described in the claims.

[0048] It is also desirable to provide a non-temporary computer-readable storage medium that stores executable instructions thereon, which, 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 in the claims.

[0049] Therefore, according to the present invention, a computer implementation method (and corresponding system) as defined in the appended claims may be provided. The computer implementation method may be described as a blockchain data constraint method. The computer implementation method may include: i) a step of receiving a first transaction for transferring control of a digital asset at a node in a blockchain network, the first transaction comprising a first script, comprising at least a first value and a second value, which is a first value and at least a portion of which contains data not constrained by a second script; ii) a step of acquiring a second transaction, the second transaction being associated with a digital asset, and as a result of execution, causing the node to acquire at least the first and second values ​​as a result of executing the first script, and to verify that the data is associated with a specific source based at least in part on the first and second values; and iii) a step of verifying the first transaction by executing the first and second scripts.

[0050] The second script may be a locking script containing a set of conditions for validating the second transaction. Additionally or alternatively, the first script may be an unlocking script to satisfy the set of conditions in the locking script.

[0051] Verifying the first transaction can be done without verifying that the entity that created the first transaction has access to the secret information.

[0052] Failure to verify that data is associated with a data source can lead to a failure in the validation of the first transaction.

[0053] The identity of a specific source does not need to be constrained by the second script.

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

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

[0056] The first script may, by including a field set for a specific transaction, cause a node to make that field set available as input to the second script as a result of executing the first script.

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

[0058] Data can be encoded in the fields of a specific transaction.

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

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

[0061] The modified public key can be created by performing elliptic curve point multiplication on the public key using the data values.

[0062] It is also desirable to provide a system including a processor and memory containing executable instructions which, as a result of execution by the processor, cause the system to perform any of the methods described in the claims.

[0063] Furthermore, it is also desirable to provide a non-temporary computer-readable storage medium that stores executable instructions thereon, which, 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 in the claims. Therefore, according to the present invention, computer implementation methods (and corresponding systems) can be provided as defined in the appended claims. The computer implementation method can be described as a blockchain data constraint method. The computer implementation method may include: i) a step of receiving a first transaction for transferring control of a digital asset at a node in a blockchain network, the first transaction comprising a first script, which, as a result of execution, causes the node to obtain at least a first set of data and field values ​​for the first transaction; ii) a step of obtaining a second transaction, the second transaction comprising a second script, which, as a result of execution, causes the node to determine at least a set of constraints based at least partially on the data provided as a result of the execution of the first script, and to verify the set of constraints for the first transaction based at least partially on the first set of field values; and iii) a step of transferring control of the digital asset according to the set of constraints as a result of the execution of the first and second scripts.

[0064] Transferring control of digital assets can be done without verifying that the entity that initiated the initial transaction has access to the sensitive information.

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

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

[0067] The second script may contain the public key of a specific data source that can be used to validate the data.

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

[0069] The constraint set can be derived, at least partially, from the parameter set in the data.

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

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

[0072] The identity of the second entity can be determined, at least partially, based on the constraint set.

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

[0074] The identity of the second entity can be determined, at least partially, based on a set of constraints.

[0075] The constraint set may also allow at least a portion of the digital assets to be reassociated with a third entity.

[0076] It is also desirable to provide a system including a processor and memory containing executable instructions which, as a result of execution by the processor, cause the system to perform any of the methods described in the claims.

[0077] It is also desirable to provide a non-temporary computer-readable storage medium that stores executable instructions thereon, which, 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 in the claims.

[0078] Therefore, according to the present invention, a computer implementation method (and corresponding system) as defined in the appended claims may be provided. The computer implementation method may be described as a blockchain data constraint method. The computer implementation method may include: i) a step of receiving a first transaction for transferring control of a digital asset at a node in a blockchain network, the first transaction comprising a first script, which, as a result of execution, causes the node to acquire at least a first set of field values ​​of the first transaction, the first set of field values ​​comprising a third script, and a second set of field values ​​of a second transaction, the second set of field values ​​comprising a copy of the second script; ii) a step of acquiring a second transaction, the second transaction comprising a second script, which, as a result of execution, causes the node to acquire at least a first set of field values ​​of the third script, and to determine that the copy of the second script matches the third script, as a result of the execution of the first and second scripts.

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

[0080] The first script could be an unlocking script to satisfy the set of conditions in the second script.

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

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

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

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

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

[0086] A blockchain network can consist of distributed electronic devices running instances of the blockchain protocol.

[0087] Transferring control of digital assets can be done without verifying that the entity that initiated the initial transaction has access to the sensitive information.

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

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

[0090] A set of iterative smart contracts can be terminated by a termination condition.

[0091] It is also desirable to provide a system including a processor and memory containing executable instructions which, as a result of execution by the processor, cause the system to perform any of the methods described in the claims.

[0092] It is also desirable to provide a non-temporary computer-readable storage medium that stores executable instructions thereon, which, 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 in the claims.

[0093] Therefore, according to the present invention, a computer implementation method (and corresponding system) as defined in the appended claims may be provided. The computer implementation method may be described as a blockchain data constraint method. The computer implementation method may include: i) a step of receiving a first transaction for transferring control of a digital asset at a node in the blockchain network, the first transaction comprising a first script, and as a result of execution, causing the node to obtain at least a first set of field values ​​for the first transaction, a second set of field values ​​for the second transaction, and inputs; ii) a step of obtaining a second transaction, the second transaction comprising a second script comprising a set of rules, the second script, as a result of execution, causing the node to verify that the second script matches a third script embedded in the first set of field values, to determine the current state at least partially based on the second set of field values, and to determine the next state at least partially based on the current state, inputs, and the set of rules, and to verify that the next state is included in the first set of field values; and iii) a step of transferring control of the digital asset as a result of the execution of the first and second scripts.

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

[0095] Any of the requested methods may further include a step of verifying the cryptographic secrets of the input source.

[0096] The set of rules can be a state transition matrix.

[0097] The third script could be a locking script that imposes a set of conditions for validating future transactions.

[0098] The second script can further instruct the node to determine if the termination condition has not been met.

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

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

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

[0102] The following states may indicate the state of the first transaction during verification.

[0103] Any method of the claim may further include the step of receiving a third transaction. Additionally or alternatively, any method of the claim may further include the step of obtaining a fourth script from the first transaction, the fourth script which, as a result of execution, may cause a node to determine, at least in part, the next state and another state different from the current state, based on the next state, a second input, and a set of rules.

[0104] The current state and the next state can be members of the possible state sets for the first and second transactions, respectively.

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

[0106] It is also desirable to provide a system including a processor and memory containing executable instructions which, as a result of execution by the processor, cause the system to perform any of the methods described in the claims.

[0107] It is also desirable to provide a non-temporary computer-readable storage medium that stores executable instructions thereon, which, 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 in the claims.

[0108] Therefore, according to the present invention, a computer implementation method (and corresponding system) as defined in the appended claims may be provided. The computer implementation method may be described as a blockchain data constraint method. The computer implementation method may include: i) a step of receiving at least a first transaction to be verified at a node in a blockchain network, the first transaction comprising at least a set of field values ​​for the first transaction, and comprising a first script which, as a result of execution, causes the node to acquire the set of field values; ii) a step of acquiring a second transaction, the second transaction being verified, and comprising a second script which, as a result of execution, causes the node to create at least a signature based at least in part on the set of field values ​​supplied as a result of the execution of the first script; and iii) a step of verifying the first transaction by executing the first and second scripts.

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

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

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

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

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

[0114] The first script could be an unlocking script to satisfy the set of conditions in the second script.

[0115] Verifying the first transaction may result in the transfer of unused transaction output.

[0116] A node can be a computing device that is communicatively connected to at least one other node within the blockchain network.

[0117] A blockchain network can consist of distributed electronic devices running instances of the blockchain protocol.

[0118] The first and second scripts can be written using the Turing incomplete instruction set.

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

[0120] The first script, by including a set of fields, can cause a node to create a set of fields that can be used as input for the second script as a result of the execution of the first script.

[0121] It is also desirable to provide a system including a processor and memory containing executable instructions which, as a result of execution by the processor, cause the system to perform any of the methods described in the claims.

[0122] It is also desirable to provide a non-temporary computer-readable storage medium that stores executable instructions thereon, which, 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 in the claims.

[0123] Therefore, according to the present invention, a computer implementation method (and corresponding system) as defined in the appended claims may be provided. The computer implementation method may be described as a blockchain data constraint method. The method may include: i) a step of receiving a first transaction at a node in a blockchain network, the first transaction comprising a first script, which, as a result of execution, causes the node to obtain at least a first set of field values ​​corresponding to the first transaction and a second set of field values ​​corresponding to a particular transaction; ii) a step of obtaining a second transaction, which is verified and, as a result of execution, causes the node to obtain at least a first set of field values ​​and a second set of field values ​​relating to a particular transaction supplied as a result of the execution of the first script, to extract a transaction identifier from the first set of field values, and to determine, at least partially, that a particular transaction corresponds to a transaction identifier; and iii) a step of verifying the first transaction by executing the first script and the second script.

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

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

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

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

[0128] Validating the first transaction can succeed without verifying that the entity that created the first transaction has access to the secret information.

[0129] A node can be a verification node in a blockchain network.

[0130] Verifying the first transaction may further include adding the first transaction to the blockchain of the blockchain network as a result of the successful verification of the first transaction.

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

[0132] The first script could be an unlocking script to satisfy the set of conditions in the second script.

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

[0134] The second script, as a result of further execution, may cause the node to determine, at least partially based on the signature hash type, that a particular transaction is a member of the first transaction and the set of transactions associated with it.

[0135] The second script, as a result of further execution, may cause the node to determine, at least partially, based on the signature hash type, that a particular transaction corresponds to the second transaction.

[0136] It is also desirable to provide a system including a processor and memory containing executable instructions which, as a result of execution by the processor, cause the system to perform any of the methods described in the claims.

[0137] It is also desirable to provide a non-temporary computer-readable storage medium that stores executable instructions thereon, which, 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 in the claims.

[0138] Therefore, 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. The method may include: i) receiving a first transaction for transferring control of a digital asset at a node in a blockchain network, the first transaction comprising a first script comprising at least a first value and a second value, which is a first value and at least a portion of which contains data not constrained by a second script; ii) acquiring a second transaction, the second transaction being verified and, as a result of execution, causing the node to acquire at least the first and second values ​​as a result of execution of the first script and to verify that the data is associated with a specific source based at least in part on the first and second values; and iii) verifying the first transaction by executing the first and second scripts.

[0139] The second script may be a locking script containing a set of conditions for validating the second transaction. Additionally or alternatively, the first script may be an unlocking script to satisfy the set of conditions in the locking script.

[0140] Verifying the first transaction can be done without verifying that the entity that created the first transaction has access to the secret information.

[0141] Failure to verify that data is associated with a data source can lead to a failure in the validation of the first transaction.

[0142] The identity of a specific source does not need to be constrained by the second script.

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

[0144] The second script may verify that a particular transaction corresponds to a transaction identifier by verifying, as a result of its execution, that the transaction identifier matches the hash of the field set of that particular transaction.

[0145] The first script may, by including a field set for a specific transaction, cause a node to make that field set available as input to the second script as a result of executing the first script.

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

[0147] Data can be encoded in the fields of a specific transaction.

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

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

[0150] The modified public key can be created by performing elliptic curve point multiplication on the public key using the data values.

[0151] It is also desirable to provide a system including a processor and memory containing executable instructions which, as a result of execution by the processor, cause the system to perform any of the methods described in the claims.

[0152] It is also desirable to provide a non-temporary computer-readable storage medium that stores executable instructions thereon, which, 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 in the claims.

[0153] Therefore, according to the present invention, a method (and a corresponding system) as defined in the appended claims may be provided. The method may be described as a blockchain data constraint method. The method may include: i) a step of receiving a first transaction to be verified at a node in a blockchain network, the first transaction comprising a first script, which, as a result of execution, causes the node to obtain at least a first set of data and field values ​​for the first transaction; ii) a step of obtaining a second transaction, the second transaction comprising a second script, which, as a result of execution, causes the node to determine at least a set of constraints based at least partially on the data provided as a result of the execution of the first script, and to verify the set of constraints for the first transaction based at least partially on the first set of field values; and iii) a step of transferring control of a digital asset according to the set of constraints as a result of the execution of the first and second scripts.

[0154] Verifying the first transaction can be done without verifying that the entity that created the first transaction has access to the secret information.

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

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

[0157] The second script may contain the public key of a specific data source that can be used to validate the data.

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

[0159] The constraint set can be derived, at least partially, from the set of parameters in the data.

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

[0161] Verifying the first transaction may involve reassociating the digital asset from the first entity to the second entity.

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

[0163] The identity of the second entity can be determined, at least partially, based on a set of constraints.

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

[0165] The identity of the second entity can be determined, at least partially, based on a set of constraints.

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

[0167] It is also desirable to provide a system including a processor and memory containing executable instructions which, as a result of execution by the processor, cause the system to perform any of the methods described in the claims.

[0168] It is also desirable to provide a non-temporary computer-readable storage medium that stores executable instructions thereon, which, 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 in the claims.

[0169] Therefore, 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. The method may include: i) a step of receiving a first transaction to be verified at a node in a blockchain network, the first transaction comprising a first script, and as a result of execution, causing the node to obtain at least a first set of field values ​​of the first transaction, the first set of field values ​​comprising a third script, and a second set of field values ​​of a second transaction, the second set of field values ​​comprising a copy of the second script; ii) a step of obtaining a second transaction, the second transaction comprising a second script, and as a result of execution, causing the node to obtain at least a first set of field values ​​of the third script, and to determine that the copy of the second script matches the third script, as a result of determining that the termination condition is not met; and iii) a step of verifying the first transaction as a result of the execution of the first and second scripts.

[0170] The first script could be an unlocking script to satisfy the set of conditions in the second script.

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

[0172] The third script could be a locking script that imposes a set of conditions for validating future transactions.

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

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

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

[0176] The third script can be embedded in the field values ​​relating to the first set of field values.

[0177] A blockchain network can consist of distributed electronic devices running instances of the blockchain protocol.

[0178] Verifying the first transaction can be done without verifying that the entity that created the first transaction has access to the secret information.

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

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

[0181] A set of iterative smart contracts can be terminated by a termination condition.

[0182] It is also desirable to provide a system including a processor and memory containing executable instructions which, as a result of execution by the processor, cause the system to perform any of the methods described in the claims.

[0183] It is also desirable to provide a non-temporary computer-readable storage medium that stores executable instructions thereon, which, 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 in the claims.

[0184] Therefore, 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. The method may include: i) a step of receiving a first transaction to be verified at a node in a blockchain network, the first transaction comprising a first script, and as a result of execution, causing the node to obtain at least a first set of field values ​​for the first transaction, a second set of field values ​​for a second transaction, and inputs; ii) a step of obtaining a second transaction, the second transaction comprising a second script comprising a set of rules, the second script, as a result of execution, causing the node to verify at least that the second script matches a third script embedded in the first set of field values, to determine the current state at least based on the second set of field values, and to determine the next state at least partially based on the current state, inputs, and the set of rules, and to verify that the next state is included in the first set of field values; and iii) a step of verifying the first transaction as a result of the execution of the first and second scripts.

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

[0186] Any of the requested methods may further include a step of verifying the cryptographic secrets of the input source.

[0187] The set of rules can be a state transition matrix.

[0188] The third script could be a locking script that imposes a set of conditions for validating future transactions.

[0189] The second script can further instruct the node to determine if the termination condition has not been met.

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

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

[0192] Verifying the first transaction may involve reassociating the digital asset from the first entity to the second entity.

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

[0194] The following states may indicate the state of the first transaction during verification.

[0195] Any method of the claim may further include the step of receiving a third transaction. Additionally or alternatively, any method of the claim may further include the step of obtaining a fourth script from the first transaction, the fourth script which, as a result of execution, may cause a node to determine, at least in part, the next state and another state different from the current state, based on the next state, a second input, and a set of rules.

[0196] The current state and the next state can be members of the possible state sets for the first and second transactions, respectively.

[0197] It is also desirable to provide a system including a processor and memory containing executable instructions which, as a result of execution by the processor, cause the system to perform any of the methods described in the claims.

[0198] It is also desirable to provide a non-temporary computer-readable storage medium that stores executable instructions thereon, which, 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 in the claims. [Brief explanation of the drawing]

[0199] These and other embodiments of the present invention will become apparent and clarified by reference to the embodiments described herein. Embodiments of the present invention are described below as merely illustrative examples, and reference is made to the accompanying drawings. [Figure 1] Figure 1 shows a blockchain environment in which various embodiments can be implemented. [Figure 2] Figure 2 shows an example of a trustless, deterministic state machine according to one embodiment. [Figure 3] Figure 3 shows an example of a problem related to locking scripts that can be solved by one embodiment. [Figure 4] Figure 4 shows one example of data accessible to the unlocking script according to one embodiment. [Figure 5] Figure 5 shows an example of creating a signature from a set of serialized transaction fields according to one embodiment. [Figure 6]Figure 6 is a flowchart illustrating one example of an injection of a set of serialized unlocking transaction fields according to one embodiment. [Figure 7] Figure 7 shows another example of a problem related to locking scripts that can be solved by one embodiment. [Figure 8] Figure 8 shows an example of a serialized previous transaction injection according to one embodiment. [Figure 9] Figure 9 shows one example of a fieldset available depending on the signature hash type, according to one embodiment. [Figure 10] Figure 10 shows an example of extracting a transaction identifier from a serialized transaction according to one embodiment. [Figure 11] Figure 11 is a flowchart of one example of a serialized previous transaction injection according to one embodiment. [Figure 12] Figure 12 shows an example of unsecure provision of undetermined data from an undetermined source, according to one embodiment. [Figure 13] Figure 13 shows an example of secure delivery of undetermined data from a determined source, according to one embodiment. [Figure 14] Figure 14 shows one example of secure provisioning of undetermined data from an undetermined source into a locking script, according to one embodiment. [Figure 15] Figure 15 is a flowchart illustrating one example of securely providing undetermined data into a locking script according to one embodiment. [Figure 16]Figure 16 shows an example of a parameterized smart contract according to one embodiment. [Figure 17] Figure 17 is a flowchart showing an example of the execution of a parameterized smart contract according to one embodiment. [Figure 18] Figure 18 shows an example of a smart contract duplication problem that can be solved by one embodiment. [Figure 19] Figure 19 shows an example of a solution to the smart contract duplication problem according to one embodiment. [Figure 20] Figure 20 shows another example relating to the problem of smart contract duplication, which is solved according to one embodiment. [Figure 21] Figure 21 shows an example of a self-replicating smart contract according to one embodiment. [Figure 22] Figure 22 is a flowchart showing an example of a self-replicating smart contract with a termination condition, according to one embodiment. [Figure 23] Figure 23 shows an example of a problem involving next-state determination, which can be solved by one embodiment. [Figure 24] Figure 24 shows an example of a trustless, deterministic state machine according to one embodiment. [Figure 25] Figure 25 is a flowchart showing one example of a trustless, deterministic state machine according to one embodiment. [Figure 26] Figure 26 shows a computing environment in which various embodiments can be implemented. [Modes for carrying out the invention]

[0200] Referring first to Figure 1, an example of a blockchain and associated blockchain network 100 is shown according to one embodiment of the present disclosure. In this embodiment, the exemplary blockchain network 100 consists of peer-to-peer distributed electronic devices running an instance of the blockchain protocol. In some embodiments, the distributed electronic devices are referred to as nodes 102. One embodiment of the blockchain protocol is the Bitcoin protocol.

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

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

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

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

[0205] Figure 2 shows an exemplary embodiment 200 relating to the present disclosure. Specifically, Figure 2 shows a previous blockchain transaction 202 encoding a first state 206, and an unlocking blockchain transaction 204 encoding a second state 208. In the exemplary embodiment 200, the first state 206 in the first time is represented as a parameter embedded in the previous blockchain transaction 202. Further details regarding parameterizing constraints are seen in the description of Figure 16. The unlocking blockchain transaction 204 includes a parameter representing the second state 208.

[0206] In exemplary embodiment 200, transactions 202 and 204 are field value sets including one or more inputs and one or more outputs. In some embodiments, the inputs and outputs reflect an intention to recombine at least a portion of a digital asset from at least one entity to at least another entity. In exemplary embodiment 200, the previous blockchain transaction 202 is the most current, confirmed transaction included in the blockchain. In exemplary embodiment 200, the unlocking blockchain transaction 204 is the most recent future, unconfirmed, and not yet included in the blockchain. Each input of the unlocking blockchain transaction 204 receives an output from the previous blockchain transaction 202.

[0207] Several blockchain technologies, such as Bitcoin, use the elliptic curve digital signature algorithm (ECDSA) as a mathematical scheme for digital signatures. In embodiments, ECDSA is a cryptographic digital signature used to protect UTXOs from being acquired by unauthorized entities. In Bitcoin, the elliptic curve digital signature (ECDSA) typically appears with a signature hash flag (SIGHASH type) appended to the end. However, the technology of this disclosure is considered to be usable with blockchain technologies that do not implement the SIGHASH type. In such blockchain technologies, ECDSA is considered to conform to the signature principles of the specific blockchain technology.

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

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

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

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

[0212] Next, point x is determined from K, and then r, the first of the 256 bits in ECDS, is determined according to the following formula. r = x mode n

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

[0214] Finally, (r, s) is encoded in DER format. Given a signature (r, s), a message / data m, and a public key A corresponding to a private key a, the signature is verifiable. To verify the signature, ν=s -1 The expression ×(m×G+r×y) is calculated. The signature is valid if ν = r.

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

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

[0217] Examples of operation codes referenced in this disclosure include: • OP_ECPX returns the x-coordinate of an elliptic curve point. OP_ADD adds the top two items to the stack. OP_BIGMOD returns the remainder (remainder) after removing the top two items from the stack. OP_BIGMODADD: Performs modulus addition of the top two items in the stack modulus onto the third item in the stack. OP_BIGMODINVERSE: Performs a modulus negative exponent operation. OP_BIGMODMUL: Performs the modulo multiplication of the top two items in the stack modulus and applies it to the third item in the stack. OP_CAT concatenates the top two items in a stack. OP_CHECKSIG pops the public key and signature from the stack and verifies them against the signature in the transaction field according to the SIGHASH type. Returns 1 if the signature is valid, 0 otherwise. OP_CHECKSIGVERIFY functions similarly to OP_CHECKSIG, but OP_VERIFY is executed afterward. OP_DERENCODE encodes the top two items of the stack in DER format. OP_DUP: Duplicates the top item of the stack. OP_ECPMULT performs elliptic curve point multiplication (also known as elliptic curve scalar multiplication) on the top two items of the stack. These statements are executed if OP_ELSE, the preceding OP_IF, OP_NOTIF, or OP_ELSE is not executed; otherwise, these statements are not executed if the preceding OP_IF, OP_NOTIF, or OP_ELSE is executed. • OP_ENDIF terminates if / else blocks. OP_EQUAL returns 1 if the inputs are exactly equal, otherwise 0. OP_EQUALVERIFY is similar to OP_EQUAL, but OP_VERIFY is executed afterward. 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 using SHA-256, and then using RIPEMD-160. • OP_IF: If the top stack value is not false, the statement is executed and the top stack value is removed. OP_MUL multiplies the top two items in the stack. • OP_NOTIF: If the value at the top of the stack is incorrect, the statement is executed and the value at the top of the stack is removed. OP_ROLL: Items with a stack depth of n items are 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 a transaction as invalid if the value at the top of the stack is not true.

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

[0219] In the above script,<SIGHASH Byte> ,message <m>Secret Key , and number <k>However, the data is entered into the main stack (last-in, first-out) in the order described above. Script operations: OP_DUP OP_TOALTSTACK<PubK G> When you execute "OP_ECPMULT", a number of <k>It is copied to the alternate stack, and then, <k>Elliptic curve generator<PubK G> This is multiplied to create the elliptic curve point K at the top of the main stack. Script operation "OP_ECPX" <n>Executing "OP_BIGMOD OP_DUP OP_TOALTSTACK" calculates r from the x-coordinate of K modulus n. A copy of r is pushed onto the alternate stack. Script operation " <n>OP_BIGMODMUL <n>OP_BIGMODADD OP_FROMALTSTACK OP_SWAP OP_FROMALTSTACK <n>OP_BIGMODINVERSE <n>The execution of "OP_BIGMODMUL" is k -1 Calculate s from (m+r×a)mod n. Finally, the execution of the script operation "OP_DERENCODE OP_SWAP OP_CAT" is encoded in DER format, and<SIGHASH Byte> This results in r and s being concatenated to it. In this disclosure, this script is referred to as OP_GENSIG. Accordingly, references to OP_GENSIG in embodiments of this disclosure should be considered as a shortened version of the operations performed by the script.

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

[0221] As described above, in some embodiments, the locking script 306 is a script that secures a transaction by specifying conditions that must be met in order to transfer the output. More specifically, executing the locking script 306 is configured to receive data from the executed unlocking script as a result of execution by a verification node of the blockchain system, perform a predetermined operation based on the data, and return a result indicating whether the execution of the unlocking script successfully "unlocked" the locking script (i.e., met an internally set set of conditions). In some embodiments, the locking script 306 defines one or more data constraints that must be met (e.g., by data provided via the unlocking script) for the transaction verification to be successful. For example, the locking script 306 may request certain data provided within the unlocking script in order to previously unlock the associated digital asset of transaction 302.

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

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

[0224] Figure 5 shows one example 500 relating to how a serialized set of transaction fields is formed. As shown in Figure 5, a serialized transaction 510 (i.e., a transaction represented by a series of bytes in a particular format) contains a set of transaction field values. The signer selects a SIGHASH type and a number k in 512, where k is typically a random or pseudorandom number to mask / protect the private key and is therefore sometimes referred to in this disclosure as the “mask number”. A modified copy of transaction 514 is one example of the set of fields of the serialized transaction 510 selected according to a specified SIGHASH type (e.g., SIGHASH_NONE+ANYONECANPAY in Example 500). The signer hashes the modified copy of transaction 514 (e.g., a double SHA-256 hash), resulting in message m516. The signer then creates the signature using the SIGHASH type, message m, the signer's private key, and a number k, as described above in relation to Figure 2.

[0225] The table below shows a typical example of an unlocking script and a locking script, in which the assumed signature of entity A specified in the unlocking script is checked against entity A's public key using the OP_CHECKSIG operation code. [Table 2]

[0226] Thus, understanding the signature creation in Figure 5, the following table shows examples of the unlocking and locking scripts when a portion of the procedure shown in Example 500 is moved into the unlocking script. [Table 3]

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

[0228] However, note that, apart from the SIGHASH type and the set of unlocking transaction fields determined according to the SIGHASH type, other operations of the procedure may be moved to the locking script. [Table 5]

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

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

[0231] In this disclosure, the script described above may be referred to as OP_UNLOCKINGTXINJECTION. Accordingly, any reference to OP_UNLOCKINGTXINJECTION in embodiments of this disclosure should be considered a simplification of the operations performed by the script described above. However, it should be noted that any entity providing a SIGHASH type and a set of unlocking transaction fields determined according to the SIGHASH type may receive the transaction output. However, this becomes a useful feature, as will be described in more detail below. As described above, in some embodiments, receiving the transaction output refers to creating an unlocking transaction that references the transaction output and evaluates to be valid, thereby ensuring that the transaction output is received.

[0232] Figure 6 is a flowchart illustrating one embodiment of process 600, which results in the injection of a set of unlocking transaction fields, determined according to the SIGHASH type, according to one embodiment depending on various embodiments. Some or all of process 600 (or any other described processes, or variations and / or combinations thereof) may be executed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions executed collectively on one or more processors. Executable instructions and / or other data may be stored in non-temporary computer-readable storage media (for example, computer programs are permanently stored in magnetic, optical, or flash media).

[0233] For example, some or all of process 600 may be performed by verification nodes within a blockchain network, such as the exemplary blockchain network 100 in Figure 1. Such verification nodes may consist of any suitable computing devices (e.g., servers in a data center, client computing devices, multiple computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device, such as computing device 2600 in Figure 26). Process 600 includes a series of operations in which the system performing process 600 executes locking and unlocking scripts for an unverified transaction together in the manner described in Figure 5, and as a result obtains a SIGHASH type and transaction field value set, creates a signature, and verifies the signature.

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

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

[0236] Figure 7 is an embodiment 700 illustrating a problem related to blockchain transactions that is solved by one embodiment of the present disclosure. Specifically, in embodiment 700 shown in Figure 7, the locking script 706 is unable to read the input of the transaction in which it is embedded, and as a result, is unable to directly read the fields of the previous transaction. In some embodiments, transaction 704 is similar to the unlocking transaction 304 in Figure 3, which represents an attempt to recombine at least a portion of the digital assets controlled by the previous transaction. As described above, in some embodiments, the locking script 706 is a script that secures the transaction by specifying conditions that must be met in order to transfer the output, similar to the locking script 306 in Figure 3.

[0237] Figure 8 shows an example 800 in which the unlocking script 808 is made to include a serialized previous transaction by extracting the transaction ID and performing a constraint check. Specifically, Figure 8 shows an unlocking transaction 804 having an unlocking script 808 that utilizes the output from previous transactions 802A-02B. As can be seen, the unlocking script 808 is made to retrieve the serialized previous transaction. In some examples, the serialized previous transaction refers to an unmodified version of the field value set of the previous transaction.

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

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

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

[0241] Therefore, in the following method, a given field can be made to exist in the determined set of unlocking transaction fields by constraining the SIGHASH type. First, a SIGHASH type is duplicated. Then, the SIGHASH type is pushed onto the stack (e.g., SIGHASH_ALL). Finally, OP_EQUALVERIFY is called. As can be seen in Figure 9, SIGHASH_ALL (as shown in unlocking transaction 904A) contains a hash and, as described above, represents the transaction IDs of previous transactions y and z. In contrast, SIGHASH_ALL+ANYONECANPAY (as shown in unlocking transaction 904B) contains only the hash of the immediately preceding transaction y. In some embodiments, unlocking transactions 904A-904B are analogous to unlocking blockchain transaction 204 in Figure 3, representing an attempt to recombine at least a portion of the digital assets controlled by previous transactions (e.g., transactions y and / or x). The extraction of the transaction ID can be achieved by parsing the serialized transaction using substring operation codes until the desired field is reached, as shown in Figure 10.

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

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

[0244] In the script described above, OP_EXTRACTXID is an operation code / script that captures data including the transaction ID and the location of the transaction ID as the input and output of the extracted transaction ID. In this disclosure, the script described above may be referred to as OP_PREVTXINJECTION. Accordingly, a reference to OP_PREVTXINJECTION in embodiments of this disclosure should be considered as a simplification of the operation performed in the script described above.

[0245] However, it should be noted that any entity providing a SIGHASH type, a set of unlocking transaction fields determined according to the SIGHASH type, and a serialized previous transaction can obtain transaction output. However, this is a useful feature, as will be explained in more detail below.

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

[0247] In this disclosure, the scripts in Table 8, as well as the scripts in Table 8, may also be referred to as OP_SELFTXINJECTION. Accordingly, any reference to OP_SELFTXINJECTION in the embodiments of this disclosure should be considered a simplification of the operations performed in the scripts.

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

[0249] Figure 11 is a flowchart illustrating one embodiment of process 1100 for causing the injection of serialized previous transactions according to various embodiments. Some or all of process 1100 (or any other described processes, or variations and / or combinations thereof) may be executed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions executed together on one or more processors. Executable instructions and / or other data may be stored in non-temporary computer-readable storage media (for example, computer programs are permanently stored in magnetic, optical, or flash media).

[0250] For example, some or all of process 1100 may be executed by verification nodes within a blockchain network, such as the exemplary blockchain network 100 in Figure 1. Such verification nodes may consist of any suitable computing devices (e.g., servers in a data center, client computing devices, multiple computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device, such as computing device 2600 in Figure 26). Process 1100 includes a series of operations in which the system executing process 1100 executes locking scripts for unverified transactions and, as a result, obtains serialized previous transactions corresponding to transaction IDs extracted from the unverified transactions.

[0251] In 1102, the system obtains an unvalidated transaction from an entity attempting to recombine at least a portion of its digital assets. The unvalidated transaction includes a locking script and an unlocking script. The locking script and unlocking script may be similar to those shown in Tables 8 and 9 above. That is, the locking script, by which the unlocking script is executed, contains a set of instructions that take values ​​stored in the main stack and alternate stack as input. Execution of the instruction set successfully validates the unvalidated transaction if it evaluates to TRUE. Thus, the unlocking script is executed before the locking script, setting the values ​​in the main stack and alternate stack used by the locking script. In the embodiment of Figure 11, the unlocking script for the unvalidated transaction includes a serialized set of the previous transaction, a SIGHASH type, and the unlocking transaction.

[0252] As a result of the execution of the locking script following the unlocking script, at 1104, the system obtains the serialized previous transaction, the SIGHASH type, and the serialized set of unlocking transaction fields included in the unlocking script. At 1106, the system creates a signature based on the SIGHASH and based on the serialized set of field values of the unvalidated transaction. Note that the SIGHASH type affects which fields are used in signature creation, and the desired SIGHASH may depend on the specific previous transaction sought. For example, Table 8 shows the locking and unlocking scripts for extracting the previous transaction, but does not necessarily show the previous transaction containing the same locking script and uses the SIGHASH type of SIGHASH_ALL. As shown in FIG. 9, the SIGHASH_ALL type enables the search for inputs of other previous transactions of the unlocking transaction. In contrast, Table 9 shows the locking and unlocking scripts for extracting the previous transaction having the same locking script (i.e., the previous transaction corresponding to the signed input) and uses the SIGHASH type of SIGHASH_ALL|ANYONECANPAY. As shown in FIG. 9, the SIGHASH_ALL|ANYONECANPAY type removes the inputs of other previous transactions other than the previous transaction having the signed input.

[0253] In 1108, the system verifies the previously created signature, and then, in 1110, creates a value that matches the transaction ID of the unlocking transaction (i.e., the serialized set of field values) by performing a double SHA-256 on the acquired serialized previous transaction. Using a substring operation code, in 1112, the system extracts the transaction ID of the serialized set of field values, and in 1114, the system determines whether the transaction ID created by the double SHA-256 on the serialized previous transaction matches the transaction ID of the serialized set of field values. Note that in various embodiments, a match does not necessarily require equality. For example, two values ​​may match if they are mathematically equivalent, even if they are not equal. In another embodiment, two values ​​may match if they correspond to a common object (e.g., a value), or are complementary in some default way, and / or satisfy one or more matching criteria. In general, any method can be used to determine whether or not a match exists. It should also be noted that one or more of the operations performed in 1102–1114 may be performed in parallel and in various orders and combinations.

[0254] FIG. 12 shows an example 1200 that illustrates the problems associated with a locking script solved by one embodiment of the present disclosure. That is, example 1200 shown in FIG. 12 illustrates the problems presented by providing undetermined data to a locking script. In some embodiments, the term “undetermined data” refers to data provided via an unlocking script that unlocks a locking script, and among them, the node executing the locking script has no prior indication.

[0255] In some embodiments, previous transaction 1202 is similar to previous transaction 302 in FIG. 3. Similarly, in some embodiments, unlocking transaction 1204 is similar to 304. In some embodiments, blockchain 1224 is composed of a set of blocks related to transactions in a peer-to-peer electronic ledger. In an embodiment, each block of blockchain 1224 includes the hash of a prior block so that the blocks are linked together (i.e., “chained”), creating a permanent and immutable record of all verified transactions within the blockchain.

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

[0257] In Example 1200, the locking script 1206 is blank, so that the data can be accepted without any prior knowledge of the data source or what the data is. <d>The value is determined at the time the unlocking transaction 1204 is created (for example, by the undetermined source 1222A). However, since the unlocking transaction 1204 is susceptible to changes (in other words, mutable) by the undetermined source 1222B, etc., before it is confirmed on blockchain 1224 (at which point the unlocking transaction 1204 becomes immutable), such locking scripts present security concerns.

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

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

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

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

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

[0263] In some embodiments, the undetermined source 1322 is an entity whose data cannot be modified. In some embodiments, the determined source 1326 is a known entity at the time the locking script 1306 is created, and thus the locking script 1306 contains the public key of the determined source 1326.

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

[0265] Example 1400 differs from Example 1300 in Figure 13 in that the data in Example 1400 may be undetermined at the time the locking script 1406 is created. The data in question is embedded somewhere in the previous transaction 1402 and can therefore be extracted by parsing the serialized previous transaction as described above in relation to Figures 8-11.

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

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

[0268] Undetermined source 1422A is an entity that supplies data encoded in a previously serialized transaction. Undetermined source 1422B is an entity that intercepts and attempts to modify the unlocking transaction 1404. In some embodiments, undetermined sources 1422A and 1422B may be the same or different entities. As can be seen in Example 1400, the identity of undetermined source 1422A does not need to be known at the time the locking script 1406 is created. Furthermore, the data also does not need to be known at the time the locking script 1406 is created. Nevertheless, undetermined source 1422B is still protected from modification of the data.

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

[0270] Figure 15 is a flowchart illustrating one embodiment of process 1500 for securely supplying undetermined data according to various embodiments. Some or all of process 1500 (or any other described processes, or variations and / or combinations thereof) may be executed under the control of one or more computer systems configured with executable instructions and / or other data. They may be implemented as executable instructions executed together on one or more processors. Executable instructions and / or other data may be stored in non-temporary computer-readable storage media (e.g., computer programs permanently stored in magnetic, optical, or flash media).

[0271] For example, some or all of process 1500 may be executed by validation nodes in a blockchain network, such as the exemplary blockchain network 100 in Figure 1. Such validation nodes may consist of any suitable computing devices (e.g., servers in a data center, client computing devices, multiple computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device, such as computing device 2600 in Figure 26). Process 1500 includes a series of operations in which an unvalidated transaction is received, undetermined data and a second value are obtained as a result of executing an unlocking script, and the undetermined data is validated as relating to a trusted data source.

[0272] In 1502, the system obtains an unverified transaction from an entity attempting to recombine at least a portion of its digital assets. The unverified transaction includes a locking script and an unlocking script. These scripts may be similar to those shown in Figures 13 and 14. The execution of the instruction set successfully verifies the unverified transaction if it evaluates to TRUE. Thus, the unlocking script sets the values ​​of the main and alternate stacks that were executed prior to the locking script and are used by the locking script.

[0273] In the embodiment shown in Figure 13, the unlocking script for an unverified transaction is for undetermined data (" <d>”) and the signature of the undetermined data signed using the modified private key (“<SigA’>”). The modified private key is the private key of a determined data source (e.g., “Bob”) modified by multiplying the value of the undetermined data using elliptic curve point multiplication. Thus, the private key would be a point on the elliptic curve. As described above, the term “undetermined” in this context means that the data is not specified or, otherwise, not restricted by the locking script itself. Similarly, an “undetermined data source” is a data source whose identity is not specified or not restricted by the locking script, while a “determined data source” restricts its identity to a specific data source within the locking script (e.g., by including the public key of the data source). The unlocking script for an unvalidated transaction in the embodiment of FIG. 14 includes the serialized undetermined data of the previous transaction, the SIGHASH type, and the serialized set of unlocking transaction fields. In this way, since the data source is the serialized previous transaction, the data source need not be specified or restricted by the locking script itself.

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

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

[0276] Figure 16 shows an embodiment of a parameterizable smart contract 1600 according to one embodiment of the present disclosure. Specifically, Figure 16 shows a prior transaction 1602 having a locking script 1606 that imposes constraints on an unlocking script 1608 of an unlocking transaction 1604. The embodiment shown in Figure 16 can be understood by recalling that the present disclosure has described in the description of Figure 3-6 how a set of unlocking transaction fields determined according to the SIGHASH type can be injected into the locking script 1606. Furthermore, recall that in the description of Figure 7-11 the present disclosure described how a set of unlocking transaction fields determined according to the SIGHASH type can be parsed using a substring operation code to extract a transaction ID before constraints are applied so that the serialized prior transaction is injected into the locking script 1606. This process can be extended to work on any field in the set of unlocking transaction fields.

[0277] It should be noted that the locking scripts described in the context of Figures 6 and 11 do not impose restrictions on specific entities that create unlocking transactions. For example, a locking script does not require proof that a specific entity has access to a secret (e.g., a private key, a value that generates a specific hash, etc.). The embodiment in Figure 16 applies this concept in an undiscriminating manner with respect to specific entities that create unlocking transactions, but imposes certain constraints on how UTXOs can be claimed. In this way, the embodiment in Figure 16 is self-executing and self-conducting. In other words, if the conditions of the smart contract are not met (i.e., the specified constraints are not followed), verification fails and the contract is not executed.

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

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

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

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

[0282] Figure 17 is a flowchart illustrating one embodiment of process 1700 for implementing a parameterized smart contract, according to various embodiments. Some or all of process 1700 (or any other described processes, or variations and / or combinations thereof) may be executed under the control of one or more computer systems configured with executable instructions and / or other data. They may be implemented as executable instructions executed together on one or more processors. Executable instructions and / or other data may be stored in non-temporary computer-readable storage media (for example, computer programs are permanently stored in magnetic, optical, or flash media).

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

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

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

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

[0287] In 1708, the system verifies the constraints against the set of unlocking transaction field values ​​determined according to the SIGHASH type. That is, the system verifies that the relevant subset of the unlocking transaction satisfies the constraint conditions. If the relevant subset of the unlocking transaction satisfies the constraints, the unlocking transaction is confirmed as valid. Otherwise, if the relevant subset of the unlocking transaction does not satisfy the constraints, the unlocking transaction is considered invalid. Note that one or more of the operations performed in 1702–1708 may be performed in parallel and in various orders and combinations.

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

[0289] Figure 19 shows one embodiment 1900 relating to a self-replicating smart contract of an embodiment of the present disclosure. As shown in Figure 19, rather than creating a predetermined number of unlocking transactions to achieve a repeating contract, a self-replicating smart contract 1904 with a termination condition can be created based on the parameterizable smart contract described in relation to Figures 16-17. Thus, in the above embodiment, Alice only needs to create one unlocking transaction to use up the initial amount of digital assets from transaction 1902. Unlocking transaction 1904A contains a script that causes unlocking transaction 1904A to replicate itself into the next unlocking transaction. The script contains a termination condition that causes unlocking transaction 1904N to stop replicating after the termination condition has been met (e.g., after n occurrences).

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

[0291] Figure 20 shows an example 2000 of a problem involving iterative transactions that is solved by embodiments of this disclosure. Specifically, the locking script of transaction 2002 (locking script 0) incorporates the locking script of the first unlocking transaction 2004A (locking script 1), the first unlocking transaction itself incorporates the locking script of the second unlocking transaction 2004B (locking script 2), and so on up to the last unlocking transaction 2004N. When fully expanded, it becomes clear that locking script 0 is not identical to locking script 1, locking script 1 is not identical to locking script 2, and so on. Therefore, embodiment 2000 cannot be said to be self-replicating because the locking scripts are not identical. This problem can be understood as stemming from self-referencing, that is, the locking scripts would need to embed copies of themselves, resulting in an unending and unravelable loop. Therefore, the locking scripts will be undeterminable. Example 2000 fixes the number of times (n) the loop can resolve before assigning a value to the nth locking script. This allows n-1 locking scripts to embed n locking scripts, n-2 locking scripts to embed n-1 locking scripts, and so on. However, this results in n different locking scripts.

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

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

[0294] Furthermore, in these embodiments, a solution to the problem shown in Figure 20 is to have the locking script 1 receive first data (e.g., unlocking transaction data) and second data (e.g., previous transaction data), both of which have the locking script embedded. In these embodiments, the locking script 1 verifies that the locking scripts from the first and second data match. If the locking script 1 then verifies that the second data (previous transaction data) has the locking script 1 embedded, then the first data is also verified to have the locking script 1 embedded.

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

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

[0297] In an embodiment, the termination condition avoids situations where a previous transaction has insufficient funds, but the locking script is still validating, i.e., unredeemable transactions. For example, the termination condition can be implemented to verify that there are sufficient digital assets to execute the next transaction, and otherwise terminate the verification. As a more specific example, if the first pool contains 365 units of digital assets plus the amount required for each transaction fee (e.g., enough for one transaction per day for a year), the termination condition can verify that the number of remaining units is greater than the number required to complete the transaction. For example, as long as sufficient funds exist, the termination condition continues to verify the transaction. Otherwise, if insufficient funds exist, the termination condition is met, and verification is terminated. Thus, if insufficient funds exist on the 366th day, it is unnecessary to verify the locking script for the 366th unlocking transaction, and the termination condition ensures that the self-replication of the locking script is terminated.

[0298] Figure 22 is a flowchart illustrating one example of process 2200 for a self-replicating smart contract with termination conditions, according to various embodiments. Some or all of process 2200 (or any other described processes, or variations and / or combinations thereof) may be implemented as executable instructions that are executed under the control of one or more computer systems configured with executable instructions and / or other data, and that are executed together on one or more processors. The executable instructions and / or other data may be stored in non-temporary computer-readable storage media (e.g., computer programs permanently stored in magnetic, optical, or flash media).

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

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

[0301] Once the termination conditions are met, at 2206, process 2200 terminates, and verification ends. Otherwise, at 2208, the system extracts the first locking script from the unverified transaction. Note that the first locking script is a locking script that is executed after the current unverified transaction has been verified, for example, when another unverified transaction attempts to transfer the current transaction's UTXO.

[0302] In step 2210, the system extracts a second locking script from the previously serialized transaction. In this embodiment, the second locking script is a copy of the currently executing locking script. In step 2212, the system running process 2200 determines whether the first locking script matches the second locking script (for example, whether the two locking scripts are identical). If the locking scripts do not match, in step 2214, the system determines that the unvalidated transaction failed to validate and remains unvalidated.

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

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

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

[0306] In some embodiments, the current state is represented as a parameter embedded in the transaction, and the unlocking transaction 2304 also has the following state value, which is embedded in the unlocking transaction 2304. The following state value is the current state for the smart contract in the field value set of the unlocking transaction 2304, and is accessible when the unlocking transaction 2304 is created, as described above. In some embodiments, at least one input is provided as external data in a parameter determined at the time the unlocking transaction 2304 is created. For security reasons, such a parameter originates from a determined source. This provides a deterministic state transition. Finally, by using the script of the self-replicating smart contract described above in relation to Figures 18-22, one embodiment of a trustless, deterministic state machine is created. In some embodiments, “trustless” refers to the property that any entity can create a valid unlocking transaction as long as the constraints are met. However, in some cases, an entity may need to interact with a determined source to obtain the required input. While the various embodiments described in relation to Figures 23-25 ​​refer to obtaining input from a determined source, it should be noted that in some embodiments, it is considered possible to obtain one or more inputs from an undetermined source, such as from a serialized previous transaction.

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

[0308] In an embodiment, each possible state is represented in a self-replicating locking script by a set of rules for state changes, such as a state transition matrix, and a particular transaction represents the state machine in a particular state. In such an embodiment, the transaction locking script is replicated for every unlocking transaction that attempts to transfer control of a digital asset to the next transaction, which must be linked to the current transaction. This process is repeated until a termination condition is satisfied. Since the input is not fixed and can be undetermined data, the state of the state machine can be constructed to change based on a particular external input. Thus, undetermined data provides inputs that can influence the next state.

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

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

[0311] Figure 25 is a flowchart illustrating one embodiment of process 2500 for a trustless, deterministic state machine, according to various embodiments. Some or all of process 2500 (or any other described processes, or variations and / or combinations thereof) may be executed under the control of one or more computer systems configured with executable instructions and / or other data. They may be implemented as executable instructions executed together on one or more processors. Executable instructions and / or other data may be stored in non-temporary computer-readable storage media (for example, computer programs are permanently stored in magnetic, optical, or flash media).

[0312] For example, some or all of process 2500 may be executed by verification nodes within a blockchain network, such as the exemplary blockchain network 100 in Figure 1. Such verification nodes may consist of any suitable computing devices (e.g., servers in a data center, client computing devices, multiple computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device, such as computing device 2600 in Figure 26). Process 2500 involves a series of operations in which the locking script of a self-replicating smart contract is verified, the current state is obtained from previously serialized transactions, input is obtained from the unlocking script, and the next state is determined at least partially based on a set of state rules. Process 2500 reflects variations of the exemplary scripts shown in Table 12.

[0313] At 2502, the system receives an unlocking transaction. The system begins by executing the unlocking script for the unlocking transaction. This causes the serialized previous transaction and the inputs embedded in the locking script to be placed on the stack. These inputs are retrieved at 2512. At 2504, the system running process 2500 determines whether a termination condition has been met. The termination condition may be one of those described in relation to Figure 19-22. In an embodiment, the termination condition, when met, terminates the transition of the state machine. If the termination condition is met, the system running process 2500 proceeds to 2506, at which point the trustless, deterministic state machine stops self-replicating.

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

[0315] In the context describing the disclosed embodiments, unless otherwise specified, the use of expressions relating to executable instructions (also referred to as code, applications, agents, etc.) that perform operations that the "instruction" would not normally perform on its own (e.g., data transmission, calculation, etc.) means that the instruction is being executed by a machine, thereby causing the machine to perform the specified operation.

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

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

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

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

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

[0321] The computing device 2600 may include at least one local clock 2624. The local clock 2624 is a counter that represents the time (numbers of ticks) that has occurred since a specific start date and may be integrated into the computing device 2600.

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

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

[0324] This specification and the drawings should therefore be considered illustrative rather than restrictive. However, it will be apparent that various modifications and alterations can be made without departing from the scope of the invention as described in the claims. Similarly, other variations are within the scope of this disclosure. Thus, the disclosed art is susceptible to various modifications and alternative configurations, the given exemplary embodiments of which have been shown in the drawings and described in detail above. However, it should be understood that there is no intention to limit the invention to any particular form disclosed, but rather to cover all modifications, alternative configurations, and equivalents within the scope of the invention as defined in the appended claims.

[0325] The terms “a” and “an” and “the” and the use of similar references in the context describing the disclosed embodiments (in particular, the context of the subsequent claims) are construed to cover both singular and plural unless otherwise indicated or unless the context makes such a contradiction apparent. The terms “comprising,” “having,” and “containing” are construed to be open-end terms (i.e., “including, but not limited to”) unless otherwise stated. The term “connected” is construed to be, if it refers to an unaltered and physical connection, to be partially or entirely contained, attached, or joined together, even if any intervening elements are present. Unless otherwise indicated, the references to ranges of values ​​in this disclosure are merely intended to function as a simplified way of individually referring to each distinct value that falls within the range, and each distinct value is incorporated into the specification as if it were individually referenced. The use of the terms “set” (e.g., “a set of items”) or “subset” should be interpreted as a nonempty collection containing one or more members, unless otherwise noted or contradicted by the context. Furthermore, unless otherwise noted or contradicted by the context, the term “subset” in relation to a corresponding set does not necessarily refer to a suitable subset of the corresponding set, although a subset and a corresponding set may be equivalent.

[0326] Associative language, such as phrases of the form "at least one of A, B, and C" (or "at least one of A, B and C"), is generally understood in context, unless otherwise specified or unless the context clearly indicates otherwise, to indicate that an item, term, etc., may be A, B, or C, or any non-empty subset of the set A, B, and C. For example, in an exemplary example of a set having three members, the associative language "at least one of A, B, and C" refers to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {A, B, C}. Thus, such associative language is not generally intended to mean that a given embodiment requires the presence of at least one A, at least one B, and at least one C, respectively.

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

[0328] All embodiments or use of exemplary language (e.g., “such as”) provided are intended solely to better clarify embodiments of the invention and, unless otherwise claimed, do not limit the scope of the invention. The language in the specification should not be construed as indicating any unclaimed element as essential to the practice of the invention.

[0329] Embodiments of this disclosure are described, including the best mode known to the inventors for carrying out the invention. Variations of these embodiments may be apparent to those skilled in the art by reading the foregoing description. The inventors expect that those skilled in the art will appropriately adopt such variations, and the inventors intend that embodiments of this disclosure will be carried out in ways other than those specifically described. Accordingly, the scope of this disclosure includes all variations and equivalents of the subject matter described in the appended claims, as permitted by applicable law. Furthermore, any combination in any possible variation of the elements described above is included in the scope of this disclosure unless otherwise indicated or unless it is clearly inconsistent with the context.

[0330] All cited references, including publications, patent applications, and patents, are incorporated herein by reference to the same degree as if each reference were individually and specifically included by reference and as if the whole were evident.

[0331] It should be noted that the embodiments described above are not limiting to the present invention, but rather illustrative, and that those skilled in the art can design many alternative embodiments without departing from the scope of the invention, as defined by the appended claims. In the claims, any reference numerals enclosed in parentheses should not be construed as limiting the claims. The terms “comprising,” “comprises,” etc., do not preclude the existence of elements or steps other than those enumerated in any claim or the entire specification. In this specification, “comprises” means “contains or consists of,” and “comprising” means “contains or consists of.” A singular reference to an element does not preclude a plural reference to such element, and vice versa. The present invention can be implemented by hardware comprising several distinct elements and by a appropriately programmed computer. In apparatus claims enumerating several means, some of these means may be embodied by one and the same hardware item. The mere fact that the prescribed means are described in different dependent claims does not indicate that combinations of these means cannot be used to their advantage. [Explanation of Symbols]

[0332] 100 Blockchain Networks 102 nodes 104 transactions Blockchain transactions 202, 302, and 402 204, 304, 404 Unlocking Blockchain Transactions< / d> < / d> < / k> < / m>

Claims

1. It is a method, The step involves a node in the blockchain network receiving a first transaction to verify, the first transaction including a first script, and as a result of execution, the node receives at least Obtain the first set of field values ​​for the first transaction, the first set of field values ​​including the third script, and, Retrieve the second set of field values ​​for the second transaction, and the second set of field values ​​including a copy of the second script. Steps to make it happen, This is a step to obtain a second transaction, the second transaction containing the second script, and as a result of its execution, the node determines that the termination condition has not been met, and therefore, The third script is obtained from the first set of field values, and, Determine that the copy of the second script matches the third script. Steps to make it happen, The steps include verifying the first transaction as a result of executing the first script and the second script, Methods that include...

2. The first script includes an unlocking script to satisfy the set of conditions of the second script. The method according to claim 1.

3. The second script includes a locking script that imposes the set of conditions for verifying the first transaction, The method according to claim 2.

4. The third script includes a locking script that imposes the set of conditions for validating future transactions. The method according to claim 2.

5. The aforementioned second transaction includes a transaction related to a digital asset, and / or The first transaction includes a transaction that recombines at least a portion of the digital assets from a first entity to a second entity. The method according to any one of claims 1 to 3.

6. The first transaction and the second transaction are members of a set of iterative smart contracts related to the digital asset. The method according to claim 5.

7. The set of iterative smart contracts is terminated by the termination condition. The method according to claim 6.

8. The step of verifying the first transaction is: The steps of recombining the digital assets from the first entity to the second entity, The method according to any one of claims 5 to 7, including

9. The step of determining whether the aforementioned termination conditions are not met is: A step of determining that the amount of the digital assets related to the second transaction is sufficient to recombine at least a portion of the digital assets, The method according to any one of claims 5 to 8, including

10. The third script is embedded in the field values ​​of the first set of field values, The method according to any one of claims 1 to 9.

11. The blockchain network comprises multiple distributed electronic devices that run instances of the blockchain protocol. The method according to any one of claims 1 to 3.

12. The step of verifying the first transaction is performed without verifying that the entity that created the first transaction has access to the secret information. The method according to any one of claims 1 to 11.

13. The above method further, The second script includes the step of causing the node to verify that the first transaction satisfies additional constraints as a further condition for verifying the first transaction, The method according to any one of claims 1 to 12.

14. A system including a processor and memory, The memory includes executable instructions, As a result of execution by the processor, the system is made to carry out the method described in any one of claims 1 to 13. system.

15. A non-temporary computer-readable storage medium that stores executable instructions, As a result of execution by the processor of the computer system, the computer system is made to perform at least one of the methods described in claims 1 to 13. A non-temporary computer-readable storage medium.

Images