Securing blockchain transactions based on pending data

Abstract

To provide computer-implemented methods for locking a blockchain transaction based on undetermined data.SOLUTION: A locking node may include a locking script in a blockchain transaction to lock a digital asset. The locking script includes a public key for a determined data source and instructions to cause a validating node executing the locking script to verify the source of data provided in an unlocking script by: a) generating a modified public key based on the public key for the determined data source and based on data defined in the unlocking script; and b) evaluating a cryptographic signature in the unlocking script based on the modified public key. The blockchain transaction containing the locking script is sent by the locking node to a blockchain network.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates generally to digital locks, and more particularly to a method and system for locking digital assets based on pending data from a particular data source. The present invention is particularly suited for, but not limited to, application to provide conditional unlocking of digital assets on a blockchain network based on data that is unavailable to the locking party at the time the digital assets are locked.

[0002] This document uses the term "blockchain" to include all forms of electronic, computer-based distributed ledgers. These forms include, but are not limited to, blockchain and transaction chain technology, permissioned and non-permissioned ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. Although reference is made herein to Bitcoin for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention. For example, the present invention may be useful in other blockchain implementations that have similar limitations in signature verification as Bitcoin.

[0003] A blockchain is a consensus-based electronic ledger implemented as a computer-based decentralized system composed of blocks, which consist of transactions and other information. In the case of Bitcoin, each transaction that transfers control of digital assets between participants in the blockchain system contains at least one input and at least one output. These blocks are chained together because each block contains a hash of the previous block, creating a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs known as scripts embedded in their inputs and outputs, which specify who can access the transaction's outputs and how. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] In order for a transaction to be written to the blockchain, it must be "validated". Validation is determined by the nodes based on a common set of rules used by the majority of nodes with block production capabilities. For example, in the Bitcoin protocol, some network nodes act as miners and work to ensure that each transaction is valid, and invalid transactions are rejected from the network. For example, a software client installed on the node performs this validation work on transactions that reference unspent transaction outputs (UTXOs). Validation can be done by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE and certain other conditions are met, the transaction is valid and can be written to the blockchain. Thus, in order for a transaction to be written to the blockchain, it must be i) verified by the node that receives the transaction (when a transaction is validated, the node relays the verified transaction to other nodes in the network); ii) added to a new block constructed by miners; and iii) mined, i.e., added to the public ledger of past transactions. A transaction is considered confirmed when a sufficient number of blocks have been added to the blockchain to make the transaction effectively irreversible.

[0005] The transaction output includes a digital asset, such as Bitcoin, and a locking script, which may also be referred to as an encumbrance or lock. The locking script locks the digital asset by specifying conditions that must be met in order to spend the output. For example, the locking script may require that certain data be provided to an unlocking script in order to unlock the associated digital asset. Traditional approaches that require the locking party to provide data to unlock a digital asset require embedding a hash of the data within the locking script. However, this approach to locking and unlocking requires that the data be determined (i.e., known and fixed) when the locking script is created.

[0006] It would thus be desirable to provide improved methods and apparatus that improve blockchain technology in one or more of these aspects. Summary of the Invention

[0007] Thus, according to the present invention there is provided a method as defined in the accompanying claims.

[0008] As described in more detail below, a computer-implemented method and electronic device are configured to lock a transaction based on pending data.

[0009] Thus, according to the present invention, a computer-implemented method (and corresponding system) may be provided. The method may be described as a security and / or control method. The method may be configured to control who and / or how the output of a blockchain transaction (TX) can be unlocked and spent via the blockchain network. The use (spending) of the output allows for the transfer of cryptocurrency. The present invention may provide a method (and corresponding system) configured to amend a cryptographic public key embedded in a locking script of a blockchain transaction (Tx) with pending data provided in an unlocking script of another transaction. The present invention allows for securing blockchain transactions based on pending data. That is, the present invention allows for locking blockchain transactions based on data that is not available at the time the lock is applied to the blockchain transaction, but is expected to become available in the future.

[0010] A method according to one embodiment of the present invention comprises: i) a node in a blockchain network including in a transaction (i.e., a blockchain transaction) a locking script to encumber (i.e., lock) a digital asset associated with the transaction (i.e., the blockchain transaction), the locking script including a public key of a particular data source and including instructions to cause a validating node executing the locking script to verify the source of the data provided in the unlocking script by a) generating a modified public key based on the public key of the particular data source and data specified in the unlocking script, and b) evaluating a signature (i.e., a cryptographic signature) in the unlocking script based on the modified public key; ii) the node sending the transaction (i.e., the blockchain transaction) to the blockchain network.

[0011] In some embodiments, the locking script further defines one or more data constraints, and the locking script further includes instructions that cause the validator node to invalidate a transaction (i.e., a blockchain transaction) that includes the unlocking script if the one or more data constraints are not satisfied by the data. In some embodiments, the one or more data constraints define one or more values ​​and a comparison function that performs a comparison based on the data and the one or more values.

