Computer-implemented system and method for exchanging data

Abstract

To provide an efficient zero knowledge verification method of composite statements that involve both arithmetic circuit satisfiability and dependent statements about validity of public keys (key-statement proofs) simultaneously.SOLUTION: A method includes a prover P sending to a verifier V, a statement S having an arithmetic circuit with m gates and n wires Wi configured to implement a function circuit and determine whether for given function circuit output and an elliptic curve point, function circuit input to a wire of the function circuit is equal to a corresponding elliptic curve point multiplier, individual wire commitments Com and / or a batched commitment for wires of the circuit, input for a wire in the arithmetic circuit, and function circuit output. The prover receives from the verifier a challenge value x and responds or sends a proving key to the verifier. The verifier determines that the circuit is satisfied and calculates the elliptic curve point and validates the statement, thus determining that the prover holds a witness to the statement.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] This specification generally relates to computer-implemented methods and systems suitable for implementation in a computer processor or a group of such processors, such as nodes in a blockchain network. An improved method for generating proofs that enable efficient zero-knowledge verification of statements is provided. 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 particularly, but not exclusively, suitable for trustless and fair data exchange between data on two different blockchains. To achieve secure trustless exchange between participants, one of the parties can prove knowledge of a key or statement without revealing the statement. In particular, the exchanged data enables the identification of a private key for an address on the blockchain network. [Background technology]

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

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

[0004] Each transaction is a data structure that encodes the transfer of control of a digital asset between participants in a blockchain system and contains at least one input and at least one output. Each block contains the hash of the previous block with which it is chained, creating a permanent, immutable record of all transactions written to the blockchain before its inception. Transactions contain small programs known as scripts that are embedded in their inputs and outputs, which specify how the transaction's outputs can be accessed and by whom. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0005] Furthermore, this document references known zero-knowledge proof protocols and system architectures that use arithmetic circuits. Blockchains have provided a decentralized, permissionless, global mechanism that enables a solution to the problem of fair transactions between two mutually distrustful parties without the need for third-party arbitration or escrow. The fair exchange of data or information, for monetary reward or in exchange for information such as digital goods, is embodied in a transaction protocol known as ZKCP (Zero-Knowledge Contingent Payments) (Non-Patent Document 2). In ZKCP, specified data is transferred from the seller to the buyer only if the payment is confirmed, and payment from the buyer to the seller is completed only if this specified data is valid according to the terms of the sale. While the details of such protocols are known (Non-Patent Document 1), they are essentially based on a combination of hash-time-locked contracts (HTLCs) and zero-knowledge proofs, which simultaneously verify that encrypted information ('digital goods') is valid / accurate and that the 'password' that decrypts this information is the data that must be revealed on the blockchain to claim payment.

[0006] A central component of the ZKCP protocol is a zero-knowledge proof for a set of dependent statements about the validity or accuracy of data / information, the validity of a key, and the corresponding hash value. Such complex compound statements require a general computationally efficient zero-knowledge proof system, which ultimately allows one party to run an arbitrary program with a secret input and prove to another party that the program recognized the input as valid and executed correctly, without revealing any information about the secret input or the program's execution. In known ZKCP examples, the general-purpose zero-knowledge proof systems employed have been based on succinct non-interactive arguments of knowledge (SNARK) frameworks, such as those implemented in the Pinocchio protocol (NPL 3) and the C++ libsnark library (NPL 4).

[0007] Zero-knowledge SNARKs (zkSNARKs) provide a zero-knowledge way to prove the validity of any computation that can be expressed as an arithmetic circuit. Two main distinguishing properties of zkSNARKs are that they are non-interactive (the prover sends the proof to the verifier in one move) and concise (proofs are 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, untested cryptographic assumptions (i.e., knowledge of the exponent assumption and the pairing-based assumption). - For a given program (circuit), they require that a common reference string (CRS) be calculated by a third party who must be trusted to remove the configuration parameters. Anyone with knowledge of the configuration parameters has the ability to create fake proofs.

[0008] Constructing a zkSNARK to prove statements involving arbitrary cryptographic elliptic curve key operations has not been attempted to date, but would hypothetically consist of arithmetic circuits with hundreds of thousands or even millions of gates, resulting in proof generation times of minutes and proof keys hundreds of megabytes in size.

[0009] Technical background A basic system for interactive zero-knowledge proofs can use the Σ (Sigma) protocol, which involves several communication steps between the prover and the verifier. Typically, the Σ protocol requires three moves: 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 a statement based on the transcript (a,x,z).

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

[0011] Central to many interactive zero-knowledge protocols is the commitment scheme, which is used for the satisfiability of arithmetic circuits. A commitment allows a prover to commit to a secret value upfront and then verifiably reveal (open) the secret value. A commitment scheme has two main properties: first, it is covert, the commitment keeps the value secret; second, it is tied, the commitment can only be opened to the original committed value. The Pedersen commitment (Non-Patent Document 5) scheme involves two elliptic curve generating points, G and F, in a group G of prime order p known to all parties. A committer must be able to determine the identity of a prime integer Z.p Generate a secure random number r in the field and a commitment to a secret value s: Com(s,r)=s×G+r×F (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) at a later stage by providing the values s and r. 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] Pedersen commitments are additively homomorphic, i.e., adding two commitments (on an elliptic curve) yields 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 is.

