Blockchain Transactions

Abstract

A computer-implemented method for generating a puzzle blockchain transaction is provided. An initial locking script of the puzzle blockchain transaction is provided, the initial locking script corresponding to a first unspent transaction output and including a hash value derived from a target solution to the timelock puzzle and a set of puzzle parameters for the timelock puzzle. The target solution is calculated using the set of secret puzzle parameters. The timelock puzzle is solvable using the set of puzzle parameters in a time equal to or greater than a minimum solving time. The set of puzzle parameters does not include the set of secret puzzle parameters. When the locking script is executed with an initial unlocking script of the answer blockchain transaction, it is configured to validate a candidate answer calculated using the set of puzzle parameters and provided in the initial unlocking script of the answer blockchain transaction based on the hash value.

Description

[Technical field]

[0001] The present disclosure relates to a method for generating a blockchain transaction, the output of which is time-locked, and a method for generating a blockchain transaction for unlocking the time-locked output. [Background technology]

[0002] The term "blockchain" refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network") and made publicly available. The blockchain consists of a chain of blocks of data, with each block consisting of one or more transactions. Each transaction, other than the so-called "coinbase transaction", points to the previous transaction in a sequence spanning one or more blocks that traces back to one or more coinbase transactions. Coinbase transactions are described in more detail below. Transactions submitted to the blockchain network are included in new blocks. New blocks are created by a process often called "mining", in which each of multiple nodes compete to perform a "proof of work" - that is, to solve a cryptographic puzzle based on a representation of a predefined set of ordered and validated pending transactions that are waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of a block can be achieved by publishing only the block header.

[0003] A transaction in a blockchain can be used for one or more of the following purposes, such as to convey digital assets (i.e., a number of digital tokens), to order a set of entries in a virtualized ledger or registry, to receive and process timestamp entries, and / or to chronologically order index pointers. A blockchain can also be used to layer additional functionality on top of the blockchain. For example, the blockchain protocol allows additional user data or indexes to be stored on the data within a transaction. Since there is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, increasingly complex data can be incorporated. For example, this can be used to store electronic documents or audio and video data on the blockchain.

[0004] Nodes in a blockchain network (often called "miners") perform a distributed transaction registration and validation process, which is described in more detail below. In summary, during this process, nodes validate transactions and insert them into a block template in an attempt to identify a valid proof-of-work solution. Once a valid solution is found, a new block is propagated to other nodes in the network, allowing each node to record the new block in the blockchain. To record a transaction in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network, which propagates it. Nodes that receive the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into a new block. Each node is configured to apply the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or incorporated into blocks. Once a transaction is validated and accepted into the blockchain, the transaction (including the user data) remains registered and indexed with each node in the blockchain network as an immutable public record.

[0005] The node that solves the proof-of-work puzzle and creates the latest block is rewarded with a new transaction, called a "coinbase transaction," which typically distributes a fixed amount of digital assets, or number of tokens. The detection and rejection of invalid transactions is performed by the actions of competing nodes, who act as agents of the network and are incentivized to report and block misconduct. Widely published information allows users to continuously audit node performance. By publishing only block headers, participants can ensure the ongoing integrity of the blockchain.

[0006] In the “output-based” model (sometimes called the UTXO-based model), the data structure of a particular transaction consists of one or more inputs and one or more outputs. A usable output consists of an element that specifies the amount of digital assets obtained from a series of transactions. A usable output is sometimes called a UTXO (or “unspent transaction output”). An output may also include a locking script that specifies the future redemption conditions of the output. A locking script is a predicate that defines the conditions required to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output of a preceding transaction and may further include an unlocking script to unlock the locking script of the pointed output. Now consider a pair of transactions, which we call the first transaction and the second transaction (or “target” transaction). The first transaction includes at least one output that includes a locking script that specifies the amount of digital assets and defines one or more conditions to unlock the output. The second target transaction consists of at least one input that includes a pointer to an output of the first transaction and an unlocking script to unlock the output of the first transaction.

[0007] In such a model, when a second target transaction is submitted to the blockchain network to be propagated and recorded in the blockchain, one validity criterion applied by each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction; another is that the output of the first transaction has not yet been redeemed by another previous valid transaction. A node that determines that the target transaction is invalid based on any of these conditions will not propagate it (potentially registering it as an invalid transaction rather than as a valid transaction) and will not include it in any new block recorded in the blockchain.

[0008] Another type of transaction model is the account-based model, where each transaction defines the amount to transfer by referring to the absolute balance of the account, rather than by referring to the UTXO of the previous transaction in the sequence of past transactions. The current state of every account is stored in a node separate from the blockchain and is constantly updated. Summary of the Invention

[0009] In some scenarios, it is desirable to create transactions with outputs that can only be used after a certain amount of time has passed. This can be achieved to some extent by nLocktime, which ensures that the entire transaction is committed to the blockchain only after nLocktime has passed, and the UTXOs can only be used after nLocktime has passed. However, this method does not allow for locking only a portion of a transaction's UTXOs, and the transaction is stored locally rather than in an immutable way on the blockchain.

[0010] Provided herein is a blockchain transaction that uses a timelock puzzle to lock the UTXO of a transaction to be stored on-chain and only be spendable after a certain amount of time has passed.

[0011] According to one aspect disclosed herein, a computer-implemented method for generating a puzzle blockchain transaction is provided, the method including: providing a first locking script of the puzzle blockchain transaction, the first locking script corresponding to a first unspent transaction output and including a hash value derived from a target solution of the timelock puzzle and a set of puzzle parameters for the timelock puzzle, the target solution being calculated using the set of secret puzzle parameters, the timelock puzzle being solvable using the set of puzzle parameters in a time equal to or greater than a minimum solving time, the set of puzzle parameters not including the secret puzzle parameter, and the locking script, when executed together with a first unlocking script of the answer blockchain transaction, verifies a candidate answer calculated using the set of puzzle parameters provided in the first unlocking script of the answer blockchain transaction based on the hash value; and making the puzzle blockchain transaction available to one or more nodes of a blockchain network.

[0012] Timelock puzzles require the user to perform an exact number of successive calculations, so parallelizing the solving process does not make the answer faster to find, and as a result, the solving time of the puzzle can be estimated in advance if the user's hardware is known.

[0013] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference is made by way of example only to the accompanying drawings, in which: [Brief description of the drawings]

[0014] [Figure 1]FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] FIG. 1 is a schematic diagram of an example of a transaction that may be recorded on a blockchain. [Diagram 3] FIG. 2 is a schematic block diagram of node software for processing transactions. [Figure 4] FIG. 13 is a schematic diagram of an example of how a solution to a timelock puzzle can be used to unlock a UTXO. [Diagram 5] FIG. 13 is a schematic diagram of an example of how a UTXO can be unlocked using a time-locked private key that is not associated with a specific user. [Figure 6] FIG. 13 is a schematic diagram of an example of how a UTXO can be unlocked using a time-locked private key associated with a particular user. [Figure 7] FIG. 13 is a schematic diagram of an example of how a time-locked private key that is not associated with a specific user can be used to unlock the UTXO chain. [Figure 8] FIG. 1 is a schematic diagram of an example of how a time-locked private key associated with a particular user can be used to unlock the UTXO chain. [Figure 9] FIG. 1 is a schematic diagram of a chain transaction involving multiple outputs forming a timelock chain. [Figure 10] FIG. 13 illustrates an example of a method to prevent a UTXO from being spent until a minimum resolution time has passed. [Figure 11] FIG. 13 is a schematic diagram of an example of how to unlock a chain of UTXOs when a spend transaction contains the next puzzle to be solved. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] 1. System overview example FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a number of blockchain nodes 104 that may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not illustrated, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to the other blockchain nodes 104.

[0016] Each blockchain node 104 includes a peer computer device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device including one or more processors, for example one or more central processing units (CPUs), accelerator processors, application specific processors and / or field programmable gate arrays (FPGAs), and other devices such as application specific integrated circuits (ASICs). Each node also includes a memory, i.e., a computer readable storage device in the form of a non-transitory computer readable medium. The memory may include one or more memory units employing one or more memory media, for example, a magnetic medium such as a hard disk, an electronic medium such as a solid state drive (SSD), a flash memory, or an EEPROM, and / or an optical medium such as an optical disk drive.

[0017] The blockchain 150 includes a chain of blocks 151 of data, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in a distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned so long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount that represents a quantity of a digital asset as property, an example of which is a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to unlock it and thereby be redeemed or spent). Each input points to an output of a preceding transaction 152, thereby linking the transactions.

[0018] Each block 151 also contains a block pointer 155 that points to a previously created block 151 in the chain, defining an order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer to a previous transaction, defining an order for the sequence of transactions (Note: the sequence of transactions 152 is allowed to branch). The chain of blocks 151 dates back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153 rather than to a preceding transaction.

[0019] Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store a respective copy of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to the ordered set of transactions that the node 104 has accepted as valid, for which the node 104 is obligated not to accept any other transactions that attempt to consume the same output.

[0020] In a given current transaction 152j, the (or each) input contains a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consumption or redemption does not necessarily mean the transfer of a financial asset, although that is certainly one of the common uses. More generally, consumption may be described as consuming an output or allocating it to one or more outputs of another subsequent transaction. In general, the preceding transaction may be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or even sent to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to a preceding element in a logical sequence linked by a pointer, not necessarily to the point of creation or transmission in the temporal sequence, and thus does not necessarily preclude a transaction 152i, 152j from being created or transmitted out of sequence (see discussion below regarding orphan transactions). A preceding transaction 152i may equally be referred to as a previous transaction or a preceding transaction.

