TW202312055A - Non-interactive approval system for blockchain wallet and method thereof - Google Patents

Abstract

A non-interactive approval system for blockchain wallet and method thereof is disclosed. By generating a signature metadata jointly by a user host and at least one node host, and then transmitting the signature metadata to an aggregator host, so that the aggregator host can providing the signature metadata to the online user host for executing partial decryption to generate a partial decryption message, and transmitting the partial decryption message to the aggregator host. When the aggregator host receives the partial decryption message that meet a decryption condition, calculating a second value of a digital signature, verifying the digital signature and broadcasting the verified digital signature to execute a transaction. The mechanism is help to improve the security of the blockchain wallet.

Description

Non-interactive approval system and method for blockchain wallet

The invention relates to an approval system and method thereof, in particular to a non-interactive approval system and method of a blockchain wallet.

In recent years, with the popularization and vigorous development of the blockchain, various technologies applied to the blockchain have sprung up like mushrooms, among which the development of the blockchain wallet has attracted the most attention.

Generally speaking, a traditional blockchain wallet is held by only one user and has a unique set of key-pairs, namely: public key and private key. If the user loses the private key, the cryptocurrency in the blockchain wallet will be stolen. Therefore, in order to enhance the security and usability of blockchain wallets, some manufacturers have further developed blockchain wallets that can be shared by multiple users, such as multi-signature blockchain wallets. This method is to generate a corresponding number of signatures through multiple different keys, and the transaction will be successful only when there are a certain number of signatures. In this way, even if one of the private keys is stolen, lost, etc., it can be guaranteed The security of the blockchain wallet has even greatly increased the usability of the blockchain wallet, for example, it can be easily applied in the majority decision situation. However, in this way, when the number of lost private keys meets the threshold, the blockchain wallet is no longer safe. Therefore, there is still the problem of insufficient security of blockchain wallets.

On the other hand, suppose N users are to jointly manage a blockchain wallet. When receiving a transaction message, the user can approve it according to the transaction content. After a certain number of users approve it, the transaction can be Generating and sending the signature of , it means agreeing to the transaction. In this case, there are many points that need to be considered, such as: if the blockchain wallet is hosted, can the custody institution transfer the user's assets by itself, or how the user can achieve non-interactive approval, etc. Taking non-interactive approval as an example, if the above-mentioned certain number of users all need to approve online simultaneously, this will greatly reduce the convenience of the blockchain wallet.

To sum up, it can be seen that the security and convenience of the blockchain wallet have long existed in the prior art. Therefore, it is necessary to propose improved technical means to solve this problem.

The invention discloses a non-interactive approval system and method for a blockchain wallet.

Firstly, the present invention discloses a non-interactive approval system for blockchain wallets, which includes: an aggregation host, a node host, and N user hosts. Wherein, the aggregating host is used to receive the transaction message and the signature metadata for verification, and after the signature metadata is verified to be correct, transmit the transaction message and the signature metadata, and receive a part of the decryption message to decrypt the part When the message satisfies the decryption condition, calculate the second signature value according to the partially decrypted message, and after verifying the digital signature including the first signature value and the second signature value, broadcast the verified digital signature; The node host is used to receive the first public key, and jointly execute the distributed key generation (Distributed Key Generation, DKG) mechanism with the dispatch host (Dealer) to generate i threshold signature scheme shared units and their corresponding second public key key, and jointly execute the Threshold Signature Scheme (TSS) with the transaction host to calculate the first signature value and i s values, and then calculate the The corresponding signature metadata is sent to the aggregation host, wherein, i is a positive integer greater than the value 1; and N user-end hosts are used as co-users of the blockchain wallet respectively, and the user-end hosts include The distribution host and the transaction host, each client host includes: a first generation module, a second generation module, a calculation module and a decryption module. Among them, the first generation module is used to select the ciphertext when the user-side host is the dispatching host, and perform linear integer secret sharing (Linear Integer Secret Sharing, LISS) together with other user-side hosts to generate homomorphically encrypted i shared unit and its corresponding first public key, and transmit the first public key to the node host and the user host, and transmit the jth shared unit to the jth user host, wherein, N, i and j are positive integers and N and i are greater than the value 1; the second generation module is connected to the first generation module, and is used to jointly execute the distributed key generation mechanism with the node host when the user-end host is the dispatching host, and Send the generated shared unit of the threshold signature scheme and its corresponding second public key to the user host; the calculation module is used to use the user host that receives the transaction message to be signed as the transaction host, and the transaction The host sends the transaction message to the aggregation host, and executes the threshold signature scheme together with the node host, and at the same time, the user host and the node host send the signature metadata generated by themselves to the aggregation host for verification; and the decryption module A group connection computing module is used to receive transaction information and signature metadata from the aggregate host for verification and partial decryption to generate corresponding partially decrypted messages, and then transmit the partially decrypted messages to the aggregate host.

