Solving Selfish/Colluding Mining

[onelineproof]

As I understand, selfish mining is an attack where miners collude to
mine at a lower hashrate than with all miners working independently.
What are the current strategies used to prevent this and what are the
future plans?

One idea I have is to let the block reward get "modulated" according
to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
consisting of 144 blocks, h is the hashrate of the last 144 block (1
day) period, and r is the base subsidy (12.5 BTC currently). You can
then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
peak you get the full reward. Otherwise you get less, down to a min of
0.5 r.

If miners were to collude to mine at a lower than peak hashrate, then
they may be able to do it profitably for 144 blocks, but after that,
the reward would get modulated and it wouldn't be so much in their
interest to continue mining at the lower hashrate.

What flaws are there with this? I know it could be controversial due
to easier mining present for early miners, so maybe it would have to
be done in combination with a new more dynamic difficulty adjustment
algorithm. But I don't see how hashrate can continue rising
indefinitely, so a solution should be made for selfish mining.

Also when subsidies stop and a fee market is needed, I guess a portion
of the fees can be withheld for later if hashrate is not at peak.

Edit: There are 3 classes of attacks I'm worried about and my proposal currently is just to modulate the fees on a voluntary user basis

[1713898796]

1713898796

[1713898796]

1713898796

[ranochigo]

Selfish mining basically describes a miner withholding the blocks and delay the broadcast of the blocks. Its an attack that harms the other miners as they tend to waste time on block that would never be on the longest chain. The concept itself assumes specific conditions which might not hold in the real world and that attack is not the biggest problem. It seems to be different from what you are describing.

The network cannot know what the hashrate is at any point of time. The network approximates this based on the last 2016 blocks for the difficulty adjustment. It would be incredibly inaccurate if the sample size decreases as blocks could be found within seconds of each other. I doubt miners would collude to hash at a slower rate too; they are all after their individual profits and having a smaller difficulty means that it would be more profitable for someone else to mine. I can't see how they would coordinate in such a way that everyone benefits and those who are not participating won't interfere.

[HeRetiK]

As already described by ranochigo, selfish mining is about wasting other miner's resources by working on the longest chain in secret, causing competing miner's blocks to be orphaned upon broadcasting said blocks.

What would be the point of colluding to merely mine at a lower hashrate?

[butka]

The only thing where hashrate enters the story of selfish mining is when you ask yourself:

"What is the necessary hashrate that the selfish miner has to have in order to be successful?"

As already explained, selfish mining is temporary withholding of newly mined blocks.

When you selfish mine, you deviate from the default strategy to announce the new block immediately. All this in hope that you will find your second block faster than the rest of the network can find their first block. If you can do that, you have a huge advantage, because when the rest of the network finally finds their first block, you can announce your 2 blocks, effectively winning the race.

So you can imagine that you need huge hashrate on your side to be able to do that.

How big? Probably at least 50% of hashrate, which is why it was never observed in practice and possibly never will. BTW selfish mining can be easily detected by the increased number of orphaned blocks.

[HeRetiK]

[...]

How big? Probably at least 50% of hashrate, which is why it was never observed in practice and possibly never will. BTW selfish mining can be easily detected by the increased number of orphaned blocks.

With 50% of the hashrate you're not Selfish Mining anymore; you're effectively able to take over the network since you now can outrun the other miners indefinitely.

Selfish Mining only requires you to outrun your competitors, say, 2-3 blocks at a time. For that you don't need quite as much hashing power. By itself it's not really much of a threat though (apart from causing low-confirmation-count transactions to be unreliable); it's when used as part of a larger plot to either bankrupt your competitors or force them to collusion that Selfish Mining becomes dangerous.

[butka]

With 50% of the hashrate you're not Selfish Mining anymore; you're effectively able to take over the network since you now can outrun the other miners indefinitely.

I totally agree and that's why this kind of attack is not really a viable threat, because if you need 50% hashrate you can do whatever you like.

I found this realistic model of selfish mining (as opposed to hypothetical theoretical models):


Source: https://medium.com/@ProfFaustus/the-caner-that-is-the-selfish-mining-fallacy-ed65c20a6ce7

