CN112418834A

CN112418834A - Safe mixed currency processing method and system compatible with bit currency and supporting down-link transaction

Info

Publication number: CN112418834A
Application number: CN202011129623.0A
Authority: CN
Inventors: 谢皓萌; 闫峥; 费书凡
Original assignee: Xidian University
Current assignee: Xidian University
Priority date: 2020-10-21
Filing date: 2020-10-21
Publication date: 2021-02-26

Abstract

The invention belongs to the technical field of computer application, and discloses a safe mixed currency processing method and system compatible with bit currency and supporting down-link transaction. The addresses of the sender and the receiver of the bitcoin are mixed by the coin mixing server for a period of time, so that the analyst cannot distinguish the connection between the sender and the receiver. The invention enhances the anonymity of the bit coins and improves the safety of the mixed coin processing method. The invention realizes the DoS attack resistance: the method effectively prevents malicious users from repeatedly joining and then exiting the protocol, and maliciously occupies bitcoin resources of the anonymous server. The invention realizes the Sybil attack resistance: the method and the device effectively prevent malicious users from creating a plurality of pseudonym joining protocols, reduce the occupation ratio of real users in anonymous concentration, and reduce the difficulty in analyzing the anonymity of target users. The invention realizes the collusion attack resistance, thereby effectively preventing the benefit of third parties from being infringed by collusion among malicious users. The protocol supports the payment under the chain, and is beneficial to the expandability of the bitcoin.

Description

Safe mixed currency processing method and system compatible with bit currency and supporting down-link transaction

Technical Field

The invention belongs to the technical field of computer application, and discloses a safe mixed currency processing method and system compatible with bit currency and supporting offline transactions.

Background

At present: bitcoin (BTC) is a new distributed digital currency created by Satoshi Nakamoto in 2008, which profoundly affects the financial industry and the entire society. Under the great popularity of bitcoin, anonymity (non-connectability) is one of its most attractive functions. The anonymity of the bitcoin mainly depends on a pseudonymous mechanism, and the connection between the true identities of the payer and the payee is theoretically cut off, so that the privacy of the transaction is protected. In addition, payers and payees may change their pseudonyms from time to disguise their identities. However, more and more research has shown that bitcoins are actually much less anonymous than envisaged by the present invention. Bitcoin blockchains are public accounts that store all transactions indicating the flow of funds from payer to payee, and may reveal associations between their pseudonyms. Once a pseudonym is associated with its true identity, all related pseudonyms and transactions may be associated with the party, resulting in anonymization failure. The mixed currency processing method enables one party in a bitcoin system (the mixed currency server) to be responsible for receiving bitcoins from a group of payers and then mix the relationships between the parties to the transaction before resending the bitcoins to the final payee. As such, bitcoin analysts are unable to infer the connection between the payee and the actual payer from a series of transactions in the public ledger. It is critical that a mixed currency processing method should prove sufficiently secure that even a mixed currency server has no ability to analyze the anonymity of all related transactions. One of the biggest challenges facing mixed-currency processing methods in bitcoin is compatibility. The invention therefore first outlines how a bitcoin works.

Trading: transaction of bitcoin records the fund from the original transaction T_originTo fulfillment transaction T_fulfillIs transferred. The redemption conditions in the original transaction dictate the conditions that must be met using the bitcoin in the transaction. The fulfillment transaction requires the provision of script data that satisfies the redemption conditions in the original transaction to cause the transfer of the bitcoin from the original transaction to the fulfillment transaction. This process consumes a certain amount of transaction fee (T)_tran) For rewarding miners to confirm the transaction on the blockchain. Each transaction may include a plurality of inputs and a plurality of outputs, each output being independent of the other, wherein the amount may be transferred to a separate fulfillment transaction. Funds in one output of the original transaction can only be transferred to one input of the fulfillment transaction.

Redemption conditions commonly used in current bitcoin transactions: hash condition (h (a)): this condition dictates that fulfillment of the transaction must reveal the original image of the hash value h (a) in order to transfer the bitcoin in the original transaction.

Time condition (T): the bitcoin in the original transaction cannot be transferred until after the time T has expired.

Signature condition (X): this condition dictates that fulfillment transactions must be signed by a particular user X using the Secp256 elliptic curve and using the elliptic curve signature algorithm (ECDSA) to divert bitcoins in the original transaction.

Hash time Condition (h (a) V): the original transaction has a hash condition and a time condition, and it is specified that one party can take the bitcoin before the time T expires or return the bitcoin to the other party after the time T expires by revealing the original image of the hash value h (a).

Both-side proxy condition (X ^ Y): this condition states that the fulfillment transaction must be signed by both parties (X, Y) to transfer the bitcoin in the original transaction. In fact, in order to prevent one party from being permanently lost and thus unable to redeem the bitcoin in the original transaction, a time condition (T) is usually also specified in the two-party proxy transaction, i.e. after the time T has expired, the other party can redeem all the bitcoins. The down-link transaction is heavily dependent on both party agent conditions. The down-link transaction consists of three steps: first, open channel: that is, one party (X) opens the payment channel by storing enough tokens on a two-party proxy transaction that is placed on the blockchain. And step two, payment: whenever X wants to pay Y bits, X constructs a fulfillment transaction for a two-party proxy transaction, and sends this transaction signature directly to Y. This transaction is not recorded on the blockchain, so it is a down-chain transaction. The amount of the bitcoin in the transaction is equal to the sum of all previous payment amounts and the payment amount. All of the down-link transactions held by Y are fulfillment transactions of both agent transactions, so eventually only one down-link transaction can be validated by the blockchain. Step three, closing a channel: before time T expires, X and Y may jointly construct and issue a new fulfillment transaction to redistribute bitcoins in both party proxy transactions; or Y may sign and publish the latest down-chain transaction onto the blockchain. After the time T expires, X can redeem all of the bitcoins in the two-party proxy transaction. Therefore, the invention can process a large number of off-chain transactions by using two transactions recorded on the blockchain, thereby greatly reducing the load of the blockchain.

The mixed currency service method comprises the following steps: the existing mixed coin processing method can be divided into two categories, namely a centralized mixed coin processing method and a distributed mixed coin processing method.

