Refund attacks on Bitcoin’s Payment Protocol
Patrick McCorry, Siamak F. Shahandashti, Feng Hao
School of Computing Science, Newcastle University UK(patrick.mccorry, siamak.shahandashti, feng.hao)@ncl.ac.uk

Abstract. BIP70 is a community-accepted Payment Protocol standard
that governs how merchants and customers perform payments in Bitcoin. This standard is supported by most major wallets and the twodominant Payment Processors: Coinbase and BitPay, who collectively
provide the infrastructure for accepting Bitcoin as a form of payment to
100,000+ merchants. In this paper, we present new attacks on the Payment Protocol, which affect all BIP70 merchants. The Silkroad Trader
attack highlights an authentication vulnerability in the Payment Protocol while the Marketplace Trader attack exploits the refund policies
of existing Payment Processors. Both attacks have been experimentally
verified on real-life merchants using a modified Bitcoin wallet. They havealso been acknowledged by both Coinbase and Bitpay with temporary
mitigation measures put in place. However, to fully address the identified
issues will require revising the BIP70 standard. We present a concrete
proposal to revise BIP70 by providing the merchant with publicly verifiable evidence to prevent both attacks.

1

Introduction

Bitcoin [18], the world’s first successful crypto-currency, is increasingly becoming
a popular method of payment for e-commerce due to low transaction fees and theease of use supplied by third party payment processors. BitPay and Coinbase are
currently the two dominant payment processors that handle Bitcoin paymentson behalf of 100,000+ merchants. Their customers include Dell [25], Microsoft[6], Overstock, Shopify [24], Paypal [19] and CeX [26]. This demonstrates thatlarge organisations are placing trust in Bitcoin as a viable form of payment. In
fact, Overstock claimed to have made $3 million worth of Bitcoin sales in 2014[13]. These payment processors are attractive due to their ability to convert
bitcoins into fiat currency instantly which removes the risk involved in Bitcoin’s
price volatility on behalf of the merchant.
Both payment processors and all merchants are recommended to follow thecommunity accepted BIP70: Payment Protocol standard that was created by
Gavin Andersen and Mike Hearn [4]. The motivation for this protocol is to
reduce the complexity of Bitcoin payments as customers are no longer required
to handle Bitcoin addresses1 . Instead, the customer can verify the merchant’s
1

A form of identity (26-35 alphanumeric characters) that correlates to a public-private
key pair and is used to send/receive bitcoins.

identity using a human-readable name before authorising a payment. At the timeof a payment authorisation, the customer’s wallet will also send a refund Bitcoin
address to the merchant that should be used in the event of a future refund.
The Payment Protocol provides two pieces of evidence that can be used incase of a dispute with an arbitrator. The customer has evidence that they wererequested to authorise a payment if they keep a copy of the signed Payment Request message. This can be considered evidence as the customer could not haveproduced the signature without the co-operation of the merchant. The second
piece of evidence for both the customer and the merchant is the payment transaction as the payment is signed by the customer and time-stamped on Bitcoin’s
Blockchain, that is stored by most users of the network. In this paper, we argue that a third piece of evidence is required to authenticate the refund address
sent from the customer as the protocol recommends the customer’s payment andrefund addresses not be the same. This flexibility leads to the following attacks:– The Silkroad Trader attack relies on a vulnerability in the Payment Protocol
as the customer can authenticate that messages originate from the merchant,
but not vice-versa. This allows a customer to route payments to an illicit
trader via a merchant and then plausibly deny their own involvement.
– The Marketplace Trader attack focuses on the current refund policies of
Coinbase and BitPay who both accept the refund address over e-mail [28][10].
This allows a rogue trader to use the reputation of a trusted merchant toentice customers to fall victim to a phishing-style attack.
Without knowledge of our attacks, Andreas Schildbach asked the BitcoinDevelopment mailing list [23] why the refund address in the Payment Protocol
was currently unprotected and one of the original authors responded:
We talked about signing it with one of the keys that’s signing the Bitcoin transaction as well. But it seems like a bit overkill. Usually it’ll
be submitted over HTTPS or a (secured!) Bluetooth channel though sotampering with it should not be possible. - Mike Hearn [14]As seen above, a solution may involve the customer endorsing a refund address using one of the public keys that authorised the transaction. However, theauthor stated this solution was an overkill as the refund address is currently protected in an HTTPS communication channel. We demonstrate that the HTTPS
communication channel cannot protect the refund address as it only provides
one-way authentication, the customer can authenticate messages originated fromthe merchant, but not vice-versa. At first glance, the ‘overkill’ solution suggested
by Hearn could provide the evidence required for the merchant. Unfortunately,
this solution opens the door to another attack which allows a malicious co-signer
the sole authority to endorse the refund address used by the merchant and thus
steal the bitcoins of other co-signers. We will discuss this in detail in Section 5.
Contributions. Our contributions in this paper are summarised below:– We present new attacks on Bitcoin’s Payment Protocol and the current practice of both the Payment Processors,