[0012] In some embodiments, the instructions that cause the validating node to evaluate a signature (i.e., a cryptographic signature) in the unlocking script based on the modified public key are configured to cause the validating node to invalidate a transaction (i.e., a blockchain transaction) that includes the unlocking script if the signature (i.e., the cryptographic signature) was not generated using a modified private key associated with the particular data source. The modified private key may be generated by the particular data source based on the private key and data of the particular data source.

[0013] In some embodiments, the locking script is configured to cause the validating node to generate the modified public key by performing operations that correspond to the operations used to generate the modified private key.

[0014] In some embodiments, the modified private key is a key generated by performing finite field arithmetic operations on the data and the private key of a particular data source.

[0015] In some embodiments, the instructions are configured to cause a validating node executing the lock script to generate a modified public key by performing an elliptic curve finite field arithmetic operation based on the data and the public key of the particular data source. In some embodiments, the elliptic curve finite field arithmetic operation performs an elliptic curve multiplication by a scalar.

[0016] In some embodiments, the locking script is further configured to include instructions for the release of the restriction (i.e., locking) of the digital assets by the node after a defined period of time.

[0017] According to the present invention there is provided a computer implemented method comprising: a) a node generating a modified private key based on the data and the private key; b) using the modified private key to generate a signature (i.e., a cryptographic signature) for a transaction that references a digital asset restricted (i.e., locked) by the locking script; c) adding a (cryptographic) signature and data to the (blockchain) transaction; d) communicating the (blockchain) transaction to another node.

[0018] In some implementations, generating the modified private key comprises performing a finite field arithmetic operation on the data and the private key. In some implementations, the finite field arithmetic operation performs a multiplication.

[0019] In some embodiments, the locking script specifies a public key for a particular data source and includes instructions to cause a validating node executing the locking script to evaluate the source of the data provided in the unlocking script by a) generating a modified public key based on the public key of the particular data source and data specified in the unlocking script, and b) evaluating the signature (i.e., a cryptographic signature) in the unlocking script based on the modified public key.

[0020] According to the present invention, there is provided an electronic device including an interface device, a processor coupled to the interface device, and a memory coupled to the processor, the memory storing computer executable instructions that, when executed, cause the processor to perform the methods described herein.

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

[0022] In accordance with the present invention, a computer readable storage medium may be provided that includes a locking script, the locking script including computer executable instructions that, when executed, cause a processor to perform the functions of the locking script described herein.

[0023] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings. [Brief description of the drawings]

[0024] [Figure 1] FIG. 1 is a block diagram of an exemplary blockchain network. [Diagram 2] FIG. 1 is a block diagram of an exemplary electronic device that may function as a node in a blockchain network. [Diagram 3] 1 is a flowchart of an exemplary method for setting up a transaction using a lock script. [Figure 4] 1 is a flowchart of an exemplary method for configuring a proposed transaction with a required signature for a lock script. [Diagram 5] 1 is a flowchart of an exemplary method for validating a transaction associated with a digital asset locked by a locking script. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] Referring initially to FIG 1, this figure illustrates in block diagram form an example blockchain network 100 associated with a blockchain. Distributed electronic devices running an instance of a blockchain protocol under the operation of the blockchain network 100 may participate in the blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be, for example, the Bitcoin protocol.

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

[0027] The nodes 102 of the blockchain network 100 are coupled to one another using suitable communication technologies, which may include wired and wireless communication technologies. Such communications adhere to a protocol associated with the blockchain. For example, the Bitcoin protocol may be used if the blockchain is the Bitcoin blockchain.

[0028] Nodes 102 maintain a global ledger of all transactions on the blockchain. Thus, the global ledger is a distributed ledger. Each node 102 may store a full or partial copy of the global ledger. Transactions by nodes 102 that affect the global ledger are verified by other nodes 102, thereby maintaining the validity of the global ledger. If the blockchain is a proof of work based blockchain, blocks are also verified by checking the proof of work sent with the block.

[0029] At least some of the nodes 102 act as miners 104 of the blockchain network 100. The blockchain of FIG. 1 is a proof-of-work blockchain in which miners 104 perform costly computations to facilitate transactions on the blockchain. For example, a proof-of-work blockchain may require miners to solve a cryptographic problem. In Bitcoin, miners 104 double hash the block header with SHA-256 to find a nonce that is a number less than a value dictated by the current difficulty. The hashing power required for a proof-of-work algorithm means that a transaction is considered effectively irreversible after a certain number of blocks have been mined on it. A miner 104 who solves the cryptographic problem creates a new block in the blockchain and broadcasts this new block to the other nodes 102. The other nodes 102 verify that the miner 104 has indeed solved the cryptographic problem and therefore demonstrated sufficient proof-of-work before accepting the block for addition to the blockchain. Other nodes 102 also verify that the block itself is valid (e.g., that the transactions and block header of the block are valid) before accepting the block for addition to the blockchain. Blocks are added to the blockchain (i.e., the global distributed ledger) by consensus of nodes 102.

