Blockchain escrow transaction method and system for multi-party collaborative privacy protection

Abstract

The present invention relates to a blockchain escrow transaction method and system for multi-party collaborative privacy protection. The escrow transaction scheme initiates a deposit request to a escrow center through a user node, and the escrow center allocates a signature public key and identity information of a legally registered proxy signature service provider to the user node. Then, through negotiation, the service provider provides its own signature component to the user node, and aggregating signature components including the user's own signature that are not less than a threshold number can obtain a threshold signature with collaborative protection characteristics, so that the independent signature of the user node is completely hidden in the threshold signature, and the personal signature of the user node is prevented from being directly exposed to the escrow center while ensuring the signature validity verification function, so that the digital currency input address and the signer's identity cannot be associated; in addition, the escrow center isolates the user deposit transaction from the payment service fee transaction, and the deposit address of the user node is also transparent to the service provider, thereby completely realizing user anonymity.

Description

Technical Field

[0001] The present invention relates to blockchain escrow payment technology, and in particular to a blockchain escrow transaction method and system with multi-party collaborative privacy protection. Background Art

[0002] De-anonymization by constructing a transaction graph of the address chain, thereby exposing the user's real identity, has become a common means of network attack. If any link address can be mapped to a user's real identity, then all past and future transactions involving the link address can be associated with the user, thereby compromising the anonymity of honest users.

[0003] By introducing a third party to mix user transactions that meet the fixed amount conditions, the obfuscation process is completed by relying on a third-party server; CoinJoin and CoinShuffle do not require the participation of a third party, but a transaction jointly created by all participants. Only when each participant completes the independent signature of the transaction can it take effect. It is a decentralized currency mixing solution. The difference is that CoinShuffle is designed with a blame process in the transaction link, which can identify dishonest participants from failed transactions and avoid DoS attacks that are easy to generate on the CoinJoin protocol. The above currency mixing protocols all have a common privacy protection defect, that is, they need to disclose their own signatures to third parties or common participants. Attackers can track the real identity of users through aggregate analysis based on the specific input address of the same signer. In some cases, users will even directly publish their own signatures as identity features on the website for the convenience of transactions.

[0004] Another privacy protection model is that a trusted third party provides digital currency custody services. The custody center provides deposit certificates, authorizes users to pay digital currency to other trading parties, and the third-party platform provides users with guarantees not to disclose their signatures, transaction addresses, product orders and other information. Compared with the above-mentioned currency mixing technology, services such as custody wallets and custody trading platforms do not require the organization of multiple users to participate at the same time, avoiding negotiation difficulties and multiple negotiation inconsistencies, making transactions more flexible, and completely isolating the tracking of address chains. However, this service method also requires users to provide signatures that identify identity information to third-party institutions, making the server easily a target for attackers, and there is still a risk of user privacy being leaked. Summary of the invention

[0005] In order to solve the privacy protection defects of the above-mentioned various digital currency obfuscation protocols, the present invention provides a blockchain escrow transaction method and system with multi-party collaborative privacy protection. The escrow transaction of the present invention can achieve the hiding of user signature messages, complete the transaction process without destroying the overall signature validity, and the user identity is transparent to third-party service agencies and agents.

[0006] To achieve the above objectives, the present invention designs a multi-party collaborative privacy-protected blockchain escrow transaction method, which specifically includes:

[0007] The user node formulates the selection criteria for the proxy signer and anonymously sends a multi-party collaborative signature request to the hosting center;

[0008] The escrow center extracts the signature public key and identity that meet the conditions from the database, generates random parameters for the escrow transaction, and returns a list of all signature public keys, identity lists, and random parameters that can perform collaborative signatures to the user node;

[0009] The user node broadcasts a proxy signature service request containing a signature public key list and an identity list;

[0010] After confirming that the proxy signature service request contains its own signature public key and identity, the network node returns a service request acceptance message to the user node if the service is allowed to be provided. The message contains the payment address of the service provider.

[0011] The user node adds the payment addresses of all service providers and the locally selected master address to the first address list and sends it to each service provider;

[0012] After the service provider confirms that the first address list contains its own payment address, it signs the first address list with its own signature private key and sends it back to the user node;

[0013] The user node generates a signature for the first address list using the local signature private key. After verifying that all received signatures are legal, the user node sums up all signatures to obtain a threshold signature and anonymously sends an anonymous deposit request containing the threshold signature to the custody center.

[0014] After the custody center verifies the legitimacy of the threshold signature, it sends a deposit commitment to the user node, which includes the signature of the custody center on the first address list;

[0015] The user node generates a one-time random address using the master address and random parameters, and uses the one-time random address as the payment address to transfer funds to the public deposit address designated by the custody center;

[0016] The custody center generates a second address list using the addresses in the first address list and random parameters. If the second address list contains a paid one-time random address, it sends a deposit certificate to the user node and pays a service fee to the payment address designated by all service providers participating in the signature. The service fee is deducted from the transferred amount of the one-time random address.

[0017] Further preferably, the step of selecting the proxy signer is as follows: the hosting center uses a Bloom filter to store the bit vectors of all legal signature public keys, and the user node extracts the signature public key and the corresponding identity identifier that meet the requirements from the Bloom filter based on the bit vector as the proxy signer.

[0018] Further preferably, the hosting center uses the elliptic curve threshold signature algorithm to distribute a signature public and private key pair (b pk,i ,b sk,i ), where the signature private key b sk,i =f(ID i ), signature public key b pk,i =b sk,i G, ID i is the identity of network node i, f() is the signature private key generation algorithm, and G represents the base point of the elliptic curve;

[0019] Generate a random factor r based on the multi-party collaborative signature request c , further calculate the random parameter R c =r c G, and signs the signature public key list, identity list and random parameters and sends them to the user node.

[0020] Further preferably, after verifying the legality of the signature of the hosting center, the user node generates an encrypted public-private key pair locally (a pk,u ,a sk,u ), encrypt the public key a pk,u Add to the proxy signature service request and broadcast to the network after signing.