Transac'on	  A	
  Input	
  Output	  Transac'on	  B	
  Input	
  Output	  Input	
  Output	  Script	  (Bitcoin	
  address),	  	
  Number	  of	
  bitcoins	
  Transac'on	
  A’s	
  iden'ﬁca'on	
  hash,	  	  Transac'on	
  A’s	
  output	
  index,	  	
  Script	  (signature	
  +	
  public	
  key)	
  Fig. 1. Information stored in the inputs and outputs of Bitcoin transactions– We present real-world experiments that demonstrate how merchants today
are vulnerable to both attacks using a modified Bitcoin wallet.
– We propose a solution that removes the incentive to perform both attacks
as the merchant is provided with publicly verifiable evidence whose origin
can be verified by an arbitrator.

2

BackgroundWe discuss background information about Bitcoin before presenting the community accepted Payment Protocol standard.
2.1

BitcoinWe discuss three concepts that are needed to understand Bitcoin’s Payment
Protocol. These include Bitcoin addresses that act as a form of identification,
Transactions that are used to send/receive bitcoins and the Blockchain that
stores all transactions on the network.
A Bitcoin address is a form of identification in the Bitcoin community thatis used to receive bitcoins and authorise payments. An address can be describedas the hash of an EC (Elliptic Curve) public key and the accompanying private
key is used to produce ECDSA (Elliptic Curve Digital Signature Algorithm)
signatures to authorise payments.
A Transaction consists of one or more inputs and one or more outputs asseen in Figure 1. Briefly, an input specifies the source of bitcoins being spent (theprevious transaction’s identification hash and an index to one of its output) andis accompanied with signature(s) and public key(s) of the sender to authorise thepayment. An output specifies the new owner’s Bitcoin address and the numberof bitcoins being sent. Strictly, these inputs and outputs are controlled usinga Forth-like scripting language to dictate the conditions required to claim thebitcoins. The dominant script today is the ‘pay-to-pubkey-hash’ which requires

a single signature from a Bitcoin address to authorise the payment. Recently,
the ‘pay-to-script-hash’ (multi-signature) approach is increasingly widely-used2
for escrow services and multi-factor authentication as it requires a threshold of
public keys (k of n keys) to authorise the payment.
The Blockchain is responsible for storing the entire network’s transaction
history with a relatively secure time-stamp [9]. This ledger is an append-only
data structure and is stored by most users of the network. To append newtransactions to this ledger requires a computationally difficult proof of work
puzzle to be solved. ‘Miners’ are responsible for solving this proof of work andare rewarded in bitcoins for appending a new ‘block’ of transactions to the ledger.
2.2

Payment Protocol

Andersen and Hearn proposed the Payment Protocol which has been accepted
as a standard in BIP70 [4] and is supported by several prominent wallets. The
goal of this protocol is described in the standard as the following:“This BIP describes a protocol for communication between a merchantand their customer, enabling both a better customer experience and better
security against man-in-the-middle attacks on the payment process.”
All communication is sent over HTTP/HTTPS except for the customer’s
payment transaction that is also distributed over the Bitcoin network. We assume
the merchant has an X.509 certificate - although using a certificate is considered
optional for the protocol. In practice, it is almost always used as it is necessary
to let the customer authenticate messages from the merchant.
Figure 2 outlines the messages exchanged and actions performed for the
protocol. To initiate, the customer clicks the ‘Pay Now’ button on the merchant’s
website to generate a Bitcoin URI. This URI opens the customer’s Bitcoin walletand downloads the Payment Request message from the merchant’s website. The
wallet verifies the digital signature for the message using the public key found in
the merchant’s X.509 certificate. A human-readable name for the merchant3 andthe number of requested bitcoins is displayed on-screen and the customer must
check this information before clicking ‘Send’. Upon authorisation, the wallet
performs two actions:
1. The customer’s payment transaction is distributed to the Bitcoin network.
2. The Payment message (payment transaction and a Bitcoin refund address)
is sent to the merchant’s website.
The merchant is responsible for detecting the payment transaction on the
network before responding with a Payment Acknowledgement message whichdisplays a confirmatory ‘Thank you’ message in the customer’s wallet. Finally,
the customer’s web browser is re-directed to a confirmation page to state that2
3

Currently 8.9% of all bitcoins are stored using the pay to script hash approach [1].
The ‘common name’ field from the X.509 certificate.