[0021] The input of the current transaction 152j also includes an input authorization, e.g., the signature of the user 103a to which the output of the previous transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user or entity 103b. The current transaction 152j can thus transfer to the new user or entity 103b the amount defined in the input of the previous transaction 152i as defined in the output of the current transaction 152j. In some cases, the transaction 152 may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a to provide change). In some cases, a transaction may also have multiple inputs to collect amounts from multiple outputs of one or more previous transactions and redistribute them to one or more outputs of the current transaction.

[0022] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wants to enact a new transaction 152j (manually or by an automated process adopted by the party), the implementing party sends the new transaction from its computer terminal 102 to a recipient. The implementing party or recipient will eventually send this transaction to one or more of the blockchain nodes 104 of the network 106 (currently typically a server or a data center, but in principle it could be other user terminals). It is also not excluded that the party 103 who enacts the new transaction 152j sends this transaction directly to one or more of the blockchain nodes 104 and in some examples does not send it to a recipient. The blockchain nodes 104 that receive the transaction check whether the transaction is valid according to the blockchain node protocol applied at each of them. The blockchain node protocol typically requires that the blockchain nodes 104 check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may involve checking that a cryptographic signature or other authorization of a party 103 included in the input of the new transaction 152j matches a condition defined in the output of a prior transaction 152i that the new transaction consumes (or "allocates"), which typically involves at least checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the prior transaction 152i to which the input of the new transaction is linked. This condition may be defined at least in part by a script included in the output of the prior transaction 152i. Alternatively, it may simply be fixed by the blockchain node protocol alone, or result from a combination of these.In any case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104, following the same blockchain node protocol and applying the same tests, forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0023] In the output-based model, the definition of whether a given output (e.g., UTXO) has been allocated (or "spent") is whether it has still been validly redeemed by the input of another, forward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless it is flagged as invalid and propagated due to a warning) or recorded in the blockchain 150. This protects against double spending, where a transaction executor tries to allocate the same transaction output multiple times. On the other hand, the account-based model prevents double spending by maintaining an account balance. Again, since there is a defined order of transactions, the account balance has a single defined state at any point in time.

[0024] In addition to validating transactions, blockchain nodes 104 compete to be the first to create a block of transactions in a process commonly referred to as mining, supported by "proof of work." At the blockchain nodes 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from an ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition could be that the output of the hash has a certain predefined number of leading zeros. This is just one particular type of proof of work puzzle, others are not excluded. A property of a hash function is that it has an unpredictable output for an input. Therefore, this search can only be performed by brute force, thus consuming a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0025] The first blockchain node 104 that solves the puzzle publishes this to the network 106, providing the solution as a proof that other blockchain nodes 104 in the network can easily check (given the hash solution, it is easy to check that it matches the hash output). The first blockchain node 104 propagates the block to a threshold consensus of other nodes that accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to a previously created block 151n-1 in the chain. The significant amount of effort, e.g., in the form of a hash, required to create the proof-of-work solution signals the first node 104's willingness to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously validated transaction, otherwise known as a double-spend. Once created, blocks 151 cannot be modified because they are known and maintained by each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on blocks 151. This therefore provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106.

[0026] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of transactions 154 that are not yet published at any given time, depending on when they started looking for a solution or the order in which the transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unpublished transactions 154 is updated. The blockchain nodes 104 then compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There is also a protocol to resolve any "forks" that may occur, which is when two blockchain nodes 104 solve the puzzle within such a short time of each other that opposing views of the blockchain are propagated between the nodes 104. In essence, whichever branch of the fork grows the longest becomes the definitive blockchain 150. Note that this should not affect users or agents of the network when the same transaction appears in both forks.

[0027] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate a new additional accepted amount of digital assets in a new special type of transaction that distributes an additional defined amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers digital assets from one agent or user to another). This special type of transaction is usually referred to as a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." It typically forms the first transaction of a new block 151n. The proof of work signals the intention of the node constructing the new block to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a redemption period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and is explained below.

[0028] Due to the resources involved in validating and publishing transactions, typically at least each of the blockchain nodes 104 takes the form of a server including one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can also take the form of a user terminal or a group of networked user terminals.

[0029] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective one or more roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any activity attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0030] Also connected to the network 101 are computer devices 102 for each of a number of parties 103 who assume the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and payees in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or payees. For example, some parties may act as storage entities that store copies of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0031] Some or all of the parties 103 may be connected as part of a different network, for example a network overlaid on the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the necessary role of a blockchain node. Instead, each party 103 may interact with the blockchain network 106 by connecting (i.e., communicating) with a blockchain node 106, thereby utilizing the blockchain 150. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, although it will be understood that this is not intended to be limiting and that references herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0032] The computer equipment 102 of each party 103 comprises a respective processing device including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment 102 of each party 103 further includes a memory, i.e., a computer readable storage device in the form of a non-transitory computer readable medium. This memory may include one or more memory units employing one or more memory media, e.g., a magnetic medium such as a hard disk, an electronic medium such as a SSD, a flash memory, or an EEPROM, and / or an optical medium such as an optical disk drive. The memory on the computer equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 configured to execute on the processing device. It will be understood that any activity attributed to a given party 103 herein may be performed using software executed on the processing device of the respective computer equipment 102. The computer equipment 102 of each party 103 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing equipment 102 of a given party 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0033] The client application 105 may be initially provided on the computing equipment 102 of any given party 103 on a suitable computer-readable storage medium, for example downloaded from a server, or may be provided on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive, or the like.

[0034] The client application 105 has at least a "wallet" function. It has two main functionalities. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104 for subsequent propagation throughout the network of blockchain nodes 104 and thereby inclusion in the blockchain 150. The other is to report to each party the amount of digital assets it currently owns. In an output-based system, this second function involves reconciling amounts belonging to the party of interest as determined in the outputs of various transactions 152 scattered throughout the blockchain 150.

[0035] NOTE: Although various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and instead any client functionality described herein may instead be implemented as a set of two or more different applications, for example, interfaced via an API or plugged into one another. More generally, client functionality may also be implemented at the application layer, or at a lower layer such as an operating system, or any combination of these. While the following will describe client application 105, it will be understood that this is not limiting.

[0036] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or indeed to inspect the transactions of other parties in the blockchain 150, since in an embodiment the blockchain 150 is a public facility that provides trust to transactions in part through its public visibility). The wallet function on each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to a blockchain node protocol and forward transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol goes with a given node protocol and together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0037] When a given party 103, say Alice, wants to send a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction (using the wallet functionality of Alice's client application 105) according to the relevant transaction protocol. Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this could be the blockchain node 104 that is most connected to Alice's computer 102. When any given blockchain node 104 receives a new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j satisfies certain conditions to be "valid", examples of which will be explained in more detail shortly. In some transaction protocols, the conditions for validity checking may be configurable per transaction by a script included in the transaction 152. Alternatively, this condition could simply be a built-in feature of the node protocol or be defined by a combination of the script and the node protocol.

[0038] Provided that the newly received transaction 152j passes the test for being considered valid (i.e., it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j forward propagates the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, then, assuming the transaction 152j is valid, this means that it will be propagated throughout the network 106 immediately.

[0039] After being admitted into the ordered pool of pending transactions 154 maintained by a given blockchain node 104, that blockchain node 104 starts a race to solve a proof-of-work puzzle with the latest version of each pool 154 that contains the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different pools of transactions l54, but whoever gets there first defines the set of transactions included in the latest block 151. Eventually, the blockchain node 104 will have solved the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) After the proof-of-work is done for the pool 154 that contains the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 contains a pointer to the previous transaction, so the order of the transactions is also immutably recorded.

[0040] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views about which instance is "valid" before the instances are published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one not published in block 151).

[0041] An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of the account-based transaction model. In the account-based case, each transaction does not define the amount transferred by referencing the UTXO of the preceding transaction in the sequence of past transactions, but rather by referencing the absolute account balance. The current state of every account is stored and constantly updated by the nodes of the network, separate from the blockchain. In such a system, transactions are ordered using the running transaction tally (also called the "position") of the account. This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed in the transaction. This data field may point to a previous transaction, for example if a previous transaction ID is included in the data field.

[0042] 2. UTXO-based model FIG. 2 illustrates an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0043] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO) that may be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value that specifies an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also include, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also include a header 201 that may include indicators of the sizes of the input fields 202 and the output fields 203. The header 201 may also include the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

[0044] For example, Alice 103a wants to create a transaction 152j that transfers an amount of digital assets of interest to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". It takes the amount of digital assets locked to Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151, nor that Tx1 is the immediate next transaction in the pool 154. Tx1 can also refer to any preceding (i.e., previous) transaction that still has unspent outputs 203 locked to Alice.

[0045] The preceding transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 by the time Alice creates the new transaction Tx1, or at least sends it to the network 106. It may already be included in one of the blocks 151 at that time, or may still be waiting in the ordered set 154, in which case it will be included in the new block 151 soon. Alternatively, Tx0 and Tx1 may be created together and sent to the network 106 together, or Tx0 may even be sent after Tx1 if the node protocol allows for buffering of "orphan" transactions. The phrases "preceding" and "successor" as used herein in the context of a sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (which transactions point to which other transactions, etc.). They may equally be replaced with "predecessor" and "successor", or "predecessor" and "descendant", "parent" and "child", or the like. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, subsequent transactions (descendant transactions or "children") that point to a preceding transaction (the previous transaction or "parent") are not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a period of time to await its parent, depending on the node protocol and / or node behavior.

[0046] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, here labeled UTXO0. Each UTXO includes a value that specifies the amount of the digital asset represented by the UTXO, and a locking script that defines the conditions that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated and thus the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines unlocking conditions, including a condition that the unlocking script in the input of the subsequent transaction includes a cryptographic signature of the party to which the preceding transaction is locked.