[0021] Further preferably, the step of the network node i generating the service request message is: after verifying the legality of the signature of the user node, generating a random number d i , calculate the random point value D i =d i G, with the encrypted public key a of the user node pk,u The locally selected payment address and random point value are encrypted, the generated address ciphertext is added to the acceptance service request message, and sent to the user node after signing.

[0022] Further preferably, after the user node receives the service request message, it also includes the following steps: after verifying the legality of the signature of the network node, using the encrypted private key a sk,u After decrypting the address ciphertext, the payment address and random point value of the network node are obtained. A threshold of t-1 network nodes are selected from the legal signatures as service providers to further calculate the point value. D u =d u G, remainder k t=μmodp; Generate a master public and private key address pair locally (α pk ,α sk ) and temporary public-private key address pair (β pk ,β sk ), the payment address and master public key address α of all service providers pk Add to the first address list, and the remainder k t , the first address list, the identity list of all signers and the temporary public key address β pk After signing, send it to the service provider.

[0023] Further preferably, the step of service provider i signing the first address list is: after verifying the legality of the signature of the user node, calculating the signature component σ i =(d i +hk t b sk,i Q i )modp, where j≠i, h represents the remainder k t , first address list and temporary public key address β pk The hash value of the signature component σ i Sent to the user node.

[0024] Further preferably, the user node receives the signature component σ i The next steps are: verify the signature component σ i Is it legal if we calculate σ i GD i =hk t Q i b pk,i , then it means that the signature component σ i Legal, otherwise it indicates that the signature component σ i Illegal; when confirming the signature component σ i After it is legal, further calculate the threshold signature Generate a one-time random address P locally pk =Hash(α sk R c )G+β pk , and the corresponding private key P sk =Hash(α sk R c )G+β sk ; The threshold signature σ t Added to anonymous deposit request and sent to escrow.

[0025] Further preferably, the hosting center receives the threshold signature σ t The next steps are: verify the threshold signature σ tIs it legal? Calculate σ t G-hk t B pk =(μ′,ω′),k′ t =μ′modp, if k t = k′ t This indicates that the threshold signature σ t Legal, otherwise it indicates the threshold signature σ t Illegal; in confirming the threshold signature σ t After legality, select the deposit public and private key address pair (addr Ipk ,addr Isk ) and the payment public and private key address pair (addr Opk ,addr Osk ), deposit public key address addr Ipk and payment public key address addr Opk Deposit user nodes and pay service fees to service providers respectively; add each address in the first address list addr pk,i With temporary public key address β pk Combine two by two to generate t one-time random addresses P pk,i The second address list, P pk,i =Hash(addr pk,i r c )G+β pk ; Set the deposit public key address addr Ipk 、Payment public key address addr Opk , first address list, random parameter R c and temporary public key address β pk Add them together to the deposit commitment, sign the deposit commitment and send it to the user node.

[0026] It is further preferred that an accountability stage is also included:

[0027] If the service provider refuses to provide proxy signature service, the user node holds the service provider accountable by publishing a service request acceptance message signed by the service provider;

[0028] If the service provider does not receive the service fee, the user node will be held accountable by publishing the first address list signed by the user node and the verification message of the local payment address;

[0029] If the user node does not receive a deposit certificate or an accountability message from the service provider after the transfer, the custody center can be held accountable by publishing the deposit commitment signed by the custody center and the master public and private key addresses.

[0030] The present invention also provides a blockchain escrow transaction system designed to implement the above method, which specifically includes a user node, an escrow center and a credit-granting service provider;

[0031] The hosting center specifically includes:

[0032] The signature key generation module uses the threshold signature algorithm to assign a signature public and private key pair to each legitimate network node;

[0033] The signature key extraction module extracts the signature public key and identity identifier that meet the conditions from the data storage module. The conditions are the proxy signer selection conditions proposed by the user node.

[0034] The random parameter generation module generates random parameters for escrow transactions based on the multi-party collaborative signature request sent by the user node;

[0035] Signature module, which signs the data sent to the user node;

[0036] The signature verification module verifies the authenticity of the threshold signature constructed by the user node;

[0037] A second address list generating module, using each address in the first address list and random parameters to generate a second address list;

[0038] The transaction settlement module determines that if the second address list contains a paid one-time random address, it sends a deposit certificate to the user node and pays a service fee to the payment address specified by all service providers participating in the signature. The service fee is deducted from the transferred amount of the one-time random address;

[0039] Data storage module, used to store the signature public key, identity identification and blockchain transaction data of network nodes;

[0040] User nodes specifically include:

[0041] A first address list generating module, used to add the payment addresses of all service providers and the locally selected master address to the first address list;

[0042] The signature module generates a signature of the first address list using a local signature private key, sums all signature components to obtain a threshold signature, and signs the data sent to the service provider;

[0043] The signature verification module verifies the authenticity of the signature of the hosting center or service provider;

[0044] The payment address generation module generates a one-time random address using the master address and random parameters, and uses the one-time random address as the payment address to transfer funds to the public deposit address designated by the custody center;

[0045] Service providers include:

[0046] The parameter exchange module returns a service request message to the user node if the service is allowed to be provided. The message contains the payment address of the service provider.

[0047] The signature module signs the first address list using its own signature private key to obtain a signature component;

[0048] The signature verification module verifies the authenticity of the signature of the user node.

[0049] The blockchain escrow transaction method and system of the present invention have the following beneficial effects:

[0050] The user node initiates a deposit request to the custody center, which assigns it the signature public key and identity information of a legally registered proxy signature service provider. The service provider provides its own signature component to the user node through negotiation, and aggregating signature components that include the user's own signature and a threshold number can obtain a threshold signature with collaborative protection characteristics, so that the user node's independent signature is completely hidden in the threshold signature, and the threshold system is indistinguishable from the signature generated by the original system. While ensuring the signature validity verification function, the user node's personal signature is prevented from being directly exposed to the custody center, and the digital currency input address cannot be associated with the signer's identity, thus fully realizing user anonymity. At the same time, for an attacker who can at most combine less than the threshold number of nodes, the probability of forging a legitimate signature for a new message is close to zero, which is more secure than traditional independent signatures.

