TumbleBit: An Untrusted Bitcoin-Compatible

Anonymous Payment Hub

Ethan Heilman∗ , Leen AlShenibr∗ , Foteini Baldimtsi† , Alessandra Scafuro‡ and Sharon Goldberg∗
∗ Boston University {heilman, leenshe}@bu.edu, [email protected]
† George Mason University [email protected]
‡ North Carolina State University [email protected]

Abstract—This paper presents TumbleBit, a new uni- leads to a total loss of anonymity. Compromise of
directional unlinkable payment hub that is fully com- anonymity-enhancing technologies is not unknown. In
patible with today’s Bitcoin protocol. TumbleBit allows 2016, for example, researchers found more than 100 Tor
parties to make fast, anonymous, off-blockchain payments nodes snooping on their users [45]. Moreover, users of
through an untrusted intermediary called the Tumbler. mix services must also contend with the potential risk
TumbleBit’s anonymity properties are similar to classic
of “exit scams”, where an established business takes in
Chaumian eCash: no one, not even the Tumbler, can link
a payment from its payer to its payee. Every payment new payments but stops providing services. Exit scams
made via TumbleBit is backed by bitcoins, and comes with have been known to occur in the Bitcoin world. In 2015,
a guarantee that Tumbler can neither violate anonymity, a Darknet Marketplace stole 11.7M dollars worth of
nor steal bitcoins, nor “print money” by issuing payments escrowed customer bitcoins [53], while btcmixers.com
to itself. We prove the security of TumbleBit using the mentions eight different scam mix services. Thus, it is
real/ideal world paradigm and the random oracle model. crucial that anonymity-enhancing services be designed
Security follows from the standard RSA assumption and in a manner that prevents bitcoin theft.
ECDSA unforgeability. We implement TumbleBit, mix
payments from 800 users and show that TumbleBit’s off- TumbleBit: An unlinkable payment hub. We present
blockchain payments can complete in seconds. TumbleBit, a unidirectional unlinkable payment hub
that uses an untrusted intermediary, the Tumbler T ,
I. I NTRODUCTION to enhance anonymity. Every payment made via Tum-
bleBit is backed by bitcoins. We use cryptographic
One reason for Bitcoin’s initial popularity was the techniques to guarantee Tumbler T can neither violate
perception of anonymity. Today, however, the sheen of anonymity, nor steal bitcoins, nor “print money” by
anonymity has all but worn off, dulled by a stream of issuing payments to itself. TumbleBit allows a payer
academic papers [38], [51], and a blockchain surveil- Alice A to send fast off-blockchain payments (of de-
lance industry [32], [26], that have demonstrated weak- nomination one bitcoin) to a set of payees (B1 , ..., BQ )
nesses in Bitcoin’s anonymity properties. As a re- of her choice. Because payments are performed off
sult, a new market of anonymity-enhancing services the blockchain, TumbleBit also serves to scale the
has emerged [43], [23], [1]; for instance, 1 million volume and velocity of bitcoin-backed payments. Today,
USD in bitcoins are funneled through JoinMarket each on-blockchain bitcoin transactions suffer a latency of
month [43]. These services promise to mix bitcoins ≈ 10 minutes. Meanwhile, TumbleBit payments are
from a set of payers (aka, input Bitcoin addresses A) sent off-blockchain, via the Tumbler T , and complete
to a set of payees (aka, output bitcoin addresses B) in a in seconds. (Our implementation1 completed a payment
manner that makes it difficult to determine which payer in 1.2 seconds, on average, when T was in New York
transferred bitcoins to which payee. and A and B were in Boston.)
To deliver on this promise, anonymity must also TumbleBit Overview. TumbleBit replaces on-
be provided in the face of the anonymity-enhancing blockchain payments with off-blockchain puzzle solv-
service itself—if the service knows exactly which payer ing, where Alice A pays Bob B by providing B with the
is paying which payee, then a compromise of the service solution to a puzzle. The puzzle z is generated through
interaction between B and T , and solved through an
interaction between A and T . Each time a puzzle is
Foteini Baldimtsi and Alessandra Scafuro performed this work while solved, 1 bitcoin is transferred from Alice A to the
at Boston University.
Tumbler T and finally on to Bob B.
This is the authors’ full version, last updated on July 31, 2017, of a
paper that was first posted online on June 3, 2016 and subsequently The protocol proceeds in three phases; see Figure 1.
appeared at NDSS ’17, 26 February - 1 March 2017, San Diego, In the on-blockchain Escrow Phase, each payer Alice
CA, USA
http://dx.doi.org/10.14722/ndss.2017.23086 1 https://github.com/BUSEC/TumbleBit/
 Tumbler Bob