[0047] A lock script (also called scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S) used in blockchain networks. A lock script specifies the information required to consume a transaction output 203, for example the requirements for Alice's signature. An unlock script appears within the output of a transaction. An unlock script (also called scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the criteria of the lock script. For example, this may include Bob's signature. An unlock script appears within the input 202 of a transaction.

[0048] Thus, in the illustrated example, UTXO0 in output 203 of Tx0 must have Alice's signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for a subsequent transaction attempting to redeem UTXO0 to be valid). A Requires lock script [Checksig P A ] is equipped. A ] is the public key P from Alice’s public-private key pair.A , a representation (i.e., a hash) of Tx1's UTXO0. Tx1's input 202 includes a pointer to Tx1 (e.g., with its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0 to identify it among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that contains Alice's cryptographic signature, created by Alice applying the private key from her key pair to a predefined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0049] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (where the conditions may include one or more criteria). In an embodiment, this involves concatenating the two scripts as follows: <Sig P A > <P A > || [Checksig P A ] Here, "||" represents concatenation, "<...>" means putting data on the stack, and "[...]" is a function that is constructed by the lock script (a stack-based language in this example). Equivalently, the scripts could be executed one after the other, with a common stack, rather than concatenating the scripts. Either way, when executed together, the scripts will create a lock script that contains Alice's public key P, as contained in the lock script in the output of Tx0. A, to authenticate that the unlock script in the input for Tx1 contains Alice's signature, signing the expected portion of the data. In order to perform this authentication, the expected portion of the data itself (the "message") must also be included. In an embodiment, the signed data includes the entirety of Tx1 (and thus there is no need to include a separate element specifying the signed portion of the data in plaintext, since it is already inherently present).

[0050] The details of authentication with public-private cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature to the message, so that anyone holding the public key can authenticate the signature. Thus, it should be noted that references herein to signing a particular data portion or part of a transaction, etc., may, in embodiments, mean signing a hash of that data portion or part of a transaction.

[0051] If the unlock script of Tx1 satisfies one or more conditions specified in the lock script of Tx0 (thus, in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to the ordered pool of pending transactions 154. The blockchain node 104 also forwards the transaction Tx1 to one or more other blockchain nodes 104 in the network 106, thereby propagating it throughout the network 106. After Tx1 is validated and entered into the blockchain 150, it defines Tx0 to UTXO0 as spent. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, a blockchain node 104 also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been spent (i.e., whether it already forms a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. Indeed, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 have been spent in which transactions 152, but what ultimately defines whether a UTXO has been spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

[0052] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another criterion for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0053] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. It is not possible to "leave" part of the amount defined in the UTXO as spent while another part is being spent. However, the amount from a UTXO may be split among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 in Tx0 may be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob all of the amount defined in UTXO0, she can use the remainder to give herself change in the second output of Tx1 or to pay another party.

[0054] In practice, Alice would also typically need to include a fee for any Bitcoin node 104 that successfully puts her transaction 104 into a block 151. If Alice does not include such a fee, Tx0 will be rejected by the blockchain node 104 and thus, although technically valid, will not be propagated and will not be included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept the transaction 152 if they do not want to do so). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, a pointer to UTXO0 is the only input to Tx1, which has only one output UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated (or consumed) by the node 104 that won the proof-of-work race to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively, or in addition, be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0055] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party's 103 assets are scattered throughout the UTXOs of various transactions 152 throughout the blockchain 150. There is no one number stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another onward transaction. This can be done by querying a copy of the blockchain 150 as stored in any of the Bitcoin nodes 104.

[0056] Note that script code is often expressed generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to express a particular function. "OP_..." refers to a particular opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of the lock script, creates a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

[0057] Typically, the input for a transaction is a public key P AIn an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs certain data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific parts of the outputs it signs depend on the SIGHASH flag, which is typically a four-byte code included at the end of the signature that selects which outputs are signed (and thus fixed at the time of signing).

[0058] The lock script may be referred to as a "scriptPubKey", referring to the fact that it typically includes the public key of the party for whom the respective transaction is locked. The unlock script may be referred to as a "scriptSig", referring to the fact that it typically provides a corresponding signature. However, more generally, in all applications of the blockchain 150, it is not essential that the condition for a UTXO to be redeemed includes authenticating the signature. More generally, the scripting language may be used to define any condition or conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0059] 3. Side Channels As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 120b, respectively, may include additional communication capabilities. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 allows for the exchange of data away from the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction (yet) being registered on the blockchain network 106 or progressing on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this manner is sometimes referred to as sharing a "transaction template." A transaction template may lack one or more inputs and / or outputs necessary to form a complete transaction. Alternatively, or in addition, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0060] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively, or in addition, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even over a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, the side channel 107 referenced anywhere herein may include any one or more links over one or more network technologies or communication media for exchanging data "off-chain," i.e., separate from the blockchain network 106. When multiple links are used, the bundle or collection of off-chain links may be referred to as the side channel 107 as a whole. Thus, it should be noted that when Alice and Bob are said to exchange some information or data or the like over the side channel 107, this does not necessarily imply that all pieces of these data must be transmitted over the exact same link or the same type of network.

[0061] 4. Node Software FIG. 3 illustrates an example of node software 450 executed by each blockchain node 104 of the network 106 in an example UTXO-based or output-based model. It should be noted that another entity may execute the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the actions required for a node 104. The node software 450 includes, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may execute node software including, but not limited to, all three of the following: a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 401 is typically configured to recognize various fields of the transaction 152 and process them according to the node protocol. Another prior transaction 152i (Tx m-1 ) output (e.g. UTXO). j ) is received, the protocol engine 451 j The protocol engine 451 identifies the unlock script in the Tx j Based on the pointer in the input of Tx i Identify and obtain Tx i may have been published to the blockchain 150, in which case the protocol engine may derive Tx from a copy of the block 151 of the blockchain 150 stored in the node 104. i Alternatively, you can get Tx i It is possible that Tx has not yet been published to the blockchain 150. In that case, the protocol engine 451 may select Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i In either case, the script engine 451 can obtain Tx iand passes it to the script engine 452.

[0062] Therefore, the script engine 452 has Tx i The lock script and the corresponding input Tx j The unlock script from the stack 453 is executed according to the stack-based scripting language being used (e.g., Script).

[0063] By executing the scripts together, script engine 452 determines whether the unlock script meets one or more criteria defined in the lock script (i.e., whether the lock script "unlocks" the output it is contained in). Script engine 452 returns the result of this determination to protocol engine 451. If script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns the result "true". Otherwise, it returns the result "false".

[0064] In the output-based model, a "true" result from the script engine 452 is one of the conditions for the validity of a transaction. Typically, one or more protocol-level conditions evaluated by the protocol engine 451 must also be satisfied. For example, Tx j The protocol engine 451 evaluates the results from the script engine 452 and one or more protocol-level conditions, and only if all are true, does it accept the transaction Txt.j The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. j Only on condition that Tx is actually validated, the decision engine 454 controls both the consensus module 455C and the propagation module 455P to j , for incorporation into a block 151. This includes having the consensus module 455C select the nodes' respective ordered transaction sets 154 to be tagged with Tx j and a propagation module 455P transmits the Tx j Optionally, in embodiments, the application-level decision engine 454 can apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine can choose to publish a transaction only on the condition that the transaction is valid and that sufficient transaction fees remain.

[0065] Also, the terms "true" and "false" here are not necessarily limited to returning a result represented in the form of a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" refers to any state that indicates success or a positive outcome, and "false" refers to any state that indicates failure or a non-positive outcome. For example, in an account-based model, a "true" outcome might be indicated by a combination of an implicit protocol-level validation of a signature and an additional positive output of a smart contract (if both individual outcomes are true, then the overall outcome is considered to indicate true).

[0066] 5. Time-locked UTXOs Timelock puzzles can be used to lock the UTXOs of a transaction stored on-chain to only become available (i.e. unlockable) after a certain amount of time has passed, as shown below.

[0067] Timelock puzzles require the user to perform an exact number of successive calculations, so parallelizing the solving process does not make the answer faster to find, and as a result, the solving time of the puzzle can be estimated in advance if the user's hardware is known.

[0068] Timelock puzzles can be used to build a chain of timelocked UTXOs, where solving one puzzle allows a user to solve the puzzle of the next UTXO. Chaining locked UTXOs ensures that no UTXO in the chain can be spent unless all puzzles of the previous UTXO in the chain are solved.

[0069] In this specification, the party that generates the puzzle is referred to as the "challenger," and the party that solves the puzzle to unlock the transaction is referred to as the "answer provider" or "puzzle solver."

[0070] 5.1 Time Lock Puzzle Solving a time lock puzzle requires the user to spend a certain amount of time. Because the puzzle is sequential in nature, parallelizing the computation does not make the solution faster. The time to solve a time lock puzzle can only be roughly controlled, because different computers have different processing power. It is advantageous for the time required to verify the solution to the puzzle to be significantly shorter than the time it takes to solve the puzzle.

[0071] Useful properties of time lock puzzles include: · Non-parallelizable: The solution cannot be obtained sooner than expected by distributing the puzzle across multiple machines or CPU cores. Efficient Verification: Verifying a solution to a puzzle should be significantly faster than solving the puzzle. - Fine-tune difficulty settings: Puzzle difficulty can be fine-tuned to various levels.

[0072] 5.1.1 Modular Square Puzzle One exemplary type of time-lock puzzle that is particularly useful in the practice of the present invention is the modular square puzzle.