[0051] The hosting center uses Bloom filters to record the legitimate signature public keys of network nodes. User nodes can use the signature public keys with the same local signature characteristics as conditions to select the corresponding proxy signers. The user node signature public keys will be included in the signature public key list provided by the hosting center, further reducing the difficulty of analyzing the user node identity. At the same time, it avoids the hosting center actively providing a large number of malicious signers to filter out the user's true signature identification. Other selection conditions can also be formulated or secondary selection can be performed according to needs, so that the threshold signature object has high randomness.

[0052] Since the user node and the hosting center negotiated the prior parameters before the first address list was published, and the random address generated by the master address and the prior parameters was used as the transfer address of the user node after the first address list was published, the service provider can only determine which addresses are receiving addresses (with digital currency inflows) by tracing back the addresses in the address list, but cannot know the user node transfer address. Even if it shares its own receiving address with all other service providers, it can only filter out the master address. Because the prior parameters are confidential to the outside, it is impossible to calculate the transfer address of the user node.

[0053] The present invention also sets up an accountability mechanism. If a breach of contract occurs during a transaction, the hosting center, user node and service provider can all provide and publicize their respective evidence. Combined with existing transactions on the chain, the authenticity of the evidence can be verified and dishonest parties can be identified to maintain a secure and stable network environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 This is a flow chart of the blockchain escrow transaction method for multi-party collaborative privacy protection of the present invention;

[0055] Figure 2 A schematic diagram of using a Bloom filter to store and select a signature public key in the present invention;

[0056] Figure 3 This is a structural diagram of the blockchain escrow transaction system with multi-party collaborative privacy protection of the present invention. DETAILED DESCRIPTION

[0057] The technical solution of the present disclosure is further described in detail below through the accompanying drawings and embodiments.

[0058] The present invention adopts the threshold signature algorithm to share the group signature key with all legally registered members, and distributes the public secret to all network members in the form of private key shards. Multiple group members simultaneously sign a deposit transfer service request proposed by the user node, and aggregate at the user node to obtain a threshold signature with multi-party collaborative protection effect. The custody center cannot determine which signer is the requester of the service request, but can always verify the authenticity of the threshold signature. In order to encourage more honest nodes to provide proxy signature services, digital currency can be paid to the service provider as a reward according to the deposit ratio or a certain amount, forming a benign transaction model.

[0059] A standard (t,n) threshold signature system signs a message that is signed by a group of signers. For a threshold signature system with n people participating, each person obtains a unique key share. The signature scheme is designed to require that a legal threshold signature can only be generated when the number of signers reaches at least a threshold value of t. The signature effect is indistinguishable from the signature result using the shared key alone and has the same validity.

[0060] Assume that the (t,n) distributed threshold signature algorithm is represented by TS = {TGenKey, TSign, Verify}, then:

[0061] TGenKey distributed key generation algorithm: The algorithm is participated by n participants, inputs a series of security parameters, and outputs a private key sequence (x1, x2, ... x n ) and the corresponding public key sequence (y1,y2,…y n), participant i is distributed to the private key shard x in a secret way i and public key shard y i . The sequence (x1, x2, …x n ) constitutes the (t,n) threshold secret sharing of x, so all participants can jointly generate the signature result of the group private key x, and use the corresponding group public key y to verify the legitimacy of the threshold signature.

[0062] TSign distributed signature algorithm: input message m and sequence (x1, x2, ... x t ), output threshold signature σ = TSign(m,(x1,x2,…x t )), the signature σ is equivalent to the group private key signature Sign(m,x).

[0063] Verify signature verification algorithm: Verify(m,y,σ)→b, input message m, threshold signature σ and group public key y, output a Boolean variable b, when the Boolean variable b returns TRUE, it indicates that σ is a valid signature, when it returns FALSE, it indicates that σ's signature is invalid.

[0064] like Figure 1 As shown, the present invention provides a multi-party collaborative privacy protection blockchain escrow transaction method, which specifically performs the following steps:

[0065] Step 1) The user node formulates the selection conditions for the proxy signer and anonymously sends a multi-party collaborative signature request to the hosting center;

[0066] Step 2) The escrow center extracts the signature public key and identity identifier that meet the conditions from the database, generates random parameters for the escrow transaction, and returns a list of all signature public keys, identity identifiers, and random parameters that can perform collaborative signatures to the user node;

[0067] Step 3) The user node broadcasts a proxy signature service request including a signature public key list and an identity list;

[0068] Step 4) After confirming that the proxy signature service request contains its own signature public key and identity, the network node returns a service request acceptance message to the user node if the service is allowed to be provided. The message contains the payment address of the service provider;

[0069] Step 5) The user node adds the payment addresses of all service providers and the locally selected master address to the first address list and sends it to each service provider;

[0070] Step 6) After the service provider confirms that the first address list contains its own payment address, it signs the first address list with its own signature private key and sends it back to the user node;

[0071] Step 7) The user node generates a signature for the first address list using the local signature private key. After verifying that all received signatures are legal, all signatures are summed to obtain a threshold signature, and an anonymous deposit request containing the threshold signature is anonymously sent to the custody center;

[0072] Step 8) After the custody center verifies that the threshold signature is legitimate, it sends a deposit commitment to the user node, which includes the signature of the custody center on the first address list;

[0073] Step 9) The user node generates a one-time random address using the master address and random parameters, and uses the one-time random address as the payment address to transfer funds to the public deposit address designated by the escrow center;

[0074] Step 10) The escrow center generates a second address list using the addresses in the first address list and the random parameters. If the second address list contains a paid one-time random address, the escrow center sends a deposit certificate to the user node and pays a service fee to the payment address designated by all service providers participating in the signature. The service fee is deducted from the transferred amount of the one-time random address.

