Computer-based methods and systems for knowledge proofs in blockchain transactions

Abstract

To provide a method of enabling knowledge proof in a blockchain transaction.SOLUTION: A method comprises sending, from a verifier to a prover, a blockchain transaction redeemable by means of data including: (i) first data (y) based on a combination of an ephemeral key (r), second data (c) and a private key of a public-private key pair of a cryptography system, where the public key (ν) is based on an integer generator raised to a first power, where the first power is based on the private key, and where knowledge of the private key is required in order to determine the ephemeral key from the first data; and (ii) third data (x) based on the integer generator raised to a second power, where the second power is based on the ephemeral key.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] This disclosure generally relates to knowledge proof systems for blockchain transactions, and more particularly to on-chain non-interactive implementations of knowledge proof systems. This disclosure is not limited to, but is particularly suitable for use in signature schemes for any data authentication. [Background technology]

[0002] In this specification, we use the term “blockchain” to encompass 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. While other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Bitcoin may be referenced herein for convenience and illustrative purposes, but it should be noted that this disclosure is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are also included in the scope of this disclosure. The term “user” here may refer to a human or a processor-based resource.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized system, composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset among participants in the blockchain system, and it contains at least one input and at least one output. Each block contains the hash of the previous block, and these blocks are concatenated together to produce a permanent, immutable record of all transactions written to the blockchain since its origin. A transaction contains a small program known as a script. The script embeds its inputs and outputs and specifies how and by whom the transaction's output is accessible. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be verified. Network nodes (miners) perform tasks to ensure that invalid transactions are rejected from the network and that each transaction is valid. Software clients installed on the nodes perform this verification on unspent transactions (UTXOs) by executing lock and unlock scripts for the UTXOs. If the execution of the lock and unlock scripts evaluates to TRUE, the transaction is valid and written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must (i) be verified by the first node that receives the transaction, and if the transaction is valid, the node relays the transaction to other nodes in the network, (ii) be added to a new block built by miners, and (iii) be mined, that is, added to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in cryptocurrency implementations, digital entrepreneurs are beginning to develop uses for both Bitcoin's underlying cryptographic security system and data that can be stored on the blockchain to implement new systems. Blockchain would be highly advantageous if it could be used for automated tasks and processes not limited to the cryptocurrency domain. Such solutions could diversify their applications while leveraging the benefits of blockchain (e.g., permanence, tamper resistance to event recording, decentralized processing, etc.).

[0006] One area of ​​current research is the use of blockchain-based computer programs for the implementation of "smart contracts." These are computer programs designed to automate the execution of machine-readable contracts or agreement clauses. Unlike traditional contracts written in natural language, smart contracts are machine-executable programs that contain rules capable of processing inputs to produce an outcome, which in turn performs actions depending on that outcome.

[0007] Another area of ​​interest related to blockchain is the use of "tokens" (or "colored coins") to represent and transfer real-world entities via the blockchain. Potentially confidential or secret items can be represented by tokens that do not have an identifiable meaning or value. Thus, tokens function as identifiers that allow real-world items to be referenced from the blockchain.

[0008] A knowledge proof is a cryptographic system that allows one party to prove to another party that they know a secret without disclosing any information about that secret. There are many implementations of knowledge proof systems. However, most of them are computationally expensive.

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

[0010] This improved solution was devised here. [Overview of the project]

[0011] The methods set forth in the attached claims are provided.

[0012] A method for enabling knowledge proofs in blockchain transactions, wherein the method is A method may be provided that includes the step of sending a blockchain transaction redeemable by data from a verifier to a prover, the data comprising: (i) first data based on the combination of a temporary key, second data and the 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 multiplier, the first multiplier is based on the private key, and knowledge of the private key is required to determine the temporary key from the first data; and (ii) third data based on the integer generator raised to a second multiplier, where the second multiplier is based on the temporary key.