[0073] The modular square puzzle is a time-lock puzzle in which the user needs to repeatedly calculate the square operation in the multiplicative group of integers modulo n = pq, where p and q are large prime numbers. This puzzle forms the basis of many time-lock puzzles. p and q are so large that they cannot be found from n. Usually, the length is 2048 bits, but other bit lengths can also be used. If the length is at least 2048 bits, strong security for the puzzle is guaranteed.

[0074] The algorithm for defining the modular square puzzle is as follows. ·SETUP(1 k ) → (params, secret): When given a security parameter k, generate a composite modulus n = pq with two randomly chosen large secret prime numbers p and q. Output params = (n) and secret = (p, q). The secret parameter k indicates the bit-length of the modulus n and may be equal to, for example, 2048. ·GENPUZ(t, params) → puz: Select a random a such that 1 < a < n. Output puz = (a, t) for t > 0, where t is the time parameter. ·FINDSOLN(puz, params) → sol:

Number

Number

[0075] The solution to the modular square puzzle is log2(2 t ) = t. The computation of the solution cannot be done in parallel because each step in the solution process depends on the previous step.

[0076] A verifier who knows φ(n)=(p-1)(q-1) can efficiently verify the solution.

number

[0077] For a user who does not know p and q, computing the squaring operations is significantly faster than computing φ(n), which proves to be as hard as factoring n. This ensures that a successful solver has performed all the repeated squaring operations.

[0078] The number of squares t required to solve a puzzle can be precisely controlled. This allows the challenger to create puzzles of varying difficulty. The control is linear in t, and if the modular speed of the user's squares is known, the solution time can be determined in advance. Suppose the challenger wants to create a time-locked puzzle that cannot be solved within T seconds, then t should be set such that t >= TS, where S is the modulo n number of squares the user can perform per second. If the user's speed is unknown, then a lower bound can be set based on current hardware capabilities, which we refer to as the minimum solution time.

[0079] Modular square puzzles are not publicly verifiable because efficiently verifying the solution requires knowledge of the secret information φ(n).

[0080] Other examples of time-lock puzzles include square-root based puzzles. Such puzzles can be used to time-lock transactions as presented herein. Modular square puzzles are preferred because they offer a wider range of time-lock periods and more tunable solutions.

[0081] 5.2 Time-locked UTXOs using modular square puzzles Time-locking puzzles, such as the modular square puzzle introduced above, can be used to time-lock a UTXO to a given time, where the given time is some minimal solution time T.

[0082] In the example provided herein, the challenger is a transaction Tx a The output of is locked for a given period of time.

[0083] 5.2.1 Standard configuration The challenger performs the following steps: 1. For the specified security parameter k, execute SETUP(1 k ) to generate (params, secret) and keep the value secret private. 2. Choose a time parameter t for the modular square puzzle and generate puz by calling GENPUZ(t). 3. Using the secret generated in step 1, compute φ(n)=(p-1)(q-1). 4. Use puz, params, and φ(n) to find the solution of the puzzle.

number

[0084] The challenger then generates a transaction with the first lock script that contains the hash of the solution, h(sol), and the puzzle parameters a, t, and n. The puzzle parameters are included in OP_RETURN so that the puzzle solver can compute the solution.

[0085] The initial lock script is associated with the first UTXO locked by the timelock puzzle and may only be used if the puzzle solver provides the solution to the puzzle in the initial unlock script of the answer transaction.

[0086] The challenger constructs the lock script as follows: Lock script: OP_HASH<h(sol)> OP_EQUALVERIFY OP_CHECKSIG OP_RETURN<puz=(a,t)><params=(n)>

[0087] The puzzle puz=(a,t) and parameters params=(t) are included in the script using OP_RETURN. Including t allows the user to estimate how long it will take to solve the puzzle and decide whether this effort is worth investing.

[0088] To spend a time-locked UTXO, a user must do so by calling FINDSOLN(puz, params).

number

[0089] The unlock script can be created as follows: Unlock script: <sig> <sol>

[0090] That is, the puzzle solver provides in the unlocking script a signature sig generated using his or her private key, the corresponding public key P, and the puzzle solution sol.

[0091] Here we assume that the challenger is honest. In fact, a malicious challenger might

number

[0092] Using this method, anyone who can compute the answer to the puzzle can redeem the funds. However, this structure is vulnerable to a "man-in-the-middle" (MITM) attack: an attacker can intercept the transaction containing the puzzle answer, replace the receiving address with their own, and sign the transaction with their own private key. They can then ensure that this modified transaction is published before the intercepted transaction, allowing them to steal funds that were redeemed by the legitimate puzzle solver.

[0093] To prevent MITM attacks, the public key specified in the unlock script is guaranteed to have a specific value h(P a ), a transaction can be sent to a specific address. However, this has the drawback that the transaction can only be sent to a specific address.

[0094] Figure 4 shows how the above structure can be used to timelock a UTXO.

[0095] The challenger provides a puzzle blockchain transaction Tx1 502A, which has the puzzle parameters 510 and an initial lock script 520A that contains a portion derived from the solution 508, here the hash of the solution h(sol). The solution provided by the challenger is called the target answer, sol T The target solution is calculated by the challenger using the large prime numbers p and q.

[0096] The puzzle parameters 510 may be provided in an OP_RETURN output to make the puzzle parameters 510 available to other users when the puzzle transaction Tx1 502A is committed to the blockchain. The OP_RETURN output is non-consumable. The puzzle parameters 510 may also be provided in a consumable output, for example, using OP_PUSH and OP_DROP.

[0097] The answer provider uses the puzzle parameters 510 provided in puzzle transaction Tx1502A to compute a solution in step A. The solution computed by the answer provider is called a candidate answer, sol C The answer provider must be able to solve the problem in at least the minimum solution time T.

number

[0098] The answer provider generates an answer transaction Tx2 504A and provides a candidate answer 506 with an initial unlock script 522A.

[0099] When the initial lock script 520A and the initial unlock script 522A are executed together, the initial lock script is configured to calculate a hash of the candidate answer 506 (step B), verify that the hash of the candidate answer equals the hash of the target answer (step C), and verify that the answer provider has correctly calculated the solution in at least the minimum computation time T.

[0100] If the hashes match, the answer provider can spend the UTXO associated with the first lock script 520A.

[0101] 5.2.2 P2PKH with Time-Locked Private Keys The following structure allows puzzle solvers to spend UTXOs locked in a modular square puzzle, while ensuring that the spend transaction cannot be modified before it is published to the blockchain.

[0102] A P2PKH script can be provided that prevents MITM attacks, allowing anyone to spend UTXOs locked in a modular square puzzle and send funds to a specific recipient at a time specified.

[0103] Therefore, the construction shown below ensures that a UTXO is not spent until at least the minimum resolution time has passed.

[0104] 5.2.2.1 Available to everyone The private key that can spend a UTXO is bound to the solution to a modular square puzzle, so that only users who have computed the solution to the puzzle can spend the UTXO, but anyone who originally computed the solution can spend the UTXO. By signing a spend transaction with a key bound to the solution to the puzzle, the spend transaction remains valid and cannot be modified by users who have not computed the solution.

[0105] In this construction, the lock script is a P2PKH and transactions are spent on sk G, where G is the elliptic curve generator, sk is a randomly generated private ECDSA key, and sk G is the corresponding public key. The private key sk is encrypted using a modular square puzzle so that it can only be decrypted after a predetermined amount of time:

number

[0106] In some embodiments,

number

[0107] Encrypted key C sk is included in the OP_RETURN data along with the puzzle puz=(a, t) and parameters params=(n), so that the private key sk can be derived.

[0108] To spend a UTXO, a user must obtain a solution to the puzzle.

number

[0109] The challenger generates a blockchain transaction using the first lock script corresponding to the first UTXO. The first UTXO contains the hash of the public key h(sk G), the puzzle parameters a, t, n, and the encrypted key C. sk The puzzle parameters and the encrypted key are contained in OP_RETURN so that the puzzle solver can compute the solution.

[0110] The lock script looks like this:

number

[0111] The puzzle solver derives a private key sk and uses it to generate a public key sk G, which is provided in the first unlock script of the solution transaction. The puzzle solver then derives a private key sk and uses it to generate a public key sk G, which is provided in the first unlock script of the solution transaction. sk The public key sk G is said to be derived from the solution, since sk is found using -sol mod n. The puzzle solver also provides a signature sig, which is generated using the derived private key sk. This ensures that the transaction cannot be modified by anyone who has not calculated the private key sk.

[0112] The unlock script looks like this: Unlock script: <sig><sk·G>

[0113] The locking script is configured to generate a hash of the provided public key sk·G and verify that it is equal to the hash h(sk·G) provided in the unlocking script.

[0114] The locking script is further configured to check that the signature provided in the unlocking script is correct and has been calculated using the private key sk.

[0115] This construction therefore allows anyone to spend time-locked UTXOs, and furthermore, the signatures ensure that spending transactions that have not yet been published to the blockchain cannot be modified by malicious actors who have not computed the solution to the puzzle.

[0116] Using this method, the solver of the puzzle cannot be identified from the unlocking script because the public key used to unlock the UTXO is the same for all users. In some embodiments, a public key append in the script is used to define that the user must include a public key in the unlocking script in addition to providing the solution to the puzzle.

[0117] Figure 5 shows how the above publicly spendable P2PKH structure is used to time-lock UTXOs.

[0118] The challenger receives the puzzle parameters 510, the encrypted key C sk 512, and a puzzle transaction Tx1 502B with a first lock script 520B that contains a portion derived from the solution 508 (here, a hash of the public key derived from the solution, h(sk G)). The private key provided by the challenger is called the target private key, sk T The target private key is calculated by the challenger using large prime numbers p and q.

[0119] The puzzle parameters 510 and the encrypted key 512 are provided to the OP_RETURN output when the puzzle transaction Tx1 502B is committed to the blockchain, making the puzzle parameters 510 available to other users.