[0014] Proof of arithmetic circuit satisfiability can be achieved with 'zero knowledge' (field Z p An arithmetic circuit (above) is a virtual configuration of arithmetic gates connected by wires (forming a directed acyclic graph) that is capable of performing arbitrarily complex computations, which must be limited to integer arithmetic and have no 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 the left (w L ) and right (w R ) wire input and one wire output (w O ), and FIG. 1(b) shows a schematic diagram 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 reality, a complete circuit has free input and output wires that define external (circuit) input and output values. A legal assignment is one that defines the wire values as satisfying the circuit, i.e., each wire is assigned a value and the output of each gate corresponds exactly to the product or sum of its inputs (i.e., the gate is consistent).

[0017] For a given arithmetic circuit, a prover can prove to a verifier that he knows the legal assignments for the circuit without revealing the wire values by first committing to each wire value in a legal assignment (using a Pedersen commitment), and then running a special Σ protocol with the verifier for each gate in the circuit (which can be run in parallel) with the wire values as evidence. These Σ protocols exploit the isomorphism of Pedersen commitments, as described below.

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

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

[0020] For each 'multiplication' gate (shown in Figure 1(a)), Σ prod The protocol is executed, which means that for each multiplication gate, L ·w R =w O This involves proving (with zero knowledge) that (i.e., the multiplication gate is satisfied). 1. The prover generates five random binding values: t1, t2, t3, t4, t5 ← Z p Generate. 2. The prover has C1=Com(t1,t3), C2=Com(t2,t5), C3=t1×W R +t4×F and send them to the verifier. 3. The verifier generates a random challenge value: x←Z p Respond with. 4. The prover opens the value: 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 and send them to the verifier. 5. Then, the verifier, L ·w R =w O As a proof, the following equation: Com(e1,z1)=x×W L +C1 Com(e2,z2)=x×W R +C2 e1×W R +z3×F=x×W O +C3 Inspect the following.

[0021] Σ zero Protocol and Σ prod The protocol can be run in parallel for verification of each gate in the circuit, and the same verification challenge value (x) can be used for all gates.

[0022] As an example, consider the circuit in Figure 1(b). To prove to the verifier with zero knowledge that the prover knows the legal assignments (i.e., the wire values that fill the circuit), the prover first sends the verifier the wire commitments for each gate (W1,...,W6) and the Σ protocol commitments (i.e., one additional commitment for each addition gate and five additional commitments for each multiplication gate).

[0023] Next, the verifier generates a random challenge x←Z p The prover responds with, ", and calculates the value that can be opened for each gate (one for each addition, five for each multiplication) and sends it back to the verifier. Then, the verifier performs the Σ protocol check, w1·w2=w4 w4·w5=w6 w2+w3=w5 and therefore, we verify that commitments W1,...,W6 correspond to satisfying wire values w1,...,w6.

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

[0025] The example in Figure 1(b) is a simple circuit. In practice, useful circuits consist of many more gates. Of particular interest is an arithmetic circuit for the SHA-256 hash function, which allows a prover to demonstrate knowledge of a 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). Proving knowledge of a SHA-256 preimage would then require transmitting about 5MB of data in both the initial commitment and opening rounds of the above protocol, requiring about 200,000 elliptic curve operations for both the prover and the verifier (each requiring several seconds of processor time).

[0026] Several methods have been 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 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 in which the communication complexity is reduced from O(n) to O(√n) or O(log(n)).

[0027] Also, for comparison, 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 and takes about 4 seconds to generate, and the proof also takes about 4 seconds to verify.

[0028] These methods will not be fully described here, except to explain the main vector batching protocol they employ in the following steps. This follows the same properties as the usual Pedersen commitment, but for n elements (m = m1,...,m n ) only requires sending a single group element: 1. The prover and verifier agree on a group element F ← G. 2. The prover generates n random numbers x1,…,x n ←Z p Generate. 3. The prover finds 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 generates a random number: r←Z p Generate. 5. The prover makes a commitment:

number

[0029] [Non-Patent Document 1] Campanelli, Matteo, et al. "Zero-knowledge contingent payments revisited: Attacks and payments for services." Commun. ACM (2017). [Non-patent document 2] https: / / github.com / zcash-hackworks / pay-to-sudoku [Non-patent document 3] Parno, Bryan, etal. "Pinocchio: Nearly practical verifiable computation." Securityand Privacy (SP), 2013 IEEE Symposium on. IEEE, 2013. [Non-patent document 4] https: / / github.com / scipr-lab / libsnark [Non-patent document 5] Bootle, Jonathan,et al. "Efficient zero-knowledge proof systems." Foundations ofSecurity Analysis and Design VIII. Springer, Cham, 2015. 1-31. [Non-patent document 6] Groth, Jens. "Linear Algebra with Sub-linear Zero-Knowledge Arguments." CRYPTO.Vol. 5677. 2009. [Non-Patent Document 7] https: / / bitcointalk.org / index.php?topic=81865.msg901491#msg901491 [Non-patent document 8] Bootle, Jonathan, et al. "Efficient zero-knowledge arguments for arithmetic circuits in the discrete log setting." Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, Berlin, Heidelberg, 2016. [Non-Patent Document 9] Standards for Efficient Cryptography (SEC) (Certicom Research, http: / / www.secg.org / sec2-v2.pd [Non-Patent Document 10] Bitcoin Developer Reference(http: / / bitcoin.org / en / developer-reference) Summary of the Invention

[0030] Generally, the present invention resides in a computer-implemented method for enabling zero-knowledge proofs or verification of statements, whereby a prover can prove to a verifier that a statement is true while keeping evidence for the statement private.

[0031] In particular, evidence can be access data that, when obtained, allows a verifier to access data protected by the evidence. The protected data can be protected using a blockchain network and its functions. More specifically, evidence can be access data that allows identification of a private key for an address on the blockchain network.

[0032] These statements are compound statements that simultaneously require both arithmetic circuit satisfiability and a dependent statement about the validity of the public key (a key statement proof).

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

[0034] The method includes a prover sending a verifier a set of data containing a statement relating to a given function circuit output and elliptic curve point, where the function circuit input is equal to a corresponding elliptic curve point multiplier(s).

[0035] The statement may be that the prover knows the private key for an address on the blockchain network.

[0036] The data includes individual and / or batched wire commitments, inputs, and outputs for the circuit of the statement. The prover may include in the data, or may have previously shared, a specification of the or each elliptic curve used in the statement. The prover then sends the opening in response to a challenge from the verifier. Alternatively, the prover may also include a proof key.

[0037] Using the data received from the prover, the verifier can determine that the circuit is satisfied, verifying the statement and therefore determining that the prover holds evidence for the statement. Elliptic curve points can also be computed. Upon receiving the data, the verifier determines, through computation, that the data matches the statement. The present invention is particularly suited to zero-knowledge proofs of hash preimage and elliptic curve private key equivalence.

[0038] The method is particularly suitable for atomic swaps between two blockchains with limited scripting capabilities that may leave one party in a vulnerable or unfair position. The method can compensate for the lack of scripting capabilities, for example, in Hash Time Locked Contracts (HTLCs). Thus, according to the present invention, there is provided a method and system as defined in the accompanying claims.

[0039] It is therefore desirable to provide a computer-implemented method for enabling zero-knowledge proofs or verifications of a statement (S) to enable an exchange of data between a prover and a verifier. Such an exchange may be referred to as an atomic swap. A prover named Alice has access to first data on a first blockchain, and a verifier named Bob has access to second data on a second blockchain, and the prover and verifier agree to exchange these data. For nominal purposes, the prover may be referred to as Alice and the verifier may be referred to as Bob. This data exchange is also known as an atomic swap.

