Blockchain Transactions

Abstract

A computer-implemented method for generating blockchain transactions is provided. A first locking script of a challenge blockchain transaction with a goal statement and a verification script for verifying a challenge solution π provided in a first unlocking script of a proof blockchain transaction are generated. The challenge solution π is a non-interactive zero-knowledge proof that proves knowledge of a private witness w. The first locking script, when executed with the first unlocking script, generates a candidate commitment value A based on the challenge solution π and the candidate statements provided in the goal statement and the first unlocking script. * and calculating the candidate commitment value A * and configured to calculate a candidate hash value using one of the target statement and the candidate statement, verify the challenge solution π based on the candidate hash value, and verify that the challenge solution π is provided in a proof blockchain transaction.

Description

[Technical field]

[0001] The present disclosure relates to a computer-implemented method for generating a blockchain transaction with a locked output based on a challenge, and a computer-implemented method for generating a blockchain transaction with an unlocking script for providing a challenge solution to unlock a locking script. [Background technology]

[0002] Blockchain refers to a form of distributed data structure, where a copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network") and made publicly available. The blockchain comprises a chain of blocks of data, where each block comprises one or more transactions. Each transaction, other than the so-called "coinbase transaction", points to a previous transaction in the sequence, which may span one or more blocks back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to the blockchain network are included in new blocks. New blocks are created by a process often referred to as "mining", which involves multiple nodes each competing to perform a "proof of work", i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered and validated outstanding transactions that are waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of blocks may be achieved by publishing only the block headers.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: to carry digital assets (i.e., a number of digital tokens), to order a set of journal entries in a virtualized ledger or register, to receive and process timestamp entries, and / or to time-order index pointers. A blockchain may also be utilized to overlay additional functionality onto the blockchain. For example, a blockchain protocol may allow for storing additional user data or indexes to data in a transaction. Since there is no pre-specified limit on the maximum data capacity that can be stored in a single transaction, increasingly complex data can be incorporated. For example, this may be used to store electronic documents, or audio or video data in the blockchain.

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

[0005] Nodes that successfully solve the proof-of-work puzzle to create the latest block are typically rewarded with a new transaction, called a "coinbase transaction," that distributes an amount of digital assets, i.e., a number of tokens. Detection and rejection of invalid transactions is performed by the activities of competing nodes, who act as agents of the network and have an incentive to report and prevent fraud. Public disclosure of information allows users to continuously audit the performance of nodes. Publishing only block headers allows participants to ensure the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every spendable output comprises an element that specifies an amount of a digital asset that is derivable from a preceding sequence of transactions. A spendable output may be called a UTXO (an “unspent transaction output”). An output may further comprise a locking script that specifies a condition for further redemption of the output. A locking script is a predicate that defines the condition required to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) may comprise a pointer (i.e., a reference) to such output in a preceding transaction and further comprise an unlocking script to unlock the locking script of the pointed-to output. Thus, consider a pair of transactions, which we call a first transaction and a second transaction (or a “target” transaction). The first transaction comprises at least one output that specifies an amount of a digital asset and comprises a locking script that defines one or more conditions for unlocking the output. The second target transaction comprises at least one input comprising a pointer to an output of the first transaction and an unlocking script for unlocking the output of the first transaction.

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

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred by referencing absolute account balances, rather than by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of all accounts is stored and periodically updated by nodes, separate from the blockchain. Summary of the Invention [Problem to be solved by the invention]

[0009] Most locking scripts are one of a limited number of types of locking scripts, including pay-to-public key (P2PK), pay-to-public key hash (P2PKH), and multi-signature. While these are suitable for many uses, it is desirable to extend the functionality of a blockchain by providing additional mechanisms for locking unspent transaction outputs (UTXOs). In addition, most locking scripts typically operate on the premise that they force the consumer of the UTXO to provide some data in the unlocking script of the spending transaction. This can create security and / or privacy issues in some situations. It is therefore beneficial to be able to lock UTXOs based on (secret) data without revealing that data in the unlocking script. [Means for solving the problem]

[0010] According to one aspect disclosed herein, a computer-implemented method for generating a blockchain transaction is provided, the method including generating a first locking script of a challenge blockchain transaction comprising a goal statement and a verification script for verifying a challenge solution π provided in a first unlocking script of a proof blockchain transaction, the challenge solution π being a non-interactive zero-knowledge proof providing knowledge of a private witness w, the first locking script, when executed together with the first unlocking script, generating a candidate commitment value A based on the challenge solution π provided in the first locking script and one of the goal statement and the candidate statements provided in the first unlocking script. * and calculating the candidate commitment value A *and a step configured to calculate a candidate hash value using one of the target statement and the candidate statement, verifying a challenge solution π based on the candidate hash value, and verifying that the challenge solution π is provided in a proof blockchain transaction; and a step of making the blockchain transaction available to one or more nodes of the blockchain.

[0011] Unlike standard puzzles, the solution to a zero-knowledge proof puzzle is never posted on-chain in the unlocking script (also referred to herein as the "scriptSig field") of the consuming transaction. Instead, the scriptSig field contains a mathematical proof that locates knowledge of the solution. This proof by itself does not reveal any information about the solution. Verification of the mathematical proof is performed in the Script, which is embedded in the locking script (also referred to herein as the "scriptPubKey field") of the transaction being consumed.

[0012] More specifically, a mathematical finite group of p elements

[0013]

number

[0014] The unlocking script for the spending transaction is a secret witness.

[0015]

number

[0016] The locking script of the transaction being spent contains a public statement that is also embedded in the locking script.

[0017]

number

[0018] Implement a verification algorithm that checks the correctness of π with respect to

[0019] As described in the detailed description, embodiments of the present disclosure provide a locking script that provides one or more of security, privacy, compatibility, and flexibility beyond at least some existing locking scripts.

[0020] To aid in the understanding of embodiments of the present disclosure and to show how such embodiments may be embodied, reference will be made, by way of example only, to the accompanying drawings in which: [Brief description of the drawings]

[0021] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] FIG. 1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Diagram 3] FIG. 2 is a schematic block diagram of some node software for processing transactions. [Figure 4a]

number

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

[0023] Each blockchain node 104 comprises a peer's computing equipment, with different nodes 104 belonging to different peers. Each blockchain node 104 comprises a processing unit comprising one or more processors, for example one or more central processing units (CPUs), accelerator processors, application specific processors and / or field programmable gate arrays (FPGAs), and other equipment such as application specific integrated circuits (ASICs). Each node also comprises a memory, i.e., computer readable storage in the form of a non-transitory computer readable medium. The memory may comprise one or more memory units utilizing one or more memory media, for example, magnetic media such as hard disks, electronic media such as solid state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0024] The blockchain 150 comprises a chain of blocks 151 of data, with a respective copy of the blockchain 150 maintained at each of a number of blockchain nodes 104 in a distributed network or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may be pruned of data, so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a certain type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one general type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing some quantity of digital assets as assets, such as a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to unlock and redeem or spend). Each input points to the output of a preceding transaction 152, thereby linking those transactions together.

[0025] Each block 151 also has a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) has a pointer to a previous transaction to define an order for the sequence of transactions (note that the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

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

[0027] In a given current transaction 152j, the input (or each input) comprises a pointer that references the output of a preceding transaction 152i in the sequence of transactions, which specifies that this output is to be redeemed or "consumed" in the current transaction 152j. Consumption or redemption does not necessarily imply a transfer of financial assets, although that is certainly one common application. More generally, consumption may be described as spending an output or allocating an output to one or more outputs in another forward transaction. In general, a preceding transaction may be any transaction in the ordered set 154 or any block 151. A preceding transaction 152i does not necessarily have to exist at the time the current transaction 152i is created or even sent to the network 106, but a preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to preceding in logical order linked by pointers, and not necessarily to time of creation or transmission in chronological order, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion of orphan transactions below). A preceding transaction 152i may also be referred to as an ancestor transaction or a predecessor transaction.

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

[0029] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wants to define a new transaction 152j (either manually or by an automated process used by the party), the defining party transmits the new transaction from his computer terminal 102 to a recipient. The defining party or recipient ultimately transmits this transaction to one or more of the blockchain nodes 104 of the network 106 (which today are usually servers or data centers, but in principle could be other user terminals). It is not excluded that the party 103 defining the new transaction 152j can transmit the transaction directly to one or more of the blockchain nodes 104 and in some instances not to the recipient. The blockchain nodes 104 receiving the transaction verify whether the transaction is valid according to a blockchain node protocol applied in each of the blockchain nodes 104. The blockchain node protocol usually requires the blockchain node 104 to verify that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may comprise verifying that a cryptographic signature or other authorization of a participant 103 included in the input of the new transaction 152j matches a condition defined in the output of a preceding transaction 152i that the new transaction consumes (or "allocates"), which condition typically comprises at least verifying that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of a previous transaction 152i that is connected to the input of the new transaction. This condition may be defined at least in part by a script included in the output of the preceding transaction 152i.Alternatively, it may simply be fixed by the blockchain node protocol alone, or it may be by a combination of these. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is disseminated throughout the network of blockchain nodes 104.

[0030] In an output-based model, the definition of whether a given output (e.g., UXTO) is allocated (e.g., spent) is whether it has already been validly redeemed by the input of another forward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not disseminated (unless it is flagged as invalid and disseminated for a warning) or recorded in the blockchain 150. This prevents double spending, such as when a transactor attempts to allocate the output of the same transaction more than once. On the other hand, an account-based model prevents double spending by maintaining an account balance. Again, since there is a defined order of transactions, the account balance has a single defined state at any given time.

[0031] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions, aided by "proof of work", in a process commonly referred to as mining. At the blockchain nodes 104, new transactions are added to an ordered pool 154 of legitimate transactions that have not yet appeared in a block 151 recorded in the blockchain 150. The blockchain nodes then compete to assemble a new legitimate block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this comprises looking for a nonce value such that when the "nonce" is concatenated with a representation of the ordered pool 154 of outstanding transactions and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition could be that the output of the hash has a certain number of leading zeros. Note that this is just one specific type of proof of work puzzle, other types are not excluded. The nature of a hash function is that it has an unpredictable output with respect to its input. This search therefore consumes a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle, as it can only be performed by brute force.