(1) The centralized mixed coin processing method requires an entity as a mixed coin server to obtain the bit coins from the payer, and then transmits the bit coins with equal amount to the payee after the address is disordered. Maxwell first introduced the mixed banknote processing method into bitcoin system and proposed the mixed banknote processing method named coinsswap. The protocol realizes fair transaction by utilizing Hash time condition transaction, but because a payer wants to inform the address of a payee to the mixed coin server in advance, anonymity cannot be guaranteed, and the payer can easily participate in and give up the protocol, occupy bit coin resources of the mixed coin server and only have the cost of a small amount of transaction fee given to miners during participation. Then, Mixcoin is proposed, which requires that the coin-mix server sends a commitment message to the payer before starting the formal transaction, and if the coin-mix server does not deliver bitcoins according to the commitment to the payee, the payer can publish the commitment, thereby reducing the credit of the coin-mix server. Therefore, the protocol can only audit the malicious behavior of the mixed currency server, and can not completely prevent the mixed currency server from stealing bit currency of the user, so that fair transaction can not be guaranteed. Blindcoin is used as an improved mixed coin processing method, and the method of blind signature is used for solving the anonymity problem aiming at the mixed coin server. The payer encrypts the address of the payee and transmits the encrypted address to the mixed coin server, the mixed coin server blindly signs the encrypted address and publishes the signed message, the payee blindly removes the signed message to obtain the address of the payee with the signature of the anonymous server and delivers the address to the mixed coin server, and then the mixed coin server transfers the bit coin to the payee. But this scheme, like Mixcoin, does not guarantee fair trading. The BSC trades using blind signatures and hash time conditions while guaranteeing anonymity and fairness, but it is not bitcoin compatible. TumbleBit improves BSC, and utilizes RSA encryption homomorphism property, firstly, the mixed coin server uses private key to make RSA encryption on the off-line transaction sent to the payee, after the payee receives the transaction, the transaction is blinded by randomly selecting blind factor, and the processed transaction is delivered to the payer. The payer sends a certain amount of bit coins and the transaction to the mixed coin server to request the mixed coin server to decrypt, the mixed coin server decrypts the transaction after receiving the bit coins and sends the transaction to the payer, and the mixed coin server cannot identify the relationship between the transaction and the original transaction because the transaction is blinded. The payee finally obtains the decrypted offline transaction from the payer, so as to obtain the bitcoin from the mixed coin server.

(2) The distributed mixed currency processing method requires cooperation to construct a multi-input multi-output transaction, so that an analyst cannot analyze from the transaction which input is associated with at all. In the distributed mixed coin processing method, no third-party entity acts as a mixed coin server. Maxwell first proposed a prototype of the distributed mixed banknote processing method, named coinjain. Treatment methods following treatment methods, CoinShuffle was proposed. This protocol details how payee information is exchanged between multiple payers in an anonymous fashion. The method comprises the steps of firstly ordering the payers, then sequentially encrypting the addresses of the payers corresponding to the payers by the payers with the public keys of all the payers behind the serial numbers of the payers, and then sending the encrypted addresses to the next payers arranged in sequence. The next payer decrypts the message after receiving the message, and then sends the encrypted address of the next payer and the decrypted message to the next payer together until the last payer obtains the information of all the payees. The last payer builds a transaction based on this information. This protocol has a cost of 0 to launch a DoS attack and a large communication overhead, since the payer can freely choose to join or abort the transaction. In order to optimize the communication overhead, CoinShuffle + + is then proposed, but the security is not improved. To solve the security problem in the distributed hybrid coin server, basiias et al propose Xim. This agreement requires that the payer pay a transaction fee first when participating in the agreement, thus preventing the DoS attack from occurring to some extent.

The defects of the prior art are mainly three aspects:

(1) malicious users in existing protocols can easily launch DoS attacks. Some protocols require that the coin-mixing server prestores a certain amount of bit coins in a two-party agent condition transaction before coin mixing, and the coin-mixing server can only recover the bit coins after the time delta T expires. But a malicious user may give up the agreement after requiring the pre-deposit of the money mixing server, and thus may lock the pre-deposit of the money mixing server for delta T time. While this process requires the user to consume a certain amount of transaction fee, the common transaction fee to date is only 1USD per stroke. A powerful, funding DoS attacker can easily force the hybrid server out of service by repeatedly joining and then aborting the protocol. However, most mixed currency processing methods are not effective against this type of DoS attack, which poses a serious threat to the security of the mixed currency processing method.

(2) The existing protocol cannot effectively resist collusion attack. That is, the payer and the payee are not trusted, and a malicious payer or payee can collude with the mixed coin server to cheat the corresponding payee or payer. Although discussed in TumbleBit, it does not consider that the payer and the money mixing server together cheat the payee, i.e., tell the payee that he has given to the payer a token for exchanging bitcoins, with the result that the payee eventually does not receive the money. On the contrary, the payee can cheat the payer with the mixed currency server, that is, the payer is told that the payer does not receive the token, and the payer is required to send the bitcoin again, so that the payer loses the bitcoin. Since there is no evidence of malicious behavior in previous protocols, honest users have difficulty clarifying themselves when exposed to collusion attacks.

(3) Existing protocols do not support payment down-link. Current advanced bitcoin transaction privacy solutions place a significant load on the blockchain because all transactions are published on the blockchain. And one solution to the problem of bitcoin blockchain scalability is under-chain payment. However, the conventional coin mix processing method does not consider this problem. Although TumbleBit studied this problem, it requires that all payers must comply with the agreement. Since the payee needs the assistance of all payers corresponding to the payee to take out bitcoins from the latest linked transaction, if one payer terminates the agreement, the payee may lose all bitcoins.

Through the above analysis, the problems and defects of the prior art are as follows:

(1) the malicious user in the existing protocol easily starts DoS attack, and the security of the mixed currency processing method is seriously threatened.

(2) The existing protocol cannot effectively resist collusion attack, and when suffering collusion attack, honest users are difficult to prove themselves.

(3) Existing protocols do not support payment down-link.

The difficulty in solving the above problems and defects is:

(1) the above problems are all premised on ensuring anonymity and fair trading of the protocol. In order to ensure anonymity, the invention elaborately designs a zero-knowledge proving method, and ensures that other people except the payer and the payee cannot know the relevance of the transaction. To ensure a fair trade, each step of the protocol of the present invention needs to be carefully considered, and an improper setting may result in a loss of funds to the participants.

(2) In order to improve the capability of resisting the DoS attack, the invention utilizes the Hash time conditional transaction compatible with the bitcoin to lock the bitcoin of the payer. In order to resist collusion attack, the invention needs to consider that each communication is traceable in designing a scheme, and in order to realize offline payment, the invention utilizes the bitcoin multiple-input multiple-output transaction. Each technology is not difficult to implement individually, but after considering the anonymity and the fair trade, the logical property of the protocol is very strict and the front and back relations are very tight.

(3) The operation of the bit currency intelligent contract is very limited, and only the signature algorithm and the hash algorithm in cryptography are supported, so that in order to simultaneously consider the compatibility of the bit currency and ensure the characteristics of anonymity, safety and the like, a plurality of cryptography operations need to be carried out outside a chain, and the design of the scheme needs to be very ingenious.

The significance of solving the problems and the defects is as follows:

(1) the DoS attack resistance of the hybrid server is improved, and the service capability and the fluency of the hybrid server can be enhanced. When the user requires the mixed coin service, the bit coin resource can be used for carrying out the timely mixed coin operation.

(2) The method resists collusion attack, and the two participants can not collude mutually to infringe the benefit of a third party, thereby being beneficial to protecting the property of honest participants and improving the safety of the protocol.

(3) And the payment under the chain is supported, so that a large amount of transactions can be carried out under the chain, block chain resources are not occupied, the load of a bitcoin network is greatly reduced, and the efficiency of confirming the transactions is improved.

Disclosure of Invention

Aiming at the problems in the prior art, the invention provides a safe mixed currency processing method and a safe mixed currency processing system compatible with bit currency and supporting the offline transaction, which can support the offline payment under the condition of being compatible with the bit currency, improve the efficiency of confirming the transaction and effectively resist DoS attack and collusion attack.

The invention is realized in such a way that the bitcoin-compatible safe mixed coin processing method supporting the chain transaction comprises an agent stage, a payment stage and a decision stage.

In the agent stage, the payer and the mixed coin server prestore a certain amount of bit coins into the agent transaction on the blockchain;

in the payment phase, the payer or the mixed currency server can transmit the bitcoin to the mixed currency server or the payee through the offline payment;

the decision stage can be divided into a refund stage and a discount stage according to different behaviors of participants; if all participants comply with the protocol, entering a discount stage; if the payee does not receive the pre-payment of the mixed coin server within a certain time, the payer starts a refund mechanism. Further, the secure mixed currency processing method and system supporting the down-link transaction which are compatible with the bitcoin relate to a three-party payer, a payee and a mixed currency server; wherein the mixed currency server is responsible for receiving the bit currency of the payer, forwarding the bit currency to the payee by using different addresses, and then charging a certain amount of service fee (F)_mix) (ii) a In the method, each party has a long-term key Pair (PK) associated with its own identity_p，SK_p). As a mechanism for profit, the mixed currency server needs to ensure the credit value of the public key; the method supports two system models, namely a traditional model and a model under a chain; in the traditional model, each payer can only send one transaction in one mixed currency period, each payee can only accept one transaction in one mixed currency period, and the number of the payers is equal to that of the payees; in the under-chain model, each payer can send multiple transactions in a mixed currency period through under-chain transactions, each payee can receive multiple transactions in a mixed currency period, the number of the payers can be different from the number of the payers, namely, one payer can pay for multiple payers, and one payee can also receive the payment of multiple payers.

Further, in the transaction mixed currency service information processing method under the safety support chain, in the proxy stage, a payer and a mixed currency server prestore a certain amount of bit currency into proxy transaction on the block chain, and the payer firstly opens a payment channel with the mixed currency server and stores QBTCs into the block chain; after the payer finishes payment and the mixed coin server receives the zero knowledge proof pi from the payee, the mixed coin server also opens a payment channel with the relevant payee and stores the PBTCs to the block chain.

Further, the bit currency compatible safe mixed currency processing method supporting the chain down transaction is characterized in that in the payment stage, a payer or a mixed currency server can transmit the bit currency to the mixed currency server or a payee through the chain down payment, the payer can execute at most q times of payments, and each payment comprises alpha + F_mixBTCs，(q×(α+F_mix) Q is less than or equal to Q, and Q is 1 in a traditional model); with each payment, the payer transmits an encrypted token H (Tn) to the hybrid server; at the same time, the payer provides the payee with a token-based zero-knowledge proof pi (Tn) for convincing the mixed currency server that a certain payer has already given alpha + F_mixThe BTCs are passed to the mixed currency server, but the identity of the payer is not revealed; after receiving expected P different zero knowledge proofs pi (Tn), the payee generates P temporary addresses, sends the P different zero knowledge proofs and the addresses to the coin mixing server, and the coin mixing server verifies that the zero knowledge proofs are correct and then transmits the zero knowledge proofs to each temporary address to transmit alpha BTCs (P x alpha is less than or equal to P, and P is 1 in the traditional model).

Further, the decision stage of the information processing method of the safety support chain down transaction mixed coin service can be divided into a refund stage and a discount stage according to different behaviors of participants, if all the participants comply with the agreement, the decision stage is entered into the discount stage, firstly, the mixed coin server closes a payment channel between the mixed coin server and a payer, and the payment channel is retrieved through the discount transaction (qx (alpha + F)_mix) The BTCs, then the payee closes the payment channel between the payee and the mixed coin server and requests for the p multiplied by alpha BTCs through cash withdrawal transaction; if the payee has not received the pre-payment from the mixed-currency server within a certain time, the payer may initiate a refund mechanism to refund the paid bitcoin via a refund transaction, which will cause the payer to reveal the corresponding token Tn if the payer has received the pre-payment from the mixed-currency server at the payeeIf a refund mechanism is activated, the mixed currency server can immediately use the refund transaction to refund the prepaid bitcoin from the payee based on the token Tn revealed by the payer.

The algorithm involved in each stage is described in detail below:

table defines the symbols used in the method:

TABLE 1 symbol definitions

Firstly, the coin mixing server sets a security parameter lambda and sets a time point T, T executed by a protocol according to the block height₁，T₂Where T is used to limit the period of the down-link payment between the payer and the escrow server. And T₁And T₂Time conditions in two-party proxy transaction between the payer and the mixed coin server and between the mixed coin server and the payee are respectively specified; then, the mixed currency server sets a set Λ for recording used payments and specifies two hash functions H (-) and G (-) where H (-) is collision resistant; the coin-mixing server then sends the parameters (lambda,_T，T₁，T₂h (-) G (-) this process is only performed once at system initialization, Λ is reset every time a new mixing cycle is entered.

Further, the safety support chain down transaction mixed currency service information processing method comprises the agent stage: each payer A and payee B establishes a two-party proxy transaction T with the money-mixing server M_escr(A，M)At the start of a new cycle, a payer first opens the payment channel and stores QBTCs in the two-party proxy transaction T_escr(A，M)In the following payment phase, the payer performs at most q payments, each payment containing α + F_mixBTCs wherein Q is ≥ Qq×(α+F_mix) In the conventional model, q is 1, at T_escr(A，M)The bitcoin in (A) can be transferred to a fulfillment transaction signed by both the payer and the mixed coin server, or at time T₁And later redeemed by payers, and similarly, the payee requires the mixed currency server to open p payment channels each storing alpha BTCs to the time condition T after receiving the desired p zero knowledge proofs from the payers in the following payment phase₂Specified two-party proxy transaction T_{escr(M，B)(k)}Wherein k is more than or equal to 1 and less than or equal to P, and P is more than or equal to P multiplied by alpha, and P is 1 in the traditional model;

further, the payment phase of the information processing method for the safety support under-chain transaction mixed currency service comprises the following steps: at proxy transaction T_escr(A，M)After being confirmed by the blockchain, the payer pays the mixed currency server through the offline transaction before the time T, wherein T₁> T. When A wants to make a new payment, he first chooses a randomly_j∈{0，1}^λAnd generate a_jHash value h of₁(j)＝H(a_j) Where j is ∈ [1, q ]]J-1 represents the number of payments that have been previously made, a_jRefers to the token described in the agreement overview phase, and the payer then builds and signs a new T_escr(A，M)To fulfill the transaction name of a transfer transaction

The transaction contains j transaction outputs, which are associated linked payments generated by the payer; each output containing α + F_mixBTCs and limited by a temporal hash condition, each bitcoin in the output can be signed by an owning payer and h is revealed₁(i) Redemption of fulfillment transactions for a pre-image, where i e [1, j ]]Or at time t₁Is later redeemed by the coin-in-hybrid server, where T₁＜t₁. The payer will

And h₁(j) Passing to a mix-up server, mix-up server detection

If it is correct, if not, the corresponding h is discarded₁(i)；

The mixed currency server stops receiving the chain payment of the payers after the time T expires, reveals all valid hash values received from all payers in the period, constructs a Merck tree (MTree) with the root node being Merck root (MRoot), and signs the Merck tree and a time stamp to obtain Sig_M(MTree, timestamp) and publish it on all available public resources for verification by all payers;

after receiving the MTree, payer a first checks whether all hash values h₁(i)(i∈[1，j]) Are all contained in MTree; if not, payer A will be at the money mixing server

Sending the payment to the block chain and withdrawing the corresponding payment; if so, the payer will execute a proof-of-generation algorithm to construct j zero-knowledge proofs. Each zero knowledge proves pi_iThe function of (1) is to persuade the coin-mixing server:

(1) there is a payer who has sent a payment;

(2) the payment corresponds to

The output on is not redeemed by the payer or used by the payee;

(3) after the mixed currency server commits to pass the alpha BTCs to the payee, the mixed currency server can redeem them immediately if the payer maliciously cancels the payment;

to generate a zero knowledge proof, the payer first generates h based on MTree₁(i) Authentication ofThe path MPath. Then randomly choose b_i∈{0，1}^λAnd calculate

h₂(i) Will be used to construct the down-link transaction between the escrow server and the payee. The payer further calculates G (i) ═ G (a)_i) The mixed currency server can use g (i) to detect whether to use

The output of the correlation has been used. Finally, the payer builds a proof of zero knowledge for the following statements_iWithout disclosing a_iAnd h₁(i) The method comprises the following steps Known as { G (-), H (-), b)_i，g(i)，h₂(i) MRoot, the payer has a_iAnd satisfies the following conditions:

H(a_i) A leaf of an Mtree with MRoot as the root;

g (i) is correctly calculated, i.e. G (i) ═ G (a)_i)；

h₂(i) Constructed correctly, i.e.

After the certificate is generated, the payer signs h₂(i) And construct the evidence Sig_A(h₂(i) For proving that the relevant payment was generated by payer a. The payer then sends { b }_i，g(i)，h₂(i)，π_i，Sig_A(h₂(i) Etc.) to the corresponding payee B. After receiving the expected p different zero knowledge proofs, the payee sends { b }_k，g(k)，h₂(k)，π_kAnd p different temporary addresses Addr_B(k) For a coin-in-place server, where k ∈ [1, p ]]. If all proofs are correct, and

the mixed coin server and the payee open a payment channel to generate T_{escr(M，B)(k)}And adding g (k) to the set Λ: Λ ═ Λ { (g) (k) }.

To prevent DoS attacks, the payee signs and sends p linked down-link transactions first

For the coin-in-mixture server, k is the [1, p ]]。

Point to T_{escr(M，B)(k)}And contains α BTCs, limited by the hash time condition. Wherein the bitcoin can be signed by a server having the mixed coin and h is disclosed₂(k) Redemption of fulfillment transactions of the original, or at time t₂Is later redeemed by the payee, where t₁＜T₂＜t₂. If the payer passes disclosure h₁(k) The mixed currency server can obtain a_kAnd calculate h therefrom₂(k) Then immediately from T_{escr(M，B)(k)}The bitcoin is redeemed. Is obtained by

Then, the mixed currency server signs and sends p transfer transactions with the same hash time condition

To the payee, where k ∈ [1, p ]]. Upon receiving

Then, the payee is at

