Computer-implemented system and method for enabled zero-knowledge proof

Abstract

To provide a method and a system for efficient zero-knowledge verification of compound statements that simultaneously require both arithmetic circuit satisfiability and dependent statements about the validity of a public key.SOLUTION: In a method, a prover sends, to a verifier, a set of data including a statement that is about an elliptic curve point and the output of a given function circuit whose input is equal to the corresponding elliptic curve point multiplier. The data includes individual wire commitments and batched commitments for the circuit, inputs and outputs of the statement. The prover sends an opening in response to a challenge from the verifier. Using the data received from the prover, the verifier determines that the circuit is filled, computes the elliptic curve point to verify the statement, and determines that it holds evidence for the statement. Upon receiving the data, the verifier determines through computation that the data fits the statement.SELECTED DRAWING: None

Description

Technical Field

[0001] This specification generally relates to computer-implemented methods and systems suitable for implementation in a computer processor, such as a node of a blockchain network, or a group of such processors. An improved method is provided for generating a proof that enables efficient zero-knowledge verification of statements. The method is suitable for incorporation into existing discrete logarithm-based zero-knowledge proof protocols for circuit satisfiability that do not require the use of bilinear pairing-friendly elliptic curves. The present invention is applicable, but not limited to, in particular, the method executed by a prover to create a proof, and the method executed by a verifier to verify a proof, and is suitable for collaborative work among two or more participants. To enable secure and trustless interaction among participants, one of the parties can prove knowledge of a key or statement without revealing that statement.

Background Art

[0002] In this document, the term 'blockchain' includes all forms of electronic, computer-based, distributed ledgers. These include consensus-based (consensus-based) blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. The most widely known use of blockchain technology is the Bitcoin ledger, but other blockchain implementations have also been proposed and developed.

[0003] Here, for the sake of convenience and explanation, Bitcoin may be referred to, but it should be noted that the present invention is not limited to the use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are also within the scope of the present invention. The term "user" herein refers to a human or a processor-based resource. A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system composed of a plurality of blocks of transactions.

[0004] Each transaction is a data structure that encodes the transfer of management of digital assets among participants in a blockchain system and includes at least one input and at least one output. By each block including the hash of the previous blocks to which that block is chained together, a permanent and immutable record of all transactions written to that blockchain before its inception is created. Transactions include small programs known as scripts embedded in their inputs and outputs, which specify how the outputs of the transaction can be accessed by whom. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0005] Furthermore, this document refers to the structure of known zero-knowledge proof protocols and systems that use arithmetic circuits. A blockchain provides a decentralized permissionless global mechanism that enables a solution to the problem of fair transactions between two mutually untrusted parties without the need for third-party arbitration or third-party escrow. Fair exchange of data or information, for financial rewards or in exchange for information such as digital goods, for example, is embodied in a transaction protocol known as ZKCP (Zero-Knowledge Contingent Payments) (Non-Patent Document 2). In ZKCP, the specified data is transferred from the seller to the buyer only if the payment is confirmed, and the payment from the buyer to the seller is completed only if this specified data is valid according to the conditions of the sale. Details of such protocols are known (Non-Patent Document 1), but it is basically based on a combination of a hash-time-locked contract (HTLC) and zero-knowledge proof, which simultaneously verifies that the encrypted information (‘digital goods’) is valid / accurate and that the ‘password’ to decrypt this information is the data that must be revealed on the blockchain to claim the payment.

[0006] The central component of the ZKCP protocol is a zero - knowledge proof for a series of dependent statements regarding the validity or accuracy of data / information, the validity of keys, and the corresponding hash values. Such complex composite statements require an efficient zero - knowledge proof system for general computations. At its core, this means that one party can run any program using a secret input and prove to other parties that the program was correctly executed, accepting the input as valid, without revealing any information about the secret input or the execution of the program. In known examples of ZKCP, the general - purpose zero - knowledge proof systems employed have been based on the succinct non - interactive arguments of knowledge (SNARK) framework, such as those implemented in the Pinocchio protocol (Non - Patent Document 3) and the C++ libsnark library (Non - Patent Document 4).

[0007] Zero - knowledge SNARK (zkSNARK) provides a way to prove the validity of any computation representable as an arithmetic circuit in zero knowledge. Two main characteristic properties of zkSNARKs are that they are non - interactive (the prover sends the proof to the verifier in one move) and succinct (the proof is small and easy to verify). However, they have significant limitations: - Proof generation is extremely computationally demanding. - The proof key is very large and proportional to the circuit size. - They rely on strong and untested cryptographic assumptions (i.e., knowledge of the exponentiation assumption and pairing - based assumptions). - For a given program (circuit), they require that a common reference string (CRS) be computed by a third party who must be trusted to delete the setup parameters. A person with knowledge of the setup parameters has the ability to create false proofs.

[0008] The construction of a zkSNARK that proves statements involving arbitrary encrypted elliptic curve key operations has not been attempted to date, but hypothetically, it would consist of an arithmetic circuit with hundreds of thousands or millions of gates, resulting in proof generation times of several minutes and proof keys of hundreds of megabytes in size.

[0009] Technical Background The basic system for interactive zero-knowledge proofs can use a Σ (sigma) protocol that involves several communication steps between the prover and the verifier. Typically, the Σ protocol requires three moves, i.e., the prover sends an initial commitment (a) to the verifier, then the verifier responds with a random challenge (x), and finally the prover responds with a final response or 'opening' (z). The verifier then accepts or rejects the statement based on the transcript (a, x, z).

[0010] The Σ protocol can be used to prove knowledge of a witness (w) known only to the prover or a statement about the witness (w). This protocol is zero-knowledge (Non-Patent Document 5) if the commitment does not reveal information or secrets about the witness to the verifier, except for the fact that the statement about the witness is true.

[0011] The core of many interactive zero-knowledge protocols is a commitment scheme that is used with respect to the satisfiability of arithmetic circuits. Commitments allow the prover to pre-commit to a secret value and then later verifiably reveal (open) the secret value. Commitment schemes have two main properties. First, they are hiding, meaning the commitment keeps the value secret. Second, they are binding, meaning the commitment can only be opened to the original committed value. The Pedersen commitment (Non-Patent Document 5) scheme involves two elliptic curve generator points, G and F, in a group G of prime order p known to all parties. The committer commits to a prime integer Zp Generate a secure random number r in the field, and commit to the secret value s: Com(s,r)=s×G+r×F Calculate this (by elliptic curve addition / multiplication), where × represents elliptic curve point multiplication.

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

[0013] The Pedersen commitment is additively homomorphic, i.e., adding two commitments (on the elliptic curve) results in a commitment to the sum of the committed values, i.e.: (s1×G+r1×F)+(s2×G+r2×F)=(s1+s2)×G+(r1+r2)×F That is.