[0032] The first blockchain node 104 to solve the puzzle announces this to the network 106 and provides the solution as a proof that can be easily verified later by other blockchain nodes 104 in the network (given the solution to the hash, it is simple to verify that the output of the hash satisfies the conditions). The first blockchain node 104 disseminates the block to a threshold consensus of other nodes, which accept the block and therefore enforce the protocol rules. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. This large amount of effort, e.g. in the form of a hash, required to create the proof-of-work solution is indicative of the first node's 104 intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously validated transaction (otherwise known as double-spend). Once created, blocks 151 cannot be altered because they are known and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on blocks 151. Because transactions 152 are recorded in blocks that are ordered at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0033] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be competing to solve the puzzle based on different snapshots of the pool of not-yet-published transactions 154 at any given time, depending on when they started searching for a solution or the order in which transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of not-yet-published transactions 154 is updated. The blockchain nodes 104 then continue to compete to create blocks from the newly defined ordered pool of not-yet-published transactions 154, and so on. There are also protocols to resolve any "forks" that may arise, which are situations in which two blockchain nodes 104 solve a puzzle within a very short time of each other, resulting in conflicting views of the blockchain being propagated between the nodes 104. That is, whichever tip of the fork has grown longer will be the final blockchain 150. Note that this should not affect users or agents of the network, since the same transactions appear in both forks.

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

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

[0036] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective role and handle transactions 152 according to the blockchain node protocol. It will be understood that any activity attributable to this specification for the blockchain node 104 may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer such as the operating system layer or protocol layer, or any combination thereof.

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

[0038] Some or all of the participants 103 may be connected as part of a different network, for example a network superimposed on the blockchain network 106. Users of the blockchain network (often called "clients") may be said to be part of a system including the blockchain network 106. However, these users are not blockchain nodes 104, as they do not perform the role required of a blockchain node. Instead, each participant 103 may interact with the blockchain network 106, thereby utilizing the blockchain 150, by connecting to (i.e., communicating with) the blockchain node 106. Two participants 103 and their respective devices 102 are shown for illustrative purposes: a first participant 103a and its respective computer device 102a, and a second participant 103b and its respective computer device 102b. It will be understood that more such participants 103 and their respective computer devices 102 may be present and participating in the system 100, but for convenience they are not shown. Each participant 103 may be an individual or an organization. Purely by way of example, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be understood that this is not limiting and that any reference to Alice or Bob herein may be replaced with "first party" and "second party," respectively.

[0039] The computing device 102 of each participant 103 comprises a respective processing device comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing device 102 of each participant 103 further comprises a memory in the form of a non-transitory computer readable medium, i.e. computer readable storage. This memory may comprise one or more memory units utilizing one or more memory media, e.g. magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing device 102 of each participant 103 stores software comprising a respective instance of at least one client application 105 adapted to execute on the processing device. It will be understood that any activity attributable to this specification for a given participant 103 may be implemented using software executed on the processing device of the respective computing device 102. The computing device 102 of each participant 103 comprises at least one user terminal, e.g. a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing equipment 102 of a given participant 103 may also include one or more other networked resources, such as cloud computing resources accessed via a user terminal.

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

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

[0042] NOTE: Although various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may be implemented in a series of two or more separate applications, for example interfacing via an API or one plugging into the other. More generally, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination of these. The following is described with respect to client application 105, but it will be understood that this is not limiting.

