Why soft fork is a very bad idea and should be avoided at all costs

[rizzlarolla]

OP Are you saying "Why soft fork TO SEGWIT is a bad idea?" I agree. Good post.

He is saying that all soft forks are bad, but it is interesting that he only brings it up now when SegWit is being prepared to be deployed. We have had multiple soft forks already to deploy new features. It seems to just be an attack at SegWit while simultaneously attacking soft forks.

Segwit just ain't Bitcoin.

How so?

I personally never liked the weak block idea, and the over complexity.

But OP also seems to brings up an attack scenario specific to segwit.
Previous soft forks have not rendered nodes blind.(?)

I think it is an attack on segwit. Sort forks are only the delivery method here.

[achow101]

I personally never liked the weak block idea, and the over complexity.

Weak blocks are not segwit. They are two completely different ideas.

But OP also seems to brings up an attack scenario specific to segwit.
Previous soft forks have not rendered nodes blind.(?)

SegWit does not render nodes blind (and blind to what?).

[SebastianJu]

So here is the discussion going on, not in the other thread johnyj...

I have read your explaination and indeed i think this is a hefty thing to plan. Consensus is something different i think. It is tricking into believing everything is right.

I'm surely not so much into the tech so i might be fully wrong. Don't take it agains me.

So what i ask myself, when the old nodes only see empty blocks, aren't the transactions needed to calculate if the block hash is correct? If the transactions are not seeable then how can the hash be calculated as valid? As far as i remember, changing the transactions of a block will give you another seed part that is used as base to find the block hash.

You write that segwit miner still would need nearly half of the network to do this fork but wouldn't it be sufficient when 10% segwit nodes find a block, let's say a minute before the 90% non segwit nodes, then they propagate it through matt's network(?) to all the big miners and these miners can instantly confirm the block because nothing big to be calculated. They would accept the block and that would be it.

Though even then, the old nodes would still think the bitcoins, that were moved in the segwit block, are at the old addresses and the segwit nodes with bitcoins that were transferred already, wouldn't that mean a fork of some kind has happened because a big part of the network has different details about the status of the bitcoins?

Further on, when the network only has 10% segwit nodes, which is likely in the beginning, then wouldn't there an attack vector by misusing the blindness of the nonsegwit miner nodes?

I mean depending on how the nodes confirm the segwit blocks at all, what if someone creates a block that contains fake segwit transactions? Completely rubbish or scammy transactions. The segwit nodes would discard this block but the nonsegwit nodes could not check if the block is invalid. They would accept it and hardfork. Though when i think about it, nothing would change for the nonsegwit nodes anyway because they don't know the segwit transactions. And the segwit nodes would still work on what they know.

Which brings me back to my previous question, when the nonsegwit nodes don't see segwit transactions then they will build blocks on data segwit nodes don't use. So it would still be a fight about trusting who will win since when i would receive bitcoins with a segwit transaction but the majority of the net is not accepting that transaction then i would not accept that transaction as valid too since i could not be sure that these bitcoins will be there in the future. So i would have to consider them worthless.

So what's the status of miners claiming to accept segwit? >50% hashpower?

Sorry for my lack of knowledge on the topic.

[eddie13]

What I am getting from reading all this:

Soft fork = 51% attack = no new fork for those that don't agree, no new 2nd coin

Hard fork = Consensus = yes new fork for those who disagree, or rather a new fork for those who want the change, making 2 coins


In my mind 51% is not = to consensus. To me consensus mean 95%+ or with the hard fork you choose to use the old coin and not the new coin if you don't like the change and if it doesn't work out the good old bitcoin is still there VS the soft fork that changes bitcoin wether 49% of others like it or not..

Am I understanding this correctly?

[achow101]

What I am getting from reading all this:

Soft fork = 51% attack = no new fork for those that don't agree, no new 2nd coin

Hard fork = Consensus = yes new fork for those who disagree, or rather a new fork for those who want the change, making 2 coins


In my mind 51% is not = to consensus. To me consensus mean 95%+ or with the hard fork you choose to use the old coin and not the new coin if you don't like the change and if it doesn't work out the good old bitcoin is still there VS the soft fork that changes bitcoin wether 49% of others like it or not..

Am I understanding this correctly?

No. Soft forks are still forks and as I have explained earlier, can still create two blockchains.

All forks, hard and soft, deploy with consensus (or should). Every soft fork that has previously happened deployed with consensus. It is still a fork, and forks deploy with consensus, not just 51%.

[johnyj]

OP Are you saying "Why soft fork TO SEGWIT is a bad idea?" I agree. Good post.