And sends a signature message to the payer to tell the payer that he has received the pre-payment from the money-mixing server.

Further, the safety support under-chain transaction mixed currency service information processing method comprises a decision stage: : when the mixed coin server wants to be at T and T₁When the payers ask for the bitcoin from the payers, the decision stage is entered, all participants close the payment channel and redeem/ask for the bitcoin according to the payment condition;

if the payer, the payee and the mixed currency server are all executed according to the agreement, the cashing stage is entered, and the mixed currency server firstly requires to generate a T together with the payer_escr(A，M)Is a discount transaction T_{cash→escr(A，M)}The mixed bank note server uses the request to ask for j x (alpha + F)_mix) BTCs, if the payer is not affiliated, the mixed currency server issues the latest transfer transaction first

Generating a fulfillment transaction T for a transfer transaction_{cash→fund(A，M)(j)}Asking for j × (α + F)_mix) BTCs in T₂Previously, the payee first required the mixed bank note server to jointly generate a T_{escr(M，B)(k)}Fulfillment transaction T_{cash→escr(M，B)(k)}For requesting alpha BTCs, if the money-mixing server is not cooperative, the receiver first issues a transfer transaction

Generating a redemption transaction T for a transfer transaction_{cash→fund(M，B)(k)}Ask for alpha BTCs, considering that the mixed coins server issues at any time

Causing double flowers, the payee needs to monitor the state of the block chain in real time and monitors the state

After release, the payee may release one

Whichever fulfillment transaction is confirmed by the blockchain, the payee will eventually get p × α BTCs;

if the payer is not at t₁Previously received payee's reply or any hash value h (a)_i) Not contained on the MTree, the payer may be referred to as a refund transaction T by issuing another fulfilling transaction name for the transfer transaction_{refund→fund(A，M)(j)}To redeemReturning the bit coin if at T_escr(A，M)No down-link transaction is available after release, and the payer can release T_escr(A，M)Fulfillment transaction T_{refund→escr(A，M)}To redeem all bitcoins; if the payer does not cooperate with the mixed currency server, a rational mixed currency server will always work

Publish to block chain to expect from

Requesting a bitcoin from the bank note; on the other hand, if the payer has been replied to by the payee, the payer is maliciously notified of the reply

The redeemed bitcoin and the mixed coin server can utilize the h revealed by the payer₁(k) Calculating h from the original image of₂(k) Then immediately construct T_{refund→fund(M，B)(k)}From

The bitcoin is redeemed.

By combining all the technical schemes, the invention has the advantages and positive effects that: the invention realizes fair transaction: the amount of the bitcoin obtained by the payee is equal to the amount sent by the payer, and neither party can steal the bitcoin during the transaction. The invention realizes anonymity: others (including the money-mixing server) other than the transaction payer and the payee are unaware of the association between the transaction parties. The method realizes the support of offline transaction: if a plurality of transactions exist between the payer and the mixed coin server or between the mixed coin server and the payee, only the final state of the initial state of the transaction needs to be recorded on the block chain, and each transaction does not need to be published, so that the load of the bit coin block chain is greatly reduced. The invention realizes the compatibility of bitcoin: although the bitcoin only supports limited operations, the mixed-coin processing method can be effectively applied to bitcoin scenes. The invention realizes collusion attack resistance: when collusion attack occurs, the mixed currency processing method can ensure that honest users cannot lose bitcoins. The invention realizes the DoS attack resistance: the mixed coin processing method can effectively prevent malicious users from repeatedly joining and exiting the protocol and maliciously occupying the bit coin resources of the mixed coin server. The invention realizes the Sybil attack resistance: the mixed currency processing method effectively prevents malicious users from creating a plurality of pseudonym joining protocols, reduces the occupation ratio of real users in anonymous concentration, and analyzes the anonymity of target users.

The present invention compares the existing work, and the comparison result is shown in table 2.

TABLE 2 comparison of coinage processing methods

Means TumbleBit satisfies this feature only if all payers comply with the agreement;

2. the larger the number in this term, the stronger the DoS attack resistance.

[1]G.Maxwell，“CoinSwap:Transaction Graph Disjoint Trustless Trading”， Bitcoin Forum，2013.

[2]J.Bonneau，A.Narayanan，A.Miller，J.Clark，J.A.Kroll and E.W. Felten，“Mixcoin:Anonymity for Bitcoin with Accountable Mixes”，Financial Cryptography and Data Security，pp.486-504，2014.

[3]L.Valenta，B.Rowan，“Blindcoin:Blinded，Accountable Mixes for Bitcoin”，Financial Cryptography and Data Security，pp.112-126，2015.

[4]E.Heilman，F.Baldimtsi and S.Goldberg，“Blindly Signed Contracts: Anonymous On-Blockchain and Off-Blockchain Bitcoin Transactions”，Financial Cryptography and Data Security，pp.43-60，2016.

[5]E.Heilman，L.AlShenibr，F.Baldimtsi，A.Scafuro and S.Goldberg， “TumbleBit:An Untrusted Bitcoin-Compatible Anonymous Payment Hub”， Network and Distributed System Security Symposium，2017.

[6]G.Maxwell，“CoinJoin:Bitcoin privacy for the real world”，Bitcoin Forum，2013.

[7]T.Ruffing，P.M.Sanchez and A.Kate，“CoinShuffle:Practicle Decentralized Coin Mixing for Bitcoin”，European Symposium on Research in Computer Security，vol.8713，pp.345-364，Sep.2014.

[8]T.Fuffing，P.M.Sanchez and A.Kate，“P2P Mixing and Unlinkable Bitcoin Transactions”，Network and Distributed System Security Symposium， 2017.

[9]G.Bissias，A.P.Ozisik，B.N.levine and M.Liberatore，“Sybil-Resistant Mixing for Bitcoin”，Proceedings for the 13th Workshop on Privacy in the Eletronic Society，pp.149-158，Nov.2014.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings used in the embodiments of the present application will be briefly described below, and it is obvious that the drawings described below are only some embodiments of the present application, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a flowchart of a method for processing information of a secure support chain down-link transaction mixed currency service according to an embodiment of the present invention.

Fig. 2(a) is a schematic diagram of a conventional model provided in an embodiment of the present invention.

