Increasing the survival chances of a sha256 hard fork

[freetrader]

Hi all,

As you know, serious considerations are being made with regards to hard-forking Bitcoin.

In this thread, I would like to discuss and seek ideas, opinions and any other comments around the topic of a hypothetical Bitcoin hard fork which retains the current PoW.

This hard fork would trigger at a certain predetermined block height, and being a hard fork it would have its own block version and ignore older blocks.

Some discussion has already been had around this topic and the potential for existing miners to attack it on a 51% hashpower basis using a fraction of their mighty ASICs.

I would also like to hear more about possible kinds of attacks they could launch against such a fork.

 

[freetrader]

The first topic I'd like to bring up for discussion is what @VeritasSapere referred to in the post below - the necessity for a different difficulty retargeting algorithm on the new fork:

Definitely, I think it would be best if we pool our resources indeed. Talking about Difficulty that will need to be adjusted for the original PoW chain. Otherwise it can become a possible attack vector, adjusting the difficulty every block or at the very least every few blocks like many of the altcoins already do today will become necessary since otherwise it will not be able to handle large swings in hash power. Without severely effecting block times.

The difficulty adjustment is a significant change but it is necessary unfortunately, it will have to be done in such a way that it does not effect supply, but that is absolutely possible. Dash's "dark gravity wave" difficulty adjustment might be a good example, since that adjust after each block.

---

I agree with VS that a much more rapidly responding difficulty algorithm is needed in the initial phase shortly after the fork is triggered.

I am open, however, to hearing contrary views - let's work out the maths.

 

[freetrader]

I just picked up another separate point, made by @largerblocks (emphasis mine):

Right now the difficulty adjustment is limited to increase or decrease by a factor of 4 at the most, this might require several difficulty adjustments to find the right level. At the fork point it might be best increase this band to for example a factor of 10 or more. This would let the difficulty auto adjust after just a few adjustments, much less than 3 months. Otherwise we might have an extended period where miners were receiving fast blocks which might make the fork look dishonest. Again this is something I'd like to make sure we get right after tests.

So there is that consideration too - trying not to defeat one's own objective by creating the wrong impression.

I guess the question is difficult to formulate in terms of the amount of BTC that should be dispensed for a certain time at a discount w.r.t. the actual difficulty that would otherwise apply if one were not trying to attract miners to the new chain.

A little differential should exist IMO between the block reward (in real terms) a miner could earn by mining the new chain vs. the old.

This differential should diminish over a relatively short period of time (3 months? 6 months? a year?), in order not to distort the long term emission schedule.

This discounting period / curve that takes effect after the trigger height is basically a parameter which one would have to decide beforehand.

Something like an exponential λ e**−λt for λ > 0 , t = (current block heigh - trigger height) appeals to me, but it's not based on anything but aesthetics. A more real-world basis underlying a choice might be helpful.

 

[jl777]

https://bitcointalk.org/index.php?topic=1157679.0

describe attack using tainted inputs

 

[steffen]

Imagine the start of a new coin either from scratch or as a full fork of the existing bitcoin blockchain from a specific block height. Besides ddos attacks the great monster we fear is the overwhelming pow attacker.

1. But what is it such a pow attacker could realistically do to kill a new coin? I am not very interested in temporary or minor disturbances to the network like fluctuations in difficulty and time between mined blocks. I think most hard money enthusiasts could live with initial disturbances. I am only interested in severe / deadly attacks. Please describe how a realistic attack could work.
   
2. I suppose than an element of the attack must be to somehow change some rules of the network but what if our original "satoshi vision loving" software simply refuse to work with the updated rule set? Wouldn't that make the attempted attack fail?
3. And couldn't this goal of making the attack unsuccessful be reached by (temporarily) going back to using only fully validating clients instead of using clients that just follow the longest chain (which might be created as part of an attack on the new network)?
4. How would a typical bitcoin full node react if it was sent a new block where all included transaction are valid, and block size limit is valid but the block header version is different from the ones the node knows about? Would the block be accepted or rejected?