[0013] A computer-based method for determining the value obtained by raising 2 to the power of an integer multiplier, wherein the method is: A step of determining the coefficients of the terms of a power series of 2, wherein each term of the series comprises each power of 2 multiplied by the respective coefficient, each of the respective coefficients of the respective terms is 0 or 1, and the sum of the terms is equal to the integer, The step of determining that each of the coefficients has a value of 1, A step of determining the product of multiple values, wherein each of the aforementioned values ​​is obtained by raising 2 to the power of each of the respective powers of 2, corresponding to each term of the series in which the corresponding coefficient has a value of 1. A method including this may be provided.

[0014] A computer-based method for adding two integers in a blockchain transaction, wherein the method is: A step of representing the integer as a pair of binary bit sequences, A step of performing a combination step with respect to the pair of binary bit sequences as input, which includes (i) XORing the corresponding pairs of bits of the input to generate a first output binary bit sequence, and (ii) ANDing the corresponding pairs of bits of the input to generate a further bit sequence, and concatenating a bit with the value 0 as the least significant bit to the further bit sequence to generate a second output binary bit sequence. If the second output binary bit sequence contains bits with a value of 1, the concatenation step is repeated using the output of the previous concatenation step as input until a second output binary bit sequence containing only bits with a value of 0 is generated. A method including this may be provided.

[0015] A method for determining the product of two integers in a blockchain transaction, wherein the method is: The steps include representing the first and second integers as first and second binary bit sequences, A step of providing, for each bit of the first integer having a value of 1, a stored bit sequence including a bit sequence representing the second integer, and the number of bits with the value 0 added thereto as the least significant bit, wherein the number is equal to a power of 2 represented by the corresponding bits of the first integer having a value of 1. A step of adding together the stored bits by at least one of the methods described above, A method including this may be provided.

[0016] A step in determining an integer in modular calculus, wherein the method is: A step of determining the coefficients of the terms of the power series of 2 (mod p), wherein each term of the series is a power of 2 (mod p) multiplied by the respective coefficient, each of the respective coefficients of each of the terms is 0 or 1, and the sum of the terms is equal to the integer (mod p). A step of storing a plurality of values, each of the values being 2 raised to the power of each of the 2 (mod p) corresponding to each term of the series having a value with a corresponding coefficient of 1. A step of adding together the plurality of values by at least one of the methods described above. A method can be provided that includes the above.

[0017] A system can be provided that includes a processor and a memory that includes executable instructions that, as a result of execution by the processor, cause the system to execute any embodiment of the computer-implemented methods described herein.

[0018] A non-transitory computer-readable storage medium storing executable instructions, the executable instructions causing at least a computer system to execute the computer-implemented methods described herein as a result of execution by a processor of the computer system. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Various embodiments according to the present disclosure are described with reference to the drawings. [Figure 1] Shows the execution of a blockchain transaction script for performing a proof of knowledge. [Figure 2] Shows the execution of a blockchain transaction script for determining large powers of 2. [Figure 3] Shows the execution of a blockchain transaction script of a specific example of the script shown in FIG. 2. [Figure 4]This demonstrates the execution of a blockchain transaction script to determine the sum of two large integers. [Figure 5] This demonstrates the execution of a blockchain transaction script to determine the product of two large integers. [Figure 6] This demonstrates the execution of a blockchain transaction script for determining large integers in modular computing. [Figure 7] This is a schematic diagram showing a computing environment in which various embodiments can be implemented. [Modes for carrying out the invention]

[0020] The knowledge proof system described herein is an implementation of Schnorr's identification scheme [CP Schnorr (1990). 'Efficient Identification and Signatures for Cards' in G. Brassard ed. Adv. In Cryptology-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 code defined in the original Bitcoin protocol. As a result, it can be easily embedded in scripts within transactions. The on-chain non-interactive implementation of the knowledge proof system is described along with two other implementations, including conversion to proof schemes for arbitrary data authentication.

[0021] The following annotations and usage examples in this disclosure should be noted. Knowledge proof systems can be embedded in just one transaction if the public verification key is available elsewhere. Furthermore, payment is only possible if the recipient knows the secret value. In particular, the public key (verification key) does not need to be publicly visible or included in the transaction. This provides complete privacy protection for the recipient. Security can also be adjusted by selecting different prime numbers. This provides flexibility in the trade-off between efficiency and security.

