Hash-based verification method and apparatus

Abstract

A computer-implemented method, the method comprising, at a validator node in a blockchain network: acquiring a first transaction, the first transaction including executable code; receiving a second transaction, the second transaction containing information including at least a commit instance of the r portion and the s portion of a first ECDSA signature, and the information further including a random number; and executing the code of the first transaction. The code is configured to verify H. PoW If (f(r, d)) satisfies the predetermined conditions defined in the code, return TRUE if the predetermined conditions defined in the code are met, where r is the submission instance of the r part, d is the random number, and H PoW q is a hash function, and f is a function that combines q and d.

Description

Technical Field

[0001] This disclosure relates to the idea of ​​implementing knowledge proofs in a blockchain context. Background Technology

[0002] A blockchain is a form of distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain consists of a series of data blocks, where each block contains one or more transactions. Each transaction can refer back to previous transactions in the sequence. Transactions can be included in a new block by submitting them to the network. The process of creating a new block is called "mining," which involves solving cryptographic puzzles based on a pool of pending transactions waiting to be included in the block.

[0003] Transactions in blockchains are typically used to transfer digital assets, i.e., data used as a store of value. However, blockchains can also be used to implement layered, additional functionalities. For example, blockchain protocols can allow additional user data to be stored in transaction outputs. Modern blockchains are constantly increasing the maximum data capacity that can be stored in a single transaction, enabling the incorporation of more complex data. This can be used, for example, to store electronic documents, or even audio or video data, within the blockchain.

[0004] Each node in the network can have any one, two, or all of the following three roles: forwarding, mining, and storing. Forwarding nodes propagate transactions throughout the network. Mining nodes mine transactions into blocks. Storing nodes each store their own copy of the mined blocks in the blockchain. To record a transaction in the blockchain, one party sends the transaction to one of the nodes in the network for propagation. Mining nodes receiving the transaction can compete to mine it into a new block. Each node is configured to adhere to the same node protocol, which will include one or more conditions for confirming the validity of a transaction. Invalid transactions will not be propagated or mined into blocks. Assuming a transaction has been verified as valid and thus accepted on the blockchain, the transaction (including any user data) will therefore continue to be stored as an immutable public record at various nodes in the P2P network.

[0005] In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element specifying the amount of digital assets, sometimes referred to as a UTXO ("unspent transaction output"). This output may also include a locking script specifying the conditions used to redeem the output. Each input includes a pointer to such an output in a previous transaction and may also include an unlocking script used to unlock the locking script pointing to the output. Therefore, consider a pair of transactions, referred to as transaction first and transaction second. Transaction first includes at least one output specifying the amount of digital assets and includes a locking script defining one or more conditions for unlocking that output. Transaction second includes at least one input and an unlocking script, the at least one input including a pointer to an output of transaction first; this unlocking script is used to unlock the output of transaction first.

[0006] In this type of model, when a second transaction is sent to the P2P network for propagation and recording in the blockchain, one of the validity conditions applied at each node will be: the unlocking script satisfies all of the conditions defined in one or more of the locking scripts of the first transaction. Another condition will be: the output of the first transaction has not yet been redeemed by another earlier valid transaction. Any node that finds the second transaction invalid based on any of these conditions will not propagate the transaction, nor will it include it in the block to be recorded in the blockchain.

[0007] Another transaction model is the account-based model. In this case, the amount transferred in each transaction is not defined by referencing the UTXO of previous transactions in a past transaction sequence, but rather by referencing the absolute account balance. The current state of all accounts is stored separately in the blockchain and is continuously updated. Account-based transaction models can also include smart contracts that run on each node and simultaneously verify the validity of the transaction.

[0008] In either model, transactions can include knowledge proofs. "Knowledge proof" is a technical term referring to any test that one party knows certain pieces of data, such as d. Taking an output-based transaction model as an example, the locking script in the output of a transaction Tx1 can include a hash puzzle. If the input of a second transaction Tx2 points to that output of Tx1, then the unlocking script in that input of Tx2 must solve the hash puzzle in order to successfully redeem the output of Tx1. The hash puzzle includes a hash value h, which is the hash value of d, i.e., h = H. puz (d). The puzzle also includes a script that, when run at the node along with the unlock script of Tx2, retrieves the data value d', which is claimed to be d, from the unlock script of Tx2, and hashes it using the hash function H. puzThe data value is hashed and compared with the hash value h included in the locking script of Tx1. That is, if the comparison result is "YES" (or "TRUE" in art terms), then it is checked whether h = H. puz (d′), and will only unlock the output of Tx1. Therefore, if d is included in the unlocking script of Tx2 to prove knowledge of d, then the beneficiary of Tx2 can only unlock the output of Tx1.

[0009] The problem with using traditional hashing problems alone is that unscrupulous nodes can observe d in the Tx2 unlocking script and then create and mine (or publish) their own Tx2. Version, in Instead of paying to the intended recipient (e.g., Bob) in Tx2, the output of Tx1 is used to pay itself. An existing method to avoid this is to additionally include a "pay to public key hash" (P2PKH) requirement in the locking script of Tx1. This requires, in addition to the proof of knowledge of d, that the intended recipient's cryptographic signature be included in the unlocking script of Tx2.

[0010] Hash puzzles and P2PKH can also be implemented using smart contracts in an account-based model, instead of using lock and unlock scripts in an output-based model.

[0011] As is well known to those skilled in the art, a cryptographic signature can be generated based on a private key V and verified based on the corresponding public key P in a private-public key pair. Given a signature generated by applying the private key V to a message m, another party can use P to verify that the signature was generated using V without knowing V (therefore, verifying the signature itself is another form of proof of knowledge).

[0012] One algorithm used in this case is the Elliptic Curve Digital Signature Algorithm (ECDSA), which performs operations based on the Elliptic Curve Cryptography (ECC) algorithm. In this case, the relationship between P and V is as follows:

[0013] P = V·G