where we can see that the selfish miner revenue (orange line) surpasses the honest miner (blue line) revenue very close to 50 percent hashrate.

If that's so, no point even discussing this kind of attack.

[onelineproof]

I believe there are various attacks (not exactly the same) that result in a miner / miners causing the hashrate to drop, and since they get the same reward as with everyone mining at full hashrate, they are incentivized to do it.

Ya the typical idea of selfish miner, is you have "one" miner who has like 30-40% of the hashrate of the network and thus can mine a few blocks ahead of others and cause the others to give up mining because they keep getting orphaned. This lowers the total hashrate and gives these selfish miners more reward per block. If they keep mining at this low rate, and this gets detected and rewards get modulated downward, then there would be less of an incentive to do that. Maybe better actually if reward was exactly proportional to hashrate. So 40% hashrate means 40% reward. Also, it doesn't have to be one miner, it can be multiple miners colluding to do this attack.

Another possibility all miners (like 95%) agreeing to mine at a lower hashrate since that way they get the same reward per block at a lower energy cost. Isn't this the classical game theory strategy where the best long term solution is to work together to make things easier? It can also be non-voluntary and due to pressure such as governments increasing the cost of electricity, as is happening in Washington State right now. If all governments double electricity costs, wouldn't that in principle cause the potential hashrate to halve, and then suddenly the centralized governments use their extra capacity to carry out a quick 51% attack? With lower rewards for less than peak hashrate, there is incentive to keep pushing for the peak hashrate to make sure there is no "spare" hashrate just waiting to be deployed for a 51% attack.

