Can Bitcoin survive on fees alone after block subsidy dies?

[Satofan44]

So the answer to the question, even if you assume that yes this is profitable and it will rise upwards in the future, is this: We will implement measures that will make the attack so costly that it will be near impossible.

What kind of measures? Can you be more precise? Introduce them where? Bitcoin game theory relies on the presumption that the majority of the hashrate stays honest. There is no counter measure that can back the network up, if this theory fails.

You are talking about a very specific kind of attack, which is renting hashrate. This can be easily fought off with rudimentary measures such as increasing the coin maturity, making it extremely uneconomical to even try to do this as you would burn up resources before you are able to sell any Bitcoin to continue financing the attack.

There are always measures for other kinds of attacks or subattacks as well, the main reason we do not use them now is because they come with tradeoffs or changes:
1. You can implement some sort of finality mechanisms.
2. Any other kind of pending research ideas, I could look if you really wanted to but you should get the point by now.
3. You can completely dump the algorithm and render the attackers ineffective and in billions of losses in assets. Bitcoin mining machines are not useful for anything else. In the worst case this is what we would do. You must understand that pure technology can not win this battle. We can take the blows, and the chain continues running and even balances stay in tact. It is going to be chaotic, turbulent, but this is not something that can kill Bitcoin.
You must remember that there is no measure that solves problems for good, that is not how computer security works. It just makes them harder, more expensive, more difficult, or disables some particular cases. Do not expect a solution of a kind that is not possible for computers.

[athanred]

You can completely dump the algorithm and render the attackers ineffective

This is possible in theory, but it was historically proven to be unsuccessful in practice. Each altcoin, which stopped using SHA-256, even though nobody broke this hash function, ended up in a worse position. For example: some developers wanted to stick with "1 CPU = 1 vote" principle, and changed the mining algorithm each time, when GPUs or ASICs were built for it. And of course, such coin could work, and provide some level of security, but it would be much worse than Bitcoin. Meanwhile, altcoins, which maintained a fraction of BTCs hashrate, but stayed with SHA-256, were much more successful.

and in billions of losses in assets

I am not so sure about that. If there are many devices in use, which can mine a given coin, in a given way, then it will often find a group of people, which would do that. All new features and upgrades have to be backward-compatible, at least to some extent, otherwise they will be just altcoins. And many users can simply reject new version, and stay with the old one, as long as it is not fully broken. Which means, that if transactions can be processed, then many miners will keep mining even highly-centralized chains, as long as they will be worth some money. In practice, chains can die, if there are exactly zero users, otherwise they can be kept alive as long as needed.

Do not expect a solution of a kind that is not possible for computers.

Sidechains can provide additional revenue for miners, but decentralized ones were rejected, so we have only some centralized federations, like RSK or Liquid, which are still very far from reaching the full potential. Currently, Bitcoin is harder and harder to change, and soon, it can reach a point of being unchangeable, which is called as "ossification" by some people. And then, the only new changes will be completely outside of consensus rules, and will happen only in second layers and subnetworks, because nobody would successfully reach any consensus for changing the main layer anymore.

[d5000]

Sidechains can provide additional revenue for miners, but decentralized ones were rejected, so we have only some centralized federations, like RSK or Liquid,

While drivechains are indeed controversial, there are other quite decentralized models based on multisignature wallets. An example is Threshold Network's tBTC (not to be confused with testnet Bitcoin of course, they should really have chosen another name) which lives on existing blockchains like Ethereum but the federation is dynamic, everybody can participate. It is however not merge-mined with Bitcoin, it currently works with a PoS token.

From my understanding it would be possible to build a sidechain with a similar decentralized federation but with merge-mining, and then it would be possible to increase miner income with the subsidy. Why hasn't this been tried? I don't know but I assume it's simply more profitable to build a premined PoS token-based system, and the L2 boom has waned a bit also.

You are talking about a very specific kind of attack, which is renting hashrate. This can be easily fought off with rudimentary measures such as increasing the coin maturity, making it extremely uneconomical to even try to do this as you would burn up resources before you are able to sell any Bitcoin to continue financing the attack.

