Computer-implemented methods and systems for knowledge proof in blockchain transactions

Abstract

A method of enabling proof of knowledge in a blockchain transaction is disclosed. The method comprises sending, from a prover to a verifier, a blockchain transaction redeemable with data comprising: (i) first data (y) based on a combination of a temporary key (r), second data (c) and a private key of a public-private key pair of a cryptographic system, wherein a public key (v) is based on taking a first power of an integer generator, wherein the first power is based on the private key, and wherein knowledge of the private key is required in order to determine the temporary key from the first data, and (ii) third data (x) based on taking a second power of the integer generator, wherein the second power is based on the temporary key.

Description

Technical Field

[0001] The present disclosure relates generally to a knowledge proof system for blockchain transactions, and more particularly to an on-chain non-interactive implementation of a knowledge proof system. The present disclosure is particularly suitable for, but not limited to, use in a signature scheme for arbitrary data authentication. Background Art

[0002] In this document, we use the term "blockchain" to include all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. Although other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Although Bitcoin may be mentioned herein for convenience and illustrative purposes, it should be noted that the present disclosure is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols fall within the scope of the present disclosure. The term "user" herein may refer to a human or a processor-based resource.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, computer-based distributed system composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block, so blocks are linked together to create a permanent, unchangeable record of all transactions written to the blockchain since its inception. Transactions contain small programs called scripts embedded in their inputs and outputs that specify how and by whom the transaction's outputs can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] In order for a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected by the network. The software client installed on the node performs this validation work on unspent transaction outputs (UTXOs) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to true, the transaction is valid and written to the blockchain. Therefore, in order for a transaction to be written to the blockchain, it must: i) be validated by the first node that receives the transaction – if the transaction is validated, the node relays it to other nodes in the network; ii) be added to a new block created by a miner; and iii) be mined, that is, added to the public ledger of past transactions.

[0005] While blockchain technology is best known for its cryptocurrency implementation, digital entrepreneurs have begun exploring new systems that leverage the cryptographic security underlying Bitcoin and the data stored on the blockchain. It would be particularly advantageous if blockchain could be used to automate tasks and processes beyond the cryptocurrency realm. Such solutions would leverage the benefits of blockchain (e.g., permanent, tamper-proof records of events, distributed processing, etc.) while offering greater versatility in its applications.

[0006] One area of ​​current research is using blockchain to implement “smart contracts.” These are computer programs designed to automatically execute the terms of a machine-readable contract or agreement. Unlike conventional contracts, which would be written in a natural language, smart contracts are machine-executable programs that include rules that can process inputs to produce results, which can then cause actions to be performed based on those results.

[0007] Another area related to blockchain is the use of "tokens" (or "colored coins") to represent and transfer real-world entities via the blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. Tokens thus serve as identifiers that allow real-world items to be referenced from the blockchain.

[0008] A proof of knowledge is a cryptographic system that allows one party to prove to another that they know a secret without revealing any information about the secret. Many examples of proof of knowledge systems exist. However, most of them are computationally expensive.

[0009] Therefore, it is desirable to provide a knowledge proof system for blockchain transactions that is computationally more efficient than existing knowledge proof systems.

[0010] Such an improved solution has now been devised. Summary of the Invention

[0011] There is provided a method as defined in the accompanying claims.

[0012] A method for implementing proof of knowledge in a blockchain transaction can be provided, the method comprising: sending a blockchain transaction redeemable by means of data from a verifier to a prover, the data comprising: (i) first data based on a combination of a temporary key, second data, and a private key of a public-private key pair of a cryptographic system, wherein the public key is based on an integer generator raised to a first power, wherein the first power is based on the private key, and wherein knowledge of the private key is required in order to determine the temporary key from the first data, and (ii) third data based on the integer generator raised to a second power, wherein the second power is based on the temporary key.

[0013] There may be provided a computer-implemented method of determining a value of an integer power of two, the method comprising: determining coefficients of a series of terms that are powers of two, wherein each term of the series comprises a respective power of two multiplied by a respective said coefficient, wherein the respective said coefficient of each said term is either 0 or 1, and wherein the sum of said terms is equal to said integer; and

[0014] determining said coefficients to have corresponding values ​​of 1;

[0015] A product of a plurality of values ​​is determined, wherein each said value is 2 raised to a respective power of 2 corresponding to each term of said series, the corresponding said coefficient of each term having a value of 1.

[0016] A computer-implemented method for adding two integers in a blockchain transaction may be provided, the method comprising:

[0017] Represent integers as pairs of binary bit strings;

[0018] performing a combining step on the pair of binary bit strings as input, the combining step comprising: (i) performing an exclusive-OR combination on pairs of corresponding bits of the input to generate a first output binary bit string, and (ii) performing an AND combination on pairs of corresponding bits of the input to generate another bit string and concatenating a bit having a value of 0 as the least significant bit to the another bit string to generate a second output binary bit string; and