{
Alice TumbleBit provides k-anonymity within an epoch—no
Puzzle-Promise
Protocol one, not even the Tumbler T , can link one of the k
Phase 1:
Escrow
3 BTC 3 BTC (c, Z )
Z transfers that were successfully completed during the
epoch to a specific pair of payer and payee (A, B).

{
Escrow Transaction Escrow Transaction
Z =Blind(Z )
RSA-puzzle solving. At the core of TumbleBit is our
Payment
Phase 2:

Z RSA-Puzzle-Solver
Protocol 1 BTC from A to B new “RSA puzzle solver” protocol that may be of
ϵ independent interest. This protocol allows Alice A to

{
Unblind( ϵ )= ϵ ϵ
σ = Dec ( c) pay one bitcoin to T in fair exchange2 for an RSA
Cash-out

ϵ
Phase 3:

Cash-out Transaction Cash-out Transaction exponentiation of a “puzzle” value z under T ’s secret

2 BTC 1 BTC 2 BTC 1 BTC key. Fair exchange prevents a cheating T from claiming
A’s bitcoin without solving the puzzle. Our protocol
Fig. 1. Overview of the TumbleBit protocol. is interesting because it is fast—solving 2048-bit RSA
puzzles faster than [37]’s fair-exchange protocol for
A opens a payment channel with the Tumbler T by solving 16x16 Sudoku puzzles (Section VIII))—and
escrowing Q bitcoins on the blockchain. Each payee because it supports RSA. The use of RSA means that
Bob B also opens a channel with T . This involves blinding can be used to break the link between the
(1) T escrowing Q bitcoins on the blockchain, and user providing the puzzle (i.e., Bob B) and the user
(2) B and T engaging in a puzzle-promise protocol requesting its solution (e.g., payer Alice A).
that generates up to Q puzzles for B. During the off- Cryptographic protocols. TumbleBit is realized by
blockchain Payment Phase, each payer A makes up to Q interleaving the RSA-puzzle-solver protocol with an-
off-blockchain payments to any set of payees. To make other fair-exchange puzzle-promise protocol. We for-
a payment, A interacts with T to learn the solution mally prove that each protocol is a fair exchange.
to a puzzle B provided. Finally, the Cash-Out Phase Our proofs use the real/ideal paradigm in the random
closes all payment channels. Each payee B uses his Q0 oracle model (ROM) and security relies on the standard
solved puzzles (aka, TumbleBit payments) to create an RSA assumption and the unforgeability of ECDSA
on-blockchain transaction that claims Q0 bitcoins from signatures.
T ’s escrow. Each payer A also closes her escrow with
T , recovering bitcoins not used in a payment.
A. TumbleBit Features
Anonymity properties. TumbleBit provides unlinkabil-
ity: Given the set of escrow transactions and the set of Bitcoin compatibility. TumbleBit is fully compati-
cash-out transactions, we define a valid configuration ble with today’s Bitcoin protocol. We developed (off-
as a set of payments that explains the transfer of funds blockchain) cryptographic protocols that work with the
from Escrow to Cash-Out. Unlinkability ensures that if very limited set of (on-blockchain) instructions provided
the Tumbler T does not collude with other TumbleBit by today’s Bitcoin scripts. Bitcoin scripts can only
users, then T cannot distinguish the true configuration be used to perform two cryptographic operations: (1)
(i.e., the set of payments actually sent during the Pay- validate the preimage of a hash, or (2) validate an
ment Phase) from any other valid configuration. ECDSA signature on a Bitcoin transaction. The limited
functionality of Bitcoin scripts is likely here to stay;
TumbleBit is therefore similar to classic Chaumian indeed, the recent “DAO” theft [47] has highlighted
eCash [17]. With Chaumian eCash, a payee A first the security risks of complex scripting functionalities.
withdraws an eCash coin in exchange for money (e.g., Moreover, the Bitcoin community is currently debat-
USD) at an intermediary Bank, then uses the coin to ing [20] whether to deploy a solution (“segregated
pay a payee B. Finally B redeems the eCash coin to the witnesses” [58]) that corrects Bitcoin’s transaction mal-
Bank in exchange for money. Unlinkability ensures that leability issue 1). TumbleBit, however, remains secure
the Bank cannot link the withdrawal of an eCash coin to even if this solution is not deployed as explained in
the redemption of it. TumbleBit provides unlinkability, Appendix I.
with Tumbler T playing the role of the Chaumian Bank.
However, while Tumbler T need not be trusted, the No coordination. In contrast to earlier work [35], [52],
Chaumian Bank is trusted to not (1) “print money” if Alice A wants to pay Bob B, she need not interact
(i.e., issue eCash coins to itself) or (2) steal money (i.e., with any other TumbleBit users. Instead, A and B need
refuse to exchange coins for money). only interact with the Tumbler and each other. This
lack of coordination between TumbleBit users makes
TumbleBit: As a classic tumbler. TumbleBit can also it possible to scale our system.
be used as a classic Bitcoin tumbler, mixing together the
2 True fair exchange is impossible in the standard model [46]
transfer of one bitcoin from ℵ distinct payers (Alice A)
to ℵ distinct payees (Bob B). In this mode, TumbleBit is and thus alternatives have been proposed, such as gradual release
mechanisms, optimistic models, or use of a trusted third party. We
run as in Figure 1 with the payment phase shrunk to 30 follow prior works that use Bitcoin for fair exchange [4], [30], [31]
seconds, so the protocol runs in epochs that require two and treat the blockchain as a trusted public ledger. Other works use
blocks added to the blockchain. As a classic tumbler, the term Contingent Payment or Atomic Swaps [34], [6].

2
Scheme Prevents Theft Anonymous Resists DoS Resists Sybils Minimum Mixing Time Bitcoin Compatible No Coordination?
Coinjoin [35] X small set × × 1 block X ×
Coinshuffle [52], [41] X small set × × 1 block X × (p2p network)
1
Coinparty [59] 2/3 users honest X some X (fees) 2 blocks X ×
XIM [13] X X X X (fees) hours X × (uses blockchain)
Mixcoin [15] TTP accountable × (TTP) X X (fees) 2 blocks X X
Blindcoin [57] TTP accountable X X X (fees) 2 blocks X X
CoinSwap [36] X × (TTP)2 X X (fees) 2 blocks X X
BSC [25] X X X X (fees) 3 blocks × X
TumbleBit X X X X (fees) 2 blocks X X
TABLE I. A COMPARISON OF B ITCOIN T UMBLER SERVICES . TTP STANDS FOR T RUSTED T HIRD PARTY. W E COUNT MINIMUM MIXING
TIME BY THE MINIMUM NUMBER OF B ITCOIN BLOCKS . A NY MIXING SERVICE INHERENTLY REQUIRES AT LEAST ONE BLOCK .
1 C OINPARTY COULD ACHIEVE SOME D O S RESISTANCE BY FORCING PARTIES TO SOLVE PUZZLES BEFORE PARTICIPATING .

Performance. We have implemented our TumbleBit compatible, Bolt has not been implemented and employs
system in C++ and python, using LibreSSL as our scripting functionalities that are not available in Bitcoin.
cryptographic library. We have tumbled payments from Instead, Bolt runs on top of Zerocash [40], [10].
800 payers to 800 payees; the relevant transactions are
Bolt operates in several modes, including a unidirec-
visible on the blockchain. (See Section VIII-C).Our
tional payment channel (where Alice can pay Bob), a
protocol requires 327 KB of data on the wire, and
bidirectional payment channel (where Alice and Bob
0.6 seconds of computation on a single CPU. Thus,
can pay each other), and bidirectional payment hub
performance in classic tumbler mode is limited only
(where Alice and Bob can pay each other through
by the time it takes for two blocks to be confirmed
an Intermediary). The latter mode is most relevant to
on the blockchain and the time it takes for transactions
TumbleBit, and offers different unlinkability properties.
to be confirmed; currently, this takes ≈ 20 minutes.
First, Bolt hides the denomination of the payment from
Meanwhile, off-blockchain payments can complete in
the Intermediary; meanwhile, TumbleBit payments all
seconds (Section VIII).
have the same denomination, which is revealed to the
Tumbler. Second, off-blockchain Bolt payments hide
B. Related Work
the identity of the payer and payee; meanwhile, off-
TumbleBit is related to work proposing new anony- blockchain TumbleBit payments reveals the identity of
mous cryptocurrencies (e.g., Zerocash [40], [10], Mon- the payee (but not the payer) to the Tumbler. Finally,
ero [2] or Mimblewimble [28]). While these are very if a party aborts a payment via Bolt’s bidirectional
promising, they have yet to be as widely adopted as payment hub, then the identity of the payer and payee
Bitcoin. On the other hand, TumbleBit is an anonymity is revealed. In this case, Bolt must fall back on the
service for Bitcoin’s existing user base. anonymity properties of Zerocash, which ensures that
on-blockchain identities are anonymous. Meanwhile,
Off-blockchain payments. When used as an unlinkable abort attacks on TumbleBit are less damaging (see
payment hub, TumbleBit is related to micropayment Section VII-C). This is important because TumbleBit
channel networks, notably Duplex Micropayment Chan- cannot fall back on Zerocash’s anonymity properties.
nels [18] and the Lightning Network [48]. These sys-
tems also allow for Bitcoin-backed fast off-blockchain Bitcoin Tumblers. Prior work on classic Bitcoin
payments. Payments are sent via paths of intermedi- Tumblers is summarized in Table I-A.
aries with pre-established on-blockchain pairwise es-
Blindcoin [57], and its predecessor Mixcoin [15],
crow transactions. TumbleBit (conceptually) does the
use a trusted third party (TTP) to mix Bitcoin addresses.
same. However, while the intermediaries in micropay-
However, this third party can steal users’ bitcoins;
ment channel network can link payments from A to B,
theft is detected but not prevented. In Mixcoin, the
TumbleBit’s intermediary T cannot.
TTP can also violate anonymity. CoinSwap [36] is a
Our earlier workshop paper [25] proposed a protocol fair-exchange mixer that allows two parties to anony-
that adds anonymity to micropayment channel networks. mously send bitcoins through an intermediary. Fair
TumbleBit is implemented and Bitcoin compatible, exchange prevents the CoinSwap intermediary from
while [25] is not. Moreover, [25] requires both Alice stealing funds. Unlike TumbleBit, however, CoinSwap
A and Bob B to interact with the Tumbler T as part of does not provide anonymity against even an honest-but-
every off-blockchain payment. Thus, the Tumbler could curious intermediary. Coinparty [59] is another decen-
correlate the timing of its interactions with A and B tralized solution, but it is secure only if 2/3 of the users
in order to link their payments. Meanwhile, TumbleBit are honest.
eliminates this timing channel by only requiring inter-
CoinShuffle [52] and CoinShuffle++[41] build on
action between A and T (and A and B) during an off-
CoinJoin [35] to provide a decentralized tumbler that
blockchain payment (see Figure 1 and Section VII-B).
prevents bitcoin theft. Their anonymity properties are
TumbleBit is also related to concurrent work propos- analyzed in [39]. CoinShuffle(++) [52], [41] both per-
ing Bolt [24], an off-blockchain unlinkable payment form a mix in a single transaction. Bitcoin’s maximum
channel. While TumbleBit is implemented and Bitcoin transaction size (100KB) limits CoinShuffle(++) to 538

3
users per mix. These systems are also particularly vul- same transaction output T1 . The security of the Bitcoin
nerable to DoS attacks, where a user joins the mix and protocol implies that double-spending transactions will
then aborts, disrupting the protocol for all other users. not be confirmed on the blockchain. Transactions also
Decentralization also requires mix users to interact via include a transaction fee that is paid to the Bitcoin miner
a peer-to-peer network in order to identify each other that confirms the transaction on the blockchain. Higher
and mix payments. This coordination between users fees are paid for larger transactions. Indeed, fees for
causes communication to grow quadratically [13], [14], confirming transactions on the blockchain are typically
limiting scalability; neither [52] nor [41] performs a expressed as “Satoshi-per-byte” of the transaction.
mix with more than 50 users. Decentralization also
Scripts. Each transaction uses Script to determine
makes it easy for an attacker to create many Sybils
the conditions under which the bitcoins held in that
and trick Alice A into mixing with them in order
transaction can be moved to another transaction. We
to deanonymize her payments [14], [56]. TumbleBit
build “smart contracts” from the following transactions:
sidesteps these scalability limitations by not requiring
- Toffer : One party A offers to pay bitcoins to any party
coordination between mix users.
that can sign a transaction that meets some condition C.
XIM [13] builds on fair-exchange mixers like [8]. The Toffer transaction is signed by A.
XIM prevents bitcoin theft, and uses fees to resist DoS - Tfulfill : This transaction points to Toffer , meets the
and Sybil attacks—users must pay to participate in a condition C stipulated in Toffer , and contains the public
mix, raising the bar for attackers that disrupt the proto- key of the party B receiving the bitcoins.
col by joining the mix and then aborting. We use fees in Toffer is posted to the blockchain first. When Tfulfill
TumbleBit as well. Also, an abort by a single XIM user is confirmed by the blockchain, the bitcoins in Tfulfill
does not disrupt the mix for others. TumbleBit also has flow from the party signing transaction Toffer to the
this property. One of XIM’s key innovations is a method party signing Tfulfill . Bitcoin scripts support two types
for finding parties to participate in a mix. However, this of conditions that involve cryptographic operations:
adds several hours to the protocol, because users must
Hashing condition: The condition C stipulated in
advertise themselves as mix partners on the blockchain.
Toffer is: “Tfulfill must contain the preimage of value
TumbleBit is faster; a tumble requires only two blocks
y computed under the hash function H.” Then, Tfulfill
on the blockchain.
collects the offered bitcoin by including a value x such
When used as a classic tumbler, TumbleBit and [25] that H(x) = y. (We use the OP_RIPEMD160 opcode
shares the same fair-exchange properties and anonymity so that H is the RIPEMD-160 hash function.)
properties. However, unlike TumbleBit, [25] is not com- Signing condition: The condition C stipulated in Toffer
patible with Bitcoin and does not provide an implemen- is: “Tfulfill must be digitally signed by a signature that
tation. Also, [25] requires three blocks to be confirmed verifies under public key PK .” Then, Tfulfill fulfills
on the blockchain, while TumbleBit requires two. this condition if it is validly signed under PK . The
Implementation. After this paper was first posted signing condition is highly restrictive: (1) today’s Bit-
online, Dorier and Ficsor began an independent open- coin protocol requires the signature to be ECDSA over
source TumbleBit implementation.3 the Secp256k1 elliptic curve [50]—no other elliptic
curves or types of signatures are supported, and (2)
the condition specifically requires Tfulfill itself to be
II. B ITCOIN S CRIPTS AND S MART C ONTRACTS signed. Thus, one could not use the signing condi-
In designing TumbleBit, our key challenge was tion to build a contract whose condition requires an
ensuring compatibility with today’s Bitcoin protocol. arbitrary message m to be signed by PK .4 (Tum-
We therefore start by reviewing Bitcoin transactions and bleBit uses the OP_CHECKSIG opcode, which re-
Bitcoin’s non-Turing-complete language Script. quires verification of a single signature, and the “2-of-2
multisignature” template ‘OP_2 key1 key2 OP_2
Transactions. A Bitcoin user Alice A is identified by OP_CHECKMULTISIG’ which requires verification of a
her bitcoin address (which is a public ECDSA key), signature under key1 AND a signature under key2.)5
and her bitcoins are “stored” in transactions. A single
transaction can have multiple outputs and multiple in- Script supports composing conditions under
puts. Bitcoins are transferred by sending the bitcoins “IF” and “ELSE”. Script also supports timelocking
held in the output of one transaction to the input of a (OP_CHECKLOCKTIMEVERIFY opcode [55]), where
different transaction. The blockchain exists to provide a Toffer also stipulates that Tfulfill is timelocked to time
public record of all valid transfers. The bitcoins held window tw . (Note that tw is an absolute block height.)
in a transaction output can only be transferred to a This allows the party that posted Tfulfill to reclaim their
single transaction input. A transaction input T3 double- 4 This is why [25] is not Bitcoin-compatible. [25] requires a blind
spends a transaction input T2 when both T2 and T3 signature to be computed over an arbitrary message. Also, ECDSA-
point to (i.e., attempt to transfer bitcoins from) the Secp256k1 does not support blind signatures.
5 Unlike cryptographic multisignatures, a Bitcoin 2-of-2 multisig-
3 https://github.com/NTumbleBit/NTumbleBit nature is a tuple of two distinct signatures and not a joint signature.

4
bitcoin if Tfulfill is unspent and the block height is phase begins and ends. One way to coordinate is to use
higher than tw . Section VIII-A details the scripts used block height; for instance, if the payment phase lasts
in our implementation. See also Appendix I. for 1 day (i.e., ≈ 144 blocks) then the Escrow Phase is
when block height is divisible by 144, and the Cash-Out
2-of-2 escrow. TumbleBit relies heavily on the Phase is when blockheight+1 is divisible by 144.
commonly-used 2-of-2 escrow smart contract. Suppose
that Alice A wants to put Q bitcoin in escrow to 1: Escrow Phase. Every Alice A that wants to send
be redeemed under the condition C2of 2 : “the fulfilling payments (and Bob B that wants to receive payments)
transaction includes two signatures: one under public during the upcoming Payment Phase runs the escrow
key PK 1 AND one under PK 2 .” phase with T . The escrow phase has two parts:
To do so, A first creates a multisig address (a) Payee B asks the Tumbler T to set up a payment
PK (1,2) for the keys PK 1 and PK 2 using the Bit- channel. T escrows 1 bitcoin on the blockchain via
coin createmultisig command. Then, A posts an a 2-of-2 escrow transaction (Section II) denoted as
escrow transaction Tescr on the blockchain that sends Tescr(T ,B) stipulating that 1 bitcoin can be claimed by
Q bitcoin to this new multisig address PK (1,2) . The any transaction signed by both T and B. Tescr(T ,B) is
Tescr transaction is essentially a Toffer transaction that timelocked to time window tw 2 , after which T can
requires the fulfilling transaction to meet condition reclaim its bitcoin. Similarly, the payeer A escrows 1
C2of 2 . We call the fulfilling transaction Tcash the cash- bitcoin in a 2-of-2 escrow with T denoted as Tescr(A,T ) ,
out transaction. Given that A doesn’t control both PK 1 timelocked for time window tw 1 such that tw 1 < tw 2 .
and PK 2 (i.e., doesn’t know the corresponding secret Upon conclusion of the puzzle-promise protocol both
keys), we also timelock the Tescr transaction for a time the escrows are established by confirming Tescr(A,T ) ,
window tw . Thus, if a valid Tcash is not confirmed by Tescr(T ,B) on Bitcoin’s blockchain.
the blockchain within time window tw , the escrowed
(b) Bob B obtains a puzzle z through an off-
bitcoins can be reclaimed by A. Therefore, A’s bitcoins
blockchain cryptographic protocol with T which we call
are escrowed until either (1) the time window expires
the puzzle-promise protocol. Conceptually, the output of
and A reclaims her bitcoins or (2) a valid Tcash is
this protocol is a promise by T to pay 1 bitcoin to B
confirmed. TumbleBit uses 2-of-2 escrow to establish
in exchange for the solution to a puzzle z. The puzzle
pairwise payment channels, per Figure 1.
z is just an RSA encryption of a value 
III. T UMBLE B IT: A N U NLINKABLE PAYMENT H UB z = fRSA (, e, N ) = e mod N (1)
Our goal is to allow a payer, Alice A, to unlinkably where (e, N ) is the TumbleBit RSA public key of
send 1 bitcoin to a payee, Bob B. Naturally, if Alice the Tumbler T . “Solving the puzzle” is equivalent
A signed a regular Bitcoin transaction indicating that to decrypting z and thus obtaining its “solution” .
Addr A pays 1 bitcoin to Addr B , then the blockchain Meanwhile, the “promise” c is a symmetric encryption
would record a link between Alice A and Bob B under key 
and anonymity could be harmed using the techniques c = Enc (σ)
of [38], [51], [12]. Instead, TumbleBit funnels payments
from multiple payer-payee pairs through the Tumbler T , where σ is the Tumbler’s ECDSA-Secp256k1 signature
using cryptographic techniques to ensure that, as long on the transaction Tcash(T ,B) which transfers the bitcoin
as T does not collude with TumbleBit’s users, then no escrowed in Tescr(T ,B) from T to B. (We use ECDSA-
one can link a payment from payer A to payee B. Secp256k1 for compatibility with the Bitcoin protocol.)
Thus, the solution to a puzzle z enables B to claim 1
bitcoin from T . To prevent misbehavior by the Tumbler
A. Overview of Bob’s Interaction with the Tumbler T , our puzzle-promise protocol requires T to provide a
We overview TumbleBit’s phases under the assump- proof that the puzzle solution  is indeed the key which
tion that Bob B receives a single payment of value decrypts the promise ciphertext c. The details of this
1 bitcoin. TumbleBit’s Anonymity properties require protocol, and its security guarantees, are in Section VI.
all payments made in the system to have the same 2: Payment Phase. Once Alice A indicates she is ready
denomination; we use 1 bitcoin for simplicity. Ap- to pay Bob B, Bob B chooses a random blinding factor
pendix A shows how Bob can receive multiple payments r ∈ ZN∗
and blinds the puzzle to
of denomination 1 bitcoin each.
z = re z mod N. (2)
TumbleBit has three phases (Fig 1). Off-blockchain
TumbleBit payments take place during the middle Pay- Blinding ensures that even T cannot link the original
ment Phase, which can last for hours or even days. puzzle z to its blinded version z. Bob B then sends z to
Meanwhile, the first Escrow Phase sets up payment A. Next, A solves the blinded puzzle z by interacting
channels, and the last Cash-Out Phase closes them with T . This puzzle-solver protocol is a fair exchange
down; these two phases require on-blockchain transac- that ensures that A transfers 1 bitcoin to T iff T gives
tions. All users of TumbleBit know exactly when each a valid solution to the puzzle z. Finally, Alice A sends

5
the solution to the blinded puzzle  back to Bob B. Bob 𝓐1 t3 𝓑1 2 BTC
?
unblinds  to obtain the solution t5
?
𝓐2 t2
?
 = /r mod N (3) t3
? 𝓑2 3 BTC
t4
and accepts Alice’s payment if the solution is valid, i.e., 𝓐3 t1
?
?
e = z mod N . t6
𝓐4 ? 𝓑3 3 BTC
t5
3: Cash-Out Phase. Bob B uses the puzzle solution  ? A compatiable interaction graph
Payer puzzle-solver payments Payee cashouts
to decrypt the ciphertext c. From the result B can create

{
{
a transaction Tcash(T ,B) that is signed by both T and B. Tumbler's View
B posts Tcash(T ,B) to the blockchain to receive 1 bitcoin
from T . Fig. 2. Our unlinkability definition: The Tumblers view and a
compatible interaction multi-graph.
Our protocol crucially relies on the algebraic prop-
erties of RSA, and RSA blinding. To make sure that T (i.e., that T holds i bitcoins while A holds Q − i
the Tumbler is using a valid RSA public key (e, N ), bitcoins). T collects a new Tcash(A,T ) (i) from A for
TumbleBit also has an one-time setup phase: each payment. If Alice refuses to sign Tcash(A,T ) (i),
0: Setup. Tumbler T announces its RSA public then the Tumbler refuses to help Alice solve further
key (e, N ) and Bitcoin address AddrT , together with puzzles. Importantly, each Tcash(A,T ) (i) for i = 1...j
a non-interactive zero knowledge proof that RSA with (for j < Q) is signed by Alice A but not by T , and is
parameters (e, N ) is a permutation and a proof of not posted to the blockchain. At the end of the Payment
knowledge of the associated RSA secret key6 . Every Phase, A has made j payments, and the Tumbler T has
user of TumbleBit validates (e, N ) using π. transaction Tcash(A,T ) (j), signed by Alice A, reflecting
a balance of j bitcoins for T and Q − j bitcoins for T .
B. Overview of Alice’s Interaction with the Tumbler 3: Cash-Out Phase. The Tumbler T claims its bit-
We now focus on the puzzle-solving protocol be- coins from Tescr(A,T ) by signing Tcash(A,T ) (j) and
tween A and the Tumbler T to show how TumbleBit posting it to the blockchain. This fulfills the condi-
allows A to make many off-blockchain payments via tion in Tescr(A,T ) , which stipulated that the escrowed
only two on-blockchain transactions (aiding scalability). coins be claimed by a transaction signed by both A
and T . (Notice that all the Tcash(A,T ) (i) point to the
During the Escrow Phase, Alice opens a payment same escrow transaction Tescr(A,T ) . The blockchain
channel with the Tumbler T by escrowing Q bitcoins in will therefore only confirm one of these transactions;
an on-blockchain transaction Tescr(A,T ) . Each escrowed otherwise, double spending would occur. Rationally,
bitcoin can pay T for the solution to one puzzle. Next, the Tumbler T always prefers to confirm Tcash(A,T ) (j)
during the off-blockchain Payment Phase, A makes off- since it transfers the maximum number of bitcoins to
blockchain payments to j ≤ Q payees. Finally, during T .) Because Tcash(A,T ) (j) is the only transaction signed
the Cash-Out Phase, Alice A pays the Tumbler T by by the Tumbler T , a cheating Alice cannot steal bitcoins
posting a transaction Tcash(A,T ) (j) that reflects the new by posting a transaction that allocates fewer than j
allocation of bitcoins; namely, that T holds j bitcoins, bitcoins to the Tumbler T .
while A holds Q − j bitcoins. The details of Alice A’s
interaction with T , which are based on a technique used Remark: Scaling Bitcoin. A similar (but more elaborate)
in micropayment channels [44, p. 86], are as follows: technique can be applied between B and T so that only
two on-blockchain transactions suffice for Bob B to
1: Escrow Phase. Alice A posts a 2-of-2 escrow receive an arbitrary number of off-blockchain payments.
transaction Tescr(A,T ) to the blockchain that escrows Q Details are in Appendix A. Given that each party uses
of Alice’s bitcoins. If no valid transaction Tcash(A,T ) is two on-blockchain transactions to make multiple off-
posted before time window tw 1 , then all Q escrowed blockchain playments, Tumblebit helps Bitcoin scale.
bitcoins can be reclaimed by A.
2: Payment Phase. Alice A uses her escrowed bitcoins C. TumbleBit’s Security Properties
to make off-blockchain payments to the Tumbler T . For
each payment, A and T engage in an off-blockchain Unlinkability. We assume that the Tumbler T does not
puzzle-solver protocol (see Sections V-B,V-D). collude with other users. The view of T consists of (1)
the set of escrow transactions established between (a)
Once the puzzle is solved, Alice signs and gives T escrow,a
each payer Aj and the Tumbler (Aj −→ i T ) of value
a new transaction Tcash(A,T ) (i). Tcash(A,T ) (i) points to escrow,b
ai and (b) the Tumbler and each payee Bi (T −→ i Bi ),
Tescr(A,T ) and reflects the new balance between A and
(2) the set of puzzle-solver protocols completed with
6 The zero-knowledge proof of knowledge can be realized via the each payer Aj at time t during the Payment Phase, and
Poupard-Stern protocol [49] that proves knowledge of the factorization (3) the set of cashout transactions made by each payer
of the RSA modulus N . Aj and each payee Bi during the Cash-Out Phase.

6
 An interaction multi-graph is a mapping of pay- receiving payments (payees). Each payment is of de-
ments from payers to payees (Figure 2). For each nomination 1 bitcoin, and the mapping from payers to
successful puzzle-solver protocol completed by payer payees is a bijection. During one epoch, the protocol
Aj at time t, this graph has an edge, labeled with time itself is identical to that in Section III with the following
t, from Aj to some payee Bi . An interaction graph is changes: (1) the duration of the Payment Phase shrinks
compatible if it explains the view of the Tumbler T , to seconds (rather than hours or days); (2) each payment
i.e., the number of edges incident on Bi is equal to the channel escrows exactly Q = 1 bitcoin; and (3) every
total number of bitcoins cashed out by Bi . Unlinkability payee Bob B receives payments at an ephemeral bitcoin
requires all compatible interaction graphs to be equally address Addr B chosen freshly for the epoch.
likely. Anonymity therefore depends on the number of
compatible interaction graphs.
A. Anonymity Properties
Notice that payees Bi have better anonymity than
payers Aj . (This follows because the Tumbler T knows As a classic tumbler, TumbleBit has the same bal-
the time t at which payer Aj makes each payment. ance property, but stronger anonymity: k-anonymity
Meanwhile, the Tumbler T only knows the aggregate within an epoch [25], [13]. Specifically, while the
amount of bitcoins cashed-out by each payee Bi .) blockchain reveals which payers and payees participated
in an epoch, no one (not even the Tumbler T ) can
A high-level proof of TumbleBit’s unlinkability is tell which payer paid which payee during that specific
in Section VII, and the limitations of unlinkability are epoch. Thus, if k payments successfully completed
discussed in Section VII-C. during an epoch, the anonymity set is of size k. (This
Balance. The system should not be exploited to print stronger property follows directly from our unlinkability
new money or steal money, even when parties collude. definition (Section III-C): there are k compatible inter-
As in [24], we call this property balance, which estab- action graphs because the interaction graph is bijection.)
lishes that no party should be able to cash-out more Recovery from anonymity failures. It’s not always the
bitcoins than what is dictated by the payments that case that k = ℵ. The exact anonymity level achieved
were successfully completed in the Payment Phase. We in an epoch can be established only after its Cash-Out
discuss how TumbleBit satisfies balance in Section VII. Phase. For instance, anonymity is reduced to k = ℵ − 1
DoS and Sybil protection. TumbleBit uses transaction if T aborts an payment made by payer Aj . We deal
fees to resist DoS and Sybil attacks. Every Bitcoin with this by requiring B to uses an ephemeral Bitcoin
transaction can include a transaction fee that is paid address Addr B in each epoch. Consider first a malicious
to the Bitcoin miner who confirms the transaction on Tumbler T that behaves itself during the Escrow Phase
the blockchain as an incentive to confirm transactions. of some epoch, but then refuses to help some payer A
However, because the Tumbler T does not trust Alice solve a puzzle during the Payment Phase. The payment
A and Bob B, T should not be expected to pay fees from A to its payee B will fail. As such, the payee
on the transactions posted during the Escrow Phase. To B will not be able to claim a bitcoin from T during
this end, when Alice A establishes a payment channel the Cash-Out Phase. It follows that the Tumbler can
with T , she pays for both the Q escrowed in transaction trivially link A and B by identifying the payee that
Tescr(A,T ) and for its transaction fees. Meanwhile, when failed to cash out. To recover from this, we follow [25]
the Tumbler T and Bob B establish a payment channel, and require B to discard his ephemeral address and
the Q escrowed bitcoins in Tescr(T ,B) are paid in the never use it again if T aborts the protocol. Note that
Tumbler T , but the transaction fees are paid by Bob B both B loses nothing in this case, since no funds have
(Section III-A). Per [13], fees raise the cost of an DoS been transferred from T to B. Also, A loses nothing,
attack where B starts and aborts many parallel sessions, since by the fair-exchange property of the puzzle-solver
locking T ’s bitcoins in escrow transactions. This simi- protocol (Theorem 1) T only obtains a bitcoin from A
larly provides Sybil resistance, making it expensive for if it cooperated in solving the puzzle.
an adversary to harm anonymity by tricking a user into
Let us now consider a non-aborting epoch with
entering a run of TumbleBit where all other users are
a small anonymity set. If B is comfortable with the
Sybils under the adversary’s control.
size of his anonymity set, he can use standard Bitcoin
transactions to move the bitcoin from his ephemeral
IV. T UMBLE B IT: A LSO A C LASSIC T UMBLER . address to his long-lived Bitcoin address. Otherwise,
if he thinks that the anonymity set is too small, B
We can also operate TumbleBit as classic Bitcoin can remix, i.e., choose a new fresh ephemeral address
Tumbler. As a classic Tumbler, TumbleBit operates in Addr 0B and rerun the protocol where his old ephemeral
epoches, each of which (roughly) requires two blocks address Addr B pays his new ephemeral address Addr 0B .
to be confirmed on the blockchain (≈ 20 mins). During Remixing can continue until B is happy with the size
each epoch, there are exactly ℵ distinct bitcoin addresses of his anonymity set, and he transfers his funds to his
making payments (payers) and ℵ bitcoin addresses long-lived address.

7
Remark: Intersection attacks. While this notion of k- blinded puzzles (see equation (2)), and thus can be used
anonymity is commonly used in Bitcoin tumblers (e.g., to create an unlinkable payment scheme. Section V-D
[13], [25]), it does suffer from the following weakness. shows how our protocol is integrated into TumbleBit’s
Any adversary that observes the transactions posted to Payment Phase. Implementation results are in Table II
the blockchain within one epoch can learn which payers of Section VIII-B.
and payees participated in that epoch. Then, this infor-
mation can be correlated to de-anonymize users across A. Approaches from the Literature
epochs (e.g., using frequency analysis or techniques
used to break k-anonymity [21]). These ‘intersection at- Contingent payments. Maxwell described a
tacks’ follow because k-anonymity is composed across protocol for “zero-knowledge contingent payments”
epochs; see also [13], [39] for discussion. (ZKCP) [34]. The scheme in [34] swaps one bitcoin
from Alice A in exchange for having T compute any
DoS and Sybil Attacks. We use fees to resist DoS agreed-upon function f on an input of A’s choosing.
and Sybil attacks. Alice again pays for both the Q The idea is as follows. After T computes the result
escrowed in transaction Tescr(A,T ) and for its transaction f (y) on Alice’s input y, it encrypts the result under
fees. However, we run into a problem if we want Bob a randomly chosen key k to obtain a ciphertext c,
B to pay the fee on the escrow transaction Tescr(T ,B) . and hashes the encryption key to obtain h = H(k).
Because Bob B uses a freshly-chosen Bitcoin address T then sends Alice A the ciphertext c and hash h
Addr B , that is not linked to any prior transaction on along with a zero-knowledge (ZK) proof that they
the blockchain, Addr B cannot hold any bitcoins. Thus, were formed correctly. (This proof must been done
Bob B will have to pay the Tumbler T out of band. in zero knowledge, because T should not reveal the
The anonymous fee vouchers described in [25] provide key k that decrypts f (y) to A before being paid with
one way to address this, which also has the additional A’s bitcoin.) After A verifies the proof, A posts a
feature that payers A cover all fees. transaction Tpuzzle offering one bitcoin under condition:
“Tsolve must contain the hash preimage of h”. T claims
An anonymous fee voucher is a blind signature σ the bitcoin by posting a transaction Tsolve containing
that T provides to A in exchange for a small out-of- k. Now A can use k to decrypt c to obtain her desired
band payment; A could pre-purchase these vouchers output f (y). This realizes a fair exchange because the
in bulk, before she begins participating in TumbleBit. offered bitcoin reverts back to A if T fails to post a
Then, when A is ready to participate, she unblinds σ to valid Tsolve in a timely manner.
σ and provides it to B who passes it along to T . The
protocol begins once T is sure that it was paid for its The limitations of using ZKCP in this setting arise
efforts. due to the inefficiency of the instantiations of ZK proofs.
Two main approaches exist:
V. A FAIR E XCHANGE FOR RSA P UZZLE S OLVING ZKCP via ZK-Snarks. Recently, [37] showed how to
instantiate the ZK proofs used in this protocol with ZK-
We now explain how to realize a Bitcoin-compatible
Snarks [11]. The function f was a 16x16 Sudoku puzzle
fair-exchange where Alice A pays Tumbler T one
and the resulting protocol was run and completed within
bitcoin iff the T provides a valid solution to an RSA
20 seconds. We could use this approach in our setting by
puzzle. The Tumbler T has an RSA secret key d and the −1
(1) letting f be fRSA , an RSA decryption/signature, and
corresponding public key (e, N ). The RSA puzzle y is
(2) using [37]’s ZK-snark but replacing the verification
provided by Alice, and its solution is an RSA secret-key
of the Sudoku puzzle with an RSA verification fRSA .
exponentiation
One disadvantage of this approach is that RSA verifi-
−1
 = fRSA (y, d , N ) = y d mod N (4) cation within a ZK-Snark is likely to be slower than
Sudoku puzzle verification because state-of-the-art ZK-
The puzzle solution is essentially an RSA decryption or Snarks operate in prime order fields of (roughly) 254
RSA signing operation. bits. Since a 2048-bit RSA verification deals with 2048-
bit numbers, each such number has to be split up and
This protocol is at the heart of TumbleBit’s Payment
expressed as an array of smaller ones, making arithmetic
Phase. However, we also think that this protocol is
operations far more complicated [19]. In any case, our
of independent interest, since there is also a growing
protocol for RSA exponentiation is faster than [37]’s
interest in techniques that can fairly exchange a bitcoin
protocol for 16x16 Sudoku puzzles (Section VIII).
for the solution to a computational “puzzle”. We there-
Also, ZK-Snarks are only secure under less standard
fore start by surveying the literature in Section V-A.
cryptographic assumptions. Meanwhile, our protocol’s
Section V-B presents our RSA-puzzle-solver protocol
security follows from the standard RSA assumption (in
as a stand-alone protocol that requires two blocks to
the random oracle model).
be confirmed on the blockchain. Our protocol is fast—
solving 2048-bit RSA puzzles faster than [37]’s protocol ZKCP via Garbled Circuits. As an alternative to ZK-
for solving 16x16 Sudoku puzzles (Section VIII)). Also, Snarks, one could use more generic ZK proofs based
the use of RSA means that our protocol supports solving on zero-knowledge garbled circuits (GC) as shown

8
in [27]. While GC-based ZK proofs work reasonably cheat if all of the “opened” values are correct and all
well for evaluating hash functions, they are computa- of the “hidden” ones are incorrect. This allows us to
tionally heavier for modular exponentiations (like RSA use fewer values in order to more efficiently achieve a
verification) because the latter do not have a short better security level.)
Boolean-circuit representation [29].
Thus, instead of asking T to provide just one (c, h)
ZKCP via Proof-of-Knowledge. A concurrent work [7] pair, T will be asked to provide m + n pairs (Step 3).
proposes proposing ZKCP using Bitcoin Script’s Sign- Then, we use cut and choose: A asks T to “open” n
ing Condition (Section II) rather than its Hashing Con- of these pairs, by revealing the randomly-chosen keys
dition. [7] aims to be generic to all problems that have ki ’s used to create each of the n pairs (Step 7). For
zero-knowledge proof-of-knowledge protocols. Our ap- a malicious T to successfully cheat A, it would have
proach is customized to RSA puzzles. [7] needs about to correctly guess all the n “challenge” pairs and form
2 minutes to sell a 1024-bit RSA factorization with a them properly (so it does not get caught), while at the
cheating probability of 2−48 . Our approach is faster, same time malforming all the m unopened pairs (so it
solving 2048-bit RSA puzzles in seconds with cheating can claim a bitcoin from A without actually solving the
probability of ≈ 2−80 . puzzle). Since T cannot predict which pairs A asks it
Incentivizing correct computation. [30] proposed a to open,
T can only cheat with very low probability
different approach that also uses GCs. Two parties use 1/ m+nn .
GCs to compute an arbitrary function g(a, b) without However, we have a problem. Why should T agree
revealing their respective inputs a and b. [30]’s protocol to open any of the (c, h) values that it produced? If A
has the added feature that if one party aborts before received the opening of a correctly formed (c, h) pair,
the output is revealed, the other party is automatically she would be able to obtain a puzzle solution without
compensated with bitcoins. To use this protocol in our paying a bitcoin. As such, we introduce the notion of
−1
setting, the function g should be fRSA , input a is the “fake values”. Specifically, the n (c, h)-pairs that A asks
RSA secret key d of T , and b becomes the input y T to open will open to “fake values” rather than “real”
chosen by A. Then, if T aborts the protocol before puzzles. Before T agrees to open them (Step 7), A must
A learns the output, the bitcoin offered by A can be prove that these n values are indeed fake (Step 6).
reclaimed by A. Again, however, the efficiency of this
approach is limited by the computational overhead of We must also ensure that T cannot distinguish “real
performing modular exponentiations inside a GC. puzzles” from “fake values”. We do this with RSA
blinding. The real puzzle y is blinded m times with
Our protocol sidesteps these issues by avoiding ZK
different RSA-blinding factors (Step 1), while the n
proofs and GCs altogether.
fake values are RSA-blinded as well (Step 2). Finally,
A randomly permutes the real and fake values (Step 3).
B. Our (Stand-Alone) RSA-Puzzle-Solver Protocol
The following stand-alone protocol description as- Once Alice confirms the correctness of the opened
sumes Alice A wants to transfer 1 bitcoin in exchange “fake” (c, h) values (Step 7), she signs a transaction
for one puzzle solution. Section V-D shows how to Tpuzzle offering one bitcoin for the keys k that open all
support the transfer of up to Q bitcoins for Q puzzle of the m “real” (c, h) values (Step 8). But what if Alice
solutions (where each solution is worth 1 bitcoin). cheated, so that each of the “real” (c, h) values opened
to the solution to a different puzzle? This would not be
The core idea is similar to that of contingent pay- fair to T , since A has only paid for the solution to a
ments [34]: Tumbler T solves Alice’s A’s puzzle y by single puzzle, but has tricked T into solving multiple
computing the solution y d mod N , then encrypts the puzzles. We solve this problem in Step 9: once A posts
solution under a randomly chosen key k to obtain a Tpuzzle , she proves to T that all m “real” values open to
ciphertext c, hashes the key k under bitcoin’s hash as the same puzzle y. This is done by revealing the RSA-
h = H(k) and finally, provides (c, h) to Alice. Alice A blinding factors blinding puzzle y. Once T verifies this,
prepares Tpuzzle offering one bitcoin in exchange for the T agrees to post Tsolve which reveals m of the k values
preimage of h. Tumbler T earns the bitcoin by posting that open “real” (c, h) pairs (Step 10). A gets a valid
a transaction Tsolve that contains k, the preimage of h, solution to puzzle y if at least one of the real (c, h)
and thus fulfills the condition in Tpuzzle and claims a pairs is validly formed (Step 11).
bitcoin for T . Alice A learns k from Tsolve , and uses k
to decrypt c and obtain the solution to her puzzle.
C. Fair Exchange
Our challenge is to find a mechanism that allows A
to validate that c is the encryption of the correct value, Fair exchange exchange entails the following: (1)
without using ZK proofs. We do so by applying the Fairness for T : After one execution of the protocol A
cut-and-choose technique and exploiting the blinding will learn the correct solution y d mod N to at most
properties of RSA. (We follow the blueprint of Lindell’s one puzzle y of her choice. (2) Fairness for A: T will
recent work [33]. Roughly, a malicious party can only earn 1 bitcoin iff A obtains a correct solution.

9
 Public input: (e, N ).
π proves validity of (e, N ) in a one-time-only setup phase.
Alice A Tumbler T
Input: Puzzle y Secret input: d

1. Prepare Real Puzzles R

For j ∈ [m], pick rj ∈ Z∗N
dj ← y · (rj )e mod N

2. Prepare Fake Values F

For i ∈ [n], pick ρi ∈ Z∗N
δi ← (ρi )e mod N

3. Mix Sets.
Randomly permute 4. Evaluation
{d1 . . . dm , δ1 . . . δn } For i = 1 . . . m + n
β1 ...βm+n
to {β1 . . . βm+n } −−−−−−→ Evaluate βi : si = βid mod N
Let R be the indices of the di Encrypt the result si :
Let F be the indices of the δi – Choose random ki ∈ {0, 1}λ1
– ci = H prg (ki ) ⊕ si
Commit to the keys: hi = H(ki )
c1 ,...,cm+n
←−−−−−−−
h1 ,...,hm+n
←−−−−−−−
F,ρi ∀i∈F
5. Identify Fake Set F −−−−−−→ 6. Check Fake Set F
For all i ∈ F :
Verify βi = (ρi )e mod N ,
If yes, reveal ki ∀i ∈ [F ].
7. Check Fake Set F Else abort.
k ∀i∈F
For all i ∈ F , i
←− −−−−
Verify that hi = H(ki )
Decrypt si = H prg (ki ) ⊕ ci
Verify si = ρi mod N
Abort if any check fails.

8. Post transaction Tpuzzle

Tpuzzle offers 1 bitcoin within timewindow tw 1
under condition “the fulfilling transaction is
signed by T and has preimages of hj ∀j ∈ R”.
9. Check βj unblind to y ∀j ∈ R
y, rj ∀j∈R
−−−−−−−→ For all j ∈ R
Verify βj = y · (rj )e mod N
If not, abort.

10. Post transaction Tsolve

Tsolve contains kj ∀j ∈ R
11. Obtain Puzzle Solution
For j ∈ R:
Learn kj from Tsolve
Decrypt cj to sj = H prg (kj ) ⊕ cj
If sj is s.t. (sj )e = βj mod N ,
Obtain solution sj /rj mod N
which is y d mod N .
Fig. 3. RSA puzzle solving protocol. H and H prg are modeled as random oracles. In our implementation, H is RIPEMD-160, and H prg is
ChaCha20 with a 128-bit key, so that λ1 = 128.

10
 We prove this using the real-ideal paradigm [22]. Figure 3 with the following modifications after Step 8
We call the ideal functionality Ffair-RSA and present it in (so that it runs entirely off-blockchain):
Appendix C. Ffair-RSA acts like a trusted party between
A and T . Ffair-RSA gets a puzzle-solving request (y, 1 (1) Because the Payment Phase is off-blockchain,
bitcoin) from A, and forwards the request to T . If T transaction Tpuzzle from Figure 3 is not posted to the
agrees to solve puzzle y for A, then T gets 1 bitcoin blockchain. Instead, Alice A forms and signs transaction
and A gets the puzzle solution. Otherwise, if T refuses, Tpuzzle and sends it to the Tumbler T . Importantly,
A gets 1 bitcoin back, and T gets nothing. Fairness for Tumbler T does not sign or post this transaction yet.
T is captured because A can request a puzzle solution (2) Transaction Tpuzzle points to the escrow trans-
only if she sends 1 bitcoin to Ffair-RSA . Fairness for B is action Tescr(A,T ) ; Tpuzzle changes its balance so that T
captured because T receives 1 bitcoin only if he agrees holds i bitcoin and Alice A holds Q − i bitcoins. Tpuzzle
to solve the puzzle. The following theorem is proved in is timelocked to time window tw 1 and stipulates the
Appendix E: same condition in Figure 3: “the fulfilling transaction is
Theorem 1: Let λ be the security parameter, m, n signed by T and has preimages of hj ∀j ∈ R.”
be statistical security parameters, let N > 2λ . Let π be (Suppose that T deviates from this protocol, and
a publicly verifiable zero-knowledge proof that fRSA instead immediately signs and post Tpuzzle . Then the
with parameters (N, e) is defines a permutation over ZN bitcoins in Tescr(A,T ) would be transferred to Tpuzzle .
and a proof of knowledge for the associated secret key However, these bitcoins would remain locked in Tpuzzle
d. If the RSA assumption holds in ZN , and if functions until either (a) the timelock tw expired, at which point
H prg , H are independent random oracles, there exists a Alice A could reclaim her bitcoins, or (b) T signs and
negligible function ν, such that protocol in Figure 3 posts a transaction fulfilling the condition in Tpuzzle ,
securely realizes Ffair-RSA in the random oracle model which allows Alice to obtain the solution to her puzzle.)
with the following security guarantees. The security for
T is 1 − ν(λ) while security for A is 1 − m+n1
− ν(λ). (3) Instead of revealing the preimages kj ∀j ∈ R in
( n )
an on-blockchain transaction Tsolve as in Figure 3, the
Tumbler T just sends the preimages directly to Alice.
D. Solving Many Puzzles and Moving Off-Blockchain
(4) Finally, Alice A checks that the preimages open
To integrate the protocol in Figure 3 into TumbleBit, a valid puzzle solution. If so, Alice signs a regular cash-
we have to deal with three issues. First, if TumbleBit out transaction Tcash(A,T ) (per Section III-B). Tcash(A,T )
is to scale Bitcoin (Section III-B), then Alice A must points to the escrow transaction Tescr(A,T ) and reflects
be able to use only two on-blockchain transactions the new balance between A and T .
Tescr(A,T ) and Tcash(A,T ) to pay for the an arbitrary
number of Q puzzle solutions (each worth 1 bitcoin) At the end of the ith payment, the Tumbler T should
during the Payment Phase; the protocol in Figure 3 have two new signed transactions from Alice: Tpuzzle (i)
only allows for the solution to a single puzzle. Second, and Tcash(A,T ) (i), each reflecting the (same) balance of
per Section III-B, the puzzle-solving protocol should bitcoins between T (holding i bitcoins) and A (holding
occur entirely off-blockchain; the protocol in Figure 3 Q−i bitcoins). However, Alice A already has her puzzle
uses two on-blockchain transactions Tpuzzle and Tsolve . solution at this point (step (4) modification above). What
Third, the Tsolve transactions are longer than typical if she refuses to sign Tcash(A,T ) (i)?
transactions (since they contain m hash preimages), and In this case, the Tumbler immediately begins to
thus require higher transaction fees. cash out, even without waiting for the Cash-Out Phase.
To deal with these issues, we now present a fair- Specifically, Tumbler T holds transaction Tpuzzle (i),
exchange protocol that uses only two on-blockchain signed by A, which reflects a correct balance of i
transactions to solve an arbitrary number of RSA bitcoins to T and Q − i bitcoins to A. Thus, T signs
puzzles. Tpuzzle (i) and posts it to the blockchain. Then, T claims
the bitcoins locked in Tpuzzle (i) by signing and posting
Escrow Phase. Before puzzle solving begins, Alice transaction Tsolve . As in Figure 3, Tsolve fulfills Tpuzzle
posts a 2-of-2 escrow transaction Tescr(A,T ) to the by containing the m preimages kj ∀j ∈ R. The bitcoin
blockchain that escrows Q bitcoins, (per Section III-B). in Tescr(A,T ) will be transferred to Tpuzzle and then to
Tescr(A,T ) is timelocked to time window tw 1 , and Tsolve and thus to the Tumbler T . The only harm done is
stipulates that the escrowed bitcoins can be transferred that T posts two longer transactions Tpuzzle (i), Tsolve (i)
to a transaction signed by both A and T . (instead of just Tcash(A,T ) ), which require higher fees
to be confirmed on the blockchain. (Indeed, this is why
Payment Phase. Alice A can buy solutions for up to we have introduced the Tcash(A,T ) (i) transaction.)
Q puzzles, paying 1 bitcoin for each. Tumbler T keeps
a counter of how many puzzles it has solved for A, Cash-Out Phase. Alice has j puzzle solutions once
making sure that the counter does not exceed Q. When the the Payment Phase is over and the Cash-Out Phase
A wants her ith puzzle solved, she runs the protocol in begins. If the Tumbler T has a transaction Tcash(A,T ) (j)

11
signed by Alice, the Tumbler T just signs and post this to create an ECDSA-Secp256k1 signature σi . Each σi is
transaction to the blockchain, claiming its j bitcoins. then hidden inside an promise ci which can decrypted
with key i . Finally, T hides each i (the encryption
We implement this protocol and evaluate its perfor- keys) in an RSA puzzle zi per equation (1). As each i is
mance in Table II and Section VIII-B. uniformly chosen at random, puzzle zi computationally
hides its solution i , under the RSA assumption7 .
VI. P UZZLE -P ROMISE P ROTOCOL
Next, B needs to check that the η “fake” (ci , zi )
We present the puzzle-promise protocol run be- pairs are correctly formed by T (Step 8). To do this,
tween B and T in the Escrow Phase. Recall from B needs T to provide the solutions i to the puzzles
Section III-A, that the goal of this protocol is to zi in fake pairs. T reveals these solutions only after
provide Bob B with a puzzle-promise pair (c, z). The B has proved that the η pairs really are fake (Step 7).
“promise” c is an encryption (under key ) of the Once this check is done, B knows that T can cheat with
Tumbler’s ECDSA-Secp256k1 signature σ on the trans- probability less than 1/ µ+η .


η
action Tcash(T ,B) which transfers the bitcoin escrowed
in Tescr(T ,B) from T to B. Meanwhile the RSA-puzzle Now we need our new trick. We want to ensure that
z hides the encryption key  per equation (1). if at least one of the “real” (ci , zi ) pairs opens to a valid
ECDSA-Secp256k1 signature σi , then just one puzzle
If Tumbler T just sent a pair (c, z) to Bob, then solution i with i ∈ R, can be used to open this pair.
Bob has no guarantee that the promise c is actually (We need this because B must decide which puzzle zi
encrypting the correct signature, or that z is actually to give to the payer A for decryption without knowing
hiding the correct encryption key. On the other hand, T which pair (ci , zi ) is validly formed.) We solve this by
cannot just reveal the signature σ directly, because Bob having T provide B with µ − 1 quotients (Step 9).
could use σ to claim the bitcoin escrowed in Tescr(T ,B) j jµ
without actually being paid (off-blockchain) by Alice A q2 = 2 , , . . . , qµ = mod N
during TumbleBit’s Payment Phase. j 1 jµ−1

To solve this problem, we again use cut and choose: where {j1 , . . . , jµ } = R are the indices for the “real”
we ask T to compute many puzzle-promise pairs values. This solves our problem since knowledge of
(ci , zi ), and have Bob B test that some of the pairs are  = j1 allows B to recover of all other ji , since
computed correctly. As in Section V-B, we use “fake” ji = 1 · q2 ·, . . . , ·qi
transactions (that will be “opened” and used only to
check if the other party has cheated) and “real” trans- On the flip side, what if B obtains more than one valid
actions (that remain “unopened” and result in correctly- ECDSA-Secp256k1 signatures by opening the (ci , zi )
formed puzzle-promise pairs). Cut-and-choose guaran- pairs? Fortunately, however, we don’t need to worry
tees that B knows that at least one of the unopened pairs about this. The escrow transaction Tescr(T ,B) offers 1
is correctly formed. However, how does B know which bitcoin in exchange for a ECDSA-Secp256k1 signature
puzzle zi is correctly formed? Importantly, B can only under an ephemeral key PK eph T used only once during
choose one puzzle zi that he will ask Alice A to solve this protocol execution with this specific payee B. Thus,
during TumbleBit’s Payment Phase (Section III-A). To even if B gets many signatures, only one can be used
deal with this, we introduce an RSA quotient-chain to form the cash-out transaction Tcash(T ,B) that redeems
technique that ties together all puzzles zi so that solving the bitcoin escrowed in Tescr(T ,B) .
one puzzle zj1 gives the solution to all other puzzles.
In this section, we assume that B wishes to obtain B. Security Properties
only a single payment of denomination 1 bitcoin; the We again capture the security requirements of the
protocol as described in Figure 4 and Section VI-A puzzle-promise protocol using real-ideal paradigm [22].
suffices to run TumbleBit as a classic tumbler. We The ideal functionality Fpromise-sign is presented in Ap-
discuss its security properties in Section VI-B and pendix D. Fpromise-sign is designed to guarantee the
implementation in Section VIII-B. In Appendix A and following properties: (1) Fairness for T : Bob B learns
Figure 6, we show how to modify this protocol so nothing except signatures on fake transactions. (2) Fair-
that it allows B to receive arbitrary number of Q ness for B: If T agrees to complete the protocol, then
off-blockchain payments using only two on-blockchain Bob B obtains at least one puzzle-promise pair. To do
transactions. this, Fpromise-sign acts a trusted party between B and
T . Bob B sends the “real” and “fake” transactions to
A. Protocol Walk Through Fpromise-sign . Fpromise-sign has access to an oracle that can
compute the Tumbler’s T signatures on any messages.
B prepares µ distinct “real” transactions and η (This provides property (2).) Then, if Tumbler T agrees,
“fake” transactions, hides them by hashing them with
H 0 (Step 2-3), permutes them (Step 4), and finally sends 7 Since we model hash functions as random oracles we can prove
them to T as β1 , ..., βm+n . In Step 5, T signs each βi i is computationally hidden when the hash of i encrypts σi to ci .

12
 Public input: (e, N, PK eph
T , π).
Tumbler T chooses fresh ephemeral ECDSA-Secp256k1 key, i.e., bitcoin address (SK eph eph
T , PK T ).
π proves validity of (e, N ) in a one-time-only setup phase.
Bob B Tumbler T . Secret input: d

1. Set up Tescr(T ,B)

Sign but do not post transaction Tescr(T ,B)
timelocked for tw 2 offering one bitcoin
under the condition: “the fulfilling transaction
must be signed under key PK eph T and
2. Prepare µ Real Unsigned Tcash(T ,B) . under key PK B .”
Tescr(T ,B)
For i ∈ 1, . . . , µ: ←−−−−−−
Choose random pad ρi ← {0, 1}λ
Set Tcash(T ,B) i = CashOutTFormat(ρi )
hti = H 0 (Tfulfill i ).

3. Prepare Fake Set.

For i ∈ 1, . . . , η:
Choose random pad ri ← {0, 1}λ
f ti = H 0 (FakeFormat||ri ).

4. Mix Sets.
Randomly permute
{f t1 , ..., f tη , ht1 , ..., htµ }
to obtain {β1 , ...βµ+η }
Let R be the indices of the hti
Let F be the indices of the f ti
β1 ...βµ+η
−−−−−−→
Choose salt ∈ {0, 1} λ

Compute: hR = H(salt||R)
hF = H(salt||F ) 5. Evaluation.
hR ,hF
−−−−→ For i = 1, . . . , µ + η:
ECDSA sign βi to get σi = Sig(SK eph T , βi )
Randomly choose i ∈ ZN .
Create promise ci = H shk (i ) ⊕ σi
Create puzzle zi =fRSA (i , e, N )
(c1 ,z1 ),...(cµ+η ,zµ+η )
←−−−−−−−−−−−−−− i.e., zi = (i )e mod N
R,F
6. Identify Fake Set. −−→
r ∀i∈F
i
−− −−−→
salt
−−→ 7. Check Fake Set.
Check hR = H(salt||R) and hF = H(salt||F )
For all i ∈ F :
8. Check Fake Set. verify βi = H 0 (FakeFormat||ri )
 ∀i∈F
For all i ∈ F i
←− −−−− Abort if any check fails
- Validate that i < N
- Validate RSA puzzle zi = (i )e mod N
- Validate promise ci :
(a) Decrypt σi = H shk (i ) ⊕ ci
(b) Verify σi , i.e.,
ECDSA-Ver(PK eph 0
T , H (f ti ), σi ) = 1 9. Prepare Quotients.
Abort if any check fails For R = {j1 , ..., jµ }:
q2 ,...,qµ  jµ
←−−−−− set q2 = jj2 , ..., qµ = jµ−1
1
10. Quotient Test.
For R = {j1 , ..., jµ } check equalities:
zj2 = zj1 · (q2 )e mod N
...
zjµ = zjµ−1 · (qµ )e mod N
Abort if any check fails 11. Post transaction Tescr(T ,B) on blockchain

12. Begin Payment Phase.

Set z = zj1 . Send z̄ = z · (r)e to Payer A

Fig. 4. Puzzle-promise protocol when Q = 1. (d, (e, N )) are the RSA keys for the tumbler T . (Sig, ECDSA-Ver) is an ECDSA-Secp256k1
signature scheme. We model H, H 0 and H shk as random oracles. In our implementation, H is HMAC-SHA256 (keyed with salt) . H 0 is
13 used in Bitcoin’s “hash-and-sign” paradigm with ECDSA-Secp256k1.
‘Hash256’, i.e., SHA-256 cascaded with itself, which is the hash function
H shk is SHA-512. CashOutTFormat is shorthand for the unsigned portion of a transaction that fulfills Tescr(T ,B) . The protocol uses ρi to
ensure the output of CashOutTFormat contains sufficient entropy. FakeFormat is a distinguishable public string.
Fpromise-sign provides Bob B with signatures on each double-spending), all colluding Bi∗ cash-out no more
“fake” transaction only. (This provides property (1).) than min(t, j SPj ) bitcoin in total, where t is the
P
The following theorem is proved in Appendix F: total number of bitcoins escrowed by T across all Bi∗ .
Theorem 2: Let λ be the security parameter, m, n Case Bi∗ and T collude. Now suppose that Bi∗ and
be statistical security parameters, let N > 2λ . Let π be T ∗ collude to harm Aj . Fairness for Aj still follows
a publicly verifiable zero-knowledge proof that fRSA directly from the fairness of the puzzle-solver protocol.
with parameters (N, e) defines a permutation over ZN This follows because the only interaction between Aj
and a proof of knowledge for the associated secret and Bi∗ is the exchange of a puzzle (and its solution).
key d. If RSA trapdoor function is hard in ZN , if No other secret information about Aj is revealed to Bi∗ .
H, H 0 , H shk are independent random oracles, if ECDSA Thus, Bi∗ cannot add any additional information to the
is strong existentially unforgeable signature scheme, view of T , that T can use to harm fairness for Aj .
then the puzzle-promise protocol in Figure 4 securely
We do note, however, that an irrational Bob Bi∗ can
realizes the Fpromise-sign functionality. The security for
misbehave by handing Alice Aj an incorrect puzzle z ∗ .
T is 1 − ν(λ) while security for B is 1 − µ+η 1
− ν(λ).
( η ) In this case, the fairness of the puzzle-solver protocol
ensures that Alice Aj will pay the Tumbler T for a
VII. T UMBLE B IT S ECURITY correct solution ∗ to puzzle z ∗ . As such, Bob Bi will
be expected to provide Alice Aj with the appropriate
We discuss TumbleBit’s unlinkability and balance goods or services in exchange for the puzzle solution
properties. See Section III-C for DoS/Sybil resistance. ∗ . However, the puzzle solution ∗ will be of no value
to Bob Bi , i.e., Bob cannot use ∗ to claim a bitcoin
A. Balance during the Cash-Out Phase. It follows that the only party
harmed by this misbehavior is Bob Bi himself. As such,
The balance was defined, at high-level, in Sec-
we argue that such an attack is of no importance.
tion III-C. We analyze balance in several cases.
Case A∗j and T collude. Similarly, even if A∗j and T
Tumbler T ∗ is corrupt. We want to show that all the
collude, fairness for an honest Bi still follows from the
bitcoins paid to T by all Aj ’s can be later claimed
fairness of the puzzle-promise protocol. This is because
by the Bi ’s. (That is, a malicious T ∗ cannot refuse a
A∗j ’s interaction with Bi is restricted in receiving a
payment to Bob after being paid by Alice.) If Bi suc-
puzzle z, and handing back a solution. While A∗j can
cessfully completes the puzzle-promise protocol with
always give Bi an invalid solution ∗ , Bi can easily
T ∗ , fairness for this protocol guarantees that Bi gets
check that the solution is invalid (since (∗ )e 6= z
a correct “promise” c and puzzle z. Meanwhile, the
mod N ) and refuse to provide goods or services.
fairness of the puzzle-solver protocol guarantees that
each Aj gets a correct puzzle solution in exchange for Case A∗j , Bi∗ and T collude. Suppose A∗j , Bi∗ and T
her bitcoin. Thus, for any puzzle z solved, some Bi all collude to harm some other honest A and/or B. This
can open promise c and form the cash-out transaction can be reduced to one of the two cases above because
Tcash(T ,B) that allows Bi to claim one bitcoin. Moreover, an honest A will only interact with Bi∗ and T ∗ , while
transaction Tescr(A,T ) has timelock tw 1 and transaction an honest B will only interact with A∗j and T .
Tescr(T ,B) has timelock tw 2 . Since tw 1 < tw 2 , it
follows that either (1) T ∗ solves A’s puzzle or (2) B. Unlinkability
A reclaims the bitcoins in Tescr(A,T ) (timelock tw 1 ),
before T can (3) steal a bitcoin by reclaiming the Unlinkability is defined in Section III-C and must
bitcoins in Tescr(T ,B) (timelock tw 2 ). hold against a T that does not collude with other users.
We show that all interaction multi-graphs G compatible
Case A∗j and Bi∗ are corrupt. Consider colluding payers with T ’s view are equally likely.
Bi∗ and payees A∗j . We show that the sum of bitcoins
cashed out by all Bi∗ is no more than the number of First, note that all TumbleBit payments have the
puzzles solved by T in the Payment Phase with all A∗j . same denomination (1 bitcoin). Thus, T ∗ cannot learn
anything by correlating the values in the transactions.
First, the fairness of the puzzle-promise protocol Next, recall from Section III-A, that all users of Tum-
guarantees that any Bi∗ learns only (c, z) pairs; thus, bleBit coordinate on phases and epochs. Escrow trans-
by the unforgeability of ECDSA signatures and the actions are posted at the same time, during the Escrow
hardness of solving RSA puzzles, B ∗ cannot claim Phase only. All Tescr(T ,B) cash-out transactions are
any bitcoin at the end of the Escrow Phase. Next, the posted during the Cash-Out Phase only. All payments
fairness of the puzzle-solver protocol guarantees that made from Ai and Bj occur during the Payment Phase
if T completes SPj successful puzzle-solver protocol only, and payments involve no direct interaction be-
executions with A∗j , then A∗j gets the solution to exactly tween T and B. This rules out timing attacks where the
SPj puzzles. Payees Bi∗ use the solved puzzles to Tumbler purposely delays or speeds up its interaction
claim bitcoins from T . By the unforgeability of ECDSA with some payer Aj , with the goal of distinguishing
signatures (and assuming that the blockchain prevents some behavior at the intended payee Bi . Even if the

14
Tumbler T ∗ decides to cash-out with Aj before the Thus, suppose we eliminate ceiling attacks. Then,
Payment Phase completes (as is done in Section V-D the puzzle z provided by Bob cannot be linked to
when Aj misbehaves), all the Bi still cash out at the any payee Bitcoin address Addr B1 , ..., Addr Bι that has
same time, during the Cash-Out Phase. escrowed Bitcoins with the Tumbler, even if Alice and
the Tumbler collude.8 This property is useful when
Next, observe that transcripts of the puzzle- Alice is able to pay Bob without learning Bob’s true
promise and puzzle-solver protocols are information- identity, e.g., when Bob is a Tor hidden service.
theoretically unlinkable. This follows because the puz-
zle z used by any Aj in the puzzle-solver protocol is Bob/Tumbler collusion. Bob and the Tumbler can
equally likely to be the blinding of any of the puzzles z collude to learn the true identity of Alice. Importantly,
that appear in the puzzle-promise protocols played with this collusion attack is useful only if Bob can be paid by
any Bi (see Section III-A, equation (2)). Alice without learning her true identity (e.g., if Alice is
a Tor user). The attack is simple. Bob reveals the blinded
Finally, we assume secure channels, so that T ∗ puzzle value z to the Tumbler. Now, when Alice asks
cannot eavesdrop on communication between Aj ’s and that Tumbler to solve puzzle z, the Tumbler knows that
Bi ’s, and that T ∗ cannot use network information to this Alice is attempting to pay Bob. Specifically, the
correlate Aj ’s and Bi ’s (by e.g., observing that they Tumbler learns that Bob was paid by the Bitcoin address
share the same IP address). Then, the above two obser- Addr A that paid for the solution to puzzle z.
vations imply that all interaction multi-graphs, that are
compatible with the view of T ∗ , are equally likely. There is also a simple way to mitigate this attack.
Alice chooses a fresh random blinding factor r0 ∈ ZN ∗

and asks the Tumbler to solve the double-blinded puzzle

C. Limitations of Unlinkability z = (r0 )e · z mod N. (5)
TumbleBit’s unlinkability (see Section III-C) is in- Once the Tumbler solves the double-blinded puzzle z,
spired by Chaumian eCash [17], and thus suffers from Alice can unblind it by dividing by r0 and recovering
similar limitations. (Section VII-D discusses the lim- the solution to single-blinded puzzle z. This way, the
itations of Chaumian eCash [17] in more detail.) In Tumbler cannot link the double-blinded puzzle z from
what follows, we assume that Alice has a single Bitcoin Alice to the single-blinded puzzle z from Bob.
address Addr A , and Bob has Bitcoin address Addr B .
However, even with double blinding, there is still a
Alice/Tumbler collusion. Our unlinkability defini- timing channel. Suppose Bob colludes with the Tum-
tion assumes that the Tumbler does not collude with bler, and sends the blinded puzzle value z to both Alice
other TumbleBit users. However, collusion between the and the Tumbler at time t0 . The Tumbler can rule out
Tumbler and Alice can be used in a ceiling attack. the possibility that any payment made by any Alice
Suppose that some Bob has set up a TumbleBit payment prior to time t0 should be linked to this payment to
channel that allows him to accept up to Q TumbleBit Bob. Returning to the terminology of our unlinkability
payments, and suppose that Bob has already accepted Q definition (Section III-C), this means that Bob and the
payments at time t0 of the Payment Phase. Importantly, Tumbler can collude to use timing information to rule
the Tumbler, working alone, cannot learn that Bob is no out some compatible interaction graphs.
longer accepting payments after time t0 . (This follows
because the Tumbler and Bob do not interact during the Potato attack. Our definition of unlinkability does
Payment Phase.) However, the Tumbler can learn this by not consider external information. Suppose Bob sells
colluding with Alice: Alice offers to pay Bob at time t0 , potatoes that costs exactly 7 bitcoins, and the Tumbler
and finds that Bob cannot accept her payment (because knows that no other payee sells items that cost exactly 7
Bob has “hit the ceiling” for his payment channel). Now bitcoins. The Tumbler can use this external information
the Tumbler knows that Bob has obtained Q payments at rule out compatible interaction graphs. For instance,
time t0 , and he can rule out any compatible interaction if Alice made 6 TumbleBit payments, the Tumbler
graphs that link any payment made after time t0 to Bob. infers that Alice could not have bought Bob’s potatoes.
Similarly, if Alice made 7 TumbleBit payments in a
The ceiling attack assumes that Bob allows any short time, the Tumbler might infer that Alice was
Alice to pay him whenever she wants. However, we can buying Bob’s potatoes.
rule out ceiling attacks if every Bob always initiates 8 To see why, recall that the only interaction between Alice and Bob
every interaction with Alice. Alternatively, Bob’s can consists of Alice receiving the puzzle from Bob and then handing
ensure that his payment channel allows him to accept back its solution. Since we assumed that Alice always gets a puzzle
significantly more payments that was he expects to from Bob, the only information that Alice gets from Bob is a blinded
receive during an epoch. Another idea is to stagger puzzle z (which is information-theoretically unrelated to any puzzle
TumbleBit epochs, so that multiple epochs take place generated by Tumbler). But, z is the same puzzle that is used by Alice
in the interaction with Tumbler, and so the combined view of Tumbler
simultaneously. Then, if Bob’s escrow from one epoch and Alice is the same as the view of Tumbler alone. Therefore, the
runs out, he can start making payments to his escrow anonymity of Bob follows from the anonymity against a malicious
in the next epoch. Tumbler only.

15
 Potato attacks could be mitigated by aggregating attack follows. To launch a potato attack, the Bank
payments (e.g., buying additional goods at the same observes that Alice withdrew only 6 coins after opening
time as buying potatoes) or adding noise (i.e., by having her account with the Bank. However, a potato costs 7
Alice set up an a TumbleBit payee address, and paying coins, and so the Bank learns that Alice could not have
that address each time she buys potatoes). This problem bought a potato. Finally, the Chaumian bank can launch
seems similar to those tackled with differential-privacy. an abort attack identical to that of Section VII-C by
refusing to allow Alice to withdraw a coin.
Intersection attacks. Our definition of unlinkability
applies only to a single epoch. Thus, as mentioned in
Section IV-A and [13], [39], our definition does not rule VIII. I MPLEMENTATION
out the correlation of information across epochs.
To show that TumbleBit is performant and com-
Abort attacks. Our definition of unlinkability applies patible with Bitcoin, we implemented TumbleBit as a
to payments that complete during an epoch. It does not classic tumbler. (That is, each payer and payee can
account for information gained by strategically aborting send/receive Q = 1 payment/epoch.) We then used
payments. As an example, suppose that the Tumbler TumbleBit to mix bitcoins from 800 payers (Alice A)
notices that during several TumbleBit epochs, (1) Alice to 800 payees (Bob B). We describe how our imple-
always makes a single payment, and (2) Bob hits the mentation instantiates our TumbleBit protocols. We then
ceiling for his payment channel. Now in the next epoch, measure the off-blockchain performance, i.e., compute
the Tumbler aborts Alice’s payment and notices that time, running time, and bandwidth consumed. Finally,
Bob no longer hits his ceiling. The Tumbler might guess we describe two on-blockchain tests of TumbleBit.
that Alice was trying to pay Bob.
A. Protocol Instantiation
D. Limitations of Unlinkability for Chaumian eCash.
We instantiated our protocols with 2048-bit RSA.
Attacks analogous to those in Section VII-C are also The hash functions and signatures are instantiated as
possible for classic Chaumian eCash [17]. described in the captions to Figure 3 and Figure 4.9
Chaumian eCash. With Chaumian eCash, a payee Choosing m and n in the puzzle-solving protocol. Per
Alice interacts with the Bank to withdraws Q eCash Theorem 1, the probability that T can cheat is param-
coins. Each coin is an RSA blind signature σ (signed eterized by 1/ m+n where m is the number of “real”


m
by the Bank) on a blinded serial number sn (selected values and n is the number of “fake” values in Figure 3.
by Alice). The blindness of the blind signature ensures From a security perspective, we want m and n to be
that the Bank does not learn the serial number sn as large as possible, but in practice we are constrained
at the time the coin is withdrawn. To use the coin, by the Bitcoin protocol. Our main constraint is that m
Alice unblinds the serial number to sn and signature RIPEMD-160 hash outputs must be stored in Tpuzzle
to σ and sends them to Bob. Upon receipt of the coin of our puzzle-solver protocol. Bitcoin P2SH scripts
(sn, σ), Bob must immediately interact with the Bank (as described below) are limited in size to 520 bytes,
to deposit and confirm the coin’s validity. To validate which means m ≤ 21. Increasing m also increases the
the coin, the Bank simply checks that no coin deposited transaction fees. Fortunately, n is not constrained by the
earlier had the same serial number sn. Notice that the Bitcoin protocol; increasing n only means we perform
view of the Chaumian Bank includes (1) the time and more off-blockchain RSA exponentiations. Therefore,
value of each payment made to Bob, and (2) the time we chose m = 15 and n = 285 to bound T ’s
and value of each withdrawal made by Alice. This cheating probability to 2−80 . (2−80 equals RIPEMD-
is slightly different than the view of our TumbleBit 160’s collision probability.)
Tumbler, which sees (1) the time and value of each
payment made by Alice (rather than by Bob), and (2) Choosing µ and η in the puzzle-promise protocol.
value of the total number of payments received by Bob. Theorem
2 also allows T to cheat with probability
1/ µ+η
µ . However, this protocol has no Bitcoin-related
We now point out how the attacks in Section VII-C constraints on µ and η. Thus, we take µ = η = 42 to
can be launched on Chaumian eCash. Analogous to the achieve a security level of 2−80 while minimizing the
first attack in Section VII-C, Alice and the Bank can number of off-blockchain RSA computations performed
collude to unmask Bob, as follows: Alice simply reveals in Figure 4 (which is µ + η).
the serial number sn to the Bank, and the Bank links
sn to the deposit made by Bob. The Chaumian Bank 9 There were slight difference between our protocols as described
can also collude with Bob to perform a ceiling attack, in this paper and the implementation used in some of the tests. In
as follows: Suppose that Bob offers to sell Alice an Figure 3, A reveals blinds rj ∀j ∈ R to T , our implementation instead
item worth 1 coin at time t0 , but Alice has no unspent reveals an encrypted version rje ∀j ∈ R. This change does not affect
performance, since A hold both rj and rje . Also, our implementation
coins. If Alice either (1) refuses to buy the item, or (2) omits the index hashes hR and hF from Figure 4; these are two 256-
withdraws an additional coin, then the Bank learns that bit hash outputs and thus should not significantly affect performance.
Alice has no unspent coins at time t0 and the ceiling We have since removed these differences.

16
 TABLE III. AVERAGE OFF - BLOCKCHAIN RUNNING TIMES OF
T UMBLE B IT ’ S PHASES , IN SECONDS . (100 TRIALS ) time dominated by network latency. Indeed, even when
Compute Running Time Running Time A and T are very far apart, our 2048-bit RSA puzzle
Time (Boston-New York-Toronto) (Boston-Frankfurt-Tokyo) solving protocol is still faster than [37]’s 16x16 Sudoku
Escrow 0.2052 0.3303 1.5503 puzzle solving protocol, which takes 20 seconds.
Payment 0.3878 1.1352 4.3455
Cash-Out 0.0046 0.0069 0.0068 TumbleBit as a classic tumbler (Table II). Next,
TABLE IV. T RANSACTION SIZES AND FEES IN OUR TESTS .
we consider classic Tumbler mode (Section IV). We
Transaction Size Satoshi/byte Fee (in BTC) consider a scenario where A and B use the same
Tescr 190B 30 0.000057 machine, because Alice A wants anonymize her bitcoin
Tcash 447B 30 0.000134 by transferring it to a fresh ephemeral bitcoin address
Trefund for Tescr 373B 30 0.000111
Tpuzzle 447B 15 0.000067 that she controls. Thus, we run (1) A and B in Boston
Tsolve 907B 15 0.000136 and T in Tokyo, and (2) A and B in Boston and T
Trefund for Tpuzzle 651B 20 0.000130
in New York. To prevent the Tumbler T for linking
A and B via their IP address, we also tested with
Scripts. By default, Bitcoin clients and miners only
(a) B connecting to T over Tor, and (b) both A and
operate on transactions that fall into one of the five
B connected through Tor. Per Table II, running time
standard Bitcoin transaction templates. We therefore
is bound by network latency, but is < 11 seconds
conform to the Pay-To-Script-Hash (P2SH) [3] tem-
even with when both parties connect to Tokyo over
plate. To format transaction Toffer (per Section II) as
Tor. Connecting to New York (in clear) results in ≈ 1
a P2SH, we specify a redeem script (written in Script)
second running time. Compute time is only 0.6 seconds,
whose condition C must be met to fulfill the transaction.
again measured by running A, B and T on the Boston
This redeem script is hashed and stored in transaction
machine. Thus, TumbleBit’s performance, as a classic
Toffer . To transfer funds out of Toffer , a transaction Tfulfill
Tumbler, is bound by the time it takes to confirm 2
is constructed. Tfulfill includes (1) the redeem script and
blocks on the blockchain (≈ 20 minutes).
(2) a set of input values that the redeem script is run
against. To programmatically validate that Tfulfill can Performance of TumbleBit’s Phases. (Table III) Next,
fulfill Toffer , the redeem script Tfulfill is hashed, and we break out the performance of each of TumbleBit’s
the resulting hash value is compared to the hash value phases when Q = 1. We start by measuring compute
stored in Toffer . If these match, the redeem script is run time by running all A, B and T on the Boston machine.
against the input values in Tfulfill . Tfulfill fulfills Toffer if Then, we locate each party on different machines. We
the redeem script outputs true. All our redeem scripts first set A in Toronto, B in Boston and T in New York
include a time-locked refund condition, that allows the and get RTTs to be 22 ms from Boston to New York, 23
party offering Toffer to reclaim the funds after a time ms from New York to Toronto, and 55 ms from Toronto
window expires. To do so, the party signs and posts to Boston. Then we set A in Frankfurt, B in Boston and
a refund transaction Trefund that points to Toffer and T in Tokyo and get RTTs to be 106 ms from Boston
reclaims the funds locked in Toffer . We reproduce our to Frankfurt, 240 ms from Frankfurt to Tokyo, and 197
scripts in Appendix I and Figure 9. ms from Tokyo to Boston. An off-blockchain payment
in the Payment Phase completes in under 5 seconds and
B. Off-Blockchain Performance Evaluation most of the running time is due to network latency.
We evaluate the performance for a run of our pro-
tocols between one payer Alice A, one payee Bob B C. Blockchain Tests
and the Tumbler T . We used several machines: an EC2 Our on-blockchain tests use TumbleBit as a classic
t2.medium instance in Tokyo (2 Cores at 2.50 GHz, tumbler, where payers pay themselves into a fresh
4 GB of RAM), a MacBook Pro in Boston (2.8 GHz ephemeral Bitcoin address. All transactions are visible
processor, 16 GB RAM), and Digital Ocean nodes in on the blockchain. Transaction IDs (TXIDs) are hyper-
New York, Toronto and Frankfurt (1 Core at 2.40 GHz linked below. The denomination of each TumbleBit pay-
and 512 MB RAM). ment (i.e., the price of puzzle solution) was 0.0000769
Puzzle-solver protocol (Table II). The total network BTC (roughly $0.04 USD on 8/15/2016). Table IV
bandwidth consumed by our protocol was 269 Kb, details the size and fees10 used for each transaction.
which is roughly 1/8th the size of the “average web- Test where everyone behaves. In our first test, all
page” per [54] (2212 Kb). Next, we test the total (off- parties completed the protocol without aborting. We
blockchain) computation time for our puzzle-solver pro- tumbled 800 payments between ℵ = 800 payers and
tocol (Section V-B) by running both parties (A and T ) ℵ = 800 payees, resulting in 3200 transactions posted
on the Boston machine. We test the impact of network
10 We use a lower transaction fee rate of 15 Satoshi/byte (see
latency by running A in Boston and T in Tokyo, and
then with T in New York. (The average Boston-to- Table IV) for Tpuzzle and Tsolve because we are in less of hurry to
have them confirmed. Specifically, if A refuses to sign Tcash(A,T ) ,
Tokyo Round Trip Times (RTT) was 187 ms and the then T ends the Payment Phase with A early (even before the Cash-
Boston-to-New York RTT was 9 ms.) From Table II, we Out Phase begins), and immediately posts Tpuzzle and then Tsolve to
see the protocol completes in < 4 seconds, with running the blockchain. See Section V-D.

17
 TABLE II. AVERAGE PERFORMANCE OF RSA- PUZZLE - SOLVER AND CLASSIC TUMBLER , IN SECONDS . (100 TRIALS ).
Compute Running Time RTT Running Time RTT
Bandwidth
Time (Boston-New York) (Boston-New York) (Boston-Tokyo) (Boston-Tokyo)
RSA-puzzle-solving protocol 0.398 0.846 0.007949 4.18 0.186 269 KB
Classic Tumbler (in clear) 0.614 1.190 0.008036 5.99 0.187 326 KB
Classic Tumbler (B over Tor) 0.614 3.10 0.0875 8.37 0.273 342 KB
Classic Tumbler (Both over Tor) 0.614 6.84 0.0875 10.8 0.273 384 KB

Block Height
to the blockchain and a k-anonymity of k = 800.The 425500 { Escrow Phase
puzzle-promise escrow transactions Tescr(T ,B) are all 425502 Tescr(𝓐, 𝓣) & Tescr(𝓣, 𝓑)
funded from this TXID and the puzzler-solver escrow
transactions Tescr(A,T ) are all funded from this TXID. 425505 { Case 2 & 3: Tpuzzle
This test completed in 23 blocks in total, with Escrow Case 3: Tsolve
425507
Phase completing in 16 blocks, Payment Phase taking
1 block, and Cash-Out Phase completing in 6 blocks. 425509 { Case 1: Tescr(𝓐, 𝓣) Refund
Case 2: Tpuzzle Refund
We note, however, that our protocol could also have 425511
completed much faster, e.g., with 1 block for the Escrow
Phase, and 1 block for the Cash Out Phase. A Bitcoin 425514 { Case 1 & 2: Tescr(𝓣, 𝓑) Refund
425527
block can typically hold ≈ 5260 of our 2-of-2 escrow
transactions Tescr and ≈ 2440 of our cash-out transac-
tion Tcash . We could increase transaction fees to make Fig. 5. Timeline of test with uncooperative behavior, showing block
sure that our Escrow Phase and Cash-Out phase (each height when each transaction was confirmed.
confirming 2×800 transactions) occur within one block.
In our tests, we used fairly conservative transaction via a refund transaction after the timelock expires.
fees (Table IV). While the exact fees needed vary from Tescr(A,T ) was timelocked for 10 blocks, and the refund
minute to minute, doubling our fees to 60 Satoshi per transaction was confirmed 8 blocks after Tescr(A,T ) was
Byte should be sufficient under standard transaction confirmed. The Tumbler T reclaims its bitcoins from
volume.11 As a classic Tumbler, we therefore expect his payment channel with Bob B1 escrow transaction
TumbleBit to have a higher denomination than the Tescr(T ,B) via a refund transaction after the timelock
0.0000769 BTC we used for our test. For instance, expires. Tescr(T ,B) was timelocked for 15 blocks, and
transaction fees of 60 Satoshi per Byte (0.0007644 the refund transaction was confirmed 25 blocks after
BTC/user) are ≈ 1/1000 of a denomination of 0.5 BTC. Tescr(T ,B) was confirmed.
Test with uncooperative behavior. Our second run of Case 2: The Tumbler aborts the puzzle-solver protocol
only 10 users (5 payers and 5 payees) demonstrates by posting the transaction Tpuzzle but refusing to provide
how fair exchange is enforced in the face of uncooper- the transaction Tsolve . (Per Section V-D, to meet the
ative or malicious parties. Transactions Tescr(A,T ) and condition in Tpuzzle and claim its bitcoins, the Tumbler
Tpuzzle were timelocked for 10 blocks and Tescr(T ,B) T has to post Tsolve that reveal a set of preimages.
was timelocked for 15 blocks. All escrow transactions Because the Tumbler refuses to post Tsolve , thus refusing
Tescr(A,T ) are funded by TXID and all escrow trans- to solve Alice’s puzzle, Alice’s bitcoins are locked in
actions Tescr(T ,B) are funded by TXID. Two payer- Tpuzzle until its timelock expires.) No payment com-
payee pairs completed the protocol successfully. For the pletes from A2 to B2 . Instead, A2 reclaims her bitcoin
remaining three pairs, some party aborted the protocol: from Tpuzzle via a refund transaction after the timelock
Case 1: The Tumbler T (or, equivalently, Alice A1 ) in Tpuzzle expires. The refund transaction was confirmed
refused to cooperate after the Escrow Phase. Alice A1 4 blocks after Tpuzzle was confirmed. Tumbler reclaims
reclaims her bitcoins from escrow transaction Tescr(A,T ) its bitcoins from its payment channel with Bob B2 via
a refund transaction after the timelock on the escrow
10 This test, all escrow transactions T transaction Tescr(T ,B) expires. The refund transaction
escr(A,T ) and Tcash(T ,B) had
the same timelock tw 2 and Tpuzzle had a timelock of tw1 , where was confirmed 25 blocks after Tescr(T ,B) was confirmed.
tw 1 < tw 2 . Also, we also modify the protocol description in in Step
(2) of Section V-D to have both A and T sign Tpuzzle during the Case 3: The Tumbler provides Alice A3 the solution
Payment Phase without posting it to the blockchain. (We can do this to her puzzle in the puzzle-solver protocol, and the
because Alice is only making a single payment in this epoch (i.e., Tumbler has an Tpuzzle signed by A (Section V-D).
Q = 1).) Then, if a malicious Tumbler tried to from steal bitcoins
(per the ‘Tumbler is corrupt’ case of Section VII-A), A could protect
However, Alice refuses to sign the cash-out transaction
herself by posting Tpuzzle to the blockchain, and reclaim the bitcoins Tcash(A,T ) to pay out from her escrow with the Tumbler.
locked in Tpuzzle after its timelock tw 1 expires, but prior to tw 2. Then, the Tumbler signs and posts the transaction Tpuzzle
11 For instance, in a 24 hour window starting on Aug 12 2016, all
and its fulfilling transaction Tsolve and claims its bitcoin.
188K transactions with a fee ≥ 41 Satoshi/Byte were confirmed in Payment from A3 to B3 completes but the Tumbler has
the next block. A precise model of current Bitcoin miner behavior,
under different fees rates and transaction volumes, remains an open to pay more in transaction fees. This is because the
research question. [42] analyzes transaction priority and fee rates but Tumbler has to post both transactions Tpuzzle and Tsolve ,
uses older data which no longer reflects current trends. rather than just Tcash(A,T ) ; see Table IV.

18
Remark: Anonymity when parties are uncooperative. [15] Joseph Bonneau, Arvind Narayanan, Andrew Miller, Jeremy
Notice that in Case 1 and Case 2, the protocol aborted Clark, JoshuaA. Kroll, and EdwardW. Felten. Mixcoin:
without completing payment from Alice to Bob. k- Anonymity for bitcoin with accountable mixes. In Financial
Cryptography and Data Security, 2014.
anonymity for this TumbleBit run was therefore k = 3.
[16] Ran Canetti. Universally composable signature, certification,
By aborting, the Tumbler T learns that payers A1 , A2 and authentication. In Proceedings. 17th IEEE Computer
were trying to pay payees B1 , B2 . However, anonymity Security Foundations Workshop, 2004., pages 219–233. IEEE,
of A1 , A2 , B1 , B2 remains unharmed, since B1 and 2004.
B2 were using ephemeral Bitcoin addresses they now [17] David Chaum. Blind signature system. In CRYPTO, 1983.
discard to safeguard their anonymity (see Section IV-A). [18] Christian Decker and Roger Wattenhofer. A fast and scalable
payment network with bitcoin duplex micropayment channels.
ACKNOWLEDGEMENTS In Stabilization, Safety, and Security of Distributed Systems,
pages 3–18. Springer, 2015.
We thank Ethan Donowitz for assistance with the [19] Antoine Delignat-Lavaud, Cedric Fournet, Markulf Kohlweiss,
preliminary stages of this project, and Nicolas Dorier, and Bryan Parno. Cinderella: Turning Shabby X. 509 Cer-
Adam Ficsor, Gregory Galperin, Omer Paneth, Dimitris tificates into Elegant Anonymous Credentials with the Magic
Papadopoulos, Leonid Reyzin, Omar Sagga, Ann Ming of Verifiable Computation. IEEE Symposium on Security and
Privacy 2016, 2016.
Samborski, Sophia Yakoubov, the anonymous reviewers
[20] Corin Faife. Will 2017 bring an end to bitcoin’s
and many members of the Bitcoin community for useful great scaling debate? http://www.coindesk.com/
discussions and suggestions. This work was supported 2016-bitcoin-protocol-block-size-debate/, January 5 2017.
by NSF grants 1012910, 1414119, and 1350733. [21] Srivatsava Ranjit Ganta, Shiva Prasad Kasiviswanathan, and
Adam Smith. Composition attacks and auxiliary information
R EFERENCES in data privacy. In ACM SIGKDD, pages 265–273, 2008.
[1] Bitcoin Fog. Wikipedia, 2016. [22] O. Goldreich, S. Micali, and A. Wigderson. How to play any
mental game. In STOC. ACM, 1987.
[2] Monero, https://getmonero.org/home. 2016.
[23] Grams. Helixlight: Helix made simple. https:
[3] Gavin Andresen. BIP-0016: Pay to Script Hash. Bitcoin //grams7enufi7jmdl.onion.to/helix/light.
Improvement Proposals, 2014.
[24] Matthew Green and Ian Miers. Bolt: Anonymous Payment
[4] Marcin Andrychowicz, Stefan Dziembowski, Daniel Mali- Channels for Decentralized Currencies. Cryptology ePrint
nowski, and Lukasz Mazurek. Secure multiparty computations Archive 2016/701, 2016.
on bitcoin. In IEEE S&P, pages 443–458, 2014.
[25] Ethan Heilman, Foteini Baldimtsi, and Sharon Goldberg.
[5] Marcin Andrychowicz, Stefan Dziembowski, Daniel Mali-
Blindly Signed Contracts: Anonymous On-Blockchain and Off-
nowski, and Łukasz Mazurek. On the malleability of bitcoin
Blockchain Bitcoin Transactions. In Workshop on Bitcoin and
transactions. In International Conference on Financial Cryp-
Blockchain Research at Financial Crypto, February 2016.
tography and Data Security, pages 1–18. Springer, 2015.
[26] Chainalysis Inc. Chainalysis: Blockchain analysis, 2016. https:
[6] A Back, G Maxwell, M Corallo, M Friedenbach, and L Dashjr.
//www.chainalysis.com/.
Enabling blockchain innovations with pegged sidechains.
Blockstream, https:// blockstream.com/ sidechains.pdf , 2014. [27] Marek Jawurek, Florian Kerschbaum, and Claudio Orlandi.
Zero-knowledge using garbled circuits: how to prove non-
[7] Wacław Banasik, Stefan Dziembowski, and Daniel Malinowski.
algebraic statements efficiently. In ACM-CCS, 2013.
Efficient Zero-Knowledge Contingent Payments in Cryptocur-
rencies Without Scripts. Cryptology ePrint Archive, Report [28] Tom Elvis Jedusor. Mimblewimble. 2016.
2016/451, 2016. [29] Benjamin Kreuter, Abhi Shelat, Benjamin Mood, and Kevin RB
[8] Simon Barber, Xavier Boyen, Elaine Shi, and Ersin Uzun. Butler. Pcf: A portable circuit format for scalable two-party
Bitter to Better - How to Make Bitcoin a Better Currency. In secure computation. In USENIX Security, 2013.
Financial Cryptography and Data Security. Springer, 2012. [30] Ranjit Kumaresan and Iddo Bentov. How to use bitcoin to
[9] Mihir Bellare and Phillip Rogaway. Random oracles are incentivize correct computations. In ACM-CCS, 2014.
practical: A paradigm for designing efficient protocols. In [31] Ranjit Kumaresan, Tal Moran, and Iddo Bentov. How to use
ACM-CCS, pages 62–73, 1993. bitcoin to play decentralized poker. In ACM-CCS, 2015.
[10] Eli Ben Sasson, Alessandro Chiesa, Christina Garman, [32] Elliptic Enterprises Limited. Elliptic: The global standard for
Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. blockchain intelligence, 2016. https://www.elliptic.co/.
Zerocash: Decentralized anonymous payments from Bitcoin.
[33] Yehuda Lindell. Fast cut-and-choose-based protocols for mali-
In IEEE Security and Privacy (SP), pages 459–474, 2014.
cious and covert adversaries. Journal of Cryptology, 29(2):456–
[11] Eli Ben-Sasson, Alessandro Chiesa, Daniel Genkin, Eran 490, 2016.
Tromer, and Madars Virza. Snarks for C: verifying program
executions succinctly and in zero knowledge. In CRYPTO, [34] Gregory Maxwell. Zero Knowledge Contingent Payment.
pages 90–108, 2013. Bitcoin Wiki, 2011.
[12] Alex Biryukov, Dmitry Khovratovich, and Ivan Pustogarov. [35] Gregory Maxwell. CoinJoin: Bitcoin privacy for the real world.
Deanonymisation of Clients in Bitcoin P2P Network. In ACM- Bitcoin-talk, 2013.
CCS, pages 15–29, 2014. [36] Gregory Maxwell. CoinSwap: transaction graph disjoint trust-
[13] George Bissias, A Pinar Ozisik, Brian N Levine, and Marc less trading. Bitcoin-talk, 2013.
Liberatore. Sybil-resistant mixing for bitcoin. In Workshop on [37] Gregory Maxwell. The first successful Zero-Knowledge Con-
Privacy in the Electronic Society, pages 149–158, 2014. tingent Payment. Bitcoin Core, February 2016.
[14] Joseph Bonneau, Andrew Miller, Jeremy Clark, Arvind [38] S Meiklejohn, M Pomarole, G Jordan, K Levchenko,
Narayanan, Joshua A Kroll, and Edward W Felten. SoK: GM Voelker, S Savage, and D McCoy. A fistful of bitcoins:
Research Perspectives and Challenges for Bitcoin and Cryp- Characterizing payments among men with no names. In ACM-
tocurrencies. In IEEE - SP, 2015. SIGCOMM Internet Measurement Conference, IMC, 2013.

19
[39] Sarah Meiklejohn and Claudio Orlandi. Privacy-Enhancing a single payment of denomination 1 bitcoin (Figure 4)
Overlays in Bitcoin. In Lecture Notes in Computer Science, to allowing Q payments of denomination 1 bitcoin. The
volume 8976. Springer Berlin Heidelberg, 2015. extended protocol is in Figure 6. The extended protocol
[40] Ian Miers, Christina Garman, Matthew Green, and Aviel D combines some new cryptographic techniques with the
Rubin. Zerocoin: Anonymous distributed e-cash from bitcoin.
In IEEE Security and Privacy (SP), pages 397–411, 2013. ideas we used in Section III-B (to extend the A-to-T
[41] Pedro Moreno-Sanchez, Tim Ruffing, and Aniket Kate. P2P
puzzle-solver protocol to handle Q payments.
Mixing and Unlinkable P2P Transactions. Draft, June 2016. The extended puzzle-promise protocol produces Q
[42] Malte Möser and Rainer Böhme. Trends, tips, tolls: A longi- puzzles z1 , ..., zQ for Bob B, where the solution to the
tudinal study of Bitcoin transaction fees. In FC, 2015.
j th puzzle allows Bob to “open” a promise cj . The
[43] Malte Möser and Rainer Böhme. Join Me on a Market for
Anonymity. Workshop on Privacy in the Electronic Society,
promise cj contains the Tumbler’s ECDSA signature
2016. on cash-out transaction Tcash(T ,B) (j) that allocates j
[44] Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew bitcoins to Bob and Q − j bitcoins for the Tumbler.
Miller, and Steven Goldfeder. Bitcoin and cryptocurrency Each transaction Tcash(T ,B) (j) for j = 1, ..., Q points to
technologies. Princeton University Pres, 2016. the same 2-of-2 escrow transaction Tescr(T ,B) where the
[45] Guevara Noubir and Amirali Sanatinia. Honey onions: Expos- Tumbler escrowed Q bitcoins during the Escrow Phase.
ing snooping tor hsdir relays. In DEF CON 24, 2016. During the Payment Phase, Bob B asks the j th payer to
[46] Henning Pagnia and Felix C. Grtner. On the impossibility of solve puzzle zj ; this puzzle solution “opens” promise
fair exchange without a trusted third party, 1999. cj and provides Bob with the Tumbler’s signature on
[47] Morgen Peck. DAO May Be Dead After $60 Million Theft. transaction Tcash(T ,B) (j). As in Section III-B, Bob does
IEEE Spectrum, Tech Talk Blog, 17 June 2016.
not sign this transaction Tcash(T ,B) (j) and also does not
[48] Joseph Poon and Thaddeus Dryja. The bitcoin lightning post it to the blockchain during the Payment Phase.
network: Scalable off-chain instant payments. Technical report,
Technical Report (draft). https://lightning. network, 2015. Instead, Bob waits until the Escrow Phase starts, and
[49] Guillaume Poupard and Jacques Stern. Short proofs of then signs and posts the single cash-out transaction
knowledge for factoring. In Public Key Cryptography allowing him to claim the maximum number of bitcoins,
(PKC), Third International Workshop on Practice and The- i.e., the Tcash(T ,B) (j) for the last payment Bob received
ory in Public Key Cryptography, PKC 2000, Melbourne, during the Payment Phase.
Victoria, Australia, January 18-20, 2000, Proceedings, pages
147–166, 2000. https://link.springer.com/chapter/10.1007% How do we ensure that Bob B can open the promise
2F978-3-540-46588-1 11?LI=true. cj (and thus obtain Tcash(T ,B) (j)) only after he has
[50] Certicom Research. Sec 2: Recommended elliptic curve domain opened all prior promises cj−1 , ..., c1 ? (This is crucial,
parameters, 2010.
because otherwise a cheating Bob claim Q bitcoins from
[51] Dorit Ron and Adi Shamir. Quantitative analysis of the full his very first payment, by asking his first payee for the
bitcoin transaction graph. In Financial Cryptography and Data
Security, pages 6–24. Springer, 2013. solution to puzzle zQ . )
[52] Tim Ruffing, Pedro Moreno-Sanchez, and Aniket Kate. Coin- We solve this problem by requiring that the solutions
shuffle: Practical decentralized coin mixing for bitcoin. In to all of the puzzle z1 , ..., zj be used to open the j th
ESORICS, pages 345–364. Springer, 2014.
promise cj . To do this, we repeat the steps of the puzzle-
[53] Jeff Stone. Evolution Downfall: Insider ’Exit Scam’ Blamed
For Massive Drug Bazaar’s Sudden Disappearance. interna-
promise protocol Q times in parallel. We refer to the
tional business times, 2015. Q parallel executions as Q levels. In the j-th level,
[54] the Internet Archive. Http Archive: Trends, 2015. http: B prepares η + µ transactions Tcash(T ,B) (j), each of
//httparchive.org/trends.php. which transfers j bitcoins to B. Let zj,` denote a puzzle
[55] Peter Todd. BIP-0065: OP CHECKLOCKTIMEVERIFY. Bit- and its solution j,` at level j, and let ` ∈ [η + µ]
coin Improvement Proposal, 2014. denote the index for the cut-and-choose as in the base
[56] F. Tschorsch and B. Scheuermann. Bitcoin and Beyond: A puzzle-promise protocol in Section VI-A. The promise
Technical Survey on Decentralized Digital Currencies. IEEE is encrypted under the j puzzle solutions 1,` ...j,` as:
Communications Surveys Tutorials, PP(99), 2016.
[57] Luke Valenta and Brendan Rowan. Blindcoin: Blinded, ac- cj,` = H(j|j,` ||j−1,` || . . . , 1,` ) ⊕ σj,`
countable mixes for bitcoin. In FC, 2015.
where σj,` is the Tumbler’s signature on the cash-out
[58] Pieter Wuille. Segregated witness and its impact on scalabil-
ity https://www.youtube.com/watch?v=NOYNZB5BCHM, De- transaction Tcash(T ,B) (j) that allocates j bitcoins to
cember 14 2015. Bob.
[59] Jan Henrik Ziegeldorf, Fred Grossmann, Martin Henze, Nicolas Now that we have Q levels, we need to extend the
Inden, and Klaus Wehrle. Coinparty: Secure multi-party mixing
of bitcoins. In CODASPY, 2015. cut-and-choose to check the behavior of Tumbler across
all Q levels. Recall that for the base case of 1 bitcoin,
B prepares η + µ transactions (η of which are fake) of
A PPENDIX 1 bitcoin each, each of which will be evaluated by T
A. Puzzle-Promise Protocol: Extending to Q payments. to obtain a η + µ puzzle-promise pairs. (See Step 5 in
Figure 4.) We can visualize this as a 1 × (η + µ) vector,
We now extend the puzzle-promise protocol between among which B will check the column positions ` ∈ F
Bob B and Tumbler T from its “base case” of allowing that correspond to fake values (Step 8 in Figure 4). Now,

20
 Public input:(e, N, PK ephT , π).
Tumbler T chooses fresh ephemeral ECDSA-Secp256k1 key, i.e., bitcoin address (SK eph T , PK eph
T ).
π proves validity of (e, N ) in a one-time-only setup phase.
Payee Bob B(Q) Voucher Promise Protocol Tumbler T (Q, d, (e, N ))

1. Set up Tescr(T ,B)

Sign but do not post transaction Tescr(T ,B) timelocked for tw2
offering Q bitcoins under the condition: “the fulfilling transaction
must be signed under key PK ephT and under PK B .”
Tescr(T ,B)
2. Prepare Real Unsigned Tcash(T ,B) . ←−−−−−−−
For j ∈ [Q] and i ∈ 1, . . . , µ:
Choose random pad ρj,i ← {0, 1}λ
Set Tcash(T ,B) j,i = CashOutFormat(j, ρj,i )
htj,i = H 0 (Tcash(T ,B) j,i ).

3. Prepare Fake Set.

For j ∈ [Q] and i ∈ 1, . . . , η:
Choose random pad rj,i ← {0, 1}λ
f tj,i = H 0 (FakeFormat||rj,i ).

4. Mix Sets.
Let R be µ random indices in [µ + η].
Let F be remaining indices F = [µ + η]\R.
Let ireal = 1 and ifake = 1.
For j ∈ [Q] and i = 1, . . . , µ + η:
If i ∈ R: Let βj,i = htj,ireal and ireal = ireal + 1.
If i ∈ F : Let βj,i = f tj,ifake and ifake = ifake + 1.
β1,1 ...β1,µ+η
−−−−−−−−−−→
.
.
.
βQ,1 ...βQ,µ+η
−−−−−−−−−−−→
λ
Choose salt ∈ {0, 1}
Compute: hR = H(salt||R), hF = H(salt||F ) 5. Evaluation.
h ,h
−−R F
−−−→ For j ∈ [Q]:
For i ∈ [µ + η]:
ECDSA sign βj,i to get σj,i = Sig(SK eph T , βj,i )
Randomly choose j,i ∈ ZN .
Compute puzzle zj,i =fRSA (j+1,i , e, N )
Compute cj,i = H shk (j|i|j,i ||j−1,i || . . . , 1,i ) ⊕ σj,i .
{(zj,i ,cj,i )} ∀i∈[µ+η] ∀j∈[Q]
←−−−−−−−−−−−−−−−−−−−−−
R,F,salt
6. Reveal Real and Fake Set. −−−−−→
{rj,i ,ρj,l }i∈R,l∈F,j∈[Q]
−−−−−−−−−−−−−−−−−−→ 7. Check Real and Fake Set.
Check hR = H(salt||R) and hF = H(salt||F )
For all j ∈ [Q]:
For all ` ∈ F : Verify βj,` = H 0 (FakeFormat||rj,` ).
For all i ∈ R, Verify βj,i = H 0 (CashOutFormat(j, ρj,i )).
j,` ,∀`∈F,j∈[Q]
8. Check Fake Set. ←−−−−−−−−−−− Abort if any check fails
If all j,` < N , For j ∈ [Q]; for ` ∈ F :
Validate puzzle zj,` = (j,` )e mod N
Validate promise cj,` :
(a) Decrypt σj,` = cj,` ⊕ H shk (j|i|j,` ||j−1,` || . . . , 1,` )
(b) Verify ECDSA-Ver(PK eph T , H 0 (f tj,` ), σj,` ) = 1
Abort if any check fails. 9. Prepare quotients.
For j ∈ [Q] and for R = {`1 , ..., `µ }:
q1,2 ,...,q1,µ j,` j,`
µ
←−−−−−−−−
− Set qj,2 = j,`
2 , ..., qj,µ = j,`
1 µ−1
.
.
.
qQ,2 ,...,qQ,µ
←
−−−−−−−−−
−
10. Quotient Test.
Let R = {`1 , ..., `µ } .
For each j ∈ [Q] check equalities:
zj,`2 = zj,`1 · (qj,2 )e mod N
...
zj,`µ = zj,`µ−1 · (qj,µ )e mod N
Abort if any check fails. 11. Post transaction Tescr(T ,B) on blockchain
12. Begin Payment Phase.
For j ∈ [Q]: The j th puzzle is zj = zj,`1 .
Choose random rj ∈ ZN and send z̄j = zj · (rj )e to Payer A

Fig. 6. Puzzle promise protocol that allows Bob B to obtain up to Q payments. (d, (e, N )) are the RSA keys for the tumbler T . (Sig,
ECDSA-Ver) is an ECDSA-Secp256k1 signature scheme. We model H, H 0 and H shk as random oracles. In our implementation, H is HMAC-
SHA256 (keyed with salt), H 0 is ‘Hash256’, i.e., SHA-256 cascaded with itself, which is the hash function used in Bitcoin’s “hash-and-sign”
paradigm with ECDSA-Secp256k1. CashOutFormat is shorthand for the unsigned portion of a transaction that fulfills Tescr(T ,B) and transfers
21 the output of CashOutFormat contains sufficent entropy. FakeFormat
j bitcoins to B and Q − j bitcoins to T . The protocol uses ρi to ensure
is a distinguishable string known to all parties.
for the case of Q bitcoins, instead of having a 1×(η+µ) (Section V-B). We capture the functionality and security
vector, we have a matrix of Q×(η+µ) elements (Step 5 requirements of this interaction in the ideal functionality
in Figure 4). B still checks the same column positions Ffair-RSA described in Section C.
i ∈ F , but instead of checking a single puzzle-promise
pair (c` , z` ), B will check a column of Q puzzle-promise We follow the standard ideal/real world paradigm.
pairs [(c1,` , z1,` ), . . . , (cQ,` , zQ,` )] (Step 8 in Figure 6). To prove that a protocol π securely realizes an ideal
functionality F, one must show that the view obtained
Finally, recall that in the base case, B additionally by a real world adversary Adv, corrupting either one of
checks that the full level of puzzles zl1 , . . . , zlµ is the parties, and running protocol π, can be simulated
consistent with the quotients q1 , . . . , qµ (Step 10 in by a PPT simulator S that only has access to the
Figure 4). Similarly, in the case of Q bitcoins, B will interface of F. Let us denote by viewπ,Advreal the view
obtain one set of quotient chain for each of the Q levels. that the adversary Adv, corrupting party Pi and playing
Bob checks each level individually (Step 10 in Figure 6) protocol π, with party Pj , playing with input xj . Let us
to ensure that by solving puzzle zj for level j, Bob can denote by viewF ,Adv
ideal the view generated by simulator
also solve all puzzles zj,l1 , . . . , zj,lµ for level j. S, interacting with F and having black-box access to
Security. The prove security for this protocol, we extend Adv. Security is defined as follows.
the definition of the ideal functionality Fpromise-sign in Definition 1 (Secure realization of F.): A two-
Section D to the case of Q payments. At high level, this party protocol π securely realizes F if, for every PPT
extended definition has the following additional goal: static and malicious adversary Adv corrupting either
to make sure that Bob B cannot cheat by claiming party P1 or party P2 , there exists a PPT Simulator
more than j bitcoins using his j th puzzle solution. S such that the view viewπ,Adv and viewF ,Adv
real ideal are
That is, a real puzzle-promise pair (cj,` , zj,` ) for level j computationally indistinguishable.
must contain a signature on a cash-out transaction that
transfers exactly j bitcoins to Bob, and no more. Our The Random Oracle Model [9]. Our security proofs are
extended ideal functionality Fpromise-sign enforces this as in the Random Oracle (RO) model [9]; hash functions
follows: When Bob B submits a request to receive the are modeled as perfectly random functions, and in the
promise of a signature on a real message, then the ideal security proof the simulator can program their answers.
functionality Fpromise-sign checks that the real messages
confirms to a correct format—namely, that for the j th C. Ideal functionality Ffair-RSA
level it confirms to the format CashOutFormat which
transfers exactly j bitcoins to Bob—before sending it The puzzle-solver protocol allows Alice A to obtain
off to T . Thus, the security of our protocol follows from the solution to a single RSA-puzzle y (chosen by A),
the theorem below, which is proved in Appendix G: from the Tumbler T (who posses the RSA secret key
d ), in exchange for a bitcoin. Fair exchange for this
Theorem 3: Let λ be the security parameter. If protocol entails the following: (1) Fairness for T : After
RSA trapdoor function is hard in Z∗N , if H, H 0 , H shk one execution of the protocol A will learn the correct
are independent random oracles, if ECDSA is strong solution y d mod N to at most one puzzle y of her
existentially unforgeable signature scheme, then the choice. (2) Fairness for A: T will earn 1 bitcoin iff A
puzzle-promise protocol in Figure 6 securely realizes obtains a correct solution.
the extended Fpromise-sign functionality for the case of Q
payments. The security for T is 1 − ν(λ) while security We model the above two requirements with an ideal
for B is 1 − µ+η1
− ν(λ). functionality, that we call Ffair-RSA , shown in Figure 7.
( η ) Ffair-RSA is a trusted party between A and T . Ffair-RSA
receives a puzzle-solving request of the form (y, 1
B. Ideal Functionalities bitcoin) from A, and forwards the request to T . If T
We analyze each of the fair-exchange protocols used agrees to solve the puzzle y for A, then T receives 1
in TumbleBit in isolation. For each protocol, we identify bitcoin while A receives the puzzle solution. Otherwise,
the security (fairness) properties that we require for the if T refuses, A will get 1 bitcoin back, and T gets
players involved in that phase. nothing. Fairness for T is captured because A can
request a puzzle solution only if she sends 1 bitcoin to
In the Escrow Phase, we consider only interactions Ffair-RSA . Fairness for B is captured because T receives
between players B and T in the puzzle-promise protocol 1 bitcoin only if he agrees to reveal the puzzle solution.
(Section VI-A). We identify the functionality and the
security requirements that we expect by this interaction Remark 1. Note that A can always learn solution to
and we formally capture them through and ideal func- RSA puzzles that she generates herself without inter-
tionality Fpromise-sign that we describe in the details in acting with Ffair-RSA . That is, A can always choose
Section D. a random x ∈ Z∗N and generate the puzzle y = xe
mod N ; in this case, she trivially knows the puzzle
In the Payment Phase, we consider only interactions solution is x. This is not a problem because TumbleBit
between players A and T in the puzzle-solver protocol requires Alice A to solve puzzles that were provided

22
 −1
Ffair-RSA is parameterized by a function (fRSA , fRSA ), Functionality Fpromise-sign
algorithm ValidatePermutation to validate that the
parameters are a permutation wrt to fRSA , a trapdoor The functionality is parameterized by a format specification
FakeFormat, and parameters µ and η.
verification algorithm VerifyTrapdoor, and expiration
time tw ∈ N. Parties. B, T , and adversary S.
Parties. A, T , and adversary S. Setup. Inform Fpromise-sign if T is corrupt or honest.
Setup. On receiving (Setup, (e, N, d ) from T
Key Generation. Upon receiving message (KeyGen, B)
If ValidatePermutation(e, N ) = 0 or from party B, send it to S and receive response
VerifyTrapdoor(e, N, d ) = 0 then do nothing. (PK eph
T , Sig). Sig is a signing algorithm.
Else, send (Setup, e, N ) to A and S. Send (Setup, PK ephT ) to B and record the pair
(PK eph , Sig).
Evaluation. T

Signature Request. Upon receiving this message from B:

On input (request, sid, y, 1BT C) from A:
0
If y is in the range of fRSA , send (sign-request, PK eph
T , {FkTxni }i∈[η] , {mi }i∈[µ] )
(request, sid, A, y) to T . 0
Start counter tw sid = 0. If PK eph
T 6= PK eph
T , then do nothing.
If ∀i, FkTxni complies with FakeFormat then send to T
On input (evaluate, sid, A, x) from T : (sign-request, B, PK eph
T , {FkTxni }i∈[η] )
If y = fRSA (x, e, N ) then send (sid, x) to A.
Send (payment, sid, 1BTC) to T . Else, do nothing.
Promise. Upon receiving (promise, B, ANS, Set) from T .
If tw sid = tw , send (refund,sid, 1BTC) to A. If ANS = NO, then set all signatures to ⊥.
Else, if Set 6= ∅, compute signatures as follows:
Fig. 7. Ideal Functionality Ffair-RSA . − If T is honest:
Set FkSigni = Sig(FkTxni , PK eph
T ) for i ∈ [η].
− Else T is corrupt:
to her by Bob B, and generated through Bob B’s Send (Sign, FkTxni , B) to adversary S, and obtain
interaction with T during the puzzle-promise protocol. respective signatures.
− Abort if there is a recorded entry
Remark 2. Note that the functionality Ffair-RSA does not (FkTxni , FkSigni , PK eph
T , 0).
provide any privacy for A. Indeed, T learns A’s puzzle − Record entries (FkTxni , FkSigni , PK eph
T , 1) and
y even if T refuses to solve the puzzle. To use Ffair-RSA (mj , PK eph
T , promise).
in our unlinkable TumbleBit scheme, users will have to Send (Sign-promise, ANS) to B.
first blind their inputs to Ffair-RSA .
Signature Verification. Upon receiving
0
(Verify, sid, m, σ, PK eph ) from any party P :
D. Ideal functionality Fpromise-sign T
0
− If PK eph
T 6= PK eph
T , do nothing.
The security requirements for the puzzle-promise − Else, if T is honest:
protocol (Figure 4), which is run in the Escrow Phase ♦ If there is a recorded entry (m, σ, PK eph
T , 1),
of TumbleBit, are captured by an ideal functionality then set ver = 1 (completeness condition).
Fpromise-sign that we describe in Figure 8. ♦ If there is no recorded entry (m, σ, PK eph
T , 1),
then set ver = 0 and set the entry
Fpromise-sign acts a trusted party between B and T , 0) (unforgeability condition).
(m, σ, PK eph
T . Bob B sends the “real” and “fake” transactions to − Else, if T is corrupt:
Fpromise-sign . Fpromise-sign has access to an oracle that can then let ver be set by S. (Corrupt signer case).
compute the Tumbler’s T signatures on any messages. Send (Verified, sid, m, σ, ver) to party P .
Fpromise-sign is designed to guarantee the following two
properties: Fig. 8. Ideal Functionality Fpromise-sign .

(1) Fairness for B: If T agrees to complete the

protocol, then Bob B obtains at least one promise that
contains a valid signature on a real transaction. This actual signature on mj , but only a promise that this
property follows because Fpromise-sign has access to an signature will be revealed in the future.
oracle that computes the T ’s signature. Specifically,
upon receipt of a real message mj from B, functionality (2) Fairness for T : Bob B learns nothing except
Fpromise-sign keeps a record (mj , PK eph
T , promise) that signatures on fake transactions. This property follows
promises to return a valid signature on mj to B. for three reasons. First, Fpromise-sign will only ask its
Importantly, however, Fpromise-sign does not reveal the signing oracle to sign fake transaction, i.e., to sign

23
messages that conform to the fake transaction format 1) Case: A is corrupted: We start with intuition,
‘FakeFormat’. Second, when Fpromise-sign is asked to and then present the formal proof.
verify signatures, only signatures computed on fake
Intuition. We want to prove that, by participating in
transactions will be valid and all others will be invalid.
(and arbitrarily deviating from) the protocol in Figure 3,
This follows because the only signatures Fpromise-sign
any corrupted A does not learn anything more than the
considers to be valid are those that had previously been
solution x to the puzzle y, i.e., A learns only the RSA
computed by its signing oracle. Third, Fpromise-sign does
pre-image x = f −1 (y, d ) = y d . The transcript obtained
not reveal the actual signature on a real message mj ,
by A in the protocol executions contains: (1) pre-images
but only a promise that the signature will be revealed
for all the fake values βi with i ∈ F , that is f −1 (βi , d );
in the future.
(2) encryptions ci of the pre-images of all “real” βi and
Discussion. In the ideal world, S will be the signing hash hi of the keys used to encrypt these ci . Informally,
oracle for Fpromise-sign . This is follows the definition such transcript does not leak any information to A for
of the ideal functionality for signatures, per [16]. We the following reasons:
stress that this does not mean that S has an additional
power. The reason being that in the ideal world, the 1) A learns nothing from the answers to the fake
only signatures that are verified by Fpromise-sign are set: For all βi in the fake set F , A must
the ones on fake messages. Thus, towards ensuring provide the pre-images f −1 (βi , ·) to T before
indistinguishability between the real world and ideal T decrypts ci . Therefore, A does not learn
world, we just need to make sure that (when T is anything new from T ’s decryptions.
honest), no party can (in both the ideal and real world) 2) For the real βi , A is computationally-bound to
produce a signature on a real message without breaking a single puzzle y because in A must provide
unforgeability of the signature scheme. values r1 , . . . , rn that demonstrate that, for all
i,
Fpromise-sign and the case of Q payments. For the βi = y · (ri )e mod N
case of Q payments, we provide an extended version
of the Fpromise-sign functionality that deals with Q sets Intuitively, due to the hardness of inverting
of signatures. The main modification that we need to RSA trapdoor function, such values can be
make—beside having Fpromise-sign provide Q sets of provided only if βi s were honestly computed.
fake signatures rather than one set—is to additionally 3) A does not learn the puzzle solution y d unless
check the format of real messages. We therefore ex- T reveals ki used to encrypted the puzzle
tend Fpromise-sign with parameters Q and RealFormat(·), solution inside ci . Encryptions ci are statisti-
and a validation test that checks that any real mes- cally hiding (and in fact, equivocable12 ) in the
sage mj,i sent for the j-th set, complies with format Random Oracle model.
RealFormat(j). This is important because in our appli- Overview of proof. Formally, we shall prove this by
cation we need to control the type of messages that showing that there exists a PPT simulator S that is able
B gets signed. In our application, RealFormat(j) = to simulate the transcript between A and T , having in
CashOutFormat. input only the puzzle solution f −1 (y, d ) = y d . If this
Concretely, we extend Figure 8 as follows. First, is possible, it means that the transcript reveals nothing
Fpromise-sign is parameterized by two format specifica- more than the puzzle solution y d to A.
tions: FakeFormat and RealFormat, and 3 parameters We heavily use the programmability of the RO. In
Q, µ and η. Second, in the Signature Request step B a nutshell, the S computes all ciphertexts using random
one of the following tuples for every j ∈ [Q]: values (instead of by encrypting the actual values) and
0 will later ensure that they decrypt to the correct values
(sign-request, PK eph , {FkTxnj,i }i∈[η] , {mj,i }i∈[µ] )
T by programming the random oracle (RO). The key
In other words, B sends a Q×µ-matrix of fake messages observation is that, at any point in the protocol, T
FkTxnj,i and a Q×µ-matrix of real messages mj,i . The “decrypts” his encryptions only after A has sent some
ideal functionality will additionally check that: crucial information. Indeed, T sees the pre-images (i.e.,
ρi ) of the fake set before he sends the keys to decrypt
mj,i = RealFormat(j)
his ciphertext. This allows the simulator to learn how to
Then, when T chooses the Set ⊂ [µ] in the Promise program the RO to decrypt the ciphertext with the values
step, then index i ∈ Set means that B is promised that ρi that A reveals. Similarly, S learns the original puzzle
mj,` will be signed for every j ∈ [Q]. In other words, if y in the second phase of the protocol, and S will query
column index i is in Set, it follows that signatures are the ideal functionality Ffair-RSA with (y, 1btc) to obtain
promised for the entire column of real messages mj,i the puzzle solution x = y d . Finally, S will program the
∀j ∈ [Q]. RO so that he can equivocate the remaining ciphertexts
so that they decrypt to the correct puzzle solution x.
E. Proof of Theorem 1 12 Equivocable means that the encryptions can be later decrypted
The proof is divided into two cases. by S as any value, by programming the output of the random oracle.

24
Proof. The formal proof consists of two steps. First, and H : {0, 1}λ1 → {0, 1}λ2 are independent random
we describe the simulator S, then we prove that the oracles. Then, the view generated by S is computation-
transcript generated by S is indistinguishable from the ally indistinguishable from the view viewAdv,T (T , d )
transcript generated in the real world execution. Let Adv obtained by Adv in the real world.
denote the adversary corrupting player A.
Proof: We use a hybrid argument.
Simulator S.
S internally runs adversary Adv. Let session identifier H0 : This is the real game. The transcript is generated
be sid. Let QH be the set of queries made to the H precisely using the procedure of T with secret input
random oracle, and QH prg be the queries made to the d . The view generated in this hybrid experiment is
H prg random oracle. viewAdv (T , d ).

1) Setup. Extract (e, N, d ) from proof π pub- H1 : In this hybrid we change the way encryptions ci
lished by Adv. Send (Setup, (e, N, d )) to are decrypted and pre-image of hash values hi are
Ffair-RSA . computed. Instead of sending keys ki , as computed in
2) Upon receiving β1 , . . . , βm+n from Adv; ran- the protocol, send ki0 computed by running procedure
domly pick ci in {0, 1}λ and hi ∈ {0, 1}λ2 for Equivocate(ci , (βi )d , hi ). Note that, in this hybrid we
i ∈ [m + n] and send it to Adv. are still using d (which S does not know), but we are
3) Upon receiving F and ρi for i ∈ F , check if programming the answers to the RO. The difference
βi = (ρi )e mod N, ∀i. If check fails, output between H0 and H1 is in the way keys ki0 are computed.
whatever Adv outputs and halt. Else, run pro- Due to the security properties assumed in the
cedure Equivocate(ci , ρi , hi ) to obtains keys RO, the values ci , hi statistically hide the message
ki0 . Send ki0 for i ∈ F to Adv. encrypted and the hash-preimage; and probability of
4) Upon receiving y, ri for i ∈ R from Adv. If event Collision is negligible. Therefore, the view
βi = y · (ri )e mod N for all i ∈ R and generated in hybrid H0 is statistically indistinguishable
transaction Tpuzzle is correctly formed, do as from the view generated in H1 .
follows:
− Send (request,sid, y, 1btc) to Ffair-RSA H2 : This hybrid experiment is exactly as H1 with the
and obtain x = y d mod N . only difference that procedure Equivocate is run with
− Run Equivocate(ci , x · ri ,hi ) and obtain ki0 input Equivocate(ci , ρi , hi ) where ρi is taken directly
with i ∈ R. from the transcript, and Equivocate(ci , y d ·ri , hi ). where
− Send transaction Tsolve with values ki0 . y d is taken from Ffair-RSA only after Adv hast send
Else, checks have failed so output whatever Tpuzzle . The view generated in this hybrid experiment is
Adv outputs and halt. identical to view generated hybrid H1 , and correspond
to the simulation strategy S.Note that in this hybrid
Procedure RO: Random Oracle Simulation for H, H prg argument the entire view is generated only with a single
proceeds as follows. Upon receiving query q for H evaluation y d .
(resp., H prg ):
2) Case: Tumbler T is corrupted: We want to show
1) if query q ∈ QH (resp., QH prg ), retrieve entry that any adversary Adv corrupting T will earn 1 bitcoin
(q, a) from the set and output a. if and only if she provides a correct solution to A’s
2) Else pick a random a ∈ {0, 1}λ2 (resp. λ1 ), puzzle. This follows from the following arguments.
add (q, a) to QH (resp., QH prg ) and output a.
Assume that the parameters (N, e) chosen by the
Procedure Equivocate(ci , mi , hi ) is as follows: malicious Tumbler T are indeed a permutation for fRSA
over all of ZN . (This is guaranteed by the Setup proof
1) Pick a random ki0 ∈ {0, 1}λ1 . If ki0 ∈ QH or π.) That means that the puzzle y handed to A is has a
QH prg , output Collision and abort. unique inverse. Under these assumptions, define BAD
2) Compute ai = ci ⊕ mi , then add (ki0 , ai ) to the following event: (1) T passes the Fake Set Check
QH prg . (Step 7 in Figure 3), therefore providing n correct
3) Add (ki0 , hi ) to QH . decryptions to ci for i ∈ F , AND (2) all encryptions ci
4) Output ki0 . in the real set i ∈ R are incorrect, i.e., do not decrypt
to a valid puzzle solution.
Indistinguishability proof.
We prove by hybrid arguments that view Since (N, e) is a valid permutation, values
viewAdv,T (T , d ) obtained by Adv interacting with β1 , . . . , βm+n are all invertible and uniformly dis-
T playing with secret input d is indistinguishable from tributed in ZN , and consequently do not reveal any
the view S interacting with Ffair-RSA . information about sets F, R.
Lemma 1: Assume π is a zero-knowledge proof of Moreover, since H, H prg are modeled as random
knowledge in the random oracle model. Assume RSA oracles, encryptions of keys are binding, and Adv can-
assumption holds in Z∗N , and H prg : {0, 1}λ1 → {0, 1}λ not changes the values after sets F, R are revealed.

