Blockchain transactions

Abstract

A computer-implemented method of generating a challenge blockchain transaction, where the challenge blockchain transaction is associated with a puzzle and an attestation criterion, where the puzzle is satisfied by a puzzle solution, and where the attestation criterion is satisfied by an attestation, the method comprising: generating a first locking script of the challenge blockchain transaction, when executed together with a first unlocking script of a deblockchain transaction comprising a candidate puzzle solution, a public key, a candidate attestation, and a signature generated for the deblockchain transaction, the first locking script is configured to: verify whether the candidate puzzle solution satisfies the puzzle; verifying whether the signature is valid for the public key; and verifying whether the candidate proof meets the proof criteria, where the proof criteria require that the candidate proof is derived from the candidate puzzle solution and the public key; and providing the challenge block chain transaction to one or more nodes of a block chain network.

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 the UTXO of the challenge transaction. Background Art

[0002] A blockchain refers to a distributed data structure in which a copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network"), and the copy is widely disclosed. The blockchain includes a series of data blocks, where each block includes one or more transactions. Except for the so-called "coinbase transaction", each transaction points to a previous transaction in the sequence, which can span one or more blocks and return to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in new blocks. The process of creating a new block is generally referred to as "mining", which involves each of the plurality of nodes competing to perform a "proof of work", that is, solving a cryptographic puzzle based on a representation of a set of defined, ordered, and verified valid pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain can be pruned at some nodes, and the release of blocks can be achieved by only releasing block headers.

[0003] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtual ledger or registry; receiving and processing timestamp entries; and / or sorting index pointers by time. Hierarchical additional functions on the blockchain can also be realized using the blockchain. For example, the blockchain protocol can allow additional user data or data indexes to be stored in a transaction. There is no pre-specified limit on the maximum data capacity that can be stored in a single transaction, so increasingly complex data can be incorporated. For example, this can be used to store electronic documents, audio, or video data in the blockchain.

[0004] Nodes of a blockchain network (commonly referred to as "miners") perform a distributed transaction registration and verification process, which will be described in more detail later. In summary, in this process, nodes verify transactions and insert these transactions into a block template, and these transactions attempt to identify a valid proof-of-work solution for the block template. Once a valid solution is found, the new block is propagated to other nodes in the network, enabling each node to record the new block on the blockchain. To record a transaction on the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network for propagation. The node that receives the transaction can compete to find a proof-of-work solution that will incorporate the verified valid transaction into a new block. Each node is configured to execute the same node protocol, which will include one or more conditions for confirming that a transaction is valid. Invalid transactions will not be propagated or incorporated into a block. Assuming that a transaction has been verified as valid and thus accepted on the blockchain, the transaction (including any user data) will then be registered and indexed as an immutable public record on each node in the blockchain network.

[0005] Nodes that successfully solve the proof-of-work puzzle to create the latest block are typically rewarded with a new transaction called a "coinbase transaction", which distributes an amount of digital assets, i.e., the number of tokens. Detection and rejection of invalid transactions are performed through the actions of competing nodes, which act as agents of the network and incentivize reporting and prevention of improper behavior. The wide dissemination of information enables users to continuously audit the performance of nodes. Publishing only the block headers enables participants to ensure the continuous integrity of the blockchain.

[0006] In the "output-based" model (sometimes called the UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element specifying an amount of digital assets, which can be derived from the ongoing sequence of transactions. Spendable outputs are sometimes called UTXOs ("unspent transaction outputs"). An output can also include a locking script, which specifies the future redemption conditions of the output. The locking script is a predicate that defines the conditions necessary to verify 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 in a previous transaction, and can also include an unlocking script for unlocking the locking script that points to the output. Thus, consider a pair of transactions, referred to as the first transaction and the second transaction (or the "target" transaction). The first transaction includes at least one output specifying an amount of digital assets and includes a locking script defining one or more conditions for unlocking the output. The second (target) transaction includes at least one input and an unlocking script, and the at least one input includes a pointer to the output of the first transaction; the unlocking script is used to unlock the output of the first transaction.

[0007] In such models, when a second (target) transaction is sent to the blockchain network for propagation and recording in the blockchain, one of the validity conditions applied at each node will be that the unlocking script satisfies all of one or more conditions defined in the locking script of the first transaction. Another condition will be that the output of the first transaction has not been redeemed by another earlier 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 may register the invalid transaction) nor include the transaction in the new block to be recorded in the blockchain.

[0008] Another transaction model is the account - based model. In this case, each transaction is defined not by referring to the UTXOs of previous transactions in the past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is stored separately by the nodes into the blockchain and is continuously updated. Summary of the Invention

[0009] In a UTXO - based blockchain, the solution to the cryptographic puzzle can be set as the spending condition of a transaction, which can be called a bounty transaction. The puzzle bounty locked in the bounty transaction can be claimed by broadcasting a redemption transaction that references the bounty transaction and contains the solution to the puzzle. As part of transaction verification, the verification of the solution is performed by blockchain nodes (e.g., miners).

[0010] A common problem with puzzle bounties is that a malicious interceptor can steal the bounty by extracting the solution to the puzzle from the redemption transaction and broadcasting a new redemption transaction with a modified output. To solve this problem, the creator of the bounty transaction (referred to as the challenger) may require the redemption transaction to 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 solution to the puzzle.

[0011] According to one aspect disclosed herein, there is provided a computer-implemented method for generating a challenge blockchain transaction, wherein the challenge blockchain transaction is associated with a puzzle and a proof standard, wherein the puzzle is satisfied by a puzzle solution, and wherein the proof standard is satisfied by a proof. The method includes: generating a first locking script for the challenge blockchain transaction, which is configured to, when executed together with a first unlocking script of a solution blockchain transaction (including a candidate puzzle solution, a public key, a candidate proof, and a signature generated for unlocking the 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 standard, wherein the proof standard requires that the candidate proof is derived from the candidate puzzle solution and the public key; and providing the challenge blockchain transaction 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 the first unlocking script of the solution blockchain transaction is configured to unlock a first transaction output of a challenge blockchain transaction, wherein the challenge blockchain transaction is associated with a puzzle and a proof standard, wherein the puzzle is satisfied by a puzzle solution, and wherein the proof standard is satisfied by a proof. The method includes: generating the first unlocking script, wherein the first unlocking script includes: a candidate puzzle solution for satisfying the puzzle, a signature of the solution blockchain transaction, a public key for generating the signature, and a candidate proof, wherein the candidate proof is derived from the candidate puzzle solution and the public key; and providing the solution blockchain transaction to one or more nodes of a blockchain network.

[0013] The methods provided herein prevent a malicious interceptor from hijacking the puzzle solution provided in the redemption (or solution) transaction by requiring the candidate proof to be derived from the public key used to sign the redemption (or solution) transaction and the puzzle solution, thereby ensuring the security of the puzzle reward.

[0014] In some embodiments provided herein, the candidate proof is generated by a method that takes a long time to compute. The time taken to compute the candidate proof is more than the average time taken to record a transaction in a block of the blockchain. In this way, a malicious interceptor of the solution blockchain transaction cannot generate its own candidate proof before the solution blockchain transaction is recorded in the blockchain, thereby preventing the malicious interceptor from maliciously obtaining the reward (i.e., digital assets) locked by the output of the challenge transaction.

[0015] One advantage of the method provided herein is that when generating the challenge blockchain transaction, the challenger does not need to know the puzzle solution. This reduces the computational and time requirements of the challenger when generating the challenge solution. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] To assist in understanding the embodiments of the present disclosure and to show how such embodiments may be implemented, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0017] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

[0018] Figure 2 schematically shows some examples of transactions that can be recorded in a blockchain;

[0019] Figure 3 provides an example of a directed acyclic graph with labeled nodes;

[0020] Figure 4 provides an exemplary method for generating a challenge blockchain transaction and a solution blockchain transaction;

[0021] Figure 5 schematically shows the use of a proof-of-work scheme to verify an unlocking script;

[0022] Figure 6 schematically shows the use of a chained proof-of-work scheme to verify an unlocking script;

[0023] Figure 7 schematically shows the use of a Sloth scheme to verify an unlocking script;

[0024] Figure 8 schematically shows the use of a sequential proof-of-work scheme to verify an unlocking script; and

[0025] Figure 9 schematically shows the use of a verifiable delay function scheme to verify an unlocking script. DETAILED DESCRIPTION

[0026] 1. Exemplary System Overview

[0027] Figure 1 An exemplary system 100 for implementing a blockchain 150 is shown. The system 100 may include a packet switching network 101, typically a wide area network such as the Internet. The packet switching network 101 includes a plurality of blockchain nodes 104, which may be arranged to form a peer-to-peer (P2P) network 106 within the packet switching network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0028] Each blockchain node 104 includes a computer device of a peer, and different nodes 104 belong to different peers. Each blockchain node 104 includes a processing device, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, dedicated processors, and / or field-programmable gate arrays (FPGAs), as well as other devices, such as application-specific integrated circuits (ASICs). Each node also includes a memory, namely a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which employ one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memories, or electrically erasable programmable read-only memories (EEPROMs), and / or optical media such as optical disk drives.

[0029] The blockchain 150 includes a series of data blocks 151, where a corresponding copy of the blockchain 150 is maintained at each of the multiple blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, as long as each blockchain node 150 stores the block header of each block 151 (discussed below), the blockchain 150 can perform data pruning. Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A specific transaction protocol is used throughout a given blockchain. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies the amount of a digital asset represented as a property, and an example is the user 103 to whom the output is cryptographically locked (requiring the signature or other unlocking of the user to redeem or spend). Each input points to the output of a previous transaction 152, thus linking these transactions.

[0030] Each block 151 also includes a block pointer 155 that points to a previously created block 151 in the blockchain to define the order of the blocks 151. Each transaction 152 (except for coinbase transactions) includes a pointer to a previous transaction to define the order of the transaction sequence (note: the sequence of transactions 152 can branch). The blockchain of blocks 151 traces back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more early original transactions 152 in the blockchain 150 point to the genesis block 153, rather than a previous transaction.

[0031] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, such that transaction 152 propagates throughout network 106. Each blockchain node 104 is configured to create block 151 and store a corresponding copy of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is commonly referred to as a "mempool". In this document, the term is not intended to be restricted to any particular blockchain, protocol, or model. The term refers to an ordered set of transactions 152 that the node 104 has accepted as valid, and for which the node 104 is forced not to accept any other transaction that attempts to spend the same output.

[0032] In a given current transaction 152j, the input (or each input) includes a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily mean transferring financial assets, although this is certainly a common application. More generally, spending can be described as consuming the output, or allocating it to one or more outputs in another subsequent transaction. Typically, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although a previous transaction 152i will need to exist and be verified as valid in order to ensure the validity of the current transaction, the previous transaction 152i does not have to exist at the time the current transaction 152j is created or even sent to network 106. Thus, in this document, "previous" refers to the predecessor in a logical sequence linked by a pointer, and not necessarily the creation time or send time in a time sequence, and thus does not necessarily exclude the case of unordered creation or sending of transactions 152i, 152j (see the discussion of orphan transactions below). The previous transaction 152i can equally be referred to as a preceding transaction or a predecessor transaction.

[0033] The input of the current transaction 152j also includes input authorization, such as the signature of user 103a to which the output of the previous transaction 152i is locked. In turn, the output of the current transaction 152j can be cryptographically locked to a 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 defined in the output of the current transaction 152j. In some cases, a transaction 152 can have multiple outputs to split the input amount among multiple users or entities (one of which can be the original user or entity 103a for change). In some cases, a transaction can also have multiple inputs, aggregating the amounts in the outputs of one or more previous transactions and reallocating them to one or more outputs of the current transaction.

[0034] According to an output-based transaction protocol, such as Bitcoin, when a party 103, such as an individual user or organization, wishes to issue a new transaction 152j (either by an automated program or manually employed by that party), the issuing party sends the new transaction from its computer terminal 102 to the recipient. The issuing party or the recipient will ultimately send the transaction to one or more blockchain nodes 104 of the network 106 (which are now typically servers or data centers, but in principle could also be other user terminals). Additionally, it is not excluded that the party 103 issuing the new transaction 152j can send the transaction directly to one or more blockchain nodes 104, and in some examples, the transaction may not be sent to the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applied at each blockchain node 104. The blockchain node protocol typically requires the blockchain node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this can include checking whether the cryptographic signature or other authorization of the party 103 included in the input of the new transaction 152j matches the conditions defined in the output of the previous transaction 152i that the new transaction spends (or "allocates"), where the conditions typically include at least checking whether the cryptographic signature or other authorization in 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 conditions can be at least partially defined by a script included in the output of the previous transaction 152i. Alternatively, this can be determined solely by the blockchain node protocol or by a combination thereof. Whichever way is adopted, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol and thus forward the new transaction 152j to one or more other nodes 104 and so on. In this way, the new transaction spreads throughout the network of blockchain nodes 104.

[0035] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is that, according to the blockchain node protocol, it is validly redeemed by the input of another subsequent transaction 152j. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it attempts to redeem has not been redeemed by another transaction. Similarly, if invalid, the transaction 152j will not spread (unless marked as invalid and spread for reminder) or be recorded in the blockchain 150. This prevents double spending, i.e., a transaction processor allocating the output of the same transaction more than once. On the other hand, an account-based model prevents double spending by maintaining account balances. Since there is also a defined order of transactions, the account balance has a single defined state at any given time.

[0036] In addition to verifying the validity of transactions, blockchain node 104 also competes to be the first node to create a transaction block in a process commonly referred to as mining, which is supported by "proof of work". At blockchain node 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in block 151 recorded on blockchain 150. Then, blockchain nodes compete to assemble a new valid transaction block 151 for the transactions 152 in the ordered transaction set 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is juxtaposed with the representation of the pending transaction ordered pool 154 and hashed, the output of the hash value meets a predetermined condition. For example, the predetermined condition could be that the output of the hash value has a certain predefined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle and does not exclude other types. The characteristic of a hash function is that its output is unpredictable relative to its input. Therefore, this search can only be carried out by brute force, consuming a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0037] The first blockchain node 104 that solves the puzzle announces the solution on network 106, providing the solution as proof, and then other blockchain nodes 104 in the network can easily check the solution (once the solution for the hash value is given, it can be directly checked whether the solution makes the output of the hash value meet the condition). The first blockchain node 104 propagates a block to other nodes that accept the block to reach a threshold consensus, thereby enforcing the protocol rules. Then, the ordered transaction set 154 is recorded as a new block 151 in blockchain 150 by each blockchain node 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the blockchain. The large amount of work required to create a proof-of-work solution (e.g., in the form of a hash) signals the intention of the first node 104 to follow the blockchain protocol. These rules include not accepting a transaction as valid if it spends or allocates the same output as a previously verified valid transaction, otherwise it is called double spending. Once created, block 151 cannot be modified because it is identified and maintained at each blockchain node 104 in the blockchain network 106. The block pointer 155 also imposes an order on block 151. Since transactions 152 are recorded in ordered blocks at each blockchain node 104 in network 106, an immutable public ledger of transactions is provided.