[0019] If the second output binary bit string contains any bit with a value of 1, the combining step is repeated using the output of the previous combining step as input until a second output binary bit string containing only bits with a value of 0 is generated.

[0020] A method for determining the product of two integers in a blockchain transaction may be provided, the method comprising:

[0021] representing a first integer and a second integer as respective first and second binary bit strings; and providing, for each bit of the first integer having a value of 1, a respective stored bit string comprising a bit string representing the second integer and a number of bits having a value of 0 added to the respective stored bit string as least significant bits, the number of bits having a value of 0 being equal to the power of 2 represented by the corresponding bit of the first integer having a value of 1; and

[0022] The stored bit strings are added together by means of at least one method as defined above.

[0023] A method for determining an integer in modular arithmetic may be provided, the method comprising:

[0024] determining coefficients of a series of terms that are powers of two (mod p), wherein each term of the series comprises a respective power of two (mod p) multiplied by a respective said coefficient, wherein the respective said coefficient of each said term is either 0 or 1, and wherein the sum of said terms is equal to said integer (mod p);

[0025] storing a plurality of values, wherein each said value is 2 raised to a respective power of 2 (modp) corresponding to each term of the series, the corresponding said coefficient of each term having a value of 1; and

[0026] A plurality of values ​​are added together by means of at least one method as defined above.

[0027] A system may be provided comprising:

[0028] processor; and

[0029] A memory comprising executable instructions that, upon execution by the processor, cause the system to perform any embodiment of the computer-implemented method described herein.

[0030] A non-transitory computer-readable storage medium having executable instructions stored thereon may be provided, the executable instructions causing the computer system, upon execution by a processor of the computer system, to perform at least embodiments of the computer-implemented methods described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Various embodiments according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0032] Figure 1 The execution of a blockchain transaction script is shown for proof of knowledge.

[0033] Figure 2 The execution of a blockchain transaction script is shown to determine a large power of 2;

[0034] Figure 3 Shown Figure 2 Execution of a blockchain transaction script for a specific example of a script shown;

[0035] Figure 4 The execution of a script of a blockchain transaction is shown to determine the sum of two large integers;

[0036] Figure 5 shows the execution of a script of a blockchain transaction to determine the product of two large integers;

[0037] Figure 6 Execution of a script of a blockchain transaction is shown to determine a large integer in modular arithmetic; and

[0038] Figure 7is a diagram illustrating a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION

[0039] The knowledge proof system disclosed herein is an implementation of the Schnorr identification scheme [CPS Schnorr (1990), Adv. In Cryptology 'Efficient Identification and Signatures for Cards', ed. G. Brassard, Crypt 239-252, Springer-Verlag (1990) Lecture Notes in Computer Science nr 435]. This scheme is not only conceptually simple but also uses only the OP codes defined in the original Bitcoin protocol. Therefore, it can be easily embedded in transaction scripts. An on-chain, non-interactive implementation of the knowledge proof system is described, along with two other implementations, including a conversion to a signature scheme for arbitrary data authentication.

[0040] The following comments and use cases of this disclosure should be noted. If the public verification key is available elsewhere, the knowledge proof system can be embedded in at least one transaction. Furthermore, the payment can only be spent if the recipient knows the secret value. In particular, the public key (verification key) does not need to be visible to the public or included in the transaction. This provides complete privacy for the recipient. Furthermore, security can be adjusted by choosing different prime numbers. This provides flexibility in the trade-off between efficiency and security.

[0041] When proof of knowledge implies proof of ownership, the scheme becomes a smart contract, stating that funds will only be released if the recipient can prove ownership of certain assets. For example, a land registry could implement the same proof of knowledge system to record property ownership. The land registry could maintain a list of certified verification keys, with each owner assigned a corresponding secret value. To prove ownership of the property, the owner could simply construct a proof of knowledge when challenged. It's important to note that the verification key doesn't have to be included in the transaction; it can be hidden within the computation.

[0042] Another example could be any token system that implements a proof-of-knowledge system. Similarly, as above, ownership of certain tokens can be proven by constructing a proof-of-knowledge of a secret value. This scheme could also be used for rental services, where the key used to unlock the rented property is a proof-of-knowledge that can be obtained by initiating a transaction containing the same challenge. For example, to use a rented car or house, the renter would receive a challenge requiring proof-of-knowledge from a locked door. The renter would then construct a transaction containing the challenge. The property owner, upon accepting payment, would reveal the proof-of-knowledge, and thus the proof-of-knowledge required to unlock the car or house door.

[0043] The present disclosure may also be a solution for asset transfer involving a third party. For example, a lawyer (third party) is instructed by the client's wishes to only release funds to people who know the secret value.

[0044] Before outlining the specific embodiments of the present disclosure, the original protocol of Schnorr is disclosed here [CP Schnorr (1990), Adv. In Cryptology 'Efficient Identification and Signatures for Cards' edited by G. Brassard, Crypt 239-252, Springer Verlag (1990) Lecture Notes in Computer Science nr 435].