He is saying that all soft forks are bad, but it is interesting that he only brings it up now when SegWit is being prepared to be deployed. We have had multiple soft forks already to deploy new features. It seems to just be an attack at SegWit while simultaneously attacking soft forks.

I'm not specifically aiming segwit, but this soft fork idea is not the traditional soft fork. In a traditional soft fork, the new version only tighten the rules and make the new version more strict in accepting blocks, so that some old blocks become invalid, like july 04 soft fork. But this soft fork is trying to cheat old nodes to implement other rules, which are not a tightening of existing rules, but a total change to another set of rules

It came out from the HongKong conference, where Pieter said he originally thought it is impossible to seperate the blockchain data without a hard fork, so he dismissed that idea, but later Luke_jr told him that he can do this trick as a soft fork

But what I don't understand is, if you use this soft fork trick, you can expand the blocksize to 2MB the same way, avoiding a hard fork too. So if the main purpose of Segwit is to avoid hard fork, then a 2MB soft fork will be a better solution than Segwit, since it does not need to separate data, which causes some extra coding and testing

Segwit just ain't Bitcoin.

How so?

Segwit to bitcoin is a RAID to a hard drive, they can achieve the same purpose of storing data, but technically they are not the same thing

[johnyj]

If one type of nodes, Classic for example, controls over 51% of hash power, they can implement whatever change they like by simply use this soft fork trick: Let all the old Core nodes accept their new format blocks while Classic nodes will reject Core blocks, so that Core blocks all get orphaned due to less hash power

This is nothing but a classic 51% attack by cooperating miners, and has nothing whatsoever to do with soft forks.  If you manage to control 51% of the hashpower, you can ignore everyone else and always have the best chain.  Bitcoin 101.

In my previous knowledge, there are things 51% attack can do, like double spending and reverse transactions, but there are things a 51% can not do, like spend the coins in other people's cold wallet etc. But now I understand, these are only true if the attacker run the same software as the rest of the network

Under this new soft fork trick, a 51% attack is not only a disturbance of the transactions, it become a political weapon to suppress the people with different idea and force them to give up due to their economy incentive

[johnyj]

So what i ask myself, when the old nodes only see empty blocks, aren't the transactions needed to calculate if the block hash is correct? If the transactions are not seeable then how can the hash be calculated as valid? As far as i remember, changing the transactions of a block will give you another seed part that is used as base to find the block hash.

In old nodes' view, it is just an empty block with a coinbase transaction, nothing special,  like those blocks generated by SPV mining. So the hash function will return OK signal.

You write that segwit miner still would need nearly half of the network to do this fork but wouldn't it be sufficient when 10% segwit nodes find a block, let's say a minute before the 90% non segwit nodes, then they propagate it through matt's network(?) to all the big miners and these miners can instantly confirm the block because nothing big to be calculated. They would accept the block and that would be it.

Though even then, the old nodes would still think the bitcoins, that were moved in the segwit block, are at the old addresses and the segwit nodes with bitcoins that were transferred already, wouldn't that mean a fork of some kind has happened because a big part of the network has different details about the status of the bitcoins?

You are right. If Segwit nodes only have 10% of hash power, then when they publish their block, the block will be accepted by core nodes, and core nodes see nothing in it. But in Segwit nodes' view, that block contains a transaction that spent Alice's coins. Core nodes does not see this transaction, thus they believe Alice's coins are still there, but in Segwit nodes' view, it is already spent

As a result, later when core nodes trying to spend those Alice's coins, that block will be accepted by Core nodes but not Segwit nodes, so a fork will happen. The fork happens because Segwit nodes does not have enough hash power to prevent core nodes to publish Alice's transaction. If Segwit nodes commands more than 60% of hash power, then core mining nodes will never be able to spend Alice's coins, because all their blocks are orphaned. And there will never be a fork

Further on, when the network only has 10% segwit nodes, which is likely in the beginning, then wouldn't there an attack vector by misusing the blindness of the nonsegwit miner nodes?

I mean depending on how the nodes confirm the segwit blocks at all, what if someone creates a block that contains fake segwit transactions? Completely rubbish or scammy transactions. The segwit nodes would discard this block but the nonsegwit nodes could not check if the block is invalid. They would accept it and hardfork. Though when i think about it, nothing would change for the nonsegwit nodes anyway because they don't know the segwit transactions. And the segwit nodes would still work on what they know.

True, this has been pointed out by someone and it seems to be a big issue. If a rogue segwit miner publish an invalid segwit block, it will be accepted by the core nodes while rejected by segwit nodes, so a fork will happen from there. In fact this makes the segwit implementation phase so vulnerable that just one invalid block will cause it to fork into its own chain

