Low- and post-subsidy network security

[casey]

As the block subsidy drops, the network security budget may be inadequate if a robust fee market fails to develop. Two forms of the problem are overall low fees, and adequate-but-bursty fees. (All credit is due to @psztorc for writing the post which made me start thinking about this stuff in the first place.)

The two big questions in my mind are:

• How big should the security budget be? In order to know whether intervention is necessary, and if so how much, we need to understand how big the security budget should be in order to keep the network operating smoothly.

• How can the security budget be raised? This could be some scheme that allows holders to coordinate to subsidize network security, some way of smoothing out fees between high-fee periods and low-fee periods,

These are economic, rather than the usual cryptographic problems, but I think they deserve serious consideration!

[LLFourn]

Hey @casey thanks for bringing this up. I think economic problems certainly fit here.

I was thinking about a problem along similar lines with a technical element added in: How could Bitcoin fall back to a "backup" consensus algorithm (via softfork) should we agree (via social consensus) that the main SHA256 PoW one has failed (i.e. persistence and/or liveness has been lost).

This is a very different framing to what you suggest as it is an optimistic strategy which assumes there is no way to figure out what the right budget is until an attack happens (but softens the blow when it does). Not sure which way the problem should be framed. It's possible that both questions need asking.

[VzxPLnHqr]

Hello @casey and @LLFourn, I would like to contribute to this research topic. Thinking about extremely long term aspects of bitcoin is something I find fascinating. Thank you for creating this repository!

Here are some general thoughts:

On a catastrophic break in PoW_sha256

How could Bitcoin fall back to a "backup" consensus algorithm (via softfork) should we agree (via social consensus) that the main SHA256 PoW one has failed

I think this hits the nail on the head. If we limit ourselves to a design space of softforks only, and we assume for purposes of analysis that SHA256 is broken such that it is no longer acceptable for PoW purposes (PoW_sha256), if any, then a possible direction be:

1. Because PoW_sha256 is broken, anybody could easily generate any PoW_sha256 items needed to build valid headers/blocks. Nodes which are unaware of the break in PoW_sha256 would not detect anything, and those node operators may not even be aware enough to look around. Can we send them a signal?
2. A possible signal could be via soft-fork (enforced by upgraded nodes and miners) which requires blocks to be empty in the sense that it would have no transactions other than perhaps the bare minimum coinbase transaction collecting subsidies necessary (if it is even necessary, since we are talking about far future where block subsidy has diminished to zero or nearly so ).
3. The coinbase input of this "empty block" could naturally contain a commitment to whatever the blockheader is for the new network/consensus moving forward. After enough time has passed and all nodes have upgraded, the network could essentially just prune off the old protocol, as strange as that perhaps sounds.

This mechanism is somewhat similar to extension blocks which were re-proposed back during the 2017 block size wars (I need to dig up a reference, but I think the concept originated in 2013). In some ways extension blocks, at least in my limited understanding, are better because non-upgraded nodes could at least still validate rewards & fees, and more importantly, their own transactions if they choose to not upgrade.

However, here we are talking about a catastrophic breakdown sha256, one of bitcoin's most fundamental primitives. So, as a shot in the dark, sending a "signal" to non-upgraded nodes, via basically a possibly multi-year chain of empty, but otherwise valid, blocks might cause them to investigate what is going on. As long as that chain of empty blocks is also the most worked chain (according to the now-broken PoW_sha256), then it will keep those nodes on the correct chain at least. So I suppose it depends how bad sha256 is actually broken.

Of course, there are a lot of downsides too. If sha256 is broken, then it may become trivial for attackers to trick old non-upgraded nodes onto a chain with more (broken) work than the chain of empty blocks which is enforced by the upgraded soft-forked nodes. However, if the upgraded nodes continue to act in good faith on behalf of the non-upgraded nodes, they might be able to stave off that attack, at least partially.

There are a lot of other things to think about which may make this idea not work.

Emulating the current miner rewards mechanism.