I believe the problem is that the attacker would build his economic profit model on the idea to short-sell Bitcoin. I think currently there would be too few Bitcoins available on lending platforms to make this attack profitable, and it would come with a lot of complexities (on lending platforms you have to hide your identity for example).

Regarding a finality measure, yes there could be an addition of PoS-voted checkpoints, which can be even added "after the fact", i.e. after the attack. It would however be fine if we didn't even come close to that.


Shower thought: Has adaptive block size already been discussed for that problem? I.e. one could determine an "ideal" percentage of block filling for fees to stay high, e.g. 90%. And then if the blocks of a difficulty period are significantly below that number, decrease the maximum block size for the next period by 1% and so on (i.e. very gradually, but eventually the blocks should become fuller again).

This would of course mean to think also about the effects of the fee level. For example, currently many Bitcoiners would still pay 5 sat/vByte without problems (I think the compllains started when in 2023/23 they went over 10 sat/vByte) and 5 sat/vByte with full blocks would still lead to significant fee income for miners. above all if Bitcoin rose again to 100k $+. And the fee level should be intimately tied to the percentage of the block space filled with transactions.

[athanred]

Why hasn't this been tried?

Because many people don't understand sidechains, and they think the system works differently, than it works in practice. For example: some people argue, that all full nodes will have to trace all sidechains. Or that all miners will have to mine all sidechains. Or some people worry, that all miners will try to steal all coins from all sidechains, and kill The Goose that Laid the Golden Eggs, instead of taking just fees, and letting them grow.

Also, it decreases the power, that developers have over Bitcoin. If anyone can just make a new sidechain, and ask miners to activate it, then anyone can change the code, and it is all about convincing users to try new features. If everything has to go through Bitcoin Core, then they decide, in which direction Bitcoin should go. But if anyone can make new changes, then the project goes into an unknown direction, and you can make any sidechains you want, including harmful ones, like "you are rewarded for each reorged block on chain X, and your coins comes from successful double-spends".

Another reason is that it competes with Lightning Network. If you have a sidechain, then you can send any funds anywhere, without worrying about liquidity, channel capacity, and other limitations like that. But in LN, everything has to touch the main layer, for every single user. Which also means, that when Core developers shifted their focus from sidechains into LN, then they basically stopped working on decentralized sidechains at all. And if someone can control centralized ones, and degrade the whole idea into that, then these people have no reason to support their competition, to allow someone else to run these centralized sidechains, which they created, or to allow random people to activate any kind of changes, without any control over it.

While drivechains are indeed controversial

Are they more controversial, than centralized ones? Are fully trusted sidechains better, than trusting the miners? What is more likely: that the sidechain creator, who has the same power over it, as signet creators have, will steal something, or that random miners will do the same thing? Existing centralized sidechains are like "just send me the coins, I will send them back correctly, I promise".

Anyway, if Bitcoin won't support decentralized sidechains, then altcoins will do that instead. Or: we will have only centralized ones, and they will work, until some sidechain operator will decide, that it is worth just signing a different message, and claiming all coins, and it will be compatible with all consensus rules.

It is however not merge-mined with Bitcoin

Yet another reason, why decentralized sidechains are not there: because people are afraid, that Merged Mining is bad, and it doesn't work for some reason. If done correctly, then it can work. But instead, we have a NameCoin, which made some mistakes, and anyone can just point at it, and say: "See? It doesn't work". Many altcoins were destroyed, because of poorly implemented Merged Mining, and now, a lot of people think, that it is a bad idea, because the same mining power can be redirected at something else, with no additional cost, and can be used to do some harmful things.

Has adaptive block size already been discussed for that problem?

There are BIPs for that, but they were unsuccessful: https://github.com/bitcoin/bips/blob/master/bip-0100.mediawiki

[Satofan44]

You can completely dump the algorithm and render the attackers ineffective

This is possible in theory, but it was historically proven to be unsuccessful in practice. Each altcoin, which stopped using SHA-256, even though nobody broke this hash function, ended up in a worse position. For example: some developers wanted to stick with "1 CPU = 1 vote" principle, and changed the mining algorithm each time, when GPUs or ASICs were built for it. And of course, such coin could work, and provide some level of security, but it would be much worse than Bitcoin. Meanwhile, altcoins, which maintained a fraction of BTCs hashrate, but stayed with SHA-256, were much more successful.

