Part 3 of this series examined whether the relatively technically simple idea of extending the inflationary block reward was worth pursuing. Having found it lacking, we turn to ideas requiring more serious reexamination of Bitcoin fundamentals.
Introduction
Boiled down to its simplest level, the security of the Bitcoin network depends upon the size of the monetary incentive offered to miners. If there is more money to be made mining blocks, more money will be invested into mining infrastructure, raising the cost for any one hostile entity to deploy their own infrastructure with the intent of subverting transactions or damaging the network. Previously we have examined several different proposals for how this block reward might be maintained following the end of the inflationary era: firstly, that voluntary fees might naturally pay for security, secondly, that large, self-interested parties might form contracts to maintain a secure network, thirdly, that altruistic individuals might chip in out of the goodness of their hearts. Finally, we examined the suggestion that the inflationary era simply be extended indefinitely. All of these proposals have been found likely to either a) completely fail or b) offer chronically unreliable or fundamentally unfair funding environments. In this post we examine two final funding proposals, each requiring more substantial intervention into the consensus rules of the Bitcoin network.
Blocksize limits to create transaction competition
One of the most popular current ideas on network funding stems from a decision by Satoshi to implement an arbitrary 1MB blocksize limit in the initial release of Bitcoin Core 0.1, motivated by a fear that spam transactions might kill the network in its infancy. While Satoshi never argued that Bitcoin ultimately needed a hard blocksize limit, this code tweak has taken on a life of its own for two reasons. Firstly, some believe that the network benefits from and may require a limit to prevent congestion and keep the costs of running nodes down. Secondly, some believe that a blocksize limit is the best way to generate an adequate block reward in the post-inflation era, which will create competition for block inclusion when transaction demand is high enough, driving users to bid for inclusion through transaction fees.
The first problem with this idea is its dependence upon transaction rate. At any transaction level below the limit, there would be zero competition for fees, and thus fees would immediately trend to zero. A second problem is that, if blocks were consistently full, transactions with uncompetitive bids would be abandoned rather than eventually included, meaning that such a system would actually give up potential funding, because these failed transactions would not contribute anything to the block reward, even though they were willing to contribute something.
What if the limit itself was designed to adjust responsively to maintain a desired payout? If the blocksize limit was exceeded, and the sum of fees rose above the desired block reward, the limit would be increased, allowing more transactions in at a lower bid price. Tellingly, the more a blocksize limit is designed to be responsive, the less it resembles a blocksize limit at all, and the more it comes to mimic the next proposal we will examine. This highlights the major problem with using a blocksize limit to sustain the block reward, its conceptual impurity. It is an attempt to manipulate one metric, transaction volume, to create a desired change on another largely unrelated metric, the block reward. It is a Rube-Goldberg solution to network funding.
Minimum fees
The simpler alternative is instead to attack the funding problem directly, by requiring a minimum fee for each transaction. This simple idea may be one of the strongest solutions available to the funding problem. As opposed to transaction fees being totally voluntary, a minimum fee for transactions would be implemented as part of the consensus code of Bitcoin, and thus all transactions in a block would need to satisfy the fee requirement for the block to validate and be accepted by the network.
How should the fee be assessed? The worst idea is a minimum overall fee per block, which would create problems building blocks with small numbers of transactions. The strongest implementation is probably a fee based on transaction size in kB. A fee based on the volume of a transaction’s inputs would fail to discriminate between users performing large transfers of value and users making small payments with large change addresses. Likewise, a fee levied simply per atomic transaction would discriminate against large numbers of transactions, and would likely encourage innovations in transaction bundling with the aim of subverting the fee regime. A fee based on transaction size would be more difficult to subvert, and would more fairly assess usage, given that, ceteris parabis, content-rich transactions (e.g. transactions consuming/creating more inputs/outputs for privacy or security reasons, advanced transaction logic and so forth) are likely to be of more value to their creators and recipients.
Conclusion
After examining a multitude of funding prospects, the most compelling candidate is a simple minimum transaction fee. Such a fee could fairly and evenly assess and exact contributions from all network users, in proportion to their usage of and value derived from the network. But if minimum transaction fees were to be implemented, how high would they need to be? Would a static fee hardcoded into the consensus library be best, or is something more flexible and organic possible? The next post in this series will examine methods for determining and setting fees to maintain an optimal level of network security.
