Parameterizable smart contracts

Abstract

To provide distributed ledger technologies such as consensus-based blockchains.SOLUTION: A computer-implemented method for parameterizable smart contracts uses a blockchain network, such as a Bitcoin blockchain. A first transaction to be validated at a node in a blockchain network includes a first script that causes the node to at least obtain data and a first set of field values of the first transaction. A second transaction includes a second script that causes the node to at least determine a set of constraints based at least in part on the data supplied as a result of execution of the first script, and verify, based at least in part on the first set of field values, that the set of constraints are applicable to the first transaction. The first transaction is validated according to the set of constraints.SELECTED DRAWING: Figure 1

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 security related to electronic transfers performed 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 blockchain and transaction-chain technologies, permissioned and un-permissioned ledgers, shared ledgers, and variations thereof. The most well-known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. "Bitcoin" may be referred to in this disclosure as a useful application of the technology for convenience and illustrative purposes, but Bitcoin is only one of many applications to which the technology described in this disclosure may be applied. However, it should be noted that the present invention is not limited to use with the Bitcoin blockchain. Alternative blockchain implementations and protocols, including non-commercial applications, are also within the scope of the present invention. For example, the present technology provides advantages for utilizing blockchain implementations that have similar restrictions to Bitcoin with respect to constraints that can be encoded within a transaction, regardless of whether a cryptocurrency exchange occurs.

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

[0004] That is, a stack-based scripting language can utilize a stack. Regarding the stack, values can be pushed onto the top of the stack or popped from the top of the stack. Various operations performed on the 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 pushes the result (1 if equal, 0 if not equal) onto the top of the stack. Other operations performed on the stack, such as OP_PICK, can allow items to be selected from positions other than the top of the stack. In some of the scripting languages used by some embodiments, there may be at least two stacks, a main stack and an alternative stack. Some operations of the scripting language can move items from the top of one stack to the top of another stack. For example, OP_TOALTSTACK moves a value from the top of the main stack to the top of the alternative stack.

[0005] For a transaction to be written to the blockchain, it needs to be “validated”. Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. One node can have different validity criteria from other nodes. Since validity in the blockchain is consensus-based, a transaction is considered valid when the majority of nodes agree that the transaction is valid. The software client installed on the node performs this validation work on the transaction by executing locking and unlocking scripts for Unspent Transaction Outputs (UTXOs), partially referencing the unspent transaction outputs. The transaction is considered valid by the node when the execution of the locking and unlocking scripts evaluates to TRUE and other validation conditions, if applicable, are met. The validated transaction is propagated to other network nodes, where the miner node can choose to include the transaction in the blockchain. Therefore, for a transaction to be written to the blockchain, the transaction needs to: i) be validated by the first node that receives the transaction. If the transaction is validated, the node relays it to other nodes in the network. And the transaction needs to: ii) be added to a new block constructed by the miner, and iii) be mined, i.e., added to the public ledger of past transactions. When a sufficient number of blocks have been added to the blockchain to make the transaction substantially irreversible, the transaction is considered confirmed.

Summary of the Invention

[0006] The present disclosure describes technical aspects related to one or more blockchain-based computer programs. A blockchain-based computer program is a machine-readable and executable program recorded in a blockchain transaction. The blockchain-based computer program includes rules that can process inputs to create results, and then actions can be executed according to those results. A locking script can utilize the blockchain to enable very flexible and complex smart contracts when it can access both unlocking and previous transactions. One area of current research is the use of blockchain-based computer programs to implement "smart contracts". Different from traditional contracts that would be written in natural language, a smart contract can be a computer program designed to automate the execution of the terms of a machine-readable contract or agreement.

[0007] In an embodiment, an interaction with a specific entity can be encoded at a specific step in a smart contract, but the smart contract can otherwise be automatically executed and self-enforced. In some examples, the automatic execution refers to the execution of a smart contract that is successfully executed to enable the transfer of UTXOs. In such examples, note that an “entity” that can cause the transfer of UTXOs refers to an entity that can create an unlocking script without being required to prove some 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 examples, self-enforcement refers to the verification nodes of a blockchain network that are made to execute unlocking transactions according to constraints. In some examples, “unlocking” a UTXO (also known as “spending” a UTXO) is used in a technical sense and refers to referring to a UTXO and creating an unlocking transaction that is validly executed.

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

[0009] Accordingly, it is desirable to provide improved methods and systems for improving blockchain technology in one or more of these aspects. Accordingly, a method and corresponding system as defined in the appended claims are provided in accordance with the present invention.

[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 recordation of a transaction in a 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 resource managed by a blockchain. A digital asset may be used as a cryptocurrency in some embodiments, although it is contemplated that in embodiments, a digital asset may be used additionally or alternatively in other contexts. The present invention is applicable to the control of digital assets, but is essentially technical and it is noted that it may be used in other contexts that utilize the data structure of a blockchain without necessarily involving the transfer of digital assets. As will be described below, the present invention may also be described as a security method / system for a new, improved, and advantageous method of performing operations via a blockchain network or platform.

[0011] As described in more detail below, in one embodiment, a locking script may provide access to a predetermined 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 constrains the transaction identifier (ID) extracted from a predetermined field of the unlocking transaction, such that access to a set of fields in the previous transaction can be given so that the serialized previous transaction is included in the unlocking script of the unlocking transaction. According to this embodiment, a method can be provided for injecting a previous transaction serialized in the locking script of a blockchain transaction. This is by obtaining, as inputs, a first set of field values corresponding to a first transaction and a second set of field values corresponding to another transaction, extracting a transaction identifier from the first set of field values, and determining, 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, the locking script and the unlocking script can be configured to enable the secure provision of undetermined data from either a determined or undetermined source. To protect data from an undetermined source from being changed, the data can be embedded within a serialized previous transaction. Note that even if the data is present within a serialized previous transaction, the data is considered undetermined in the sense that the locking script does not constrain the data to be a predetermined value. To protect data from a determined source from being changed, a public key from the determined source may be included within the locking script. Thus, the data can be used to modify the public key and then, using the modified private key, can be used to verify the signature of the signed data. A method for obtaining undetermined data and a second value can be provided according to this embodiment. And based on the data and the second value provided in the unlocking script, it is verified that the undetermined data is associated with the 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 an unlocking transaction. The parameterized smart contract can be embodied through a locking script that has constraints parameterized by secure, undetermined data provided in the unlocking script of an unlocking transaction from a determined or undetermined source. A method for obtaining undetermined data can be provided according to this embodiment. A set of constraints applied to the recombination of digital assets can be determined from the data, and the digital assets are recombined with a second entity according to the set of constraints.

[0015] As will be described in more detail below, in one embodiment, a smart contract is created to be self-replicating until an end condition is reached. In accordance with this embodiment, a method may be provided for checking that the end condition is satisfied. And if the end condition is not satisfied, the locking script of the previous transaction is checked to match 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 can be used to create a trustless, deterministic state machine. In accordance with this embodiment, a method may be provided for verifying a self-replicating locking script and determining the next state of a trustless, deterministic state machine based at least in part on the input from a finalized source and the current state of the trustless, deterministic state machine.

[0017] The novel techniques described and suggested in this disclosure extend the functionality of a blockchain without disrupting the properties of the blockchain that guarantee the integrity of the data stored within the blockchain data structure. For example, the techniques improve the field of digital record verification, which is the field of defined smart contracts where the conditions for verification are embedded within the records. This is by setting and implementing criteria for recombining digital assets and by utilizing a blockchain network. Additionally, the techniques described and suggested in this disclosure may improve the functionality of a blockchain network. This is by enabling blockchain transactions to function as state machines and by enabling the functionality of a computer program to depend on the state recorded within such state machines.

[0018] Furthermore, the techniques described and suggested in this disclosure are necessarily rooted in computer technology to overcome problems specifically arising from blockchain technologies (e.g., Bitcoin's script) that have been specially designed to limit functionality for security reasons. For example, the script originally does not support the functionality of complex flow control, such as loops that occur. One advantage of this limitation is that the program has a predictable execution time. Another significant advantage of restricting the script 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, while the security of blockchain transfers / exchanges is enhanced and maintained, the mechanism needs to be found to implement functionality not permitted or provided by the language itself. The present invention provides an advance in this regard and addresses, at least in part, the current limitations of blockchain transactions using the implementation of a locking script for self-replicating and self-replicating blockchain transactions. Accordingly, the present invention provides a technical solution to a technical problem and offers advantages with respect to security, improved control of digital asset exchange / transfer via blockchain, and the extension of current blockchain-related functionality.

[0019] Therefore, according to the present invention, a computer-implemented method (and corresponding system) can be provided as defined in the appended claims. The computer-implemented method can be described as a blockchain data constraint method. The computer-implemented method includes: i) receiving, at a node in a blockchain network, a first transaction for transferring control of a digital asset, the first transaction including a first script that includes at least a set of field values of the first transaction, and upon execution, causing the node to obtain the set of field values; ii) obtaining a second transaction, the second transaction being associated with the digital asset and including a second script, and upon execution, 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 the execution of the first script; and iii) verifying the first transaction by executing the first script and the second script.