[0014] A proof of arithmetic circuit satisfiability can be achieved in 'zero knowledge'. (Arithmetic circuits over the field Z p are virtual configurations of arithmetic gates connected by wires (forming a directed acyclic graph), which can perform any complex calculation, where the calculation is limited to integer operations and must not have data-dependent loops or mutable state.

[0015] Each gate has two input wires and one output wire, and performs a multiplication (×) or addition (+) operation on the inputs. Figure 1(a) shows a schematic of a multiplication gate with left (w L ) and right (w R ) wire inputs and one wire output (w O ), and Figure 1(b) shows a schematic of a simple arithmetic circuit with three gates, three input wires (w1, w2, w3), one output wire (w6), and two internal wires (w4, w5).

[0016] In fact, a complete circuit has free input wires and free output wires that define the external (circuit) input and output values. A legal assignment is one that defines the values of the wires such that the circuit is satisfied, i.e., each wire is assigned a value and the output of each gate exactly corresponds to the product or sum of the inputs (i.e., the gate is consistent).

[0017] For a given arithmetic circuit, the prover first commits to each wire value under a legal assignment (using Pedersen commitments), and then, using the wire values as evidence, can prove to the verifier that it knows a legal assignment for the circuit without revealing the wire values, by running a special Σ - protocol with a verifier for each gate in the circuit (which can be run in parallel). These Σ - protocols exploit the homomorphic properties of Pedersen commitments, as will be described later.

[0018] (To generate a proof that the circuit is satisfied), first the prover makes commitments for each wire w i (where the number of wires is n and i = 1,…,n): W i =Com(w i ,r i ) and sends these to the verifier.

[0019] For each 'addition' gate in the circuit (one shown in Figure 1(b)), a Σ zero protocol is run, which involves proving (in zero - knowledge) that w L +w R -w O =0 (i.e., the input wires w L and w R are equal to the output wire w O and the addition gate is satisfied). This involves the following steps, namely: 1. The prover makes a commitment to zero: B = Com(0,rB ) Generate and send it to the verifier. 2. The verifier responds with a random challenge value: x ← Z p in response. 3. Then, the prover calculates the opening value: z = x(r L + r R - r O ) + r B and sends it to the verifier. 4. The verifier proves that w L + w R - w O = 0 by proving Com(0, z) = x × (W L + W R - W O ). B represents a curve point similar to the public key; B = r × F + 0 × G r B represents the corresponding pair of private keys.

[0020] For each'multiplication' gate (shown in Fig. 1(a)), the Σ prod protocol is executed, which involves proving (in zero knowledge) that w L · w R = w O for each multiplication gate (i.e., the multiplication gate is satisfied). 1. The prover generates five random binding values: t1, t2, t3, t4, t5 ← Z p and generates them. 2. The prover calculates C1 = Com(t1, t3), C2 = Com(t2, t5), C3 = t1 × W R + t4 × F and sends these to the verifier. 3. The verifier responds with a random challenge value: x ← Z p in response. 4. The prover calculates the opening values: e1 = w L x + t1 e2 = w R x + t2 z1 = r L x + t3 z2 = r R x + t5 z3 = (r O - w L r R )x + t4 Calculate these and send them to the verifier. 5. Then, for the verifier to prove that w L · w R = w O , as a proof, the following equations: Com(e1, z1) = x × W L + C1 Com(e2, z2) = x × W R + C2 e1 × W R + z3 × F = x × W O + C3 are inspected.

[0021] Σ zero protocol and the Σ prod protocol can operate in parallel for the verification of each gate in the circuit and can use the same verification challenge value (x) for all gates.

[0022] As an example, considering the circuit in Figure 1(b), for the prover to prove to the verifier in zero - knowledge that it knows a legal assignment (i.e., wire values that satisfy the circuit), the prover first sends to the verifier the wire commitments (W1,…,W6) for each gate and the Σ - protocol commitments (i.e., one additional commitment for each addition gate and five additional commitments for each multiplication gate).

[0023] Then, the verifier responds with a random challenge x ← Z p , and the prover calculates the opening values for each gate (one for each addition and five for each multiplication) and sends them back to the verifier. Then, the verifier executes the Σ - protocol check to w1·w2 = w4 w4·w5 = w6 w2 + w3 = w5 hold, and thus, correspondingly, the commitments W1,…,W6 satisfy the wire values w1,…,w6, is verified.

[0024] If the prover wishes to show that, in addition to satisfying the circuit, a particular wire has a particular value, they can fully open the commitment to the relevant wire. In this example, the verifier can further send the values w6 and r6 to the verifier in order to show that w6 is the actual output from a particular valid assignment (and the verifier can verify that W6 = Com(w6,r6)).

[0025] The example of Figure 1(b) is a simple circuit. In practice, useful circuits are composed of many more gates. Of particular interest are arithmetic circuits for the SHA-256 hash function, which allow a prover to show that they know the preimage (input) to the SHA-256 function that hashes to a particular (output) value without revealing the preimage. One of the most efficient implementations of a circuit for the SHA-256 algorithm consists of 27,904 arithmetic gates (Zcash2016). Then, proving knowledge of the SHA-256 preimage would require sending about 5MB of data in both the first commitment and opening rounds of the protocol above, and would require about 200,000 elliptic curve operations for both the prover and the verifier (each taking several seconds of processor time).

[0026] There are several methods developed to significantly improve the performance of the parallel Σ protocol approach for proving arithmetic circuit satisfiability. Known approaches (Non-Patent Document 5, Non-Patent Document 6) involve batching commitments to circuit wire values in order to substantially reduce the size of the data that must be sent from the prover to the verifier (i.e., reduce the communication complexity). These methods enable proof systems where the communication complexity is reduced from O(n) to O(√n) or O(log(n)).

[0027] Also, as a comparison for proving the satisfiability of the same SHA circuit, the protocol (Non-Patent Document 5) has a proof key size of only 5 KB and a key generation time of 180 ms. The proof size is 24 KB, taking about 4 seconds to generate, and the proof also takes about 4 seconds to verify.

[0028] Regarding these methods, we will not fully explain them here, except to describe the main vector batching protocol adopted in the following steps. This follows the same nature as the ordinary Pedersen commitment, but a commitment to n elements (m = m1, …, m n ) only requires sending a single group element: 1. The prover and the verifier agree on a group element F ← G. 2. The prover generates n random numbers x1, …, x n ← Z p . 3. The prover calculates points K i = x i × F (for i = 1, …, n). These values form the proof key PrK sent to the verifier. 4. The prover generates a random number: r ← Z p . 5. The prover calculates the commitment:

Number

Prior Art Documents

Non-Patent Documents

[0029]

Non-Patent Document 1

Non-Patent Document 2

Non-Patent Document 3

Non-Patent Document 4

Non-Patent Document 5

Non-Patent Document 6

Non-Patent Document 7

Non-Patent Document 8

Non-Patent Document 9

Non-Patent Document 10

Summary of the Invention

[0030] Overall, the present invention is in a computer-implemented method for enabling zero-knowledge proof or verification of statements. A prover can use the method herein to prove to a verifier that a statement is true while keeping the evidence for the statement secret. These statements are composite statements that simultaneously require both subordinate statements (key statement proofs) regarding arithmetic circuit satisfiability and public key validity.

[0031] The method herein can be used in known protocols regarding circuit satisfiability, such as existing discrete logarithm-based zero-knowledge proof protocols. The method is particularly suitable for protocols that do not require the use of bilinear pairing-friendly elliptic curves.

[0032] The method includes a prover sending a set of data including a statement regarding a given function circuit output and an elliptic curve point to a verifier, where the function circuit input is equal to the corresponding elliptic curve point multiplication(s). The data includes individual wire commitments and / or batched commitments, inputs, and outputs for the circuit of the statement. The prover can include in the data the specification of the elliptic curve or each elliptic curve used in the statement, or can have shared it in advance. Then, the prover sends an opening in response to a challenge from the verifier. Alternatively, the prover can further include a proof key.

[0033] Using the data received from the prover, the verifier verifies the statement by determining that the circuit is satisfied, and can thus determine that the prover holds evidence for the statement. Elliptic curve points can also be calculated. Upon receiving the data, the verifier determines through calculation that the data conforms to the statement. The present invention is particularly suitable for zero-knowledge proofs of the equivalence of hash pre-images and elliptic curve private keys.

[0034] Accordingly, the present invention provides a method and system as defined in the appended claims.

[0035] Thus, it is desirable to provide a computer-implemented method for enabling a zero-knowledge proof or verification of a statement (S), in which a prover proves to a verifier that the statement is true while keeping the evidence (W) for the statement secret. This proof can be an explicit proof.

[0036] A computer-implemented method can be provided for enabling a zero-knowledge proof or verification of a statement (S), in which a prover proves to a verifier that the statement is true while keeping the evidence (w) for the statement secret, the method comprising: the prover sending to the verifier: a statement (S) represented by an arithmetic circuit having m gates and n wires configured to implement a function circuit to determine whether a function circuit input (s) to a wire of the function circuit is equal to an elliptic curve point multiplier (s) corresponding to a given function circuit output (h) and an elliptic curve point (P); individual wire commitments and / or batched commitments for the wires of the circuit; the function circuit output (h); a proof key (PrK); and including This enables the verifier to determine that the circuit is satisfied, calculate the elliptic curve point (P), and verify the statement, and thus determine that the prover holds a proof (w) for the statement.

[0037] The method includes the prover sending a set of data (a set of data) to the verifier. The set of data includes a statement having an arithmetic circuit implementing a function circuit and having m gates and n wires configured to determine whether, for a given function circuit output (h) and elliptic curve point (P), the function circuit inputs (s) to or on the wires within the function circuit are equal to the corresponding elliptic curve point multipliers (s). The function circuit can be a circuit implementing the function of a hash function. The preimage for the hash function circuit or for a wire within the function circuit can be equal to the corresponding elliptic curve point multiplier.

[0038] The data also includes individual wire commitments and / or batched commitments. The commitment or each commitment can be the wire inputs and outputs (which are encrypted) regarding the gates of the circuit. The data also includes an input. The input serves as a key opening for the wires of the arithmetic circuit [elliptic curve point (P)]. Either the prover or the verifier can name the wires. The input or key opening can be for the first wire within the circuit. The data also includes the function circuit output. The specification of the elliptic curve or each elliptic curve used within the statement can be included in the data.

[0039] After sending the data, the prover receives a challenge value from the verifier and responds with an opening. The opening can be a value statement according to the Σ (sigma) protocol. The opening value can be for each gate of the circuit that enables the verifier to determine that the statement is true and calculate the elliptic curve point.

[0040] Instead of waiting for a challenge, the prover may further send a proof key to the verifier. The proof key may be generated from data that is part of the proof. The proof key may be a hash of one or more of the random numbers used in the proof.

[0041] The data sent to the verifier enables the verifier to determine that the circuit is satisfied, calculate elliptic curve points, and verify the statement, and thus determine that the prover holds a proof for the statement.

[0042] The set of data sent to the verifier and / or the opening to the challenge sent to the verifier can function like a key created independently of the verifier. The challenge from the verifier is similar to determining the identity and key integrity of the prover.

[0043] The input or key opening can be for the first wire in the arithmetic circuit. However, since it is more difficult to prove knowledge of an intermediate wire than knowledge of the first wire, it is preferable to select a random wire. Further, selecting a random wire other than the first wire is more robust and prevents the discovery of a proof or evidence by a malicious third party.

[0044] It is equally desirable to provide a complementary computer-implemented method for enabling a zero-knowledge proof or verification of a statement, by which the verifier can verify that the statement is true without knowing the proof (w) for the statement by analyzing the data received from the prover. To be clear, the method of the present invention extends to the reverse action taken by the verifier in a plug-and-play manner. The present invention extends to full collaboration between the prover and the verifier.

[0045] In addition to, or instead of, waiting for a challenge value, the verifier may send to the prover a random value that enables the verifier to determine that the statement is true and calculate an elliptic curve point. Upon receiving data from the prover, the verifier may instead receive a random value that enables the verifier to determine that the statement is true and calculate an elliptic curve point. The random value may be a function of at least one commitment. This function may be a hash function.

[0046] The random value or challenge may be replaced to improve the convenience and efficiency of the process. There is also a risk associated with the verifier generating a non-random challenge in an attempt to extract information about the proof. Further, replacing the challenge value with a random value provided by the prover converts this method from an interactive to a non-interactive one. The prover can generate a proof that can be verified independently and publicly offline. The random value may be the output from a hash function. Using the output from the hash of one or more commitments instead of the random value (x) utilizes the Fiat-Shamir principle.

[0047] The random value can be calculated by hashing the concatenation of all commitments generated by the prover and sent to the verifier.

[0048] The commitment can be W i =Com(w i ,r i ), where Com is a commitment to a function circuit, w i is a wire value, r i is a random number, i.e., it is different for each wire commitment, i is the wire type, Com(w,r)=w×G+r×F, and F and G are elliptic curve points.

[0049] The input to wire l in the arithmetic circuit can be ko = r l ×F, and ko is the key opening input, r l is a random number, and F is a point on the elliptic curve.

[0050] The wire can be the first wire in the circuit.

[0051] The verifier can confirm that the circuit is satisfied, with elliptic curve point subtraction: pk l = Com(w l ,r l ) - ko l to calculate the public key for wire l.

[0052] The prover can send a batch of wire commitments and generate random numbers for calculating elliptic curve points for each wire to form a proof key.

[0053] The commitments batched for the proof are

Number

[0054] The input to wire n in the arithmetic circuit is

Number

[0055] The input can be for the first wire.

[0056] The verifier can calculate the public key opening of the key statement wire via the elliptic curve operation:

Number

[0057] The prover can further send at least one wire a fully open commitment. The method can use Pedersen commitment. The statement can use only one arithmetic circuit for the function circuit. The function circuit can implement a hash function which is preferably the SHA-256 hash function.

[0058] The method can be used by the prover to enable zero-knowledge transactions with respect to data such as cryptographic keys (which can be zero-knowledge transactions). The prover cooperates with the verifier to confirm the provided data (which can be a vanity address) and the received data (which can be a payment in the form of UTXO), establishes a communication channel with the verifier (which can be open), and the prover receives from the verifier the elliptic curve public key pk B generated by the verifier from a secure random secret key skB, and pk V = sk V × G, where G is an elliptic curve point, The prover protects the provided data with a lock value i such that data = pk V + i × G.

[0059] The prover may perform a search for the required pattern in the Base58-encoded address obtained by varying i. The prover P sends to the verifier those public keys where pk

[0060] = i × G, and the output f(i) from the function circuit where the function circuit input (e.g., preimage) is the lock value i. P The prover can send to the verifier a statement proof that the input to the function circuit is the secret key corresponding to pk V such that, by the verifier verifying the proof and confirming that the address corresponding to pk = pk P + pk

[0061] matches the agreed pattern, it may be possible to determine that knowing the lock value i enables the derivation of the complete secret key regarding the data, and that the lock value i is the function circuit input to the function circuit.

[0062] The prover may receive a transaction Tx1 that includes an output containing the received data, which can be accessed by the signature from the prover and the function circuit input. The transaction may be a hash time lock function. The received data may provide access to a UTXO. sk = sk B + i, and pk = sk × G.

[0063] Data provided by the prover may include vanity addresses. Data received from the verifier may include cryptocurrency payments (e.g., UTXOs).

[0064] Transactions can be made completely atomic and trustless, where the buyer only receives payment if they provide a valid value i, and the value i is publicly revealed on the blockchain. By splitting the private key, the value revealed on the blockchain is useless to anyone else and does not compromise the security of the complete private key.

[0065] A certain computer-implemented method may involve the prover performing a trustless and fair data exchange with the verifier (without using a third-party centralized exchange). This can be described as a cross-chain atomic swap or atomic trade. This is because in this context, it refers to the fair exchangeability where either both parties complete the transaction or neither of them do. This swap can be executed between blockchains that support a script function enabling hashed time-locked contracts.

[0066] The prover has access to first data, such as a 1 Bitcoin UTXO on the first blockchain, and the verifier has access to second data, such as 100 LTC on the second blockchain, and the prover and verifier agree to exchange the data. The method includes the prover generating a key pair for the second blockchain, sending the public key to the verifier, and retaining the private key, and the prover receiving the verifier's public key for the first blockchain, and the verifier generating a key pair for the first blockchain and retaining the private key (s B ), and the prover sending a statement, one or more commitments, an input or key opening and function circuit output (h), and an elliptic curve specification.

[0067] The prover can create a first blockchain transaction Tx that sends the first data to a common public key address, and broadcast the transaction on a first blockchain network, where the address is determined by the sum of the input and the verifier's public key. This data can be accessed by the prover after the swap has not been executed within 24 hours. A After the swap has not been executed within 24 hours, this data can be accessed by the prover.

[0068] The prover can verify a second blockchain transaction Tx, which is created by the verifier and broadcast on a second blockchain network after confirming that the first blockchain transaction Tx is included in the first blockchain. The transaction sends the second data in the form of 100 LTC to the prover's public key address, which can be accessed by the prover using a valid signature for the prover's public key address and a value that is the function circuit input determining the function circuit output. This data can be accessed by the verifier after the swap has not been executed within 24 hours. B The transaction sends the second data in the form of 100 LTC to the prover's public key address, which can be accessed by the prover using a valid signature for the prover's public key address and a value that is the function circuit input determining the function circuit output. This data can be accessed by the verifier after the swap has not been executed within 24 hours. A After the swap has not been executed within 24 hours, this data can be accessed by the verifier.

[0069] The prover confirms that the second blockchain transaction Tx is included on the second blockchain and accesses the second data by providing the signature and the above value that is the function circuit input of the function circuit output, thus enabling the verifier to observe the above value that is the function circuit input determining the function circuit output and access the first data by providing a signature using the secret key of (P of s + s from the homomorphism of elliptic curve point multiplication). B The prover confirms that the second blockchain transaction Tx is included on the second blockchain and accesses the second data by providing the signature and the above value that is the function circuit input of the function circuit output, thus enabling the verifier to observe the above value that is the function circuit input determining the function circuit output and access the first data by providing a signature using the secret key of (P of s + s from the homomorphism of elliptic curve point multiplication). B P of s + s C After the swap has not been executed within 24 hours, this data can be accessed by the verifier.

[0070] The data to be exchanged can be a cryptocurrency. The first data preferably corresponds to the amount of a first cryptocurrency, which is Bitcoin, and the second data preferably corresponds to the amount of a second cryptocurrency, which is Litecoin.

[0071] As described above, all actions by the prover require opposite actions by the verifier to verify the proof. The present invention extends to methods or actions performed by the verifier. Accordingly, there is provided a computer-implemented method for enabling zero-knowledge proof or verification of a statement, wherein the prover proves to the verifier that a statement is true while keeping secret the evidence for the statement, preferably explicitly, the method comprising: the verifier receiving from the prover: a statement having an arithmetic circuit having m gates and n wires configured to implement a function circuit, preferably a hash function, and to determine whether a function circuit input or preimage to the function circuit is equal to an elliptic curve point multiplication for an output of a given function circuit and preferably a specified function circuit and an elliptic curve point. The verifier also receives individual wire commitments and / or batched commitments that are encrypted wire inputs and outputs for the wires of the circuit, an input or key opening for a wire (preferably a wire other than the first wire) within the arithmetic circuit, and a function circuit output (h). The verifier may also receive the specification of the elliptic curve or each elliptic curve used in the statement. The verifier can send a challenge value to the prover and then receive an opening. The opening can be in accordance with a Σ protocol and can include values for each gate of the circuit that enable the verifier to determine that the statement is true and calculate an elliptic curve point. Additionally, alternatively, the verifier may receive a proof key from the prover.

[0072] The verifier then determines that the circuit is satisfied, calculates an elliptic curve point (P), and thus determines that the prover holds evidence (w) for the statement.

[0073] This can be achieved by the prover proving, in zero knowledge, what the prover knows about the values for each gate of the statement circuit, using the Sigma protocol if the proof is interactive, or using the proof key if the Fiat-Shamir heuristic is used. The verifier receives the Σ_zero and Σ_prod commitments for each gate from the prover, responds with a challenge value, receives the opening values from the prover, and can then verify against the commitments. The verifier can confirm that the circuit is satisfied by calculating the public key for wire l via elliptic curve point subtraction. The verifier can confirm that each public key for each wire matches the (one or more) keys specified in the statement. The verifier can complete the verification by determining that the fully opened wires match the specifiable values within the statement.

[0074] It is also desirable to provide a computer-readable storage medium having computer-executable instructions that, when executed, configure a processor to execute a method that is executed by a prover, by a verifier, or by a prover and verifier cooperating with each other.

[0075] It is also desirable to provide an electronics device having an interface device, one or more processors coupled to the interface device, and a memory coupled to the one or more processors, the memory storing computer-executable instructions that, when executed, configure the one or more processors to execute the method claimed herein. It is also desirable to provide a node of a blockchain network configured to execute the claimed method. It is also desirable to provide a blockchain network having such nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0076] Aspects of the present invention will become apparent with reference to the embodiments described herein. Hereinafter, embodiments of the present invention will be described by way of example only, with reference to the accompanying drawings, which include the following.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