Fig. 2. Overview of the Payment Protocol [4]the payment has been received. For the rest of this paper, we focus on messages
sent over the HTTP/HTTPS communication channel as seen in Figure 2. The
content for each message is the following:– The Payment Request message contains a unique payment address M,
requested number of bitcoins B, creation time for request t1 , expiry time forrequest t2 , a memo message mM , a payment URL uM and some merchantspecific data to link any future payments zM . The contents of this message issigned using the private key xskM that corresponds to the merchant’s X.509
certificate public key such that σM = SxskM (M, B, t1 , t2 , mM , uM , zM ) where
S is the signature algorithm.
– The Payment message contains the payment transaction τC , a list of refund addresses (RC1 , ..., RCn ) and the number of bitcoins B that should berefunded to each address are listed in tuples such as ((RC1 , B1 ), ..., (RCn , Bn ))and a repeat of the merchant’s memo mM and merchant-specific data zM .
There is no restriction to the number of refund addresses sent to the merchantand the customer is responsible for deciding how the bitcoins are refundedamongst the refund addresses provided. Merchants expect one or more Payment messages until all requested bitcoins have been received.
– The Payment Acknowledgement message will be a repeat of the Payment
message sent from the customer.
As seen in Figure 2, the refund address sent in the Payment message is notdigitally signed by the customer and its integrity relies on the HTTPS communication channel established between the customer and the merchant to prevent
man in the middle attacks.This lack of mutual authentication in the Payment
Protocol and the refund policy of both Payment Processors to accept refund
addresses over e-mail has enabled the attacks outlined in the next section.

Customer
Click ‘Pay Now’

Merchant
Send Payment Request

Authorise?
Send Payment
Broadcast τCM, B, t1 , t2 , mM , uM , zM , σM←−−−−−−−−−−−−−−−−−−−−−τC , ((RC1 , B1 ), ..., (RCn , Bn )), mM , zM−−−−−−−−−−−−−−−−−−−−−−−−−−−−→
Send Payment
Acknowledgement

NotifiedτC , ((RC1 , B1 ), ..., (RCn , Bn )), mM , zM←−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Fig. 3. Message contents for the Payment Protocol

3

Attacking the Payment Protocol

In this section, we outline attacks which are feasible due to an authentication
vulnerability in the Payment Protocol and the refund policy of both Payment
Processors. Fundamentally, our attacks rely on the merchant’s inability to distinguish if the refund address originated from the same pseudonymous customerthat authorised the payment. As well, these attacks are successful even when all
messages are sent over an HTTPS communication channel.
3.1

Silkroad Trader Attack

This attack allows a customer to route payments to an illicit trader via anhonest merchant and then plausibly deny their own involvement in the refund
transaction. The main aspect for this attack relies on the customer’s ability toswap the refund address in their Payment message with a Bitcoin address under
the control of an illicit trader. Most importantly, the customer is not required
to endorse the illicit trader’s Bitcoin address with a digital signature.
Figure 4 is an outline of the Silkroad Trader attack. It begins with the customer visiting the website of an illicit trader. The customer downloads a Payment Request message for the desired ‘illicit goods’ they wish to purchase before
searching for a merchant who supports the Payment Protocol and is selling an
item approximately equal (or greater) in price. Once a merchant and item has
been found, the customer clicks ‘Pay now’ to start the payment process anddownloads a Payment Request message from the merchant’s website. To commence the attack, the customer’s wallet authorises the payment transaction τC
and inserts the illicit trader’s payment address T in the Payment message as therefund address (instead of their own refund address) and then sends the message
to the merchant.
The customer can request a refund to finish the attack once their Bitcoin
wallet has received the Payment Acknowledgement message alongside a confirmation e-mail from the merchant. Assuming the merchant follows the Payment

Messages sent over an HTTPS communication channel
Silkroad Trader
Customer
Merchant
Send Payment
RequestT, B, t1T , t2T ,mT , uT , zT , σT−−−−−−−−−−−→
Find Merchant
Click: Pay Now−−−−−−−−−−−→
Send Payment
RequestM, B, t1M , t2M ,mM , uM , zM , σM←−−−−−−−−−−−−
Authorise?
Broadcast τC
Send Payment
τC , (T, B), mM , zM−−−−−−−−−−−−−→
Detect τC
Send Payent
Acknowledgement
τC , (T, B), mM , zM←−−−−−−−−−−−−−
Cancel order
Refund request−−−−−−−−−−−→
Broadcast τM
Detect τM
Detect τM
Ships item
Fig. 4. Silkroad Trader attack allows a customer to route bitcoins to an illicit trader
via an honest merchant and then plausibly deny their involvement.

Protocol faithfully - the refunded bitcoins in τM are sent to the illicit trader’spayment address T. Also, the customer can detect the refund transaction (merchant sending bitcoins to the illicit trader) τM on the Bitcoin network before
contacting the illicit trader for an acknowledgement that the ‘illicit goods’ havebeen dispatched.
Ideally, if this attack happened in practice, the merchant could provide thePayment message as publicly verifiable evidence that the bitcoins were sent to
the refund address provided by the pseudonymous customer. Unfortunately, thecustomer may plausibly deny supplying the illicit trader’s payment address dueto their lack of endorsement, and hence claim that the merchant has forged themessage single-handedly.
3.2

Marketplace Trader attack

In practice, the policy of Coinbase and BitPay encourages customers to provide
refund addresses using an external method of communication such as e-mail[10][28] which ignores the refund address sent in the Payment Protocol. This

Merchant
Send Payment
RequestMessages sent over an HTTPS communication channel
Rogue Trader

M, B, t1M , t2M ,mM , uM , zM , σM−−−−−−−−−−−−→