[0120] The answer provider uses the puzzle parameters 510 provided in transaction Tx1502B to compute a solution in step A. The solution computed by the answer provider is called a candidate answer, and sol C The answer provider must be able to solve the problem in at least the minimum solution time T.

number

[0121] Next, the answer provider presents the candidate answer sol C and the encrypted key C sk 512 to find the candidate private key sk C (Step B). The candidate private key is sk C =C sk -sol C mod n. The answer provider then uses the candidate private key to derive the candidate public key sk C Generate G514 (Step C).

[0122] The answer provider generates an answer transaction Tx2504C and submits the candidate public key sk in the first unlocking script 522B. C ·G514 is provided.

[0123] When the initial lock script 520B and the initial unlock script 522B are executed together, the initial lock script 520B is configured to calculate a hash of the candidate public key 514 (step D), verify that the hash of the candidate public key equals the hash of the target public key (step E), and verify that the answer provider has correctly calculated the solution in at least the minimum computation time T.

[0124] The lock script 520B is a public key sk that is provided with a signature 518 in the unlock script 522B. C G is also configured to verify that it is correct with respect to step F. That is, the lock script uses sk to generate the signature sig518. C Verify that was used.

[0125] The answer provider also states that if the hashes match, i.e. sk C sk T and the signature 518 is the private key sk C If the UTXO associated with the first lock script 520B is calculated using

[0126] 5.2.2.2 Consumable by a Single User The above construction uses the public key P A For this purpose, the challenger can be adapted to transfer funds at a specific time to a specific recipient with (sk A +sol) G, where

number

[0127] Using the distributive law of elliptic curve scalar multiplication, the challenger can A Even if you don't know (sk A +sol)·G can be calculated. (sk A + sol)·G=sk A G + sol G=P A +sol·G

[0128] Thus, the challenger obtains the user's public key P A If you know the private key sk A UTXO can be locked to the corresponding user.

[0129] The challenger generates a blockchain transaction using the initial lock script that corresponds to the initial UTXO. The initial UTXO is the hash of the public key h((sk A + sol) G) and the puzzle parameters a, t, and n. The puzzle parameters are contained in OP_RETURN so that the puzzle solver can compute the solution. The puzzle solver has the secret key sk A Note that no encrypted keys are provided in this configuration since we know

[0130] The lock script looks like this: Lock script: 0P_DUP 0P_HASH <h((sk A +sol)·G)> 0P_EQUALVERIFY OP_CHECKSIG 0P_RETURN<puz=(a,t)><params=(n)>

[0131] The puzzle solver derives the solution sol and uses it to find the public key (sk A +sol) G, which is provided in the first unlock script of the solution transaction. The puzzle solver needs to find the solution to generate the public key, so the public key (sk A +sol)·G can be said to be derived from the solution. The puzzle solver also A To prove that you are the owner of and have derived the solution sol, you use your private key (sk A +sol) to provide the generated signature sig.

[0132] The unlock script looks like this: Unlock script: <sig><(sk A +sol)·G>

[0133] The lock script uses the provided public key (sk A +sol)·G is generated and converted to the hash h((sk A +sol) · G).

[0134] The lock script also verifies that the signature provided by the unlock script is correct and that the private key (sk A +sol) is used to check that the calculation is performed.

[0135] private key sk A Only a user who knows the secret key sk can calculate the solution sol of the puzzle and send it to the A You can spend UTXO by spending it using +sol.

[0136] Figure 6 illustrates the use of the above single-user usable P2PKH structure to time-lock UTXOs.

[0137] The challenger provides a puzzle blockchain transaction Tx1 502C, which includes the puzzle parameters 510 and a portion derived from the solution 508 (here, a hash of the public key derived from the solution, h((sk A There is an initial lock script 520C that contains p + solT) · G). The solution used to derive the private key provided by the challenger is called the target answer and is denoted by solT. The target answer is calculated by the challenger using large prime numbers p and q.

[0138] The puzzle parameters 510 are provided in OP_RETURN to make the puzzle parameters 510 available to other users when the puzzle transaction Tx1502C is committed to the blockchain.

[0139] The answer provider uses the puzzle parameters 510 provided in puzzle transaction Tx1502C to compute a solution in step A. The solution computed by the answer provider is called a candidate answer, and sol C The answer provider must provide a candidate answer within at least the minimum solution time T.

number

[0140] Next, the answer provider selects the candidate answer sol C and the private key sk A Calculate the candidate public key using (step B). The candidate public key is (sk A +sol C )·G.

[0141] The answer provider generates an answer transaction Tx2504C and submits the candidate public key (sk) in the first unlocking script 522C. A +sol C )·G516 is offered.

[0142] When the initial lock script 520C and the initial unlock script 522C are executed together, the initial lock script 520C is configured to calculate a hash of the candidate public key 516 (step C), verify that the hash of the candidate public key equals the hash of the target public key (step D), and verify that the answer provider has correctly calculated the solution in at least the minimum computation time T.

[0143] The lock script 520C is a public key (sk) that is provided with the signature 518 in the unlock script 522C. A +sol C )·G is also configured to check that it is correct (step E). That is, the lock script uses sk to generate the signature sig518. A +sol C Check that has been used.

[0144] The answer provider confirms if the hashes match, i.e. sol C is equal to solT, and the signature 518 is the private key sk A +sol C If the UTXO associated with the first lock script 520C is calculated using

[0145] 5.3 Time-locked puzzle chains Time-locked puzzles, such as modular square puzzles, can be used to create chains of puzzles, which allow for the creation of transaction chains or locked UTXOs. A time-locked transaction chain is a chain of transactions that are created by multiplying each transaction by a number of times, each time [t, ..., t N N transactions [Tx1, ..., Tx] that can only be spent in N ] is composed of.

[0146] 5.3.1 Anyone can consume it A chain of transactions is provided using linked successive modular square puzzles. Puzzles can be linked by setting the solution of one puzzle as a parameter that must be repeatedly squared in the next puzzle. Thus, only the first transaction in the chain needs to specify the value a. Finding the solution to the puzzle in transaction Txi allows the user to find the solution in the next transaction Tx. i +1 to solve the puzzle.

[0147] To create a puzzle chain, the challenger proceeds as follows: 1. For the specified security parameter k, execute SETUP(1 k ) to generate (params, secret) and keep the value secret private. 2. N time parameters t1, ..., t N Select t to determine the solution time for each puzzle (optionally choose t to be the same for all puzzles). 3. Call GENPUZ(t1) to generate the first puzzle puz=(a, t1). 4. Calculate φ(n)=(p-1)(q-1) using the secret generated in step 1. 5. Solution using puz and params

number

number

number

[0148] Before publishing all N transactions on the blockchain, the challenger must create a transaction Tx i The OP_RETURN data contains the puzzle time parameter t i (plus the value a of the first transaction Tx1), parameters params=(n), and the encrypted private key

number

[0149] The address h(sk) where the next UTXO can be spent in the chain i+1 G), so that users know the next transaction in the chain, and therefore can derive the complete chain of transaction IDs from the first transaction in the chain.

[0150] A time parameter t included in each transaction i Using the , the user can estimate how long it will take to solve each puzzle and thereby complete the entire puzzle chain.

[0151] The lock and unlock script for the first transaction, Tx1, is as follows: Lock script:

number

[0152] The lock and unlock scripts for the i-th transaction Txi are as follows: Lock script:

number

[0153] Note that the locking script for each transaction i>1 does not contain the puzzle parameter a. Instead, the set of puzzle parameters provided consists only of t1 and n1. This means that the solution sol i When calculating the puzzle parameter a, we use the previous puzzle parameter sol i-1 This is because the solution is squared.

[0154] The private keys sk1...sk needed to spend the UTXOs on the chain N To derive, the user needs to calculate the following values ​​in order:

number

[0155] From the recursive structure of the puzzle chain, sol i To calculate j <iのすべてのsol j Therefore, only the user who has calculated the solutions to all puzzles in the chain can make the final transaction Tx N can be consumed.

[0156] The puzzle chain construction is performed over a time parameter t hard_puzzle We consider a single difficult puzzle with time parameters t1,...,t N into N sub-puzzles with

number

[0157] Figure 7 shows how to extend the use of a P2PKH structure that anyone can consume to time-lock the UTXO shown in Figure 5 to the time-lock of the transaction chain. It can be seen that it is not the transaction itself that is time-locked, but the UTXO of the transaction.

[0158] The challenger provides the first transaction Tx1 with the solution to the first time-lock puzzle sol1 and the first set of parameters a, t1, and n1 corresponding to the first encryption key C in OP_RETURN. The lock script also includes the hash derived from the solution of the first time-lock puzzle (here h(sk1·G)) and the hash derived from the solution of the second time-lock puzzle (here h(sk2·G)). sk1 The challenger also generates subsequent transactions for each Tx where 2 ≦ i ≦ N, where N is the total number of transactions in the chain. Each of these transactions includes a lock script that provides the second set of puzzle parameters t, n corresponding to the i-th solution of the i-th time-lock puzzle sol, and the i-th encryption key C in OP_RETURN. The lock script also includes the hash derived from the solution of the i-th time-lock puzzle (here h(sk·G)). For each Tx where 2 ≦ i < N, OP_RETURN also includes the hash derived from the solution of the (i + l)-th time-lock puzzle (here h(sk·G)).