[0043] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions in which the respective participant 103 is a recipient (or in an embodiment, actually investigate other participants' transactions in the blockchain 150, since the blockchain 150 is a public entity that provides credibility to transactions in part by virtue of its public presence). The wallet function of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As mentioned above, each blockchain node 104 executes software configured to validate transactions 152 according to a blockchain node protocol and forward them to disseminate the transactions 152 throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is accompanied by a given node protocol, and together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0044] When a given party 103, for example Alice, wants to submit a new transaction 152j to be included in the blockchain 150, she organizes the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. She then transmits the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, the blockchain node 104 handles the new transaction 152j according to the blockchain node protocol and its respective role. This comprises first verifying whether the newly received transaction 152j satisfies some condition for being "legitimate", an example of which will be discussed in more detail shortly. In some transaction protocols, the condition for validity check may be configurable per transaction by a script included in the transaction 152. Alternatively, this condition may simply be a built-in feature of the node protocol, or may be defined by a combination of the script and the node protocol.

[0045] Provided that the newly received transaction 152j passes the test to be considered valid (i.e., it is "validated"), every blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set 154 of transactions maintained at that blockchain node 104. Additionally, every blockchain node 104 that receives the transaction 152j disseminates the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, assuming the transaction 152j is valid, this means that it will soon be disseminated throughout the network 106.

[0046] Once granted access to the ordered pool 154 of outstanding transactions maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle for the latest version of each pool 154 that contains the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different pools 154 of transactions, but whoever gets there first defines the set of transactions contained in the latest block 1511. Eventually, the blockchain node 104 solves the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that contains the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 has a pointer to an earlier transaction, the order of the transactions is also immutably recorded.

[0047] Because different blockchain nodes 104 initially receive different instances of a given transaction, they may have conflicting views of which instance is "valid" before an instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts an instance as valid and discovers that a second instance has been recorded in the blockchain 150, it will accept it and discard (i.e., treat as invalid) the instance it first accepted (i.e., the instance not published in block 151).

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

[0049] 2. UTXO-Based Model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a basic data structure of the blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not a limitation to all possible embodiments. Note that although the exemplary UTXO-based protocol is described with reference to Bitcoin, it may also be implemented on other exemplary blockchain networks.

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

[0051] Suppose Alice 103a wants to create a transaction 152j that transfers a target amount of digital assets to Bob 103b. In Figure 2, Alice’s new transaction 152j is written as “Tx 1 " It will be named. Tx 1takes the amount of digital assets locked in Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is denoted in FIG. 2 as “Tx 0 " It will be named. Tx 0 and Tx 1 are just arbitrary names. They are 0 does not necessarily mean that this is the first transaction on blockchain 151, 1 It does not mean that Tx is the next transaction in the pool 154. 1 may point to any preceding (i.e., ancestor) transaction that still has unconsumed outputs 203 locked to Alice.

[0052] Preceding transaction Tx 0 Alice creates a new transaction Tx 1 When Tx is created, or at least when she sends it to the network 106, it may already have been validated and included in a block 151 of the blockchain 150. It may already have been included in one of the blocks 151 at that point, or it may still be waiting in the ordered set 154, in which case it will be included in a new block 151 shortly. Alternatively, Tx 0 and Tx 1 , may be compiled together and sent to the network 106, or, if the node protocol allows for buffering of "orphan" transactions, Tx 0 Tx 1The terms "predecessor" and "successor" as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence as defined by transaction pointers specified in the transaction (such as which transaction points to which other transaction). They may be equally replaced by "predecessor" and "successor", or "ancestor" and "descendant", "parent" and "child", etc. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a preceding transaction (ancestor transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for some time to wait for the parent, depending on the node protocol and / or node behavior.

[0053] Preceding transaction Tx 0 One of the one or more outputs 203 of 0 Each UTXO comprises a value that specifies the amount of the digital asset represented by the UTXO, and a locking script that defines the conditions that must be met by the unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and thus for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction in which the locking script is included). That is, the locking script defines the unlocking conditions, which typically comprise a condition that the unlocking script in the input of the subsequent transaction comprises a cryptographic signature of the party for which the preceding transaction is locked.

[0054] A locking script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A locking script specifies what information is needed to consume the transaction output 203, e.g., requirements for Alice's signature. An unlocking script appears in the output of a transaction. An unlocking script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, it may include Bob's signature. An unlocking script appears in the input 202 of a transaction.

[0055] Thus, in the example shown, Tx 0 UTXO in output 203 0 UXTO 0 To be able to redeem (strictly speaking, UTXO 0 For a subsequent transaction attempting to redeem the token to be valid, Alice's signature Sig P A Locking script that requires [Checksig P A ]. [Checksig P A ] is the public key P from Alice’s public-private key pair. A Contains a representation (i.e., a hash) of Tx 1 The input 202 of the Tx 1 (For example, its transaction ID, TxID 0 Pointed to by TxID 0 In the embodiment, the whole transaction Tx 0 A pointer to the Tx 1 The input 202 of the Tx 0 UTXO from all other possible outputs of 0 To identify the Tx 0 UTXO within 0It has an index that identifies the Tx 1 The input 202 is an unlocking script with Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined piece of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.

[0056] New transaction Tx 1 When the arrives at a blockchain node 104, the node applies the node protocol, which comprises running the locking script and the unlocking script together to see if the unlocking script meets the conditions defined in the locking script (which may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] Here, "||" denotes concatenation, "<...>" means to put data on the stack, and "[...]" are functions to be included in the locking script (in this example, a stack-based language). Equivalently, rather than concatenating the scripts, the scripts may be executed one after the other using a common stack. Either way, when executed together, the scripts will be executed in the order Tx 0 Alice's public key P, as included in the locking script in the output of A Using Tx 1 The input of Tx authenticates that the unlocking script contains Alice's signature, which signs the expected portion of the data. The expected portion of the data itself (the "message") must also be included in order to perform this authentication. In an embodiment, the signed data is 1(Thus, there is no need to include a separate element that specifies the signed portion of the data in plaintext, since it is already there).

[0057] The details of public-private cryptographic authentication are familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the message in plaintext, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically comprises hashing the message, signing the hash, and tagging this as the signature onto the message, allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular piece of data or transaction, etc., may, in an embodiment, mean signing a hash of that data or transaction piece.

[0058] Tx 1 The unlocking script in Tx 0 If one or more conditions specified in the locking script of 1 If provided and authenticated in Tx 1 This means that the blockchain node 104 considers Tx 1 The blockchain node 104 also notifies one or more other blockchain nodes 104 in the network 106 of the transaction Tx 1 , so that it is disseminated throughout the network 106. 1 Once validated and included in the blockchain 150, it is consumed as Tx 0 UTXO from 0 Define Tx 1Note that Tx can only be legal if it consumes an unconsumed transaction output 203. If Tx attempts to consume an output that has already been consumed by another transaction 152, 1 is invalid even if all other conditions are met. Therefore, the blockchain node 104 0 It is also necessary to ascertain whether a referenced UTXO in has already been spent (i.e., has already formed legal input into another legal transaction). This is one reason why imposing a prescribed ordering on transactions 152 is important for the blockchain 150. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 a transaction 152 has spent therein, but ultimately what defines whether a UTXO is spent is whether the UTXO has already formed legal input into another legal transaction in the blockchain 150.

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

[0060] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it cannot "leave behind" part of the amount defined in the UTXO as being spent while another part is being spent. However, the amount from the UTXO can be split among multiple outputs of subsequent transactions. For example, Tx 0 UTXO in 0 The amount defined in is Tx 1 Therefore, if Alice receives a UTXO 0If she does not want to give Bob the full amount defined in Tx 1 The remainder of the second output can be given to yourself or paid to another party.

[0061] In practice, Alice should normally also include a fee for any Bitcoin nodes 104 that succeed in including her transaction 104 in block 151. If Alice does not include such a fee, Tx 0 may be rejected by a blockchain node 104 and therefore not disseminated and included in the blockchain 150, even if technically valid (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not want to do so). In some protocols, transaction fees do not require a unique separate output 203 (i.e., do not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, a UTXO 0 A pointer to Tx 1 is the only input to the Tx 1 is the only output UTXO 1 Let us assume that we have UTXO. 0 The amount of digital assets specified in 1 If the difference is greater than the amount specified in 1 However, it is not necessarily precluded that a transaction fee may alternatively or additionally be explicitly specified in its own one of the UTXOs 203 of transaction 152.

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

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

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

[0065] A locking script is sometimes referred to as a "scriptPubKey", referring to the fact that the locking script typically comprises the public key of the party for which the respective transaction is locked. An unlocking script is sometimes referred to as a "scriptSig", referring to the fact that the unlocking script typically provides a corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for allowing a UTXO to be redeemed comprises authenticating a signature. More generally, a scripting language may be used to define any condition or conditions. Thus, the more general terms "locking script" and "unlocking script" are sometimes preferred.

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

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

[0068] 4. Node Software FIG. 3 illustrates an example of node software 450 executed on each blockchain node 104 of the network 106 in the example of the UTXO-based model or the output-based model. Note that another entity may execute the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the activities required of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may execute node software including, but is not limited to, all three of the following: an agreement module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 401 is typically configured to recognize different fields of a transaction 152 and process them according to the node protocol. Another preceding transaction 152i (Tx m-1 ) j ) is received, the protocol engine 451 j The protocol engine 451 also identifies the unlocking script in Tx j Based on the pointer in the input of Tx i Identify and extract. Tx i may be published on the blockchain 150, in which case the protocol engine derives Tx i Alternatively, Tx i , Tx may not yet be published on the blockchain 150. In that case, the protocol engine 451 selects Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i In any case, the script engine 451 may extract Txi locates the locking script in the referenced output of and passes it to the script engine 452.

[0069] Therefore, the script engine 452 executes the Tx i Locking script and Tx j For example, Tx 0 and Tx 1 2, the same can be true for any pair of transactions. The script engine 452 executes the two scripts together as previously discussed, which includes putting data on and taking data off the stack 453 according to the stack-based scripting language being used (e.g., Script).

[0070] By executing the scripts together, the script engine 452 determines whether the unlocking script meets one or more criteria defined in the locking script, i.e., whether the unlocking script "unlocks" the output in which the locking script is included. The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlocking script meets one or more criteria specified in the corresponding locking script, the script engine 452 returns the result "true". Otherwise, it returns the result "false".

[0071] In the output-based model, the result "true" from the script engine 452 is one of the conditions for the validity of a transaction. j the aggregate value of the Digital Assets specified in the output of Tx will not exceed the aggregate value indicated by its input; iThere are also one or more further protocol-level conditions that must be satisfied as well, which are evaluated by protocol engine 451, such as that the pointed-to output of has not already been consumed by another legitimate transaction. Protocol engine 451 evaluates the result from script engine 452 together with one or more protocol-level conditions and accepts transaction Tx only if they are all true. j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. j Only if Tx is actually validated, the decision engine 451 controls both the agreement module 455C and the propagation module 455P to j This is because the consensus module 455C may choose to perform the respective blockchain-related functions for Tx j 4 to the ordered set of transactions of each node, and the propagation module 455P j to another blockchain node 104 in the network 106. Optionally, in an embodiment, the application level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to publish a transaction only if the transaction is legitimate and leaves sufficient transaction fees.

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

[0073] 5. Zero-Knowledge Proofs

[0074]

number

[0075] Let be a finite group of order p,

[0076]

number

[0077] Let be the ring of exponents.

[0078]

number

[0079] The elements in are lowercase

[0080]

number

[0081] It is written as

[0082]

number

[0083] The elements in are in uppercase.

[0084]

number

[0085] It is expressed as:

[0086]

number

[0087] A vector of n elements in

[0088]

number

[0089] Similarly,

[0090]

number

[0091] A vector of m elements in

[0092]

number

[0093] The symbol + is written as

[0094]

number

[0095] Group operations (in additive notation) and rings

[0096]

number

[0097] It is used for both addition in (mod p addition).

[0098] p does not have to be a prime number. However, in a realistic realization, p is a prime number. Usually,

[0099]

number

[0100] is set as an elliptic curve of prime order.

[0101] 5.1 Sigma Protocol Let R be an NP-relation, i.e., {0,1} such that (st,w)∈R. * ×{0,1} * A subset of w may be identified in polynomial time of length st, where the length of w is also a polynomial of length st.

[0102] The first element of the tuple is called the statement, which is public information. The second element is called the witness (of the statement), which is private. There may be more than one witness for a given statement. The induced NP language L R is a set of statements. LR:={st:∃w such that (st,w)∈R}

[0103] In this paper, we use the Camenish-Stadler notation to represent a set of witnesses (knowledge set). ZKPoK(st) :={w:(st,w)∈R} It is written as follows.

[0104] This notation is used herein because it is convenient to concisely distinguish between statements st, witnesses w, and the predicates R that act on them.

[0105] The Sigma protocol is a three-round protocol between a prover and a verifier with the following structure: both parties receive a statement st as input. In addition, the prover receives a witness w as an extra input. 1. The prover computes a commitment A using randomness a. It then sends A to the verifier while keeping a secret. 2. The verifier randomly samples a challenge e and sends it to the prover. 3. The prover computes the answer z (using w and a) and sends it to the verifier. 4. The verifier accepts statement st as valid or invalid based on the public transcript π:=(A,e,z).

[0106] The properties of the Sigma Protocol are as follows: Completeness. If (st, w) ∈ R, the verifier accepts with probability 1. Special soundness. For any pair of accepted transcripts π = (A, e, z), π' = (A, e', z') with the same commitment A (the prover's first message) and distinct challenges e ≠ e', it is possible to compute a witness w such that (st, w) ∈ R. Special honest verifier zero-knowledge (SHVZK). st∈L R There exists a polynomial-time algorithm Sim that, given a random e as input, outputs an acceptance transcript π = (A, e, z) that is indistinguishable from the protocol transcript.

[0107] Special soundness implies the stronger property that the Sigma protocol is also a (witness) proof of knowledge.

[0108] SHVZK also implies the standard notion of (correct verifier) ​​zero-knowledge, where a simulator is responsible for simulating a transcript as it receives statements as input. In other words, SHVZK guarantees that, assuming the verifier behaves as specified, exchanged messages do not leak information about the witnesses.

[0109] 5.2 Relations based on group homomorphisms NP statements about elements of groups of prime order are considered here, including elliptic curves. Prime p, group of order p

[0110]

number

[0111] , and one-way homomorphisms

[0112]

number

[0113] Consider the binary relation

[0114]

number

[0115] Then, the knowledge set

[0116]

number

[0117] is obtained.

[0118] The protocol presented in Figure 4a has been shown to be sound and SHVZK. Given a vector of group elements,

[0119]

number

[0120] For

[0121]

number

[0122] Knowledge of

[0123]

number

[0124] This is proved under

[0125] 5.3 Simulating a Transcript Input points

[0126]

number

[0127] (Derived from the statement) and a simulator algorithm for zero-knowledge about the challenge e

[0128]

number

[0129] does the following: 1. Random

[0130]

number

[0131] Sampling 2.

[0132]

number

[0133] Calculate 3. Simulated Proofs

[0134]

number

[0135] Output

[0136] The simulated proof passes the test formula, so it is perfectly valid for the verifier. In fact, if e is random, it partitions into perfectly valid proofs. A simulation of this particular method shows that the first message

[0137]

number

[0138] Note that a dishonest prover involved in the interactive protocol described in Fig. 4a cannot do this since it is only possible if the challenge e is known when generating

[0139] Proof simulation is not only useful for asserting that no information about witnesses is leaked (since one can generate transcripts as in protocols without using witnesses), but the algorithm can also be used to prove OR statements, as presented in Section 5.5.

[0140] 5.4 Conjunctive proofs An AND proof is a proof of (possibly different) relations R 1 ,…,R s prove the knowledge of n independent witnesses of the relation

[0141]

number

[0142] When constrained to , the knowledge set for the AND relation is

[0143]

number

[0144] It is.

[0145] R AND teeth,

[0146]

number

[0147] is a composition group homomorphism

[0148]

number

[0149] This can be seen as yet another protoimage knowledge relation such that

[0150] Z AND The protocol is

[0151]

number

[0152] Simply follow the protocol in Figure 4a for all

[0153]

number

[0154] Note that the same challenge is used to prove preimage knowledge of

[0155] 5.5 Disjunctive proofs In this scenario, the goal is to verify the witness' knowledge of at least one statement in r. The knowledge set of the OR relation is

[0156]

number

[0157] It is.

[0158] The idea of ​​OR proofs is to let the prover simulate all but one of the proofs, i.e., the prover can simulate proofs for statements for which he does not know the witness, but is not given too much freedom in choosing the challenges (the prover can choose exactly r-1 challenges). In this way, the prover is forced to prove knowledge of the witness for at least one relation.

[0159] For more information, see st j Let be a genuine statement, i.e. the prover

[0160]

number

[0161] Suppose we know w such that . Proof π for i ≠ j i Sigma Protocol

[0162]

number

[0163] Simulator

[0164]

number

[0165] (see Section 5.3) and the challenge e i However, the challenge for the jth proof is chosen in advance based on the other challenges and on the fact that the verifier has all the commitments.

[0166]

number

[0167] This is entirely determined by an offset value, also referred to herein as the offset challenge, given by the verifier after seeing π j Ensure that the

[0168] Figure 4b shows the Σ OR An interactive version of the protocol is presented.

[0169] 5.6 Dialogue Elimination - FIAT-SHAMIR Heuristic It is desirable to restrict communication to only one message from the prover to the verifier.

[0170] The Sigma protocol is an example of a public-coin interactive proof system, i.e. the message (challenge) sent by the verifier is random and unrelated to the prover's message. This feature can be exploited to make the interactive Sigma protocol non-interactive by simulating the verifier's entropy used to sample the challenge e with a cryptographic hash function. This is known as the Fiat-Shamir heuristic.

[0171] The Fiat-Shamir heuristic operates in a stronger security model, where cryptographic hash functions are modeled as functions that, for any novel input bit string, output a uniformly distributed sequence of bits. In this security model, well-known hash functions such as SHA256 can take any bit string and make it

[0172]

number

[0173] A "random oracle" function that maps to challenges in RO:{0,1} * →C, where the prover

[0174]

number

[0175] By setting

[0176]

number

[0177] We can see that,is the (public) transcript that occurs immediately after the challenge,e,is generated by the verifier in the interactive,Sigma protocol.

[0178] The assumptions about the RO function ensure two things. First, the challenge e is randomly distributed, so zero knowledge for a valid verifier is sufficient. Second, the prover knows the commitment

[0179]

number

[0180] Since we cannot compute the challenge before computing s (and statement s for that problem), we cannot reverse the order of execution of the protocol.

[0181]

number

[0182] The latest is true as long as the challenge space is large enough that we can never reach a (unique) challenge that allows simulation, i.e.,

[0183]

number

[0184] (See Section 5.3.) * The probability of reaching

[0185]

number

[0186] It is.

[0187] 5.6.1 Binding Information to Non-Interactive Proofs Any public context information ctxt can be associated with the proof by prepending the context information to the input of the random oracle RO. This means that such information is guaranteed to be issued by the prover (since only the prover can attest to the knowledge of the witness) since the challenge e also depends on ctxt. In particular, the challenge e for a non-interactive Sigma proof is

[0188]

number

[0189] is generated as:

[0190] 5.6.2 Shorter Proofs To reduce the size of the solution to the puzzle, specifically the size of the Σ-proof π, we can convert the transmitted proof into a commitment.

[0191]

number

[0192] An equivalent verification procedure can be used that allows for the proof to be removed.

[0193]

number

[0194] It is defined as follows.

[0195] [Table 1]

[0196] 6. Zero-knowledge puzzle specifications Zero-knowledge puzzles can be solved in any NP language that supports Script verification. i A language L is an NP language L (see Section 5.1) that arises from AND / OR combinations of i (again, with Script verification) is referred to as a puzzle. A solution to a puzzle is a statement st∈L together with a non-interactive zero-knowledge proof π(nizk) that proves its correctness. A non-interactive zero-knowledge proof π may also be referred to herein as a proof or a challenge solution.

[0197] Path to Identifying Zero-Knowledge Puzzles: Identifying zero-knowledge puzzles consists of defining Script algorithms for the different verifiers from Section 5. These are centralized through the generic non-interactive verifier described in Section 5.6.2.

[0198] Specifying a script for this generic verifier is done by using the group homomorphism

[0199]

number

[0200] Answer

[0201]

number

[0202] This means that we need to be able to instantiate a random oracle by applying

[0203] Section 6.1 below describes the abstract structure (template) of a zero-knowledge puzzle script. Section 6.2 provides a concrete instantiation of the random oracle function RO in Script (see Section 5.6). The remaining sections deal with the on-chain implementation of (non-interactive versions of) verifiers: Section 6.3 implements the preimage-knowledge verifier from 4a, Section 6.4 implements an AND verifier, and Section 6.5 implements an OR verifier.

[0204] 6.1 The structure of the zero-knowledge puzzle as a consumption condition The steps required to construct a zero-knowledge puzzle as a locking script, and its solution as a corresponding unlocking script, are described below.

[0205] 6.1.1 Binding Spending Transactions to NIZK Proofs Integrity of spending transactions (transactions that provide the solution to the puzzle in the unlocking script) against fraudulent miners or man-in-the-middle attackers, which is enforced at the script engine 452 level.

[0206] The integrity of the transaction is verified using a dummy signature technique. A digital signature tx_dummy_sign:=(r,s), generated using a signing key and, optionally, an ephemeral key fixed at 1, is included in the unlocking script. The dummy signature can be an ECDSA signature. This signature on secp256k1 allows the opcode OP_CHECKSIG to be used to ensure integrity.

[0207] It will be appreciated that other forms of ensuring transaction integrity may be used, for example injection techniques such as the so-called OP_PUSHTX technique. The dummy signature technique is used herein because it is more efficient than other known techniques.

[0208] Once verified, the tx_dummy_sign is used as context information to generate a non-interactive challenge on-chain (again, see Section 6.2).

[0209] 6.1.2 Generating a locking script The locking script can be generated using the following steps. 1. Write out the NP language of the use case. In its more general form, the language is in disjunctive normal form

[0210]

number

[0211] can be expressed as, where

[0212]

number

[0213] is any group homomorphism

[0214]

number

[0215] It is a proto-image knowledge language for. 2. Using the modular framework in the next section, we develop the resulting verifier script [Σ L -verifier]. 3. Let st∈L be a public statement. Hard-code it in the locking script (alternatively, for "puzzle as address", hard-code the hash of the statement).

[0216] The locking script generated by following the steps above is

[0217]

number

[0218] where G denotes the basis point of the curve secp256k1, st is the goal statement, and [Σ L -verifier] is a verification script for verifying the challenge solution π. As presented in more detail below, the verification script provided in the locking script depends on the application, i.e., the type of puzzle used. When executed, the locking script checks that the candidate statements provided in the unlocking script match the goal statements of the unlocking script, verifying the challenge solution provided in the unlocking script.

[0219] 6.1.3 Generating the unlocking script An unlocking script may be generated by performing the following steps using a candidate statement st ∈ L and a private witness w. 1. Let tx_dummy_sign be a dummy signature for SIGHASH serialization of the transaction. 2. Create a nizk proof π To ensure transaction integrity of the transaction fields, tx_dummy_sign is used as the context information ctxt. This ensures that the proof provided in the unlocking script is bound to the fields of the transaction. It will be appreciated that other methods may be used to prove transaction integrity. Collaboratively create nizk proofs if necessary. This is necessary when witnesses are split among several parties, see for example Section 7.3. 3. Include the context information, the candidate statements, and the nizk proof, also referred to herein as the challenge solution, in the unlocking script.

[0220] The unlocking script generated by following the steps above is:

[0221]

number

[0222] where π is the challenge solution, st is a candidate statement, and tx_dummy_sign is the context information (here a dummy signature).

[0223] The challenge solution π is a vector of elements, the length of which depends on the application as explained below.

[0224] 6.2 Instantiation of a Random Oracle In the examples presented here, the order of the group is p>2. 128 Therefore, the challenge space is

[0225]

number

[0226] It is sufficient to set the order to . This choice ensures a conservative security level of 128 bits for the soundness of the Sigma protocol. Other orders may be chosen. The random oracle function H is

[0227]

number

[0228] is caused as.

[0229] As defined, RO maps a bit string x of any length to values ​​that are uniformly distributed (under the ROM heuristic) in C. It is observed that the modular reduction step does not introduce any bias into the output of the hash function SHA256. This is because the size of the output byte array d:=SHA256(x) is exactly 256 bits and mod 2 128 applies (so that every point in the RO image has exactly two preimages with equal probability).

[0230] An example random oracle script for generating a 128-bit challenge is:

[0231]

number

[0232] It is.

[0233] Another possibility is to generate a 160-bit challenge using the following (slightly more efficient) script:

[0234]

number

[0235] A caveat to using a 160-bit challenge is that the challenge is 4 bytes longer than before. For large OR proofs, this may not be desirable. The challenge space is

[0236]

number

[0237] and the random oracle is

[0238]

number

[0239] It is defined as follows.

[0240] The spend transaction's dummy signature, tx_dummy_sign, is bound to the proof provided in the spend transaction's unlocking script by prepending it to the RO's input, i.e.

[0241]

number

[0242] and

[0243]

number

[0244] is a commitment.

[0245] The digest d:=SHA256(x) is interpreted as an integer in little endian, which allows the RO to be triggered in Script. Provers must interpret the digest in the same way to ensure consistency (i.e., the same challenge is computed by either party). Note also that if the prover uses little endian, there is no need to implement reverse endianness in Script.

[0246] 6.3 Verifying knowledge of preimages Verification script

[0247]

number

[0248] -verifier] implements the algorithm presented in Section 5.6.2 for a given group homomorphism