[0075] The following is a specific example to illustrate the implementation process of the escrow transaction method of the present invention:

[0076] In the system initialization phase, the hosting center uses the threshold signature generation algorithm to assign unique identity information and signature public and private key pairs to each successfully registered legitimate user. In this embodiment, the elliptic curve threshold signature algorithm is used to perform this process.

[0077] 1. Generate public safety parameters

[0078] First, establish a finite field GF(2 m ) on the elliptic curve, GF(2 m ) by 2 m elements and addition and multiplication operations defined on polynomials. Let q = 2 m , p>3 is a prime number, a, b∈GF(2 m ), select a value m, then in GF(2 m ) is suitable for elliptic curve cryptography applications:

[0079] y 2 +xy=x 3 +ax 2 +b

[0080] All solutions With a point at infinity Together they form GF(2 m ) on an elliptic curve:

[0081]

[0082] Based on this, we choose a finite field A specific elliptic curve E′ is used, and the public security parameters (p, q, E′, G) are used. p is a large prime number, and G represents the base point of the elliptic curve E′ with an order of q. Select a secure Hash function. Publish the security parameters (p, q, E′, G) on the network and share them among all nodes in the network.

[0083] 2. Generate a shared group public and private key pair

[0084] Generate a unique ID for each registered member i , randomly select B sk ∈F q As the group private key, B is calculated by the elliptic curve cryptography algorithm pk =B sk G∈E′(f q ) as the group public key. Take any polynomial of order not exceeding t-1 f(x) = (a0+a1x+…+a t-1 x t-1 )∈F q (x), let a0=B sk , a i ∈Z n (i=1,2,…,n).

[0085] 3. Distribute public and private key shards to network nodes

[0086] Calculate b sk,i =f(ID i ) and b pk,i =b sk,i G is used as the private key shard and public key shard of each group member. sk,i Distribute to each group member node through a secret channel and make the public key shard b public pk,i (i=1,2,…,n), identity ID i and the blinding parameter c j =a j G(j=1,2,…,t-1).

[0087] When network node i receives the public and private key fragments (b pk,i ,b sk,i ) needs to verify the legitimacy first, first judge equation b pk,i =b sk,i G and Is it true? When the equality is confirmed, it indicates the public and private key fragmentation (b pk,i ,b sk,i) are mutually valid parameters, and together with the blinding parameter sequence and its own identity ID i Correct association, that is, public and private key sharding (b pk,i ,b sk,i ) is applicable to the blind threshold signature algorithm. Then determine the public and private key shards (b pk,i ,b sk,i ) is finalized on the elliptic curve published by the hosting center (b pk,i ,b sk,i ) is a valid signature public-private key pair and is stored locally; otherwise, if the verification is incorrect, it is rejected (b pk,i ,b sk,i ) provides proxy signing services and feeds back error messages to the hosting center.

[0088] When a user needs to request a deposit from the escrow center, a multi-party collaborative signature request needs to be anonymously sent to the escrow center. The request message contains the selection conditions of the proxy signer proposed by the user node. In addition, the multi-party collaborative signature request also includes basic information such as the escrow transaction identifier, pre-deposit amount, and settlement method. In this embodiment, a Bloom filter is used in the system to filter the signature public keys that meet the user's conditions. The escrow center uses a Bloom filter to store the hash values ​​of all legal signature public keys.

[0089] The signature public key is compressed and mapped through a set of hash functions and stored as a point in the space vector. If the point corresponding to the input data exists, it means that the data may be in the set; otherwise, it means that the data is definitely not in the set. Figure 2 As shown, formally, the Bloom filter consists of an m-bit bit vector D = (d1, d2, ... d m ) and a series of hash functions H = (Hash1, Hash2, ... Hash k ), k<m. The initial values ​​of the bit vector are all set to 0. After the hash operation, any input data will get a hash value sequence (h1,h2,…h k ), each hash value h i Mapped to bit vector D = (d1, d2, ... d m ) and set the corresponding bit to 1 to complete the bit vector record of the input data.

[0090] The user node can use the object with similar feature values ​​to the local signature public key as the selection condition to determine the identity of the signature agent. Assume that the signature public key of the user node can be represented as a bit vector Then extract the parts to form a new bit vector It is sent as a condition to the hosting center, and the hosting center screens the signature public key that meets the proxy signature qualification. The bit vector corresponding to it must contain D′u , that is, the agent's signature public key and the user's signature public key satisfy the same feature D′ u , and the signature public key list sent by the hosting center must also include the user's own signature public key.

[0091] The hosting center c extracts the signature public and private key pair that meets the above conditions from the database (b pk,i ,b sk,i ) and identity ID i , then collect all signature public keys b pk,i Obtain a signature public key list, which contains no less than a threshold value of t signature public keys. If the number is less than t, it is necessary to feedback relevant messages to the user node, and the user node resets the conditions to perform a secondary selection.

[0092] At the same time, the hosting center c also generates a random factor r based on the multi-party collaborative signature request sent by the user node c , further calculate the random parameter R c =r c G, the random parameter R c As a priori parameters, it participates in the one-time random address negotiation. When a dispute occurs, if the user node has transferred funds to the hosting center according to the negotiated random address, the exchanged random parameter R c Able to provide proof. As a custodian, the above signature public key list List pk 、Identity list List ID and the random parameter R c Signature c =Sign((List pk ,List ID ,R c ),C sk ), where C sk Indicates the signature private key of the hosting center, and the corresponding signature public key C is published on the network pk Finally, the signature σ c Sent to the user node together with the signed data.

[0093] The user node receives the signature σ c Then, using the signature public key C pk Verify its validityVerify((List pk ,List ID ,R c ),C pk ,σ c ), after confirming that the signature is valid, the user node u generates an encrypted public-private key pair locally (a pk,u ,a sk,u ), encrypt the public key a pk,Added to the proxy signature service request, used to encrypt data, the encryption public key a pk,u , Signature public key list List pk and the list of identities List ID Signature to get σ u1 =Sign((List pk ,List ID ,a pk,u ),U sk ), where U sk Represents the signature private key of the user node and publishes the corresponding signature public key U pk , the signature σ u1 The signed data is added to the proxy signature service request and then broadcast to the network.