25
Therefore the probability of event BAD amounts to the to the information provided by the ideal functionality
probability of guessing set F , which is Fpromise-sign . Recall that, in the ideal world, Bob B only
receives signatures for the fake messages. With only
1 1
Pr[BAD] = m+n

+ this information in hand, S will have to simulate the
n
2λ1 view that the real world adversary B ∗ has during its
interaction with T . The idea is that, if we can prove
Simulator S. that the transcript generated by S is indistinguishable
Suppose Adv corrupts Tumbler T . S internally runs from the one generated by T , then it follows that any
Adv. B ∗ learns no more that what B learns from Fpromise-sign .
After the setup phase, S obtains pair ((e, N ), d ) We stress that the following analysis only consider
by extracting the proof π (recall π is a non-interactive the puzzle-promise protocol run during the Escrow
zero-knowledge proof-of-knowledge in the random ora- Phase. The analysis works in the stand-alone setting,
cle model). If ValidatePermutation(RSA, N ) = 1 S, where no other protocol, except the puzzle-promise
playing in the ideal world, receives (request, sid, protocol is executed.
y, 1 bitcoin) from Ffair-RSA . Using input y, S sim-
We start with the intuition behind the proof.
ulates the transcript that Adv expects to see in the
real world, by honestly following A’s procedure on Proof Intuition. We have to prove that the transcript
input y. Upon receiving {ki } for all i ∈ F from Adv, of the protocol between B ∗ and T , reveals nothing
S checks if all {ci }i∈F are correct. If so, S sends more than signatures on fake messages, i.e., σ` =
message (evaluate,sid, A) to Ffair-RSA which then Sig(SK eph
T , β` ) for ` ∈ F ; and a “promise” of at least
passes the puzzle solution x to the ideal world player one valid signatures on a real messages βi for i ∈ R. In
A. Meanwhile, S sends Tpuzzle to Adv. Upon receiving the real world, the promise is the set of puzzle-promise
Tsolve from Adv: if all keys {ki } for all i ∈ R decrypt pairs (ci , zi ) for i ∈ R, where ci is an encryption of a
ciphertexts ci that do not contain valid puzzle solutions, valid signatures on βi , and zi is an RSA puzzle whose
then S outputs BAD and aborts. Else, S outputs solution can be used to decrypt ci . The point of the
whatever Adv outputs and halts. proof is to show that B learns nothing else beyond the
guarantee that for i ∈ R there is at least one pair (ci , zi )
Indistinguishability Proof.
that has an encryption of a valid ECDSA signatures on
Under the assumption that fRSA is a permutation over
a real message βi .
ZN for public key (N, e), and that d is the trapdoor,
the transcript generated by the simulator is distributed We prove this by showing that if (1) the encryption
identically to the one generated in the real world, unless scheme is perfectly secure in the RO model, and (2)
the event BAD happens. To see why, note that, when S that RSA trapdoor function is hard to invert, then the
outputs ”BAD” it means that in the ideal world S sent transcript obtained by B from the interaction with T
message (evaluate,sid, A) to Ffair-RSA , so that ideal reveals nothing but the signatures on fake messages.
player A receives her output. However, in the real world, We will show that the entire transcript can be simulated
A will not get any valid output. So the two worlds by a simulator S that only gets the signatures on fake
will be distinguishable. The two worlds are therefore messages as input.
distinguishable with probability Pr[BAD].
To build intuition, we list the information that B ∗
obtains from the transcript, and we explain why it gives
F. Proof of Theorem 2 no information on the signatures of valid messages. B ∗
In this section we provide the formal proof of obtains the following values:
Theorem 2. We prove that the puzzle-promise protocol 1. Encryptions (c1 , . . . , cµ+η ) computed as a one-time
in Figure 4 securely realizes functionality Fpromise-sign pad of the output of the Random Oracle H shk queried
(Figure 8) in the random oracle model. with secret values 1 , . . . , µ+η .
The proof consists of analyzing two cases: (1) Case As we work in the (programmable) random ora-
B is corrupted, where we argue that any malicious cle, we assume that each encryption perfectly hides
B ∗ does not learn anything besides signatures of fake the message. Also, the simulator can equivocate each
transactions; (2) Case T is corrupted, where we argue decryption, by programming the random oracle. This
that, if the protocol successfully terminates, then B means that, encryptions ci alone do not reveal any in-
will be able to retrieve a signature (on a real cash- formation to B ∗ ; indeed the simulator S could generate
out transaction Tcash(T ,B) ) from a puzzle-promise pair such ci by just sending a random value. Here we are
(ci , zi ) for some i ∈ R. using the unpredictability property of the RO, as well
its programmability.
1) Case B is corrupted: The proof consists of
showing that for any corrupted B ∗ there exists a PPT 2. RSA puzzles (z1 , . . . , zµ+η ) where zi =
simulator S that corrupts B in the ideal world, and can Ffair-RSA (i , e, N ). Recall that each i is randomly
generate the entire view of B ∗ while having access only chosen group element, and that RSA parameters are

26
computed using the correct procedure. Therefore, under If there is no pair with (·, hR ) or (·, hF ), then
the assumption that RSA trapdoor function is hard in set R = F = ⊥.
the group determined by the chosen parameters, a PPT 2) Send pairs (ci , zi ) to B ∗ prepared as:
B ∗ cannot learn any i from zi . (1) For all i, ci ← {0, 1}s ;
$

(2) For i ∈ F , zi = (i )e where i ← Z∗N ;

 $
3. Quotients (q2 , ..., qµ ), where qj = j ji for ji ∈ R.
i−1 (3) For R = {j1 , . . . , jµ }, zji = (qi )e · zji−1
This is a sequence of connected divisions of the secret
where zj1 , q2 , . . . qµ ← Z∗N .
$
keys j1 , . . . , jµ . Intuitively, to see that these quotients
do not give any more information than what can be (B) Upon receiving (F 0 , R0 , ri ) from B ∗ , do the follow-
learnt from values zj1 , . . . , zjµ , we show that one can ing:
compute zji and qji that pass the “quotient test”, without
knowing any ji . 1) If F 0 6= F or R 6= R0 , then abort.
2) If any (FakeFormat||ri , βi ) ∈ / QH 0 for i ∈ F
To see why, note that the quotient test checks that then abort. For j ∈ R, set mj = γ if there
for each each i = 2, ..., µ, exists (γ, βi ) ∈ QH 0 . Else set mj = ⊥.
zji = zji−1 · (qji )e 3) Send to Fpromise-sign the message
(sign-request, PK eph T , {FakeFormat||r i }i∈F ,
where R = {j1 , ..., jµ }. This means that one can fix {mj }j∈R )
arbitrary zji , qji ∈ Z∗N and compute zji−1 as zji /(qji )e . Obtain response (promise, |B ∗ , ANS,
In this way one can generate zji , qji that pass the test {FkSigni }i∈[η] ).
without knowing the RSA inverse of any of the zji . If ANS = NO, then halt and output whatever
This observation will be crucial in the proof, because B ∗ outputs.
it allows us to show that if there is an adversary B ∗ that 4) Compute hj` = cj` ⊕ FkSign` .
is able to learn some ji for ji ∈ R, then we can build Store in QH shk the pair (j` ,hj` ).
a reduction ARSA that can solve an RSA puzzle z ∗ . 5) Send i for i ∈ F and quotients qj1 , . . . , qjµ .

