Author Archives: Patrick Mccorry

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.

Towards Bitcoin Payment Networks

Posted on by
17

The Newcastle University Bitcoin group was invited by the 21st Australasian Conference on Information Security and Privacy (ACISP 2016) to write a paper about Bitcoin security.

Instead, in collaboration with Malte Möser from the University of Münster, we decided to summarise an upcoming field in Bitcoin. We call this field `Bitcoin Payment Networks’ and we hope that our paper will inspire other researchers to think about how to construct payment channels, how bitcoins can be routed across two or more channels using an overlay payment network, and what potential regulation (if any) is required if anyone can participate in routing payments?

Now, I am sure you are thinking:

I thought Bitcoin already supported payments?

What is a payment channel?

And why do we need an overlay payment network for that matter?

Yes, Bitcoin is a peer to peer electronic cash system, and yes, Bitcoin already has a peer to peer network.

Unfortunately, Bitcoin as deployed today does not scale. The currency can support approximately 2-3 transactions per second and this is primarily due to an artificial cap of 1 MB blocks. Simply lifting the cap can alleviate the scalability problems in the short term, but recent research at the 3rd Bitcoin Workshop demonstrates that the underlying peer to peer network can only handle up to 27 tps. As well, lifting the cap and re-parameterizing Bitcoin is arguably just kicking the can down the road.

So how do we solve this problem? Research has focused in two directions:

  1. New types of Blockchain protocols such as GHOST and Bitcoin-NG,
  2. Facilitating Bitcoin transactions `off-chain’ and only using the Blockchain if an adjudicator is required.

In our paper, we focus on the second approach that requires a payment channel that facilitates bi-directional payments. These channels can be established when one or both parties deposit bitcoins into a multi-signature address controlled by both parties. Sending a payment then requires the authorisation of both parties, and essentially re-allocates the channel’s bitcoins to both parties. For example, if the channel has 1 BTC, then 0.5 BTC can be sent to Alice and 0.5 sent to Bob. If Alice sends 0.1 BTC to Bob, then the channel is updated to send 0.4 BTC to Alice, and 0.6 BTC to Bob. To close the channel, both parties can cooperate and settle using a single transaction, or when cooperation is not possible, either party can raise a dispute (requiring two or more transactions) on the Blockchain to settle the final balance.

Why are these channels useful?

  • The channel can be set up in such a way that the depositors are guaranteed to have their bitcoins returned if no payments occur,
  • The channel supports bidirectional activity and thousands of transactions can happen without the need to inform the Bitcoin network,
  • The channel prevents double-spending as each payment requires the authorization of the counterparty.

The prominent schemes proposed in the community are Duplex Micropayment Channels by Christian Decker and Roger Wattenhofer, and Lightning Channels by Joseph Poon and Thaddeus Dryja. We provide a comparison of both schemes to better understand their suitability for payment networks. Overall, we found that both schemes are primarily suited for different network topologies. Duplex is suited for a regulated hub-and-spoke model with highly reliable hubs, whereas Lightning is suited for a mesh network in which anyone can become a hub.

Now that we have a channel that can accept deposits from both parties and send bidirectional payments – what exactly is a payment network? A network consists of a set of channels, and allows two parties to find a route of channels that connects them. Then, both parties can send bi-directional payments across the network.

In the simplest case, Alice and Bob share a channel with Caroline (A->C, C->B), and Alice can send bitcoins to Bob using both of Caroline’s channels.

However, in the more interesting case, we can have more than one intermediary and still route payments:

Alice to Caroline, A->C

Caroline to Dave, C->D

Dave to Eugene, D->E

Eugene to Bob, E->B

Alice can send bitcoins to Bob via Caroline, Dave and Eugene. Most importantly, all routed bitcoins are sent without trusting any intermediary, and this relies upon the Hashed Time-Locked Contract (HTLC) technique proposed by Joseph Poon and Thaddeus Dryja for the Lightning Network.

In our paper, we detail how HTLC works for both Duplex Micropayment Channels and the Lightning Network. We highlight the potential limitations that HTLC imposes on the channels. For example, in Duplex Micropayment Channels, the routed bitcoins are potentially locked into the transfer for the channel’s entire lifetime, while in Lightning, the time allocated for the transfer determines how frequently each party must monitor the Blockchain for the remaining lifetime of their channel which is a potential burden for low-resourced participants.

One of the most important remaining challenges for payment networks is assessing the feasibility of different underlying topologies for the network. For instance, the community’s vision is that a mesh network will exist in which anyone can route bitcoins.

However, to achieve a mesh network, we need to decide how users can find payment routes on the network. Is there a gossip network for hubs to advertise their services? Do hubs reveal their channels (and leak their financial privacy) using Bitcoin’s blockchain? Are routing fees fixed or dynamic per route? Finally, are hubs on the mesh network considered money transmitters and need to be regulated? In the final section of our paper, we provide a brief discussion on some of these challenges.

We hope our blood, sweat and tears (yes blood, I somehow managed to cut myself while stapling a copy of the paper) will help both researchers and the community understand how cryptocurrencies can scale using payment networks. Furthermore, we hope to highlight that payment networks as a scaling solution can also potentially maintain the open-membership and self-enforcing properties that we have grown to love about Bitcoin.

Just in case, our paper can be found here. Also, just below you will find a selfie of the first two authors Patrick and Malte, alongside Rasheed from Bitt.com while attending Financial Cryptography 2016 this year.

Malte, Patrick and Rasheed

Malte, Patrick and Rasheed

Refund Attacks on Bitcoin’s Payment Protocol

Posted on by
6

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 BitPay.com (Source: BitPay)

Figure 1: A Bitcoin Core wallet displaying a Payment Request from BitPay.com (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 ncl.ac.uk.