[0020] Verifying 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 a private cryptographic key of an asymmetric key pair. Additionally or alternatively, the second script may further cause the node to create a signature based at least in part on the private cryptographic key and a 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 set of field values may be at least in part based 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] Also, it is desirable to provide a system including a processor and a memory containing executable instructions that cause the system to execute any of the methods recited in the claims as a result of execution by the processor.

[0033] Also, it is desirable to provide a non-transitory computer-readable storage medium having stored thereon executable instructions that cause a computer system to at least execute any of the methods recited in the claims as a result of execution by a processor of the computer system.

[0034] Accordingly, a computer-implemented method (and corresponding system) as defined in the appended claims may be provided in accordance with the present invention. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: i) receiving, at a node within a blockchain network, a first transaction for transferring control of a digital asset, and as a result of execution, causing 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) obtaining a second transaction, the second transaction being associated with the digital asset and including a second script, and as a result of execution, causing the node to obtain at least a first set and a second set of field values related 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 the transaction identifier based at least in part on the second set of field values; and iii) verifying the first transaction by executing the first script and the second script.

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

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

[0037] A particular transaction can be associated with the control of a digital asset being transferred.

[0038] A particular transaction can be associated with a second digital asset 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] The node can be a verification node of the blockchain network.

[0041] Verifying the first transaction can further include adding the first transaction to the blockchain in the blockchain network as a result of successfully verifying the first transaction.

[0042] 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 met.

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

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

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

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

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

[0048] It is also desirable to provide a non-transitory computer-readable storage medium having stored thereon executable instructions that cause a computer system to at least execute any of the methods recited in the claims, as a result of execution by a processor of the computer system.

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

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

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

[0052] Failure to verify that the data is associated with the data source may cause failure to verify the first transaction.

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

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

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

[0056] The first script can make the field set of a particular transaction available to a node as input to the second script as a result of execution of the first script by including the field set of the particular transaction.

[0057] A particular transaction can be a second transaction.

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

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

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

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

[0062] It is also desirable to provide a system including a processor and a memory including executable instructions that cause the system to execute any of the methods recited in the claims as a result of execution by the processor.

[0063] It is also desirable to provide a non-transitory computer-readable storage medium storing thereon executable instructions that cause a computer system to execute at least any of the methods recited in the claims as a result of execution by a processor of the computer system. Therefore, according to the present invention, a computer-implemented method (and corresponding system) can be provided as defined in the appended claims. The computer-implemented method can be described as a blockchain data constraint method. The computer-implemented method can include: i) receiving, at a node in a blockchain network, a first transaction for transferring control of a digital asset, the first transaction including a first script, and as a result of execution, causing the node to obtain at least a first set of data and field values of the first transaction; ii) obtaining a second transaction, the second transaction including a second script, and as a result of execution, causing the node to determine at least a set of constraints based at least in part on data provided as a result of execution of the first script and to verify the set of constraints for the first transaction based at least in part on the first set of field values; and iii) transferring control of the digital asset according to the set of constraints as a result of execution of the first script and the second script.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0077] It is also desirable to provide a non-transitory computer-readable storage medium having stored thereon executable instructions that cause a computer system to execute at least any of the methods recited in the claims as a result of execution by a processor of the computer system.

[0078] Therefore, in accordance with the present invention, a computer-implemented method (and corresponding system) as defined in the appended claims may be provided. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: i) receiving, at a node in a blockchain network, a first transaction for transferring control of a digital asset, the first transaction including a first script, 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 including a third script, and causing the node to obtain a second set of field values of a second transaction, the second set of field values including a copy of the second script; ii) obtaining the second transaction, the second transaction including the second script, and as a result of execution, causing the node to obtain at least the first set of field values of the first transaction and the third script as a result of determining that an end condition is not satisfied, and causing the node to determine that a copy of the second script matches the third script; and iii) transferring control of the digital asset as a result of execution of the first script and the second script.

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

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

[0081] The second script may be a locking script for imposing a set of conditions for verifying the first transaction.

[0082] The third script can be a locking script that imposes a set of conditions for the verification of future transactions.

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

[0084] Determining that the termination condition is not met can 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] The blockchain network can be composed of distributed electronic devices that execute an instance of the blockchain protocol.

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

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

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

[0090] The set of repeating smart contracts can be terminated by an end condition.

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

[0092] It is also desirable to provide a non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to execute at least any of the methods recited in the claims.

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

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

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

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

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

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

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

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

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

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

[0103] Any of the methods recited in the claims may further include the step of receiving a third transaction. Additionally or alternatively, any of the methods recited in the claims may further include the step of obtaining a fourth script from the first transaction, and the fourth script, as a result of being executed, may cause the node to determine a different state that is different from the next state and the current state based at least in part on the next state, the second input, and the rule set.

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

[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 a memory including executable instructions that, as a result of execution by the processor, cause the system to execute any of the methods recited in the claims.

[0107] It is also desirable to provide a non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to at least execute any of the methods recited in the claims.

[0108] Accordingly, a computer-implemented method (and corresponding system) as defined in the appended claims may be provided in accordance with the present invention. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: i) receiving, at a node within a blockchain network, at least a first transaction to be verified, the first transaction including at least a set of field values of the first transaction, and, as a result of being executed, causing the node to obtain the set of field values, the first script; ii) obtaining a second transaction, the second transaction being verified and, as a result of being executed, 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, the second script; and iii) verifying the first transaction by executing the first script and the second script.

[0109] Verifying the first transaction may 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 a private cryptographic key of an asymmetric key pair. Additionally or alternatively, the second script may further cause the node to create a signature based at least in part on the private cryptographic key and a 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.

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

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

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

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

[0115] Verifying the first transaction may cause a transfer of an unspent transaction output.

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

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

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

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

[0120] The first script may cause a node to create a set of fields available as input to the second script as a result of the execution of the first script by including a set of fields.

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

[0122] It is also desirable to provide a non-transitory computer-readable storage medium storing thereon executable instructions that cause a computer system to execute at least any of the methods recited in the claims as a result of being executed by a processor of the computer system.

[0123] Therefore, in accordance with the present invention, a computer-implemented method (and corresponding system) as defined in the appended claims may be provided. The computer-implemented method may be described as a blockchain data constraint method. The method may include: i) receiving, at a node within a blockchain network, a first transaction, the first transaction including a first script, and as a result of execution, causing 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) obtaining a second transaction, the second transaction being verified and, as a result of execution, causing the node to obtain at least a first set of field values and a second set of field values related 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 determining, based at least in part on the second set of field values, that the particular transaction corresponds to the transaction identifier; and iii) verifying the first transaction by executing the first script and the second script.

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

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

[0126] The particular transaction may be associated with control of a digital asset transferred as a result of verifying 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 verification of the first transaction.

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

[0129] The node can be a verification node of the 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 a successful verification of the first transaction.

[0131] 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 met.

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

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