DETAILED DESCRIPTION OF THE INVENTION

[0077] Overview The present invention enables efficient zero - knowledge verification of composite statements that require both arithmetic circuit satisfiability and a validity proof of a public key (key statement proof) simultaneously. A public - key elliptic - curve specification is employed within an isomorphic commitment function to prove circuit satisfiability. This enables proof of a public - key statement corresponding to a secret key that is used as a circuit input and / or output in an efficient manner.

[0078] The proof size and computational cost for generating a proof regarding a statement that includes both circuit satisfiability and an elliptic - curve key pair can be significantly reduced. The method herein can be easily incorporated into existing discrete - logarithm - based zero - knowledge proof protocols for circuit satisfiability that do not require the use of bilinear - pairing - friendly elliptic curves. The method is fully compliant with the Bitcoin secp256k1 standard.

[0079] For example, two applications related to fair - exchange transactions between two parties on a blockchain such as the Bitcoin blockchain are described. The first includes zero - knowledge - accompanied payments related to the trustless sale of outsourced vanity addresses, which requires a zero - knowledge proof that the SHA256 hash pre - image is equal to an elliptic - curve (e.g., Bitcoin) private key. The second includes improving the security of cross - chain atomic swaps, which requires proof that the SHA256 hash pre - image is equal to the product of a nonce and an unknown private key (with the provided public key).