[0022] When proof of knowledge means proof of ownership, the solution would be a smart contract that indicates that funds are released only if the recipient can prove ownership of a certain asset. As an example, a land registry office could implement the same proof of knowledge system to record ownership of property. The land registry office could have a list of authenticated verification keys, each given their corresponding secret value. To prove ownership of property, the owner could easily construct a proof of knowledge if given a challenge. Importantly, it should be noted that the verification key does not need to be included in the transaction; it can be hidden during computation.

[0023] Another example could be any token system that implements a knowledge proof system. Similarly, as mentioned above, ownership of several tokens can be proven by constructing a knowledge proof of a secret value. The solution can also be used in rental services where the key to unlocking the rented property is a knowledge proof that can be obtained by initiating a transaction that includes the same challenge. For example, to access a rented car or house, the lender receives a challenge to provide a knowledge proof from a locked door. The borrower then constructs a transaction that includes the challenge. The owner of the property discloses a knowledge proof when accepting payment, and therefore discloses the knowledge proof needed to unlock the door to the car or house.

[0024] This disclosure could also be a solution for asset transfer, including involving third parties. For example, a lawyer (a third party) might be instructed, at their client's request, to release funds only to individuals who know the secret value.

[0025] Before outlining specific embodiments of this disclosure, Schnorr's identification scheme is disclosed here [CP Schnorr (1990). 'Efficient Identification and Signatures for Cards' in G. Brassard ed. Adv. In Cryptology-Crypt 239-252. Springer Verlag (1990) Lecture Notes in Computer Science nr 435].

number

[0026] Regarding public parameters, they present the following subgroups of order q of the multiplicative group:

number

[0027] The condition is that the following equation must have 2 as a subgroup generator:

number

[0028] This significantly improves the efficiency of exponentiation.

[0029] The security of the scheme is based on the discrete logarithm problem. For a group of size N, the security is approximately √N. For example, if q is 256 bits, the security of the scheme is approximately 128 bits. In other words, it takes approximately 2 bits for an attacker to infiltrate the system. 128 It requires several calculations.

[0030] For reference, the signature scheme obtained by the Fiat-Shamir Transform is represented as follows:

number

[0031] It should be noted that the main difference between knowledge proofs and signature schemes is that challenge c is replaced by the following:

number

[0032] Knowledge proofs in transactions Non-interactive transactions A transaction from Bob to Alice is described. In this case, Alice can only use the payment if she provides a proof of knowledge.

[0033] Bob assumes he has a copy of the public parameters (p,q), and Alice's proof key ν, either from Alice herself or from a verifiable source.

[0034] Bob can simply construct a transaction and include the following output:

number

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

[0036] To use the payment, Alice simply calculates x and y as instructed by the protocol and constructs a transaction with the unlock script as follows:

number

[0037] To verify the transaction, the script is executed as shown in Figure 1.

number

[0038] It should be noted that, ν c Mod p can be pre-calculated and included in the script. This not only saves computation time for in-script verification but also hides the public verification key.

[0039] To protect the integrity of the transaction output generated by Alice, the ECDSA signature requires an ID attached to the lock script within Bob's transaction.

number

[0040] In response, when Alice uses the transaction, she signs the new transaction with her ECDSA signature.

number

[0041] If y is a large number, 2 y To calculate modulo p, a more complex script involving bitwise calculations is required. Implementation would be possible if the current upper limit on the maximum number of opcodes were significantly increased. The script is shown in detail in Figure 2.

[0042] It was assumed that the arithmetic opcodes used would have a large integer library. This was the case with the original Bitcoin protocol. However, Figures 4-6 show other embodiments that simulate large integer arithmetic operations using string operations.

[0043] 2 y Calculate mod p:

[0044] The script shown in Figure 2 is executed by performing the following steps:

number

[0045] Here, the top of the stack is 2 y It has modulo p.