[0030] Blocks created by miners 104 include transactions broadcast to the blockchain by nodes 102. For example, a block may include a transaction from an address associated with one node 102 to an address associated with another node 102. In this way, a block serves as a record of transactions from one address to another. A party requesting that a transaction be included in a block proves that it has the authority to initiate a transfer (e.g., in the case of Bitcoin, to spend Bitcoin) by signing the request with a private key that corresponds to the public key. Only if the request is validly signed is the transfer added to the block.

[0031] In the case of Bitcoin, there is a one-to-one correspondence between public keys and addresses: each public key is associated with a single address. Thus, references herein to transferring digital assets to or from a public key (e.g., paying a public key) and to transferring digital assets to or from an address associated with that public key refer to general actions.

[0032] Some of the nodes 102 may not act as miners, but instead participate as validating nodes. Validating a transaction may include verifying the signature (which may also be referred to herein as a cryptographic signature) or other conditions specified in the locking script, verifying references to valid UTXOs, etc.

[0033] The example of FIG. 1 includes six nodes 102, two of which participate as miners 104. In practice, the number of nodes 102 or miners 104 may be different. In many blockchain networks, the number of nodes 102 and miners 104 may be much higher than the number shown in FIG. 1.

[0034] 2 is a block diagram illustrating components of an exemplary electronic device 200 that may function as a node 102 (FIG. 1) in a peer-to-peer blockchain network 100 (FIG. 1). The exemplary electronic device 200 may also be referred to as a processing device. The electronic device may take a variety of forms including, for example, a desktop computer, a laptop computer, a tablet computer, a server, a mobile device such as a smartphone, a wearable computer such as a smart watch, or another type of form.

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

[0036] Memory 220 may store the global ledger of blockchain network 100 (FIG. 1), or a portion thereof. That is, memory 220 may store all the blocks of the blockchain, or a portion of the blocks, such as the most recent blocks, or a portion of the information in some blocks.

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

[0038] The present invention may provide a method (and corresponding system) configured to modify a cryptographic public key embedded in a locking script of a blockchain transaction (Tx) using pending data provided in an unlocking script of another transaction. When used in combination with a signature check opcode (opcode) in, for example, the Bitcoin protocol that uses transaction bytecodes as messages (e.g., OP_CHECKSIG, etc.), both the transaction and the data require approval or authorization from the owner of the public key, thereby protecting them from alteration. Thus, the present invention provides advantages in terms of security, encryption, authorization, and transfer control.

[0039] Referring now to FIG. 3, a method 300 for locking digital assets on a blockchain network is shown. Method 300 may be executed by a node 102 of a blockchain network 100 (FIG. 1) to lock digital assets based on secure pending data. The data is pending in that the node setting the lock does not need to know the data at the time the lock is set, and the data is secure in that the lock is set such that modification of the data by an unauthorized party will invalidate the transaction. For ease of reference, a node 102 that executes method 300 may be referred to herein as a locking node. A locking node may be configured with processor-executable instructions that, when executed by a processor of the locking node, execute method 300.

[0040] Thus, the pending data used to lock a digital asset may be data that is not yet known to the locking node at the time of locking. This data may be data that has not yet been established (such as data that is to be created in the future but has not yet been created), or data that is known to another node but is not yet available to the locking node. However, the data is data that is expected to be available (now or in the future) from a determined data source. The data source is determined such that the identity of the data source is known at the time the locking script is generated. In some embodiments where the locking script is configured to depend on data from a single data source (as opposed to an embodiment where the locking script accepts data from multiple data sources and determines which data source to depend on), the data source may be referred to as an authoritative data source.

[0041] Method 300 includes, at operation 302, preparing a locking script for locking a digital asset based on pending data. A locking script is a restriction in the form of computer executable code or instructions placed on an output of a transaction that specifies conditions that must be met in order to spend the output in the future. More specifically, the locking script is configured to receive data from an unlocking script and perform certain actions based on the data such that a validating node can determine whether the unlocking script successfully unlocks the locking script.

[0042] The lock script may specify one or more data constraints. A data constraint is a requirement that the data provided in the unlock script must meet in order for the lock script to evaluate successfully (e.g., evaluate as TRUE in the case of Bitcoin). Thus, in operation 302, the lock script may be configured to include instructions that cause a validator node executing the lock script to evaluate the data provided in the unlock script against the data constraints. The data constraints of the lock script may specify thresholds or values ​​and the required relationship between the data and the specified values ​​or thresholds. A comparison function may be used to cause a validator node executing the lock script based on the data provided in the unlock script to make a comparison based on the data and one or more values. By way of example, a data constraint may require that the data be equal to a value specified in the lock script, greater than a value specified in the lock script, less than a value specified in the lock script, not equal to a value specified in the lock script, etc. Many other possible data constraints may also be specified.

