Blockchain Transactions

Abstract

A computer-implemented method for time-locking a blockchain transaction. The method includes computing a solution to the time-lock puzzle using a set of secret puzzle parameters. The time-lock puzzle can be solved in a time equal to or greater than a minimum solving time using the set of puzzle parameters. The set of puzzle parameters does not include the secret puzzle parameters. The method further includes generating a transaction encryption key K, encrypting the blockchain transaction using encryption key K, and encrypting the transaction encryption key K using the solution to the time-lock puzzle.

Description

[Technical field]

[0001] The present disclosure relates to a method for time-locking a blockchain transaction by encrypting the blockchain transaction for a specific amount of time, and a method for decrypting the encrypted blockchain transaction. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which copies of the blockchain are 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 includes a chain of blocks of data, with each block including one or more transactions. Each transaction, other than so-called "coinbase transactions," points backwards to a preceding transaction in a sequence that may span one or more blocks back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to the blockchain network are included in new blocks. New blocks are often created by a process called "mining," which involves multiple nodes each competing to solve a cryptographic puzzle based on a "proof of work," i.e., a representation of a defined set of ordered, approved, 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 may be accomplished by simply publishing the block header.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: transfer of digital assets (i.e., some digital tokens), ordering of a set of entries in a virtual ledger or registry, receiving and processing timestamp entries, and / or time-ordering of index pointers. A blockchain may also be utilized to stack additional functions on top of the blockchain. For example, a blockchain protocol may allow for storing additional user data or indexes to data in a transaction. There is no predefined limit on the maximum data capacity that can be stored in a single transaction, and thus much more complex data can be incorporated. For example, this may be used to store electronic documents in a blockchain, or to store audio or video data.

[0004] The nodes of the blockchain network (often called "miners") perform a distributed transaction registration and validation process that will be described in more detail later. In summary, during this process, nodes approve transactions and insert transactions into block templates where they attempt to identify a valid proof-of-work solution. Once a valid solution is found, a new block is propagated to other nodes of the network, thus allowing each node to record a new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes of the network to be propagated. The nodes receiving the transaction may compete to find a proof-of-work solution that will incorporate the approved transaction into a new block. Each node is configured to enforce the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated and are not incorporated into a block. Assuming the transaction is approved and thereby accepted into the blockchain, the transaction (including any user data) thus remains registered and indexed in each of the nodes of the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are typically rewarded with a new transaction called a "coinbase transaction" that distributes an amount of digital assets, i.e., some number of tokens. Detection and rejection of invalid transactions is enforced by the actions of competing nodes that act as agents of the network and are incentivized to report and block fraudulent activity. Widespread publication of information allows users to continuously audit node performance. Publication of mere block headers allows participants to guarantee the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Every spendable output includes an element that specifies an amount of a digital asset derivable from an ongoing sequence of transactions. A spendable output is sometimes called a UTXO (unspent transaction output). An output may further include a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that defines the conditions required to approve 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 output of a prior transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Now consider a pair of transactions, which we call a first transaction and a second transaction (or “target” transaction). The first transaction includes at least one output that specifies an amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second, target transaction includes at least one input including a pointer to an output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when the second, target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of the one or more conditions defined in the locking script of the first transaction. Another criterion is that the output of the first transaction has not already been fulfilled by another previous valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate the transaction (as a valid transaction, but possibly propagate to register an invalid transaction) and will not include the transaction in a new block to be recorded in the blockchain.

[0008] An alternative kind of transaction model is the account-based model, where each transaction defines the amount to be transferred by referencing absolute account balances, rather than by looking backwards at the UTXOs of previous transactions in a sequence of past transactions. The current state of every account is stored and constantly updated by nodes separate from the blockchain. Summary of the Invention [Means for solving the problem]

[0009] In some scenarios, it is desirable to create a transaction that can only be spent after a certain amount of time, where spending the transaction can be thought of as unlocking the transaction's output. This can be achieved to some extent by nLocktime. However, this method does not allow the transaction to be hidden from the user, which entails that the transaction cannot be stored immutably on the blockchain without becoming visible to everyone.

[0010] Encrypted blockchain transactions are presented herein, where the transactions are encrypted using a key that is itself encrypted based on a time-lock puzzle that can only be decrypted after a specific amount of time, such that the blockchain transaction itself can only be decrypted after a specific amount of time.

[0011] According to one aspect disclosed herein, a computer-implemented method for time-locking a blockchain transaction is provided, the method including the steps of: calculating a solution to the time-lock puzzle using a set of secret puzzle parameters, where the time-lock puzzle is capable of being solved in a time equal to or greater than a minimum solving time using the set of puzzle parameters, where the set of puzzle parameters does not include the secret puzzle parameter; generating a transaction encryption key K; encrypting the blockchain transaction using encryption key K; and encrypting the transaction encryption key K using the solution to the time-lock puzzle.

[0012] Timelock puzzles require the user to perform an exact number of sequential calculations such that parallelizing the solving process does not speed up the solution, which also means that the time to solve 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 put 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 illustrates a schematic diagram of some examples of transactions that may be recorded on a blockchain. [Diagram 3] FIG. 2 is a schematic block diagram of certain node software for processing transactions. [Figure 4] FIG. 13 illustrates a schematic diagram of an exemplary method for decrypting an encrypted blockchain transaction provided within a puzzle parameter blockchain transaction. [Diagram 5] FIG. 1 illustrates an example method of using a time-lock puzzle to prevent sending a transaction output before a minimum solving time. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] 1. Exemplary System Overview FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include 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 arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a near-complete graph. Thus, each blockchain node 104 is tightly 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., computer readable storage in the form of a non-transitory computer readable medium or multiple non-transitory computer readable media. 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 of a distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing all of the blockchain 150. Instead, the blockchain 150 may be pruned of data, so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 of 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 an amount of digital assets as property, an example being a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or spent). Each input points backwards to an output of a previous transaction 152, thereby linking the transactions.