[0046] It should be noted that the current maximum stack depth is 1000. If 128 bits of security are to be achieved, then y will be 256 bits. Therefore, the current upper limit on stack depth is not an issue.

[0047] An example of executing the script shown in Figure 2 is illustrated in detail in Figure 3.

[0048] Example: 2 12 Calculate modulo 31.

number

[0049] The script in Figure 2 is then executed as shown in Figure 3.

[0050] 1-round transaction If there is a request for on-chain communication, for Alice, the direct way is to initiate communication by sending a transaction to Bob and passing on the public verification key.

number

[0051] It should be noted that Output 1 is simply there to cover the transaction fee for the miner. Output 2 can also be included in Output 1 using "<ν> OP_DROP".

[0052] The second leg of the round is the transaction described in the non-interactive case, and the challenge c embedded in the lock script. This is done using a new output via OP_RETURN, or in the existing lock script, <c>This is possible by adding "PO_DROP".

[0053] Implementation as a signature scheme The Schnorr scheme can also be used as a method for source verification of any data type, in other words, as a digital signature scheme. Currently, any digital signature scheme involving large integer powers is avoided in Bitcoin due to its significant computational cost. Since high-cost powers can be pre-calculated off-chain, the aforementioned Schnorr signature scheme can be implemented within a Bitcoin script. A key technical difference between knowledge proofs and digital signatures is that in digital signatures, the challenge issued by the verifier is the hash of the message or data and temporary public key used in the signature (see above).

[0054] The difficulty here is that Bob does not know the temporary public key before signing. One way to overcome this is for the signer to send the temporary public key before Bob generates the transaction. A better way might be to have a set of temporary public keys shared between the signer and Bob.

[0055] For example, Bob wants to send Alice some Bitcoin. This Bitcoin can only be used by her if she provides a valid signature (x,y) on message m from a signer with a public key ν trusted by Bob. He can construct the following transaction:

number

[0056] To use the payment from Bob, Alice first obtains the signature (x,y) from the signer on message m.

[0057] Note that both x and m are fixed within the lock script by the following equation:

Number

[0058] The value of y serves as the key for providing authentication.

[0059] Alice can then construct a transaction with the following unlock script:

Number

[0060] Note that this script does not require Alice to generate a signature for m, but only provides the signature generated by a signer with the public key ν. The last four opcodes (from OP_DUP to OP_CHECKSIG) of the above lock script ensure that Alice's private key is also required to use the transaction.

[0061] The implementation of the signature scheme does not provide the same level of privacy protection as the knowledge proof system implementation because the challenge c must be included in the lock script together with ν c mod p. It is not computationally difficult to derive ν from c and ν c mod p.

[0062] The signed message must also be known to the verifier who provides both of the following within the lock script:

Number

[0063] On the other hand, this limits the implementation's ability to provide a method for validating uncertain data, and when the message space is small, the verifier can use flow control opcodes for the Schnorr scheme, which first determines the message and then authenticates it.

[0064] For example, Bob generates a transaction that requests authorization from a third party (Carol) if Alice wishes to use it. In this case, the signed message is a Boolean value. That is,

number

[0065] Bob doesn't know which message is included as part of the unlock script, but he wants to verify that it is signed by Carol, who has the public key ν. If the message from Carol is "Yes", Alice can use it; if it's "No", it is returned to Bob.

[0066] The challenges corresponding to m1 and m2 are as follows:

number

[0067] Bob generates the following lock script:

number

[0068] The lock script first checks that the message is either m1 or m2, verifies that it is signed by Carol, and finally checks that the authorized user will unlock the transaction.

[0069] For example, if the message Carol wants to sign has m1 = "Yes", she can generate a signature (x,y) corresponding to her chosen message and send the message / signature to Alice. Alice can then generate the following unlock script to use the transaction:

number

[0070] Calculation of x + y Figure 4 shows in detail a script for adding two large integers together. Assume the integers (x,y) are pushed onto the stack as two binary strings. This script is denoted as FUNC_STRINGADD in a further embodiment.