[0014] Where P is a binary vector (P x ,P y V is a scalar, and G is a binary vector (G0). x G y The binary vector represents a predetermined point (“generated point”) on a two-dimensional elliptic curve. The operation “·” is scalar elliptic curve multiplication—a known form of operation that transforms a point on an elliptic curve to another.

[0015] An ECDSA signature is a tuple (r, s) consisting of two elements known in the art: the r part (r) and the s part (s). The signature (r, s) is generated by applying a private key V to a message m. When a transaction is recorded in a blockchain, m will be part of the transaction, and in addition to this part in plaintext, the signature will also be attached to the transaction to verify its validity. For example, in an output-based model, the signature signs a portion of Tx2 and is included in the locking script of Tx2 to unlock the output of Tx1. The signature portion typically includes the output of the transaction, so these outputs cannot be altered without verifying the signature's invalidity and therefore the transaction's invalidity.

[0016] Regardless of the transaction model used, the signature (r,s) is calculated as follows:

[0017] r = [R] x Where R = k·G

[0018] s = k -1 (H sig (m)+rV)mod n

[0019] Among them, [R] x Represents a binary vector R = (R x ,R y H is the x-coordinate of the set [1, n-1]. k is called the temporary key, usually randomly chosen from the set [1, n-1], where n is the prime modulus and [1, n-1] is the set of real numbers ranging from 1 to n-1 (inclusive). sig It is a hash function, the same as the hash function H used in the hash puzzle. puz In contrast, the hash function can be the same or a different form of hash function.

[0020] Given a signature (r,s), a message m, and a public key P, any party that does not know the private key V can verify that the signature was generated using the private key V of message m. This can be achieved by calculating:

[0021] R′=H sig (m)s -1 ·G+rs -1 ·P

[0022] And verify [R'] x =r. The signature is only valid if the result is TRUE; otherwise, it is invalid. This can be viewed as verification that the party associated with the public key P is indeed the signer of the message. Summary of the Invention

[0023] In a blockchain network, the proof required to mine a transaction into a block is an inherent feature of the node protocol applied by each mining node in the network. However, this paper recognizes that it may be necessary to add an additional "layer 2" proof (i.e., placed on top of the basic node protocol). In particular, according to this disclosure, this can be achieved by setting a challenge in Tx1 based on the r part of the ECDSA signature, which is a variant of a puzzle type referred to herein as the "r puzzle".

[0024] According to one aspect disclosed herein, a computer-implemented method is provided, the method comprising, at a validator node of a blockchain network: obtaining a first transaction, the first transaction including executable code; receiving a second transaction, the second transaction containing information including at least a commit instance of the r portion and the s portion of a first ECDSA signature, and the information further including a random number; and executing the code of the first transaction. The code is configured to verify H. PoW If (f(r,d)) satisfies the predetermined conditions defined in the code, return TRUE if the predetermined conditions are met, where r is the submission instance of the r part, d is the random number, and H... PoW is a hash function, and f is a function that combines r and d.

[0025] In an alternative embodiment, the r-challenge set in the code of the first transaction may further include a challenge requiring the second transaction to include a specified value of the r-part. Therefore, the r-challenge can be used to implement a knowledge proof based on the r-part of the signature.

[0026] When combined with P2PKH to avoid the potential vulnerabilities discussed in the background art, using a hash puzzle as a proof of knowledge presents a problem: a node could see d and exchange it for a new version of the second transaction, paying the node operator instead of the prover. While P2PKH ensures payment is only made to the party that first knew d, this also means that the output of Tx1 is associated with a specific predetermined receiver or set of receivers (alternative conditions that may include alternative receivers can be specified, but they must still be pre-identified).

[0027] As recognized in this paper, it may be desirable to allow transactions redeemable by any unspecified party who can prove knowledge of a particular secret value, but avoid revealing the way that value is disclosed. For example, suppose Alice wants to establish a first transaction that can be unlocked by anyone she provides with the key, but she doesn't want to pre-specify the identities of these parties. For example, the first transaction could pay someone to accept the delivery of items such as letters or packages on Alice's behalf; and / or pay a courier company to deliver the items. The first transaction can be redeemed by a second transaction that proves knowledge of the secret. When placing a delivery order, Alice can establish the first transaction and provide it to the courier company or publish it to the blockchain (or simply provide the necessary details, such as enabling the courier company to create the first transaction). Thus, the courier company is confident in paying upon completion of the delivery. However, Alice doesn't want to decide at this stage who will receive the delivered items on her behalf. Instead, she only provides the secret value later to one or more trusted parties (e.g., her roommates Charlie and / or Bob, who have now confirmed they will be present on the day of delivery). This would allow either of them to sign on her behalf by providing a second transaction that proves Alice's secret value.

[0028] It should be understood that this is merely an illustrative example. Another example is that agreement to the terms of an agreement can be expressed through a transaction. Alice might want to enter into an agreement immediately, but only after the fact can she decide on one or more trusted parties to authorize or delegate a power of attorney to sign on her behalf. For example, Alice might have intended to sign the agreement herself at the time of its formation, but later discover that she is losing her mental capacity or is unable to sign for some reason, thus needing to transfer the power of attorney to someone else (e.g., in this case, Bob and Charlie might be her family members or business partners).

[0029] In simpler terms, while not essential to the main idea of ​​proof, the aim is to provide an alternative to the traditional hashing problem. Specifically, this alternative could enable proof-of-knowledge of a secret value without revealing it to nodes or publishing it on the blockchain, and the value should be independent of any particular identity.

[0030] To address this problem, according to an alternative embodiment disclosed herein, the method may include: obtaining a public key, wherein a first ECDSA signature is used to sign a message, which is part of a second transaction, based on a private key corresponding to the public key; applying an ECDSA verification function to verify the first ECDSA signature received in the second transaction based on the public key and the message, wherein code is configured to return the TRUE result under a further condition of the verification of the first ECDSA signature. The code may further include a reference value corresponding to the r-part of the first ECDSA signature, the reference value being a reference instance of the r-part or a transformation thereof. In this case, the code is configured to check whether the reference value corresponds to the reference instance of the r-part received in the second transaction, and return the TRUE value under a further condition that the reference value corresponds to the reference instance of the r-part received in the second transaction.

[0031] The identifier of the r portion included in the code of the first transaction may be the reference instance of the r portion or its transformation, such as the hash value of the component including the r portion (where, for example, the hashed component may be exactly equivalent to the portion itself, or may be concatenated with another data element d).

[0032] Therefore, regardless of the method, the code establishes the "r-problem," which requires the challenged party (e.g., Bob) to already know the temporary key k (providing the solution without knowing k is infeasible). This problem advantageously uses the r-part as the basis for this knowledge proof and does not require the challenged party to submit the temporary key k to the node, nor does it require revealing the temporary key in the second transaction (e.g., Tx2). This means, for example, that k can be used by the first party (e.g., Alice) as a temporary private key or secret that she can use to transfer signer authorization to one or more second parties such as Bob and / or Charlie. Because the r-problem proves knowledge of k without revealing it, a malicious node cannot create his / her own signature to form a valid second transaction that would pay him / her instead of the intended beneficiary. Furthermore, since the 'r' part of the signature itself is independent of any identity in the system, this means that anyone who knows 'k' can satisfy the proof requirement. The validity of the second transaction does not necessarily have to be associated with a specific identity through the first transaction. Therefore, for example, Alice does not need to decide beforehand who to lock the first transaction to. For instance, she could provide the courier company with the details of establishing the first transaction and then decide who to authorize to sign on her behalf to receive the package.

[0033] In light of the foregoing, and more generally, the scope of this disclosure can be extended to any “layer 2” proof, whereby code in a transaction is used to place additional proof puzzles on top of inherent proofs already executed in the blockchain.

[0034] Therefore, according to another aspect disclosed herein, a computer-implemented method is provided, the method comprising, at a verification node of a blockchain network: acquiring a first transaction, the first transaction including executable code; receiving a second transaction, the second transaction containing information, the information including at least a first portion and a random number; and executing the code of the first transaction, the code being configured to verify H. PoW If (f(q,d)) satisfies the predetermined conditions defined in the code, return TRUE if the predetermined conditions are met, where q is the first part, d is the random number, and H... PoW is a hash function, and f is a function that combines r and d. Attached Figure Description

[0035] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which:

[0036] Figure 1 This is a schematic block diagram of a system for implementing blockchain.

[0037] Figure 2 The illustration shows some examples of transactions that can be recorded in the blockchain;

[0038] Figure 3 Another schematic block diagram of a system for implementing blockchain;

[0039] Figure 4 A schematic block diagram of node software for processing transactions according to a node protocol based on an output-based model is shown.

[0040] Figure 5 An exemplary set of transactions is illustrated schematically;

[0041] Figures 6A to 6D This illustration illustrates some of the principles behind the Elliptic Curve Digital Signature Algorithm (ECDSA).

[0042] Figure 7 This is a schematic diagram of a possible implementation of a knowledge proof, referred to in this paper as the r-problem (or synonymously, the r-challenge);

[0043] Figure 8 This is a schematic diagram of another possible implementation of the r-problem;

[0044] Figure 9This is a schematic diagram of another possible implementation of the r-problem;

[0045] Figure 10 This is a schematic diagram of another possible implementation of the r-problem;

[0046] Figure 11 This is a schematic block diagram of node software used to process transactions according to a node protocol based on an account-based model.

[0047] Figure 12 An exemplary format for an ECDSA signature is illustrated schematically;

[0048] Figure 13 This is a step-by-step script analysis of an exemplary implementation of a locking script and an unlocking script for a form of r-problem;

[0049] Figures 14A to 14D Examples of an r-problem are illustrated, which imposes additional proofs on top of already completed intrinsic proofs as part of the underlying blockchain protocol. Detailed Implementation

[0050] In some cryptographic schemes, a verifier may need to be convinced that someone (called the prover or the challenged) possesses some information in a so-called proof of knowledge. This can be achieved simply by providing the information directly to the verifier. Alternatively, the prover may need to perform a computation dependent on that information. Preferably, the computation involved is such that the verifier can set the challenge without knowing the information themselves, and can verify that the prover knows the information without revealing it to the verifier. For computational methods, a verification computation must be performed on the input data. Because cryptographic hash functions possess anti-image and collision-resistant properties, a straightforward way to prove knowledge of a secret value is to use a cryptographic hash function. This hashing method can be easily integrated into many blockchain applications because hash functions can form a fundamental part of their private-key-public-key cryptosystems. This type of proof of knowledge is widely used in blockchain applications and is often referred to as a hash puzzle.

[0051] In UTXO-based blockchains, the solution to a hash puzzle (the preimage of a hashed value) can be set as a spending condition, thus performing verification as part of transaction verification. However, in this approach, the transaction must also require a signature using a specific private key, or else receive the hash puzzle solution before being included in the block. This allows malicious nodes to create spending transactions whose output points to an address belonging to that node.

[0052] This disclosure provides a proof of knowledge that circumvents this problem while still allowing verification to be performed by forwarding nodes. To this end, the proof of knowledge is associated with a temporary key corresponding to an Elliptic Curve Digital Signature Algorithm (ECDSA) signature. Since the cryptographic primitives used in this algorithm are native to many blockchains, they can be easily integrated into current infrastructure.

[0053] Exemplary System Overview

[0054] Figure 1 An exemplary system 100 for implementing blockchain 150 is shown. System 100 includes a packet-switched network 101, typically a wide area network such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer computer device, and different nodes 104 belong to different peers. Each node 104 includes a processing device containing one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). Each node also includes memory, i.e., computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memory (EEPROMs), and / or optical media such as optical disc drives.

[0055] Blockchain 150 comprises a series of data blocks 151, with a corresponding copy of blockchain 150 maintained at each of the multiple nodes in the P2P network 160. Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain typically uses a specific transaction protocol throughout. 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 an amount representing the value of digital assets belonging to user 103 whose output is cryptographically locked (requiring the user's signature to unlock, thereby enabling redemption or spending). Each input points to the output of a previous transaction 152, thus linking these transactions.

[0056] At least some of the nodes in node 104 act as forwarding nodes 104F, forwarding and thus propagating transaction 152. At least some of the nodes in node 104 act as storage nodes 104S (sometimes also called "full copy" nodes), each storage node storing a corresponding copy of the same blockchain 150 in its respective storage. A given node 104 can be forwarding node 104, storage node 104S, or any combination of these nodes.

[0057] In a given current transaction 152j, the inputs (or each input) include 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. Typically, the current transaction can be any transaction in pool 154 or any block 151. While the existence and verification of the previous transaction 152i are required to ensure the validity of the current transaction, the previous transaction 152i does not necessarily exist when the current transaction 152j is created or even sent to network 106. Therefore, in this context, "previous" refers to the predecessor in the logical sequence linked by the pointer, not necessarily the creation or sending time in the time series, thus not necessarily excluding the possibility of out-of-order creation or sending of transactions 152i or 152j (see the discussion of orphaned transactions below). The previous transaction 152i can also be referred to as the preceding transaction or predecessor transaction.

[0058] The input to the current transaction 152j also includes the signature of user 103a to whom 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 103b. Therefore, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs to split the input amount among multiple users (one of which can be the original user 103a for modification). In some cases, the transaction may also have multiple inputs to aggregate the amounts from multiple outputs of one or more previous transactions and redistribute them to one or more outputs of the current transaction.

[0059] The above can be referred to as an "output-based" transaction protocol, or sometimes as a protocol for unspent transaction outputs (UTXOs) (where the output is called a UTXO). A user's total balance is not defined by any single number stored in the blockchain; instead, the user needs a special "wallet" application 105 to organize all of the user's UTXO values, which are scattered across many different transactions 152 on the blockchain 151.

[0060] As part of the account-based transaction model, another type of transaction protocol can be called an "account-based" protocol. In the account-based case, each transaction's amount is not defined by referencing the UTXO of previous transactions in a past transaction sequence, but rather by referencing the absolute account balance. The current state of all accounts is stored separately in the blockchain and is continuously updated. In such systems, transactions are ordered using the account's running transaction history (also known as "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Furthermore, optional data fields can also be used to sign transactions. For example, if a data field contains the ID of a previous transaction, that data field can point to that previous transaction.

[0061] Regardless of the type of transaction protocol used, when user 103 wishes to execute a new transaction 152j, they wish to send the new transaction from their computer terminal 102 to one of the nodes 104 of the P2P network 106 (currently typically a server or data center, but in principle it could be another user terminal). This node 104 checks the validity of the transaction according to the node protocol applied at each node in the node 104. The details of the node protocol will correspond to the type of transaction protocol used in the relevant blockchain 150, together forming the entire transaction model. The node protocol typically requires node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, depending on the previous transaction 152i in the ordered sequence of transactions 152. In the case of output-based transactions, this may include checking whether the user's cryptographic signature contained in the input of the new transaction 152j matches the condition defined in the output of the previous transaction 152i that the new transaction spends, where the condition typically includes at least checking whether the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction points. In some transaction protocols, conditions may be defined, at least in part, by custom scripts included in the inputs and / or outputs. Alternatively, this may be determined solely by the node protocol, or through a combination thereof. Regardless of the approach, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, thereby forwarding the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction propagates throughout the network of nodes 104.

[0062] In the output-based model, whether a given output (e.g., a UTXO) is spent is defined as whether it has been validly redeemed by the input of another subsequent transaction 152j, according to the node protocol. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it attempted to spend or redeem has not yet been spent / redeemed by another valid transaction. Similarly, if invalid, transaction 152j will not be propagated or recorded in the blockchain. This prevents double-spending, i.e., a spender spending the output of the same transaction more than once. On the other hand, the account-based model prevents double-spending by maintaining an account balance. Because a defined transaction order also exists, the account balance has a single defined state at any given time.

[0063] Node 104M, having solved the puzzle, announces its solution on network 106, providing proof of the solution. Other nodes 104 in the network can then easily check the solution (once a solution with a hash value is provided, it can be directly checked whether the solution makes the output of the hash value satisfy the condition). Based on the winner's announced solution being checked at each of these nodes, the winner's pool of transactions 154 that solved the puzzle is subsequently recorded in blockchain 150 as a new block 151 by at least some of the nodes 104 acting as storage nodes 104S. Block pointer 155 is also assigned to a new block 151n pointing to the previously created block 151n-1 in the blockchain. Once created, block 151 is immutable because it is identified and maintained by each storage node 104S in the P2P network 106 according to the same protocol. Block pointer 155 also imposes ordering on block 151. Since transaction 152 is recorded in ordered blocks at each storage node 104S in the P2P network 106, an immutable public ledger of transactions is provided.

[0064] It should be noted that different nodes 104M vying to solve the puzzle at any given time may perform this operation based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they begin searching for a solution. The person solving the corresponding puzzle first defines the transactions 152 contained in the new block 151n and updates the current unmined transaction pool 154. Then, nodes 104M continue to compete to create blocks from the newly defined unmined pool 154, and so on. Furthermore, there are protocols for resolving any potential "forks," where two nodes 104M solve the puzzle for each other in a very short time, thus propagating a conflicted view of the blockchain. In short, the fork with the longest possible direction becomes the final blockchain 150.

[0065] Each forwarding node 104M and / or storage node 104S can also take the form of a server or a data center. However, in principle, any given node 104 can take the form of a single user terminal or a group of user terminals networked together.

[0066] Each node 104's memory stores software 400 configured to run on the processing device of node 104 to perform its corresponding role and process transactions 152 according to the node protocol. It should be understood that any action attributed herein to node 104 can be performed by the software 400 running on the processing device of the corresponding computer device. The node software 400 may be implemented in one or more applications at the application layer, or in lower layers such as the operating system layer or protocol layer, or in any combination of these layers. Furthermore, the term "blockchain" as used herein refers to a general term for a general type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0067] Each of the multiple parties 103 acting as consumer users has its computer device 102 connected to network 101. They act as payers and payees in transactions, but do not necessarily participate in mining or disseminating transactions on behalf of other parties. 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, but for convenience, they are not shown. Each party 103 can be an individual or organization. For illustrative purposes only, the first party 103a is referred to as Alice and the second party 103b as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob herein may be replaced by "first party" and "second party," respectively.

[0068] Each party 103's computer device 102 includes a corresponding processing means, 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. Each party 103's computer device 102 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on each party 103's computer device 102 stores software including corresponding instances of at least one client application 105 configured to run on the processing means. It should be understood that any action attributed herein to a given party 103 can be performed by software running on the processing means of the respective computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The computer device 102 of the given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

[0069] The client application 105 may initially be provided to any given party 103's computer device 102 via, for example, a suitable computer-readable storage medium downloaded from a server, or via a removable storage device such as a removable SSD, flash key, removable EEPROM, removable disk drive, floppy disk or tape, optical disc such as a CD or DVD ROM, or a removable optical drive.

[0070] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the corresponding user 103 to create, sign, and send transactions 152 intended to be propagated throughout the network of nodes 104 and thus included in the blockchain 150. The other function is to report the amount of digital assets currently held by the corresponding party. In an output-based system, this second function involves organizing the amounts defined in the outputs of the various transactions 152 belonging to the relevant party scattered across the blockchain 150.

[0071] Note: While various client functionalities can be described as being integrated into a given client application 105, this is not necessarily limiting. Rather, any client functionality described herein can be implemented in a suite of two or more different applications, such as through an API or as a plugin for one application. More colloquially, client functionalities can be implemented at the application layer or at a lower layer such as the operating system, or any combination of these layers. The following description is based on client application 105, but it should be understood that this is not limiting.

[0072] An instance of client application or software 105 on each computer device 102 is operatively coupled to at least one forwarding node among the forwarding nodes 104F of the P2P network 106. This enables the wallet functionality of client 105 to send transaction 152 to network 106. Client 105 can also contact one, some, or all of the storage nodes 104 to query in blockchain 150 any transaction for which the corresponding party 103 is the recipient (or actually check transactions of other parties in blockchain 150, since in this embodiment, blockchain 150 is a public facility that provides trust in transactions to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transaction 152 according to a transaction protocol. Each node 104 runs software 400, which is configured to verify the validity of transaction 152 according to a node protocol and forward transaction 152 in the case of forwarding node 104F to propagate such transactions throughout network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. All transactions 152 in blockchain 150 use the same transaction protocol (although the transaction protocol may allow different transaction subtypes within it). All nodes 104 in network 106 use the same node protocol (although they may distinguish and process different transaction subtypes according to rules defined for that subtype, and different nodes may also play different roles, thus implementing different corresponding aspects of the protocol).

[0073] As described above, blockchain 150 includes a series of blocks 151, each block 151 comprising a set of one or more created transactions 152. Each block 151 also includes a block pointer 155 pointing to previously created blocks 151 in the blockchain to define the order of blocks 151. Blockchain 150 also includes a pool of valid transactions 154 awaiting inclusion in new blocks. Each transaction 152 includes pointers to previous transactions 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 blockchain 150 point to the genesis block 153, not to previous transactions.

[0074] When a given party 103 (say Alice) wishes to send a new transaction 152j to be included in blockchain 150, she will formulate the new transaction according to the relevant transaction protocol (using the wallet functionality in her client application 105). She then sends transaction 152j from client application 105 to one of one or more forwarding nodes 104F that it is connected to. For example, this could be a forwarding node 104F that is most recently or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, it will process it according to the node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j meets specific 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 via a script included in transaction 152. Alternatively, the conditions may simply be a built-in function of the node protocol, or defined by combining scripts and the node protocol.

[0075] If the newly received transaction 152j passes the validity test (i.e., under the condition of being "valid"), any storage node 104S that receives transaction 152j will add the new valid transaction 152 to pool 154 in the replica of blockchain 150 maintained at that node 104S. Further, any forwarding node 104F that receives transaction 152j will then propagate the valid transaction 152 to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, it is assumed that transaction 152j is valid, meaning that the transaction will quickly propagate throughout the P2P network 106.

[0076] Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also recorded immutably.

[0077] Different nodes 104 can initially receive different instances of a given transaction, and thus have conflicting views about which instance is "valid" before an instance is mined into block 150, at which point all nodes 104 agree that the mined instance is the only valid instance. If a node 104 accepts an instance as valid and then finds that a second instance has been recorded in blockchain 150, then that node 104 must accept this and discard (i.e., consider) its initially accepted unmined instance invalid.

[0078] UTXO-based model

[0079] Figure 2An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. Transaction 152 (referred to as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The following description will refer to either an output-based or UTXO-based protocol. However, this is not limited to all possible embodiments.

[0080] In the UTXO-based model, each transaction (“Tx”) 152 includes a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO specifies the amount of digital asset (a store of value). It may also contain the transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include size indicators for the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In this embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152.

[0081] For example, Alice 103a wants to create transaction 152j to transfer related digital assets to Bob 103b. Figure 2 In the sequence, Alice's new transaction 152j is labeled "Tx1". This new transaction acquires the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least a portion of such an amount to Bob. Figure 2 In this context, the previous transaction 152i is marked as "Tx0". Tx0 and Tx1 are just arbitrary markers, and they do not necessarily mean that Tx0 refers to the first transaction in blockchain 151 and Tx1 refers to the next transaction in pool 154. Tx1 can point to any previous (i.e., preceding) transaction that still has unspent output 203 locked to Alice.

[0082] When Alice creates her new transaction Tx1, or at least when she sends it to network 106, the previous transaction Tx0 may already be valid and included in blockchain 150. This transaction may at this point be included in a block of block 151, or it may still be waiting in pool 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 can be created and sent together to network 102; or, if the node protocol allows buffering “orphaned” transactions, Tx0 may even be sent after Tx1. The terms “previous” and “subsequent” as used in the context of transaction sequences in this paper 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 also be replaced with “predecessor” and “successor,” “preceding” and “descending,” or “parent” and “child,” etc. This does not necessarily refer to the order in which they are created, sent to network 106, or arrive at any given node 104. However, subsequent transactions (descendant transactions or "child transactions") that point to a previous transaction (preceding transaction or "parent transaction") will not be valid unless the parent transaction is valid. Child transactions that arrive at node 104 before the parent transaction are considered orphaned transactions. According to the node protocol, they may be discarded or buffered for a period of time to wait for the parent transaction.

[0083] One of the outputs 203 of a 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. This locking script defines the conditions that the unlocking script in the input 202 of a subsequent transaction must meet 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 typically include the following condition: the unlocking script in the input of the subsequent transaction includes the cryptographic signature of the party to whom the previous transaction was locked.

[0084] A 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 a "script" (S capitalized). The locking script specifies the information required for the spend transaction output 203, such as the requirement for Alice's signature. The unlocking script appears in the transaction output. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the locking script standard. For example, it might contain Bob's signature. The unlocking script appears in the transaction input 202.

[0085] Therefore, in the example shown, UTXO0 in the output 203 of Tx0 includes the locking script [Checksig P] A This locking script requires Alice's signature (Sig P). AThis is to redeem UTXO0 (strictly speaking, to make subsequent transactions attempting to redeem UTXO0 valid). [Checksig P] A [Contains the public key P in Alice's public-private key pair] A Input 202 of Tx1 includes a pointer back to Tx1 (e.g., by its transaction ID (TxID0), which in this embodiment is the hash of the entire transaction Tx0). Input 202 of Tx1 includes an index identifying UTXO0 in Tx0, to identify it in any other possible output of Tx0. Input 202 of Tx1 further includes an unlock script. <Sig P A The unlocking script includes Alice's cryptographic signature, which she creates by applying the private key from her key pair to a predetermined portion of data (sometimes referred to in cryptography as a "message"). The data (or "message") that Alice needs to sign to provide a valid signature can be defined via a locking script, a node protocol, or a combination thereof.

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

[0087] <Sig P A > <P A >||[Checksig P A ]

[0088] Here, "||" indicates concatenation, "<...>" indicates placing data on a stack, and "[...]" indicates a function consisting of the unlock script (in this example, a stack-based language). Similarly, scripts can be run one after another using a shared stack, instead of concatenating them. Regardless of the method used, when run together, the scripts use Alice's public key P. A (Included in the locking script at the output of Tx0) to authenticate whether the locking script at the input of Tx1 contains the signature when Alice signs the expected portion of the data. The expected portion of the data itself (“message”) also needs to be included in Tx0 in order to perform this authentication. In this embodiment, the signed data includes the entire Tx0 (therefore, it is not necessary to include a separate element to plaintext specify the portion of the signed data, as it already exists on its own).

[0089] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Essentially, if Alice has encrypted and signed a message using her private key, then given Alice's public key and the message in plaintext (the unencrypted message), other entities such as Node 104 must have already signed the encrypted version of the message to authenticate it. Signing typically involves hashing the message, signing the hash value, and attaching this to the plaintext version of the message as a signature, thereby enabling any holder of the public key to authenticate the signature. Therefore, it should be noted that in embodiments, any reference herein to signing a specific data segment or transaction portion, etc., can mean signing the hash value of that data segment or transaction portion.

[0090] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (therefore, in the example shown, if Alice's signature is provided and authenticated in Tx1), then node 104 considers Tx1 valid. If it is a storage node 104S, this means it will be added to the transaction pool 154. If it is a forwarding node 104F, it will forward transaction Tx1 to one or more other nodes 104 in network 106, thus propagating it throughout the network. Once Tx1 is valid and included in blockchain 150, this defines UTXO0 in Tx0 as spent. Note that Tx1 is only valid if it spends an unspent transaction output 203. If an attempt is made to spend an output that has already been spent by another transaction 152, Tx1 will be invalid even if all other conditions are met. Therefore, node 104 also needs to check if the UTXO referenced in the previous transaction Tx0 has already been spent (has formed a valid input to another valid transaction). This is one of the reasons why the order in which blockchain 150 imposes definitions on transaction 152 is important. In practice, a given node 104 can maintain a separate database that marks the UTXOs 203 of the spent transaction 152, but the final definition of whether a UTXO has been spent depends on whether it forms a valid input to another valid transaction in blockchain 150.

[0091] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another failure criterion in most transaction models. Therefore, such a transaction will not be propagated or mined into block 151.

[0092] Please note that in a UTXO-based transaction model, a given UTXO must be used as a whole. You cannot "leave" a portion of the amount defined in a UTXO as spent while simultaneously spending another portion. However, the amount in a UTXO can be divided among multiple outputs of the next transaction. For example, the amount defined in UTXO0 of Tx0 can be divided among multiple UTXOs in Tx1. Therefore, if Alice doesn't want to give Bob all the amount defined in UTXO0, she can use the remaining amount to make change herself in the second output of Tx1, or pay the other party.

[0093] Alice and Bob's digital assets consist of unspent UTXOs locked to them in any transaction 152 anywhere in blockchain 150. Therefore, typically, the assets of the given party 103 are scattered across the various UTXOs of transactions 152 throughout blockchain 150. No single number defining the total balance of the given party 103 is stored anywhere in blockchain 150. The wallet function of the client application 105 serves to consolidate the various UTXO values ​​locked to the respective party and not yet spent in other subsequent transactions. This is achieved by querying a copy of blockchain 150 stored at any storage node 104S (e.g., the storage node 104S most recently or best connected to the respective party's computer device 102).

[0094] Please note that script code is typically represented using diagrams (i.e., non-precise language). For example, it might be written as [ChecksigP A ] indicates [Checksig P A ] = OP_DUP OP_HASH160 <H(P A OP_EQUALVERIFY OP_CHECKSIG. "OP_..." refers to a specific opcode in the scripting language. OP_CHECKSIG (also known as "Checksig") is a scripting opcode that takes two inputs (signature and public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any occurrences of the signature ('sig') in the script are removed, but additional requirements, such as hash puzzles, are retained in transactions verified by the 'sig' input. Similarly, OP_RETURN is a scripting language opcode used to create a non-spendable output for a transaction, which can store metadata in the transaction, thus immutably recording the metadata in the blockchain. For example, the metadata may include files that need to be stored in the blockchain.

[0095] Signature P AThis is a digital signature. In this embodiment, it is based on ECDSA using elliptic curve secp256k1. The digital signature signs a specific data segment. In this embodiment, for a given transaction, the signature will sign part of the transaction input and all or part of the transaction output. Signing a specific portion of the output depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature, used to select the output to be signed (and therefore fixed at the time of signing).

[0096] A locking script, sometimes called a "scriptPubKey," refers to the fact that it includes the public key of the party to whom the corresponding transaction is locked. An unlocking script, sometimes called a "scriptSig," refers to the fact that it provides the corresponding signature. However, more generally speaking, in all applications of Blockchain150, the conditions for UTXO redemption do not necessarily include signature authentication. Furthermore, scripting languages ​​can be used to define one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferable.

[0097] Optional side channel

[0098] Figure 3 Another system 100 for implementing blockchain 150 is shown. In addition to additional communication functions, system 100 is connected to… Figure 1 The content shown is essentially the same. The client applications on each of Alice and Bob's computer devices 102a and 120b include additional communication capabilities. That is, this allows Alice 103a to establish a separate side channel 301 from Bob 103b (at the instigation of either party or a third party). Side channel 301 enables data exchange independently of the P2P network. This type of communication is sometimes referred to as "off-chain" communication. For example, when exchanging transaction 152 between Alice and Bob, if they do not want to publish the transaction (yet) to the P2P network 106 or mine it to block 150, they can use this communication until one of them chooses to broadcast the transaction to network 106. Alternatively or additionally, this side channel 301 can be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0099] Side channel 301 can be established via the same packet-switching network 101 as the P2P overlay network 106. Alternatively, side channel 301 can be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even a direct wired or wireless connection between Alice and Bob's devices 1021, 102b. Generally, side channel 301 as referred to herein can include any one or more links via one or more networking technologies or communication media for exchanging data "off-chain" (i.e., independently of the P2P overlay network 106). When multiple links are used, the entire bundle or collection of off-chain links can be referred to as side channel 301. Therefore, it is important to note that while Alice and Bob may exchange specific information or data fragments or similar items via side channel 301, this does not necessarily mean that all these data fragments must be sent via the same link or even the same type of network.

[0100] Node software

[0101] Figure 4 An example of node software 400 running on each node 104 of a P2P network 106 is shown, in examples of UTXO-based or output-based models. Node software 400 includes a protocol engine 401, a script engine 402, a stack 403, an application-level decision engine 404, and a collection 405 of one or more blockchain-related functional modules. At any given node 104, these modules may include any one, two, or all of the following three modules: a mining module 405M, a forwarding module 405F, and a storage module 405S (depending on one or more roles of the node). Protocol engine 401 is configured to identify different fields of transaction 152 and process such fields according to the node protocol. When a transaction with a reference to another previous transaction 152m-1(Tx) is received... m-1 The output (e.g., UTXO) of the input transaction 152m (Tx) m When ), the protocol engine 401 identifier Tx m The unlock script is then passed to script engine 402. Protocol engine 401 is also based on Tx. m The pointer in the input is used to identify and retrieve Tx m-1 If Tx m-1 If it is not yet on blockchain 150, then Tx can be retrieved from the corresponding node's own pending transaction pool 154. m-1 Or, if Tx m-1 If it's already on blockchain 150, it can be retrieved from a copy of block 151 in blockchain 150 stored on the corresponding node or another node 104. Regardless of the method used, script engine 401 will identify Tx. m-1 The pointer points to the locked script in the output and passes it to the script engine 402.

[0102] Therefore, script engine 402 has Tx m-1 The locking script and from Tx m The corresponding input unlock script. For example, Figure 4 The examples shown are Tx1 and Tx2, but the same applies to any trading pair, such as Tx0 and Tx1. As previously mentioned, script engine 402 runs two scripts simultaneously, which will include placing data onto stack 403 and retrieving data from that stack according to the stack-based scripting language being used (e.g., script).

[0103] By running the scripts simultaneously, the script engine 402 determines whether the unlock script meets one or more criteria defined in the locking script, i.e., whether the unlock script unlocks the output including the locking script. The script engine 402 returns this determination to the protocol engine 401. If the script engine 402 determines that the unlock script does indeed meet one or more criteria specified in the corresponding locking script, it returns the result "TRUE". Otherwise, it returns the result "FALSE".

[0104] In the output-based model, the result "TRUE" from script engine 402 is one of the conditions for transaction validity. Typically, one or more further protocol-level conditions evaluated by protocol engine 401 must also be met; for example, Tx m The total amount of digital assets pointed to in the output does not exceed the total amount specified in the input, and Tx m-1 The output pointed to by the transaction has not yet been spent by another valid transaction. Protocol engine 401 evaluates the results from script engine 402 along with one or more protocol-level conditions, and only when all of them are TRUE does protocol engine 401 verify transaction Tx. m Valid. Protocol engine 401 outputs an indication of whether the transaction is valid to application-level decision engine 404. Only in Tx m Only when the verification is valid can the decision engine 404 select one or both of the control mining module 405M and the forwarding module 405F to execute their Tx-related functions. m. The corresponding blockchain-related functions. This may include: a mining module 405M, which will mine Tx m Add to the corresponding pool 154 of the node to mine block 151; and / or forwarding module 405F, which forwards Tx mThe transaction is forwarded to another node 104 in the P2P network 106. However, it should be noted that in this embodiment, while the decision engine 404 does not choose to forward or mine invalid transactions, this does not necessarily mean that the decision engine must trigger the mining or forwarding of a transaction simply because it is valid. Optionally, in this embodiment, the decision engine 404 may apply one or more additional conditions before triggering one or both of these functions.

[0105] Furthermore, it should be noted that in this paper, the terms "TRUE" and "FALSE" are not necessarily limited to returning a result represented only as a single binary number (bit), although this is indeed one possible implementation. More colloquially, "TRUE" can refer to any state indicating a successful or affirmative result, while "FALSE" can refer to any state indicating an unsuccessful or uncertain result. For example, in an account-based model ( Figure 4 In (not shown), the result can be indicated as "TRUE" by a combination of the implicit protocol-level verification of the signature by node 104 and the additional positive output of the smart contract (if both individual results are TRUE, the overall result is considered TRUE).

[0106] Exemplary transaction set

[0107] Figure 5 A transaction set 152 used according to the embodiments disclosed herein is shown. This transaction set includes: transaction zero Tx0, transaction first Tx1, and transaction second Tx2. It should be noted that "zero," "first," and "second" are merely convenience labels. They do not necessarily mean that these transactions will be immediately and sequentially placed in block 151 or blockchain 150, nor do they mean that transaction zero is the initial transaction in block 151 or blockchain 150. These labels do not necessarily imply any information about the order in which their transactions are sent to network 106. They only refer to a logical sequence where the input of the next transaction points to the output of a transaction. It should be remembered that in some systems, a parent transaction can be sent to network 106 after its child transactions (in which case, the "orphaned" child transaction will be buffered at one or more nodes 104 for a period of time while waiting for the parent transaction to arrive).

[0108] The zeroth transaction Tx0 can also be referred to as the source transaction for the purposes of this invention, as it serves as the source of the digital asset amount locked to Alice 103a. The first transaction Tx1 can also be referred to as the challenge transaction or puzzle transaction for the purposes of this invention, acting as an intermediary for the conditional transfer of the digital asset amount from the source transaction Tx0 according to the second transaction Tx2, thereby providing a solution to the r-problem. The second transaction Tx2 can also be referred to as the proof transaction or the spending transaction, as this transaction will provide a solution to the r-problem set in Tx1 of the first transaction and lock the resulting payment to the prover (or a potential beneficiary represented by the prover). The embodiment can be described by way of example, in which the prover (the second party) happens to be Bob, but it should be understood from the discussion later that the r-problem actually allows any second party to be the prover, regardless of their identity, as long as they provide a valid signature that solves the r-problem.

[0109] like Figure 5 As shown, the source transaction Tx0 includes at least one output 2030 (e.g., output 0 of Tx0) specifying the amount of the digital asset, and further includes a locking script that locks that output to Alice 103a. This means that the locking script of the source transaction Tx0 requires at least one condition to be met: the input of any transaction attempting to unlock the output (and thus redeem the amount of the digital asset) must contain Alice's cryptographic signature (i.e., using Alice's public key) in its unlocking script. In this sense, the amount defined in the output of Tx0 can be said to be owned by Alice. This output can be referred to as a UTXO. For the purposes of this invention, the output of the previous transaction to which the input of Tx0 points is not particularly important (as long as it is sufficient to cover the total output of Tx0).

[0110] In this scenario, the transaction that unlocks the output of the source transaction Tx0 is the first transaction Tx1 (the challenge transaction). Therefore, Tx1 has at least one input 2021 (e.g., input 0 of Tx1) that includes a pointer to the relevant output of Tx0 (output 0 of Tx0 in the example shown), and further includes an unlock script configured to unlock the output pointed to by Tx0 according to conditions defined in the lock script of that output, which at least requires Alice's signature. The Alice signature required by the lock script of Tx0 necessitates signing a portion of Tx1. In some protocols, the portion of Tx1 that requires signing can be a setting defined in the unlock script of Tx1. For example, this can be achieved by setting a SIGHASH flag, which is appended to the signature and is one byte in size; thus, in terms of data, the unlock script appears as: <Sig P A > <sighashflag><P A Alternatively, the part that needs to be signed can simply be a fixed or default part of Tx1. Regardless of the approach, the part to be signed typically does not include the unlock script itself and may not include some or all of Tx1's input. However, the signed part of Tx1 will at least include the output 2031, which contains the r-difficulty (see below; in this example, Tx1's output is 0).

[0111] The first transaction Tx1 has at least one output 2031 (e.g., output 0 of Tx1, which may also be referred to as a UTXO). The output of the first transaction Tx1 is not locked to any party. Like Tx0, which has at least one output (e.g., output 0 of Tx1) specifying the amount of digital assets to be transferred subsequently, and further includes a locking script that defines what is needed to unlock the output and thus redeem that amount. However, this locking script allows its output to be unlocked by either party providing a solution to the r-problem.

[0112] The second transaction (spending transaction) Tx2 has at least one input 2022 (e.g., input 0 of Tx2), which includes a pointer to the aforementioned output of Tx1 (output 0 of Tx1, as shown in the example), and also includes an unlocking script configured to unlock the output of Tx1 based on one or more requirements satisfying the unlocking conditions defined in the locking script of Tx1. According to the embodiments disclosed herein, the unlocking conditions include at least the requirement that the corresponding unlocking script includes a solution to an r-problem. The r-problem includes a challenge defined in the locking script of Tx1 based on the r-part of an elliptic curve cryptography (ECC) signature, which can be addressed by either party (in this case, Bob), including their signature (or at least its s-part) in the unlocking script of Tx2. It should be noted that, unlike the locking script of Tx0, a signature from either party can be used to unlock the locking conditions in Tx1, provided it is a valid signature addressing the r-challenge (i.e., the r-problem). Examples of this will be discussed in more detail later. Here, Bob is chosen as an example of a prover or second party, but the r-problem actually allows any second party as a prover, such as Charlie, Dora, Ezekiel, etc. In some embodiments, the unlocking conditions in Tx1 may also depend on one or more other conditions, such as also requiring Alice's signature to be included in the unlocking script of Tx2.

[0113] The second transaction Tx2 has at least one output 2022 (e.g., output 0 of Tx2) that specifies the amount of digital assets transferred to Bob and the locking script that locks this to Bob (i.e., requires further subsequent transactions to include Bob's signature in the unlocking script to be spent). In this sense, the output of the target transaction Tx2 can be said to be owned by Bob. This output can also be referred to as a UTXO.

[0114] The certifier must sign it (e.g., Sig P if it is Bob). B The part of the signed Tx2 will include at least this output 2032, which is the output that locks the payment to the prover (in this example, the output of Tx2 is 0).

[0115] In an embodiment, the locking script in the output 2031 of Tx1 may define multiple alternative conditions for unlocking the output, such as multiple alternative r-challenges. In this case, if any one of the alternative unlocking conditions is met, the unlocking script in the input 2022 of Tx2 unlocks the output of Tx1.

[0116] The zeroth transaction (i.e., the source transaction) Tx0 can be generated by Alice, the prover (e.g., Bob), or a third party. It typically requires the signature of the preceding party from whom Alice obtains the amount defined in the input of Tx0. It can be sent to network 106 by Alice, Bob, the preceding party, or other third parties.

[0117] The first transaction (i.e., the challenge transaction) Tx1 can also be generated by Alice, a prover (e.g., Bob), or a third party. Since Alice's signature is required in this embodiment, it can be generated by Alice. Alternatively, it can be generated by Bob or a third party as a template and then sent to Alice for signing, for example, via side channel 301. Alice can then send the signed transaction to network 106 herself, or send it to Bob or a third party for them to forward to network 106, or simply send her signature for Bob or a third party to assemble into the signed Tx1 and forward to network 106. Any off-chain exchanges prior to sending Tx1 to network 106 can be performed via side channel 301.

[0118] The second transaction (i.e., the proof transaction or the spending transaction) Tx2 can be generated by Alice, the prover (e.g., Bob), or a third party. Since the first version requires the prover's signature and / or data, it can be generated by Bob. Alternatively, it can be generated by Alice or a third party as a template and then sent to Bob for signing, for example, via side channel 301. Bob can then send the signed transaction to network 106 himself, or send it to Alice or a third party for them to forward to network 106, or simply send his signature and have Alice or a third party assemble it into a signed Tx2 and forward it to the network.

[0119] It should be understood that there are multiple locations where different elements of a transaction can be generated and assembled, as well as various methods for subsequently sending it directly or indirectly to its final destination on the P2P network 106. The scope of implementations of the disclosed technology is not limited to any of these aspects.

[0120] It should also be understood that phrases such as "by Alice," "by Bob," and "by a third party" in this document can be used as abbreviations for "computer device 102a of Alice 103a," "computer device 102b of Bob 103b," and "computer device of a third party," respectively. Furthermore, it should be noted again that a given party's device may include one or more user devices used by that party, or server resources such as cloud resources used by that party, or any combination of these. This is not necessarily limited to actions performed on a single user device.

[0121] Elliptic Curve Digital Signature Algorithm (ECDSA)

[0122] In many different blockchain architectures, public-key cryptography serves as the foundation for protecting transactions. Its applications include public-key encryption and digital signature schemes. Public-key cryptography is based on the principle that certain functions are easy to compute but difficult to invert without special knowledge. Such functions are called trapdoor functions, and the special knowledge required to invert them is called the trapdoor. Easy to compute means that it is computationally feasible to compute a trapdoor function for a given input (or a set of inputs) within a reasonable timeframe, while difficult to invert means that it is computationally infeasible to deduce from the result that the input (or those inputs) is computationally infeasible without knowledge of the trapdoor.

[0123] In the context of public-key cryptography, a key pair refers to a public key (which anyone can freely obtain) and a corresponding private key (presumably secret, as this is known only to a specific entity or group). The public key defines a trapdoor function, while the corresponding private key is the trapdoor needed to invert that function.

[0124] In the context of public-key cryptography, encryption is based on a trapdoor function (i.e., encryption is performed in the "forward direction"), while decryption is based on the inverse of the trapdoor function (i.e., decryption is performed in the "reverse direction"), which is only possible when the trapdoor is known.

[0125] In the context of digital signatures, signature verification is performed using the public key in the forward direction, while signature generation is performed in the reverse direction, and signature generation can only be performed using the private key.

[0126] In the context of blockchain, digital signatures based on public-key cryptography serve as the basis for cryptographically signing and verifying transaction signatures.

[0127] ECC is a public-key cryptography that utilizes the mathematical properties of elliptic curves and has various advantages compared to other encryption schemes such as DSA (Digital Security Algorithm).

[0128] Elliptic Curve Digital Signature Algorithm (ECDSA) refers to a class of digital signature schemes that use ECC as the basis for digital signature generation and verification. Some principles of ECDSA are summarized below.

[0129] In mathematical terms, ECC utilizes the algebraic structure of elliptic curves over finite fields of prime order. A finite field is a finite set of elements and a set of associated multiplication, addition, subtraction, and division operations that, when applied to the elements of that set, satisfy general arithmetic rules (associativity, commutativity, etc.). That is, in a "general" sense, addition, multiplication, etc., are not required, but their behavior is essentially the same.

[0130] Elliptic curve operations:

[0131] In the context of ECC, addition, subtraction, and multiplication operations are elliptic curve point addition (represented as "+" in this paper), elliptic curve point subtraction (represented as "-" in this paper), and elliptic curve scalar multiplication (represented as "·" in this paper), respectively. Addition and subtraction operations are applied to two points on the elliptic curve, respectively, and return a third point on the elliptic curve; however, multiplication is applied to a scalar and a single point on the elliptic curve, and returns a second point on the elliptic curve. Conversely, division is defined as a scalar operation.

[0132] For ease of explanation, Figure 6A It shows The elliptic curve ε in It is the set of all real-valued two-dimensional coordinates. express The elements of an elliptic curve ε are the set of points that satisfy the following equation:

[0133] ε:y 2 =x 3 +ax+b

[0134] Addition: The mathematical property of ε is that, given any two points A and B on the elliptic curve ε, the line intersecting A and B will re-intersect ε only with one additional point, denoted as C; the elliptic curve addition of A and B, i.e., A+B, is defined as the "reflection" of C: take the horizontal line intersecting C, and the reflection of C is another point on the elliptic curve intersecting that line. This definition applies to the case A=B, where the modified C is now the point where the tangent to ε at A re-intersects ε. By defining the point at infinity, denoted as ∞, as a point on the elliptic curve, and any perpendicular line intersecting the elliptic curve at that point (e.g., points labeled D and E are vertically and horizontally aligned, so D+E=∞), this definition applies to the case where the line intersecting the two points is perpendicular.

[0135] Inverse subtraction / addition: The above definition of reflection applies to any point, and provides the definition of elliptic curve point subtraction: AB is the sum of the reflections of A and B. The reflection of B is more formally called the "inverse addition" of B, expressed as -B. Using this notation, elliptic curve subtraction can be defined mathematically as follows:

[0136] AB = A + (-B).

[0137] Therefore, in Figure 6B In this context, C = -(A+B) and (A+B) = -C. Also note that under this definition, D = -E, reflecting a general rule of algebraic structures: any point on an elliptic curve and the elliptic point of its inverse addition operation are points at infinity.

[0138]

[0139] The point ∞ at infinity is more formally called the "identity element" (note the parallelism and deviation from general arithmetic: in general arithmetic, the sum of any number a and its inverse addition -a is 0, where 0 is the identity element of general arithmetic). Another property of the identity element ∞ reflects general arithmetic, namely, A + ∞ = A for any point A on ε containing ∞ itself (similar to the statement a + 0 = 0 for any real number a).

[0140] Multiplication: Based on the definition of point addition on an elliptic curve, the definition of scalar multiplication on an elliptic curve is as follows: The multiplication of an elliptic curve point A with an integer v is defined as:

[0141]

[0142] In other words, as v, the point A on the elliptic curve is added to itself.

[0143] Note: Elliptic curve scalar multiplication is also known in this art as elliptic curve dot multiplication. These two terms have the same meaning in this disclosure.

[0144] Inverse division / multiplication operations: Regarding the definition of scalars, division operation: Given a scalar v, in scalar v -1 Define its "inverse multiplication operation" such that:

[0145] vv -1 =1.

[0146] Figure 6A It provides an intuitive visualization of the above operations, including all real numbers. ε is defined on an infinite field.

[0147] Figure 6B This illustrates more precisely how the above operations are applied in the ECC context, as it shows the elliptic curve ε defined by the equation. n :

[0148] ε n :y 2 =x 3 +ax+b mod p

[0149] Where p is a prime number (modulo prime), and mod represents the modulo operation. The set of points satisfying the above equation is finite. Figure 6B In the diagram, all points except one are represented by white circles; the remaining points are the identity element ∞.

[0150] The prime number p forms part of the definition of an elliptic curve and can be freely chosen. For an elliptic curve to have good cryptographic properties, p should be large enough. For example, some blockchain models specify 256 bits for p.

[0151] In contrast, the subscript "n" in this paper refers to the order of the group of points formed by the elliptic curve under the point addition defined above (this can be simply referred to as the elliptic curve ε). n (In order), see below.

[0152] In other words, n is the order of the group, and p is the order of the field. There will be a total of n elliptic curve points. Each point on the elliptic curve is represented by two numbers / coordinates (x, y), where x and y are in the range –(p-1),…0,…,(p-1).

[0153] It can be seen that, Figure 6B ε n Showing Figure 6A The ε in the equation is similarly horizontally symmetric, which is a general property of elliptic curves on prime numbers; therefore, ε n The definition of the inverse addition operation for the upper point still applies. Some points do not have a horizontally aligned corresponding point (e.g., (0,0)), and these points are their own inverse addition operations.

[0154] With ε n The line that intersects points A and B A,B For a finite set of points, represented by smaller black circles, satisfying similar geometric requirements, the definition of elliptic curve scalar multiplication still applies. Figure 6A similar, Figure 6B The expression shows that point A + B = -C, which is the inverse addition operation of point C = -(A + B). Line l... A,B At this point and ε n They intersect again.

[0155] ε n The elliptic curve addition A + B = -C at any two points on the curve can be algebraically defined by the following equation:

[0156] A=(x A ,y A ),

[0157] B = (x B ,y B ),

[0158] C=(x C ,y C )=-(A+B),

[0159] x C =(λ 2 -x A -x B )mod p,

[0160] y C =(λ(x) C -x A )+y A )mod p,

[0161] =(λ(x) C -x B )+y B )mod p,

[0162] in

[0163] λ=(y A -y B (x) A -x B ) -1 mod p if A≠B,

[0164] and

[0165] If A = B.

[0166] For the aforementioned purpose, the inverse operation of multiplication of integer v is performed. -1 The definition is revised as follows:

[0167] v -1 v≡1(modp).

[0168] In other words, the inverse multiplication operation of an integer v is the modulo inverse of v mod p.

[0169] The case of B = -A is special and can be solved by introducing the identity element ∞. As mentioned earlier, in this case, A + B = A + (-A) = ∞. The case of B = ∞ is also special, and can be solved as described above, i.e., A + ∞ = A.

[0170] The definition of elliptic curve scalar multiplication adopts the definition of elliptic curve addition; otherwise, it remains unchanged.

[0171] In other contexts, the inverse operation of multiplication of scalar v is... -1 The definition of is:

[0172] v -1 v≡1(mod n)

[0173] In the context, it is clear whether the inverse multiplication operation with respect to mod n or mod p is defined.

[0174] In practice, to determine whether a number should be considered mod n or mod p, the following check can be applied:

[0175] 1. Does this number represent the coordinates of point EC?

[0176] a. If so, it should be considered as mod p

[0177] 2. Is this number used to multiply by EC points?

[0178] a. If so, it should be considered mod n

[0179] It should be noted that in some cases, both checks will give an affirmative answer; in such cases, the number must be mod p and mod n.

[0180] Elliptic Curve Cryptography (ECC)

[0181] Elliptic curve arithmetic provides the unique ability to hide secret values ​​and forms the basis of many modern cryptographic systems. In particular, scalar multiplication inversion at elliptic curve points over finite fields is a tricky problem (computationally infeasible).

[0182] The private key V is in integer form, and the corresponding public key P is an elliptic curve ε. n The point P derived from the "generating point" G is also the point on the elliptic curve ε. n A point on, as shown below:

[0183]

[0184] Where "·" represents the elliptic curve ε defined by a, b, and n (elliptic curve parameters). n Elliptic curve scalar multiplication.

[0185] For sufficiently large V, it is practically difficult, i.e., computationally infeasible, to derive P from V elliptic curve addition. However, if V is known, P can be computed more efficiently by leveraging the algebraic properties of elliptic curve operations. An example of an efficient algorithm that can be used to compute P is the "double addition" algorithm, which, importantly, is only possible when V is known.

[0186] Conversely, if V is unknown, then even if G and P are known, there is no computationally feasible way to derive V (i.e., to perform inverse scalar multiplication) (this is the so-called "discrete logarithm problem"). An attacker could try to "brute-force" P by starting with G and repeatedly performing elliptic curve point additions until P is reached; at this point, he would know that V is the number of elliptic curve point additions he must perform; however, this proves to be computationally infeasible. Therefore, V satisfies the trapdoor requirement in the aforementioned sense.

[0187] In ECC, the public key P, the generator key G, and the elliptic curve ε n It is public and assumed to be known, while the private key V is secret.

[0188] Elliptic Curve Digital Signature Authentication Algorithm (ECDSA)

[0189] In a blockchain system, users or other entities typically hold a private key V to prove their identity, and the corresponding public key P is calculated using the following equation:

[0190] P = V·G

[0191] The private key V can be used to sign data m ("message") using ECDSA.

[0192] For example, more information about ECDSA can be found in the following, the full text of which is incorporated herein by reference: "RFC 6979 - Deterministic use of digital signature algorithms (DSA) and elliptic curve digital signature algorithms (ECDSA)," Tools.ietf.org, 2019.

[0193] Figure 6C A schematic functional block diagram of the signature generation function (signature generator_600, which generates an ECDSA signature (r,s) of a public-private key pair (V,P)) is shown. The EDSA signature is a pair of values, referred to herein as the r part (r) and the s part (s).

[0194] The signature is generated based on the same elliptic curve ε used to derive the public key P. n And the generation point G, so the elliptic curve parameters a, b and n and the generation point G are shown as inputs to the signature generator 600.

[0195] The temporary key generator 602 of the signature generator 600 generates a "temporary" key k∈[1,n-1], that is, the range is between 1 and n-1 (inclusive).

[0196] The r-part generator 604 calculates the corresponding temporary public key based on k, as shown below:

[0197] R = k·G

[0198] Then take the x-coordinate of the calculation point ([] x (This describes the process of obtaining the x-coordinates of points on an elliptic curve.)

[0199] r = [R] x

[0200] This is the 'r' part of the signature.

[0201] The s-part generator 606 uses the modular inverse k of kmodn. -1 (that is, k) -1 The signature s part (s) is calculated using the hash value of message m (denoted as H(m), truncated if necessary) and k≡1(mod n as described above), as follows:

[0202] s = k -1 (H(m)+rV)mod n

[0203] In this example, message m includes data to be included in transaction 608 (one or more transaction outputs in this example). This can be referred to as the process of signing message m, and message m can be referred to as the signed portion of the transaction.

[0204] The message m and the signature (r,s) in turn form part of transaction 608. In this example, the signature (r,s) is included in the input of transaction 608 as part of the unlock script.

[0205] Figure 6D A schematic functional block diagram of a signature verification function (signature verifier) ​​620 for verifying transaction 608 is shown. The computations performed by the signature verifier 620 are based on the same elliptic curve ε. n And the point G, as mentioned above, is public.

[0206] Although signing requires a private key V as input (i.e., knowing the private key is necessary to generate a valid signature), verifying the signature (r,s) only requires the signature pair (r,s), the message m, and the public key P. To verify the signature, the signature verifier 620 hashes the signed portion of transaction m (applying the same hash function H used to generate the signature (r,s)). The verification process is then performed using the following calculation:

[0207] R′=H(m)s -1 ·G+rs -1 ·P

[0208] If and only if [R′] x The signature is valid only when r is equal to 0 (i.e., signature verification is successful); otherwise, the signature is invalid (i.e., signature verification fails). In this example, r represents the r-part of the signature included in transaction 608.

[0209] For example, the public key P used in the signature verification process can be specified in the locking script of a previous transaction. In this case, signature verification is performed using the public key specified in the locking script of the previous transaction, along with the signed portion m and signature (r,s) of (subsequent) transaction 608, and the signature verification will fail unless a signature (r,s) has already been generated based on the private key V corresponding to the public key P specified in the previous transaction and the signed portion m of subsequent transaction 608. Therefore, only the person holding the private key V can claim the output of the previous transaction (usually by including their own public key in the output of subsequent transaction 608), and the signed portion m of subsequent transaction 608 cannot be altered without verifying that the signature (r,s) is invalid.

[0210] r Problem

[0211] The following describes a new knowledge proof based on ECDSA. For illustration, the challenger is Alice, the first party, who sets the r-problem in the first transaction Tx1 by either creating and publishing Tx1 herself to the P2P blockchain network 106, or by providing the necessary details to a third party for them to assemble and publish it. The validator (the party actually running the proof) is the operator of node 104 on the network. The solution to the r-problem is provided by publishing Tx2 to network 106. The prover can be any second party, as the r-problem itself is identity-independent; however, as an example, the following can be described as if the prover happens to be Bob. The prover can either create and publish Tx2 herself, or provide the necessary details to a third party for them to assemble and publish it.

[0212] Cryptographic hash functions provide a deterministic way to hide inputs, where small changes in the inputs lead to unpredictable changes in the outputs. Traditional hash functions include MD5, RIPEMD-160, SHA-1 and SHA-256[5], each of which has collision resistance (the probability of finding two inputs that produce the same output is extremely small) and anti-image properties (it is extremely difficult to find input d given a hash value h = H(d)).

[0213] A traditional hash problem can be set up as follows. The idea is to establish a first transaction Tx1 that allows a second transaction Tx2 to redeem its output on the condition that its input includes certain specific data.

[0214] In a blockchain transaction, the first party (Alice) can easily create a non-standard transaction Tx1 using the hash value h in the locking script, as shown below:

[0215] OP_HASH160 <h>OP_EQUALVERIFY

[0216] Where h = H puz (d) and H puz The hash function used in the puzzle (in the example above, this hash function must be HASH160 according to the locking script, but another form of hash function can be used in other implementations). To redeem the UTXO that includes this locking script, the hash puzzle solution in the unlocking script of a subsequent transaction will be required. Therefore, the spending transaction Tx2 with the second party at address Addr_Bob will be constructed using an unlocking script that only needs to contain d.

[0217]

[0218] Where TxID i It is Tx i The transaction ID. The locking script means: take the data value d from the unlocking script in the input of Tx2, hash it, and check if it is equal to the hash value h included in the locking script in the output of Tx1. Therefore, the output is unlocked by providing d in the unlocking script of Tx2.

[0219] In this example, after seeing a user transaction with a Tx2 hash puzzle solution, the first node to receive the transaction might maliciously reject it and create a new extended version with the same hash puzzle solution. However, it will change the output to its own address, Addr_Miner. Then, a malicious node can attempt to... If they successfully mine their own block 151, and if they succeed before Tx2 is mined, the node, not Bob, will receive the payment.

[0220]

[0221] Digital signatures are commonly used in blockchain transactions to prove ownership and redeem unspent transaction outputs (UTXOs). This allows the outputs of transactions like Tx1 to be locked to a specific party. The most common example is a payment to a public key hash (P2PKH) transaction, where the transaction's outputs are locked to a specific hash value of the public key (which also acts as the address of that party). The locking script for public key P is:

[0222] OP_DUP OP_HASH160 <h P >OP_EQUALVERIFY OP_CHECKSIG

[0223] Where h P =H sig (P) and H sig This is the hash function used in the signature (in the example above, this hash function must be HASH160 according to the locking script, but another form of hash function can be used in other implementations). In order to use this UTXO as input to another transaction, an unlocking script with a valid ECDSA signature must be provided using P:

[0224] <sig>

[0225] The entire string (unlock script + lock script) is evaluated by the node, which checks if the correct public key is provided and if the signature is valid and corresponds to P. The lock script essentially represents: obtaining the public key P from the unlock script in the input of Tx2, hashing it, and checking if it equals the hash value h included in the lock script in the output of Tx1. P Furthermore, it uses the public key P from the unlocking script of Tx2, based on the ECDSA verification function, to verify the signature sig, provided that knowledge of the signed portion of Tx2 is available. The ECDSA verification function is invoked using the opcode OP_CHECKSIG.

[0226] Therefore, the output can only be unlocked by providing a valid signature sig based on the private key V corresponding to P in the Tx2 unlocking script.

[0227] Combining this with the hashing puzzle, the aforementioned vulnerability can be corrected by requiring the intended recipient's digital signature and the solution to the hashing puzzle. The locking script will be constructed as follows:

[0228] OP_HASH160 <h>OP_EQUALVERIFY OP_DUP OP_HASH160 <h P >OP_EQUALVERIFY OP_CHECKSIG

[0229] The corresponding unlock script must be:

[0230] <sig>< / sig> < / h> <d>.

[0231] However, this limits who can redeem it to the owner of the public key P. This paper recognizes that this may not be desirable in some applications, such as where Alice wants to retain the ability to authorize a designated signer only after the puzzle has been set.

[0232] This paper recognizes that the hash puzzle function can be simulated by utilizing the 'r' part of the ECDSA signature, which can be a temporary random value. The ECDSA signature consists of two main parts: r and s. As mentioned above, r = [k·G] x Instead of the traditional hashing problem h = H(d), the intractable elliptic curve addition presents a similar problem, referred to in this paper as the r-problem. To solve this problem, a solution value k is needed, where k is the temporary key corresponding to r.

[0233] For traditional hashing problems, there is a risk of revealing 'd' in the blockchain when solving the problem. However, for r-problems, 'k' is never revealed. Instead, 'r' is revealed, and knowledge of 'k' can be obtained from 'r' and the signature proof.

[0234] To simulate the functionality of the hashing puzzle, the creator of the r-problem could first hash some other preimage data to obtain the value k, since k must be of fixed size, while the preimage data of the hashing puzzle can have any length (and a property of hash functions is that they output a fixed-length value regardless of the length of the input data). For example, if using a 256-bit private key / temporary key, the preimage data of the r-problem should be hashed to obtain k. However, it is also possible to directly choose a value of suitable length for k and use it directly as the secret value (i.e., without needing to derive the secret value from some other previous preimage).

[0235] This method can be used in any blockchain system that uses ECDSA signatures for spending. As an illustration, an exemplary implementation in a UTXO-based model is described below. In the scripting language, the OP_CHECKSIG opcode requires a signature and a public key on the stack (the public key is at the top of the stack, and the signature is directly below). For the r-problem, the script is configured to check if the r value in the provided signature is the same as the value used for the r-problem challenge. In other words, the script will not only check if the signature is valid on the public key (via OP_CHECKSIG), but will also ensure that the signature was created using the r value of the r-problem, which will be published on the blockchain beforehand.

[0236] Now refer to Figures 7 to 10 This section discusses some exemplary implementations of the r-problem. In each case, the prover (e.g., Bob) creates a signature (r,s) by signing a portion of Tx2. This form of signature is sometimes also referred to as "sig". In the context of cryptographic signatures, the signed portion is also called the "message" (m). The signed portion (message) m includes at least the output 2032 of Tx2, which locks the final payment to Bob. If there are multiple outputs, m can include some or all of them. If a locking time is used, m can also include other portions. However, the unlocking script itself is typically not included (at least the signature itself must not be included, of course). The portion of Tx2 to be signed as message m can be set by Sighash, or it can be a default or fixed feature of the protocol.

[0237] Figure 7 The simplest implementation is shown. The locking script in Tx1 includes the reference instance or r part marked r' here. In this method, the unlocking script in Tx2 only needs to contain at least the s part (s) of Bob's signature. It may also include the public key P corresponding to the private key V that Bob used to sign m. The locking script of Tx1 is configured to, when run by the script engine 402 at node 104, take s and P from the unlocking script of Tx2 and perform the following operations:

[0238] I)R′=H sig (m)s -1 ·G+r′s -1 ·P, and

[0239] II) Check [R′] x =r′,

[0240] r' is obtained from the locking script of Tx1, and s and m are obtained from the unlocking script of Tx2. Bob's public key P can also be obtained from the unlocking script Tx2, or can be obtained through other means. H sig G is the hash function used to hash m when generating the first ECDSA signature. It can be any form of hash function. Regardless of its form, it can be assumed that the form (type) of the hash function is predetermined and known at both ends. G is a fixed, well-known vector value.

[0241] The locking script is configured to return a "TRUE" result if the check is TRUE, otherwise a "FALSE" result. In the case of UTXO, a TRUE (i.e., successful) result from running both the locking and unlocking scripts is a necessary condition for the transaction to be valid. Therefore, the validity of Tx2 can be used as a proxy for the result of the r-dilemma. Or in other words, the validity of Tx2 depends on providing a solution to the r-dilemma. That is, if Bob fails the r-dilemma, his transaction Tx2 will not propagate on network 106, nor will it be recorded in blockchain 150 (and any payments defined in the output of Tx1 will not be redeemed).

[0242] Although Figure 7 The example might be the simplest in a mathematical sense, but that doesn't necessarily mean it's the simplest to integrate with any given node protocol or scripting language. If the consumer only provides in the unlock script... <s> and< / s> < / d> <s> Instead<r,s> and< / s> <s>Then the script must take this into account. Operations I)-II) are not standard Checksig type opcode operations. The OP_CHECKSIG opcode expects a signature in DER format, therefore if the unlock script only provides... <s>If the value is not specified, then some additional opcodes (OP_CAT for cascading, etc.) will be needed in the locking script to generate a valid signature in DER format. Figure 8 An alternative example is shown simply, which, although involving additional mathematical steps, is actually simpler to integrate scripting languages ​​such as Script, which already have dedicated opcodes for invoking ECDSA signature verification based on r and s obtained from the input of Tx2.

[0243] It should also be noted that P need not be included in Tx2 in all possible embodiments. In fact, based on knowledge of messages m and (r,s) (or in this case, (r',s)), two possible values ​​of the public key, P and –P (but the specifics are unknown), can be computed. Two verifications can then be used to identify which one is correct, or alternatively, a bit flag can be included in Tx2 to indicate which of the two possible solutions to use. The latter approach is currently used in some account-based protocols. However, it tends not to be used in current UTXO-based protocols where the scripting language (e.g., Script) does not have opcodes for computed to P and –P based on (r,s) and m. However, the possibility that an opcode can be introduced or that the operation can simply be explicitly encoded into the locking script should not be ruled out. Another possibility is that Alice already knows or has access to P or has received the opcode via side channel 301. However, this would require a separate lookup to map P to Tx2.

[0244] Figure 8 Another exemplary implementation is shown. Here, the r-problem requires that the unlocking script of Tx2 explicitly include the commit instance r of the r-part. The locking script of Tx1 includes a test on the r-part, which includes a reference instance r' of the r-part to be compared with the commit instance r. In this approach, the unlocking script in Tx2 must contain at least the r-part (r) and s-part (s) signed by Bob. It may also include the public key P corresponding to the private key V that Bob used to sign m. The locking script of Tx1 is configured to, when run by the script engine 402 at node 104, obtain r, s, and P from the unlocking script of Tx2 and perform the following operations:

[0245] I) Check r′=r,

[0246] II) Calculate R′=H sig (m)s -1 ·G+rs -1 ·P,

[0247] III) Check [R′] x =r,

[0248] r' is obtained from the locking script of Tx1, and s, r, and m are obtained from the unlocking script of Tx2. Bob's public key P can also be obtained from the unlocking script Tx2, or it can be obtained in other ways, such as by deriving it from (r,s) and m or (r,s) and m as mentioned above.

[0249] The locking script is configured to return "TRUE" if both checks in steps I) and III) are TRUE, otherwise return "FALSE". Similarly, in the UTXO-based case, this allows the validity of a transaction to be determined based on the result of a knowledge proof of an r-problem. It should be noted that the numbers I-III do not necessarily indicate order. Check I) can be performed before or after II)-III), but III) must indeed be performed after II).