[0043] As an example, in Bitcoin, below are some examples of possible instruction codes that may be included in the data constraint portion of a lock script to ensure that data meets certain conditions: Note that other operations are possible and the script may modify the data in some way (e.g., multiplication, subtraction, division, addition, or another operation) before using one of the comparison functions below. · OP_GREATERTHAN: This returns a value of TRUE if the second item in the stack is greater than the top item on the stack. · OP_LESSTHANOREQUAL: This returns a value of TRUE if the second item in the stack is less than or equal to the top item. · OP_GREATERTHANOREQUAL: This returns a value of TRUE if the second item in the stack is greater than or equal to the top item. · OP_WITHIN: This returns a value of TRUE if the third item in the stack is between the second and first items. · OP_NUMEQUAL: This returns a value of TRUE if the top items in the stack have the same number. · OP_NUMNOTEQUAL: This returns a value of TRUE if the top two items do not have the same number. · OP_LESSTHAN: This returns a value of TRUE if the second item in the stack is less than the top item.

[0044] A lock script may also contain instructions such as a verify function that invalidates a transaction that includes an unlock script intended to unlock the lock script if the data constraints are not satisfied by the data. As an example, if the blockchain network is Bitcoin, an OP_VERIFY opcode may be included after the compare function. The OP_VERIFY code checks the top of the stack and stops and invalidates the transaction if the value at the top of the stack is not TRUE.

[0045] Thus, in at least some embodiments, the data constraint portion of a lock script may be of the following form: <Script to check constraints>OP_VERIFY Here, <script that checks constraints> is a script that evaluates whether the data in the unlock script satisfies one or more specified constraints and returns TRUE or FALSE based on such evaluation.

[0046] A locking script may also include computer-executable instructions that cause a validating node executing the locking script to evaluate the source of the data. For example, a locking script may require that data be provided by a particular data source, such as a particular node, that has not been tampered with by other nodes. That is, the locking script is configured such that such tampering invalidates any transaction that purports to unlock the locking script.

[0047] The locking script causes a validating node that executes the locking script to use elliptic curve finite field arithmetic to validate the source of the data (the source of the data provided in the unlocking script that is intended to unlock the locking script). More specifically, the locking script can be configured to cause the node, when executed, to perform elliptic curve finite field arithmetic based on the public key of the particular data source and the data included in the locking script by the locking node. That is, the locking script can be configured to cause the node that executes the locking script to generate a modified public key for the particular data source based on the public key of the particular data source specified in the locking script and the data specified in the unlocking script. The modified public key is determined by performing elliptic curve finite field arithmetic based on the public key of the particular data source embedded in the locking script and the data provided in the unlocking script. The modified public key can also be determined using multiple operations (e.g., data x data x public key, etc.).

[0048] To unlock the lock script, a particular data source must obtain a modified private key by performing finite field arithmetic operations on the data source's private key and the data. More specifically, the operations performed on the private key correspond to the operations the lock script is configured to perform on the public key. As with the public key, multiple operations may be performed on the private key to obtain the modified private key (e.g., data x data x private key). The modified private key is used by the particular data source to generate a signature that can be included in the unlock script. This signature may be referred to herein as a signature from a modified private key.

[0049] To understand how similarly modifying the private and public keys with the data allows for verification of the source of the data, it is helpful to consider the relationship between private and public keys. More specifically, an elliptic curve public key is calculated as follows: D = d × G where d is the private key, D is the corresponding public key, and G is an elliptic curve finite field generator element.

[0050] The relationship between the private and public keys requires that when a change is made to the public key with the data, a corresponding change must be made to the private key. Any number of methods can be used to modify the private and public keys with the data, as long as the operations can be decomposed into finite field additions.

[0051] As an example, if d is the original private key, d' is the modified private key, D is the original public key, and D' is the modified public key, then the modified public key and the modified private key may be determined as follows (data is data): d' = d × data D'=d'×G=d×data×G=data×D Alternatively, the modified public key and the modified private key may be determined as follows: d'=d+data D'=d'×G=(d+data)×G=D+DATA where DATA is an elliptic curve point.

[0052] Although some existing blockchain networks may not include specific opcodes for performing elliptic curve finite field arithmetic operations, opcodes may be provided in a protocol that controls the operation of the blockchain network 100 (FIG. 1) to provide such operations. As an example, an opcode OP_ECPMULT may be defined that takes an encoded elliptic curve point and a number, and performs an elliptic curve multiplication by a scalar. This opcode outputs the result as an encoded elliptic curve point.

[0053] To perform elliptic curve finite field arithmetic, two specific elliptic curve operations can be used: Adding a point (P+Q) is used to calculate a new point on the elliptic curve as the negation of the intersection of this curve. This can be explained as R=P+Q. Point doubling (P+P) uses point addition to calculate P times the points. This can be written as R=P+P=2P.

[0054] These operations can be expressed as follows: x3=s 2 -x1-x2mod p y3=s(x1-x3)-y1mod p Where:

number