[0040] A computer-implemented method for enabling zero-knowledge proofs or verifications of a statement (S) can be provided to enable an exchange of data between a prover and a verifier, the prover having access to first data on a first blockchain and the verifier having access to second data on a second blockchain, the method comprising: The prover generates a key pair for the second blockchain and provides the public key (P A ) to the verifier, and the private key (s A ) and The prover provides the verifier public key (P B ), the verifier generates a key pair for the first blockchain and uses the private key (s B ) and The prover sends a dataset to the verifier, which includes a zero-knowledge proof statement (S), one or more commitments, and an input (P x ) and function circuit output (h), The prover provides access to the first data via a shared public key address (P c ) the first blockchain transaction Tx A and broadcast the transaction on the first blockchain network, and the address is x ) and the verifier public key (PB ) and P C =P B +P x and The prover submits a second blockchain transaction, Tx B The transaction is then validated and the transaction is recorded in the first blockchain as a first blockchain transaction Tx A After verifying that the transaction contains the second data, the transaction is created by the verifier and broadcast on the second blockchain network, and the transaction grants access to the second data to the prover public key address (P A ) and transfer it to the prover public key address (P A )teeth, The prover public key address (P A ) and a valid signature on A value (x) that is a function circuit input that determines the function circuit output (h), and The prover submits a second blockchain transaction, Tx B is included on the second blockchain, and accesses the second data by providing its signature and a value (x) that is a function circuit input of the function circuit output (h); Thus, the verifier observes the value (x) that is the function circuit input that determines the function circuit output (h), and determines s from the isomorphism of elliptic curve point multiplication. B +x is P C and enabling the first data to be accessed by providing a signature using a private key for This includes:

[0041] The method involves: a prover generating a key pair for a second blockchain and providing a public key (P A ) to the verifier and sends the private key (s A ) for the first blockchain; the prover holds the verifier public key (P B ), the verifier generates a key pair for the first blockchain and creates a private key (s B), the prover sends a dataset to the verifier, which contains a zero-knowledge proof statement (S), one or more commitments, and an input (P x ) and a function circuit output (h). The data set may include an elliptic curve specification. The method further includes: a prover converting the first data into a shared public key address (P c ) the first blockchain transaction Tx A and broadcast the transaction on the first blockchain network, and the address is x ) and the verifier public key (P C ) and P C =P B +P x and the prover submits the second blockchain transaction Tx B The transaction is then validated and the transaction is recorded in the first blockchain as a first blockchain transaction Tx A After verifying that the transaction contains the second data, the transaction is created by the verifier and broadcast on the second blockchain network, and the transaction sends the second data to the prover public key address (P A ) and sends it to the prover's public key address (P A ) is the prover public key address (P A ), and a value that is a function circuit input preimage that determines the function circuit output (h); B is included on the second blockchain, and accesses the second data by providing its 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 obtains s from the isomorphism of elliptic curve point multiplication. B +x is P C providing a signature using a private key for the first data to access the first data.

[0042] At least one of the first data and the second data may be a cryptocurrency, and at least one of the cryptocurrencies may be Bitcoin or Litecoin.

[0043] The statement may consist of only one arithmetic circuit for the function circuit. The function circuit may implement a hash function. The hash function may be a SHA-256 hash function.

[0044] It is therefore also desirable to provide 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 the evidence (w) for the statement secret. This proof can be an explicit proof.

[0045] The method includes a prover sending a set of data (a set of data) to a verifier. The set of data includes statements having an arithmetic circuit with m gates and n wires configured to implement a function circuit and determine, for a given function circuit output (h) and elliptic curve point (P), whether function circuit input(s) to or to wires within the function circuit equals a corresponding elliptic curve point multiplier (s). The function circuit may be a circuit that implements a hash function function. A preimage to the hash function circuit or to a wire within the function circuit may equal the corresponding elliptic curve point multiplier.

[0046] The data also includes individual wire commitments and / or batched commitments. The or each commitment may be the wire inputs and outputs (which are encrypted) for the gates of the circuit. The data also includes the inputs. The inputs serve as key openings for the wires of the arithmetic circuit [elliptic curve point (P)]. Either the prover or the verifier may name the wires. The input or key opening may be for the first wire in the circuit. The data also includes the function circuit outputs. The data may include a specification of the or each elliptic curve used in the statement.

[0047] After transmitting the data, the prover receives a challenge value from the verifier and responds with an opening. The opening may be a value statement according to the Σ (Sigma) protocol. An opening value may be for each gate in the circuit that allows the verifier to determine that the statement is true and to compute the elliptic curve point.

[0048] As an alternative to waiting for a challenge, the prover may also 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.

[0049] The data sent to the verifier allows the verifier to determine that the circuit is satisfied, compute the elliptic curve points, verify the statement, and therefore determine that the prover holds evidence for the statement.

[0050] 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 analogous to determining the identity of the prover and the integrity of the key.

[0051] The input or key opening may be to the first wire in the arithmetic circuit. However, because proving knowledge of an intermediate wire is more difficult than proving knowledge of the first wire, a random wire is preferably selected. Furthermore, selecting a random wire other than the first wire is more robust and prevents a malicious third party from discovering the proof or evidence.

[0052] It would be equally desirable to provide a complementary computer-implemented method for enabling zero-knowledge proofs or verification of a statement, in which the verifier verifies that the statement is true without knowing the evidence (w) for the statement by analyzing 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-socket fashion. The present invention extends to full collaboration between the prover and the verifier.

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

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

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

[0056] Commitment is W i =Com(w i ,r i ) and Com is a commitment to function circuits, w i is the 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, F and G are elliptic curve points.

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

[0058] The wire may be the first wire in a circuit.

[0059] The verifier can verify that the circuit satisfies elliptic curve point subtraction: pk l =Com(w l ,r l )-ko l The public key for wire l can be calculated via

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

[0061] The batched commitments regarding evidence are

number

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

number

[0063] The input may be to the first wire.

[0064] The verifier performs elliptic curve operations:

number

[0065] The prover may further send a fully open commitment on at least one wire. The method may use Pedersen commitments. The statement may use only one arithmetic circuit for the function circuit. The function circuit may implement a hash function, preferably a SHA-256 hash function.

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

