CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 18/200,507, filed 22 May 2023, which is a continuation of U.S. patent application Ser. No. 16/615,806, filed 21 Nov. 2019, now U.S. patent Ser. No. 11/893,582, issued 17 Jan. 2024, which is a 371 National Stage of International Patent Application No. PCT/IB2018/053337, filed 14 May 2018, which claims priority to United Kingdom Patent Application No. 1708190.2, filed 22 May 2017. United Kingdom Patent Application No. 1708200.9, filed 22 May 2017. United Kingdom Patent Application No. 1708192.8, filed 22 May 2017, United Kingdom Patent Application No. 1708196.9, filed 22 May 2017, United Kingdom Patent Application No. 1708198.5, filed 22 May 2017, and United Kingdom Patent Application No. 1708185.2, filed 22 May 2017, the disclosures of which are incorporated herein by reference in their entirety.

FIELD OF INVENTION

This invention relates generally to distributed ledger technologies, including blockchain transactions, and more particularly to causing the injection of fields from blockchain transactions into the unlocking transaction scripts. The invention utilises cryptographic and mathematical techniques to enforce security in relation to electronic transfers conducted over a blockchain network. The invention is particularly suited for, but not limited to, use in smart contracts and state machines.

BACKGROUND OF INVENTION

In this document we use the term “blockchain” 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 widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. While “Bitcoin” may be referred to as a useful application of the technology described in the present disclosure, for the purpose of convenience and illustration. Bitcoin is just one of many applications to which the technology described in the present disclosure may be applied. However, it should be noted that the invention is not limited to use with the Bitcoin blockchain; alternative blockchain implementations and protocols, including non-commercial applications, also fall within the scope of the present invention. For example, techniques would provide advantages to utilising blockchain implementations that have limitations similar to Bitcoin regarding what constraints can be encoded within transactions, regardless of whether an exchange of cryptocurrency occurs.

A blockchain is a peer-to-peer, electronic ledger which is implemented as a computer-based decentralised, distributed system made up of blocks which in turn are made up of transactions and other information. In some examples, a “blockchain transaction” refers to an input message encoding a structured collection of field values comprising data and a set of conditions, fulfilment of the set of conditions being prerequisite for the set of fields to be written to a blockchain data structure. For example, with Bitcoin, each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system and includes at least one input and at least one output. In some implementations, transferring control of a digital asset can be performed by reassociating at least a portion of a digital asset from a first entity to a second entity. Each block contains a hash of the previous block so that blocks become chained together to create a permanent, immutable record of all transactions which have been written to the blockchain since its inception. Transactions contain small programs known as scripts embedded into their inputs and outputs that specify how and by whom the outputs of the transactions can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

That is, the stack-based scripting language may utilize a stack. With the stack, values can be pushed onto the top of the stack or popped from the top of the stack. Various operations performed to the stack can result in pushing or popping one or more of the values to or from the top of the stack. For example, an OP_EQUAL operation pops the top two items from the stack, compares them, and pushes a result (e.g., 1 if equal or 0 if unequal) to the top of the stack. Other operations performed to the stack, such as OP_PICK, may allow items to be selected from positions other than the top of the stack. In some scripting languages employed by some of the present embodiments, there may be at least two stacks: a main stack and an alternate 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 alternate stack.

In order for a transaction to be written to the blockchain, it must be “validated”. Network nodes (miners) perform work to ensure that each transaction is valid, with invalid transactions rejected from the network. A node can have standards for validity different from other nodes. Because validity in the blockchain is consensus based, a transaction is considered valid if a majority of nodes agree that a transaction is valid. Software clients installed on the nodes perform this validation work on transactions referencing an unspent transaction (UTXO) in part by executing the UTXO locking and unlocking scripts. If execution of the locking and unlocking scripts evaluates to TRUE and other validation conditions, if applicable, are met, the transaction is valid by the node. The validated transaction is propagated to other network nodes, whereupon a miner node can select to include the transaction in a blockchain. Thus, in order for a transaction to be written to the blockchain, it must be i) validated by the first node that receives the transaction—if the transaction is validated, the node relays it to the other nodes in the network; and ii) added to a new block built by a miner; and iii) mined, i.e., added to the public ledger of past transactions. The transaction is considered to be confirmed when a sufficient number of blocks are added to the blockchain to make the transaction practically irreversible.