[0250] exist Figure 8 In this method, steps II) and III) are routine operations performed solely by the ECDSA verification function. Therefore, in most protocols, they can be invoked using specialized opcodes, such as the existing Checksig opcode (OP_CHECKSIG) in the script. Step I) can be encoded separately into the locking script using a generic opcode (an example will be given later). It is also not excluded that steps II) and III) could, in principle, be explicitly encoded using generic opcodes instead of specialized opcodes like Checksig.

[0251] In an exemplary transaction protocol, the transaction ECDSA signature uses the ASN.1 (Abstract Syntax Notation 1) DER (Distinguished Encoding Rule) encoding format, such as... Figure 12 As shown. The first byte field contains the flag 0x30, indicating the ASN.1 sequence number. The second byte field contains the sequence length in hexadecimal. The third byte field contains the flag 0x02, indicating the ASN.1 integer. Afterwards, the r value of the ECDSA signature is contained in the following 32 or 33 bytes. The field should be 32 bytes, however, if the first byte of r is greater than 0x7f (the first bit is 1), an addition byte of 0 is added before the r value, making its length 33 bytes. This is the result of DER format encoding, which interprets the first bit of the integer as a sign. An extra zero byte is added to the beginning of the value so that it is not interpreted as a negative value. The same applies to the s value of the ECDSA signature. Finally, a byte field, the hash type (ht), is added to the DER encoding, which corresponds to the signature type in the transaction (SIGHASH_ALL, SIGHASH_NONE, etc.).

