Wednesday 21 September 2011

Bitcoin Confirmation Honeypot

Background

In a previous post I discussed long confirmation delays being a major obstacle to adoption, especially for bricks-and-mortar shops where the customer expects to walk away with his purchase immediately.

An interesting reply linked to a comment made by Satoshi on bitcointalk:
I believe it'll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less.
which then went on to discuss the technicalities. The obvious question this raises is then:
"If this is the case, then why do most big players in the bitcoin economy require multiple confirms?"
MtGOX asks for several hours, TradeHill estimates one hour, VirtEx requires 6 confirms, not sure how long BritCoin requires after their makeover but it used to be 6 confirms. Are they being unnecessarily cautious, or has the technology Satoshi refers to not arrived yet? If so, when can we expect that? These aren't rhetorical questions, I think a lot of people would really like to know if zero-confirm transactions can indeed be made relatively secure.

Other replies point out that since the existing credit card infrastructure allows chargebacks, and chargebacks can happen months after the initial transaction, bitcoin is still superior to CC. However, CC chargeback is a somewhat known quantity; CyberSource’s Annual Online Fraud Report claims that about 40% of retailers have a chargeback rate of 1% or more, according to this blog. This means that as a business you should expect your CC transactions to cost a percentage point more than your payment provider claims.  Annoying, but not something that's going to kill you. And since credit cards have been around for a while, it's unlikely to get orders-of-magnitude worse.

I view the confirmation characteristics as being a probability as a function of time. The longer you wait, the more certain you are of a valid transaction. In the case of credit cards you have to wait 2 months for a complete guarantee, whereas for bitcoin you might have to wait up to an hour based on what the big exchanges are telling us, although according to Satoshi it may be far less than an hour. The following diagram depicts the datapoints we have:

The blocks are known values, whereas the wiggly connecting lines are where we are missing data. The probabilities are normalised by a factor k, which is the unconditional probability of a transaction being bogus (which includes mundane factors like wrong PIN, insufficient funds etc as well as the probability of attempted fraud). It illustrates that bitcoin is clearly the better choice if you wait an hour, and that they are both equivalent if you wait 2 months. Which is better after 5s is the big unknown; we know that CC has about a 1% rejection rate after 5s but not much is known about the bitcoin rejection rate at that point.

The Honeypot

What I propose is that we setup a honeypot to find out more about the properties of the bitcoin validity curve in this region. It would work like a security honeypot - if you can have a transaction rejected after 5 seconds then you win a prize. Of course we want to know all the data-points, so we would have multiple prizes, one for each duration we're interested in. The process would work like this:

  1. Whitehat sends bounty to honeypot address.
  2. Honeypot waits 5s and sends the money back if transaction is still valid at this point.
  3. If whitehat manages to reverse his original payment, then he keeps his original bitcoins from 1. and also wins the bounty from 2. Otherwise, he just gets his money back from 2.
The website would display a table of what has been hacked so far and what the current bounties are, something like this (not sure what the actual bounties should be):
  
Or perhaps you could start all bounties off at 1 BTC, and then let each one grow daily until someone manages to hack them. That way you don't have to make decisions about the relative difficulties of different rejections, you just find out over time.

If someone builds this, I will fund bounties as a service to the bitcoin community.

4 comments:

  1. I think you are missing some important factors in your diagram. For one: transaction value. Given enough resources, you can mine a block, include a double spend but only broadcast the block after some time (Finney attack). Since you'd have to invest some serious hashing power and electricity the risk of this being done on a 0.01 BTC transaction is very low, whereas if you accept 10000 BTC it might be very high. Also there's a difference between accepting transactions automatically on a website or at a brick&mortar shop (you can't time the latter as accurately and you can't try it over and over again without consequences).

    The second thing I'd like to add is that there have been whole hours where there was no block found. Therefore 60 minutes might equate to zero block confirmations at some times. A much better metric would be blocks passed since the transaction.

    ReplyDelete
  2. The reason I use time as a metric rather than confirmations is that business-owners don't really care about confirmations, they only care about how long they have to wait.

    From what you say about block intervals, I guess that means that there is little chance of BTC ever being used directly in the real world (by directly I mean without bitcoin banks or escrow or whatnot), since it's not possible to guarantee even a single confirm within one hour. Is that correct?

    ReplyDelete
  3. It is very well possible for business-owners to accept BTC directly. For small transactions (eg. below 100 USD) accept them after a "listening period" (wait for signs of double-spends for maybe 5-10 seconds). For larger transactions you should wait for a few confirmations or use some additional technique to reduce the risk (ie. escrow, instawallet,...).

    Security is not a 0/1 thing. Just because you can show one instance where a Bitcoin transaction was reversed after one hour doesn't mean you should assume that every transaction will be reversed within that time. Every merchant has to build a personal risk model and create the according policies around it.

    I think its great that you want to help make Bitcoin more secure but you need to distinguish between the three possible classes of threats and model your proposed risk-assessment around them: broadcast conflicting transactions (easily remedied by a listening-period), the Finney-attack (mitigated by waiting for at least 2 confirmations) and the 51% attack (just learn to live with that one ;).

    Since the listening-period is trivial for everybody to apply (might even be included in a future client by default) and the 51% attack is highly unlikely, I think it would be most helpful to concentrate on techniques to mitigate the Finney attack.

    ReplyDelete
  4. Thanks for this information, I've been looking into Secure Payment Processing systems because I'm intending to start my own business.

    ReplyDelete