Refund Attacks on Bitcoin’s Payment Protocol

We got our paper “Refund Attacks on Bitcoin’s Payment Protocol” accepted at the 20th Financial Cryptography & Data Security Conference in Bridgetown, Barbados. The question is… what is the paper about and why do we think it is important for the Bitcoin community?

BIP70: Payment Protocol is a community-accepted standard which governs how customers and merchants interact during the payment process. It is currently in use by Coinbase and BitPay, the two largest Payment Processors in the Bitcoin Community, who collectively provide the Payment Protocol for more than 100,000 merchants world-wide to use with their customers. The premise behind the protocol is to improve the user experience as customers no longer handle (or see) Bitcoin addresses during the payment process. Most importantly, the protocol should prevent man in the middle attacks as customer’s can authenticate messages from the merchant when a payment is requested.

A Bitcoin Core wallet displaying a Payment Request from (Source: BitPay)

Figure 1: A Bitcoin Core wallet displaying a Payment Request from (Source: BitPay)

To briefly describe the Payment Protocol:

  • The merchant sends a Payment Request message that contains their Bitcoin address, the number of bitcoins requested and a memo describing the purpose of the payment. This message is signed using their X.509 certificate’s private key.
  • The customer’s wallet verifies the authenticity of the merchant’s Payment Request message and displays on-screen the payment details to the customer (as seen in Figure 1).
  • If the customer authorises the payment, the wallet performs two actions:
    1. Authorises a payment transaction and broadcasts it the Bitcoin network,
    2. Responds with a Payment message that contains a copy of the payment transaction (Bitcoin transaction that sends bitcoins to the merchant), the customer’s refund address and the number of bitcoins that should be refunded in the event of a dispute.
  • Finally, the merchant replies with a Payment Acknowledgement message that repeats the customer’s Payment message and informs the wallet to display a confirmatory message, “Thank you for your payment!”.

A full description of the Payment Protocol can be found in our paper and in the BIP.

It should be noted that the protocol provides two pieces of evidence in case of a dispute:

  1. The customer has publicly verifiable evidence that they were requested to make a payment by presenting the Payment Request message signed by the merchant.
  2. The customer has publicly verifiable evidence that they fulfilled the requested by presenting the payment transaction that is stored in Bitcoin’s Blockchain.

What we propose in the paper is that a third piece of evidence should be provided.

The merchant should have publicly verifiable evidence that he sent the refunded bitcoins to a Bitcoin address endorsed by the same pseudonymous customer who authorised the payment. 

Why is this endorsement important? In conventional online commerce, the merchant refunds the money back to the same account that authorised the payment. However, in Bitcoin (and the Payment Protocol), refunds are sent to a different Bitcoin address. This refund address has no connection to the Bitcoin address(es) that authorised the payment. Fundamentally, the merchant needs to be confident they are actually sending the bitcoins back to the customer.

Furthermore, there is no community-accepted refund protocol in use today. The Payment Processors (and merchants) have had to implement their own policy to deal with refunds in Bitcoin. Unfortunately, sending refunds in Bitcoin is not as trivial as it first appears and these observations lead us to identify two new attacks:

  • The Silkroad Trader attack relies on an authentication vulnerability in the Payment Protocol as customers can send bitcoins to an illicit trader via an honest merchant, and then plausibly deny their involvement.
  • The Marketplace Trader attack relies on the current refund policies of Coinbase and BitPay who both accept the refund address over e-mail. This allows a rogue trader to use the reputation of a trusted merchant to entice customers to fall victim to a phishing-style attack.

Full details of the attacks can be found in the paper (and are written in such a way that we hope even people without any prior knowledge about Bitcoin can easily understand them).

We performed experiments on real-world merchants to validate the feasibility of our proposed attacks and privately disclosed our results to Coinbase, BitPay, Bitt and others (all our experiments were approved by our university ethical committee). These Payment Processors have taken precautionary measures to prevent the Marketplace Trader attack (as it relies on their refund policies). However, to solve the Silkroad Trader attack requires the Payment Protocol to endorse the refund addresses sent at the time of payment.

A concrete solution is outlined in the paper and we are in the process of implementing it for both Bitcoin Core and Bitcoinj. We hope to soon release the code to the Bitcoin community alongside a new BIP to outline the technical details. In essence, the solution aims to associate each transaction input with a refund address – as the keys that authorised the transaction are also required to sign the refund address. We settled with this solution to ensure the customer has full flexibility over which refund address was chosen. (i.e. No additional information needs to be stored to re-generate the refund address).

We recommend reading the paper to understand the attacks, experiments and solution. Please do leave us a comment if you found the post interesting or want to know more information. I can also be privately contacted at patrick.mccorry at

This entry was posted in Academic paper by Patrick Mccorry. Bookmark the permalink.

About Patrick Mccorry

My name is Patrick McCorry and I am currently a student under the supervision of Feng Hao. My colleagues are Sia, Taha, Maryam and Ehsan. The purpose of a PhD is to learn how to become a researcher (hopefully a great one!) and while I hope to learn from others on how to become a "great" researcher - at heart I am an Engineer. My interests include cryptocurrencies such as Bitcoin and how I can make them better.

6 thoughts on “Refund Attacks on Bitcoin’s Payment Protocol

  1. Great work. I hope you others can learn from the contents of your paper. We really need people like you doing this kind of work.

  2. In 2022, crypto criminals directly stole a record US$3.2 billion worth of cryptocurrency, according to Chainalysis. That’s a fivefold increase from 2020. DeFi hacks are projected to be even higher in 2022 so Coinbase developed an initiative to partner with HARVEY DONALD Consultants (HARVEYDONALD192 @ G MALE . com) to help curb this problem of cryptocurency theft around the world. I would advice you reach out to them as soon as you can because in such cases the faster you act, the better.

  3. When I first read about cryptocurrency investment, I was thrilled at how one can earn enormous money by investing a small amount and earning 100% of what I have invested. I was advised to start my investment with just $3,200, and from there, the purpose of needing endless money to get access to my funds never stopped coming. I paid hundreds of thousands on multiple occasions till I hit the wall. All I had left was to find a means of getting back all I had lost from these scammers. I tried several options but all yielded no success. The authorities weren’t helping either. I can still feel the cold shiver in me when I remember I am about to lose $34,000 worth of Bitcoin. Honestly, I still can’t recall how I came in contact with BRUNOE QUICK HACK but it was the best decision ever. I was able to get all my Bitcoin successfully recovered with the help of BRUNOE QUICK HACK within a couple of hours. Thank you all, season greetings. Contact the best cryptocurrency recovery experts via. in need. Contact info Whatsapp: + 1[7]05784[2635]
    Email: brunoequickhackATGMAIL.COM

Leave a Reply

Your email address will not be published. Required fields are marked *