[0045] Settings (Public):

[0046] 1. Select a prime number p

[0047] 2. Choose a prime number q such that q|p-1 (i.e., p-1 is divisible by q), and

[0048] 2 q ≡1mod p

[0049] The common parameters are (p, q)

[0050] KeyGen (prover):

[0051] 1. Random selection

[0052] 2. Calculate v≡2 -s mod p

[0053] The secret value is s, and the public verification key is v

[0054] 3. Send v to the verifier

[0055] Challenge (verification party):

[0056] 1. Random selection

[0057] 2. Send c to the prover

[0058] Certification (certifying party):

[0059] 1. Random selection

[0060] 2. Calculate x≡2 r mod p

[0061] 3. Calculate y≡r+s·c mod q

[0062] 4. Send (x, y) to the verifier

[0063] Verification (verification party):

[0064] 1. Calculate x′≡2 y ·v c mod p

[0065] 2. Compare x′ with x

[0066] For common parameters, they represent the multiplicative group q-order subgroup of . 2 q The condition for ≡1 mod p is to use 2 as a subgroup generator. This significantly improves the efficiency of exponentiation.

[0067] The security of this scheme is based on the discrete logarithm problem. For a group of size N, the security is approximately For example, if q is 256 bits, the security of the scheme is about 128 bits. That is, the attacker spends about 2 128 This operation can damage the system.

[0068] For reference, the signature scheme obtained via the Fiat-Shamir transform is also presented below:

[0069] Settings (Public):

[0070] 1. Select a prime number p

[0071] 2. Select a prime number q such that q|p-1 and 2 q ≡1mod p

[0072] KeyGen (signing party):

[0073] 1. Random selection

[0074] 2. Calculate v≡2 -s mod p

[0075] The secret key is s and the public key is v

[0076] Signature (the signatory gives the message m):

[0077] 1. Random selection

[0078] 2. Calculate x≡2 r mod p

[0079] 3. Calculate c≡H(x||m)mod q

[0080] 4. Calculate y≡r+s·cmodp

[0081] 5. Send (m, x, y) to the verifier

[0082] Verification (verification party):

[0083] 1. Calculate c≡H(x||m)mod q

[0084] 2. Calculate x′≡2 y ·v c mod p

[0085] 3. Compare x′ with x

[0086] It is important to note that the main difference between proof of knowledge and signature schemes is that the challenge c is replaced by H(x||m) mod q.

[0087] Proof of Knowledge in Transactions

[0088] Non-interactive transactions

[0089] Describes a transaction from Bob to Alice, where Alice can spend the payment only if she provides proof of knowledge.

[0090] Assume that Bob has a copy of the public parameters (p, q) and Alice's verification key v, either from Alice herself or from a verifiable source.

[0091] Bob can simply construct the transaction and include the following outputs:

[0092] Transaction 1 - from Bob to Alice:

[0093] Output 1:

[0094] Value: 10.00000000

[0095] Locking Script: " <2> OP_SWAP OP_LSHIFT <v c mod p>OP_MULOP_MOD OP_NUMEQUAL"

[0096] Assume v c mod p is calculated by Bob off-block, and the value entry is arbitrary. To achieve perfect privacy, Bob sends the challenge c to Alice off-chain, or they have some shared randomness as the challenge.

[0097] In order for Alice to spend the payment, she simply calculates x and y as instructed by the protocol and constructs a transaction with the unlocking script as follows:

[0098] Spend Transaction 1

[0099] Unlock script: "<Alice’s public key> <x> <y>”

[0100] To verify the transaction, execute the script such as Figure 1 As shown:

[0101] implement:

[0102] " <x> <y><2> OP_SWAP OP_LSHIFT <v c mod p>OP_MUL< / y> < / x> < / y> < / x> OP_MOD OP_NUMEQUAL"

[0103] It should be noted that v c mod p can be pre-computed and placed in the script. This not only saves computation for implementing verification within the script, but also hides the public verification key.

[0104] To protect the integrity of the output of the transaction created by Alice, the ECDSA signature request id is appended to the locking script in Bob's transaction. That is:

[0105] Locking script: " <2> OP_SWAP OP_LSHIFT <v c mod p>OP_MUL OP_MOD OP_NUMEQUALOP_IF OP_DUP OP_HASH160<Hash of Alice’s public key> OP_EQUALVERITY OP_CHECKSIG".

[0106] In response, when Alice spends the transaction, she will sign a new transaction using her ECDSA signature. That is:

[0107] Unlock script: "<Alice’s signature><Alice’s public key> <x> <y>”

[0108] In the case of a large number, a more complex script is needed to calculate 2 y mod p, which involves bitwise calculations. This implementation would be possible if the current upper limit on the maximum number of opcodes were significantly increased. The script is in Figure 2 Shown in detail.