The present disclosure describes technical aspects of 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 comprises rules that can process inputs in order to produce results, which can then cause actions to be performed dependent upon those results. If a locking script can access both the unlocking and previous transactions, the blockchain can be utilized to enable highly flexible and complex smart contracts. One area of current research is the use of blockchain-based computer programs for the implementation of “smart contracts”. Unlike a traditional contract which would be written in natural language, smart contracts may be computer programs designed to automate the execution of the terms of a machine-readable contract or agreement.

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

A blockchain transaction output includes a locking script and information regarding ownership of digital assets such as Bitcoins. The locking script, which may also be referred to as an encumbrance, “locks” the digital assets by specifying conditions that are required to be met in order to transfer the UTXO. For example, a locking script could require that certain data be provided in an unlocking script to unlock the associated digital assets. The locking script is also known as “scriptPubKey” in Bitcoin. A technique for requiring a party to provide data to unlock a digital asset involves embedding a hash of the data inside the locking script. However, this presents a problem if the data is undetermined (e.g., not known and fixed) at the time the locking script is created.

SUMMARY OF INVENTION

Thus, it is desirable to provide for improved methods and systems that improve blockchain technology in one or more of these aspects. Thus, in accordance with the present invention, there is provided a method and corresponding system as defined in the appended claims.

The invention may be described as a verification method/system, and/or as a control method/system for controlling the validation of blockchain transactions. In some embodiments, a validated blockchain transactions results in recordation of the transaction on a blockchain, which in some applications, may result in an exchange or transfer of a digital asset via the blockchain. The digital asset is a unit of a resource managed by a blockchain. Although the digital asset may, in some embodiments, be used as cryptocurrency, it is contemplated that the digital asset, in embodiments, is additionally or alternatively usable in other contexts. Note that the invention, while applicable to the control of digital assets, is technical in nature and can be used in other contexts that utilise blockchain data structures without necessarily involving the transfer of digital assets. As explained below, the invention may also be described as a security method/system for new, improved and advantageous ways of performing operations via a blockchain network or platform.

As will be described in greater detail below, in an embodiment, a locking script may be given access to certain fields of an unlocking transaction by taking as input a set of field values of the unlocking transaction and a signature hash (SIGHASH) type from an unlocking script of the unlocking transaction and performing signature generation and verification operations.

As will be described in greater detail below, in an embodiment, a locking script may be given access to a set of fields in a previous transaction by constraining a transaction identifier (ID), extracted from the certain fields of the unlocking transaction, such that a serialized previous transaction is included in the unlocking script of the unlocking transaction. In accordance with the embodiment, there may be provided a method to inject a serialized previous transaction in a blockchain transaction locking script by taking as input a first set of field values corresponding to a first transaction and a second set of field values corresponding to another transaction, extracting a transaction identifier from the first set of field values, and determining based on the second set of field values that the other transaction corresponds to the transaction identifier

As will be described in greater detail below, in an embodiment, locking and unlocking scripts may be configured to enable secure provision of undetermined data from either a determined or undetermined source. To make data from an undetermined source secure from alteration, the data can be embedded in a serialized previous transaction. Note that even though the data is in the serialized previous transaction, it is considered undetermined in the sense that the locking script does not constrain the data to be a certain value. To make data from a determined source secure from alteration, a public key from the determined source can be included in the locking script where the data can be used to modify the public key, which can then be used to validate a signature of the data signed using a modified private key. In accordance with the embodiment, there may be provided a method to obtain undetermined data and a second value and validating that the undetermined data is associated with a data source based on the data and the second value provided in an unlocking script.

As will be described in greater detail below, in an embodiment a parameterized smart contract may be created by extracting constraint parameters from a previous transaction and applying the constraint parameters to fields of the unlocking transaction. The parameterized smart contract can be realized through a locking script having constraints that are parameterized by secure, undetermined data provided in an unlocking script of an unlocking transaction from a determined or undetermined source. In accordance with the embodiment, there may be provided a method to obtain undetermined data from which a set of constraints to apply to reassociation of a digital asset can be determined and reassociating the digital assets with a second entity according to the set of constraints.

As will be described in greater detail below, in an embodiment, the smart contract is created to be self-replicating until a termination condition is reached. In accordance with the embodiment, there may be provided a method to check for fulfilment of a termination condition and, if the termination condition is unfulfilled, check that a locking script of a previous transaction matches a locking script of the unlocking transaction.