Forward
Payment Request
M, B, t1M , t2M ,mM , uM , zM , σM−−−−−−−−−−−−→τC , ((RC1 , B1 ), ..., (RCn , Bn )), mM , zM←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Detect τC
Send Payment
Acknowledgement

Customer

Authorise?
Send Payment
Broadcast τC

Detect τCτC , ((RC1 , B1 ), ..., (RCn , Bn )), mM , zM−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→
Re-direct
customer
Fake
Confirmation Page−−−−−−−−−−−−−−→
Cancel order(T, B) sent
over e-mail←−−−−−−−−
Send RefundτM refund to T−−−−−−−−−−−→
Fig. 5. Marketplace Trader attack involves a rogue trader using the reputation of a‘trusted’ merchant to encourage customers to fall victim to a phishing-style attack.

deviation from the protocol is the basis of a new phishing style attack as a rogue
trader can use the reputation of a ‘trusted’ merchant to encourage potential
customers to purchase an item from their website.
Figure 5 outlines this attack. It begins with the rogue trader establishinga website that sells the latest products well below the market rate to attract
customers to their store. Most customers may be suspicious that the rogue trader
can offer these prices and may wisely think it is a scam. To encourage customers
to proceed with a purchase, the rogue trader can advertise that all payments aresent to a ‘trusted’ merchant such as Cex and there is little reason not to trust
them. When a customer proceeds to checkout on the rogue trader’s website andclicks ‘Pay now’, the rogue trader’s website can automatically fetch a Payment
Request message from the ‘trusted’ merchant’s website and forward this to thecustomer. The customer’s wallet opens the genuine Payment Request message

and displays a human-readable name for the ‘trusted’ merchant alongside thenumber of requested bitcoins. This can boost the customer’s confidence that therogue trader is legitimate as the payment is sent to the ‘trusted’ merchant.
Unfortunately, the customer falls victim to the attack upon authorising thepayment as they are unwittingly paying for a purchase on behalf of the rogue
trader to the ‘trusted’ merchant. The rogue trader can detect the payment4transaction on the Bitcoin network and re-direct the victim to a fake confirmation
page. The rogue trader can proceed to cancel the order and send a new refund
address over e-mail to the ‘trusted’ merchant. As the merchant’s policy is to use
an external method of communication to authenticate customers and deviatesfrom the Payment Protocol standard - then the refund address sent by the rogue
trader over e-mail should receive the bitcoins.
Furthermore, the customer cannot be aware this attack has occurred as theylack enough information to identify the refund transaction on the Bitcoin network. More importantly, this attack is deployable single-handedly by a rogue
trader and does not require the co-operation of a ‘trusted’ merchant. In fact,
the ‘trusted’ merchant may only become aware of this scam if contacted in the
future by the customer.

4

Real-world experiments

Our experiments aim to verify the current practice of processing refunds bymerchants, and assess the feasibility of the attacks. We purchased items fromreal-life merchants using a modified Bitcoin wallet before requesting for the order
to be cancelled and a refund processed. The attack is considered successful if therefunded bitcoins are received by the adversary’s wallet. The merchants usedduring these experiments are based in the UK and are supported by BitPayor Coinbase. The bitcoins used for the experiments are owned by the authors
and no money is sent to any illicit trader. All experiments have been ethnicallyapproved by our university ethical committee.
4.1

Proof of concept wallet

We have developed a wallet which supports the Payment Protocol and automates
the Silkroad Trader attack. We explain how our wallet works step-by-step:
1. The customer inserts the illicit trader’s Payment Request URI into the wallet
which stores both the request and Bitcoin address for later use.
2. The customer finds an item equal (or greater) in value as the ‘illicit goods’
and inserts the merchant’s Payment Request URI into their wallet.
3. The wallet provides a list of refund addresses that can be chosen for the
Payment message that is sent to the merchant and the customer can choose
the illicit trader’s Bitcoin address.
4. Assuming a refund has been authorised by the merchant - the wallet can
detect the merchant’s refund transaction on the network and include it in a
Payment message that is sent to the illicit trader.
4

Currently 50% of nodes on the network receive a new transaction within 5 seconds [2].

5. The wallet is notified by a Payment Acknowledgement message from theillicit trader that the payment has been received.
4.2

Simulation of attacks