Looking ahead, in order to carry out the reduction, (C) Finally, output whatever B ∗ outputs and halt.
we need to make sure that adversary ARSA can identify Procedure RO1: Random Oracle simulation for H
the set R in advance, so that he can place his challenge proceeds as follows. Upon receiving query γ for H:
value as z ∗ = zji for some ji in the real set. To achieve
this, we exploit the observability of the RO. Namely, the 1) If query γ ∈ QH , retrieve (γ, a) from QH .
reduction ARSA can obtain the set F and R by observing 2) Else pick random a ∈ {0, 1}λ2 . Add tuple
the RO queries made by B ∗ to obtain the values hR and (γ, a) to QH .
hF . 3) Output a.
Formal Proof. The formal proof consists of two Procedure RO2: Random Oracle simulation for H shk
steps. First we show a PPT simulator S generates proceeds as follows. Upon receiving query γ for H shk :
a simulated transcript for B ∗ , by using only the in- 1) If query γ ∈ QH shk , retrieve (γ, a) from QH shk .
formation that B would get in the ideal world (that 2) If (γ)e = (zi ) for some i ∈ R and no pair
is, only signatures of fake values obtained through (γ, a) has been recorded yet in QH shk , then
interaction with Fpromise-sign ). S exploits the extractabil- output RSA failure.
ity/programmability properties of the RO. Second, we 3) Else, pick a random a ∈ {0, 1}λ2 . Add tuple
prove that the view generated by the simulator S in the (γ, a) to QH shk .
ideal world is computationally indistinguishable from 4) Output a.
the transcript in the real world.
Indistinguishability Proof.
Simulator S. We now show that the transcript generated by S is
S, interacting with Fpromise-sign , internally runs adver- indistinguishable from the transcript generated by T in
sary B ∗ and simulates the messages that B ∗ expects the real world. This is done via a sequence of hybrid
from T as follows. experiments. We start with the real world transcript,
First, inform Fpromise-sign that T is honest. Then, hybrid H0 , where the transcript of the protocol is
compute (PK eph eph computed following algorithm T (Figure 4). Then, in
T , SK T ) = GenKey(1 ), and send
λ
eph
PK T to B and to Fpromise-sign .
∗ a sequence of hybrid experiments we change the way
we compute the values βi , ci , zi , qi until we reach the
(A) Upon receiving hR , hF , and {β1 . . . βµ+η } from B ∗ , final hybrid experiment where all values are computed
do the following: following the algorithm S defined above.
1) Extract sets F and R from RO. To do this, look H0 . This is the real world. The transcript is computed
at the set of queries QH made by B ∗ and ex- according to Protocol in Figure 4. Namely, the simulator
tract the pairs (salt||R, hR ) and (salt||F, hF ). follows exactly the same steps as the Tumbler T .