[0018] Each block 151 also contains a block pointer 155 that points back to previously created blocks 151 in the chain, defining a chronological order up to block 151. Each transaction 152 (other than coinbase transactions) contains a pointer back to the previous transaction, defining an order in the sequence of transactions (note that the sequence of transactions 152 is allowed to branch). The chain of blocks 151 traces back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 early in the chain 150 pointed to the genesis block 153, not 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 respective copies of the same blockchain 150 in their respective memories. Each blockchain node 104 also maintains an ordered collection (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 in this specification is not intended to be limited to any particular blockchain, protocol, or model. This term refers to an ordered collection of transactions that the node 104 accepts as valid and that the node 104 is obligated to not accept any other transactions that attempt to consume the same output.

[0020] For a given current transaction 152j, the (or each) input contains a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be fulfilled or "consumed" in the current transaction 152j. Consuming or fulfilling does not necessarily mean the transfer of financial assets, although that is certainly one common use. More broadly, consuming may be described as spending an output or allocating an output to one or more outputs of another onward transaction. In general, a previous transaction may be any transaction in the ordered set 154 or any block 151. The previous 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 previous transaction 152i must exist and be approved for the current transaction to be valid. Thus, "predecessor" herein refers to a predecessor in a logical sequence linked by pointers, and not necessarily to a time of creation or transmission in a temporal sequence, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A predecessor transaction 152i may similarly be referred to as an antecedent or predecessor transaction.

[0021] The input of the current transaction 152j also includes the authorization of the input, e.g., the signature of the user 103a to whom 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. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, the transaction 152 may have multiple outputs to split the input amount among multiple users or entities (one of which may be the original user or entity 103a to give 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 participant 103, such as an individual user or an organization, wants to put a new transaction 152j into action (either manually or by an automated process adopted by the participant), the participant sends the new transaction from his computer terminal 102 to the recipient. The participant or recipient eventually sends this transaction to one or more of the blockchain nodes 104 of the network 106 (currently generally servers or data centers, but in principle could be other user terminals). It is also not excluded that the participant 103 putting a new transaction 152j into action could send it directly to one or more of the blockchain nodes 104 and in some cases not to the recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied in each of the blockchain nodes 104. The blockchain node protocol generally requires the blockchain nodes 104 to check that the cryptographic signature of the new transaction 152j matches an expected signature that 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 participant 103 included in the input of the new transaction 152j matches a condition defined in the output of the prior transaction 152i that the new transaction consumes (or "allocates"), which condition generally includes at least checking that the cryptographic signature or other authorization of the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the prior transaction 152i.Alternatively, the conditions may be determined solely by the blockchain node protocol, or may result from a combination of these. In any case, if the new transaction 152j is valid, the blockchain node 104 forwards the new transaction 152j to one or more other blockchain nodes 104 of the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol, and therefore 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 an output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is whether that output has already been validly fulfilled by the input of another onward 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 fulfill has not already been fulfilled by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless it is flagged as invalid for a warning and propagated) and is not recorded in the blockchain 150. This prevents double spending, where a transactor tries to allocate the output of the same transaction more than once. On the other hand, an account-based model prevents double spending by maintaining an account balance. Again, since there is a defined order of transactions, the account balance always has a single defined state.

[0024] In addition to approving transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process supported by "proof of work", usually called mining. 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 in the blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Generally, this involves searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool 154 of pending transactions and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has a certain predefined number of leading zeros. Note that this is just one particular type of proof of work puzzle, and others are not excluded. A property of a hash function is that it has an unpredictable output for its input. Therefore, this search can only be performed by brute force, thus expending 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 announces this to the network 106 and provides the solution as a proof that can then be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to check that it satisfies the conditions on the output of the hash). The first blockchain node 104 accepts the block and thus propagates the block up to a threshold consensus of other nodes that enforce the rules of the protocol. The ordered set of transactions 154 then becomes recorded in the blockchain 150 by each of the blockchain nodes 104 as a new block 151. The new block 151n is also allocated a block pointer 155 that points backwards to the previously created block 151n-1 in the chain. The significant amount of effort, e.g., in the form of hashing, required to create the proof-of-work solution signals the intention of the first node 104 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 approved transaction, also known as double spending. Once created, blocks 151 cannot be modified because they are known and maintained at each of the blockchain nodes 104 of the blockchain network 106. Also, block pointers 155 impart a chronological order to blocks 151. This thus provides an immutable public ledger of transactions as transactions 152 are recorded in ordered blocks on each blockchain node 104 of the network 106.

[0026] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be doing so based on different snapshots of the pool 154 of transactions not yet published at any given time, depending on when they started searching for a solution or the order in which transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool 154 of unpublished transactions is updated. Then, the blockchain nodes 104 continue to compete to create blocks from the newly defined ordered pool 154 of unpublished transactions, and so on. There is also a protocol to resolve any "forks" that may occur, where a fork is the point at which two blockchain nodes 104 solve their puzzles within a very short time of each other, such that conflicting views of the blockchain are propagated between the nodes 104. In short, the claw of whichever fork is the longest becomes the final blockchain 150. Note that this should have no impact on users or agents of the network, since the same transactions appear 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 an additional permitted 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 an amount of digital assets from one agent or user to another). This special type of transaction is typically called a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." This special type of transaction generally forms the first transaction of a new block 151n. The proof of work signals the node's intent to follow the rules of the protocol that allow this special transaction to be subsequently fulfilled. The rules of the blockchain protocol may require a maturity period, e.g., 100 blocks, before this special transaction may be fulfilled. Often, a regular (non-generation) 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 the "transaction fee" and is discussed 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 could take the form of a user terminal, or a group of user terminals networked together.