You are mistaking reasons for change in other coins and then using that as precedence. Historical changing of the algorithm has never occurred under the situation that I was describing. It would have to have happened to Bitcoin and under the same circumstance for us to be able to say that there is historical precedence for an outcome. To date there have been no such changes in Bitcoin, and definitely not under an attack scenario. We can't use the consensus in shitcoins as an example especially when those decisions were made because people thought they were "smarter" or because they are greedy, those are wishes/desires and not at all comparable to a situation where something must be done to protect Bitcoin.

and in billions of losses in assets

I am not so sure about that. If there are many devices in use, which can mine a given coin, in a given way, then it will often find a group of people, which would do that. All new features and upgrades have to be backward-compatible, at least to some extent, otherwise they will be just altcoins. And many users can simply reject new version, and stay with the old one, as long as it is not fully broken. Which means, that if transactions can be processed, then many miners will keep mining even highly-centralized chains, as long as they will be worth some money. In practice, chains can die, if there are exactly zero users, otherwise they can be kept alive as long as needed.

Why would users reject an upgrade that is saving Bitcoin from destruction? Your argument works in general, but not under the attack scenario. It is either embrace the change with massive losses inflicted to the miners or let Bitcoin die. Why would anyone with a working brain choose the second option?

Do not expect a solution of a kind that is not possible for computers.

Sidechains can provide additional revenue for miners, but decentralized ones were rejected, so we have only some centralized federations, like RSK or Liquid, which are still very far from reaching the full potential. Currently, Bitcoin is harder and harder to change, and soon, it can reach a point of being unchangeable, which is called as "ossification" by some people. And then, the only new changes will be completely outside of consensus rules, and will happen only in second layers and subnetworks, because nobody would successfully reach any consensus for changing the main layer anymore.

This is not good, while I admit that there is a risk of "ossification" it can not happen as there are many consensus cleanups to do. While developers may be hesitant to push for these changes individually or as a group for different reasons, we have to do it.

You are talking about a very specific kind of attack, which is renting hashrate. This can be easily fought off with rudimentary measures such as increasing the coin maturity, making it extremely uneconomical to even try to do this as you would burn up resources before you are able to sell any Bitcoin to continue financing the attack.

I believe the problem is that the attacker would build his economic profit model on the idea to short-sell Bitcoin. I think currently there would be too few Bitcoins available on lending platforms to make this attack profitable, and it would come with a lot of complexities (on lending platforms you have to hide your identity for example).

That is a good extension to the attack model, I do admit that I forget about that at times. However, at that point I would also bring up the legality of the attack. No regulated miner anywhere in the developed world can do this attack, they would be sued to the ground and shut down before anything can happen. It is questionable even if attacking Bitcoin by renting hashrate would even be feasible if the hashrate is located in the west, similarly how you can't rent out servers to run attacks on western companies (well you can, until you are stopped/caught). The attack vector is really only a possibility for nation states in practice, but the implications of that are more complicated for a topic on technical aspects. I will put just a small note. Depending on how well spread and integrated Bitcoin is in the US, any country even scheming to attack Bitcoin can be seen as a declaration of economic war -- and aside from superpowers, everyone can be crushed easily economically or militarily and the attack can be stopped (almost trivially in non-superpower cases). The chance that someone will attempt this is very low, the risks are too high and the reward too low.

Regarding a finality measure, yes there could be an addition of PoS-voted checkpoints, which can be even added "after the fact", i.e. after the attack. It would however be fine if we didn't even come close to that.

I am confident that we would get many innovative ideas and solutions should we reach a time where research focus has to be on this topic. Since the attack vector is slim, it is mostly being ignored.

Shower thought: Has adaptive block size already been discussed for that problem? I.e. one could determine an "ideal" percentage of block filling for fees to stay high, e.g. 90%. And then if the blocks of a difficulty period are significantly below that number, decrease the maximum block size for the next period by 1% and so on (i.e. very gradually, but eventually the blocks should become fuller again).

This would of course mean to think also about the effects of the fee level. For example, currently many Bitcoiners would still pay 5 sat/vByte without problems (I think the compllains started when in 2023/23 they went over 10 sat/vByte) and 5 sat/vByte with full blocks would still lead to significant fee income for miners. above all if Bitcoin rose again to 100k $+. And the fee level should be intimately tied to the percentage of the block space filled with transactions.