27
H0.5 (Learn R, F using observability of RO). In this hy- B ∗ that causes hybrid H2 to abort due to an RSA
brid experiment the simulator uses the observability of failure event.
the RO H during the protocol execution. Namely, upon
AdvRSA plays the RSA game, receiving values
receiving message (hF , hR , βi ) from B ∗ , we extract the
(e, N ), z ∗ from a challenger. The goal of AdvRSA is to
queries (salt||F, hF ) and (salt||R, hR ) made to QH to
output a the pre-image x = (z ∗ )d with non-negligible
identify the real and fake sets R, F . If no such query is
probability.
found, but later B ∗ sends a well formed message, the
simulator aborts. Meanwhile, the reduction’s high-level goal is to
place the challenge value z ∗ among the values
The difference between the distribution of the tran-
zj1 , . . . , zjµ with ji ∈ R. Because B ∗ causes hybrid H2
script obtained in H0 and that in H0.5 is that the
to abort due to RSA failure event, there exists some
simulator aborts in H0.5 if the RO H was not queried
i such that B ∗ queries H shk with ji = (zji )d , with
when forming hR , hR ). The probability of aborting
non-negligible probability. Thus, if AdvRSA places z ∗ in
corresponds to the probability of correctly guessing the
position ji , then AdvRSA wins the game with the same
output of H. As H is modeled as a RO, this probability
probability (discounted by a 1/µ polynomial factor of
amounts to 1/2λ2 . Therefore experiments H0 and H0.5
guessing ji correctly). The crux of the reduction is to
are statistically close.
show how AdvRSA generates the entire transcript for
H1 (Equivocate encryptions using programmability of B ∗ —and in particular the quotients q2 , . . . , qµ —without
RO). In this hybrid we change the way encryptions ci knowing the the pre-image of zji . To do this, we have
are computed. Instead of computing AdvRSA generate all zj` for j` ∈ R, without knowing
their pre-image.
ci = H shk (i ) ⊕ σi
Reduction AdvRSA .
In H1 , the simulator sets ci ← {0, 1} and stores the
$ s AdvRSA receives (e, N, z ∗ ) from the RSA chal-
pair (i , ci ⊕ σi ) in QH shk . Hybrids H0.5 and H1 are lenger. AdvRSA chooses ECDSA ephemeral key
statistically close due to the unpredictability of the RO (SK eph eph
T , PK T ). AdvRSA activates B
∗
on input
eph
H shk (when answers to RO H shk are processed as in ((e, N ), PK T ) and follow procedure run in H2 by
procedure RO2 of S above). computing (zji , qi ) as follows. AdvRSA first randomly
picks an index ji ∈ R and sets zji = z ∗ . Then she
H2 (Change computation of values for real set R using chooses values qj1 , . . . , qjµ and remaining zj1 , . . . , zjµ
RSA security). In this hybrid the simulator computes as follows.
zji , qi for i ∈ R, following the algorithm S described
above. The differences are the following. For ji ∈ R, 1) For values preceding zji (i.e., for 0 < ` < i),
in H1 we have that pick q`+1 ∈ Z∗N ; compute z` = (qz`+1
`+1
)e .
2) For values following zji (i.e., for i < ` ≤ µ),
zji = (ji )e pick q` ∈ Z∗N ; compute z` = (q` )e · z`−1
while in H2 we have that If event RSA failure occurs, then procedure RO2
e has observed an RSA pre-image some some zi . If zi =
zji = (qi ) · zji−1 z ∗ then AdvRSA outputs it and win the game. Else, she
halts.
where zj1 , q2 , . . . qµ ← Z∗N . Note that in H2 , ji is
$

neither computed nor stored in QH shk . Thus, H2 is Summing up, in hybrid H2 , tuples (i , ci ⊕ σi ) for
different from H1 because in H2 procedure RO2 can all i ∈ R are not recorded in QH shk . In other words,
trigger a RSA failure event and abort. (Because neither i , nor the signature σi for real messages mi
the RSA failure event happens when B ∗ queries with i ∈ R are computed in this hybrid.
oracle QH shk with the pre-image of a real puzzle zji ,
it follows that the probability of an abort in H2 is H3 (Obtaining signatures from Fpromise-sign .) In this
related to the probability of B ∗ of (RSA)-inverting zji hybrid experiment the signatures σi for i ∈ F
for some ji ∈ R.) Therefore, to argue that H1 and H2 are computed using Fpromise-sign . That is, S sends
are computationally indistinguishable, we need to show Fpromise-sign the message
that the distinguishing event – event RSA failure – (sign-request, B, PK eph T , {FakeFormat||ri }i∈F ,
happens only with probability that is negligible in λ. {mj }j∈R )
If ANS =yes, S uses answers σi = FkSigni to set
Lemma 2: Assuming that RSA is hard in Z∗N , with (i , ci ⊕ σi ) in QH shk . From B ∗ ’s the point of view,
N > 2λ then hybrid H2 and H3 are identical. Experiment H3
P r[RSA failure] ≤ ν(λ) thus corresponds to the exact simulation strategy S
described above. This conclude the proof.
Proof: We can construct a reduction AdvRSA to the In the above proof we have shown that any PPT
hardness of RSA trapdoor function using an adversary B ∗ does not learn anything from the transcript obtained

28
in Protocol in Figure 4. We now show that if B ∗ does choose Set in the ideal world. (2) To correctly compute
indeed output a valid signature σ ∗ for a valid message the signatures requested by Fpromise-sign via Sig. To this
Tcash(T ,B) , then B ∗ (who is not getting any information end, ST will do as follows. ST interacts with real world
from the transcript), must have produced a signature T ∗ , and if T ∗ provides an accepting transcript, then ST
forgery. Define event Eforge as the event where, a PPT will play ANS =yes. Then, by using the observability
B ∗ runs the protocol in Figure 4 and outputs a pair of the RO H shk , ST will extract the signatures σi for
(Tcash(T ,B) , σ) where Tcash(T ,B) is a real message rather i ∈ F ∪ Set and uses these signatures to produce the
than a fake message (i.e., Tcash(T ,B) is a valid cash- output of the signing algorithm Sig.
out transaction for Tcash(T ,B) that does not conform to
At high-level, a bad case for the simulator ST is
FakeFormat). We now prove the following.
when (1) the transcript is accepting13 and ST sent
Lemma 3: If ECDSA is an existentially unforgeable promise ’ANS =yes, Set’ to Fpromise-sign , but either
signature scheme, P r[Eforge ] is negligible. (1) the real T ∗ did not make RO queries that allow ST
to recover σi from ci for all i ∈ F ∪Set, or (2) the pairs
Proof: We can construct an adversary Advecdsa that cj , zj for the real set R, will not eventually allows B
forges a signature on a new message Tescr(T ,B) i using to obtain at least one signatures. That is, the bad case
adversary B ∗ . happens when the promise is fulfilled in the ideal world,
Advecdsa plays the signature game and has oracle but not in the real world.
access to the signing algorithm O, and has verification Thus, the crux of the proof is to show that the
key PK ephT . The goal of Advecdsa is to use B
∗
to probability of the bad event is negligible if T ∗ provides
produce a signatures σ on a message that was never
∗
an accepting transcript. That is, when the transcript is
queried to O. Advecdsa simulates the interaction between accepting and ST plays ANS =yes in the ideal world,
B and T using algorithm S. Recall that S obtains also real world B is guaranteed that will receive the
the signatures by interacting with the ideal function- promised signature. At a high level, this holds due to
ality Fpromise-sign and, in particular, S only queries the following reasons.
Fpromise-sign for signatures on fake messages, i.e., , with
messages in f ki ∈ FakeFormat. Thus, the reduction 1. Fake-Set Test. Due to the perfect hiding of the RO,
Advecdsa will simply run S’s algorithm, and when S sets F and R are information theoretically hidden for
queries Fpromise-sign , Advecdsa will use its access to O T ∗ . Thus the probability that T ∗ successfully passes
to generate the correct signatures. It follows from the the cut-and-choose phase, (i.e., the Fake Set Check in
previous hybrid arguments that B ∗ cannot distinguish Figure 4) and that there is no i ∈ R such that (ci , zi )
whether she is talking to T or S. Therefore, the proba- is correctly formed, corresponds to the probability of
bility of B ∗ generating a forgery when interacting with correctly guessing the set F . This happens with proba-
T is close (up to a negligible factor) to the probability bility: η+µ
1
( η )
of B ∗ generating a forgery when interacting with S and 2. Quotient Test. The quotients q2 , . . . , qµ guarantees
therefore Advecdsa . that knowledge of j1 = (zj1 )d for j1 ∈ R, allows B to
If B ∗ outputs the pair (σ, m), and m ∈
/ FakeFormat, learn all remaining keys j2 , . . . , jµ . To see why, notice
then Advecdsa has obtained her forgery (σ, m). Thus, that if T ∗ passes the Quotient Test, it means that for
P r[Eforge ] = P r[Eforge−ECDSA ] − ν(λ). Which is neg- each i, zji = qi · zji−1 . Thus unlocking zj1 recovers j1
ligible assuming EDCSA signature scheme is secure. that in turns unlocks zj2 which recovers j2 and so on.
Since (N, e) define a permutation over ZN , then zj1 is
invertible and has a unique pre-image j1 . Therefore,
2) T is corrupted: We now show that the view of even if only one ciphertext cji contains a valid signature,
any corrupted T ∗ , playing with an honest B, can be B will be able to decrypt cji and recover that signature.
simulated by a simulator ST that only has access to the
ideal functionality Fpromise-sign . Formal proof. We now proceed with the formal argu-
ment. We present the simulator ST , the algorithm Sig
Proof Intuition. In the ideal world, T needs to decide (which is part of Fpromise-sign , see Figure 8), and finally
whether to grant signatures to B (that is, set ANS to argue that the transcript generated by the simulator in
yes or no, and the indexes in Set) in a committing the ideal world is indistinguishable from that in the real
manner: if ANS =yes then T has no power to prevent world.
B from getting the promised signatures later. This is
because ideal functionality Fpromise-sign has access to Simulator S.
the algorithm Sig, and when ANS =yes the ideal func- S runs T ∗ internally.
tionality proceeds with the computation of the required Upon receiving (KeyGen, B), send request to T ∗ and
signatures for the fake messages, and has the ability to obtain PK eph eph
T . Send (PK T , Sig) to Fpromise-sign where
sign the real messages in the future. Sig is defined as below.
Now, the goal of the simulator ST , is twofold: (1) To 13 A transcript is accepting if the honest player B completes the
decide whether T should set ANS to yes or no, and to protocol without aborting.