[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 role or roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that all actions attributed to the 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] Further connected to the network 101 are computer devices 102 for each of a number of participants 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in approving transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some participants may act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0031] Some or all of the participants 103 may be connected as part of a different network, for example, a network overlaid on the blockchain network 106. Although 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, these users are not blockchain nodes 104 because they do not fulfill the required role of a blockchain node. Instead, each participant 103 may interact with the blockchain network 106 by connecting to (i.e., communicating with) a blockchain node 106, thereby utilizing the blockchain 150. For illustrative purposes, two participants 103 and their respective devices 102 are shown: a first participant 103a and its respective computer device 102a, and a second participant 103b and its respective computer device 102b. It will be understood that many more such participants 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not shown. Each participant 103 may be an individual or an organization. Purely for purposes of illustration, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, but it will be understood that this is not limiting and all references herein to Alice or Bob may be replaced by "first party" and "second party," respectively.

[0032] The computing device 102 of each participant 103 includes 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 computing device 102 of each participant 103 further includes a memory, i.e., computer readable storage in the form of a non-transitory computer readable medium or multiple non-transitory computer readable media. This memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing device 102 of each participant 103 stores software including a respective instance of at least one client application 105 arranged to execute on the processing device. It will be understood that all actions attributed to a given participant 103 herein may be performed using software executing on the processing device of the respective computing device 102. The computing equipment 102 of each participant 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 participant 103 may also include one or more other networked resources, such as cloud computing resources, that are accessed via a user terminal.

[0033] The client application 105 is initially provided to the computing equipment 102 of any given participant 103 on one or more suitable computer-readable storage media, for example may be downloaded from a server or 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.

[0034] The client application 105 includes at least a "wallet" functionality. It has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign) and then send transactions 152 to one or more Bitcoin nodes 104 to be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to each party the amount of digital assets that it currently owns. In an output-based system, this second function involves aggregating the amounts defined in the outputs of the various transactions 152 scattered throughout the blockchain 150 that belong to the party in question.

[0035] NOTE: Although various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting; rather, any client functionality described herein may instead be implemented in a suite of two or more different applications that interface, for example, via an API or are plug-ins to one another. More broadly, client functionality may be implemented at the application layer, or at a lower layer such as an operating system, or any combination of these. While the following is described in terms of a 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 which each party 103 is the recipient of any transactions (or in embodiments, to verify the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet function of each computing device 102 is configured to assemble and send the transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to approve the transactions 152 according to the blockchain node protocol and forward the transactions 152 to propagate the transactions 152 across the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol together with a given node protocol implements a given transaction model. The same transaction protocol is used for all transactions 152 of the blockchain 150. The same node protocol is used by all nodes 104 of the network 106.

[0037] When a given party 103, say Alice, wants to submit a new transaction 152j to be included in the blockchain 150, she assembles the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. The party 103 then transmits 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 best connected to Alice's computer 102. When any given blockchain node 104 receives a new transaction 152j, it processes the new transaction 152j according to the blockchain node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions to be "valid", examples of which will be considered in more detail shortly. In some transaction protocols, the conditions for approval may be configurable on a per-transaction basis by a script included in the transaction 152. Alternatively, the conditions could simply be an inbuilt feature of the node protocol or defined by a combination of the script and the node protocol.

[0038] Provided that the newly received transaction 152j passes the test to be considered valid (i.e., the newly received transaction 152j is "approved"), every blockchain node 104 that receives the transaction 152j adds the newly approved transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, every blockchain node 104 that receives the transaction 152j propagates the approved transaction 152 towards one or more other blockchain nodes 104 of the network 106. Since each blockchain node 104 applies the same protocol, this means that the transaction 152j is immediately propagated throughout the network 106, assuming that the transaction 152j is valid.

[0039] Once placed in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 starts competing to solve a proof-of-work puzzle for the latest version of its respective pool 154 of transactions that contains the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different pools 154 of transactions, but whoever succeeds first defines the set of transactions contained in the latest block 151. Eventually, the blockchain node 104 solves the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that contains the new transaction 152j, the pool 154 becomes immutably part of one of the blocks 151 of the blockchain 150. Each transaction 152 contains a pointer back 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 may have conflicting views of which instance is "valid" before one instance is 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 instance that was not published in block 151).

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

[0042] 2. UTXO-Based Model FIG. 2 illustrates an exemplary 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 a limitation to all possible embodiments. It should be noted that the exemplary UTXO-based protocol is described in the context of Bitcoin, but may be similarly implemented in other exemplary blockchain networks.

[0043] In a UTXO-based model, each transaction ("Tx") 152 includes 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), which may be used as a source of input 202 for another new transaction (if the UTXO has not already been fulfilled). 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, a transaction ID for the transaction from which the UTXO originated. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include an ID for 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] Suppose Alice 103a wants to create a transaction 152j that sends an amount of the digital asset in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". Transaction 152j takes the amount of the digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence and sends at least a portion of it to Bob. The previous 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 may point back to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0045] The predecessor transaction Tx0 may already have been approved and included in a block 151 of the blockchain 150 when Alice creates her new transaction Tx1, or at least by the time Alice sends the new transaction Tx1 to the network 106. The predecessor transaction Tx0 may already have been included in one of the blocks 151 at that time, or may still be waiting in the ordered set 154, in which case the predecessor transaction Tx0 will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be created together and sent to the network 106, or even Tx0 may be sent after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "predecessor" and "successor" as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers specified in the transaction (such as which transaction points backwards to which other transaction). The terms may be equally interchangeable with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily imply the order in which those transactions are created, sent to the network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (descendant transaction or “child”) that points to a preceding transaction (ancestor transaction or “parent”) will not be approved until and unless the parent transaction is approved. A child that arrives at a blockchain node 104 before its parent is considered an orphan. The child may be discarded or buffered for a certain amount of time to wait for the 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 a condition that must be met by an unlocking script of the input 202 of the subsequent transaction for the subsequent transaction to be approved and thus the UTXO to be successfully fulfilled. Generally, the locking script locks the amount to a particular party (the beneficiary of the transaction in which the locking script is included). That is, the locking script defines an unlocking condition that generally includes a condition that the unlocking script of the input of the subsequent transaction includes a cryptographic signature of the party to whom the preceding transaction is locked.