Next, the present invention discloses a non-interactive approval method for blockchain wallets, the steps of which include: providing N user-side hosts as co-users of blockchain wallets, and providing node hosts and aggregation hosts, when all When the above-mentioned user-end host is the dispatching host, the dispatching host selects the ciphertext, and performs linear integer secret sharing with other user-end hosts to generate i shared units of homomorphic encryption and their corresponding first public keys, and Send the first public key to the node host and the user-end host, and send the j-th shared unit to the j-th user-end host, where N, i, and j are positive integers and N and i are greater than the value 1; assign The host and the node host jointly execute the distributed key generation mechanism to generate i shared units of the threshold signature scheme and their corresponding second public keys; the dispatching host transmits the generated second public key and shared units of the threshold signature scheme To the user-end host; when the user-end host receives the transaction message to be signed, it sends the transaction message to the aggregation host, and executes the threshold signature scheme with the node host to calculate the first signature value and i s value, and then calculate the corresponding signature metadata according to the first signature value and i said s value; both the user host and the node host send the signature metadata generated by themselves to the aggregation host for verification, when After the aggregation host verifies that it is correct, the aggregation host sends the transaction message and all received signature metadata to the connected client host for verification and partial decryption to generate a corresponding partial decryption message, and then sends the partial decryption message to the aggregation host; and when the partial decryption message received by the aggregation host meets the decryption condition, it is allowed to calculate the second signature value based on the partial decryption message without knowing the private key, and verify that the first signature value is included and the digital signature of the second signature value, and then broadcast the verified digital signature.

The system and method disclosed in the present invention are as above, and the difference from the prior art is that the present invention generates the corresponding signature metadata through the user-end host and the node host, and then sends them to the aggregate host for verification, so that the aggregate host can pass the signature metadata The data provider online client host performs partial decryption to generate a partial decrypted message, and returns the generated partial decrypted message to the aggregation host. When the partial decrypted message received by the aggregation host satisfies the decryption condition, the digital signature is first calculated The second signature value of , then verify the digital signature, and broadcast the verified digital signature to execute the transaction.

Through the above-mentioned technical means, the present invention can achieve the technical effect of improving the security and convenience of the blockchain wallet.

The implementation of the present invention will be described in detail below in conjunction with the drawings and examples, so as to fully understand and implement the implementation process of how the present invention uses technical means to solve technical problems and achieve technical effects.

First of all, before explaining the non-interactive approval system and method of the blockchain wallet disclosed in the present invention, the nouns defined by the present invention will be explained first. The sharing unit (Share) mentioned in the present invention, such as: sharing unit , threshold-type signature sharing unit, etc., refer to the elements generated by exchanging data and calculation results between different node hosts during secure multi-party computing, which can be regarded as a part of the private key, and the elements can be Without the need to reorganize the private key, the signature (or "signature") that conforms to the signature format of the Elliptic Curve Digital Signature Algorithm (ECDSA) is directly calculated by mathematical operations.