There are BIPs for that, but they were unsuccessful: https://github.com/bitcoin/bips/blob/master/bip-0100.mediawiki

This BIP is not the same thing. General adaptive block size =/= adaptive block size based on fees. Furthermore, the BIP was started by a scammer during a contentious time, of course it had no chance. AFAIK @d5000 it has not been discussed, at least not not in recent times. You can try Delving Bitcoin since I know you do not want to try to write a BIP yourself, perhaps you can get the attention of someone who is interested in pursuing the idea.

[BlackHatCoiner]

You are talking about a very specific kind of attack, which is renting hashrate. This can be easily fought off with rudimentary measures such as increasing the coin maturity, making it extremely uneconomical to even try to do this as you would burn up resources before you are able to sell any Bitcoin to continue financing the attack.

I don't believe this is an effective counter-measure at all.

• An attacker doesn't have to sell Bitcoin to finance a 51% attack. The 51% attacks that have occurred so far did not need from the attacker to sell his coinbase rewards. What you are describing makes sense in the scenario that the attacker has decided to run this attack for an indefinite period of time, and does not have enough capital in the first place.
• Coin maturity may prevent an attacker from spending the coins, but it does not prevent him from taking on debt using the non-mature coins as collateral. It is a definite collateral since the Bitcoin network owes those coins to the miner.

[philipma1957]

2010 satoshi said in 20 years which is 2030

Let's look

Note I rounded a bit.

2024 1,300,000 coins about 3.2 coins a block

2028.  650,000 coins. About 1.56 coin a block.   We need at least 150k a coin or more fees

?......?.............................................................................   satoshi 20 time pick


2032.  325,000 coins about 0.78 coins a block we need 300k a coin or more fees

2036.   162,000 coins about  0.39 coins a block we need 600k a coin or more fees

2040.     81,000 coins. About 0.195 coins a block we need 1.2m a coin or more fees.


Now some think miners quitting makes things  less secure some think it will be a disaster if miners quit as security will drop

Here is what I think if you are lucky you will live long enough to find out.

I will be 83 in 2040 I hope to see what happens at that 1/2ing

I pray God give you long life to witness 2040. Satoshi expected fee market to work by 2030 and not 2140. So the test start with 2-3 halvings and not with next generations as I put in my thread. Maybe we can see early warning if let say by 2036 fees can't replace 0.39 BTC subsidy, haspower will drop before 2140. One thing is certain if price doesn't reach that, either hashpower drops or fees must be painful for users.

This has also been discussed in here: https://bitcointalk.org/index.php?topic=5574940.msg66422758#msg66422758

My answer on the what level of security is sufficient question is this:

1. How do you determine what level of security is sufficient?

That's a great question. How about this?

As long as no attackers collectively have access to the infrastructure for ~half the hashrate, then any level of security is sufficient. The 51% attack is relevant when an attacker is capable of taking access to the miners. Historically, all altcoin 51% attacks have occurred either because the attacker rented enough hashrate or infected computers with malware to gain CPU/GPU hash power. There has never been a case where an attacker practiced 51% attack and had ownership of the infrastructure.

With this definition of security sufficiency, the risk of Bitcoin is to encourage miners to switch into renting their hashpower part-time. According to Mining Rig Rentals, around 50 EH/s are available to rent. That's roughly 4% of hashrate. Currently low risk, but what if this number goes upwards in the future?

Thank you. I searched the wrong way and miss that thread. I know 51% attack only matters if someone can actually gather half the hashpower. I'm still trying to connect your point about renting to the long term incentive problem.

To all gathering the hash power will be pretty easy. If the companies shrinking their hash rate do not destroy the gear.

we were at 155t we are at 125t diff

we dropped over 200eh in hash. 10 years of that and someone buying the gear cheap would give the 55% of the hash easy peasy.

granted say it is 1000eh of slightly old gear.

1000 ph = 1 eh

5 x s21 miners is 1 ph

so 3.5kwatts for 1 s21
35 kwatts for 10 s21
350kwatts for 100 s21
3.5mega watts for 1000 s21
17.5 mega watts for 5,000 s21 or 1 eh

