CN112671540A - Contract signing method, system and medium based on block chain and fair exchange - Google Patents

Abstract

The invention requests to protect a contract signing method, a system and a medium based on block chain and fair exchange. The method comprises the following steps: and in the fuzzy signature exchange stage, the initiator and the receiver exchange respective fuzzy signatures according to a concurrent signature algorithm based on bilinear pairings, and verify the fuzzy signatures. In the transaction stage, the initiator and the receiver generate corresponding blockchain transactions according to the key number hash value in the fuzzy signature of the other party. And in the disclosing stage, the initiator and the receiver disclose the corresponding secret values of the initiator and the receiver through blockchain transaction, and bind the fuzzy signature. The transaction verification phase will verify the exchange in conjunction with the blockchain state. The invention realizes the security properties of non-forgeability, fairness, non-tamper property and the like without a traditional credible third party. The computational and storage pressures of the server are no longer an issue. All of the computational pressure will be shared by the block link points, and the computational overhead is maintained at a low level.

Description

Contract signing method, system and medium based on block chain and fair exchange

Technical Field

The invention belongs to the technical fields of information security technology and Internet of things, and relates to a block chain-based fair exchange scheme which can be used for services such as contract signing in the fields of e-commerce and e-government affairs.

Background

Fair exchange plays a key role in businesses such as contract signing in the fields of e-commerce and e-government. Taking contract signing as an example, two parties signing a signature by a traditional paper contract are carried out in the same physical environment in the same place, and the two parties signing the signature are mutually supervised to finish the signature, so that the unfair problem hardly occurs. In a network environment, because both sides signing a contract have no trust basis, how to ensure the rights and interests of both sides exchanging, especially the fairness, is an important problem in the fields of e-commerce, e-government affairs and the like. A fair exchange protocol is an important protocol to solve this problem, so-called fair exchange, i.e. at the end of the exchange, each participant receives the desired item, or all participants do not receive it, the exchange is fair.

In the existing fair exchange scheme oriented to internet application, a solution with higher cost based on mutual trust of both sides of a service of a trusted third party is generally adopted. The application provides a block chain-based fair exchange scheme, an exchange model uses concurrent signatures, both exchange parties have own key numbers, and the key numbers are released through block chain transaction to bind respective signatures. The safety certification based on formalization and the performance test based on BitcoinCore show that the application has higher safety and better performance.

The invention designs a block chain-based fair exchange protocol, which is realized by using a concurrent signature technology, a bit currency P2SH and a time locking technology and by using the shunting of bit currency scripts, so that the fairness of exchange is ensured. The security analysis and the performance analysis show that the invention still has more ideal performance on the premise of ensuring the unforgeability and the fairness.

Disclosure of Invention

The present invention is directed to solving the above problems of the prior art. A contract signing method based on block chain and fair exchange is provided. The technical scheme of the invention is as follows:

a contract signing method based on block chain and fair exchange comprises the following steps:

fuzzy signature exchange stage: the initiator and the receiver exchange respective fuzzy signatures according to a concurrent signature algorithm based on bilinear pairings, and verify the fuzzy signatures;

a transaction stage: the initiator and the receiver generate corresponding bitcoin-based blockchain transaction according to the key number hash value in the fuzzy signature of the other party;

and (3) a disclosure stage: the initiator and the receiver disclose the corresponding secret values through blockchain transaction and bind the fuzzy signature;

a transaction verification stage: the exchange will be verified in connection with the blockchain status.

Further, in the fuzzy signature exchange stage, the concurrent signature algorithm based on bilinear pairings specifically includes:

the specific construction of the concurrent signature algorithm comprises four steps, specifically system setting, fuzzy signature and fuzzy signature verification, wherein the signature verification comprises the following steps:

the system is set up by giving a safety parameter l, selecting large prime numbers p and q, q | p-1, q length l-bit, G₁Is a q-order addition group, G₂Is a group of q factorials, G being G₁G, bilinear mapping e₁×G₁→G₂Two cryptographically secure hash functions H₁，H₂：{0,1}^*→Z_qThe domains S, F, K are defined as S.ident.F ═ Z_q，K＝{0,1}^*Private key x_iRandomly from Z_qOf (1) public key X_i＝x_iG; fuzzy signature by<X_i,X_j,x_i,f,M>As input, wherein X_i，X_j≠X_iIs a public key, x_i∈Z_qIs X_iCorresponding private key, F belongs to F and is a hash value corresponding to the key number, M is the message to be signed, and the algorithm selects a random number r belongs to Z_qAnd the following operations are carried out:

h＝H₂(e(rG,fX_j))||M) (1)

h₁＝h-fmod q (2)

