Blockchain Transactions

Abstract

A computer-implemented method for generating a challenge blockchain transaction is described. The transaction is associated with a puzzle and a proof criterion, where the puzzle is satisfied by a puzzle solution and the proof criterion is satisfied by the proof. The method includes generating a first locking script for the transaction. The first locking script, when executed with a first unlocking script including a candidate puzzle solution, a public key, a candidate proof, and a signature generated for the solution blockchain transaction, verifies that the candidate puzzle solution satisfies the puzzle, verifies that the signature is valid for the public key, and verifies that the candidate proof satisfies the proof criterion. The proof criterion requires that the candidate proof be derived from the candidate puzzle solution and the public key. The method further includes making the challenge blockchain transaction available to blockchain network nodes.

Description

[Technical Field]

[0001] The present disclosure relates to a method for generating a challenge blockchain transaction and a method for generating a solution blockchain transaction for unlocking a UTXO of the challenge transaction. [Background technology]

[0002] A blockchain refers to a form of distributed data structure in which copies of the blockchain are maintained and publicly published at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). The blockchain includes a chain of blocks of data, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points backward to a preceding transaction in the sequence, which 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 competing to perform "proof of work," i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered, confirmed, pending transactions awaiting inclusion in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of a block may be achieved simply by publishing the block header.

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

[0004] Nodes (often called "miners") in a blockchain network perform a distributed transaction registration and validation process, which is described in more detail below. Briefly, during this process, nodes approve transactions and insert them 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 in the network, thus allowing each node to record the new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network to be propagated. 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 blocks. 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 in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are rewarded with a new transaction, typically called a "coinbase transaction," that distributes a certain amount of digital assets, i.e., some number of tokens. Detection and rejection of invalid transactions is enforced by the actions of competing nodes, who 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 simple 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 specifying the amount of a digital asset derivable from the 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 the output's future redemption. 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 an output of a prior transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Consider a pair of transactions, called a first transaction and a second transaction (or “target” transaction). The first transaction includes at least one output that specifies the 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 that includes a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when a 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 unlock script meets all of one or more conditions defined in the lock script of the first transaction. Another criterion is that the output of the first transaction has not already been redeemed 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 to register an invalid transaction) or include the transaction in a new block to be recorded in the blockchain.

[0008] An alternative type 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 all accounts is stored and constantly updated by nodes separate from the blockchain. Summary of the Invention [Means for solving the problem]

[0009] In a UTXO-based blockchain, the solution to a cryptographic puzzle may be set as a spending condition in a transaction, sometimes called a bounty transaction. The puzzle bounty locked in the bounty transaction may be claimed by broadcasting a fulfillment transaction that references the bounty transaction and includes the solution to the puzzle. Verification of the solution is performed by blockchain nodes (e.g., miners) as part of validating the transaction.

[0010] One common problem with puzzle bounties is that a malicious eavesdropper can steal the bounty by extracting the puzzle solution from the fulfillment transaction and broadcasting a new fulfillment transaction with a modified output. To solve this problem, the creator of the bounty transaction, called the challenger, may require that the fulfillment transaction be signed by a specific user. However, in some cases, it may be desirable for the puzzle bounty not to be tied to a specific user, but rather to be claimable by anyone who provides the correct puzzle solution.

[0011] According to one aspect disclosed herein, there is provided a computer-implemented method for generating a challenge blockchain transaction, the challenge blockchain transaction being associated with a puzzle and a proof criterion, the puzzle being satisfied by a solution to the puzzle, and the proof criterion being satisfied by the proof, the method including: generating a first locking script for the challenge blockchain transaction, the first locking script being configured to, when executed together with a first unlocking script for a solution blockchain transaction that includes a candidate puzzle solution, a public key, the candidate proof, and a signature generated for the solution blockchain transaction, verify that the candidate puzzle solution satisfies the puzzle, verify that the signature is valid for the public key, and verify that the candidate proof satisfies the proof criterion, wherein the proof criterion requires that the candidate proof be derived from the candidate puzzle solution and the public key; and making the challenge blockchain transaction available to one or more nodes of a blockchain network.

[0012] According to another aspect disclosed herein, there is provided a computer-implemented method for generating a solution blockchain transaction, wherein a first unlocking script of the solution blockchain transaction is configured to unlock a first transaction output of a challenge blockchain transaction, the challenge blockchain transaction being associated with a puzzle and a proof criterion, the puzzle being satisfied by a solution to the puzzle, and the proof criterion being satisfied by the proof, the method including: generating a first unlocking script, the first unlocking script including a candidate puzzle solution for satisfying the puzzle, a solution blockchain transaction signature, a public key for generating the signature, and a candidate proof derived from the candidate puzzle solution and the public key; and making the solution blockchain transaction available to one or more nodes of a blockchain network.

[0013] The methods provided herein protect puzzle bounties by preventing malicious eavesdroppers from hijacking puzzle solutions provided within fulfillment transactions by requiring that candidate proofs be derived from the public key and puzzle solution used to sign the fulfillment (or solution) transaction.

[0014] In some embodiments provided herein, the candidate proofs are generated by a computationally time-intensive method. The time required to compute the candidate proofs is significant compared to the average time it takes for a transaction to be recorded in a block on the blockchain. In this way, a malicious interceptor of the solution blockchain transaction cannot generate his or her own candidate proof before the solution blockchain transaction is recorded on the blockchain, thus preventing the malicious interceptor from maliciously obtaining the bounty (i.e., digital assets) locked by the output of the challenge transaction.

[0015] One advantage of the methods provided herein is that the challenger does not need to know the solution to the puzzle when the challenge blockchain transaction is generated, which reduces the computational and time requirements of the challenger when generating the challenge solution.

[0016] 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 explanation of the drawings]

[0017] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3] 1 is an example directed acyclic graph with labeled nodes. [Figure 4] FIG. 1 provides an example method for generating challenge and solution blockchain transactions. [Figure 5] FIG. 1 illustrates a schematic diagram of verifying an unlock script using a proof-of-work scheme. [Figure 6] FIG. 1 illustrates a schematic diagram of verifying an unlock script using a chained proof of work scheme. [Figure 7] FIG. 10 is a diagram illustrating the use of the Sloth method to verify an unlock script. [Figure 8] FIG. 10 illustrates a schematic diagram of verifying an unlock script using a proof of sequential work scheme. [Figure 9]FIG. 10 is a diagram illustrating the use of a verifiable delay function scheme to verify the unlock script. DETAILED DESCRIPTION OF THE INVENTION

[0018] 1. Exemplary System Overview 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 multiple 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.

[0019] Each blockchain node 104 includes a peer computing 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, e.g., 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 memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The 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 solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0020] A blockchain 150 includes a chain of blocks of data 151, 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 all of the blockchain 150. Instead, the blockchain 150 may be pruned, so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain includes one or more transactions 152, with a transaction in this context referring 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 for each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing the amount of digital assets 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 be unlocked and thereby redeemed or spent). Each input points backward to the output of a previous transaction 152, thereby linking the transactions.

[0021] 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 diverge). 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.

[0022] Each blockchain node 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, as used herein, is not intended to be limited to any particular blockchain, protocol, or model. This term refers to an ordered collection of transactions that a 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.

[0023] 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 within the ordered set 154 or any block 151. The previous transaction 152i does not necessarily need 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 also be referred to as an antecedent or predecessor transaction.

[0024] The input of the current transaction 152j also includes the input's authorization, 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, a transaction 152j 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 into one or more outputs of the current transaction.

[0025] According to an output-based transaction protocol such as Bitcoin, when a participant 103, such as an individual user or an organization, wants to execute a new transaction 152j (either manually or through an automated process employed by the participant), the initiator sends the new transaction from their computer terminal 102 to a recipient. The initiator or recipient ultimately transmits this transaction to one or more blockchain nodes 104 of the network 106 (currently typically a server or data center, but in principle could be other user terminals). It is also not excluded that the participant 103 executing the new transaction 152j may transmit the transaction directly to one or more blockchain nodes 104 and, in some cases, not to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied at 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 party 103 included in the input of a new transaction 152j matches a condition defined in the output of a 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 either 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 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol, and thus 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.

[0026] In an output-based model, the definition of whether a given output (e.g., a 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 and propagated for a warning) and is not recorded in the blockchain 150. This prevents double-spending, where a transactor attempts 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, because there is a defined order of transactions, an account balance always has a single, defined state.

[0027] 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," typically referred to as mining. At a blockchain node 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. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions 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 hash output satisfies a predetermined condition. For example, the predetermined condition might be that the hash output has a certain predefined number of leading zeros. Note that 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 given 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.

[0028] The first blockchain node 104 to solve 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 hash solution, it is easy to check that it satisfies the conditions on the hash output). The first blockchain node 104 accepts the block and therefore propagates it to a threshold consensus of other nodes that enforce the rules of the protocol. The ordered set of transactions 154 is then recorded in the blockchain 150 by each of the blockchain nodes 104 as a new block 151. The new block 151 is also assigned a block pointer 155 that points backward 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 first node 104's intention 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 a double-spend. 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. Block pointers 155 also impart a chronological order to blocks 151. This therefore provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks on each blockchain node 104 of the network 106.

[0029] 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 those blockchain nodes 104 began 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. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool 154 of unpublished transactions, and so on. There is also a protocol for resolving any possible "forks," where two blockchain nodes 104 solve their puzzles within a very short time of each other so that conflicting views of the blockchain are propagated between the nodes 104. In short, whichever fork ends up with the longest claws will result in the final blockchain 150. Note that this should not affect users or agents of the network, as the same transaction appears in both forks.

[0030] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate additional authorized amounts 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 constructing the new block's intent to follow the rules of the protocol, which allow this special transaction to be subsequently executed. The rules of the blockchain protocol may require a maturity period, e.g., 100 blocks, before this special transaction may be executed. 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.

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

[0032] 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 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.

[0033] Further connected to the network 101 are computing 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).

[0034] 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. Users of the blockchain network (often called “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 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 computing device 102a, and a second participant 103b and its respective computing device 102b. It will be understood that many additional such participants 103 and their respective computing 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.

[0035] The computing equipment 102 of each participant 103 includes a respective processing unit including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing equipment 102 of each participant 103 further includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or 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 memory, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing equipment 102 of each participant 103 stores software including a respective instance of at least one client application 105 arranged to execute on the processing unit. It will be understood that all actions attributed to a given participant 103 herein may be performed using software executing on the processing unit of the respective computing equipment 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 smartwatch. 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 the user terminal.

[0036] 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, and may, for example, 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.

[0037] The client application 105 includes at least a "wallet" functionality, which has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign), and then submit 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 they currently own. In an output-based system, this second function involves aggregating the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to the party in question.