[0080] General Solution This invention relates to a method that enables proof of a specific class of composite statements that includes a relationship with an elliptic - curve public / secret - key pair (based on elliptic - curve point multiplication).

[0081] It is considered unrealistic to use zkSNARKs to prove statements involving arbitrary cryptographic elliptic curve operations. Therefore, the method uses information about elliptic curve public keys directly extracted from "homomorphic hiding" (or commitment schemes) used in the construction of proofs regarding general circuit satisfiability. The specific type of elliptic curve involved in the statements of the method is the same as that used in circuit commitment schemes.

[0082] However, the SNARK method requires pairing operations and thus requires special bilinear pairing-friendly elliptic curves. This makes it impossible to use zk-SNARKs since some of the elliptic curves used on some blockchains are not compatible with bilinear pairing-friendly elliptic curves.

[0083] As an example, statements related to Bitcoin public keys use the Bitcoin secp256k1 curve, which is not compatible.

[0084] Therefore, the method of the present invention conforms to other protocols for proving arithmetic circuit satisfiability with fewer cryptographic assumptions without relying on pairings. Overall, the method of the present invention is more efficient than zkSNARKS because it requires less computation and has a smaller proof size for trustless exchange applications.

[0085] As an example, the schematic diagram of FIG. 2, which represents a composite circuit related to "Statement 1" described later, includes sub-circuits for both a hash function and an elliptic curve multiplication. In FIG. 2, the schematic diagram has three inputs: the private key's', the corresponding public key 'P' that forms a pair with it, and the value 'h' (which is the hash of the private key's'). This schematic diagram includes two arithmetic circuits. The first performs a hash on the private key, and the second performs an elliptic curve multiplication (EC mult) on the private key. The outputs (Out) of these circuits are compared with the inputs.