[0038] It should be noted that different blockchain nodes 104 competing to solve the puzzle at any given time can do so based on different snapshots of the pool 154 of transactions not yet released at any given time, depending on the order in which they start searching for solutions or receive transactions. The person solving the corresponding puzzle first defines the transactions 152 included in the new block 151n and their order, and updates the current pool 154 of unreleased transactions. Then, the blockchain nodes 104 continue to compete to create a block from the newly defined ordered pool 154 of unreleased transactions, and so on. In addition, there are protocols for resolving any "forks" that may occur, where two blockchain nodes 104 solve the puzzle within a short time of each other, thus spreading conflicting views of the blockchain between the nodes 104. Briefly, the fork with the longest direction becomes the final blockchain 150. It should be noted that this does not affect the users or agents of the network, as the same transaction will appear in both forks.

[0039] According to the Bitcoin blockchain (and most other blockchains), the node that successfully constructs a new block 104 is granted the ability to newly allocate an additional, accepted amount of digital assets in a new special type of transaction that allocates an additional limited quantity of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers a certain quantity of digital assets from one agent or user to another). This special type of transaction is commonly referred to as a "coinbase transaction", but it can also be called a "bootstrap transaction" or a "generation transaction". It typically forms the first transaction of the new block 151n. The proof-of-work signals the intention of the node constructing the new block to follow the protocol rules, thus allowing the specific transaction to be redeemed later. Before the special transaction can be redeemed, the blockchain protocol rules may require a maturation period, such as 100 blocks. Typically, a regular (non-generative) transaction 152 will also specify an additional transaction fee in one of its outputs to further reward the blockchain node 104 that creates the block 151n in which the transaction is published. This fee is commonly referred to as the "transaction fee" and is discussed below.

[0040] Due to the resources involved in transaction verification and publication, typically at least each blockchain node 104 takes the form of a server that includes one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal or a group of user terminals networked together.

[0041] The memory of each blockchain node 104 stores software configured to run on the processing device of the blockchain node 104 to perform its respective role and process transactions 152 according to the blockchain node protocol. It should be understood that any action attributed to the blockchain node 104 herein can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in an application layer or in one or more applications at a lower layer such as an operating system layer or a protocol layer, or any combination of these layers.

[0042] The computer devices 102 of each party 103 that play the role of consumer users are also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in a transaction. Other users can interact with the blockchain 150 without having to act as senders or receivers. For example, some parties can 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).

[0043] Some or all of the parties 103 can be connected as part of different networks, such as a network overlaying the blockchain network 106. Users of the blockchain network (often referred to as "clients") can be said to be part of the system that includes the blockchain network 106; however, these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 can interact with the blockchain network 106 so as to utilize the blockchain 150 by connecting to a blockchain node 106 (i.e., communicating with a blockchain node 106). For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system 100, but are not shown for convenience. Each party 103 can be an individual or an organization. For illustrative purposes only, in this document, the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob herein can be replaced by "first party" and "second party" respectively.

[0044] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. The computer device 102 of each party 103 also includes a memory, namely a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which employ one or more memory media, such as magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computer device 102 of each party 103 stores software, which includes a corresponding instance of at least one client application 105 configured to run on the processing device. It should be understood that any action attributed to a given party 103 herein can be performed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smartphone, or a wearable device such as a smartwatch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through the user terminal.

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

[0046] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the corresponding party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104, which are then propagated in the network of blockchain nodes 104 and thus included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets it currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 belonging to the relevant party scattered in the blockchain 150.

[0047] Note: Although various client functions may be described as integrated into a given client application 105, this is not necessarily restrictive. Instead, any client function described herein may be implemented in a suite consisting of two or more different applications, such as through API connectivity or one application being a plugin of another application. More generally, client functions may be implemented at the application layer or a lower layer such as an operating system or any combination of these layers. The following will be described in terms of the client application 105, but it should be understood that this is not restrictive.