[0071] The theory behind addition Let a0 and b0 be two binary strings of length t. Define the following:

number

[0072] The process is to create a string of 0, b k When the condition = 00...0 is repeated a sufficient number of times, a k This is a binary string representing a0 + b0.

[0073] Proof: It should be noted that XOR simulates bitwise addition in the sense that it does not take into account all carries.

number

[0074] The only problem is that 1+1 is not 0. However, the ∧ operator can be used to identify this scenario, as it flags the result with a 1, indicating where this problem occurred. It should be noted that these 1s in the result represent the carry, which is the part of the addition. By concatenating the result with 0, we efficiently generate a number that captures all the carries. This process can be repeated until there are no more carries in the addition.

[0075] Proof by induction: We want to prove the following equation:

number

number

[0076] As shown in Table 1 below, a 00 and b 00 By going through all possible values ​​of t, we can conclude that the statement is true for t=1. Table 1 [Table 1]

[0077] Assume that the statement is true for some k≧1 t=k. We want to prove that the statement is true for t=k+1.

number

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

number

[0079] Furthermore, the following facts are used:

number

[0080] Multiplication by 2 is equivalent to shifting the bit string one position to the left and then adding a zero at the end.

[0081] The final equation of the inference is again derived from Table 1 above.

[0082] If the statement is true for t=k, then it has been proven to be true for t=k+1, so by induction we can conclude the following:

number

[0083] It should be noted that a1 and b1 are just two binary strings representing two numbers as a0 and b0. Without loss of generality, by repeating the above proof, we can conclude the following:

number

[0084] Therefore, when the process is repeated until one of the outputs consists entirely of bits with the value 0, it can be concluded that the other output represents the sum of the two initial inputs.

[0085] Calculation of x·y: Figure 5 shows in detail a script for multiplying two large integers together.

[0086] One of the integers, y, is written as follows:

number

[0087] Assume that y is pushed onto the stack as follows:

number

[0088] Here, y0 is at the top of the stack.

[0089] The script then appends the value of another integer x as the least significant bit to y. i The values ​​are stored along with the number of zero bits corresponding to the powers of 2 represented by each non-zero value. These values ​​are then added together by the FUNC_STRINGADD process described above, referring to Figure 4.

[0090] Calculation of y mod p: Figure 6 shows in detail a script for calculating large integers in modular calculus. The following values ​​are first pre-calculated for i=k-1,...,t, where k is the bit length of p:

number

[0091] Assume that y is pushed onto the stack as follows:

number

[0092] Here, y t It is at the top of the stack.

[0093] Finally, FUNC_SPLITSTRINGTOBIT is defined to take a binary string input and place each bit vertically onto the stack. This can be achieved using OP_SUBSTR.

[0094] <Conclusion> A protocol implementation was described that would allow payments from Bob to Alice, usable only if Alice knew the secret value. The advantages of this disclosure lie in its simplicity, security, usefulness, and compatibility with the original Bitcoin protocol, which is the most secure and reliable.

[0095] The choice to use integer representation instead of elliptic curve representation makes implementation and understanding far simpler. The fact that only the public key for the power of a random number needs to be made public provides security in terms of recipient privacy protection. Furthermore, the values ​​can be pre-calculated to enable on-chain verification and save computation.

[0096] A novel and efficient implementation of powers modulo prime numbers was also described. This allows the knowledge proof system to be embedded in scripts within standard transactions that can be accepted by miners on the Bitcoin network. As a byproduct, an implementation of a signature scheme is also provided, enabling arbitrary data authentication and verification within the script. Furthermore, the signature scheme is applied to all standard properties and extensions of Schnorr. For example, batch verification enables verification of multiple signatures in a single step by first aggregating them. Another example is the extension to threshold signatures, an alternative to MULTISIG in Bitcoin.