The non-interactive approval system and method of the blockchain wallet of the present invention will be further described in conjunction with the drawings below. Please refer to "Fig. 1" first. "Fig. 1" is the non-interactive approval system of the blockchain wallet of the present invention. A system block diagram of a core system, the system includes: an aggregation host 110, a node host 120, and node hosts (130a-130n). Among them, the aggregation host 110 is used to receive the transaction message and signature metadata for verification, and after the signature metadata is verified to be correct, transmit the transaction message and signature metadata, and receive a partial decryption message so that the partial decryption message meets the decryption condition , calculate the second signature value according to the partially decrypted message, and verify the digital signature including the first signature value and the second signature value, and then broadcast the verified digital signature. In actual implementation, the signature metadata includes a plurality of parameters, the parameters are the first signature value (ie: a part of the ECDSA signature), the homomorphic encryption value (ie: the ciphertext of the homomorphic encryption) , the product value (ie: points on the elliptic curve) and consistency proof (ie: the zero-knowledge proof that proves that the homomorphic encryption value and the product value are the same), when the aggregation host 110 receives the signature metadata, it uses zero-knowledge proof Verify the proof of the existence of the homomorphic encryption value, verify the consistency certificate, and verify whether the parameter range of the parameter is correct. The _homomorphic encryption value is the value "E _D (s _i )", for example, the homomorphic encryption value "E _D (s ₁ )" is the value generated by homomorphically encrypting the corresponding s value "s ₁ "; the homomorphic encryption value "E _D (s ₂ )” is the value generated by homomorphically encrypting the corresponding s value “s ₂ ”, and so on. In addition, the aggregation host 110 sums up the product value of each signature metadata (such as: "sum_i hat{si}*R = r*P + m*G") when the received partial decrypted message satisfies the decryption condition, where , the product value is a point on the elliptic curve, and the total product value is equal to the product of the first signature value "r" and the second key "P" plus the hash value of the transaction message "m" and the base point "G ", for the convenience of illustration, "hat{s _i }" will be represented by "s _i ", and the base point is the base point of the elliptic curve.

The node host 120 is used to receive the first public key, and jointly execute the DKG mechanism with the dispatch host to generate i threshold signature scheme shared units and their corresponding second public keys, and jointly execute the TSS with the transaction host to calculate the first A signature value and i s values, and then calculate the corresponding signature metadata (Metadata) based on the first signature value and the i s values to send to the aggregation host 110, where i is a positive value greater than 1 integer. In actual implementation, the number of node hosts 120 may be one or more than one.

The user-end hosts (130a~130n) are respectively used as common users of the blockchain wallet, and the user-end hosts (130a~130n) include a dispatch host and a transaction host, and each user-end host (130a~130n ) all include: a first generation module 131 , a second generation module 132 , a calculation module 133 and a decryption module 134 . Among them, the first generation module 131 is used to select the ciphertext when the user-end hosts (130a~130n) are the dispatching hosts, and execute LISS together with other user-end hosts to generate i shared units of homomorphic encryption and their Corresponding first public key, and transmitting the first public key to the node host 120 and the user-end hosts (130a~130n), and transmitting the jth shared unit to the jth user-end host, wherein, N, i and j are positive integers and N and i are greater than the value 1. Taking LISS as an example, assuming that there is a distribution host who wants to distribute the ciphertext "s" to other people for safekeeping, each custodian holds what is called a "shared unit". If there is no sufficient number of shared units, the ciphertext cannot be restored. s", when the dispatch host wants to divide the shared unit into m shares, the method is as follows:

1. The dispatching host selects a matrix "M" with a size of "m*n", and selects a vector v := [s, x ₂ ,…,x _n ] ^T , then the n shared units generated are "M * v = [s ₁ ,…,s _m ] ^T ”, where s is the selected ciphertext and “x ₂ ,…,x _n ” are all randomly selected within an appropriate interval.

2. The assigning host distributes the shared unit "s _i " to the appropriate one.

When the vector "w" can be found such that M ^T * w = [1,0,0,…,0] ^T , then calculate [s ₁ ,…,s _m ] ^T *w, and s can be restored. For example, suppose there are four users: A, B, C, and D, and assume that the following combination conditions can form a private key:

1. A, B

2. C, D

3. A, B, C

4. A, B, D

5. B, C, D

6. A, B, C, D

Corresponding to this situation, consider the matrix M as:

[1, 1, 0] ß A

[0, 1, 0] ß B

[1, 0, 1] ß C

[0, 0, 1] ß D

M*[s, x ₂ , x ₃ ] ^T = [s+x ₂ , x ₂ , s+x ₃ , x ₃ ]. Therefore, the shared units held by A, B, C, and D respectively are: "s+x ₂ ", "x ₂ ", "s+x ₃ ", and "x ₃ ". Among them, "s" is the ciphertext, and "x ₂ " and "x ₃ " are randomly selected values. In this way, it can be easily checked. Taking the combination condition of A and B as an example, the first vertical row (Column) of the following matrix is the transpose (Transpose) of the horizontal column (Row) of A, and the second The vertical rows are the transpose of B taking the horizontal columns.

[1, 0] * [1] = [1]

[1, 1] [-1] [0]

[0, 0] [0]