[0134] As a result of further execution, the second script can cause the node to determine that a particular transaction is a member of a set of transactions related to the first transaction, at least partially based on the signature hash type.

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

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

[0137] It is also desirable to provide a non-transitory computer-readable storage medium storing thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to execute at least any of the methods recited in the claims.

[0138] Accordingly, a method (and corresponding system) as defined in the appended claims may be provided in accordance with the present invention. The method may be described as a blockchain data constraint method. The method may include: i) receiving, at a node within a blockchain network, a first transaction for transferring control of a digital asset, the first transaction including a first script and including at least a first value, at least a portion of which includes data not constrained by a second script, and a second value; ii) obtaining a second transaction, the second transaction being verified and, as a result of execution, causing the node to obtain, at least, the first value and the second value as a result of execution of the first script and to verify that the data is associated with a particular source, at least partially based on the first value and the second value; and iii) verifying the first transaction by executing the first script and the second script.

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

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

[0141] A failure to verify that the data is associated with a data source can cause a failure to verify the first transaction.

[0142] The identity of a particular source need not be restricted by the second script.

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

[0144] As a result of being executed, the second script can verify that the particular transaction corresponds to the transaction identifier by verifying that the transaction identifier matches the hash of the field set of the particular transaction.

[0145] The first script can cause the node to make the field set of the particular transaction available as input to the second script as a result of the execution of the first script by including the field set of the particular transaction.

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

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

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

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

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

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

[0152] It is also desirable to provide a non-transitory computer-readable storage medium having executable instructions stored thereon that cause a computer system to perform at least any of the methods recited in the claims as a result of execution by a processor of the computer system.

[0153] 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 includes: i) receiving, at a node in a blockchain network, a first transaction to be verified, the first transaction including a first script, and as a result of execution, causing the node to obtain at least a first set of data and field values of the first transaction; ii) obtaining a second transaction, the second transaction including a second script, and as a result of execution, causing the node to determine at least a set of constraints, at least partially based on data provided as a result of execution of the first script, and to verify the set of constraints for the first transaction, at least partially based on the first set of field values; and iii) transferring control of a digital asset according to the set of constraints as a result of execution of the first script and the second script.

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

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

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

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

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

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

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

[0161] Verifying the first transaction can include re - associating the digital asset from the first entity to the second entity.

[0162] The set of constraints can further cause at least a portion of the digital asset to be re - associated with a third entity.

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

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

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

[0166] The set of constraints can further cause at least a portion of the digital asset to be re - associated with a third entity.

[0167] Also, it is desirable to provide a system including a processor and a memory containing executable instructions that cause the system to execute any of the methods recited in the claims as a result of execution by the processor.

[0168] Also, as a result of being executed by a processor of a computer system, there is provided a non-transitory computer-readable storage medium storing thereon executable instructions for causing the computer system to at least execute any of the methods recited 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) receiving, at a node in a blockchain network, a first transaction to be verified, the first transaction including 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 including a third script, and causing the node to obtain a second set of field values of a second transaction, the second set of field values including a copy of the second script; ii) obtaining the second transaction, the second transaction including the second script, and as a result of execution, causing the node to, as a result of determining that an end condition is not satisfied, obtain at least the first set of field values and the third script of the first transaction, and cause the node to determine that a copy of the second script matches the third script; and iii) verifying the first transaction as a result of execution of the first script and the second script.

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

[0171] The second script may be a locking script for imposing a set of conditions for verifying the first transaction.

[0172] The third script may be a locking script for imposing a set of conditions for verifying a future transaction.

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

[0174] Verifying the first transaction can include re-associating the digital asset from the first entity to the second entity.

[0175] Determining that the end condition is not met can include determining that the amount of digital asset associated with the second transaction is sufficient to recombine at least a portion of the digital asset.

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

[0177] The blockchain network can be composed of distributed electronic devices that execute an instance of the blockchain protocol.

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

[0179] The second script can further cause the node to verify that the first transaction meets additional constraints as a further condition for verifying the first transaction.

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

[0181] The set of iterative smart contracts can be terminated by an end condition.

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

[0183] It is also desirable to provide a non-transitory computer-readable storage medium having stored thereon executable instructions that cause a processor of a computer system to execute at least any of the methods recited in the claims as a result of execution.

[0184] Accordingly, a method (and corresponding system) as defined in the appended claims may be provided in accordance with the present invention. The method may be described as a blockchain data constraint method. The method may include: i) receiving, at a node in a blockchain network, a first transaction to be verified, the first transaction including a first script that, when executed, causes the node to obtain at least a first set of field values of the first transaction, a second set of field values of a second transaction, and an input; ii) obtaining a second transaction, the second transaction including a second script including a set of rules, the second script causing the node to verify that at least a third script in which the second script is embedded in the first set of field values matches, determine a current state based at least in part on the second set of field values, and determine a next state based at least in part on the current state, the input, and the set of rules, and verify that the next state is included in the first set of field values; and iii) verifying the first transaction as a result of execution of the first script and the second script.

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

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

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

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

[0189] The second script may further cause the node to determine that the end condition is not satisfied.

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

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

[0192] Verifying the first transaction may include re-associating the digital asset from the first entity to the second entity.

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

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

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

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

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

[0198] It is also desirable to provide a non-transitory computer-readable storage medium having stored thereon executable instructions that cause a computer system to execute at least any of the methods recited in the claims as a result of execution by a processor of the computer system.

Brief Description of the Drawings

[0199] These and other aspects of the present invention will become apparent and elucidated with reference to the embodiments described herein. Embodiments of the present invention will now be described by way of example only, and reference will be made to the accompanying drawings.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

DETAILED DESCRIPTION OF THE INVENTION

[0200] Referring first to FIG. 1, an example of a blockchain network 100 associated with a blockchain according to one embodiment of the present disclosure is shown. In this embodiment, an exemplary blockchain network 100 is composed of peer-to-peer distributed electronic devices that execute an instance of a blockchain protocol. In some embodiments, the distributed electronic device is referred to as node 102. One example of a blockchain protocol is the Bitcoin protocol.

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

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

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