[0097] Referring to Figure 7, a simplified block diagram is provided for describing a computing device 2600 that may be used to carry out at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 may be used to implement any of the illustrated systems described above. For example, the computing device 2600 may be configured to be used as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in Figure 7, the computing device 2600 may include one or more processors having one or more levels of cache memory and memory control units (collectively labeled 2602) that can be configured to communicate with a storage subsystem 2606 which includes a main memory 2608 and a permanent storage device 2610. The main memory 2608 may include, as shown, a dynamic random access memory (DRAM) 2618 and a read-only memory (ROM) 2620. The storage subsystem 2606 and the cache memory 2602 may be used for storing information such as transaction and block-related details as described in the present disclosure. The processor 2602 may be used to provide any step or function of any embodiment described herein.

[0098] The processor 2602 can also communicate with one or more user interface input devices 2612, one or more user interface output devices 2614, and the network interface subsystem 2616.

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

[0100] The network interface subsystem 2616 may provide interfaces to other computing devices and networks. In some embodiments, the network interface subsystem 2616 may function as an interface for receiving data from and sending data to other systems of the computing device 2600. For example, the network interface subsystem 2616 allows data technicians to connect the device to a network. As a result, data technicians can send data to and receive data from the device even if they are in a remote location such as a data center.

[0101] The user interface input device 2612 may include one or more user input devices, such as a keyboard, integrated mouse, trackball, touchpad, or graphics tablet; a scanner, barcode scanner, touchscreen integrated into a display; a voice recognition system; an audio input device such as a microphone; and other types of input devices. Generally, 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.

[0102] 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 include a planar display such as a cathode ray tube (CRT), liquid crystal display (LCD), light-emitting diode (LED) display, or projection, or other display device. Generally, the use of the term “output device” is intended to include all possible types of devices and mechanisms that output information from the computing device 2600. One or more user interface output devices 2614 may be used, for example, to present a user interface and facilitate user interaction with an application that performs the processes and variations described herein, when such interaction is appropriate.

[0103] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data structures that provide functionality for at least one embodiment of the Disclosure. Applications (e.g., programs, code modules, instructions), when executed by one or more processors, may provide functionality for one or more embodiments of the Disclosure and be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 further provides a repository for storing data used in accordance with the Disclosure. For example, main memory 2608 and cache memory 2602 may provide volatile storage for programs and data. Permanent storage devices 2610 may provide permanent (non-volatile) storage for programs and data and may include magnetic hard disk drives, one or more floppy disk drives associated with removable media, one or more optical drives (e.g., CD-ROM, or DVD, or Blu-ray) associated with removable media, and other similar storage media. Such programs and data may include programs for performing steps of one or more embodiments described in the Disclosure, and data associated with transactions and blocks described in the Disclosure.

[0104] The computing device 2600 may be of various types, including a portable computer, a tablet computer, a workstation, or any other device described later. Furthermore, the computing device 2600 may include another device that can be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). The device that can be connected to the computing device 2600 may include multiple ports configured to receive optical fiber connectors. Thus, this device may be configured to convert optical signals into electrical signals transmitted to the computing device 2600 through ports to which the device is connected for processing. Due to the constantly changing characteristics of computers and networks, the description of the computing device 2600 shown in Figure 7 is intended only as a specific example for the purpose of illustrating a preferred embodiment of the device. Many other configurations are possible with more or fewer components than the system shown in Figure 7.

[0105] <Examples of listed embodiments> Examples of embodiments of this disclosure can be described in terms of the following sections.

[0106] [Item 1] A method for enabling knowledge proofs in blockchain transactions, wherein the method is A method comprising the steps of sending a blockchain transaction redeemable by data from a verifier to a prover, the data comprising: (i) first data based on the combination of a temporary key, second data and the 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 multiplier, the first multiplier is based on the private key, and knowledge of the private key is required to determine the temporary key from the first data; and (ii) third data based on the integer generator raised to a second multiplier, the second multiplier is based on the temporary key.