As will be described in greater detail below, in an embodiment, the parameterized, self-replicating smart contract may be used to create a trustless, deterministic state machine. In accordance with the embodiment, there may be provided a method to verify a self-replicating locking script and, based at least in part on input from a determined source and a current state of a trustless, deterministic state machine, determine a next state for the trustless, deterministic state machine.

The novel techniques described and suggested in the present disclosure extend the functionality of the blockchain without disrupting the properties of the blockchain that ensure the integrity of the data stored within the blockchain data structure. For example, the techniques improve the field of computing, specifically the field of digital record validation where conditions for validation are defined smart contracts embedded in the records, by utilizing a blockchain network to set and enforce criteria for reassociating digital assets. Additionally, techniques described and suggested in the present disclosure may improve the functionality of blockchain networks by enabling blockchain transactions to function as state machines to enable computer program functionality to be dependent upon states recorded in such state machines.

Moreover, techniques described and suggested in the present disclosure may be necessarily rooted in computer technology in order to overcome problems specifically arising with blockchain technologies (such as Bitcoin's Script) which have been specifically designed to restrict functionality for security reasons. For example, Script does not natively support complex flow control functionality, for example, loops to occur. One advantage of this restriction is that the programs have predictable execution times. Another significant advantage of limiting scripts to linear or tree-like decision tasks is that this avoids infinite loops, which can be used as a means of launching exploits such as a denial of service (DoS or DDoS) attack. Thus, the security of blockchain transfer/exchange is enhanced and preserved but mechanisms need to be found to implement the functionality that is not permitted or provided by the language itself. The present invention provides an advance in this respect, addressing the current limitations of blockchain transactions at least in part, with an implementation of self-replicating and self-referencing blockchain transaction locking scripts. Thus, the invention provides a technical solution to a technical problem, and offers advantages in respect of security, improved control of digital assets exchange/transfer via a blockchain, and an extension of current blockchain-related functionality.

Therefore, in accordance with the invention there may be provided a computer-implemented method (and corresponding system(s)) as defined in the appended claims. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: i) receiving, at a node in a blockchain network, a first transaction to transfer control of a digital asset, the first transaction including a first script that at least: includes a set of field values of the first transaction; and as a result of being executed, causes 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 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 supplied as a result of execution of the first script; and iii) validating the first transaction by executing the first script and the second script.

Validating the first transaction may be successfully performed without verifying that an entity that created the first transaction has access to secret information.

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 generate the signature based at least in part on the private cryptographic key and a mask number. Additionally, or alternatively, validating the first transaction may further include validating that the signature is associated with a public cryptographic key of the asymmetric key pair.

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.

The signature hash type may be a value that indicates which field values of the set of field values of the first transaction are to be included in the signature.

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

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

The digital asset may be associated with an unspent transaction output in the blockchain network.

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

The blockchain network may be comprised of distributed electronic devices running an instance of a blockchain protocol.

The first script and second script may be written using a Turing incomplete instruction set.

The first script and second script are written using a Turing complete instruction set.

The first script, by including the set of fields, may cause the node, as a result of execution of the first script, to make the set of fields available as input to the second script.

It is also desirable to provide a system comprising: a processor; and memory including executable instructions that, as a result of execution by the processor, causes the system to perform any of the methods as claimed.

Therefore, in accordance with the invention there may be provided a computer-implemented method (and corresponding system(s)) as defined in the appended claims. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: i) receiving, at a node in a blockchain network, a first transaction to transfer control of a digital asset, the first transaction including a first script that, as a result of being executed, causes the node to at least: obtain a first set of field values corresponding to the first transaction; and obtain 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 that, as a result of being executed, causes the node to at least: obtain the first set of field values and the second set of field values of the particular transaction supplied as a result of execution of the first script; extract a transaction identifier from the first set of field values; and determine, based at least in part on the second set of field values, that the particular transaction corresponds to the transaction identifier; and iii) validating the first transaction by executing the first script and the second script.

The second set of field values may be in a canonicalized format.

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

The particular transaction may be associated with the control of the digital asset being transferred.

The particular transaction may be associated with a second digital asset different from the digital asset being transferred.

Validating the first transaction may succeed without verifying that an entity that created the first transaction has access to secret information.

The node may be a validation node of the blockchain network.

Validating the first transaction may further include, as a result of successful validation of the first transaction, adding the first transaction to a blockchain in the blockchain network.

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

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

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

The second script, may further as a result of being executed, cause the node to determine, based at least in part on the signature hash type, that the particular transaction is a member of a set of transactions associated with the first transaction.

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