[0159] The challenger also generates subsequent transactions for each Tx where 2 ≦ i ≦ N, where N is the total number of transactions in the chain. Each of these transactions includes a lock script that provides the second set of puzzle parameters t, n corresponding to the i-th solution of the i-th time-lock puzzle sol, and the i-th encryption key C in OP_RETURN. The lock script also includes the hash derived from the solution of the i-th time-lock puzzle (here h(sk·G)). For each Tx where 2 ≦ i < N, OP_RETURN also includes the hash derived from the solution of the (i + l)-th time-lock puzzle (here h(sk·G)). i に対して後続のトランザクションを生成し、ここで、Nはチェーン内のトランザクションの総数である。これらのトランザクションの各々は、i番目のタイムロックパズルsol i のi番目の解に対応する、2番目のパズルパラメータt i 、n i のセット、およびOP_RETURN内のi番目の暗号化鍵C ski を提供するロックスクリプトを含む。ロックスクリプトはまた、i番目のタイムロックパズルの解から導出されたハッシュ(ここではh(sk i ·G))を含む。2≦i<Nの各Tx i に対して、OP_RETURNはまた、(i+l)番目のタイムロックパズルの解から導出されたハッシュ(ここではh(sk i+1 ·G))を含む。

[0160] トランザクションTx i はブロックチェーンにコミットされる。この実施形態では、正しい解を計算すれば、どのパズル解答者でもUTXOのロックを解除できることに留意されたい。

[0161] The puzzle solver uses the first set of parameters provided in the first transaction Tx1 to calculate the first solution sol1. The puzzle solver then receives the first solution sol1 and the first encryption key C provided in the first transaction Tx1. sk1 to derive the initial private key sk1.

[0162] The puzzle solver generates a hash of the public key derived from the initial private key h(sk1 G). The puzzle solver then issues an initial spend transaction Tx that contains the unlock script containing the public key sk1 G. S1 Generate.

[0163] Tx S1 The public key provided in the unlock script of is checked against the hash provided in the lock script of Tx1 to verify that the puzzle solver has correctly calculated the solution, and S1 The signature provided with the unlock script is checked to verify that it was generated from the private key sk1.

[0164] Once the puzzle solver has computed the first solution, sol1, they can use sol1 and a second set of puzzle parameters provided in a second transaction, Tx2, to compute the solution to the second time-locked puzzle, sol2. The second solution, sol2, is calculated using the second encryption key, C sk2 to derive the second private key, sk2.

[0165] The puzzle solver then uses the second private key sk2 to make the second spend transaction, Tx S2 Generate an unlock script.

[0166] The puzzle solver is sol N Calculate this sk N Nth consumption transaction Tx SN Each transaction Tx i This procedure is repeated for

[0167] Each transaction Tx i defines the amount of digital assets that will be transferred to the puzzle solver to provide the solution corresponding to that transaction.

[0168] Next Time Lock Puzzle h(sk i+1 The hash derived from the solution of G) is i It is provided in the lock script, but it is understood that the hash can also be sent off-chain. The purpose of providing this hash to the puzzle solver, whether in the transaction lock script or off-chain, is to allow the puzzle solver to identify the next transaction in the chain.

[0169] It can be seen that the amount locked by the locking script in each transaction may also include an amount sufficient to cover the transaction fee of the consuming transaction, or the puzzle solver may be required to pay a transaction fee when providing the transaction.

[0170] 5.3.2 Consumable by a Single User In the puzzle chain construction described above, anyone can consume UTXOs in the chain. This can be done by using the idea described in Section 5.2.2.2 with the public key PA=sk A We can change it so that a single user with G can spend any UTXO on the chain.

[0171] Therefore, the challenger must i (sk A +sol i ) G, where:

number

number

[0172] The lock and unlock script for the first transaction, Tx1, is as follows: Lock script: 0P_DUP 0P_HASH <h((sk A +sol1)·G)> 0P_EQUALVERIFY OP_CHECKSIG 0P_RETURN <puz=(a,t1)><params=(n)><h((sk A +sol2)·G)> Unlock script: <sig><(sk A +sol1)·G>

[0173] i-th transaction Tx i The lock and unlock scripts are: Lock script: OP_DUP OP_HASH <h((sk A +sol i )·G)> OP_EQUALVERIFY OP_CHECKSIG 0P_RETURN <t i > <params=(n)><h((sk A +sol i +1)·G)> Unlock script: <sig><(sk A +sol i )·G>

[0174] The private key sk A Only the user who knows the solution sol i of the puzzle can calculate the solution sol A +sol i of the consumption transaction by signing the consumption transaction with sk

[0175] As shown with reference to FIG. 8, FIG. 6 shows how a single user consumes a P2PKH structure to time-lock a UTXO and make it usable in a transaction chain. It can be seen that it is the UTXO of the transaction that is time-locked, not the transaction itself.

[0176] The challenger provides the first transaction Tx1 with the first set of parameters a, t1, and n1 corresponding to the solution of the first time-lock puzzle sol1 within the OP_RETURN output. The lock script also includes the hash derived from the solution of the first time-lock puzzle (here h((sk A +sol1)·G)), where sk A is the private key of the defined puzzle solver, and also includes the hash derived from the solution of the second time-lock puzzle (here h((sk A +sol2)·G)).

[0177] The challenger also generates subsequent transactions for each Tx i where 2 ≤ i ≤ N. Each of these transactions is composed of a lock script that provides the second set of parameters t i and n i corresponding to the solution of the i-th time-lock puzzle sol i in the OP_RETURN output. The lock script also includes the hash derived from the solution of the i-th time-lock puzzle (here h((sk A +sol i )·G)). For each Tx where 2 ≤ i < N i For i+l, OP_RETURN also returns the hash (here h((sk A +sol i Includes +1)·G)).

[0178] TransactionTx i is committed to the blockchain.

[0179] sk A The puzzle solver, the owner of T, computes the first solution, sol1, using the first set of parameters provided in the first transaction, Tx1.

[0180] The puzzle solver has the secret key sk A and the first solution sol1, (sk A +sol1) G. The puzzle solver generates a public key derived from (sk A +sol1) First spending transaction Tx containing the unlock script containing G S1 Generate.

[0181] Tx S1 The public key provided in the unlock script is checked against the hash provided in the lock script in Tx1 to verify that the puzzle solver has correctly calculated the solution, and the signature provided in the unlock script is also verified using the private key (sk A +sol).

[0182] Once the puzzle solver has calculated the first solution, sol1, they can now use sol1 and a second set of puzzle parameters provided in the lock script of a second transaction, Tx2, to calculate the solution to the second time-locked puzzle, sol2.

[0183] The puzzle solver uses the second solution, sol2, to make a second spend transaction, Tx S2 Generate an unlock script.

[0184] The puzzle solver makes the Nth spending transaction Tx SN sol to provide to the unlock script N For each transaction Tx i This procedure is repeated for

[0185] As mentioned above, the following time lock puzzle h(sk i+1 The hash derived from the solution to G) may be sent off-chain to the puzzle solver, rather than being provided in the transaction locking script.

[0186] As described with reference to FIG. 7, each transaction Tx i Transaction Tx i defines the amount of digital assets that will be sent to the puzzle solver for solving the puzzle provided by sk. Here, the puzzle solver A Please note that the owner of this document is

[0187] A time-locked puzzle chain that can be consumed by a single user can be used, for example, to implement fixed income securities, such as fixed-rate bonds. A fixed-rate bond is a bond that pays the same level of interest for its entire term. The issuer of the bond can create a chain of transactions that pay back the holder. Since the transactions are time-locked in the chain, the holder can only claim the coupons periodically in order. At the maturity of the bond, the holder receives the first principal from the last UTXO of the chain. This solution requires the continuous calculation of the answer to the puzzle over a very long period of time, as the bond may mature over decades. The calculation can be outsourced to an external server that performs the calculation on behalf of the owner. Even if the external server learns the answer to the puzzle, it is guaranteed that it cannot spend the time-limited transactions, as this would require knowledge of the owner's private key.

[0188] 5.3.3 Chained UTXOs The method provided above for chaining transactions can be modified to chain the outputs of a single transaction, so that each output of a transaction can only be used after the solution for the previous output in the chain has been computed.

[0189] Figure 9 shows an example of a transaction that includes a chained UTXO. The UTXO in this example is available to any solution provider who correctly computes the solution to the time puzzle. However, it will be appreciated that the UTXO can also be locked so that it is available to only one user, following the methods described in Section 5.3.2.

[0190] A chain puzzle transaction Tx containing a set of outputs C is provided by the challenger. Each output locks a certain amount of digital assets with a lock script. The lock script defines a set of puzzle parameters and an encryption key. The set of puzzle parameters and the encryption key can be included in the OP_RETURN output. The unlock script provides the solution sk i · Have a public key derived from G.

[0191] For i=1, the set of puzzle parameters includes a, n1, and t1, and for i>1, the set of puzzle parameters includes n i and t i contains the solution sol from the previous output in the chain i-1 Solved i This is because it is used to calculate

[0192] The puzzle solver uses the information provided in the OP_RETURN output to create a solution transaction, Tx Si To generate an unlock script for each of the set of i and the private key sk i Each spend transaction is a chain transaction Tx C This corresponds to one of the time-locked outputs.

[0193] For each output i>1, the puzzle solver returns the solution sol corresponding to the previous output in the chain, together with the puzzle parameters provided in the OP_RETURN output. i-1 Using the solution sol i and calculate the unlock script for the i-th answer transaction.

[0194] Therefore, the puzzle solver must compute the answer transactions in sequence, such that each UTXO in a chain transaction is consumed only after a different, and successively larger, minimum solution time. α If we provide, then all outputs for i>α remain locked, but outputs for i≦α can be or have been consumed.

[0195] Providing the chained outputs in a single chain transaction reduces the storage requirements resulting from the puzzle chain compared to the approach provided in Sections 5.3.1 and 5.3.2, where each chained UTXO is provided in a different transaction.