[0107] By providing blockchain transactions redeemable with data based on a cryptographic system where the public key is based on an integer generator raised to a first multiplier, and the first multiplier is based on the private key, this offers the advantage of being computationally simple and efficient, and therefore not as computationally expensive as other cryptographic systems such as elliptic curve cryptography. By including in the data required to redeem the transaction a temporary key, a second data set and the private key of a public-private key pair, the knowledge of which is required to determine the temporary key from the first data set, and a third data set based on an integer generator raised to a second multiplier, where the second multiplier is based on the temporary key, this offers the advantage of allowing verification that the first data set contains the private key without disclosing the private key. By determining the second data set, this indicates that the parties constituting the first and third data sets must possess the private key.

[0108] [Item 2] The method according to item 1, wherein the integer generator is 2.

[0109] This offers the advantage of greater computational efficiency.

[0110] [Item 3] The second data is selected by the verifier using the method described in Item 1 or 2.

[0111] This offers the advantage of ensuring that the party constituting the first data possesses the private key.

[0112] [Clause 4] The method according to any one of Clauses 1 to 3, further comprising the step of transmitting the second data from the verifier to the certifier, separately from the blockchain transaction.

[0113] This offers the benefit of improved privacy protection.

[0114] [Item 5] The first data above is in the form of the following equation:

number

[0115] [Item 6] The second data is based on the message and is provided in any one of items 1 to 5.

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

[0117] [Item 8] The second data above is in the form of the following equation:

number

[0118] [Clause 9] The method according to any one of Clauses 6 to 8, further comprising the step of receiving the message at the verifier.

[0119] [Clause 10] The method according to any one of Clauses 1 to 9, further comprising the step of sharing at least one temporary key between the verifier and the prover.

[0120] [Clause 11] The method according to any one of Clauses 1 to 10, further comprising the step of receiving the public key at the verifier.

[0121] [Clause 12] The method according to any one of Clauses 1 to 11, further comprising the step of the verifier receiving the first data and the second data.

[0122] [Item 13] A computer-based method for determining the value obtained by raising 2 to an integer multiplier, the method being: A step of determining the coefficients of the terms of a power series of 2, wherein each term of the series comprises each power of 2 multiplied by the respective coefficient, each of the respective coefficients of the respective terms is 0 or 1, and the sum of the terms is equal to the integer, The step of determining that each of the coefficients has a value of 1, A step of determining the product of multiple values, wherein each of the aforementioned values ​​is obtained by raising 2 to the power of each of the respective powers of 2, corresponding to each term of the series in which the corresponding coefficient has a value of 1. A method that includes this.

[0123] This offers the advantage of being computationally efficient by allowing coefficients to be represented by binary bit sequences.

[0124] [Clause 14] The method described in Clause 13, wherein the value is calculated and stored in advance.

[0125] [Clause 15] The method described above is the method described in Clause 13 or 14, which is carried out by a blockchain transaction.

[0126] [Clause 16] The method described above is 2 y The method described in any one of terms 13 to 15, wherein the value of modulo p is determined and y is the aforementioned integer.

[0127] [Clause 17] The method described in any one of Clauses 13 to 16, which is used to provide a blockchain transaction in the method described in any one of Clauses 1 to 12.

[0128] [Item 18] A computer-based method for adding two integers in a blockchain transaction, the method being: A step of representing the integer as a pair of binary bit sequences, A step of performing a combination step with respect to the pair of binary bit sequences as input, which includes (i) XORing the corresponding pairs of bits of the input to generate a first output binary bit sequence, and (ii) ANDing the corresponding pairs of bits of the input to generate a further bit sequence, and concatenating a bit with the value 0 as the least significant bit to the further bit sequence to generate a second output binary bit sequence. If the second output binary bit sequence contains bits with a value of 1, the concatenation step is repeated using the output of the previous concatenation step as input until a second output binary bit sequence containing only bits with a value of 0 is generated. A method that includes this.

[0129] This offers the advantage of enabling computationally efficient addition of large integers in blockchain transactions.

[0130] [Item 19] A method for determining the product of two integers in a blockchain transaction, the method being: The steps include representing the first and second integers as first and second binary bit sequences, A step of providing, for each bit of the first integer having a value of 1, a stored bit sequence including a bit sequence representing the second integer, and the number of bits with the value 0 added thereto as the least significant bit, wherein the number is equal to a power of 2 represented by the corresponding bits of the first integer having a value of 1. The step of adding together the stored bits by at least one method described in item 18, A method that includes this.