[0094] After receiving the proxy signature service request message, network node i first uses the signature public key U pk Verify signature u1 ValidityVerify((List pk ,List ID ,a pk,u ),U pk ,σ u1 ), after confirming that the signature is valid, determine its own signature public key b pk,i and ID i Is it included in the signature public key list? pk and the list of identities List ID If it does not contain, the operation is terminated. If it does contain, it further determines whether to allow the user node to provide this signature service. If the service is allowed, it returns a service request message to the user node, which contains its own payment address. The payment address is encrypted by the public key a provided by the user node. pk,u At the same time, a random number d is generated for executing this signature service i , calculate the random point value D i =d i G, and also uses the encrypted public key a of the user node pk,u For random point value D i Encrypt, and then use the locally stored signature private key b sk,i For the encrypted payment address and random point value D i Signature i =Sign(M,b sk,i ), M represents the ciphertext, the ciphertext M, the signature σ i Added to the accepted service request message and sent to the user node.

[0095] The user node first verifies the signature σ according to the received service request message. iThe validity of Verify(M,b pk,i ,σ i ), after confirming that the signature is valid, use the encrypted private key a sk,u Decrypt the ciphertext to obtain the corresponding payment address and random point value D i , select t-1 network nodes from these legal signatures as service providers, and further calculate the point value The random point value D u =d u G,d u Represents the random number generated locally by the user node, remainder k t =μmodp; Generate a master public and private key address pair locally (α pk ,α sk ) and temporary public-private key address pair (β pk ,β sk ), the payment address and master public key address α of all selected service providers pk Add to the first address list List1, from the identity list List ID Extract the identity identifiers of all signers and reconstitute an identity identifier list List′ ID , the signers include the user node and all selected service providers, for the remainder k t , first address list List1, identity list List′ ID and temporary public key address β pk Execution signature u2 =Sign((k t ,List1,List′ ID ,β pk ),U sk ), and then the signature σ u2 And the signed data is sent to each selected service provider.

[0096] When network node i receives signature σ u2 After the data message is received, the signature public key U pk Verify its validity t ,List1,List′ ID ,β pk ),U pk ,σ u2 ), after confirming that the signature is valid, let the message m = k t ||List1||β pk , calculate the hash value of the message h = Hash (m), and then use the local signature private key b sk,i Generate a signature component σ about the hash value h i =(di +hk t b sk,i Q i )modp, the intermediate value is calculated by Lagrange interpolation formula The identity ID that participates in the service together with the local node j From the identity list List′ ID Finally, the signature component σ i It is bound to the signed data and sent to the user node.

[0097] The user node receives the signature component σ of a service provider i After that, verify the signature component σ i Is it legal if we calculate σ i GD i =σ i G i G=(d i +hk t b sk,i Q i )Gd i G=hk t b sk,i Q i G=hk t b pk,i Q i , then it means that the signature component σ i Legal, otherwise it indicates that the signature component σ i Illegal; after confirming each signature component σ i After all are legal, aggregate the t signature components and calculate the threshold signature where σ u Represents the signature component generated locally by the user node, that is, σ u =(d u +hk t U sk Q u )modp, Only when the signature weights σ of at least t signatories are i Gather together to calculate At this time, the data being signed is still message m, because the data of the threshold signature does not contain the identity ID of any signer. i Therefore, whether it is the service provider or the user itself, their identity information is transparent to the hosting center. The hosting center can only obtain a list of addresses that are not associated with the identity, which is used to verify the receipt of funds or pay service fees.

[0098] In addition, the user node generates a one-time random address P locally pk=Hash(α sk R c )G+β pk , and the corresponding private key P sk =Hash(α sk R c )G+β sk , the one-time random address P pk As the address for user node to transfer funds to the hosting center. t The signed data is added to the anonymous deposit request and sent to the escrow center. In addition, the anonymous deposit request also includes basic information such as the escrow transaction identifier, the agreed deposit amount, and the settlement method.

[0099] The hosting center receives the threshold signature σ t After that, first pass the group public key B pk Verify threshold signature σ t Is it legal? Calculate σ t G-hk t B pk =(μ′,ω′),k′ t =μ′modp, if k t = k′ t This indicates that the threshold signature σ t Legal, otherwise it indicates the threshold signature σ t Illegal. When confirming the threshold signature σ t After legality, select the deposit public and private key address pair (addr Ipk ,addr Isk ) and the payment public and private key address pair (addr Opk ,addr Osk ), deposit public key address addr Ipk and payment public key address addr Opk Deposit money for user nodes and pay service fees to service providers respectively.

[0100] The correctness of the above threshold signature verification algorithm can be derived by the following formula:

[0101]

[0102] Then, the anonymous deposit request is matched with the multi-party collaborative signature request for transaction identification, and the multi-party collaborative signature request with the same escrow transaction identification is found, and the random factor r associated with the request is extracted. c , add each address in the first address list addr pk,i With temporary public key address β pk Combine two by two to generate t one-time random addresses P pk,i The second address list, P pk,i =Hash(addrpk,i r c )G+β pk ,addr pk,i The payment address of the service provider or the master public key address of the user α pk Therefore, the payment address P of the user node can be generated locally in the hosting center pk =Hash(α pk r c )G+β pk =Hash(α sk r c G)G+β pk =Hash(α sk R c )G+β pk However, only after the digital currency is actually received at this address, the escrow center can know the payment address P pk It is owned by the anonymous user, and the escrow transaction to which the transfer belongs is determined by judging which second address list the transfer address belongs to.

[0103] Set the deposit public key address addr Ipk 、Payment public key address addr Opk , the first address list List1, random parameter R c and temporary public key address β pk Add them together to the deposit commitment, sign the deposit commitment and send it to the user node.