[0249]

number

[0250] is described below. This script can be thought of as being implemented in two steps: first it recalculates the commitment, then it checks the challenge.

[0251] Step 1 - Recalculate your commitments

[0252] The first step is to obtain the goal statement st and the challenge solution provided in the unlocking script.

[0253]

number

[0254] Recalculate the commitment using, e is the target challenge,

[0255]

number

[0256] is the answer to the goal challenge.

[0257]

number

[0258] The steps of the -verifier recompute commitment are as follows: a. If not clear, select the image point from the goal statement st.

[0259]

number

[0260] Leads to. b. Extract the challenge e from π,

[0261]

number

[0262] Calculate. c. Answer from Pi

[0263]

number

[0264] Extract

[0265]

number

[0266] Calculate. d. Candidate Commitments

[0267]

number

[0268] Calculate.

[0269] Homomorphisms are realized on elliptic curves. Hence, the group

[0270]

number

[0271] is an elliptic curve of order p. The Script interface for elliptic curve computations is used. The following notation is used herein: ·[Add points]: Add two points (of an elliptic curve) ·[Substract points]: Subtract two points · [Multiply by scalar]: Multiply a point by a scalar · [Multiply P by scalar]: Multiply a hard-coded P by a scalar · [Are equal points]: Returns true only if two points are equal · [Negate point]: Returns the inverse of a point

