Memory is Money is a sequence of posts on Core Economics describing the internals of the Bitcoin network. The intended audience are professional (academic) economists. Memory is Money is not a tutorial series on how to use Bitcoin, there are many excellent resources for this on the internet. It will be occasionally useful to describe certain aspects of the Bitcoin network with the aid of a user interface, for this I will use the open source Armory desktop application for managing personal Bitcoin funds. The data of all transactions in the network is publicly available, I’ll use the website blockchain.info when needed.
In this post I shall describe the basic aspects of the Bitcoin payment system, paying special attention to transaction fees. I recall attending a number of seminars by Joshua Gans, Stephen King, and Julian Wright about regulating interchange fees (for references see for example Joshua and Stephen’s papers). At the time there was significant interest in understand the economics of payment fees. The Australian Reserve Bank conducted an enquiry into interchange fees associated with credit cards and moved to regulate these fees. The Bitcoin payment system makes certain aspects of this redundant, as it is a payment system that does not require intermediation by MasterCard or Visa or Bankcard. It allows for bilateral payments directly from one Bitcoin account to another and such payments are registered by a decentralised network of competing Bitcoin accountants.
Introduction to the payment system
Bitcoin is a distributed network for recording Bitcoin denominated transactions between Bitcoin accounts. Transactions between Bitcoin accounts (addresses in wallets) do not rely on trusted third party mediation and are recorded by a network of competing accountants (miners) in a public ledger that contains a record of all transactions. There is only one way to transfer Bitcoins from one account to another, and that involves getting the distributed network of competing Bitcoin miners to record the transaction.
All transactions in the Bitcoin network are made between Bitcoin addresses in wallets (for this post, simply wallets). Wallets contain private and public information. The public information in a wallet is an address for receiving Bitcoins. It looks like this:
This particular address is the public address for donating to Wikileaks. Anyone who knows the public address in your wallet can send you Bitcoins. You don’t have to be online for this to happen, in fact you don’t have to do anything to receive Bitcoins. However, you do have to have an internet connection to know the balance of Bitcoins in your wallet. This is because your wallet does not contain the Bitcoins you own, that information is contained in the public record of Bitcoin transactions, which you need to access each time you want to check the quantity of Bitcoins you own.
The Bitcoin wallet also includes private information used for sending Bitcoins to other wallets. This information is secret to you. It is private information that is best kept offline. Some keep it in printed form in a safe, others on a USB that does not go into a computer with an internet connection. Many people these days keep the private component of their wallet in an online account held by a trusted third party (I’m not entirely familiar with this method or the trust issues associated with it). While you can keep an eye on your Bitcoin balance, and can receive Bitcoins, without accessing the private part of your wallet (indeed, without your full wallet being online), you need to use your private key to send Bitcoins to another wallet.
When sending Bitcoins, you are required to choose a non-negative transaction fee that you are willing to pay to the miner that records the transaction. Competing miners confirm your transaction and update the public record. This in-turn updates the balances in the sender’s and receiver’s wallets. Receivers do not pay a transaction fee.
It is possible at present to get your transactions confirmed without paying a positive transaction fee. When I began writing this Memory is Money post a transfer of around $140 million USD was made and confirmed in 33 minutes at no cost to the sender. That is, with a zero transaction fee. This information is publicly available (for example see here) and is shown in the next figure:
With a zero transaction fee you run the risk of delays in confirmation. Transactions with zero fees can remain unconfirmed, unless they meet certain priority requirements that are described below. Presently, it takes on average around 12 minutes for transactions to be confirmed, and there has been some sort of spike in average confirmation times since the US senate’s hearing on Bitcoins, see the next figure:
Miners and transaction fees in the Bitcoin payment system
With an eye on eventually developing a straightforward model for understanding Bitcoin transactions, here is how things work at present (I’ve eschewed certain details. In particular, those having to do with the heterogeneity of computer-memory size of transactions, these are not related to the economic size of the transaction, and I’m ignoring issues having to do with miner dispute resolution and the ways transaction fees are handled in the presence of disputes).
There is a large number of wallet owners. Each individual may own a number of wallets, which are generated at zero cost. The owner of wallet A wants to send Bitcoins to the owner of wallet B. The owner of wallet A is connected to the network. There is a large number of miners (accountants) all of whom are also connected to the network. The basic timeline for confirming a transaction is as follows:
- The software of the owner of address A announces to the network that a quantity of Bitcoins are sent from wallet address A to wallet address B with a non-negative transaction fee.
- The announcement is accepted into network memory pool if it satisfies certain minimal conditions.
- The memory pool contains many unconfirmed transactions. These are ordered according to a priority rule.
- A miner makes a list (according to a block creation rule) of unconfirmed transactions. This list has a size upper bound, so some unconfirmed transactions can be left out of the list.
- The competing miners try to solve a computational problem associated with their list (block).
- If the computational problem is solved, then the solution is confirmed by other miners and the transactions listed in the block by the successful miner are entered into the public record.
Turning to payoffs,
- If the transaction from address A to B was in the confirmed list of transactions, then the balances in addresses A (minus transaction fee) and B are adjusted. If the transaction is not confirmed within three days, it is usually cancelled by the sender’s software.
- The successful miner receives a reward of a) newly minted Bitcoins and b) the transaction fees in the new memory block that has been created. Unsuccessful miners get nothing.
- All miners that attempted to solve a computational problem pay a cost that depends on the technology that they use (e.g., electricity, hardware cost). Analytically, solving a computational problem is indistinguishable from a technology dependent probability distribution describing a probability of successfully completing a project in a contest setting. Indeed, the beauty of costly (seemingly useless) proof-of-work computational challenges is that they are a clever implementation of decentralised randomness (a nature node) in the mechanism.
The priority rule in step 3 above does not involve the transaction fee. If there are two transactions for x and y Bitcoins going from a single address to another single address and have been in the memory pool for time t1 and t2, respectively, then the first transaction is given greater priority than the second iff xt1 > yt2.
On the other hand, the current block creation rule of step 4 above involves the transaction fee in the following nonlinear way:
- There is a limit to the size of the block listing transactions to be confirmed by the miner, lets call this least-upper-bound M.
- If less than a threshold of around 0.06M is in the block, then include any transaction (according to priority) even those that have zero fees.
- For less than 0.5M accept all transactions that include a flat 0.0005 Bitcoin transaction fee.
- For the range 0.5M to M accept transactions with fees that increase exponentially with the size of the block.
Miners have began implementing their own fee rules. So envisage a situation, which may soon happen in the Bitcoin network, where the miners are principally motivated by the transaction fee. Over time, the reward of newly minted Bitcoins is set to diminish. If the Bitcoin exchange rate stabilises, then this may increase the focus of miners on transaction fees. In the extreme case where miners are exclusively rewarded through transaction fees, the overwhelming incentive will be to move away from the priority rules involving time, and simply prioritise transactions based on fees. A sender’s transaction fees in this situation buys her priority in the transaction-confirmation process. The basic idea in the Bitcoin transaction system is that there are too many miners for either regulation or collusion. So the situation in which prioritisation is based exclusively on transaction fees is in line with standard intuition about economic efficiency.
There are, however, informational problems associated with a decentralised mechanism in which fees reduce delays. There needs to be a parsimonious way to inform users about the delays that they can expect at each level of transaction fee. How will a person making a transaction know the price of expeditious confirmation? There is no centralised exchange here, no market maker announcing the priority bids and asks. Further, one cannot expect a rule that compels miners to truthfully announce their fees-rules: Why would a potentially anonymous miner do this? Why would a user believe this? I also don’t think that this is a problem that can be resolved in a hardwired way within the Bitcoin system. Transaction delays and the required fees to alleviate these delays is likely to emerge as a major issue for the Bitcoin payment system. The issue may, however, be mitigated by means of client-side third-party information aggregation software that provide realtime estimates of fees-to-delay schedules based on publicly available information regarding confirmed and importantly unconfirmed transactions.
My own expectation is that the Bitcoin payment system will increasingly be used for remittance. Indeed, I would not be surprised if the remittance activities of say Western Union will be fundamentally changed within a few years. This, however, cannot happen in the presence of uncertainty regarding transaction delays and the inability of users to reduce these using higher transaction fees.
There are ongoing discussions in the Bitcoin community about how to improve the use of transaction fees (see for example). Economists interested in payment systems can potentially make significant contributions to these discussions.