[0104] After the user node receives the deposit commitment and verifies that it is a message signed by the custody center, and the signed data is consistent with the local original record data, it sends a one-time random address P pk The digital currency can be transferred from the user's other wallet deposit address, or from the output address of the previous transaction process, or other more secure cryptocurrencies such as zero coin or Monero. After the currency injection is completed, the one-time random address p pk As the input address of this deposit custody transaction, the deposit public key address addr Ipk As the output address, the digital currency is transferred to the custody center.

[0105] When the custody center receives a deposit, it first extracts the second address list of all unfinished deposit custody transactions, and searches for which deposit custody transaction the currency input address of this deposit belongs to. When the actual payment address p is recorded in the second address list of a deposit custody transaction, pk When the first address list recorded in the deposit escrow transaction is extracted again, a search is performed to find the address that can generate the payment address p pk The address is the master public key address α of the user node pk, delete the master public key address α pk The remaining addresses are the payment addresses of all service providers participating in this signature, with the payment public key address addr Opk As the transaction input address, a certain percentage of the deposit amount or a fixed amount of digital currency is paid to each receiving address in the list as the service fee for participating in this proxy signature. The fee is borne by the user and recorded in the settlement sheet of this custody transaction. It can also be written into the deposit certificate provided by the custody center to the user's node.

[0106] The custodian center's income and expenditure digital currency operations are independent of each other, separating user deposits from service fee settlement operations, and using addr Ipk and addr Opk Two different addresses implement the transaction process, avoiding the association of transaction addresses and preventing the relationship between the user node and the proxy signer from being leaked.

[0107] After completing the service fee settlement, the custody center will return the deposit voucher to the anonymous user who has sent the anonymous deposit request. The deposit voucher contains a receipt confirmation letter and a service fee payment confirmation letter signed by the custody center, informing the user of the actual receipt amount, receipt time, service fee payment amount, payment time, input and output addresses of each sub-transaction and other information of this custody transaction. Sub-transactions include transactions in which user nodes transfer digital currency to the custody center and the custody center transfers digital currency to service providers.

[0108] In order to ensure the timeliness of transaction data, timestamps can be added to messages exchanged between the custody center and user nodes, and between user nodes and service providers. Signed messages are only valid within a preset time range to prevent transaction data from being intercepted by malicious third parties. User nodes add a time field to anonymous deposit requests, and it is agreed that transfers to the custody center within the time recorded in the field will be considered valid transactions. The time is calculated starting from the timestamp marked by the custody center in the deposit commitment.

[0109] When a user needs to pay other blockchain nodes (such as merchants), the user node can generate a payment request message, which records the merchant's payment address, payment amount, agreed payment time limit, established smart contract and other important information, and sends the master private key address α sk , random parameter R c , the payment request message and deposit certificate are sent to the hosting center in a secret and anonymous manner (such as encrypted using the hosting center's encrypted public key), and the hosting center uses the master private key address α sk and the random parameter R c , if it is possible to generate an address P with the same value as the deposit address recorded in the deposit certificate pk =Hash(α sk R c )G+βpk , it indicates that the deposit voucher belongs to the anonymous user and the user owns the deposit recorded on the deposit voucher. The escrow center, as the trustee, pays the merchant on behalf of the anonymous user according to the merchant payment address recorded in the payment request message, and returns the payment voucher to the anonymous user after the payment is successful. The payment voucher records the main information of this payment transaction, such as the input and output addresses, payment amount, payment time and deposit balance.

[0110] In another embodiment provided by the present invention, the above-mentioned escrow transaction implementation method also includes an accountability mechanism. Since the transaction method of the present invention is jointly implemented by the escrow center, user nodes and service providers, any breach of contract by any party will result in transaction failure. When such a breach of contract occurs, the dishonest objects can be analyzed and identified by executing the accountability process, and restricting these dishonest objects from participating in other transactions again can improve the loyalty of other network members and constrain their own behavior. The accountability mechanism is activated when the following situations occur, and the corresponding accountability process is executed:

[0111] If the service provider refuses to provide proxy signature service, the user node holds the service provider accountable by publishing the service provider's signed acceptance service request message. Specifically, the signature σ sent by the refuser is published to network members. i =Sign(M,b sk,i ) and the signed data, encrypted private key a sk,u , the signature σ sent by the user node u2 =Sign((k t ,List1,List′ ID ,β pk ),U sk ) and the signed data, other transaction members first verify the signature σ u2 Is it consistent with the original signed message received before? After confirming the consistency, verify the signature σ i Validity, if invalid, it means that the user node evidence is not established, otherwise the encrypted private key a sk,u Decrypt the ciphertext M and determine whether the payment address in the plaintext is recorded in List1. If not, it means that the user node evidence is invalid. Otherwise, it means that the rejector did not provide the proxy signature service to the user node as agreed in the agreement and is a dishonest object.

[0112] If the service provider does not receive the service fee, the user node is held accountable by publishing the first address list signed by the user node and the verification message of the local payment address. Specifically, the signature σ sent by the user node is published to network members. u2 =Sign((k t ,List1,List′ ID ,β pk ),Usk ) and the signed data, the public and private key pair of the service provider's own payment address (addr pk,i ,addr sk,i ); Other transaction members verify the signature σ u2 If valid, determine the public key of the payment address addr pk,i Does it exist in List1? If not, it means that the service provider evidence is not established. Otherwise, further verify addr pk,i with addr sk,i Are they valid parameters? If the parameters are invalid, it means that the service provider evidence is invalid. Otherwise, it means (addr pk,i ,addr sk,i ) The ownership does belong to the service provider, and further retrieves the payment address public key addr pk,i Whether it exists in a transaction recorded in the blockchain, if there is a digital currency transfer record, it means that the hosting center has paid the corresponding service fee and the service provider is a dishonest object, otherwise it means that the user node is a dishonest object. If the user node does not agree that it has been judged to be dishonest, it can start the accountability phase between the user node and the hosting center.