We discuss our experience carrying out a simulation of both attacks against realworld merchants using arbitrary identities (i.e., random name, e-mail address,
telephone number, delivery/billing addresses created for experiments only). Onlye-mail is used to communicate with each merchant. Our results for the Silkroad
Trader attack are as follows:
Cex refunded the bitcoins within 3 hours of cancelling the order and used
the refund address from the Payment Protocol.
Pimoroni Ltd refunded the bitcoins within a single business day and used
the refund address from the Payment Protocol.
Scan refunded the bitcoins after 26 days and used the refund address fromthe Payment Protocol. The delay was due to Scan initially requesting us toprovide a refund address over e-mail, but we insisted using the one specified in
the original payment message.
Dell were unable to process the refund due to ‘technical difficulties’ and requested our bank details. We informed them that we did not own a bank accountand Dell suggested sending the refund as a cheque. While not the experiment’s
aim, this potentially opens Dell as an exchange for laundering tainted bitcoins.
To simulate the Marketplace Trader attacks we sent the refund address in an
e-mail to the merchants. Assuming the merchants accepted e-mail as a good formof authentication and ignored the refund address sent in the Payment Protocol,then the phishing-style attack we described earlier could happen in practice. Our
results were the following:
Something Geeky refunded the bitcoins within a single business day to arefund address sent over e-mail.
Girl meets dress refunded the bitcoins within 11 business days to a refund
address sent over e-mail. The delay was due to the merchant initially thinking
we paid using a bank transfer.
BitRoad refunded the bitcoins within a single business day to a refund
address sent over e-mail. In this experiment, we registered using a non-existinge-mail address and requested for the order to be cancelled using a variant of
the e-mail address. This demonstrates that even the registered e-mail address toinitiate the purchase is not being used to authenticate the customer.

5

Solution

We propose providing the merchant with publicly verifiable evidence that cancryptographically prove the refund address received during the protocol wasendorsed by the same pseudonymous customer who authorised the payment.
A solution proposed by Hearn [14] assumes the payment transaction is authorised by a single customer and recommends endorsing the refund addressusing any public key which authorised the transaction. However, it is not valid

Payment	
  Transac-on	
  Mallory’s	  	
  public	  key	
  and	  signature	
  Alice’s	  	
  public	  key	
  and	  signature	
  Input	
  Output	  Refund	  Transac-on	  Input	
  Output	  Mallory’s	  refund	  address	  Input	
  Fig. 6. The malicious co-signer attack allows a co-signer the sole authority to endorse
the refund address used by the merchant and thus steal the bitcoins of other co-signers

to assume that a transaction has been authorised by a single customer due to thenature of a Bitcoin transaction. If the adversary is responsible for sending the
Payment message to the merchant, then they have the sole authority to endorse
the refund address used by the merchant as seen in Figure 6.
Our proposed solution prevents this attack by requiring each public key that
authorised the transaction to also endorse its own refund address. In the eventof a refund the merchant sends the same (or less) number of bitcoins received5
from each transaction input to an associated refund address.
5.1

Proposed Solution

To achieve a signature solution requires changes to each message sent as partof the protocol. We outline these changes in Figure 7 and explore each message
separately before discussing their implications.
The Payment Request message considers the memo mM as a mandatory
parameter and should contain enough information for the customer(s) to beaware that this payment request is only for them, e.g. the registered e-mailaddress, delivery address, product information, etc. This memo field should also
include customer-specified instructions to provide evidence that the merchantfollowed any instructions provided by the customer. The payment address M
should be unique for each Payment request and like before, there should be norestriction on the number of times a customer can download the same Payment
Request to support paying from multiple devices or sharing with others.
The Payment message requires the customer to send the payment transaction τC to the merchant and is no longer responsible for broadcasting thetransaction to the Bitcoin network. More importantly, we propose associatingeach transaction input τC with a refund address and the merchant is expected
to verify an additional signature which endorses the refund address from eachpublic key that authorised the transaction input.
The refund address endorsement signature is σC = SskC (πC , RC , BC , Payment Request), where S is the signature algorithm, skC is the private key whichcorresponds to the public key that authorised the transaction input, πC is a concatenation of the elements that constitute the signed transaction input, RC is5

A transaction input does not record the number of bitcoins ‘sent’ and instead references an output from a previous transaction which specifies the bitcoins.

Messages sent over a secure HTTP communication channel
Customer
Merchant
Click ‘Pay Now’
Send Payment
M, B, t1 , t2 , mM , uM , zM , σM←−−−−−−−−−−−−−−−−−−−−−
Send Payment
τC , ((RC1 , BC1 , σC1 ), ..., (RCn , BCn , σCn )), mM , zM−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→
Broadcast τC
Send Payment
Acknowledgement
τC , (RC1 , BC1 , σC1 ), ..., (RCn , BCn , σCn ), mM , zM , σM←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Notified
Fig. 7. A single customer sends a payment to the merchantthe refund address, BC is the number of bitcoins to refund and Payment Request
is the signed message from the merchant. These parameters were chosen to clarify which transaction input is associated with the endorsed refund address andto ensure this endorsement is only valid for this Payment Request message. The
concatenated information πC is the data stored inside the transaction input andincludes: the previous transaction identification hash, an index for the output inthe referenced transaction and the script which contains a signature to authorise
the payment and its corresponding public key.
A new refund policy for the merchant is required as each transaction input is
responsible for endorsing a refund address. We propose the bitcoins associatedwith each refund address must be equal (or less) than the number of bitcoins
sent in the respective transaction input. The merchant must also check that the
total number of bitcoins associated with all refund addresses in this message isequal (or less) than the number of bitcoins he received in the payment transaction. These checks are necessary as the payment transaction can have additional
outputs for change and the merchant needs to ensure he does not refund more
bitcoins than he received from each transaction input. For example, if the transaction has a single input of 5 BTC (from the customer) and two outputs: 4 BTC(to the merchant) and 1 BTC (to the customer as change), then the merchantmust ensure the customer is only refunded 4 BTC (and not 5 BTC).
The message content sent to the merchant is outlined in Figure 7 and includes; a list of refund addresses alongside their associated endorsement signatures and the number of bitcoins to refund ((RC1 , BC1 , σC1 ), ..., (RCn , BCn , σCn )),the complete transaction τC , memo mM and some merchant specific-data zM .
The Payment Acknowledgement message is signed using the merchant’s
X.509 private key and repeats each field received in the customers Payment message. The signature is σM = SxskM (((RC1 , BC1 σC1 ), ..., (RCn , BCn , σCn )), τC , mM ,zM ) where S is the signature algorithm and xskM is the private key that corresponds to the merchant’s public key in their X.509 certificate.
We simplified the notation for σC to only show the case when the customer endorses a refund address using a single public key. However, if the multi-signatureapproach is used to authorise the transaction input, then the same k public keys
should also endorse the same refund address such that σC = (σ1 , ..., σk ). Eachcustomer with control of 1 of k keys can independently authorise the transaction
input and endorse the refund address. This pair is sent to the other co-signers
to be included in the Payment message.
5.2

