1545-5971 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2019.2938953, IEEE
Transactions on Dependable and Secure Computing
1
A Mixing Scheme Using a Decentralized Signature
Protocol for Privacy Protection in Bitcoin
Blockchain
Ruiyang Xiao, Wei Ren, IEEE, Tianqing Zhu, IEEE, and Kim-Kwang Raymond Choo, IEEE
Abstract—Bitcoin transactions are not truly anonymous as
an attacker can attempt to reveal a user’s private information
by tracing related transactions. Existing approaches to protect
privacy (e.g. mixcoin, shuffle, and blinded token) suffer from a
number of limitations. For example, some approaches assume
the existence of a trusted third party, rely on exchanges among
various currencies, or broadcast sensitive details before mixing.
Therefore, there is a real risk of privacy breach or losing
tokens. Thus in this paper, we design a mixing scheme with one
decentralized signature protocol, which does not rely on a third
party or require a transaction fee. Specifically, our scheme uses
a negotiation process to guarantee transaction details, which is
monitored by the participants. Furthermore, the scheme includes
a signature protocol based on the ElGamal signature protocol and
secret sharing. The proposed scheme is then proven secure.
Index Terms—Blockchain, privacy protection, coin mixing,
multi-party signature.
I. INTRODUCTION
B
ITCOIN has been known to be exploited by criminals,
for example for ransomware payment [1], [2]. This is
partly fulled by the fact or belief that Bitcoin transactions
are anonymous or impossible to trace, since one does not
necessarily need to use his/her real identity to create an
account. However, such a belief or perception is not truly
accurate, as each Bitcoin transaction is linked to at least one
other transaction in the previous block and all transactions in
the Bitcoin blockchain can be traced back to their origin. Even
if these anonymous addresses are not linked to real identities,
attackers can deduce from a user’s transaction network [3], [4]
and infer the user’s or owner’s real identities using techniques
such as clustering analysis [5], [6]. In addition, vulnerabilities
in a Bitcoin wallet can be exploited to recover either the
user’s identity or gain access to the Bitcoins stored in the
wallet [7], [8]. Thus, another individual (e.g. attacker or
R.Y. Xiao is with the School of Computer Science, China University of
Geosciences (Wuhan), Wuhan, China, 430074, and the School of Mathematics
and Physics, China University of Geosciences (Wuhan), Wuhan, Hubei, China,
430074.
W. Ren is with the School of Computer Science, China University of
Geosciences(Wuhan), Wuhan, China, 430074, the Hubei Key Laboratory
of Intelligent Geo-Information Processing, China University of Geosciences
(Wuhan), Wuhan, Hubei, China, 430074, and the Guizhou Provincial Key
Laboratory of Public Big Data, Guizhou University, Guizhou, P.R. China.
Corresponding Author email:weirencs@cug.edu.cn.
T.Q. Zhu is with the School of Software, University of Technology Sydney,
Ultimo, NSW 2007, Australia.
K.-K.R. Choo is with the Department of Information Systems and Cyber
Security, University of Texas at San Antonio, San Antonio, TX 78249-0631,
USA.
Manuscript received November 7, 2018; revised .
investigator) can trace existing Bitcoin transactions in the
blockchain to determine a particular user’s complete addresses,
their transaction network, and infer their real identities (also
using other available information).
Hence, several privacy-enhancing technologies have been
developed and such solutions can be broadly categorized into
the following:
1) Solutions that avoid having a real link between input and
output addresses in a transaction but require advanced
cryptographic technologies (e.g, coinjoin [9], [10], coin
shuffle [11] or blinded token [12], [13]).
2) Solutions that split the relationship between several
different addresses of a user but require the use of ad-
ditional currencies (e.g. Altcoin [3] and Zerocash[14]).
3) Solutions that prevent the tracing of user’s transactions.
In addition to these mixing approaches, a number of third-
party entities provide paid mixing services (e.g. Bitcoin Fog
[15], BitLaundry [16], Dark Wallet [17] and Bitmixer [18]),
although there are known limitations in such services (e.g.
delayed transaction, additional charges, and privacy breaches).
For example, schemes that require a third-party or additional
currencies require more time to complete the mixing service.
Also, users who mix coins with a third-party mixing server
or convert coins between pairwise currencies typically have to
pay for the service. Bitcoins (or other cryptocurrencies) are
also at risk of being stolen by mixing servers because the
servers possess all the valid signatures. In addition, a user’s
initial transactions can be exposed because mixing servers are
at risk of attack. Furthermore, one can predict another user’s
output addresses by tracing information on a bulletin board.
Therefore to mitigate these limitations, in this paper we
present a mixing scheme with a decentralized signature pro-
tocol that places specific emphasis on multiple-transaction
processes in Bitcoin (BTC) blockchain. Specifically, the con-
tributions of this paper are as follows:
1) To avoid unnecessary delays, we introduce a negotiation
process, where each user keeps his/her initial transaction
details secret. Thus, this requires less mixing time than
using a third-party.
2) To avoid incurring additional charges, we design a mix-
ing scheme that splits the direct relationships between
the initial input addresses and output addresses, in order
to ensure randomness and anonymity.
3) To protect privacy, we do not rely on third parties and
instead use a decentralized signature protocol based on
Authorized licensed use limited to: University of Technology Sydney. Downloaded on October 17,2020 at 07:07:44 UTC from IEEE Xplore. Restrictions apply.
1545-5971 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2019.2938953, IEEE
Transactions on Dependable and Secure Computing
2
ElGamal signature protocol. In the protocol, detected
malicious behavior will be penalized by temporarily
suspending the associated assets.
Having introduced the paper, we will briefly review related
work in the next section (see Section II). In Section III, we
describe the problem formulation and other relevant materials.
In Section IV, we present our proposed approach, prior to
presenting the evaluation findings in Section V. We conclude
the paper in Section VI.
II. RELATED WORK
We will briefly describe key mixing approaches below.
Mixcoin: The Mixcoin process [19] is completed by a single
trusted third-party mixing server. Users only need to provide
their input addresses and related fresh output addresses. Ad-
ditionally, a number of transactions with multiple input and
output addresses need to be mixed by the third-party server.
However, there are several security issues. First, a malicious
third-party can steal the currency it is handling (e.g. by chang-
ing the output address). Also, as this third-party has access
to all original transactions, it becomes an attractive target to
cybercriminals seeking to steal the cryptocurrencies. In the
event that multiple users need to transfer fund to the same
address (e.g. for an international conference registration), this
mixing payment method means transactions are ambiguous,
and the recipient may find it challenging to identify which
payment is made by who. Lastly, such service is usually not
free.
Coinjoin: The coin mixing process [9], [10] is conducted
by a trusted third-party mixing server (i.e. a mixing server),
where multiple users agree to generate a combined transaction
with multiple inputs and outputs. This scheme also suffers
from several limitations. For example, each output address
must be a fresh new address because two users who share the
same output address would otherwise not be able to recognize
their own transaction details in a mixed transaction. As a
result, the mixing server knows each original transaction and,
if that mixing server is successfully compromised, then the
transaction details will be leaked. Users also need to pay
additional fees for this mixing service.
CoinShuffle: In this scheme, users broadcast their require-
ments, which include the amounts to be mixed. Users who
are in need of the same coins can join as one group [10],
[11]. They merely exchange each other’s output addresses
directly. However, finding a mixing group to join is difficult
and waiting for another can result in time wastage. Addition-
ally, because all users put their requirements on a bulletin
board, one can potentially infer another user’s real output
addresses from his/her mixed amount. Moreover, malicious
nodes may promise signatures and then refuse to sign after
gaining other valid signatures. Such malicious nodes may also
steal valid signatures for illegal uses, and CoinShuffle’s pun-
ishment mechanism has little to do with financial punishments.
Moreover, this scheme is completed without monitoring by a
trusted third party; therefore, it is hard to prove that a node is
malicious or dishonest.
Altcoin: In Altcoin [3], users convert their mixing coins
into other virtual currencies, such as Zerocoin [14]. After
the conversion, the users’ coins are aggregated. However, an
additional underlying protocol is needed for the conversion
between different currencies. In addition, the values of these
currencies fluctuate daily, and market fluctuations may occur
between pairwise currencies. This means users may not receive
the same amount of coins when the currency is returned.
Moreover, this conversion process incurs additional time.
Blinded token: In this scheme, a user randomly selects
other users to join and create mixing groups. A ”so-called”
trusted mixing server is selected by users from several third-
party mixing servers [13]. Without knowing the links between
the input addresses and output addresses [12], the selected
server verifies the validity of the signatures. However, the
mixing servers may become so busy that users experience
significant delays, and additional fees for the third-party still
apply.
Our proposed scheme seeks to split the initial links among
input addresses and output addresses. Therefore, similar to
mixing technologies like Mixcoin and Coinjoin, our scheme
can form multiple input addresses and multiple output address-
es in one transaction.
Although our scheme is on the basis of mixing technologies,
it uses each user rather than a third-party to form the final
transaction. In terms of replacing the mixing third party, we
introduce a multi-signature protocol dynamically formed by a
group of signers [20], which was first proposed by K. Itakura
and K. Nakamura [21] and was formally defined by Silvio
Micali, Kazuo Ohta, Leonid Reyzin [22].
III. PROBLEM FORMULATION
A. Adversary Model
Definitions of the problems are listed below:
Dishonest/cheating behaviour This includes both a user
0
i
s
and a third-party
0
i
s dishonest behavior. The former relates to a
user providing fake addresses, useless signatures, and doublge
spending transactions. The latter relates to a third party
0
i
s
deliberate behavior, such as counterfeiting output addresses,
signatures or transactions, leaking initial transaction details,
and refusing to provide mixing services.
Dishonest/malicious nodes Any individuals or organiza-
tions that behave dishonestly can be thought of as a dishon-
est/malicious node.
Third parties Third parties are divided into two categories:
negotiating third parties, which provide alternative chatting
services (e.g., Wechat, a BBS, WhatsApp), and mixing third
parties, which provide specific mixing services (e.g., Bitcoin
Fog, BitLaundry, Dark Wallet, Bitmixer).
B. Design Goals
We outlined three main disadvantages of existing schemes
in Section I and Section III-A: delay, extra charges, and
privacy breaches. Now, we provide more specific details of
our three design goals: time, coins, and privacy. Definitions of
the specific subgoals are listed below.
Time - Shorter waiting intervals Except for essential
transaction confirmation from the blockchain, users do not
need to wait for mixing services.
Authorized licensed use limited to: University of Technology Sydney. Downloaded on October 17,2020 at 07:07:44 UTC from IEEE Xplore. Restrictions apply.
1545-5971 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2019.2938953, IEEE
Transactions on Dependable and Secure Computing
3
Coins - No additional mixing fees The protocol should
not require additional fees for specific mixing services. But
transaction fees are allowed.
Privacy - Transaction security The security for trans-
actions requires non-linked input and output addresses, un-
predictable user identities, and untraceable initial transaction
details.
Privacy - Trustless third party environments Even if a
trusted third party is involved in the mixing procedure, it will
not have enough information to counterfeit transaction details
or even obtain the initial transaction details.
We explore a way in which each user can monitor the whole
mixing process without extra cost in time, coins, and privacy.
Secret sharing is used to prevent users from distributing
signatures to malicious nodes by placing all the group mem-
bers into an agreement using a secret. Secret sharing can split
a secret into different secret shares, or pieces, and distribute
them to each group member. If the available shares do not
equal the original amount, none of the group members can
recover the secret. Because transactions might be eliminated
if someone cheats the mixing process, we have added a
negotiation process that requires the participation of all users.
The validity of one transaction in the blockchain can be
verified through the signature, which is solely generated by
all related private keys.
Additionally, the ElGamal signature protocol [23] has been
proven to be secure because discrete logarithmic problems are
believed to be hard. The ElGamal signature protocol is suitable
for designing a shared secret, as ElGamal
0
i
s signature includes
a commitment, which makes it possible to prove every user
0
i
s
ownership of a private key.
IV. PROPOSED MIX SCHEME USING A DECENTRALIZED
SIGNATURE PROTOCOL
We propose a decentralized signature protocol that builds
on the ElGamal signature protocol, which defends against
malicious behavior by temporarily suspending assets.
However, before describing our approach, we first introduce
the basic model with a negotiation process. The basic model
somewhat mitigates the risk of a mixing server being compro-
mised because negotiation before mixing ensures that no one
else has direct access to anyone’s real transaction details. But
users still suffer from time waste in case that malicious nodes
refuse to sign their final transaction. Table I lists the notations
used in this protocol.
A. Basic Scheme
As mentioned a negotiation process reduces risks of a pri-
vacy leak, but this process is only required in a random-named
negotiation group to ensure users do not know each other. Our
scheme aims to create a new transaction, where links among
the original input and output addresses are randomly split. The
four steps are shown in Fig. 1.
1) Forming a random group
A node that needs to mix coins broadcasts a mixing
request, i.e., a MixRes on the bulletin board. No sensi-
tive details are included, such as output addresses, BTC
6WHS)RUPLQJD
UDQGRPJURXS
6WHS1HJRWLDWLQJD
JHQHUDOWUDQVDFWLRQ
6WHS*HQHUDWLQJD
ILQDOWUDQVDFWLRQ
6WHS6HQGLQJDILQDO
WUDQVDFWLRQ
Fig. 1. Procedures of basic scheme
distributions, or private keys. Every node can choose to
create a new mixing group or join other node’s mixing
group.
For those who want to create a new mixing group
(Creator), Creator’s MixRes only includes creator’s
former transaction addresses, a mixing demand, a nonce,
a minimum number of group member, a end time, a
timestamp and a signature. Moreover, Creator’s sig-
nature signs all other information except itself in the
MixRes.
For those who want to join other node’s mixing
group (Participant), the MixRes includes participant’s
former transaction addresses, a mixing demand, the
nonce of creator’s MixRes, a timestamp and a signa-
ture, where participant’s signature also signs all other
information except itself in the M ixRes.
Broadcasts with the same nonce before the creator’s
end time allow users to form a temporary mixing group.
Only if there exist no less than minimum number of
group members in creator’s MixRes will a mixing
group be created. Otherwise, the group shall be dis-
solved.
Suppose that there are m nodes in this group in
total(m ≥ 2), each node is denoted as Node
i
(1 ≤
i ≤ m) in random order. Fig. 2 shows an example of
how the group is formed, which could be completed
on any social media platform allowing users to share
information (e.g., Wechat, a BBS, WhatsApp).
2) Negotiating a general transaction
As shown in Fig. 3 and Fig. 4, Node
i
cre-
ates fresh accounts as output addresses and generates
Authorized licensed use limited to: University of Technology Sydney. Downloaded on October 17,2020 at 07:07:44 UTC from IEEE Xplore. Restrictions apply.
1545-5971 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2019.2938953, IEEE
Transactions on Dependable and Secure Computing
4
TABLE I
NOTATIONS
Notation Description
MixRes A mixing request for mixing group members
m A sum of the nodes in the mixing group
Node
i
A random temporary name of a user in a mixing group
NegRes
ik
A resolution request of N ode
i
’s initial mixing request
OutAddress
ik
The output addresses in N egRes
ik
Sum
ik
The amount of BTC needed in N egRes
ik
SatMess
j
A satisfaction message that Node
j
can completely satisfy
P artSatM ess
j
A satisfaction message that Node
j
can partly satisfy
NegRes
ik
0
A new mixing transaction that Node
j
can not satisfy
Sum
ik
0
The amount of BTC needed in N egRes
ik
0
Assessment
i
Node
0
i
s assessment of all broadcast messages
MixT ran The final mixed transaction of this mixing group
p A random chosen prime number
g A primitive element in Z
∗
p
=< Z/pZ\{0}, ∗ >
x
i
A random integer number of N ode
i
k
i
An integer number with (k
i
, p − 1) = 1(1 ≤ i ≤ m) of Node
i
r
i
, h
i
, t
i
, s
i
Transmitted data from Node
i
SIGN Signatures of M ixT ran
Sign
1
, Sign
2
, Sign
3
An element of SIGN
8VHU
$
&UHDWRU
V)RUPHUWUDQVDFWLRQDGGUHVVHV1RQFHāāāāāā
0LQLPXPQXPEHURIJURXSPHPEHU7LPHVWDPSSP
0L[LQJGHPDQG0L[LQJFRLQ(QG7LPHPLQ
6LJQDWXUH6LJQ
$
8VHU
$
V)RUPHUWUDQVDFWLRQDGGUHVVHV__1RQFH__0LQLPXPQXPEHURI
JUHRXSPHPEHU__7LPHVWDPS__0L[LQJGHPDQG__(QG7LPH
ā
ā
ā
8VHU
%
3DUWLFLSDQWV)RUPHUWUDQVDFWLRQDGGUHVVHV1RQFHāāāāāā
7LPHVWDPSSP0L[LQJGHPDQG0L[LQJFRLQ
6LJQDWXUH6LJQ
%
8VHU
%
V)RUPHUWUDQVDFWLRQDGGUHVVHV__1RQFH__7LPHVWDPS__0L[LQJ
GHPDQG
ā
ā
ā
8VHU
Y
3DUWLFLSDQWV)RUPHUWUDQVDFWLRQDGGUHVVHV1RQFHāāāāāā
7LPHVWDPSSP0L[LQJGHPDQG0L[LQJFRLQ
6LJQDWXUH6LJQ
9
8VHU
Y
V)RUPHUWUDQVDFWLRQDGGUHVVHV__1RQFH__7LPHVWDPS__0L[LQJ
GHPDQG
0L[LQJ&RLQ%LOOERDUGLQ
%HWZHHQDQG&UHDWRU8VHU
$
Fig. 2. Formation of a random group
several disparate negotiating requests N egRes
ik
(k ≥
1, 1 ≤ i ≤ m). N egRes
ik
includes all output address
OutAddress
ik
and the number of coins Sum
ik
. Node
i
randomly chooses different nodes to send each negoti-
ating request to. At the same time, it receives requests
from other nodes.
Once a negotiating request NegRes
ik
is re-
ceived, Node
j
(1 ≤ j ≤ m) in Fig. 5 judges
whether or not his/her former transaction address
has enough BTC to satisfy Sum
ik
. If the answer
is yes, Node
j
will generate a satisfaction message
SatMess
j
, and broadcast it among the mixing group.
SatMess
j
includes N ode
0
j
s former transaction address,
OutAddress
ik
and Sum
ik
in N egRes
0
ik
s. Otherwise,
Node
j
will firstly generate a part-satisfaction message
P artSatMess
j
and broadcast it among the mixing
group. Then, Node
j
will generate a new negotiating
1HJ5HVL
1HJ5HVLN
N
M
1HJ5HVL
1HJ5HVL
1HJ5HVLM
ā
ā
ā
Fig. 3. Generating several disparate negotiating requests
2XWDGGUHVV
L
$
6XP
L
%7&
2XWDGGUHVV
L
%
6XP
L
%7&
1RGHL
2XWDGGUHVV
L
$
6XP
L
%7&
2XWDGGUHVV
L
&
6XP
L
%7&
2XWDGGUHVV
L
%
6XP
L
%7&
2XWDGGUHVV
L
%
6XP
L
%7&
2XWDGGUHVV
L
&
6XP
L
%7&
1HJ5HV
L
1HJ5HV
L
1HJ5HV
L
1HJ5HV
L
1HJ5HV
L
2XWDGGUHVV
L
$
6XP
L
%7&
2XWDGGUHVV
L
%
6XP
L
%7&
2XWDGGUHVV
L
&
6XP
L
%7&
1HJ5HV
L
Fig. 4. Sending several specific disparate negotiating requests
request N egRes
ik
0
and randomly choose another node
to send it to. P artSatMess
j
includes Node
0
j
s former
Authorized licensed use limited to: University of Technology Sydney. Downloaded on October 17,2020 at 07:07:44 UTC from IEEE Xplore. Restrictions apply.
1545-5971 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2019.2938953, IEEE
Transactions on Dependable and Secure Computing
5
1HJ5HVLN
)URP1RGHL
1RGHMFKHFNVKLVRZQ
OHIWELWFRLQV
6DW0HVVM
%URDGFDVW
3DUW6DW0HVVM%URDGFDVW
1HZ1HJ5HVM7RDQRWKHUQRGH
1HZ1HJ5HVM
7RDQRWKHUQRGH
HQRXJK
ELWFRLQV
QRQH
QRWHQRXJK
ELWFRLQV
Fig. 5. Negotiating details separately
transaction address, the OutAddress
ik
in NegRes
0
ik
s
and N ode
0
j
s current amount of BTC. N egRes
ik
0
in-
cludes the OutAddress
ik
in NegRes
ik
and the BTC
Sum
ik
0
. Once a satisfaction message SatM ess
j
or a
part-satisfaction message P artSatM ess
j
is broadcast,
Node
0
j
s former transaction address will reduce its BTC
by an equal amount, to some extent.
Example (Here we take N ode
1
as an example to
illustrate the negotiating process):
(1)Suppose that N ode
1
generates three fresh address A,
B and C as his/her mixing output addresses. N ode
1
’s
real mixing request are to send A 1 BTC, to send B
2BTC and to send C 3 BTC. Then Node
1
chooses
a random number h between 1 and the size of group
member to divide his/her initial request NegRes
1
into
several sub-request N egRes
1i
(where i = 1, 2, · · · , h).
Here we set h as 5. Therefore, N ode
1
can get that
NegRes
11
is to send A 0.4 BTC and to send B 1 BTC,
NegRes
12
is to send A 0.6 BTC, NegRes
13
is to send
C 2.2 BTC, N egRes
14
is to send B 1.8 BTC, NegRes
15
is to send B 0.2 BTC and to send C 0.8 BTC.
(2)Node
1
chooses 5 different nodes in mixing group to
send a sub-request secretly. At the same time, Node
1
shall receive sub-requests from other nodes.
(3)Suppose that Node
1
firstly receives a sub-request to
send H 3 BTC. Since Node
1
has 6 BTC in total, he/she
can satisfy this sub-request and can have 3 BTC left.
Thus, he/she broadcasts a SatMess
1
which includes
Node
1
’s former transaction hash, OutAddress
1
= H
and Sum
1
= 3.
(4)Suppose that Node
1
then receives a sub-request
to send W 8 BTC. Since N ode
1
only has 3 BTC
left, he/she broadcast a P artSatM ess
1
which includes
Node
1
?s former transaction hash, OutAddress
1
= W
and Sum
1
= 3. Noted that there exist 5 BTC in this
received sub-request, Node
1
regenerates a new sub-
request which aims at sending W 5 BTC and sends it to
another node.
$OO6DW0HVVDQG
3DUW6DW0HVVPHVVDJHV
IURPPL[LQJJURXS
$VVHVVPHQWL
%URDGFDVW
1RGHL
L
P
6WHS
$OO$VVHVVPHQW
PHVVDJHV
IURPPL[LQJJURXS
6WHS
'LVVROYHJURXS
PDNHD
MXGJHPHQW
1RGHL
L
P
*HQHUDWHDILQDO
WUDQVDFWLRQ
IDOVH
WUXH
Fig. 6. Verifications made before generating a final transaction
(5) Suppose that Node
1
still receives sub-requests from
other nodes. But considering that he/she has no coins
left, Node
1
directly sends his/her received sub-requests
to another node.
3) Generating the final transaction
Having finished step 2, each node verifies the
validity of these messages in two aspects. First, Node
i
(1 ≤ i ≤ m) judges whether or not its output
addresses OutAddress
ik
(k ≥ 1) have received an
equal amount of BTC. This judgement aims to prevent
unsatisfactory requests. Then, by making comparisons
between the amount of coins in all satisfaction and part-
satisfaction messages and that in all mixing requests,
Node
i
judges whether or not there any requests have
been omitted. As shown in Fig. 6, Node
i
makes an
assessment Assessment
i
based on both judgments and
then broadcasts it to the group. If, and only if, over
two-thirds of the group
0
i
s assessments have indicated
a verification will this group generate a final mixed
transaction MixT ran. M ixT ran includes all input
addresses, all output addresses, new divisions of BTC
from step 2 and the hash values of MixT ran (see
Fig. 7). Otherwise, this mixing group will be dissolved.
4) Sending the final transaction
Having completed Step 3, N ode
i
(1 ≤ i ≤ m)
will broadcast his/her Sign
i
MixT ran
among the
mixing group. Each node in this group is able
to collect everyone’s signature and broadcast
(MixT r an, Sign
1
MixT ran
, ..., Sign
m
MixT ran
) to
the internet. Therefore, even if malicious nodes refuse
to sign signatures to final transaction, other nodes in
this group will not suffer from BTC theft because the
final transaction is invalid.
This scheme uses a negotiation process to replace a third
party. Since messages, such as mixing requests and negotiating
requests, do not include the amount of BTC and the addresses
in the initial transaction, real identities cannot be predicted
using the final transactions.
Authorized licensed use limited to: University of Technology Sydney. Downloaded on October 17,2020 at 07:07:44 UTC from IEEE Xplore. Restrictions apply.