[0086] Note that these internal gates are for illustrative purposes only. This circuit checks that the output of the hash is equal to the elliptic curve (EC) public key. Only the input 'h', 'P', and the output are fully revealed to the verifier. All its values are encrypted.

[0087] Statement 1 "Given the output h of the hash function (H) and the elliptic curve point P (public key), the pre-image of the hash s (i.e., h = H(s)) is equal to the elliptic curve point multiplication (private key, i.e., P = s × G, where G is the elliptic curve generator point)".

[0088] The method enables the prover to prove this particular statement in zero knowledge. Examples of applications that benefit from such a method are trustless data exchange (e.g., the sale of outsourced Bitcoin vanity addresses), and anonymous secure cross-chain atomic swaps, which will be described later.

[0089] Verification that Statement 1 is true can be determined, for example, using the following pseudo-code function that takes the inputs 'h', 'P','s' and outputs '1' if the statement is true and '0' otherwise: int verify(h,P,s) { if(h == H(s) && P == s x G) { return 1 } else { return 0 } }

[0090] Verifying 'Statement 1' in zero knowledge, i.e., the prover verifying the value of's' from the verifier while keeping it secret, using a zkSNARK system, requires arithmetic circuits for both the hash function and the elliptic curve point multiplication, as shown in Figure 2.

[0091] Arithmetic circuits for the SHA-256 hash function are widely used and optimized, typically containing fewer than 30,000 multiplication gates. However, in the literature, no examples of arithmetic circuits for implementing elliptic curve point multiplication are known. Even if such circuits were known, they would not be practical due to their size and complexity and would contain more gates.

[0092] The method functions with a complete arithmetic circuit for a single hash function as shown in FIG. 2, which has a schematic diagram of an arithmetic circuit for a key statement proof and a composite statement 1 using only one arithmetic circuit for the hash function. This circuit checks that the output of the hash is correct and that the public key is equal to the encrypted input (key statement proof) of the EC. The values highlighted in blue, namely the inputs 'h', 'P' and the output '1' are revealed to the verifier, and all other values are encrypted.

[0093] Using the circuit of FIG. 3, the prover can explicitly prove that the hash of the secret key's' becomes 'h' via circuit satisfiability, and that the corresponding public key 'P' of the key pair is equal to's×G' with the elliptic curve generation point being G. The secret key's' is the preimage of the hash or the input to the function and is not revealed to the verifier when proving the statement.

[0094] Needless to say, verifying that's×G' is equal to 'P' can be extracted from the circuit proof with an additional computational cost that can be ignored by using the elliptic curve required in the commitment scheme as part of the proof protocol. Such an operation is called a 'key-statement proof' and uses a commitment opening procedure called 'key-opening'.

[0095] Technical effects Known zk-SNARK (Zero-knowledge Succinct Non-interactive Arguments of Knowledge) is an implementation of a general-purpose proof system for arithmetic circuit satisfiability. In the SNARK framework, the statement encoded as an arithmetic circuit is transformed into a structure called a Quadratic Arithmetic Program (QAP) consisting of a set of polynomials. And by proving the validity of this set of equations at a single point, the statement can be proven. The main advantages of the SNARK method are that the verifier only needs to perform a small number of elliptic curve (pairing) operations (which take a few milliseconds), and the proof is very small (288 bytes) and does not depend on the circuit size.

[0096] The very small proof and verification time achieved by the SNARK method come at the expense of a trusted setup, non-standard cryptographic assumptions, and a much heavier computational load imposed on the prover. The SNARK method also requires the use of elliptic curve bilinear pairings. However, the use of computationally realizable bilinear pairings requires the use of special 'pairing-friendly' elliptic curves. This excludes the use of many standard cryptographic elliptic curve parameter sets, including Bitcoin's secp256k1. Then, statements involving general elliptic curve point multiplications must use explicit circuits (which can be very large).

[0097] As a comparison with the Σ-protocol approach for proving SHA circuit satisfiability described in the previous section, when using the SNARK (Pinocchio) framework, the proof key takes about 10 seconds to generate and is about 7MB in size, and the proof also takes about 10 seconds to generate. However, the proof size is 288B, and it only takes about 5ms to verify (Non-Patent Document 8).

[0098] Furthermore, incorporating explicit elliptic curve multiplication (key statement) into the circuit will multiply both the proof key size and the proof generation time by at least an order of magnitude.

[0099] The present invention enables zero - knowledge proofs of statements that include elliptic curve public - key / secret - key relationships, concurrent with general arithmetic circuit satisfiability. This is achieved at a negligible computational cost beyond proving arithmetic circuit satisfiability, obviating the need to create explicit arithmetic circuits for elliptic curve point multiplication operations, which would significantly increase the computational cost of the proof.

[0100] Implementation Hereinafter, the implementation of the present invention will be described for both batch - type and non - batch - type commitment - based zero - knowledge proof systems.

[0101] In these examples, a zero - knowledge proof protocol involves two parties: a prover (P) and a verifier (V). The purpose of this protocol is for the prover to convince the verifier that a given statement (S) is true while keeping the information about the evidence for that statement secret. The statement consists of an arithmetic circuit (C) having m gates and n wires, and a dependent assertion about an elliptic curve public key: pk l where the subscript l is the wire index of the key statement. Further, the statement may also include assertions about fully open (public) wire values (i.e., the public inputs / outputs of the circuit).

[0102] The (one or more) elliptic curve public keys specified in the statement correspond to a target elliptic curve specification, which is defined by the entire set of elliptic curve parameters: T=(p,a,b,G,n,h).

[0103] In the case of Bitcoin Script, these parameters are defined by the specifications of secp256k1 (Non-Patent Document 9). This usage includes the base generation point G. In addition to specifying the base point, the statement must also specify a second point F (where F = f × G and f is an element of Z p ). Allowing the prover to freely choose f could enable the prover to generate a false proof, so the value of f must be provably random (e.g., the Bitcoin genesis block hash), or a "nothing up my sleeve" number such as the first 256 bits of the binary representation of π, for example.

[0104] Batch and non-batch commitments will be described in relation to FIG. 4, a representative arithmetic circuit having four gates and five wires. The input wire (w1) has the public key that is revealed or opened from the wire commitment W1 having the 'key opening' value ko1.

[0105] Implementation - Individual Wire Commitments Using FIG. 4 as an example, 'key opening' is an individual commitment for each wire in the circuit, created by the prover and sent to the verifier. These key openings follow a known Σ protocol for arithmetic circuit satisfiability. FIG. 5 shows the data exchanged between the prover and the verifier.

[0106] Satisfiability is achieved by including several steps as follows: 1. For each wire i (i = 1,..., n) in the circuit, a commitment is made using a Pedersen commitment: W i = Com(w i , r i ) where Com(w, r) = w × G + r × F 2. For circuit wire l that requires illumination of its corresponding public key (key statement proof), the prover also provides a key opening: ko l =r l ×F and also transmits it. 3. Optionally, if circuit wire j requires being publicly revealed (fully disclosed wire), the prover provides a complete opening tuple: (w j ,r j ) and transmits it. 4. Then, using the Σ protocol, it is proven in zero knowledge that each gate of the circuit is satisfied, which involves the prover calculating and transmitting Σ zero and Σ prod commitments (i.e., B, or C1, C2, C3 respectively), the verifier responding with a challenge value (x), then the prover transmitting opening values (z and e values), and the verifier checking against the commitments. 5. When the verifier confirms that the circuit is satisfied, the verifier then calculates the public key for wire l via elliptic curve point subtraction: pk l =Com(w l ,r l ) - ko l 6. And the verifier completes the verification by checking that each pk l matches the (one or more) keys specified in the statement (and that the fully open wire matches the specified value).

