Ensuring the security of blockchain transactions based on undetermined 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 generally relates to digital locks, and more specifically, to methods and systems for locking digital assets based on undetermined data from a particular data source. The present invention is particularly suitable, but not limited, for use in providing conditional unlocking of digital assets on a blockchain network based on data that is not available to the locking party at the time of locking the digital assets.

[0002] In this document, the term "blockchain" is used to include all forms of electronic computer-based distributed ledgers. These forms include, but are not limited to, blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known use of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. Although reference is made to Bitcoin herein for convenience and illustrative purposes, it should be noted that the present invention is not limited to use in 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 having similar limitations to Bitcoin in signature verification.

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

[0004] For a transaction to be written to the blockchain, it must be "verified." Verification is determined by a node based on a common set of rules used by the majority of nodes with block-generating capabilities. For example, in the Bitcoin protocol, some network nodes act as miners, verifying that each transaction is valid, and invalid transactions are rejected from the network. For example, a software client installed on a node performs this verification on a transaction that references an unspent transaction output (UTXO). Verification can be performed by executing its lock and unlock script. If the execution of the lock and unlock script evaluates to TRUE and other specific conditions are met, the transaction is valid and can be written to the blockchain. Thus, for a transaction to be written to the blockchain, it must: i) be verified by the node receiving the transaction (once the transaction is verified, the node relays the verified transaction to other nodes in the network); ii) be added to a new block built by a miner; and iii) be mined, that is, added to the public ledger of past transactions. A transaction is considered confirmed when a sufficient number of blocks have been added to the blockchain to make the transaction effectively irreversible.

[0005] Transaction output includes digital assets such as Bitcoin, and lock scripts, which may also be called encumbrances or locks. A lock script locks a digital asset by specifying conditions that must be met in order to spend the output. For example, a lock script may require specific data to be provided to an unlock script in order to unlock the associated digital asset. Traditional methods that require the locking party to provide data in order to unlock a digital asset require embedding a hash of the data within the lock script. However, this locking and unlocking method requires the data to be determined (i.e., known and fixed) when the lock script is created.

[0006] Thus, it is desirable to provide improved methods and apparatus for improving blockchain technology in one or more of these embodiments. [Overview of the Initiative]

[0007] Thus, the present invention provides a method defined in the appended claims.

[0008] As will be explained in more detail below, computer-based methods and electronic devices are configured to lock transactions based on undetermined data.

[0009] Accordingly, the present invention may provide a method (and a corresponding system) implemented on a computer. This method can be described as a security and / or control method. This method can be configured to control who and / or how the output of a blockchain transaction (TX) can be unlocked and used via the blockchain network. Use (spending) of the output enables the transfer of cryptocurrency. The present invention may provide a method (and a corresponding system) configured to modify a cryptographic public key embedded in the lock script of a blockchain transaction (Tx) with undetermined data provided in the unlock script of another transaction. The present invention makes it possible to secure a blockchain transaction based on undetermined data. In other words, the present invention makes it possible to lock a blockchain transaction 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 is i) A step in which a node in the blockchain network includes a lock script in a transaction (i.e., a blockchain transaction) in order to encumber (i.e., lock) the digital assets associated with the transaction (i.e., a blockchain transaction), wherein the lock script includes the public key of a specific data source, and includes instructions to cause a verification node executing the lock script to verify the source of data provided in an unlock script by a) generating a modified public key based on the public key of a specific data source and the data specified in the unlock script, and b) evaluating the signature (i.e., cryptographic signature) in the unlock script based on the modified public key. ii) The node sends a transaction (i.e., a blockchain transaction) to the blockchain network.

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

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

[0013] In some embodiments, the lock script is configured to cause the verification node to generate a modified public key by performing operations corresponding to the operations used to generate the modified private key.

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

[0015] In some embodiments, the instruction is configured to cause a verification node executing a lock script to generate a modified public key by performing elliptic curve finite field arithmetic operations based on the data and the public key of a particular data source. In some embodiments, the elliptic curve finite field arithmetic operations perform elliptic curve multiplication by a scalar.

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

[0017] According to the present invention, a method can be provided that is carried out by a computer, and this method is a) A step in which the node generates a modified secret key based on the data and the secret key, b) Using the modified private key, generate a signature (i.e., a cryptographic signature) of a transaction that references a digital asset restricted (i.e., locked) by the lock script, c) The step of adding (cryptographic) signatures and data to the (blockchain) transaction, d) The step of communicating a (blockchain) transaction to another node, including:

[0018] In some embodiments, the step of generating the modified secret key includes the step of performing finite-field arithmetic operations on the data and the secret key. In some embodiments, multiplication is performed by finite-field arithmetic operations.

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

[0020] According to the present invention, an electronic device can be provided. The electronic device includes an interface device, a processor coupled to the interface device, and a memory coupled to the processor. The memory stores computer-executable instructions that, when executed, cause the processor to execute the methods described herein.

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

[0022] According to the present invention, a computer-readable storage medium including a lock script may be provided, the lock script including computer-executable instructions that, when executed, cause a processor to execute the functions of the lock script described herein.

[0023] These and other aspects of the present invention will be described with reference to the embodiments described herein and will become apparent from this description. Here, embodiments of the present invention will be described by way of example only, with reference to the accompanying drawings.

Brief Description of the Drawings

[0024] [Figure 1] It is a block diagram of an exemplary blockchain network. [Figure 2] It is a block diagram of an exemplary electronic device that can function as a node in a blockchain network. [Figure 3] It is a flowchart of an exemplary method of setting a transaction using a lock script. [Figure 4] It is a flowchart of an exemplary method of setting a proposed transaction using a signature required for a lock script. [Figure 5] It is a flowchart of an exemplary method of verifying a transaction associated with a digital asset locked by a lock script.

Best Mode for Carrying Out the Invention

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

[0026] The electronic devices that execute the blockchain protocol and form the nodes 102 of the blockchain network 100 can be of various types, including, for example, computers such as desktop computers, laptop computers, tablet computers, servers, mobile devices such as smartphones, wearable computers such as smartwatches, or other electronic devices.

[0027] The nodes 102 of the blockchain network 100 are coupled to each other using suitable communication technologies that can include wired and wireless communication technologies. Such communication adheres to the protocol associated with the blockchain. For example, when the blockchain is the Bitcoin blockchain, the Bitcoin protocol can be used.

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

[0029] At least some of the nodes 102 will act as miners 104 on the blockchain network 100. The blockchain in Figure 1 is a proof-of-work blockchain where miners 104 perform costly calculations to facilitate transactions on the blockchain. For example, in a proof-of-work blockchain, miners may need to solve a cryptographic problem. In Bitcoin, miner 104 double-hashes the block header with SHA-256 to find a nonce such that the result is less than a value determined by the current difficulty. The hashing ability required for a proof-of-work algorithm means that a transaction is considered virtually irreversible after a certain number of blocks have been mined on it. Having solved the cryptographic problem, miner 104 creates a new block on the blockchain and broadcasts this new block to other nodes 102. The other nodes 102 verify that miner 104 has actually solved the cryptographic problem and thus demonstrated sufficient proof of work before accepting to add the block to the blockchain. Other nodes 102 also verify that the block itself is valid (for example, that the transaction and block header of the block are valid) before accepting the block to be added to the blockchain. The block is added to the blockchain (i.e., the global distributed ledger) by consensus of nodes 102.

[0030] A block created by miner 104 contains a transaction broadcast to the blockchain by node 102. For example, a block may contain a transaction from an address associated with one node 102 to an address associated with another node 102. In this way, a block functions as a record of transactions from one address to another. A party requesting to include a transaction in a block proves that it has the authority to initiate the transfer (for example, using Bitcoin in the case of Bitcoin) by signing the request with a private key corresponding to its 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 a public key and an address. That is, each public key is associated with a single address. Thus, references here to the transfer of digital assets to and from a public key (e.g., payments to a public key) and the transfer of digital assets to and from the address associated with that public key refer to general operations.

[0032] Some of Node 102 may not act as miners but instead participate as verification nodes. Transaction verification may include checking signatures (which may also be called cryptographic signatures here) or other conditions specified in lock scripts, and verifying references to valid UTXOs.

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

[0034] Figure 2 is a block diagram showing the components of an exemplary electronic device 200 that could function as a node 102 (Figure 1) in a peer-to-peer blockchain network 100 (Figure 1). The exemplary electronic device 200 may also be called a processing unit. The electronic device can take various 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 smartwatch, or other types of forms.