17,500 mega watts for 1000 eh of s21

and of course 5 million s21 miners.

right now = way too hard to do.

but give mining shrinkage some time

and grow a few ai companies with big power

and I think we could see an attack on the network .

in 22 years or less time ie the 2048 1/2ing it should be ripe for attack.

2024 3.125
2028  1.5625
2032  0.78125
2036  0.390625
2040  0.1953125
2044  0.09765624     we run out of place holders
2048  0.048828125   we need to go to 10 digits not 8
2052  0.0244140625
2056  0.01220703125 we need to go to 12 digits not 10

I see a lot of unsolved issues above by 2036 to 2056.

No one talks about the 8 turning in 10 turning into 12 but it will need to be addressed.

the red zone is were we adapt or die with BTC.

the digit place holder issue has really meaning if BTC price grows.

No one even talks about that.


If btc is 1 dollar a satoshi
1 btc is 100 million dollars

by 2060 if 1 BTC is 100 million dollars 1 block would be 610351.5625   usd which if we do not have the 8 digit changed to 12 digit would have been rounded  lower.



So to started a 16 digit vs 8 digit should be done.

I would bet tons of people would argue that and that one is easy

ie

1.12345678                  8 digits
should be
1.1234567887654321  16 digits

we do that now and the problem is push out a long time

[Myleschetty]

Yes, Bitcoin is designed to eventually survive entirely on transaction fees, after all the total 21 million coins are mined, but it's a long-term metamorphosis with debate about how smoothly it will go because Bitcoin would have achieved sufficient global adoption and economic density in its block space during 2140 when all BTC will be fully mined.

[d5000]

Why hasn't this been tried?

Because many people don't understand sidechains, and they think the system works differently, than it works in practice. For example: some people argue, that all full nodes will have to trace all sidechains. Or that all miners will have to mine all sidechains. Or some people worry, that all miners will try to steal all coins from all sidechains, and kill The Goose that Laid the Golden Eggs, instead of taking just fees, and letting them grow

I agree with a lot of what you wrote but I was referring here to sidechain models that are already possible with the current Bitcoin Script capabilities.

Basically, I'd simply fork Threshold's tBTC model to an altcoin chain with EVM (it seems to be based largely on EVM-compatible smart contracts which operate on several PoS chains) but with consensus powered by a merged mined PoW algorithm. I think this is a relatviely low hanging fruit, and that's why I'll asking myself why that hasn't been done - and the answer for me was until now: because it's not profitable for the dev group, or less than a tBTC chain with PoS and premine. But maybe this is short-sighted. Perhaps the community could reach out to miners to support such a sidechain, if it could benefit them in the future.

BTW BIP 100 imo was more directed into the other direction: to extend the block size when blocks become "too full". I also don't like the concept of miners voting for the block size. The idea is to go explicitly into the other direction, and thus I was searching for discussions where such a model would be used to guarantee a certain fee level.

However, at that point I would also bring up the legality of the attack. No regulated miner anywhere in the developed world can do this attack, they would be sued to the ground and shut down before anything can happen.

I think you're correct if you're talking about a "destructive" attack, i.e. someone trying to reorg 100 or more blocks to "destroy" Bitcoin. That's very difficult to imagine and there would be definitely countermeasures.

But I'm a bit more concerned about small 51% attacks that could harm Bitcoin's reputation. Like the 16 block reorg (or so) that recently occurred on Litecoin due to an attacker exploiting a mining pool software vulnerability. A successful attack of this kind could cause a quite sizeable dip in Bitcoin (so if the attacker is short selling he'd probably get at least some recompensation). Such an attack gets easier if the security budget is low.

Perhaps the best countermeasure would be to have a countermeasure package ready to be deployed as a BIP. The first step could be a simple incentive mechanism like a fee market boost (adaptive block size, or alternatively a mandatory transaction fee like on altcoins like Peercoin), then another step changing the mining algorithm, and finally the "finality by PoS" idea, at least as an emergency mechanism of last resort. This would transmit some confidence to people even if somebody achieves a small reorg (16 blocks would already be a lot on BTC, but 16 LTC blocks are roughly equivalent to 4 BTC blocks).