[0107] Detailed implementation - individual wire commitments Continuing to refer to Figure 4, an explicit example is provided that details the individual commitments and verifications for this example. This describes verifying the satisfiability of a simple arithmetic circuit in both a key statement proof for one of the wires and a complete disclosure for another wire.

[0108] ​ The circuit C shown in FIG. 4 has five wires w i (i = 1, …, 5) and four gates g j (j = 1, …, 4). Gates 1 and 3 are addition gates, and gates 2 and 4 are multiplication gates.

[0109] The prover and the verifier agree on a statement that includes the circuit, the value of wire 5, and the public key of wire 1, along with the elliptic curve and the commitment specification. The statement (S) that the prover wishes to prove to the verifier that it is true is: “I know a satisfying assignment to circuit C (i.e., a wire value {w i} i=1 5 that satisfies all gates), provided that wire 1 has the public key P (i.e., P = w1 × G) and wire 5 has the value h (i.e., w n = h).” That is.

[0110] The values of wires 1 through 4 are not revealed. And as shown in FIG. 6 and as described below, the prover and the verifier interact: 1. The prover generates five random blinding values (r1, …, r5), then calculates five wire commitments (W1, …, W5) and sends them to the verifier. 2. The prover calculates a key opening for wire 1: ko1 = r1 × F and sends it to the verifier. 3. The prover sends the verifier the complete opening information (w5, r5) regarding wire 5. 4. For the addition gates (g1 and g3), the prover generates commitments to zero: B1 = Com(0, r B1 and r B3 ) and B3 = Com(0, r B1 ) (using random nonces r B3 ) and sends them to the verifier. 5. For the multiplication gates (g2 and g4), the prover generates commitments as follows: For gate 2: C 12 =Com(t 12 ,t 32 ) C2=Com(t 22 ,t 52 ) and C3=t 12 ×W1+t 42 ×F For gate 4: C 14 =Com(t 14 ,t 34 ) C2=Com(t 24 ,t 54 ) and C3=t 14 ×W3+t 44 ×F Generate commitments as follows, where t xx value is a random blinding factor. The prover sends these commitments to the verifier. 6. Next, the verifier generates a random challenge value x and sends it to the prover. Alternatively, the verifier may generate the value x by hashing the concatenation of all commitments using the Fiat-Shamir heuristic. 7. For the addition gates (g1 and g3), the prover calculates the following openings: z1=x(r1+r1-r2)+r B1 z3=x(r2+r1-r4)+r B3 and sends them to the verifier. 8. For the multiplication gates (g2 and g4), the prover calculates the following openings: e 12 =w1x+t 12 e 22 =w2x+t 22 z 12 =r1x+t 32 z 22 =r2x+t 52 z 32 =(r3 - w1r2)x + t 42 e 14 =w3x + t 14 e 24 =w4x + t 24 z 14 =r3x + t 34 z 24 =r4x + t 54 z 34 =(r5 - w3r4)x + t 44 Calculate them and send them to the verifier. 9. Finally, the verifier checks the equivalence. If these pass, the proof is verified.

[0111] The verification performed by the verifier is summarized in Figure 7, and the checks within the inner box verify that the circuit is satisfied and that the first wire has the required public key and the fifth wire has the required value.

[0112] The challenges 'x' in Figures 5 and 6 provide an interactive proof, with communication going back and forth between the prover and the verifier.

[0113] Since the seller and the buyer may not be able to respond simultaneously or may not be online, this interaction can be inconvenient when zero - knowledge contingent payment (ZKCP) is performed. Also, the buyer (verifier) may wish that the proof is publicly verifiable, for example, if it is part of an advertisement for digital goods.

[0114] Furthermore, the proof is strictly zero-knowledge only in the perfect special-honest verifier model, i.e., only when it is assumed that the verifier generates truly random numbers as challenges and does not select challenge values to try to extract information about the proof.

[0115] To solve these problems, the Fiat-Shamir heuristic is applied, which replaces the random challenge value 'x' with the output of the hash of the commitment created by the prover. In the random oracle model (where the output of the cryptographic hash function is considered truly random), the prover cannot act dishonestly and the verifier can inspect the generated challenge value.

[0116] Thus, this example can be improved by using the Fiat-Shamir heuristic to convert the interactive proof system into a non-interactive one, and the prover can generate proofs that can be publicly verified independently offline.

[0117] More specifically, the challenge value (x) is replaced with a value calculated by hashing (e.g., with SHA-256) the concatenation of all the commitments generated by the prover (i.e., all the wire commitments and all the B and C1, C2, C3 commitments for the sum and product gates respectively).

[0118] Implementation - Batched Vector Commitments Compressed proof systems (Non-Patent Document 8, Non-Patent Document 6) regarding circuit satisfiability with batching of vector commitments use the method described below, which enables extraction of key state statement proofs from batched circuit wire commitments.

[0119] To avoid repetition, the following steps focus on the generation of batched wire commitments and illustrate that it contains the specified public key without describing the complete process. In the following steps, wire l is given a key opening, and assuming n wires are batched together within a vector commitment, the batched commitment is generated as follows. 1. The prover generates n - 1 random numbers x1,…,x n-1 ←Z p . 2. The prover calculates the elliptic curve points K i =x i ×G (for i = 1,…,n - 1). The sum of these values with K n =G forms the proof key PrK sent to the verifier. 3. The prover generates a random value: r←Z p . 4. Assuming w n is key - opened, the prover calculates the commitment to the vector of wire values w i (for i = 1,…,n):

Number

Number

Number

[0120] Summary of the Invention The proof of the equivalence of the hash preimage and the elliptic curve secret key can be utilized in numerous applications. Below, the construction of a specific example of a key statement zero-knowledge proof for utilization will be outlined. Two applications will be described.

[0121] The following statement S is a more specific version of statement 1 above for the purposes of the application example: S: "Given a SHA-256 hash function (H) with public output h and a public point P on the secp256k1 elliptic curve, the secret preimage s of the hash (i.e., h = H(s)) is equal to the elliptic curve point multiplication (i.e., the corresponding secret key, i.e., P = s × G)"

[0122] In the example provided, this statement, along with the assertion that the input wire (w1) is the secret key of the public point P and the output wire (wn) is equal to h, is composed of a single arithmetic circuit C SHA256 (having n wires w i (i = 1,…,n) and m gates), that is, [Number] is composed of.

[0123] Therefore, in order to fully verify this statement, the prover must demonstrate to the verifier that they know a satisfying assignment to the SHA256 circuit using a secp256k1-based commitment scheme, and then simply provide a key opening (ko1) for wire 1 and a full opening (w n ,r n ) for wire n. The verifier does not learn the value of the input wire (w1), that is, they do not learn the value of any of the other wires except for the output wire w n that is fully opened.

[0124] Application I The example of the present invention described in the above implementation section can be applied to ZKCP for an outsourced Bitcoin vanity address that represents data exchanged for payment or access to resources.

[0125] Bitcoin addresses are encoded in a human-readable alphanumeric format (Base58 encoding) to be easy to publish, copy, and transcribe. The use of this format has led to the popularity of so-called vanity addresses, such as those shown below: [External 1] To find a private key that generates an address containing a desired (name-like) string such as TIFF2025090713000009.tif25170, the key space is brute-force (exhaustive) searched.

[0126] Deriving a vanity address with a significant pattern is computationally expensive (for example, the address shown above required the generation of approximately 10 13 different public keys before a match was found), so it is common to outsource the search, and there are several online marketplaces where vanity addresses are sold on consignment. This can be done securely using the isomorphism of elliptic curve point multiplication (Non-Patent Document 7).