[0252] Consider Alice (A) wanting to create an r-problem transaction in which anyone who solves the problem can spend it. To do this, she will create a new transaction Tx1 as shown below. The input part includes the unlocking script for the previous transaction tx0 that is being spent. For simplicity, assume it is a standard P2PKH using Alice's signature and public key. The output part includes the locking script (script public key), in other words, the r-problem challenge. Figure 12 As shown, the signature may use DER encoding format in some protocols, so the script must extract the value of r from the encoded signature and then check if it equals 0. <r>Next, the script must check if the signature on the public key is valid. Figure 5 A more detailed description of how the script works is shown. The bold opcode is essentially just one way to extract 'r' from the signature.

[0253]

[0254] The corresponding unlock script is shown below, where the signature is sig. r Using r, spender Bob (B) can compute a signature using any private / public key pair. It should be noted that sig r It is (r,s).

[0255] <P B > <sig r >

[0256] Figure 13 The step-by-step script analysis is shown.

[0257] The temporary key k can be generated by Alice and provided to Bob (and optionally one or more other potential provers). Alternatively, k can be generated by Bob and provided to Alice to set up an r-problem that only Bob (or anyone Bob chooses to share k with) can solve. In either case, the prover Bob must believe that the sender Alice will not spend the transaction herself because she knows the solution (k) to the r-problem. To prevent this, the prover Bob can create the problem and then send the value of r to Alice so that she can use it when creating the r-problem transaction. Afterward, Bob can redeem the output later using any private / public key pair, as long as he retains the value k, which is the solution to the r-problem and can be considered a form of key. On the other hand, in some cases, the fact that Alice knows k can be an advantageous feature. For example, this can be used to create a private key problem and perform general atomic swaps through that problem.