[0055] Thus, the lock script prepared in operation 302 of method 300 may be configured to cause a validating node executing the lock script to verify whether the data provided in the corresponding unlock script was provided by a particular data source by obtaining the modified public key of the data source using the techniques described above. The lock script may be configured to cause the validating node to evaluate a signature from the modified private key (i.e., a signature generated from the modified private key based on the data). More specifically, the lock script may include a signature verification opcode that verifies whether the signature from the modified private key corresponds to the modified public key and is therefore a valid signature. As an example, the OP_CHECKSIG opcode may be used. OP_CHECKSIG pops the public key and signature from the stack and verifies the signature of the transaction hash data. If the values ​​match, OP_CHECKSIG returns TRUE. Thus, instructions in the locking script that configure a validating node to evaluate a signature in the unlocking script based on a modified public key can be configured to cause the validating node to invalidate a transaction that includes the unlocking script if the signature contained in the unlocking script was not generated using a modified private key associated with a particular data source, i.e., a transaction that includes an purported unlocking script will be invalidated by the validating node if the signature was not generated with a modified private key generated by a particular data source based on the private key and data of the particular data source.

[0056] As an example, OP_CHECKSIG can be used with elliptic curve finite field arithmetic in a lock script as follows: <Public Key D> OP_ECPMULT OP_CHECKSIG Here, public key D is the public key of the particular data source providing the data.

[0057] Below is the corresponding portion of the unlock script that successfully verifies this portion of the lock script: <Sig’> <data> Where: <data>is the data,<Sig’> is the signature produced by a modified private key (i.e., the private key modified based on the data).

[0058] The order of the data constraint portion of the lock script and the data source check portion of the lock script can be reversed. For example, a lock script might first have a validating node verify that data was provided by a particular data source before considering whether the data satisfies the data constraints.

[0059] A locking script may include other locking features in addition to those listed above. For example, a locking script may also require an additional signature from another node. For example, a locking script may require that the recipient of the transaction (i.e., the party receiving the digital assets associated with the transaction) submit a valid signature to unlock the locking script. For example, a locking script may include the following: <Public Key B>OP_CHECKSIG Here, public key B is the public key of a node that is the recipient of the digital asset restricted by the locking script.

[0060] Additionally, a locking script may be configured to require the addition of a signature associated with the locking node itself before the locking script is verified as TRUE, ensuring that the digital asset is no longer restricted by the locking script. For example, a locking script may include the following: <Public Key A>OP_CHECKSIGVERIFY where public key A is the public key of the node that is the recipient of the digital asset restricted by the lock script. OP_CHECKSIGVERIFY behaves similarly to OP_CHECKSIG, except that OP_CHECKSIGVERIFY stops using OP_VERIFY if OP_CHECKSIG does not evaluate to TRUE.

[0061] Additionally, the locking script prepared in operation 302 may be configured to include instructions for lifting the restrictions placed on the digital assets by the locking script after a prescribed period of time. That is, the locking script may be configured to include one or more conditions that allow the locking party to reclaim the digital assets under certain conditions. For example, the locking script may allow the locking node to reclaim the digital assets if the data, once determined, fails to meet the data constraints required by the locking script. For example, the locking script may be configured to allow the locking node (or other parties specified by the public key) to claim the digital assets after a period of time specified in the locking script has elapsed, if such digital assets have not been claimed by others during this period of time.

[0062] As an example, a lock script might contain conditional branches that include: <Time limit>OP_CHECKSEQUENCEVERIFY <Public Key A>OP_CHECKSIG where <time limit> is a period embedded in the locking script, and OP_CHECKSEQUENCEVERIFY is an opcode that allows execution of a particular pathway only if the output being used is at least as old as the specified period. For example, if <time limit> is set to 10 days, a locking node (with a private key corresponding to public key <PubKey A>) can retrieve the output after 10 days by providing a signature signed with the locking node's private key.

[0063] Thus, a locking script may contain many conditions that must be met before it can be unlocked. Locking scripts can take many forms, but here are some examples of scripts you can use: OP_IF <pubkeya>OP_CHECKSIGVERIFY OP_DUP <90> OP_GREATERTHAN OP_VERIFY <pubkeyc>OP_ECPMULT OP_CHECKSIGVERIFY <pubkeyb>OP_CHECKSIG OP_ELSE <10days>OP_CHECKSEQUENCEVERIFY <pubkeya>OP_CHECKSIG OP_ENDIF

[0064] This exemplary locking script allows locking node A to request more than 90 pieces of data from a particular data source C. In addition, the locking script requires that the particular data source attest to the source of the data by providing a signature generated from a modified private key (i.e., from a private key modified based on the data). The exemplary locking script also requires that both locking node A and another node B, a potential recipient of the digital asset in transit, provide a valid signature to the unlocking script.

[0065] The exemplary locking script includes multiple branches, one of which allows Locking Node A to reclaim the digital assets restricted by the locking script if those digital assets are not claimed within 10 days.

