Questions about soft fork

[BlackHatCoiner]

I've had a time comprehending the main difference between soft fork and hard fork. Please correct me: a soft fork means stricter rules. Taking the current rules, and adding more, but without invaliding the previous. For instance, SegWit was a soft fork, because it added another rule which, according to the non-upgraded clients was valid.

Question: is the invalidation of an old, valid rule considered part of soft fork? Yes, according to the wiki. So, you can mine an invalid block, that is valid in old clients terms, and broadcast it in the old client network. Does that encourage old clients to switch to new version, since they might hear on blocks that are likely to reorg? What could be the excuse of a non-Segwit node to stay in non-Segwit?

[1714637350]

1714637350

[1714637350]

1714637350

[1714637350]

1714637350

[1714637350]

1714637350

[1714637350]

1714637350

[ymgve2]

A soft fork is backwards compatible and works transparently with older software. A hard fork is not backwards compatible and breaks older software.

[hosseinimr93]

If the change is backward compatible, it's a soft fork.
For example, the taproot upgrade was a soft fork, because you didn't have to upgrade your software and you could still use the older version of bitcoin core. If you are a miner, you can still mine the blocks with an old version of bitcoin core. (Of course, if you are miner and use an old version of bitcoin core, you would miss taproot transactions).

If the change isn't backward compatible, it's a hard fork. For example, in 2010 there was an upgrade for fixing a bug and all nodes had to upgrade their software.

[pooya87]

Please correct me: a soft fork means stricter rules. Taking the current rules, and adding more, but without invaliding the previous.

Correct. Soft fork is all about adding more rules/restrictions to the consensus rules. We could view it as limiting the number of things that are valid. For example previously dummpy item for OP_CHECKMULTISIG could be anything including OP_0 but now it is limited to only OP_0.

Does that encourage old clients to switch to new version, since they might hear on blocks that are likely to reorg?

It should because they can no longer be considered Full [Verification] Nodes since they no longer "verify everything".

What could be the excuse of a non-Segwit node to stay in non-Segwit?

I can think of two reasons:
1. Laziness
2. Trying to avoid bugs in new releases eg. (usually done by running multiple versions)

[odolvlobo]

I've had a time comprehending the main difference between soft fork and hard fork. Please correct me: a soft fork means stricter rules. Taking the current rules, and adding more, but without invaliding the previous. For instance, SegWit was a soft fork, because it added another rule which, according to the non-upgraded clients was valid.

Question: is the invalidation of an old, valid rule considered part of soft fork? Yes, according to the wiki. So, you can mine an invalid block, that is valid in old clients terms, and broadcast it in the old client network. Does that encourage old clients to switch to new version, since they might hear on blocks that are likely to reorg? What could be the excuse of a non-Segwit node to stay in non-Segwit?

It is more accurate to say that the new rules in a soft fork are more restrictive. That is, things that were once valid are no longer necessarily valid after the fork.

The interesting twist is that features have been added in a soft fork by taking an instruction that is always valid and always succeeds -- NOP, and changing its meaning so that it may now fail.

It is important to note that a majority of miners must adopt the soft fork in order for it to work. If a majority of miners do not adopt the soft fork, then a transaction that is not valid according to the rules of the soft fork will still be valid because the longest chain would still treat the new instructions according to the old rules.

[pooya87]

It is important to note that a majority of miners must adopt the soft fork in order for it to work. If a majority of miners do not adopt the soft fork, then a transaction that is not valid according to the rules of the soft fork will still be valid because the longest chain would still treat the new instructions according to the old rules.

That is not specific to soft-forks only, any kind of change that can create a chain split needs the supermajority of the network to reach consensus otherwise there will be a chain split.

[Wind_FURY]

Does that encourage old clients to switch to new version, since they might hear on blocks that are likely to reorg?

Miners especially, yeah they should upgrade, or else their blocks will be rejected by full nodes that enforce Segwit.

For Users/Full nodes, a question, "Are non-Segwit nodes still considered to be full nodes"?

What could be the excuse of a non-Segwit node to stay in non-Segwit?

I would like to read a technical post/discussion from n0nce, d5000, or DooMAD about valid excuses to stay non-Segwit. Because many of the reasons why currently some groups' want to stay non-Segwit are political/philosophical reasons like Mircea Popescu and his followers.