Therefore, in accordance with the invention there may be provided a computer-implemented method (and corresponding system(s)) as defined in the appended claims. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: i) receiving, at a node in a blockchain network, a first transaction to transfer control of a digital asset, the first transaction including a first script that includes at least: a first value, at least a portion of the first value including data that is unconstrained by a second script; and a second value; ii) obtaining a second transaction, the second transaction being associated with the digital asset and including the second script that, as a result of being executed, causes the node to at least: obtain the first value and the second value as a result of execution of the first script; and validate, based at least in part on first value and the second value, that the data is associated with a particular source; and iii) validating the first transaction by executing the first script and the second script.

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

Validating the first transaction may be performed without verifying that an entity that created the first transaction has access to secret information.

Unsuccessful validation that the data is associated with the data source may cause validating the first transaction to be unsuccessful.

An identity of the particular source may be unconstrained by the second script.

A particular transaction may be the particular source of the data. Additionally, or alternatively, the first value may be a set of field values of the particular transaction. Additionally, or alternatively, the second value may include a transaction identifier associated with the particular transaction. The second script may validate that the data is associated with the data source by validating that the particular transaction corresponds to the transaction identifier.

The second script may validate that the particular transaction corresponds to the transaction identifier by validating that the transaction identifier matches a hash of the set of fields of the particular transaction.

The first script, by including the set of fields of the particular transaction, may cause the node, as a result of execution of the first script, to make the set of fields of the particular transaction available as input to the second script.

The particular transaction may be the second transaction.

The data may be encoded in a field of the particular transaction.

The second script may constrain an identity of the particular source.

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

The modified public key may be generated by performing elliptic curve point multiplication on the public key by a value of the data.

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 perform any of the methods as claimed. Therefore, in accordance with the invention there may be provided a computer-implemented method (and corresponding system(s)) as defined in the appended claims. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: i) receiving, at a node in a blockchain network, a first transaction to transfer control of a digital asset, the first transaction including a first script that, as a result of being executed, causes the node to at least obtain data and a first set of field values of the first transaction; ii) obtaining a second transaction, the second transaction including a second script that, as a result of being executed, causes the node to at least: determine, based at least in part on the data supplied as a result of execution of the first script, a set of constraints; and verify, based at least in part on the first set of field values, the set of constraints against the first transaction; 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.

Transferring control of the digital asset may be performed without verifying that an entity that created the first transaction has access to secret information.

An identity of a source of the data may be unconstrained by the second script.

The second script may constrain an identity of a source of the data.

The second script may include a public key of a particular data source usable to validate the data.

Validating the data may include generating, based at least in part on the public key and the data, a modified public key and, additionally or alternatively, determining that the data is associated with a data source based at least in part on the modified public key.

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

Fulfilment of the set of constraints may be a condition for reassociating of at least the portion of the digital asset.

Transferring control of the digital asset may include reassociating the digital asset from a first entity to a second entity.

An identity of the second entity may be determined based at least in part on the set of constraints.

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

An identity of the second entity may be determined based at least in part on the set of constraints.

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

Therefore, in accordance with the invention there may be provided a computer-implemented method (and corresponding system(s)) as defined in the appended claims. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: i) receiving, at a node in a blockchain network, a first transaction to transfer control of a digital asset, the first transaction including a first script that, as a result of being executed, causes the node to at least: obtain a first set of field values of the first transaction, the first set of field values including a third script; and 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 a second script that, as a result of being executed, causes the node to, as a result of determining that a termination condition is unfulfilled, at least: obtain the third script from the first set of field values; and determine that the 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.

The second transaction may be a transaction associated with the digital asset. Additionally, or alternatively, the first transaction may be a transaction is a transaction to reassociate at least the portion of the digital asset from a first entity to a second entity.

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

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

The third script may be a locking script that imposes the set of conditions for validation of a future transaction.

Transferring control of the digital asset may include reassociating the digital asset from a first entity to a second entity.

Determining that a termination condition is unfulfilled may include determining that an amount of the digital asset associated with the second transaction is sufficient to reassociate at least the portion of the digital asset.

The third script may be embedded in a field value of the first set of field values.

The blockchain network may be comprised of distributed electronic devices running an instance of a blockchain protocol.

Transferring control of the digital asset may be performed without verifying that an entity that created the first transaction has access to a secret information.

The second script may further cause the node to verify, as a further condition for transferring control of the digital asset, that the first transaction meets an additional constraint.

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