Also, in the reddit post about this (https://www.reddit.com/r/Bitcoin/comments/7e04ov/why_has_there_been_no_selfish_mining_attack_on/) gmaxwell/nullc said an interesting thing:

Selfish mining costs you income now in exchange for lower difficulty in the future, if your relative share of the total network hashrate is falling it's easy to be in a situation where it would lose you money.

So if network hashrate keeps rising (share of selfish miner's hashrate is falling) then it is not profitable, but once we start seeing falling hashrate, it may become more realistic, so we should watch out.
Also Peter Todd said there are attacks more effective than selfish mining, but I am not sure what he's talking about.

@ranochigo says

The network cannot know what the hashrate is at any point of time. The network approximates this based on the last 2016 blocks for the difficulty adjustment. It would be incredibly inaccurate if the sample size decreases as blocks could be found within seconds of each other.

For every 144 blocks, you take the time of block 144 minus the time of block 0 (can use medianTimePast to protect against inaccurate timestamps). Add up the work for those blocks. Take the work divided by time. Then for the next 144 block period use that as the "current hashrate"

Actually, to be more conservative, I would recommend modulating only the miner fees and not the subsidies, and then slowly the reward will be dominated by fees, so there will be a slow transition with this effect. I need to think still of a way this could be done as a softfork, as that would be easier than a hard fork. For example you can set a rule that miners can only take fees * h / p from the fees (easy soft fork), with some standard rule for determining where to put the difference of fees and fees * h / p.

[DaCryptoRaccoon]

This is a very interesting topic, over the past few week I have notice many blocks with timestamps "Ahead" of time.
Seems to be only 3 pools that are broadcasting there block finds with timestamps "ahead" of time!

I captured a few screen shots and created a post asking about this  (it was swiftly removed!)

Now for the strange part..

I know that the code allows for time issues but what is this is a new type of attack that is being pushed at the network?
Seems only a few pools are doing this then they suddenly switch back to the correct time.

1. why would they change the timestamps for X-amount blocks then change back to the correct time.

So for a 2nd time..

Here are the screen shots.

https://imgur.com/a/bQgCyDE


Deleted post...

https://imgur.com/a/gIxtYY0

[onelineproof]

@MagicByt3 says:

This is a very interesting topic, over the past few week I have notice many blocks with timestamps "Ahead" of time.
Seems to be only 3 pools that are broadcasting there block finds with timestamps "ahead" of time!

A few seconds into the future is normal. Clocks aren't perfectly syncronized to the second and the Bitcoin Core software accepts blocks up to 2 hours in the future. Timestamp attacks are a different issue from selfish mining I believe, and there's various strategies. When you measure the time from block 0 to block 2016, you are just using 2 blocks to measure the time so if there are a few blocks with 2 hour in the future timestamps in between, they will get canceled out. There are also strategies (I don't think yet implemented by Bitcoin) to measure initial and final times (for purposes of difficulty adjustment) using "median time past" i.e. the median time of the past 11 blocks. This diffuses the effects of timestamp attackers even more.

[DaCryptoRaccoon]

http://seclists.org/fulldisclosure/2012/Feb/0

I revert to this OLD post regarding exploit that could have allowed something like this to occur.

A powerful attacker could definitely exploit this; timestamps in the future are rejected and Bitcoin won't generally accept a version of history in which time goes backwards, but otherwise a 51% attacker can choose whatever timestamps they like and can delay releasing their version of the chain to meet the "less than 10 seconds" requirement.  (note screenshots up to 45 sec)

It's a very expensive attack but far from impossible.

I cannot find where this change was made to allow timestamps in the future.  
But it was never allowed in the early versions of the software.

More funny commits i guess.

*edit*  https://github.com/bitcoin/bitcoin/commit/b14bd4df58171454c2aa580ffad94982943483f5

[HeRetiK]

Another possibility all miners (like 95%) agreeing to mine at a lower hashrate since that way they get the same reward per block at a lower energy cost. Isn't this the classical game theory strategy where the best long term solution is to work together to make things easier?

Cooperation is only a viable strategy if no one defects.

Looking at PoW, anyone who agrees to not increase their hashrate further will get fucked over by those that are either (a) not part of the agreement or (b) part of the agreement but decide to increase their hashrate covertly.

PoW, pretty much by design, does not reward cooperation. It rewards putting as much hashpower as possible on the network, especially as economics of scale kicks in. It rewards securing the blockchain instead of attacking it, by means of opportunity cost.

The optimal strategy gets a bit wonky in systems with increased block reward variance (eg. post-block-subsidy Bitcoin), but that's a different discussion altogether.

It can also be non-voluntary and due to pressure such as governments increasing the cost of electricity, as is happening in Washington State right now. If all governments double electricity costs, wouldn't that in principle cause the potential hashrate to halve, and then suddenly the centralized governments use their extra capacity to carry out a quick 51% attack?

Global markets don't work that way though. Price fixing barely works under totalitarian communism on a national scale, let alone within a capitalistic free market on an international scale.

Governments are barely able to figure out trade agreements. Fiat currencies fluctuate in relation to one another. Many -- if not most -- power plants are privately owned.

Even if 99% of governments would manage to arbitrarily increase electricity cost, the remaining 1% of governments would simply get rich by all the mining operations moving there.

With lower rewards for less than peak hashrate, there is incentive to keep pushing for the peak hashrate to make sure there is no "spare" hashrate just waiting to be deployed for a 51% attack.

Peak hashrate is being pushed as is, because keeping "spare" hashrate is simply wasted capital that could be put to work instead.

[onelineproof]

@HeReTiK you have good points, but it still doesn't show that these attacks are not possible, and what if suddenly we find ourselves operating at 50% the hashrate of peak hashrate of the year, what do we do? Wouldn't that be suspicious that not all miners are making use of their resources and there is some spare mining power ready to deploy an attack at any time. If your hypothesis is right that miners are always mining close to peak, then we wouldn't have to worry about the effects of such a protocol change because it would only take effect if hashpower is significantly less than peak. So I think it's worth an analysis.

My feeling is that without such a rule the pressures miners to stay at peak hashrate, they will get a bit lazy, use less of their energy on Bitcoin, and provide an opening for selfish mining or (33%) or 51% attacks. And it can take just one such attack to damage the reputation of bitcoin, and that would be a snowball effect that lowers the hashrate more (because of lower price) and makes more such attacks possible. Better to close those holes in my view, but I can post it to the list to see what others think.

[AdolfinWolf]

@HeReTiK you have good points, but it still doesn't show that these attacks are not possible, and what if suddenly we find ourselves operating at 50% the hashrate of peak hashrate of the year, what do we do?

Well, they obviously could be possible, but they won't be viable and probably extremely costly. The miners that didn't conspire will find themselves with a proportionally larger share of the network. = more profits. As stated above^ -- Which means that you'll need a 51% attack to cut them out to really have any efffect.

A 51% attack ( which would be needed to mine at a smaller cost with less energy consumption efficiently will probably also be significantly more difficult for the involved parties (As they removed 50% of their hashpower in this hypothesis. - Right?)) and doing so is basically burning your own fingers -- since the price of bitcoin will probably drop enormously if there were to be such an attack = reduction in profits. I doubt that the money which is spared in using less energy/electricity covers those losses.

I simply don't see how you could ever make a profit doing this when you have (bought) so much hashing power. (100.000's of Antminers). Unless you were somehow able to short bitcoin itself for billions.

Wouldn't that be suspicious that not all miners are making use of their resources and there is some spare mining power ready to deploy an attack at any time. If your hypothesis is right that miners are always mining close to peak, then we wouldn't have to worry about the effects of such a protocol change because it would only take effect if hashpower is significantly less than peak. So I think it's worth an analysis.

Unless the miners have already achieved 51% of the hashpower, i don't see any reason not to deploy all resources that could potentially mine at a profit?
Not doing so would definitely be 'weird'

My feeling is that without such a rule the pressures miners to stay at peak hashrate, they will get a bit lazy, use less of their energy on Bitcoin, and provide an opening for selfish mining or (33%) or 51% attacks. And it can take just one such attack to damage the reputation of bitcoin, and that would be a snowball effect that lowers the hashrate more (because of lower price) and makes more such attacks possible. Better to close those holes in my view, but I can post it to the list to see what others think.

Doing so would effectively destroy the eco system and thus their mining equipment in which some of them probably invested billions. This would be driven by malice, not by trying to make a profit.

[HeRetiK]

@HeReTiK you have good points, but it still doesn't show that these attacks are not possible, and what if suddenly we find ourselves operating at 50% the hashrate of peak hashrate of the year, what do we do? Wouldn't that be suspicious that not all miners are making use of their resources and there is some spare mining power ready to deploy an attack at any time. If your hypothesis is right that miners are always mining close to peak, then we wouldn't have to worry about the effects of such a protocol change because it would only take effect if hashpower is significantly less than peak. So I think it's worth an analysis.

Anyone willing to waste their resources on mounting a 51% attack on Bitcoin will do so regardless of whether we try to tweak the incentive structure in one way or another. Assuming such an adversary exists, selfish mining or covertly aggregating (unused) reserve hashing power would be the least of our worries.

It is also worth noting that covertly aggregating (unused) reserve hashing power would not even be the most effective strategy in this case. Given Moore's Law an adversary able to attain enough hashing power to successfully mount a 51% attack would want to do so as soon as possible, lest their hardware becomes obsolete before they even scratched the blockchain.

Either way it all breaks down to: If someone is able to gain Bitcoin's majority hashrate and is willing to attack it, Bitcoin's fucked. But that's neither something new, nor something that can be easily fixed with currency issuance tweaks.

My feeling is that without such a rule the pressures miners to stay at peak hashrate, they will get a bit lazy, use less of their energy on Bitcoin, and provide an opening for selfish mining or (33%) or 51% attacks. And it can take just one such attack to damage the reputation of bitcoin, and that would be a snowball effect that lowers the hashrate more (because of lower price) and makes more such attacks possible. Better to close those holes in my view, but I can post it to the list to see what others think.

Obviously one possible outcome is the one you describe -- miners try to keep the hashrate at current levels or above.

Another imaginable outcome however would be a negative feedback loop, with miners either leaving Bitcoin for a competing blockchain or being taken offline as profitability plummets.

With the current system, as soon as Bitcoin becomes less profitable to mine, miners drop off and difficulty is reduced, with the hashrate finding a new equilibrium. If the mining reward is reduced with a drop in difficulty, Bitcoin becomes even less profitable to mine, with more and more miners leaving as block reward is further and further dynamically reduced, creating the very pool of "spare" hashing power that the difficulty-dependent-block-reward is trying to avert.

From what we've seen so far, miners already have the implicit incentive to keep adding hashrate. Adding complexity to a system that works just as good, if not better, with simpler rules, rarely works out well. Especially if it depends on miners working together for the common good (ie. "let's keep the hashrate growing or else the block reward gets reduced") rather than doing what is most profitable for them.

[TeamBitmark]

..... what if suddenly we find ourselves operating at 50% the hashrate of peak hashrate of the year, what do we do? Wouldn't that be suspicious that not all miners are making use of their resources and there is some spare mining power ready to deploy an attack at any time....

An air-burst EMP weapon could neutralize all electronics in a large area, say the size of the continental United States or China.
What kind of effect would the gutting of a large part of the planet's networking and hashing infrastructure have on hash rate ?
Of course what would be left would be a fraction of the recent peak.   This could happen, it's  possible (although we want to think, also improbable). And it would have nothing at all to do with miner collusion or game theory.

[ranochigo]

An air-burst EMP weapon could neutralize all electronics in a large area, say the size of the continental United States or China.
What kind of effect would the gutting of a large part of the planet's networking and hashing infrastructure have on hash rate ?
Of course what would be left would be a fraction of the recent peak.   This could happen, it's  possible (although we want to think, also improbable). And it would have nothing at all to do with miner collusion or game theory.

Possibly more than half of the hashrate would be gone. Anyhow, I honestly doubt the others would have enough resources to outpace the remaining network. There are only that many ASIC machines and I doubt any other entity would possess that much machines without using it at all, the sheer cost of it would be astounding. The block interval is likely to be twice as long without any further attacks. It would surely drive people off of Bitcoin.

But the more important question is; Why would you care about Bitcoin when literally everything that is electronic has been taken out? Bitcoin should be least of your worries when the infrastructure of your country is wiped clean

[onelineproof]

@Heretic says:

Anyone willing to waste their resources on mounting a 51% attack on Bitcoin will do so regardless of whether we try to tweak the incentive structure in one way or another. Assuming such an adversary exists, selfish mining or covertly aggregating (unused) reserve hashing power would be the least of our worries.

Yes of course attackers don't care so much about the value provided by the block rewards, though they do to some degree, and if miners who do care are incentivized to work at peak, the effect of an attack will be smaller. It's like putting shock absorbers on a car. You may hit a rock, but with shock absorbers it will be smoother.

@Heretic says:

Another imaginable outcome however would be a negative feedback loop, with miners either leaving Bitcoin for a competing blockchain or being taken offline as profitability plummets.
With the current system, as soon as Bitcoin becomes less profitable to mine, miners drop off and difficulty is reduced, with the hashrate finding a new equilibrium. If the mining reward is reduced with a drop in difficulty, Bitcoin becomes even less profitable to mine, with more and more miners leaving as block reward is further and further dynamically reduced, creating the very pool of "spare" hashing power that the difficulty-dependent-block-reward is trying to avert.

That's where merge mining (another shock absorber) would be useful in my opinion, but we can save that for another thread

Look, we just had a sudden 35% increase in hashpower recently (from what I read in the news), that's enough for a selfish mining attack, so to trust in the decentralization of Bitcoin mining is a bit of a shaky argument I believe, and I don't think what I am suggesting is urgent, but should carefully and smoothly rolled in, without much complication.

There have been other core developers also concerned with the decentralization of mining, and even planning for a PoW change in case a 51% attack happens. I think other technologies like sidechains and merge mining will strengthen decentralization and hashpower attack prevention in the future also.

@ranochigo says

Possibly more than half of the hashrate would be gone. Anyhow, I honestly doubt the others would have enough resources to outpace the remaining network. There are only that many ASIC machines and I doubt any other entity would possess that much machines without using it at all, the sheer cost of it would be astounding. The block interval is likely to be twice as long without any further attacks. It would surely drive people off of Bitcoin.

But the more important question is; Why would you care about Bitcoin when literally everything that is electronic has been taken out? Bitcoin should be least of your worries when the infrastructure of your country is wiped clean

EMP attacks are attacks that are protected with physical security protocols, not Bitcoin, which is a software protocol. I also suggested a one year period for measuring the peak hashrate to allow for time to adjust to changing environmental conditions. The user @TeamBitmark is a troll from another thread I participated in so I will not directly answer him, unless someone echoes his question.

[TeamBitmark]

But the more important question is; Why would you care about Bitcoin when literally everything that is electronic has been taken out? Bitcoin should be least of your worries when the infrastructure of your country is wiped clean

This is very true. The situation in that hemisphere would be dire, and reverting, at least in the short term, to a very primitive level.

However, remember that bitcoin is a global network, and barring complete annihilation of all electronics worldwide, and electronics manufacturing facilities, the internet would return again to the areas where it was wiped.   

A more interesting question for the remaining part of the network is just how badly the hash rate was affected, and how long it would take of the 10 minute average block time take to be re-established.   It might be wise for bitcoin to adopt one of the more sophisticated diffalgos which were developed for alt coins  suffering from wild hash-rate swings for this reason: the unexpected disappearance of substantial hash rate. Unlikely, yes, but impossible, no.

[onelineproof]

@Heretic says:

If the mining reward is reduced with a drop in difficulty, Bitcoin becomes even less profitable to mine, with more and more miners leaving as block reward is further and further dynamically reduced, creating the very pool of "spare" hashing power that the difficulty-dependent-block-reward is trying to avert.

I want to revist this scenario, assuming no merge mining. First, I think a price drop will be slightly offset by the lower rate of coins being mined. Also, confirmation times will get longer: Both the time to get a block will increase and the number of confirmations needed to have enough work done on the chain so that your transaction is considered safe. The fees would likely rise and this would increase rewards to miners, especially in a fee-market dominated future. It would be nice to write this up in terms of mathematical equations to see exactly what would happen.

Anyway, I am proposing just to modulate the fees (not the fixed subsidy). I think a good way would be to let users choose how their fees are used. If a user wants, they can say: "I am paying f h/p to the miner", where f is the nominal fee, h the hashrate of the past period (current hashrate), p the peak hashrate. So the miner who mines the block with that transaction will only get f h/p, and f-fh/p will be kept in reserve and can slowly be released to miners as the hashrate approaches the peak. For example, if once the current 144 block period is over, it is calculated that h2 > h, then h2/p-h/p will be released to miners who mine the blocks in the next period (perhaps spread evenly over that period). Like this each user can choose more precisely how they want their fees spent, and it makes sense that they would care about the security provided by blocks coming after the transaction they make, instead of just caring about the immediate block they get their transaction on.

Can this sort of thing be done easily with a soft fork or some kind of smart contract between users and miners? I don't know, I am thinking about it.

@Heretic says:

Anyone willing to waste their resources on mounting a 51% attack on Bitcoin will do so regardless of whether we try to tweak the incentive structure in one way or another. Assuming such an adversary exists, selfish mining or covertly aggregating (unused) reserve hashing power would be the least of our worries.

Also revisiting this...I think I should add another category of attacks that I am trying to prevent: subtle attacks that are profitable and don't significantly affect the price of Bitcoin. This could be block withholding attacks (mining pools wasting each other's resources), networking attacks (to mess with other miners' connectivity), physical attacks (like purposely selling defective hardware and for yourself mining with the good hardware). I think this is what Peter Todd was talking about in the Reddit post about "other subtle and more effective attacks", and he (and others) likely don't want to lay them all out to give attackers bad ideas. Even EMP attacks on general electric devices can be considered "subtle" as it can be done to look like just an attack on general devices, while really it is targetting an area dense with honest miners. The selfish mining attacks and collusion attacks (the other categories) can also be done quite profitably I think, but with Internet anonymity still immature, they are less practical (as Peter Todd also indicated). In general, the point of my proposal is to disincentivize miners from driving out the competition. With the same reward for a lower hashrate, it is profitable to drive out competiton (lower overall hashrate) as that gives a bigger share to the attacker, and the same reward. If someone knows other ways to achieve this goal, then please let me know. This is one simple way that I think would work.

[HeRetiK]

[...]

Look, we just had a sudden 35% increase in hashpower recently (from what I read in the news), that's enough for a selfish mining attack, so to trust in the decentralization of Bitcoin mining is a bit of a shaky argument I believe, and I don't think what I am suggesting is urgent, but should carefully and smoothly rolled in, without much complication.

35% increase of total hashpower is not the same as a single miner increasing their hashpower by 35%.

Looking at Bitcoin's current hashrate distribution per pool, the proportions don't seem to have shifted much [1]. Distributed evenly, a 35% hashrate increase merely means that attacking the network via hashing power just got harder.

[1] https://www.blockchain.com/en/pools?timespan=24hours

There have been other core developers also concerned with the decentralization of mining, and even planning for a PoW change in case a 51% attack happens. I think other technologies like sidechains and merge mining will strengthen decentralization and hashpower attack prevention in the future also.

I know too little about sidechains to give an educated opinion, but what brings you to the conclusion that merge mining helps decentralization? I'm only thinking of Namecoin right now, so I might have missed some recent development in this area.

[...]

A more interesting question for the remaining part of the network is just how badly the hash rate was affected, and how long it would take of the 10 minute average block time take to be re-established.   It might be wise for bitcoin to adopt one of the more sophisticated diffalgos which were developed for alt coins  suffering from wild hash-rate swings for this reason: the unexpected disappearance of substantial hash rate. Unlikely, yes, but impossible, no.

In theory, yes. In practice I think this is much harder to achieve in a robust, nearly side-effect free way than one may imagine. Prime example is the mess that was BCH's EDA. That is not to say that solving this problem is impossible. I just think that it's a harder problem than it looks -- moreso with a crypto the scale of Bitcoin.

@Heretic says:

If the mining reward is reduced with a drop in difficulty, Bitcoin becomes even less profitable to mine, with more and more miners leaving as block reward is further and further dynamically reduced, creating the very pool of "spare" hashing power that the difficulty-dependent-block-reward is trying to avert.

I want to revist this scenario, assuming no merge mining. First, I think a price drop will be slightly offset by the lower rate of coins being mined. Also, confirmation times will get longer: Both the time to get a block will increase and the number of confirmations needed to have enough work done on the chain so that your transaction is considered safe. The fees would likely rise and this would increase rewards to miners, especially in a fee-market dominated future. It would be nice to write this up in terms of mathematical equations to see exactly what would happen.

I've also been thinking about how the decreased currency issuance rate could absorb part of the price drop. However I think the negative price pressure would be larger for two simple reasons:

1) Historically speaking, decreased currency issuance rate (ie. halvings, in our case) took a couple months to be reflected in Bitcoin's price

2) Low confirmation times and increased fees put a lot of negative short-term price pressure that could turn into mid- to long term price pressure in case of a downward spiral