s＝r-h₁x_imod q (3)

algorithm output σ ═<s,h₁,f>(ii) a Wherein H₂Is a cryptographically secure hash function, h is ANDInformation-dependent hash value, h₁S is a parameter for subsequent fuzzy signature verification;

fuzzy signature verification by taking S as<σ,X_i,X_j,M>As input, S is only a parameter set<σ,X_i,X_j,M>For convenience of description, wherein σ ═<s,h₁,f>And checking an algorithm:

h₁+f＝H₂(e(sG+h₁X_i,fX_j)||M) (4)

signature verification by<k,S,R>As input, where k ∈ Z_qIs the corresponding key number, R ═ kx_i ^-1G and R are parameters for verifying the key number k, and the algorithm checks:

f＝H₁(k) (5)

e(R,X_i)＝e(G,G)^k (6)

H₁r is a parameter for the authentication key number k, which is a cryptographically secure hash function.

Further, in the fuzzy signature exchange stage, the bilinear pairs specifically include:

let the security parameter be l, select large prime numbers p and q, q | p-1, q length be l-bit, G₁Is a q-order addition group, G₂Is a group of q factorials, G being G₁If e is mapped to G₁×G₁→G₂The following properties are satisfied and are called bilinear pairs:

1) bilinear: for any a, b ∈ Z_q，P,Q∈G₁E (aP, bQ) ═ e (P, Q)^ab(ii) a P and Q are additive groups G₁Any of (1);

2) non-degradability: presence of P, Q ∈ G₁，e(P,Q)≠1；

3) Calculability: for any P, Q ∈ G₁There is an efficient algorithm to compute e (P, Q).

Further, the transaction stage adopts a bitcoin transaction form, specifically:

the transaction committed by TxCommit can be carried out in two waysRedemption, a transaction redeemed by the recipient through the disclosure of the corresponding key number, a transaction redeemed by the exchange originator after a certain time with its own signature, assuming the exchange was initiated by Alice and received by Bob, assuming Alice prepared a sufficient amount of transaction input In advance, In txcomp transaction, whose input is a transaction prepared In advance by the exchange originator with sufficient UTXO, referenced by txcomp, In-script unlocks the transaction through its own signature for the originator, using UTXO therein, Out-script is a condition for using txcomp output, one is to provide k such that k (k) f is satisfied, one is to provide ver after time t_A(body,σ₂) Redeeming the transaction output of TxCommit, Val representing the amount of money of the transaction output, and Tlock representing the lock time of the transaction output.

Further, the fuzzy signature exchange stage specifically includes the following steps:

alice is used as an initiator of the agreement, Bob is used as a receiver of the agreement, and Alice's public and private key pair<x_A,X_A>Public and private key pair of Bob<x_B,X_B>The fuzzy signature switching node is specifically implemented as follows: alice selects a random number k_A∈Z_qAs a key number, and calculating f ═ H₁(k_A)，R_A＝k_Ax_A ^-1G, Alice runs ASIGN algorithm and inputs<X_A,X_B,x_A,f,M>To obtain a fuzzy signature sigma_A＝<s,h₁,f>Will be<σ_A,R_A>Together sent to Bob;

when Bob receives the fuzzy signature from Alice, the AVERIFY algorithm is executed, and the input of the algorithm is S ═<σ_A,X_A,X_B,M>. If AVERIFY (σ)_A,X_A,X_BM) TRUE, Bob receives the message and selects a random number k_B∈Z_qAs a key number, and calculating a key number hash value f ═ H₁(k_B)，R_B＝k_Bx_B ^-1G, running ASIGN algorithm, inputting<X_B,X_A,x_B,f',M>To obtain a fuzzy signature sigma_A＝<s',h₁',f'>Will be<σ_B,R_B>Sending the data to Alice together;

when Alice receives the fuzzy signature of Bob, AVERIFY algorithm is executed, and the input of the algorithm is S ═<σ_B,X_B,X_A,M>If AVERIFY (σ)_B,X_B,X_AM) TRUE, Alice accepts the message.

Further, the implementation of the transaction stage specifically includes: after the exchange of the fuzzy signatures is completed, the two transaction parties construct the bitcoin transaction meeting the agreement;

transaction for initiator Alice to create x-bit coins

The ID of the transaction is ID_AConditional payments and time lock settings involving bitcoins will be made in the UTXO of the transaction and Alice will make a lock script<f'>Set therein, Bob is expected to provide its original image to redeem the output;

for this transaction, Bob may release his key number k by releasing his own key number_BTo redeem the transaction, Alice may redeem the transaction after time t with his own signature, and the responder Bob will create a transaction in x bitcoins