[0038] NOTE: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting; rather, any client function described herein may instead be implemented in a suite of two or more different applications that interface via an API or are plug-ins to one another, for example. More broadly, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described in terms of a client application 105, it will be understood that this is not limiting.

[0039] 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 enables the wallet functionality 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 functionality of each computing device 102 is configured to assemble and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to approve transactions 152 according to the blockchain node protocol and forward transactions 152 to propagate them throughout 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 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.

[0040] When a given party 103, e.g., 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 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 for being "valid," examples of which will be discussed in more detail shortly. In some transaction protocols, conditions for approval may be configurable on a per-transaction basis via a script included in the transaction 152. Alternatively, the conditions could simply be a built-in feature of the node protocol or defined by a combination of the script and the node protocol.

[0041] 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 toward one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that the transaction 152j is quickly propagated throughout the network 106, assuming the transaction 152j is valid.

[0042] Once placed in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 begins a race to solve a proof-of-work puzzle for the latest version of its respective pool 154 of transactions, including the new transaction 152j. (Recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools 154 of transactions; whoever succeeds first defines the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 solves the puzzle for the part of the ordered pool 154 that includes Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that includes the new transaction 152j, the pool 154 immutably becomes part of one of the blocks 151 of the blockchain 150. Each transaction 152 includes a pointer back to previous transactions; therefore, the order of the transactions is also immutably recorded.

[0043] Different blockchain nodes 104 initially receive different instances of a given transaction and may therefore 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 later 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 that it originally accepted (i.e., the instance that was not published in block 151).

[0044] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol, as part of an account-based transaction model. In an account-based model, each transaction defines the amount to be transferred by referencing an absolute account balance, rather than by referencing the UTXO of a previous transaction backward in a sequence of past transactions. The current state of every account is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction tally (also called "position"). 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 a transaction. This data field may point backward to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0045] 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 the 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. Note that the exemplary UTXO-based protocol is described in relation to Bitcoin, but may be similarly implemented in other exemplary blockchain networks.

[0046] 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 can be used as a source of input 202 for another new transaction (if the UTXO is not already fulfilled). A UTXO includes a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of 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 the transaction's ID. 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.