[0131] [Clause 20] A step of determining an integer in modular calculus, wherein the method is: A step of determining the coefficients of the terms in a power series of 2(mod p), wherein each term of the series is a power of 2(mod p) multiplied by the respective coefficient, each coefficient of the respective term is 0 or 1, and the sum of the terms is equal to the integer (mod p), A step of storing multiple values, wherein each of the values ​​is obtained by raising 2 to the power of each 2(mod p) corresponding to each term of the series having a coefficient of 1, The step of adding the plurality of values ​​together by at least one method described in paragraph 18, A method that includes this.

[0132] [Clause 21] A system implemented by a computer, Processor and A memory containing executable instructions that, as a result of execution by the processor, cause the system to execute any embodiment of the method performed by the computer described in any of items 1 to 20, A system that includes this.

[0133] [Clause 22] A non-temporary computer-readable storage medium storing executable instructions, wherein the executable instructions, as a result of being executed by a processor of a computer system, cause the computer system to perform at least an embodiment of the method described in any of Clauses 1 to 20.

[0134] It should be noted that the embodiments described above are illustrative, not limiting, of the disclosure, and that a person skilled in the art can devise many alternative embodiments without departing from the scope of the disclosure as defined by the appended claims. Any reference numerals in parentheses in the claims should not be considered limiting. The terms “comprising,” “comprises,” etc., do not preclude the existence of elements or steps other than those enumerated in any claim or throughout the specification. In this specification, “comprising” means “having or comprising,” and “comprising” means “comprising or comprising.” A singular reference to an element does not preclude multiple references to such element, and vice versa. The disclosure can be implemented by hardware comprising several distinct elements and by a appropriately programmed computer. In an apparatus claim enumerating several means, some of these means may be embodied by a single identical hardware item. The mere fact that certain means are described in different dependent claims does not imply that combinations of these means cannot be used advantageously.

[0135] References [1] CP Schnorr (1990). 'Efficient Identification and Signatures for Cards' in G. Brassard ed. Adv. In Cryptology-Crypt 239-252. Springer verlag (1990) lecture notes in Computer Science nr 435.< / c>

Claims

1. A method that enables knowledge proofs within blockchain transactions, The process includes the step of sending a blockchain transaction redeemable by data containing integer powers of 2 from a verifier computer system to a certifier computer system, The powers of the above 2 are as follows: A step of determining the coefficients of the terms in a power series of 2, wherein each term in the series comprises each power of 2 multiplied by the respective coefficient, each of the coefficients in each of the terms is 0 or 1, and the sum of the terms is equal to the integer, The steps include determining that each of the coefficients has a value of 1, A step of determining the product of multiple values, wherein each of the aforementioned values ​​is obtained by raising 2 to the power of each respective power of 2, corresponding to each term of the series in which the corresponding coefficient has a value of 1. A method determined by [the specified method].

2. The method according to claim 1, wherein the aforementioned value is calculated and stored in advance.

3. The method according to claim 1, wherein the method is carried out by a blockchain transaction.

4. The above method determines the value of the following equation, 2 y towards The method according to claim 1, wherein y is the integer.

5. The aforementioned data is (i) First data based on the combination of a temporary key, second data, and the private key of a public-private key pair of a cryptographic system, wherein the public key is based on 2 raised to the power of a first power, the first power of which is based on the private key, and knowledge of the private key is required to determine the temporary key from the first data, and (ii) A third data based on 2 raised to the power of the second square, wherein the second square is based on the temporary key and the third data, The method according to claim 1, including the method described in claim 1.

6. A verifier computer system comprising a processor configured to perform the method described in any one of claims 1 to 5.

7. A non-temporary computer-readable storage medium storing executable instructions that cause a processor of a verifier computer system to execute the method according to any one of claims 1 to 5.

Images