[0109] It has been assumed that the arithmetic opcodes used are equipped with a large integer library, which is the case in the original Bitcoin protocol. Figures 4 to 6 Other embodiments of using string operations to simulate large integer arithmetic operations are shown in detail in .

[0110] Calculation 2 y mod p:

[0111] Figure 2 The script shown in is executed by implementing the following steps:

[0112] 1. Write y=y02 0 +y12 1 +…+y t 2 t , where for i=0,1,...,t,y i ∈{0, 1}, which is the binary representation of y.

[0113] 2. Make is pre-calculated.

[0114] 3. Please note that when y i =1, and

[0115] 4. Assume that y is taken as (y0, y1, ..., y t ) onto the stack, with y0 at the top of the stack:

[0116] Now the top of the stack will have 2 y mod p.

[0117] It should be noted that the current maximum stack depth is 1000. If 128 bits of security were to be achieved, then y would be 256 bits. Therefore, the current upper limit on the stack depth is not a problem.

[0118] Figure 2 An example of the execution of the script shown in Figure 3 Shown in detail.

[0119] Example: Calculation 2 12 mod 31

[0120] 1. Write 12 = 2 2 +2 3

[0121] 2. Precompute n0, n1, n2, n3 as 2, 4, 16, 8.

[0122] 3. Push (1, 1, 0, 0) onto the stack, followed by OP_1.

[0123] Then execute the script Figure 2 as shown in Figure 3 .

[0124] A round of transactions

[0125] If on-chain communication is required, Alice initiates the communication directly by sending a transaction to Bob and passing the public verification key.

[0126] Transaction 0 - from Alice to Bob:

[0127] Output 1:

[0128] Value: 0.00000600

[0129] Locking script: "OP_DUP OP_HASH160<Hash of Bob’s public key>OP_EQUALVERIFYOP_CHECKSIG”

[0130] Output 2:

[0131] Value: 0.00000000

[0132] Locking script: "OP_RETURNv”

[0133] It should be noted that output 1 here is just to cover the miner’s transaction fee. It is also possible to use <v>OP_DROP" includes output 2 in output 1.

[0134] The second round of this round will be the transaction described in the non-interactive case plus the challenge c embedded in the locking script. This can be done using a new output with OP_RETURN or by adding " <c>OP_DROP” is added to the existing locking script to complete.

[0135] As an implementation of a signature scheme

[0136] The Schnorr scheme can also be used as a method of source verification for arbitrary data types, in other words, a digital signature scheme. So far, any digital signature scheme involving large integer exponentiation has been avoided in Bitcoin due to the high computational cost of large integer exponentiation. The Schnorr signature scheme described above can be implemented in the Bitcoin script since the costly exponentiation operation can be pre-computed off-chain. An important technical difference between a knowledge proof and a digital signature is that for a digital signature, the challenge issued by the verifier is the hash of the message or data used in the signature and the ephemeral public key (see above).

[0137] The difficulty here is that Bob does not know the ephemeral public key before any signature. One way to overcome this difficulty is to have the signer send the ephemeral public key before Bob creates the transaction. A better way is to have a shared set of ephemeral public keys between the signer and Bob.

[0138] For example, Bob wants to send some Bitcoin to Alice, and only Alice can spend the Bitcoin if Alice provides a valid signature (x, y) of the message m by a signer with public key v that Bob trusts. Bob can construct the following transaction:

[0139] Transaction 1 - from Bob to Alice:

[0140] Output 0:

[0141] Value: 10.00000000

[0142] Locking script: <x>OP_SWAP OP_CAT OP_HASH256 <q>OP_MOD <c>OP_EQUALVERIFY <2> OP_SWAP OP_LSHIFT <v c mod p>OP_MUL< / c> < / q> < / x> < / c> < / v> < / y> < / x> OP_MOD OP_NUMEQUAL OP_DUP OP_HASH160<Hashof Alice’s public key> OP_EQUALVERIFY OP_CHECKSIG"

[0143] Assume v c mod p is calculated off-chain by Bob.

[0144] To spend the payment from Bob, Alice first obtains a signature (x, y) on the message m from the signing party.

[0145] It should be noted that both x and m are fixed in the locking script by the equation c≡H(x||m) mod q. The value of y becomes the key that provides authenticity.

[0146] Alice can then construct a transaction with the following unlocking script:

[0147] Spend Transaction 1

[0148] Unlock script:<Alice’s signature><Alice’s public key> <x> <y> <m>

[0149] Note that this script does not require Alice to create a signature for m, only a signature created by a signing party with public key v. The last four opcodes of the locking script listed above (from OP_DUP to OP_CHECKSIG) ensure that Alice's private key is also required to spend the transaction.

[0150] Signature scheme implementations do not provide the same level of privacy as knowledge proof system implementations because the challenge c must be consistent with v c mod p is included in the locking script together. From c and v c It is not computationally difficult to derive v mod p.