[0048] An instance of the client application or software 105 on each computer device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of the client 105 to send a transaction 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions where a corresponding party 103 is the recipient (or indeed to check the transactions of other parties in the blockchain 150, as in an embodiment, the blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet function on each computer device 102 is configured to formulate and send a transaction 152 according to a transaction protocol. As described above, each blockchain node 104 runs software that is configured to verify a transaction 152 according to a blockchain node protocol and forward the transaction 152 for propagation in the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. All nodes 104 in the network 106 use the same node protocol.

[0049] When a given party 103 (say Alice) wishes to send a new transaction 152j to be included in the blockchain 150, she formulates the new transaction according to the relevant transaction protocol (using the wallet function in her client application 105). She then sends the transaction 152 from the client application 105 to one or more of the blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j meets certain conditions to become "valid", specific examples of which will be discussed in detail later. In some transaction protocols, the validity conditions can be configured on a per-transaction basis through a script included in the transaction 152. Alternatively, the conditions can be merely a built-in function of the node protocol or defined by a combination of the script and the node protocol.

[0050] If the newly received transaction 152j passes the validity test (i.e., under the condition of "valid"), any blockchain node 104 that receives the transaction 152j will add the newly verified valid transaction 152 to the ordered transaction set 154 maintained at the blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j will then propagate the verified valid transaction 152 to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, assuming the transaction 152j is valid, this means the transaction will soon spread throughout the network 106.

[0051] Once in the pending transaction ordered pool 154 maintained at a given blockchain node 104, that blockchain node 104 will start competing to solve the proof - of - work puzzle on the latest version of its respective pool 154 that contains the new transaction 152 (remember, other blockchain nodes 104 may attempt to solve the puzzle based on different transaction pools 154. However, the one who solves the puzzle first will define the set of transactions included in the latest block 151. Eventually, blockchain node 104 will solve the puzzle for a part of the ordered pool 154 that includes Alice's transaction 152j). Once the pool 154 that includes the new transaction 152j completes the proof of work, it will irrevocably become part of a block in block 151 of the blockchain 150. Each transaction 152 includes a pointer to an earlier transaction, so the order of the transactions is also irrevocably recorded.

[0052] Different blockchain nodes 104 may first receive different instances of a given transaction and thus have conflicting views on which instance is "valid" before one instance is published into the 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 an instance as a valid instance and then discovers that a second instance has been recorded in the blockchain 150, the blockchain node 104 must accept this and will discard (i.e., consider invalid) the instance it initially accepted (i.e., the instance that has not yet been published in block 151).

[0053] As part of an account-based transaction model, another type of transaction protocol operated by some blockchain networks can be referred to as an "account-based" protocol. In the account-based case, each transaction does not define the amount of transfer by referring to the UTXO of a previous transaction in the past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is separately stored in the blockchain by the nodes of the network and is continuously updated. In such a system, transactions are sorted using the running transaction record (also known as "position") of the account. This value is signed by the sender as part of its cryptographic signature and is hashed as part of the transaction reference calculation. Additionally, optional data fields can also be signed in the transaction. For example, if the data field contains the ID of a previous transaction, the data field can point to the previous transaction.

[0054] 2. UTXO - based Model

[0055] Figure 2 An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. Transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). It will be described below by referring to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that although an exemplary UTXO-based protocol is described with reference to Bitcoin, it can equally be implemented on other example blockchain networks.

[0056] In the 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 can include an unspent transaction output (UTXO), which can be used as the source of an input 202 for another new transaction (if the UTXO has not been redeemed). The UTXO includes a value specifying the amount of digital assets. This represents a set of tokens on the distributed ledger. The UTXO can also contain the transaction ID of its source transaction and other information. The transaction data structure can also include a header 201, which can include size indicators for the input field 202 and the output field 203. The header 201 can also include the ID of the transaction. In an embodiment, the transaction ID is the hash value of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to the node 104.

[0057] For example, let's say Alice 103a wishes to create a transaction 152j transferring a relevant amount of digital assets to Bob 103b. In Figure 2 this, Alice's new transaction 152j is labeled "Tx1". This new transaction obtains the amount of digital assets locked to Alice in the output 203 of a previous transaction 152i in the sequence and transfers at least a portion of such amount to Bob. In Figure 2In this case, the previous transaction 152i is labeled "Tx0". Tx0 and Tx1 are just arbitrary labels and do not necessarily mean that Tx0 refers to the first transaction in the blockchain 151 and Tx1 refers to a subsequent transaction in the pool 154. Tx1 can point to any previous (i.e., antecedent) transaction that still has an unspent output 203 locked to Alice.

[0058] When Alice creates her new transaction Tx1, or at least when she sends the new transaction to the network 106, the previous transaction Tx0 may already be valid and included in the block 151 of the blockchain 150. This transaction may already be included in a block in block 151 at this time, or may still be waiting in the ordered set 154, in which case the transaction will soon be included in a new block 151. Alternatively, Tx0 and Tx1 can be created and sent to the network 106 together; or, if the node protocol allows buffering of "orphan" transactions, Tx0 can even be sent after Tx1. The terms "previous" and "subsequent" used in the context of the transaction sequence in this article refer to the order of transactions in the sequence defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They can equally be replaced by "predecessor" and "successor", "ancestor" and "descendant", or "parent" and "child", etc. This does not necessarily refer to the order in which they are created, sent to the network 106, or reach any given blockchain node 104. However, a subsequent transaction (descendant transaction or "child") that points to a previous transaction (ancestor transaction or "parent") will not be valid unless the parent transaction is valid. A child that reaches the blockchain node 104 before the parent is considered an orphan. Depending on the node protocol and / or node behavior, it can be discarded or buffered for some time to wait for the parent.

[0059] One of the outputs 203 of the previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that the unlocking script in the input 202 of a subsequent transaction must satisfy in order for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking conditions, which generally include the condition that the unlocking script in the input of the subsequent transaction includes the cryptographic signature of the party to which the previous transaction was locked.

[0060] The locking script (also known as 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" (with S capitalized), which can be used by the blockchain network. The locking script specifies the information required to spend the transaction output 203, such as the requirement for Alice's signature. The unlocking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is a piece of code written in a domain - specific language that provides the information required to meet the criteria of the locking script. For example, it can contain Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0061] So in the example shown, the UTXO0 in the output 203 of Tx0 includes the locking script [Checksig P A , which requires Alice's signature Sig P A to redeem UTXO0 (strictly speaking, to make a subsequent transaction attempting to redeem UTXO0 valid). [Checksig P A contains the representation (i.e., hash) of the public key P A in Alice's public - private key pair. The input 202 of Tx1 includes a pointer to Tx1 (e.g., via its transaction ID (TxID0), which in the embodiment is the hash value of the entire transaction Tx0). The input 202 of Tx1 includes the index that identifies UTXO0 in Tx0 to identify it among any other possible outputs of Tx0. The input 202 of Tx1 further includes the unlocking script <Sig P A >, which includes Alice's cryptographic signature created by Alice by applying the private key in her key pair to a predetermined portion of data (sometimes called the "message" in cryptography). The data (or "message") for which Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0062] When the new transaction Tx1 arrives at the blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check if the unlocking script meets the conditions defined in the locking script (where the conditions can include one or more criteria). In an embodiment, this involves juxtaposing the two scripts:

[0063] <Sig PA> <pa>||[Checksig PA]

[0064] Where "||" represents juxtaposition, "<...>" represents pushing data onto the stack, and "[...]" represents a function composed of a locking script (in this example, a stack-based language). Similarly, scripts can run one after another using a common stack instead of juxtaposing scripts. Either way, when run together, the scripts use Alice's public key P A (including in the locking script of the output of Tx0) to authenticate the signature when the unlocking script in the input of Tx1 contains the data of the expected part of Alice's signature. The expected part of the data itself ("message") also needs to be included in order to perform this authentication. In an embodiment, the data signed includes the entire Tx1 (so there is no need to include a separate element to specify the part of the data being signed in plain text as it already exists).

[0065] Those skilled in the art will be familiar with the details of authentication through public-private cryptography. Basically, if Alice has encrypted and signed a message using her private key, given Alice's public key and the message in plain text, other entities such as node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash value, and tagging this to the message as the signature, so that any holder of the public key can authenticate the signature. Therefore, it should be noted that in an embodiment, any reference herein to signing a specific data fragment or part of a transaction, etc., can mean signing the hash value of that data fragment or part of the transaction.

[0066] If the unlocking script in Tx1 meets one or more conditions specified in the locking script of Tx0 (thus, in the example shown, if Alice's signature is provided and authenticated in Tx1), then blockchain node 104 considers Tx1 valid. This means that blockchain node 104 will add Tx1 to the pending transactions ordered pool 154. Blockchain node 104 will also forward transaction Tx1 to one or more other blockchain nodes 104 in network 106 so that it will be propagated throughout network 106. Once Tx1 is valid and included in blockchain 150, this will define UTXO0 from Tx0 as spent. It should be noted that Tx1 is only valid when spending an unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, then Tx1 will be invalid even if all other conditions are met. Thus, blockchain node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has already been spent (i.e., whether it has formed a valid input for another valid transaction). This is one of the reasons 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 marking the UTXO 203 of spent transactions 152, but ultimately defining whether a UTXO has been spent depends on whether a valid input for another valid transaction has been formed in blockchain 150.

[0067] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, then this is another basis for invalidation in most transaction models. Thus, such transactions will not be propagated or included in block 151.

[0068] Note that in a UTXO-based transaction model, a given UTXO needs to be used as a whole. One cannot "leave" a portion of the amount defined as spent in a UTXO while spending another portion. However, the amount of a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob all of the amount defined in UTXO0, she can use the remainder to give herself change in the second output of Tx1, or pay it to another party.

[0069] In practice, Alice typically also needs to include a fee for Bitcoin node 104 that successfully includes Alice's transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain node 104 and thus may not propagate and be included in blockchain 150 despite being technically valid (if blockchain node 104 does not wish to accept transaction 152, the node protocol does not force blockchain node 104 to accept). In some protocols, the transaction fee does not require its own separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount pointed to by input 202 and the total amount specified by output 203 of a given transaction 152 will automatically be provided to the blockchain node 104 that publishes the transaction. For example, assume that the 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 can be allocated (or spent) by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. Alternatively or additionally, this does not necessarily preclude the transaction fee from being explicitly specified in one of the UTXOs 203 of its own transaction 152.

[0070] Alice and Bob's digital assets consist of UTXOs locked to them in any transaction 152 anywhere in blockchain 150. Thus, typically, a given party 103's assets are spread across the UTXOs of various transactions 152 throughout blockchain 150. No single number defining the total balance of a given party 103 is stored anywhere in blockchain 150. The role of the wallet function of client application 105 is to collate the various UTXO values locked to the corresponding party and not yet spent in other subsequent transactions. To achieve this, it can query a copy of blockchain 150 stored at any one of the Bitcoin nodes 104.

[0071] It should be noted that script code is typically represented schematically (i.e., using non-precise language). For example, opcodes can be used to represent specific functions. "OP_..." refers to specific opcodes of the script language. For example, OP_RETURN is a script language opcode that, when prefixed with OP_FALSE at the start of the locking script, creates an unspendable output of the transaction that can store data within the transaction, thereby immutably recording the data in blockchain 150. For example, the data can include a file to be stored in the blockchain.

[0072] Typically, the input of a transaction contains a digital signature corresponding to the public key PA. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific data segment. In an embodiment, for a given transaction, the signature will sign part of the transaction input as well as part or all of the transaction output. Signing a specific part of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that is used to select the output to be signed (and thus fixed at the time of signing).

[0073] The locking script, sometimes called "scriptPubKey", means that it typically includes the public key of the party to which the corresponding transaction is locked. The unlocking script, sometimes called "scriptSig", means that it typically provides the corresponding signature. But more generally, in all applications of the blockchain 150, the conditions for UTXO redemption do not necessarily include verifying the signature. More generally, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" can be preferably used.

[0074] 3. Side Channel

[0075] As Figure 1 shown, the client applications on each of the computer devices 102a, 120b of Alice and Bob can include additional communication functions. This additional function enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 enables data to be exchanged outside the blockchain network. Such communication is sometimes called "off-chain" communication. For example, this can be used to exchange a transaction 152 between Alice and Bob without registering the transaction (yet) on the blockchain network 106 or publishing it on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing a transaction in this way is sometimes called sharing a "transaction template". The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 can be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0076] A side channel 107 can be established through the same packet-switching network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 can be established via a different network such as a mobile cellular network or a local area network such as a wireless local area network, or even via a direct wired or wireless link between the devices 102a, 102b of Alice and Bob. Generally, the side channel 107 referred to anywhere in this document can include any one or more links via one or more networking technologies or communication media, which are used for "off-chain" data exchange, that is, data exchange outside the blockchain network 106. In the case of using multiple links, the off-chain link bundle or set as a whole can be referred to as the side channel 107. Therefore, it should be noted that if it is said that Alice and Bob exchange certain information or data, etc. through the side channel 107, this does not necessarily mean that all of this data must be sent through exactly the same link or even the same type of network.

[0077] 4. Hash Puzzle

[0078] Cryptographic hash functions provide a way to deterministically hide the input, where a small change in the input results in a significant change in the output. Cryptographic hash functions have the following properties:

[0079] ● Preimage resistance: Given a hash value H(m), it is computationally difficult to find the preimage m.

[0080] ● Second preimage resistance: Given a hash value H(m) and its preimage m, it is computationally difficult to find m′ such that H(m′) = H(n).

[0081] ● Collision resistance: It is computationally difficult to find a pair of messages n, n′ such that H(n) = H(m′).

[0082] In a UTXO-based blockchain, the solution to the cryptographic puzzle can be set as the spending condition of a transaction, which can be called a reward transaction. The puzzle reward locked in the reward transaction can be claimed by broadcasting a redemption transaction that references the reward transaction and includes the puzzle solution. As part of transaction verification, the verification of the solution is performed by miners.

[0083] One type of cryptographic puzzle among the most common types of cryptographic puzzles in blockchain applications is the hash puzzle. Hash puzzles can be used to lock the reward in a certain transaction. The reward can be claimed by providing the preimage m of a certain hash value H(m). The creator of the reward transaction does not necessarily know the preimage m.

[0084] The locking script of the reward transaction locked by the hash puzzle is as follows:

[0085] Locking Script:

[0086] OP_HASH256<H(m)>OP_EQUAL

[0087] Therefore, the unlocking script for the redemption transaction will be:

[0088] Unlocking Script:

[0089] <m>

[0090] A malicious party intercepting the ransom transaction can create a new ransom transaction containing the solution m to the hash puzzle (whose output points to its own address) and then propagate this new ransom transaction across the network. If this second ransom transaction is accepted by the network before the first ransom transaction, the interceptor will steal the reward from the legitimate solver.

[0091] This vulnerability can be corrected by requiring the ransom transaction to include a digital signature from the intended recipient with public key P A and the solution to the hash puzzle. The locking script will be constructed as:

[0092] Locking Script:

[0093] OP_HASH256<H(m)>OP_EQUALVERIFY OP_DUP OP_HASH160<H(P A )>OP_EQUALVERIFYOP_CHECKSIG

[0094] The unlocking script for the corresponding ransom transaction should be:

[0095] Unlocking Script:

[0096] <P A > <m>

[0097] However, this structure restricts who can redeem the puzzle bounty to the owner of the public key P A In some cases, anyone would like to be able to claim the hash bounty by providing the pre-image of the hash.

[0098] Therefore, there is a problem in ensuring that the first user to solve the broadcast puzzle receives the bounty, including cases where the challenger does not know the solution.

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

[0100] 5. Proof of Sequential Computation

[0101] Sequential computation proofs are proofs that can be computed within a specified amount of time N, but do not speed up (significantly) even with access to a large amount of parallel hardware. Anyone can easily verify the proof without interacting with a trusted third party, ideally in time polylog(N).

[0102] This time measures sequential work, i.e., work that cannot be executed faster by distributing the computation across multiple parallel cores. When the user's hardware is known, sequential computation proofs can be used as proof that a certain amount of time has passed. If the user's speed is unknown, a lower bound can be estimated based on the latest hardware capabilities.

[0103] The following subsections describe three types of sequential computation proofs: Sloth (Section 5.1), Proof of Sequential Work (PoSW) (Section 5.2), and Verifiable Delay Function (VDF) (Section 5.3).

[0104] 5.1 SLOTH

[0105] The first structure for sequential computation proofs is based on the problem of extracting modular square roots in Given a challenge where p ≡ 3 mod 4, anyone can efficiently verify a pair using a single squaring operation y 2 ≡ x mod p Calculation. There is no known algorithm that can compute modular exponentiation in sub-linear time within the bit-length of the exponent. However, since the exponent can be reduced by taking the modulus p - 1 before performing the calculation, the difficulty of the puzzle is limited to O(log p). Therefore, generating a difficult puzzle requires using a very large prime number p, which, however, also introduces the opportunity to parallelize the multiplication operation in to achieve an acceleration of up to O(log p).

[0106] To overcome this limitation, a series of square root calculations in can be interleaved with simple permutations to form a structure called Sloth. The chain can only be evaluated sequentially, and the difficulty is linear within the length of the chain. Therefore, Sloth provides the opportunity to create a proof of sequential computation, whose difficulty can be arbitrarily large but also depends on the available data storage.

[0107] More specifically, let p ≡ 3 mod 4 be a prime number. Therefore, for any exactly one of x or -x is a square, and the square root can be calculated by raising this square to the power. If y is the square root of the square , then y and -y are the only two square roots of x. Define as the unique, even square root of x, and define as the unique, odd square root of x. The parity of an element y is defined as the unique integer parity such that

[0108] The chain in Sloth is calculated by iterating the permutation , where ° is the composition operator. The permutation ρ is defined as follows:

[0109]

[0110] where the inverse is:

[0111]

[0112] Iterating the permutation ρ can simplify the calculation of ρ L , where L is the length of the chain. This simplification first calculates and then calculates a single modular exponentiation x v , so only O(log p) multiplications are required to evaluate the chain. This can be avoided by adding a layer of unstructured obfuscation using the permutation σ = σ -1 that simply swaps neighbors as follows:

[0113]

[0114] Compared with the O(log p) multiplication operations required for evaluation, the verification of each step in the chain requires one multiplication operation on Thus, the gap between the computation and verification of the chain in Sloth is O(log p). Increasing the size of p amplifies this gap, yet it also introduces opportunities to parallelize the multiplication operations in

[0115] 5.2 Sequential Proof of Work

[0116] The sequential computation proof described in the previous subsection cannot be verified asymptotically efficiently: the verification of the Sloth chain is only faster than the evaluation program by a constant factor of O(log p). In the following, proofs of sequential work (PoSW) are described, which achieve an exponential gap between evaluation and verification.

[0117] PoSW enables the verifier to efficiently check whether the prover has expended a given sequential amount of work after receiving a certain statement χ.

[0118] PoSW is most easily defined and proven secure in the random oracle model (ROM), as here the (potentially parallel) queries to the random oracle (RO) can be identified as a time step. Assume that the prover and the verifier both have access to the random oracle

[0119] For the random oracle The concept of sequentiality in PoSW defined in the ROM depends on the computation of -sequences. A -sequence of length L is a sequence x1,…,x L ∈ {0,1} * such that for each i, 1 ≤ i < L, is contained in x i+1 as a consecutive substring, i.e., where some a, b ∈ {0,1} * Whenever the adversary outputs a -sequence of length L (where L is much less than 2 w , which is the case in practice if the standard block length w = 256 is used), it can be assumed that for ​At least L sequential queries are performed. Suppose has collision resistance.

[0120] The PoSW in the ROM model consists of the following four algorithms.

[0121] ● S ETUP (1 λ ) → pp: Obtain the security parameter λ and generate the public parameter

[0122] ● Take the statement time parameter as input and output a commitment after computing a -sequence of length T In addition, generate and store some additional information locally for use in the OPEN algorithm.

[0123] ● Take the challenge vector γ = (γ1,…,γ k ) and the locally stored information as input and send the proof vector π = (π1,…,π ) ∈ {0,1} k to * .

[0124] ● VERIFY(pp,(χ,T,φ),π) → {0,1}: Take the commitment vector (χ,T,φ), the proof π as input and accept it (output 1) or reject it (output 0).

[0125] PoSW should satisfy the following properties:

[0126] ● Soundness: For any pp = (w,k) output by S ETUP (1 λ ), statement and time parameter , if and then VERIFY(pp,(χ,T,φ),π) = 1. Thus, an honest prover can make the verifier accept by performing only T sequential queries to H.

[0127] ● Rationality: Any cheating prover that performs (1 - α)T sequential queries (where 0 < α < 1) to will make the verifier accept with probability (1 - α) k . By increasing the security parameter k ∈ pp, this probability can be arbitrarily ignored.

[0128] ● Efficiently verifiable: The solution must be publicly verifiable in total time O(polylog(T)).

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

[0130] Cohen and Pietrzak PoSW

[0131] In Cohen and Pietrzak's PoSW (CP-PoSW), the random oracle is instantiated using a hash function H that is essentially sequential. This means that computing an H-sequence of length T requires T queries to H. By sending the statement χ is used to sample a new hash function H' defined as H salted with χ χ :

[0132]

[0133] In CP-PoSW, uses to compute the labels of a directed acyclic graph (DAG), where the label of a node is the hash of the labels of its parents (if there is a directed edge from u to v, then u is a parent of v). More precisely, the label l i ∈ {0,1} w of i ∈ V is recursively computed as:

[0134] where (p1,…,p d ) = parents(i).

[0135] The labels in the DAG can be computed in any topological order. Computing the T labels in the DAG reduces to computing an H-sequence of length T and thus requires T sequential queries to .

[0136] When using a hash function H that employs the Merkle-Damgård construction, care must be taken regarding how the parent nodes of a node are ordered when computing the label of that node. The Merkle-Damgård construction is used to build a hash function H: {0,1} 2w → {0,1} w of arbitrary input length from a compression function h: {0,1} * → {0,1} w as follows:

[0137] H(x1,…,x z ) = y z , where y i : = h(x i , y i-1 ), i ≥ 1.

[0138] Using this structure, it is possible to compute y using only the known prefixes x1,…,x i to compute y i . An attacker may gain an advantage by computing such intermediate y z before knowing the entire input x1,…,x i to take advantage of the parallelization provided to compute the labels of the graph. By requiring to be the label of a node computed before the current node, this can be avoided.

[0139] After labeling the DAG, compute the Merkle tree-like commitment of the labels and send it to The latter then issues a challenge to disclose some of these labels and their parents. Finally, the verifier verifies whether the labels received from are correctly computed and whether the openings are correct with respect to the Merkle tree-like commitment initially received.

[0140] Graph construction

[0141] For let T = 2 t+1 - 1 and B t = (V, E′) be a full binary tree of depth t. Each of the T nodes can be identified using a binary string of length at most t, which is recursively defined as follows: for a node x ∈ {0, 1} <t , its left child is identified as x‖0, and its right child is identified as x‖1. The root is identified using the empty string ∈. The directed edges in B n extend from the leaves towards the root:

[0142] E′ = {(x‖b, x) : b ∈ {0, 1}, x ∈ {0, 1} i , i < t}.

[0143] The DAG that must be labeled in CP - PoSW is constructed as follows. Starting from B t , for all leaves u ∈ {0, 1} t add the edges E″ it contains, and for any v (which is the left sibling of a node on the path from u to the root ∈) add the edge (v, u). Thus, E = E′ ∪ E″, where:

[0144] E″ = {(v, u) ∶ u ∈ {0, 1} t , v = a‖0, u = a‖1‖a′}。

[0145] Figure 3 Denote Figure 300. The edges in E′ are represented by solid arrows, and the edges in E″ are represented by dashed arrows. For example, the edge (v = 00, u = 0100) belongs to E″ and is represented by a dashed arrow because u ∈ {0, 1} t , v = a‖0, u = a‖1‖a′, where a = 0, and a′ = 00.

[0146] The graph used in CP - PoSW An interesting property of Figure t 300 is that the labels can be computed in topological order (starting from 0

[0147] Computing the proof

[0148] If only logarithmic memory is used, then it is necessary to recompute all the labels of the graph to compute the disclosure information of the label challenged by v. Fortunately, there is a simple trade - off where using slightly more memory can make the computation of the proof more efficient. One can store the labels of the m top - most nodes of the tree . From this, any other required nodes can be computed to compute a proof that makes only 2 χ - 1 queries to H t-m+1 .

[0149] Algorithm

[0150] CP - PoSW consists of the following four algorithms. Assume the time parameter takes the form T = 2 t+1 - 1, where the integer is denoted by m ≈ log2M, where M is the amount of memory allowed to be used (measured in w - bit blocks).

[0151] ● S ETUP (1 λ ) → pp: Obtain the security parameter λ and generate the common parameters All parties have access to the hash function H: {0, 1} * → {0, 1} w . Usually, w = 256 (e.g., when H is the SHA256 function).

[0152] ● Use H χ to compute the graph The label of Store the labels of the m top-level And set the root label φ = l ∈ Send to

[0153] ● On the challenge γ = (γ1, …, γ ) sampled by k , prove that each element π k of the vector π = (π1, …, π i contains the label of the node γ i ∈ {0, 1} t and the labels of all sibling nodes of the nodes on the path from γ to the root (just like in the disclosure information of the Merkle tree commitment), that is i

[0154]

[0155] Where:

[0156]

[0157] Figure 3 For example, for γ i = 0101 (see Figure 3 ), π i contains the labels of 0101, 0100, 011, 00, and 1.

[0158] ●V ERIFY (pp, (χ, T, φ), π) → {0, 1}: Utilize the fact that in , all parents of the leaf γ i are a subset of . For each 1 ≤ i ≤ k, first check whether it is correctly calculated from its parent label

[0159] where (p1, …, p d ) = parents(γ i )

[0160] Then, for each 1 ≤ i ≤ k, verify the "Merkle tree-like" commitment of l i by iteratively calculating using the labels in π γi , where j = t - 1, t - 2, …, 0

[0161]

[0162] Then, verify whether the calculated root is equal to φ.

[0163] Since the prover adopts the common currency model, by deriving the challenge γ (where γ = (H χ (φ, 1), …, H χ (φ, k))), the Fiat-Shamir heuristic can be used to make the CP-PoSW non-interactive. In the non-interactive version of the CP-PoSW, the E VAL and O PEN algorithms can be combined together.

[0164] The soundness of the CP-PoSW stems from the construction of the protocol. It is easy to see that if an honest prover correctly computes χ the labels in 300 by making T sequential queries to H , she will be able to generate a commitment φ and a proof π that will always be accepted by an honest verifier.

[0165] For a hash function with a large output (e.g., 256-bit output), if a cheating prover makes at most (1 - α)T sequential queries to H χ after receiving χ (where 0 < α < 1), there is a probability of (1 - α) k that V will accept the corresponding proof. Therefore, the protocol is sound when using a large value for k. For example, by setting k = 100, a cheating prover who makes 0.8T sequential queries to H χ will be able to make accepted with a probability of 2 -32 (for k = 150, the probability drops to 2 -48 ).

[0166] For a commitment vector (χ, T, φ), anyone can verify the proof π without accessing any secret information. This only requires verifying the sampling of the challenge γ, verifying whether the corresponding labels are correctly computed, and verifying whether the Merkle-style commitments of these labels are correct with respect to φ. Overall, V ERIFY needs to make O(k.log2T) sequential queries to H χ , while E VAL needs to make T sequential queries. Therefore, the CP-PoSW provides an exponential gap between the evaluation and verification of the proof.

[0167] 5.3 Verifiable Delay Function

[0168] A verifiable delay function (VDF) is a function that can only be evaluated after a specified number of sequential steps VDF generates publicly verifiable proofs that these steps have been executed to produce the output. Similar to PoSW, VDF guarantees that it takes a certain amount of time for a party to evaluate them. The required computational time is also needed on parallel computers, making it impossible to perform the evaluation faster through parallelized computing. The only way to gain an advantage is to purchase or design faster hardware, but there is a theoretical lower bound on the time required to evaluate VDF.

[0169] VDF can be regarded as the only special case of PoSW because two acceptable proofs cannot be computed on the same challenge. In PoSW, if a user removes any single edge in the graph, the proof will change but is unlikely to be detected by a random challenge.

[0170] VDF consists of the following three algorithms:

[0171] ● S ETUP (1 λ ) → pp: A randomization algorithm that takes the security parameter λ as input and produces the public parameter pp.

[0172] ● EVAL(pp, (x, T)) → (y, π): A deterministic algorithm that takes the challenge as input and outputs the response and the proof π, proving that y is correctly computed.

[0173] ● VERIFY(pp, (x, T), (y, π)) → {0, 1}: A deterministic algorithm that takes the challenge (x, T) and the response (y, π) as input and outputs 1 if y is the correct evaluation of the VDF on the input x, otherwise 0.

[0174] A VDF scheme should satisfy the following properties:

[0175] ● Correctness: For any λ output by SETUP(1 ) and pp, if (y, π) ← EVAL(pp, (x, T)), then V ERIFY (pp, (x, T), (y, π)) = 1.

[0176] ● Soundness (uniqueness): For any input x ∈ x, V ERIFY will accept exactly one Specifically, let be an efficient algorithm that, given pp as input, outputs ((x, T), (y, π)) such that V ERIFY (pp, (x, T), (y, π)) = 1, then Pr[EVAL(pp, (x, T)) ≠ y] is negligible.

[0177] ● Sequentiality: Parallel algorithms Using at most poly(λ) processors and running in less than time T, it is impossible to compute the function. Specifically, for any k output by SETUP(1 and pp, if (y,π)←EVAL(pp,(x,T)), then can be ignored.

[0178] ● Efficiently verifiable: VERIFY should be computable by anyone as fast as possible; it should take total time O(polylog(T)).

[0179] VDFs are based on computational tasks that cannot be accelerated by parallelization. Modular exponentiation in groups of unknown order is thought to have this property. Two VDF constructions have emerged, which similarly exploit the sequential nature of this task.

[0180] 1. The first VDF construction (Pietrzak) is faster to create, but larger and slower to verify.

[0181] 2. The second VDF construction (Wesolowski) is slower to create (but parallelizable), but shorter and faster to verify.

[0182] This paper uses the first of these constructions. Although the second VDF is shorter and faster to verify, verification requires a primality test. A test that "proves" the primality of a number rather than just showing that primality is "probable" is called a deterministic primality test. When checking whether a number is indeed prime in the locking script of a transaction, since the script is public, it is better to perform a deterministic primality test. The problem is that deterministic primality tests are quite expensive when dealing with large numbers. The first VDF does not use any complex algorithms (such as primality tests), so in the context of the use cases provided in this paper, it is preferred over the second VDF. Additionally, for VDFs with a required evaluation time of less than an hour, the gap between the two proof sizes is not significant.

[0183] Pietrzak's VDF

[0184] The setup algorithm SETUP(1 λ ) of Pietrzak's VDF (P-VDF) outputs two objects:

[0185] ● A finite abelian group of unknown order (The specific group setup will be discussed later).

[0186] ● An efficiently computable hash function modeled as a random oracle

[0187] Evaluation algorithm E VAL (pp,(x,T)) is defined as follows:

[0188] ●Calculate the hash value g←H(x).

[0189] ●Through calculation The t-times square operation is used to calculate In Start with g.

[0190] ●Prove π by calculation as follows.

[0191] ●Output (y,π).

[0192] Pietrzak gives a public money parsimony argument to prove that the output y is correct. Given the binary As input, the prover and the verifier participate in a recursive protocol to prove In where g = H(x). For simplicity, assume T = 2 t is a power of 2. The protocol can be adapted to more general settings where T is not necessarily a power of 2.

[0193] 1. Validator Check Otherwise output 0.

[0194] 2. If T = 1, the verifier checks y=g 2 , if so, output 1, otherwise output 0 and stop.

[0195] 3. If T>1, the prover and verifier perform the following operations:

[0196] a. Prover calculation And send μ to the verifier. The verifier checks And output 0, otherwise stop.

[0197] Next, the prover needs to convince the verifier that and This can prove Since the same exponential is used in both equations, they can be verified simultaneously by checking random linear combinations, namely:

[0198] For {1,…,2 λ } in a random r.

[0199] The verifier and prover perform the following operations.

[0200] b. The verifier sends {1,…,2 λ random r in {}.

[0201] c. Both the prover and the verifier compute g2 ← g through r μ and y2 ← μ r y.

[0202] d. The prover and the verifier recursively participate in an interactive proof to prove the

[0203] property

[0204] that the P-VDF satisfies the properties of a VDF:

[0205] ● Soundness: From the recursive structure of the protocol, it can be seen that if of then an honest verifier will always accept the proof from an honest prover.

[0206] ● Soundness (uniqueness): The soundness of the P-VDF depends on a low-degree assumption, which states that there does not exist an efficient algorithm that takes as input the description of and outputs a pair (v, d) where v d = 1, where and 1 < d < 2 λ . If the low-degree assumption holds, the soundness error of Pietrzak's succinct argument is negligible.

[0207] ● Sequentiality: It is believed that computing y requires T sequential squaring operations in , even on a parallel computer with poly(λ) processors. It cannot be simplified unless the order of is known . For anyone who knows the order of , it can be easily computed with just two modular exponentiations: followed by g e . In this case, the running time is logarithmic in T.

[0208] ● Efficiently verifiable: At each level of the recursion, the verifier performs two small modular exponentiations in to compute g i+1 and y i+1 for the next level. Thus, verifying the proof requires approximately 2 log2 T small modular exponentiations in . Overall, the proof π contains log2 T elements in {}.

[0209] Compute the proof

[0210] Prove the number μ of each level of the computation recursion i . Let g1 = H(x), μ1, r1 be the values of μ and r at the top level of the recursion, μ2, r2 at the next level, and so on. Unfolding the recursion shows that these quantities are as follows:

[0211]

[0212]

[0213]

[0214] Power product of

[0215] The emerging pattern suggests an efficient way to construct the proof π. When the VDF evaluator computes the VDF output , this stores the 2 d group elements encountered along the way where i = 0,…,2 d -1 (how to determine the value d will be explained later).

[0216] When constructing the proof π, these (2 d ) stored values enable it to use a total of approximately 2 small modular exponentiations performed in d to compute the group elements μ1,…,μ d required for the proof. The prover computes the remaining elements μ d+1 , g d+2 ,…, g log T by raising them to the appropriate exponents from scratch d+1 , μ d+2 ,…, μ log T . This step performs a total of T / 2 multiplications in d . Thus, the total number of multiplications for computing the proof is approximately 2 d + T / 2 d , which shows that is optimal. Therefore, the VDF output and the proof π can be computed in a total time of approximately .

[0217] Specific group settings

[0218] For the RSA group is a natural choice, where for a pair of distinct prime numbers p and q, N = pq. However, since is an element of order two, the low-order assumptions required to prove soundness are trivially false in groups of this kind. Groups for which the low-order assumptions are considered to hold Included to ensure the rationality of the protocol. The generation of the modulus N must be trustworthy and not reveal the factorization of N. This can be achieved either by involving a trusted party that immediately forgets the values p, q after generating them, or by using multiparty computation to sample N. When the factorization of N is unknown, computing the order of is as difficult as factoring N, so it can be used as a group of unknown order.

[0219] Integers N that are products of strong primes can be used. A prime p is a strong prime if (p - 1) / 2 is also prime. If N = pq is a product of distinct strong primes, then the group does not contain low-order elements other than 1. Thus, the low-order assumption holds unconditionally in this group. Using instead of does not significantly simplify the computation. In step (3.a) of the protocol, the verifier needs to check whether Therefore, when performing computations in the protocol should be adjusted so that the prover sends μ′ such that μ′ 2 ≡ μ mod N. Then, the verifier will compute μ = μ′ 2 mod N and thus determine Since the prover can send any of the 4 roots of μ here, the proof is not unique.

[0220] The computation can be performed in the signed quadratic residue group which is isomorphic to . The group is defined as where |x| is the absolute value when representing the elements of as the set {-(N - 1) / 2,…,(N - 1) / 2}. The group is cyclic, where the group operation is given by . Using instead of has the advantage that membership in can be efficiently tested: Given (represented as {-(N - 1) / 2,…,(N - 1) / 2}) belongs to if and only if x ≥ 0 and its Jacobi symbol is +1. Using instead of also makes the proof unique.

[0221] To ensure that no one knows To completely avoid trusted setup in terms of the order, an imaginary quadratic field can be used of the class group, where p is a negative prime such that p ≡ 1 mod 4. This class group has an odd order, and computing the order of this class group is considered difficult when |p| is large, even for parties who know p.

[0222] Non - interactive protocol

[0223] Due to the common - currency nature of Pietrzak's succinct argument, the Fiat - Shamir heuristic can be used to make the proof non - interactive. The prover uses a hash function to hash the quantities (g i , y i , μ i , T / 2 i-1 ) to generate the challenge r i at each level of the recursion and appends μ i to the overall proof π. In what follows, assume that all operations are performed in .

[0224] ● SETUP(1 λ ) → pp: The statistical security parameter λ defines the bit - length λ RSA of the generated modulus N. The parameter λ RSA should be at least large enough such that a λ - bit modulus provides λ - bit security (e.g., λ = 256 and λ RSA = 2048). Then, a hash function RSA is chosen and the pair pp = (N, H) is output.

[0225]

[0225] ● E VAL (pp, (x, T)) → (y, π): Output (y, π), where and π = {μ i} i∈[t] along with the corresponding proof that y has been correctly computed. Let (g1, y1): = (H(x), y), and for i = 1, …, t, let:[[]]

[0226]

[0227] r i : = hash(g i , y i , μ i , T / 2 i-1 )

[0228]

[0229]

[0230] ●V ERIFY (pp,(x,T),(y,π)) → {0,1}: Parse π = {μ i} i∈[t] and check if g1,y1 := (H(x),y) and all Otherwise output 0. Otherwise, for i = 1,…,t, compute:

[0231] r i := hash(g i ,y i ,μ i ,T / 2 i-1 )

[0232]

[0233]

[0234] Finally, check if and output 1 if true, otherwise output 0.

[0235] 6. Ensuring Puzzle Reward Security

[0236] This document provides a series of solutions to ensure the security of puzzle rewards. These rewards can be claimed by anyone, and the challenger who creates the reward transaction (also called the challenge transaction in this document) does not need to know its solution. The puzzle solution is denoted by S in the rest of this section puz The challenger creates a challenge transaction, which can be redeemed by anyone (the challengee) who broadcasts a redemption transaction (also called the solution transaction in this document, which contains S puz ). These solutions ensure that the first user to broadcast S puz effectively receives the reward by preventing other users from intercepting the solution S included in the redemption transaction puz and redeeming the puzzle reward themselves.

[0237] The solution to the puzzle that locks the Bitcoin transaction must be publicly verifiable so that any miner can verify its correctness. Any suitable puzzle can be used in the solutions provided in this document. Some suitable exemplary puzzles (whose solutions are publicly verifiable) include:

[0238] ● Hash puzzle: The puzzle can be solved by providing the preimage of a certain hash value (Section 4).

[0239] ● Prime number puzzles: The puzzles require prime numbers greater than a predefined value as solutions. These puzzles motivate users to spend their computing power to find large prime numbers.

[0240] ● Evaluation of a verifiable delay function: The puzzles reward any user who computes the evaluation of a verifiable delay function (usually the result of multiple squaring operations in an RSA group).

[0241] ● Proof of retrievability: The puzzles require proving that a user has been allocated space to store a specific file and that the file is intact.

[0242] ● Protein folding: The puzzles require users to fold certain proteins and prove that they have folded certain proteins correctly.

[0243] The puzzles used can allow anyone to claim the reward. Additionally, the challenger does not necessarily know the puzzle solution.

[0244] The schemes for securing puzzle rewards all follow the same principle. Besides the puzzle solution S puz these schemes also require the user to provide a certain computational proof related to S puz in the redemption transaction as well as the public key Pk that signs the redemption transaction. Thus, an attacker attempting to exchange the public key in the redemption transaction must recalculate the computational proof from scratch. Since the computational proof is included in the redemption transaction and is verified by all miners in the network as part of the transaction verification process, the proof should be a publicly verifiable proof. This computational proof ensures that a certain amount of time has passed since the solver found the puzzle solution. This time delay should be large enough to ensure that the redemption transaction of the legitimate solver is accepted by the network before a malicious user who intercepts the solution S

[0245] can create a valid redemption transaction with a valid proof related to their public key Pk′ puz

[0246] One challenge in designing these schemes is to ensure that the amount of time required for generation is independent of the number of users' hardware, so that an approximate estimate (or at least a lower bound) of the time required for generation for all users can be made. The goal is that even an attacker using massively parallel hardware cannot generate a valid computational proof related to their public key before the first legitimate redemption transaction is accepted by the network. Another challenge is to minimize the scale overhead caused by including the computational proof in the redemption transaction and verifying the computational proof in the reward transaction.

[0247] The schemes for securing puzzle rewards use five different types of computational proofs respectively: ​​​

[0248] ● Section 6.1 – Proof of Work (PoW): This scheme is inspired by Bitcoin's PoW. The scaling overhead is negligible, but this scheme is not secure against parallel attackers.

[0249] ● Section 6.2 – Chained Proof of Work: This scheme is based on chained PoW to limit the advantages provided by parallel computing. The scaling overhead is significant for both users and challengers (reward transactions and redemption transactions).

[0250] The following three schemes are based on sequential computational proofs, eliminating the advantages provided by parallel computing.

[0251] ● Section 6.3 – Sloth: This scheme uses the Sloth construction described in Section 5.1. The scaling overhead is negligible in redemption transactions, but significant in reward transactions.

[0252] ● Section 6.4 – Sequential Proof of Work: This scheme uses Cohen and Pietrzak's PoSW described in Section 5.2. The overhead is balanced between reward and redemption transactions.

[0253] ● Section 6.5 – Verifiable Delay Function: This scheme uses Pietrzak's VDF described in Section 5.3. The main overhead occurs in reward transactions.

[0254] In Section 6.6, these schemes are compared in detail in terms of script size according to the required security level and resistance to parallel computing.

[0255] In each of the schemes described below, the challenger generates a locking script to be included in the challenge transaction, and this locking script verifies that:

[0256] i. the puzzle solution S provided by the challenged party puz satisfies the puzzle;

[0257] ii. the proof provided by the challenged party satisfies the proof criteria defined by the scheme; and

[0258] iii. the signature generated for the solution transaction is valid for the public key provided in the solution transaction.

[0259] The proof criteria implemented depend on the scheme chosen. The proof criteria in each case are satisfied only when the proof provided by the challenged party from the public key and the puzzle solution S provided by the challenged party puz is met.

[0260] In each scheme, the challenged party generates the puzzle solution S puz and the proof And provide the puzzle solution and the proof, as well as their public keys, in the unlocking script of the unlocking transaction. The unlocking script also includes a signature valid for the public key generated for the unlocking transaction. The puzzle solution and the proof provided in the blockchain transaction can be referred to herein as the challenge puzzle solution and the challenge proof, respectively.

[0261] Figure 4 Summarizes the approach of each scheme.

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

[0263] In step 2, the challenger 402 generates a challenge transaction. The challenge transaction includes a first locking script that is configured to verify each of the puzzle solution S puz , the proof and the signature of the unlocking transaction. The first locking script is associated with a reward or other UTXO that is unlocked by a valid unlocking script. In step 3, the challenge transaction is sent to the blockchain 150 and stored therein.

[0264] In step 4, the challenge and the puzzle are provided to the challenged party 404. These challenges and puzzles can be sent directly from the challenger 402 to the challenged party 404. Alternatively, for example, the puzzle and the challenge can be publicly provided on a website. In some embodiments, the challenge and the puzzle are provided in the challenge transaction such that when the challenge transaction is sorted into the blockchain 150, or when the challenge transaction is retrieved from the blockchain 150, the puzzle and the challenge become visible.

[0265] In step 5, the challenged party 404 generates a candidate puzzle solution S puz corresponding to the defined puzzle. In step 6, the challenged party 404 uses the candidate puzzle solution and the public key of the challenged party to calculate a candidate proof The method for generating the candidate proof is described below.

[0266] The responder 404 generates a solution transaction that includes a first unlocking script for unlocking the UTXO of the challenge transaction. The first unlocking script includes a candidate puzzle solution S puz , a candidate proof and the public key Pk of the responder. In step 8, the solution transaction is signed using the public key Pk and then sent to the blockchain 150 for storage.

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

[0268] If each of the candidate proof, the candidate puzzle solution, and the signature is verified, the UTXO is provided to the responder 404.

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

[0270] 6.1 Proof of Work

[0271] This scheme for securing the puzzle reward is inspired by Bitcoin's proof of work (PoW). Bitcoin uses PoW to secure the reward. The first miner to solve the PoW puzzle can redeem the reward by claiming the Coinbase transaction. The reward is secure because if the Coinbase transaction (or any other transaction in the block) is modified, the solution to the PoW puzzle changes, and thus the work must be done again from scratch.

[0272] Similarly, the puzzle reward can be secured by requiring the solver of the puzzle (the responder) to provide the solution to the PoW puzzle in the redemption transaction. More specifically, given the solution S puz of the puzzle, the public key Pk that signs the redemption transaction, the 32 - byte target difficulty target, and the hash function H, the proof adopted in this scheme can be expressed by the following formula:

[0273] Find nonce ∈ {0, 1} * , such that int(H(nonce‖Pk‖S puz )) mod 2 256 ≤ target.

[0274] The smaller the target value, the longer (probabilistically) it takes for the user to find a random number value that satisfies the equation.

[0275] In this scheme, the proof provided by the challenged party is the nonce.

[0276] The proof standard is allegedly definable as a threshold (target). If the candidate target value calculated based on the proof (nonce), public key (Pk), and puzzle solution (S puz ) provided by the challenged party in the redemption transaction is less than or equal to the threshold, then the proof standard is met. Although it should be understood that other functions can be defined for defining the candidate target value, the candidate target value in this example is int(H(nonce‖Pk‖S puz )) mod 2 256 .

[0277] To determine the challenge proof, the challenged party can access the proof standard, especially the functions for defining the candidate target value and the threshold. The challenged party can perform trial-and-error calculations to find a proof (nonce) that meets the standard.

[0278] In the following implementation, the hash function H is SHA256 and is applied twice. [VerifyPuzzleSolution] represents the script part of the puzzle solution S puz required to verify the redemption reward. The locking script of the reward transaction protected by the PoW puzzle is as follows:

[0279] Locking Script:

[0280] OP_2OP_PICK OP_2OP_PICK OP_CAT OP_CAT OP_HASH256<0x00>OP_CAT<target>OP_LESSTHANOREQUAL OP_VERIFY[VerifyPuzzleSolution]OP_CHECKSIG

[0281] The unlocking script of the redemption transaction is as follows:

[0282] Unlocking Script:

[0283] <sig Pk > <pk> <S puz > <nonce>

[0284] The unlocking script is valid if the following conditions occur:

[0285] ● The value generated by the random number is less than or equal to the hash of the specified target: int(SHA256(SHA256(nonce‖Pk‖S puz ))) ≤ target.

[0286] ● The puzzle solution S puz is correct (checked by VerifyPuzzleSolution).

[0287] ● The signature is a valid signature for the transaction and the public key Pk.

[0288] The verification of the random number ensures that a certain amount of time has passed since the solver found the solution. Since the random number is concatenated with Pk before hashing, other users cannot exchange Pk without spending time recalculating a valid random number.

[0289] The size overhead in the reward transaction and the redemption transaction is only a few bytes.

[0290] Figure 5 The verification steps implemented to verify the unlocking script are schematically shown.

[0291] The challenger 402 generates a challenge transaction 502 that has a locking script that includes the threshold target. The challenged party 404 generates a solution transaction 504 that has an unlocking script that includes a candidate puzzle solution S puz , a candidate proof nonce, and the public key Pk of the challenged party. The solution transaction 504 also includes a signature sig Pk .

[0292] Then, the locking script of the challenge transaction 502 and the unlocking script of the solution transaction 504 are run together, and steps A through D are performed in the script.

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

[0294] In step C, the candidate puzzle solution is verified against the puzzle defined by the challenger 402. The way to verify the candidate puzzle depends on the type of puzzle used. Those skilled in the art will understand the method of verifying the candidate puzzle solution.

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

[0296] If each check is found to be valid, it is determined that the locking script of the solution transaction 504 is valid and the UTXO of the unlocking challenge transaction 502 is unlocked.

[0297] 6.2 Chain of Proof of Work

[0298] One problem with the previous scheme is that an attacker with strong motivation can easily accelerate the generation of PoW solutions 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 may vary from user to user. In fact, the solution of the PoW puzzle can be (probabilistically) accelerated through parallel computing. For a fixed target value, the attacker's ability to steal the puzzle reward depends on the amount of their hardware. Therefore, the PoW scheme described above is not secure for attackers who can deploy a large amount of parallel hardware.

[0299] To mitigate the advantage provided by parallelization, the following scheme can be used to ensure the security of the puzzle reward.

[0300] The following scheme requires users to solve multiple chained PoW puzzles instead of a single PoW puzzle. Since the chaining property requires the previous value to construct the next value, the process of solving the chain of PoW puzzles is sequential to some extent. Specifically, each time a solution to a PoW puzzle in the chain is found, synchronization between processors is required. This property can be used to limit the advantage of stealing the puzzle reward using large-scale parallel computing.

[0301] The chained PoW puzzle is defined as follows:

[0302] ● The first puzzle in the chain is defined in a similar way to the previous scheme. Given the solution S puz , the public key Pk for signing the redemption transaction, the 32-byte target difficulty target, and the hash function H, the goal is to find the value nonce0 such that:

[0303] int(H(nonce0‖Pk‖S puz )) mod 2 256 ≤ target.

[0304] ● The subsequent puzzles in the chain are based on the previous puzzle, similar to the way the block header chain in Bitcoin is protected. Specifically, the i-th puzzle in the chain needs to find the value nonce i , such that:

[0305] int(H(nonce i ‖h i-1 )) mod 2 256 ≤ target,

[0306] where h i-1 is the hash value obtained by solving the previous puzzle, and H and target are the same as those of the first puzzle, i.e.:

[0307]

[0308] In this scheme, the calculation proof of a chain of length L can be expressed by the formula as follows:

[0309] Find L values nonce0,.., nonce L-1 ∈ {0, 1} * such that

[0310]

[0311] where

[0312] That is to say, the challenge proof includes a sequence of candidate proof values (nonce i ) for calculating a sequence of candidate target values. The first candidate target value (h0) among these candidate target values is calculated using nonce0, S puz and Pk. Each subsequent candidate target value (h i ) of the chain is calculated based on the corresponding one of these proof values (nonce i ) and the previous candidate target value in the chain. Since the final candidate target value is calculated based on the final proof value nonce L-1 and the penultimate candidate target value h L-2 , the final candidate target value is actually based on all the proof values, i.e., the entire proof public key and puzzle solution.

[0313] Evaluation The time required depends on both the value target and the length value L. The effect of increasing L will linearly increase the time required for any user to evaluate regardless of the number of their parallel hardware. However, by adopting a large number of parallel hardware, the impact of increasing the target value on the proof evaluation time can be offset.

[0314] In the following implementation, the hash function H is SHA256 and is applied twice. The locking script for constructing a reward transaction protected by a chained PoW puzzle with length L ≥ 2 can be built by adding the following opcodes:

[0315] 1. Duplicate the second-to-last value and the third-to-last value at the top of the stack (to pull Pk and sol):

[0316] <L+1>OP_PICK<L+1>OP_PICK

[0317] 2. Verify whether the first random value nonce0 satisfies: int(SHA256(SHA256(nonce0‖Pk‖S puz )))≤target.

[0318] OP_CAT OP_CAT OP_HASH256<target>OP_SWAP OP_2DUP<0x00>OP_CAT OP_GREATERTHANOREQUAL OP_VERIFY

[0319] 3. For i = 1 to L - 2, add the following opcodes to verify nonce i whether it satisfies int(SHA256(SHA256(nonce i ‖h i-1 )))≤target:

[0320] OP_ROT OP_SWAP OP_CAT OP_HASH256 OP_2DUP<0x00>OP_CAT OP_GREATERTHANOREQUAL OP_VERIFY

[0321] 4. Verify the last random number nonce L-1 whether it satisfies int(SHA256(SHA256(nonce L-1 ‖h L-2 )))≤target:

[0322] OP_ROT OP_SWAP OP_CAT OP_HASH256<0x00>OP_CAT OP_GREATERTHANOREQUALOP_VERIFY

[0323] 5. Verify the puzzle solution S puz whether it is correct:

[0324] [VerifyPuzzleSolution]

[0325] 6. Verify whether the signature is a valid signature for the transaction and the public key Pk:

[0326] OP_CHECKSIG

[0327] The unlocking script for the redeem transaction is as follows:

[0328] Unlocking Script:

[0329] <sig Pk > <pk><S puz ><nonce L-1 ><nonce L-2 >… <nonce0>

[0330] Among them, <nonce L-1 ><nonce L-2 >… <nonce0>Is the proof value sequence.

[0331] The unlocking script is valid if the following conditions occur:

[0332] ● The hash of the random value nonce0 generates a value less than or equal to the specified target: int(SHA256(SHA256(nonce0‖Pk‖S puz ))) ≤ target.

[0333] ● Each subsequent random value nonce i is as follows: int(SHA256(SHA256(nonce i ‖h i-1 ))) ≤ target, where 0 < i ≤ L - 1.

[0334] ● The puzzle solution S puz is correct (checked by VerifyPuzzleSolution).

[0335] ● The signature is a valid signature of the transaction and the public key Pk.

[0336] In this scheme, each puzzle depends on the previous one. Since the first puzzle is initialized with the public key Pk that signs the redemption transaction, there is a dependency between Pk and all subsequent puzzles. This means that an attacker cannot reuse any random numbers in the chain and must recalculate all random numbers to make the redemption transaction signed with Pk′≠Pk valid.

[0337] Each candidate target value h is checked according to the threshold target i . It is crucial to verify each candidate target value in the candidate target values. This is because, if only the final candidate target value h L-1 is verified, that is, checking int(SHA256(SHA256(nonce L-1 ‖hL -2 ))) ≤ target, the prover only needs to find a suitable h L-2 . The amount of work required to find a suitable h L-2 is the same as the PoSW scheme described in this paper, but the work can be more easily parallelized, thus being calculated faster.

[0338] Figure 6 Schematically shows a method for verifying the unlocking script of the solution transaction 604. This method is similar to the Figure 5 method described above.

[0339] The challenger 402 generates a challenge transaction 602 that has a locking script including a threshold target. The challenged 404 generates a solution transaction 604 that has an unlocking script including a candidate puzzle solution S puz , candidate proofs nonce0, …, nonce L-1 and the public key Pk of the challenged. The solution transaction 604 also includes a signature sig derived from the public key Pk of the challenged Pk .

[0340] Then, the locking script of the challenge transaction 602 and the unlocking script of the solution transaction 604 are run together such that steps A to E are executed in the scripts.

[0341] First, in step A, a first candidate target value h0 is calculated using the first candidate proof value nonce0, the public key, and the puzzle solution of the unlocking script. Then, in step B, subsequent candidate target values h i are calculated, where each of these candidate target values is based on the corresponding candidate proof value nonce i and the immediately preceding candidate target value in the candidate target values h i-1 .

[0342] Then, in step C, each of the calculated candidate target values h i is compared with the threshold of the locking script to determine whether they meet the challenge criteria, i.e., each of the candidate target values is less than or equal to the threshold.

[0343] In step D, the candidate puzzle solution is verified for the puzzle defined by the challenger 402. The way to verify the candidate puzzle depends on the type of puzzle used. A person skilled in the art will know the method of verifying the candidate puzzle solution.

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

[0345] If each check is found to be valid, it is determined that the locking script of the solution transaction 604 is valid and the UTXO of the challenge transaction 602 is unlocked.

[0346] In the scheme described in this section, the challenged can use parallel computing to solve the puzzle, but for each intermediate h i , the parallel processors must synchronize to start solving the next problem of h i+1 , which limits the acceleration provided by parallelized computing.

[0347] Since the puzzles are chained, synchronization between processors is required, which imposes some drag on parallel computing. However, an attacker can still use parallel computing to speed up the solution of each individual puzzle. Therefore, large chains are needed to mitigate the impact of parallel computing. Each hash puzzle in the chain requires 7 additional bytes in the reward transaction, and a random value is the ransom transaction. When considering a chain consisting of hundreds of thousands of hash puzzles, the overhead caused by the chained PoW scheme can become quite large.

[0348] In practice, this scheme has limitations because if good anti-parallel computing characteristics are required, the script size quickly becomes very large. That is, there is a trade-off here between the script size and the anti-parallel computing characteristics.

[0349] The following schemes are provided as alternatives, which are inherently fully resistant to parallel computing and have a reasonable script size.

[0350] 6.3 SLOTH

[0351] As elaborated above, the previous chained PoW scheme can be used to mitigate the advantage of stealing puzzle rewards using large-scale parallel hardware. However, the effect of this scheme is only obvious when using a large puzzle chain. The problem with having a large puzzle chain is that it introduces a significant scale overhead in the reward transaction and the ransom transaction, and thus is inefficient in terms of storage.

[0352] In this scheme, the Sloth chain elaborated in Section 5.1 is utilized to create a scheme that is fully resistant to parallel attackers. The computational proofs adopted in this scheme need to evaluate the Sloth chain, which can only be done sequentially.

[0353] The advantage of using sequential computational proofs is that the time required to evaluate them can be better approximated because it does not depend on the number of available hardware. Users (the challenged) can still invest in faster hardware to speed up the evaluation of the proofs, but the physical limitations of the hardware impose a limit on the computational time interval between users, which can be unbounded in computationally parallel proofs. Specifically, there is a theoretical lower bound on the time required to evaluate any sequential computational proof.

[0354] Sloth proposed intertwining a series of square root calculations in with a simple permutation chain such that the chain can only be evaluated sequentially. More specifically, Sloth defines two permutations on : the permutation ρ such that ρ(x) 2 = ±x; and the permutation σ such that σ(x) = x ± 1, depending on the parity of x. The parity of x is defined as the unique integer parity such that

[0355] For an input x, the output of a Sloth chain of length L is For more details, see Section 5.2. Verifying w means iterating the permutation a total of more than L times, where:

[0356]

[0357] and

[0358]

[0359] Given the solution S of the puzzle puz , the public key Pk for signing the redemption transaction, the 2048-bit prime number p, the hash function H, the chain length the proof adopted in this scheme can be expressed by the formula as follows:

[0360] Calculate where x = int(H(Pk ‖ S puz )) mod p.

[0361] The value of x can be called an intermediate value in this article and is based on the public key and the puzzle solution. w is a candidate proof and can be described as being derived by the prover through a series of square root calculations. The prover's calculation of w is described in more detail in Section 5.1.

[0362] Evaluate The time required is linearly related to the length L of the chain. In addition, it has the property of being resistant to parallel computing; there is no advantage in using parallel hardware to calculate faster.

[0363] In the following implementation, the hash function H is SHA256 and is applied twice. The locking script for the reward transaction protected by the Sloth chain of length L can be constructed by adding the following opcodes.

[0364] 1. Push the prime number p onto the stack:

[0365]

[0366] 2. Verification

[0367] OP_SWAP OP_DUP OP_DUP OP_0OP_GREATERTHAN OP_SWAP OP_3OP_PICK OP_LESSTHAN OP_BOOLAND OP_VERIFY

[0368] 3. For j = 0 to L - 1, calculate by adding the following opcodes

[0369] i. Calculate ρ -1 :

[0370] OP_DUP OP_DUP OP_MUL OP_2OP_PICK OP_MOD

[0371] OP_SWAP OP_2OP_MOD

[0372] OP_IF OP_OVER OP_SWAP OP_SUB OP_ENDIF

[0373] ii. Calculate σ -1 :

[0374] OP_1OP_OVER OP_2OP_MOD

[0375] OP_IF OP_ADD OP_ELSE OP_SUB OP_ENDIF

[0376] 4. Verification

[0377] OP_2OVER OP_CAT OP_HASH256 OP_ROT OP_MOD OP_NUMEQUALVERIFY

[0378] 5. Verify the puzzle solution S puz whether it is correct:

[0379] [VerifyPuzzleSolution]

[0380] 6. Verify whether the signature is a valid signature for the transaction and the public key Pk:

[0381] OP_CHECKSIG

[0382] That is, the locking script is configured to find the function Inverse of, thereby deriving the intermediate value x. The locking script is also configured to calculate the intermediate value x based on the public key and the puzzle solution. If the two calculated intermediate values are equal, the proof criterion is met, i.e., the proof is verified.

[0383] The unlocking script for the redemption transaction is as follows:

[0384] Unlocking Script:

[0385] <sig Pk > <pk> <S puz > <w>

[0386] The unlocking script is valid if any of the following conditions are met:

[0387] ● The evaluation w of the Sloth chain on the input Pk‖S puz is correct, i.e.: where x = int(SHA256(SHA256(Pk‖S puz ))) mod p.

[0388] ● The puzzle solution S puz is correct (checked by VerifyPuzzleSolution).

[0389] ● The signature is a valid signature of the transaction and the public key Pk.

[0390] Figure 7 A schematic diagram of a method for verifying the unlocking script of the solution transaction 704 is provided.

[0391] The challenger 402 generates a challenge transaction that has a locking script that includes a script for performing the following verification steps. The challenged party 404 generates a solution transaction 704 that has an unlocking script that includes a candidate puzzle solution S puz , a candidate proof w, and the public key Pk of the challenged party. The solution transaction 704 also includes a signature sig derived from the public key Pk of the challenged party Pk .

[0392] Then, the locking script (not shown) of the challenge transaction and the unlocking script of the solution transaction 704 are run together such that steps A through E are performed in the script.

[0393] First, in step A, the candidate target value is calculated using the candidate proof value w by computing the inverse of a reversible function (i.e., ). It should be understood that the chain length L can be provided as a challenge variable in the locking script of the challenge transaction.

[0394] In step B, an intermediate value x is calculated using the public key and the candidate puzzle solution of the solution transaction 704. It should be understood that the prime number p can be provided as a challenge variable in the locking script of the challenge transaction.

[0395] Then, in step C, the candidate target value and the calculated intermediate value are compared to determine if they meet the challenge criteria, i.e., the two values are equal.

[0396] In step D, the candidate puzzle solution is verified against the puzzle defined by the challenger 402. The manner of verifying the candidate puzzle depends on the type of puzzle used. One skilled in the art will understand the method of verifying the candidate puzzle solution.

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

[0398] If each check is found to be valid, it is determined that the locking script of the solution transaction 704 is valid and the UTXO of the unlocking challenge transaction is unlocked.

[0399] The overhead in the redemption transaction is only an additional 2048-bit value w (for a prime p of size 2048 bits), which is the result of the evaluation of the Sloth chain. However, the size of the locking script for the reward transaction to linearly verify w depends on the length of the Sloth chain. For a chain of length L and a prime p of size B bytes, the size overhead in the reward transaction is 17 + 23×L + B bytes. Since the difficulty of Sloth is linearly related to the length of the chain, the size overhead in the reward transaction grows linearly with the difficulty.

[0400] 6.4 Sequential Proof of Work

[0401] In this scheme, the sequential proof-of-work (CP-PoSW) described by Cohen and Pietrzak is used as the computational proof for protecting the puzzle reward. CP-PoSW constitutes a sequential computational proof in the same way as the Sloth chain. In CP-PoSW, the difference between the evaluation time and the verification time grows exponentially with the difficulty, while in the Sloth scheme, this difference is only a constant (a factor of O(log p)).

[0402] In CP-PoSW, the challenge labels a directed acyclic graph G = (V, E) of T nodes that requires T sequential hash computations to be performed. Figure 3 An exemplary graph 300 for such a scheme is shown. The value can be referred to as the time parameter, and T = 2 t+1 - 1 is adopted, where the integer

[0403] In the following implementation, the hash function used to label the graph G is the function HASH256 X : x → SHA256(SHA256(X‖x)), where χ = SHA256(SHA256(Pk‖S puz )), where Pk is the public key that signs the redemption transaction, and S puz is the solution to the puzzle for which the reward needs to be protected. Assuming that HASH256 χ is sequential in nature, which means computing a sequence x1,..., x T ∈ {0,1} * (where for each i, 1 ≤ i < T, x i+1 = a‖HASH256 X (x i )‖b, where a, b ∈ {0, 1} for some * ) requires a sequential query of T times for HASH256 χ .

[0404] The label l of node i ∈ V i is calculated as:

[0405] where (p1,..., p d ) = parents(i).

[0406] The label is the label of the node calculated before the current node. As explained in Section 5.2, this can prevent an attacker from using the Merkle-Damgård structure of SHA256 to speed up the calculation of the label using parallel computing.

[0407] In CP-PoSW, the prover commits to the labels of V by sending a Merkle tree-like commitment φ (similar to the Merkle root of a Merkle tree) of the labels of V to the verifier. In the non-interactive version of CP-PoSW, the user (prover) randomly samples k leaves γ i = HASH256 χ (φ‖i) mod 2 t (where 1 ≤ i ≤ k) and sends a proof vector π = (π1,..., π k ) to the verifier (challenger). For each 1 ≤ i ≤ k, π i contains the disclosure information of the label of leaf γ i . Therefore, the proof vector can be called a set of disclosure information corresponding to the directed acyclic graph G. These disclosure information are similar to the Merkle proofs corresponding to the leaves of a Merkle tree. The graph G generated by the prover can be called the candidate directed acyclic graph G.

[0408] Then, the verifier resamples the k leaves γ1,..., γ k , verifies whether their labels are correctly calculated using the labels of their parents, and verifies whether these disclosure information are correct with respect to the commitment φ initially received. By only verifying a subset of the leaves of the candidate graph G, the verifier can verify whether the prover meets the challenge criteria faster than verifying all leaves. The value of k chosen by the prover is large enough to ensure that the prover has calculated a large portion of the labels with a good probability.

[0409] It should be noted that choosing a larger value of k will result in a larger script size, so a trade-off needs to be made between security and computational efficiency.

[0410] Given the solution S of the puzzle puz , the public key Pk for signing the redemption transaction, security parameters and the graph G with time parameters defined in CP-PoSW (wherein a certain ) in the scheme, the proof adopted in the scheme can be expressed by the following formula:

[0411] Calculate the commitment φ and disclosure information of the label of γ i = int(HASH256 χ (φ‖i)) mod 2 t where 1 ≤ i ≤ k, and χ = SHA256(SHA256(Pk‖S puz ))).

[0412] χ can be called an intermediate value in this article and is calculated based on the public key and the puzzle solution.

[0413] [Openingγ i represents the script part corresponding to π i with the disclosure information of the label containing γ i . This script part [Openingγ i can be constructed as follows:

[0414] 1. Add the disclosure information of the label of γ i , that is, all the labels of the sibling nodes of the nodes on the path from γ i to the root. Arrange the labels in ascending order of the height of the labels in the tree (first arrange the labels at height 1, then arrange the labels at height 2, and so on). For example, if γ i = 0011 (see Figure 1 ), then add l1, l 01 , l 000 , and then add l 0010 .

[0415] 2. Add the label l i of γ γi .

[0416] 3. Add the identifier γ i .

[0417]

[0418] In the implementation method described here, the identifier of the node is the integer value of the identifier in big-endian format defined in CP-PoSW (see Section 5.2). In the previous example, γ i Equal to 3, rather than 0011 defined in CP-PoSW. This means 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 their parents are different. Therefore, even if multiple nodes share the same identifier, it should not enable users to speed up the calculation of the labels of the graph.

[0419] The graph G used in CP-PoSW makes γ i The labels of the parents of are included in the disclosure information of the label of γ i When counting from 0 from left to right, the positions of these labels in [Opening γ i correspond to the positions of 1 in the binary representation of γ i For example, referring to Figure 3 Figure 300, for γ i = 3 at the fourth level in the tree (represented in binary as 0011) 302, the parent labels appear in positions 2 and 3 in [Opening γ i , and these positions actually correspond to l 000 306 and l 0010 304.

[0420] [HASH256 χ is represented by the script part of the implementation function HASH256 χ Assume that the three elements at the bottom of the main stack are: (bottom), <pk>and puz >.

[0421] [HASH256 χ ]: = OP_DEPTH OP_2OP_SUB OP_PICK OP_DEPTH OP_3OP_SUB OP_PICKOP_CAT OP_HASH256 OP_SWAP OP_CAT OP_HASH256 for a certain query leaf γ i ,[VerifyOpeningγ i ]Verified by [Openingγ i ] contained in γ i The script part of the disclosure information is represented. In the following, it is assumed that the Merkle tree commitment φ is at the top of the alt stack. In addition, it is assumed that the three elements at the bottom of the main stack are: <sig Pk >(bottom), <pk>And <sol>(Top).

[0422] For some 1 ≤ i ≤ k, the script part [VerifyOpeningγ i can be constructed as follows:

[0423] 1. Verify challenge leaf γ i is correctly sampled as γ i = int(HASH256 χ (φ‖i)) mod 2 t :

[0424] OP_DUP OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_CAT[HASH256 χ <0x00>OP_CAT<2 t >OP_MOD OP_NUMEQUALVERIFY

[0425] 2. Push the parent of γ i onto the alt stack. The position of 1 in the binary representation of γ i is used to locate its parent:

[0426] i. Push the flag -1 onto the alt stack:

[0427] OP_1NEGATE OP_TOALTSTACK

[0428] ii. For j = t - 1 down to 0, add the following opcode:

[0429] OP_DUP<2 j >OP_DIV OP_2OP_MOD OP_0NOTEQUAL

[0430] OP_IF

[0431] <j + 2>OP_PICK OP_TOALTSTACK

[0432] OP_ENDIF

[0433] 3. Verify the tag of γ i has been correctly calculated using the tag of its parent:

[0434] i. Initialize:

[0435] OP_DUP OP_FROMALTSTACK

[0436] ii. For j = 0 to t - 1, add the following opcode:

[0437] OP_DUP OP_1NEGATE OP_EQUAL

[0438] OP_NOTIF

[0439] OP_CAT OP_FROMALTSTACK

[0440] OP_ENDIF

[0441] iii. Finalize:

[0442] OP_DROP[HASH256 χ OP_2OP_PICK OP_EQUALVERIFY​

[0443] 4. Verify whether the disclosed information promised is correct:

[0444] i. For j = 1 to t - 1, add the following operation codes:

[0445] OP_DUP OP_2OP_DIV

[0446] OP_DUP OP_0NOTEQUAL OP_NOTIF OP_DROP<0x00>OP_ENDIF

[0447] OP_TUCK OP_TOALTSTACK OP_TOALTSTACK

[0448] OP_ROT OP_ROT

[0449] OP_FROMALTSTACK OP_2OP_MOD OP_IF OP_SWAP OP_ENDIF

[0450] OP_CAT OP_CAT[HASH256 χ

[0451] OP_FROMALTSTACK

[0452] ii. Calculate the candidate commitment l ∈ :

[0453] OP_2OP_MOD OP_IF OP_SWAP OP_ENDIF

[0454] OP_CAT[HASH256 χ

[0455] iii. Verify the calculated candidate commitment l ∈ whether it is equal to φ:

[0456] OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_EQUALVERIFY The complete locking script for the reward transaction protected by CP - PoSW is as follows:

[0457] Locking Script:

[0458] OP_TOALTSTACK[VerifyOpeningγ1][VerifyOpeningγ2]…[VerifyOpeningγ k ​​OP_FROMALTSTACK OP_DROP[VerifyPuzzleSolution]OP_CHECKSIG

[0459] The unlocking script for the redemption transaction is as follows:

[0460] Unlocking Script:

[0461] <sig Pk > <pk><S puz >[Openingγ k [Openingγ k-1 …[Openingγ1]<φ>

[0462] The unlocking script is valid if the following conditions occur:

[0463] ● Each disclosure information of the tags of γ1,…,γ k is valid.

[0464] ● The puzzle solution S puz is correct (checked by VerifyPuzzleSolution).

[0465] ● The signature is a valid signature of the transaction and the public key Pk.

[0466] Figure 8 A method for verifying the unlocking script of the solution transaction 804 is schematically shown.

[0467] The challenger 402 generates a challenge transaction (not shown), which has a locking script that includes a script for performing the following verification steps. The challenged party 404 generates a solution transaction 804, which has an unlocking script that includes a candidate puzzle solution S puz , a candidate proof [Openingγ k [Openingγ k-1 …[Openingγ1]<φ> and the public key Pk of the challenged party. The solution transaction 704 also includes a signature sig Pk .

[0468] The locking script of the challenge transaction and the unlocking script of the solution transaction 804 are run together so that steps A to F are performed in the script.

[0469] First, in step A, the candidate leaf value γ i is calculated using the commitment φ. It should be understood that the parameter t can be provided as a challenge variable in the locking script of the challenge transaction. In addition, an intermediate value χ can also be calculated based on the candidate puzzle solution and the public key. The candidate leaf value is compared with the leaf value of the candidate graph G to verify whether the leaf has been correctly sampled.

[0470] In step B, by checking each tag to verify whether γ i has been correctly calculated using the tags of its parent

[0471] Then, the promised disclosure information is verified as follows: In step C, the target commitment l is calculated based on the disclosure information of the solution transaction 804 ∈ ; and in step D, the target commitment l ∈ is compared with the candidate commitment φ of the solution transaction 804

[0472] In step E, the candidate puzzle solution is verified for the puzzle defined for the querier 402. The way to verify the candidate puzzle depends on the type of puzzle used. A person skilled in the art will understand the method of verifying the candidate puzzle solution

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

[0474] If each check is found to be valid, it is determined that the locking script of the solution transaction 804 is valid, and the UTXO of the unlocking query transaction is unlocked

[0475] Each leaf in G can be identified using at most bytes, and the size of each label is 32 bytes. Therefore, the size overhead in the redemption transaction is k×size opening bytes, where size opening ≈32×t. The size overhead in the reward transaction is k×size verify_opening bytes, where size verify_opening ≈70 + 54×t. Since the difficulty of CP - PoSW is exponentially related to the parameter t, the size overhead in the reward transaction and the redemption transaction grows logarithmically with the difficulty

[0476] 6.5 Verifiable Delay Function

[0477] In this scheme, as elaborated in Section 5.3, Pietrzak's VDF (P - VDF) is used as the computational proof for protecting the puzzle reward. P - VDF involves computing the value * of a certain input x∈{0,1} , time parameter and hash function and generating a proof π that the value y has been correctly computed. To ensure the security of the puzzle solution S puz , this scheme requires the user to evaluate P - VDF on the query (x,T), where x is the concatenation of S puz and the public key Pk that signs the redemption transaction and can be called the intermediate value. y can be called the result value in this article

[0478] The working principle of the P - VDF - based scheme is as follows. The querier selects the security parameter λ, time parameter T and runs the S ETUP program, which outputs the group for performing the operation Description and Hash Function For simplicity, in the remainder of this section, assume that for some T = 2 t is a power of two. Evaluating the P-VDF involves performing T squaring operations to compute Similar to the Sloth scheme and CP-PoSW, evaluating the P-VDF is inherently a sequential problem, thus constituting a proof of sequential computation, and its evaluation cannot be accelerated by parallel computation.

[0479] In addition to the result value y of the evaluation of the P-VDF, a proof π consisting of log2T elements μ1, …, μ t is attached to prove that y has been correctly computed. The proof can be referred to as including the proof values μ i sequence.

[0480] To verify it, the verifier needs to perform 2log2T modular exponentiation operations, as detailed in Section 5.3. Similar to CP-PoSW, the P-VDF achieves an exponential gap between the evaluation time and verification time of the proof.

[0481] Given the solution S puz of the puzzle, the public key Pk for signing the redemption transaction, the hash function H, and the time parameter (where some ), the proof adopted in this scheme can be expressed by the formula as follows:

[0482] Computation result and the proof π = {μ i}, to prove that y has been correctly computed, where x = Pk‖S i∈[t] . puz .

[0483] x can be referred to as the intermediate value. The result value y is computed by the verifier based on the intermediate value and as the result of a sequence of squaring operations, as elaborated in Section 5.3. Each proof value is derived from the hash of the intermediate value.

[0484] Parameter Settings

[0485] Depending on the settings used, the verifier may or may not know the order of the group in which the operations are performed. For a discussion on the choice of group, see Section 5.3. In the following, all operations are performed in the group Execute in. Assume the challenger is trustworthy and forgets the factorization of the parameter N = pq immediately after generating it. As explained in Section 5.3, a malicious challenger who knows the order of the group can evaluate the P-VDF for any input x in O(log2T) steps instead of O(T) steps, and can thus easily intercept and steal the puzzle reward. The following implementation can be adapted to other groups, such as the class group of imaginary quadratic fields where the challenger does not need to be trusted.

[0486] To obtain good security, the size of N should be at least λ RSA = 2048 bits. The hash function can be constructed by evaluating SHA256 on the input concatenated with the counter level.

[0487]

[0488] where x = Pk‖S puz and is the first integer such that the output value is within Random value in The probability of generating an element in is When N is large, this probability is close to 1. Therefore, only a few attempts are needed to find a suitable value of c.

[0489] In the non-interactive version of the P-VDF, the hash function hash is used to generate the challenge r. Depending on the required security level, the hash function hash used in the Bitcoin script can be RIPEMD160°SHA256 (for λ = 160) or (for λ = 256). Below, λ is chosen to be equal to 256 and

[0490] Verification script

[0491] [ModExponentiate] represents the script part that takes x, a, n as input and returns x a mod n (the implementation will be detailed later). The locking script for implementing the verification of the P-VDF evaluation can be constructed as follows:

[0492] 1. Push N onto the main stack:

[0493] <n>

[0494] 2. Check (by checking 1 < μ i < N - 1 and ), and pushing them onto the alt stack by copying t times:

[0495] OP_SWAP OP_2OP_PICK OP_DUP OP_DUP OP_1OP_GREATERTHAN OP_VERIFY OP_3OP_PICK OP_1SUB OP_LESSTHAN OP_VERIFY OP_MUL OP_OVER OP_MOD OP_1OP_NUMEQUALVERIFY OP_SWAP OP_TOALTSTACK

[0496] 3. Push T onto the alt stack:

[0497] <t>OP_TOALTSTACK

[0498] 4. Check (by checking 1 < y1 < N - 1 and ) and push it onto the alt stack:

[0499] OP_SWAP OP_2OP_PICK OP_DUP OP_DUP OP_1OP_GREATERTHAN OP_VERIFY OP_3OP_PICK OP_1SUB OP_LESSTHAN OP_VERIFY OP_MUL OP_OVER OP_MOD OP_1OP_NUMEQUALVERIFY OP_SWAP OP_TOALTSTACK

[0500] 5. Calculate (by calculating ):

[0501] OP_SWAP OP_TOALTSTACK OP_TOALTSTACK OP_3DUP OP_CAT OP_CAT OP_HASH256<0x00>OP_CAT OP_FROMALTSTACK OP_TUCK OP_MOD

[0502] 6. Check (by checking 1 < g1 < N - 1 and ):

[0503] OP_DUP OP_DUP OP_DUP OP_1OP_GREATERTHAN OP_VERIFY OP_3OP_PICK OP_1SUBOP_LESSTHAN OP_VERIFY OP_FROMALTSTACK OP_MUL OP_2OP_PICK OP_MOD OP_1OP_NUMEQUALVERIFY

[0504] 7. Pull y1 from the alt stack:

[0505] OP_FROMALTSTACK

[0506] 8. Repeat the following steps for i = 1, …, t:

[0507] ● Calculate r i = int[SHA256(SHA256(T / 2 i-1 ‖ g i ‖ y i ‖ μ i ))]:

[0508] OP_FROMALTSTACK OP_FROMALTSTACK OP_SWAP OP_DUP OP_2OP_DIV OP_TOALTSTACK OP_SWAP OP_2SWAP OP_ROT OP_SWAP OP_3DUP OP_TOALTSTACK OP_TOALTSTACK OP_TOALTSTACK OP_CAT OP_CAT OP_CAT OP_HASH256<0x00>OP_CAT

[0509] ● Calculate

[0510] OP_DUP OP_FROMALTSTACK OP_SWAP OP_3OP_PICK[ModExponentiate]OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_MUL OP_2OP_PICK OP_MOD

[0511] ● Calculate

[0512] OP_FROMALTSTACK OP_ROT OP_3OP_PICK[ModExponentiate]OP_FROMALTSTACKOP_MUL OP_2OP_PICK OP_MOD

[0513] 9. Check if

[0514] OP_SWAP OP_DUP OP_MUL OP_2OP_ROLL OP_MOD OP_NUMEQUALVERIFY OP_DROP

[0515] 10. Verify the puzzle solution S puz is correct:

[0516] [VerifyPuzzleSolution]

[0517] 11. Verify that the signature is a valid signature of the transaction and the public key Pk:

[0518] OP_CHECKSIG

[0519] The corresponding unlocking script is as follows:

[0520] Unlocking Script:

[0521]

[0522] That is, the locking script is configured to compute a series of first exponents g i and a series of second exponents y i , where 1 ≤ i ≤ t + 1. The first of the first exponents g1 is computed based on the public key and the puzzle solution. The first of the second exponents y1 is the result value provided in the unlocking script.

[0523] The first exponents g i and the second exponents y i each use the previous one in the first exponents g i-1 and the second exponents y i-1 and the corresponding previous proof value in the proof values μ i-1 to compute. That is, all previous values of both the first series of exponents and the second series of exponents are required to compute the next exponent in each series.

[0524] If the final second exponent y t+1 equals the square of the final first exponent g t+1 mod N, then the proof is verified.

[0525] The unlocking script is valid if the following conditions hold:

[0526] ● A proof π, which proves that where x = Pk‖S puz is a valid P-VDF proof.

[0527] ● The puzzle solution sol is correct (checked by VerifyPuzzleSolution).

[0528] ● The signature is a valid signature of the transaction and the public key Pk.

[0529] Figure 9 Schematically shows a method for verifying the unlocking script of the solution transaction 904.

[0530] The challenger 402 generates a challenge transaction (not shown) that has a locking script including a script for performing the following verification steps. The challenged party 404 generates a solution transaction 904 that has an unlocking script including a candidate puzzle solution S puz , a candidate proof π, and the public key Pk of the challenged party. The solution transaction 904 also includes a signature sig Pk derived from the public key Pk of the challenged party.

[0531] Run the locking script of the challenge transaction and the unlocking script of the unlocking transaction 904 together, so that steps A to G are executed in the script. The locking script may also include a time parameter T and a value N.

[0532] First, in step A, check the proof value μ i .

[0533] In step B, use the public key and the candidate puzzle solution to calculate the first first exponent g i . Then, in step C, use the inverse of the first first exponent provided in the unlocking transaction 904 to check the first first exponent.

[0534] In step D, use the equation listed in step 8 above to calculate each series of first exponents g i , the second exponent y i and the value r i .

[0535] In step E, compare the final second exponent y t+1 with the square of the final first exponent g t+1 to determine whether the challenge criteria are met.

[0536] In step F, verify the candidate puzzle solution for the puzzle defined by the challenger 402. The way to verify the candidate puzzle depends on the type of puzzle used. Those skilled in the art will understand the method of verifying the candidate puzzle solution.

[0537] Then, in step G, determine whether the signature of the unlocking transaction 804 is valid for the public key of the unlocking script.

[0538] If each check is found to be valid, determine that the locking script of the unlocking transaction 904 is valid and unlock the UTXO of the challenge transaction.

[0539] If it is assumed that the size of N is 256 bytes and the size of c is 1 byte, the scale overhead in the redemption transaction is 767 + 512×t bytes. As described below, for a 256-bit exponent, the size of [ModExponentiate] is 6921 bytes. If it is assumed that the size of N is 256 bytes, the scale overhead in the reward transaction is approximately 13904×t bytes. Since the difficulty of the P-VDF is exponentially related to the parameter t, the scale overhead in the reward transaction and the redemption transaction grows logarithmically with the difficulty.

[0540] Modular exponentiation within the script

[0541] Hereinafter, the part [ModExponentiate] that performs modular exponentiation in the script is described. The value x a mod n can be calculated using the square-and-multiply algorithm. The following assumptions are made:

[0542] ● Require the value of the power x such that 0 < x < n.

[0543] ● The magnitude of a is known.

[0544] ● The modulus n is strictly greater than 1.

[0545] To calculate x a mod n, iteratively calculate all squares and multiply the result res by the i-th square only when the i-th bit of a is set. Finally, output res = x a mod n.

[0546] Starting from x, a, n at the top of the stack, use the following opcodes to construct a script for calculating x a mod n, where a is represented using k bits:

[0547] 1. Initialize the result res to 1:

[0548] OP_ROT OP_ROT OP_1OP_ROT OP_ROT OP_DUP

[0549] 2. For i = 0 to k, add the opcodes:

[0550] OP_IF

[0551] OP_DUP OP_2OP_MOD / / Calculate a mod 2

[0552] OP_SWAP OP_2OP_DIV OP_TOALTSTACK / / Perform integer division of a by 2 and store the value in the alt stack

[0553] OP_IF / / If a mod 2 == 1

[0554] OP_DUP OP_ROT OP_MUL OP_2OP_PICK OP_MOD OP_SWAP

[0555] OP_ENDIF

[0556] OP_DUP OP_MUL OP_2OP_PICK OP_MOD

[0557] OP_FROMALTSTACK OP_DUP

[0558] OP_ELSE

[0559] OP_0

[0560] OP_ENDIF

[0561] 3. Finalize by clearing the stack:

[0562] OP_2DROP OP_DROP OP_NIP

[0563] Each iteration takes 27 bytes. For a k-bit exponent a, step 2 above takes 27×k bytes. By adding 6 bytes for initialization (step 1), and 3 bytes for clearing the stack (step 3), the total size of the script is 9 + 27×k bytes.

[0564] 6.6 Scheme Selection

[0565] The solution proposed in this paper ensures the security of the puzzle reward by requiring the user (the challenged party) to provide a computational proof (a proof) related to the solution of the puzzle and the public key for signing the redemption transaction. The computational proof ensures that a certain amount of time has passed since the solver found the solution to the puzzle, and is also necessary for malicious users who intercept the solution.

[0566] Three security levels can be defined to ensure the security of the puzzle reward. These security levels correspond to the amount of time required to generate the computational proof:

[0567] · Basic security – 10 seconds: This roughly corresponds to the time it takes for a transaction to propagate across the network. If a malicious user broadcasts an alternative redemption transaction, the transaction will be considered invalid because the first legitimate transaction has already been received by the nodes. However, this does not prevent malicious miners from rejecting the first legitimate redemption transaction and mining a block containing the alternative redemption transaction. In Bitcoin SV, such behavior will be detected by other miners through the double-spend prevention mechanism.

[0568] · Medium security – 10 minutes: This corresponds to the average time it takes for the network to mine a new block. This security level guarantees that if a legitimate redemption transaction is included in the next block, the only way for a malicious attacker to hijack the puzzle reward is to create a new branch containing the alternative redemption transaction. Again, the double-spend prevention mechanism in Bitcoin SV will allow miners to detect such behavior and signal the network.

[0569] · Maximum security – 70 minutes: After this time, the transaction will be included in a block, and on average six subsequent blocks will be appended to the blockchain after that block. This security level ensures that any attempt to steal the puzzle reward is highly likely to fail.

[0570] These durations depend on the number of users' hardware (in parallel computational proofs) or the hardware speed (in sequential computational proofs). Therefore, these security levels are relevant to the attackers who need to ensure the security of the puzzle reward.

[0571] For a scheme based on a provable parallel computation, it is difficult to define the parameters of the scheme corresponding to a specific security level because the evaluation time of the scheme can always be reduced by increasing the number of parallel hardware. In practice, it is assumed that the solver has access to modern GPU units. The hash rate of most currently available GPU units is lower than 1 GH / s. If an attacker has access to an application-specific integrated circuit (ASIC) machine that can compute at 10 TH / s (corresponding to the current state-of-the-art ASIC machine), the solver will have to spend at least 10,000 times longer than the time defined in the security level to compute the proof of computation.

[0572] For a scheme based on a provable sequential computation, there is a theoretical lower bound on the computational gap between the solver and the attacker based on physical hardware limitations. Some work has been done to design low-latency large integer modular squaring. These can be used to estimate the practical lower bound of the VDF evaluation time. Compared with modern CPU processors, the ASIC implementation can reduce the latency of evaluating the VDF on a 2048-bit input by about 200 times. This means that, to achieve a specific security level, the solver must spend 200 times longer evaluating the VDF.

[0573] The solver (the prover) can also outsource the generation of the proof of computation to an external server that has access to more powerful hardware. Since the input of the proof of computation does not contain the explicit solution to the puzzle (but only its hashed version), the server cannot learn any information about the solution and cannot reuse it to claim the puzzle reward on behalf of a legitimate solver.

[0574] The following table summarizes the characteristics of each scheme described in this paper. If the anti-parallel computation feature is not required, PoW should be chosen because it only incurs a constant small-scale overhead in the reward transaction and the redemption transaction. When the anti-parallel computation feature is required, CP-PoSW and P-VDF are preferred to achieve a high security level because the scale of the reward transaction and the redemption transaction grows logarithmically with the evaluation time. However, when minimizing the scale overhead in the redemption transaction, the Sloth scheme is a good choice.

[0575]

[0576] Each scheme based on sequential computational proofs was evaluated, and the corresponding reward transactions and redemption transactions were generated. These evaluations were performed on a Linux machine with 32GB of RAM and a CPU running at 1.7GHz. The following table shows the size overheads generated by the schemes for multiple evaluations corresponding to different security levels. It should be noted that in practice, these schemes will run on more powerful machines, and thus the scripts will be larger. As can be seen from the table, the Sloth scheme is only meaningful for low security levels and where the size overhead in the redemption transaction should be minimal. However, higher security levels cause significant overhead in the reward transaction. On the other hand, the size overheads in the CP-PoSW and P-VDF schemes grow slowly (actually logarithmically) with the evaluation time. The difference between the two is that, compared to the CP-PoSW scheme, the P-VDF scheme causes less overhead in the redemption transaction but, on the contrary, higher overhead in the reward transaction. Additionally, it is also worth noting that in the CP-PoSW scheme, the size overheads in the reward transaction and the redemption transaction are more balanced.

[0577]

[0578] 7. Further Comments

[0579] Once the disclosure of this paper is given, other variations or use cases of the disclosed technology may become obvious to those skilled in the art. The scope of this disclosure is not limited by the described embodiments, but only by the appended claims.

[0580] For example, some of the above embodiments have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of the blockchain 150, and the above description can generally be applied to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any reference above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 can be replaced by reference to the blockchain network 106, the blockchain 150, and the blockchain node 104, respectively. The blockchain, blockchain network, and / or blockchain node may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104 as described above.

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

[0582] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some of the functions of creating, publishing, propagating, and storing the blocks 151 of the blockchain 150 but not all of them. 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 the blocks 151 but does not store and / or propagate these blocks 151 to other nodes.

[0583] Even more generally, any reference above to the term "Bitcoin node" 104 can be replaced with the term "network entity" or "network element", where such an entity / element is configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functions of such a network entity / element can be implemented in hardware in the same manner as described above with reference to the blockchain node 104.

[0584] Some embodiments have been described in terms of a blockchain network that is used to implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and any type of suitable consensus mechanism can be used in general embodiments, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-past-time. As a specific example, proof-of-stake uses a randomization process to determine which blockchain node 104 has the opportunity to produce the next block 151. The selected node is typically referred to as a verifier. A blockchain node can lock its tokens for a period of time in order to have the opportunity to become a verifier. Generally, the node that locks the largest stake for the longest time is most likely to become the next verifier.

[0585] It should be understood that the above embodiments are described only by way of example. More generally, a method, apparatus, or program can be provided according to any one or more of the following statements.

[0586] Statement 1. A computer-implemented method for generating a challenge blockchain transaction, wherein the challenge blockchain transaction is associated with a puzzle and a proof standard, wherein the puzzle is satisfied by a puzzle solution, and wherein the proof standard is satisfied by a proof, the method comprising:

[0587] Generate a first locking script for the challenge blockchain transaction that, when executed with a first unlocking script of a solution blockchain transaction including a candidate puzzle solution, a public key, a candidate proof, and a signature generated for the solution blockchain transaction, is configured to:

[0588] Verify whether the candidate puzzle solution satisfies the puzzle;

[0589] Verify whether the signature is valid for the public key; and,

[0590] Verify whether the candidate proof satisfies the proof criterion, where the proof criterion requires that the candidate proof be derived from the candidate puzzle solution and the public key; and,

[0591] Provide the challenge blockchain transaction to one or more nodes of a blockchain network.

[0592] Statement 2. The method according to statement 1, wherein the proof criterion defines a threshold, and wherein the satisfaction of the proof criterion is satisfied if the candidate target value is less than or equal to the threshold.

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

[0594] Statement 4. The method according to statement 2, wherein the candidate proof includes a sequence of candidate proof values, and wherein when executed with the first unlocking script, the first locking script is further configured to calculate a corresponding sequence of candidate target values by:

[0595] 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,

[0596] At least one subsequent candidate target value, where each subsequent candidate target value is calculated based on a corresponding one of the candidate proof values and the immediately preceding candidate target value in the sequence of candidate target values.

[0597] Statement 5. The method according to statement 4, wherein the satisfaction of the proof criterion is satisfied if each candidate target value in the candidate target values is less than or equal to the threshold.

[0598] Statement 6. The method according to statement 1, wherein the candidate proof is defined by a reversible function and calculated based on a series of square root calculations, wherein the first locking script is further configured to calculate a candidate target value, and the candidate target value is the inverse of the reversible function.

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

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

[0601] Statement 9. The method according to statement 1, wherein the candidate proof includes a sequence of proof values and a result value, and the result value is calculated based on a sequence of squaring operations, and the first locking script is further configured to:

[0602] calculate a series of first exponentials; and,

[0603] calculate a series of second exponentials;

[0604] wherein the first first exponential in the series of first exponentials is calculated based on the candidate puzzle solution and the public key;

[0605] wherein the first second exponential in the series of second exponentials is equal to the result value;

[0606] wherein each subsequent first exponential in the series of first exponentials is calculated based on the corresponding previous proof value in the sequence of proof values, the corresponding previous first exponential in the series of first exponentials, and the corresponding previous second exponential in the series of second exponentials; and,

[0607] wherein each subsequent second exponential in the series of second exponentials is calculated based on the corresponding previous proof value in the sequence of proof values, the corresponding previous first exponential in the series of first exponentials, and the corresponding previous second exponential in the series of second exponentials.

[0608] Statement 10. The method according to statement 9, wherein, 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, the proof criterion is satisfied.

[0609] Statement 11. 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, wherein the challenge blockchain transaction is associated with a puzzle and a proof criterion, wherein the puzzle is satisfied by a puzzle solution, and wherein the proof criterion is satisfied by a proof, the method comprising:

[0610] Generating the first unlocking script, wherein the first unlocking script comprises:

[0611] A candidate puzzle solution for satisfying the puzzle;

[0612] A signature of the solution blockchain transaction;

[0613] A public key for generating the signature; and,

[0614] A candidate proof, wherein the candidate proof is derived from the candidate puzzle solution and the public key; and,

[0615] Providing the solution blockchain transaction to one or more nodes of a blockchain network.

[0616] Statement 12. The method according to statement 11, wherein the proof criterion defines a threshold, wherein if a candidate target value is less than or equal to the threshold, the proof criterion is satisfied; wherein the method further comprises: determining that the candidate proof, when used to derive the candidate target value, satisfies the proof criterion.

[0617] Statement 13. The method according to statement 12, wherein the candidate target value is derived based on the candidate proof, the candidate puzzle solution, and the public key.

[0618] Statement 14. The method according to statement 11, wherein the proof criterion defines a threshold, wherein the candidate proof comprises a sequence of candidate proof values, wherein if each candidate target value in the sequence of candidate target values is less than or equal to the threshold, the proof criterion is satisfied, wherein the sequence of candidate target values comprises:

[0619] A first candidate target value, the first candidate target value being calculated based on the public key, the candidate puzzle solution, and a first candidate proof value in the sequence of candidate proof values; and,

[0620] At least one subsequent candidate target value, where each subsequent candidate target value is calculated based on a corresponding one of the candidate proof values and the immediately preceding candidate target value in the candidate target value sequence.

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

[0622] Statement 16. The method according to statement 15, wherein the candidate proof is defined by a reversible function of the intermediate variable, and the candidate proof is generated by calculating a series of square root calculations.

[0623] Statement 17. The method according to statement 15, wherein the proof criterion corresponds to a directed acyclic graph, and the method further includes: generating a candidate directed acyclic graph based on the intermediate value derived from the public key and the puzzle solution, wherein the candidate proof includes a commitment and a set of disclosure information, and the set of disclosure information corresponds to the candidate directed acyclic graph.

[0624] Statement 18. The method according to statement 15, wherein the candidate proof includes a sequence of proof values and a result value, and the result value is calculated based on the intermediate value and by calculating a sequence of square operations, and each proof value in the sequence of proof values is calculated based on a hash of the intermediate value.

[0625] Statement 19. A computer device, the computer device includes:

[0626] A memory, the memory includes one or more memory units; and,

[0627] A processing device, the processing device includes one or more processing units, wherein the memory stores code configured to run on the processing device, and the code is configured to, when running on the processing device, execute the method according to any one of statements 1 to 18.

[0628] Statement 20. A computer program, the computer program is included on a computer-readable memory and is configured to, when running on one or more processors, execute the method according to any one of statements 1 to 18.< / t> < / n> < / pk> < / sol> < / pk> ​< / pk> < / w> < / pk> < / pk> < / nonce> < / pk> < / m> < / m> < / pa>

Claims

1. A computer-implemented method for generating a challenge blockchain transaction, where the challenge blockchain transaction is associated with a puzzle and a proof standard, where the puzzle is satisfied by a puzzle solution, and where the proof standard is satisfied by a proof, the method comprising: Generating a first locking script for the challenge blockchain transaction, which when executed together with a first unlocking script of a solution blockchain transaction including a candidate puzzle solution, a public key, a candidate proof, and a signature generated for the solution blockchain transaction, is configured to: Verify whether the candidate puzzle solution satisfies the puzzle; Verify whether the signature is valid for the public key; and Verify whether the candidate proof satisfies the proof standard, where the proof standard requires that the candidate proof is derived from the candidate puzzle solution and the public key; And Providing the challenge blockchain transaction to one or more nodes of a blockchain network.

2. The method according to claim 1, wherein, The proof standard defines a threshold, where if the candidate target value is less than or equal to the threshold, the proof standard is satisfied.

3. The method according to claim 2, wherein, When executed together with the first unlocking script, the first locking script is further configured to: calculate the candidate target value based on the public key, the candidate puzzle solution, and the candidate proof.

4. The method according to claim 2, wherein, The candidate proof includes a sequence of candidate proof values, where when executed together with the first unlocking script, the first locking script is further configured to calculate a corresponding sequence of candidate target values by: 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, where each subsequent candidate target value is calculated based on a corresponding candidate proof value in the candidate proof values and the immediately preceding candidate target value in the sequence of candidate target values.

5. The method according to claim 4, wherein, If each candidate target value in the candidate target values is less than or equal to the threshold, the proof standard is satisfied.

6. The method according to claim 1, wherein, The candidate proof is defined by a reversible function and calculated based on a series of square root calculations, where the first locking script is further configured to calculate the candidate target value, where the candidate target value is the inverse of the reversible function.

7. The method according to claim 6, wherein, The candidate proof is calculated based on an intermediate variable, where the intermediate variable can be derived from the public key and the candidate puzzle solution, where the first locking script is further configured to calculate the intermediate variable based on the public key and the candidate puzzle solution of the first unlocking script, where if the candidate target value is equal to the calculated intermediate variable, the proof standard is satisfied.

8. The method according to claim 1, wherein The proof standard corresponds to a directed acyclic graph, where the candidate proof includes a set of disclosure information and commitments, where the first locking script is further configured to verify whether the candidate proof of the first unlocking script is valid for the directed acyclic graph.

9. The method according to claim 1, wherein The candidate proof includes a sequence of proof values and a result value, where the result value is calculated based on a sequence of squaring operations, where the first locking script is further configured to: Calculate a series of first exponents; and Calculate a series of second exponents; The first 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 the corresponding previous proof value in the sequence of proof values, the corresponding previous first exponent in the series of first exponents, and the corresponding previous second exponent in the series of second exponents; and Each subsequent exponent in the series of second exponents is calculated based on the corresponding previous proof value in the sequence of proof values, the corresponding previous first exponent in the series of first exponents, and the corresponding previous second exponent in the series of second exponents.

10. The method according to claim 9, wherein, 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, the proof criterion is satisfied.

11. 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, wherein the challenge blockchain transaction is associated with a puzzle and a proof criterion, wherein the puzzle is satisfied by a puzzle solution, and wherein the proof criterion is satisfied by a proof, the method comprising: Generating the first unlocking script, wherein the first unlocking script comprises: A candidate puzzle solution for satisfying the puzzle; A signature of the solution blockchain transaction; A public key for generating the signature; and A candidate proof, wherein the candidate proof is derived from the candidate puzzle solution and the public key; and Providing the solution blockchain transaction to one or more nodes of a blockchain network.

12. The method according to claim 11, wherein, The proof criterion defines a threshold, wherein if a candidate target value is less than or equal to the threshold, the proof criterion is satisfied; Wherein the method further comprises: determining the candidate proof, which, when used to derive the candidate target value, satisfies the proof criterion.

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

14. The method according to claim 11, wherein, The proof criterion defines a threshold, wherein the candidate proof comprises a sequence of candidate proof values, wherein if each candidate target value in the sequence of candidate target values is less than or equal to the threshold, the proof criterion is satisfied, wherein the sequence of candidate target values comprises: A first candidate target value, which is calculated based on the public key, the candidate puzzle solution, and the first candidate proof value in the sequence of candidate proof values; and At least one subsequent candidate target value, wherein each subsequent candidate target value is calculated based on the corresponding one candidate proof value in the candidate proof values and the immediately previous candidate target value in the sequence of candidate target values.

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

16. The method according to claim 15, wherein, The candidate proof is defined by an invertible function of the intermediate variable, wherein the candidate proof is generated by a series of square root calculations.

17. The method according to claim 15, wherein, The proof standard corresponds to a directed acyclic graph, and the method further includes: generating a candidate directed acyclic graph based on the intermediate value derived from the public key and the puzzle solution, wherein the candidate proof includes a commitment and a set of disclosure information, and the set of disclosure information corresponds to the candidate directed acyclic graph.

18. The method according to claim 15, wherein, The candidate proof includes a sequence of proof values and a result value, wherein the result value is calculated based on the intermediate value and 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.

19. A computer device, the computer device comprising: a memory including one or more memory units; and a processing device including one or more processing units, wherein the memory stores code configured to run on the processing device, and the code is configured to, when running on the processing device, execute the method according to any one of claims 1 to 18.

20. A computer program embodied on a computer-readable memory and configured to, when run on one or more processors, execute the method according to any one of claims 1 to 18.

Images