[0272] This scripting interface allows the construction of homomorphic maps of any given elliptic curve.

[0273]

number

[0274] It is sufficient to compute steps (a)-(d) above for the homomorphic mapping function

[0275]

number

[0276] depends on the application.

[0277] Step 2 - Check the challenge

[0278] The second step verifies whether the target challenge e embedded in the proof π was computed correctly.

[0279]

number

[0280] Let be the recomputed commitment in step 1, also referred to herein as the candidate commitment value, tx_dummy_sign be the dummy signature of the consuming transaction, and st be the candidate statement.

[0281]

number

[0282] -verifier check challenge] performs the following steps: a.

[0283]

number

[0284] (using opcode OP_CAT). b. Run the script [Random Oracle] from Section 6.2. This step derives a challenge e, also referred to herein as a candidate challenge, from the public transcript x. * Recalculate. c. Extract the target challenge e from the challenge solution π and let it be the candidate challenge e * Check that it is equal to (using OP_EQUAL).

[0285] If the recomputed challenge matches the one extracted from the proof, the script pushes a 1 onto the top of the stack, otherwise it pushes a 0.

[0286] Candidate Challenge * may also be referred to herein as a candidate hash value.

[0287] 6.4 Verifying "AND" Proofs s preimage knowledge relations

[0288]

number

[0289] The conjunctive proof of is verified exactly the same as in the previous section. The only difference is that the script [

[0290]

number

[0291] -verifier] is synthesized using a hard-coded group homomorphism.

[0292]

number

[0293] See Section 5.4 for more details.

[0294] 6.5 Verifying "OR" Proofs Non-interactive verifier [Σ OR The verifier is very similar to the verifier from Section 6.3. The main difference is that the offset challenge o is added to all the commitments.

[0295]

number

[0296] It is calculated based on

[0297]

number

[0298] Then, all the challenges e i (as illustrated in FIG. 4b).

[0299] Step 1 - Recalculate your commitments This is the script [Σ OR -verifier recompute commitment]. 1 ,π 1 ),…,(st r ,π r ) is the input and the following steps are performed: 1. Input i-th candidate statement st i and the i-th challenge proof

[0300]

number

[0301] For the script [

[0302]

number

[0303] -verifier recompute commitment] to ith candidate commitment

[0304]

number

[0305] Rebuild

[0306] As explained earlier, elliptic curve mathematics is used when performing this step.

[0307] Step 2 - Check the challenge

[0308]

number

[0309] Let be the r recomputed, i.e., candidate, commitments in step 1, tx_dummy_sign be the dummy signature of the spend transaction, and st i Let be a candidate statement. Script [Σ OR -verifier check challenge] consists of the following steps: a.

[0310]

number

[0311] (using opcode OP_CAT). b. Run the script [Random Oracle] from Section 6.1 on the input x. This step derives the offset challenge o from the public transcript x. * Recalculate. c.

[0312]

number

[0313] Verify that it is e i is a candidate challenge (using OP_ADD, OP_MOD, and OP_EQUAL).

[0314] Candidate Offset Challenge * is the challenge solution π i Target challenge extracted from e i If it matches, the script pushes a 1 onto the top of the stack, otherwise it pushes a 0.

[0315] 7. Examples of Zero-Knowledge Puzzles A modular framework was presented in the previous section that allows simple puzzles to be composed into arbitrarily complex puzzles. This is achieved using the Σ protocols, a family of three-round public-coin zero-knowledge proof systems that do not require a trusted environment. In particular, the group homomorphism

[0316]

number

[0317] The preimage sigma protocol is described to prove preimage knowledge (in zero knowledge) under

[0318]

number

[0319] If x is an elliptic curve and one utilizes the appropriate Script interface for elliptic curve computations, it is shown how the non-interactive verifier of the preimage Sigma protocol can be implemented as a locking script. Moreover, to achieve modularity, AND / OR verification statements in Script can be used.

[0320] The versatility of zero-knowledge puzzles is illustrated by three new payment modalities presented below. In the examples, the spending transaction can be explicitly bound to the nizk signature π using transaction integrity techniques or injection techniques. It will be appreciated that further puzzles can be constructed using our Script framework.

[0321] The first application presented below is paying for a general-purpose ECDSA public key P, which is a generalization of the standard P2PK puzzle.

[0322]

number

[0323] Let be an elliptic curve with base point G. The requirement to sign the curve secp2561k1 (for which the opcode OP_CHECKSIG is hardcoded) is waived, and a signing key w, i.e.,

[0324]

number

[0325] nizk proof of knowledge of discrete logarithm of π DL As will be appreciated by those skilled in the art, the ECDSA signature algorithm supports many curves other than just secp256k1.

[0326]

number

[0327] There are several reasons to customize a curve. a) Long-lived transactions: Current P2PK UTXOs must be spent within a period not longer than 10 years. This is because public keys with 128-bit security (such as public keys on the secp256k1 curve) can be brute-force cracked in less than 10 years. Parties may wish to be paid to addresses with greater than 128-bit security. For example, the curves secp384r1 and secp521r1 have 192-bit and 256-bit security, respectively. P2GPK UTXOs may remain unspent for any period of time, depending on the curve behind them. b) Default Public Key: A party may have a public key P that is already certified by a Certification Authority (CA) (or P is a favorite key of the party that the party uses to authenticate itself, not just in the blockchain context). Such a public key may not be secp2561k1 compatible.

[0328] Verification of a P2PK solution is fast and cheap (both in terms of fees and computational resources) due to the built-in opcode OP_CHECKSIG. On the downside, this technique produces larger scripts in exchange for increased security or compatibility.

[0329] The next two payment modalities focus on providing privacy to the consuming party.

[0330] A second application is to be able to make payments to a group of public key holders. Any of the holders can spend the funds, but no one, not even other members of the group, knows who in the group actually redeemed the funds. This is achieved by using OR proofs for knowledge of discrete logarithms.

[0331] A third application is a generalization of the above payment modalities to thresholding and standard multi-signature puzzles (P2MS), where the identity of the threshold subset spending funds remains unknown to anyone other than the members of the threshold subset. A combination of OR / AND proofs is used to bootstrap techniques for P2GP scripting for this scenario, and an off-chain protocol between members to privately generate nizk proofs is designed.

[0332] 7.1 Paying for a General-Purpose ECDSA Public Key All elliptic curve (ECDSA) public keys are of the form PK=xG for a fixed generator G of the curve. Instead of the standard P2PK, a zero-knowledge puzzle for knowledge of the discrete logarithm x in base G can be used, where x can be thought of as a signing key. Specifically, the puzzle corresponds to a proof system with a knowledge set.

[0333]

number

[0334] The subset of order p over which ECDSA is instantiated

[0335]

number

[0336] For a given generator G of G, the group homomorphism is simply

[0337]

number

[0338] The prover and verifier steps are detailed below.

[0339] [Table 2]

[0340] The prover is implemented off-chain and the context information is a dummy signature of the spend transaction. The function RO is instantiated as described in Section 6.2.

[0341] Verifiers follow the steps of the generic algorithm template outlined in Section 5.6.2, which is implemented on-chain, for example using the Script interface for elliptic curve computations (see also step 1 in Section 6.3).

[0342] The resulting script is

[0343]

number

[0344] -verifier].

[0345] FIG. 5 shows a first transaction Tx, referred to herein as a challenge transaction. 1 2 illustrates the on-chain steps performed by the validation script of the first locking script 203A of FIG. 2. The first locking script 203A also includes a goal statement.

[0346] A second transaction Tx, referred to herein as a certification transaction. 2 The first unlocking script 202A comprises a challenge proof π, a candidate statement, and a context information part tx_dummy_sign. These components are generated off-chain by the challenger.

[0347] In step A, the candidate statements and the target statement are compared.

[0348] In step B, candidate commitment A *is calculated using the proof π = (e, z) and the candidate statement provided in the first unlocking script. In step C, the candidate hash value (here the candidate challenge e * ), we use candidate commitment A * is used together with the candidate statement and the context information part tx_dummy_sign.

[0349] Finally, the candidate challenge is compared to the target challenge in step D.

[0350] If the candidate statement and the target statement, and the candidate challenge and the target challenge are both equal, the challenger has knowledge of the proof and therefore can send the first transaction Tx 1 are eligible to unlock UTXOs.

[0351] 7.1.1 Generalized P2PK Script Alice 103a transfers, say, 1BSV to Bob 103b’s public key

[0352]

number

[0353] If a user wants to send a Token to a Token holder, she creates a transaction with the following locking script:

[0354]

number

[0355] G secp256k1 denotes the base point of the curve secp256k1. The corresponding unlocking script is

[0356]

number

[0357] and

[0358]

number

[0359] is a proof of knowledge of the signing key s,

[0360]

number

[0361] is a candidate statement.

[0362] 7.1.2 Generalized P2PK Addresses Similarly, an analogy of P2PKH addresses can be considered with locking scripts.

[0363]

number

[0364] Here, the address is defined as GPKHash:=RIPEMD160(SHA256(G||PK)). The unlocking script is exactly [us_P2GPK].

[0365] 7.2 Paying the group privately Payment to a group of public key holders can be achieved using OR proofs on the DL relation. 1 ,…,PK r For a given set of

[0366]

number

[0367] It is.

[0368] All public keys are the same group

[0369]

number

[0370] The steps of the OR prover and OR verifier are presented below.

[0371] The prover is responsible for each public key PK of a statement st for which the witness x is not the private key. i Target commitment value for A i To derive,,we perform the simulations presented in Section 5.3.,In this way, the prover can generate a valid,unlocking script with knowledge of only one private key (the,witness).