[0151] The verifier must also know the message being signed. The verifier provides c(≡H(x||m) mod q) and v in the locking script. c While this limits the ability of implementations to provide methods for verifying undetermined data, if the message space is small, the verifier can use flow control opcodes to first determine the message and then determine the Schnorr scheme for authentication.

[0152] For example, if Alice wishes to spend a transaction, Bob creates a transaction that requires approval from a third party (Carol). In this case, the message being signed is a Boolean value, i.e., m∈{m1,m2}, where m1='yes' and m2='no'. Bob does not know which message will be included as part of the unlocking script, but wants to verify that it has been signed by Carol, who has public key v. If the message from Carol is 'yes', Alice can spend it; if it is 'no', it is returned to Bob.

[0153] The corresponding challenges for m1 and m2 are c1=H(x1||m1) and c2=H(x2||m2). Bob creates the following locking script:

[0154] Transaction 2 - from Bob to Alice:

[0155] Output 0:

[0156] Value: 10.00000000

[0157] Locking script:

[0158] " <x1>OP_SWAP OP_CAT OP_HASH256 <q>UP_MOD <c1>OP_EQUAL OP_IF <2> OP_SWAPOP_LSHIFT OP_MUL < / q> < / m> < / y> < / x> OP_MOD OP_NUMEQUAL OP_DUP OP_HASH160<Hash ofAlice’s public key> OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF

[0159] <x2>OP_SWAP OP_CAT OP_HASH256 <q>UP_MOD <c2>OP_EQUAL OP_IF <2> OP_SWAP OP_LSHIFT OP_MUL < / q> OP_MOD OP_NUMEQUAL OP_DUP OP_HASH160<Hash ofBob’s public key> OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF”

[0160] The locking script first checks whether the message is m1 or m2 and verifies that it has been signed by Carol, and finally checks whether a legitimate spender is unlocking the transaction. For example, if the message Carol wishes to sign is m1 = 'yes', she can generate a signature (x1, y1) corresponding to her chosen message and send that message / signature to Alice. Alice can then create the following unlocking script to spend the transaction:

[0161] Spend Transaction 2

[0162] Unlock script:<AliceSig.> <alicepubkey> <x1> <y1> <m1>

[0163] This data scheme lays the foundation for secure data origin verification using Bitcoin Script. If Bob wishes to attach additional spending criteria that depend on the message / data (for example, in a smart contract), then the additional script can be included in Transaction 2.

[0164] Calculate x+y:

[0165] The script for adding two large integers together is in Figure 4 Assume that the integers (x, y) are pushed onto the stack as two binary strings. In other embodiments, this script will be represented as FUNC_STRINGADD.

[0166] The theory behind addition

[0167] Let a0 and b0 be two binary strings of length t. We define:

[0168]

[0169] b i+1 =a i ∧b i ||0

[0170] in, represents a bitwise exclusive-or operation, and ∧ represents a bitwise and operation.

[0171] When this process is repeated enough times so that b k =00...0 is a string of zeros, then a k is a binary string representing a0+b0.

[0172] prove:

[0173] It should be noted that XOR simulates bitwise addition in the sense that all carries are not taken into account.

[0174]

[0175]

[0176]

[0177] The only problem is that 1+1 is not 0. However, this can be identified using the ∧ operator, which marks the position where the problem occurred with a 1. Note that these digits in the result represent carries that occurred as part of the addition. By concatenating the result with 0, we effectively create a number that captures all carries. This process can be iterated until there are no more carries in the addition.

[0178] Proof by induction:

[0179] What we want to prove is that for all n≥1, a0+b0=a1+b1=…=a n +b n .

[0180] First, we want to prove that a0+b0=a1+b1.

[0181] For some integer t, let a0=a 00 ...a 0t-1 and b0 = b 00 b 01 ...b 0t-1 .

[0182] When t = 1, we make a0 = a 00 and b0 = b 00 . Therefore, the left side is just a 00 +b 00 .

[0183] On the right is

[0184]

[0185] By carefully examining the a 00 and b 00 For all possible values ​​of , we can conclude that for t = 1, the statement is true.

[0186]

[0187] Table 1

[0188] Suppose that this statement is true for t = k for some k ≥ 1. We want to prove that it is true for t = k + 1.

[0189]

[0190]

[0191] It should be noted that the fact that the statement is true for t=k has been used. That is:

[0192]

[0193] Moreover, the following facts have been used:

[0194] a 0i ∧b 0i ·2=a 0i ∧b 0i || 0. Multiplying by 2 is the same as shifting the bit string left by one position and appending a 0 to the end.

[0195] The last equation in the derivation comes again from Table 1 above.

[0196] Now that we have proved that the statement is true for t = k + 1 under the condition that it is true for t = k, we can conclude by induction that for all integers t ≥ 1, a0 + b0 = a1 + b1 is true.