[0047] A lock script (aka scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A lock script specifies what information is required to consume a transaction output 203, e.g., the need for Alice's signature. An unlock script appears in the output of a transaction. An unlock script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the criteria of a lock script. For example, an unlock script might include Bob's signature. An unlock script appears in 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 fulfilled (or, more precisely, for a subsequent transaction that attempts to fulfill UTXO0 to be valid). A Requires lock script [Checksig P A ]. [Checksig P A] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 includes a pointer that points back into Tx0 (e.g., by 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 UTXO0 among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that includes Alice's cryptographic signature, created by Alice applying her private key from her key pair to a pre-defined 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 a lock script, or by a 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 (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts, i.e. <Sig P A > <P A > || [Checksig P A ] where "||" represents concatenation, "<...>" means putting data on the stack, and "[...]" is a function included by the lock script (in this example, a stack-based language). Equivalently, the scripts may be executed one after the other using a common stack rather than concatenating the scripts. In either case, when executed together, the scripts will generate Alice's public key P as included in the lock script in the output of Tx0.A is used to authenticate that the input unlock script for Tx1 contains Alice's signature signing the expected portion of the data. The expected portion of the data itself (the "message") must also be included in order to perform this authentication. In an embodiment, the signed data includes the entirety of Tx1 (so a separate element specifying the signed portion of the plaintext data does not need to be included 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 with 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, thus allowing all holders of the public key to authenticate the signature. Thus, it should be noted that all references herein to signing a particular piece of data or transaction, etc., may, in embodiments, mean signing a hash of that piece of data or 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 of the network 106 so that the transaction Tx1 is propagated throughout the network 106. Once Tx1 is approved and included in the blockchain 150, this defines the UTXO0 from Tx0 as spent. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If Tx1 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, the blockchain node 104 also needs to check whether the referenced UTXO of the prior transaction Tx0 has already been spent (i.e., whether that UTXO has already formed a valid input to another valid transaction). This is one reason why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database indicating which UTXOs 203 of which transactions 152 have been spent, but ultimately, what defines whether a UTXO has been spent is whether it has already formed 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 inputs 202 of that transaction 152, this is another ground of invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0053] Note that in a UTXO-based transaction model, a given UTXO must be spent in its entirety. A given UTXO cannot have a portion of the amount defined in the UTXO as spent spent while leaving another portion "left over." However, an amount from a UTXO can be split among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 of Tx0 can be split among multiple UTXOs of Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remainder to give herself change or pay another party in the second output of Tx1.

[0054] In practice, Alice would usually also need to include a fee to any Bitcoin node 104 that successfully includes her transaction 104 in the block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and thus may not be propagated and included in the blockchain 150, although it is technically valid (the node protocol does not force the blockchain node 104 to accept the transaction 152 if it does not want to). 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 of a given transaction 152 and the total amount specified in the output 203 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose that a pointer to UTXO0 is the only input to Tx1, and Tx1 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 wins the proof-of-work race to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0055] Alice and Bob's digital assets consist of UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, the assets of a given party 103 are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. There is no one number stored anywhere in the blockchain 150 that defines the total balance of a given party 103. It is the role of a wallet function within the client application 105 to compile the value of all the various UTXOs locked to each party and that have not yet been spent in another onward transaction. The wallet function can do this by querying the copy of the blockchain 150 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 on the blockchain 150. For example, the data could include a document that is desired to be stored on the blockchain.

[0057] In general, 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 specific 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 that the signature signs depend on the SIGHASH flag, which is a 4-byte code typically included at the end of the signature (and therefore fixed at the time of signing) to select which outputs are signed.

[0058] A lock script may be referred to as a "scriptPubKey", generally referring to the fact that it contains the public key of the party to whom each transaction is locked. An unlock script may be referred to as a "scriptSig", generally referring to the fact that it provides the corresponding signature. However, more broadly, it is not required in all applications of blockchain 150 that the condition for a UTXO to be fulfilled include authenticating the signature. More broadly, a scripting language may be used to define any condition or conditions. Thus, the broader terms "lock script" and "unlock script" may be preferred.

[0059] 3. Side Channels As shown in FIG. 1, each of the client applications on Alice's and Bob's computing devices 102a, 102b may include additional communication capabilities. This additional capability allows Alice 103a to establish (at the urging of either party or a third party) a separate side channel 107 with Bob 103b. The side channel 107 allows data to be exchanged apart from the blockchain network. Such communication may be 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 in the blockchain network 106 or progressing towards the chain 150 until one of the parties chooses to broadcast the transaction 152 to the network 106. Sharing transactions in this manner may be referred to as sharing a "transaction template." A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, 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 additionally, the side channel 107 may be established over a different network, such as a local area network, such as a mobile cellular network, or a local wireless network, or even a direct wired or wireless link between Alice and Bob's devices 102a, 102b. Generally, the side channel 107 referred to anywhere in this specification may also include any link or links through one or more networking technologies or communication media for exchanging data apart from the blockchain network 106, "off-chain". When more than one link is 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 certain information or data, etc., over the side channel 107, this does not necessarily imply that all of these data must be transmitted over the exact same link or even the same type of network.

[0061] 4. Node Software FIG. 3 illustrates an example of node software 450 that runs on each blockchain node 104 of the network 106 in an example UTXO or output-based model. It should be noted that another entity may run the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the required actions of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a collection of one or more blockchain-related function modules 455. Each node 104 may run node software that includes, but is not limited to, all three of 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 different fields of a transaction 152 and process those fields according to a node protocol. Another prior transaction 152i (Tx m-1 ) j ) is received, the protocol engine 451 j The protocol engine 451 also identifies the unlock script for Tx j Based on the input pointer of Tx i Identify and extract. Tx i may be published on the blockchain 150, in which case the protocol engine may generate Tx i Alternatively, Tx i may not yet be published on 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. iIn any case, the protocol engine 451 may extract Tx i The script engine 452 then locates the lock script for the referenced output of the