[0067] The prover may perform a search for the required pattern in the Base58 encoded address obtained by varying i. P = i × G, and the output f(i) from the function circuit whose function circuit input (e.g., preimage) is the lock value i, to the verifier.

[0068] The prover proves that the input to the function circuit is pk PThe verifier can then send a statement proof to prove to the verifier that the private key corresponds to pk = pk. V +pk P By verifying that the address corresponding to matches the agreed-upon pattern, knowing the lock value i may enable derivation of a perfect secret key for the data and identify that the lock value i is a function circuit input to the function circuit.

[0069] The prover may receive a transaction Tx1 that includes an output that includes received data accessible by a signature from the prover and a function circuit input. The transaction may be a hash time lock function. The received data may provide access to the UTXO.

[0070] the prover can sign the transaction and broadcast it on the blockchain, which is mined into a block, allowing the prover to access the data from the output of transaction Tx1 by providing a second transaction Tx2 that provides a signature and value i to unlock the transaction, and the transaction is revealed on the blockchain, thus allowing the verifier to identify the lock value i and access the data provided by the prover; sk=sk B +i, pk=sk×G.

[0071] The data provided by the prover may include a vanity address, and the data received from the verifier may include a cryptocurrency payment (e.g., a UTXO).

[0072] Transactions can be fully atomic and trustless, and buyers only receive payment if they provide a valid value i, which is publicly revealed on the blockchain. Due to the private key split, the value revealed on the blockchain is useless to anyone else and does not compromise the security of the full private key.

[0073] A computer-implemented method may involve a prover performing a trustless, fair data exchange with a verifier (without a centralized third-party exchange). This may be described as a cross-chain atomic swap or atomic trade, since in this context it refers to a fair exchange where either both parties complete the transaction or neither completes it. This swap may be performed across blockchains that support scripting functionality that allows for hashed, time-locked contracts.

[0074] The prover has access to a first piece of data, e.g., a UTXO of 1 Bitcoin, on a first blockchain, and the verifier has access to a second piece of data, e.g., 100 LTC, on a second blockchain, and the prover and verifier agree to exchange data. The method involves the prover generating a key pair for the second blockchain, sending the public key to the verifier, and retaining the private key; the prover receiving the verifier public key for the first blockchain, and the verifier generating a key pair for the first blockchain and transmitting the private key (s B ), and the prover submits a statement, one or more commitments, an input or key opening and function circuit output (h), and an elliptic curve specification.

[0075] The prover creates a first blockchain transaction Tx that sends the first data to the shared public key address. Aand broadcast the transaction on the first blockchain network, where the address is determined by the sum of the input and the verifier public key. This data can be accessed by the prover after no swap has been performed within 24 hours.

[0076] The prover then issues a second blockchain transaction, Tx B The transaction can be verified, and the transaction is recorded in the first blockchain as a first blockchain transaction Tx A a transaction created by the verifier and broadcast on a second blockchain network after verifying that the transaction contains the value of the prover's public key address, which sends second data in the form of 100 LTC to the prover's public key address, which is accessible by the prover using a valid signature on the prover's public key address and values that are function circuit inputs that determine the function circuit outputs. This data can be accessed by the verifier after no swap has been performed within 24 hours.

[0077] The prover then issues a second blockchain transaction, Tx B is included on the second blockchain, and accesses the second data by providing a signature and the above value, which is the function circuit input of the function circuit output. Thus, the verifier observes the above value, which is the function circuit input that determines the function circuit output, and (from the isomorphism of elliptic curve point multiplication) B +s P C The first data may be accessed by providing a signature using the private key.

[0078] The data exchanged may be cryptocurrencies, the first data corresponding to an amount of the first cryptocurrency, preferably Bitcoin, and the second data corresponding to an amount of the second cryptocurrency, preferably Litecoin.

[0079] As noted above, every action by the prover requires a reverse action by the verifier to verify the proof. The 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, in which the prover attests to the verifier that the statement is true, preferably explicitly, while keeping evidence for the statement private, 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, to determine whether a function circuit input or preimage to the function circuit is equal to an elliptic curve point multiplier for a given function circuit, and preferably for a specified function circuit output and elliptic curve point. The verifier also receives individual and / or batched wire commitments, which are encrypted wire inputs and outputs for the wires of the circuit, inputs or key openings for wires in the arithmetic circuit (preferably wires other than the first wire), and the function circuit output (h). The verifier may also receive a specification of the 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 follow the Σ protocol and include values for each gate in the circuit that allows the verifier to determine that the statement is true and to compute the elliptic curve point. Additionally or alternatively, the verifier can receive a proof key from the prover.

[0080] The verifier then determines that the circuit is satisfied, computes the elliptic curve point (P), and therefore determines that the prover holds evidence (w) for the statement.

[0081] This can be achieved by proving with zero knowledge that the prover knows the values for each gate in the statement circuit, using the Sigma protocol if the proof is interactive, or using a proof key if the Fiat-Shamir heuristic is used. The verifier can receive the Σ_zero and Σ_prod commitments for each gate from the prover, respond with a challenge value, receive an opening value from the prover, and verify the commitments. The verifier can verify that the circuit is satisfied by computing the public key for wire l via elliptic curve point subtraction. The verifier can verify that each public key for each wire matches the key(s) specified in the statement. The verifier can complete the verification by determining that the fully opened wires match the specifiable values in the statement.

[0082] It is also desirable to provide a computer-readable storage medium having computer-executable instructions which, when executed, configure a processor to perform a method performed by a prover, by a verifier, or by a prover and a verifier working together.

[0083] 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 perform the methods claimed herein. It is also desirable to provide a node of a blockchain network configured to perform the methods claimed herein. It is also desirable to provide a blockchain network having such a node. [Brief explanation of the drawings]