The set of repeating smart contracts may be terminated by the termination condition.

Therefore, in accordance with the invention there may be provided a computer-implemented method (and corresponding system(s)) as defined in the appended claims. The computer-implemented method may be described as a blockchain data constraint method. The computer-implemented method may include: A computer-implemented method, comprising: i) receiving, at a node in a blockchain network, a first transaction to transfer control of a digital asset, the first transaction including a first script that, as a result of being executed, causes the node to at least obtain 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 the second transaction, the second transaction including a second script that includes a set of rules, the second script, as a result of being executed, causing the node to at least: verify that the second script matches a third script embedded in the first set of field values; determine, based at least in part on the second set of field values, a current state; and determine, based at least in part on the current state, the input, and the set of rules, a next state; 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.

The second script may constrain an identity of a source of the input.

Any of the methods as claimed may further comprise verifying a cryptographic secret of a source of the input.

The set of rules may be a state-transition matrix.

The third script may be a locking script that imposes a set of conditions for validation of a future transaction.

The second script may further cause the node to determine that a termination condition is unfulfilled.

The input may be embedded in the second set of field values.

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

The current state may indicate a state of the second transaction.

The next state may indicate a state of the first transaction upon validation.

Any of the methods as claimed may further comprise receiving a third transaction. Additionally, or alternatively, any of the methods as claimed may further comprise obtaining a fourth script from the first transaction, the fourth script, as a result of being executed, causing the node to determine, based at least in part on the next state, a second input, and the set of rules, another state different from the next state and the current state.

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

Transferring control of the digital asset may include reassociating the digital asset from a first entity to a second entity.

Therefore, in accordance with the invention there may be provided a method (and corresponding system(s)) as defined in the appended claims. The method may be described as a blockchain data constraint method. The method may include: i) receiving, at a node in a blockchain network, a first transaction to validate, the first transaction including a first script that at least: includes a set of field values of the first transaction; and as a result of being executed, causes the node to obtain the set of field values; ii) obtaining a second transaction, the second transaction having been validated and including a second script 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 supplied as a result of execution of the first script; and iii) validating the first transaction by executing the first script and the second script.

Validating the first transaction may be successfully performed without verifying that an entity that created the first transaction has access to secret information.

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.

The signature hash type may be a value that indicates which field values of the set of field values of the first transaction are to be included in the signature.

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

Validating the first transaction may cause the transfer of an unspent transaction output.

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

The blockchain network may be comprised of distributed electronic devices running an instance of a blockchain protocol.

The first script and second script may be written using a Turing incomplete instruction set.

The first script and second script are written using a Turing complete instruction set.

The first script, by including the set of fields, may cause the node, as a result of execution of the first script, to make the set of fields available as input to the second script.

Therefore, in accordance with the invention there may be provided a method (and corresponding system(s)) as defined in the appended claims. The method may be described as a blockchain data constraint method. The method may include: i) receiving, at a node in a blockchain network, a first transaction to validate, the first transaction including a first script that, as a result of being executed, causes the node to at least: obtain a first set of field values corresponding to the first transaction; and obtain a second set of field values corresponding to a particular transaction; ii) obtaining a second transaction, the second transaction having been validated and including a second script that, as a result of being executed, causes the node to at least: obtain the first set of field values and the second set of field values of the particular transaction supplied as a result of execution of the first script; extract a transaction identifier from the first set of field values; and determine, based at least in part on the second set of field values, that the particular transaction corresponds to the transaction identifier; and iii) validating the first transaction by executing the first script and the second script.

The second set of field values may be in a canonicalized format.

The particular transaction may be associated with control of a digital asset transferred as a result of validating the first transaction.

The particular transaction may be associated with a second digital asset different from a digital asset being transferred as a result of validating the first transaction.

Validating the first transaction may succeed without verifying that an entity that created the first transaction has access to secret information.

The node may be a validation node of the blockchain network.

Validating the first transaction may further include, as a result of successful validation of the first transaction, adding the first transaction to a blockchain in the blockchain network.

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

Therefore, in accordance with the invention there may be provided a method (and corresponding system(s)) as defined in the appended claims. The method may be described as a blockchain data constraint method. The method may include: i) receiving, at a node in a blockchain network, a first transaction to validate, the first transaction including a first script that includes at least: a first value, at least a portion of the first value including data that is unconstrained by a second script; and a second value; ii) obtaining a second transaction, the second transaction having been validated and including the second script that, as a result of being executed, causes the node to at least: obtain the first value and the second value as a result of execution of the first script; and validate, based at least in part on first value and the second value, that the data is associated with a particular source; and iii) validating the first transaction by executing the first script and the second script.

