Proof and verification of statements

Abstract

1. A method of providing a proof that a statement is true while keeping the secret input to the statement secret, comprising: generating a proof using a public input, a secret input, and a proof key associated with an extended verification circuit, the extended verification circuit comprising: (i) a verification circuit adapted to accept an input, provide a secret input representing the statement to a function circuit to generate a function circuit output, and determine whether the public input corresponds to the function circuit output; and (ii) a multiplication gate adapted to accept the secret input and a dummy value. The proof comprises a commitment to an input of the multiplication gate of the extended verification circuit, the commitment being generated using a first vector comprising n elements from a finite set of data elements. The secret input is the discrete logarithm of a public element of the finite set. The proof is transmitted to a verification device.

Description

[Technical field]

[0001] This disclosure relates to proving and verifying statements. In particular, certain embodiments relate to proving (and verifying) that a statement is true while keeping a secret input to the statement secret. The embodiments extend to proving (and verifying) that a secret committed in a batched commitment is the discrete logarithm of a public element of a finite set of data elements. [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 called "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 the storage of 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") perform 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, and the nodes attempt to identify a valid proof-of-work solution for that block template. 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 so that it can be disseminated. Nodes that receive a transaction can 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 thereby 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 referred to as 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 referred to as 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 a 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 “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 unlock script for unlocking the output of the first transaction.

[0007] In such a model, when the second target transaction is sent to the blockchain network to be disseminated and recorded in the blockchain, one validity criterion 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.

[0009] Blockchain provided a decentralized, permissionless, global mechanism that allowed solving the problem of equivalent exchange between two mutually distrustful parties without the need for third-party coordination or escrow. The equivalent exchange of data or information for monetary compensation or in exchange for information such as digital goods is embodied in a transaction protocol known as Zero-Knowledge Contingent Payments (ZKCP). In ZKCP, specified data is transferred from seller to buyer only if the payment is confirmed, and payment from buyer to seller is completed only if the specified data is valid according to the terms of the sale. The details of such a protocol are known, but it is essentially based on a combination of hash-time-locked contracts (HTLCs) with zero-knowledge proofs, which simultaneously verify that some encrypted information (the "digital goods") is valid / correct and that the "password" to decrypt this information is the data that must be revealed on the blockchain to claim the payment.

[0010] The central component of the ZKCP protocol is a zero-knowledge proof for a set of dependent statements about the validity or correctness of the data / information, the validity of the key, and its corresponding hash value. Such complex compound statements require an efficient zero-knowledge proof system for general computation. Essentially, this allows one party to run an arbitrary program with a secret input and then prove to another party that the program accepted the input as valid and ran correctly, without revealing anything about the secret input or the program's execution.

[0011] Zero-knowledge SNARKs (zkSNARKs) provide a way to prove, in zero-knowledge, the validity of any computation that can be expressed as an arithmetic circuit. The two main notable properties of zkSNARKs are that they are non-interactive (the prover sends the proof to the verifier in a single move) and succinct (the proofs are small and easy to verify). Summary of the Invention [Means for solving the problem]

[0012] The well-known Zero-knowledge Succinct Non-interactive ARguments of Knowledge (zk-SNARKs) are an implementation of a generalized illumination system for the satisfiability of arithmetic circuits. In the SNARK framework, a statement encoded as an arithmetic circuit is transformed into a construct called a Quadratic Arithmetic Program (QAP), which consists of a set of polynomials. A statement can then be proved by demonstrating the validity of this set of expressions at a single point. The main advantages of the SNARK method are that the verifier only needs to perform a small number of elliptic curve (pairing) operations (taking a few ms), and the proofs are very small (288 bytes) and independent of the circuit size.

[0013] The very small proof and verification times achieved by SNARK methods come at the cost of trusted set-up, non-standard cryptographic assumptions, and a much heavier computational burden imposed on the prover. SNARK methods also require the use of elliptic curve bilinear pairings. However, the use of computationally feasible bilinear pairings requires the use of special "pairing-friendly" elliptic curves. This precludes the use of many standard cryptographic elliptic curve parameter sets, including Bitcoin secp256k1. Statements involving general elliptic curve point multiplication must then utilize explicit circuits (which can be very large).

[0014] In addition, incorporating explicit elliptic curve multiplication (key-statement) into the circuit increases both the proof key size and the proof generation time by at least an order of magnitude.

[0015] The present invention enables zero-knowledge proofs of statements that involve elliptic curve public-private key relations simultaneously with the satisfiability of general arithmetic circuits. This is achieved at a small computational cost beyond proving the satisfiability of arithmetic circuits, and obviates the need to create explicit arithmetic circuits for elliptic curve point multiplication operations, which would significantly increase the computational cost of the proof.

[0016] According to one aspect disclosed herein, there is provided a computer-implemented method for providing a proof that a statement is true while keeping a secret input to the statement secret, the method running on a computing device, comprising: generating a zero-knowledge proof using the public input, the private input, and a proof key associated with the extended verification circuit (500); The enhanced verification circuit comprises: (i) a verification circuit (400) adapted to accept a public input and a secret input, to provide the secret input representing a statement to a function circuit (402) to generate a function circuit output, and to determine whether the public input corresponds to the function circuit output; and (ii) a multiplication gate (502) adapted to accept the secret input and a dummy value; the zero-knowledge proof comprises a batched commitment to an input of a multiplication gate of an extended verification circuit (500), the batched commitment being generated using a first vector comprising n elements from a finite set of data elements, and the secret input being the discrete logarithm of a public element of said finite set of data elements; Steps and and transmitting the zero-knowledge proof to a verification computing device to enable the verification computing device to verify that the computing device has knowledge of the secret input.

[0017] According to another aspect disclosed herein, there is provided a computer-implemented method for verifying that a statement is true without knowledge of a secret input to the statement, the method being executed on a computing device and comprising: receiving a zero-knowledge proof from a proof computing device; obtaining a statement; verifying that the zero-knowledge proof is valid using the zero-knowledge proof, the public input, and a verification key associated with the extended verification circuit; the augmented verification circuit comprises: (i) a verification circuit adapted to accept a public input and a secret input, to provide the secret input representing a statement to a function circuit to generate a function circuit output, and to determine whether the public input corresponds to the function circuit output; and (ii) a multiplication gate adapted to accept the secret input and a dummy value; the zero-knowledge proof comprises a batched commitment to an input of a multiplication gate of an extended verification circuit, the batched commitment being generated using a first vector comprising n elements from a finite set of data elements, and a secret input being the discrete logarithm of a public element of the finite set of data elements; Steps and and determining that the attesting computing device has knowledge of the secret input based on the verification.

[0018] To aid in understanding 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. [Brief description of the drawings]

[0019] [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. [Figure 3A] FIG. 2 is a schematic block diagram of a client application. [Figure 3B] FIG. 3B is a schematic mock-up diagram of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4]FIG. 2 is a schematic block diagram of a verification circuit; [Diagram 5] FIG. 2 is a schematic block diagram of an extended verification circuit; [Figure 6] FIG. 1 illustrates inputs to the proof generation process. [Figure 7] FIG. 1 illustrates inputs to the proof verification process. [Figure 8] FIG. 1 illustrates how to prove (and verify) that a secret committed in a batched commitment is the discrete logarithm of a public element of a finite set of data elements. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0021] 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 high-value disk drives.

[0022] The blockchain 150 comprises a chain of blocks 151 of data, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in the distributed network or blockchain network 101. 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 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 be unlocked and redeemed or spent). Each input points to the output of a preceding transaction 152, thereby linking those transactions.

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

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

[0025] For 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. In general, the preceding transaction can be any transaction in the ordered set 154 or any block 151. The 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 the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" in this specification refers to something that precedes in the logical sequence linked by the pointer, and does not necessarily refer to the time of creation or transmission in the temporal order, and therefore does not necessarily exclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below on orphan transactions). The preceding transaction 152i may also be referred to as an ancestor transaction or a predecessor transaction.

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

[0027] According to an output-based transaction protocol such as Bitcoin, when a participant 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 participant), the defining participant transmits the new transaction from his computer terminal 102 to the recipient. The defining participant or the 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 participant 103 implementing 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 check 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 assigns, which condition typically comprises at least verifying that a cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of a previous transaction 152i to which the input of the new transaction is chained. 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.