@Heretic says:

Anyone willing to waste their resources on mounting a 51% attack on Bitcoin will do so regardless of whether we try to tweak the incentive structure in one way or another. Assuming such an adversary exists, selfish mining or covertly aggregating (unused) reserve hashing power would be the least of our worries.

Also revisiting this...I think I should add another category of attacks that I am trying to prevent: subtle attacks that are profitable and don't significantly affect the price of Bitcoin. This could be block withholding attacks (mining pools wasting each other's resources), networking attacks (to mess with other miners' connectivity), physical attacks (like purposely selling defective hardware and for yourself mining with the good hardware). I think this is what Peter Todd was talking about in the Reddit post about "other subtle and more effective attacks", and he (and others) likely don't want to lay them all out to give attackers bad ideas. Even EMP attacks on general electric devices can be considered "subtle" as it can be done to look like just an attack on general devices, while really it is targetting an area dense with honest miners. The selfish mining attacks and collusion attacks (the other categories) can also be done quite profitably I think, but with Internet anonymity still immature, they are less practical (as Peter Todd also indicated). In general, the point of my proposal is to disincentivize miners from driving out the competition. With the same reward for a lower hashrate, it is profitable to drive out competiton (lower overall hashrate) as that gives a bigger share to the attacker, and the same reward. If someone knows other ways to achieve this goal, then please let me know. This is one simple way that I think would work.

I think the subtle attacks that Peter Todd was talking about where political attacks similar to the BCH / B2X dramas we saw in 2017. That's just my guess though.