[0258] Figure 9 By analogy with Pay-to-Public-Key Hash (P2PKH), another example of the r-problem is shown, which can be referred to in this paper as "Pay-to-r-Problem Hash" (P2RPH). To improve security and privacy, the r value can be hashed before being placed into Tx1 (it will be propagated through node 104 of network 106 and placed on blockchain 150). Similar to P2PKH, only the hash value of the public key, not the public key itself, is on the blockchain; the same applies to the r-problem.

[0259] Here, the r-problem again requires that the unlocking script of Tx2 include the commit instance r of the r part. The locking script of Tx1 again includes a test on the r part, but this time in the form of a compressed instance of the r part in the form of the r' hash value, i.e., h = H(r'). This will be compared with the commit instance r. In this approach, the unlocking script in Tx2 must also contain at least the r part (r) and s part (s) signed by Bob. It may also include the public key P corresponding to the private key V that Bob used to sign m. The locking script of Tx1 is configured to, when run by the script engine 402 at node 104, take r, s, and P from the unlocking script of Tx2 and perform the following operations:

[0260] I) Check h = H puz (r),

[0261] II) Calculate R′=H sig (m)s -1 ·G+rs -1 ·P,

[0262] III) Check [R′] x =r,

[0263] Where h is obtained from the locking script of Tx1, and s, r, and m are obtained from the unlocking script of Tx2. The hash value h = H puz (r), where H puz It is the hash function used in the hash puzzle of r. It can be any form of hash function. It can be H sig The same or different forms of hash functions. Regardless of the form, it can be assumed that H... puz The form is predetermined and known at both ends. Bob's public key P can also be obtained from the unlocking script Tx2, or it can be obtained in other ways, such as by deriving it from (r,s) and m or (r,s) and m as previously described.

[0264] The locking script is configured to return "TRUE" if both checks in steps I) and III) are TRUE, otherwise return "FALSE". Check I) can be executed before or after II)-III), but III) must be executed after II).

[0265] Similarly, with Figure 8 Similar to the case where steps II) and III) are routine operations performed solely by the ECDSA verification function. Therefore, in most protocols, they can be invoked using specialized opcodes, such as the existing Checksig opcode (OP_CHECKSIG) in the script. Step I) can be encoded separately into the locking script using a generic opcode.

[0266] The following is an example of a locking script in Trading Challenge Tx1:

[0267]

[0268] Any type of hash function that is consistent between the sender and receiver can be used. However, to maintain consistency with the P2PKH standard, OP_HASH160, double hash SHA-256, and RIPEMD-160 are used.

[0269] The corresponding unlock script is shown below (same as the previous section), where the signature sig r Using r, spender Bob (B) can compute a signature using any private / public key pair:

[0270] <P B > <sig r >

[0271] therefore, Figure 9 Examples and Figure 8 Similarly, the difference is that it uses the hash value of the r part as the basis for the r puzzle, instead of using an untransformed instance of r.

[0272] It should be noted that in any of the above cases, it is possible that the Tx1 unlocking script may impose additional criteria on the "TRUE" result. For example, a lock time or additional signature requirements.

[0273] Examples of use cases for any of the above techniques serve as general knowledge challenges. Consider any challenge that has some solution k or solutions that can be hashed down to k. Alice can then create an r-chapter coupled to the aforementioned challenge. That is, she can define r = [k·G]. x .

[0274] For example, Alice is a math professor. She can construct an r-problem transaction Tx1, where the underlying value of k is a solution to a math problem that incentivizes students to solve it. Whoever designs the solution can use that solution to create a signature (r,s), where r will match the value in the locking script, thus claiming the reward. The signature not only provides authenticity but also acts as proof of knowledge without revealing the solution to anyone else. Therefore, the r-problem provides a secure mechanism to prove knowledge of certain solutions or general information without the risk of exposure. It elegantly reuses the signature needed in the unlocking script and allows anyone who finds the solution to claim the reward in a private manner, since any public key P is available.

[0275] This scheme can also be used in the form of tokens or digital tickets. For example, event organizers can issue participants different values ​​of k as digital tickets. When participants want to attend the event, they can prove they possess knowledge of the secret token by using an r-puzzle.

[0276] As another example use case, the r-challenge can be used as a signer delegation scheme, where one party can delegate the signing authority to another. Consider the r-challenge transaction Tx1, which can only be unlocked when a signature with an r value matching the locking script is provided. This means that only when the value of k is known (where [k·G]...)... x Only a person with the knowledge of k (r) can generate such a signature. However, if this person passes on the knowledge of k to someone else, then this effectively authorizes that person to sign on his or her behalf.

[0277] For example, suppose Alice wants to receive a delivery, but she's worried she might not be able to. She provides Bob and Charlie with a copy of k so they can receive the delivery on her behalf. If Dave is delivering the package, she must obtain a signature with the expected value r before she can provide the package to Bob.

[0278] In such a scenario, k can be regarded as acting as a temporary private key and r as acting as a temporary public key; they are similar to V and P respectively, except that k and r are not related to a specific identity.

[0279] The problem of joint value r

[0280] As Figure 9 An extension of the hashed r-problem (P2RPH) can include an additional value d concatenated with r before hashing (to obtain h = H). puz (r||d)). In this case, the prover (e.g., Bob) must not only solve the r problem, but also know r. Figure 10 An implementation example of this is shown in the figure.

[0281] The locking script of Tx1 is configured to, when run by script engine 402 at node 104, retrieve r, s, P, and d from the unlocking script of Tx2 and perform the following operations:

[0282] I) Check h joint =H puz (r||d),

[0283] II) Calculate R′=H sig (m)s -1 ·G+rs -1 ·P,

[0284] III) Check [R′] x =r,

[0285] Where r||d represents the concatenation of r and d in any order (r first or d first). An example of a locking script in Trading Challenge Tx1 is shown below:

[0286]

[0287] The corresponding unlock script is shown below (except for 'd', it is the same as the previous section). Signature sig r P B Using r, prover Bob (B) can compute a signature using any private / public key pair.

[0288] <sig′><P B > <d><sig r >

[0289] The additional signature sig′ is a feature added to enhance security (see the section below on optional security features). However, this is not necessary for all possible implementations.

[0290] An example use case is the r-problem related to CLTV. In this case, the data value d could be the time value t associated with the CLTV (Check Lock Time Verification) transaction output. The purpose of this is to hide the time t that cannot be spent before the output in the P2RPH hash and associate it with the r-problem. In this case, the prover (e.g., Bob) must not only solve the r-problem but also know t and wait until the specific time to spend it. An example of a locking script in a transaction is shown below:

[0291]

[0292] The corresponding unlock script is shown below, where the signature is sig. r P B Using r, spender Bob (B) can compute a signature using any private / public key pair.

[0293] <sig′><P B > <t><sig r >

[0294] The additional signature sig′ is a feature added to enhance security (see the section below on optional security features). However, this is not necessary for all possible implementations.

[0295] The above describes cascading. However, it can also be generalized as a function f(r,d). For example, f can be the sum of r and d, implemented as follows: <r> <d>OP_ADD.

[0296] Proof of the r-problem

[0297] As a variant of the aforementioned joint value puzzle, the value d received in the proof transaction Tx2 can be used as a random value for a proof puzzle. The spender must not only solve the r-problem but also find a random value that leads to a hash value target with a certain degree of difficulty. In other words, the check-in script of the following equation, or a value with more leading zeros than the target.

[0298] H puz (r||random number)<target

[0299] Note: Typically, a given hash function can be a single basic hash function or a combination of two or more constituent hash functions. For example, in the embodiment, H... puz = H[H(...)]. In common blockchain mining protocols, the transaction header is hashed twice in the proof. Therefore, to mimic this, in the embodiment of the r-challenge proof disclosed herein, r||d may also be hashed twice. However, this is optional, and in other embodiments, H puz It can be just a single hash value.

[0300] Preferably, this check is combined at least with a regular ECDSA signature verification performed on the received signature tuple (r,s) in Tx2 to verify whether the value of r used in the proof corresponds to the signature. When the locking and unlocking scripts are run together, if both checks are satisfied—that is, the random number and r satisfy the objective, and the signature is verified—only a "TRUE" result is output.

[0301] In this scenario, the locking script of Tx1 is configured to, when run by script engine 402 at node 104, obtain r, s, P, and a random number from the unlocking script of Tx2 and perform the following operations:

[0302] Check H PoW (r||d)<target,

[0303] Calculate R′=H sig (m)s -1 ·G+rs -1 ·P,

[0304] Check [R′] x =r,