The ID of the transaction is ID_BConditional payments and time-lock settings involving bitcoins will be involved in the UTXO of the transaction, and Bob will be in the lock script<f>Set therein, it is expected that Alice provides a corresponding pre-image to redeem the output; for this transaction, Alice releases its key number k_ATo redeem the transaction, Bob can redeem the transaction after time t with his own signature.

Further, the disclosure stage specifically includes the steps of:

if the transaction phase is successfully completed, Alice and Bob will jointly complete the disclosure phase;

alice quote transaction

And are provided with<Alice’s Sig><k_A>True as an unlocking script, generating a transaction

The transaction ID is recorded as ID'_AThis step is equal to the public Alice's key number k_AAnd publicly verifying that f is H₁(k_A)；

Bob through ID'_ASearching the transaction, analyzing the unlocking script used by Alice to generate the transaction<Alice’s Sig><k_A>True, k from which Alice's is extracted_A. Bob will sign σ the fuzzy signature received from Alice_AVerification was performed using equation (6):

if the last step of verification passes, Bob transacts by reference

And are provided with<Bob’s Sig><k_B>True as an unlocking script, generating a transaction

The transaction ID is ID'_B. Equivalent to the disclosure k_BAnd verifying f' ═ H₁(k_B)，

Alice passes ID'_BRetrieve transactions, extract Bob's key number k from them_B. Alice will sign σ the ambiguity received from Bob_BVerify using equation (6):

further, the transaction verification stage specifically includes:

TXVERIFY(<k,S>,<k',S'>,<ID_A,ID_A'>,<ID_B,ID_B'>)

where k represents Alice's key number k_AS represents the set of parameters of Alice<σ_A,X_A,X_B,M>And k' represents the key number k of Bob_BS' represents the parameter set of Bob<σ_B,X_B,X_A,M>The input to the algorithm is the transaction ID, and when the amount is redeemed with the key hash's primitive, the algorithm outputs True; when redeemed by the originator of the transaction with its own signature after a time t determined by the time-lock, the algorithm outputs False, for the purposes of redeeming the transaction txcomp, there are two different possibilities, when the transaction is redeemed by disclosing the correct keystone, the new transaction generated is called TxOpen; when the transaction is redeemed after time lock t, by its originator's own signature, the resulting transaction is called TxReturn; let the transaction ID of TxCommit be ID at this time_ARedemption of TxCommit transaction ID as ID_A'；

A secondary algorithm:

Quote(<k,S>,<ID_A,ID_A'>)＝True

checking ID_AWhether the locking script references the key hash value f, ID in S_A' whether the unlocking script refers to a key number k or not, and if yes, the output is True;

Quote(<k',S'>,<ID_B,ID_B'>)＝True

in the same way, if the above are True,

TXVERIFY(<k,S>，<k',S'>,<ID_A,ID_A'>,<ID_B,ID_B'>) And returning True, otherwise, returning False.

A block chain and fair exchange contract signing system, comprising: the initiator: as an initiator of the protocol, firstly selecting a key number of the initiator, generating a corresponding key number hash value, generating a fuzzy signature through a fuzzy signature algorithm, and sending the fuzzy signature to a receiver;

the receiver: after receiving the fuzzy signature of the initiator, the receiver checks the signature correspondingly, and if the signature passes the corresponding check, the receiver generates the fuzzy signature of the receiver as the initiator according to the protocol requirement and sends the fuzzy signature to the initiator;

block chains: and when the initiator and the receiver both receive the fuzzy signature of the other party, generating corresponding blockchain transactions according to the key number hash value of the other party. The blockchain node packages the transactions for uplink. The issuer will initiate a transaction of the passkey number at the open stage in order to redeem the amount in the blockchain transaction. In the verification stage, the algorithm reads the state of the blockchain transaction to complete verification.

A medium storing computer executable instructions for implementing the method of any one of claims 1 to 8 when executed.

The invention has the following advantages and beneficial effects:

the invention provides a fair exchange scheme realized by a concurrent signature scheme based on a block chain, which takes the transaction state of the block chain as a verification condition for successful exchange and does not need to invest money with the same value as a contract to be signed in the block chain transaction as a guarantee by an exchange participant. The blockchain transaction involved in the scheme can be completed by a native system completely using bitcoin without additionally developing an intelligent contract.

The invention is a fair exchange scheme realized based on a block chain, and can realize safety, fairness and usability under the condition of not participating by a trusted third party. In general, the computational and storage pressures of the server are no longer an issue since there are no traditional trusted third parties. All the computing pressure is shared by all the nodes, the scheme has higher efficiency under the current computing environment, and the computing cost is maintained at a lower level.

The invention is based on the characteristic of concurrent signature of claim 2, both sides of contract exchange can exchange fuzzy signature and carry on the preliminary verification, the fuzzy signature can not bind with concrete signer, the verification algorithm is based on the characteristic of bilinear pairing of claim 3, can disclose the verification fuzzy signature under the condition that the secret value is not disclosed. In conjunction with the bitcoin-based blockchain transaction embodiment of claim 4, exchange participants can be given the opportunity to publish key numbers or redeem transactions by initiating new transactions. In particular, the exchange participant discloses the corresponding key numbers in claim 6 and claim 7, respectively. The signature verification algorithm according to claim 2 can verify that the key number is correct after the key number is disclosed and bind the identity of the signer with its signature so that the signature is no longer ambiguous.

Finally, the biggest difference from the existing solutions is based on the transaction verification algorithm described in claim 8. The blockchain transaction in the invention does not need to include the equivalent blockchain currency of the exchange contract in the transaction, and the application range can be greatly improved. The impossibility of tampering with the blockchain is heavily applied, so that the transaction status is unchangeable. And the transactions in claim 6 and claim 7 may publicly verify the key number. In general terms rights 1-8 fulfill the need for a fair exchange of contract endorsements in an internet environment and a blockchain based implementation can make the exchange publicly verifiable and tamper-proof.

Drawings

FIG. 1 is a diagram of a system model in accordance with a preferred embodiment of the present invention;

FIG. 2 is a diagram of a transaction model of the present invention;

fig. 3 is a transaction flow diagram of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be described in detail and clearly with reference to the accompanying drawings. The described embodiments are only some of the embodiments of the present invention.

The technical scheme for solving the technical problems is as follows:

the frame of the system is described below in conjunction with fig. 1.

The initiator: as an initiator of the protocol, the initiator selects a key number of the initiator and generates a corresponding key number hash value, generates a fuzzy signature through a fuzzy signature algorithm, and sends the fuzzy signature to a receiver.

The receiver: after receiving the fuzzy signature of the initiator, the receiver checks the signature correspondingly, and if the signature passes the corresponding check, the receiver generates the fuzzy signature of the receiver as the initiator according to the protocol requirement and sends the fuzzy signature to the initiator.

Block chains: and when the initiator and the receiver both receive the fuzzy signature of the other party, generating corresponding blockchain transactions according to the key number hash value of the other party. The blockchain node packages the transactions for uplink. The issuer will initiate a transaction of the passkey number at the open stage in order to redeem the amount in the blockchain transaction. In the verification stage, the algorithm reads the state of the blockchain transaction to complete verification.

The bitcoin transaction model of the present invention is described in further detail below with reference to fig. 2. The method comprises the following specific steps:

the txcommt committed transaction herein can be redeemed in two ways, one by the recipient through the disclosure of a corresponding key number (key) and one by the exchange originator after a certain time through its own signature. For purposes of illustration, this section assumes that the exchange is initiated by Alice and received by Bob. Assuming Alice prepares a transaction input of sufficient amount In advance, the transaction process is as shown In FIG. 2, In TxCommit transaction, where its input is enough UTXO transaction prepared In advance for the exchange initiator, referenced by TxCommit, In-script unlocks the transaction for the initiator by its own signature, UTXO is used, Out-script is the condition for using TxCommit output, one is to provide k so that K (k) ═ f is satisfied, one is to satisfy ver by providing it after time t_A(body,σ₂) The signature of (c) redeems the transaction output of txcommt. Val represents the amount of the transaction output and Tlock represents the lock time for the transaction output.

The transaction flow of the present invention is further described in detail with reference to fig. 3, which specifically includes the following modules and steps:

1) bilinear pairings:

let the security parameter be l, select the large prime numbers p and q (q | p-1, q length l-bit). G₁Is a q-order addition group, G₂Is a q-factorial group. G is G₁The generator of (1). If mapping e: G₁×G₁→G₂The following properties are satisfied and are called bilinear pairs:

bilinear: for any a, b ∈ Z_q，P,Q∈G₁P and Q are additive groups G₁Any element in (b) is e (P, Q) ═ e (aP, bQ)^ab。

Non-degradability: presence of P, Q ∈ G₁，e(P,Q)≠1。

Calculability: for any P, Q ∈ G₁There is an efficient algorithm to compute e (P, Q).

2) And (3) concurrent signature algorithm:

the specific construction of the concurrent signature algorithm based on bilinear pairings (SETUP, ASIGN, averfy, VERIFY) is as follows:

the system sets up that given a security parameter l, large prime numbers p and q (q | p-1, q length l-bit) are chosen. G₁Is a q-order addition group, G₂Is a q-factorial group. G is G₁The generator of (1). Bilinear mapping e G₁×G₁→G₂. Two cryptographically secure hash functions H₁，H₂：{0,1}^*→Z_q. The domains S, F, K are defined as S ≡ F ═ Z_q，K＝{0,1}^*Private key x_iRandomly from Z_qTo select. Public key X_i＝x_iG. Fuzzy signature-the algorithm will be<X_i,X_j,x_i,f,M>As an input. Wherein X_i，X_j≠X_iIs a public key. x is the number of_i∈Z_qIs X_iThe corresponding private key. F ∈ F is a hash value corresponding to the key number. M is the message to be signed. The algorithm selects a random number r epsilon Z_qAnd the following operations are carried out:

h＝H₂(e(rG,fX_j))||M) (7)

h₁＝h-fmod q (8)

s＝r-h₁x_imod q (9)

algorithm output σ ═<s,h₁,f>. Wherein H₂For cryptographically secure hash functions, h is associated with the message

Hash value of h₁And s is a parameter for subsequent verification of the fuzzy signature.

Fuzzy signature verificationIt is verified that the algorithm will be expressed as S<σ,X_i,X_j,M>As an input. Wherein σ ═<s,h₁,f>. And (3) checking an algorithm:

h₁+f＝H₂(e(sG+h₁X_i,fX_j)||M) (10)

signature verification algorithm to<k,S,R>As an input. Wherein k ∈ Z_qIs the corresponding key number. R ═ kx_i ^-1G. And (3) checking an algorithm:

f＝H₁(k) (11)

e(R,X_i)＝e(G,G)^k (12)

H₁r is a parameter for the authentication key number k, which is a cryptographically secure hash function.

3) A fair switching scheme:

a block chain based fair switching scheme. Without loss of generality, Alice is used as the initiator of the protocol, and Bob is used as the responder of the protocol. Public and private key pair of Alice<x_A,X_A>Public and private key pair of Bob<x_B,X_B>。

The scheme is divided into four stages, namely a fuzzy signature exchange stage, a transaction stage, an open stage and a transaction verification stage. The details are as follows.

Fuzzy signature exchange stage: alice selects a random number k_A∈Z_qAs a critical number. And calculating f ═ H₁(k_A)。R_A＝k_Ax_A ^-1G. Alice runs the ASIGN algorithm. Input device<X_A,X_B,x_A,f,M>To obtain a fuzzy signature sigma_A＝<s,h₁,f>. Will be provided with<σ_A,R_A>Sent to Bob together.

When Bob receives the fuzzy signature from Alice, averfy algorithm is performed. The algorithm input is S ═<σ_A,X_A,X_B,M>. If AVERIFY (σ)_A,X_A,X_BM) TRUE, Bob receives the message and selects a random number k_B∈Z_qAs a critical number.And calculating the key hash value f ═ H₁(k_B)，R_B＝k_Bx_B ^-1G. The ASIGN algorithm is run. Input device<X_B,X_A,x_B,f',M>To obtain a fuzzy signature sigma_A＝<s',h₁',f'>. Will be provided with<σ_B,R_B>Sent to Alice together.

When Alice receives Bob's fuzzy signature, the AVERIFY algorithm is executed. The algorithm input is S ═<σ_B,X_B,X_A,M>. If AVERIFY (σ)_B,X_B,X_AM) TRUE, Alice accepts the message. A transaction stage: after the exchange of the fuzzy signatures is completed, the two parties to the transaction will construct a bitcoin transaction that satisfies the agreement.

The transaction forms used in the article are described in detail herein using bitcoin as an example. These requirements must be met by the script herein, which refers to script opcodes such as literature, since in the schema construction, the redemption of the same UTXO under different conditions, and the time-lock on the UTXO are involved^[24]As shown. One powerful function of bitcoin scripting is flow control, but since bitcoin scripting is stack-based language, logical conditions occur before if.

Initiator Alice creates a transaction in x bitcoins

The ID of the transaction is ID_A. The conditional payment and time lock setting involving the bitcoin will be in the UTXO for the transaction. In the locking script Alice will handle<f'>Where Bob is expected to provide its original image to redeem the output. Specific transaction scripts are as follows in table 1:

TABLE 1

Locking scripts

Table1

Lock script

For this transaction, Bob may release his key number k by releasing his own key number_BTo redeem the transaction, Alice may redeem the transaction after time t with his own signature.

The responder Bob will create a transaction in x bitcoins

The ID of the transaction is ID_B. The conditional payment and time lock setting involving the bitcoin will be in the UTXO for the transaction. In the locked script Bob will set f in it, expecting Alice to provide a corresponding pre-image to redeem the output. The specific transaction script is shown in table 2:

TABLE 2

Locking scripts