Lastly, and somewhat unrelated to the above, I have been thinking about how/if mining rewards could be faithfully emulated in a world where there is no longer a block subsidy, but only fees. I think, as a starting point, it is as simple as transactions including an output with the following script <T blocks> OP_CSV and choosing a T which is an acceptable security parameter to the transaction participants. Of course the output would also need to include an amount which is acceptable to miners, otherwise it may not be chosen for inclusion in a block.

In bitcoin today T is 100 (or is it 101? -- need to double check), but perhaps in bitcoin of the future it may need to be greater. I do not think T can be less than 100 without breaking current consensus rules since fees are part of coinbase outputs and are already locked for 100 blocks as-is -- hence why this construction is a step towards emulating existing rewards.

Maybe there are reasons to start transacting this way on bitcoin today? But one reason not to, is that it is not very space efficient. Yet, perhaps the fee output can also contain some sort of feature signal which could help with reaching consensus on other things per some of the current mailing list discussions about how users can participate more in the feature/upgrading/soft-forking process.

[LLFourn]

Hello @casey and @LLFourn, I would like to contribute to this research topic. Thinking about extremely long term aspects of bitcoin is something I find fascinating. Thank you for creating this repository!

Sweet. If you want to take charge of writing up the problem page that would be great.

I think this hits the nail on the head. If we limit ourselves to a design space of softforks only, and we assume for purposes of analysis that SHA256 is broken such that it is no longer acceptable for PoW purposes (PoW_sha256), if any, then a possible direction be:

We really need to separate two concerns here:

1. SHA256 is no longer collision resistant (consensus breaks because there are blocks with duplicate hashes)
2. There is a dishonest majority of hashing power (consensus and/or persistence or liveness breaks)

This issue is about (2) since it's about the economic incentives failing to generate an honest majority of hashing power but (1) could certainly have an issue too. Note that (2) might have a technical element to it (the malicious miners might have some magic ASICs that allow them to get more hash power at lower cost) but that it still a different problem to (1) and will likely have different solutions. In scenario (1) you'll need to do a very severe fork where you trash the consensus algorithm altogether. The existing miner's hardware will likely be made worthless. In scenario (2) you probably want to preserve the value of the honest minority's ASICs and continue to pay out rewards to the honest minority but to reach consensus in a different way (hopefully temporarily).

3. The coinbase input of this "empty block" could naturally contain a commitment to whatever the blockheader is for the new network/consensus moving forward. After enough time has passed and all nodes have upgraded, the network could essentially just prune off the old protocol, as strange as that perhaps sounds.

Softforks which create empty blocks in the view of older nodes are pretty spicy because they mean they cannot see the actual state of the ledger. Probably worth mentioning in the problem that having to use this is the worst possible category of solutions.

Lastly, and somewhat unrelated to the above, I have been thinking about how/if mining rewards could be faithfully emulated in a world where there is no longer a block subsidy, but only fees. I think, as a starting point, it is as simple as transactions including an output with the following script <T blocks> OP_CSV and choosing a T which is an acceptable security parameter to the transaction participants. Of course the output would also need to include an amount which is acceptable to miners, otherwise it may not be chosen for inclusion in a block.

I didn't get this. What's the goal here?

[VzxPLnHqr]

Sweet. If you want to take charge of writing up the problem page that would be great.

Ok, I will put together a pull request, or two rather since it is pretty much two different issues (technical primitives breaking down versus economic primitives/assumptions breaking down) as you suggested.

Softforks which create empty blocks in the view of older nodes are pretty spicy because they mean they cannot see the actual state of the ledger. Probably worth mentioning in the problem that having to use this is the worst possible category of solutions.

Agreed, though I am not quite sure I would go so far as saying worst-possible :-)

I didn't get this. What's the goal here?