[0305] Where r||d represents the concatenation of r and d in any order (r first or d first), and d is a random number, such as Figure 14A As shown. Typically, H PoW It can be H sig and / or H PoW The same or different forms of hash functions.

[0306] The corresponding locking script in transaction Tx1 is shown below:

[0307]

[0308] The corresponding unlock script is shown below (same as the previous section, except for the random number and data value d), where the signature sig r P B Using r, spender Bob (B) can compute a signature using any private / public key pair.

[0309] <sig′><P B > <nonce><sig r >

[0310] The additional signature sig′ is an optional feature added to enhance security (see the section below on optional security features). However, this is not mandatory for all possible implementations.

[0311] It should be noted that the random number here differs from the random number used in the inherent underlying proof, which is executed by the mining nodes on their transaction pool 154 to mine transactions into block 151 according to the basic node protocol followed by all nodes 104. Therefore, the disclosed technique places the additional proof to be performed by the prover (e.g., Bob) on top of the basic blockchain protocol. To redeem the output, Bob must not only know the value of k, but also perform a certain proof to obtain a valid random value.

[0312] One exemplary use case is that challenger Alice only wants the prover (Bob) to receive the amount of digital assets defined in the output of Tx1 after a certain period of time (because proving takes time). This can be used as an alternative to locking time.

[0313] Another example is proof of computational power. Alice wants to determine who has the strongest computational power. To do this, she creates an r-problem that requires proof; whoever solves the problem first spends the output and proves they have the strongest hashing power. In this case, it might also be useful if they could link their identity to the solution using their public key P or another P2 (see the next section). Alice could then choose to use some other service from the winner that requires that computational power.

[0314] Typically, the value of k required to generate the r-part of the solution can be provided to the prover by Alice or a third party, or it can be provided to Alice by the prover (or one of the potential provers). For example, in the computational ability proof example, Alice or a third party could assign k to one or more potential provers to enable them to participate in the challenge.

[0315] It should be noted that in the example locking script above, the locking script does not include checking the value of 'r' used. This is not necessary for verifying the proof itself.

[0316] However, optionally, in an embodiment, the unlocking script will include some additional code (not shown) to check the value of r used. For example, this can be done by combining the r puzzle demonstrated above with reference to... Figures 7 to 9 Any checks described can be implemented. Figure 14B The proof of the r-problem is shown. Figure 7 The combination of verifications shown. Figure 14C The proof of the r-problem is shown. Figure 8 The combination of verifications shown. Figure 14C The proof of the r-problem is shown. Figure 9 The combination of verifications shown is illustrated. In these cases, when the locking and unlocking scripts run together, only a "TRUE" result is output if all checks are satisfied. It should be noted that the numbers I), III), and IV) used in this document do not imply a specific order in which the checks must be performed; they can generally be performed in any order relative to each other.

[0317] In other embodiments, it may be advantageous for the r part of the locked script to not have a reference value. This would allow anyone to provide a solution without it being stolen by others. The idea is that the prover can choose a value for k and then compute r. The prover then checks all possible values ​​for d. If none of these values ​​are available, the prover can try different k. After finding a pair of r and d, the prover can construct a signature with r as its r part.