Table2

Lock script

For this transaction, Alice releases its key number k_ATo redeem the transaction, Bob can redeem the transaction after time t with his own signature.

And (3) a disclosure stage: if the transaction phase is successfully completed, Alice and Bob will collectively complete the disclosure phase.

Alice quote transaction

And are provided with<Alice’s Sig><k_A>True as an unlocking script, generating a transaction

The transaction ID is recorded as ID'_A. This step is equal to the critical number k of public Alice_AAnd publicly verifying that f is H₁(k_A)。

Bob through ID'_ASearching the transaction, analyzing the unlocking script used by Alice to generate the transaction<Alice’s Sig><k_A>And (6) True. K from which Alice is extracted_A. Bob will sign σ the fuzzy signature received from Alice_AVerification was performed using equation (6):

if the last step of verification passes, Bob transacts by reference

And are provided with<Bob’s Sig><k_B>True as an unlocking script, generating a transaction

The transaction ID is ID'_B. Key number k equivalent to Bob of the publication_BAnd verifying f' ═ H₁(k_B)。

Alice passes ID'_BRetrieve transaction from which Bob's key number k is advanced_B. Alice will sign σ the ambiguity received from Bob_BVerify using equation (6):

a transaction verification stage:

TXVERIFY(<k,S>,<k',S'>,<ID_A,ID_A'>,<ID_B,ID_B'>)

where k represents Alice's key number k_AS represents the set of parameters of Alice<σ_A,X_A,X_B,M>And k' represents the key number k of Bob_BS' represents the parameter set of Bob<σ_B,X_B,X_A,M>. The input to the algorithm is the transaction ID, and when the amount is redeemed with the key hash's primitive, the algorithm outputs True. When redeemed with its signature by the originator of the transaction after a time t determined by the time-lock, the algorithm outputs False. Specifically, from the transaction model diagram of FIG. 2, it can be seen that there are two different possibilities for redeeming the transaction TxCommit. When the transaction is redeemed by disclosing the correct keystone, the new transaction generated we call TxOpen. When the transaction is redeemed after time lock t, by the transaction's originator's own signature, the resulting transaction we call TxReturn. For the sake of brevity of the following description. Let us assume the transaction ID of TxCommit at this time as ID_ARedemption of TxCommit transaction ID as ID_A'。

A secondary algorithm:

Quote(<k,S>,<ID_A,ID_A'>)＝True

checking ID_AWhether the locking script references the key hash value f, ID in S_AWhether the unlock script of' refers to the key number k. If so, the output is True.

Quote(<k',S'>,<ID_B,ID_B'>)＝True

As above. If the values above are all True,

TXVERIFY(<k,S>,<k',S'>,<ID_A,ID_A'>,<ID_B,ID_B'>) And returning True, otherwise, returning False.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The above examples are to be construed as merely illustrative and not limitative of the remainder of the disclosure. After reading the description of the invention, the skilled person can make various changes or modifications to the invention, and these equivalent changes and modifications also fall into the scope of the invention defined by the claims.

Claims (10)

1. A contract signing method based on block chain and fair exchange is characterized by comprising the following steps:

fuzzy signature exchange stage: the initiator and the receiver exchange respective fuzzy signatures according to a concurrent signature algorithm based on bilinear pairings, and verify the fuzzy signatures;

a transaction stage: the initiator and the receiver generate corresponding bitcoin-based blockchain transaction according to the key number hash value in the fuzzy signature of the other party;

and (3) a disclosure stage: the initiator and the receiver disclose the corresponding secret values through blockchain transaction and bind the fuzzy signature;

a transaction verification stage: the exchange will be verified in connection with the blockchain status.

2. The contract signing method based on block chain and fair exchange according to claim 1, wherein in the fuzzy signature exchange stage, the concurrent signature algorithm based on bilinear pairings specifically includes:

the specific construction of the concurrent signature algorithm comprises four steps, specifically system setting, fuzzy signature and fuzzy signature verification, wherein the signature verification comprises the following steps:

the system is set up by giving a safety parameter l, selecting large prime numbers p and q, q | p-1, q length l-bit, G₁Is a q-order addition group, G₂Is a group of q factorials, G being G₁G, bilinear mapping e₁×G₁→G₂Two cryptographically secure hash functions H₁，H₂：{0,1}^*→Z_qThe domains S, F, K are defined as S.ident.F ═ Z_q，K＝{0,1}^*Private key x_iRandomly from Z_qOf (1) public key X_i＝x_iG; fuzzy signature by<X_i,X_j,x_i,f,M>As input, wherein X_i，X_j≠X_iIs a public key, x_i∈Z_qIs X_iCorresponding private key, F belongs to F and is a hash value corresponding to the key number, M is the message to be signed, and the algorithm selects a random number r belongs to Z_qAnd the following operations are carried out:

h＝H₂(e(rG,fX_j))||M) (1)

h₁＝h-f mod q (2)

s＝r-h₁x_imod q (3)

algorithm output σ ═<s,h₁,f>(ii) a Wherein H₂Is a cryptographically secure hash function, h is a hash value associated with the message, h₁S is a parameter for subsequent fuzzy signature verification;

fuzzy signature verification by taking S as<σ,X_i,X_j,M>As input, S is only a parameter set<σ,X_i,X_j,M>For convenience of description, wherein σ ═<s,h₁,f>And checking an algorithm:

h₁+f＝H₂(e(sG+h₁X_i,fX_j)||M) (4)

signature verification by<k,S,R>As input, where k ∈ Z_qIs the corresponding key number, R ═ kx_i ^-1G and R are parameters for verifying the key number k, and the algorithm checks:

f＝H₁(k) (5)

e(R,X_i)＝e(G,G)^k (6)

H₁r is a parameter for the authentication key number k, which is a cryptographically secure hash function.

3. The contract signing method based on block chain and fair exchange according to claim 2, wherein in the fuzzy signature exchange stage, the bilinear pairings specifically include:

let the security parameter be l, select large prime numbers p and q, q | p-1, q length be l-bit, G₁Is a q-order addition group, G₂Is a group of q factorials, G being G₁If e is mapped to G₁×G₁→G₂The following properties are satisfied and are called bilinear pairs:

1) bilinear: for any a, b ∈ Z_q，P,Q∈G₁E (aP, bQ) ═ e (P, Q)^ab(ii) a P and Q are additive groups G₁Any of (1);