[0204] In one embodiment, at least some of the nodes 102 operate as validating nodes that verify transactions, as described in this disclosure. In some examples, a transaction includes proof of ownership of a digital asset (e.g., a number of bitcoins), and data that provides conditions for the acceptance or transfer of ownership / control of the digital asset. In some examples, an “unlocking transaction” refers to a transaction that re-associates (e.g., transfers ownership or control) at least a portion of a digital asset, as indicated by an unspent transaction output (UTXO) of a previous transaction, to an entity associated with a blockchain address. In some examples, a “previous transaction” refers to a transaction that includes 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 satisfied before ownership / control can be transferred (i.e., “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 / re-associated. In some blockchain protocols implemented in some embodiments, there is a one-to-one correspondence between a public key associated with an entity and a blockchain address. Verification of a transaction can include verification of one or more conditions specified in the locking script and / or the unlocking script.When the verification of transaction 104 is successful, the verification node adds transaction 104 to the blockchain and distributes it to node 102.

[0205] FIG. 2 shows an exemplary embodiment 200 according to the present disclosure. Specifically, FIG. 2 shows a previous blockchain transaction 202 that encodes a first state 206 and an unlocking blockchain transaction 204 that encodes a second state 208. In exemplary embodiment 200, the first state 206 at a first time is represented as a parameter embedded in the previous blockchain transaction 202. Further details regarding the constraints of parameterizing can be found in the description of FIG. 16. The unlocking blockchain transaction 204 includes parameters representing the second state 208.

[0206] In exemplary embodiment 200, transactions 202 and 204 are sets of field values that include one or more inputs and one or more outputs. In some embodiments, the inputs and outputs reflect the 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 a transaction in the near future that has not yet been confirmed and is not yet included in the blockchain. Each input of the unlocking blockchain transaction 204 receives the output of the previous blockchain transaction 202.

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

[0208] In an embodiment, a SIGHASH type refers to a set of fields that are extracted from a transaction before being serialized (e.g., normalized) and hashed. For example, the SIGHASH type can affect which fields of the transaction are included in a signature. In some examples, the SIGHASH type can be one or more of SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, or SIGHASH_ANYONECANPAY. In one embodiment, the type SIGHASH_ALL indicates that all fields within a transaction are hashed and signed, except for the input script. In one embodiment, the type SIGHASH_NONE indicates that the outputs need not be signed, allowing others to update the transaction. In one embodiment, the type SIGHASH_SINGLE indicates that the inputs are signed but the sequence numbers are blank, such that others can create a new version of the transaction, but only the signed outputs are in the same position as the inputs. In one embodiment, the type SIGHASH_ANYONECANPAY is combined with other types and indicates that inputs that include SIGHASH_ANYONECANPAY are signed, but other inputs need not be signed. The SIGHASH type can be represented by a value indicating the SIGHASH type. For example, in some implementations, SIGHASH_ALL is represented by a byte with a value of 1, SIGHASH_NONE is represented by a byte with a value of 2, SIGHASH_SINGLE is represented by a byte with a value of 3, and SIGHASH_ANYONECANPAY is represented by a byte with a value of 80. In some implementations, 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 the corresponding subset of the transaction that is encoded in bytes as determined by the SIGHASH type. For example, for the SIGHASH type of SIGHASH_ANYONECANPAY, only the single transaction input is included in the signature.

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

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

[0212] Next, point x is determined from K, and r, the first of the 256-bit numbers in ECDS, is determined according to the following equation. r = x mod n

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

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

[0215] Bitcoin uses a scripting system called "Script". In this disclosure, various script operation codes and keywords are referenced to perform various operations. However, it is contemplated that other blockchain technologies may implement different instruction sets, and thus, the operation codes described in this disclosure are considered to exemplify the operations performed by the operation codes rather than specific operation codes in the script. 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 implementing the described instruction set permits more than 200 instructions (e.g., operation codes) in a single script. Similarly, certain embodiments of this disclosure further assume the following. · That the functionality provided by the operation codes referred to in this disclosure exists and is available in a system that executes the operation code script / instruction set. And / or, · That the required functionality can be achieved by creating customized functions described to provide the desired behavior. These customized functions may be described to implement the functionality of op_codes that exist but are disabled in the language, or may be "new" op_codes that provide specific functionality not otherwise provided in the scripting language itself.

[0217] Examples of operation codes referred to in this disclosure include the following. · OP_ECPX, which returns the x coordinate of an elliptic curve point · OP_ADD, which adds the top two items on the stack · OP_BIGMOD, which returns the remainder after dividing the top two items on the stack · OP_BIGMODADD, which performs a modular addition of the top two items of the stack modulus on the third item of the stack · OP_BIGMODINVERSE, which performs a modulus negative exponent operation · OP_BIGMODMUL, which performs a modular multiplication of the top two items of the stack modulus on the third item of the stack · OP_CAT, which concatenates the top two items on the stack · OP_CHECKSIG, where the public key and signature are popped from the stack and verified against the signature of the transaction field according to the SIGHASH type. Returns 1 if the signature is valid and 0 otherwise · OP_CHECKSIGVERIFY, which functions the same as OP_CHECKSIG but then OP_VERIFY is executed · OP_DERENCODE, which encodes the top two items on the stack in DER format · OP_DUP, which duplicates the top item on the stack · OP_ECPMULT, which performs an elliptic curve point multiplication (also referred to as elliptic curve scalar multiplication) on the top two items on the stack ·OP_ELSE: These statements are executed if OP_ELSE, a preceding OP_IF, OP_NOTIF, or OP_ELSE was not executed; otherwise, if a preceding OP_IF, OP_NOTIF, or OP_ELSE was executed, these statements are not executed. ·OP_ENDIF: Ends an if / else block. ·OP_EQUAL: Returns 1 if the inputs are exactly equal, and 0 otherwise. ·OP_EQUALVERIFY : Similar to OP_EQUAL, but then executes OP_VERIFY. ·OP_FROMALTSTACK: Puts 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 statements are executed and the top stack value is removed. ·OP_MUL: Multiplies the top two items on the stack. ·OP_NOTIF: If the top stack value is false, the statements are executed and the top stack value is removed. ·OP_ROLL: Moves the item at depth n items on the stack to the top. ·OP_SUBSTR: Returns a section of a string. ·OP_SWAP: Swaps the top two items on the stack. ·OP_TOALTSTACK: Puts the input on top of the alternate stack and removes it from the main stack. ·OP_VERIFY: Marks the transaction as invalid if the top stack value is not true.

[0218] In one embodiment, the ECDS creation script can be created using opcode. This can be extended to create the signature creation script OP_GENSIG by appending the SIGHASH byte at the end.

Table 1

[0219] In the above script, <SIGHASH Byte>, message <m>, Private key , and several <k>is input into the main stack (last-in first-out) in the above order. When the script operation "OP_DUP OP_TOALTSTACK<PubK G>OP_ECPMULT" is executed, the number <k>is copied to the alternative stack, and, <k>is multiplied by the elliptic curve creator <PubK G>, creating an elliptic curve point K at the top of the main stack. The script operation "OP_ECPX <n>When "OP_BIGMOD OP_DUP OP_TOALTSTACK" is executed, r is calculated from the x - coordinate of K modulus n. A copy of r is pushed onto the alternative stack. The " <n>OP_BIGMODMUL <n>OP_BIGMODADD OP_FROMALTSTACK OP_SWAP OP_FROMALTSTACK <n>OP_BIGMODINVERSE <n>The execution of "OP_BIGMODMUL" is k -1 (m + r × a) mod n is used to calculate s. Finally, the execution of the script operation "OP_DERENCODE OP_SWAP OP_CAT" results in r and s, which are encoded in DER format and concatenated with <SIGHASH Byte>. In the present disclosure, this script is referred to as OP_GENSIG. Therefore, the reference to OP_GENSIG in the embodiments of the present disclosure should be regarded as a shorthand for the operations performed by the above script.

[0220] Figure 3 is Example 300 showing the problems related to blockchain transactions solved by one embodiment of the present disclosure. That is, in Example 300 which is the embodiment shown in Figure 3, the locking script 306 in the previous transaction 302 cannot directly read the fields of the unlocking transaction 304. As noted, in some embodiments, the previous transaction 302 is the latest, confirmed transaction included in the blockchain. Similarly, in some embodiments, the unlocking transaction 304 is a future transaction, not yet confirmed and not yet included in the blockchain. This represents an attempt to re-associate at least a portion of the digital asset controlled by the previous transaction 302.

[0221] As described above, in some embodiments, the locking script 306 is a script that secures a transaction by specifying conditions that need to 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, execute a predetermined operation based on the data, and return a result indicating whether the execution of the unlocking script has successfully "unlocked" the locking script (i.e., satisfied a set of internal conditions). In some embodiments, the locking script 306 defines one or more data constraints that need to be satisfied for the verification of the transaction to succeed (e.g., by data provided via the unlocking script). For example, the locking script 306 can require predetermined data provided within the unlocking script in order to unlock a related digital asset of a previous transaction 302.

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

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

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

[0225] The following table shows one embodiment of a typical unlocking script and a locking script, whereby the assumed signature of entity A specified in the unlocking script is checked against the public key of entity A using the OP_CHECKSIG opcode.

Table 2

[0226] Thus, understanding the signature creation in Figure 5, the following table shows an example of an unlocking script and a locking script when a part of the procedure shown in embodiment 500 is moved into the unlocking script.

Table 3

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

Table 4

[0228] Note, however, that other operations of the procedure may be moved to the locking script, except for the SIGHASH type and the set of determined unlocking transaction fields according to the SIGHASH type.

Table 5

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

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

Table 6

[0231] In the present disclosure, the above script may be referred to as OP_UNLOCKINGTXINJECTION. Therefore, the reference to OP_UNLOCKINGTXINJECTION in the embodiments of the present disclosure should be regarded as a simplification of the operations performed by the above script. However, note that any entity that provides the SIGHASH type and a set of unlocking transaction fields determined according to the SIGHASH type can receive the transaction output. However, this will become a useful feature, as will be described in more detail below. As described above, in some embodiments, receiving the transaction output refers to referring to the transaction output and creating an unlocking transaction that evaluates it as valid, thereby enabling the transaction output to be received.

[0232] FIG. 6 is a flowchart showing one example of process 600 that results in the injection of a set of unlocking transaction fields, determined according to a SIGHASH type, according to one embodiment corresponding to various embodiments. Some or all of process 600 (or any other described process, or variations and / or combinations of these processes) may be executed under the control of one or more computer systems configured with executable instructions and / or other data. And it may be implemented as executable instructions executed collectively on one or more processors. The executable instructions and / or other data may be stored in a non-transitory computer-readable storage medium (for example, a computer program is permanently stored in a magnetic medium, an optical medium, or a flash medium).

[0233] For example, some or all of process 600 may be executed by a verification node in a blockchain network, such as the exemplary blockchain network 100 of FIG. 1. Such verification nodes may be composed of any suitable computing device (for example, a server in a data center, a client computing device, multiple computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device such as the computing device 2600 of FIG. 26). Process 600 includes a series of operations, where the system executing process 600 executes the locking script and the unlocking script of the unvalidated transaction together in the manner described in FIG. 5, and as a result, obtains the SIGHASH type and the set of transaction field values, creates a signature, and verifies the signature.

[0234] At 602, the system obtains an unvalidated transaction from an entity attempting to recombine at least a portion of the digital asset. The unvalidated transaction includes a locking script and an unlocking script. The unlocking script is executed by the system prior to executing the locking script. 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 of the unvalidated transaction. As a result, at 604 and 606, the system executing process 600 obtains the SIGHASH type and the serialized set of transaction field values of the unvalidated transaction from the unlocking script and places them on the main stack. Once the execution of the unlocking script completes successfully, the system uses the state of the main stack (and, in some implementations, the state of an alternative stack) at the completion of the execution of the unlocking script to initiate the execution of the locking script. The locking script may be similar to the locking scripts shown in Tables 5 and 6 above.

[0235] At 608, according to the locking script, the system creates a signature using at least the SIGHASH type, the set of transaction field values placed on the main stack as a result of the execution of the unlocking script, and the private key associated with the public key pair. At 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 performed in various orders and combinations depending on the implementation, and some of the operations may be performed in parallel with other operations of process 600.

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

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

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

Table 7

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

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

[0241] Accordingly, in the following method, a given field can be made to exist within a set of determined unlocking transaction fields by constraining the SIGHASH type. First, duplicate the SIGHASH type. Then, push the SIGHASH type onto the stack (e.g., SIGHASH_ALL). Finally, call OP_EQUALVERIFY. As can be seen in Figure 9, SIGHASH_ALL (as shown in unlocking transaction 904A) includes the 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) includes only the hash of the immediately previous transaction y. In some embodiments, unlocking transactions 904A-904B are similar to unlocking blockchain transaction 204 of Figure 3, representing an attempt to recombine at least a portion of a digital asset controlled by a previous transaction (e.g., transaction 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 Example 1000 of the extraction of a transaction ID in one embodiment of the present disclosure. Specifically, Figure 10 shows that hash 1020, which is composed of a transaction ID in big-endian format, is a substring of serialized transaction 1010 that can be extracted by using a substring operation code in a 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 identify the position of hash 1020 before the transaction ID is extracted. However, in implementations where the fields have a fixed length, it is considered that parsing may not be required.

[0243] Therefore, in some embodiments, the previous transaction ID can be made accessible by constructing a locking script that causes the injection of a specific serialized previous transaction referred to in the unlocking transaction in the manner described with reference to Figure 6. For example, first, the SIGHASH type constraint is determined, the transaction ID is extracted, and the serialized previous transaction is replicated and inspected against the transaction ID extracted (according to the SIGHASH type) from the set of serialized fields of the unlocking transaction. Note that this process can be executed to cause the injection of multiple different serialized previous transactions. As an example, Table 8 represents a script that causes the injection of a previous transaction corresponding to input X of the unlocking transaction.

Table 8

[0244] In the above script, OP_EXTRACTXID is an operation code / script that captures data including the transaction ID and the position of the transaction ID as the input and output of the extracted transaction ID. In the present disclosure, the above script may be referred to as OP_PREVTXINJECTION. Therefore, a reference to OP_PREVTXINJECTION in an embodiment of the present disclosure should be regarded as a simplification of the operations performed in the above script.

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

[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 the present disclosure, similar to the script in Table 8, the above script in Table 8 may also be referred to as OP_SELFTXINJECTION. Therefore, a reference to OP_SELFTXINJECTION in an embodiment of the present disclosure should be regarded as a simplification of the operations performed in the above script.

[0248] Any entity that provides a SIGHASH type, a set of unlocking transaction fields determined according to the SIGHASH type, and a serialized previous transaction also notes that it can obtain a transaction output. However, this turns out to be a useful feature, as will be explained in more detail below. As described above, in some embodiments, obtaining a transaction output means creating an unlocking transaction that references the transaction output and successfully verifying the unlocking transaction.

[0249] FIG. 11 is a flowchart showing one example of a process 1100 for causing the injection of a serialized previous transaction according to various embodiments. Some or all of process 1100 (or any other described process, or variations and / or combinations of these processes) may be executed under the control of one or more computer systems configured with executable instructions and / or other data. And it may be implemented as executable instructions executed together on one or more processors. The executable instructions and / or other data may be stored in a non-transitory computer-readable storage medium (for example, a computer program is permanently stored in a magnetic medium, an optical medium, or a flash medium).

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

[0251] At 1102, the system obtains an unverified transaction from an entity attempting to recombine at least a portion of a digital asset. The unverified transaction includes a locking script and an unlocking script. The locking script and the unlocking script may be similar to the locking script and the unlocking script shown in Table 8 and Table 9 above. That is, the locking script, such as by the unlocking script, includes a set of instructions that capture values stored in the main stack and the alternate stack as inputs. Execution of the set of instructions successfully verifies the unverified transaction if evaluated to true (TRUE). Thus, the unlocking script is executed before the locking script and sets the values in the main stack and the alternate stack used by the locking script. The unlocking script of the unverified transaction in the embodiment of FIG. 11 includes a serialized previous transaction, a SIGHASH type, and a serialized set of unlocking transactions.

[0252] As a result of 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 can 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] At 1108, the system verifies a previously created signature and then, at 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 of the acquired serialized previous transaction. Using a substring operation code, at 1112, the system extracts the transaction ID of the serialized set of field values, and at 1114, the system determines whether the transaction ID created by the double SHA-256 of the serialized previous transaction matches the transaction ID of the serialized set of field values. Note that in various embodiments, a match does not necessarily require equality. For example, two values can match if they are mathematically equivalent even if they are not equal. As another example, two values can match if they correspond to a common object (e.g., a value), or are complementary in some predefined way, and / or if they meet one or more match criteria. Generally, any method for determining whether a match exists can be used. Also note that one or more of the operations performed at 1102 - 1114 can include parallelism and can be performed 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, of which the node executing the locking script has no prior indication.

[0255] In some embodiments, previous transaction 1202 is similar to previous transaction 302 of 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 such 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, whereby data can be accepted without prior knowledge of the source of the data or what the data is. Data (” <d>”) is determined when the unlocking transaction 1204 is created (e.g., by the undetermined source 1222A). However, since the unlocking transaction 1204 is susceptible to changes (in other words, mutable) by an undetermined source 1222B etc. before it is confirmed in the blockchain 1224 (at which point the unlocking transaction 1204 becomes immutable), such locking scripts present security concerns.

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

[0259] In the example 1300, the locking script 1306 is configured to cause a 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 private key can be modified based on the data (d), and a modified private 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 of the unmodified private key, can be similarly modified by performing an elliptic curve point multiplication to create a modified public key (A’) in the following manner. A’ = d × A

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

[0262] As can be seen by looking at Example 1300, the execution of the locking script 1306 causes the node to place the public key on the stack and perform an elliptic curve point multiplication operation (OP_ECMULT) between the public key and the data placed on the stack by the pre-execution of the locking script 1308. Then, at the time when the unlocking transaction is created by the source specified in the locking script (e.g., the determined source 1326), the data can be determined. Thus, the locking script has knowledge of the source that provides the data, but has no knowledge of what the data will become. Further execution of the locking script 1306 results in a verification result for the signature of the data signed using the modified private key (e.g., OP_CHECKSIG returns TRUE if the values match). This approach is secure because changes to the unlocking transaction 1304 invalidate it. However, the source of the data (the determined source 1326) needs to be specified. The signature verification algorithm in ECDSA involves checking whether the signature, public key, and message have a particular mathematical relationship. The message can be any data. In Bitcoin, the verification operation code, OP_CHECKSIG, restricts the message to be a serialized transaction, thereby preventing any arbitrary data from being the message, while allowing the message to be verified as coming from a particular source. Embodiments of the present disclosure provide an alternative solution to this limitation.

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

[0264] Figure 14 shows an embodiment 1400 that illustrates 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 of Figure 11. In some embodiments, previous transaction 1402 is similar to previous transaction 302 of Figure 3. Similarly, in some embodiments, unlocking transaction 1404 is similar to 304. In some embodiments, blockchain 1424 is similar to blockchain 1224 of Figure 12.

[0265] Embodiment 1400 differs from embodiment 1300 of Figure 13 in that the data in embodiment 1400 can be undetermined at the time the locking script 1406 is created. The data in question is embedded somewhere in previous transaction 1402 and can thus be extracted by parsing the serialized previous transaction as described above in connection with Figures 8-11 above.

[0266] In this way, the node executing the locking script 1406 does not need to have prior knowledge of the entity providing the serialized previous transaction, and also the node does not need to have prior knowledge of previous transaction 1402. Further, previous transaction 1402, what is committed to blockchain 1424, is already immutable at the time the unlocking transaction 1404 is created and is thus protected from changes 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, but the data is determined at the time previous transaction 1402 is created.

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

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

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

[0270] FIG. 15 is a flowchart showing one example of a process 1500 for securely supplying undetermined data according to various embodiments. Some or all of the process 1500 (or any other described process, or variations and / or combinations of these processes) may be executed under the control of one or more computer systems configured with executable instructions and / or other data. And it may be implemented as executable instructions executed together on one or more processors. The executable instructions and / or other data may be stored in a non-transitory computer-readable storage medium (e.g., a computer program permanently stored in a magnetic medium, an optical medium, or a flash medium).

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

[0272] At 1502, the system obtains an unvalidated transaction from an entity attempting to recombine at least a portion of a digital asset. The unvalidated transaction includes a locking script and an unlocking script. The locking script and the unlocking script may be similar to the locking script and the unlocking script shown in FIGS. 13 and 14. Execution of the instruction set successfully validates the unvalidated transaction if evaluated to TRUE. Thus, the unlocking script is executed prior to the locking script and sets the values of the main stack and the alternative stack used by the locking script.

[0273] The unlocking script of the unvalidated transaction in the embodiment of FIG. 13 has undetermined data (” <d>”), and a signature of the undetermined data signed using the modified private key (“<SigA’>”). The modified private key is obtained by multiplying the value of the undetermined data by the private key of a determined data source (e.g., “Bob”) 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 the 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 does not need to 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 sources associated with the data (e.g., a signature signed using the modified private key or a serialized set of unlocking transaction fields from which a transaction identifier can be extracted).

[0275] In 1506, the system verifies the data. For example, in the embodiment of FIG. 13, the system uses elliptic curve point multiplication (as described above) to verify that the data is related to the public key included in the locking script by modifying the public key using the data, and that the modified public key is related to a signature created using the corresponding private key that has itself been modified using elliptic curve point multiplication. As another example, in the embodiment of FIG. 14, the system determines whether 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 of FIG. 11. Note that one or more of the operations performed in 1502 - 1506 include parallelism and can be performed in various orders and combinations.

[0276] Figure 16 shows an example of a parameterizable smart contract 1600 according to one embodiment of the present disclosure. Specifically, Figure 16 shows a previous transaction 1602 having a locking script 1606 that imposes constraints on the 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 how a set of unlocking transaction fields determined according to the SIGHASH type can be injected into the locking script 1606 in the description of Figures 3-6. Further, in the description of Figures 7-11, recall that the present disclosure has described how a set of unlocking transaction fields determined according to the SIGHASH type can be parsed using a substring operation code for extracting a transaction ID prior to applying constraints such that the serialized previous 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] Note that the locking script described in the context of Figures 6 and 11 does not impose restrictions on the particular entity that creates the unlocking transaction. For example, the locking script does not require proof that a particular entity has access rights to a secret (e.g., a private key, a value for creating a particular hash, etc.). The embodiment of Figure 16 applies this concept to be non-discriminating with respect to the particular entity that creates the unlocking transaction, but imposes certain constraints on how a UTXO can be claimed. In this way, the embodiment of Figure 16 is automatically executed and self-executing. In other words, if the conditions of the smart contract are not met (i.e., do not comply with the specified constraints), the 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 of the unlocking transaction 1604 (e.g., requiring an 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 the secure, undetermined data within the unlocking script 1608. In embodiments, the parameterized data protects the smart contract from changes, in the manner described in connection with FIGS. 13-15, by being undetermined and securely parameterized data that protects the smart contract from changes. In embodiments, the parameterized data is undetermined.

[0279] The present disclosure has described two ways for providing secure, undetermined data to a locking script (e.g., a smart contract). The first way is that, as described in the context of FIGS. 13 and 15, secure, undetermined data can be obtained from a determined source. The second way is that, as described in the context of FIGS. 14-15, secure, undetermined data can be obtained from an undetermined source (e.g., a previous transaction). In an embodiment using the first way, the parameter is determined by the entity creating the unlocking transaction and will be set when the unlocking transaction is created (e.g., in the unlocking script 1608). In an embodiment using the second way, the parameter is determined by the entity that created the previous transaction and will be set at the time of creation of the previous transaction (i.e., embedded in the serialized previous transaction). Also note that in an embodiment, the first and second ways can 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 is shown to illustrate how a smart contract can be created using these ways. In this example, a smart contract is created by or for Alice to transfer 70% of her income to savings and 30% of her income to Bob, her investment manager. Her savings account is associated with the public key A (PubK A) of the cipher, and her account with Bob is associated with the public key B (PubK B) of the cipher. Alice's employer executes this smart contract so that on the pay day, Alice's income is distributed in the above way. Thus, Alice's income is automatically separated as she desires.

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

Table 10-1

Table 10-2

[0282] FIG. 17 is a flowchart illustrating one example of a process 1700 for implementing a parameterized smart contract according to various embodiments. Some or all of process 1700 (or any other described process, or variations and / or combinations of these processes) may be executed under the control of one or more computer systems configured with executable instructions and / or other data. And it may be implemented as executable instructions executed together on one or more processors. The executable instructions and / or other data may be stored in a non-transitory computer-readable storage medium (e.g., a computer program is permanently stored in a magnetic medium, an optical medium, or a flash medium).

[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 of FIG. 1. Such verification nodes may be composed of any suitable computing device (e.g., a server within a data center, a client computing device, multiple computing devices in a distributed system of a computing resource service provider, or by any suitable electronic client device such as the computing device 2600 of FIG. 26). Process 1700 includes a series of operations, where constraints are extracted from secure, undetermined data-embedded parameters.

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

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

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

[0287] In 1708, the system verifies constraints against the unlocking transaction field value set 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 include parallelism and can be executed in various orders and combinations.

[0288] Figure 18 shows Example 1800 related to the problems associated with repeating a smart contract, which is solved by an embodiment of the present disclosure. That is, in order to create a transaction that repeats a known number of times (for example, 5 times), a known number of unlocking transactions could be created in advance. This may be manageable for a small number of transactions, but for a contract with many repeated transactions, it would be 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 an amount of a digital asset (such as Bitcoin) that has value that can be exchanged for goods or services. Alice has allocated this amount to be used by her son Bob to pay for school lunches every day. Example 1800 of Figure 18 shows that Alice could create the unlocking transactions 1804A - 1804N in advance for each of Bob's individual lunch transactions. However, as shown in Figure 19, the present disclosure contemplates an alternative solution for Alice.

[0289] Figure 19 shows an example 1900 related 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 pre-determined 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. In this way, in the above example, Alice only needs to create one unlocking transaction to exhaust the initial amount of the digital asset in the previous transaction 1902. The unlocking transaction 1904A includes a script for the unlocking transaction 1904A to replicate itself into the next unlocking transaction. The script includes a termination condition to stop the replication in the unlocking transaction 1904N after the termination condition is met (for example, after n occurrences).

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

[0291] Figure 20 shows an example 2000 of a problem with iterative transactions solved by an embodiment of the present disclosure. That is, the locking script of the previous transaction 2002 (locking script 0) incorporates the locking script of the first unlocking transaction 2004A (locking script 1), and 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 the same as locking script 1, and locking script 1 is not the same as locking script 2, etc. Therefore, example 2000 cannot be said to be self-replicating because the locking scripts are not the same. This problem can be understood as being due to self-referencing. That is, the locking script would need to embed a copy of itself and would result in an unending and unravelable loop. Therefore, the locking script would be undeterminable. Example 2000 fixes the number of times (n) the loop can be unraveled before assigning a value to the nth locking script. Thereby, the n - 1 locking script can embed the n locking script, the n - 2 locking script can embed the n - 1 locking script, etc. However, this results in n different locking scripts.

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

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

[0294] Furthermore, in an embodiment, a solution to the problem shown in FIG. 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 embed the locking script. In these embodiments, the locking script 1 verifies that the locking scripts from the first data and the second data match. Then, if the locking script 1 verifies that the second data (previous transaction data) embeds the locking script 1, it is also verified that the first data embeds the locking script 1.

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

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

[0297] In an embodiment, the termination condition is a situation where a previous transaction has insufficient funds but the locking script still needs to be verified, that is, to avoid an unredeemable transaction. For example, the termination condition can be implemented to verify that there are sufficient digital assets to execute the next transaction, and if not, end the verification. As a more specific example, when the first pool contains 365 units of digital assets plus the amount required for each transaction fee (e.g., an amount sufficient for one transaction per day for one year), the termination condition can verify that the number of remaining units is more than the number required to complete the transaction. For example, as long as there are sufficient funds, the termination condition continues to verify the transaction. Otherwise, if there are insufficient funds, the termination condition is met and the verification is interrupted. Therefore, if there are insufficient funds on the 366th day, it is not necessary to verify the locking script of the 366th unlocking transaction, and the termination condition ensures the end of the self - replication of the locking script.

[0298] Figure 22 is a flowchart showing one example of a 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 process, or variations and / or combinations of those processes) are executed under the control of one or more computer systems configured with executable instructions and / or other data, and can be implemented as executable instructions executed together on one or more processors. The executable instructions and / or other data can be stored in a non - transitory computer - readable storage medium (e.g., a computer program permanently stored in magnetic, optical, or flash media).

[0299] For example, some or all of process 2200 may be performed by a verification node in a blockchain network, such as the exemplary blockchain network 100 of FIG. 1. Such verification nodes may be composed of any suitable computing device (e.g., a server within a data center, a client computing device, multiple computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device such as the computing device 2600 of FIG. 26). Process 2200 includes a series of operations where, if the end condition is not met, it is verified that the unlocking transaction and the locking script of the previous transaction are the same, and other constraints are verified.

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

[0301] Once the termination condition is met, at 2206, process 2200 ends and the verification is completed. Otherwise, at 2208, the system extracts the first locking script from the un-verified transaction. Note that the first locking script is a locking script that is executed after the current un-verified transaction is verified when another un-verified transaction attempts to transfer the UTXO of the current transaction.

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

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

[0304] Figure 23 shows an example 2300 of a problem solved by one embodiment of the present disclosure. Specifically, Figure 23 shows a state machine transitioning from a first state to a second state using blockchain transactions. In some examples, the state transition of the state machine is described as one or more inputs 2326, given the current state, and a set of state rules 2306 that determine the next state. Example 2300 of Figure 23 shows a set of state rules 2306 and a previous transaction 2302 having a first state 2328A embedded in the parameters. In some embodiments, the unlocking transaction 2304 is created to accept an input 2326 from a determined source. The input 2326 can be combined with the first state 2328A and 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 set of state rules is a state-transition matrix and can be represented by the constraints in the unlocking transaction 2304 in a manner described in connection with 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 includes the next state value in a particular field.

[0306] In an embodiment, the current state is represented as a parameter embedded in a transaction, and the unlocking transaction 2304 has the next state value also embedded in the unlocking transaction 2304. The next state value is the current state for the smart contract within the set of field values 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, such parameters are derived from a deterministic source. This provides a deterministic state transition. Finally, one embodiment of a trustless, deterministic state machine is created by using the script of the self-replicating smart contract described above in connection with FIGS. 18-22. In some examples, "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 deterministic source to obtain the required input. The various embodiments described in connection with FIGS. 23-25 refer to obtaining input from a deterministic source, but note that in some embodiments, it is contemplated that one or more inputs can be obtained from a non-deterministic source, such as from a serialized previous transaction.

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

[0308] In 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 a state machine in a particular state. In such an embodiment, the locking script of a transaction is replicated for every unlocking transaction that attempts to transfer control of a digital asset to the next transaction that needs to be linked to the current transaction. This process is repeated until an end condition is satisfied. Since the input is not fixed and can be undetermined data, the state of the state machine can be created to change based on a particular external input. Thus, the undetermined data provides an input that can affect the next state.

[0309] As an illustrative example, Alice lends some money to Bob, and Bob agrees to repay Alice. As described in this disclosure, a trustless, probabilistic state machine can be implemented as a smart contract that represents the transfer Bob makes to Alice. For example, the smart contract can be constructed such that Bob makes monthly payments to Alice for the next three months, and if the payments are not made, Bob's debt enters the debt collection stage. Thus, as long as Bob makes the transfer monthly, the current state remains the repayment state. However, if an external entity provides an input indicating that Bob did not make the transfer, then the state branches to the missed transfer state. In the missed transfer state, Alice can release the transaction and hand it over to the debt collector. Then, the trustless deterministic state machine 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 in the scripts of the embodiments shown in FIGS. 23-25.

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

Table 12-2

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

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

[0313] In 2502, the system receives an unlocking transaction. The system starts by executing the unlocking script of the unlocking transaction. It causes the inputs embedded in the serialized previous transaction and the locking script to be placed on the stack. These inputs are retrieved in 2512. In 2504, the system executing process 2500 determines whether the termination condition is satisfied. The termination condition may be the termination condition as described in connection with FIGS. 19-22. In an embodiment, the termination condition, when satisfied, causes the transition of the state machine to end. If the termination condition is satisfied, the system executing process 2500 proceeds to 2506, whereupon the trustless, deterministic state machine stops self-replicating.

[0314] At 2508, the system verifies that the locking script of the previous transaction matches the locking script of the unlocking transaction, in the manner described at 2212 of FIG. 22. If the locking scripts do not match, the verification fails and the unlocking transaction is not enabled. Otherwise, if the locking scripts match, at 2510, the system extracts the current state of a set of possible states from the serialized previous transaction. At 2512, the system obtains the input or inputs placed on the stack as a result of the execution of 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 the input. At 2516, the system verifies that the next state (e.g., state variables and other state-related data, if applicable) is embedded in the unlocking transaction. The system may also apply any remaining constraints as specified in the locking script. After the operations of 2502 - 16 complete successfully, the process ends at 2500, whereupon the unlocking transaction can be considered valid by the system executing the process. Note that one or more of the operations executed at 2502 - 18 may include parallelism and may be executed in various orders and combinations.

[0315] In the context of describing the disclosed embodiments, unless otherwise specified, the use of the expression for executable instructions (also referred to as code, application, agent, etc.) that perform operations (e.g., sending data, calculations, etc.) that usually do not execute alone by an instruction means that the instruction is being executed by a machine, thereby causing the machine to execute the specified operation.

[0316] FIG. 26 is an exemplary simplified block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 may be used to implement any of the systems illustrated and described above. For example, the computing device 2600 may be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 26, the computing device 2600 may include one or more processors 2602 that communicate with a number of peripheral subsystems via a bus subsystem 2604 and may be operatively coupled. The processor 2602 may be utilized for traversal of decision trees in a random forest of a supervised model in embodiments of the present disclosure (e.g., to yield an evaluation of the inverse document frequency of various search terms). These peripheral subsystems may include a storage subsystem 2606, 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 transactions described in the present disclosure, a database of history records described in the present disclosure, and decision rules of the monitoring model in the present 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 can enable a data technician to connect the device to a wireless network so that the data technician can send and receive data while located remotely, such as at a user data center. The bus subsystem 2604 may be utilized to communicate data such as details, search terms, etc. to the monitoring model of the present disclosure, and the output of the monitoring model may be utilized 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, an integrated mouse, a trackball, a touchpad, or a pointing device such as a graphics tablet, a scanner, a barcode scanner, a touch screen incorporated in a display, a voice input device such as a voice recognition system, a microphone, or other types of input devices. Generally, the use of the term "input device" is intended to include any possible type of device and mechanism for inputting information to the computing device 2600. One or more user interface output devices 2614 may include a non-visual display such as a display subsystem, a printer, or an audio output device. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection or other display device. Generally, the use of the term "output device" is intended to include any possible type of device and mechanism 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 executing the processes and variations described herein, when such interaction may be appropriate.

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

[0320] Memory subsystem 2608 may include 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, and may have a number of memories. File / disk storage subsystem 2610 may comprise non-temporary persistent (non-volatile) storage for program files and data files, and may include a hard disk drive, a floppy (registered trademark) disk drive together with associated removable media, a compact disk read-only memory drive (CD-ROM), an optical drive, a removable media cartridge, and other similar storage media.

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

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

[0323] Computing device 2600 can be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described hereinafter. Additionally, computing device 2600 may include another device that can be connected to computing device 2600 via one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). The device that can be connected to computing device 2600 may include a plurality of ports configured to receive an optical fiber connector. Accordingly, this device may be configured to convert an optical signal into an electrical signal that can be transmitted for processing to computing device 2600 via the port connecting the devices. Due to the ever-changing nature of computers and networks, the description of computing device 2600 shown in FIG. 26 is intended only as a specific example for the purpose of illustrating a preferred embodiment of the device. Many other configurations with more or fewer components than the system shown in FIG. 26 are possible.