[0196] 5.3.4 Template Puzzle Transactions The chained transactions described above with reference to Figures 7 and 8 can also be provided in a link set of chained transactions. Figure 11 shows an example of such a link set using a method that anyone can use. It will be appreciated that this method can be modified to allow a method that can be used by a single user.

[0197] The challenger sends in the first transaction Tx1 an initial set of parameters a, t1, and n1 corresponding to the solution sol1 of the first time-lock puzzle, and an initial encryption key C for OP_RETURN. sk1 Provide a lock script. The lock script also includes a hash derived from the solution of the first time-lock puzzle, here h(sk1·G).

[0198] The challenger also generates a template transaction for each Tx where 2 ≦ i < N, where N is the total number of transactions in the chain. Each of these transactions has a second puzzle parameter t i corresponding to the i-th solution sol of the i-th time-lock puzzle, i and a set of n i and the i-th encryption key C i within OP_RETURN, and includes a lock script that provides the lock script. The lock script also includes a hash (here h(sk ski ·G)) derived from the solution of the i-th time-lock puzzle. i ·G)).

[0199] The first transaction Tx1 is committed to the blockchain and the template transactions become available to one or more puzzle solvers. Note that in this embodiment, any puzzle solver can unlock the UTXO if they calculate the correct solution.

[0200] The puzzle solver uses the first parameter set provided in the first transaction Tx1 to calculate the first solution sol1. Next, the puzzle solver uses the first solution sol1 and the first encryption key C sk1 provided in the first transaction Tx1 to derive the first secret key sk1.

[0201] The puzzle solver uses the first secret key to generate the public key sk1·G. The puzzle solver uses the second transaction of the template to generate a second transaction Tx2 that includes the lock script provided by the challenger in the template transaction and an unlock script that includes the public key sk1·G.

[0202] The public key provided in Tx2's unlock script is checked against the hash provided in Tx1's lock script to verify that the puzzle solver correctly calculated the solution, and the signature provided in the unlock script is checked to verify that it was generated using the private key sk1.

[0203] Once the puzzle solver has calculated the first solution, sol1, they can use sol1 and a second set of puzzle parameters provided in the lock script of a second transaction, Tx2, to calculate the solution to the second time-locked puzzle, sol2. The second solution, sol2, is calculated using the second encryption key, C sk2 is used together with sk2 to derive the second private key, sk2.

[0204] The puzzle solver uses the second private key sk2 to generate an unlock script for the third transaction Tx3, which includes the lock script defined by the challenger in the template for the third transaction.

[0205] The puzzle solver is sol N-1 Calculate this sk N-1 Nth transaction Tx N Each transaction Tx i This procedure is repeated for

[0206] For a puzzle solver to know the order of transactions, the hash obtained from the next solution in the chain can be provided in the locking script of the template transaction, as shown in Figures 7 and 8. Alternatively, the order can be conveyed by associating each template transaction with an index that corresponds to its order in the chain.

[0207] The initial transaction Tx1 defines the total amount of digital assets transferred to the puzzle solvers across the entire puzzle chain. In each template transaction where 1 < i < N, the lock script provided by the challenger is associated with the amount of digital assets locked in the transaction, i.e., the amount transferred to the puzzle solvers.

[0208] For example, Tx1 defines the total amount of digital assets x1. The template for Tx2 defines that the amount x2 = x1 - y1 is locked by the lock script of Tx2, where y1 is the amount of digital assets allocated to the puzzle solver to compute sol1. Similarly, the template for Tx3 defines that the amount x3 = x1 - y1 - y2 is locked by the lock script of Tx3.

[0209] The puzzle solver also provides an additional output when generating each transaction from the template transaction that pays the amount y i The amount of digital assets locked by the lock script of each transaction may also include an amount sufficient to cover the transaction fee. Alternatively, the puzzle solver may need to pay the transaction fee when providing the transaction.

[0210] The amount of digital assets locked in the second - last transaction Tx N-1 is equal to the final amount transferred to the puzzle solver.

[0211] It should be understood that the amount locked by the lock script of each transaction may also include an amount sufficient to cover the transaction fee. Alternatively, the puzzle solver may need to pay the transaction fee when providing the transaction.

[0212] However, there is no guarantee that the user will not break the transaction chain by changing the template. This can be overcome by using the pseudocode PUSHTX, which ensures that the transaction Tx i is the next transaction Tx in the chain i+1 This enforces that the chain can only be used by challengers, while allowing challengers to publish their complete chain on the blockchain.

[0213] 5.4 General methods Figure 10 shows an example of how to implement time-locked UTXOs as described above.

[0214] In step 1, the challenger 602 randomly selects p and q, and calculates n from these values ​​to set up the puzzle. The challenger 602 also randomly selects a parameter a and determines an appropriate time parameter t. The challenger 602 uses p, q, a, and t to

number

[0215] In step 2, the challenger 602 generates a hash derived from the solution to the time-lock puzzle. Various variations of this hash are shown above, with the hashed value depending at least in part on who is eligible to spend the UTXO, i.e., anyone who can pay, or just one person who can pay. In some embodiments, the challenger 602 defines a private key sk in step 2 and encrypts this private key with the solution, resulting in an encryption key C. sk Generate.

[0216] In step 3, the challenger 602 generates a puzzle transaction Tx1 502, in which the challenger 602 provides the puzzle parameters n, a, and t and a hash derived from the solution to the time-lock puzzle in the lock script.

[0217] In step 4, the challenger 602 makes the transaction Tx1 available to one or more nodes of the blockchain 606 for committing to the blockchain 606.

[0218] In step 5, the puzzle solver 604 retrieves from the blockchain 606 the puzzle parameters n, a, and t, as well as any other information provided in the OP_RETURN output, such as the encryption key C, if provided. sk and get.

[0219] In step 6, the puzzle solver 604

number

[0220] In step 7, the puzzle solver 604 uses a pre-image of the hash derived from the solution to generate an unlock script for the solution transaction Tx2504.

[0221] The answer transaction Tx2504 is sent to one or more nodes of the blockchain 606 for commitment to the blockchain 606 in step 8.

[0222] In some embodiments, multiple puzzle solvers 604 may attempt to solve a puzzle and subsequently provide an answer transaction 504. Only the first answer transaction provided, which contains a pre-image of the hash corresponding to the solution, is committed to the blockchain.

[0223] 6. Further claims Other variations or uses of the disclosed techniques will be apparent to those of ordinary skill in the art upon reading the disclosure herein, and the scope of the disclosure is not limited by the described embodiments, but only by the scope of the appended claims.

[0224] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may be generally applied to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain. More generally, references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

[0225] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the aforementioned functions of creating, publishing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and publishing them (note that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0226] In other embodiments of the invention, the blockchain network 106 may not be the Bitcoin network. These embodiments do not preclude a node from performing at least one or some (but not all) of the functions of creating, publishing, propagating, and storing blocks 151 of the blockchain 150. For example, in other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151, but is configured not to store and / or propagate those blocks 151 to other nodes.

[0227] More generally, references above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above with reference to blockchain nodes 104.

[0228] It will be understood that the above embodiments have been described by way of example only. More generally, a method, an apparatus, or a program may be provided according to any of the following statements:

[0229] Statement 1. A computer-implemented method for generating puzzle blockchain transactions, comprising: providing an initial lock script for the puzzle blockchain transaction, the initial lock script corresponding to a first unspent transaction output and including a hash value derived from a target solution to the timelock puzzle and a set of puzzle parameters for the timelock puzzle, the target solution being calculated using the set of secret puzzle parameters, the timelock puzzle being solvable using the set of puzzle parameters in a time equal to or greater than a minimum solving time, the set of puzzle parameters not including the set of secret puzzle parameters, and the lock script: configured to validate a candidate answer provided in the first unlocking script of the answer blockchain transaction based on a hash value calculated using a set of puzzle parameters when executed with the first unlocking script of the answer blockchain transaction; making the puzzle blockchain transaction available to one or more nodes of a blockchain network.

[0230] Statement 2. The method of statement 1, wherein the hash value is a hash of a public key derived using a target answer to a time lock puzzle.

[0231] Statement 3. The method of statement 2, wherein the public key is derived from the private key, and the private key is derived from the public key of a given recipient and the target answer.

[0232] Statement 4. The method of statement 3, wherein the private key is the sum of the intended recipient's private key and the target answer.

[0233] Statement 5. The method of statement 2, wherein the public key is derived from a private key, the private key being a randomly generated private key, and the method further comprising the step of randomly generating the private key.

[0234] Statement 6. The method of statement 5, wherein the method further comprises the step of encrypting the private key based on the target answer.

[0235] Statement 7. The method of statement 6, wherein the initial lock script further includes an encrypted private key for making available when the puzzle blockchain transaction is committed to the blockchain.

[0236] Statement 8. The method of any one of statements 1-7, wherein the first lock script further has a second hash value, the second hash value derived from a second target answer to the second timelock puzzle and a second set of puzzle parameters for the second timelock puzzle and corresponds to a second unspent transaction output, the second unspent transaction output corresponding to the second lock script having the second hash value.

[0237] Statement 9. The method of statement 8, wherein the second unspent transaction output and the second lock script are provided in a second puzzle blockchain transaction.

[0238] Statement 10. The method of statement 8, wherein the second unspent transaction output and the second lock script are provided in a puzzle blockchain transaction.

[0239] Statement 11. The method of any statement that cites statement 8 or statement 2, wherein the second hash value is a hash of a second public key derived using the target answer to a second time lock puzzle.