[0197] It should be noted that a1 and b1 simply represent two binary strings with two numbers a0 and b0. Without loss of generality, by repeating the above proof, we can conclude that for all n≥1, a0+b0=a1+b1=…=a n +b n Therefore, when we iterate this process until one of the outputs consists entirely of bits with value 0, we can conclude that the other output represents the sum of the two initial inputs.

[0198] Calculate x·y:

[0199] The script for multiplying two large integers together is in Figure 5 Shown in detail.

[0200] Where an integer y is written as y=y02 0 +y12 1 +…+y t 2 t , where for i=0,1,...,t,y i ∈{0,1}. Assume that y is (y0, y1, ..., y t ) is pushed onto the stack, with y0 at the top of the stack.

[0201] The script then saves the value of another integer x, where the number of bits with the value 0 added as the least significant bits corresponds to the number of bits added by y. i Each non-zero value of represents a power of 2. These values ​​are then referred to above Figure 4 The FUNC_STRINGADD procedures described add each other.

[0202] Calculate y mod p:

[0203] Scripts for computing large integers in modular arithmetic are available in Figure 6 First, for i=k-1, ..., t, the value r is pre-calculated. i ≡2 i mod p, where k is the bit length of p. Assume that y is (y0, y1, ..., y t ) is pushed onto the stack, where y t At the top of the stack.

[0204] Finally, define FUNC_SPLITSTRINGTOBIT to take a binary string as input and place each bit vertically on the stack. This can be achieved by using OP_SUBSTR.

[0205] in conclusion

[0206] A protocol implementation has been described that enables a payment from Bob to Alice to be spent only if Alice knows a secret value. The advantages of this disclosure are that it is simple, secure, useful, and compatible with the most secure and trusted Bitcoin original protocol.

[0207] The choice of integer representation over elliptic curve representation makes it easier to implement and understand. The fact that only the public key of the power of the random number needs to be disclosed provides security in terms of the privacy of the recipient. In addition, this value can be pre-computed to enable on-chain verification and save computation.

[0208] We have also described an innovative and efficient implementation of exponentiation modulo on prime numbers. This enables a proof-of-knowledge system to be embedded in scripts within standard transactions accepted by miners on the Bitcoin network. As a byproduct, we also provide an implementation of a signature scheme that allows authentication and verification of arbitrary data within a script. Furthermore, all standard features and extensions of the Schnorr signature scheme apply. For example, batch verification enables verification of multiple signatures in a single step by first aggregating them. Another example is the extension of threshold signatures, an alternative to MULTISIG in Bitcoin.

[0209] Now turn Figure 7 , provides an illustrative simplified block diagram of a computing device 2600 that can be used to practice at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 can be used to implement any of the systems shown and described above. For example, the computing device 2600 can be configured to function as a data server, a network server, a portable computing device, a personal computer, or any electronic computing device. Figure 7 As shown, computing device 2600 may include one or more processors (collectively referred to as 2602) with one or more levels of cache memory and a memory controller, which may be configured to communicate with a storage subsystem 2606 including a main memory 2608 and a permanent storage device 2610. As shown, main memory 2608 may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620. Storage subsystem 2606 and cache memory 2602 may be used to store information, such as details associated with transactions and blocks described in this disclosure. Processor(s) 2602 may be used to provide the steps or functionality of any embodiment described in this disclosure.

[0210] The processor(s) 2602 may also communicate with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0211] The bus subsystem 2604 may provide a mechanism for enabling the various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple busses.

[0212] The network interface subsystem 2616 can provide an interface to other computing devices and networks. The network interface subsystem 2616 can serve as an interface for receiving data from and transmitting data to other systems other than the computing device 2600. For example, the network interface subsystem 2616 can enable a data technician to connect the device to a network so that the data technician can transmit data to and receive data from the device while being located at a remote location (e.g., a data center).

[0213] The user interface input devices 2612 may include one or more user input devices, such as a keyboard; a pointing device such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touch screen incorporated into a display; an audio input device such as a voice recognition system, a microphone, or the like; and other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0214] The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as an audio output device. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projector, or other display device. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used, for example, to present a user interface to facilitate user interaction with an application that performs the described processes and variations therein, if such interaction is appropriate.

[0215] The storage subsystem 2606 can provide a computer-readable storage medium for storage of computer-readable instructions, program modules, program data, and the like that can provide functionality for at least one embodiment of the present disclosure. Applications (programs, code modules, instructions) can provide functionality for one or more embodiments of the present disclosure when executed by one or more processors 2602, and can be stored in the storage subsystem 2606. These application modules or instructions can be executed by the one or more processors 2602. Additionally, the storage subsystem 2606 can provide a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and cache memories 2602 can provide volatile storage for