29
 Upon receiving (sign-request, B, PK eph Indistinguishability
T , {FkTxni }i∈[η] ): Proof.
Randomly pick R, F with R ∩ T = ∅, compute the RO The protocol messages generated by ST interacting
outputs hF , hR and β1 , . . . , βη+µ , and send them to with T ∗ are distributed identically to the transcript
T ∗. produced by a real B. The only difference between the
distribution of the output of the real and ideal world
Upon receiving a pair (ci , zi ) from T ∗ :
is that the simulator aborts more often. Thus, prov-
1) Extract i by observing queries to H shk . ing indistinguishability between the two distributions,
2) Let σi be the signature decrypted from ci using amounts to proving that events binding-fail! and
i . cut-and-choose-fail! happen with negligible
3) If ci , zi , i , βi , σi for i ∈ F pass all validity probability.
checks, record tuple (FkTxni , βi , σi ) in Lf ake . Let us look at each event, and argue why they occur
4) If ci , zi , i , βi , σi for i ∈ R pass all validity with negligible probability.
checks, add i to set Set, and add (βi , σi ) to
Lreal . If no such i exists, set real = no. (Note Event cut-and-choose-fail! This event hap-
that, for the real set, it is sufficient that one a pens when the transcript is accepting and all the fake
single l , with l ∈ R is correct. This is because values are computed correctly, but all the real values are
the quotient chain guarantees that knowledge incorrect (i.e., ST set real = no). Since (N, e) defines
of the pre-image of zj1 (i.e., j1 ) allows B to a permutation for fRSA , we have that all zji ∈ ZN have
obtain all the pre-images zj1 (i.e., ji ) for ji ∈ a unique inverse ji .
R.)
Namely cut − and − choose − fail! happens
For all i ∈ F , pick randomness ri , and send it T ∗ . when:
Add pair (FkTxni ||ri , βi ) to QH 0 .
1) For all i ∈ F , T ∗ provides consistent re-
Upon receiving the ‘openings’ 0i to fake mes- sponses i , which were queried to H shk .
sages i ∈ F , use 0i to obtain σi0 from ci . If 2) For all j ∈ R, there exists no j ∈ QH shk that
any (i, ci , zi , 0i , βi , σi0 ) fails any validity check, send can be used to decrypt cj to a valid signature
(promise, B, N O, ⊥) to Fpromise-sign . Else, if all checks σj on βj .
pass, send (promise, B, yes, Set).
Now we have two cases: By the hiding of H, H 0 , probability of
cut − and − choose − fail! corresponds to the
Case 1: Suppose there exists i ∈ F such that tuple probability that T ∗ guesses the set F which is:
(i, i , βi , σi ) passes all validity checks but (·, βi , σi )
0 0 0