[0240] Statement 12. A computer-implemented method for generating an answer blockchain transaction for unlocking a time-locked unspent transaction output of a puzzle blockchain transaction, comprising: the puzzle blockchain transaction includes an initial lock script of the puzzle blockchain transaction, the initial lock script corresponds to a first unspent transaction output and includes a hash value derived from a target solution to the timelock puzzle and a set of puzzle parameters for the timelock puzzle, the target answer is calculated using the set of secret puzzle parameters, the timelock puzzle is solvable using the set of puzzle parameters in a time equal to or greater than a minimum solving time, the set of puzzle parameters does not include the set of secret puzzle parameters, and the method comprises: generating candidate solutions to the time lock puzzle based on a set of puzzle parameters; providing a portion derived from the candidate answer to an initial unlocking script of the answer blockchain transaction; making the answer blockchain transaction available to one or more nodes of a blockchain network; A method comprising:

[0241] Statement 13. The method of statement 12, wherein the portion derived from the candidate answer is a public key derived using the candidate answer.

[0242] Statement 14. The method is generating a public key, the public key being generated using the candidate answer and a private key of a user generating the candidate answer; deriving a public key using the generated private key; generating a signature using the private key; Provide a signature for the unlock script and The method of claim 13, further comprising:

[0243] Statement 15. The first lock script of the puzzle blockchain transaction further includes an encrypted private key, the encrypted private key being a randomly generated private key encrypted based on the target answer, and the method further comprises: determining a private key based on the candidate answers and the encrypted private key; deriving a public key using the determined private key; generating a signature using the private key; Provide a signature for the unlock script and The method of claim 13, further comprising:

[0244] Statement 16. The first lock script of the puzzle blockchain transaction further includes a second hash value, the second hash value being derived from a second target answer of the second timelock puzzle and a second set of puzzle parameters of the second timelock puzzle and corresponding to a second unspent transaction output, the second unspent transaction output corresponding to the second lock script having the second hash value, and the method further comprises: obtaining a second candidate solution for the second time lock puzzle based on the second set of puzzle parameters and the candidate solution for the time lock puzzle; providing a second part derived from the second candidate answer to a second unlocking script of the second answer blockchain transaction; Making the blockchain transaction available to one or more nodes in the blockchain network; The method according to any one of statements 12 to 15, further comprising:

[0245] Statement 17. The method of statement 16 referencing statement 14 or 15, wherein the second part's private key is derived from the second candidate answer.

[0246] Statement 18. The method of any one of statements 1 to 13, wherein the time lock puzzle is a modular square puzzle.

[0247] Statement 19. The candidate answer is

number

[0248] Statement 20. The method of statement 19, wherein the puzzle parameter n is defined by modulus n=pq, where p and q are large prime numbers.

[0249] Statement 21. The target answer is

number

[0250] Statement 22. The method of statement 19 or any statement quoting statement 19, wherein the encrypted transaction encryption key is defined by Ck=K+sol mod n.

[0251] Statement 23. The method of statement 19 or any statement citing statement 8 or 16, wherein the second set of puzzle parameters includes puzzle parameters t and n, puzzle parameter a is not included in the second lock script, and the candidate answer to the time lock puzzle is used as puzzle parameter a when generating candidate answers to the second time lock puzzle.

[0252] Statement 24. A memory having one or more memory units; A computing device comprising: a processing device having one or more processing units; wherein the memory stores code arranged to operate on the processing device, the code being configured to execute a method according to any one of statements 1 to 23 when executed on the processing device.

[0253] Statement 25. A computer program embodied on a computer readable storage configured to, when executed on one or more processors, perform the method of any one of statements 1 to 23. [Explanation of symbols]

[0254] 100 Systems 101 Packet Switching Network 102 Computer terminals 103 User, Parties 104 Blockchain nodes 105 Client Applications 107 Side Channel 150 Blockchain 151 Blocks of Data 151n Block 151n-1 Block 152 Transactions 152i Transactions 152j Transaction 153 Genesis Block (Gb) 155 Block Pointer 201 Header 202 Input 203 Output< / sig> < / sig> < / sig> < / sig> < / sig> < / sig> < / sol> < / sig>

Claims

1. 1. A computer-implemented method for generating puzzle blockchain transactions, comprising: providing an initial lock script for the puzzle blockchain transaction, the initial lock script corresponding to a first unspent transaction output and including a hash value derived from a target solution to a timelock puzzle and a set of puzzle parameters for the timelock puzzle, the target solution being calculated using a set of secret puzzle parameters, the timelock puzzle being solvable using the set of puzzle parameters in a time equal to or greater than a minimum solving time, the set of puzzle parameters not including the set of secret puzzle parameters, and the lock script: configured to validate a candidate answer provided in the first unlocking script of the answer blockchain transaction based on the hash value calculated using the set of puzzle parameters when executed with the first unlocking script of the answer blockchain transaction; making the puzzle blockchain transaction available to one or more nodes in a blockchain network; A method comprising:

2. The method of claim 1 , wherein the hash value is a hash of a public key derived using the target solution to the time lock puzzle.

3. 3. The method of claim 2, wherein the public key is derived from a private key, the private key being derived from a public key of a given recipient and the target answer.

4. 4. The method of claim 3, wherein the private key is the sum of the private key of the given recipient and the target answer.

5. 3. The method of claim 2, wherein the public key is derived from a private key, the private key being a randomly generated private key, the method further comprising the step of randomly generating the private key.

6. The method of claim 5 , further comprising the step of encrypting the private key based on the target solution.

7. 7. The method of claim 6, wherein the initial lock script further includes an encrypted private key for making available when the puzzle blockchain transaction is committed to a blockchain.

8. 8. The method of claim 1, wherein the first lock script further has a second hash value, the second hash value derived from a second target solution to a second timelock puzzle and a second set of puzzle parameters for the second timelock puzzle and corresponds to a second unspent transaction output, the second unspent transaction output corresponding to a second lock script having the second hash value.

9. 9. The method of claim 8, wherein the second unspent transaction output and the second lock script are provided in a second puzzle blockchain transaction.

10. 9. The method of claim 8, wherein the second unspent transaction output and the second lock script are provided in the puzzle blockchain transaction.

11. A method according to claim 8 or any claim that recites claim 2, wherein the second hash value is a hash of a second public key derived using the target solution to the second time lock puzzle.

12. 1. A computer-implemented method for generating an answer blockchain transaction for unlocking a time-locked unspent transaction output of a puzzle blockchain transaction, comprising: the puzzle blockchain transaction includes an initial lock script of the puzzle blockchain transaction, the initial lock script corresponding to a first unspent transaction output and including a hash value derived from a target solution to a timelock puzzle and a set of puzzle parameters for the timelock puzzle, the target solution is calculated using a set of secret puzzle parameters, the timelock puzzle is solvable using the set of puzzle parameters in a time equal to or greater than a minimum solving time, and the set of puzzle parameters does not include the set of secret puzzle parameters; and the method comprises: generating candidate solutions to the time lock puzzle based on the set of puzzle parameters; providing a portion derived from the candidate answer to an initial unlock script of the answer blockchain transaction; making the answer blockchain transaction available to one or more nodes of a blockchain network; A method comprising:

13. The method of claim 12 , wherein the portion derived from the candidate answer is a public key derived using the candidate answer.

14. The method further comprising: generating a public key, the public key being generated using the candidate answer and a private key of a user generating the candidate answer; deriving the public key using the generated private key; generating a signature using the private key; providing said signature to said unlock script; The method of claim 13, further comprising:

15. The first lock script of the puzzle blockchain transaction further includes an encrypted private key, the encrypted private key being a randomly generated private key encrypted based on the target answer, and the method further comprises: determining the private key based on the candidate answers and the encrypted private key; deriving the public key using the determined private key; generating a signature using the private key; providing said signature to said unlock script; The method of claim 13, further comprising:

16. the first lock script of the puzzle blockchain transaction further includes a second hash value, the second hash value being derived from a second target answer of a second timelock puzzle and a second set of puzzle parameters of the second timelock puzzle and corresponding to a second unspent transaction output, the second unspent transaction output corresponding to a second lock script having the second hash value, and the method further comprises: deriving a second candidate solution to the second time lock puzzle based on the set of second puzzle parameters and the candidate solution to the time lock puzzle; providing a second unlocking script of a second solution blockchain transaction with a second portion derived from the second candidate solution; making the second answer blockchain transaction available to one or more nodes in a blockchain network; The method of any one of claims 12 to 15, further comprising:

17. 17. A method according to claim 16 when dependent on claim 14 or 15, wherein the private key of the second part is derived from the second candidate answer.

18. The method according to any one of claims 1 to 13, wherein the time lock puzzle is a modular square puzzle.

19. The candidate answer is, [0010] 20. The method of claim 18, wherein a, t, and n are puzzle parameters and 1<a<n and t>0.

20. 20. The method of claim 19, wherein the puzzle parameter n is defined by modulus n=pq, where p and q are large prime numbers.

21. The target answer is: [0025] where φ(n)=(p−1)(q−1) and the set of secret puzzle parameters includes p and q.

22. The encrypted transaction encryption key is k 20. A method according to claim 19 or any claim dependent thereon, wherein n is defined by: = K+sol mod n.

23. A method according to claim 19 or any claim dependent on claim 8 or 16, wherein the set of second puzzle parameters includes puzzle parameters t and n, and puzzle parameter a is not included in the second time lock script, and the candidate solution to the time lock puzzle is used as puzzle parameter a when generating the candidate solution to the second time lock puzzle.

24. a memory having one or more memory units; A computing apparatus comprising: a processing unit having one or more processing units, the memory storing code arranged to run on the processing unit, the code being configured to perform the method of any one of claims 1 to 23 when executed on the processing unit.

25. A computer program embodied on a computer readable storage configured to perform the method of any one of claims 1 to 23 when executed on one or more processors.

Images