Among them, w = [1, -1], therefore, "w ^T *[s+x ₂ , x ₂ ] = s" can successfully restore the private key, and the other cases are the same, and it can be verified that there are "w" makes the ciphertext (ie: private key) "s" recoverable. Therefore, techniques using LISS can generate shared units that are distributed to other users. In other words, the overall process selects the ciphertext "d" for a distribution host and generates the corresponding public key "D", and then decides who can be together to generate a shared unit according to management requirements, and outputs the matrix "M", and then uses LISS Generate the corresponding shared unit "d _j ". Wherein, the private key satisfies “d = ∑ _j a _j *d _j ”, “a _j ” belongs to “{-1, 0, 1}”, and the public key is transmitted to the node host 120 . In fact, the LISS, like DKG, can cooperate with multiple people to generate the public key "D" and the shared unit "d _j " held by everyone without anyone knowing the ciphertext "d". It should be noted that when the assigning host allocates shared units, it will establish an access structure (Access Structure) to determine the user-end hosts that are allowed to restore the ciphertext to plaintext (or called decryption). The access structure may include a threshold access structure (Threshold Access Structure) and a non-threshold access structure. When the aggregation host 110 receives a condition that satisfies the decipherable partial decryption message, it can start to decrypt to calculate the digital signature. The second part, namely: the second signature value "s". In fact, an access structure will determine the conditions under which decryption is allowed this time (that is, as long as part of the decrypted information meeting the conditions is collected, decryption can be performed).

The second generation module 132 is connected to the first generation module 131 to execute the DKG mechanism together with the node host 120 when the user hosts (130a~130n) are dispatching hosts, and share the generated threshold signature scheme The units and their corresponding second public keys are sent to the user hosts (130a~130n). In actual implementation, the DKG mechanism involves the participation of the user and the node host managed by the custodian organization. Without generating the private key, all parties can obtain the public key and the shared unit. Participating users can use the network-connected smart phones, computers and other devices as user hosts (130a~130n), or run a node host 120, if the shared unit is stored in the smart phone, each time a new user joins, it will get same shared unit. In addition, the two parties can also determine the ownership of responsibility through the weight.

The calculation module 133 is used to use the user hosts (130a~130n) that receive the transaction messages to be signed as transaction hosts, the transaction hosts transmit the transaction information to the aggregation host 110, and execute the TSS together with the node host 120, At the same time, both the user hosts ( 130 a - 130 n ) and the node host 120 transmit the signature metadata generated by themselves to the aggregation host 110 for verification.

The decryption module 134 is connected to the computing module 133 for receiving the transaction message and signature metadata from the aggregation host 110 for verification and partial decryption to generate a corresponding partial decryption message, and then sending the partial decryption message to the aggregation host 110 . In actual implementation, the " _si " contained in the homomorphic encryption value " _ED (s _i )" can be verified through signature metadata, and without knowing " _si ", it can be verified through mathematical zero-knowledge proof It is believed that the contained information is a signature of the transaction message "m".

In particular, it should be noted that in actual implementation, the modules described in the present invention can be implemented in various ways, including software, hardware or any combination thereof. For example, in some implementations, each module can use software and hardware or one of them. In addition, the present invention can also be realized partially or completely based on hardware. For example, one or more modules in the system can be implemented through integrated circuit chips, system Single chip (System on Chip, SoC), complex programmable logic device (Complex Programmable Logic Device, CPLD), field programmable logic gate array (Field Programmable Gate Array, FPGA) and so on. The present invention can be a system, method and/or computer program. The computer program may include a computer-readable storage medium loaded with computer-readable program instructions for causing a processor to implement various aspects of the present invention, the computer-readable storage medium may be a tangible and equipment. A computer readable storage medium may be, but is not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (non-exhaustive list) of computer-readable storage media include hard disks, random access memory, read-only memory, flash memory, optical disks, floppy disks, and any suitable combination of the foregoing. As used herein, computer-readable storage media are not to be construed as transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (for example, light signals through fiber optic cables), or transmitted electrical signals. Additionally, the computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to various computing/processing devices, or downloaded over a network, such as the Internet, local area network, wide area network, and/or wireless network to an external computer device or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, hubs and/or gateways. The network card or network interface in each computing/processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in computer-readable storage media in each computing/processing device middle. The computer program instructions for performing the operations of the present invention may be assembly language instructions, instruction set architecture instructions, machine instructions, machine-related instructions, micro instructions, firmware instructions, or source code or object code written in any combination of one or more programming languages (Object Code), the programming language includes object-oriented programming languages, such as: Common Lisp, Python, C++, Objective-C, Smalltalk, Delphi, Java, Swift, C#, Perl, Ruby and PHP, etc., as well as conventional programs Procedural programming language, such as: C language or similar programming language. The computer program instructions may be executed entirely on the computer, partly on the computer, as a stand-alone piece of software, partly on the client computer and partly on the remote computer, or entirely on the remote computer or server to execute.