Could these elements be used to provide some needed competition to Blockstream?

 

[VeritasSapere]

As far as I understand it, the worse that can be done is a fifty one percent attack, at worst they will be able to censor all transactions on the network and double spend their own transactions. That is the worst that can be done as far as I understand, not fatal considering that such an attack can not be sustained, considering it will require the attacking hashpower to continue to burn energy for the duration of the attack. The more hashpower we attract the less likely such an attack becomes.

I am also not convinced that many miners would even attack this genesis fork considering it does not actually represent that much of a threat to them, even if users decided to give this genesis fork more value, miners can and will simply just follow the profit instead of wasting money carrying out fifty one percent attack.

I would love to see this genesis fork included in the multi pools. Where the hashpower automatically moves to the most profitable SHA256 coin at any one time. This helps to create an equilibrium in mining where the security of any one chain mirrors the value of the block reward at any one time. Like I said miners can join a multipool and profit instead of losing wealth by attacking competing chains. Seems very rational to me, we can rely on the miners continued self interest.

 

[freetrader]

@steffen,

Thank you for the questions.

I am writing up detailed responses to your various questions, which I will post in in separate replies, so that it's easier to digest and discuss.

Hopefully everyone can correct me if I make mistakes in my answers.

 

[steffen]

As far as I understand it, the worse that can be done is a fifty one percent attack, at worst they will be able to censor all transactions on the network and double spend their own transactions. That is the worst that can be done as far as I understand

Thank you for the answer. I like it. Both these two issues sound minor compared to having an unscalable bitcoin.
Regarding censoring we will just have to wait for a minority miner to include the transaction in a block and perhaps have that block followed by a large number of blocks before we can really trust that the transaction is permanent.
Regarding double spend their own transactions, we will have to be careful who we do business with while the new network is still small.

 

[freetrader]

1. What could a PoW attacker do to kill a new coin?

You have mentioned an attack using the difficulty / time between blocks, and called it "temporary or minor disturbances. I disagree.

I'll describe the attack first for other to know what we are talking about:

The attacker starts mining the new coin with a vastly superior hashpower (a majority attack).
This raises the difficulty (fast or slowly - depending on algorithm).

Once the difficulty has been raised high enough, the attacker stops mining the new coin and goes back to doing other work. Suddenly, the remaining miners now face a huge difficulty, and time between blocks is increased enormously. The new coin is barely usable for as long as the difficulty takes to re-adjust to suitable levels.

When the difficulty has lowered again, the attacker comes and repeats the attack.

It does not cost the attacker that much, they need only control > 50% of the hashpower at all times.
Their mining does not benefit the coin while they attack (e.g. they mine only their own transactions).
The attacker could practically play this game for as long as they wish - they get the to keep the block rewards mined during their attack.

Freezing out of honest miners for long duration would effectively kill the usability of the new coin
and lead to loss of honest hashpower, further reducing security and the cost of future such attacks.

The only way I see to defend against this is to establish a significant enough fraction of hashpower on the new coin relative to the attacker to make the attack more costly than the attacker would be willing to spend. However, this is unlikely to be successful against a determined attacker.

---

On further hashpower attacks, I am going to provide links:

Majority attack:
https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power

Double-spend attacks:
https://en.bitcoin.it/wiki/Double-spending

"Analysis of hashrate-based double-spending" by Meni Rosenfeld:
https://bitcoil.co.il/Doublespend.pdf

Article about historic Ghash 51% situation (as can be seen it was considered an absolutely real threat to the network):
http://www.coindesk.com/51-attacks-real-threat-bitcoin/

The majority attack maths for a new fork / coin that keeps POW are scary:

As @largerblocks said in the other full fork thread:

For example if the minority branch has 1000th the value of the main chain, then any 0.1% miner could successfully 51% attack the branch.

I'll put some comparative mining power numbers down here:

Powerful CPU: < 25 x 10e6 h/s per CPU
Graphics cards: < 1 x 10e9 h/s
AntMiner S7 : ~4.86 x 10e12 h/s
Small Pool (slush) : 48.66 x 10e15 h/s
Total Bitcoin hashing power : > 1 x 10e18 h/s

Sobering numbers in the context of what @largerblocks said, so I consider majority attacks as absolutely realistic for a new fork. As we have already seen with the DDOS attacks on XT, Classic, F2Pool, now Poloniex as well - there are motivated attackers willing to spend money.

Even a relatively unsophisticated attacker could rent hashpower in the early phases while a fork is weak.

[1] https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison

 

[freetrader]

@steffen

2. I suppose than an element of the attack must be to somehow change some rules of the network but what if our original "satoshi vision loving" software simply refuse to work with the updated rule set? Wouldn't that make the attempted attack fail?

I see a few possible ways to attack that could be termed "changing the rules of the network", but they are not limited to an attack against our hypothetical fork, and I don't see how we could "simply refuse" them:

2.a) Denial of Service attacks focusing on a particular subset of the network, e.g. against nodes of this fork. Could be based on bandwidth starvation (like the DNS amplification DDOS we've seen), or could be based on vulnerabilities in the Bitcoin protocol (e.g. lack of authentication and encryption).

2.b) Exploiting security vulnerabilities against the client or operating systems it runs on. As for the OS's, there are always exploits in circulation, and probably the majority of Bitcoin nodes are not running on hardened installations. Someone might have been quietly charting vulnerabilities and waiting until it's profitable (e.g. one of the fork's adversaries offers a bounty to take down some nodes).

3.c) Sybil attack on the fork - swamp the network with clients that look like the fork, but are running a slightly modified version of the fork.
They can't easily change the POW function to make it easier for themselves, otherwise they'd be a complete hard fork in themselves. So it'd probably be something else, like difficulty algorithm etc.
If the Sybil nodes gain the majority, the fork is in deep trouble as it will effectively have been overtaken.
We can only detect this by monitoring the processing and comparing to what is expected according to the fork's original software. And of course monitor the p2p network for signs of trouble.
[doublepost=1457941960][/doublepost]

3. And couldn't this goal of making the attack unsuccessful be reached by (temporarily) going back to using only fully validating clients instead of using clients that just follow the longest chain (which might be created as part of an attack on the new network)?

I don't know exactly what you mean by "fully validating". I am going to assume every node that is participating has a full copy of the blockchain.

In the ideal case, we could prevent an attack by recognizing branches that are created by attackers.
However, I don't see any practical way to do that.

The assumption is that an attacker could be running the exact same software (our fork) but just with more hashpower.

So one could start to discriminate against attackers on the basis of measured hashpower.
If their branch grows too fast, it must be an attacker.

Of course, this is not necessarily true, so what one would end up doing is artificially constraining the growth of hashpower on one's fork, discouraging new miners, while the Bitcoin main chain is free to grow unrestrained. I'd say it's not a successful strategy.
[doublepost=1457942383,1457941392][/doublepost]

4. How would a typical bitcoin full node react if it was sent a new block where all included transaction are valid, and block size limit is valid but the block header version is different from the ones the node knows about? Would the block be accepted or rejected?

I think it depends on how the receiving node's software is set up to handle the case.

It could be written so it rejects all blocks that don't match a specific block version. This is what you would do if you want to create a fork that _definitely_ forks off some chain. This is what e.g. the POW fork will do.

Or a client could accept a range of block versions which are supposed to be compatible with it. This is the way that current elective hard fork versions like Classic, BU and XT work - they still process Core blocks ...

 

[steffen]

1. What could a PoW attacker do to kill a new coin?

You have mentioned an attack using the difficulty / time between blocks, and called it "temporary or minor disturbances. I disagree.

I'll describe the attack first for other to know what we are talking about:

The attacker starts mining the new coin with a vastly superior hashpower (a majority attack).
This raises the difficulty (fast or slowly - depending on algorithm).

Once the difficulty has been raised high enough, the attacker stops mining the new coin and goes back to doing other work. Suddenly, the remaining miners now face a huge difficulty, and time between blocks is increased enormously. The new coin is barely usable for as long as the difficulty takes to re-adjust to suitable levels.

When the difficulty has lowered again, the attacker comes and repeats the attack.

It does not cost the attacker that much, they need only control > 50% of the hashpower at all times.

"Only" > 50% may be a significant cost depending on how much supporting mining power the new coin will attract. Besides, there is on opportunity cost for the attacker, the bitcoins the attacking miner is not earning while the attack is going on. And there is a publicity cost. No one who wants to appear to be honest likes to be openly doing something which everyone can see is an attack. That is probably the main reason we don't see many direct attacks against altcoins.

Their mining does not benefit the coin while they attack (e.g. they mine only their own transactions).
The attacker could practically play this game for as long as they wish - they get the to keep the block rewards mined during their attack.

I expect that honest users and miners will be attracted to the new coin and as more and more get attracted the attack will become more and more expensive. Therefore the attacks will fade out.

Freezing out of honest miners for long duration would effectively kill the usability of the new coin
and lead to loss of honest hashpower, further reducing security and the cost of future such attacks.

The only way I see to defend against this is to establish a significant enough fraction of hashpower on the new coin relative to the attacker to make the attack more costly than the attacker would be willing to spend. However, this is unlikely to be successful against a determined attacker.

We will need to see who are most determined. One advantage of keeping the existing POW is that we have an important ally out there, Satoshi Nakamoto, just waiting to decide where and when he will put his mining power into the battle. I believe he could choose to put (some of) it behind an alternative to bitcoin. I think his main interest is the original vision behind bitcoin, not necessarily bitcoin itself.
[doublepost=1457953911,1457952780][/doublepost]

@steffen
2. I suppose than an element of the attack must be to somehow change some rules of the network but what if our original "satoshi vision loving" software simply refuse to work with the updated rule set? Wouldn't that make the attempted attack fail?
I see a few possible ways to attack that could be termed "changing the rules of the network", but they are not limited to an attack against our hypothetical fork, and I don't see how we could "simply refuse" them:

2.a) Denial of Service attacks focusing on a particular subset of the network, e.g. against nodes of this fork. Could be based on bandwidth starvation (like the DNS amplification DDOS we've seen), or could be based on vulnerabilities in the Bitcoin protocol (e.g. lack of authentication and encryption).

2.b) Exploiting security vulnerabilities against the client or operating systems it runs on. As for the OS's, there are always exploits in circulation, and probably the majority of Bitcoin nodes are not running on hardened installations. Someone might have been quietly charting vulnerabilities and waiting until it's profitable (e.g. one of the fork's adversaries offers a bounty to take down some nodes).

3.c) Sybil attack on the fork - swamp the network with clients that look like the fork, but are running a slightly modified version of the fork.
They can't easily change the POW function to make it easier for themselves, otherwise they'd be a complete hard fork in themselves. So it'd probably be something else, like difficulty algorithm etc.
If the Sybil nodes gain the majority, the fork is in deep trouble as it will effectively have been overtaken.
We can only detect this by monitoring the processing and comparing to what is expected according to the fork's original software. And of course monitor the p2p network for signs of trouble.

DOS (2a) and Security holes (2b) does not change the validation rules. They are different classes of attacks. It is the slightly modified client (2c which you seem to have accidentally called 3c) I am concerned about in this question. And I agree with you that the solution is to monitor, and compare, and watch out for signs of trouble.
[doublepost=1457954964][/doublepost]Steffen wrote:

3. And couldn't this goal of making the attack unsuccessful be reached by (temporarily) going back to using only fully validating clients instead of using clients that just follow the longest chain (which might be created as part of an attack on the new network)?

freetrader wrote:

I don't know exactly what you mean by "fully validating". I am going to assume every node that is participating has a full copy of the blockchain.

I mean that ordinary users who just want to be able to pay and receive with a new coin might have to go temporarily back to using software which stores the full blockchain to gain more security while the project is young and with limited mining power. No Simplified Payment Verification for ordinary users who want good protection. I will just point out that my thoughts here are mostly about a completely new coin so the blockchain will be small for a long time.

Steffen wrote:

4. How would a typical bitcoin full node react if it was sent a new block where all included transaction are valid, and block size limit is valid but the block header version is different from the ones the node knows about? Would the block be accepted or rejected?

freetrader wrote:

I think it depends on how the receiving node's software is set up to handle the case.

It could be written so it rejects all blocks that don't match a specific block version. This is what you would do if you want to create a fork that _definitely_ forks off some chain. This is what e.g. the POW fork will do.

Yes, initially only accepting a specific block version is the defense I imagine would be necessary to protect against an overwhelming POW attacker who wants to kill the new coin by changing some rules which would prevent future growth. When the network has grown to some moderate to big size and we really need a specific new scaling improvement we release a new piece of software which allows both the old block version and the next specific block version.

 

[freetrader]

No one who wants to appear to be honest likes to be openly doing something which everyone can see is an attack.

Unless they believe they can stay incognito. Approx 5% of current hashpower is unknown, perhaps a lot more if you count those behind "known by name but not really transparent" pools.

 

[steffen]

Unless they believe they can stay incognito. Approx 5% of current hashpower is unknown.

It is a dangerous world out there. I think we need to do an attempt at least.It might no go the way we would like but then we must learn from whatever went wrong so the next attempt might succeed.

 

[freetrader]

Completely agree. It's a new situation, and we have to learn by doing.

 

[steffen]

@freetrader wrote:

I'll describe the attack first for other to know what we are talking about:

The attacker starts mining the new coin with a vastly superior hashpower (a majority attack).
This raises the difficulty (fast or slowly - depending on algorithm).

Once the difficulty has been raised high enough, the attacker stops mining the new coin and goes back to doing other work. Suddenly, the remaining miners now face a huge difficulty, and time between blocks is increased enormously. The new coin is barely usable for as long as the difficulty takes to re-adjust to suitable levels.

When the difficulty has lowered again, the attacker comes and repeats the attack.

Here is an idea for defending against that kind of attack:
If no block has been found during the previous 20 minutes all good nodes recalculate the difficulty. It is halved. If another 20 minutes go without discovering a new block all good nodes recalculate the difficulty again. It is halved again. And so it continues until blocks start being discovered. That way the attacker cannot prevent new blocks from being found for a very long time.

I know that nodes don't synchronize their time with each other but I don't think that prevents this solution because each node compares two of its own local times. The main problem with this proposal might be that nodes don't receive blocks at exactly the same time. One node might accept a block it receives 21 minutes after the previous block while another node receives it just 19 minutes after the previous block it has seen and rejects it because the solution arrived too early, it wont be valid before another minute has passed. To prevent such timing issues which might create a split among the honest nodes we might initially reject such a 19 minutes block but accept it later if other nodes accept it and build new blocks on top of it.

Could this special difficulty halving idea maybe solve most of the problem with POW attackers?

 

[VeritasSapere]

Thank you for the answer. I like it. Both these two issues sound minor compared to having an unscalable bitcoin.
Regarding censoring we will just have to wait for a minority miner to include the transaction in a block and perhaps have that block followed by a large number of blocks before we can really trust that the transaction is permanent.
Regarding double spend their own transactions, we will have to be careful who we do business with while the new network is still small.

In the case of a fifty one percent attack they can censor transactions since even though the minority miners can choose to include transactions in their blocks, the majority of attacking miners can choose not to build on top of those blocks, effectively censoring all transactions on that blockchain. Realistically though you would require more then fifty one percent of the hashpower to pull this off consistently and effectively. Though even if our fork had only five percent of the total SHA256 hashpower such an attack would still be extremely expensive to carry out and maintain, with little benefit to the attacker.