Discussion

Our solution provides a proof of endorsement as the refund address received
by the merchant is signed using the same set of keys used to authorise thetransaction. This evidence removes the customer’s plausible deniability for theirinvolvement in the Silkroad Trader attack and provides an incentive for the merchant to use the refund address sent during the Payment Protocol which prevents
the Marketplace Trader attack. The merchant does not need to distinguish if thepayment has been split which preserves the customers privacy and prevents themalicious co-signer attack as co-signers can not endorse the refund addressesof others. These additional signatures are handled by the wallet on behalf of
the user. Also, no connection to the peer to peer network is required
for the customer as the merchant is responsible for broadcasting the paymenttransaction τC and this prepares the Payment Protocol to support off-chaintransactions such as the Lightning Network [20].
Payment Processors are expected to perform anti-money-laundering policies on behalf of their merchants [11] and the state of New York recently released Bitlicense [27] to outline regulation for Bitcoin businesses. Our solution
enhances the book-keeping required for this license as the signed Payment message is cryptographic evidence that the pseudonymous customer has endorsed
the transaction-related information required for auditing by investigators. We
improve the mandatory customer receipt which is currently a static web-page oran e-mail by using the Payment Acknowledgement message as a cryptographic
receipt as it is signed by the merchant’s X.509 private key. Similar cryptographic
evidence has been explored in the Bitcoin research community and two examples include; providing a warrant to hold a mixer accountable in the event of any
wrongdoing with Mixcoin/Blindcoin [8][29], and to provide a proof of solvency[12] that demonstrates the business is financially in good standing to customers.
Clustering techniques [5] can link a group of Bitcoin addresses to a single pseudonymous user. Meiklejohn et al [17] identified that 374.49 BTC stolen
from Betcoin in April 2012 and 4,588 BTC from the Bitcoinica theft in May 2012were sold at Bitcoin-24, Mt Gox, BTC-e, CampBX and Bitstamp. Also, Reidet al [21] tracked 25k stolen bitcoins and deduced LulSec’s involvement in thetheft. These analysis techniques using the Blockchain are currently supporting
criminal charges in the Silkroad Trial [3]. However, privacy-enhancing protocols
are actively [15][22][16] reducing the effectiveness of these analysis techniques.
Nevertheless, these techniques provide a platform for the Silkroad Trader attack
as independent observers may discover merchants sending bitcoins to an illicit
trader and then publicly release the ‘evidence’. Our solution provides the merchant with publicly verifiable evidence to demonstrate a customer’s deception.

Step Description
Time
Preparing Payment Message in the current protocol
1 Fetch refund address RC from the wallet’s key pool
95.29 ms
2 Update wallet’s address book with refund address RC
66.22 ms
Total:
161.51 ms
Our proposed changes for preparing the Payment Message
3 Confirm public key C in transaction input belongs to wallet
0.02 ms
4 Fetch the public key C’s corresponding private key skC
0.07 ms
5 Produce endorsement signature σC using the private key skC
0.41 ms
Total:
0.50 ms
Our proposed verification of the Payment Message
6 Verify the transaction input’s endorsement signature σC
0.62 ms
Table 1. Time performance for proposed changes to the Payment Protocol

5.3

Inherent issues due to Bitcoin