2) non-degradability: presence of P, Q ∈ G₁，e(P,Q)≠1；

3) Countable meterCalculability: for any P, Q ∈ G₁There is an efficient algorithm to compute e (P, Q).

4. The contract signing method based on block chain and fair exchange according to claim 3, characterized in that the transaction phase adopts a bitcoin transaction form, specifically:

the redemption can be carried Out In two ways, one is carried Out by a receiver through disclosing a corresponding key number keystone, the other is carried Out by an exchange initiator through a signature of the exchange initiator after a certain time, the exchange is assumed to be initiated by Alice, the exchange is received by Bob, the Alice is assumed to prepare transaction input with enough money In advance, In the TxCommit transaction, the transaction input is prepared for the exchange initiator In advance and has enough UTXO, the transaction is quoted by TxCommit, In-script is used for the initiator to unlock the transaction through the signature of the initiator, UTXO is used, Outscript is used as a condition for using TxCommit output, the other is to provide k, so that K (k) f is satisfied, and the other is carried Out by providing a condition of satisfying ver after the time t_A(body,σ₂) Redeeming the transaction output of TxCommit, Val representing the amount of money of the transaction output, and Tlock representing the lock time of the transaction output.

5. The contract signing method based on block chain and fair exchange according to claim 2, wherein the fuzzy signature exchange stage specifically comprises the following steps:

alice is used as an initiator of the agreement, Bob is used as a receiver of the agreement, and Alice's public and private key pair<x_A,X_A>Public and private key pair of Bob<x_B,X_B>The fuzzy signature switching node is specifically implemented as follows:

alice selects a random number k_A∈Z_qAs a key number, and calculating f ═ H₁(k_A)，R_A＝k_Ax_A ^-1G, Alice runs ASIGN algorithm and inputs<X_A,X_B,x_A,f,M>To obtain a fuzzy signature sigma_A＝<s,h₁,f>Will be<σ_A,R_A>Together sent to Bob;

when Bob receives the fuzzy signature from Alice, the AVERIFY algorithm is executed, and the input of the algorithm is S ═<σ_A,X_A,X_B,M>. If AVERIFY (σ)_A,X_A,X_BM) TRUE, Bob receives the message and selects a random number k_B∈Z_qAs a key number, and calculating a key number hash value f ═ H₁(k_B)，R_B＝k_Bx_B ^-1G, running ASIGN algorithm, inputting<X_B,X_A,x_B,f',M>To obtain a fuzzy signature sigma_A＝<s',h₁',f'>Will be<σ_B,R_B>Sending the data to Alice together;

when Alice receives the fuzzy signature of Bob, AVERIFY algorithm is executed, and the input of the algorithm is S ═<σ_B,X_B,X_A,M>If AVERIFY (σ)_B,X_B,X_AM) TRUE, Alice accepts the message.