[0113] If the user node does not receive a deposit certificate or an accountability message from the service provider after the transfer, the deposit commitment signed by the custody center and the master public-private key address pair are published to the network members. pk ,α sk ); Other transaction members, after verifying the validity of the deposit commitment signature, determine the master public key address α pk Does it exist in the first address list List1? If not, it means that the user node evidence is not established. Otherwise, further verification α pk With α sk Are they mutually valid parameters? If the parameters are invalid, it means that the node evidence is invalid. Otherwise, the master private key address α is used. sk , temporary public key address β pk and the random parameter R c Regenerate payment address P pk =Hash(α sk R c )G+β pk , find out whether a transaction exists in the blockchain: with the payment address P pk As input address, take deposit public key address addr Ipk As the transaction record of the output address, that is, P pk Already sent to addr IpkA certain amount of digital currency has been transferred. If it does not exist, it means that the node did not deposit the money into the designated account of the custody center as agreed in the agreement. Otherwise, it means that the custody center has indeed received the money, but did not send the deposit certificate to the user node as agreed in the agreement, or based on the service provider's accountability of the user node, the user node has reason to prove that the custody center has not paid the service fee to the service provider and that the custody center has credit problems based on the above accountability process.

[0114] In order to implement the above-mentioned escrow transaction method, the present invention also provides a blockchain escrow transaction system based on multi-party collaborative privacy protection, such as Figure 3 As shown, the system includes user nodes, a hosting center and a trusted service provider.

[0115] The hosting center specifically includes:

[0116] The signature key generation module uses the threshold signature algorithm to assign a signature public and private key pair to each legitimate network node;

[0117] The signature key extraction module extracts the signature public key and identity identifier that meet the conditions from the data storage module. The conditions are the proxy signer selection conditions proposed by the user node.

[0118] The random parameter generation module generates random parameters for escrow transactions based on the multi-party collaborative signature request sent by the user node;

[0119] Signature module, which signs the data sent to the user node;

[0120] The signature verification module verifies the authenticity of the threshold signature constructed by the user node;

[0121] A second address list generating module, using each address in the first address list and random parameters to generate a second address list;

[0122] The transaction settlement module determines that if the second address list contains a paid one-time random address, it sends a deposit certificate to the user node and pays a service fee to the payment address specified by all service providers participating in the signature. The service fee is deducted from the transferred amount of the one-time random address;

[0123] Data storage module, used to store the signature public key, identity identification and blockchain transaction data of network nodes;

[0124] User nodes specifically include:

[0125] A first address list generating module, used to add the payment addresses of all service providers and the locally selected master address to the first address list;

[0126] The signature module generates a signature of the first address list using a local signature private key, sums all signature components to obtain a threshold signature, and signs the data sent to the service provider;

[0127] The signature verification module verifies the authenticity of the signature of the hosting center or service provider;

[0128] The payment address generation module generates a one-time random address using the master address and random parameters, and uses the one-time random address as the payment address to transfer funds to the public deposit address designated by the custody center;

[0129] Service providers include:

[0130] The parameter exchange module returns a service request message to the user node if the service is allowed to be provided. The message contains the payment address of the service provider.

[0131] The signature module signs the first address list using its own signature private key to obtain a signature component;

[0132] The signature verification module verifies the authenticity of the signature of the user node.

[0133] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present disclosure rather than to limit it, although the present disclosure is described in detail with reference to the preferred embodiments. It should be understood by those skilled in the art that the present invention is not limited to the details of the above exemplary embodiments, and the specific implementation methods of the present disclosure can still be modified or some technical features can be replaced by equivalents; without departing from the spirit of the technical solution of the present disclosure, the scope of the present invention is defined by the attached claims rather than the above description, and they should all be included in the scope of the technical solution for protection of the present disclosure.

Claims

1. A blockchain escrow transaction method with multi-party collaborative privacy protection, characterized in that: include: The user node formulates the selection criteria for the proxy signer and anonymously sends a multi-party collaborative signature request to the hosting center; The escrow center extracts the signature public key and identity that meet the conditions from the database, generates random parameters for the escrow transaction, and returns a list of all signature public keys, identity lists, and random parameters that can perform collaborative signatures to the user node; The user node broadcasts a proxy signature service request containing a signature public key list and an identity list; After confirming that the proxy signature service request contains its own signature public key and identity, the network node returns a service request acceptance message to the user node if the service is allowed to be provided. The message contains the payment address of the service provider. The user node adds the payment addresses of all service providers and the locally selected master address to the first address list and sends it to each service provider; After the service provider confirms that the first address list contains its own payment address, it signs the first address list with its own signature private key and sends it back to the user node; The user node generates a signature for the first address list using the local signature private key. After verifying that all received signatures are legal, the user node sums up all signatures to obtain a threshold signature and anonymously sends an anonymous deposit request containing the threshold signature to the custody center. After the custody center verifies the legitimacy of the threshold signature, it sends a deposit commitment to the user node, which includes the signature of the custody center on the first address list; The user node generates a one-time random address using the master address and random parameters, and uses the one-time random address as the payment address to transfer funds to the public deposit address designated by the custody center; The escrow center generates a second address list using the addresses and random parameters in the first address list. If the second address list contains a paid one-time random address, it sends a deposit certificate to the user node and pays the service fee to the payment address specified by all service providers participating in the signature. The service fee is deducted from the transferred amount of the one-time random address. The selection step of the proxy signer is as follows: the hosting center uses a Bloom filter to store the bit vectors of all legal signature public keys, and the user node extracts the signature public key and the corresponding identity that meet the requirements from the Bloom filter as the proxy signer based on the bit vector as a feature; The hosting center uses the elliptic curve threshold signature algorithm to distribute signature public and private key pairs to each network node i (b pk，i , b sk，i ), where the signature private key b sk，i =f(ID i ), signature public key b pk，i =b sk，i G, ID i is the identity of network node i, f() is the signature private key generation algorithm, and G represents the base point of the elliptic curve; Generate a random factor r based on the multi-party collaborative signature request c , further calculate the random parameter R c =r c G, and signs the signature public key list, identity list and random parameters and sends them to the user node; After verifying the legitimacy of the signature of the hosting center, the user node generates an encrypted public-private key pair locally (a pk,u , a sk,u ), encrypt the public key a pk,u Add to the proxy signature service request and broadcast to the network after signing; The steps for network node i to generate a service request message are as follows: after verifying the legality of the signature of the user node, a random number d is generated. i , calculate the random point value D i =d i G, with the encrypted public key a of the user node pk,u The locally selected payment address and random point value are encrypted, the generated address ciphertext is added to the acceptance service request message, and sent to the user node after signing.