[0066] An exemplary locking script may for example be used to reward a node B associated with one party by a locking node A associated with another party, rewarding that node B if a particular data source C provides data above 90. The data may for example be test results in the form of marks or grades and the particular data source may be a teacher. In such a case, node B is associated with the party that received the mark or grade in question and node A is associated with the party that wishes to reward the party that received the mark or grade if the mark or grade is met.

[0067] The locking script prepared in operation 302 may be included in a blockchain transaction by a locking node. That is, the locking node may embed the locking script in the output of the blockchain transaction (in operation 304 of method 300) to restrict (i.e., lock) the digital assets associated with the transaction. The transaction may be sent by the locking node to the blockchain network 100 (FIG. 1). That is, the transaction including the locking script may be broadcast to the blockchain network 100 (FIG. 1). If certain criteria are met, such as including sufficient mining fees, the transaction (sometimes referred to as a first transaction or first blockchain transaction) is added to a block generated by a miner 104 (FIG. 1) on the blockchain network 100 (FIG. 1). The locking node may wait until the block is mined and confirmed into the blockchain.

[0068] In operation 306, the locking node may prepare a transaction input for a further blockchain transaction (sometimes referred to as a second transaction or second blockchain transaction) that uses the digital assets included in the first transaction as an output. That is, the transaction may include the UTXO associated with the first transaction as an input to the second transaction. The locking node may generate a signature based on the locking node's private key and include the signature in the unlocking script of the second transaction. The locking node may also include a branch trigger as an input to the transaction that is used to trigger the action of a particular one of the conditional branches in the locking script. For example, the exemplary locking script described above includes two conditional branches, a first conditional branch that allows another party B to claim the digital assets included in the first transaction and a second conditional branch that allows the locking node to reclaim such digital assets if they are not otherwise claimed by B within a specified period of time. To have the unlock script in the second transaction trigger the first branch instead of the second branch, the lock node can include a "1" as an input to the transaction so that OP_IF evaluates to TRUE and causes the first branch to execute.

[0069] The locking node's signature is added in a way that allows other nodes to add it to the transaction without needing the locking node's approval. For example, a signature can be added as SIGHASH_NONE|SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY is a signature hash type that signs only the current input, while SIGHASH_NONE is a signature hash type that signs only the input, allowing anyone to modify the output without needing the locking node's permission.

[0070] Thus, in operation 306, the locking node can generate a signature and add this signature to the transaction, set up the transaction to allow other parties to add inputs and outputs, and add branch triggers to the transaction to trigger the behavior of certain conditional branches of the locking script.

[0071] The lock node may provide (at operation 308) the second transaction prepared in operation 306 to another node of another party, such as party B, or to a particular data source C.

[0072] 4, a method 400 for facilitating unlocking of digital assets on a blockchain network is shown. Method 400 may be performed by a node 102 of blockchain network 100 (FIG. 1) or by another electronic device that may not participate in blockchain network 100. A node 102 that performs method 400 may be referred to as a determined data source. A determined data source may be configured with processor-executable instructions that, when executed by a processor of the determined data source, perform method 400.

[0073] At operation 402, a particular data source may receive a proposed transaction, which may be a transaction prepared by a locking node at operation 306 of method 300. That is, the transaction is a transaction that references one or more digital assets that are restricted (i.e., locked) by a locking script.

[0074] In operation 404, the particular data source generates a modified private key based on the particular data source's private key and the data provided by the particular data source in the blockchain transaction. The modified private key is generated using the techniques described above. For example, the modified private key can be generated by modifying the private key with the data using an operation corresponding to an operation specified in the lock script to generate the modified private key. Thus, operation 404 can be of the type described above with reference to FIG. 3. For example, the modified private key can be determined by performing a finite field arithmetic operation on the private key and the data. For example, the finite field arithmetic operation can be a multiplication.

[0075] A signature for the proposed transaction is generated using the modified private key in operation 406. This signature is added to the transaction along with the data itself in operation 408. The signature may be added in a way that allows other nodes to add it to the transaction without requiring approval from a particular data source. For example, the signature may be added as SIGHASH_NONE|SIGHASH_ANYONECANPAY.