We outline four issues that are inherent due to Bitcoin that need to be considered
for our solution:
First, the proof of endorsement evidence can only authenticate pseudonymous customers as the Payment Protocol lacks the type of real-life identity
endorsement that comes with banks. While protecting an honest merchant, oursolution cannot prevent a malicious merchant simulating both attacks and insisting they were tricked.
Second, in a similar way to the original protocol, an observer of the Blockchain
may be able to link the payment and refund transactions using the denominations of bitcoins sent/received.
Third, customers can re-sign the transaction to change the identificationhash and broadcast it to the network. We recommend the merchant keeps a
copy of the payment transaction received in the Payment message as a re-signed
transaction cannot be used to verify the endorsement in the future.
Fourth, we assume merchants are running a full network node6 to participate
in the Payment Protocol. This is necessary as Simplified Payment Verification(SPV) wallets cannot verify transactions independently or calculate the numberof bitcoins to refund for each transaction input. However, customers can continue
to use SPV wallets for the Payment Protocol.
5.4

Solution performance

All tests are carried out on a MacBook Pro mid-2012 running OS X 10.9.1 with
2.3GHz Intel Core i7 and 16 GB DDR3 RAM. Time performance in Table 1 represents our modifications to the Payment Protocol implementation in the Bitcoin
Core client while utilising 1 core. Steps 1-2 represent the current Payment Protocol’s implementation for fetching a new refund address and storing this addressalongside the merchant’s name for future use. The total time for both steps is161.51 ms and is performed once as only one refund address is supplied as default in the Payment message. Our proposed changes for the customer’s wallet
6

A wallet that independently verifies transactions and stores the full Blockchain.

in Step 3-5 require 0.50 ms to check if the transaction input belongs to the user,
fetch the corresponding private key skC and produce the endorsement signature
σC for the Payment Message. On the other hand, the merchant’s wallet in Step
6 requires 0.62 ms to verify the transaction input’s endorsement signature. As
mentioned earlier, our solution must fetch the transaction outputs spent by thepayment transaction to check the number of bitcoins to refund for each transaction input. We exclude the fetching operation from Table 1 as this fetching isalready performed by the wallet to verify the transaction is valid.

6

Payment Processors Response

We privately disclosed our attacks to the Payment Processors and received thefollowing response:
BitPay acknowledged ‘the researchers have done their homework’ and that‘refunds are definitely a significant money laundering attack vector’. They are
now actively monitoring for refund activity on behalf of their merchants. Furthermore, after disclosing our results, BitPay released a new refund flow [7] thatrecommends using the refund address provided in the Payment Protocol rather
than the one supplied by email.
Coinbase acknowledged the ‘Silkroad Trader’ attack as a good example ofan authentication vulnerability in the Payment Protocol. To prevent the Marketplace Trader attack, Coinbase no longer provides merchants the API to change
the refund address if it has been supplied by the Payment Protocol. Also, they
have updated their user documentation to discourage merchants sending therefund using their own bitcoins to bypass the API changes.
Bitt is preparing to launch merchant services for the Caribbean and acknowledged both attacks. They believe the endorsement evidence may support
Payment Processors become more ‘airtight’ for future regulation.
These temporary mitigation measures help to address the Marketplace Trader
attack, but not the Silkroad Trader attack. To fully address the latter, the BIP70
standard would need to be revised, as we have discussed in Section 5.

7

Conclusion

This paper presented two attacks that leverage an authentication vulnerability
in Bitcoin’s Payment Protocol and the refund policies of the two largest payment processors: Coinbase and BitPay. We experimentally demonstrated both
attacks on real-life merchants using a proof of concept wallet before proposing asolution that provides the merchant with cryptographic evidence that the refund
address received during the Payment Protocol has been endorsed from the same
pseudonymous customer who authorised the transaction. Both Payment Processors have acknowledged our attacks and have implemented mitigation measures.

8

Acknowledgements

We would like to thank the original authors of the Payment Protocol; Mike Hearn
for his constructive feedback on our proposed solution and recommendation to
include customer-specified instructions in the digital signing and Gavin Andersen
for reviewing this paper and giving feedback.