Fig. 2(b) is a schematic diagram of a model under a chain according to an embodiment of the present invention.

FIG. 3 is a schematic diagram of three-stage execution of a method for processing information of a transaction mix-up service under a security support chain according to an embodiment of the present invention

Fig. 4 is a schematic diagram of a transaction flow provided by an embodiment of the invention.

Fig. 5 is a detailed schematic diagram of an information processing method of a transaction mixed currency service under a security support chain according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is further described in detail with reference to the following embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

Aiming at the problems in the prior art, the invention provides a safe mixed currency processing method and a system model compatible with bitcoin and supporting the offline transaction, and the invention is described in detail with reference to the attached drawings.

As shown in fig. 1, the method for processing the information of the transaction mixed currency service under the security support chain provided by the invention comprises the following steps:

s101: in the agent stage, the payer and the mixed coin server prestore a certain amount of bit coins into the agent transaction on the blockchain;

s102: in the payment phase, the payer or the mixed currency server can transmit the bitcoin to the mixed currency server or the payee through the offline payment;

s103: the decision stage can be divided into a refund stage and a discount stage according to different behaviors of participants; if all participants comply with the protocol, entering a discount stage; if the payee does not receive a prepayment from the mixed currency server within a certain time, the payer may initiate a refund mechanism.

The technical solution of the present invention is further described below with reference to the accompanying drawings.

Processing method the system model of the present invention is shown in fig. 2, involving three parties, a payer, a payee and a mixed currency server, respectively. Wherein the mixed currency server is responsible for accepting the bit currency of the payer, forwarding the bit currency to the payee by using different addresses, and then charging a certain amount of service fee (F)_mix). In the present protocol, each party has a long-term key Pair (PK) associated with its identity_p，SK_p). As a mechanism for profit, the money mixing server needsGuaranteeing the reputation value of its public key. The protocol of the invention can support two system models, namely a traditional model and a chained model. In the conventional model, each payer can only send one transaction in one mixed-currency period, and each payee can only accept one transaction in one mixed-currency period, and the number of payers is equal to that of payees. In the under-chain model, each payer can send multiple transactions in a mixed currency period through under-chain transactions, each payee can accept multiple transactions in a mixed currency period, the number of the payers can be different from that of the payees, namely, one payer can pay for multiple payees, and one payee can also accept the payment of multiple payers. The model diagrams are shown in fig. 2(a) and 2 (b).

As shown in fig. 3, this protocol is performed in three phases. In the proxy phase, the payer and the mixed currency server prestore a certain amount of bitcoins into proxy transactions on the blockchain. The payer firstly opens a payment channel with the mixed currency server and stores QBTCs on the block chain. After the payer finishes paying and the mixed coin server receives the zero knowledge proof pi from the payee, the mixed coin server also opens a payment channel with the relevant payee and stores the PBTCs on the block chain. During the payment phase, the payer or the mixed currency server can transmit the bitcoin to the mixed currency server or the payee through the chain down-payment. The payer performs at most q payments, each payment comprising alpha + F_mixBTCs，(q×(α+F_mix) Q ≦ Q, 1 in the traditional model). With each payment, the payer transmits an encrypted token H (Tn) to the escrow server. At the same time, the payer provides the payee with a token-based zero-knowledge proof pi (Tn) for convincing the mixed currency server that a certain payer has already given alpha + F_mixThe BTCs are passed to the mixed currency server, but do not reveal the identity of the payer. After receiving P different zero knowledge proofs pi (Tn) sent by the payee, the coin-mixing server transmits P × α BTCs (P × α ≦ P, which is 1 in the conventional model) to the payee. The decision phase can be divided into a refund phase and a discount phase according to different behaviors of participants. If all participants comply with the agreement, the discount phase is entered. First mix the coin clothesThe server closes the payment channel with the payer and asks for (q × (α + F) by discount transaction_mix) BTCs and the payee closes the payment channel with the money mixing server and requests for p x α BTCs by cash-in transaction. If the payee does not receive a prepayment from the mixed currency server within a certain time, the payer may initiate a refund mechanism to refund the paid bitcoin through a refund transaction, which will cause the payer to reveal the corresponding token Tn. If the payer has received the pre-payment from the remix server at the payee, but has also initiated a refund mechanism, the remix server may immediately refund the pre-paid bitcoin from the payee using a refund transaction based on the payer-revealed token Tn.

Fig. 4 depicts all of the transaction flows involved in the protocol. Fig. 5 depicts the execution of the protocol. First, the coin-mixing server sets the security parameters (e.g. 80) according to the time point T, T of the block height setting protocol execution₁，T₂The 500 th block height, the 501 th block height and the 503 th block height, respectively. And two hash functions H (-) and G (-) are specified as SHA256 and SHA1, respectively. The coin-mixing server then sends the parameters (lambda, T)₁，T₂H (-) G (-) this process is only performed once at system initialization. A is re-nulled each time a new mixing cycle is entered. In the following transactions, the invention provides that the amount of each transaction is 1BTC, the service fee is 0.1BTC, the payer A sends 3 transactions in a period, and the payee B receives 2 transactions in the period.

A proxy stage: at this stage, each of payer A and payee B establishes a two-party proxy transaction with the money-mixing server M. At the start of a new cycle, a payer first opens a payment channel and saves 3.3BTCs to a two-party proxy transaction T_escr(A，M)In (1). The payer performs at most 3 payouts in the following payout stage, each of which contains 1.1 BTCs. Likewise, the payee requests the mix bank server to open the payment channels T after receiving the expected 2 zero knowledge proofs from the payers in the following payment phase_{escr(M，B)(k)}(1. ltoreq. k. ltoreq.2), each branchSub-channel storage 1BTC, T_{escr(M，B)(k)}Can be T₂The lock, i.e. the bitcoin therein, can be unlocked after 503 blocks of height. .

And (3) a payment stage: at proxy transaction T_escr(A，M)After being validated by the blockchain, the payer pays the mixed currency server through a down-chain transaction before 500 blockheights. When A wants to make a third payment, he first chooses a randomly₃∈{0，1}^λAnd generate a₃Hash value h of₁(3)＝H(a₃). The payer then constructs and signs a new transfer transaction