[0084] BRIEF DESCRIPTION OF THE DRAWINGS Aspects of the present invention will be apparent from and elucidated with reference to the embodiments described herein. Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] Figures 1(a) and (b) are diagrams used in the technical background section to describe the basic system for interactive zero-knowledge proofs. Figure 1(a) is a schematic diagram of a multiplication gate with left and right wire inputs and one wire output, and Figure 1(b) is a schematic diagram of an arithmetic circuit with three gates, three input wires, one output wire, and two internal wires. [Figure 2] 1 is a schematic diagram of a composite circuit for a statement, including arithmetic circuits for hash functions and elliptic curve multiplication. [Figure 3] FIG. 2 is an alternative schematic diagram of an arithmetic circuit for the compound statement of FIG. 1, in which only one arithmetic circuit is required. [Figure 4] 1 is a schematic diagram of an arithmetic circuit with four gates and five wires, each wire having its own public key that is revealed or opened from a wire commitment with a key opening value. [Figure 5] is a schematic representation of the data exchanged between prover and verifier for proof of a statement S, with a circuit description and the first wire carrying the corresponding public key. [Figure 6] 1 is another schematic representation of the data exchanged between the prover and the verifier. [Figure 7] FIG. 5 is a schematic diagram of the checks performed by a verifier to verify that the circuit of FIG. 4 is filled, that the input wires have the required public keys, and that the hashes of the output wires have the required values. DETAILED DESCRIPTION OF THE INVENTION

[0085] Overview The present invention enables efficient zero-knowledge verification of compound statements that simultaneously require both arithmetic circuit satisfiability and dependent statements about the validity of public keys (key statement proofs). Public-key elliptic curve specifications are employed within an isomorphic commitment function to prove circuit satisfiability. This enables the proof of public-key statements corresponding to private keys used as circuit inputs and / or outputs in an efficient manner.

[0086] The proof size and computational cost of generating proofs for statements involving both circuit satisfiability and elliptic curve key pairs 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 compatible with the Bitcoin secp256k1 standard.

[0087] Two applications are described that involve fair exchange transactions between two parties on a blockchain, such as the Bitcoin blockchain. The first involves zero-knowledge collateral payments for trustless sales of outsourced vanity addresses, which requires a zero-knowledge proof of equality between a SHA256 hash preimage and an elliptic curve (e.g., Bitcoin) private key. The second involves improving the security of cross-chain atomic swaps, which requires a proof that a SHA256 hash preimage equals an unknown private key (with a provided public key) multiplied by a provided nonce.

[0088] General Solution The present invention relates to a method that allows the proof of a particular class of compound statements involving an elliptic curve public / private key pair (based on elliptic curve point multiplication).

[0089] It is considered impractical to use zkSNARKs to prove statements involving arbitrary cryptographic elliptic curve key operations, and therefore the method uses information about elliptic curve public keys extracted directly from the "homomorphic hiding" (or commitment scheme) used to construct 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.

[0090] However, SNARK methods require pairing operations and therefore require special bilinear pairing-friendly elliptic curves, which makes the use of zk-SNARKs impossible, as the elliptic curves used on some blockchains are not compatible with bilinear pairing-friendly elliptic curves.

[0091] As an example, statements relating to Bitcoin public keys use the Bitcoin secp256k1 curve, which is incompatible.

[0092] Our method is therefore compatible with other protocols for proving arithmetic circuit satisfiability that do not rely on pairing and have fewer cryptographic assumptions. Overall, our method is more efficient than zkSNARKS because it requires fewer computations and results in smaller proof sizes for trustless exchange applications.

[0093] As an example, the schematic diagram in Figure 2, which represents a composite circuit for "Statement 1" below, includes both a hash function and an elliptic curve multiplication subcircuit. In Figure 2, the schematic diagram has three inputs: a private key 's', its corresponding public key 'P', and a value 'h' (which is a hash of the private key 's'). The schematic diagram includes two arithmetic circuits: one that performs a hash on the private key, and a second that performs an elliptic curve multiplication (EC multiply) on the private key. The outputs of these circuits are compared with the inputs.

[0094] Note that these internal gates are for illustrative purposes only. This circuit verifies that the hash output is equal to an Elliptic Curve (EC) public key. Only the inputs 'h', 'P', and the output are fully revealed to the verifier; all other values are encrypted.

[0095] Statement 1 "Given the output h of a hash function (H) and an elliptic curve point P (the public key), the preimage of the hash s (i.e., h = H(s)) is equal to the elliptic curve point multiplier (the private key, i.e., P = s × G, where G is the elliptic curve generator point)."

[0096] The method allows the prover to prove this particular statement with zero-knowledge. Examples of applications that benefit from such a method are described below for trustless data exchange (e.g., selling outsourced Bitcoin vanity addresses) and anonymized, secure cross-chain atomic swaps.

[0097] Verifying that statement 1 is true can be determined, for example, using the following pseudocode function, which takes inputs 'h', 'P', and 's' and outputs '1' if the statement is true, and '0' otherwise: int verify(h,P,s) { if(h == H(s) && P == sx G) { return 1 } else { return 0 } }

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

[0099] While arithmetic circuits for the SHA-256 hash function are widely used and optimized, typically containing fewer than 30,000 multiplication gates, there are no known examples of arithmetic circuits for cryptographic elliptic curve point multiplication implementations in the literature. Even if such circuits were known, they would be impractical due to their size and complexity and would contain many more gates.

[0100] The method works with a complete arithmetic circuit for a single hash function as shown in Figure 2, which has a schematic diagram of the arithmetic circuit for the key statement proof and the compound statement 1 using only one arithmetic circuit for the hash function. This circuit verifies that the hash output is correct and that the public key is equal to the EC encrypted input (the key statement proof). The values highlighted in blue, i.e., input 'h', 'P' and output '1', are revealed to the verifier, while all other values are encrypted.

[0101] Using the circuit in Figure 3, a prover can explicitly prove, via circuit satisfiability, that the hash of a private key 's' is 'h' and that the corresponding public key 'P' of the key pair is equal to 's × G', where G is the elliptic curve generator point. The private key 's' is the preimage of the hash, or input to the function, and is not revealed to the verifier when proving the statement.

[0102] Needless to say, verifying that 's × G' is equal to 'P' can be extracted from the circuit proof with negligible additional computational cost 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'.

[0103] Technical effects The well-known zk-SNARK (Zero-knowledge Succinct Non-interactive Arguments of Knowledge) is one implementation of a general-purpose proof system for arithmetic circuit satisfiability. In the SNARK framework, a statement encoded as an arithmetic circuit is transformed into a construction called a Quadratic Arithmetic Program (QAP), which consists of a set of polynomials. The statement can then be proven 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 few elliptic curve (pairing) operations (taking a few milliseconds), and the proof is very small (288 bytes) and independent of the circuit size.

[0104] The extremely small proof and verification times achieved by SNARK methods come at the expense of a trust setup, 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's secp256k1. Statements involving general elliptic curve point multiplication must then use explicit circuits, which can be very large.

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

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