Ah, yes, about the emulation of mining rewards. Apologies, I certainly did not motivate enough. I will try to do so now, but may still fail. In essence, when blocks are full on a regular basis, and we assume that miners essentially rationally try to maximize the (expected) present value (in sats) of their fees (let's exclude the block reward subsidy), right now that is a pretty simple calculation. Fees are locked for 100 blocks, which is a relatively short time period so the time value component is pretty much ignored. That 100 blocks is pretty much equivalent to "the present day."

However, perhaps one miner sees a transaction in its mempool which has a low regular fee (the difference between inputs and outputs), but one of the outputs is a really large amount that is spendable by whoever mines it, but only after, say, 10,000 blocks. So, it is essentially an extra fee. Yet, since that fee is not spendable right away, if the miner still chose to include it in the block, and by doing so forewent some other transactions with smaller fees but which are spendable sooner, then we actually have a possibly very convoluted, and costly, way to measure time preference. Or at least if there were a lot of such transactions like this so as to smooth out the effects of any single miner decision, we might be able to get an approximate measurement of time preference, or at least time preference among miners.

This is interesting (at least to me) because we are talking about a far future where we are concerned about whether there is enough PoW security available/committed to the future of bitcoin. If a signal like this is constructed and measured on a regular basis, then initially it might start out where miners are extra bullish. When a transaction with a huge "extra fee output" (orders of magnitude bigger than current fees, but locked for, say, 5 years), the miners might jump all over it and include that transaction over a couple others with modest present-day fees. However, if miners begin having concerns about the longevity of bitcoin, rationally they would includes shorter-duration transactions (if available) so they can still liquidate their rewards before it all implodes.

Of course right now pretty much all transactions available to miners for inclusion are short-duration transactions, so none of this is very helpful. Yet, if users constructing transactions become better at assessing their own time preferences, then some might choose to construct these types of transactions, and, similarly, if miners become better at assessing their own time preferences, some might choose to include these types of transactions. The net result is that we all would win because now the fees (if we count these "extra fee outputs" as fees) would not be homogeneous with respect to their lockup timeframes. Measuring and reporting on, for example, the median lockup time of such mining rewards might then become a meaningful signal. It would provide some real-time insight in a lowest-trust and distributed fashion into the time preferences of the network participants as a whole.

Sorry for the wall of text. Had to get it out of my head somehow! :-) In my mind I suppose this line of reasoning, to the extent it is even solid reasoning (doubtful!), is maybe useful as we discuss low/post-subsidy network security, so I wanted to at least throw it out there.

[VzxPLnHqr]

TL;DR: I wonder if we need to have a mechanism whereby a transaction creator can specify fees to be earned in a shrinking-pie fashion.

I have been thinking some more about the post-subsidy world of bitcoin and what it might look like. Based on some other conversations I have observed or participated in, there seems to be at least an implicit assumption that, in the long run, fees should be approximately uniformly distributed in time.

@LLFourn has pointed out elsewhere¹, that right now transactions themselves are not generally uniformly broadcast across time zones and days of the week. There is at least one proposal which efforts to keep the fee pressure more even².

Maybe spreading fee pressure out more evenly is a step in the right direction, but maybe it is also a step backwards. It is hard for me to tell right now. The reason is that right now the incentives of miners with respect to fees are all muddled up with those of the block subsidy. Currently the amount of the block subsidy is significantly larger than the amount earned as fees, so at least for now, it seems reasonable to assume that miner incentives are driven more by the subsidy.

One of the core properties of the subsidy mechanism which bitcoin has adopted (halving the subsidy every 210000 blocks) is that it creates a "shrinking pie." Even though the difficulty adjusts to minimize profits, the nominal size of the reward pie shrinks.

Now, as we think about a transition to a post-subsidy bitcoin world, it also means that the network is transitioning from a passive rewarding mechanism where the cost is shared pro-rata by all utxos to an active rewarding mechanism which is paid for by only some utxos (the ones being spent).

Of course we all hope that a robust fee market develops and none of this is really much of an issue. However, in an effort to ease the transition from active to passive, we may want to try to preserve as many of the other properties as possible. As such, I do wonder if we need to have a mechanism whereby spenders can setup the fees for their transactions to somehow be earned out over time in a shrinking-pie fashion? I am not sure if or how that is even possible right now in the protocol and without covenants, but it is something I have been thinking about a little and wanted to at least get it written down here for us.

Footnotes

1. https://github.com/bitcoin-problems/bitcoin-problems.github.io/pull/32#issuecomment-1152097510 ↩

2. https://scalingbitcoin.org/transcript/telaviv2019/elastic-block-caps ↩