This transaction contains 3 transaction outputs. Each output contains 1.1BTCs and is divided by a 502 th block height t₁The defined temporal hash condition. The bitcoin in each output may be signed by an owning payer and h is revealed₁(i) Redemption of a fulfillment transaction for a pre-image, where i e [1, 3 ]]. Or redeemed by the hybrid server after a time of block height 502. Thereafter, the payer will send

And h₁(j) Passing to a mix-up server, mix-up server detection

If it is correct, if not, the corresponding h is discarded₁(i)。

The coin-in-mixture server stops accepting the payer's payment down the chain after the 500 th block height. The money mixing server then reveals all valid hash values received from all payers during this period, constructing a Merck tree (MTree) whose root node is the Merck root (MRoot). The mixed currency server signs the Mercker tree and a time stamp to obtain Sig_M(MTree, timestamp) and publishes it on all available public resources, (e.g., web site, blockchain IPFS) for all payers to verify.

After receiving the MTree, the payerA first checks whether all hash values h₁(i)(i∈[1，3]) Are already contained in MTree. If not, payer A will be at the money mixing server

And sending the payment to the block chain and withdrawing the corresponding payment. If so, the payer will execute a proof-of-generation algorithm to construct 3 proofs of zero knowledge with a return value of π_i，b_i∈{0，1}^λ，g_i＝G(ai)，

After the certificate is generated, the payer signs h₂(i) And construct the evidence Sig_A(h₂(i) For proving that the relevant payment was generated by payer a. The payer then sends { b }_i，g(i)，h₂(i)，π_i，Sig_A(h₂(i) Etc.) to the corresponding payee B. After receiving the expected 2 different zero knowledge proofs, the payee sends { b }_k，g(k)，h²(k)，π_kAnd 2 temporary addresses Addr_B(k) For a coin-feed server, where k ∈ [1, 2 ]]. If all proofs are correct, and

the mixed currency server opens a payment channel with the payee and adds g (k) to the set Λ: Λ ═ Λ { (g) (k) }.

Payee signs and sends a chain down-link transaction first

To the coin-mixing server.

Contains 1BTC and has a block height t of 504₂A specified hash time condition limit.

The bit coin in (1) canSigned by a owning confounding server and disclosed h₂(k) The fulfillment transaction of the pre-image is redeemed, or by the payee after a 504 th altitude. If the payer passes disclosure h₁(k) The original image of the transaction is maliciously cancelled and sold, and the mixed currency server can obtain a_kAnd calculate h therefrom₂(k) Is then immediately followed from

The bitcoin is redeemed. In at least

Thereafter, the mixed currency server signs and sends a transfer transaction with the same hash time condition

To the payee.

A decision stage: the decision phase is entered when the coin-in-mix server wants to request a bitcoin from the payer before the 501 th block height. At this stage, all participants close the payment channel and redeem/claim the bitcoin according to the payment situation.

If the payer, the payee and the money mixing server all execute according to the agreement, the discount phase is entered. The mixed currency server first requires the payer to jointly generate a T_escr(A，M)Is a discount transaction T_{cash→escr(A，M)}. The mixed coin server can ask for 3.3BTCs by using the mixed coin server. If the payers are not affiliated, the money mixing server may first issue the latest transfer transaction

Fulfillment transaction T for the transfer transaction is then generated_{cash→fund(A，M)(3)}To claim 3.3 BTCs. Similarly, before the 503 th block height, the payee first asks the mix server to collectively generate a T_{escr(M，B)(k)}Fulfillment transaction T_{cash→escr(M，B)(k)}For claim of 2BTCs, if the mixed currency server is not cooperative, the payee may first issue a transfer transaction

A fulfillment transaction T for the transfer transaction is then generated_{cash→fund(M，B)(k)}To retrieve 2 BTCs.

However, if the payer does not get the payee's reply or any hash value h (a) before the blockchain reaches block 502 height_i) Not included on the MTree, the payer may be referred to as a refund transaction T by issuing another fulfillment transaction name for the transfer transaction_{refund→fund(A，M)(j)}To redeem the bitcoin. If at T_escr(A，M)No down-link transaction is available after release, and the payer can release T_escr(A，M)Fulfillment transaction T_{refund→escr(A，M)}To redeem 3.3 BTCs. If the payer does not cooperate with the mixed currency server, an intelligent mixed currency server will always work

Publish to block chain to expect from

The bitcoin is requested. On the other hand, if the payer has replied to the payee, the payer maliciously replies with the payee

Redeeming 1.1BTCs, the mixed currency server can utilize h revealed by the payer₁(k) Calculating h from the original image of₂(k) Then immediately construct T_{refund→fund(M，B)(k)}From

To redeem 1 BTCs.

In the model under the chain, the 2 different zero knowledge proofs received by the payee may be from the same payer, or from different payers. The payee may receive all 2 payments using one temporary address, but may also receive each payment separately using 2 different temporary addresses for better anonymity.

The agent phase may be cancelled to cause the transferTransaction T_fundDirect chaining, but participants cannot collaborate on retrieving bitcoins, which can prolong the transaction time. Different zero knowledge proof modes (zkbor, ZKSnark) can be adopted according to different application scenarios.

Those of ordinary skill in the art will understand that: all or part of the steps for implementing the method embodiments can be implemented by hardware related to program instructions, the program can be stored in a computer readable storage medium, and the program executes the steps including the method embodiments when executed; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.

The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any modification, equivalent replacement, and improvement made by those skilled in the art within the technical scope of the present invention disclosed in the present invention should be covered within the scope of the present invention.

Claims

1. A bitcoin-compatible safe mixed coin processing method for supporting the down-link transaction is characterized by comprising three stages:

in the agent stage, the payer and the mixed currency server prestore a certain amount of bit currency into the agent transaction on the block chain;

in the payment stage, a payer or a mixed coin server can transmit the bitcoin to the mixed coin server or a payee in a chain down-payment mode in an anonymous mode through a zero-knowledge proof scheme;