@freetrader Great observations on the other possible attack vectors, I also agree that changing the speed of difficulty adjustments is critical, unfortunately. I would prefer changing as little as possible, but that is one change we must make in order to survive these hypothetical attacks.

Its funny that many people are saying that what we are doing here is impossible, I love to make the impossible, possible. We will put this out into the world and prove them wrong.

 

[freetrader]

Could this special difficulty halving idea maybe solve most of the problem with POW attackers?

Interesting idea @steffen. I'll need to have to look at how the difficulty algorithm I'm currently considering (MIDAS) performs under a scenario where a majority of miners (51, 75%, 95%...) suddenly withholds blocks. Since that algorithm adjusts at every block, and has an "emergency mode" where it recovers more aggressively, I would expect it to do quite well against such an attack even while only relying on the blocks found by the remaining minority of miners.

 

[freetrader]

In @Gavin Andresen 's recent AMA, he mentioned this:

If I am wrong and blocks are created on the minority chain, people plan to get enough hash power to replace those blocks with empty blocks, so it is impossible to make any transactions on the minority chain.

I interpret that there are plans by some miners/pools to attack a minority fork with their majority hashpower to censor all transactions on the minority fork. By mining only empty blocks, they deny service on that fork.

An interesting question is how much hash power (how big a majority) do they have to invest in return for what sort of degradation. We can assume at ~50% they mine just more than every second block on average, at 75% they mine 3/4 blocks on average, etc. So the expected number of blocks that go past without your transaction having *a chance* of being included is, by brief mental exercise, the nominator of that fraction divided by 2 (since it's equally likely that we start out in either half of the "waiting time" for the next honest block). And then, when the honest block is mined, you are in a pool of transactions which may have grown large because of the denial of service, so your chance is reduced in proportion to the ratio of the backlog vs. the block size limit (assuming the honest nodes would stuff blocks full if there was a backlog). It would be good to model/graph this to determine the actual expected wait time for a transaction under such an attack.

But I wonder if one could introduce a heuristic to mitigate such a denial of service by empty blocks.

Naively, I might imagine one could declare a block to be invalid if

a) it is empty or contains less than a certain mininum of transactions (e.g. less than 1/f(h,n) of the current block size limit), where f(h,n) is a function of the last n blocks at height h
b) if more than some fraction of its transactions are unknown to your node

My thinking is it would be good to incentivize blocks containing transactions that have already widely propagated, versus some that might be selfishly mined by an attacker. I do see that (b) would introduce further complications such as perhaps exacerbating the effect of transactions censorship attacks and requiring a warm-up phase for new nodes to synchronize their mempool.

It's just a thought - there are probably good reasons I'm unaware of for not doing this...

 

[johnyj]

There is no meaning for miners to waste their hash power to do such attack, they either ignore it, or would just mine the fork if they think that fork is most legit, e.g. the chain that mostly represent the original bitcoin idea

 

[nmag]

How about introducing a secondary POW during the early days of the deployment of the fork and slowly phase it out as the fork gets stronger/as time passes by? The secondary POW would not be intended to form a chain of headers, but rather it should be used as a protection mechanism.

Here is an example of how it could work:

The fork happens at some block height, sha256 difficulty is resetted and even maybe a new difficulty adjustment schedule is defined for the early days. However, in order for a miner to build on top of a new block that he receives, he would also expect a 2nd POW at some fraction of the difficulty of the sha256 difficulty. In this way, an attacker must have high computational power for the 2nd POW too, which reduces the chances of this happening. As time passes, the fractional difficulty of the 2nd POW should decrease and become zero at some point (even though I believe that a better idea is to set the fractional difficulty of the 2nd POW as a function of the strength of the sha256 chain compared to the strength of the old consensus chain; the stronger the sha256 chain the less franctional difficulty required for protection).

What do you guys think?