[0107] The present invention enables zero-knowledge proofs of statements involving elliptic curve public-private key relations, along with general arithmetic circuit satisfiability. This is achieved at 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.

[0108] implementation Below, implementations of the present invention are described for both batch and non-batch commitment-based zero-knowledge proof systems.

[0109] In these examples, the zero-knowledge proof protocol involves two parties: a prover (P) and a verifier (V). The goal of the protocol is for the prover to convince the verifier that a given statement (S) is true, while keeping information about the evidence for that statement private. The statement is given by an arithmetic circuit (C) with m gates and n wires, and an elliptic curve public key: pk corresponding to one (or more) of the circuit wire values. l where the subscript l is the wire index of the key statement. Furthermore, statements may also contain assertions about fully exposed (public) wire values (i.e., the public inputs / outputs of the circuit).

[0110] The elliptic curve public key(s) specified in the statement correspond to a target elliptic curve specification (which is specified by the complete set of elliptic curve parameters: T = (p, a, b, G, n, h)).

[0111] In the case of the Bitcoin script, these parameters are defined by the secp256k1 (Non-Patent Document 9) specification. This specification includes a 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 a function of Z). p (Fragment is an element of ). Because allowing the prover to freely choose f would allow the prover to generate false proofs, 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 π.

[0112] Batched and unbatched commitments are described with reference to Figure 4, which is a representative arithmetic circuit with four gates and five wires. The input wire (w1) has its public key revealed or opened from the wire commitment W1 with a 'key-opening' value k01.

[0113] Implementation - Individual Wire Commitment Using Figure 4 as an example, 'key openings' are individual commitments for each wire in the circuit that are made by the prover and sent to the verifier. These key openings follow the well-known Σ protocol for arithmetic circuit satisfiability. Figure 5 shows the data exchanged between the prover and verifier.

[0114] Satisfiability is achieved by including several steps: 1. For each wire i (i = 1, ..., n) in the circuit, a commitment is made using the Pedersen commitment: W i =Com(w i ,r i ) where: Com(w,r)=w×G+r×F 2. For a circuit wire l, which requires the proof of the corresponding public key (key statement proof), the prover also performs key opening: ko l =r l ×F Also send. 3. Optionally, if the circuit wire j is required to be openly revealed (fully exposed wire), the prover must provide the complete opening tuple: (w j ,r j ) Send. 4. Then, each gate in the circuit is proved to be satisfied with zero knowledge using the Σ protocol, which means that the prover can prove that for each gate, zero and Σ prod This involves calculating and sending a commitment (i.e., B, or C1, C2, and C3, respectively), the verifier responding with a challenge value (x), the prover then sending opening values (z and e values), and the verifier verifying the commitment. 5. Once the verifier confirms that the circuit is satisfied, the verifier then performs elliptic curve point subtraction: pk l =Com(w l ,r l )-ko l Calculate the public key on the wire l via 6. Then, the verifier checks each pk l The validation is completed by checking that the matches the key(s) specified in the statement (and that the fully opened wires match the specified values).

[0115] Detailed implementation - individual wire commitments With continued reference to Figure 4, we provide an explicit example detailing the individual commitments and verifications of this example. This describes verifying the satisfiability of a simple arithmetic circuit with both a key statement proof of one of its wires and a full disclosure of the other wire.

[0116] Circuit C shown in Figure 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.

[0117] The prover and verifier agree on a statement that includes the circuit, the value on wire 5, and the public key on wire 1, along with the elliptic curve and commitment specification. The statement (S) that the prover wants to prove to the verifier that it is true is: "I am trying to find a satisfying assignment to a circuit C (i.e., a wire value {w i} i=1 5 where Wire 1 has the public key P (i.e., P = w1 × G) and Wire 5 has the value h (i.e., w n =h)” is.

[0118] The values of wires 1 through 4 are not revealed. The prover and verifier then interact as shown in Figure 6 and described below: 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 the key opening for wire 1: ko1 = r1 × F and sends it to the verifier. 3. The prover sends the complete opening information about wire 5 (w5, r5) to the verifier. 4. For the addition gates (g1 and g3), the prover must B1 and r B3 Commitment to zero: B1 = Com(0,r B1 ) and B3 = Com(0,r B3 ) and send them to the verifier. 5. For the multiplication gates (g2 and g4), the prover generates a commitment as follows: About Gate 2: C 12 =Com(t 12 ,t 32 ) C2 = Com(t 22 ,t 52 ) and C3=t 12 ×W1+t 42 ×F About 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 The value is a random blinding nonce. The prover sends these commitments to the verifier. 6. The verifier then 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 addition gates (g1 and g3), the prover performs the following opening: z1=x(r1+r1-r2)+r B1 z3=x(r2+r1-r4)+r B3 and send them to the verifier. 8. For multiplication gates (g2 and g4), the prover performs the following opening: 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 and send them to the verifier. 9. Finally, the verifier checks for equality. If these pass, the proof is verified.

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

[0120] The challenge 'x' in Figures 5 and 6 provides an interactive proof, with back and forth communication between the prover and the verifier.

[0121] This interaction can be inconvenient when zero-knowledge contingent payments (ZKCPs) are made, as the seller and buyer may not be available or online at the same time. Also, the buyer (verifier) may want the proof to be publicly verifiable, for example, if it is part of an advertisement for a digital good.

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

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

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

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

[0126] Implementation - Batched Vector Commitment Compact proof systems for circuit satisfiability with batching of vector commitments (Non-Patent Document 8, Non-Patent Document 6) use the method described below, which allows extracting key statement proofs from batched circuit wire commitments.

[0127] To avoid repetition, we will not describe the complete process, but rather the following steps focus on illustrating the generation of a batched wire commitment and its inclusion of a specified public key. In the following steps, given a wire l given a key opening, and n wires batched together in a vector commitment, the batched commitment is generated as follows: 1. The prover generates n-1 random numbers x1,…,x n-1 ←Z p Generate. 2. The prover finds an elliptic curve point K i =x i Calculate ×G(for i=1,…,n-1). Add K to these values. n = G form the proof key PrK that is sent to the verifier. 3. The prover generates a random value: r←Z p Generate. 4. w n is to be keyed, and the prover obtains the wire value w i Commitment to a vector w (for i=1,…,n):

number

number

number