[0047] Suppose Alice 103a wishes to create transaction 152j to send the amount of the digital asset in question to Bob 103b. In Figure 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 Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 may point backward to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0048] The predecessor transaction Tx0 may already be 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 submits her 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 and submitted to the network 106 together, or Tx0 may even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “predecessor” and “subsequent” 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 transactions (e.g., which transactions point backward to which other transactions). 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 (a descendant transaction or “child”) that points to a preceding transaction (an 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 time to wait for its parent, depending on the node protocol and / or node behavior.

[0049] 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 specifying the amount of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by the unlocking script of the input 202 of the subsequent transaction for the subsequent transaction to be approved and, therefore, for 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 unlocking conditions that generally include a condition that the unlocking script of the input of the subsequent transaction include the cryptographic signature of the party to whom the preceding transaction is locked.

[0050] 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, for example, the need for Alice's signature. An unlock script appears in the transaction's output. An unlock script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the lock script's criteria. For example, an unlock script might include Bob's signature. An unlock script appears in the transaction's input 202.

[0051] Thus, in the illustrated example, UTXO0 in output 203 of Tx0 must contain Alice's signature Sig P for UTXO0 to be fulfilled (or, more precisely, for any subsequent transaction attempting to fulfill UTXO0 to be valid). A Requires a 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 Tx0's 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 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 a lock script, or by a node protocol, or by a combination of these.

[0052] 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 (a stack-based language in this example). 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 use Alice's public key P, included in the lock script of the output of Tx0.A is used to authenticate that the unlock script in Tx1's input contains Alice's signature, which signs the expected portion of the data. The expected portion of the data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data includes the entirety of Tx1 (thus a separate element specifying the signed portion of the plaintext data need not be included, as it is already inherently present).

[0053] The details of authentication via 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 with 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 particular data, portions of a transaction, etc., may, in embodiments, mean signing a hash of that data or portion of a transaction.

[0054] If the unlock script of Tx1 satisfies one or more conditions specified in the lock script of Tx0 (thus, in the illustrated example, if Alice's signature is provided in Tx1 and is authenticated), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that 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 unspent transaction outputs 203. If Tx1 attempts to consume outputs already consumed by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, 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 already formed a valid input to another valid transaction). This is one reason why it is important for 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 is spent is whether it has already formed a valid input to another valid transaction in blockchain 150.

[0055] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated 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.

[0056] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. A given UTXO cannot have part of the amount defined in the UTXO as spent spent while leaving another part "left over." However, the amount from a UTXO can be divided among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be divided 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.

[0057] In practice, Alice must typically also include a fee to any Bitcoin node 104 that successfully includes her transaction 152 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and thus, while technically valid, may not be propagated and included in the blockchain 150 (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 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 competition 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 transaction 152's UTXOs 203 itself.

[0058] Alice and Bob's digital assets consist of UTXOs locked to them in any transaction 152 anywhere on the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. No single number is stored anywhere on the blockchain 150 that defines a given party's 103 total balance. It is the responsibility of a wallet function within the client application 105 to compile the value of all the various UTXOs locked to each party that have not yet been spent in another onward transaction. The wallet function can do this by querying a copy of the blockchain 150 stored on one of the Bitcoin nodes 104.

[0059] Note that script code is often represented generally (i.e., without using a precise language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific 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, can store data within the transaction, thereby creating a non-consumable output of the transaction that can immutably record the data on the blockchain 150. For example, the data could include a document that is desired to be stored on the blockchain.

[0060] Generally, the input to a transaction is a public key P AIn embodiments, 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 portions 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) that selects which outputs are signed.

[0061] 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. Therefore, the broader terms "lock script" and "unlock script" may be preferred.

[0062] 3. Side Channels As shown in FIG. 1, each client application on Alice's and Bob's computing devices 102a, 102b may include additional communication capabilities. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (either through the initiation of a participant or a third party). The side channel 107 allows data to be exchanged separately from the blockchain network. Such communication may be referred to as “off-chain” communication. For example, it may be used to exchange transactions 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or progressing toward the chain 150 until one of the participants 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.

[0063] 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 over a direct wired or wireless link between Alice and Bob's devices 102a, 102b. Generally, the side channel 107 referred to anywhere herein may also be "off-chain," i.e., include any one or more links via one or more networking technologies or communication media for exchanging data separately from the blockchain network 106. 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 particular information, data, etc. over the side channel 107, this does not necessarily imply that all of this data must be transmitted over the exact same link or even the same type of network.

[0064] 4. Hash Puzzle Cryptographic hash functions provide a means to deterministically obscure an input, where small changes in the input lead to dramatic changes in the output. Cryptographic hash functions have the following properties: Pre-image resistance: Given a hash value H(m), it is computationally difficult to find the pre-image m. Second pre-image resistance: Given a hash value H(m) and its pre-image m, it is computationally infeasible to find m' such that H(m') = H(m). Collision resistance: It is computationally intractable to find a pair of messages m, m' such that H(m) = H(m').

[0065] In a UTXO-based blockchain, the solution to a cryptographic puzzle may be set as a spending condition in a transaction, sometimes called a bounty transaction. The puzzle bounty locked in the bounty transaction may be claimed by broadcasting a fulfillment transaction that references the bounty transaction and includes the solution to the puzzle. Verification of the solution is performed by miners as part of validating the transaction.

[0066] One of the most abundant types of cryptographic puzzles in blockchain applications is the hash puzzle. Hash puzzles can be used to lock a bounty within some transaction. The bounty can be claimed by providing a preimage m of some hash value H(m). The preimage m is not necessarily known to the creator of the bounty transaction.

[0067] The locking script for a bounty transaction locked by a hash puzzle looks like this: Lock script: OP_HASH256<H(m)> OP_EQUAL

[0068] Therefore, the unlock script for the fulfillment transaction is: Unlock script: <m>

[0069] A malicious actor who intercepts this fulfillment transaction can create a new fulfillment transaction containing the solution to the hash puzzle, m, with the output directed to their own address, and propagate that new fulfillment transaction throughout the network. If this second fulfillment transaction is accepted by the network before the first, the eavesdropper has therefore stolen the bounty from the legitimate solver.

[0070] This vulnerability occurs when a fulfillment transaction contains a public key P along with the solution to a hash puzzle. A This can be corrected by requiring that the locking script include a digital signature from the intended recipient with the following: Lock script: OP_HASH256<H(m)> OP_EQUALVERIFY OP_DUP OP_HASH160 <H(P A )> OP_EQUALVERIFY OP_CHECKSIG

[0071] And the unlock script of the corresponding fulfillment transaction must be: Unlock script:

number

[0072] However, this construction restricts who can fulfill the puzzle bounty to those with public key P A In some cases, it is desirable to allow anyone to claim a hash bounty by providing a preimage of the hash.

[0073] Thus, a problem arises in ensuring that the first user to broadcast a solution to a puzzle receives the bounty, even if the solution is not known to the challenger.

[0074] It will be understood that the term "bounty" as used herein is not limited to digital currency, but may include any lockable transaction output.

[0075] 5. Proof of sequential computation A proof of sequential computation is a proof that can be computed in a given amount of time N, but cannot be computed (significantly) faster, even when one has access to a large amount of parallel hardware. Proofs should ideally be easy to verify by anyone, in time polylog(N), without the need to interact with a trusted third party.

[0076] Time measures sequential work, i.e., the amount of work that cannot be performed faster by distributing the computation across multiple parallel cores. When the user's hardware is known, a proof of sequential computation can be used as proof that a specific amount of time has elapsed. If the user's speed is not known, a lower bound can be estimated based on the capabilities of modern hardware.

[0077] The following subsections describe three types of proofs for sequential computation: Sloth (Section 5.1), "Proof of Sequential Work" (PoSW) (Section 2.1), and Verifiable Delay Functions (VDFs) (Section 5.3).

[0078] 5.1 Sloth This first structure for proofs of sequential computation is

number

number

number

number

[0079] To overcome this limitation, the data are interleaved by simple permutations in a structure called Sloth.

number

[0080] More precisely, let p ≡ 3 mod 4 be a prime number.

number

number

number

number

number

number

number

[0081] Sloth chains are permutations

number

number

number

number

[0082] Repeating the permutation ρ gives ρ L This allows a shortcut in the calculation of L, where L is the length of the chain. This shortcut is first

number

number

[0083] Verifying each step in the chain takes O(log p) multiplications compared to the O(log p) multiplications required for evaluation.

number

number

[0084] 5.2. Proof of Sequential Work The sequential computational proofs described in the previous subsection are not asymptotically efficiently verifiable, i.e., verification of Sloth chains is a constant O(log p) times faster than the evaluation procedure. Below, Proof of Sequential Work (PoSW) is described, which achieves an exponential gap between evaluation and verification.

[0085] PoSW allows a verifier V to efficiently check that a prover P has expended a given amount of sequential work after receiving some statement χ.

[0086] Here, PoSW is easiest to define and prove secure in the Random Oracle Model (ROM), since it is possible to specify a (potentially parallel) query to a Random Oracle (RO) as one time step.

number

[0087] The notion of sequentiality in PoSW, as defined by ROM, relies on the computation of an H-sequence for a random oracle H. An H-sequence of length L is such that for each i, 1 ≤ i < L, H(x i ) is x i+1 is contained as a continuous subsequence in {0, 1}, i.e., for some a, b∈{0, 1} * Regarding x i+1 = a||H(x i )||b, the sequence x1, ..., x L ∈{0, 1} * (This is actually the case when the standard block length w = 256 is used, 2 w Whenever an adversary outputs an H-sequence of length L (for L much smaller than L), it can be assumed that the adversary has made at least L successive queries to H. H is assumed to be collision-resistant.

[0088] The ROM model PoSW consists of the following quadruple of algorithms: SETUP(1 λ ) → pp: Obtain the security parameter λ and the public parameter

number

number

[0089] PoSW should meet the following properties: Correctness: SETUP(1 λ ) output by any pp = (w, k), statement χ∈X, and time parameter

number

[0090] The correctness and soundness properties of PoSW suggest that a valid solution to PoSW constitutes a proof that T time has elapsed since χ was received.

[0091] Cohen and Pietrzak PoSW In Cohen and Pietrzak's PoSW (CP-PoSW), the random oracle is instantiated using a hash function H that is assumed to be sequential in nature. This means that computing an H-sequence of length T requires T queries to H. A statement χ sent by V to P is instantiated using a new hash function H, defined as H with χ as salt. χ is used to sample the

number

[0092] In CP-PoSW, P uses H to compute the label of a directed acyclic graph (DAG). The label of a node is the hash of the label of its parent (if there is a directed edge from u to v, then u is the parent of v). χ More precisely, we use the label l for i∈V. i ∈{0, 1} w is calculated recursively as follows:

number

[0093] Labels in a DAG can be computed in any topological order. Computing T labels in a DAG boils down to computing an H-sequence of length T, and thus H χ requires T sequential queries to

[0094] When employing a hash function H that uses the Merkle-Damgard construction, care must be taken to consider how the parents of a node are ordered when computing the node's label. The Merkle-Damgard construction is used for the compression function h: {0, 1} 2w → {0, 1} w Hash function H for any input length from {0, 1} * → {0, 1} w is used to construct the following: H(x1, ..., x z ) = y z , where for i ≥ 1, y i := h(x i , y i-1 )

[0095] Using this construction, we can find known prefixes x1,...,x i Just use y i The adversary can calculate the input x1,...,x z Before the whole is known, such intermediate i ' and therefore potentially take advantage of the advantages offered by parallelization for computing graph labels.

number

[0096] After labeling the DAG, P computes a Merkle tree-like commitment of the labels and sends it to V, which then challenges P to open a portion of the labels together with its parents. Finally, the verifier V verifies that the labels received from P are computed correctly and that the opening is correct relative to the initially received Merkle tree-like commitment.

[0097] Building a graph

number

[0098] DAG that must be labeled in CP-PoSW

number

[0099] Figure 3 shows the graph

number

[0100] Graphs used in CP-PoSW

number

[0101] Proof calculation If only logarithmic memory were used, P would need to recalculate all the labels of the graph in order to compute the opening of the label challenged by V. Fortunately, there is a simple trade-off: using a little more memory can make the proof computation significantly more efficient: the labels of the nodes in the top m levels of the tree

number

[0102] algorithm CP-PoSW consists of the following quadruple of algorithms: Time parameters

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

[0103] When the prover is a public coin, CP-PoSW sets the challenge γ as γ = (H χ (φ, 1), ..., H χ It can be made non-interactive using the Fiat-Shamir heuristic by deriving it as (φ, k). In a non-interactive version of CP-PoSW, the EVAL and OPEN algorithms can be merged.

[0104] The correctness of CP-PoSW follows from the structure of the protocol. χ by making T sequential queries on

number

[0105] For hash functions with large outputs (e.g., 256-bit outputs), after a dishonest prover receives χ (for 0 < α < 1), H χ If we make at most (1 - α)T sequential queries to V, then V will k Therefore, the protocol is sound when using large values ​​of k. For example, by setting k = 100, H χ A dishonest prover who makes 0.8T sequential queries to -32 (For k = 150, the probability is 2 -48 (Falls to .

[0106] Given a commitment vector (χ, T, φ), verifying a proof π can be done by anyone without access to any secret information. Verifying a proof π only requires verifying a sampling of the challenge γ, verifying that the corresponding labels were computed correctly, and verifying that the label Merkle tree-like commitment for φ is correct. In total, VERIFY requires O(k.log2T) sequential queries compared to the T sequential queries required for EVAL. CP-PoSW therefore provides an exponential gap between proof evaluation and proof verification.

[0107] 5.3 Verifiable Delay Functions A verifiable delay function (VDF) is a function f: X → Y that can be evaluated only after a specified number of sequential steps. A VDF generates a publicly verifiable proof that these steps were performed to produce an output. In a similar way to PoSW, a VDF guarantees that it takes at least a specific amount of time for a party to evaluate the proof. This specified computation time is also required on a parallel computer, and therefore the evaluation cannot be performed faster by parallelizing the computation. The only way to gain an advantage is by purchasing or designing faster hardware, but there is a theoretical lower bound on the time required to evaluate a VDF.

[0108] VDF can be considered a special case of PoSW that is unique in the sense that it is not possible to compute two accepting proofs for the same challenge: in PoSW, if a user removes any edge from the graph, the proof changes, but this is unlikely to be detected by a random challenge.

[0109] The VDF consists of the following triad of algorithms: SETUP(1 λ ) → pp: A randomized algorithm that takes a security parameter λ and generates a public parameter pp. EVAL(pp, (x, T)) → (y, π): Challenge

number

[0110] The VDF method should satisfy the following characteristics: Correctness: for any x∈X,

number

number

[0111] VDFs are based on computational tasks that cannot be accelerated by parallelization. Powers in groups of unknown order are thought to have this property. Two VDF structures have emerged that similarly exploit the serial nature of this task. 1. The first VDF structure (Pietrzak) is fast to create but larger and slower to verify. 2. The second VDF structure (Wesolowski) is slower to build (but parallelizable), but shorter and faster to verify.

[0112] In this specification, the first of these structures was used. The second VDF is shorter and faster to verify, but verifying it requires a primality test. A test that "proves" the primality of a number, rather than just "probably" primality, is called a deterministic primality test. When checking whether a number is truly prime within a transaction's lock script, it is desirable to perform a deterministic primality test because the script is public. The problem is that deterministic primality tests are quite costly when dealing with large numbers. The first VDF does not utilize any complex algorithms (such as primality tests) and is therefore preferable to the second VDF in the context of the use case provided herein. Furthermore, for a VDF that requires less than an hour to evaluate, the gap between the sizes of the two proofs is not significant.

[0113] Pietrzak's VDF Pietrzak's VDF (P-VDF) setup algorithm SETUP(1 λ ) outputs two things: Finite Abelian groups of unknown order

number

number

[0114] The evaluation algorithm EVAL(pp, (x, T)) is defined as follows: Calculate the hash value g ← H(x). Starting from g,

number

number

number

[0115] Pietrzak gives a concise argument for public coins to prove that the output y is correct.

number

number

number

number

number

number

number

number

number

number

number

number

number

number

[0116] characteristics P-VDF meets the characteristics of VDF. Correctness: From the recursive structure of the protocol,

number

number

number

number

number

number

number

number

number

number

number

number

number

[0117] Proof calculation The proof is that at every level of recursion, the quantity μ i We assume that g1 = H(x), and that μ1, r1 are the values ​​of μ and r at the highest level of the recursion, μ2, r2 are the values ​​at the next level, and so on. Solving the recursion shows that these quantities are

number

number

number

[0118] Proof When constructing π, these two d The stored values ​​are given to the VDF evaluator.

number

number

number

number

[0119] Specific group setup RSA groups where N = pq for any pair of distinct primes p and q

number

number

number

number

number

number

number

[0120] An integer N that is a product of strong primes can be used. A prime p is strong if (P - 1) / 2 is also prime. If N = pq is a product of different strong primes, then the group

number

number

number

number

number

number

number

[0121] The calculation is

number

number

number

number

number

number

number

number

number

number

number

number

number

number

[0122] surely

number

number

[0123] Non-interactive Protocols Thanks to the public-coin nature of Pietrzak's concise arguments, the proof can be made non-interactive using the Fiat-Shamir heuristic. The prover can then use the hash function

number

number

number

number

number

number

number

number

[0124] 6. Secure Puzzle Bounty A set of schemes are provided herein for protecting puzzle bounties that can be claimed by anyone and do not require the solution to be known to the challenger who creates the bounty transaction, also referred to herein as the challenge transaction. In the remainder of this section, the solution to the puzzle is referred to as S puz The challenger is represented by S puz The scheme creates a challenge transaction that can be fulfilled by anyone (the challengee) who broadcasts a fulfillment transaction, also referred to herein as a solution transaction, that contains the solution S puz By preventing S from intercepting the puz This ensures that the first user to broadcast effectively receives the puzzle bounty.

[0125] The solution to the puzzle that locks a Bitcoin transaction must be publicly verifiable so that any miner can verify its correctness. Any suitable puzzle may be used in the schemes provided herein. Some exemplary suitable puzzles whose solutions are publicly verifiable include: Hash Puzzles: Puzzles can be solved by providing a preimage of some hash value (Section 4). Prime Number Puzzle: The puzzle expects a solution that is a prime number greater than a predefined value. This puzzle motivates the user to exert their computing power in order to find a large prime number. · Evaluation of some verifiable delay function: The puzzle rewards any user who computes the evaluation of some verifiable delay function, typically the result of multiple squaring operations in the RSA group. Proof of retrievability: The puzzle requires proof that a user has allocated space to store a particular file, and that this file is intact. Protein Folding: The puzzle requires the user to fold some protein and prove that the user did so correctly.

[0126] The puzzle used may allow the bounty to be claimed by anyone, and the solution to the puzzle does not necessarily have to be known to the challenger.

[0127] The schemes for securing puzzle bounties all follow the same principle: the user must provide the puzzle solution S in a fulfillment transaction. puz In addition, S puz and some proof of computation bound to the public key Pk that signs the fulfillment transaction.

number

[0128] The computational proof guarantees that a specific amount of time has passed since the solver found the solution to the puzzle. This time delay is puz A malicious user who intercepts the public key Pk' can obtain a valid certificate bound to that public key Pk'.

number

[0129] One challenge in designing these methods is

number

number

[0130] The schemes used to protect puzzle bounties separately utilize five different types of proofs of computation. Section 6.1 -- Proof of Work (PoW): This scheme is inspired by Bitcoin's PoW. While the size overhead is negligible, this scheme is not secure against parallel adversaries. Section 6.2 -- Chained Proof of Work: This scheme is based on chaining PoW to limit the advantage provided by parallel computation. The size overhead is very large for both users and challengers (bounty and fulfillment transactions).

[0131] The following three methods are based on sequential proofs of computation, which remove the advantages offered by parallel computation. Section 6.3 -- Sloth: This scheme uses the Sloth structure described in Section 5.1. The size overhead is negligible for fulfillment transactions, but is very large for bounty transactions. Section 6.4 -- Proof of Sequential Work: This scheme uses Cohen and Pietrzak's PoSW, described in Section 5.2. The overhead is balanced between bounty transactions and fulfillment transactions. Section 6.5 -- Verifiable Deferred Function: This scheme uses Pietrzak's VDF, described in Section 5.3. The main overhead is in the bounty transactions.

[0132] In Section 6.6, a detailed comparison of the methods in terms of script size, depending on the desired security level and resistance to parallel computation, is presented.

[0133] In each of the schemes described below, the challenger generates a lock script for inclusion in the challenge transaction, and the lock script verifies the following: i. The solution S of the puzzle provided by the challenger puz Filling the puzzle, ii. The proof provided by the challenger

number

[0134] The standard of proof implemented depends on the scheme selected. In each case, the standard of proof is the proof provided by the challenger.

number

[0135] In each method, the challenge is to find a solution to the puzzle, S puz and proof

number

[0136] Figure 4 summarizes the methods for each method.

[0137] As step 1, the challenger 402 defines a puzzle and a challenge. The puzzle may be one of the puzzles described above, and the solution to the puzzle is publicly verifiable. The challenge defined by the challenger 402 may specify the type of scheme to be used and any variables of the challenge criteria. For example, if the challenge criteria define a threshold (see examples in Sections 6.1 and 6.2), this may be defined by the challenger 402 when defining the challenge. Other challenge variables may include the chain length L, the time parameter T, and the number of leaves k. It will be apparent to one skilled in the art upon reading the schemes described below that other variables may be provided as challenge variables of the challenge. The scheme used is identified, for example, by its name or other suitable identifier, or by the calculation to generate the proof.

[0138] In step 2, the challenger 402 generates a challenge transaction. The challenge transaction is a puz ,Proof

number

[0139] In step 4, the challenge and puzzle are made available to the challenger 404. They may be sent directly from the challenger 402 to the challenger 404. Alternatively, the puzzle and challenge may be made publicly available, for example, on a website. In some embodiments, the challenge and puzzle are provided within the challenge transaction such that the puzzle and challenge are made visible when the challenge transaction is sorted into the blockchain 150 or when the challenge transition is retrieved from the blockchain 150.

[0140] In step 5, the challenge 404 is generated to find a candidate puzzle solution S corresponding to the defined puzzle. puz In step 6, the challenger 404 generates the candidate's proof using the candidate's puzzle solution and the challenger's 404 public key.

number

[0141] The challenger 404 generates a solution transaction that includes a first unlocking script to unlock the UTXO of the challenge transaction. The first unlocking script is a solution S of the candidate puzzle. puz ,Candidate Proof

number

[0142] The first locking script of the challenge transaction is then executed together with the first unlocking script of the solution transaction to verify the candidate puzzle solution, candidate proof, and signature in step 9. The method for verifying the candidate proof depends on the scheme used, as described below.

[0143] If the candidate proof, candidate puzzle solution, and signature each verify, the UTXO is made available to the challenger 404.

[0144] The method of Figure 4 is implemented in each of the schemes described below, with a different challenge defined for each scheme. The way in which candidate proofs are generated (step 6) and the proofs are verified (step 9) depends on the scheme being used.

[0145] 6.1 Proof of Work This method for securing puzzle bounties is inspired by Bitcoin's Proof of Work (PoW), which uses PoW to secure bounties. The first miner to solve the PoW puzzle can fulfill the bounty by claiming the coinbase transaction. If the coinbase transaction (or any other transaction in the block) is amended, the solution to the PoW puzzle changes, and therefore the work must be started over, so the bounty is secure.

[0146] Similarly, a puzzle bounty can be protected by requiring the puzzle solver (challenger) to provide the solution to the PoW puzzle in a fulfillment transaction. More specifically, the puzzle solution S puz Given a public key Pk to sign the execution transaction, a 32-byte target difficulty target, and a hash function H, the proof adopted in this scheme is

number

number

[0147] The smaller the target value, the longer it will take (probabilistically) for a user to find a nonce value that satisfies this formula.

[0148] In this scheme, the proof provided by the challenger is a nonce.

[0149] The standard of proof is sometimes said to define a target. The proof (nonce), public key (Pk), and puzzle solution (S) provided by the challenger in the solution transaction are used to prove the validity of the challenge. puz ) is less than or equal to the threshold. In this example, the candidate's target value is int(H(nonce||Pk||S puz )) mod 2 256 However, it will be appreciated that other functions for defining candidate target values ​​may be defined.

[0150] To determine the challenge proof, the challenger has access to the proof criteria and, in particular, functions and thresholds to define the candidate's target value. The challenger may perform trial-and-error calculations to find a proof (nonce) that meets the criteria.

[0151] In the implementation below, the hash function H is SHA256 applied twice. [VerifyPuzzleSolution] is the puzzle solution S required to fulfill the bounty. puz The lock script for a bounty transaction protected by a PoW puzzle looks like this: Lock script: OP_2 OP_PICK OP_2 OP_PICK OP_CAT OP_CAT OP_HASH256 OP_CAT <target>OP_LESSTHANOREQUAL OP_VERIFY [VerifyPuzzleSolution] OP_CHECKSIG

[0152] The fulfillment transaction unlock script looks like this: Unlock script: <sig Pk > <pk> <S puz > <nonce>

[0153] The unlock script is effective in the following cases: Generate a hash whose nonce value is less than or equal to the specified target, i.e., int(SHA256(SHA256(nonce||Pk||S puz ))) ≦ target. Puzzle Solutions puz is correct (passes the VerifyPuzzleSolution check). The signature is a valid signature for the transaction and the public key Pk.

[0154] Validating the nonce value ensures that a certain amount of time has passed since the solver found the solution. Because the nonce is concatenated with Pk before hashing it, another user cannot swap Pk without spending time recomputing a valid nonce.

[0155] The size overhead of bounty and fulfillment transactions is only a few bytes.

[0156] FIG. 5 shows in schematic form the verification steps that are performed to approve an unlock script.

[0157] The challenger 402 generates a challenge transaction 502 with a lock script containing a threshold target. The challenger 404 generates a solution S of the candidate puzzle. puz , the candidate's proof nonce, and the unlock script containing the challenger's public key Pk. The solution transaction 504 contains a signature sig derived from the challenger's public key Pk. Pk Also includes.

[0158] At that time, the lock script of the challenge transaction 502 and the unlock script of the solution transaction 504 are executed together, and steps A to D are executed in the scripts.

[0159] First, in step A, a candidate target value is calculated using the candidate proof of the unlock script, the public key, and the puzzle solution. Then, in step B, the calculated candidate target value is compared to the threshold value of the lock script to determine whether the calculated candidate target value meets the challenge criteria, i.e., whether the candidate target value is less than or equal to the threshold value.

[0160] In step C, the solution to the candidate puzzle is verified with respect to the puzzle defined by challenger 402. The manner in which the candidate puzzle is verified depends on the type of puzzle used. Those skilled in the art will understand the manner in which the solution to the candidate puzzle may be verified.

[0161] Then, in step D, it is determined whether the signature of the solution transaction 504 is valid for the public key of the unlock script.

[0162] If each check proves valid, the unlock script of solution transaction 504 is determined to be valid and the UTXO of challenge transaction 502 is unlocked.

[0163] 6.2 Chained Proof of Work One problem with previous schemes is that a highly motivated adversary can easily speed up the generation of a PoW solution by deploying sufficient parallel hardware. That is, in the proof-of-work scheme described in Section 6.1, the time required to compute a valid nonce can vary from user to user. In fact, solving a PoW puzzle can be (probabilistically) sped up by parallelizing the computation. For a given target value, an adversary's ability to steal the puzzle bounty depends on the amount of hardware they have. Therefore, the PoW schemes described above are not secure against adversaries who can deploy large amounts of parallel hardware.

[0164] To diminish the advantage offered by parallelization, the following scheme can be used to protect puzzle bounties.

[0165] Instead of a single PoW puzzle, the following scheme requires users to solve multiple PoW puzzles chained together. Because chaining requires the previous value to construct the next puzzle, the process of solving a chain of PoW puzzles is somewhat sequential. In particular, synchronization between processors is required each time a solution to a PoW puzzle in the chain is found. This property can be used to limit the advantages of using massively parallel computation in stealing puzzle bounties.

[0166] A chained PoW puzzle is defined as follows: The first puzzle in the chain is defined in the same way as before. The solution S of the puzzle puz Given a public key Pk to sign a fulfillment transaction, a 32-byte target difficulty target, and a hash function H, the goal is int(H(nonce0||Pk||S puz )) mod 2 256 ≦ target The goal is to find a value nonce0 such that Subsequent puzzles in the chain build on previous puzzles, similar to how the chain of block headers is secured in Bitcoin. In particular, the ith puzzle in the chain is int(H(nonce i ||h i-1 )) mod 2 256 ≦ target A value nonce such that i Need to find h i-1 is the hash value resulting from solving the previous puzzle, and H and target are the same as in the first puzzle, i.e.,

number

[0167] In this scheme, the proof of computation of a chain of length L

number

number

number

number

[0168] That is, the challenge proof is the candidate's proof value (nonce i ) and is used to calculate a sequence of candidate target values. The first candidate target value (h0) among the candidate target values ​​is nonce0, S puz , and Pk. The target value (h i ) is the corresponding proof value (nonce i ) and the target value of the previous candidate in the chain. The target value of the last candidate is calculated from the final proof value, nonce L-1 and the target value h of the penultimate candidate L-2 Since the final candidate target value is calculated based on the proof values, i.e., the proof

number

[0169]

number

number

[0170] In the implementation below, the hash function H is SHA256 applied twice. A locking script for bounty transactions secured by chained PoW puzzles of length L >= 2 can be constructed by adding the following opcodes: 1. Copy the second to last and third to last values ​​onto the top of the stack (to pull Pk and sol): <L + 1> OP_PICK<L + 1> OP_PICK 2. The first nonce value, nonce0, is int(SHA256(SHA256(nonce0||Pk||S puz Verify that ))) ≦ target is satisfied. OP_CAT OP_CAT OP_HASH256 <target>OP_SWAP OP_2DUP OP_CAT OP_GREATERTHANOREQUAL OP_VERIFY 3. For i = 1 to L-2, the nonce i int(SHA256(SHA256(nonce i ||h i-1 Add the following opcode to verify that ))) ≤ target is satisfied. OP_ROT OP_SWAP OP_CAT OP_HASH256 OP_2DUP OP_CAT OP_GREATERTHANOREQUAL OP_VERIFY 4. Final nonce L-1 int(SHA256(SHA256(nonce L-1 ||h L-2 Verify that ))) ≤ target: OP_ROT OP_SWAP OP_CAT OP_HASH256 OP_CAT OP_GREATERTHANOREQUAL OP_VERIFY 5. Puzzle Solution S puz Verify that is correct: [VerifyPuzzleSolution] 6. Verify that the signature is a valid signature for the transaction and public key Pk: OP_CHECKSIG

[0171] The fulfillment transaction unlock script looks like this: Unlock script: <sig Pk > <pk><S puz > <nonce L-1 > <nonce L-2 > ... <nonce0> <nonce L-1 > <nonce L-2 > ... <nonce0>is a sequence of proof values.

[0172] The unlock script is effective in the following cases: Generate a hash with a nonce value nonce0 less than or equal to the specified target, i.e., int(SHA256(SHA256(nonce0||Pk||S puz ))) ≦ target. Each subsequent nonce value i For 0 < i ≦ L - 1, int(SHA256(SHA256(nonce i ||h i-1 ))) ≦ target. Puzzle Solutions puz is correct (passes the VerifyPuzzleSolution check). The signature is a valid signature for the transaction and the public key Pk.

[0173] In this scheme, each puzzle depends on the previous one. Because the first puzzle is initialized with the public key Pk that signs the fulfillment transaction, there is a dependency between Pk and all subsequent puzzles. This implies that an adversary cannot reuse any of the nonces in the chain and would have to recompute all of them in order for the adversary's fulfillment transaction signed with Pk' ≠ Pk to be valid.

[0174] The target value h for each candidate i is checked against a threshold target. It is important to verify each of the candidate targets. This is because the final candidate target value h L-1 Only the int(SHA256(SHA256(nonce L-1 ||h L-2 If we check ))) ≦ target, then the challenge is a suitable h L-2 All we need to do is find a suitable h L-2 The amount of work required to find ∑ i = ...

[0175] Figure 6 shows a schematic of a method for validating the unlock script of a solution transaction 604. The method is similar to the method of Figure 5 described above.

[0176] The challenger 402 generates a challenge transaction 602 with a lock script containing a threshold target. The challenger 404 generates a challenge transaction 602 with a lock script containing a candidate puzzle solution S puz , Proof of candidate nonce0,..., nonce L-1 , and the unlock script containing the challenger's public key Pk. The solution transaction 604 contains a signature sig derived from the challenger's public key Pk. Pk Also includes.

[0177] The lock script of the challenge transaction 602 and the unlock script of the solution transaction 604 are then executed together so that steps A to E are executed in the script.

[0178] First, in step A, the target value h0 of the first candidate is calculated using the proof value nonce0 of the first candidate of the unlock script, the public key, and the puzzle solution. Then, the target values ​​h i are calculated in step B, and each of these candidate target values ​​is the corresponding candidate proof value nonce i and the target value of the previous candidate among the candidate targets h i-1 Based on.

[0179] Then, in step C, the calculated candidate target value h i To determine whether each candidate target value satisfies the challenge criteria, i.e., whether each candidate target value is below the threshold, the calculated candidate target value h i Each of these is compared to the threshold of the lock script.

[0180] In step D, the solution to the candidate puzzle is verified with respect to the puzzle defined by challenger 402. The manner in which the candidate puzzle is verified depends on the type of puzzle used. Those skilled in the art will understand the manner in which the solution to the candidate puzzle may be verified.

[0181] Then, in step E, it is determined whether the signature of the solution transaction 604 is valid for the public key of the unlock script.

[0182] If each check proves valid, the unlock script of the solution transaction 604 is determined to be valid and the UTXO of the challenge transaction 602 is unlocked.

[0183] In the scheme described in this section, the challenger can use parallel computing to solve the puzzle, but each intermediate value h i With respect to i+1 must be synchronized to start solving the next problem for , which limits the speedup that can be achieved by parallelizing the computation.

[0184] Because puzzles are linked in a chain, synchronization between processors is required, which creates some resistance to parallel computation. However, an adversary can still use parallel computation to speed up the solution of each individual puzzle. Therefore, a large chain is required to reduce the effect of parallel computation. Each hash puzzle in a chain requires an additional 7 bytes in the bounty transaction and one nonce value in the fulfillment transaction. Considering a chain of hundreds of thousands of hash puzzles, the overhead caused by a chained PoW scheme can be very large.

[0185] In practice, this approach has limitations because the script size quickly becomes very large when strong resistance to parallel computation is desired, i.e., there is a trade-off between script size and resistance to parallel computation.

[0186] As an alternative that is inherently completely tolerant to parallel computation and has a moderate script size, the following scheme is provided.

[0187] 6.3 Sloth As explained above, previous chained PoW schemes can be used to reduce the advantage of using large parallel hardware to steal puzzle bounties. However, the effect is only noticeable when large chains of puzzles are used. The problem with having large chains of puzzles is that it introduces overhead due to the large size of bounty transactions and fulfillment transactions, and is therefore inefficient in terms of storage.

[0188] In this scheme, the Sloth chains described in Section 5.1 are used to produce a scheme that is completely resistant to parallel adversaries.

number

[0189] The advantage of using sequential computational proofs is that the time required to evaluate them can be much better estimated, since the evaluation does not depend on the amount of hardware available. While users (challengers) can continue to invest in faster hardware to speed up proof evaluation, the physical limitations of hardware impose a limit on the computational time gap between users, which can be made unlimited in parallelizable proofs of computation. In particular, there is a theoretical lower bound on the time required to evaluate any sequential computational proof.

[0190] Sloth uses interleaved simple substitutions so that chains can only be evaluated sequentially.

number

number

number

number

[0191] The output of a Sloth chain of length L for an input x is

number

number

number

number

[0192] Puzzle Solution puz , public key Pk to sign the fulfillment transaction, 2048-bit prime number p, hash function H, chain length

number

number

number

[0193] The value of x, sometimes referred to herein as an intermediate value, is based on the public key and the solution to the puzzle. w is the candidate proof and may be described as being derived by the challenger by computing a series of square root calculations. The challenger's computation of w is described in more detail in Section 5.1.

[0194]

number

number

number

[0195] In the implementation below, the hash function H is SHA256 applied twice. A locking script for a bounty transaction secured by a Sloth chain of length L can be constructed by adding the following opcodes: 1. Push a prime number p onto the stack: 2.

number

number

number

[0196] That is, the lock script is executed by the function

number

[0197] The fulfillment transaction unlock script looks like this: Unlock script: <sig Pk > <pk> <S puz > <w>

[0198] The unlock script is effective in the following cases: Input Pk||S puz Sloth's chain evaluation w for is correct, i.e.,

number

[0199] FIG. 7 provides a schematic diagram of a method for validating the unlock script of a solution transaction 704 .

[0200] The challenger 402 generates a challenge transaction with a lock script that contains scripts to perform the following verification steps: The challenger 404 receives a solution S of the candidate puzzle. puz , the candidate's proof w, and the unlock script containing the challenger's public key Pk. The solution transaction 704 includes a signature sig derived from the challenger's public key Pk. Pk Also includes.

[0201] The lock script of the challenge transaction (not shown) and the unlock script of the solution transaction 704 are then executed together so that steps A to E are executed in the script.

[0202] First, in step A, the candidate target value is the inverse function of the invertible function, i.e.,

number

[0203] In step B, an intermediate value x is calculated using the public key of the solution transaction 704 and the solution to the candidate puzzle. It will be appreciated that the prime number p may be provided in the lock script of the challenge transaction as a challenge variable.

[0204] The candidate target value and the calculated intermediate value are then compared in step C to determine whether they meet the challenge criteria, i.e., whether the two values ​​are equal.

[0205] In step D, the solution to the candidate puzzle is verified with respect to the puzzle defined by challenger 402. The manner in which the candidate puzzle is verified depends on the type of puzzle used. Those skilled in the art will understand the manner in which the solution to the candidate puzzle may be verified.

[0206] Then, in step E, it is determined whether the signature of the solution transaction 704 is valid for the public key of the unlock script.

[0207] If each check proves valid, the locking script of the solution transaction 704 is determined to be valid and the UTXO of the challenge transaction is unlocked.

[0208] The overhead of a fulfillment transaction is just one additional 2048-bit value w (for a prime p of size 2048 bits) resulting from evaluating the Sloth chain. However, the size of the lock script of the bounty transaction verifying w depends linearly on the length of the Sloth chain. For a chain of length L and a prime p of size B bytes, the bounty transaction size overhead is 17 + 23 × L + B bytes. Since Sloth difficulty depends linearly on the chain length, the bounty transaction size overhead grows linearly with the difficulty.

[0209] 6.4. Proof of Sequential Work In this scheme, Proof of Sequential Work (CP-PoSW), as described by Cohen and Pietrzak, is used as the proof of computation employed to protect the puzzle bounty. CP-PoSW constitutes a proof of sequential computation in the same way as Sloth chains. In CP-PoSW, the difference between evaluation time and verification time is exponential in difficulty, whereas in the Sloth scheme this difference is only constant (by a factor of O(log p)).

[0210] In CP-PoSW, the challenge labels a directed acyclic graph G = (V, E) of T nodes, which requires performing T sequential hash computations. Figure 3 shows an example graph 300 for use in such a scheme.

number

number

[0211] In the implementation below, the hash function used to label the graph G is the function HASH256 χ : x→SHA256(SHA256(χ||x)), where χ = SHA256(SHA256(Pk||S puz )), Pk is the public key that signs the fulfillment transaction, and S puz is the solution to the puzzle for which the bounty needs to be protected. χ is assumed to be sequential in nature, i.e., for each i ≤ i < T, there exists some a, b∈{0, 1} * Regarding x i+1 = a||HASH256 χ (x i )||b, a sequence x1, ..., x of length T T ∈{0, 1} * Calculating HASH256 χ requires T sequential queries to

[0212] Label l of node i∈V i is calculated as follows:

number

[0213] label

number

[0214] In CP-PoSW, the challenger commits to the label of V by sending a Merkle tree-like commitment φ to the verifier, which is the Merkle root of the Merkle tree for the label of V. In the non-interactive version of CP-PoSW, the user (challenger) ... i = HASH256 χ (φ||i) mod 2 t randomly sample and obtain the proof vector π = (π1, ..., π k ) to the verifier (challenger). For each 1 ≦ i ≦ k, π i is leaf γ i The proof vector contains openings labeled with . Thus, the proof vector is sometimes called the set of openings corresponding to the directed acyclic graph G. Openings are analogous to Merkle proofs, which correspond to the leaves of a Merkle tree. The graph G produced by the challenger is sometimes called the candidate directed acyclic graph G.

[0215] Then the verifier selects k leaves γ1,...,γ k resample k, verify that the labels of those leaves were correctly computed using the labels of those leaves' parents, and verify that the opening is correct for the originally received commitment φ. By verifying only a subset of the leaves of the candidate graph G, the verifier can verify that the challenger met the criteria of the challenge more quickly than if all leaves were verified. The challenger chooses the value of k to be large enough to ensure with high probability that the challenger has computed the majority of the labels.

[0216] Choosing a large value for k will result in a larger script size, and therefore there is a trade-off to be made between security and computational efficiency.

[0217] Puzzle Solution puz , the public key Pk to sign the fulfillment transaction, and security parameters

number

number

number

number

number

[0218] χ, sometimes referred to herein as the intermediate value, is calculated based on the public key and the puzzle solution.

[0219] [Opening γ i ] is γ i π including the opening of the label i This script part [Opening γ i ] can be constructed as follows: 1. Gamma i The opening of the label, i.e., γ i Add all the labels of the siblings of the node on the path from γ to the root. The labels are ordered by increasing order of their height in the tree (first the labels with height 1, then the labels with height 2, and so on). For example, γ i = 0011 (see Figure 3), then l1 and l 01 and,l 000 And, and 0010 Add the following. 2. Gamma i Label

number

number

[0220] In the implementation described here, the node identifier is the integer value of the identifier in big-endian format defined in CP-PoSW (see Section 5.2). In the previous example, γ i is equal to 3, not 0011 as defined in CP-PoSW. This suggests that multiple nodes at different levels of the tree can have the same identifier. Even if multiple nodes have the same identifier, their labels will be different because they have different parents. Therefore, having multiple nodes sharing the same identifier should not allow users to speed up the calculation of a graph's label.

[0221] The graph G used in CP-PoSW is γ i The parent label of is γ i The opening of the label is included in the [Opening γ i ] are the positions of γ i For example, with reference to graph 300 in FIG. 3, γ i = 3 302, the parent label is [Opening γ i ] appear at positions 2 and 3, and they are certainly 000 306 and l 0010 Corresponds to 304.

[0222] [HASH256 χ ] is the function HASH256 χ The bottom three elements of the main stack are represented by the part of the script that implements <sig Pk >(bottom), <pk>, and puz > is assumed to be

[0223] [HASH256 χ ] := OP_DEPTH OP_2 OP_SUB OP_PICK OP_DEPTH OP_3 OP_SUB OP_PICK OP_CAT OP_HASH256 OP_SWAP OP_CAT OP_HASH256

[0224] [VerifyOpening γ i ] is the leaf of some challenge γ i Regarding [Opening γ i ] included in γ i In what follows, it is assumed that a Merkle tree-like commitment φ is at the top of the alt stack. Furthermore, the bottom three elements of the main stack are <sig Pk >(bottom), <pk>, and <sol>(top).

[0225] Script part [VerifyOpening γ i ] can be constructed as follows for some 1≦i≦k: 1. Challenge Leaf γ i is γ i = int(HASH256 χ (φ||i)) mod 2 t Verify that it was sampled correctly as: OP_DUP OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_CAT [HASH256 χ ] OP_CAT <2 t > OP_MOD OP_NUMEQUALVERIFY 2. Gamma i Pushes the parent of onto the alt stack. i The position of the 1 in the binary representation of is used to locate its parent: i. Push flag -1 onto the alt stack: OP_1NEGATE OP_TOALTSTACK ii. Add the following opcodes for j = t - 1 to 0: OP_DUP <2 j > OP_DIV OP_2 OP_MOD OP_0NOTEQUAL OP_IF <j + 2> OP_PICK OP_TOALTSTACK OP_ENDIF 3. Gamma i Label

number

[0226] The complete locking script for a CP-PoSW secured bounty transaction looks like this: Lock script: OP_TOALTSTACK [VerifyOpening γ1] [VerifyOpening γ2] ... [VerifyOpening γ k ] OP_FROMALTSTACK OP_DROP [VerifyPuzzleSolution] OP_CHECKSIG

[0227] The fulfillment transaction unlock script looks like this: Unlock script: <sig Pk > <pk> puz > [Opening γ k ][Opening γ k-1 ] ... [Opening γ1] <φ>

[0228] The unlock script is effective in the following cases: ·γ1,...,γ k Each opening of the label is valid. Puzzle Solutions puz is correct (passes the VerifyPuzzleSolution check). The signature is a valid signature for the transaction and the public key Pk.

[0229] FIG. 8 illustrates a method for validating the unlock script of a solution transaction 804 .

[0230] The challenger 402 generates a challenge transaction (not shown) with a lock script that contains scripts to perform the following verification steps: puz , Proof of the candidate [Opening γ k ][Opening γ k-1 ] ... [Opening γ1] <φ>, and generate a solution transaction 804 with an unlock script containing the challenger's public key Pk. The solution transaction 804 contains a signature sig Pk Also includes.

[0231] The lock script of the challenge transaction and the unlock script of the solution transaction 804 are executed together so that steps A to F are executed in the script.

[0232] First, in step A, the candidate leaf value γ i ​is computed using the commitment φ. It will be appreciated that the parameter t may be provided in the lock script of the challenge transaction as a challenge variable. The intermediate value χ may also be computed based on the candidate's puzzle solution and public key. The candidate's leaf value is compared with the leaf value of the candidate graph G to verify that the leaf was sampled correctly.

[0233] In step B, γ i Label

number

number

[0234] Then, the opening of the commitment is the target commitment l based on the opening of the solution transaction 804. ε Step C to calculate the goal commitment l ε The solution transaction 804 is verified by step D, which compares the commitment φ with the candidate commitment φ of the solution transaction 804.

[0235] In step E, the solution of the candidate puzzle is verified with respect to the puzzle defined by challenger 402. The manner in which the candidate puzzle is verified depends on the type of puzzle used. Those skilled in the art will understand the manner in which the solution of the candidate puzzle may be verified.

[0236] Then, in step F, it is determined whether the signature of the solution transaction 804 is valid for the public key of the unlock script.

[0237] If each check proves valid, the unlock script of the solution transaction 804 is determined to be valid and the UTXO of the challenge transaction is unlocked.

[0238] Each leaf of G has a maximum

number

[0239] 6.5 Verifiable Delay Functions In this scheme, Pietrzak's VDF (P-VDF), as explained in Section 5.3, is used as the proof of the computation employed to protect the puzzle bounty. The P-VDF is a proof of computation for any input x∈{0, 1} * , time parameter

number

number

number

[0240] The P-VDF-based scheme works as follows: the challenger chooses a security parameter λ, a time parameter T, and a group on which the operation is to be performed.

number

number

number

number

[0241] In addition to the result value y of the P-VDF evaluation, log2T elements μ1,...,μ are used to prove that y was computed correctly. t The proof is attached with a proof π consisting of the proof value μ i It is sometimes said to contain a sequence of

[0242] To verify the proof, the challenger needs to perform 2 log2T exponentiations, as detailed in Section 5.3. Similar to CP-PoSW, P-VDF achieves an exponential gap between proof evaluation time and verification time.

[0243] Puzzle Solution puz , a public key Pk to sign the fulfillment transaction, a hash function H, and some

number

number

number

number

number

[0244] x is sometimes called the intermediate value. The result value y is calculated by the challenger as the result of a sequence of squaring operations based on the intermediate value, as described in Section 5.3. Each proof value is derived from a hash of the intermediate value.

[0245] Parameter Setup Depending on the settings used, the group on which the operation is performed

number

number

[0246] For a sufficient level of security, N should be at least λ in size. RSA = 2048 bits. Hash function

number

number

number

number

number

number

number

number

[0247] In the non-interactive version of P-VDF, a hash function, hash, is used to generate the challenge, r. Depending on the desired security level, the hash function, hash, used in Bitcoin scripts can be (for λ = 160):

number

number

number

[0248] Verification script [ModExponentiate] takes x, a, and n as inputs and modifies x a represents the part of the script that returns mod n (the implementation is detailed later). A lock script that performs validation of the P-VDF evaluation can be constructed as follows: 1. Push N onto the main stack: <n> 2. (1 < μ i < N - 1 and

number

number

number

number

number

number

number

number

number

number

number

[0249] The corresponding unlock script would look like this: Unlock script:

number

[0250] That is, the lock script is a first index g for 1 ≦ i ≦ t + 1. i series and the second index y i The first one of the first exponents, g1, is calculated based on the public key and the puzzle solution, and the first one of the second exponents, y1, is a result value provided in the unlocking script.

[0251] The subsequent first and second exponents g i , y i Each of the first and second indices is a first index and a second index g i-1 , y i-1 , and each previous one of the certification values ​​μ i-1 That is, all previous values ​​of both the first and second series of exponents are required to calculate the next exponent in each series.

[0252] The last second exponent y t+1 is the last first index g t+1 If it is equal to the square of mod N, then the proof is verified.

[0253] The unlock script is effective in the following cases: ·

number

[0254] FIG. 9 illustrates a method for validating the unlock script of a solution transaction 904 .

[0255] The challenger 402 generates a challenge transaction (not shown) with a lock script that contains scripts to perform the following verification steps: puz , the candidate's proof π, and the unlock script containing the challenger's public key Pk. The solution transaction 904 contains a signature sig derived from the challenger's public key Pk. Pk Also includes.

[0256] The lock script of the challenge transaction and the unlock script of the solution transaction 904 are executed together so that steps A-G are executed in the script. The lock script may also include a time parameter T and a value N.

[0257] First, in step A, the proof value μ i is checked.

[0258] In step B, the first index g i is calculated using the public key and the candidate puzzle solution. Then, in step C, the initial primary exponent is checked using the inverse of the initial primary exponent provided in the solution transaction 904.

[0259] In step D, the first index g i , the second index y i , and r i A series of values ​​of is calculated using the equations described in step 8 above.

[0260] In step E, to determine whether the challenge criteria are met, the final second index y t+1 is the last first exponent g t+1 is compared with the square of

[0261] In step F, the solution to the candidate puzzle is verified with respect to the puzzle defined by challenger 402. The manner in which the candidate puzzle is verified depends on the type of puzzle used. Those skilled in the art will understand the manner in which the solution to the candidate puzzle may be verified.

[0262] Then, in step G, it is determined whether the signature of the solution transaction 804 is valid for the public key of the unlock script.

[0263] If each check proves valid, the unlock script of the solution transaction 904 is determined to be valid and the UTXO of the challenge transaction is unlocked.

[0264] If N is assumed to be 256 bytes in size and c is assumed to be 1 byte in size, the size overhead of the fulfillment transaction is 767 + 512 × t bytes. As explained below, the size of [ModExponentiate] is 6921 bytes for a 256-bit exponent. If N is assumed to be 256 bytes in size, the size overhead of the bounty transaction is approximately 13904 × t bytes. Since the difficulty of P-VDF depends exponentially on the parameter t, the size overhead of the bounty and fulfillment transactions grows logarithmically with the difficulty.

[0265] Modular exponentiation in scripts Below, we explain the part of the script that performs modular exponentiation [ModExponentiate]. a Mod n can be calculated with the square and multiply algorithm. The following assumptions are made: The value x to be raised is such that 0 < x < n. The size of a is known. · Modulo n is strictly greater than 1.

[0266] x a To calculate mod n, all squares

number

[0267] Starting with x, a, n on the top of the stack, x is represented using k bits. a The script for calculating mod n is constructed using the following opcodes: 1. Initialize the result res to 1: OP_ROT OP_ROT OP_1 OP_ROT OP_ROT OP_DUP 2. For i = 0 to k, add the opcode: OP_IF OP_DUP OP_2 OP_MOD / / Calculate a mod 2 OP_SWAP OP_2 OP_DIV OP_TOALTSTACK / / Performs integer division of a by 2 and stores the value on the alt stack OP_IF / / if a mod 2 == 1 OP_DUP OP_ROT OP_MUL OP_2 OP_PICK OP_MOD OP_SWAP OP_ENDIF OP_DUP OP_MUL OP_2 OP_PICK OP_MOD OP_FROMALTSTACK OP_DUP OP_ELSE OP_0 OP_ENDIF 3. Conclude by cleaning up the stack: OP_2DROP OP_DROP OP_NIP

[0268] Each iteration takes 27 bytes. For a k-bit exponent a, step 2 above takes 27*k bytes. Adding 6 bytes for initialization (step 1) and 3 bytes for stack cleanup (step 3), the script has a total size of 9 + 27*k bytes.

[0269] 6.6 Method Selection The scheme presented here protects the puzzle bounty by requiring the user (challenger) to provide some proof of computation (proof) that is bound to the puzzle solution and the public key that signs the fulfillment transaction. The proof of computation guarantees that a certain amount of time has passed since the solver found the solution to the puzzle and is also required against malicious users who intercept the solution.

[0270] Three security levels for protecting puzzle bounties may be defined, which correspond to the amount of time required to generate a proof of computation. Base security -- 10 seconds: This roughly corresponds to the time it takes for a transaction to propagate throughout the network. If a malicious user broadcasts an alternative fulfillment transaction, this transaction will be considered invalid since the first legitimate fulfillment transaction was already received by the node. However, this does not prevent a malicious miner from rejecting the first legitimate fulfillment transaction and mining a block containing an alternative fulfillment transaction. In Bitcoin SV, such behavior is detected by other miners through the double-spend prevention mechanism. Medium Security -- 10 minutes: This corresponds to the average time it takes the network to mine a new block. This security level ensures that if a legitimate fulfillment transaction is included in the next block, the only way a malicious attacker can hijack the puzzle bounty is to create a new fork containing an alternative fulfillment transaction. Again, Bitcoin SV's double-spend prevention mechanism allows miners to detect such behavior and inform the network. Maximum Security -- 70 minutes: After this time, the transaction will be included in a block and an average of six subsequent blocks will be added to the blockchain after it. This security level ensures that any attempt to steal puzzle bounties will have a very high chance of failing.

[0271] These durations depend on the amount of hardware (in proofs of parallelizable computation) or the speed of the hardware (in proofs of sequential computation), and therefore their security level is relative to the adversary against which the puzzle bounty needs to be secured.

[0272] For schemes based on parallelizable proof-of-computation, it is difficult to define the parameters of the scheme corresponding to a specific security level, since the evaluation time of the scheme can always be reduced by increasing the amount of parallel hardware. In practice, it is assumed that the solver has access to a modern GPU unit. Most currently available GPU units have a hash rate of less than 1 GH / s. If an adversary has access to an application-specific integrated circuit (ASIC) machine capable of 10 TH / s of computation (corresponding to current state-of-the-art ASIC machines), the solver would have to spend at least 10,000 times longer than the time defined by the security level to compute the proof-of-computation.

[0273] For schemes based on proofs of sequential computation, there exists a theoretical lower bound on the computational gap between the solver and the adversary based on physical hardware limitations. Several studies have been conducted to design low-latency modular squaring of large integers. These can be used to estimate a realistic lower bound on the VDF evaluation time. ASIC implementations may achieve approximately a 200x latency reduction to evaluate a VDF for a 2048-bit input compared to modern CPU processors. This means that to achieve a certain security level, a solver must spend 200 times longer evaluating the VDF.

[0274] The challenger can also outsource the generation of the proof of computation to an external server that has access to more powerful hardware. Because the proof of computation input does not contain the plaintext puzzle solution (but only a hashed version of it), the server knows nothing about the solution and cannot reuse it to claim the puzzle bounty on behalf of the legitimate solver.

[0275] The following table summarizes the characteristics of each scheme described in this specification. If resistance to parallel computation is not required, PoW should be selected because it only incurs a small, constant overhead in the size of bounty transactions and fulfillment transactions. When resistance to parallel computation is required, CP-PoSW and P-VDF are preferred choices for a high level of security because the size of bounty transactions and fulfillment transactions grows logarithmically with evaluation time. However, when the overhead in the size of fulfillment transactions needs to be minimized, the Sloth scheme is a good choice.

[0276] [Table 1]

[0277] Each scheme based on sequential proof of computation was evaluated, generating bounty and fulfillment transactions. The evaluation was performed on a Linux machine with 32 GB of RAM and a CPU running at 1.7 GHz. The table below shows the resulting size overhead of the schemes for multiple evaluation times corresponding to different levels of security. Note that in practice, the schemes are run on more powerful machines, and therefore the scripts are larger. From this table, the Sloth scheme appears to be interesting only for low levels of security and when the size overhead of fulfillment transactions must be minimal. However, higher levels of security incur significant bounty transaction overhead. On the other hand, the size overhead of the CP-PoSW and P-VDF schemes increases slowly (in fact, logarithmically) with evaluation time. The difference between the two is that, compared to the CP-PoSW scheme, the P-VDF scheme incurs a smaller fulfillment transaction overhead but, conversely, a larger bounty transaction overhead. It is also worth noting that the size overhead of bounty transactions and fulfillment transactions is more balanced in the CP-PoSW scheme.

[0278] [Table 2]

[0279] 7. Further Special Notes Other variations or use cases of the disclosed technology will be apparent to those skilled 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.

[0280] 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 a blockchain 150, and the above description may apply broadly to any blockchain. That is, the present invention is not limited in any way 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.

[0281] 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 described 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, network entities may perform the function 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).

[0282] In other embodiments of the present 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 does not store and / or propagate those blocks 151 to other nodes.

[0283] Even more broadly, all 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 in connection with blockchain node 104.

[0284] Some embodiments have been described in terms of blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and in general, embodiments may use any type of suitable consensus mechanism, such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a specific example, proof-of-stake uses a randomized process to determine which blockchain nodes 104 will be given the opportunity to generate the next block 151. The selected nodes are often called validators. Blockchain nodes may lock up their tokens for a specific amount of time in order to have a chance to become validators. In general, the node that locks up the largest stake for the longest period of time has the greatest chance to become the next validator.

[0285] 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:

[0286] Statement 1. 1. A computer-implemented method for generating a challenge blockchain transaction, the challenge blockchain transaction being associated with a puzzle and a proof criterion, the puzzle being satisfied by a solution to the puzzle, and the proof criterion being satisfied by the proof, the method comprising: generating a first locking script of the challenge blockchain transaction, wherein when the first locking script is executed together with a first unlocking script of the solution blockchain transaction that includes the candidate puzzle solution, the public key, the candidate proof, and the generated signature for the solution blockchain transaction; Verifying that a candidate puzzle solution satisfies the puzzle; Verifying that the signature is valid for the public key; and Verifying that the candidate proof meets a proof criterion, the proof criterion requiring that the candidate proof be derived from the candidate puzzle solution and public key. and making the challenge blockchain transaction available to one or more nodes in the blockchain network; A method comprising:

[0287] Statement 2. The method of statement 1, in which the proof criterion defines a threshold, and the proof criterion is met if the candidate's target value is less than or equal to the threshold.

[0288] Statement 3. 3. The method of statement 2, wherein the first locking script, when executed with the first unlocking script, is further configured to calculate a candidate target value based on the public key, the candidate puzzle solution, and the candidate proof.

[0289] Statement 4. When the candidate proof includes a sequence of candidate proof values ​​and the first lock script is executed together with the first unlock script, calculating a first candidate target value based on the public key, the solution to the candidate puzzle, and a first candidate proof value in the sequence of candidate proof values; at least one subsequent candidate target value, each subsequent candidate target value being calculated based on a corresponding candidate proof value among the candidate proof values ​​and the target value of an immediately preceding candidate in the sequence of candidate target values; 3. The method of statement 2, further configured to calculate a corresponding sequence of candidate target values ​​by:

[0290] Statement 5. The method of statement 4, where the criterion of proof is met if each of the candidate target values ​​is less than or equal to a threshold.

[0291] Statement 6. 10. The method of statement 1, wherein the candidate proof is defined by an invertible function and calculated based on a series of square root calculations, and the first lock script is further configured to calculate a candidate target value, the candidate target value being an inverse function of the invertible function.

[0292] Statement 7. 10. The method of statement 6, wherein the candidate proof is calculated based on an intermediate variable, the intermediate variable being derivable from the public key and the solution to the candidate puzzle, the first locking script further configured to calculate the intermediate variable based on the public key of the first unlocking script and the solution to the candidate puzzle, and the proof criterion is satisfied if the candidate target value is equal to the calculated intermediate variable.

[0293] Statement 8. 10. The method of statement 1, wherein the proof criterion corresponds to a directed acyclic graph, the candidate proof includes an opening set and a commitment, and the first locking script is further configured to verify that the candidate proof of the first unlocking script is valid for the directed acyclic graph.

[0294] Statement 9. the candidate proof includes a sequence of proof values ​​and a result value, the result value being calculated based on a sequence of squaring operations, and the first lock script calculating a first series of exponents; and Calculating the second series of exponents further configured to: an initial first exponent in the series of first exponents is calculated based on the candidate puzzle solution and the public key; The first second exponent in the series of second exponents is equal to the result value, each subsequent exponent in the series of first exponents is calculated based on a corresponding previous proof value in the sequence of proof values, a corresponding previous first exponent in the series of first exponents, and a corresponding previous second exponent in the series of second exponents; 10. The method of statement 1, wherein each subsequent exponent in the second series of exponents is calculated based on a corresponding previous proof value in the sequence of proof values, a corresponding previous first exponent in the first series of exponents, and a corresponding previous second exponent in the second series of exponents.

[0295] Statement 10. The method of statement 9, wherein the criterion of proof is met if the last second exponent in the series of second exponents is equal to the square of the last first exponent in the series of first exponents.

[0296] Statement 11. 1. A computer-implemented method for generating a solution blockchain transaction, wherein a first unlock script of the solution blockchain transaction is configured to unlock a first transaction output of the challenge blockchain transaction, the challenge blockchain transaction being associated with a puzzle and a proof criterion, the puzzle being satisfied by a solution to the puzzle, and the proof criterion being satisfied by the proof, the method comprising: generating a first unlock script, the first unlock script comprising: candidate puzzle solutions for satisfying the puzzle, Solution Blockchain transaction signing, A public key for generating the signature, and A candidate proof derived from the candidate puzzle solution and public key and making the blockchain transaction available to one or more nodes in the blockchain network; A method comprising:

[0297] Statement 12. 12. The method of statement 11, wherein the criterion of proof defines a threshold, the criterion of proof being met if the candidate target value is less than or equal to the threshold, and further comprising determining a candidate proof that meets the criterion of proof when the method is used to derive the candidate target value.

[0298] Statement 13. The method of statement 12, in which the candidate's target value is derived based on the candidate's proof, the candidate's puzzle solution, and the public key.

[0299] Statement 14. The proof criterion defines a threshold, the candidate proof includes a sequence of candidate proof values, the proof criterion is satisfied if each of the candidate target value sequences is less than or equal to the threshold, and the candidate target value sequence is a first candidate target value calculated based on the public key, the solution to the candidate puzzle, and the first candidate proof value in the sequence of candidate proof values; and at least one subsequent candidate target value, each subsequent candidate target value being calculated based on a corresponding candidate proof value among the candidate proof values ​​and the target value of an immediately preceding candidate in the sequence of candidate target values; The method of statement 11, including:

[0300] Statement 15. The method of statement 11, wherein the candidate proof is derived based on the public key and an intermediate value calculated based on the solution to the puzzle.

[0301] Statement 16. The method of statement 15, wherein the candidate proof is defined by an invertible function of intermediate variables, and the candidate proof is generated by computing a series of square root calculations.

[0302] Statement 17. 16. The method of statement 15, wherein the proof basis corresponds to a directed acyclic graph, and the method further comprises generating a candidate directed acyclic graph based on the public key and intermediate values ​​derived from the puzzle solution, and wherein the candidate proof includes a set of commitments and openings corresponding to the candidate directed acyclic graph.

[0303] Statement 18. 16. The method of statement 15, wherein the candidate proof includes a sequence of proof values ​​and a result value, the result value is calculated based on an intermediate value by computing a sequence of squaring operations, and each proof value in the sequence of proof values ​​is calculated based on a hash of the intermediate value.

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

[0305] Statement 20. 19. A computer program embodied on computer-readable storage and configured to, when executed on one or more processors, perform the method of any of statements 1 to 18. [Explanation of symbols]

[0306] 100 systems 101 Packet Switched Network 102 Computer terminals and computer equipment 102a Computer equipment and devices 102b Computer equipment and devices 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, Blocks, Bitcoin Nodes, Transactions 105 Client Applications, Software 106 Peer-to-peer (P2P) network, blockchain network, blockchain node, Bitcoin network 107 Side Channel 150 Blockchain, Blockchain Nodes, Bitcoin Blockchain 151 Blocks of Data Blocks created 151n-1 years ago 151n New Block 152 transactions 152i Predecessor Transaction 152j Current Transaction, New Transaction, Onward Transaction 153 Genesis Block (Gb) 154 Ordered Sets, Ordered Pools, Transactions 155 Block Pointer 201 Header 202 Input 203 Output, UTXO 402 Challenger 404 Challenge 502 Challenge Transaction 504 Solution Transaction 602 Challenge Transaction 604 Solution Transaction 704 Solution Transactions 804 Solution Transaction 904 Solution Transaction< / t> < / n> < / pk> < / sol> < / pk> ​< / pk> < / w> < / pk> < / pk> < / target> < / nonce> < / pk> < / target> < / m>

Claims

1. 1. A computer-implemented method for generating a challenge blockchain transaction, the challenge blockchain transaction being associated with a puzzle and a proof criterion, the puzzle being satisfied by a puzzle solution, and the proof criterion being satisfied by a proof, the method comprising: generating a first locking script for the challenge blockchain transaction, wherein when the first locking script is executed together with a first unlocking script for the solution blockchain transaction that includes the candidate puzzle solution, the public key, the candidate proof, and a signature generated for the solution blockchain transaction; verifying that a solution of the candidate puzzle satisfies the puzzle; verifying that the signature is valid for the public key; and verifying that the candidate proof satisfies the proof criteria, the proof criteria requiring that the candidate proof be derived from the candidate puzzle solution and the public key. a generating step configured to: making the challenge blockchain transaction available to one or more nodes in a blockchain network; A method comprising:

2. The method of claim 1 , wherein the proof criteria defines a threshold, and the proof criteria is met if a candidate's target value is less than or equal to the threshold.

3. 3. The method of claim 2, wherein the first locking script, when executed with the first unlocking script, is further configured to calculate a target value for the candidate based on the public key, the solution to the candidate puzzle, and the candidate proof.

4. the candidate proof includes a sequence of candidate proof values, and when the first lock script is executed together with the first unlock script: calculating a first candidate target value based on the public key, the candidate puzzle solution, and a first candidate proof value in the sequence of candidate proof values; and at least one subsequent candidate target value, each subsequent candidate target value calculated based on a corresponding candidate proof value among the candidate proof values ​​and the target value of an immediately preceding candidate in the sequence of candidate target values; The method of claim 2 , further comprising: calculating a corresponding sequence of candidate target values ​​by:

5. The method of claim 4 , wherein the certification criterion is met if each of the candidate target values ​​is less than or equal to the threshold.

6. 2. The method of claim 1, wherein the candidate proof is defined by an invertible function and calculated based on a series of square root calculations, and the first lock script is further configured to calculate a candidate target value, the candidate target value being an inverse function of the invertible function.

7. 7. The method of claim 6, wherein the candidate proof is computed based on an intermediate variable, the intermediate variable being derivable from the public key and a solution to the candidate puzzle, the first locking script is further configured to compute the intermediate variable based on the public key of the first unlocking script and a solution to the candidate puzzle, and the proof criterion is satisfied if the candidate target value is equal to the computed intermediate variable.

8. 2. The method of claim 1, wherein the proof criteria corresponds to a directed acyclic graph, the candidate proof includes an opening set and a commitment, and the first locking script is further configured to verify that the candidate proof of the first unlocking script is valid for the directed acyclic graph.

9. the candidate proof includes a sequence of proof values ​​and a result value, the result value being calculated based on a sequence of squaring operations, and the first lock script: calculating a first series of exponents; and Calculating the second series of exponents further configured to: an initial first exponent in the series of first exponents is calculated based on the candidate puzzle solution and the public key; a first second index in said series of second indexes is equal to said result value; each subsequent index in the series of first indexes is calculated based on a corresponding previous attestation value in the sequence of attestation values, a corresponding previous first index in the series of first indexes, and a corresponding previous second index in the series of second indexes; 2. The method of claim 1, wherein each subsequent exponent in the series of second exponents is calculated based on a corresponding previous proof value in the sequence of proof values, a corresponding previous first exponent in the series of first exponents, and a corresponding previous second exponent in the series of second exponents.

10. 10. The method of claim 9, wherein the proof criterion is met if a last second exponent in the series of second exponents is equal to the square of a last first exponent in the series of first exponents.

11. 1. A computer-implemented method for generating a solution blockchain transaction, wherein a first unlock script of the solution blockchain transaction is configured to unlock a first transaction output of a challenge blockchain transaction, the challenge blockchain transaction being associated with a puzzle and a proof criterion, the puzzle being satisfied by a puzzle solution and the proof criterion being satisfied by a proof, the method comprising: generating the first unlock script, the first unlock script comprising: candidate puzzle solutions for satisfying said puzzle; a signature of the solution blockchain transaction; a public key for generating said signature; and a candidate proof derived from the candidate puzzle solution and the public key; generating a making the solution blockchain transaction available to one or more nodes in a blockchain network; A method comprising:

12. 12. The method of claim 11, further comprising determining a proof of the candidate that meets the proof criterion when the method is used to derive the candidate target value, wherein the proof criterion defines a threshold, the proof criterion being met if the candidate target value is less than or equal to the threshold.

13. The method of claim 12 , wherein the candidate target value is derived based on the candidate's proof, the candidate's puzzle solution, and the public key.

14. The proof criterion defines a threshold, the candidate proof includes a sequence of candidate proof values, the proof criterion is satisfied if each of the sequence of candidate target values ​​is less than or equal to the threshold, and the sequence of candidate target values ​​includes: a first candidate target value calculated based on the public key, the candidate puzzle solution, and a first candidate proof value in the sequence of candidate proof values; and at least one subsequent candidate target value, each subsequent candidate target value calculated based on a corresponding candidate proof value among the candidate proof values ​​and the target value of an immediately preceding candidate in the sequence of candidate target values; 12. The method of claim 11, comprising:

15. The method of claim 11 , wherein the candidate proof is derived based on the public key and an intermediate value calculated based on the solution to the puzzle.

16. 16. The method of claim 15, wherein the candidate proofs are defined by invertible functions of intermediate variables, and the candidate proofs are generated by computing a series of square root calculations.

17. 16. The method of claim 15, wherein the proof basis corresponds to a directed acyclic graph, the method further comprising generating a candidate directed acyclic graph based on the public key and the intermediate values ​​derived from the puzzle solution, the candidate proof including a set of commitments and openings corresponding to the candidate directed acyclic graph.

18. 16. The method of claim 15, wherein the candidate proof comprises a sequence of proof values ​​and a result value, the result value being calculated based on the intermediate values ​​by computing a sequence of squaring operations, and each proof value in the sequence of proof values ​​being calculated based on a hash of the intermediate value.

19. a memory including one or more memory units; a processing device including one or more processing units; 19. A computing device comprising: a processor; a memory for storing code arranged to be executed on the processor; and a processor configured to execute the method of any one of claims 1 to 18.

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

Images