[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 containing machine-readable instructions and data for performing the functions described herein. For example, the memory may contain processor-executable instructions that, when executed by the processor 210, cause the electronic device to perform the methods described herein. The processor-executable instructions may contain instructions that, when executed by the processor 210, cause the electronic device to implement protocols related to the blockchain network 100 (Figure 1). For example, the instructions may include instructions for implementing the Bitcoin protocol.

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

[0037] In Figure 2, memory 220 is shown as a single block, but in reality, the electronic device 200 may include multiple memory components. These memory components can be of various types, such as RAM, HDD, SSD, flash drive, etc. Different types of memory may be suitable for different purposes. Furthermore, although memory 220 is shown separately from the processor 210, the processor 210 may include embedded memory.

[0038] The present invention may provide a method (and corresponding system) configured to modify a cryptographic public key embedded in a lock script of a blockchain transaction (Tx) using undetermined data provided in an unlock script of another transaction. For example, when used in combination with a signature check opcode (opcode) in a Bitcoin protocol that uses transaction bytecode as a message (e.g., OP_CHECKSIG), both the transaction and the data require approval or authorization from the public key owner. This protects those transactions and data from being swapped. Thus, the present invention provides advantages in terms of security, encryption, authorization, and transfer control.

[0039] Referring here to Figure 3, a method 300 for locking a digital asset on a blockchain network is shown. Method 300 is executed by node 102 of blockchain network 100 (Figure 1) and can lock a digital asset based on secure, undetermined data. The data is undetermined 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 so that any modification of the data by an unauthorized party would invalidate the transaction. For convenience of reference, node 102 executing method 300 may be referred to herein as the lock node. The lock node may be set by a processor executable instruction that executes method 300, when executed by the lock node's processor.

[0040] Therefore, the undetermined data used to lock digital assets may be data that is not yet known to the lock node at the time of locking. This data may be data that has not yet been established (such as data that is planned 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 lock node. However, the data is data that is expected to become available (currently or in the future) from a specific (determined) data source. The data source is determined so that its ID is known when the lock script is generated. In some embodiments where the lock script is configured to depend on data from a single data source (as opposed to embodiments where the lock script accepts data from multiple data sources and determines which data source to depend on), that data source may be called a trusted data source.

[0041] Method 300 includes the step in operation 302 of preparing a lock script for locking a digital asset based on undetermined data. A lock script is a restriction in the form of computer executable code or instructions placed on the output of a transaction that specifies conditions that must be met in order to use the output in the future. More specifically, the lock script receives data from an unlock script, performs a specific action based on that data, and is configured so that a verification node can determine whether the unlock script successfully unlocks the lock script.

[0042] A lock script can define one or more data constraints. These constraints are requirements that the data provided by the unlock script must satisfy in order for the lock script to successfully evaluate (for example, evaluate to TRUE in the case of Bitcoin). Therefore, in operation 302, the lock script can be configured to include instructions for the validation node executing the lock script to evaluate the data provided by the unlock script against the data constraints. The data constraints in a lock script may define thresholds or values, and the necessary relationships between the data and the defined values ​​or thresholds. A comparison function can be used to cause the validation node executing the lock script to compare the data with one or more values ​​based on the data provided by the unlock script. For example, a data constraint might require that the data is equal to, greater than, less than, or not equal to a value specified in the lock script. Many other possible data constraints can also be defined.

[0043] As an example, in Bitcoin, the following are some examples of possible instruction codes that may be included in the data constraint section of a lock script to verify that the data meets certain conditions. Note that other operations are also possible before using any of the comparison functions below, and the script may modify the data in some way (e.g., multiplication, subtraction, division, addition, or other operations). • OP_GREATERTHAN: This returns TRUE if the second item in the stack is greater than the top item in the stack. • OP_LESSTHANOREQUAL: This returns TRUE if the second item in the stack is less than or equal to the top item. • OP_GREATERTHANOREQUAL: This returns TRUE if the second item in the stack is greater than or equal to the top item. • OP_WITHIN: This returns 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 are the same number. • OP_NUMNOTEQUAL: This returns TRUE if the top two items do not have the same number. • OP_LESSTHAN: This returns TRUE if the second item in the stack is smaller than the top item.

[0044] A lock script may include instructions such as a verification function that invalidates a transaction containing an unlock script, intended to unlock the lock script if the data constraints are not met by the data. For example, if the blockchain network is Bitcoin, the OP_VERIFY instruction code may be included after the comparison 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 the lock script can take the following form: <Script to check constraints> OP_VERIFY Here, the <script to check 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 lock script may contain computer-executable instructions that cause the verification node executing the lock script to evaluate the source of the data. For example, a lock script may require data to be provided by a specific data source, such as a specific node, that has not been tampered with by other nodes. In other words, a lock script is configured so that any transaction intended to unlock the lock script is invalidated by such tampering.

[0047] A lock script causes a verification node executing the lock script to verify the data source (the data source provided by the unlock script, which is intended to unlock the lock script) using elliptic curve finite field operations. More specifically, a lock script can be configured to cause a node to perform elliptic curve finite field operations at runtime based on the public key and data of a specific data source included in the lock script. In other words, a lock script can be configured to cause a node executing the lock script to generate a modified public key for a specific data source based on the public key of the specific data source defined in the lock script and the data defined in the unlock script. The modified public key is determined by performing elliptic curve finite field arithmetic operations based on the public key of the specific data source embedded in the lock script and the data provided in the unlock script. The modified public key can also be determined using multiple operations (e.g., data × data × public key).

[0048] To unlock a lock script, a specific data source must obtain a modified private key by performing finite-field arithmetic operations on the data source's private key and data. More specifically, the operations performed on the private key correspond to the operations that 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 a modified private key (e.g., data × data × private key). The modified private key is used by the specific data source to generate a signature that can be included in the unlock script. In this specification, this signature may be referred to as the signature from the modified private key.

[0049] To understand how verifying the source of data becomes possible by modifying both the private and public keys using the data, it is helpful to consider the relationship between the private and public keys. More specifically, the elliptic curve public key is calculated as follows: D = d × G Here, d is the secret key, D is the corresponding public key, and G is the source element of the elliptic curve finite field.

[0050] Due to the relationship between the private and public keys, if a change is made to the public key using data, a corresponding change must be made to the private key. As long as the operation can be broken down into finite field additions, there are multiple ways to modify the private and public keys using data.

[0051] For 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 modified private key can be determined as follows (data is data): d' = d × data D'=d'×G=d×data×G=data×D Alternatively, the modified public key and modified private key may be determined as follows: d'=d+data D'=d'×G=(d+data)×G=D+DATA Here, DATA represents the elliptic curve point.

[0052] While some existing blockchain networks may not include specific instruction codes for performing elliptic curve finite-field arithmetic operations, the protocol controlling the operation of blockchain network 100 (Figure 1) may provide such instruction codes to offer such operations. For example, an instruction code OP_ECPMULT can be defined that takes encoded elliptic curve points and numerical values ​​and performs scalar elliptic curve multiplication. This instruction code outputs the result as encoded elliptic curve points.

[0053] To perform finite-field elliptic curve operations, you can use two specific elliptic curve operations: The addition of a point (P+Q) is used to calculate a new point on the elliptic curve as the negation (a point that is not an intersection) of the curve. This can be explained as R=P+Q. • Doubling points (P+P) calculates a multiple of P using point addition. 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) - y1 mod p Here,

number

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

[0056] For example, OP_CHECKSIG can be used in lock scripts with elliptic curve finite field arithmetic operations as follows: <Public Key D>OP_ECPMULT OP_CHECKSIG Here, public key D is the public key of the specific data source that provides the data.

[0057] The corresponding part of the unlock script that successfully verifies this part of the lock script is as follows: <Sig’> <data> Here, <data>This is data,<Sig’> This is a signature generated by a modified private key (i.e., a private key modified based on the data).

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

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

[0060] Furthermore, lock scripts can be configured to require the addition of a signature associated with the lock node itself before the lock script is verified as TRUE, ensuring that digital assets are no longer restricted by the lock script. For example, a lock script may include the following: <Public Key A>OP_CHECKSIGVERIFY Here, 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, but OP_CHECKSIGVERIFY will use OP_VERIFY to stop if OP_CHECKSIG does not evaluate to TRUE.

[0061] Furthermore, the lock script prepared in operation 302 may be configured to include instructions for releasing the restrictions placed on the digital asset by the lock script after a specified period. In other words, the lock script may be configured to include one or more conditions that allow the locking party to reclaim the digital asset under certain conditions. For example, the lock script may allow the lock node to reclaim the digital asset if the data, once determined, fails to meet the data constraints required by the lock script. For example, the lock script may be configured to allow the lock node (or another party specified by the public key) to claim the digital asset after a period specified in the lock script has elapsed, provided that the digital asset has not been claimed by anyone else during that period.

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

[0063] Thus, lock scripts may contain numerous conditions that must be met in order to unlock. Lock scripts can take many forms, but examples of usable scripts are shown below: 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 lock script allows lock node A to request more than 90 units of data from a specific data source C. Furthermore, the lock script requires the specific data source to prove the source of the data by providing a signature generated from a modified private key (i.e., a private key modified based on the data). The exemplary lock script also requires both lock node A and another node B, which may be the recipient of the digital assets in transit, to provide a valid signature for the unlock script.

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

[0066] An exemplary lock script is used, for example, to reward node B associated with another party by lock node A associated with one party, and node B is rewarded if a particular data source C provides more than 90 data points. The data may be, for example, test results in the form of marks or grades, and the particular data source may be a teacher (grader). 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 lock script prepared in operation 302 is included in the blockchain transaction by the lock node. That is, the lock node can embed the lock script in the output of the blockchain transaction (in operation 304 of method 300) and restrict (i.e., lock) the digital assets associated with the transaction. The transaction is sent by the lock node to the blockchain network 100 (Figure 1). That is, a transaction containing a lock script can be broadcast to the blockchain network 100 (Figure 1). If certain criteria are met, such as including sufficient mining fees, the transaction (sometimes called the first transaction or first blockchain transaction) is added to a block generated by the miner 104 (Figure 1) on the blockchain network 100 (Figure 1). The lock node may wait until the block is mined into the blockchain and confirmed.

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

[0069] A lock node's signature is added in a way that allows other nodes to add to a transaction without requiring the lock 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 and allows anyone to modify the output without requiring the lock node's permission.

[0070] Thus, in operation 306, the lock node can generate a signature and add this signature to the transaction, configure the transaction to allow another party to add inputs and outputs, and add a branch trigger to the transaction to trigger a specific conditional branch operation of the lock script.

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

[0072] Referring here to Figure 4, a method 400 for facilitating the unlocking of digital assets on a blockchain network is shown. Method 400 may be performed by a node 102 of the blockchain network 100 (Figure 1), or by another electronic device that does not have to be part of the blockchain network 100. The node 102 that performs Method 400 may be called a determined data source. The determined data source may consist of processor-executable instructions that, when executed by the processor of the determined data source, perform Method 400.

[0073] In operation 402, a particular data source may receive a proposed transaction, which may be a transaction prepared by the lock node in 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 the lock script.

[0074] In operation 404, a specific data source generates a modified private key based on the private key of the specific data source and the data provided by the specific data source in a blockchain transaction. The modified private key is generated using the method described above. For example, the modified private key can be generated by modifying the private key with the data using an operation (operation) corresponding to an operation (operation) specified in the lock script to generate the modified private key. Thus, operation 404 may be of the type described above with reference to Figure 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 may be multiplication.

[0075] In operation 406, a signature for the proposed transaction is generated using the modified private key. 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 specific data source. For example, the signature may be added as SIGHASH_NONE|SIGHASH_ANYONECANPAY.

[0076] In operation 410, a specific data source communicates a transaction to another node. For example, a specific data source may pass a proposed transaction to another node B associated with a public key specified in a lock script (intended to unlock the transaction's unlock script). This other node adds an additional signature generated based on its private key and also adds output specifying how to use the digital assets associated with the transaction. This other node can broadcast the transaction (sometimes called a second transaction) to the blockchain network 100 (Figure 1).

[0077] When adding a blockchain transaction (sometimes called a second transaction) to a block to be accepted into the blockchain, the transaction input, which 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] Referring now to Figure 5, this figure shows an exemplary method 500 that may be performed by node 102 of blockchain network 100 in flowchart form. A node that performs this method may be called a verification node because it verifies a blockchain transaction (i.e., a second transaction which is a transaction containing 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. A verification node may also be a miner 104, which may not mine but simply verify a block or a transaction that has not yet been mined into a block, as proposed by miner 104.

[0079] The verification node executes the unlock script (defined in the second transaction) along with the corresponding lock script (defined in the first transaction) to determine whether the blockchain transaction (i.e., the second transaction) is valid. More specifically, it can execute the unlock script within each input of the transaction along with the lock script to determine whether the unlock script satisfies the usage (expenditure) conditions defined by the lock script.

[0080] For example, an unlock script might be executed first using the stack execution engine. If the unlock script executes successfully without errors, the main stack is copied by a verification node, and then the lock script may be executed. If the unlock script evaluates to TRUE, the unlock script has met the usage (expenditure) conditions defined by the lock script. The blockchain transaction is then determined to be valid and can 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] Therefore, the operation of method 500 is defined by computer-executable instructions within the lock script. Thus, method 500 may include any of the functions of the lock script described above.

[0082] In operation 502, the validation node evaluates the data provided by the unlock script to determine whether the data satisfies one or more constraints defined in the lock script. Examples of data constraints are shown above with reference to Figure 3.

[0083] In operation 504, if the validation node determines that the data does not meet the required data constraints, the validation node determines that the unlock script is not a valid solution to the lock script. The validation node then acts to prevent the blockchain transaction containing the unlock script (i.e., the second transaction) from being added to the blockchain. For example, if the node is miner 104 (Figure 1), the node excludes the transaction from the next block prepared by miner 104.

[0084] In operation 506, the verification node evaluates the data source. More specifically, a lock script executed by the verification node causes the node to determine the modified public key for a particular data source. The modified public key is determined by performing elliptic curve finite field arithmetic operations on the public key of the particular data source embedded in the lock script, and also based on the data provided in the unlock script. Next, the signature check function is invoked to determine whether the modified public key corresponds to a signature generated based on the modified private key. Details of this operation (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 verification 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 is determined to be valid (i.e., determined to have been generated or provided by a specific data source without subsequent tampering), then the transaction can be determined to be valid in operation 508 (provided that other possible requirements of the lock script are also met). The transaction can then be mined into the blockchain.

[0086] Method 500 in Figure 5 illustrates a verification method that generally confirms that data satisfies one or more specified constraints and that the data has not been tampered with. However, the verification method may include other criteria that are evaluated before the lock script evaluates to TRUE (i.e., before the transaction is determined to be valid).

[0087] Other actions may be performed, such as those described in the lock script example discussed above. For example, a verification node can determine whether other nodes associated with the public key specified in the lock script have validly signed the lock transaction containing the unlock script. As mentioned above in the discussion in Figure 4, these other nodes may be, for example, the lock node (i.e., the node that generated the lock script), the receiver node (i.e., a node intended to be the receiver of the digital asset referenced in the transaction containing the lock script), or another node. Failure of any of these verification actions may result in verification failure.

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

[0089] It should also be noted that the order of operations 502 and 506 may be reversed. That is, the data source may be verified by the validation node before verifying that the data satisfies the specified constraints.

[0090] The embodiments described above are illustrative, not limiting, of the present invention, and it should be noted that those skilled in the art can design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. Reference numerals in parentheses in the claims should not be construed as limiting the claims. Words such as “comprising,” “composed” do not preclude the existence of elements or steps other than those enumerated throughout the claims or specification. In this specification, “comprises,” “composed” means “includes,” “including,” or “consists of,” “consist of.” A singular reference to an element does not preclude a plural reference to such an element, and vice versa. The present invention can be carried out by hardware comprising several distinct elements and by a appropriately programmed computer. In apparatus claims that enumerate several means, some of these means may be embodied by the same item of hardware. The mere fact that certain means are described in different dependent claims does not imply that combinations of these means cannot be used advantageously.

[0091] The following is an example of the claims as originally filed. [Example 1] A method performed by a computer, the method is A step of including a lock script within a blockchain transaction in order for a node in the blockchain network to lock a digital asset associated with the blockchain transaction, wherein the lock script includes the public key of a specific data source, and includes an instruction to a verification node executing the lock script to verify the source of data provided in an unlock script by a) generating a modified public key based on the public key of the specific data source and the data specified in the unlock script, and b) evaluating the cryptographic signature in the unlock script based on the modified public key. The node includes the step of transmitting the blockchain transaction to the blockchain network, A method performed using a computer. [Example 2] The method implemented on a computer according to Embodiment 1, wherein the lock script further defines one or more data constraints, and the lock script further includes an instruction to the verification node to invalidate the blockchain transaction including the unlock script if the one or more data constraints are not satisfied by the data. [Example 3] The computer-based method described in Example 2, wherein 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. [Example 4] The instruction to the verification node to evaluate the cryptographic signature in the unlock script based on the modified public key is configured to cause the verification node to invalidate the blockchain transaction including the unlock script if the cryptographic signature is not generated using the modified private key associated with the particular data source, wherein the modified private key is generated by the particular data source based on the private key of the particular data source and the data, a method performed on a computer according to any one of Examples 1 to 3. [Example 5] The method performed on a computer according to Embodiment 4, wherein the instruction is configured to cause the verification node to generate the modified public key by performing an operation corresponding to the operation used to generate the modified private key. [Example 6] The method performed on a computer according to Embodiment 4 or 5, wherein the modified secret key is a key generated by performing finite-field arithmetic operations on the data and the secret key of the specific data source. [Example 7] The method performed on a computer according to Embodiment 6, wherein the instruction is configured to cause the verification node executing the lock script to generate the modified public key by performing elliptic curve finite field arithmetic operations on the data and the public key of the specific data source. [Example 8] The elliptic curve finite-field arithmetic operation is performed by the computer method described in Example 7, which involves scalar elliptic curve multiplication. [Example 9] The method performed on a computer according to any one of Examples 1 to 8, wherein the lock script is further configured to include an instruction for the node to unlock the digital asset after a specified period of time. [Example 10] A computer-readable storage medium containing computer-executable instructions that, when executed, cause a processor to perform the method described in any one of Examples 1 to 9. [Example 11] An electronic device, said electronic device, Interface device and A processor coupled to the interface device, A memory coupled to the processor, which, when executed, stores computer executable instructions that cause the processor to perform the method described in any one of Embodiments 1 to 9, electronic equipment. [Example 12] A method performed by a computer, the method is The node generates a modified secret key based on the data and the secret key, The steps include: using the modified private key to generate a cryptographic signature for a blockchain transaction referencing a digital asset locked by a lock script; The steps include adding the cryptographic signature and the data to the blockchain transaction, The step of communicating the aforementioned blockchain transaction to another node is included, A method performed using a computer. [Example 13] The step of generating a modified secret key is a method performed on a computer as described in Example 12, comprising the step of performing finite-field arithmetic operations on the data and the secret key. [Example 14] A computer-based method according to Example 12 or 13, wherein multiplication is performed by finite-field arithmetic operations. [Example 15] A computer-based method according to any one of Examples 12 to 14, wherein the lock script specifies the public key of a particular data source, and includes an instruction to a verification node executing the lock script to evaluate the source of data provided in the unlock script by a) generating a modified public key based on the public key of the particular data source and the data specified in the unlock script, and b) evaluating the cryptographic signature in the unlock script based on the modified public key.< / pubkeya> < / pubkeyb> < / pubkeyc> < / pubkeya> < / data> < / data>