[0324] This specification and the drawings are, therefore, to be considered in an illustrative rather than a limiting sense. However, it will be apparent that various modifications and changes may be made without departing from the scope of the invention as set forth in the claims. Similarly, other variations are within the scope of this disclosure. Accordingly, the disclosed technology is susceptible to various modifications and alternative configurations, although certain exemplary embodiments thereof have been shown in the drawings and described in detail above. However, there is no intention to limit the invention to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, alternative configurations, and equivalents within the scope of the invention as defined in the appended claims.

[0325] The terms "a" and "an" and the use of similar references in the context of describing the disclosed embodiments (in particular, the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated or clearly contradicted by the context. The terms "comprising", "having", and "containing" are to be construed as open-end terms (i.e., meaning "including, but not limited to") unless otherwise stated. The term "connected", when unchanged and referring to a physical connection, is to be construed as being included, attached, or joined together, either partially or wholly, even if there is some intervening element. The recitation of a range of values in this disclosure is merely intended to function as a shorthand way of referring individually to each separate value that falls within the range, and each separate value is incorporated into the specification as if it were individually recited. The use of the term "set" (e.g., "a set of items" or "subset") is to be construed as a nonempty collection containing one or more members, unless otherwise noted or contradicted by the context. Further, unless otherwise noted or contradicted by the context, the term "subset" with respect to a corresponding set does not necessarily denote a proper subset of the corresponding set, but the subset and the corresponding set may be equivalent.

[0326] Conjunctive language such as the phrase “at least one of A, B, and C” (or “at least one of A, B and C”) is understood in the context in which it is commonly used, unless otherwise specified or clearly inconsistent with the context, and indicates that an item, term, etc. can be either A or B or C, or any non-empty subset of the set of A, B, and C. For example, in an exemplary example of a set having three members, the conjunctive language “at least one of A, B, and C” refers to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {A, B, C}. Thus, such conjunctive language is not generally intended to mean that a given embodiment requires the presence of at least one A, at least one B, and at least one C, respectively.

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

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

[0329] Embodiments of the disclosure are described, including the best mode known to the inventors for practicing the invention. Variations of these embodiments may become apparent to those skilled in the art upon reading the foregoing description. The inventors expect such variations to be appropriately adopted by those skilled in the art, and the inventors intend for the embodiments of the disclosure to be practiced otherwise than as specifically described. Accordingly, the scope of the disclosure includes all modifications and equivalents of the technical matter recited in the appended claims as permitted by applicable law. Further, any combination of any of the above-described elements in all possible variations thereof is included within the scope of the disclosure unless otherwise indicated or clearly contradicted by context.

[0330] All references cited, including publications, patent applications, and patents, are hereby incorporated by reference in their entirety to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were fully disclosed.

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

Claims

1. 1. A computer-implemented method implemented by a processing resource, the method comprising: i) receiving, at a node in the blockchain network, a first transaction to transfer control of a digital asset; the first transaction includes a first script that includes at least a set of field values ​​of the first transaction; and causing the node to obtain the set of field values; Steps and ii) obtaining a second transaction; the second transaction includes a second script associated with the digital asset and that, as a result of being executed, causes the node to at least generate a signature based, at least in part, on the set of field values ​​provided as a result of execution of the first script; iii) verifying a first transaction by executing the first script and the second script; A method comprising:

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