[0076] In operation 410, the particular data source communicates the transaction to another node. For example, the particular data source can pass the proposed transaction to another node B associated with the public key specified in the locking script (intended to unlock the transaction's unlocking script). This other node adds an additional signature generated based on the other node's private key, as well as an output that specifies how to spend the digital assets associated with the transaction. This other node can broadcast the transaction (sometimes referred to as a second transaction) to the blockchain network 100 (FIG. 1).

[0077] For a blockchain transaction (sometimes referred to as a second transaction) to be added to a block that is accepted into the blockchain, the transaction input that includes the transaction unlock script must successfully unlock the lock script of the first transaction (i.e., the transaction prepared in operation 304 of method 300).

[0078] 5, which illustrates in flow chart form an example method 500 that may be performed by a node 102 of a blockchain network 100. A node performing this method may be referred to as a validator node because the node validates a blockchain transaction (i.e., a second transaction, which is a transaction that includes an unlock script intended to unlock the lock script of a first transaction) to determine whether the transaction should be added to the blockchain distributed ledger. The validator node may be a miner 104, or the validator node may be a validator node that does not mine but simply validates blocks proposed by the miner 104 or transactions that have not yet been mined into a block.

[0079] A validating node may execute the unlock script (specified in the second transaction) together with the corresponding lock script (specified in the first transaction) to determine whether the blockchain transaction (i.e., the second transaction) is valid. More specifically, the unlock script in each input of the transaction may be executed together with the lock script to determine whether the unlock script satisfies the usage (spending) conditions specified by the lock script.

[0080] For example, the unlock script may be executed first using a stack execution engine. If the unlock script is executed successfully without errors, the main stack may be copied by the validating node, and then the lock script may be executed. If the unlock script evaluates to TRUE, the unlock script meets the spending conditions prescribed by the lock script. The blockchain transaction is then determined to be valid, and the transaction may be written to the blockchain if certain other conditions are met (e.g., sufficient mining fees for miners to include the transaction in a new block).

[0081] Thus, the operations of method 500 are defined by computer-executable instructions in the lock script, and thus method 500 may include any of the functionality of the lock script described above.

[0082] At operation 502, the validator node evaluates the data provided in the unlock script to determine whether the data satisfies one or more constraints specified in the lock script. Examples of data constraints are described above with reference to FIG.

[0083] If the validator node determines that the data does not meet the required data constraints, then in operation 504, the validator node determines that the unlock script is not a valid solution to the lock script. The validator node then operates to not add the blockchain transaction (i.e., the second transaction) that includes the unlock script to the blockchain. For example, if the node is a miner 104 (FIG. 1), the node excludes the transaction from the next block prepared by that miner 104.

[0084] In operation 506, the validating node evaluates the source of the data. More specifically, a lock script executed by the validating node causes the node to determine a modified public key for the particular data source. The modified public key is determined by performing elliptic curve finite field arithmetic on the public key for the particular data source embedded in the lock script and based on the data provided in the unlock script. A signature check function is then invoked to determine whether the modified public key corresponds to a signature generated based on the modified private key. Details of this operation are described in detail above in the description of the lock script. The signature is provided in the unlock script. If the signature is determined to be invalid, the validating node determines in operation 504 that the unlock script is not a valid solution to the lock script.

[0085] If the data is determined to satisfy the data constraints and if the data is determined to be valid (i.e., the data is determined to have been generated or provided by a particular data source without subsequent tampering), the transaction may be determined to be valid in operation 508 (if other possible requirements of the lock script are also satisfied). The transaction may then be mined into the blockchain.

[0086] Although method 500 of FIG. 5 illustrates a validation method that generally verifies that the data satisfies one or more specified constraints and that the data has not been tampered with, the validation method may include other criteria that are evaluated before the lock script is evaluated as TRUE (i.e., before the transaction is determined to be valid).

[0087] Other operations may also be performed, such as those described in the locking script example discussed above. For example, a validating node may determine whether other nodes associated with the public key specified in the locking script validly signed the locking transaction that included the unlocking script. As noted above in the discussion of Figure 4, these other nodes may be, for example, the locking node (i.e., the node that generated the locking script), the recipient node (i.e., the node that is intended to be the recipient of the digital asset referenced in the transaction that includes the locking script), or another node. Failure of any of these validation operations may result in a failed validation.

[0088] Method 500 may also include, prior to performing operations 502 and 506, determining that the unlock script includes a branch trigger that triggers a branch of the lock script that defines operations 502 and 506. Operations 502 and 506 may be performed only if triggered by the branch trigger.

[0089] It should also be noted that the order of operations 502 and 506 may be reversed, i.e. the source of the data may be verified by the validator node prior to verifying that the data satisfies the specified constraints.

[0090] It should be noted that the above-described embodiments illustrate rather than limit the present invention, and 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, reference signs placed in parentheses shall not be construed as limiting the scope of the claims. Words such as "comprising, having, comprises" do not exclude the presence of elements or steps other than those listed in the claim or the specification as a whole. In this specification, "comprises, comprising" means "includes, including" or "consists of, consisting of". A reference to a singular element does not exclude a reference to a plural of such element and vice versa. The present invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several 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 used to advantage.

[0091] The contents of the claims as originally filed are described below as examples. [Example 1] 1. A computer-implemented method, the method comprising: A node in a blockchain network includes a locking script in a blockchain transaction to lock a digital asset associated with the blockchain transaction, the locking script including a public key of a particular data source and including instructions to cause a validating node executing the locking script to verify the source of data provided in an unlocking script by a) generating a modified public key based on the public key of the particular data source and data specified in the unlocking script, and b) evaluating a cryptographic signature in the unlocking script based on the modified public key; The node transmitting the blockchain transaction to the blockchain network. A computer-implemented method. [Example 2] 2. The computer-implemented method of claim 1, wherein the locking script further defines one or more data constraints, and the locking script further comprises instructions that cause the validator node to invalidate a blockchain transaction that includes the unlocking script if the one or more data constraints are not satisfied by the data. [Example 3] 3. The computer-implemented method of example 2, wherein the one or more data constraints specify one or more values ​​and a comparison function that performs a comparison based on the data and the one or more values. [Example 4] The computer-implemented method of any one of Examples 1 to 3, wherein the instructions causing the validator node to evaluate the cryptographic signature in the unlocking script based on the modified public key are configured to cause the validator node to invalidate the blockchain transaction including the unlocking script if the cryptographic signature was not generated using a modified private key associated with the particular data source, the modified private key being generated by the particular data source based on the private key of the particular data source and the data. [Example 5] 5. The computer-implemented method of example 4, wherein the instructions are configured to cause the validator node to generate the modified public key by performing operations corresponding to operations used to generate the modified private key. [Example 6] 6. The computer-implemented method of any one of claims 4 to 5, wherein the modified private key is a key generated by performing finite field arithmetic based on the data and the private key of the particular data source. [Example 7] 7. The computer-implemented method of example 6, wherein the instructions are configured to cause the validator node executing the lock script to generate the modified public key by performing elliptic curve finite field arithmetic based on the data and the public key of the particular data source. [Example 8] 8. The computer-implemented method of example 7, wherein the elliptic curve finite field arithmetic performs elliptic curve multiplication by a scalar. [Example 9] 9. The computer-implemented method of any one of Examples 1 to 8, wherein the locking script is further configured to include instructions for unlocking the digital asset by the node after a defined period of time. [Example 10] A computer-readable storage medium comprising computer-executable instructions that, when executed, cause a processor to perform the method of any one of Examples 1 to 9. [Example 11] An electronic device, the electronic device comprising: An interface device; a processor coupled to the interface device; A memory coupled to the processor, the memory storing computer executable instructions that, when executed, cause the processor to perform the method of any one of Examples 1 to 9. electronic equipment. [Example 12] 1. A computer-implemented method, the method comprising: generating a modified private key based on the data and the private key; using the modified private key to generate a cryptographic signature of a blockchain transaction that references the digital assets locked by the locking script; adding the cryptographic signature and the data to the blockchain transaction; and communicating the blockchain transaction to another node. A computer-implemented method. [Example 13] 13. The computer-implemented method of example 12, wherein generating a modified private key comprises performing finite field arithmetic on the data and the private key. [Example 14] 14. The computer-implemented method of example 12 or 13, wherein the multiplication is performed by finite field arithmetic. [Example 15] 15. The computer-implemented method of any one of Examples 12 to 14, wherein the locking script specifies a public key of a particular data source and includes instructions to cause a validating node executing the locking script to evaluate the source of the data provided in an unlocking script by a) generating a modified public key based on the public key of the particular data source and data specified in the unlocking script, and b) evaluating a cryptographic signature in the unlocking script based on the modified public key.< / pubkeya> < / pubkeyb> < / pubkeyc> < / pubkeya> < / data> < / data>