[0062] Therefore, the script engine 452 executes the Tx i Lock script and Tx j and an unlock script from the corresponding inputs of . For example, transactions labeled Tx0 and Tx1 are shown in FIG. 2, but the same could apply to any pair of transactions. The script engine 452 executes the two scripts together as previously discussed, which includes pushing data onto and popping data from the stack 453 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 unlock script "unlocks" the output in which the lock script is included. 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, script engine 452 returns the result "false."

[0064] In an output-based model, the result "true" from the script engine 452 is one of the conditions for the validity of a transaction. j The total amount of digital assets specified in the output of Tx j and Tx iThere are also one or more further protocol-level conditions evaluated by protocol engine 451 that must also be satisfied, such as that the pointed-to output of has not already been consumed by another valid transaction. Protocol engine 451 evaluates the result from script engine 452 together with one or more protocol-level conditions, and accepts transaction Tx only if they are all true. j The protocol engine 451 outputs an indication to the application level decision engine 454 whether the transaction is valid. Tx j Only on condition that the Tx j , which may be used by the consensus module 455C to select a node to submit to its respective ordered set 154 of transactions for incorporation into a block 151. j The propagation module 455P is added to the Tx j to another blockchain node 104 in the network 106. Optionally, in embodiments, the application level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to publish the transaction only on the condition that the transaction is valid and has sufficient transaction fees remaining.

[0065] It should also be noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only one binary digit (bit), but that is certainly one possible implementation. More broadly, "true" can refer to any state that indicates a successful or positive outcome, and "false" can refer to any state that indicates an unsuccessful or non-positive outcome. For example, in an account-based model, a "true" outcome may be indicated by a combination of an implicit protocol-level approval of a signature and an additional positive output of a smart contract (where the overall outcome is considered to signal true if both individual outcomes are true).

[0066] 5. Time-locked transactions Timelock puzzles can be used as described below to create transactions that are stored on-chain that can only be spent or revealed after a specific amount of time.

[0067] Timelock puzzles require the user to perform an exact number of sequential calculations such that parallelizing the solving process does not speed up the solution, which also means that the time to solve the puzzle can be estimated in advance if the user's hardware is known.

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

[0069] 5.1. Time Lock Puzzle Time lock puzzles require the user to spend a certain amount of time solving them. Time lock puzzles are sequential in nature, so parallelizing the computation does not help to find a solution faster. Because different computers have different processing power, the time to solve a time lock puzzle can only be approximately controlled. It is advantageous for verifying a solution to a puzzle to take significantly less time than solving the puzzle.

[0070] Some useful properties of the Time Lock Puzzle include: · Non-parallelizability: A solution cannot be obtained faster than can be scheduled 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-grained difficulty: Puzzle difficulty can be finely adjusted to different levels.

[0071] 5.1.1 Modular squaring puzzles One exemplary type of time-lock puzzle that is particularly useful in the present implementation is a modular quadratic puzzle.

[0072] The modular square puzzle is a time-lock puzzle that requires a user to repeatedly compute the square operation in the multiplicative group of the integers modulo n = pq, where p, q are large prime numbers. This puzzle forms the basis of many time-lock puzzles. p and q are large in that they cannot be derived from n. Typically, p and q are 2048 bits in length, although it will be understood that other bit lengths may be used. A bit length of at least 2048 provides strong security guarantees for the puzzle.

[0073] The algorithm that defines the modular quadratic puzzle is as follows: SETUP(1 k) → (params, secret): Given a security parameter k, generate a composite modulus n = pq using two large randomly chosen secret primes p, q. Output params = (n) and secret = (p, q). The secret parameter k represents the bit length of the modulus n. The secret parameter k may be equal to 2048, for example. GENPUZ(t, params) → puz: Choose a random number a, 1 < a < n. Output puz = (a, t), t > 0, where t is the time parameter. ·FINDSOLN(puz, params) → sol:

number

number

number

[0074] The solution to the modular quadratic puzzle is log2(2 t ) = t modular multiplications. Because each step in the solving process depends on the previous step, computing the solution cannot be done in parallel.

[0075]

number

number

[0076] For a user who does not know p and q, computing the square operation is probably as difficult as factoring n.

number

[0077] The number of squares t required to solve a puzzle can be tightly controlled. This allows the challenger to create puzzles of various desired levels of difficulty. The control is proportional to t, and if the user's modular squaring speed is known, the solving time can be pre-determined. Assuming the challenger wants to create a time-lock puzzle that cannot be solved before T seconds, t should be set such that t ≥ TS, where S is the number of modulo n squares per second that can be performed by the user. If the user's speed is not known, a lower bound can be set based on the capabilities of modern hardware, referred to herein as the minimum solving time.

[0078] Modular square puzzles are a secret that can be efficiently verified.

number

[0079] Other examples of time-lock puzzles include square root based puzzles. Such puzzles may be used to time-lock transactions as presented herein. Modular square puzzles are preferred as they offer a wider range of possible time-lock durations and therefore a more tunable solution.

[0080] 5.2 Time-locked transactions using modular square puzzles A time-lock puzzle, such as the modular quadratic puzzle presented above, may be used to encrypt a complete and valid transaction for a predetermined amount of time, the minimum solution time T.