[0372] The verifier then calculates a set of corresponding commitment values ​​and, based on these, determines the candidate offset value o * The candidate offset values ​​may also be referred to herein as candidate hash values.

[0373] [Table 3]

[0374] As shown above, tx_dummy_sign indicates the dummy signature of the spend transaction, and the verifier executes the script [

[0375]

number

[0376] -verifier] It is implemented on-chain in .

[0377] The challenge in step 3 performed by the verifier iBy requiring that the sum of x and y be equal to the offset value, at least one of the challenges must be computed correctly, i.e. with knowledge of the private key x. Thus, the prover can prove knowledge of a sufficient solution to be eligible to unlock the UTXO.

[0378] FIG. 6 shows a first transaction Tx, referred to herein as a challenge transaction. 1 2 illustrates the on-chain steps performed by the verification script of the first locking script 203B of FIG. The first locking script 203B also comprises a goal statement. In this implementation, the statement comprises the public keys of each of the users.

[0379] A second transaction Tx, referred to herein as a certification transaction. 2 The first unlocking script 202B of the first block comprises a challenge proof π, a candidate statement, and a context information portion tx_dummy_sign. These components are generated off-chain by the challenger. The challenge proof is divided into a challenge proof portion π corresponding to each of the keys to which the UTXO is locked. i each of the challenge proof portions has a corresponding challenge portion e i and answer value z i Equipped with.

[0380] In step A, the candidate statements and the target statement are compared.

[0381] In step B, candidate commitment A i * But, proof π = (e 1 ,z 1 ,…,e r ,z r ) and the candidate statements provided in the first unlocking script. i * In step C, we calculate the candidate hash value (here, the candidate offset o* ), together with the candidate statement and the context information part tx_dummy_sign.

[0382] Finally, in step D, the candidate offset value is multiplied by mod 2 128 is compared to the target challenge total.

[0383] If the checks performed in steps A and D turn out to be true, the challenger has knowledge of the proof and therefore can send the first transaction Tx 1 are eligible to unlock UTXOs.

[0384] 7.2.1 Group Payment Script For example, to send 1 BSV to a group address, Alice 103a creates the following locking script:

[0385]

number

[0386] Then the unlocking script will be

[0387]

number

[0388] and the proof is

[0389]

number

[0390] and the statement is

[0391]

number

[0392] It is.

[0393] It is also possible to pay to a group address hash.

[0394]

number

[0395] 7.3 Paying Threshold Groups Privately In some cases, it is desirable to require that any subset of the group of public key holders below a threshold t can collectively redeem a UTXO without revealing exactly which subset they are. This is true both for the generalization of the pay to group privately script (P2GP) mentioned above, and for standard multi-signature P2MS scripts.

[0396] For example, the 2-out-of-3 threshold, the public key holder PK 1 , P.K. 2 , P.K. 3 whereas the knowledge set is

[0397]

number

[0398] It is.

[0399] The underlying AND homomorphism is

[0400]

number

[0401] ,

[0402]

number

[0403] It is obtained.

[0404]

number

[0405] -verifier] is very similar to the one outlined in section 7.2, the only difference is that this time

[0406]

number

[0407] and

[0408]

number

[0409] This means that the operation is performed on vectors of dimension 2 above.

[0410] FIG. 7 shows the first transaction Tx, referred to herein as the challenge transaction, in the case of the 2 out of 3 threshold. 1 2 illustrates the on-chain steps performed by the verification script of the first locking script 203C of FIG. The first locking script 203C also comprises a goal statement. In this implementation, the statement comprises the public keys of each of the users.

[0411] A second transaction Tx, referred to herein as a certification transaction. 2 The first unlocking script 202C of the challenger comprises a challenge proof π, a candidate statement, and a context information portion tx_dummy_sign. These components are generated off-chain by the challenger. As in the example of FIG. 6, the challenge proof π includes a challenge proof portion π corresponding to each of the keys to which the UTXO is locked. i Equipped with.

[0412] In step A, the candidate statements and the target statement are compared.

[0413] In step B, candidate commitment A i * But, proof π = (e 1,2 ,z 1,2 ,e 1,3 ,z 1,3 ,e 2,3 ,z 2,3 ) and for each i=1, 2, 3 using the candidate statements provided in the first unlocking script. Candidate commitment A i * In step C, we calculate the candidate hash value (here, the candidate offset value o * ), together with the candidate statement and the context information part tx_dummy_sign.

[0414] Finally, in step D, the candidate offset value is multiplied by mod 2 128 is compared to the target challenge total.

[0415] If the checks performed in steps A and D turn out to be true, the challenger has knowledge of the proof and therefore can send the first transaction Tx 1 are eligible to unlock UTXOs.

[0416] 7.3.1 Script for private payments to threshold groups The locking script (for a 2 out of 3 threshold) is:

[0417]

number

[0418] It is.

[0419] The unlocking script is

[0420]

number

[0421] Here, the proof is

[0422]

number

[0423] It is.

[0424] 7.3.2 Creating an unlocking script User (key holder)

[0425]

number

[0426] and

[0427]

number

[0428] When two parties want to redeem a UTXO, they cooperate off-chain to prove 30R-2AND_DL The reason is that the witnesses of a genuine AND statement are

[0429]

number

[0430] and

[0431]

number

[0432] Because x, x' are the discrete logarithms of x, x'. Users of the threshold subset would like to keep their values ​​private.

[0433] For example, with a 2 out of 3 threshold, a statement comprises three public keys belonging to three different users. Two of the three users need to cooperate to generate the proof. Each user knows a unique signing key but does not want to share this with any other user. The protocol for creating the unlocking script has three rounds:

[0434] One of the two users participating in the proof acts as a collaborator and challenges i and answer z i and provide a challenge solution π in the unlocking script. 30R-2AND_DL In the example presented below, the user

[0435]

number

[0436] acts as a collaborator, but the user

[0437]

number

[0438] Send your challenges and answers to users

[0439]

number

[0440] to be provided.

[0441] The steps are as follows: 1. Users

[0442]

number

[0443] starts: a. Commitment

[0444]

number

[0445] Randomly sample b.

[0446]

number

[0447] The user

[0448]

number

[0449] Send to 2. Users

[0450]

number

[0451] is the input x' received input

[0452]

number

[0453] do the following to: a. Commitment

[0454]

number

[0455] Randomly sample.

[0456]

number

[0457] Set it as b. Challenge

[0458]

number

[0459] Randomly sample c. Simulate the proof (see Section 5.4):

[0460]

number

[0461] d. Create an offset challenge:

[0462]

number

[0463] e.

[0464]

number

[0465] Calculate f.Answer

[0466]

number

[0467] Create g.

[0468]

number

[0469] The user

[0470]

number

[0471] Send to 3. Users

[0472]

number

[0473] Enter

[0474]

number

[0475] and the received input

[0476]

number

[0477] do the following to: a. Check the following: i. Simulated Proof

[0478]

number

[0479] Verify that the is verified. ii. A confirmation offset is derived from the serialized transaction, statement, and commitment. iii. Challenge

[0480]

number

[0481] and sum it up to offset o (modulo 128). iv. Certification

[0482]

number

[0483] Verify that the is verified. b.Answer

[0484]

number

[0485] Calculate c. Create an unlocking script with the certificate:

[0486]

number

[0487] The method presented above is illustrated in Figure 8. In this case, users Alice 103a, Bob 103b, and Charlie each have a public key P A , P B , and P C Each user can spend using zk proofs for the OR-AND relationship. Thus, a zk proof proving knowledge of the first and second public keys, or the first and third public keys, or the second and third public keys, can be used to unlock the UTXO of a challenge transaction.

[0488] In the example in Figure 8, Alice 103a and Bob 103b want to unlock a UTXO. They have a signing key sk A and sk BIn this paper, Alice 103a is referred to as the prover and Bob 103b is referred to as the collaborator.

[0489] sk A and sk B The AND relation for proving knowledge of is similar to the protocol in Figure 4a, but in parallel, Alice 103a and Bob 103b prove their knowledge of commitment A. A = aG, A B = bG to the verifier, who responds with a challenge e, and Alice 103a and Bob 103b receive z A =a+e*sk A and z B =a+e*sk B The same challenge e is answered by z A and z B is used to generate z, and only Alice 103a can generate z A (with knowledge of her signing key), and only Bob 103b can generate z B can be generated.

[0490] Alice 103a and Bob 103 cooperate to generate a challenge proof π, as shown in FIG. 8, in the following steps:

[0491] In step 1a, Alice 103a meets her goal commitment A A and sends it to Bob 103b (step 1b).

[0492] In step 2a, Bob 103b then agrees to a cooperator goal commitment A C Specific goal commitment A, also referred to herein as B To generate his target commitment, Bob 103b creates a randomly selected collaborator secret value r cYour secret random value, also called

[0493]

number

[0494] Use.

[0495] Charlie's signing key sk C Since sk is unknown to either Alice 103a or Bob 103b, Bob 103b uses the signing key sk in step 2c. A and sk C Proof of knowledge of , as well as the signing key sk B and sk C , π A,C and π B,C It also simulates proofs for knowledge of.

[0496] Commitment A A and A B , Simulated proof π A,C and π B,C From the challenge value of and the statement, Bob 103b derives the offset value o that the verifier is to issue in the interactive version of the protocol (see FIG. 4b) (step 2d), and from that offset value, Bob 103b derives the genuine challenge value e A,B (Step 2e) and find your answer z B (Step 2e).

[0497] In step 2g, Bob 103b generates the simulated proof π A,C and π B,C , My Commitment A B , the offset challenge o, and the challenge value e A,B to Alice.

[0498] Alice 103a verifies (step 3a) the value received from Bob 103b. That is, Alice 103a verifies, among other things, that the offset challenge o received from Bob 103b is derived from transaction fields that Alice 103a is satisfied with. Alice 103a then verifies the challenge value e A,B Using my answer z A (Step 3b).

[0499] Alice 103a now has all the data necessary to create an OR-AND proof π to be included in the unlocking script (step 3c).

[0500] This protocol can be generalized to a threshold of m out of n as follows: Let us denote a subset of t users by

[0501]