the decision stage can be divided into a refund stage and a discount stage according to different behaviors of participants; if all participants comply with the agreement, entering a discount stage, namely the anonymous server and the payee collect the bitcoin paid by the payer and the anonymous server in the payment stage; if there is a party that does not comply with the agreement, the payer initiates a refund mechanism, i.e. the payer and the anonymity server withdraw the bitcoin paid during the payment phase.

2. A bitcoin compatible secure mixed coin processing method supporting linked-down transactions according to claim 1 characterized in that the method is first of all initialized by the system, the mixed coin server sets and discloses the parameters (λ, T)₁，T₂，H(·)，G(·)，α，F_mix) Where λ is a safety parameter, T₁，T₂For the definition of the times of the different steps, H (-), G (-), are different hash functions, α is the denomination to be mixed for each coin-mixing cycle, F_mixThe coin-mix server re-empties the set Λ before the beginning of each coin-mix cycle for the service fee charged by the coin-mix server.

3. A secure mixed currency processing method compatible with bitcoin for supporting a downlink transaction as claimed in claim 1 wherein said method is characterized in that in the proxy phase, each of the payor and payee establishes a two-party proxy transaction with the mixed currency server; at the start of a new cycle, a payer first opens the payment channel and deposits the bitcoin into the two-party proxy transaction T_escr(A，M)Performing the following steps; at T_escr(A，M)The bitcoin in (A) can be transferred to a fulfillment transaction signed by both the payer and the mixed coin server, or at time T₁And later redeemed by the payer; similarly, after receiving expected zero knowledge proof from multiple payers in the next payment stage, the payee requires the mixed currency server to open the payment channel, store the bitcoin until the time condition T₂Specified two-party proxy transaction T_escr(M，B)In (1).

4. The bitcoin compatible secure mixed coin processing method supporting the offline transaction as claimed in claim 1, wherein said method is characterized in that in the payment phase, the payer pays for the mixed coin server through the offline transaction before time T, wherein T₁T is greater than; the payer randomly selects a e {0, 1}^λAnd calculates a hash value h₁H (a); the payer then constructs and signs the transfer transaction

This transaction is directed to T_esce(A，M)The transaction output of which contains alpha + F_mixBTCs, the bitcoin in the transaction output can be signed by a payor and h is revealed₁Redemption of the fulfillment transaction of the portrait; or at time t₁Is later redeemed by the mix-in server, where T₁＜t₁(ii) a Thereafter, the payer will send

And h₁And transmitting the data to a coin mixing server.

5. A bitcoin compatible secure mixed coin processing method in support of an offline transaction as claimed in claim 4, characterized in that the mixed coin server of said method stops accepting the offline payment of the payer after the expiration of time T; the mixed currency server then reveals all valid hash values received from all payers in the period, and constructs a merkel tree (MTree) with the root node being the merkel root (MRoot); the mixed currency server signs the Merck tree and a time stamp to obtain Sig_M(MTree, timestamp) and publishes it to all available public resource websites and IPFS for all payers to validate.

6. The bitcoin compatible secure mixed coin processing method in support of an under-chain transaction as claimed in claim 5 wherein the method upon receiving MTree, the payer executes a proof-of-generation algorithm to construct a proof of zero knowledge; the zero knowledge proves that the function of pi is to persuade the coin-mixing server:

(1) there is a payer who has sent a payment;

(2) the payment corresponds to

The output on is not redeemed by the payer or used by the payee;

(3) after the mixed currency server commits to pass the alpha BTCs to the payee, the mixed currency server can redeem them immediately if the payer maliciously withdraws the payment;

the payer randomly selects b e {0, 1}^λAnd calculate

The payer further calculates g ═ g (a); payer signs h₂And sends { b, g, h₂，π，Sig_A(h₂) To the corresponding payee; after receiving the expected zero knowledge proof, the payee sends { b, g, h₂N and a temporary address Addr_BA money feeding and mixing server; if all proofs are correct, and

the mixed currency server and the payee open a payment channel and add g into the set Λ; thereafter, the payee and the escrow server exchange transfer transactions

And

and

point to T_escr(M，B)The transaction output contains alpha BTCs, the bitcoin in the transaction output can be signed by the owning mixed coin server and h is disclosed₂Redemption of fulfillment transactions of the original, or at time t₂And then redeemed by the payee.

7. A bitcoin compatible secure mixed coin processing method in support of an under-chain transaction as claimed in claim 1 wherein the method is in the decision phase, payer, payeeThe man and the mixed coin server are executed according to the protocol, firstly the mixed coin server closes the payment channel between the man and the payer and requests alpha + F through the cash-off transaction_mixThe payment channel between the payee and the mixed coin server is closed, and alpha BTCs are requested through cash withdrawal transactions; however, if the payer is not at t₁If the payee's reply is received or if any hash h (a) is not included on MTree, the payer may initiate a refund mechanism to refund the paid bitcoin via a refund transaction; h is disclosed by this mechanism₁The payer maliciously redeems the bitcoin, the mixed coin server can utilize h revealed by the payer₁Calculating h from the original image of₂From

The bitcoin is redeemed.

8. The bitcoin-compatible, chain-transaction-enabled secure mixed coin processing method as claimed in claim 1, wherein the system model of the bitcoin-compatible, chain-transaction-enabled secure mixed coin processing method involves three parties, namely a payer, a payee and a mixed coin server; wherein the mixed currency server is responsible for accepting the bit currency of the payer, forwarding the bit currency to the payee by using different addresses, and then charging a certain amount of service fee (F)_mix) (ii) a In the protocol, each party has a long-term key Pair (PK) associated with its identity_p，SK_p) As a mechanism for profit, the mixed currency server needs to ensure the credit value of its public key.

9. The bitcoin-compatible under-chain transaction-supporting secure mixed coin processing method according to claim 8, wherein the system model of the bitcoin-compatible under-chain transaction-supporting secure mixed coin processing method supports two system models, namely a legacy model and an under-chain model; in the traditional model, each payer can only send one transaction in one mixed currency period, each payee can only accept one transaction in one mixed currency period, and the number of the payers is equal to that of the payees; in the under-chain model, each payer can send multiple transactions in a mixed currency period through under-chain transactions, each payee can receive multiple transactions in a mixed currency period, the number of the payers can be different from that of the payees, namely, one payer can pay for multiple payees, and one payee can also receive the payment of multiple payers.