Please refer to "Figure 2A" and "Figure 2B". "Figure 2A" and "Figure 2B" are the method flow chart of the non-interactive approval method of the blockchain wallet of the present invention. The steps include: providing N Each user-end host is used as a common user of the blockchain wallet, and provides a node host and an aggregation host. When the user-end host is a dispatching host, the dispatching host selects the ciphertext and communicates with other user-end hosts Jointly perform linear integer secret sharing to generate i shared units of homomorphic encryption and their corresponding first public keys, and transmit the first public key to the node host and the user host, and transmit the jth shared unit to the j user hosts, wherein N, i and j are positive integers and N and i are greater than the value 1 (step 201); the distribution host sends the generated first public key to the node host 120, so that the node host 120 and the distribution The hosts jointly execute the distributed key generation mechanism to generate i shared units of the threshold signature scheme and their corresponding second public keys (step 202); Send to the user-end host (step 203); when the user-end host receives the transaction message to be signed, it sends the transaction message to the aggregation host, and executes the threshold signature scheme together with the node host to calculate the first signature value and i s values, and then calculate the corresponding signature metadata according to the first signature value and the i s values (step 204); both the user end host and the node host will generate the signature metadata Send it to the aggregation host 110 for verification. When the aggregation host 110 verifies that it is correct, the aggregation host 110 sends the transaction message and all received signature metadata to the connected user-side host for verification and partial decryption to generate the corresponding Partially decrypt the message, and then send the partially decrypted message to the aggregation host 110 (step 205); when the partial decryption message received by the aggregation host 110 satisfies the decryption condition, it is allowed to calculate according to the partial decryption message without knowing the private key After obtaining the second signature value and verifying the digital signature including the first signature value and the second signature value, broadcast the verified digital signature (step 206). Through the above steps, the corresponding signature metadata can be jointly generated by the user host and the node host, and then sent to the aggregation host for verification, so that the aggregation host can provide the signature metadata to the online user host to perform partial decryption to generate Partially decrypt the message, and return the generated part of the decrypted message to the aggregation host. When the partial decryption message received by the aggregation host meets the decryption conditions, first calculate the second signature value of the digital signature, and then verify the digital signature. and broadcast a verified digital signature to execute the transaction.

The following description will be made in the form of an embodiment in conjunction with "Figure 3A" to "Figure 3K". "Figure 3A" to "Figure 3J" are examples of the non-interactive approval process of the blockchain wallet applying the present invention. schematic diagram. First, as shown in "Figure 3A", suppose there are two users (i.e. N is 2) who jointly hold the blockchain wallet through the user-end host 330a and the user-end host 330b respectively. If the user-end host 330a is the dispatcher host (namely: Dealer role), the user host 330a will select a ciphertext (or called secret), and use the LISS method to generate two shared units of homomorphic encryption with the user host 330b , such as: the first shared unit “share d ₁ ” and the second shared unit “share d ₂ ”, and the first public key “D” corresponding to these two shared units, then, as in “Figure 3B” As shown, the user host 330a holds the first shared unit and the first public key, the user host 330b holds the second shared unit and the first public key, and transmits the first public key to the node host 320 . Next, as shown in "Fig. 3C", the dispatching host (namely: in this example, the user-end host 330a) and the node host 320 jointly execute the DKG mechanism to generate i threshold signature scheme shared units "s _{sign, i} ” and its corresponding second public key “P”, wherein, the node host 320 holds the first shared unit “s _sign,1 ” of the threshold signature scheme, and the dispatch host holds the second threshold signature scheme Shared unit "s _sign,2 ". Then, as shown in "FIG. 3D", the distribution host sends the generated second public key "P" and the second shared unit "s _sign,2 " of the threshold signature scheme to the client host 330b.