6. The contract signing method based on block chain and fair exchange according to claim 5, wherein the specific implementation of the transaction phase specifically comprises: after the exchange of the fuzzy signatures is completed, the two transaction parties construct the bitcoin transaction meeting the agreement;

transaction TxCommit in which initiator Alice creates an x-bit currency_IDAThe ID of the transaction is ID_AConditional payments and time lock settings involving bitcoins will be made in the UTXO of the transaction and Alice will make a lock script<f'>Set therein, Bob is expected to provide its original image to redeem the output;

for this transaction, Bob may release his key number k by releasing his own key number_BTo redeem the transaction, Alice may redeem the transaction after time t with his own signature, and the responder Bob will create a transaction in x bitcoins

The ID of the transaction is ID_BAt UT of the transactionConditional payments and time lock settings in XO will involve bitcoins, and Bob will hold in the lock script<f>Set therein, it is expected that Alice provides a corresponding pre-image to redeem the output; for this transaction, Alice releases its key number k_ATo redeem the transaction, Bob can redeem the transaction after time t with his own signature.

7. The contract signing method based on block chain and fair exchange according to claim 6, characterized in that the publishing phase specifically comprises the following steps:

if the transaction phase is successfully completed, Alice and Bob will jointly complete the disclosure phase;

alice quote transaction

And are provided with<Alice’s Sig><k_A>True as an unlocking script, generating a transaction

The transaction ID is recorded as ID'_AThis step is equal to the public Alice's key number k_AAnd publicly verifying that f is H₁(k_A)；

Bob through ID'_ASearching the transaction, analyzing the unlocking script used by Alice to generate the transaction<Alice’s Sig><k_A>True, k from which Alice's is extracted_A. Bob will sign σ the fuzzy signature received from Alice_AVerification was performed using equation (6):

if the last step of verification passes, Bob transacts by reference

And are provided with<Bob’s Sig><k_B>True as an unlocking script, generating a transaction

The transaction ID is ID'_B. Equivalent to the disclosure k_BAnd verifying f' ═ H₁(k_B)，

Alice passes ID'_BRetrieve transactions, extract Bob's key number k from them_B. Alice will sign σ the ambiguity received from Bob_BVerify using equation (6):

8. the contract signing method based on block chain and fair exchange according to claim 7, wherein the transaction verification stage specifically comprises:

TXVERIFY(<k,S>,<k',S'>,<ID_A,ID_A'>,<ID_B,ID_B'>)

where k represents Alice's key number k_AS represents the set of parameters of Alice<σ_A,X_A,X_B,M>And k' represents the key number k of Bob_BS' represents the parameter set of Bob<σ_B,X_B,X_A,M>The input to the algorithm is the transaction ID, and when the amount is redeemed with the key hash's primitive, the algorithm outputs True; when redeemed by the originator of the transaction with its own signature after a time t determined by the time-lock, the algorithm outputs False, for the purposes of redeeming the transaction txcomp, there are two different possibilities, when the transaction is redeemed by disclosing the correct keystone, the new transaction generated is called TxOpen; when the transaction is redeemed after time lock t, by its originator's own signature, the resulting transaction is called TxReturn; let the transaction ID of TxCommit be ID at this time_ARedemption of TxCommit transaction ID as ID_A'；

A secondary algorithm:

Quote(<k,S>,<ID_A,ID_A'>)＝True

checking ID_AWhether the locking script references the key hash value f, ID in S_A' whether the unlocking script refers to a key number k or not, and if yes, the output is True;

Quote(<k',S'>,<ID_B,ID_B'>)＝True

in the same way, if the above are True,

TXVERIFY(<k,S>,<k',S'>,<ID_A,ID_A'>,<ID_B,ID_B'>) And returning True, otherwise, returning False.

9. A contract signing system of block chain and fair exchange based on the method of any one of claims 1-8, comprising: the initiator: as an initiator of the protocol, firstly selecting a key number of the initiator, generating a corresponding key number hash value, generating a fuzzy signature through a fuzzy signature algorithm, and sending the fuzzy signature to a receiver;

the receiver: after receiving the fuzzy signature of the initiator, the receiver checks the signature correspondingly, and if the signature passes the corresponding check, the receiver generates the fuzzy signature of the receiver as the initiator according to the protocol requirement and sends the fuzzy signature to the initiator;

block chains: and when the initiator and the receiver both receive the fuzzy signature of the other party, generating corresponding blockchain transactions according to the key number hash value of the other party. The blockchain node packages the transactions for uplink. The issuer will initiate a transaction of the passkey number at the open stage in order to redeem the amount in the blockchain transaction. In the verification stage, the algorithm reads the state of the blockchain transaction to complete verification.

10. A medium storing computer executable instructions for implementing the method of any one of claims 1 to 8 when executed.

Images