[0128] Summary of the Invention Proofs of hash preimage and elliptic curve private key equivalence can be used in a number of applications. Below we describe two applications that outline the construction of specific examples of key-statement zero-knowledge proofs for use.

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

[0130] In the example provided, this statement is the SHA-256 hash function C, along with the assertion that the input wire (w1) is the private key of the public point P, and that the output wire (wn) is equal to h. SHA256 (n wires w i (i=1,...,n) and m gates), i.e.,

number

[0131] Therefore, to fully verify this statement, the prover must demonstrate to the verifier that it knows the satisfying assignment to the SHA256 circuit using a secp256k1-based commitment scheme, and then provide the key opening (ko1) for wire 1 and the full opening (w n ,r n The verifier does not know the value of the input wire (w1), i.e., the output wire w n The values of any of the other wires are not taught.

[0132] Application I The example of the present invention described in the implementation section above can be applied to ZKCP for outsourced Bitcoin vanity addresses, which represent data exchanged for payments or access to resources.

[0133] 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, such as the one shown below: [Outside 1] The key space is brute-force searched to find private keys that yield addresses containing the desired (name-like) string, such as TIFF0007725629000009.tif25170.

[0134] Because deriving vanity addresses with meaningful patterns is computationally expensive (e.g., the address shown above takes approximately 10 13 It is common to outsource the search (which required the generation of several different public keys), and there are several online marketplaces where vanity addresses are sold on consignment. This can be done securely using the isomorphism property of elliptic curve point multiplication [7].

[0135] While outsourcing generation is secure, selling vanity addresses is untrustworthy. The buyer must obtain the required value before the seller receives payment, or the seller must receive payment before delivering the required value, or both parties must trust an escrow service. The present invention can be used to enable the trustless sale of vanity addresses via ZKCP. Below we describe the steps taken between the buyer / verifier and the seller / prover. 1. A buyer and seller agree on the desired vanity pattern (Str) and price (a Bitcoin) and establish a communication channel that does not need to be secure. 2. The buyer generates a secure random private key skB and a corresponding elliptic curve public key pk B =sk B ×G. 3. Buyer pk to seller B Send. 4. Then, the seller changes i to pk=pk B + Perform a search for the required pattern in the Base58 encoded address derived from i×G. 5. If an address with the required pattern is found, the seller saves i and signals to the buyer that pk s = i × G and send the SHA256 hash H(i). 6. The seller also assumes that the preimage for H(i) is pk s The buyer will receive proof that the private key corresponds to the 7. The buyer verifies the proof and checks that pk=pk B +pk s verifies that the address corresponding to i matches the agreed-upon pattern. At this point (by the proof), the buyer knows that by learning the value i, he or she has the full private key (sk) for the vanity address. B +i) and knowing that a particular value i hashes to h = H(i). 8. The buyer then constructs a hash time-locked contract (HTLC) transaction Tx1 that includes 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 seller and the hash preimage i, ii. With a signature from the buyer after a specified time, for example using the CHECKLOCKTIMEVERIFY (OP_CLTV) script op code, which can be used to prevent outputs from being consumed until a specified time or block height; Can be unlocked. 9. The buyer then signs and broadcasts this transaction to the blockchain, where it is mined into a block. 10. Once confirmed, the seller can claim the fee on the output of Tx1 by submitting transaction Tx2, supplying his signature and the value i to unlock the hash lock, and the value i is revealed on the blockchain. 11. The buyer will receive the final vanity address private key sk=sk B +i can be calculated, and pk = sk × G. 12. If the buyer does not supply the value i before the specified OP_CLTV time, the seller can provide a signature to reclaim the fee (to prevent fees from being lost due to an uncooperative buyer).

[0136] The transaction is then fully atomic and trustless, and the buyer only gets paid if they provide a valid value i, which is publicly revealed on the blockchain. Due to the private key split, this value is useless to anyone else and does not compromise the security of the full private key.

[0137] Application II The example of the present invention described in the implementation section above can be applied to a private data exchange between two parties, each with the data to be exchanged recorded on a respective, different blockchain.

[0138] More specifically, the present invention can be applied to privacy-preserving cross-chain atomic swaps, also known as atomic trades, which are trustless, fair exchange protocols that leverage blockchain transaction mechanisms. This protocol is used to trade two different cryptocurrency tokens on two different blockchains without the use of a centralized third-party exchange. The word 'atomic' in this context refers to the fair nature of the exchange: either both parties complete the transaction, or neither completes it.

[0139] An example of a known basic protocol follows these steps: To be secure, both cryptocurrencies used in the swap must have scripting capabilities that allow for hashed and time-locked contracts. The swap involves two parties, Alice and Bob. In this example, Alice holds 1 Bitcoin and agrees to trade it for Bob's 100 Litecoin. 1. Alice sends her Litecoin public key P to Bob. A Generate. 2. Bob sends the Bitcoin public key P to Alice. B Generate. 3. Alice generates a secure random number x. 4. Alice computes the SHA-256 hash of x: h = H(x). 5. Alice submits the following Bitcoin transaction Tx A , i.e., i. Validate the signature AND hash to h to convert 1 bitcoin to P B pay to, ii. OR refund 1 Bitcoin to Alice after 24 hours; Bitcoin transaction Tx A Create a. 6. Alice broadcasts the transaction to the Bitcoin network. 7. Bob sends Tx A is confirmed, the following Litecoin transaction Tx B , i.e., i. Validate the signature AND hash the value to h to generate 100 Litecoins. A pay to, ii. OR refund Bob 100 Litecoins after 24 hours, Bitcoin transaction Tx B Create a. 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 a value x on the Litecoin blockchain, he can claim the Bitcoin output by providing his signature and the value x.

[0140] This example ensures that either they both get their coins or neither gets theirs. Alice generates the hash value, and only she knows the preimage, but she is required to reveal this preimage to claim the coins, which allows Bob to claim his coins. If either party does not follow the protocol to completion, they can both reclaim their coins after a lockout period.

[0141] One significant drawback of the known protocols mentioned above is that transactions on both blockchains are trivially linkable, and once confirmed, the unique value x is publicly visible on both blockchains forever, affecting both the fungibility of coins and the privacy of transactions.

[0142] To unlink 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 by Alice that when she reveals her hash preimage, he will be told the information he needs to unlock his coins.

[0143] By employing the key-statement proof described in the example above, the hash-locked output on the second blockchain can be transformed into a regular pay-to-public-key-hash (P2PKH) output, hiding the nature of the transaction and breaking any possible link.

[0144] Applying the example above, where Alice holds 1 Bitcoin and agrees to trade it for Bob's 100 Litecoin, the refinement process would involve the following actions: 2. Alice sends her Litecoin public key P to Bob. A (private key s A ) to generate a 3. Bob sends the Bitcoin public key P to Alice. B (private key s B (by) generating. 4. Alice generates a secure random number x←Z p Generate. 5. Alice obtains the SHA-256 hash of x: h = H(x) and the corresponding elliptic curve public key: P x Calculate = x × G. 6. Alice is given h and P x and securely transmit both to Bob. 7. Alice also knows that the preimage of h is P x Send Bob a key statement proof that the generated private key is equal to the 8. Alice issues the following Bitcoin transaction Tx A , i.e., i. 1 Bitcoin with public key P C =P B +P x pay to, ii. OR refund 1 Bitcoin to Alice after 24 hours; Bitcoin transaction Tx A Create a. 9. Alice broadcasts the transaction to the Bitcoin network. 10. Bob sends Tx A is confirmed, the following Litecoin transaction Tx B , i.e., i. Validate the signature AND the SHA-256 hash of h to generate 100 Litecoins. A pay to, ii. OR refund Bob 100 Litecoins after 24 hours, Bitcoin transaction Tx B Create a. 11. Bob broadcasts the transaction to the Litecoin network. 12. Once the transaction is confirmed, Alice can claim the Litecoin output by providing her signature and the value x. 13. When Bob observes a value x on the Litecoin blockchain, he knows that s B +x is P C A user can request a Bitcoin output by providing a signature using the private key of

[0145] General uses The present invention is suitable for zero-knowledge proofs or verifications 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 secret can be handled by a function, such as a hash function, but can also include cryptographic elliptic curve key operations, such as validating the statement with respect to a public key. In the above example, the method of the present invention is used to enable trustless ZKCP for vanity addresses. This can also be applied, for example, to derivation of passwords, verification of valid machine-readable documents such as passports or identity certificates, or other such sensitive transactions.

[0146] It should be noted that the above-described embodiments are illustrative rather than limiting of the present invention, and that those skilled in the art will be able to design numerous alternative embodiments without departing from the scope of the present invention as defined by the appended claims.

[0147] In the claims, any signs placed between parentheses shall not be construed as limiting the claim. The words "comprises" and "having" and the like do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprises" means "comprises or consists of" and "having" means "comprising or consisting of."

[0148] The singular reference of an element does not exclude the plural reference of such elements and vice versa. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer.

[0149] In a device claim enumerating several means, several of these means may be embodied by one and 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 these means cannot be used to advantage.

Claims

1. 1. A computer-implemented method for enabling zero-knowledge proofs or verifications of a statement (S) to enable an exchange of data between a prover computer system and a verifier computer system, the prover computer system having access to first data on a first blockchain and the verifier computer system having access to second data on a second blockchain, the method comprising: The prover computer system generates a key pair for the second blockchain, and a public key (P Ａ ) to the verifier computer system, and the private key (s Ａ ) and The prover computer system provides a verifier computer system public key (P Ｂ ), and the verifier computer system generates a key pair for the first blockchain and selects a private key (s Ｂ ) and The prover computer system sends a data set to the verifier computer system, the data set comprising a zero-knowledge proof statement (S), one or more commitments, an input (P ｘ ) and function circuit output (h), the data further including a vanity address; The prover computer system provides access to the first data via a shared public key address (P ｃ ) the first blockchain transaction Tx Ａ and broadcast the transaction on the first blockchain network, where the address is the address of the input (P ｘ ) and the verifier computer system public key (P Ｂ ) and P Ｃ =P Ｂ +P ｘ and The prover computer system generates a second blockchain transaction Tx Ｂ and the transaction is registered in the first blockchain as the first blockchain transaction Tx Ａ and the transaction is created by the verifier computer system and broadcast on a second blockchain network after verifying that the second data includes a public key address (P Ａ ) and transfer it to the prover computer system public key address (P Ａ )teeth, The prover computer system public key address (P Ａ ) and a valid signature on A value (x) that is a function circuit input that determines the function circuit output (h), and The prover computer system transmits the second blockchain transaction Tx Ｂ is included on the second blockchain, and accesses the second data by providing its signature and the value (x) that is the function circuit input of the function circuit output (h); Thus, the verifier computer system observes the value (x) that is the function circuit input that determines the function circuit output (h), and determines s from the isomorphism of elliptic curve point multiplication. Ｂ +x P Ｃ and enabling said first data to be accessed by providing a signature using a private key for said A computer-implemented method comprising:

2. The computer-implemented method of claim 1 , wherein the vanity address is obtained from a third party.

3. The computer-implemented method of claim 1 , wherein the vanity address comprises a string that identifies a party.

4. 10. The computer-implemented method of claim 1 for enabling zero-knowledge proof or verification of a statement (S), in which a prover computer system proves to a verifier computer system that the statement is true while keeping evidence (w) for the statement secret, the method comprising: The prover computer system then sends to the verifier computer system: 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 said 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 a This allows the verifier computer system to determine that the circuit is satisfied and to compute the elliptic curve point (P) to verify the statement, and thus determine that the prover computer system possesses the evidence (w) for the statement. Computer-implemented method.

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

6. The commitment W ｉ Is W ｉ =Com(w ｉ , r ｉ ) and Com is a commitment to the function circuit, w ｉ is the wire value, r ｉ is a random number that is different for each wire commitment, i is the wire type, Com(w, r) = w × G + r × F, F and G are elliptic curve points, 5. The computer-implemented method of claim 4.

7. 5. The computer-implemented method of claim 4, wherein the prover computer system sends a batch of wire commitments and generates a random number for computing an elliptic curve point for each wire to form the proof key (PrK).

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

9. 10. The computer-implemented method of claim 1, wherein the prover computer system further sends a fully open commitment to at least one wire of the function circuit.

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

11. 2. The computer-implemented method of claim 1, wherein the function circuit implements a hash function, preferably a SHA-256 hash function.

12. 10. A computer-readable storage medium having computer-executable instructions thereon, the computer-executable instructions, when executed, configuring a processor to perform the method of claim 1.

13. 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 claim 1; An electronics device having:

14. A node of a blockchain network, the node being configured to perform the method of claim 1.

15. A blockchain network comprising the nodes of claim 14.

Images