Topic: Why soft fork is a very bad idea and should be avoided at all costs - page 3. (Read 6768 times)

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.

Soft fork deployment of 95% will happen. No fork deployed by developers will ever deploy without some sort of block 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.

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?


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.


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?

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.

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

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

This. I hope it never comes so far

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

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.)

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 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 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



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)

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

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 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

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%.

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?

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.

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

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

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.

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.

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.

How so?

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

Segwit just ain't Bitcoin.

What matters most to the user is that their own bitcoin transactions are verified. Anyone running these nodes are not compatible with many soft forks currently running.  They don't care because it's not any transactions that involve their own bitcoin.  Soft forks preserve every users' choice whether or not to opt in, whereas hard forks break this capability -- along with introducing other unknowable systemic risks, but that's for another post.