[0216] The computing device 2600 can have various types of configurations, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 can include another device that can be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, lightning connector, etc.). The device that can be connected to the computing device 2600 can include a plurality of ports configured to accept fiber optic connectors. Thus, the device can be configured to convert optical signals to electrical signals that can be transmitted through the ports connecting the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of computing device 2600 depicted in Figure 7 The description of the computing device 2600 depicted in FIG. 26 is intended only as a specific example for purposes of illustrating the preferred embodiments of the device. Many other configurations having more or fewer components than the system depicted in FIG. 26 are possible. Figure 7 Many other configurations of the system depicted in FIG. 26 are possible.

[0217] Enumerated example embodiments

[0218] Examples of embodiments of the present disclosure can be described in connection with the following clauses:

[0219] 1. A method of implementing proof of knowledge in a blockchain transaction, the method comprising:

[0220] A blockchain transaction redeemable by means of data is sent from a verifier to a prover, the data comprising: (i) first data based on a combination of an ephemeral key, second data, and a private key of a public-private key pair of a cryptographic system, wherein the public key is based on a first power of an integer generator, wherein the first power is based on the private key, and wherein knowledge of the private key is required in order to determine the ephemeral key from the first data, and (ii) third data based on a second power of the integer generator, wherein the second power is based on the ephemeral key.

[0221] Providing blockchain transactions redeemable via data based on a cryptographic system in which a public key is based on an integer generator raised to a first power, where the first power is based on a private key, offers the advantages of being computationally simple and efficient, and therefore not as computationally expensive as other cryptographic systems such as elliptic curve cryptography. By ensuring that the data required for a redemption transaction includes first data based on a combination of an ephemeral key, second data, and a private key of a public-private key pair, and third data based on an integer generator raised to a second power, where knowledge of the private key is required to determine the ephemeral key from the first data, where the second power is based on the ephemeral key, offers the advantage of being able to verify that the first data contains the private key without disclosing the private key. By determining the second data, it is demonstrated that the party that constructed the first and third data must possess the private key.

[0222] 2. The method of clause 1 , wherein the integer generator is 2.

[0223] This offers the advantage of being computationally more efficient.

[0224] 3. The method according to clause 1 or 2, wherein the second data is selected by the authenticator.

[0225] This provides the advantage of ensuring that the party constructing the first data possesses the private key.

[0226] 4. The method according to any of the preceding clauses further includes: sending the second data and the blockchain transaction from the verifier to the prover respectively.

[0227] This offers the advantage of increased privacy.

[0228] 5. A method according to any of the preceding clauses, wherein the first data is in the form of:

[0229] y≡r+s·cmod q

[0230] Here, y is the first data, r is a temporary key, s is a private key, c is the second data, and q is a prime number.

[0231] 6. A method according to any of the preceding clauses, wherein the second data is based on a message.

[0232] 7. The method of clause 6, wherein the message includes data for implementing a smart contract.

[0233] 8. The method according to clause 6 or 7, wherein the second data is in the form of:

[0234] c≡H(x||m)mod q

[0235] Here, c is the second data, x is the third data, m is the message, q is a prime number, and H is a hash function.

[0236] 9. The method of any of clauses 6 to 8, further comprising: receiving the message at the authenticator.

[0237] 10. The method according to any of the preceding clauses, further comprising: sharing at least one temporary key between the verifier and the prover.

[0238] 11. The method of any preceding clause, further comprising: receiving the public key at the authenticator.

[0239] 12. The method according to any of the preceding clauses, further comprising: receiving the first data and the second data at the authenticator.

[0240] 13. A computer-implemented method of determining a value of an integer power of two, the method comprising: determining coefficients of a series of terms that are powers of two, wherein each term of the series comprises a respective power of two multiplied by a respective said coefficient, wherein the respective said coefficient of each said term is either 0 or 1, and wherein the sum of said terms is equal to said integer; and

[0241] determining said coefficients to have corresponding values ​​of 1;

[0242] A product of a plurality of values ​​is determined, wherein each said value is 2 raised to a respective power of 2 corresponding to each term of said series, the corresponding said coefficient of each term having a value of 1.

[0243] This offers the advantage of being computationally efficient by enabling the coefficients to be represented by binary bit strings.

[0244] 14. The method of clause 13, wherein the value is pre-calculated and stored.

[0245] 15. The method of clause 13 or 14, wherein the method is implemented by a blockchain transaction.

[0246] 16. A method according to any one of clauses 13 to 15, wherein the method determines 2 y mod p, where y is the integer.

[0247] 17. A method according to any one of clauses 13 to 16, wherein the method is used to provide blockchain transactions in a method as defined in any one of clauses 1 to 12.

[0248] 18. A computer-implemented method for adding two integers in a blockchain transaction, the method comprising:

[0249] Represent integers as pairs of binary bit strings;