[0081] In the example provided herein, the challenger may challenge the transaction Tx for a predetermined amount of time. a The challenger performs the following steps: 1. For a given security parameter k, SETUP(1 k ) to generate (params, secret), keeping the value secret secret. 2. Choose a time parameter t for the modular quadratic puzzle and generate puz by calling GENPUZ(t). 3. Using the secret generated in step 1,

number

number

number

[0082] The challenger then receives the encrypted transaction, the encrypted transaction encryption key C K , and the puzzle parameters a, n, and t are available to the solver of the puzzle. K Using a, n, and t, the puzzle solver computes the solution to the time-lock puzzle, derives the transaction encryption key K, and creates the blockchain transaction Tx. a can be decoded.

[0083] In one embodiment, the challenger generates a second transaction Tx b In the OP_RETURN data, we put the puzzle puz = (a, t), the parameter n, and the encrypted key C K , and AES(K, Tx a ), and transaction Tx a is encrypted with key K using AES. Note that data may be included in any kind of output, not necessarily an OP_RETURN output. b Then, the transaction Tx b is published on the blockchain. Example puzzle parameter blockchain transaction Tx b is given below.

[0084] [Table 1]

[0085] Puzzle parameters Blockchain transaction Tx bis the encrypted transaction Tx a The information required to decode Tx a It can be seen that the inputs are provided with the inputs, which contain outputs that are pushed onto the stack to make them available to the puzzle solver.

[0086] In an alternative embodiment, the challenger transmits some or all of the above information off-chain to the puzzle solver. By providing at least a portion of the information and / or encrypted transaction required to solve the puzzle off-chain, the challenger can generate a transaction Tx a This may limit who can decrypt the cipher suite.

[0087] At least the encrypted transaction Tx a Transaction Tx published on the blockchain b By providing in the transaction Tx a is immutably recorded on the blockchain.

[0088] AES(K, Tx a ), it is computationally infeasible to determine the key K from K = (C K - sol) The fastest known method to derive mod n is the puzzle

number

[0089] This structure provides an alternative to nLocktime, a transaction parameter used to prevent a transaction from being included in a block before a certain amount of time. Both methods ensure that a transaction cannot be included in a block before a pre-determined amount of time, but the difference in using a timelock puzzle is that a transaction can be published on the blockchain without being hidden from other users and becoming publicly viewable.

[0090] By publishing an encrypted transaction on the blockchain, the transaction cannot be altered or repudiated by anyone. By encrypting the transaction with a time lock, the challenger is guaranteed that the transaction will not be revealed (and therefore spent) before a certain amount of time. If the challenger is honest, i.e., sol and C k Assuming that x is calculated correctly, the user can be assured that the transaction can be decrypted after time T = t / S by performing repeated squaring, where t is the time parameter of the puzzle and S is the number of modulo-n squarings per second that the user can perform.

[0091] Time-locking a transaction could be used, for example, in estate-planning, where a party can lock funds to be gifted in their will, and the immutable encrypted transaction prevents any dispute over the funds.

[0092] FIG. 4 illustrates an example scenario in which information 510 for decrypting an encrypted blockchain transaction 508 and the encrypted blockchain transaction 508 are provided within a puzzle parameter blockchain transaction 502.

[0093] The puzzle solver obtains information 510 for decrypting the encrypted blockchain transaction 508 and the encrypted blockchain transaction 508 from the stack to which the puzzle parameters blockchain transaction 502 were pushed when they were committed to the blockchain. The information 510 includes a set of puzzle parameters a, t, and n, from which the puzzle solver derives a solution to the time-lock puzzle and an encrypted transaction encryption key C K can be calculated.

[0094] The puzzle solver is

number

[0095] The puzzle solver is K = (C K -sol) mod n The solution is used to derive the encryption key by computing

[0096] Once the puzzle solver derives the transaction encryption key K, it uses the transaction encryption key K to decrypt the encrypted blockchain transaction 508. This is the decryption of the blockchain transaction Tx a 504 can be used by the puzzle solver, so that the puzzle solver can a 504 to the blockchain node to record it in the blockchain, creating a blockchain transaction Tx a 504 UTXOs can be spent.

[0097] Blockchain transaction Tx in Figure 4 a 504 is shown to include two outputs. The first output is the public key P AThe amount of digital assets locked for the first recipient Alice corresponding to the public key P B and a second amount of digital assets locked for a second recipient user Bob corresponding to

[0098] Alice will then enter her signature, sig, in the unlock script. A By providing the blockchain transaction Tx a A spend transaction, Tx, to spend the 504 UTXO s 506. Alice may be the solver of the puzzle, or another user may compute the solution. a 504 defines the recipients of the locked UTXOs, so the puzzle may be solved by any user.

[0099] Bob may create his own consume transaction (not shown) to consume x2.

[0100] FIG. 5 illustrates an exemplary method for implementing a time-locked transaction as described above.

[0101] In step 1, the Challenger 602 sets up the puzzle by randomly selecting p and q and calculating n from those values. The Challenger 602 also randomly selects a parameter a and determines a suitable time parameter t. The Challenger 602 uses p, q, a, and t to calculate a solution to the Time Lock Puzzle.

[0102] In step 2, the challenger 602 generates a transaction encryption key K. The transaction key K may be for a conventional cryptosystem such as AES, although other cryptosystems may be used. The challenger 602 receives a transaction Tx previously generated by the challenger 602. a504 using transaction encryption key K, and encrypting transaction encryption key K using the solution to obtain encrypted transaction encryption key C K Calculate.

[0103] In step 3, the challenger 602 receives the puzzle parameter transaction Tx b Generate 502 and create a puzzle parameter transaction Tx b Within 502, a challenger 602 receives puzzle parameters n, a, and t, an encrypted transaction encryption key C K , and the encrypted transaction AES(K, Tx a ) 508 is provided.