[0127] Outsourcing the generation is secure, but the sale of vanity addresses is untrustworthy. The buyer may obtain the required value before the seller receives payment, the seller may receive payment before passing the required value, or both may have to trust a third-party escrow service. The present invention can be used to enable a trustless sale of vanity addresses via ZKCP. The steps taken between the buyer / verifier and the seller / prover are described below. 1. The buyer and the seller agree on the required vanity pattern (Str) and price (a bitcoins) and establish a communication channel that does not need to be secure. 2. The buyer generates a secure random private key skB and the corresponding elliptic curve public key, and the public key pk B = sk B × G. 3. The buyer sends pk B to the seller. 4. Then, the seller performs a search for the required pattern at the Base58-encoded address derived from pk = pk B + i × G by varying i. 5. If an address with the required pattern is found, the seller saves i and signals the buyer to send pk s = i × G and the SHA256 hash H(i). 6. The seller also provides the buyer with proof that the preimage for H(i) is the private key corresponding to pk s . 7. The buyer verifies the proof and also confirms that the address corresponding to pk = pk B + pk s matches the agreed-upon pattern. At this point (by the proof), the buyer learns the value i and can derive the complete private key (sk B + i) regarding the vanity address for themselves, and knows that a specific value i hashes to h = H(i). 8. Then, the buyer constructs a hash time lock contract (HTLC) transaction Tx1 that includes an output containing the agreed-upon fee (a). This output can be unlocked in two ways, namely: i. At any time, using the signature from the seller and the hash preimage i, ii. For example, using the CHECKLOCKTIMEVERIFY (OP_CLTV) script opcode that can be used to prevent the output from being spent until a specified time or block height, and using the signature from the buyer after the specified time, it can be unlocked. 9. Next, the buyer signs this transaction and broadcasts it to the blockchain, where it is mined into a block. 10. Once confirmed, the seller can claim the fee in the output of Tx1 by providing a transaction Tx2 that supplies their signature and the value i for unlocking the hash lock, and the value i is revealed on the blockchain. 11. The buyer can calculate the final vanity address private key sk = sk B + i, where pk = sk × G. 12. If the buyer does not supply the value i before the specified OP_CLTV time, the seller can (to prevent the fee from being lost by an uncooperative buyer) provide a signature and re-claim the fee.

[0128] Then the transaction is fully atomic and trustless, the buyer receives payment only if a valid value i is provided, and the value i is publicly revealed on the blockchain. By splitting the private key, this value is useless to anyone else and does not compromise the security of the complete private key.

[0129] Use Case II The examples of the present invention described in the implementation section above can be applied to private data exchange between two parties, each having data to be exchanged recorded on their respective, different blockchains.

[0130] More specifically, the present invention can be applied to a cross-chain atomic swap that protects privacy, which is a trustless fair exchange protocol that utilizes the blockchain transaction mechanism, also known as atomic trade. This protocol is used to trade two different cryptocurrency tokens on two different blockchains without using a third-party centralized exchange. The word 'atomic' in this context refers to the nature of the fair exchange, where either both parties complete the transaction or neither does.

[0131] An example of a known basic protocol is executed according to the following steps. For security, both cryptocurrencies used in the swap must have a script function that enables a hashed and time-locked contract. This swap involves two parties, Alice and Bob. In this example, Alice holds 1 Bitcoin and agrees to trade it for 100 Litecoins of Bob. 1. Alice generates the Litecoin public key P A to send to Bob. 2. Bob generates the Bitcoin public key P B to send to Alice. 3. Alice generates a secure random number x. 4. Alice calculates the SHA-256 hash of x: h = H(x). 5. Alice creates a Bitcoin transaction Tx A , that is, i. Pays 1 Bitcoin to P B using a valid signature AND a value hashed to h, ii. OR Pays back 1 Bitcoin to Alice after 24 hours, for the Bitcoin transaction Tx A . 6. Alice broadcasts the transaction to the Bitcoin network. 7. When Bob observes that Tx A is confirmed on the Bitcoin blockchain, he creates a Litecoin transaction Tx B , that is, i. Pays 100 Litecoins to P A using a valid signature AND a value hashed to h, ii. OR Pays back 100 Litecoins to Bob after 24 hours, for the Bitcoin transaction Tx B . 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. When Bob observes the value x on the Litecoin blockchain, he can claim the Bitcoin output by providing his signature and the value x.

[0132] This example ensures that either both get the coins or neither does. Alice generates a hash value that only she knows the preimage of, but she is required to reveal this preimage to claim the coins, and that enables Bob to claim his coins. If either party fails to follow the protocol towards completion, both of them can re-claim their coins after a lockout period.

[0133] One significant drawback of the known protocols described above is that the transactions on both blockchains are trivially linkable, and once confirmed, the unique value x becomes publicly visible on both blockchains permanently. This affects both the fungibility of the coins and the privacy of the transactions.

[0134] To not link the two transactions, different keys must be used for the outputs on each chain, but for the protocol to be secure and trustless, Bob must be given a proof that he will learn the information necessary for him to unlock his coins when Alice reveals her hash preimage.

[0135] By adopting the key statement proof described in the above example, the hash-locked output on the second blockchain can be converted into a normal pay-to-public-key-hash (P2PKH) output, hiding the nature of the transaction and breaking any possible links.

[0136] Applying to the above example where Alice holds 1 Bitcoin and agrees to trade it for 100 Litecoins of Bob, the improved process will involve the following actions: 2. Alice generates the Litecoin public key P A to be sent to Bob (with the private key s A ). 3. Bob generates the Bitcoin public key P B to be sent to Alice (with the private key s B ). 4. Alice generates a secure random number x ← Z p . 5. Alice calculates the SHA-256 hash of x: h = H(x) and the elliptic curve public key corresponding to x: P x = x × G. 6. Alice securely sends both h and P x to Bob. 7. Alice also sends to Bob the key statement proof that the preimage of h is equal to the private key that generated P x . 8. Alice creates a Bitcoin transaction Tx A , that is, i. pays 1 Bitcoin to the public key P C = P B + P x , ii. OR pays 1 Bitcoin back to Alice after 24 hours, the Bitcoin transaction Tx A . 9. Alice broadcasts the transaction to the Bitcoin network. 10. When Bob observes that Tx on the Bitcoin blockchain has been confirmed, he creates a Litecoin transaction Tx, which is as follows: A i. Pay 100 Litecoins to P using a valid signature AND a value hashed with SHA-256 to h, B ii. OR pay back 100 Litecoins to Bob after 24 hours. That is, A B B 11. Bob broadcasts the transaction to the Litecoin network. 12. When the transaction is confirmed, Alice can claim the Litecoin output by providing her signature and the value x. 13. When Bob observes the value x on the Litecoin blockchain, he can claim the Bitcoin output by providing a signature using the private key of P which is s + x from the isomorphism of elliptic curve point multiplication. B C

[0137]

[0138] General Use

[0138] The present invention is suitable for zero-knowledge proof or verification of a statement (S) where a prover proves to a verifier that a statement is true while keeping the evidence (w) for the statement secret. The secret can be processed by a function such as a hash function, but can further include cryptographic elliptic curve key operations such as the validity of a statement regarding a public key. In the above example, the method of the present invention is used to enable trustless ZKCP regarding vanity addresses. This can also be applied to, for example, password derivation, verification of a valid machine-readable document such as a passport or identity certificate, or other such confidential transactions.Note that the above-described embodiments are not intended to limit the present invention, but are illustrative, and those skilled in the art can design numerous alternative embodiments without departing from the scope of the present invention defined by the appended claims.

[0139] In the claims, any reference signs placed in parentheses shall not be construed as limiting the claim. The terms "comprising" and "comprises" and the like do not exclude the presence of elements or steps other than those listed in any claim or the entire specification. In this specification, "comprises" means "including or consisting of", and "comprising" means "including or consisting of".