number

[0502] Let one of the users in the set, say

[0503]

number

[0504] acts as an arbiter. That user simulates the proof and creates an offset challenge after receiving all commitments from other users in the set. Then,

[0505]

number

[0506] broadcasts this information to other users, who can verify that the transcript is correct, calculate their own answers, and use those answers to create unlocking scripts.

[0507]

number

[0508] The size of the unlocking script grows exponentially with the number of users (specifically

[0509]

number

[0510] Note that since the threshold is proportional to the number of iterations, the unlocking script becomes prohibitively large for very large thresholds.

[0511] Figure 9 shows the generalized protocol for a threshold of 3 out of n, with users Alice 103a, Bob 103b, and Charlie 103c contributing to the challenge proof, with Alice 103a again acting as a reconciler, and Bob 103g and Charlie 103c acting as collaborators.

[0512] In steps 1a and 1b, Bob 103b and Charlie 103c each generate and calculate their commitments. The collaborators then send their commitments to Alice 103a (steps 2a and 2b).

[0513] Alice 103a uses the received commitments of Bob 103b and Charlie 103c along with her own commitment to simulate the proof portion and generate an offset challenge (step 3). Alice 103a also generates a challenge value e.

[0514] Alice 103a then broadcasts the simulated proof portion and the offset challenge (steps 4a and 4b), which are then verified by Bob 103b and Charlie 103c (steps 5a and 5b). Alice 103a may also broadcast the challenge value e, but it will be appreciated that this is not necessary as this value is fixed from the simulated proof challenge and offset challenge.

[0515] If the collaborators are satisfied with the simulated proofs and offset values, they generate their answers (steps 6a and 6b), which are then sent to Alice 103a in steps 7a and 7b. After the collaborators have verified the received values, they send their answers z B and z C By sending a ,cooperator ensures that the collaborator will only provide their answer if they are happy with the,content of the transaction.,This way a dishonest reconciler cannot change the output of the,spend transaction to which the funds are sent, to one of,their choice.

[0516] Once Alice 103a receives Bob and Charlie's responses, she generates a proof π for inclusion in the spend transaction.

[0517] 8. Alternative Embodiments In each of the implementations presented above, the candidate statements, i.e. the statements provided in the unlocking script, are used to verify the proof. However, it will be appreciated that the goal statements, i.e. the statements provided in the locking script, may instead be used when verifying the proof. This is because the goal statements and the candidate statements should be the same, which are verified in the script.

[0518] In some embodiments, the unlocking script does not include candidate statements. In such embodiments, the target statement of the locking script is used to verify the proof, and the step of checking the candidate statements against the target statement (step A in each of Figures 5, 6, and 7) is not performed.

[0519] It will be appreciated that there are alternative ways to verify the proof, such as directly converting the interactive Sigma protocol into a non-interactive protocol. The methods presented above use "short challenge proofs", where π = (e,z). Each of the methods described above implements the following steps: 1. Recompute the commitment A from statement st, challenge e, and answer z (implicitly using the verifier's test formula). 2. Verify that the hash (statement, commitment) matches the challenge.

[0520] Alternatively, a "long challenge proof" may be used, where the long challenge proof is defined as π=(A,e,z). The verification method comprises: 1. Run the test formula and if it passes, accept it. The test for the preimage sigma protocol is z*G=A(st e )

[0521] The embodiments have been described primarily with respect to a prover and a verifier. In general, the prover and the verifier may take any form, for example a user, a group of users, an organization, an autonomous device, a smart contract, etc. In some examples, the prover may take the form of Alice 103a, operate a computing device 102a, and be configured to perform any of the activities described with respect to Figures 1 and 2 as being performed by Alice 103a. Similarly, the verifier may take the form of Bob 103, operate a computing device 102b, and be configured to perform any of the activities described with respect to Figures 1 and 2 as being performed by Bob 103b. Alternative forms may apply, i.e. the prover may be Bob 103b and the verifier may be Alice 103a.

[0522] 9. Further Observations Other variations or uses of the disclosed techniques may be apparent to those of ordinary skill in the art given the disclosure herein. The scope of the disclosure is limited only by the appended claims, and not by the described embodiments.

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

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

[0525] In other embodiments of the invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not precluded that a node may perform at least one or some, but not all, of the functions of creating, publishing, disseminating, and storing blocks 151 of the blockchain 150. For example, on those other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151, but not store and / or disseminate those blocks 151 to other nodes.

[0526] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," with such entity / element configured to perform some or all of the roles of creating, publishing, disseminating and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above in connection with the blockchain node 104.

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

[0528] Statement 1. A computer-implemented method for generating a challenge blockchain transaction, comprising: generating a first locking script of the challenge blockchain transaction comprising a goal statement and a verification script for verifying a challenge solution π provided in a first unlocking script of the proof blockchain transaction, the challenge solution π being a non-interactive zero-knowledge proof providing knowledge of a private witness w, the first locking script, when executed together with the first unlocking script, Based on the challenge solution π provided in the first locking script and the goal statement and one of the candidate statements provided in the first unlocking script, a candidate commitment value A is determined. * Calculating Candidate commitment value A * and calculating a candidate hash value using the target statement and one of the candidate statements; Verifying the challenge solution π based on the candidate hash value; and Verifying that the challenge solution π is provided in a proof blockchain transaction; and configured to: making the challenge blockchain transaction available to one or more nodes of the blockchain; A method comprising:

[0529] Statement 2. The method of statement 1, wherein the first locking script is further configured to compare the candidate statement to the goal statement.

[0530] Statement 3. The method of statement 1 or statement 2, wherein the challenge solution π comprises a target challenge value e and a target answer value z.

[0531] Statement 4. A non-interactive zero-knowledge proof is a one-way homomorphic mapping function

[0532]

number

[0533] The method of any preceding statement as defined by.

[0534] Statement 5. Candidate Commitment A * but

[0535]

number

[0536] , z is a target answer value, e is a target challenge value, and w is a secret witness.

[0537] Statement 6. The method of any preceding statement, wherein the candidate statement and the goal statement comprise an elliptic curve point generator G and a public key PK associated with the witness.

[0538] Statement 7. Function

[0539]

number

[0540] but

[0541]

number

[0542] and the public key is

[0543]

number

[0544] and the candidate commitments are defined as A * =zG-ePK The methods of statements 5 and 6 are calculated as follows:

[0545] Statement 8. The method of any preceding statement, wherein the first locking script is further configured to verify a context information portion of the first locking script, the context information portion being for providing integrity of the attestation blockchain transaction.

[0546] Statement 9. If the candidate hash value is a candidate challenge value e *and the step of verifying the challenge solution π is performed by using a candidate challenge value e * The method of statement 3 or any statement dependent thereon, comprising the step of comparing the target challenge value e with the target challenge value e.

[0547] Statement 10. Candidate challenge value e * is a context information portion, a goal statement, one of the candidate statements, and a candidate commitment A * Calculated using the methods of Statements 8 and 9.

[0548] Statement 11. The candidate statement and the target statement further comprise at least one additional public key, and each public key Pk i The corresponding secret witness w i and the challenge solution is i The target challenge value e i and the target answer value z i Each candidate commitment A * i but A * i =z i Ge i Penalty kick i Each witness using i The methods of statements 3, 6, and 7 are calculated for.

[0549] Statement 12. Candidate hash value is offset candidate o * and the candidate offset o * are each candidate commitments A * i 12. The method of claim 8 and claim 11, wherein each of the first and second statements is calculated using one of the target statement and the candidate statement, and the context information portion.

[0550] Statement 13. The step of verifying a challenge solution π comprises: Target challenge value e i calculating a target offset o based on Target offset o and candidate offset o * and comparing The method of claim 12.

[0551] Statement 14. A computer-implemented method for generating attestation blockchain transactions, comprising: randomly selecting a secret value r; calculating a target commitment r using the secret value r; computing a challenge solution π based on a goal commitment A, the candidate statements, and a private witness w, where the challenge solution π is a non-interactive zero-knowledge proof that proves knowledge of the private witness w; generating a first unlocking script of the proof blockchain transaction with the challenge solution π; making the proof blockchain transaction available to one or more nodes of the blockchain; A method comprising:

[0552] Statement 15. The method of statement 14, wherein the first unlocking script further comprises candidate statements.

[0553] Statement 16. The challenge solution π comprises a target challenge value e and a target answer value z, where the target challenge value e is a hash value derived from the target commitment A and the candidate statement; 16. The method of statement 14 or statement 15, wherein the target answer value z is calculated using the target challenge value e, the secret witness w, and the secret value r.

[0554] Statement 17. The method of statement 16, wherein the first unlocking script further comprises a context information portion, and the target challenge value e is further derived from the context information portion.

[0555] Statement 18. The candidate statement is given by: i and a public key PKi Each of them is a secret witness i Corresponding to at least one secret witness w j is known and there is at least one secret witness w i is unknown, and the method is that of each unknown secret witness w i In contrast, Target challenge value e i randomly selecting Target challenge value e i , an elliptic curve point generator G, and a public key PK i Based on the challenge solution part π i and simulating 15. The method of claim 14, further comprising:

[0556] Statement 19. Challenge solution part π i The step of simulating each unknown secret witness w i In contrast, Simulated Answers i randomly selecting Target challenge value e i , elliptic curve point generator G, simulated answer z i , and the public key PK i Based on the simulated target commitment A i and calculating Equipped with Challenge solution part π i But the simulated answer z i , Simulated goal commitment A i , and the target challenge value e i The method of claim 18.

[0557] Statement 20. The first unlocking script further comprises a context information portion, and the method further comprises: At least one unknown secret witness w i The challenge solution part π i , at least one known witness w j Target commitment A corresponding to j, and simulated goal commitment A i calculating a target offset o based on Given a target offset o, a secret value r, and a known witness w j Based on at least one known confidential witness w j The challenge solution part π j and calculating Further equipped with The challenge solution π is each secret witness w i The challenge solution part π i The method of statement 19 is derived from.

[0558] Statement 21. Candidate statement is given by: i and a public key PK i Each of them is a secret witness i Corresponding to at least one secret witness w j is known and there is at least one secret witness w i is unknown, and the goal commitment A is known by a secret witness w j Related Goal Commitment A j and the method is Goal Commitment A j to a collaborator; From a collaborator: At least one simulated proof part π i Each simulated proof portion π i is the simulated target commitment A i At least one simulated proof part π derived from i , A randomly selected collaborator secret value r c Goal-partner commitment A derived based on c , Goal Commitment A j , Simulated goal commitment A i , Collaborator goal commitment A c , and multiple public keys PKi A target offset value o derived based on a target challenge value e derived based on the target offset value o; and Target challenge value e and collaborator secret witness w c The collaborator response value z derived based on c receiving the A target challenge value e and a known secret witness w j Based on the target answer value z j and calculating Further equipped with The challenge solution π is the target answer value z j , participant response value z c , a target challenge value e, and at least one simulated proof part π i The method of claim 14.

[0559] Statement 22. Candidate statement is given by: i and a public key PK i Each of them is a secret witness i Corresponding to at least one secret witness w j is known and there is at least one secret witness w i is unknown, and the goal commitment A is known by a secret witness w j Related Goal Commitment A j and the method is A randomly selected collaborator secret value r c At least one goal-partner commitment A derived based on c receiving each target collaborator commitment A c are generated by each collaborator, and At least one simulated proof part π i generating each simulated proof portion π i is the simulated target commitment A i and Goal Commitment A j and target collaborator commitment A cand Goal Commitment A j , Simulated goal commitment A i , at least one collaborator goal commitment A c , and multiple public keys PK i calculating a target offset value o and a target challenge value e, derived based on At least one simulated proof part π i and a target offset value o to each collaborator; A target offset value o and a collaborator secret witness w c Each participant's response value z is derived based on c receiving from each collaborator; Further equipped with The challenge solution π is the target answer value z j , participant response value z c , a target challenge value e, and at least one simulated proof part π i The method of claim 14.

[0560] Statement 23. A memory having one or more memory units; a processing device comprising one or more processing units; 23. A computing apparatus comprising: a memory storing code adapted to be executed on a processor; and the code, when on the processor, is configured to perform the method of any of statements 1 to 22.

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

[0562] 101 Packet Switching Network 102 Computer terminals 103 users 104 Blockchain nodes 105 Client Applications 106 Blockchain Network 107 Side Channel 150 Blockchain 151 Blocks 152 Transactions 153 Genesis Block 154 Pool 155 Block Pointer 201 Header 202 Input 203 Output 450 Node Software 451 Protocol Engine 452 Script Engine 453 Stack 454 Application Level Decision Engine 455 Function Module

Claims

1. 1. A computer-implemented method for generating a challenge blockchain transaction, comprising: generating a first locking script of the challenge blockchain transaction comprising a goal statement and a verification script for verifying a challenge solution π provided in a first unlocking script of a proof blockchain transaction, the challenge solution π being a non-interactive zero-knowledge proof providing knowledge of a private witness w, the first locking script, when executed together with the first unlocking script, A candidate commitment value A is determined based on the challenge solution π provided in the first locking script and one of the goal statement and the candidate statement provided in the first unlocking script. * Calculating The candidate commitment value A * and calculating a candidate hash value using the target statement and one of the candidate statements; verifying the challenge solution π based on the candidate hash value; Verifying that the challenge solution π is provided in the attestation blockchain transaction; and configured to: making the challenge blockchain transaction available to one or more nodes of a blockchain; A method comprising:

2. The method of claim 1 , wherein the first locking script is further configured to compare the candidate statement to the goal statement.

3. The method of claim 1 or 2, wherein the challenge solution π comprises a target challenge value e and a target answer value z.

4. The non-interactive zero-knowledge proof is a one-way homomorphic mapping function [0010] The method according to any one of claims 1 to 3, wherein said method is defined by:

5. Candidate Commitment A * but [0025] 5. The method of claim 3, wherein z is the target answer value, e is the target challenge value, and w is the secret witness.

6. The method of claim 1 , wherein the candidate statement and the goal statement comprise an elliptic curve point generator G and a public key PK associated with the witness.

7. The above function [0030] but [0045] and the public key is [0050] and the candidate commitment is defined as A * =zG-ePK The method according to claims 5 and 6, wherein:

8. 8. The method of claim 1, wherein the first locking script is further configured to verify a context information portion of the first locking script, the context information portion being for providing integrity of the proof blockchain transaction.

9. The candidate hash value is a candidate challenge value e * and the step of verifying the challenge solution π is * A method according to claim 3 or any claim dependent thereon, comprising the step of comparing the target challenge value e with

10. The candidate challenge value e * is a set of the context information portion, the goal statement and one of the candidate statements, and the candidate commitment A * The method according to claims 8 and 9, wherein the calculation is performed using

11. The candidate statement and the target statement further comprise at least one additional public key, and each public key Pk i The corresponding secret witness w i and the challenge solution is associated with each witness w i The target challenge value e i and the target answer value z i Each candidate commitment A * i but A * i =z i G-e i PK i Each witness using i The method of claims 3, 6 and 7, wherein the method is calculated based on

12. The candidate hash value is offset candidate o * and the candidate offset o * Each of the candidate commitments A * i 12. The method of claim 8 and 11, wherein each of the target statement and one of the candidate statements and the context information portion is calculated using the target statement and one of the candidate statements.

13. the step of verifying the challenge solution π comprises: The target challenge value e i calculating a target offset o based on the target offset o and the candidate offset o * A step of comparing The method of claim 12 comprising:

14. 1. A computer-implemented method for generating a proof blockchain transaction, comprising: randomly selecting a secret value r; calculating a target commitment A using the secret value r; computing a challenge solution π based on the goal commitment A, the candidate statements, and a private witness w, where the challenge solution π is a non-interactive zero-knowledge proof that proves knowledge of the private witness w; generating a first unlocking script for the proof blockchain transaction comprising the challenge solution π; making the proof blockchain transaction available to one or more nodes of the blockchain; A method comprising:

15. The method of claim 14 , wherein the first unlocking script further comprises the candidate statements.

16. the challenge solution π comprises a target challenge value e and a target answer value z, the target challenge value e being a hash value derived from the target commitment A and the candidate statement; 16. The method of claim 14 or 15, wherein the target answer value z is calculated using the target challenge value e, the secret witness w, and the secret value r.

17. 17. The method of claim 16, wherein the first unlocking script further comprises a context information portion, and the target challenge value e is further derived from the context information portion.

18. The candidate statements are represented by an elliptic curve point generator G and a number of public keys PK i said public key PK i Each of them is a secret witness i Corresponding to at least one secret witness w j is known and there is at least one secret witness w i is unknown, and the method comprises: i In contrast, Target challenge value e i randomly selecting The target challenge value e i , the elliptic curve point generator G, and the public key PK i Based on the challenge solution part π i and simulating The method of claim 14, further comprising:

19. Challenge solution part π i The step of simulating each unknown secret witness w i In contrast, Simulated Answers i randomly selecting The target challenge value e i , the elliptic curve point generator G, the simulated answer z i , and said public key PK i Based on the simulated target commitment A i and calculating Equipped with The challenge solution portion π i But the simulated answer z i , the simulated target commitment A i , and the target challenge value e i 20. The method of claim 18, comprising:

20. The first unlocking script further comprises a context information portion, and the method further comprises: said at least one unknown confidential witness w i The challenge solution portion π corresponding to i , said at least one known witness w j The target commitment A j , and the simulated target commitment A i calculating a target offset o based on the target offset o, the secret value r, and the known witness w j Based on the at least one known secret witness w j The challenge solution part π j and calculating Further equipped with The challenge solution π is i The challenge solution portion π corresponding to i 20. The method of claim 19, derived from:

21. The candidate statements are represented by an elliptic curve point generator G and a number of public keys PK i said public key PK i Each of them is a secret witness i Corresponding to at least one secret witness w j is known and there is at least one secret witness w i is unknown, and the target commitment A is transmitted to the known private witness w j Related Goal Commitment A j and said process further comprises: The above-mentioned goal commitment A j to a collaborator; From the above collaborators: At least one simulated proof part π i Each simulated proof portion π i is the simulated target commitment A i At least one simulated proof part π derived from i , A randomly selected collaborator secret value r c Goal-partner commitment A derived based on c , The above-mentioned goal commitment A j , the simulated target commitment A i , the collaborator goal commitment A c , and the plurality of public keys PK i A target offset value o derived based on a target challenge value e derived based on the target offset value o; and The target challenge value e and the cooperating secret witness w c The collaborator response value z derived based on c receiving the The target challenge value e and the known secret witness w j Based on the target answer value z j and calculating Further equipped with The challenge solution π is the target answer value z j , the participant response value z c , the target challenge value e, and the at least one simulated proof portion π i The method of claim 14 comprising:

22. The candidate statements are represented by an elliptic curve point generator G and a number of public keys PK i said public key PK i Each of them is a secret witness i Corresponding to at least one secret witness w j is known and there is at least one secret witness w i is unknown, and the target commitment A is transmitted to the known private witness w j Related Goal Commitment A j and said process further comprises: A randomly selected collaborator secret value r c At least one goal-partner commitment A derived based on c receiving each target collaborator commitment A c are generated by each collaborator, and At least one simulated proof part π i generating each simulated proof portion π i is the simulated target commitment A i and the above-mentioned Target Commitment A j and the target collaborator commitment A c and The above-mentioned goal commitment A j , the simulated target commitment A i , said at least one collaborator goal commitment A c , and the plurality of public keys PK i calculating a target offset value o and a target challenge value e, derived based on The at least one simulated proof portion π i and transmitting the target offset value o to each collaborator; The target offset value o and the cooperating secret witness w c Each participant's response value z is derived based on c receiving from each collaborator; Further equipped with The challenge solution π is the target answer value z j , the participant response value z c , the target challenge value e, and the at least one simulated proof portion π i The method of claim 14 comprising:

23. a memory comprising one or more memory units; a processing device comprising one or more processing units; 23. A computing device comprising: a processor; and a memory for storing code adapted to be executed on the processor; the code configured, when on the processor, to perform a method according to any one of claims 1 to 22.

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

Images