[0104] In step 4, the challenger 602 sends a puzzle parameter transaction Tx to one or more nodes of the blockchain 606 for committing to the blockchain 606. b is made available.

[0105] In step 5, the puzzle solver 604 obtains from the blockchain 606 the puzzle parameters n, a, and t, the encrypted transaction encryption key C K , and the encrypted transaction AES(K, Tx a ) Take out 508.

[0106] In step 6, a puzzle solver 604 uses the puzzle parameters n, a, and t to calculate a solution to the puzzle. The puzzle solver returns the solution and the encrypted transaction encryption key C K and determine the transaction encryption key K.

[0107] In step 7, the puzzle solver 604 solves the encrypted transaction AES(K, Tx a ) 508 is decrypted and the transaction Tx a Request 504.

[0108] The puzzle solver then sends the now decrypted Tx to one or more nodes of the blockchain 606 for committing to the blockchain 606 in step 8. a Send 504.

[0109] Once committed to the blockchain, the transaction Tx a A recipient of the digital asset can generate their own consumption transaction 506 to consume the digital asset.

[0110] In some embodiments, a multiple puzzle solver 604 solves the puzzle and then generates an encrypted transaction, AES(K, Tx a ) 508. In some embodiments, the transaction Tx a The UTXO of 504 is the transaction Tx a In other embodiments, the UTXO is locked to a predefined user, such that only that user or the puzzle solver 604 can spend it, regardless of whether the user decrypts the transaction Tx a The UTXO of is locked so that any puzzle solver 604 can spend the UTXO.

[0111] In the examples of Figures 4 and 5, the puzzle parameters and encrypted transactions are provided in a puzzle parameters transaction, and the puzzle parameters transaction is committed to the blockchain. As noted above, it will be appreciated that the parameters and / or encrypted transactions may be provided to the puzzle solver off-chain.

[0112] In some embodiments, for example, transaction Tx a The puzzle parameters of the transaction Tx are recorded on the blockchain and are therefore immutable. b The transaction is encrypted with AES(K, Txa ), the parameters n, a, and t needed to compute the solution to the puzzle, and the encrypted transaction encryption key C K may be provided to the recipient's puzzle solver off-chain, such that only the recipient's puzzle solver can decrypt the transaction.

[0113] 6. Further Special Notes Other variations or uses of the disclosed technology will be apparent to one of ordinary skill in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0114] For example, some embodiments above have been described in terms of 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 apply broadly to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More broadly, all 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 characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 above.

[0115] In a preferred embodiment of the invention, the blockchain network 106 is the Bitcoin network, where the Bitcoin nodes 104 perform at least all of the described functions of creating, publishing, propagating and storing blocks 151 of 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, network entities may perform the functions of propagating and / or storing blocks without creating and publishing them (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0116] In other embodiments of the invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform 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, on these 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 not configured to store and / or propagate those blocks 151 to other nodes.

[0117] Even more broadly, all references above to the term “Bitcoin node” 104 may be replaced by 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 in relation to the blockchain node 104.

[0118] It will be appreciated that the above embodiments have been described by way of example only. More broadly, there may be provided a method, apparatus or program according to any one or more of the following statements:

[0119] Statement 1. 1. A computer-implemented method for time-locking blockchain transactions, comprising: computing a solution to the time-lock puzzle using a set of secret puzzle parameters, where the time-lock puzzle can be solved in a time equal to or greater than a minimum solving time using the set of puzzle parameters, where the set of puzzle parameters does not include the secret puzzle parameters; generating a transaction encryption key K; encrypting the blockchain transaction using an encryption key K; and encrypting the transaction encryption key K using the solution to the time-lock puzzle.

[0120] Statement 2. 2. The method of statement 1, further comprising making the set of puzzle parameters and the encrypted transaction encryption key available to one or more puzzle solvers.

[0121] Statement 3. generating a puzzle parameter blockchain transaction, the puzzle parameter blockchain transaction including a first output to make output data of the first output available when the puzzle parameter blockchain transaction is committed to the blockchain, the output data including an encrypted blockchain transaction; and making the puzzle parameter blockchain transaction available to one or more nodes of the blockchain network.

[0122] Statement 4. The method of statement 3, wherein the output data further includes a set of puzzle parameters and an encrypted transaction encryption key.

[0123] Statement 5. 1. A computer-implemented method for decrypting an encrypted blockchain transaction, the encrypted blockchain transaction being encrypted using a transaction encryption key, the transaction encryption key being encrypted based on a solution to a time-lock puzzle, the time-lock puzzle being capable of being solved in a time equal to or greater than a minimum solving time using a set of puzzle parameters, the method comprising: obtaining a set of puzzle parameters and an encrypted transaction encryption key; generating a solution to the time lock puzzle based on a set of puzzle parameters; deriving a transaction encryption key based on the solution and the encrypted transaction encryption key; and decrypting the encrypted blockchain transaction using the decrypted transaction encryption key.

[0124] Statement 6. The method of statement 5, wherein the encrypted blockchain transaction is obtained from the puzzle parameter blockchain transaction.

[0125] Statement 7. 7. The method of statement 6, further comprising obtaining the set of puzzle parameters and the encrypted transaction encryption key from the puzzle parameter blockchain transaction.

[0126] Statement 8. The method of any of the preceding statements, wherein the time lock puzzle is a modular square puzzle.

[0127] Statement 9. The solution is,

number

[0128] Statement 10. The puzzle parameter n is Modulus n = pq The method of statement 9, where p and q are large prime numbers, is defined by

[0129] Statement 11. The solution is,

number

number

[0130] Statement 12. The encrypted transaction encryption key is C k = K + sol mod n The method according to statement 9 or any statement subordinate to statement 9, as defined by