2. The multi-party collaborative privacy-protected blockchain escrow transaction method according to claim 1, characterized in that: After the user node receives the service request message, it also includes the following steps: after verifying the legality of the signature of the network node, using the encrypted private key a sk,u After decrypting the address ciphertext, the payment address and random point value of the network node are obtained. A threshold of t-1 network nodes are selected from the legal signatures as service providers to further calculate the point value. D u =d u G, remainder k t =μmodp; Generate a master public and private key address pair locally (α pk , α sk ) and temporary public-private key address pair (β pk , β sk ), the payment address and master public key address α of all service providers pk Add to the first address list, and the remainder k t , the first address list, the identity list of all signers and the temporary public key address β pk After signing, send it to the service provider.

3. The multi-party collaborative privacy-protected blockchain escrow transaction method according to claim 2, characterized in that: The steps for service provider i to sign the first address list are: after verifying the legality of the signature of the user node, calculate the signature component σ i =(d i +hk t b sk，i Q i )modp, where h represents the remainder k t , the first address list and temporary public key address β pk The hash value of the signature component σ i Sent to the user node.

4. The multi-party collaborative privacy-protected blockchain escrow transaction method according to claim 3 is characterized in that: The user node receives the signature component σ i The next steps are: verify the signature component σ i Is it legal if we calculate σ i GD i =hk t Q i b pk，i , then it means that the signature component σ i Legal, otherwise it indicates that the signature component σ i Illegal; In confirming the signature component σ i After it is legal, further calculate the threshold signature Generate a one-time random address P locally pk =Hash(α sk R c )G+β pk , and the corresponding private key P sk =Hash(α sk R c )G+β sk ; The threshold signature σ t Added to anonymous deposit request and sent to escrow.

5. The multi-party collaborative privacy-protected blockchain escrow transaction method according to claim 4, characterized in that: The hosting center receives the threshold signature σ t The next steps are: verify the threshold signature σ t Is it legal? Calculate σ t G-hk t B pk =(μ′,ω′),k′ t =μ′modp, if k t = k′ t This indicates that the threshold signature σ t Legal, otherwise it indicates the threshold signature σ t Illegal; in confirming the threshold signature σ t After legality, select the deposit public and private key address pair (addr Ipk ,addr Isk ) and the payment public and private key address pair (addr Opk ,addr Osk ), deposit public key address addr Ipk and payment public key address addr Opk Deposit user nodes and pay service fees to service providers respectively; add each address in the first address list addr pk，i With temporary public key address β pk Combine two by two to generate t one-time random addresses P pk，i The second address list, P pk，i =Hash(addr pk，i r c )G+β pk ; Set the deposit public key address addr Ipk 、Payment public key address addr Opk , first address list, random parameter R c and temporary public key address β pk Add them together to the deposit commitment, sign the deposit commitment and send it to the user node.

6. The multi-party collaborative privacy-protected blockchain escrow transaction method according to claim 5, characterized in that: It also includes an accountability phase: If the service provider refuses to provide proxy signature service, the user node holds the service provider accountable by publishing a service request acceptance message signed by the service provider; If the service provider does not receive the service fee, the user node will be held accountable by publishing the first address list signed by the user node and the verification message of the local payment address; If the user node does not receive a deposit certificate or an accountability message from the service provider after the transfer, the custody center can be held accountable by publishing the deposit commitment signed by the custody center and the master public and private key addresses.

7. A multi-party collaborative privacy-protected blockchain escrow transaction system, characterized by: The system is applied to the blockchain escrow transaction method for multi-party collaborative privacy protection as described in any one of claims 1-6, including user nodes, an escrow center and a trusted service provider; the escrow center specifically includes: The signature key generation module uses the threshold signature algorithm to assign a signature public and private key pair to each legitimate network node; The signature key extraction module extracts the signature public key and identity identifier that meet the conditions from the data storage module. The conditions are the proxy signer selection conditions proposed by the user node. The random parameter generation module generates random parameters for escrow transactions based on the multi-party collaborative signature request sent by the user node; Signature module, which signs the data sent to the user node; The signature verification module verifies the authenticity of the threshold signature constructed by the user node; A second address list generating module, using each address in the first address list and random parameters to generate a second address list; The transaction settlement module determines that if the second address list contains a paid one-time random address, it sends a deposit certificate to the user node and pays a service fee to the payment address specified by all service providers participating in the signature. The service fee is deducted from the transferred amount of the one-time random address; Data storage module, used to store the signature public key, identity identification and blockchain transaction data of network nodes; User nodes specifically include: A first address list generating module, used to add the payment addresses of all service providers and the locally selected master address to the first address list; The signature module generates a signature of the first address list using a local signature private key, sums all signature components to obtain a threshold signature, and signs the data sent to the service provider; The signature verification module verifies the authenticity of the signature of the hosting center or service provider; The payment address generation module generates a one-time random address using the master address and random parameters, and uses the one-time random address as the payment address to transfer funds to the public deposit address designated by the custody center; Service providers include: The parameter exchange module returns a service request message to the user node if the service is allowed to be provided. The message contains the payment address of the service provider. The signature module signs the first address list using its own signature private key to obtain a signature component; The signature verification module verifies the authenticity of the signature of the user node.

Images