Claims

1. 1. A computer-implemented method, the computer-implemented method comprising: A particular data source receives a blockchain transaction that references one or more digital assets locked by a locking script; generating a modified private key based on the private key of the particular data source and the data that the particular data source provides to the blockchain transaction; generating a first signature of the blockchain transaction using the modified private key; adding the first signature and the data to the block chain transaction; communicating the blockchain transaction to a node; generating the modified private key includes modifying the private key with the data using operations corresponding to operations defined in the lock script; A computer-implemented method.

2. 2. The computer-implemented method of claim 1, further comprising generating the modified private key by performing finite field arithmetic on the private key and the data.

3. The computer-implemented method of claim 2 , wherein the finite field arithmetic operation performs a multiplication.

4. 4. The computer-implemented method of claim 1, wherein the first signature is added to the blockchain transaction as SIGHASH_NONE|SIGHASH_ANYONECANPAY.

5. 5. The computer-implemented method of claim 1, wherein the node is associated with a public key specified in the locking script and the unlocking script of the blockchain transaction that is intended to be unlocked.

6. generating a second signature by the node based on the private key of the node; 6. The computer-implemented method of claim 1, further comprising: adding the second signature to the blockchain transaction.

7. 7. The computer-implemented method of claim 1, further comprising the node adding one or more outputs to the blockchain transaction that specify how the one or more digital assets associated with the blockchain transaction are to be used.

8. 8. The computer-implemented method of claim 1, further comprising the node broadcasting the blockchain transaction to a blockchain network.

9. A computer-readable storage medium containing computer-executable instructions which, when executed, configure a processor to perform the method of any one of claims 1 to 8. A computer-readable storage medium.

10. An electronic device, the electronic device comprising: An interface device; a processor coupled to the interface device; and a memory coupled to the processor storing computer executable instructions that, when executed, configure the processor to perform the method of any one of claims 1 to 8. electronic equipment.

Images