Here are some of my thoughts regarding the block size limit. I don't know all the technical issues, so I may have missed out some important stuff about orphan blocks, for example, but I hope a kind of market analysis might add to the debate from a different perspective.
In an efficient system, the price of transactions should converge towards the cost of processing those transactions.
For miners at the moment, the block reward covers their overheads in terms of hardware and electricity and so on. While there are relatively few transactions taking place, the cost of processing each transaction is negligible, or not worth calculating.
In the future, transaction fees will have to be covering both the cost of processing and also mining overheads as well. That means the most efficient miners will be those with the lowest total costs per transaction processed. In other words, they will be competing on bandwidth costs as well as electricity costs and hashing power.
So when transaction fees are making up a significant proportion of miner's income, the measure of a miner's efficiency might be something like transactions per second per dollar of costs instead of Mhash per dollar. Given the average rate of transactions on the network, a miner will be able to estimate the transaction fee per transaction in order to break even. Even if there were no block size limit, they could choose to reject all transactions offering a lower fee than their break even point.
An efficient miner will be able to process a larger number of transactions with a lower fee per transaction. This will bid down the average fee size. An inefficient miner will not be able to find enough transactions with a sufficient fee so they will drop out.
If the block size is limited, then miners lose out as well, because conceivably, transactions with a big enough fee to be profitable will have to be ignored, because it will take them over the block size limit.
Some of those points need further thinking, but the important thing is to work out how to calculate the cost per transaction. That changes the thinking from wanting fees to be simply as big as possible to wanting them to be at least above your break even point. Also, instead of worrying how to keep transactions scarce, you can see that bandwidth limitations make transactions scarce, and therefore higher priced on their own without needing an additional block size limit.
Hi Pteppic,
Thanks for your reply! While I disagree on some points, I appreciate the thoughtfulness.
As I see it, some mining costs are semi-fixed or sticky: hardware, scheduled maintenance etc.
Some mining costs vary, e.g.: electricity per block created.
That variable cost is essentially based on a bubble. It's a game of supply and demand, where a "limited resource" is being supplied by the protocol, and Bitcoin users 'demand' that resource.
The limited resource is a combination of two items: new coins, and block ledger space where transactions are signed.
(Ignoring the new coins for now), block space is like "bandwidth for SMS messages" -- there's a limited supply, and people find it useful so they're willing to pay in order to get some.
In the future, transaction fees will have to be covering both the cost of processing and also mining overheads as well. That means the most efficient miners will be those with the lowest total costs per transaction processed. In other words, they will be competing on bandwidth costs as well as electricity costs and hashing power.
True, but their aggregate costs are dictated by Bitcoin's popularity.
Let's say the markets are hitting $45 per BTC.
Discounting future investment and general betting, if a miner isn't breaking-even and getting at least $45-worth from their efforts, it's not worth doing. Thus the price regulates the "difficulty" of the hashing game, and since it's a competitive game it's no surprise that the system is constantly evolving. Inefficient miners get left behind, and the remaining competitors push the relative costs higher and higher until it's
barely worth doing.
An efficient miner will be able to process a larger number of transactions with a lower fee per transaction. This will bid down the average fee size. An inefficient miner will not be able to find enough transactions with a sufficient fee so they will drop out.
I like to think of block space as a precious item that the miners want to sell for as much money for as they can get. E.g.: prime water-front real estate. Thus, high bids get high priority, and vice versa. And
expensive requests (transactions with multiple I/O) also cost more. However, it's also a race against time because some other miner might also discover a block. Therefore only the bids that have already queued up are considered. If there's any unsold space at the end of the auction, some of the remaining space might be given away for free --
depending on the miner's politics. E.g.: one reason to reject free transactions could be to encourage users to "bid higher next time".
Let's look at 2 alternate scenarios:
1)
Block space is extremely abundant and there's always enough for everyone. Why pay? Even if 100 miners keep rejecting transaction requests to encourage users to cough-up higher bids, the 101st miner might sign all the 'free-loaders' regardless. Since the network difficulty must match the "resource reward" (made up of new coins and
winning bids), low rewards would tend to force the difficulty down.
2)
If block space is
too scarce, basically the opposite happens. Miners get rewarded with higher and higher bids... until Visa and Mastercard et al. start looking competitive again. Bitcoin doesn't operate in a vacuum so it should take its environment into account.
So how does one find the
right level of scarcity to maintain a multi-dimensional balance of:
D1: high network security
D2: 'optimum'(?) exchange rate
D3: competitive transaction costs
??
By a fixed algorithm? E.g.: the Bitcoin protocol automatically adjusts block size as well as difficulty.
Or by a human-influenced market? E.g.: miners competitively pull block-size up or down.
I think both options are likely to have flaws, and it seems like an extremely difficult problem to model. Since Bitcoin will likely always have external influences (competing currencies and payment systems), and those externalities may behave irrationally, I'm leaning towards allowing a human-controlled evolutionary algorithm for finding that balance.