[0028] 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 the transaction attempts to allocate or redeem has not yet been redeemed by another transaction. Again, if 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 protects against double spending, such as when a transactor attempts to allocate the same transaction output more than once. On the other hand, an account-based model protects against double spending by maintaining an account balance. Again, because there is a defined order of transactions, the account balance has a single defined state at any given time.

[0029] 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 valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. 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.

[0030] The first blockchain node 104 that attempts to solve the puzzle announces this to the network 106 and provides the solution as a proof that can be easily verified 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 thereby 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, for example 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 assigns 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.

[0031] 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 where 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.

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

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

[0034] 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 nodes 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.

[0035] 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 building 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).

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

[0037] 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 performed 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 network-connected resources, such as cloud computing resources accessed via a user terminal.

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

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

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

[0041] 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 the transactions of other participants in the blockchain 150, since the blockchain 150 is a public entity that provides credit for some transactions 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 the 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.

[0042] 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, it 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 "valid", an example of which will be discussed in more detail shortly. In some transaction protocols, the condition for validation 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.

[0043] Provided that the newly received transaction 152j passes the test to be considered as valid (i.e., it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained by 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.

[0044] 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 ordered sets of transactions 154, 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.

[0045] 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 accepts it and discards (i.e., treats as invalid) the instance it first accepted (i.e., the instance not published in block 151).

[0046] 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, the optional data field may also be the signed transaction. This data field may point to a previous transaction, for example if a previous transaction ID is included in the data field.

[0047] 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. It should be noted that although the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented on other exemplary blockchain networks.

[0048] 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. It 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.

[0049] 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 " will be labeled. 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 " will be labeled. Tx 0 and Tx 1 are just arbitrary labels. 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.

[0050] Preceding transaction Tx 0 Alice creates a new transaction Tx 1 When Tx creates the block 151, 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 be 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.

[0051] Preceding transaction Tx 0 One of the one or more outputs 203 of 0 Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO, and a locking script that defines a condition that must be met by an unlocking script in the input 202 of a subsequent transaction for the subsequent transaction to be validated, and thus for the redemption of the UTXO to be successful. 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 an unlocking condition, which typically comprises a condition that the unlocking script in the input of the subsequent transaction comprises a cryptographic signature of the party to which the preceding transaction is locked.

[0052] A lock 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 lock script specifies what information is needed to consume the transaction output 203, e.g., the requirements of Alice's signature. An unlock script appears in the output of the transaction. An unlock script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to meet the lock script criteria. For example, it may include Bob's signature. An unlock script appears in the input 202 of the transaction.

[0053] Thus, in the example shown, Tx 0 UTXO in output 203 0 UXTO 0 To be able to redeem (strictly speaking, UTXO 0 Alice's signature Sig P must be present in order for any subsequent transactions attempting to redeem the token to be valid. A Requires lock script [Checksig P A ]. [Checksig P A ] is the public key P from Alice’s public-private key pair. A 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 0 It has an index that identifies the Tx 1The input 202 further includes an unlock script with Alice's cryptographic signature, which is created by Alice applying her private key from the key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0054] New transaction Tx 1 When the arrives at a blockchain node 104, the node applies the node protocol, which comprises running the lock script and the unlock script together to see if the unlock script meets the conditions defined in the lock 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 contained in the lock 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 lock script in the output of A Using Tx 1 The input of Tx authenticates that the unlock script contains Alice's signature signing the expected portion of the data. The expected portion of the data itself (the "message") must also be included in order to perform this authentication. In an embodiment, the signed data is 1(Thus, there is no need to include a separate element specifying the signed portion of the data in plaintext, since that was already there).

[0055] 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., in embodiments means signing a hash of that data or transaction piece.

[0056] Tx 1 The unlock script in Tx 0 If one or more conditions specified in the lock 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 valid when consuming an unconsumed transaction output 203. If an attempt is made to consume an output that has already been consumed by another transaction 152, then Tx 1 is invalid even if all other conditions are met. Therefore, the blockchain node 104 may not 0 It is also necessary to ascertain whether a referenced UTXO in has already been spent (i.e., has already formed valid inputs into another valid 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 valid inputs into another valid transaction in the blockchain 150.

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

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

[0059] In practice, Alice should normally also include a fee for Bitcoin nodes 104 that successfully include Alice's 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.

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

[0061] 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 the lock 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.

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

[0063] A lock script is sometimes referred to as a "scriptPubKey", referring to the fact that the lock script typically comprises the public key of the party for which the respective transaction is locked. An unlock script is sometimes referred to as a "scriptSig", referring to the fact that the unlock 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, the scripting language may be used to define any condition or conditions. Thus, the more general terms "lock script" and "unlock script" are sometimes preferred.

[0064] Client Software 3A illustrates an exemplary implementation of a client application 105 for implementing embodiments of the schemes disclosed herein. The client application 105 comprises a transaction engine 301 and a user interface (UI) layer 302. The transaction engine 301 is configured to perform transaction-related functions behind the scenes of the client 105, such as orchestrating transactions 152 and sending the transactions to one or more nodes 104 for dissemination through the blockchain network 106, according to schemes as discussed above and in more detail shortly.

[0065] The UI layer 302 is configured to render a user interface via user input / output (I / O) means of the device 102, including outputting information to each user 103 via a user output means of the respective user's computing device 102, and receiving input from each user 103 via a user input means of the device 102. For example, the user output means may comprise one or more display screens (touch screen or non-touch screen) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing haptic output, etc. The user input means may comprise, for example, one or more touch screen input arrays (same or different as those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and speech or voice recognition algorithms for receiving speech or voice input, one or more gesture-based input devices for receiving input in the form of hand or body gestures, or one or more mechanical buttons, switches, or joysticks, etc.

[0066] Note: although various functions herein may be described as being integrated into the same client application 105, this is not necessarily limiting, and instead they may be implemented in a suite of two or more separate applications, e.g., one plugging into the other or interfacing via an API (Application Programming Interface). For example, the functionality of the transaction engine 301 may be implemented in a separate application from the UI layer 302, or the functionality of a given module, such as the transaction engine 301, may be split between more than one application. It is not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Where reference is made anywhere in this specification to a single or given application 105, etc., it will be understood that this is by way of example only, and more generally, the described functionality may be implemented in any form of software.

[0067] 3B provides a mock-up of an example user interface (UI) 300 that may be rendered by the UI layer 302 of the client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by the client 105b on Bob's device 102b, or any other participant's client.

[0068] As an example, Figure 3B shows the UI 300 from Alice's perspective. The UI 300 may comprise one or more UI elements 351, 352, 353 that are rendered as separate UI elements via user output means.

[0069] For example, the UI elements may comprise one or more user selectable elements 351, which may be different on-screen buttons, or different options in a menu, etc. User input means are provided to allow a user 103 (in this case Alice 103a) to select or otherwise manipulate one of the options, such as by clicking or touching the UI element on the screen, or by speaking the name of the desired option (note that the term "manual" as used herein is intended only to contrast with automatic, and is not necessarily limited to using hands). The options allow the user (Alice) to organize transactions 152 and send them to one or more nodes 104 for dissemination through the blockchain network 106.

[0070] Alternatively or additionally, the UI element may comprise one or more data entry fields 352, through which a user can organize transactions 152 and submit them to one or more nodes 104 for dissemination through the blockchain network 106. These data entry fields may be rendered via a user output means, e.g., on a screen, and data may be entered into the fields via a user input means, e.g., a keyboard or touch screen. Alternatively, data may be received orally, e.g., based on speech recognition.

[0071] Alternatively or additionally, the UI elements may comprise one or more information elements 353 for outputting information to the user. For example, this / these may be rendered on a screen or in sound.

[0072] It will be understood that the particular means of rendering the various UI elements, selecting options, and inputting data are not important. The functionality of these UI elements will be discussed in more detail shortly. It will also be understood that the UI 300 shown in FIG. 3B is merely a schematic mockup, and may in fact comprise one or more additional UI elements that are not shown for the sake of brevity.

[0073] Commitment At the heart of many interactive zero-knowledge protocols is a commitment scheme, which is used for the satisfiability of arithmetic circuits. A commitment allows a prover to commit to a secret value in advance and then verifiably reveal (publish) the secret value at a later time. A commitment scheme has two main properties: first, it is confidential - the commitment keeps the value secret; second, it is binding - the commitment can only be opened to the original committed value. The Pedersen commitment scheme involves two elliptic curve generating points, G and F, in a group G of prime order p, known to all parties. The committers are responsible for determining whether a given elliptic curve is generated by a group G in the field Z of primes. p Generate a secure random number r in , and then compute the commitment (via elliptic curve addition / multiplication) to a secret value s. Com(s,r) = s × G + r × F Here, × denotes elliptic curve point multiplication.

[0074] The committer can fully disclose the commitment at a later stage (i.e., the commitment can be verified) by providing the values ​​s and r. The committer can also disclose the commitment in response to a particular challenge value as part of the Σ protocol, without revealing the secret s or the random number r.

[0075] Pedersen commitments are additive homomorphic, which means that the addition (on an elliptic curve) of two commitments yields a commitment to the sum of the committed values, i.e. (s 1 ×G+r1 ×F)+(s 2 ×G+r 2 ×F)=(s 1 +s 2 )×G+(r 1 +r 2 )×F

[0076] Proofs of satisfiability for arithmetic circuits can be achieved in "zero knowledge". p A arithmetic gate (above) is a hypothetical construct of arithmetic gates (forming a directed acyclic graph) connected by wires that can perform arbitrarily complex computations, provided that the computations are not limited to integer arithmetic and have no data-dependent loops or mutable state.

[0077] Each gate has two input wires and one output wire, and performs either a multiplication (×) or addition (+) operation on the inputs.

[0078] In reality, a complete circuit has free input wires and free output wires that define the external (circuit) input and output values. The legal assignment is the definition of the values ​​of such wires such that they satisfy the circuit, i.e., each wire is assigned a value, and then the output of each gate corresponds correctly to the product or sum of its inputs (i.e., the gate is consistent).

[0079] Several methods have been developed to significantly improve the performance of the parallel Σ-protocol approach to proving the satisfiability of arithmetic circuits. Known methods, including those by Bootle and Groth, involve batching commitments to circuit wire values ​​to significantly reduce the size of the data that must be transmitted from the prover to the verifier (i.e., lowering the communication complexity).

[0080] Again, as a comparison for proving the satisfiability of the same SHA circuit, the Bootle protocol has a proof key size of just 5KB and a key generation time of 180ms. The proof size is 24KB and takes about 4 seconds to generate, and the proof also takes about 4 seconds to verify.

[0081] These methods will not be described in full here, other than to note that the main vector batch processing protocol employed is described in the following steps. It follows the same properties as the standard Pedersen commitment, but for n elements (m=m 1 ,…,m n ) requires only the transmission of a single group element. 1. The prover and verifier agree on a group element F ← G 2. The prover generates n random numbers x 1 ,…,x n ←Z p Generate 3. The prover is point K. i =x i × F for i = 1, ..., n. These values ​​form the proof key PrK that is sent to the verifier. 4. The prover sets a random value r ← Z p Generate 5. Prover makes a commitment

[0082]

number

[0083] and send it to the verifier.

[0084] A vector Pedersen commitment, or batched Pedersen commitment, is a vector

[0085]

number

[0086] A single point

[0087]

number

[0088] Here, we generalize the Pedersen scheme for commits using

[0089]

number

[0090] is called an elliptic curve of prime order p, or a subgroup of the curve.

[0091]

number

[0092] The points in are written as superscripts,

[0093]

number

[0094] Field elements in are denoted by subscripts and vectors are in bold.

[0095] There are two algorithms in this scheme: Elliptic Curve

[0096]

number

[0097] The description of is considered to be an implicit input to both algorithms. · Commit Com(x,CK;r): input message vector

[0098]

number

[0099] , random element

[0100]

number

[0101] , and a commitment key

[0102]

number

[0103] Regarding the output points: C = r × G 0 +x 1 ×G 1 +...+x n ×G n Here, the commitment operation outputs a linear combination of commitment key components determined by the message scalars x1,...,xn and the randomness r. Verify commit VerifyCom(x,r,C,CK): Disclose input

[0104]

number

[0105] , Commitment

[0106]

number

[0107] , and a commitment key

[0108]

number

[0109] About C * Calculate =Com(x,CK;r). * If b=C, output b=T (accept), otherwise output b=⊥ (reject). Here, the verify commit operation re-executes the commit operation and checks for the given messages x=x1,...,xn and randomness r.

[0110] Providing proof of statements In general, one aspect of the invention is a computer-implemented method for enabling zero-knowledge proofs or verifications of statements. A prover can use the methods herein to prove to a verifier that a statement is true while keeping a witness to the statement private. In some embodiments, the statement is a compound statement that simultaneously involves both the satisfiability of an arithmetic circuit and a dependent statement about the validity of a public key (a key-statement proof).

[0111] The methods herein can be used in known protocols for circuit satisfiability, such as existing discrete logarithm-based zero-knowledge proof protocols. The methods are particularly suited to protocols that do not require the use of bilinear pairing-friendly elliptic curves.

[0112] The present invention enables efficient zero-knowledge verification of compound statements that simultaneously involve both the satisfiability of an arithmetic circuit and dependent statements about the validity of a public key (key-statement proofs). To prove the satisfiability of a circuit, the specification of a public-key elliptic curve is exploited within a homomorphic commitment function. This allows efficient proof of public-key statements that correspond to private keys used as circuit inputs and / or outputs.

[0113] The proof size and computational cost of generating proofs for statements involving both circuit satisfiability and elliptic curve key pairs can be greatly reduced. The methods herein can be easily integrated into existing discrete log-based zero-knowledge proof protocols for circuit satisfiability that do not require the use of bilinear pairing-friendly elliptic curves. Methods using discrete log-based zero-knowledge proofs are fully compliant with the Bitcoin secp256k1 standard.

[0114] The present invention relates to a method for enabling the proof of a certain class of compound statements that involve an elliptic curve public / private key pair (based on elliptic curve point multiplication).

[0115] Since it is deemed impractical to use zkSNARKs to prove statements involving arbitrary cryptographic elliptic curve key operations, the method uses information about the elliptic curve public key that is extracted directly from the "homomorphic privacy" (or commitment scheme) used in constructing proofs for general circuit satisfiability. The particular type of elliptic curve involved in the method's statements is the same as that used in the circuit commitment scheme.

[0116] However, SNARK methods require special bilinear pairing-friendly elliptic curves because they involve pairing operations. This precludes the use of zk-SNARKs based on elliptic curves (e.g., Groth16) because the elliptic curves used by some blockchains are not compatible with bilinear pairing-friendly elliptic curves. As an example, statements about Bitcoin public keys use the Bitcoin secp256k1 curve, which is not compatible.

[0117] Thus, the methods of the present invention are compatible with alternative protocols for providing satisfiability of arithmetic circuits that do not rely on pairings and make fewer cryptographic assumptions. Embodiments of the present disclosure use zk-SNARKs based on discrete logarithms (e.g., Bootle and Bulletproof groups of zk-SNARKs). Overall, the methods of the present invention are more efficient than elliptic curve-based zkSNARKs, as they require fewer computations and reduce proof sizes for trustless exchange applications.

[0118] FIG. 4 shows a verification circuit 400, which is itself an arithmetic circuit.

[0119] The verification circuit 400 receives a public input

[0120]

number

[0121] and a secret input (sk). The secret input (sk) may be any value that is not revealed to the verifier. For example, the secret input (sk) may be a private key. An example of a private key is a signing key, such as an Elliptic Curve Digital Signature Algorithm (ECDSA) signing key. We refer to the input (sk) as being "secret" in the sense that it is not revealed to the verifier.

[0122] Specifically, a function circuit 402 (itself an arithmetic circuit) that represents a statement that the prover wishes to prove receives a secret input sk and produces a function circuit output P(sk). For any term P∈

[0123]

number

[0124] It is assumed that the body

[0125]

number

[0126] is the field element {0,1,2,…,p-1} that is the remainder of n modulo p arithmetic, where n is an integer and p is a prime number. P is

[0127]

number

[0128] -arithmetic circuit C 402. The function circuit 402 comprises a number of arithmetic gates connected by wires and is capable of performing arbitrarily complex calculations. Each gate has two input wires and one output wire, and performs either a multiplication (x) or an addition (+) operation on the inputs.

[0129] The equivalence checking module 404 checks the public input

[0130]

number

[0131] and the function circuit output P(sk) and the public input

[0132]

number

[0133] corresponds to the function circuit output P(sk) and gives a true / false result.

[0134]

number

[0135] Evaluates to true if and only if.

[0136] Therefore, the published value

[0137]

number

[0138] Given,

[0139]

number

[0140] A party that claims to be s k = s k ⁢ ... but does not want to reveal the secret input s k can generate a zero-knowledge argument to this statement using verification circuitry 400. Specifically, a prover can prove a statement such as Statement 1: "P(sk) is the hash of sk under the SHA256 function." Statement 2: "P(sk) is the result of decomposing sk into two subvectors of equal length, adding them together, and taking the dot product with the public vector v." · Any other statement with a predicate P that can be expressed as an arithmetic circuit.

[0141] In verification circuit 400, the secret input sk must be an input wire to verification circuit 400, but not necessarily a wire of a multiplication gate, since it is desirable to consider an arbitrary term P on the secret input sk. For example, for a given byte array

[0142]

number

[0143] To determine whether s is a hash of a secret input sk under SHA-256, a predicate circuit C implements a hash function

[0144]

number

[0145] The above is the arithmetic circuit.

[0146] FIG. 5 shows an extended verification circuit 500, which is itself an arithmetic circuit.

[0147] The extended verification circuit 500 comprises the verification circuit 400 and a dummy multiplication gate 502. The dummy multiplication gate 502 is adapted to receive a secret input sk and a dummy value (d). The dummy value (d) can be any value. As shown in FIG. 5, the output d*sk of the multiplication gate 502 is not coupled in any way to the verification circuit 400 and does not provide an output of the extended verification circuit 500. Within the verification circuit 400, the outputs of the multiplication gates that are not outputs of the extended verification circuit 500 are referred to herein as auxiliary variables.

[0148] The zkSNARK proof system uses a matrix a i* The use of the dummy multiplication gate 502 (with the secret input sk fed to it as input) allows the secret input sk to be collected and committed to all of the columns of this matrix a during the generation of the proof. i* , and therefore ensures that the prover commits to the secret input sk during proof generation.

[0149] The zkSNARK protocol generally consists of three steps. a Preparation: Under an arithmetic circuit (e.g., the extended verification circuit 500), a pair of attestation and verification keys is calculated. In the example of the Bootle and Bulletproof groups of zk-SNARKs, the preparation stage comprises verifiably generating a Pedersen commitment key, which is used as both the attestation and verification keys. b. Proof Generation (the prover performs proof generation): Given the proof key, the public component of the arithmetic circuit X (which includes the public inputs to the arithmetic circuit, the public outputs of the arithmetic circuit, and any public auxiliary variables), and the private component of the arithmetic circuit W (which includes the secret inputs to the arithmetic circuit, and any private auxiliary variables), the prover generates a proof π and sends it to the verifier. c. Verification (the verifier runs the verification protocol): The verifier receives the proof π. With the verification key and the public components X of the arithmetic circuit (which includes the public inputs to the arithmetic circuit, the public outputs of the arithmetic circuit, and any public auxiliary variables), the verifier performs verification of the proof π.

[0150] Thus, during the preparation phase, the attestation key PrK and the verification key VK are calculated under the extended verification circuit 500. The attestation key PrK and the verification key VK may be the same (e.g., a common reference string) or they may be different from each other (depending on the type of zkSNARK).

[0151] 6 illustrates inputs provided to a proof generation process 600 performed by a prover's proof computing device. For example, the prover may correspond to Alice 103a associated with the prover computing device 102a. As illustrated in FIG. 6, to provide a proof that a statement (represented by function circuit 402) is true while keeping a secret input sk secret, the prover computing device 102a generates a zero-knowledge proof using a public component X of the extended verification circuit 500, a private component X of the extended verification circuit 500, and a proof key PrK associated with the extended verification circuit 500 to generate a zero-knowledge proof π.

[0152] The attestation computing device 102a may then transmit the zero-knowledge proof π to the verification computing device to enable the verification computing device to verify that the computing device has knowledge of the secret input.

[0153] The prover computing device 102a may transmit the statement to the verification computing device. The statement may be transmitted together with the transmission of the zero-knowledge proof π or in a separate transmission. In some implementations, the verification computing device may obtain the statement by other means and it is not necessary for the prover computing device 102a to transmit the statement to the verification computing device.

[0154] In an embodiment of the present invention, the zkSNARK proving system uses the Pedersen commitment scheme to commit to the inputs of the multiplication gates of the extended verification circuit 500. Consider the extended verification circuit 500 as a circuit C with N=mn multiplication gates, where m and n are integers. For the i-th multiplication gate, the left input, right input, and output wires are respectively (a i ,b i ,c i ) where all left input wires are in row a i m × n matrix M a In the example, all right input wires are arranged in row b i The matrix M b In the example shown in FIG. 1, all output wires are arranged in a row c i The matrix M c In the following, the matrix M a Row a i* i is the index of * Mention the following.

[0155] Specifically, the proof π is a vector a using the commitment key CK and random values. i* (otherwise referred to herein as the first vector) i* This is A i* =Com(a i* ,CK;r) It can be expressed as:

[0156] A i* is the matrix M aA is a commitment to the i-th row of A, which is part of the circuit satisfiability argument. i* is an elliptic curve

[0157]

number

[0158] It could be the above point.

[0159] Vector a i* A vector a has "n" components from a finite set of data elements, where n is an integer value. i* In (position j * One of the n components in is a secret input sk, which is the discrete logarithm of the elements of a finite set of data elements. The finite set of data elements is the elliptic curve

[0160]

number

[0161] For example, the secret input sk may be a signing key, and the above mentioned elements may be a public key PK corresponding to the signing key (then the public key PK may be a scalar of the elliptic curve

[0162]

number

[0163] (The above point)

[0164] As mentioned above, the use of the dummy multiplication gate 502 (to which the secret input sk is fed as input) ensures that the secret input sk is collected and that it is the vector a during proof generation. i* Make sure that the vector a is a component of i* is kept secret by the attesting computing device (it is not shared with the verifying computing device).

[0165] The commitment key CK is also a finite set of data elements (vector a i* is a vector with "n" components (where n is an integer) from the set of n elements (which has the same number of components as n). This can be expressed as:

[0166]

number

[0167] Here, each G i is from a finite set of data elements, e.g. an elliptic curve

[0168]

number

[0169] It is a point in .

[0170] As mentioned above, in the example Bootle and Bulletproof groups of zk-SNARKs, the attestation key and verification key are the same, and they correspond to (i.e. are the same as) the commitment key CK.

[0171] The embodiments extend to other discrete log-based zero-knowledge proof schemes. Thus, depending on the specific discrete log-based zero-knowledge proof scheme being used, the proof key and verification key may be the same, but the commitment key CK may be different from the proof / verification keys. In other implementations, the proof key and verification key may be different from each other and from the commitment key CK.

[0172] One of the n components of the commitment key vector CK (position j * ) is the first vector a i* Position j in * The elliptic curve at a given position corresponding to

[0173]

number

[0174] The jth commitment key CK can be used as a reference point. * The th generator G j* can be the reference point G of the ECDSA scheme. In other words, if the public key PK is j * The th generator G j* can be obtained by multiplying with the secret input sk. This means that PK=skG j* It can be expressed as:

[0175] More generally, some element of a finite set of data elements (not necessarily the public key PK) is j of the commitment key CK. * The th generator G j* of,

[0176]

number

[0177] may be obtained by multiplying it by a secret input (not necessarily a signing key), which may be any integer in

[0178] The commitment key CK is made public to both the attesting computing device and the verifying computing device. Similarly, the public key PK is made public to both the attesting computing device and the verifying computing device.

[0179] Commitment A i* The randomness used to generate

[0180]

number

[0181] is kept secret by the attesting computing device (it is not shared with the verifying computing device).

[0182] Those skilled in the art will understand that the steps involved in the proof generation process performed by a proving computer machine will depend on the particular type of ZKP being implemented, and such steps will be known to those skilled in the art.

[0183] The third verification stage of the zkSNARK protocol returns an accept or reject decision depending on whether the proof is found to be valid or invalid, respectively.

[0184] 7 illustrates inputs provided to a proof verification process 700 performed by a verifier's verification computing device. For example, the verifier may represent Bob 103b associated with the verification computing device 102b.

[0185] The verification computing device 102b receives the zero-knowledge proof π from the proof computing device 102a. The verification computing device 102b also obtains a statement. As shown in Figure 7, to verify that the statement (represented by the function circuit 402) is true without knowledge of the secret input sk to the statement, the verification computing device verifies that the zero-knowledge proof π is valid using the proof π, the public component X of the extended verification circuit 500, and the verification key VK associated with the extended verification circuit 500.

[0186] If the attestation verification process 700 performed by the verification computing device 102b returns a decision acceptance, the verification computing device 102b determines that the attestation computing device 102a has knowledge of the secret input without the secret input being revealed to the verification computing device 102b.

[0187] Anyone with knowledge of this proof π and the corresponding extended verification circuit 500 can verify the computation, making it a non-interactive proof. The verifier does not have any information about the secret sk, and it is computationally infeasible to succeed without the proof being computed correctly, i.e., it is computationally infeasible for the prover to compute an acceptable proof without acting legitimately. The verification key VK assures the verifier that a pre-determined statement (represented by the function circuit 402) is in fact validated without the verifier directly using the extended verification circuit 500.

[0188] Similarly, those skilled in the art will understand that the steps involved in the proof verification process performed by a verifier computing device will depend on the specific type of ZKP being implemented, and such steps will be known to those skilled in the art.

[0189] Thus, taking the example of Statement 1: “P(sk) is the hash of sk under the SHA256 function”, according to an embodiment of the present disclosure, a prover can prove that he knows the preimage(sk) for a given hash digest without revealing that preimage(sk).

[0190] Proof of consistency between private and public keys In addition to proving statements about the secret input sk, embodiments of the present disclosure extend to the proof computing device 102a proving that the secret input sk is the discrete logarithm of some element of a finite set of data elements, and the verification computing device 102b verifying (without knowledge of the secret input sk) that the secret input sk committed in a batched commitment is the discrete logarithm of that element of the finite set of data elements.

[0191] As explained above, a finite set of data elements can be expressed as an elliptic curve.

[0192]

number

[0193] For example, the secret input sk may be a private key (such as a signing key), and the above mentioned elements may be a public key PK corresponding to the private key (then the public key PK may be a scalar of elliptic curve

[0194]

number

[0195] (Point above.) Thus, in one example, embodiments of the present disclosure are extended to proving that a signing key sk corresponds to (i.e., is consistent with) a given public key PK that is published to both the attestation computing device 102a and the verification computing device 102b, without revealing any information about the signing key sk to the verification computing device 102b.

[0196] Specifically, the attesting computing device 102a receives the batched commitment A i* It can be proved that the signing key sk committed in corresponds to the public key PK, i.e., that the signing key sk is the discrete logarithm of the public key PK. This can be done by using the first vector a i* is position j * This involves the attestation computing device 102a certifying that the public key PK includes a signing key sk corresponding to the public key PK in

[0197] Thus, taking the example of statement 1: "P(sk) is the hash of sk under the SHA256 function", in addition to the prover proving that it knows the preimage(sk) for a given hash digest without revealing that preimage, the prover can additionally prove that the preimage(sk) that the prover knows is precisely the signing key corresponding to a known public key PK.

[0198] A method for proving that a signing key sk corresponds to (ie, is consistent with) a given public key PK is described with respect to FIG.

[0199] The method described with respect to FIG. 8 may be used in combination with the use of the extended verification circuit 500 (which is a part of the proof, which is a batched commitment A i* is a vector a with a signing key sk i* (Ensuring that the commitment is to

[0200] However, the method described with respect to Fig. 8 is not limited to an implementation in which the extended verification circuit 500 is used. That is, the method described with respect to Fig. 8 is a method for converting a vector a with a signing key sk into i* It may be used in combination with any other zkSNARKs that generate commitments to, and is not limited to use with Bootle and Bulletproof groups of zk-SNARKs.

[0201] In step S802, the attest computing device 102a generates a further batched commitment U. Specifically, to generate the further batched commitment U, the attest computing device 102a uses a random vector

[0202]

number

[0203] Vector u has n elements, each of which is a random integer value (vector u is a vector a i* Then, the proving computing device 102a finds the location j in u * Insert 0 after -1. This is a vector of length n

[0204]

number

[0205] (also referred to herein as the second vector),

[0206]

number

[0207] That is, the vector

[0208]

number

[0209] One of the n elements (position j) in * in is 0 (n is an integer).

[0210] To generate further batched commitments U, the attestation computing device 102a may

[0211]

number

[0212] The randomness used to generate further batched commitments U

[0213]

number

[0214] is kept secret by the attesting computing device (it is not shared with the verifying computing device).

[0215] The attesting computing device 102a uses the commitment key CK and the random value s to generate a vector

[0216]

number

[0217] Compute a further batched commitment U to

[0218]

number

[0219] It can be expressed as:

[0220] In step S804, the attestation computing device 102a transmits the further batched commitment U to the verification computing device 102b.

[0221] In step S806, the verification computing device 102b generates a random challenge

[0222]

number

[0223] and transmits the random challenge x to the attestation computing device 102a in step S808.

[0224] In step S810, the attesting computing device 102a calculates a first vector a i* , the second vector

[0225]

number

[0226] , and the random challenge x to generate a response to the random challenge x.

[0227] Specifically, the attesting computing device 102a may* The first vector, modified by replacing the signing key in with 0

[0228]

number

[0229] The first vector a is generated by i* Correct the

[0230]

number

[0231] teeth

[0232]

number

[0233] It can be expressed as:

[0234] The attesting computing device 102a uses the random challenge to Corrected first vector

[0235]

number

[0236] to the second vector

[0237]

number

[0238] By combining with the vector a, a response vector v with "n" components is generated (the response vector v is the vector a i* (The number of components is the same as for the vector v.) Specifically, the response vector v is

[0239]

number

[0240] It can be expressed as:

[0241] The attesting computing device 102a also includes a commitment A i* Generate a combined random element t by combining the random values ​​r and s used to generate

[0242]

number

[0243] It can be expressed as:

[0244] The response (v,t) generated by the proving computing device 102a in step S810 comprises a response vector v and a combined random element t.

[0245] In step S812, the prover computing device 102a sends the response (v,t) to the verification computing device 102b.

[0246] In step S814, the verification computing device 102b receives the response (v,t), the batched commitment A i* , a further batched commitment U, and a random challenge x to verify (without knowledge of the secret input sk) whether a secret input sk committed in the batched commitment is a discrete logarithm of an element of a finite set of data elements. In the example of FIG. 8, the verification computing device 102b receives the response (v,t), the batched commitment A i*, the further batched commitment U, and the random challenge x to verify that the attestation computing device 102a has knowledge of the signing key sk corresponding to the public key PK. Specifically, in step S814, the verification computing device 102b verifies that it has knowledge of the signing key sk corresponding to the public key PK. i* Check for consistency between.

[0247] To do this, the verification computing device 102b * Determine whether any component of the response vector v at position j is nonzero. * If the verification computing device 102b determines that the components of the response vector v in are not zero, then verification that the proving computing device 102a has knowledge of the signing key sk corresponding to the public key PK fails.

[0248] position j * If the verification computing device 102b determines that the components of the response vector v in are zero, then further checks are performed.

[0249] Specifically, the verification computing device 102b receives the batched commitment A i* , the random challenge x, the further batched commitment U, and the public key PK to compute a combined commitment A′. Specifically, the combined commitment A′ is

[0250]

number

[0251] It can be expressed as:

[0252] The verification computing device 102b uses the response (v,t), the combined commitment A', and the commitment key CK to verify whether the proof computing device 102a has knowledge of the signing key sk corresponding to the public key PK. As known to those skilled in the art, verifying a Pedersen commitment comprises re-running the commitment algorithm with a given randomness to verify that it outputs the same commitment.

[0253] If this verification is successful, the verifier Computing device 102b determines that the prover Computing device 102a has knowledge of the signing key sk that corresponds to the public key PK.

[0254] Figure 8 shows an elliptic curve

[0255]

number

[0256] 8 is described above with respect to a secret input sk being a signing key and an element of the finite set of data elements being a public key PK, this is by way of example only, and method 800 may be used to prove that any secret input sk committed in a batched commitment is the discrete logarithm of a public element of the finite set of data elements.

[0257] The embodiments of the present disclosure may have a number of different applications.

[0258] Application example I Examples of the present invention as described in the Implementation section above can be applied to ZKCP for outsourced Bitcoin vanity addresses that represent data to be exchanged for payments or access to resources.

[0259] Bitcoin addresses are encoded in a human-readable alphanumeric format (Base58 encoding) to make them easy to publish, copy, and transcribe. The use of this format has led to the popularity of so-called vanity addresses, where the key space is brute-force searched to find a private key that results in an address containing a desired string (such as a name).

[0260] Deriving vanity addresses with significant patterns can be computationally expensive (e.g., the address shown above takes about 10 13 For a given address, the lookup is typically outsourced (requiring the generation of distinct public keys), and there are several online marketplaces where vanity addresses are ordered and sold. This can be done securely using the homomorphic properties of elliptic curve point multiplication.

[0261] While outsourcing the generation is secure, selling vanity addresses is trustless. Either the buyer gets the needed value before the seller gets paid, or the seller gets paid before releasing the needed value, or they both must trust an escrow service. The present invention can be utilized to enable trustless selling of vanity addresses via ZKCP. The steps taken between the buyer / verifier and the seller / prover are described below.

[0262] 1. The buyer and seller agree on the desired vanity pattern (Str) and price (1 Bitcoin) and establish a communication channel, which does not need to be secure. 2. The buyer generates a secure random secret key sk B and generate the corresponding elliptic curve public key, pk B =sk B ×G. 3. Buyer pk B to the seller. 4. The seller then changes i to pk = pk B+ i × G. Perform a search for the required pattern in the Base58 encoded address derived from G. 5. When an address with the required pattern is found, the seller saves the value i, informs the buyer, and sends pk s = i × G and send the SHA256 hash H(i). 6. The seller can also use the techniques described herein to determine if the preimage to H(i) is pk s The purchaser will be provided with proof that the private key corresponds to the 7. The purchaser verifies the proof and confirms that pk=pk B +pk S At this point (by proof), the buyer knows the vanity address (sk) by knowing the value i. B +i) and that a particular value i hashes to h = H(i). 8. The purchaser then creates a hash-time-locked contract (HTLC) transaction Tx 1 (a), which contains an output containing the agreed upon fee (a). This output can be unlocked in two ways. i. At any time, using the signature from the merchant and the hash preimage i. ii. It may be used to prevent consumption of outputs until a specified time or block height, for example using the CHECKLOCKTIMEVERIFY (OP_CLTV) script op, with a signature from the buyer after the specified time. 9. The buyer then signs this transaction and broadcasts it to the blockchain, where it is mined into a block. 10. Once verified, the merchant issues a transaction Tx supplying its signature and the value i to unlock the hash lock. 2 By providing 1 A fee can be charged at the output of i, which is then published on the blockchain. 11. The buyer will receive the private key sk=sk of the final vanity address. B +i can be calculated, where pk = sk × G. 12. If the buyer fails to supply the value i before the specified OP_CLTV time, the seller can provide its own signature to recover the fee (to prevent the fee from being lost due to an uncooperative buyer).

[0263] The transaction is then fully atomic and trustless: the buyer only gets paid if he provides a valid value i, which is published on the blockchain. Due to the private key splitting, this value is useless to anyone else and does not compromise the security of the full private key.

[0264] Application Example II Examples of the present invention may also be applied to the private exchange of data between two parties, each with the respective data to be exchanged being registered on a different blockchain.

[0265] More specifically, the present invention can be applied to privacy-preserving interchain atomic exchanges, which are trustless equivalent exchange protocols that leverage features of blockchain transactions, also known as atomic transactions. The protocol is used to trade two different cryptocurrency tokens on two different blockchains without a third-party centralized exchange. The term "atomic" in this context refers to the nature of an equivalent exchange, where either both parties complete the transaction or both do not.

[0266] A known example of the basic protocol follows these steps: To be secure, both cryptocurrencies used in the exchange must have scripting capabilities that allow for hashed and time-locked contracts. The swap involves two parties, Alice and Bob. In this example, Alice has 1 Bitcoin and agrees to trade it for Bob's 100 Litecoin.

[0267] 1. Alice receives the Litecoin public key P A and send it to Bob. 2. Bob obtains the Bitcoin public key P B and send it to Alice. 3. Alice generates a secure random number x. 4. Alice computes the SHA-256 hash of x, h = H(x). 5. Alice sends a Bitcoin transaction Tx A This creates i. P with a valid signature and a value that hashes to h B Pay 1 Bitcoin to ii. Or, after 24 hours, return 1 Bitcoin to Alice. 6. Alice broadcasts the transaction to the Bitcoin network. 7. Tx A When Bob observes that the Litecoin transaction Tx B This creates i. P with a valid signature and a value that hashes to h A ii. Pay 100 Litecoins to Bob. ii. Or, after 24 hours, return the 100 Litecoins to Bob. 8. Bob broadcasts the transaction to the Litecoin network. 9. Once the transaction is confirmed, Alice can claim the Litecoin output by providing her signature and the value x. 10. Once Bob observes the value x on the Litecoin blockchain, he can claim the Bitcoin output by providing his signature and the value x.

[0268] This example ensures that either both parties get their coins or both don't. Alice generates the hash value, and although only Alice knows the preimage, she is required to reveal this preimage in order to claim her coins, which then allows Bob to claim his coins. If either party does not follow the protocol to completion, both parties can get their coins back after a lockout period.

[0269] One important disadvantageous feature of the known protocols described above is that transactions on both blockchains are trivially connectable, i.e., once confirmed, a unique value x is published forever on both blockchains, which affects both coin fungibility and transaction privacy.

[0270] To unbind the two transactions, a different key must be used for the output on each chain, but for the protocol to be secure and trustless, Bob must be given a proof by Alice that he knows the information needed to unlock Bob's coins when Alice reveals Alice's hash preimage.

[0271] By utilizing the key-statement proofs described in the example above, the hash-locked outputs on the second blockchain may be transformed into ordinary pay-to-public-key-hash (P2PKH) outputs, both disguising the nature of the transaction and breaking any possible ties.

[0272] When applied to the example above where Alice has 1 Bitcoin and is trading it for Bob's 100 Litecoin, the improved process would include the following actions:

[0273] 1. Alice receives the Litecoin public key P A (Secret key S A ) and send it to Bob. 2. Bob obtains the Bitcoin public key P B (Secret key S B ) and send it to Alice. 3. Alice creates a secure random number x←Z p Generate. 4. Alice obtains the SHA-256 hash of x, h=H(x), and x:P x Calculate the elliptic curve public key corresponding to = x × G. 5. Alice is h and P x Securely send both to Bob. 6. Alice says that the inverse image of h is P x The sb_key also sends Bob a proof-of-key statement that the sb_key is equal to the private key that generated it. 7. Alice sends a Bitcoin transaction Tx A This creates i. 1 Bitcoin public key P C =P B +P x pay to. ii. Or pay back 1 Bitcoin to Alice 24 hours later. 8. Alice broadcasts the transaction to the Bitcoin network. 9. Tx A When Bob observes that the Litecoin transaction Tx B This creates i. P with a valid signature and the SHA-256 hash of h A ii. Pay 100 Litecoins to Bob. ii. Or, after 24 hours, return the 100 Litecoins to Bob. 10. Bob broadcasts the transaction to the Litecoin network. 11. Once the transaction is confirmed, Alice can then claim the Litecoin output by providing her signature and the value x. 12. When Bob observes a value x on the Litecoin blockchain, the homomorphic properties of elliptic curve point multiplication give us s B +x is P C" A user can claim the Bitcoin output by providing a signature using the private key for

[0274] Other Applications The present invention is suitable for zero-knowledge proofs or verifications of statements, such that a prover proves to a verifier that a statement (S) is true while keeping a witness (w) to the statement secret. The secret may be handled by a function such as a hash function, but may additionally involve cryptographic elliptic curve key operations, e.g., the validity of the statement on a public key. In the above example, the method of the present invention is used to enable trustless ZKCP for vanity addresses. This may also be applied, for example, to the derivation of passwords, the verification of valid machine-readable documents such as passwords or identification documents, or other such secret transactions.

[0275] It should be noted that the above mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art can design many alternative embodiments without departing from the scope of the invention as defined by the appended claims.

[0276] conclusion 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, not by the described embodiments.

[0277] Some embodiments above are 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 reference 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 properties of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

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

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

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

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

[0282] Aspects of the present disclosure are defined below with reference to the following clauses:

[0283] 1. A computer-implemented method for providing a proof that a statement is true while keeping a secret input to the statement secret, the method running on a computing device, comprising: generating a zero-knowledge proof using the public input, the private input, and a proof key associated with the extended verification circuit; the augmented verification circuit comprises: (i) a verification circuit adapted to accept a public input and a secret input, to provide the secret input representing a statement to a function circuit to generate a function circuit output, and to determine whether the public input corresponds to the function circuit output; and (ii) a multiplication gate adapted to accept the secret input and a dummy value; the zero-knowledge proof comprises a batched commitment to an input of a multiplication gate of an extended verification circuit, the batched commitment being generated using a first vector comprising n elements from a finite set of data elements, and a secret input being the discrete logarithm of a public element of the finite set of data elements; Steps and transmitting the zero-knowledge proof to a verification computing device to enable the verification computing device to verify that the computing device has knowledge of the secret input.

[0284] 2. The computer-implemented method according to clause 1, wherein the batched commitments are batched Pedersen commitments.

[0285] 3. A computer-implemented method according to clause 1 or 2, wherein each of the n components of the first vector corresponds to a respective input of a multiplication gate of the arithmetic circuit, and one of the n components of the first vector is in a position corresponding to an input wire of a dummy multiplication gate adapted to accept a secret input.

[0286] 4. The computer-implemented method according to clause 3, wherein the finite set of data elements is an elliptic curve.

[0287] 5. The computer-implemented method according to clause 4, wherein a public element of said finite set of data elements is a public key and the private input is a signing key.

[0288] 6. The computer-implemented method according to any of clauses 3 to 5, further comprising the step of proving that the secret input is the discrete logarithm of the public element.

[0289] 7. Proving that the secret input is the discrete logarithm of the public input comprises: generating a further batched commitment and transmitting the further batched commitment to a verification computing device; receiving a random challenge from a verification computing device; and generating a response to the random challenge and transmitting the response to a verification computing device to prove that the secret input is the discrete logarithm of the public element.

[0290] 8. The computer-implemented method according to clause 7, wherein the further batched commitments are batched Pedersen commitments.

[0291] 9. The step of generating further batched commitments comprises: generating a second vector having n components, the components of the second vector at predetermined positions corresponding to positions in the first vector being set to zero; and generating further batched commitments by committing to a second vector.

[0292] 10. The computer-implemented method according to clause 9, wherein the remaining components of the second vector are random values.

[0293] 11. The computer-implemented method according to clause 9 or 10, wherein the finite set of data elements is of an elliptic curve, and the step of generating a further batched commitment to the second vector uses a commitment key vector comprising n components from the finite set of data elements, one of the n components of the commitment key vector being a reference point of the elliptic curve at a predetermined position corresponding to a position in the first vector, and the public element being obtained by multiplying said reference point with a secret input.

[0294] 12. In response to receiving the random challenge: modifying the first vector by replacing the secret input at said location with zero to generate a modified first vector; the response comprises a response vector generated by combining the modified first vector with the second vector using a random challenge; and transmitting the response to a validating computing device.

[0295] 13. The computer-implemented method according to clause 12, further comprising combining the random element used to generate the batched commitment with a further random element of a further batched commitment to generate a combined random element, wherein the response comprises the combined random element.

[0296] 14. A computer-implemented method according to any preceding clause, comprising transmitting the statement to a verifying computing device.

[0297] 15. A computer-implemented method for verifying that a statement is true without knowledge of a secret input to the statement, the method running on a computing device, comprising: receiving a zero-knowledge proof from a proof computing device; obtaining a statement; verifying that the zero-knowledge proof is valid using the zero-knowledge proof, the public input, and a verification key associated with the extended verification circuit; the augmented verification circuit comprises: (i) a verification circuit adapted to accept a public input and a secret input, to provide the secret input representing a statement to a function circuit to generate a function circuit output, and to determine whether the public input corresponds to the function circuit output; and (ii) a multiplication gate adapted to accept the secret input and a dummy value; the zero-knowledge proof comprises a batched commitment to an input of a multiplication gate of an extended verification circuit, the batched commitment being generated using a first vector comprising n elements from a finite set of data elements, and a secret input being the discrete logarithm of a public element of the finite set of data elements; Steps and and determining that the attesting computing device has knowledge of the secret input based on the verification.

[0298] 16. The computer-implemented method according to clause 15, wherein the batched commitments are batched Pedersen commitments.

[0299] 17. A computer-implemented method according to clause 15 or 16, wherein each of the n components of the first vector corresponds to a respective input of a multiplication gate of the arithmetic circuit, and one of the n components of the first vector is in a position corresponding to an input wire of a dummy multiplication gate adapted to accept a secret input.

[0300] 18. The computer-implemented method according to clause 17, wherein the finite set of data elements is an elliptic curve.

[0301] 19. The computer-implemented method according to clause 18, wherein a public element of the finite set of data elements is a public key and the private input is a signing key.

[0302] 20. A computer-implemented method according to any of clauses 17 to 19, further comprising verifying, without knowledge of the secret input, that the secret input is the discrete logarithm of the public element.

[0303] 21. The step of verifying that the secret input is the discrete logarithm of the public element comprises: receiving a further batched commitment from the attesting computing device; in response to receiving the further batched commitment, generating a random challenge and sending the random challenge to the attesting computing device; receiving a response to the random challenge from the attesting computing device; and processing the response to verify that the secret input is the discrete logarithm of the public element.

[0304] 22. The computer-implemented method according to clause 21, wherein the further batched commitments are batched Pedersen commitments.

[0305] 23. A computer-implemented method according to clause 21 or 22, wherein the further batched commitments are commitments to a second vector having n elements, and elements of the second vector at predetermined positions corresponding to positions in the first vector are set to zero.

[0306] 24. The computer-implemented method according to clause 23, wherein the remaining components of the second vector are random values.

[0307] 25. A computer-implemented method according to any of clauses 21 to 24, wherein the response comprises a response vector that is a combination of a modified first vector and a second vector using a random challenge, the modified first vector corresponding to the first vector, and the secret input at said location being replaced with a zero.

[0308] 26. The computer-implemented method according to clause 25, wherein the response vector comprises a plurality of components, and the processing step comprises verifying that a component of the plurality of components of the response vector at a predetermined position corresponding to a position in the first vector is not zero.

[0309] 27. The finite set of data elements is an elliptic curve, and the processing step comprises: computing a combined commitment using the batched commitment, the random challenge, the further batched commitment, and the public factor; 27. The computer-implemented method according to any of clauses 21 to 26, comprising: verifying using the response, the combined commitment, and a commitment key vector that the secret input is the discrete logarithm of the public element, wherein the commitment key vector comprises n components from a finite set of data elements, one of the n components of the commitment key vector is a reference point of an elliptic curve at a predetermined position corresponding to a position in the first vector, and the public element is obtained by multiplying the reference point with the secret input.

[0310] 28. A computer-implemented method according to any of clauses 15 to 27, comprising receiving the statement from a verification computing device.

[0311] 29. A computer-implemented method according to any preceding clause, wherein the output of the multiplication gate is not coupled to a verification circuit.

[0312] 30. A computer-implemented method according to any preceding clause, wherein the function circuit implements a hash function, preferably implementing a SHA-256 hash function.

[0313] 31. A computer program which, when read by a computing device, causes the computing device to perform the method of any preceding clause.

[0314] 32. A non-transitory computer-readable storage medium comprising computer-readable instructions that, when read by a computing device, cause the computing device to perform any of the methods of clauses 1 to 30.

[0315] 33. A computing device comprising a processor and a memory, the memory storing instructions that, when executed by the processor, cause the computing device to perform any of the methods of clauses 1 to 30.

[0316] The instructions may be provided on one or more carriers. For example, there may be one or more non-transitory memories, such as programmed memories, such as EEPROM (e.g., flash memory), disks, CD-ROMs or DVD-ROMs, read-only memories (e.g., for firmware), one or more temporary memories (e.g., RAM), and / or data carriers, such as optical or electrical signal carriers. The memory / memories may be integrated into the corresponding processing chip and / or may be separate from the chip. Code (and / or data) for implementing embodiments of the present disclosure may comprise source code, object code, or executable code in a conventional programming language (interpreted or compiled), such as C or assembly code, code for configuring or controlling an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array), or code for a hardware description language. [Explanation of symbols]

[0317] 101 Packet Switching Network 102 Computer Equipment 103 Related parties 104 Blockchain nodes 105 Client Applications 106 Blockchain Network 150 Blockchain 151 Blocks 152 Transactions 153 Genesis Block 154 Ordered Sets 155 Block Pointer 201 Header 202 Input Field 203 Output Fields 300 User Interface 301 Transaction Engine 302 UI layer 351 UI elements 352 UI elements 353 UI elements 400 Verification Circuit 402 Function Circuit 404 Equivalence Check Module 500 Extension Circuit 502 Multiplication Gate 600 Proof Generation Process 700 Proof Verification Process

Claims

1. 1. A computer-implemented method for providing a proof that a statement is true while keeping a secret input to the statement secret, the method being executed on a computing device and comprising: generating a zero-knowledge proof using a public input, the private input, and a proof key associated with an extended verification circuit, comprising: the extended verification circuit comprises: (i) a verification circuit adapted to accept the public input and the secret input, to provide the secret input representing the statement to a function circuit to generate a function circuit output, and to determine whether the public input corresponds to the function circuit output; and (ii) a multiplication gate adapted to accept the secret input and a dummy value; the zero-knowledge proof comprises batched commitments to inputs of multiplication gates of the extended verification circuit; the batched commitments are generated using a first vector comprising n elements from a finite set of data elements; the secret input is the discrete logarithm of a public element of the finite set of data elements; Steps and transmitting the zero-knowledge proof to a verification computing device to enable the verification computing device to verify that the computing device has knowledge of the secret input; A method comprising:

2. 2. The computer-implemented method of claim 1, wherein the batched commitments are batched Pedersen commitments.

3. each of the n components of the first vector corresponds to a respective input of the multiplication gate of an arithmetic circuit; 3. The computer-implemented method of claim 1, wherein one of the n components of the first vector is at a position corresponding to an input wire of a dummy multiplication gate adapted to accept the secret input.

4. The computer-implemented method of claim 3 , wherein the finite set of data elements is an elliptic curve.

5. 5. The computer-implemented method of claim 4, wherein the public element of the finite set of data elements is a public key and the private input is a signing key.

6. 6. The computer-implemented method of claim 3, further comprising the step of proving that the secret input is the discrete logarithm of the public element.

7. proving that the secret input is the discrete logarithm of the public element, generating a further batched commitment and transmitting the further batched commitment to the verification computing device; receiving a random challenge from the verification computing device; generating a response to the random challenge and transmitting the response to the verifying computing device to prove that the secret input is the discrete logarithm of the public element; The computer-implemented method of claim 6, comprising:

8. 8. The computer-implemented method of claim 7, wherein the further batched commitments are batched Pedersen commitments.

9. generating the further batched commitments, generating a second vector having n components, the components of the second vector at predetermined positions corresponding to positions in the first vector being set to zero; generating the further batched commitments by committing to the second vector; 9. The computer-implemented method of claim 7 or 8, comprising:

10. 10. The computer-implemented method of claim 9, wherein the remaining components of the second vector are random values.

11. the finite set of data elements is an elliptic curve; generating the further batched commitment to the second vector using a commitment key vector comprising n elements from the finite set of data elements; one of the n components of the commitment key vector is a reference point of the elliptic curve at a predetermined position corresponding to a position in the first vector; 11. The computer-implemented method of claim 9 or 10, wherein the public element is obtained by multiplying the reference point with the secret input.

12. In response to receiving the random challenge, modifying the first vector by replacing the secret input at the location with zero to generate a modified first vector; the response comprises a response vector generated by combining the modified first vector with the second vector using the random challenge; sending the response to the verification computing device; 12. The computer-implemented method of claim 7, comprising:

13. combining the random elements used to generate the batched commitment with further random elements of the further batched commitment to generate a combined random element; 13. The computer-implemented method of claim 12, wherein the response comprises the combined random element.

14. 14. A computer-implemented method according to claim 1, comprising the step of transmitting the statement to the verifying computing device.

15. 1. A computer-implemented method for verifying that a statement is true without knowledge of a secret input to the statement, the method being executed on a computing device and comprising: receiving a zero-knowledge proof from a proof computing device; obtaining said statement; verifying that the zero-knowledge proof is valid using the zero-knowledge proof, a public input, and a verification key associated with an extended verification circuit; the extended verification circuit comprises: (i) a verification circuit adapted to accept the public input and the secret input, to provide the secret input representing the statement to a function circuit to generate a function circuit output, and to determine whether the public input corresponds to the function circuit output; and (ii) a multiplication gate adapted to accept the secret input and a dummy value; the zero-knowledge proof comprises batched commitments to inputs of multiplication gates of the extended verification circuit; the batched commitments are generated using a first vector comprising n elements from a finite set of data elements; the secret input is the discrete logarithm of a public element of the finite set of data elements; Steps and determining that the attesting computing device has knowledge of the secret input based on the verification; A method comprising:

16. 16. The computer-implemented method of claim 15, wherein the batched commitments are batched Pedersen commitments.

17. each of the n components of the first vector corresponds to a respective input of the multiplication gate of an arithmetic circuit; 17. The computer-implemented method of claim 15 or 16, wherein one of the n components of the first vector is in a position corresponding to an input wire of a dummy multiplication gate adapted to accept the secret input.

18. 20. The computer-implemented method of claim 17, wherein the finite set of data elements is an elliptic curve.

19. the public element of the finite set of data elements is a public key; 20. The computer-implemented method of claim 18, wherein the secret input is a signing key.

20. 20. The computer-implemented method of claim 17, further comprising verifying, without knowledge of the secret input, that the secret input is the discrete logarithm of the public element.

21. verifying that the secret input is the discrete logarithm of the public element, receiving a further batched commitment from the attesting computing device; in response to receiving the further batched commitment, generating a random challenge and transmitting the random challenge to the attesting computing device; receiving a response to the random challenge from the attestation computing device; processing the response to verify that the secret input is the discrete logarithm of the public element; 21. The computer-implemented method of claim 20, comprising:

22. 22. The computer-implemented method of claim 21, wherein the further batched commitment is a batched Pedersen commitment.

23. the further batched commitments are commitments to a second vector having n elements; 23. The computer-implemented method of claim 21 or 22, wherein components of the second vector at predetermined positions corresponding to positions in the first vector are set to zero.

24. 24. The computer-implemented method of claim 23, wherein the remaining components of the second vector are random values.

25. the response comprises a response vector that is a combination of a modified first vector and the second vector using the random challenge; the modified first vector corresponds to the first vector; 25. The computer-implemented method of claim 21, wherein the secret input at said location is replaced with a zero.

26. the response vector comprises a plurality of components; 26. The computer-implemented method of claim 25, wherein the processing step comprises verifying that a component of the plurality of components of the response vector at a predetermined position corresponding to the position in the first vector is not zero.

27. the finite set of data elements is an elliptic curve; The processing step includes: computing a combined commitment using the batched commitment, the random challenge, the further batched commitment, and the public element; using the response, the combined commitment, and a commitment key vector to verify that the private input is the discrete logarithm of the public element; Equipped with the commitment key vector comprises n elements from the finite set of data elements; one of the n components of the commitment key vector is a reference point of the elliptic curve at a predetermined position corresponding to a position in the first vector; 27. The computer-implemented method of claim 21, wherein the public element is obtained by multiplying the reference point with the secret input.

28. 28. A computer-implemented method according to any one of claims 15 to 27, comprising receiving the statement from the verification computing device.

29. 29. The computer-implemented method of claim 1, wherein an output of the multiplication gate is not coupled to the verification circuit.

30. 30. A computer-implemented method according to any one of claims 1 to 29, wherein the function circuit implements a hash function, preferably a SHA-256 hash function.

31. A computer program which, when read by a computing device, causes the computing device to perform the method of any one of claims 1 to 30.

32. A non-transitory computer readable storage medium comprising computer readable instructions that, when read by a computing device, cause the computing device to perform the method of any one of claims 1 to 30.

33. A computing device comprising a processor and a memory, the memory storing instructions that, when executed by the processor, cause the computing device to perform a method according to any one of claims 1 to 30.

Images