References
1. Alcio. Monitor pay to script hash adoption. May 2015. http://p2sh.info/, Accessedon 2015-05-21.
2. S. T. Ali, P. McCorry, P. H.-J. Lee, and F. Hao. Zombiecoin: Powering nextgeneration botnets with bitcoin. In Bitcoin Workshop at Financial Cryptography
and Data Security. Springer, 2015.
3. I. Allison. Silk Road prosecutors talk about Bitcoin, Ripple and money laundering.
International Business Times, Aug. 2015. http://www.ibtimes.co.uk/silk-roadprosecutors-talk-about-bitcoin-ripple-money-laundering-1517414.
4. G. Andersen and M. Hearn. BIP 70: Payment Protocol. Bitcoin Improvement Process, July 2013.
https://github.com/bitcoin/bips/blob/master/bip0070.mediawiki, Accessed on 2015-01-15.
5. E. Androulaki, G. Karame, M. Roeschlin, T. Scherer, and S. Capkun. Evaluatinguser privacy in bitcoin. In Financial Cryptography and Data Security, pages 34–51.
Springer, 2013.
6. BBC.
Microsoft to accept payments made in bitcoins.
2015.
http://www.bbc.co.uk/news/technology-30377654, Accessed on 2015-02-26.
7. BitPay.
New Invoice Adjustment and Refund Flow.
Aug. 2015.
https://blog.bitpay.com/new-refund-flow/, Accessed on 2015-09-20.
8. J. Bonneau, A. Narayanan, A. Miller, J. Clark, J. A. Kroll, and E. W. Felten.
Mixcoin: Anonymity for bitcoin with accountable mixes. In Financial Cryptography
and Data Security, pages 486–504. Springer, 2014.
9. J. Clark and A. Essex. CommitCoin: Carbon Dating Commitments with Bitcoin.
In Financial Cryptography and Data Security, pages 390–398. Springer, 2012.
10. Coinbase.
How do I do a customer refund with the API?
May
2015. https://support.coinbase.com/customer/portal/articles/ 1521752-how-do-ido-a-customer-refund-with-the-api-, Accessed on 2015-05-15.
11. Fincen.
Request for Administrative Ruling on the Application of FinCENs Regulations to a Virtual Currency Payment System.
2015.
http://www.fincen.gov/news room/rp/rulings/pdf/FIN-2014-R012.pdf, Accessedon 2015-09-07.
12. G. Dagher and B. Bunz and J. Bonneau and J. Clarke and D. Boneah. Provisions:
Privacy-preserving Proofs of Solvency for Bitcoin Exchanges. In The 22nd ACM
Conference on Computer and Communications Security. 2015.
13. B. Geiger. Overstock.com offers its staff the option of being paid in Bitcoin.
2015. http://fortune.com/2015/01/09/overstock-com-offers-its-staff-the-option-ofbeing-paid-in-bitcoin/ Accessed on 2015-02-26.
14. M. Hearn. Re: [Bitcoin-development] BIP 70 refund field. Bitcoin-Development,
Mar. 2014. http://sourceforge.net/p/bitcoin/mailman/message/ 32157661/, Accessed on 2015-02-01.
15. G. Maxwell.
CoinJoin: Bitcoin privacy for the real world.
2013.
https://bitcointalk.org/index.php?topic=279249, Accessed on 2015-05-20.
16. S. Meiklejohn and C. Orlandi. Privacy-enhancing overlays in bitcoin. In Bitcoin
Workshop at Financial Cryptography and Data Security. Springer, 2015.
17. S. Meiklejohn, M. Pomarole, G. Jordan, K. Levchenko, D. McCoy, G. M. Voelker,
and S. Savage. A fistful of bitcoins: characterizing payments among men with nonames. In Proceedings of the 2013 conference on Internet measurement conference,
pages 127–140. ACM, 2013.

18. S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. November 2008.
https://bitcoin.org/bitcoin.pdf, Accessed on 2015-01-01.
19. J. Pagliery.
PayPal now lets shops accept Bitcoin.
2014.
http://money.cnn.com/2014/09/26/technology/paypal-bitcoin/, Accessed on
2015-02-26.
20. Y. Perez. Could the Bitcoin Lightning Network Solve Blockchain Scalability? 2015. http://www.coindesk.com/could-the-bitcoin-lightning-network-solveblockchain-scalability/, Accessed on 2015-05-15.
21. F. Reid and M. Harrigan. An analysis of anonymity in the bitcoin system. In
Privacy, security, risk and trust (passat), 2011 IEEE Third International Conference on and 2011 IEEE third international conference on social computing , pages
1318–1326, Oct 2011.
22. T. Ruffing, P. Moreno-Sanchez, and A. Kate. Coinshuffle: Practical decentralizedcoin mixing for bitcoin. In Computer Security-ESORICS 2014, pages 345–364.
Springer, 2014.
23. A. Schildbach.
Re: [Bitcoin-development] BIP 70 refund field.
BitcoinDevelopment, Mar. 2014. http://sourceforge.net/p/bitcoin/mailman/message/
32157651/, Acccessed on 2015-02-1.
24. J. Southurst. Shopify officially integrates bitcoin as a payment option for its
70,000+ merchants. 2013. http://www.coindesk.com/shopify-integrates-bitcoinpayments/, Accessed on 2015-02-26.
25. M. Sparkes.
Britons can now buy Dell computers with Bitcoin.
2015.
http://www.telegraph.co.uk/technology/news/11425250/ Britons-can-now-buyDell-computers-with-Bitcoin.html Accessed on 2015-02-26.
26. M. Sparkes.
CeX to adopt Bitcoin across the UK.
2015.
http://www.telegraph.co.uk/technology/news/11169814/ CeX-to-adopt-Bitcoinacross-the-UK.html Accessed on 2015-02-26.
27. N. Y. State. Chapter i regulations of the superintendent of financial services, part200. virtual currencies. Department of finance services, Feb. 2015.
28. M. Tur. Can BitPay refund my order? 2015. https://support.bitpay.com/hc/enus/articles/203411523-Can-BitPay-refund-my-order-, Accessed on 2015-04-07.
29. L. Valenta and B. Rowan. Blindcoin: Blinded, accountable mixes for bitcoin. In
Bitcoin Workshop at Financial Cryptography and Data Security, 2015.