Thursday, 29 September 2011

Bitcoin Transaction Mining

In the long-term (when all the bitcoins have been mined), the security of bitcoin comes from the revenues generated from transactions. How much revenue is that? Basically no one has any clue how many transactions there will be in ten or twenty years time, nor how much revenue will come from them.

But perhaps we can look at the real world for some kind of guidance. Visa has an annual revenue of $8 billion. Assuming that bitcoin will have to process transactions significantly cheaper - lets say 10% of the cost - to gain traction, that means an annual transaction revenue of around $80 million, assuming bitcoin grabs 10% market share from Visa.

The problem here is one of old-fashioned competition. Assuming there is no mining monopoly, miners mine independently of each other, and are free to charge whatever transaction fee they like, in the sense that they are free to include or exclude whatever (valid) transactions they like, irrespective of fee. Because incorporating an extra transaction into a block has zero (or close to zero) marginal cost, economically rational miners will choose to accept any and all transactions that have a non-zero fee. Miners that refuse low-fee transactions will make less money than miners who accept them and eventually will get squeezed out of the market. Note that the marginal cost of transactions is unrelated to how many hashes you had to do to solve the block - once you've solved a block you can add as many transactions as you like.

Effectively, competition will force the transaction fee down to the marginal cost of adding a transaction to a block. That cost is virtually zero (in fact the cost of bandwidth for sending the solved block to your peers), so fees become virtually zero. With super-low fees, you have insufficient revenue to secure the blockchain from attack.

Suppose then, that the miners 'unionize' and enforce a minimum average transaction fee. They could do this by collectively agreeing not to accept blocks that have fees less than the minimum agreed value. A miner whose block contains a transaction below the threshold would lose the fees from all the valid transactions as well, so it would be strongly in a miner's interest to only accept transactions above that fee threshold. However, a miner could then agree (off-network) to give a partial refund on all transactions. Superficially the transaction would appear to be valid, but the real net fee would be far smaller. They wouldn't be able to send the fee-discount back in bitcoins due to the minimum-fee rule, but presumably they would be able to use some other medium of transactions. For example, they could return some digital cash using Open-Transactions.

And this really leads to the big problem. Bitcoin will not be competing against Visa and Mastercard, Bitcoin will be competing against other digital currencies, including ones with no lower bound on the transaction cost. It will not be long before you can issue Bitcoins onto an Open Transactions Processor, which will be able to handle the transactions of an unlimited number of other currencies. Other currencies that do not require (comparatively) high transaction fees to pay for the (comparitively) high security costs of the issuance will be at an economic advantage and will undercut bitcoin. Why send money through raw BitCoin when you can send it over OT (either as bitcoin or as some other currency) and pay a hundredth of the charge? As a merchant, why install BitCoin technology which only supports BitCoin when you can install OT technology and support all digital currencies simultaneously and at no extra cost?

1 comment:

  1. "Note that the marginal cost of transactions is unrelated to how many hashes you had to do to solve the block - once you've solved a block you can add as many transactions as you like."

    Changing the block's txns, you change the bottom of the tree, which affects the top of the tree, which is in the header, which is hashed. The transactions are arranged into a tree and hashed the root of the hash tree is placed in the block header.