is not recorded in Lf ake . Then, abort and output 1 1

µ+η + λ1


binding-fail!. n
2
Case 2: Otherwise, for all i ∈ F , we have that .
(i, 0i , βi , σi0 ) pass all validity tests and (·, βi , σi0 ) is Event binding-fail! This event happens when (1)
recorded in Lf ake . T ∗ did not query the random oracle H shk with string 0i ,
1) If real = no, abort and output but (2) later he sends 0i that passes all validity checks
cut-and-choose-fail!. and is such that
2) Else, set variables Lf ake and Lreal for algo- ci = H shk (0i ) ⊕ σi
rithm Sig.
where σi is a valid signature on βi . This event happens
If Case 1 and Case 2 do not happen, then it holds
if somehow T ∗ was able to predict the output of H shk
that the transcript generated in the protocol –which
without actually querying H shk , or if T ∗ finds two i , 0i
is distributed identically to a real transcript–, contains
such that zi = i and zi = 0i . Due to the fact that RSA
enough information for an honest B to decrypt at least
is a permutation and that B checks that i < N , the
one valid signature, by simply solving puzzle zj1 . The
latter event happens with probability 0. Due to the one-
latter is true, due the fact that zj1 ∈ ZN and have
wayness of the random oracle, the first event happens
a unique preimage, since parameters (N, e) define a
when T ∗ guesses the output of H, which happens with
permutation.
negligible probability 1/2λ2
Algorithm Sig(mi , PK ephT ).
Internal variable Lf ake and Lreal . G. Proof of Theorem 3: the case of Q payments
If there is tuple (mi , βi , σi ) in Lf ake , output signature
(βi , σi ). We now prove the Theorem 3 for puzzle-promise
Else if there is tuple (βi , σi ) in Lreal , then add tuple protocol that allows Bob B to obtain Q payments. The
(mi , β) to QH 0 , and output signature (βi , σi ). proof follows similar arguments used to prove Theo-
Else, abort. rem 2 for the “base case” where Q = 1 in Appendix F.