[0140] References to elements in the singular do not exclude references to those elements in the plural, and vice versa. The present invention can be implemented by means of several distinct elements of hardware or by a suitably programmed computer.

[0141] In a device claim listing several means, some of those means may be embodied by the same item of hardware. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of those means cannot be used advantageously.

Claims

1. 1. A computer-implemented method for enabling zero-knowledge proofs or verifications of a statement (S), in which a prover proves to a verifier that the statement is true while keeping a proof (w) for the statement private, the method comprising: Prover to Verifier: A statement (S) represented by an arithmetic circuit having m gates and n wires configured to implement a function circuit to determine, for a given function circuit output (h) and elliptic curve point (P), whether a function circuit input (s) to a wire of the function circuit is equal to a corresponding elliptic curve point multiplier (s); individual wire commitments and / or batched commitments for wires of said circuit; Function circuit output (h); A certification key (PrK); and transmitting This allows the verifier to determine that the circuit is satisfied and to compute the elliptic curve point (P) to verify the statement, and therefore to determine that the prover holds the evidence (w) for the statement. A computer-implemented method.

2. 2. The computer-implemented method of claim 1, wherein the prover sends individual wire commitments and communicates with the verifier using a Σ protocol to prove knowledge of the evidence (w).

3. 3. The computer-implemented method of claim 1 or 2, wherein the prover receives a challenge value (x) from the verifier and responds with an opening.

4. 3. The computer-implemented method of claim 1, wherein the prover sends the verifier a random value (x) that enables the verifier to determine that the statement is true and to calculate the elliptic curve point (P).

5. The computer-implemented method of claim 4 , wherein the random value (x) is a function of at least one commitment.

6. 6. The computer-implemented method of claim 4 or 5, wherein the random value (x) is calculated by hashing the concatenation of all the commitments generated by the prover and sent to the verifier.

7. The commitment W ｉ , W ｉ =Com(w ｉ , r ｉ ) and Com is a commitment to the function circuit, W ｉ is the wire value, r ｉ is a different random number for each wire commitment, i is the wire type, Com(w, r) = w x G + r x F, F and G are elliptic curve points, A computer-implemented method according to any preceding claim.

8. The input to wire l in the arithmetic circuit is k o =r ｌ ×F, ko is the key opening input, r ｌ is a random number, F is a point on the elliptic curve, 8. The computer-implemented method of claim 7.

9. The verifier checks that the circuit satisfies the elliptic curve point subtraction: pk ｌ =Com( / ) ｌ ,r ｌ )-か ｌ 10. The computer-implemented method of claim 8, wherein the public key for wire l can be computed via:

10. 2. The computer-implemented method of claim 1, wherein the prover sends a batch of wire commitments and generates random numbers for computing an elliptic curve point for each wire to form the proof key (PrK).

11. The batched commitments regarding the evidence include: [0010] and r is a random number generated by the prover, The prover is the wire value w ｉ Compute the commitment to vector w for i = 1,...,n, and ｎ is keyed open, K ｉ is the computed elliptic curve point, W ｉ is the wire value, F is a point on the elliptic curve, 11. The computer-implemented method of claim 10.

12. The input to wire n in the arithmetic circuit is [0025] and k ｎ is the key opening input, r is a random number, F is a point on the elliptic curve, 12. The computer-implemented method of claim 11.

13. The verifier performs elliptic curve calculations: [0030] 13. The computer implemented method of claim 12, further comprising: computing a public key opening of the key statement wire via:

14. 14. The computer-implemented method of claim 1, wherein the prover further sends a fully open commitment onto at least one wire.

15. 15. A computer-implemented method according to any preceding claim, wherein the method uses Pedersen commitments.

16. 16. The computer-implemented method of claim 1, wherein the statement uses only one arithmetic circuit for the function circuit.

17. A computer implemented method according to any preceding claim, wherein the function circuit implements a hash function, preferably a SHA-256 hash function.

18. The method is used by the prover to enable zero-knowledge attached transactions on data, such as cryptographic keys; The prover cooperates with a verifier to verify provided and received data and establishes a communication channel with the verifier; The prover receives from the verifier an elliptic curve public key pk generated by the verifier from a secure random private key skB. Ｂ Receive pk Ｖ = sk Ｖ × G, where G is an elliptic curve point, The prover uses data=pk Ｖ +i×G, The prover is pk Ｐ = i × G and the output f(i) from said function circuit whose function circuit input is said lock value i, The prover determines whether the input to the function circuit is pk Ｐ a statement (S) proof to the verifier that the private key corresponds to the The verifier verifies the proof, and pk=pk Ｖ +pk Ｐ Knowing the lock value i by verifying that the address corresponding to data (sk Ｂ +i) and determining that the lock value i is the function circuit input to the function circuit; The prover generates a transaction Tx that includes an output that includes the received data and is accessible by a signature from the prover and the function circuit inputs. １ Receive, The prover signs the transaction and broadcasts the transaction on the blockchain, which is then mined into a block, providing a second transaction Tx that provides the signature and value i to unlock the transaction. ２ By providing the transaction Tx １ and the transaction is revealed on the blockchain; Thus, the verifier can specify the lock value i to access the data provided by the prover, sk=sk Ｂ +i, pk=sk×G, 18. A computer-implemented method according to any preceding claim.

19. 20. The computer-implemented method of claim 18, wherein the data provided by the prover includes a vanity address.

20. 20. The computer-implemented method of claim 18, wherein the data received from the verifier comprises a cryptocurrency payment.

21. The prover exchanges data with the verifier in a trustless and fair manner. The prover has access to first data on a first blockchain, the verifier has access to second data on a second blockchain, the prover and the verifier agree to exchange the data, and the method includes: The prover generates a key pair for the second blockchain and generates a public key (P Ａ ) to the verifier, and a private key (s Ａ ) and The prover provides a verifier public key (P Ｂ ), and the verifier generates a key pair for the first blockchain to generate a private key (s Ｂ ) and The prover provides a statement (S), one or more commitments, and an input (P ｘ ) and the function circuit output (h), and the elliptic curve specification; The prover transmits the first data to a common public key address (P ｃ ) the first blockchain transaction Tx Ａ and broadcasting the transaction on the first blockchain network, the address of which is the input (P ｘ ) and the verifier public key (P ｃ ) and P Ｃ =P Ｂ +P ｘ and The prover transmits a second blockchain transaction Tx Ｂ The transaction is then verified by recording the first blockchain transaction Tx Ａ After verifying that the second data includes a prover public key address (P Ａ ) and the certifier public key address (P Ａ )teeth, The certifier public key address (P Ａ ) valid signature, A value that is a function circuit input preimage that determines the function circuit output (h), and The prover confirms the second blockchain transaction Tx Ｂ on the second blockchain and accessing the second data by providing a signature and the value that is the function circuit input of the function circuit output (h); Thus, the verifier observes the value that is the function circuit input that determines the function circuit output (h), and determines s from the isomorphism of elliptic curve point multiplication. Ｂ +s P Ｃ and enabling said first data to be accessed by providing a signature using a private key of 18. A computer-implemented method according to any preceding claim, comprising:

22. 22. The computer-implemented method of claim 21, wherein the data to be exchanged is cryptocurrency, and the first data corresponds to an amount of a first cryptocurrency, preferably Bitcoin, and the second data corresponds to an amount of a second cryptocurrency, preferably Litecoin.

23. 23. A computer readable storage medium having computer executable instructions which, when executed, configure a processor to perform a method according to any one of claims 1 to 22.

24. An interface device; one or more processors coupled to the interface device; a memory coupled to the one or more processors, the memory storing computer executable instructions that, when executed, configure the one or more processors to perform the method of any one of claims 1 to 22; An electronic device having:

25. A node of a blockchain network, the node being configured to carry out the method according to any one of claims 1 to 22.

26. A blockchain network comprising the nodes according to claim 25.

Images