Validating the first transaction may be performed without verifying that an entity that created the first transaction has access to secret information.

Unsuccessful validation that the data is associated with the data source may cause validating the first transaction to be unsuccessful.

An identity of the particular source may be unconstrained by the second script.

A particular transaction may be the particular source of the data. Additionally, or alternatively, the first value may be a set of field values of the particular transaction. Additionally, or alternatively, the second value may include a transaction identifier associated with the particular transaction. The second script, as a result of being executed, may validate that the data is associated with the data source by validating that the particular transaction corresponds to the transaction identifier.

The second script, as a result of being executed, may validate that the particular transaction corresponds to the transaction identifier by validating that the transaction identifier matches a hash of the set of fields of the particular transaction.

The particular transaction may be the second transaction.

The data may be encoded in a field of the particular transaction.

The second script may constrain an identity of the particular source.

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

The modified public key may be generated by performing elliptic curve point multiplication on the public key by a value of the data.

Therefore, in accordance with the invention there may be provided a method (and corresponding system(s)) as defined in the appended claims. The method may be described as a blockchain data constraint method. The method may include: i) receiving, at a node in a blockchain network, a first transaction to validate, the first transaction including a first script that, as a result of being executed, causes the node to at least obtain data and a first set of field values of the first transaction; ii) obtaining a second transaction, the second transaction including a second script that, as a result of being executed, causes the node to at least: determine, based at least in part on the data supplied as a result of execution of the first script, a set of constraints; and verify, based at least in part on the first set of field values, the set of constraints against the first transaction; and iii) validating the first transaction according to the set of constraints as a result of execution of the first script and the second script.

Validating the first transaction may be performed without verifying that an entity that created the first transaction has access to secret information.

An identity of a source of the data may be unconstrained by the second script.

The second script may constrain an identity of a source of the data.

The second script may include a public key of a particular data source usable to validate the data.

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

Fulfilment of the set of constraints may be a condition for reassociating of at least a portion of a digital asset.

Validating the first transaction may include reassociating the digital asset from a first entity to a second entity.

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

An identity of the second entity may be determined based at least in part on the set of constraints.

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

Therefore, in accordance with the invention there may be provided a method (and corresponding system(s)) as defined in the appended claims. The method may be described as a blockchain data constraint method. The method may include: i) receiving, at a node in a blockchain network, a first transaction to validate, the first transaction including a first script that, as a result of being executed, causes the node to at least: obtain a first set of field values of the first transaction, the first set of field values including a third script; and 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 a second script that, as a result of being executed, causes the node to, as a result of determining that a termination condition is unfulfilled, at least: obtain the third script from the first set of field values; and determine that the copy of the second script matches the third script; and iii) validating the first transaction as a result of execution of the first script and the second script.

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

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

The third script may be a locking script that imposes the set of conditions for validation of a future transaction.

Validating the first transaction may include reassociating a digital asset from a first entity to a second entity.

Determining that a termination condition is unfulfilled may include determining that an amount of a digital asset associated with the second transaction is sufficient to reassociate at least a portion of the digital asset.

The third script may be embedded in a field value of the first set of field values.

The blockchain network may be comprised of distributed electronic devices running an instance of a blockchain protocol.

Validating the first transaction may be performed without verifying that an entity that created the first transaction has access to a secret information.

The second script may further cause the node to verify, as a further condition for validating the first transaction, that the first transaction meets an additional constraint.

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

The set of repeating smart contracts may be terminated by the termination condition.

Therefore, in accordance with the invention there may be provided a method (and corresponding system(s)) as defined in the appended claims. The method may be described as a blockchain data constraint method. The method may include: i) receiving, at a node in a blockchain network, a first transaction to validate, the first transaction including a first script that, as a result of being executed, causes the node to at least obtain 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 the second transaction, the second transaction including a second script that includes a set of rules, the second script, as a result of being executed, causing the node to at least: verify that the second script matches a third script embedded in the first set of field values; determine, based at least in part on the second set of field values, a current state; and determine, based at least in part on the current state, the input, and the set of rules, a next state; verify that the next state is included in the first set of field values; and iii) validating the first transaction as a result of execution of the first script and the second script.