(Correction: Before the fork condition is reached, e.g. 75% hash power supporting segwit, segwit nodes will not generate and accept new transaction format, so the system is still safe. And after the fork, the attacker need more than 25% of hash power from segwit nodes to push in such an invalid block, since the other 25% of old nodes' hash power will assist to write the block into the chain)

[sturle]

If one type of nodes, Classic for example, controls over 51% of hash power, they can implement whatever change they like by simply use this soft fork trick: Let all the old Core nodes accept their new format blocks while Classic nodes will reject Core blocks, so that Core blocks all get orphaned due to less hash power

This is nothing but a classic 51% attack by cooperating miners, and has nothing whatsoever to do with soft forks.  If you manage to control 51% of the hashpower, you can ignore everyone else and always have the best chain.  Bitcoin 101.

In my previous knowledge, there are things 51% attack can do, like double spending and reverse transactions, but there are things a 51% can not do, like spend the coins in other people's cold wallet etc. But now I understand, these are only true if the attacker run the same software as the rest of the network

The attacker can run whatever software he wants, as long as he, or they, generate valid blocks.  If the blocks are invalid, e.g. by creating or spending coins in invalid ways, the blocks will be ignored by all validating nodes.  (SPV wallets may be vulnerable if the attacker has enough nodes on the network.)

Under this new soft fork trick, a 51% attack is not only a disturbance of the transactions, it become a political weapon to suppress the people with different idea and force them to give up due to their economy incentive

You aren't describing a soft fork, what you describe is a 51% attack.  You describe a situation where 51% of the hashrate cooperate by ignoring blocks produced by others.  This is perfectly doable today, and the main reason why miner centralization is a problem.  If you mine at the large pools, switch to one with less than 10% of the global hashrate.

Soft forks aren't activated until 95% of the last 2016 blocks conform to the new rules, btw.

[johnyj]

If one type of nodes, Classic for example, controls over 51% of hash power, they can implement whatever change they like by simply use this soft fork trick: Let all the old Core nodes accept their new format blocks while Classic nodes will reject Core blocks, so that Core blocks all get orphaned due to less hash power

This is nothing but a classic 51% attack by cooperating miners, and has nothing whatsoever to do with soft forks.  If you manage to control 51% of the hashpower, you can ignore everyone else and always have the best chain.  Bitcoin 101.

In my previous knowledge, there are things 51% attack can do, like double spending and reverse transactions, but there are things a 51% can not do, like spend the coins in other people's cold wallet etc. But now I understand, these are only true if the attacker run the same software as the rest of the network

The attacker can run whatever software he wants, as long as he, or they, generate valid blocks.  If the blocks are invalid, e.g. by creating or spending coins in invalid ways, the blocks will be ignored by all validating nodes.  (SPV wallets may be vulnerable if the attacker has enough nodes on the network.)

Under this new soft fork trick, a 51% attack is not only a disturbance of the transactions, it become a political weapon to suppress the people with different idea and force them to give up due to their economy incentive

You aren't describing a soft fork, what you describe is a 51% attack.  You describe a situation where 51% of the hashrate cooperate by ignoring blocks produced by others.  This is perfectly doable today, and the main reason why miner centralization is a problem.  If you mine at the large pools, switch to one with less than 10% of the global hashrate.

Soft forks aren't activated until 95% of the last 2016 blocks conform to the new rules, btw.

In case of an intentional attack towards bitcoin, there is no difference. An attacker (a bank or government for example)who want to destroy bitcoin would just publish empty blocks and stall the network with more than 51% of hash power, and they don't need to change the software, just use the same software as the rest of the network

However, in case of an internal political conflict, this becomes dangerous, because the attacker might not want to kill bitcoin, but just to capture and morph the hash power from his opposite side to his side. In that case, commanding 60% hash power can almost guarantee it will happen

[bob123]

If one type of nodes, Classic for example, controls over 51% of hash power, they can implement whatever change they like by simply use this soft fork trick: Let all the old Core nodes accept their new format blocks while Classic nodes will reject Core blocks, so that Core blocks all get orphaned due to less hash power

This is nothing but a classic 51% attack by cooperating miners, and has nothing whatsoever to do with soft forks.  If you manage to control 51% of the hashpower, you can ignore everyone else and always have the best chain.  Bitcoin 101.

This. I hope it never comes so far

[Moloch]

Just wait until they start running multiple soft forks in parallel:
SegWit & Soft Forks & Sidechains, Oh, My! - Andreas Antonopoulos on Bitcoin

[johnyj]

Just wait until they start running multiple soft forks in parallel:
SegWit & Soft Forks & Sidechains, Oh, My! - Andreas Antonopoulos on Bitcoin

And that will trigger lots of hard fork without people even understand what is happening

[sturle]

Just wait until they start running multiple soft forks in parallel:
SegWit & Soft Forks & Sidechains, Oh, My! - Andreas Antonopoulos on Bitcoin

And that will trigger lots of hard fork without people even understand what is happening

No, a soft fork can not trigger a hard fork.  A soft fork can trigger chainforks which are longer than normal if a malicious miner claim they have support for the fork, but don't (which is a very bad idea from an economic perspective).  The chainfork is not hard, and the risk is pretty low.

[SebastianJu]

In old nodes' view, it is just an empty block with a coinbase transaction, nothing special,  like those blocks generated by SPV mining. So the hash function will return OK signal.

So the actual transactions are not needed to calculate the block hash? And the transactions normally are only checked to see if they are valid but if they are valid then no checksum or something like that is created to calculate that the actual hash is correct?

You are right. If Segwit nodes only have 10% of hash power, then when they publish their block, the block will be accepted by core nodes, and core nodes see nothing in it. But in Segwit nodes' view, that block contains a transaction that spent Alice's coins. Core nodes does not see this transaction, thus they believe Alice's coins are still there, but in Segwit nodes' view, it is already spent

As a result, later when core nodes trying to spend those Alice's coins, that block will be accepted by Core nodes but not Segwit nodes, so a fork will happen. The fork happens because Segwit nodes does not have enough hash power to prevent core nodes to publish Alice's transaction. If Segwit nodes commands more than 60% of hash power, then core mining nodes will never be able to spend Alice's coins, because all their blocks are orphaned. And there will never be a fork

I wonder how i should react on this. I mean let's assume segwit nodes start with 10% of the hashrate. As an escrow i receive coins. But either these coins only moved on the core mining nodes or only moved on the segwit nodes. The end is i can't be sure if i actually received something of value or which chain will win at the end. When i trust segwit wins then actually core nodes might win and vice versa.

The only way to handle this might be to check that i received the coins on both chains, right?

Well this really is stupid when this is enforced this way. A soft fork with 95%, like it was done before it seems, would be way safer because you know the new thing won so far and it is very unlikely that it will lose then.

Further on, when the network only has 10% segwit nodes, which is likely in the beginning, then wouldn't there an attack vector by misusing the blindness of the nonsegwit miner nodes?

I mean depending on how the nodes confirm the segwit blocks at all, what if someone creates a block that contains fake segwit transactions? Completely rubbish or scammy transactions. The segwit nodes would discard this block but the nonsegwit nodes could not check if the block is invalid. They would accept it and hardfork. Though when i think about it, nothing would change for the nonsegwit nodes anyway because they don't know the segwit transactions. And the segwit nodes would still work on what they know.

True, this has been pointed out by someone and it seems to be a big issue. If a rogue segwit miner publish an invalid segwit block, it will be accepted by the core nodes while rejected by segwit nodes, so a fork will happen from there. In fact this makes the segwit implementation phase so vulnerable that just one invalid block will cause it to fork into its own chain

(Correction: Before the fork condition is reached, e.g. 75% hash power supporting segwit, segwit nodes will not generate and accept new transaction format, so the system is still safe. And after the fork, the attacker need more than 25% of hash power from segwit nodes to push in such an invalid block, since the other 25% of old nodes' hash power will assist to write the block into the chain)

Oh that actually sounds like the soft fork is implemented similarly like previous softforks? I thought segwit nodes will start to generate segwit blocks right away. So even when segwit nodes would be sure that the miner rewards for their blocks will be safe even on the other chain, they won't create segwit blocks at all until they reached majority?

[achow101]

So the actual transactions are not needed to calculate the block hash? And the transactions normally are only checked to see if they are valid but if they are valid then no checksum or something like that is created to calculate that the actual hash is correct?

They are. The merkle root is a field in the header that is the hash of all of the transactions. To check the validity of the merkle root  and thus the entire block header, all of the transactions are hashed together to see if the resulting hash matches the merkle root.

I wonder how i should react on this. I mean let's assume segwit nodes start with 10% of the hashrate. As an escrow i receive coins. But either these coins only moved on the core mining nodes or only moved on the segwit nodes. The end is i can't be sure if i actually received something of value or which chain will win at the end. When i trust segwit wins then actually core nodes might win and vice versa.

The only way to handle this might be to check that i received the coins on both chains, right?

Well this really is stupid when this is enforced this way. A soft fork with 95%, like it was done before it seems, would be way safer because you know the new thing won so far and it is very unlikely that it will lose then.

Soft fork deployment of 95% will happen. No fork deployed by developers will ever deploy without some sort of block majority.

Oh that actually sounds like the soft fork is implemented similarly like previous softforks? I thought segwit nodes will start to generate segwit blocks right away. So even when segwit nodes would be sure that the miner rewards for their blocks will be safe even on the other chain, they won't create segwit blocks at all until they reached majority?

SegWit will deploy just as previous soft forks have. There is no point to immediately start creating segwit blocks as that is also dangerous.

[True Demon]

Can anyone explain the major difference between a soft fork and a hard fork? And why is everyone afraid of soft fork?

[achow101]

Can anyone explain the major difference between a soft fork and a hard fork? And why is everyone afraid of soft fork?

Soft forks are backwards compatible meaning that people running old nodes do not need to upgrade. Hard forks are not so everyone will need to upgrade their software in order to remain compatible.

People are not afraid of soft forks, they are actually the preferred method of the devs to deploy new features. It is just that people don't like SegWit which will be deployed as a soft fork.

[SebastianJu]

So the actual transactions are not needed to calculate the block hash? And the transactions normally are only checked to see if they are valid but if they are valid then no checksum or something like that is created to calculate that the actual hash is correct?

They are. The merkle root is a field in the header that is the hash of all of the transactions. To check the validity of the merkle root  and thus the entire block header, all of the transactions are hashed together to see if the resulting hash matches the merkle root.

Then the transactions get only checked against the merkle tree, which can contain all segwit transactions too, as long as the basetransaction is in there too.

But the transactions or the merkle tree plays no role in the calculation of the block hash?

I wonder how i should react on this. I mean let's assume segwit nodes start with 10% of the hashrate. As an escrow i receive coins. But either these coins only moved on the core mining nodes or only moved on the segwit nodes. The end is i can't be sure if i actually received something of value or which chain will win at the end. When i trust segwit wins then actually core nodes might win and vice versa.

The only way to handle this might be to check that i received the coins on both chains, right?

Well this really is stupid when this is enforced this way. A soft fork with 95%, like it was done before it seems, would be way safer because you know the new thing won so far and it is very unlikely that it will lose then.

Soft fork deployment of 95% will happen. No fork deployed by developers will ever deploy without some sort of block majority.

Ok, the OP sounded differently and i'm no expert.

Oh that actually sounds like the soft fork is implemented similarly like previous softforks? I thought segwit nodes will start to generate segwit blocks right away. So even when segwit nodes would be sure that the miner rewards for their blocks will be safe even on the other chain, they won't create segwit blocks at all until they reached majority?

SegWit will deploy just as previous soft forks have. There is no point to immediately start creating segwit blocks as that is also dangerous.

Good to hear that. If segwith really reaches that leven then it is pretty sure that it will stay since it won't lose support then anymore.

[sturle]

So what i ask myself, when the old nodes only see empty blocks, aren't the transactions needed to calculate if the block hash is correct? If the transactions are not seeable then how can the hash be calculated as valid? As far as i remember, changing the transactions of a block will give you another seed part that is used as base to find the block hash.

In old nodes' view, it is just an empty block with a coinbase transaction, nothing special,  like those blocks generated by SPV mining. So the hash function will return OK signal.

Wrong.  All transactions are recorded in the block.  Only the signatures are moved.

You are right. If Segwit nodes only have 10% of hash power, then when they publish their block, the block will be accepted by core nodes, and core nodes see nothing in it. But in Segwit nodes' view, that block contains a transaction that spent Alice's coins. Core nodes does not see this transaction, thus they believe Alice's coins are still there, but in Segwit nodes' view, it is already spent

As a result, later when core nodes trying to spend those Alice's coins, that block will be accepted by Core nodes but not Segwit nodes, so a fork will happen. The fork happens because Segwit nodes does not have enough hash power to prevent core nodes to publish Alice's transaction. If Segwit nodes commands more than 60% of hash power, then core mining nodes will never be able to spend Alice's coins, because all their blocks are orphaned. And there will never be a fork

Wrong.  An old and a new node will have the coins at exactly the same places.  The UTXO set will be identitcal.

(Correction: Before the fork condition is reached, e.g. 75% hash power supporting segwit, segwit nodes will not generate and accept new transaction format, so the system is still safe. And after the fork, the attacker need more than 25% of hash power from segwit nodes to push in such an invalid block, since the other 25% of old nodes' hash power will assist to write the block into the chain)

Segwit will not be activated until 95% of all hashpower support it, like with all soft forks.

Please educate yourself about segwit and bitcoin in general.  Have you been on Reddit or something?