As shown in "Fig. 3E", when the client host 330a has a transaction that needs to be signed, for example: receiving the transaction message "m" to be signed, the client host 330a will send the transaction message "m" to Aggregation host 310 . At the same time, the user host 330a and the node host 320 will jointly execute the TSS to calculate the first signature value and i s values (ie: s _i ), and then calculate the corresponding The signature metadata of , wherein the signature metadata contains multiple parameters, the parameters are the first signature value, homomorphic encryption value " _ED (s _i )", product value "s _i *R" and consistency Prove "C(E _D (s _i ), s _i *R)". In this example, the node host 320 calculates the first signature metadata as "(r, E _D (s ₁ ), s ₁ *R, C(E _D (s ₁ ), s ₁ *R))" , the client host 330a calculates the second signature metadata as "(r, E _D (s ₂ ), s ₂ *R, C(E _D (s ₂ ), s ₂ *R))". Next, as shown in "Fig. 3F", both the client host 330a and the node host 320 transmit the signature metadata generated by themselves to the aggregating host 310 for verification. ”, the aggregation host 310 will send the transaction message “m” and all received signature metadata, such as: the first signature metadata “(r, E _D (s ₁ ), s ₁ *R, C( E _D (s ₁ ), s ₁ *R))” and the second signature metadata “(r, E _D (s ₂ ), s ₂ *R, C(E _D (s ₂ ), s ₂ *R ))” and sent to the connected client host (such as: client host 330a) for verification and partial decryption, so as to generate corresponding partial decryption messages as shown in “Figure 3H”, for example: 1st Partially decrypted message "E _{partial, 1} (s)", and then send the first partially decrypted message "E _{partial, 1} (s)" to the aggregation host 310, wherein, "s := s ₁ + s ₂ " . In particular, when other user-end hosts (such as: user-end host 330b) go online, the aggregation host 310 will also send the transaction message "m" and all signature metadata as shown in "Figure 3I" In this example, the aggregator host 310 sends the transaction message "m", the first signature metadata "(r, E _D (s ₁ ), s ₁ *R, C(E _D (s ₁ ), s ₁ *R))” and the second signature metadata “(r, E _D (s ₂ ), s ₂ *R, C(E _D (s ₂ ), s ₂ *R))” together Send it to the online client host 330b for verification and partial decryption, so as to generate the second partial decryption message "E _{partial, 2} (s)" as shown in "Fig. 3J" and send it back to the aggregation host 310. In fact, the jth online client host will perform the following steps:

1. Verify the proof of the existence of E _D (s _i ).

2. Verify the consistency proof "C(E _D (s _i ), s _i *R)".

3. Verify that the ranges for each parameter are correct.

4. Calculate "∑ _i s _i * R = r * P + m * G", where "m" is the hash value of the transaction message.