[BlackHatCoiner]

It should because they can no longer be considered Full [Verification] Nodes since they no longer "verify everything".

Right. Past-softfork nodes don't follow the new rules, so they don't check for the new rules during verification.

Because many of the reasons why currently some groups' want to stay non-Segwit are political/philosophical reasons like Mircea Popescu and his followers.

It's kinda unsafe. Think of this: you're a miner who wants to trick some client who runs a non-Segwit node. You can take any UTXO you don't own and spend it to their address with an invalid signature. They can't verify the signature, so including it in a block is considered valid to them. Of course, it's soon going to be reorged, because no miner will build on top of a non-Segwit chain.

[tromp]

So, you can mine an invalid block, that is valid in old clients terms, and broadcast it in the old client network. Does that encourage old clients to switch to new version, since they might hear on blocks that are likely to reorg?

The reason that soft-forks work, is that they are enforced by a hashing majority. So in your example, the hashrate majority of miners will ignore the invalid block and will end up reorging it.
That's how old clients are forced into the new rules that they're not even aware of.

[Wind_FURY]

Because many of the reasons why currently some groups' want to stay non-Segwit are political/philosophical reasons like Mircea Popescu and his followers.

It's kinda unsafe. Think of this: you're a miner who wants to trick some client who runs a non-Segwit node. You can take any UTXO you don't own and spend it to their address with an invalid signature. They can't verify the signature, so including it in a block is considered valid to them. Of course, it's soon going to be reorged, because no miner will build on top of a non-Segwit chain.

Then that's where we prove that Bitcoin's incentive structure actually works. Why would a miner act dishonestly, and waste computing cycles, if he/she can just mine honestly and be paid in Bitcoin as a reward for doing his/her job for the network?

[digaran]

The reason that soft-forks work, is that they are enforced by a hashing majority. So in your example, the hashrate majority of miners will ignore the invalid block and will end up reorging it.
That's how old clients are forced into the new rules that they're not even aware of.

That's how bitcoin consensus should work, right? Meaning non-mining nodes should be forced into accepting what the hash rate majority(miners) want or desire?

Do we even have a case where nodes force miners into accepting their desired changes?

[pooya87]

That's how bitcoin consensus should work, right? Meaning non-mining nodes should be forced into accepting what the hash rate majority(miners) want or desire?

Do we even have a case where nodes force miners into accepting their desired changes?

No, this is not how things work. Bitcoin as a system consists of all groups and each have a say in this decentralized currency's future. Nodes, miners, businesses, investors, etc. One group can't really force other groups into something they don't want.
The best example in 2017 where the hard fork step in SegWit2x proposal had a huge support from miners but only had minimal support from everyone else. Consequently it failed.

[kano]

That's how bitcoin consensus should work, right? Meaning non-mining nodes should be forced into accepting what the hash rate majority(miners) want or desire?

Do we even have a case where nodes force miners into accepting their desired changes?

No, this is not how things work. Bitcoin as a system consists of all groups and each have a say in this decentralized currency's future. Nodes, miners, businesses, investors, etc. One group can't really force other groups into something they don't want.
The best example in 2017 where the hard fork step in SegWit2x proposal had a huge support from miners but only had minimal support from everyone else. Consequently it failed.

Unfortunately vague statements trying to bend reality.

Consensus means mining consensus.

Bitcoin is PoW not PoS.

The one an only time that users have had an strong effect on changes against mining, was the falsely named segwit.

In the end the miners agreed to go ahead with it due to the fact that core was trying to push it anyway without consensus.
This is a documented fact in the way segwit was planned to happen.

I'd also imagine that at the same time, core may not have gone ahead with it without the miner's agreement since it could have lead to a fork and core being on a very low security tiny side of that fork, fortunately that didn't get tested and mining agreed to accept segwit.

As for soft forks and backward compatibility, alas that is a misunderstanding and a false claim.
It is sometimes the case that those who stay on the pre soft-fork software, can be accepting of invalid transactions.
Basically a soft fork means: screw the miners if they don't update, but the blocks will 'usually' be valid on the longest chain - as proven in July 2015

[pooya87]

Unfortunately vague statements trying to bend reality.
The one an only time that users have had an strong effect on changes against mining, was the falsely named segwit.