[0131] Statement 13. The method of statement 11 when the set of secret puzzle parameters depends on statement 1 or any statement that depends on statement 1, including large prime numbers p and q.

[0132] Statement 14. 14. The method of statement 13, further comprising the steps of randomly selecting large prime numbers p and q and a puzzle parameter a, and calculating a puzzle parameter t, prior to computing the solution.

[0133] Statement 15. The method of statement 9 when the solution depends on statement 5 or any statement that depends on statement 5, generated using the puzzle parameters a, t, and n.

[0134] Statement 16. The minimum solution time is

number

[0135] Statement 17. 17. A computing apparatus comprising: a memory including one or more memory units; and a processing unit including one or more processing units, the memory storing code arranged to be executed on the processing unit, the code being configured, when on the processing unit, to perform the method of any of statements 1 to 16.

[0136] Statement 18. A computer program embodied on a computer readable storage and configured to perform the method of any of statements 1 to 16 when executed on one or more processors. [Explanation of symbols]

[0137] 100 Systems 101 Packet Switching Network 102 Computer terminals, computer equipment 102a Computer equipment 102b Computer equipment 103 Users, Parties, and Agents 103a User, original user or entity, first party, Alice 103b New user or entity, second party, Bob 104 Blockchain nodes, Bitcoin nodes 105 Client Applications, Software 106 Peer-to-Peer (P2P) Network, Blockchain Network, Bitcoin Network 107 Side Channel 150 Blockchain, Bitcoin Blockchain 151 Blocks of Data Blocks created before 151n-1 151n New Block 152 Transactions 152i Preceding Transaction 152j Current Transaction, New Transaction, Onward Transaction 153 Genesis Block (Gb) 154 Ordered Sets, Ordered Pools 155 Block Pointer 201 Header 202 Input 203 Output, UTXO 401 Protocol Engine 450 Node Software 451 Protocol Engine 452 Script Engine 453 stack, stack-based memory 454 Application Level Decision Engine 455 Blockchain-related functional modules 455C Consensus Module 455P Propagation Module 455S Storage Module 502 Puzzle Parameter Blockchain Transaction, Puzzle Parameter Transaction Tx b 504 Blockchain Transaction Tx a 506 Consumption Transaction Tx s 508 Encrypted Blockchain Transactions 510 Information 602 Challenger 604 Puzzle Solver 606 Blockchain

Claims

1. 1. A computer-implemented method for time-locking blockchain transactions, comprising: computing a solution to a time-lock puzzle using a set of secret puzzle parameters, the time-lock puzzle being solvable in a time greater than or equal to a minimum solution time using a set of puzzle parameters, the set of puzzle parameters not including the secret puzzle parameters; generating a transaction encryption key K; encrypting the blockchain transaction using the encryption key K; encrypting the transaction encryption key K using the solution to the time-lock puzzle; A method comprising:

2. The method of claim 1 , further comprising making the set of puzzle parameters and the encrypted transaction encryption key available to one or more puzzle solvers.

3. generating a puzzle parameter blockchain transaction, the puzzle parameter blockchain transaction including the first output to make output data of the first output available when the puzzle parameter blockchain transaction is committed to a blockchain, the output data including the encrypted blockchain transaction; making the puzzle parameter blockchain transaction available to one or more nodes of a blockchain network; 3. The method of claim 2, further comprising:

4. The method of claim 3 , wherein the output data further comprises the set of puzzle parameters and the encrypted transaction encryption key.

5. 1. A computer-implemented method for decrypting an encrypted blockchain transaction, the encrypted blockchain transaction being encrypted using a transaction encryption key, the transaction encryption key being encrypted based on a solution to a time-lock puzzle, the time-lock puzzle being capable of being solved in a time equal to or greater than a minimum solving time using a set of puzzle parameters, the method comprising: obtaining the set of puzzle parameters and the encrypted transaction encryption key; generating the solution to the time lock puzzle based on the set of puzzle parameters; deriving the transaction encryption key based on the solution and the encrypted transaction encryption key; decrypting the encrypted blockchain transaction using the decrypted transaction encryption key; A method comprising:

6. The method of claim 5 , wherein the encrypted blockchain transaction is obtained from a puzzle parameter blockchain transaction.

7. 7. The method of claim 6, further comprising obtaining the set of puzzle parameters and the encrypted transaction encryption key from the puzzle parameter blockchain transaction.

8. The method of any one of claims 1 to 7, wherein the time lock puzzle is a modular quadratic puzzle.

9. The solution is [0010] 9. The method of claim 8, wherein a, t, and n are puzzle parameters, with 1 < a < n and t > 0.

10. The puzzle parameter n is Modulus n = pq 10. The method of claim 9, wherein p and q are large prime numbers.

11. The solution is [0025] is defined by [0030] The method according to claim 10, wherein

12. the encrypted transaction encryption key is C k = K + sun mod n 10. The method of claim 9 or any one of the claims dependent on claim 9, wherein:

13. The method of claim 11 when dependent on claim 1 or any claim dependent on claim 1, wherein the set of secret puzzle parameters includes the large prime numbers p and q.

14. 14. The method of claim 13, further comprising the step of randomly selecting the large prime numbers p and q and the puzzle parameter a and calculating the puzzle parameter t prior to calculating the solution.

15. The method of claim 9 when dependent on claim 5 or any claim dependent on claim 5, wherein the solution is generated using the puzzle parameters a, t, and n.

16. The minimum solution time is [0045] 10. A method according to claim 9 or any claim dependent thereon, wherein the method is defined by: and S is the number of squaring modulo n per second that a user computing the solution using the set of puzzle parameters may perform.

17. 1. A computer device comprising: a memory including one or more memory units; a processing device including one or more processing units, the memory storing code arranged to be executed on the processing device, the code being configured, when on the processing device, to execute the method of any one of claims 1 to 16. Computer equipment.

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

Images