[0250] A combining step is performed on the pair of binary bit strings as input, the combining step comprising: (i) performing exclusive-OR combination on corresponding bit pairs of the input to generate a first output binary bit string, and (ii) performing AND combination on corresponding bit pairs of the input to generate another bit string and concatenating a bit with a value of 0 as the least significant bit to the another bit string to generate a second output binary bit string; and if the second output binary bit string contains any bit with a value of 1, repeating the combining step using the output of the previous combining step as input until the second output binary bit string containing only bits with a value of 0 is generated.

[0251] This offers the advantage of being able to perform computationally efficient addition of large integers within blockchain transactions.

[0252] 19. A method for determining the product of two integers in a blockchain transaction, the method comprising: representing a first integer and a second integer as respective first and second binary bit strings; for each bit of the first integer having a value of 1, providing a respective stored bit string, the respective stored bit string comprising a bit string representing the second integer and a number of bits having a value of 0, the number of bits having a value of 0 being added to the respective stored bit string as least significant bits, the number of bits having a value of 0 being equal to a power of 2 represented by the corresponding bit of the first integer having a value of 1; and

[0253] The stored bit strings are added together by means of at least one method according to clause 18.

[0254] 20. A method of determining an integer in modular arithmetic, the method comprising:

[0255] determining coefficients of a series of terms that are powers of two (mod p), wherein each term of the series comprises a respective power of two (mod p) multiplied by a respective said coefficient, wherein the respective said coefficient of each said term is either 0 or 1, and wherein the sum of said terms is equal to said integer (mod p);

[0256] storing a plurality of values, wherein each said value is 2 raised to a respective power of 2 (mod p) corresponding to each term of said series, the corresponding said coefficient of each term having a value of 1; and

[0257] The plurality of values ​​are added together by means of at least one method according to clause 18.

[0258] 21. A computer-implemented system comprising:

[0259] processor; and

[0260] A memory comprising executable instructions that, upon execution by the processor, cause the system to perform any embodiment of the computer-implemented method of any of clauses 1 to 20.

[0261] 22. A non-transitory computer-readable storage medium having stored thereon executable instructions, the executable instructions, when executed by a processor of a computer system, causing the computer system to perform at least an embodiment of the method of any one of clauses 1 to 20.

[0262] It should be noted that the above embodiments illustrate rather than limit the present disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present disclosure as defined by the appended claims. In the claims, any figure signs in brackets should not be interpreted as limiting the claims. The words "comprising, comprise" 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, "comprise" means "include or consist of", and "comprising" means "including or consist of". The singular form of an element does not exclude the plural form of such elements, and vice versa. The present disclosure can be implemented by hardware comprising several different elements and by a suitably programmed computer. In a device claim that lists several means, several of these means may be implemented by one and the same hardware. The fact that certain means are recited in mutually different dependent claims does not mean that a combination of these means cannot be used to advantage.

[0263] References

[0264]

[0265] < / y1> < / x1> < / alicepubkey>

Claims

1. A method for implementing knowledge proof in blockchain transactions, the method comprising: A blockchain transaction redeemable by means of data is sent from a verifier to a prover, the data comprising: (i) first data based on a combination of an ephemeral key, second data, and a private key of a public-private key pair of a cryptographic system, wherein the public key is based on a first power of an integer generator, wherein the first power is based on the private key, and wherein knowledge of the private key is required in order to determine the ephemeral key from the first data; and (ii) third data based on a second power of the integer generator, wherein the second power is based on the ephemeral key.

2. The method according to claim 1, wherein The integer generator is 2.

3. The method according to claim 1 or 2, wherein: The second data is selected by the authenticator.

4. The method according to any one of the preceding claims, further comprising: The second data and the blockchain transaction are respectively sent from the verifier to the prover.

5. A method according to any one of the preceding claims, wherein The first data is in the form of: y≡r+s·cmod q Here, y is the first data, r is the temporary key, s is the private key, c is the second data, and q is a prime number.

6. A method according to any one of the preceding claims, wherein The second data is message based.

7. The method according to claim 6, wherein: The message includes data used to implement the smart contract.

8. The method according to claim 6 or 7, wherein: The second data is in the form of: c≡H(x||m)modq Here, c is the second data, x is the third data, m is the message, q is a prime number, and H is a hash function.

9. The method according to any one of claims 6 to 8, further comprising: The message is received at the authenticator.

10. The method according to any one of the preceding claims, further comprising: At least one temporary key is shared between the verifier and the prover.

11. The method according to any one of the preceding claims, further comprising: The public key is received at the authenticator.

12. The method according to any one of the preceding claims, further comprising: The first data and the second data are received at the authenticator.

13. A computer-implemented system comprising: processor; as well as A memory comprising executable instructions that, upon execution by the processor, cause the system to perform any embodiment of the computer-implemented method of any one of claims 1 to 12.

14. A non-transitory computer-readable storage medium having executable instructions stored thereon, the executable instructions, when executed by a processor of a computer system, causing the computer system to perform at least an embodiment of the method of any one of claims 1 to 12.

Images