30
 1) Case B is corrupt: We outline the key differences hybrid H2j as the experiment where: (1) the j-th row of
w.t.r to the simulator and the indistinguishability proof puzzles zj,i1 , . . . , zj,iµ is computed as:
provided in Appendix F.
Simulator. zj,il = (ql )e · zj,il−1 , ∀l ∈ [µ]
The simulator for protocol in Figure 6, that we denote
by S Q , follows the same steps as the simulator S shown (2) queries (j||`|j,` , j−1,` , . . . , 1,` ) for ` ∈ R are not
for the base case, with the following modifications: recorded in QH shk .

Step (A): S receives hR , hF and βj,i for j ∈ Q, i ∈ Then, indistinguishability of experiment H2j and
[η + µ]. H2j−1 can be argued by following the same argument
as Lemma 2: the RSA reduction AdvRSA will place
Step (B.2): S additionally receives ρj,i for j ∈ its challenge z ∗ among the puzzles of the j-th row
[Q], i ∈ R, checks whether zj,i1 , . . . , zj,iµ (il ∈ R), while computing all the re-
maining rows as in H2j .
(CashOutFormat(j, ρj,i ) ∈ QH 0
and, if so, sets the real messages mj,i = H. Case T is corrupt
CashOutFormat(j, ρj,i ), and the fake messages
FkTxnj,i = FakeFormat||rj,i . Else, it aborts. The Here it will be most convenient to present the full
difference here is that for the case of Q payments simulator STQ for the case of Q payment. We then pro-
we also check the semantics of the real messages. vide an indistinguishability proof by presenting its key
That is, a real message for level j must be a cash-out differences w.r.t. the base case shown in Appendix F.
transaction that transfers exactly j bitcoins to Bob. Simulator.
Step (B.3): For each j ∈ Q, S sends Conceptually, there is no difference between STQ and
ST (the simulator for the base case in Appendix F). The
0
(sign-request, PK eph , {FkTxnj,` }`∈F , {mj,i }i∈R ) both send ANS =yes to Fpromise-sign if the transcript is
T
accepting, and they both try to extract keys j,i from
the RO H shk , for all i ∈ F and for some i ∈ R. For
Step (B.4): For j ∈ Q, ` ∈ F , S stores in QH shk the both simulators, the bad event corresponds to case when
pair the transcript is accepting but the simulator does not
([j, `, j,` ||j−1,` || . . . , 1,` ], hj,` ) observes a RO query that contains an i that allows σi
to be recovered from ci for all i ∈ F ∪ Set.
Procedure RO2: The difference here is that in the
The only difference between ST and STQ is what
case of Q payments, when decrypting a ciphertext at
constitutes a good key, that is, a key that allows the
level j, B ∗ needs to query the RO H shk with all the
simulator to decrypt a signature. In the base case of 1
j 0 with j 0 < j. Thus, Procedure RO2 is modified as
payment, a good key is a string i such that H shk (i ) ⊕
follows. A query γ is parsed as (j|`|γj |γj−1 | . . . , γ1 ),
ci = σi and σi is a valid signature and zi = (i )e . In
and the procedure aborts and outputs RSA failure
the case of Q payment, we need Q good keys, and the
if there exits a j ∗ ∈ [j] such that (γj ∗ )e = zj ∗ ,` with
j-th good key is a chain (j,i , j−1,i , . . . , 1,i ) of good
` ∈ R, and no pair ([j ∗ , `, . . . ||γj ∗ || . . .], a) has been
keys.
recorded yet in QH shk .
Simulator STQ .
Indistinguishability Proof.
The indistinguishability proof for the output of S Q STQ runs T ∗ internally.
follows the same hybrid experiments shown for arguing Upon receiving (KeyGen, B) send request to T ∗ and
indistinguishability of the output of S in AppendixF. obtain PK eph eph
T . Send (PK T , Sig) to Fpromise-sign where
In particular, experiments H0.5 and H3 can be directly Sig is defined below.
extended for the case of Q payments. Denote the
extended experiments by H0.5 Q
and H3Q . Upon receiving
0
In experiment H2 , S changes the way the real (sign-request, PK eph
T , {FkTxnj,i }i∈[η] , {mj,i }i∈[µ] )
RSA puzzles are computed by not recording the RSA-
solutions i` for i` ∈ R in QH shk . This change po- for all j ∈ [Q]. Randomly pick R, F with R ∩ F = ∅,
tentially triggers event RSA failure in the RO2 compute the RO outputs hF , hR and βj,i for j ∈ Q and
procedure. The distribution of hybrid H2 is only compu- i ∈ [η + µ], and send them to T ∗ .
tationally indistinguishable from hybrid H1 in the proof Upon receiving pairs (cj,i , zj,i ) from T ∗ . Then, do
of the base case in of Appendix F. So, when we deal the following for j = 1, . . . , Q:
with of Q payments we use a sequence of sub-hybrids
H2Q , H2Q−1 , . . . , H21 . In sub-hybrid H2j we change the 1) Extract key j,i by observing queries to H shk
j-th row of real RSA puzzles. Hence, first we define that have format (j|i|j,i |j−1,i | . . . |?), where

31
 j−1,i , . . . 1,i are the keys extracted previ- compute any i ∈ R correctly, therefore not de-
ously. livering any promise. We focus only on the event
2) Let σj,i be the signature decrypted from cj,i cut-and-choose-fail!(event binding-fail!
using j,i , . . . , 1,i . depends only on the failure of the random oracle, and
3) If cj,i , zj,i , j,i , βj,i , σj,i for i ∈ F pass all va- is independent of the number of payments). We argue
lidity checks, record tuple (FkTxnj,i , βj,i , σj,i ) that probability of such event is negligible, due to the
in Lf ake . same arguments as the base case. Too see why, consider
4) If cj,i , zj,i , j,i , βj,i , σj,i for i ∈ R pass all the following observations.
validity checks add pair (j, i) to a temporary
set TempSet. Else add (j, ⊥) in TempSet. In the base case, a coordinate i ∈ F passes the va-
lidity check if the tuple zi , ci , σi is correctly computed.
If there exist no i such that for all j, tuple (j, i) ∈ In the Q-payments case, a coordinate i ∈ F passes the
TempSet then set real = no. Else, store in Set the in- check if the column zj,i , cj,i , σj,i is correctly computed
dexes i such that (j, i) ∈ TempSet for all j ∈ Q. Then, for all j ∈ [Q]. That is, starting from j = 1, it holds that
only for i ∈ Set, record tuple (mj,i , βj,i , σj,i ) ∈ Lreal c1,i is correctly computed using keys 1,i , and for j = 2,
for all j ∈ [Q]. c2,i is correctly computed using both keys (2,i |1,i ) and
so on and so forth. Thus, for column i we have that B
For all j ∈ [Q] and i ∈ F , pick randomness rj,i , is guaranteed that he can decrypt all signatures for all
and send it T ∗ . Add pair (FkTxnj,i ||rj,i , βj,i ) to QH 0 . j = [Q].
For all j ∈ [Q] and i ∈ R, pick randomness ρj,i , Now, recall that this check is performed for all
and send it T ∗ . Add pair (mj,i ||ρj,i , βj,i ) to QH 0 . i ∈ F . This means that for η coordinates T ∗ correctly
computed for all levels j ∈ [Q]. Hence, the probability
For all j ∈ [Q], upon receiving the ‘openings’
that all columns i ∈ F are computed correctly in all Q
0j,i to fake messages i ∈ F , use 01,i , . . . , 0j,i to
levels, but there is no column i ∈ R that is completely
obtain σj,i
0
from cj,i . If any (j, i, cj,i , zj,i , 0j,i , βj,i , σj,i
0
)
correct in all Q levels, amounts to the probability of
fails any validity check, send (promise, B, N O, ⊥) guessing F . Thus, it follows that there exists at one
to Fpromise-sign . Else, if all checks pass, send column i ∈ R, where values (zj,i cj,i , σj,i ) are computed
(promise, B, Y ES, Set).
correctly for all levels j, except with probability µ+η 1
.
( n )
Now we have two cases:
However, we need a second argument that shows
Case 1: Suppose there exists i ∈ F and j ∈ [Q] such that, even one good index i ∈ R suffices for B to
that tuple (i, 0j,i , βj,i , σj,i
0
) passes all validity checks but recover his required signatures. To argue this, we use the
(·, βj,i , σj,i ) is not recorded in Lf ake . Then, abort and
0
quotient chains provided for each j ∈ Q. The quotient
output binding-fail!. chain qj,1 , . . . , qj,µ guarantees that for level j, solving
puzzle zj,i1 for i1 ∈ R is sufficient to then unlock all
Case 2: Otherwise, for all i ∈ F and j ∈ [Q], we
puzzles in level j. This guarantees that for every level
have that (j, i, 0j,i , βj,i , σj,i
0
) pass all validity tests and
j, B will be able to unlock keys j,i for all i ∈ R. Thus,
(·, βj,i , σj,i ) is recorded in Lf ake .
0
if there is at least on i ∈ R where the entire column
1) If real = no, abort and output is correctly formed, then B is guaranteed to decrypt at
cut-and-choose-fail!. least one entire column (and STQ is guaranteed to not
2) Else, set variables Lf ake and Lreal for algo- abort) except with probability µ+η 1
.
( n )
rithm Sig.

Algorithm Sig(mi , PK eph I. Details of our Bitcoin Scripts

T ).
Variables: Lf ake and Lreal . Figure 9 overviews the relationships between the
Search for record (mj,i , βj,i , σj,i ) in Lf ake and Lreal transactions used in the TumbleBit protocol. We walk
and output (βj,i , σj,i ). Else, abort. through the details of our transactions, explain why
Note that mi,j cannot be found in both lists. This they conform to the Pay-To-Script-Hash (P2SH) [3]
is because Lf ake is populated only with signatures template, and discuss why TumbleBit protocol is not
of messages in FakeFormat, and Lreal only collects affected by the transaction malleability issue [5] of the
signatures of messages in RealFormat, and a message current Bitcoin protocol:
mj,i cannot be both fake and real.
Transaction malleability. The transaction malleability
Indistinguishability Proof. issue is roughly explained as follows. If one bitcoin
As for the base case, the indistinguishability proof transaction Tfulfill fulfills another bitcoin transaction
amounts to show that the probability that STQ aborts Toffer , then Tfulfill must contain a pointer to Toffer . The
in the simulation is negligible. As in the base case pointer is the TXID, which is the hash of entire Toffer
(Appendix F), STQ will abort if the test phase passes transaction, including any signatures on that transac-
successfully, but later he finds that T ∗ did not tion. Now, bitcoin uses ECDSA signatures over the

32
Secp256k1 elliptic curve. It is well known that ECDSA up to and including OP_CHECKMULTISIG checks for
signatures are not deterministic. First, a party that holds the condition T ∧ B—checking if a valid Tcash(T ,B) has
the secret signing key can easily produce multiple valid been posted that is signed by both Tumbler T and Bob
signatures on a single message m. Second, even a party B. The redeem script above is hashed and its hash is
that does not know the secret signing key can take a stored in Tcash(T ,B) . (This ensures that the transaction
valid signature on a message m, and maul it to produce conform to the to the Pay-To-Script-Hash (P2SH) [3]
a different valid signature on m. Now, because TXID template.)
is the hash of the entire Toffer transaction, including all
signatures on that transaction, mauling these signatures If Tcash(T ,B) is posted to the blockchain, it contains
results to a different TXID of Toffer . Such mauling (1) the redeem script above and (2) the following input
attacks are not a problem for a transaction that is values that include the required two signatures:
already in a blockchain, but they can cause problems
to transactions that are still unconfirmed. OP_FALSE
payer_signature
The Bitcoin community is currently considering patch- redeemer_signature
ing transaction malleability using a solution called seg- OP_TRUE
regated witness [58], but as of this writing it has not
been fully deployed [20]. TumbleBit, however, remains To programmatically validate that Tcash(T ,B) can fulfill
secure even in the absence of segregated witness. Tescr(T ,B) (per the P2SH template), the redeem script
in Tcash(T ,B) is hashed, and the resulting hash value is
1) Interaction between Tumbler and Bob.: The right compared to the hash value stored in Tescr(T ,B) . If these
side of the Figure 9 presents the transactions used for match, the redeem script is run against the input values
the interaction between the Tumbler T and Bob B. The in Tcash(T ,B) . Tcash(T ,B) fulfills Tescr(T ,B) if the redeem
script in the Tescr(T ,B) transaction offers 1 bitcoin to a script outputs true.
fulfilling transaction satisfies the condition (B ∧ T ) ∨
(T ∧ tw2 ), i.e., a transaction that is either (1) signed Meanwhile, if Bob B refuses to post Tcash(T ,B)
by both B and T , or (2) signed by T and posted to the before the timewindow tw2 ends, then the Tumbler
blockchain after timewindow tw2 . Condition (2) is time- T can reclaim the bitcoin escrowed in Tescr(T ,B) by
locked refund condition which is scripted as follows: posting a refund transaction Trefund(T ,B) . (See the right
side of Figure 9.) When Trefund(T ,B) is posted to the
locktime blockchain, it contains (1) the redeem script above and
OP_CHECKLOCKTIMEVERIFY (2) the following input values, where signature is a
OP_DROP signature that verifies under payer_pubkey:
payer_pubkey
OP_CHECKSIG Signature
OP_FALSE
where locktime is a timewindow (i.e., an absolute
block height). All subsequent descriptions of our scripts Trefund(T ,B) fulfills Tescr(T ,B) if the hash of the redeem
use refund_condition as a placeholder for the script in Trefund(T ,B) matches the hash value stored
script above. For Tescr(T ,B) , the refund condition script in Tescr(T ,B) , and if the redeem script in Trefund(T ,B)
has locktime is set to tw2 and payer_pubkey is outputs true when run against the input values in
set to the Tumbler’s public key. Trefund(T ,B) .
Now, the full redeem script for the two-of-two Notice that Bob B is not involved in constructing
escrow transaction Tescr(T ,B) is as follows: the refund transaction Trefund(T ,B) ; indeed, Trefund(T ,B)
need only be signed by the Tumbler T . There are two
OP_IF reasons why this is crucial.
OP_2
payer_pubkey First, Trefund(T ,B) must be posted when B becomes
redeemer_pubkey uncooperative. Thus, Tumbler T can singlehandedly
OP_2 post Trefund(T ,B) , and reclaim his bitcoin, even in cases
OP_CHECKMULTISIG, where Bob refuses to interact with T .
OP_ELSE The second reason is the transaction malleablity
refund_condition issue [5] of the current Bitcoin protocol. Suppose that
OP_ENDIF Bob B mauls14 his signature on transaction Tescr(T ,B)
before it is posted to the blockchain, causing the TXID
where payer_pubkey is the Tumbler’s public key, for Tescr(T ,B) to change from the TXID value expected
redeemer_pubkey is Bob’s public key, and the
refund_condition is scripted as described above 14 In fact, this mauling could even be done by the Bitcoin miner
with locktime set equal to tw 2 . Note that instructions that confirms Tescr(T ,B) on the blockchain!

33
by T . This has no effect on the Tumbler’s ability has input values that contain the correct preimages
to post the refund transaction Trefund(T ,B) . Specifically, (h1 , . . . , h15 from Figure 3) and is signed by T ’s
before posting Trefund(T ,B) , the Tumbler need only find public key, or (2) the fulfilling transaction is a refund
Tescr(T ,B) on the blockchain, hash Tescr(T ,B) to obtain transaction signed by Alice and posted to the blockchain
its TXID, and use this TXID when it forming his after timewindow tw1 . This redeem script is hashed
refund transaction Trefund(T ,B) . By contrast, suppose and its hash is stored in Tpuzzle . To fulfil Tpuzzle , the
our protocol had instead somehow required Bob to transaction Tsolve contains (1) the redeem script whose
participate in forming Trefund(T ,B) before Tescr(T ,B) had hash is stored in Tpuzzle , and (2) the following input
been posted to the blockchain. Then a malicious Bob values:
could give the Tumbler a valid Trefund(T ,B) on Tescr(T ,B) .
Then, Bob could maul the signatures on Tescr(T ,B) , signature
and then post the mauled Tescr(T ,B) to the blockchain. k15
Tescr(T ,B) would still be a valid transaction, but the ...
Trefund(T ,B) held by the Tumbler would be useless, be- k1
cause Trefund(T ,B) no longer points to Tescr(T ,B) (because OP_TRUE
Bob has mauled the TXID of Tescr(T ,B) ).
where signature is a signature under the the Tum-
2) Interaction between Tumbler and Bob.: The left
bler T ’s public key. The preimages k1 , ..., k15 are such
side of the Figure 9 presents the transactions used
that H(k` ) = h` per Figure 3.
for the interaction between Alice A and the Tumbler
T . The script in the Tescr(A,T ) transaction offers 1 Per Section V-D, however, if all parties are cooper-
bitcoin to a fulfilling transaction satisfies the condition ative, the Tumbler T just holds on to Tpuzzle and never
(A ∧ T ) ∨ (T ∧ tw1 ). The redeem script for this signs or posts Tpuzzle to the blockchain. However, it is
transaction is identical to the one used in Tescr(T ,B) , important to note that once Alice A provides Tpuzzle
except that now payer_pubkey is Alice’s public key, to the Tumbler T , the Tumbler can claim the bitcoin
redeemer_pubkey is the Tumbler’s public key, and escrowed in Tescr(A,T ) . To do this, T just signs and
the locktime in the refund_condition is set posts Tpuzzle to the blockchain, and then forms, signs
equal to tw 1 . Tcash(A,T ) from Figure 9 is formed analo- and posts Tsolve to the blockchain. No involvement
gously to Tcash(T ,B) , and the refund Trefund(A,T ) pointing from Alice A is required to do this, and thus the
to Tescr(A,T ) is formed analogously to Trefund(T ,B) . Tumbler T can claim his bitcoin even if Alice stops
communicating with T . Notice, however, if T decides
Recall from Section V-D, that in the puzzle-solver
to unilaterally claims a bitcoin by posting Tsolve , the
protocol, Alice forms and signs Tpuzzle and sends it to
Tumbler T necessarily reveals the puzzle solution (see
the Tumbler. Transaction Tpuzzle fulfils Tescr(A,T ) via the
Section V-B). Therefore, Alice gets what she paid for
condition (A ∧ T ). Thus, (just like Tcash(A,T ) ), a valid
even if she stops cooperating with the Tumbler T . As
transaction Tpuzzle should contain (1) a hash of redeem
a final note, Alice cannot use transaction malleability
script for Tescr(T ,B) , and (2) input values that include
to steal her bitcoin from the Tumbler; when Alice A
the required signatures from A and T . If a valid Tpuzzle
gives Tpuzzle to the Tumbler T , then Tpuzzle points to
is posted to the blockchain, Alice’s bitcoin escrowed in
the Tescr(A,T ) transaction which is already confirmed
Tescr(A,T ) is transferred to Tpuzzle . However, this bitcoin
by the blockchain and thus cannot be mauled.
remains locked up in Tpuzzle until Tpuzzle fulfilled by a
transaction the meets the condition (T ∧ A∀j ∈ R : Finally, recall from Section V-D that if T becomes
hj = H(kj )) ∨ (A ∧ tw1) as specified to the following uncooperative, T could sign and post Tpuzzle to the
redeem script: blockchain, and then refuse to sign and post Tsolve . In
this case, Alice never obtains her puzzle solution, and
OP_IF must reclaim her bitcoin which is locked in Tpuzzle by
OP_RIPEMD160, h1, OP_EQUALVERIFY posting a refund transaction Trefund(A,T ) that points at
OP_RIPEMD160, h2, OP_EQUALVERIFY Tpuzzle . (See Figure 9.) Specifically, Trefund(A,T ) points
... at Tpuzzle and (1) contains the redeem redeem script
OP_RIPEMD160, h15, OP_EQUALVERIFY whose hash is stored in Tpuzzle and (2) and the following
redeemer_pubkey input values values, where signature is a signature
OP_CHECKSIG that verifies under Alice’s public key:
OP_ELSE
refund_condition Signature
OP_ENDIF OP_FALSE

The redeemer_pubkey is the Tumbler T public Once again, Alice can post Trefund(A,T ) without any help
key, and the refund condition has payer_pubkey as from the Tumbler. Once again, this matters because the
Alice’s public key and locktime as tw1 . This redeem refund transactions must be posted when T becomes
script checks that either (1) the fulfilling transaction uncooperative, and must still be valid even in the face

34
of transaction malleability (i.e., if T mauls the TXID
for the transaction fulfilled by Trefund(A,T ) .)

35
 Alice to Tumbler (𝓐→𝓣) Transactions Tumbler to Bob (𝓣→𝓑) Transactions

Tescr(𝓐,𝓣) Tescr(𝓣,𝓑)
Inputs: Inputs:
0. ← 𝓐 0. ← 𝓣
Outputs: Outputs:
0. [1 BTC] → (𝓐 ∧ 𝓣) ∨ (𝓐 ∧ tw1) 0. [1 BTC] → (𝓑 ∧ 𝓣) ∨ (𝓣 ∧ tw2)

⊕ ⊕
Trefund(𝓐,𝓣) Tpuzzle Tcash(𝓐,𝓣) T refund(𝓣,𝓑) Tcash(𝓣,𝓑)
Inputs: Inputs: Inputs: Inputs: Inputs:
0. ← 𝓐 ∧ tw1 0. ← (𝓐 ∧ 𝓣) 0. ← (𝓐 ∧ 𝓣) 0. ← 𝓣 ∧ tw2 0. ← (𝓑 ∧ 𝓣)
Outputs: Outputs: Outputs: Outputs: Outputs:
36

0. [1 BTC] → 𝓐 0. [1 BTC] → (𝓣 ∧ ∀j∈R:hj=H(kj))∨(𝓐 ∧ tw1) 0. [1 BTC] → 𝓣 0. [1 BTC] → 𝓣 0. [1 BTC] → 𝓑

⊕ Uncooperative 𝓑
Trefund(𝓐,𝓣) Tsolve
Inputs: Inputs:
0. ← 𝓐 ∧ tw1 0. ← 𝓣 ∧ ∀j∈R:hj=H(kj)
Outputs: Outputs:
0. [1 BTC] → 𝓐 0. [1 BTC] → 𝓣

Uncooperative 𝓣 Uncooperative 𝓐

Fig. 9. Transaction relationships when Q = 1. Arrows indicate spending. Transactions in dotted line boxes denote transactions that are only published if a party is uncooperative.