[0318] On the other hand, locking the script to a fixed r′ (or the hash of r') would require the prover to first solve the r puzzle or be assigned a k value, which is undesirable in this case.

[0319] The above is a description of cascading. However, in any version of the proof of the r-problem, it can be generalized to a function f(r,d). For example, f can be the sum of r and d, implemented as follows: <r> <d>OP_ADD. Furthermore, the condition that f(r,d) must satisfy is not limited to a hash value less than the target value or having at least a predetermined number of leading zeros. Generally, any condition can be used for proof; for example, the hash value of f is greater than the target value or within a predetermined range. Furthermore, a similar comment applies to the prover's public key P, as mentioned above, i.e., P can be received in Tx2, or derived from the r and s parts, or received through some other means.

[0320] Optional security feature #1

[0321] If a signature based on k is published, anyone who knows the value of k can deduce the value of the key V used to create the signature. This can be achieved by cracking V in the signature equation below.

[0322] s = k -1 (H(m)+rV)mod n

[0323] Solving for V, we can obtain:

[0324] V = r -1 (sk-H(m))mod n

[0325] This poses no significant risk because in many cases, the recipient of the transaction is the only person who knows k. In other cases, the spender must be careful never to reuse the private key V, which is used to sign the solution to the r-problem. Good security practice suggests that users should ideally avoid reusing public / private key pairs (P,V) and always use a new public / private key pair when receiving new funds.

[0326] In principle, the public-private key pair (P,V) is "permanent." In other words, it can be used many times. The use of a random temporary key k should ensure this. However, there have been instances where the random number generator implementation has been flawed.

[0327] If two different messages are signed using the same temporary key k and the same private key, the private key V can be derived from these two signatures. That is, given (r, s) and k, V can be calculated, where r = [k·G]. c V is the private key of the public key P used in the signature. If the random number generator fails during the signing process, it may generate the same random number as before, thus exposing the private key to the public. To address this issue, people began to avoid reusing the public key instead of fixing the random number generator.

[0328] In this example, if Alice knows k but doesn't know Bob's private key V (his public key), when Alice passes k to Bob, Bob will be able to solve the puzzle by providing (r,s) using his private key. When Alice sees the signature, since she knows k, she will be able to deduce V. This is probably not what Bob wants. Therefore, Bob is better off avoiding reusing (P,V).

[0329] However, one problem with this approach is that Bob's public key p cannot be used as a persistent way to identify Bob.

[0330] To address this issue, according to the embodiments disclosed herein, Bob can include his additional signature sig2 in Tx2 using a separate private key V2 with a corresponding public key P2. He also includes P2 and the additional signature. Therefore, there are two types of public-private key pairs. The first type is a dynamically generated public-private key pair for one-time use. The other type is a public-private key pair generated according to some additional protocol (e.g., HD wallet). Bob can use the first type of key pair for r-problem signing and the second type of key pair for a second signature.

[0331] Then, based on the mapping between the public key and the identity, Alice can use that other public key to look up Bob's identity, such as Bob's proper name, username, or network address. For example, the mapping could be available in a public database that maps public keys to identities, or the mapping could simply be pre-agreed upon between Alice and Bob (e.g., privately stored on Alice's computer device 102a).

[0332] Consider again the signatory authorization use case. For example, Alice wants to receive a delivered item but may not be able to receive it in person. She provides Bob and Charlie with a copy of k so they can receive the item on her behalf. Dave is delivering a package and must obtain a signature with the expected value r. Now, suppose Dave also needs to verify the recipient's identity to meet his record-keeping or regulatory requirements.

[0333] Suppose Bob has the opportunity to receive a delivered item. If Bob generates his public key and signature based on k, then Alice and Charlie can both calculate Bob's private key V. This isn't a problem if the public key is only for one-time use. However, it's not ideal if Bob needs the public key in the future to prove his identity.

[0334] To address this issue, an implementation could include an additional signature in Tx2, independent of the r-problem that can be used to identify Bob. For example, an additional signature and the corresponding public key P2 could be added to the OP_RETURN output (an unspendable output) of the same transaction accepted by Dave. An alternative is to include an additional OP_CHECKSIG in the locking script of the r-problem transaction. By browsing the transaction and the public key used for the additional signature, Alice can determine who signed on her behalf.

[0335] In other cases, there might be concerns about the value k being leaked before it is used. To address this, Alice can add P2PKH to the r-puzzle transaction to improve security. Suppose Alice wants to delegate her signing authority to Bob. Alice obtains a one-time public key k from Bob and creates an r-puzzle transaction that specifies not only the value r but also an additional public key P2.

[0336] To allow Alice to sign as well, she can choose to create a 2-out-of-1 MultiSig. An example of a locking script is shown below:

[0337]

[0338] It should be noted that the r-problem increases flexibility because Alice can choose when to pass the solution to the r-problem (i.e., the signing right) to Bob. She can decide whether to continue, even after the transaction has been mined.

[0339] If k is leaked, the private key used to sign using the leaked k can be discovered. However, there is another private key, V2: this private key is linked to a private key that can be used to identify Bob's public key. To compromise the output, an attacker must obtain two separate secrets, which is much more difficult than simply leaking one of them.

[0340] It should be noted that in the example above, Tx2's locking script locks to Bob's additional public key P2 via regular P2PKH (unlocked via an additional signature instead of the signature used in the r-challenge). The r-challenge technique provides users with additional options. In some applications, the r-challenge may be necessary to allow provers to take on challenges regardless of identity. On the other hand, in some other applications, a combination of hashing puzzles and P2PKH may still be desirable, and the r-challenge can be optionally used in conjunction with it. This will be discussed in more detail later.

[0341] However, if the additional signature corresponding to P2 is required for identity lookup and / or security, but there is no locking script for Tx1 pre-bound to the identity of a specific prover as in P2PKH, the aforementioned locking script can be modified accordingly. In other words, it can only include Checksig on the additional signature, and not OP_EQUALVERIFY on the corresponding public key P2.

[0342] Optional security feature #2

[0343] Another potential security vulnerability in the above method is the forgery of signatures. This could be exploited by nodes attempting to claim funds (similar to a hash puzzle). A node receiving a transaction (from the spender) could alter the transaction to send funds to itself, using the same signature as in the original transaction.

[0344] The specific steps are as follows:

[0345] Let P = V·G be the public / private key pair used to sign the original transaction represented by m to obtain the signature (r,s), such that:

[0346] r = [k·G] x ,

[0347] s = k -1 (H(m)+rV)modn.

[0348] To spend this transaction, the spender will use the following unlock script:

[0349] < / d> < / r> < / nonce> < / d> < / r> < / t> < / d> < / r> < / s> < / s> <s> <s><r,s>

[0350] The node that receives the transaction can use the following new unlocking script to change the transaction into a new transaction (represented by m'), and send the funds to itself through this new transaction:

[0351] <P′><r,s>

[0352] Where P′=V′·H is a public / private key pair, such that:

[0353] V′=V+r -1 [H(m)-H(m′)],

[0354] P′=P+r -1 [H(m)-H(m′)]·G.

[0355] It should be noted that the nodes do not need to know V′ (because they do not know V). The verification process is completed using the following calculations:

[0356] R′=H(m)s -1 ·G+rs -1 ·P

[0357] If and only if (R′) x The signature is only valid when it is equal to r; otherwise, the signature is invalid.

[0358] For the new transaction m' and the new unlock script, the verification process is as follows:

[0359] R′=H(m′)s -1 ·G+rs -1 ·P′

[0360] =H(m′)s -1 ·G+rs -1 ·{P+r -1 [H(m)-H(m′)]·G}

[0361] =rs -1 ·P+H(m)s -1 ·G

[0362] =r

[0363] (It should be noted that the meaning of prime number representation here is different from that before—in this context, prime numbers do not refer to examples.)

[0364] To address this potential vulnerability, various embodiments can be implemented in another message m sighash The unlocking script includes an additional signature, sig′, which nodes cannot provide unless they know the key V. In this case, the unlocking script is:

[0365] <sig′>< / s> < / s> <s> <s><sig r >

[0366] sig' could be different message m sighash The signature on the message is so complex that to change the message, you simply need to use a different SIGHASH flag than the original message (e.g., SIGHASH_NONE instead of the default flag SIGHASH_ALL). Furthermore, sig' must use a different value for r so that it doesn't reveal the private key (since the private key can be derived from two signatures using the same ephemeral key). Finally, the transaction needs to include another OP_CHECKSIG at the end, as shown below.

[0367]

[0368] This requires using the same public key P as the r-problem, so that only someone who knows the private key V of public key P can create another signature, thus making the above attack impossible.

[0369] An attacker attempts to replace the public key with another public key whose private key the attacker does not know. To defend against this attack, the challenge also requires knowledge of the private key. In this case, one signature is insufficient. Therefore, two signatures are needed. Both signatures are considered proof of knowledge of the same private key. This is secure because the challenge emphasizes that the two signatures will have different ephemeral keys.

[0370] P2PKH+P2PRPH

[0371] Similar to using the r-problem as a proof of knowledge, the P2PKH output is also a proof of knowledge of the private key corresponding to the public key in the P2PKH output. This is essentially done by replacing the problem k with the public key P mapped to the P2PKH output. puzzle =V puzzle ·G's private key V puzzle This is achieved through [method / mechanism]. In the r-problem implementation, the knowledge proof is accompanied by a public key, which can be chosen by the prover and used to link to an identity. In P2PKH, the usual cost signature and public key (proving knowledge of the secret problem) must be accompanied by another signature and public key to link to a specific identity. Typically, the prover can add another signature and public key to the P2PKH unlock, which corresponds to another OP_CHECKSIG in the locking script, as shown below.

[0372]

[0373] The corresponding unlock script is shown below:

[0374] <sigP ID > <P ID > <sigP puzzle > <P puzzle >

[0375] It should be noted that, <sigP ID > <P ID There is no cryptographic link between the puzzle and even the transaction. In fact, anyone can replace them with another signature on another public key, which is somewhat similar to intercepting an unsolved hash puzzle. The interceptor cannot change the message to send funds to themselves (just like with an unsolved hash puzzle). However, nothing prevents them from doing so. <sigP ID > <P ID Replace it with your own identity to make it appear relevant to your identity.

[0376] On the other hand, based on the techniques disclosed in this paper, P2PKH and P2RPH can be used simultaneously in the same script to force the encrypted link on the second signature to prevent it from being intercepted and replaced as in the case described above.

[0377]

[0378] In the locked script, P puzzle =V puzzle ·G, and r=[R] x =[V puzzle ·G] x This makes them essentially equivalent. However, they are not actually equal because public keys can be both compressed and decompressed, and either way, a prefix is ​​added to the public key. The prefix can also be explicitly added to the script when extracting the r value from the signature to obtain... <H(P puzzle )>= <H(r puzzle As shown below. However, this did not actually bring much benefit.

[0379]

[0380] (It should be noted that in the illustrative representation of the locked script, H(...) is represented by triangular brackets <>, which actually refers to the hash value, not the hash function. The triangular brackets <> indicate that the value should be placed on the stack.)

[0381] The corresponding unlock scripts for these two transactions are shown below:

[0382] <P ID > <r puzzle ,s> <sigP puzzle > <P puzzle >

[0383] Alternative implementations in account-based models

[0384] The above description is largely based on the implementation in output-based models (e.g., UTXO-based models). However, it should be understood that this is not limiting. Figure 11 This demonstrates a possible alternative implementation using an account-based model.

[0385] In short, in an account-based model, the r-puzzle functionality can be included in a smart contract function invoked by the user. One party can set the r-puzzle value (or a hashed r-puzzle value) in the smart contract, and the other party then provides the signature to the smart contract.

[0386] In the UTXO blockchain architecture, the requirements contained in the unlocking script of the first transaction must be satisfied by the locking script of the second transaction for the second transaction to be considered valid and recorded in the blockchain. In the current context, this is advantageous because it leverages the work already done during the transaction verification process. As a concrete example in the current context, the fact that a transaction has been added to the blockchain means that it has been verified by nodes throughout the blockchain network, which in turn means that its locking script meets certain specific useful requirements. The relevant parties do not need to check whether these requirements are met themselves; they can simply assume that these requirements are met based on the fact that the transaction has been successfully re-encoded in the blockchain. This is because the script must return a "TRUE" result upon completion for the transaction to be valid (there may be other requirements for the transaction to be valid), and if the script returns a "FALSE" result (which, according to the terminology used in this paper, includes cases where the script fails, such as when the script terminates due to the OP_VERIFY opcode), the transaction is invalid.

[0387] However, in other blockchain models (e.g., some account-based architectures), this interdependence between transaction validity and the outcome of transaction code execution may not be reflected. For example, in some smart contract blockchains, transactions may be valid and therefore eligible to be recorded on the blockchain provided they meet a set of "basic" validity requirements imposed by the blockchain protocol. Therefore, even if a second transaction does not meet some of the requirements contained in the code of the first transaction, the second transaction may still be considered valid and recorded on the blockchain. For example, the code of the first transaction could be smart contract code.

[0388] Suppose the second transaction is for a smart contract account created by the first transaction. The smart contract code determines how to respond to that transaction. For example, if certain requirements are not met, it can be ignored (or a FALSE result can be returned), while if the requirements are met, the prover can be rewarded with digital assets deducted from and credited to the smart contract account's balance (or a TRUE result can be returned in other ways). In a sense, this abstracts the "proxy-level" processing of the smart contract (i.e., explicitly coded in the smart contract code) from the "protocol-level" processing (i.e., the processing of transaction execution) performed "implicitly" by the nodes to determine whether it meets the validity requirements imposed by the blockchain protocol by which the blockchain network operates. Therefore, in such a blockchain architecture, the "valid / invalid" decision made by the nodes at the protocol level in each transaction can be separated from the "TRUE / FALSE" result returned at the proxy level for that transaction via the smart contract, because the transaction can be determined to be valid at the protocol level but still return a FALSE result at the proxy level.

[0389] This is related to the UTXO architecture, in which a script that returns a "TRUE" result is required for a transaction to be valid; if the script terminates or completes, leaving anything other than TRUE on the stack, the transaction is invalid (in the terms used in this article, any of these results constitutes a "FALSE" result).

[0390] One of the fundamental requirements for a valid transaction is that it includes a valid signature. Therefore, while in the UTXO example above, the signature is verified by code that challenges the transaction itself (e.g., using an OP_CHECKSIG opcode that has already verified the signature and returns TRUE / FALSE for signature verification, or using an OP_CHECKSIGVERIFY opcode that checks the signature in the same way and additionally verifies the result as TRUE, or the script terminates if it doesn't), in alternative blockchain architectures, the signature can be implicitly verified by the processing node in the aforementioned sense, which avoids the need to encode signature checks within the transaction code itself.

[0391] As a concrete example in the current context, a transaction may be considered valid at the protocol level, for example, because it includes a valid signature, but still return a FALSE result at the application level, for example, because it does not meet some other requirements.

[0392] Figure 11 An alternative to node software 400, referred to herein as 400acc, for processing transactions according to an account-based model, is shown. Instances of this node software 400acc can be implemented at each node 104 of the account-based version of network 106. The account-based node software 400acc comprises an account-based protocol engine 401acc, a contract engine 402acc (somewhat similar to a script engine 402), an application-level decision engine 404, and a collection of one or more blockchain-related functional modules 405. At any given node 104, these modules may include any one, two, or all of the following three modules: a mining module 405M, a forwarding module 405F, and a storage module 405S (depending on one or more roles of the node). The protocol engine 401acc is configured to identify different fields of a transaction and process such fields according to the node protocol. The node software 400acc also maintains the account state 406 of each of the multiple accounts in the memory of the corresponding node 104. These accounts may include, for example, Alice's account, the prover's account (e.g., Bob's), and / or the account of another party that will be debited or credited according to the contract to be made between Alice and the prover. The contract engine 402acc is configured to modify the account state based on the results of smart contracts received in transactions. Smart contracts are also known as "agents".

[0393] Figure 11 A pair of transactions was also shown. and They can achieve the above-mentioned... Figures 7 to 10 The same or similar r-difficulty functions. Each transaction includes a source account address 1102 (in the source address field) and a destination account address 1103 (in the destination address field). First transaction This includes source account address 1102a and target account address 1103a. Second transaction. Includes source account address 1102b and target account address 1103b. First transaction. It also includes smart contract 1101. Smart contract 1101 may include Alice's Challenge (a puzzle). It can be created by Alice or by a third party acting on Alice's behalf using detailed information provided by Alice. Optionally, a second transaction... It may include one or more free data fields 1104 for carrying user-specified payload data. It may include at least a portion of a solution to a puzzle provided by a prover (e.g., Bob). Transaction and It was also signed by Alice and the witness, respectively. Each transaction also included the signatures of the corresponding parties, 1105a and 1105b.

[0394] Transactions are broadcast on network 106. When protocol engine 401acc receives each transaction, it implicitly verifies the validity of signature 1105. That is, this is an inherent feature of protocol engine 401acc and does not need to be specified in smart contract 1101. Therefore, protocol engine 401acc verifies the validity of each transaction used for forwarding and / or mining, at least under the condition that the corresponding signature is valid. It may also require one or more additional conditions to meet the validity requirements. If valid, application-level decision engine 404 can choose whether to control mining module 405M and / or forwarding module 405F to mine and / or forward transactions respectively.

[0395] In this account-based model, Alice, Bob, and the smart contract itself are assigned different accounts with different account addresses. Transactions are considered to be sent "from" the address in their source address field to the address in their destination address field. To create a smart contract account, a transaction containing the smart contract bytecode is uploaded to the blockchain. For such account creation transactions, the destination address 1103 in the destination field should be an address that has never been used in the blockchain, and once the transaction is accepted, this address becomes the address of the newly created smart contract account. Subsequently, another transaction can be sent to this address to "invoke" the smart contract, even if the smart contract's bytecode is able to run according to that other transaction. The "destination" address 1103 acts as an intermediary address for contract formulation—Alice will... Send to that address to create a smart contract specifying one or more requirements; Bob will Sending to the same address to invoke the smart contract, instead enabling smart contract verification. Does it meet those specified requirements? The "source" address 1102 specifies the account of the user who is a party to the contract—as determined in the smart contract. If the specified requirements are indeed met, a smart contract can be configured to deduct a digital asset amount from its own account balance, and make it possible for... The account with source address 1102b (i.e., Bob's account) has a balance of that amount (intuitively, by sending...). Bob effectively requests the smart contract (as identified in the target address field) to credit his account (as identified in the source address field).

[0396] When protocol engine 401acc receives When, under its valid conditions, it will search for and match The account matched by target address 1103b. Assume... Processed and valid; the account will be able to use it. And it exists and will be associated with the smart contract code provided in TX1. In response, protocol engine 401acc controls contract engine 402acc from Execute smart contract 1101, retrieving data as operand data from one or more fields of the smart contract according to the standards defined in the contract. Operand data may, for example, include data from one or more free data fields 1104 and / or a signature from the signature field 1105b. Operand data satisfies Under one or more criteria defined in smart contract 1101, contract engine 402acc modifies the account state 406 of one or more parties (Alice, the prover, and / or one or more third parties) according to the modifications defined in smart contract 1101. Otherwise, the account state 406 is not modified. However, it should be noted that in some account-based systems, the result of the smart contract is not a condition for the validity of the transaction. Therefore, if Failed to meet the requirements The standard set in smart contract 1101, then It will still be propagated and mined into the block as a record of failed transactions.

[0397] To implement the r-hard problem, at least some of the r-hard problem functionality can be encoded into... In smart contract 1101, and can be in The solution is presented in one or more data fields 1104. For example, this can be used to implement... Figure 7 A variant of this. Alternatively, some implicit signature verification features of the 401acc protocol engine can be utilized, for example, to implement... Figures 8 to 10 One of the variants. In Figures 8 to 10 In the case of a 401 Acc verification by the protocol engine When signing, steps II) and III) can be implicit functions of the 401acc protocol engine (please remember that signature verification itself is an inherent feature of the node protocol implemented by the 401acc protocol engine). Therefore, it is only necessary to... The smart contract 1101 places step I) above this point. The smart contract checks whether the result of I) is TRUE and whether the protocol engine 401ac indicates... Valid. If both are affirmative, then the overall result of the verification is declared as "TRUE," meaning Bob has successfully solved the challenge set by the r-problem. Note that in... Figures 8 to 10 In the implementation method, only Figure 9 and Figure 10 In this case, the data value d needs to be included in the free data field 1104. Signature information is included in the signature field 1105b.

[0398] Smart contract accounts also have indexed "data registers" (not shown), which are (logical) data storage elements associated with the account. In the UTXO model described above, the value is embedded in the locking script itself, and this may also be the case for a specific smart contract code 1101. However, the smart contract bytecode of a smart contract can alternatively or additionally operate on data stored in one or more of its account registers. Furthermore, values ​​can typically be stored in smart contract account registers after the smart contract account is created. Thus, for example, values ​​can be obtained through challenge transactions containing smart contract bytecode. To create a smart contract account, you can then send separate "intermediary" transactions to the (existing) smart contract account. Its function is to store a specific value v in the register $R of the smart contract account. The smart contract can be configured to accept only such data from a specified source account address (e.g., the same party that initially created the smart contract (Alice)). When received... At that time, the operation performed by the contract engine 402acc (e.g., "accessing register $R and matching that value with...") (Comparing values ​​in the data field $D) by Challenge Transaction The smart contract bytecode definition is provided in [the documentation]; however, the value stored in $R has been changed by the intermediary transaction. Settings. According to the terminology used in this document, It is still considered a challenge transaction that sets one or more requirements, but it can now be referenced in one or more intermediate transactions (e.g., These requirements are defined using the data provided in ().

[0399] Therefore, in some implementations, challenge transactions Operations for the r-hard problem can be defined (e.g., proving a transaction). The r part of the signature is compared with the value in register $R to see if they match, etc., but the value in $R is not the same as the value in the proof transaction. The value compared to the r part may have already been determined by the intermediary transaction. set up.

[0400] Also note: some account-based models do not require the public key P to be included in the signature 1105. Instead, only the 1-bit flag flg is needed. As mentioned above, two possible keys P and –P can be derived from (r,s) and the message. The flag flg is used to indicate which of the two possible solutions actually corresponds to the one used by the prover to verify the signature. The message is signed using the private key V and the public key. Protocol engine 401acc uses (r,s) and flg to derive the prover's public key P, instead of... The system explicitly receives this information. This technique is also possible in output-based models and is not specific to account-based models; however, many scripting languages ​​used in current output-based models happen to lack dedicated opcodes for deriving P from r and s. Therefore, explicitly encoding this functionality into the unlock script using existing generic opcodes in stack-based languages ​​would be complex. It should also be noted that some account-based models derive the source address of a transaction from the public key used to sign it. Therefore, the source address does not need to be encoded separately in the transaction, and since the public key is derived from the signature, this means the source address can also be indirectly derived from the signature.

[0401] in conclusion

[0402] It should be understood that the above embodiments are described by way of example only.

[0403] More generally, according to a first embodiment of the teachings disclosed herein, a computer-implemented method is provided, the method comprising, at a validator node of a blockchain network: obtaining a first transaction, the first transaction including executable code; receiving a second transaction, the second transaction containing information including at least a submission instance of the r portion and the s portion of a first ECDSA signature, and the information further including a random number; and executing the code of the first transaction. The code is configured to verify H. PoW If (f(r,d)) satisfies the predetermined conditions defined in the code, return TRUE if the predetermined conditions are met, where r is the submission instance of the r part, d is the random number, and H... PoW is a hash function, and f is a function that combines r and d.

[0404] In an embodiment, according to a second alternative embodiment disclosed herein, a method according to the first embodiment may be provided, wherein: f is a cascade of r||d.

[0405] According to a third alternative embodiment of this disclosure, a method according to the second embodiment can be provided, wherein the predetermined condition is H. puz (r||d) is less than a predetermined target value or has at least a predetermined minimum number of leading zeros.

[0406] According to a fourth alternative embodiment of this disclosure, a method according to the first, second, or third embodiment can be provided, the method comprising: obtaining a public key, wherein a first ECDSA signature is used to sign a message, which is part of a second transaction, based on a private key corresponding to the public key; applying an ECDSA verification function to verify the first ECDSA signature received in the second transaction based on the public key and the message, wherein code is configured to return a TRUE result under another condition of the verification of the first ECDSA signature.

[0407] In an output-based model (e.g., a UTXO-based model), the ECDSA verification function can be invoked by an opcode in the locking script of the first transaction's output (e.g., a UTXO). The opcode can invoke an instance of the ECDSA verification function pre-stored on the verification node. Alternatively, for example, in an account-based model, the ECDSA verification function can be an implicit function of the node, which runs automatically as part of the node protocol and does not require explicit invocation by the code in the first transaction (which could be a smart contract in the account-based case). As another alternative, it is not excluded that the ECDSA verification can be explicitly encoded into the code.

[0408] According to a fifth alternative embodiment, a method according to the fourth embodiment can be provided, wherein: the code further includes a reference value corresponding to the r portion of the first ECDSA signature, the reference value being a reference instance of the r portion or a transformation thereof; the code is configured to check whether the reference value corresponds to the reference instance of the r portion received in the second transaction, and to return the TRUE value if the reference value corresponds to the reference instance of the r portion received in the second transaction.

[0409] According to a sixth alternative embodiment, a method according to the fifth embodiment can be provided, wherein the reference value is a reference instance of the r portion of the ECDSA signature.

[0410] According to a seventh alternative embodiment, a method according to the sixth embodiment can be provided, wherein the code is configured to perform the following operations:

[0411] Check H PoW Does (f(r,d)) satisfy the predetermined condition?

[0412] The ECDSA verification function performs the following operations:

[0413] Calculate R′=H sig (m)s -1 ·G+r′s -1 ·P,

[0414] Check [R′] x =r′,

[0415] Where r′ is the reference instance of the r portion of the first ECDSA signature, s is the s portion of the first ECDSA signature, P is the first public key, m is the portion of the second transaction signed by the first ECDSA signature, and H sig is the hash function used to hash m when generating the first ECDSA signature, G is the ellipse generation point, [R′] x Let x represent the x-coordinate of R′, and "·" denote elliptic curve scalar multiplication. In this case, the code is configured to return a TRUE result if both checks are TRUE, otherwise return a FALSE result.

[0416] H PoW H is the hash function used in the hash puzzle. sig H is the hash function used in the ECDSA signature and verification. PoW and H sig It can be a hash function of the same form or not.

[0417] According to an eighth alternative embodiment, a method according to a sixth embodiment can be provided, wherein the code is configured to perform the following operations:

[0418] Check H PoW (f(r,d)) satisfies the preset condition.

[0419] Check r′=r,

[0420] The ECDSA verification function performs the following operations:

[0421] Calculate R′=H sig (m)s -1 ·G+rs -1 ·P,

[0422] Check [R′] x =r,

[0423] Where r is the submission instance of the r portion of the first ECDSA signature, r′ is the reference instance of the r portion of the first ECDSA signature, s is the s portion of the first ECDSA signature, P is the first public key, m is the portion of the second transaction signed by the first ECC signature, and H... sig is the hash function used to hash m when generating the first ECDSA signature, G is the ellipse generation point, [R′]. x The x-coordinate of R′ is represented by "·", and "·" indicates elliptic curve scalar multiplication. In this case, the code is configured to return the TRUE result if all three checks are TRUE, otherwise return the FALSE result.

[0424] According to a ninth alternative embodiment, a method according to the fifth embodiment can be provided, wherein: the reference value is a transformation of a reference instance of the r portion of the first ECDSA signature, and the code is configured to perform the check whether the submission instance corresponds to the reference value by performing the same transformation on the submission instance and comparing it with the reference value.

[0425] According to a tenth alternative embodiment, a method according to the ninth embodiment can be provided, wherein: the reference value is a hash value, and the hash value is the hash value of the reference instance of the r portion of the first ECDSA signature.

[0426] According to the eleventh alternative embodiment, a method according to the tenth embodiment can be provided, wherein the code is configured to perform the following operations:

[0427] Check H PoW (f(r,d)) satisfies the preset condition.

[0428] Check h=H puz (r),

[0429] The ECDSA verification function performs the following operations:

[0430] Calculate R′=H sig (m)s -1 ·G+rs -1 ·P,

[0431] Check [R′] x =r,

[0432] Where r′ is the reference instance of the r portion of the first ECDSA signature, r is the submission instance of the r portion of the first ECDSA signature, s is the s portion of the first ECDSA signature, h is the hash value, and H puz The hash function is used to hash r' to generate h, P is the first public key, m is the part of the second transaction signed by the first ECC signature, and H is... sig is the hash function used to hash m when generating the first ECDSA signature, G is the ellipse generation point, [R′]. x The x-coordinate of R′ is represented by "·", and "·" indicates elliptic curve scalar multiplication. In this case, the code is configured to return the TRUE result if all three checks are TRUE, otherwise return the FALSE result.

[0433] H puz H is the hash function used in the hash puzzle. puz It can be or cannot be related to H sig and / or H PoW Hash functions of the same form.

[0434] According to the twelfth alternative embodiment, a method can be provided in any one of the first to eleventh embodiments, wherein obtaining the first public key includes receiving the first public key as part of the information in the second transaction.

[0435] Alternatively, the information in the second transaction may include a submission instance of the s-part and the r-part of the first ECDSA signature, and the retrieval may include deriving the first public key from the combination of the submission instances of the s-part and the r-part of the first ECDSA signature.

[0436] As an alternative, it is not excluded that the acquisition may include: for example, receiving the first public key via a side channel associated with the second transaction; or, receiving, in the second transaction or via the side channel, the index of the first public key or the identity of the owner of the first public key and private key, and using it to find the first public key.

[0437] According to the thirteenth alternative embodiment, a method according to any one of the first to twelfth embodiments can be provided, wherein: the submission instance of the r portion and the s portion of the first ECDSA signature are generated by the second party using the following: a temporary key provided by the first party to the second party, and vice versa; a first private key, which is the private key of the second party; and the random number is also generated by the second party by performing a proof on the second party's computer device.

[0438] According to the fourteenth alternative embodiment, a method according to the thirteenth embodiment can be provided, wherein: P = V·G, k∈[1,n-1], R = k·G, r = [R] x s = k -1 (H sig (m)+rV)mod n, where P is the first public key, V is the first private key, k is the temporary key, G is the elliptic generator point, n is the prime modulus (the prime order of the generator point), m is the portion of the second transaction signed by the first ECDSA signature, and H sig This is the hash function used to hash m when generating the first ECDSA signature. [R] x The x-coordinate of R is represented by "·", and "·" indicates elliptic curve scalar multiplication.

[0439] According to the fifteenth alternative embodiment, a method according to the thirteenth or fourteenth embodiment can be provided, wherein receiving the second transaction includes receiving the second transaction from the second party.

[0440] According to the sixteenth alternative embodiment, a method according to any one of the thirteenth to fifteenth embodiments can be provided, the method comprising: triggering a service for the first party under the condition that the result returned by the code is TRUE.

[0441] For example, the service may have been commissioned by the first party, may be performed on behalf of the first party, and / or may be performed for the benefit of the first party. The service may be a computerized service, and the trigger may include automatically triggering the service.

[0442] By providing the temporary key to the second party ("Bob"), the first party ("Alice") is able to have Bob sign the service on her behalf without Bob revealing the temporary key k to the node or publishing it on the blockchain. Furthermore, since the process is not limited to any particular private key (or its corresponding public key), this means Alice can also provide a copy of the temporary key to a third party ("Charlie"), and either Bob or Charlie can then successfully sign the service. This is possible because the r-part serves as the challenge basis and is not mapped to any specific identity.

[0443] According to the seventeenth alternative embodiment, a method according to any one of the thirteenth to sixteenth embodiments can be provided, wherein: the information received in the second transaction includes another cryptographic signature by which the second party signs a portion of the second transaction using another private key of the second party, the other private key corresponding to another public key.

[0444] The other signature can be an ECC signature or another type, such as an RSA signature.

[0445] According to the eighteenth alternative embodiment, a method according to the seventeenth embodiment can be provided, wherein: the mapping can be used to enable the first party and / or a third party to find the identity of the second party based on the other public key.

[0446] For example, the identity could be the second party's personal name, company name, username, or web address. For example, the third party could be the provider of the aforementioned services.

[0447] According to the nineteenth alternative embodiment, a method according to the seventeenth or eighteenth embodiment can be provided, wherein: the code is configured to verify the other cryptographic signature using the other public key, and return the TRUE result under another condition that the other cryptographic signature is verified.

[0448] According to the twentieth optional embodiment, a method according to the seventeenth to nineteenth embodiments can be provided, wherein: the information received in the second transaction further includes an encrypted signature by which the first party signs a portion of the second transaction using the first party's private key.

[0449] In one embodiment, the method may include obtaining a public key corresponding to the private key of the first party, wherein the code is configured to verify the cryptographic signature of the second party and return the TRUE result if the cryptographic signature of the first party is verified.

[0450] In an embodiment, the mapping can be used to enable the second party and / or a third party to look up the identity of the first party based on the first party's public key. For example, the first party's identity can be the first party's personal name, company name, username, or network address.

[0451] According to the twenty-first optional embodiment, a method according to any one of the thirteenth to twentieth embodiments can be provided, wherein: the information received in the second transaction includes an additional ECDSA signature having an r portion having a value different from the first ECDSA signature, but using the same first private key as the first ECDSA signature; the code is configured to verify the additional ECDSA signature using the first public key, and return the TRUE result if the additional ECDSA signature is verified.

[0452] In some embodiments, the additional ECDSA signature can be used to sign a portion of the second transaction that is different from the first ECDSA signature.

[0453] According to the twenty-second optional embodiment, a method according to any one of the first to twenty-first embodiments can be provided, wherein: each transaction in the transaction includes a data structure including one or more inputs and one or more outputs, wherein each output includes a locking script, and each input includes an unlocking script and a pointer to the output of another transaction; wherein the code contains the locking script of the first transaction, wherein the information received in the second transaction includes the unlocking script in the input of the second transaction, and wherein the pointer in the input of the second transaction points to the output of the first transaction; and the method includes verifying the validity of the transaction at least if the code returns the TRUE result, and in response to the verification, including at least one of the following: including the second transaction in a transaction pool for mining into one or more blocks by the verification node; and / or forwarding the second transaction to at least one other node of the blockchain network.

[0454] For each of the plurality of transactions including the first and second transactions, at least some of the nodes in the network are configured to propagate each transaction if the transaction is valid, and at least some of the nodes in the network are configured to record each transaction in at least a portion of a copy of the blockchain if the transaction is valid. The validity of the second transaction depends at least on the code that returns the TRUE result.

[0455] According to the twenty-third optional embodiment, a method according to any one of the first to twenty-first embodiments can be provided, wherein: the transaction is configured according to an account-based model, and the code includes a smart contract included in the first transaction.

[0456] In embodiments, in any model, the verification node may be a mining node, a forwarding node, and / or a storage node storing at least a portion of the blockchain (e.g., a full copy storage node storing a complete copy of the blockchain). In embodiments, obtaining the first transaction may include receiving at least a portion of the first transaction from a first party (e.g., the aforementioned first party). In embodiments, obtaining the first transaction may include receiving the first transaction from the first party. Alternatively, in embodiments, obtaining the first transaction may include forming the first transaction at the verification node. In embodiments, obtaining the first transaction may include receiving at least the reference instance of the r portion from the first party and forming the first transaction at one of the nodes. In embodiments, obtaining the first transaction may include forming the first transaction, including generating the r portion at the verification node.

[0457] In one embodiment, receiving the second transaction may include receiving the second transaction from a second party (e.g., the second party described above). In another embodiment, the second transaction is at least partially generated by the second party. In yet another embodiment, the second transaction is generated by the second party. In yet another embodiment, receiving the second transaction may include receiving the second transaction directly from the second party or via the first party or a third party. In yet another embodiment, the second transaction is generated by a third party at least based on the s portion of the first ECDSA signature provided by the second party to the third party (and, in another embodiment, the submission instance and / or the data element of the r portion of the first ECDSA signature).

[0458] According to a twenty-fourth alternative embodiment of the teachings disclosed herein, a computer program may be provided, which is contained on a computer-readable storage medium and configured to perform the method described in any one of the first to twenty-third embodiments when run on a node of a network.

[0459] According to a twenty-fifth alternative embodiment of the teachings disclosed herein, a node of a network is provided, the node comprising: a memory including one or more storage units; a processing device including one or more processing units; wherein the memory stores code set to run on the processing device, the code being configured to, when on the processing device, execute the method according to any one of the first to twenty-third embodiments.

[0460] According to twenty-six alternative embodiments of the teachings disclosed herein, a computer-implemented method is provided, the method comprising: observing a first transaction on a second-party computer device, the first transaction including executable code configured to verify H PoW If (f(r,d)) satisfies the predetermined conditions defined in the code, return TRUE if the predetermined conditions are met, where r is the r part of the ECDSA signature, d is a random number, and H... Pow It is a hash function, f is a function combining r and d, where the r part is specified by the first party; the r part is generated based on the temporary key; the value of the random number d is searched such that H PoW (f(r,d)) satisfies the predetermined condition; a second transaction is formed in relation to the first transaction, the second transaction containing information including at least the r and s portions of the first ECDSA signature, and the information also including the random number d; the second transaction is sent to be propagated through the blockchain network so that it is recorded in the blockchain.

[0461] In an embodiment, the method performed on the second party's device may further include any of the embodiments or other features disclosed herein.

[0462] According to a twenty-seventh embodiment of the teachings disclosed herein, a set of transactions for recording in a blockchain is provided, the set of transactions comprising the following items contained on one or more computer-readable media: a first transaction, the first transaction comprising executable code; a second transaction, the second transaction containing information including at least a commit instance of the r portion and the s portion of a first ECDSA signature, and the information further comprising a random number; wherein the code is configured to verify H PoW If (f(r,d)) satisfies the predetermined conditions defined in the code, return TRUE if the predetermined conditions are met, where r is the submission instance of the r part, d is the random number, and H... PoW is a hash function, and f is a function that combines r and d.

[0463] In the embodiments, the first and second embodiments may also be configured according to any of the embodiments or other features disclosed herein.

[0464] According to a twenty-eighth embodiment of the teachings disclosed herein, a computer-implemented method can be provided, the method comprising, at a verification node of a blockchain network: acquiring a first transaction, the first transaction including executable code; receiving a second transaction, the second transaction containing information, the information including at least a first portion and a random number; and executing the code of the first transaction, the code being configured to verify H. PoW If (f(q,d)) satisfies the predetermined conditions defined in the code, return TRUE if the predetermined conditions are met, where q is the first part, d is the random number, and H... PoW q is a hash function, and f is a function that combines q and d.

[0465] Any features disclosed herein that relate to proofs based on the r-problem can be generalized to any such "level 2" proof.

[0466] The first part q can be any predetermined part of the data, or any part of the second transaction, except for the random number.

[0467] In embodiments, any features disclosed herein related to the r-problem proof problem can also be applied to this more general proof problem. For example, in embodiments, f is a cascade of q||d. In embodiments, the predetermined condition may be H. puz (q||d) is less than a predetermined target value or has at least a predetermined minimum number of leading zeros.

[0468] In an embodiment, the information received in the second transaction may further include a cryptographic signature. The method may include: obtaining a public key, wherein the cryptographic signature is used to sign a message, which is part of the second transaction, based on a private key corresponding to the public key. The method may include: applying a verification function to verify the cryptographic signature received in the second transaction based on the public key and the message, wherein the code is configured to return a TRUE result under another condition of the verification of the cryptographic signature. In an embodiment, the public key may be mapped to the identity of the prover. This can be used by a first party to find the identity of the prover.

[0469] According to other embodiments, a program, method, or transaction set corresponding to the twenty-eighth embodiment may be provided.

[0470] Once the disclosure herein is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of this disclosure is not limited to the described embodiments, but only to the appended claims.< / s> < / s> < / sig> < / h> < / sighashflag>

Claims

1. A computer-implemented method at a validator node in a blockchain network, the method comprising: Obtain first transaction data, the first transaction data including executable code, the code being configured to verify H. PoW If (f(r,d)) satisfies the predetermined conditions defined in the code, return TRUE if the predetermined conditions are met, where r is the r part of the first ECDSA signature, d is the random number nonce, and H PoW It is a hash function, f is a function combining r and d, wherein the r part is specified by the first party; and wherein the predetermined condition is H. PoW (f(r,d)) is less than a predetermined target value, greater than a predetermined target value, within a predetermined range, or has a predetermined minimum number of leading zeros; thus, the code sets a proof challenge, which requires a second party to perform a proof by searching for the value of the random number d on the second party's computing device, such that H PoW (f(r,d)) satisfies the predetermined condition; Receive second transaction data, the second transaction data containing information, the information including at least the submission instance of the r portion and the s portion of the first ECDSA signature, and the information also including the random number; and The code that executes the first transaction data verifies H. PoW Does (f(r,d)) satisfy the predetermined condition defined in the code? 2. The method according to claim 1, wherein f is a cascade of r||d.

3. The method according to claim 1 or 2, further comprising: Obtain a first public key, wherein the first ECDSA signature is used to sign a message based on a first private key corresponding to the first public key, and the message is part of the second transaction data; An ECDSA verification function is applied to verify the first ECDSA signature received in the second transaction data based on the first public key and the message, wherein the code is configured to return the TRUE result under another condition of the verification of the first ECDSA signature.

4. The method of claim 3, wherein the code further includes a reference value corresponding to the r portion of the first ECDSA signature, the reference value being a reference instance of the r portion or a transformation thereof; The code is configured to check whether the reference value corresponds to the reference instance of the r portion received in the second transaction data, and to return the TRUE value if the reference value corresponds to the reference instance of the r portion received in the second transaction data.

5. The method of claim 4, wherein the reference value is a reference instance of the r portion of the ECDSA signature.

6. The method of claim 5, wherein the code is configured to perform the following operations: Check H PoW Does (f(r,d)) satisfy the predetermined condition? The ECDSA verification function performs the following operations: Calculate R′=H sig (m)s -1 ·G+r′s -1 ·P, Check [R′] x =r′, Where r′ is the reference instance of the r portion of the first ECDSA signature, s is the s portion of the first ECDSA signature, P is the first public key, m is the portion of the second transaction data signed by the first ECDSA signature, and H sig is the hash function used to hash m when generating the first ECDSA signature, G is the ellipse generation point, [R′]. x Represents the x-coordinate of r′, and "·" indicates scalar multiplication of elliptic curves; The code is configured to return a TRUE result if both of the aforementioned checks are TRUE, and a FALSE result otherwise.

7. The method of claim 5, wherein the code is configured to perform the following operations: Check H PoW Does (f(r,d)) satisfy the predetermined condition? Check r′=r, in, The ECDSA verification function performs the following operations: Calculate R′=H sig (m)s -1 ·G+rs -1 ·P, Check [R′] x =r, Where r is the submission instance of the r portion of the first ECDSA signature, r′ is the reference instance of the r portion of the first ECDSA signature, s is the s portion of the first ECDSA signature, P is the first public key, m is the portion of the second transaction data signed by the first ECC signature, and H... sig is the hash function used to hash m when generating the first ECDSA signature, G is the ellipse generation point, [R′]. x Represents the x-coordinate of R′, and "·" indicates scalar multiplication of elliptic curves; The code is configured to return a TRUE result if all three checks are TRUE, otherwise return a FALSE result.

8. The method of claim 4, wherein the reference value is a transformation of the reference instance of the r portion of the first ECDSA signature, and the code is configured to perform the check whether the submission instance corresponds to the reference value by performing the same transformation on the submission instance and comparing it with the reference value.

9. The method of claim 8, wherein the reference value is a hash value, the hash value being the hash value of the reference instance of the r portion of the first ECDSA signature.

10. The method of claim 9, wherein the code is configured to perform the following operations: Check H PoW Does (f(r,d)) satisfy the predetermined condition? Check h=H puz (r), in, The ECDSA verification function performs the following operations: Calculate R′=H sig (m)s -1 ·G+rs -1 ·P, Check [R′] x =r, Where r' is the reference instance of the r portion of the first ECDSA signature, r is the commit instance of the r portion of the first ECDSA signature, s is the s portion of the first ECDSA signature, h is the hash value, and H puz The hash function is used to hash r' to generate h, P is the first public key, m is the portion of the second transaction data signed by the first ECC signature, and H is... sig is the hash function used to hash m when generating the first ECDSA signature, G is the ellipse generation point, [R′]. x Represents the x-coordinate of R′, and "·" indicates scalar multiplication of elliptic curves; The code is configured to return a TRUE result if all three checks are TRUE, otherwise return a FALSE result.

11. The method according to claim 3, wherein obtaining the first public key comprises: The first public key is received as part of the information in the second transaction data.

12. The method of claim 1, wherein the submission instance of the r portion and the s portion of the first ECDSA are generated by the second party using: a temporary key provided by the first party to the second party, or vice versa; and a first private key, which is the private key of the second party.

13. The method according to claim 12, wherein: P = V·G, k∈[1,n-1], R = k·G, r = [R] x ,and s = k -1 (H sig (m)+rV)modn, Where P is the first public key, V is the first private key, k is the temporary key, n is the prime modulus, G is the elliptic generator point, m is the portion of the second transaction data signed by the first ECDSA signature, and H... sig This is the hash function used to hash m when generating the first ECDSA signature. [R] x The x-coordinate of R is represented by "·", and "·" indicates elliptic curve scalar multiplication.

14. The method of claim 12 or 13, wherein receiving the second transaction data includes receiving the second transaction data from the second party.

15. The method of claim 12 or 13, wherein the method includes triggering a service for the first party under the condition that the result returned by the code is TRUE.

16. The method of claim 12 or 13, wherein the information received in the second transaction data includes another cryptographic signature by which the second party signs a portion of the second transaction data using another private key of the second party, the other private key corresponding to another public key.

17. The method of claim 16, wherein the mapping can be used to enable the first party and / or a third party to look up the identity of the second party based on the other public key.

18. The method of claim 16, wherein the code is configured to verify the other cryptographic signature using the other public key and return the TRUE result if the other cryptographic signature is verified under another condition.

19. The method of claim 16, wherein the information received in the second transaction data further includes a cryptographic signature by which the first party signs a portion of the second transaction data using the first party's private key.

20. The method according to claim 12 or 13, wherein: The information received in the second transaction data includes an additional ECDSA signature, which has an r portion with a value different from the first ECDSA signature, but uses the same first private key as the first ECDSA signature; The code is configured to verify the attached ECDSA signature using the first public key, and return the TRUE result if the attached ECDSA signature is verified.

21. The method of claim 1, wherein each transaction data in the transaction data includes a data structure, the data structure including one or more inputs and one or more outputs, wherein each output includes a locking script, and each input includes an unlocking script and a pointer to the output of another transaction data; The code contains the locking script of the first transaction data, the information received in the second transaction data contains the unlocking script in the input of the second transaction data, and the pointer in the input of the second transaction data points to the output of the first transaction data; The method includes verifying the validity of the transaction data at least if the code returns the TRUE result, and in response to the verification, including at least one of the following: - Include the second transaction data in the transaction pool so that it can be mined into one or more blocks by the verification node; and / or - Forward the second transaction data to at least one other node in the blockchain network.

22. The method of claim 1 or 2, wherein the transaction data is configured according to an account-based model, and the code includes a smart contract incorporated in the first transaction data.

23. A computer program product contained on a computer-readable storage medium and configured to perform the method according to any one of claims 1 to 22 when run on a node of a network.

24. A node in a network, the node comprising: The memory includes one or more storage units; A treatment device, the treatment device comprising one or more processing units; The memory stores code configured to run on the processing device, the code being configured to execute the method according to any one of claims 1 to 22 when running on the processing device.

25. A computer-implemented method on a second-party computer device, the method comprising: Observe the first transaction data, which includes executable code configured to verify H. PoW If (f(r,d)) satisfies the predetermined conditions defined in the code, return TRUE if the predetermined conditions are met, where r is the r part of the ECDSA signature, d is the random number nonce, and H... PoW It is a hash function, f is a function combining r and d, where r is specified by the first party; wherein the predetermined condition is H. PoW (f(r,d)) is less than a predetermined target value, greater than a predetermined target value, within a predetermined range, or has a predetermined minimum number of leading zeros; thus, the code sets a proof challenge, which requires the second party to perform a proof by searching for the value of the random number d, such that H PoW (f(r,d)) satisfies the predetermined condition; The r part is generated based on the temporary key; Search for the value of the random number d such that H PoW (f(r,d)) satisfies the predetermined condition; A second transaction data related to the first transaction data is formed. The second transaction data contains information, which includes at least the r and s portions of the first ECDSA signature, and also includes the random number d. Send the second transaction data to be transmitted through the blockchain network so that it is recorded in the blockchain.

Images