3. the first script further includes a private encryption key of an asymmetric key pair; The method of claim 1.

4. the second script causes the node to generate a signature based, at least in part, on the private encryption key and a mask number; The method according to claim 3.

5. The step of verifying the first transaction further comprises: verifying that the signature is associated with a public cryptographic key of the asymmetric key pair; The method of claim 3 , comprising:

6. The first script further specifies a signature hash type. The method of claim 1.

7. the set of field values ​​is based, at least in part, on the signature hash type; The method according to claim 6.

8. the signature hash type is a value that indicates which field values ​​of the set of field values ​​of the first transaction should be included in the signature. The method according to claim 7.

9. the second script is a locking script that imposes a set of conditions for validating the first transaction; The method of claim 1.

10. Execution of the locking script causes the node to validate the first transaction by determining whether the set of conditions is satisfied.

10. The method of claim 9.

11. the first script includes an unlocking script for satisfying a set of conditions of the second script; The method of claim 1.

12. The digital assets are associated with unspent transaction outputs in the blockchain network. The method of claim 1.

13. The node is a computing device that is communicatively coupled to at least one other node in the blockchain network. The method of claim 1.

14. The blockchain network is composed of distributed electronic devices running instances of a blockchain protocol. The method of claim 1.

15. the first script and the second script are written using a Turing incomplete instruction set; The method of claim 1.

16. the first script and the second script are written using a Turing complete instruction set; The method of claim 1.

17. the first script includes a field set such that, as a result of execution of the first script, the node makes the field set available as input to the second script; The method of claim 1.

18. 1. A system including a processor and a memory, The memory stores executable instructions which, when executed by the processor, result in the system performing a method according to any one of claims 1 to 17. system.

Images