Claims

1. A method performed on a computer by a verification node within a blockchain network, the method being: A step of receiving a blockchain transaction, wherein the blockchain transaction includes an unlock script configured to unlock one or more lock scripts associated with digital assets, The verification node executes the lock script and the unlock script, and this execution includes: Evaluate the cryptographic signature in the unlock script based on the modified public key determined from the data in the unlock script and the public key specified in the unlock script. Determining that the data in the unlock script satisfies one or more data constraints defined in the lock script, and The step includes determining whether a branch trigger in the unlock script triggers a branch in the lock script, If the unlock script determines that one or more conditions are met, the steps include verifying the blockchain transaction, The process includes the step of adding the blockchain transaction to the blockchain after verifying the blockchain transaction, A method performed using a computer.

2. The method performed on a computer according to claim 1, wherein the verification node executes the unlock script using a stack execution engine before executing the lock script.

3. A computer-based method according to claim 1, comprising determining the modified public key by performing elliptic curve finite-field arithmetic operations for evaluating the cryptographic signature.

4. The computer-based method according to claim 1, wherein the one or more data constraints include one or more values, and the validation node uses a comparison function to make a comparison between the data and the one or more values.

5. A computer-based method according to claim 1, further comprising determining that the data in the unlock script satisfies one or more data constraints defined in the lock script, and confirming that the data was provided by a determined data source.

6. The method performed on a computer according to claim 5, wherein the public key specified in the lock script is for the determined data source.

7. The method performed on a computer according to claim 1, further comprising excluding the transaction from a block if the verification node determines that the data in the unlock script does not satisfy one or more data constraints defined in the lock script.

8. A non-temporary computer-readable storage medium storing computer-executable instructions that, when executed by the processor, constitute the processor to perform the method according to any one of claims 1 to 7.

9. An electronic device, said electronic device, Interface device and A processor coupled to the interface device, Includes memory in which computer executable instructions are stored, When the computer executable instruction is executed, the processor is configured to perform the method according to any one of claims 1 to 7. electronic equipment.

Images