Good idea, Clayton. Interesting how/why Satoshi didn't think this would be a problem while designing the system. Or maybe he did?
First, the problem. After 21M Bitcoins have been mined, there will be no new blocks awarded. The blockchain will consist solely of distributed edits (appends) to the original 21 million blocks mined during Bitcoin's expansion-phase.
Just to clarify some language you used. Blocks are comprised of BTC transactions
and there's no limit for how many of them can be added to the blockchain. New BTC is what's currently awarded to the miners (not blocks).
Now, here's where the problem comes in. After the 21M blocks have been mined, the idea is that miners will "magically" start fighting over transaction fees instead of over finding new blocks.
Again, 21M blocks (of transactions) is not a limit. 21M BTC is.
But there is an inherent conflict between transaction fees and miner hashrate-race security - users want transaction fees to be as low as possible but the network security needs the hashrate to be high enough that no one actor can suddenly hijack the blockchain by swamping the network with overwhelming compute power (overwhelming hashrate). This means that the network cannot afford to have the hashrate "move up and down with the market", which is what tying the hashrate to transaction fees implies - lower network traffic means lower transaction fees means lower hashrate.
I don't get this. So if there were zero transactions -- like, everyone happy with their BTC right where they are -- for half an hour, then it would cost ZERO btc (or $, or computing power) to "take over" the blockchain? How would this happen, exactly?
But lower hashrate is just a security hole, it's just an opening to attack the network and hijack the blockchain (let's call this the "sleeping giant problem"). But if you price-fix the transaction-fees (to keep the hashrate race up), then the Bitcoin currency becomes a victim of the problems plaguing any price-fixing mechanism - surpluses and shortages caused by the currency's non-response to outside market forces (price fluctuations in other currencies and goods).
How are transaction fees calculated today? (They are non-zero, even though there's also new BTC being awarded to miners.)
My thought is to set up a lottery system that will "taper in" as the old block mining begins to taper out. The way it works is this. A lottery is held to select Bitcoin blocks at random to be swept into a pot. (There are protocols for multiple agents to generate random numbers in such a way that every agent can be certain that the numbers finally generated are, in fact, random.) The amount of Bitcoin swept from any one user is minuscule, far smaller than a typical transaction fee. Now, the miners are racing to win the pot. How to divvy up or pool the pot I am ignoring as implementation details, but it should be comparable to the currently-working system, i.e. hash-difficulty calibrated to maintain regularized block payouts (say, once every ten minutes), and so on. Adjustments to the pot size (that is, mining payout) are made on the basis of security considerations alone, without regard to fluctuations in demand for Bitcoin or even network transaction loads; if a new compute technology (say, Quantum Computing) is just starting to become viable, you crank up the mining payout to secure the network against the tail-risk that a sleeping giant tries to build a doomsday hashing farm to swamp the network and hijack the blockchain.
I think devaluing resting (non-transacted) BTC addresses like this would not be a good idea, and would defeat the advantages of limiting the BTC supply to 21M. As others noticed, you're simply replacing devaluation by inflation with devaluation by taxation. There surely are simpler and fairer ways to make the transactors pay for the cost of their transactions through fees. To me, this would be the only "ideal tax".
- You keep the same basic mining incentive structure that is currently in place, is well-understood and has been proven to work
- You do not "punish transactors" in order to "protect storers" - after all, both transactors and storers are demanding network security
How can a hijacker "steal" someone's stored BTC exactly?
- Network security does not hinge on demand for Bitcoin and does not fluctuate with transaction fees
Are you certain that security of the blockchain, as it currently is, hinges on a certain (required) volume of transactions (i.e. demand)?
I have to admit, I'm not fully convinced on the answers to the above questions myself.