」，此處的「(

」與「∑ _iE _D(s _i)」相等，並且生成「

」和「

」的一致性證明。 5. Execute the approval calculation: "E _partial,j (s) := (

", where "(

” is equal to “∑ _i E _D (s _i )” and generates “

"and"

"Consistency proof.

」和「

」的一致性證明。 6. Return the generated partial decryption message "E _partial,j (s)" and "

"and"

"Consistency proof.

Finally, as shown in "Figure 3K", when the partially decrypted message received by the aggregating host 310 satisfies the decryption condition (for example: there are enough and decipherable partially decrypted messages), it is allowed without knowing the private key, according to the Partially decrypt the message to calculate the second signature value (ie: the s value in the digital signature (r, s)), and verify the digital signature including the first signature value and the second signature value, and then broadcast the Verified digital signature. So far, since the blockchain wallet can calculate the digital signature that complies with the ECDSA specification without knowing the private key, the security is greatly improved, and the user can go online asynchronously for approval, and go offline after approval. There is no need to maintain continuous interaction during the transaction process, so it is more convenient.

To sum up, it can be seen that the difference between the present invention and the prior art lies in that the corresponding signature metadata is jointly generated by the user-end host and the node host, and then sent to the aggregation host for verification, so that the aggregation host can provide the signature metadata online The user-end host performs partial decryption to generate a partial decrypted message, and returns the generated partial decrypted message to the aggregation host. When the partial decrypted message received by the aggregation host meets the decryption conditions, it first calculates the second value of the digital signature. Signature value, re-verify the digital signature, and broadcast the verified digital signature to execute the transaction. With this technical means, the problems existing in the previous technology can be solved, and the security and convenience of the blockchain wallet can be improved. The technical effect.

Although the present invention is disclosed above with the aforementioned embodiments, it is not intended to limit the present invention. Any person familiar with similar skills may make some changes and modifications without departing from the spirit and scope of the present invention. Therefore, the present invention The scope of patent protection shall be subject to what is defined in the scope of patent application attached to this specification.

110: aggregation host 120: node host 130a~130n: user host 131: The first generation module 132:Second Generation Module 133: Calculation module 134: Decryption module 310: aggregation host 320: node host 330a, 330b: user host Step 201: Provide N user-end hosts as co-users of a blockchain wallet, and provide at least one node host and an aggregation host. When the user-end host is a dispatch host (Dealer), the The assigning host selects a ciphertext, and performs a linear integer secret sharing (Linear Integer Secret Sharing, LISS) together with other said user end hosts to generate i shared units of homomorphic encryption and a corresponding first public key , and transmit the first public key to the node host and the user host, and transmit the jth shared unit to the jth user host, wherein N, i and j are Positive integer and N and i are greater than the value 1 Step 202: The assigning host and the node host jointly execute a distributed key generation (Distributed Key Generation, DKG) mechanism to generate i shared units of the threshold signature scheme and a corresponding second public key Step 203: The assigning host sends the generated second public key and the sharing unit of the threshold signature scheme to the user host Step 204: After the user host receives a transaction message to be signed, it sends the transaction message to the aggregation host, and executes a threshold signature scheme together with the node host to calculate a first A signature value and i s values, and then calculate a corresponding signature metadata based on the first signature value and i said s values Step 205: Both the user end host and the node host transmit the signature metadata generated by themselves to the aggregate host for verification, and when the aggregate host verifies that it is correct, the aggregate host sends the transaction message and all received The received signature metadata is sent to the connected client host for verification and partial decryption to generate a corresponding partial decryption message, and then the partial decryption message is sent to the aggregation host Step 206: When the part of the decrypted message received by the aggregation host satisfies a decryption condition, it is allowed to calculate a second signature value based on the part of the decrypted message without knowing the private key, and verify that the part contains the first signature value. After a signature value and a digital signature of the second signature value, broadcast the verified digital signature

Figure 1 is a system block diagram of the non-interactive approval system of the blockchain wallet of the present invention. FIG. 2A and FIG. 2B are flow charts of the method of the non-interactive approval system of the blockchain wallet of the present invention. FIG. 3A to FIG. 3K are schematic diagrams of the non-interactive approval process of the blockchain wallet applying the present invention.

110: aggregation host

120: node host

130a~130n: user host

131: The first generation module

132:Second Generation Module

133: Calculation module

134: Decryption module

Claims (10)

A non-interactive approval system for blockchain wallets, the system includes: An aggregation host, configured to receive a transaction message and a plurality of signature metadata for verification, and after the signature metadata is verified to be correct, transmit the transaction message and the signature metadata, and receive a plurality of partially decrypted messages for When the partially decrypted message satisfies a decryption condition, calculating a second signature value according to the partially decrypted message, and after verifying a digital signature including a first signature value and the second signature value, Rebroadcast the digital signature that has been verified; At least one node host, used to receive a first public key, and jointly execute a distributed key generation (Distributed Key Generation, DKG) mechanism with a distribution host (Dealer) to generate i shared units of the threshold signature scheme and Its corresponding second public key, and jointly execute a threshold signature scheme with a transaction host to calculate the first signature value and i s values, and then according to the first signature value and i The s value calculates the corresponding signature metadata to be sent to the aggregation host, wherein, i is a positive integer greater than the value 1; and N user-end hosts are used as co-users of a blockchain wallet respectively, the user-end hosts include the dispatch host and the transaction host, and each of the user-end hosts includes: A first generation module, used to select a ciphertext when the user-end host is the dispatching host, and perform a linear integer secret sharing (Linear Integer Secret Sharing, LISS) with other said user-end hosts To generate i shared units of homomorphic encryption and the corresponding first public key, and transmit the first public key to the node host and the user host, and transmit the jth shared unit To the jth user-side host, wherein N, i and j are positive integers and N and i are greater than the value 1; A second generation module, connected to the first generation module, used to jointly execute the distributed key generation mechanism with the node host when the user-end host is the dispatching host, and generate all The threshold signature scheme sharing unit and the corresponding second public key are transmitted to the user host; A calculation module, used to use the user-side host that receives a transaction message to be signed as the transaction host, the transaction host sends the transaction message to the aggregation host, and executes together with the node host The threshold signature scheme enables both the user host and the node host to transmit the signature metadata generated by themselves to the aggregation host for verification; and A decryption module, connected to the computing module, used to receive the transaction message and the signature metadata from the aggregation host for verification and partial decryption to generate the corresponding partial decryption message, and then transmit the partial decryption message to the aggregation host. The non-interactive approval system of blockchain wallet as in claim 1, wherein the signature metadata includes a plurality of parameters, and the parameters are respectively the first signature value, a homomorphic encryption value, a product value and a Consistency proof, when the aggregation host receives the signature metadata, use zero-knowledge proof to respectively verify the proof of the existence of the homomorphic encryption value, verify the consistency proof and verify whether the parameter range of the parameter is correct. The non-interactive approval system of blockchain wallet as claimed in claim 2, wherein the aggregating host sums up the product value of each signature metadata when the received partial decryption message satisfies the decryption condition, wherein, The product value is a point on the elliptic curve, and the sum of the product value is equal to the product of the first signature value and the second key plus the product of the hash value of the transaction message and a base point. As in the non-interactive approval system of the blockchain wallet of Claim 2, wherein the homomorphically encrypted value is a value generated by homomorphically encrypting the corresponding s value. The non-interactive approval system of the blockchain wallet as claimed in claim 1, wherein the dispatching host establishes an access structure (Access Structure) to decide to allow the use of restoring the ciphertext to plaintext when dispatching the shared unit For an end host, the access structure includes a threshold access structure (Threshold Access Structure) and a non-threshold access structure to determine the decryption condition. A non-interactive approval method for a blockchain wallet, the steps of which include: Provide N user-end hosts as co-users of a blockchain wallet, and provide at least one node host and an aggregation host. When the user-end host is a dealer, the dealer chooses a ciphertext, and jointly execute a linear integer secret sharing (Linear Integer Secret Sharing, LISS) with other said user end hosts to generate i shared units of homomorphic encryption and a corresponding first public key, and The first public key is sent to the node host and the user host, and the jth shared unit is sent to the jth user host, wherein N, i and j are positive integers and N and i are greater than the value 1; The dispatching host and the node host jointly execute a distributed key generation (Distributed Key Generation, DKG) mechanism to generate i shared units of the threshold signature scheme and a corresponding second public key; The assigning host sends the generated second public key and the sharing unit of the threshold signature scheme to the user host; When the user host receives a transaction message to be signed, it sends the transaction message to the aggregation host, and executes a threshold signature scheme with the node host to calculate a first signature value and i s values, and then calculate a corresponding signature metadata according to the first signature value and i said s values; Both the user host and the node host transmit the signature metadata generated by themselves to the aggregating host for verification. After the aggregating host verifies that it is correct, the aggregating host sends the transaction message and all received The signature metadata is sent to the connected client host for verification and partial decryption to generate a corresponding partial decryption message, and then the partial decryption message is sent to the aggregation host; and When the part of the decrypted message received by the aggregation host satisfies a decryption condition, it is allowed to calculate a second signature value based on the part of the decrypted message without knowing the private key, and verify that the first signature is included value and a digital signature of the second signature value, and then broadcast the verified digital signature. The non-interactive approval method of blockchain wallet as in claim item 6, wherein the signature metadata includes a plurality of parameters, and the parameters are respectively the first signature value, a homomorphic encryption value, a product value and a Consistency proof, when the aggregation host receives the signature metadata, use zero-knowledge proof to respectively verify the proof of the existence of the homomorphic encryption value, verify the consistency proof and verify whether the parameter range of the parameter is correct. A non-interactive approval method for a blockchain wallet as in claim 7, wherein the aggregation host sums up the product value of each signature metadata when the received partial decryption message satisfies the decryption condition, wherein, The product value is a point on the elliptic curve, and the sum of the product value is equal to the product of the first signature value and the second key plus the product of the hash value of the transaction message and a base point. A non-interactive approval method for a blockchain wallet as in Claim 7, wherein the homomorphic encryption value is a value generated by homomorphically encrypting the corresponding s value. The non-interactive approval method of the blockchain wallet as claimed in claim 6, wherein the assigning host establishes an access structure (Access Structure) to determine the use of allowing the ciphertext to be restored to plaintext when assigning the shared unit For an end host, the access structure includes a threshold access structure (Threshold Access Structure) and a non-threshold access structure to determine the decryption condition.

Images