You are contradicting yourself by claiming my statement about "users having an affect" is bending reality while admitting that "users have a strong effect"!

In the end the miners agreed to go ahead with it due to the fact that core was trying to push it anyway without consensus.

Wrong.
A small minority of nodes and miners that were less than 10% of the whole Bitcoin network were enforcing an attack known as BIP148. It would have never succeeded even if SegWit hadn't been activated when it did simply because they were the minority and would have created an altcoin.

[BlackHatCoiner]

Consensus means mining consensus.

It doesn't. If it were mining consensus that we have, then we wouldn't have built off-chain solutions. If miners could coordinate to increase the blocksize to infinity with no userbase effects, they would. So here you either argue the miners control the network (ergo, mining consensus), or you argue that the miners want small blocks, both of which seem wrong to me. It is pretty clear to me that the Bitcoin community is consisted of legitimate users who won't go along with miners' decisions without questioning.

[Wind_FURY]

That's how bitcoin consensus should work, right? Meaning non-mining nodes should be forced into accepting what the hash rate majority(miners) want or desire?

Do we even have a case where nodes force miners into accepting their desired changes?

No, this is not how things work. Bitcoin as a system consists of all groups and each have a say in this decentralized currency's future. Nodes, miners, businesses, investors, etc. One group can't really force other groups into something they don't want.

The best example in 2017 where the hard fork step in SegWit2x proposal had a huge support from miners but only had minimal support from everyone else. Consequently it failed.

Plus his post can be also be debated that it was the full non-mining nodes, as illustrated by the UASF, that forced the miners into activating Segwit in the first place. Why? Because it's the full non-mining nodes that give demand for what the miners are incentivized to produce = The Blocks.

[pooya87]

as illustrated by the UASF, that forced the miners into activating Segwit in the first place.

UASF might have acted as an extra push to encourage everyone into accepting SegWit but it definitely didn't "force" anybody to do anything considering that to "force" the network into accepting a proposal they had to be a lot more than 5-10% of the network!

[Wind_FURY]

as illustrated by the UASF, that forced the miners into activating Segwit in the first place.

UASF might have acted as an extra push to encourage everyone into accepting SegWit

It wasn't the extra push. It WAS the Actual Push. The probability of Segwit's activation would be very low without the UASF, because the miners objected against it the upgrade. Whatever their reason was, I believe gmaxwell's theory might be one of the biggest reasons = ASIC Boost.

but it definitely didn't "force" anybody to do anything considering that to "force" the network into accepting a proposal they had to be a lot more than 5-10% of the network!

The UASF was actually gaining support further towards "Independence Day," with Eric Lombrozo and other Core developers starting to be louder in their support. Plus if it took not more than 5-10% of the network, the intolerant minority, to make the miners notice/listen, then I believe it's a success. It's not just the miners who can enforce the rules.

Plus if we were back during 2017, where would the majority of us in BitcoinTalk lend our support? To Jihan Wu, Roger Ver, and the signatories of the New York Agreement? Or to the Core Developers?

[pooya87]

Plus if we were back during 2017, where would the majority of us in BitcoinTalk lend our support? To Jihan Wu, Roger Ver, and the signatories of the New York Agreement? Or to the Core Developers?

To none of them as we should.
The support should be with the majority even if the majority isn't going for a proposal which was the case with BIP148. Bitcoin can not and will not survive if the minority succeeds to enforce its opinion on the rest of the network. After all that is the main reason why we consider bcash a shitcoin!

[Wind_FURY]

Plus if we were back during 2017, where would the majority of us in BitcoinTalk lend our support? To Jihan Wu, Roger Ver, and the signatories of the New York Agreement? Or to the Core Developers?

To none of them as we should.

The support should be with the majority even if the majority isn't going for a proposal which was the case with BIP148. Bitcoin can not and will not survive if the minority succeeds to enforce its opinion on the rest of the network. After all that is the main reason why we consider bcash a shitcoin!

But we can't, or shouldn't, speak for all of them, no? The UASF/BIP-148 was merely a proposal on how to have Segwit activated, an upgrade that many people in the Bitcoin community truly wanted. Plus if it's your opinion that 5-10% couldn't force the miners to activate an upgrade, OK. But it did with Segwit, because there was unquestionably more than 5-10% of the Economic Majority that actually wanted Segwit. It wasn't like the laughable BCash.