Author

Topic: Questions about soft fork (Read 718 times)

legendary
Activity: 2898
Merit: 1823
August 18, 2023, 05:12:05 AM
#44
Disregards the majority? Although BIP-148 was controversial, SegWit was still wanted by the majority. It only became a necessary "movement", or a kind of "mechanism" for SegWit's activation, because Jihan Wu and the mining cartel were playing political games by using miner signalling as a political tool which delayed activation.

"want" can not be some abstract idea in a decentralized ledger. It must be explicitly expressed through voting and any proposal that requires/enforces a fork like BIP16, BIP148, BIP341, etc. must be activated after checking those votes. BIP148 does NOT do that!

In other words whether or not the majority wanted SegWit is irrelevant since BIP148 did not even care about that which is what leads to chain-splits!


Of course it doesn't do that and of course there were risks, BUT without the actual campaign for a UASF, there wouldn't have been a BIP-149, or the NYA, or the economic majority and the users wouldn't have started to have the urgency to want for SegWit to be activated. The miners would have delayed it further, playing political games by using signalling as their tool.
hero member
Activity: 1111
Merit: 588
August 17, 2023, 11:19:58 AM
#43
My bad , by miners i mean mining nodes/pools .
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
August 17, 2023, 08:54:13 AM
#42
Voting requires permission.  Running code to enforce network rules is an enactment of will.  The consensus mechanism then allows those who agree on a common ruleset to build a chain together.  In practice, it's a very different concept to voting, in the traditional sense.
The question at hand is how users of a decentralized protocol will collectively determine which ruleset to uphold. Running the software represents an expression of intention, although its execution would be significantly swayed if there was a way for us all to convene and acknowledge the prevailing majority's preferences. We probably can't do that efficiently, so we have to separately run software, and see the consequences later.

That, alone, is a disincentive to separate networks by hard forking. The consensus we currently have is invaluable. The risk of introducing turmoil to the current state of the network outweighs any potential benefits.
legendary
Activity: 3472
Merit: 10611
August 17, 2023, 08:30:15 AM
#41
Disregards the majority? Although BIP-148 was controversial, SegWit was still wanted by the majority. It only became a necessary "movement", or a kind of "mechanism" for SegWit's activation, because Jihan Wu and the mining cartel were playing political games by using miner signalling as a political tool which delayed activation.
"want" can not be some abstract idea in a decentralized ledger. It must be explicitly expressed through voting and any proposal that requires/enforces a fork like BIP16, BIP148, BIP341, etc. must be activated after checking those votes. BIP148 does NOT do that!

In other words whether or not the majority wanted SegWit is irrelevant since BIP148 did not even care about that which is what leads to chain-splits!
legendary
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
August 17, 2023, 07:44:19 AM
#40
vote

Before we get too in depth, I'd pause to question this particular aspect.  I believe when satoshi used the word "vote" in the whitepaper, it was in order for people to latch on to an existing concept that they understand.  I don't think it was intended to imply that consensus is akin to voting, though. 

Voting requires permission.  Running code to enforce network rules is an enactment of will.  The consensus mechanism then allows those who agree on a common ruleset to build a chain together.  In practice, it's a very different concept to voting, in the traditional sense.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
August 17, 2023, 07:28:05 AM
#39
Nope , there isn't . Imagine voting in a country that has no electoral catalogues and anyone could vote as many times he want , could you ever have a valid election ?
Absolutely not, and this is fundamentally how a UASF works.

That's why miners are the best choice . They are known and you can see if you agree or disagree with their choice
First of all, miners don't have to be known. There is already a fair percentage of miners who are anonymous. We only know that the majority of the hash rate comes from known pools. Secondly, if I can't vote, how can the miner know if he's made the right choice?
legendary
Activity: 2898
Merit: 1823
August 17, 2023, 03:43:01 AM
#38
Taken in the right context, the reason why I emphasized that the Core Developers supported an idea is precisely because of the merit behind the idea - at that time.

The abstract idea of nodes voicing their preference is a good one with merit but BIP148 is not and it is instead a dangerous proposal because of a simple fact that it disregards majority. It simply has no way of checking or caring what the majority says, whether it is 1% or 99% it will enforce the change!

In any change, regardless of what it is, we must reach consensus amongst network participants otherwise it goes against the idea of being decentralized.


Disregards the majority? Although BIP-148 was controversial, SegWit was still wanted by the majority. It only became a necessary "movement", or a kind of "mechanism" for SegWit's activation, because Jihan Wu and the mining cartel were playing political games by using miner signalling as a political tool which delayed activation.
hero member
Activity: 1111
Merit: 588
August 16, 2023, 03:37:56 PM
#37
There has to be a way of collectively voting for a change without giving absolutely every voting power to the miners, isn't there?

Nope , there isn't . Imagine voting in a country that has no electoral catalogues and anyone could vote as many times he want , could you ever have a valid election ?
That's a problem that anonymity causes , to have a valid/honest result you would need known entities . That's why miners are the best choice . They are known and you can see if you agree or disagree with their choice . The economic incentive will drive them to decide the best for the network or they will lose clients and profit .

legendary
Activity: 1512
Merit: 7340
Farewell, Leo
August 16, 2023, 12:46:21 PM
#36
The abstract idea of nodes voting for a change by just running a full node software is just terrible, in my opinion. The majority isn't determined by the number of Bitcoin clients, for if it was, we wouldn't have mining; we'd select the order of the transactions by voting as in Proof-of-Stake, but with instances of Bitcoin clients instead of money.

There has to be a way of collectively voting for a change without giving absolutely every voting power to the miners, isn't there?
legendary
Activity: 3472
Merit: 10611
August 16, 2023, 07:33:36 AM
#35
Taken in the right context, the reason why I emphasized that the Core Developers supported an idea is precisely because of the merit behind the idea - at that time.
The abstract idea of nodes voicing their preference is a good one with merit but BIP148 is not and it is instead a dangerous proposal because of a simple fact that it disregards majority. It simply has no way of checking or caring what the majority says, whether it is 1% or 99% it will enforce the change!

In any change, regardless of what it is, we must reach consensus amongst network participants otherwise it goes against the idea of being decentralized.
legendary
Activity: 2898
Merit: 1823
August 16, 2023, 06:16:05 AM
#34
There were Core Developers who supported it.
That's never a valid argument if you ask me. For one, we have had Gavin Andresen and Mike Hearn were also core developers once and they both went nutz and made questionable moves and statements. One supporting faketoshi and the other spreading FUD about bitcoin... Grin

Ideas are best judged on merit and not by which individuals support them.  It's not a popularity contest and we don't need to introduce a cult-of-personality element.  Appeals to authority aren't the correct method for network governance.

As for what's considered an "attack", that's always going to be subjective.  Some ideas are more reckless or dangerous than others, but ultimately it's all just people doing what they want to do. 


Taken in the right context, the reason why I emphasized that the Core Developers supported an idea is precisely because of the merit behind the idea - at that time. The Scaling Debate was a unique period in Bitcoin's history, which probably no one in the community knew what move was truly going to be the right move. I could only imagine how enlightening it was for everyone directly involved.
legendary
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
August 15, 2023, 08:22:50 AM
#33
There were Core Developers who supported it.
That's never a valid argument if you ask me. For one, we have had Gavin Andresen and Mike Hearn were also core developers once and they both went nutz and made questionable moves and statements. One supporting faketoshi and the other spreading FUD about bitcoin... Grin

Ideas are best judged on merit and not by which individuals support them.  It's not a popularity contest and we don't need to introduce a cult-of-personality element.  Appeals to authority aren't the correct method for network governance.

As for what's considered an "attack", that's always going to be subjective.  Some ideas are more reckless or dangerous than others, but ultimately it's all just people doing what they want to do. 
legendary
Activity: 2898
Merit: 1823
August 15, 2023, 08:15:22 AM
#32
There were Core Developers who supported it.
That's never a valid argument if you ask me. For one, we have had Gavin Andresen and Mike Hearn were also core developers once and they both went nutz and made questionable moves and statements. One supporting faketoshi and the other spreading FUD about bitcoin... Grin


Valid argument or not, it's still not an attack. It was merely one of the mechanisms to have SegWit activated. When the miners were acting against the interest of the network, through BIP-148 it was shown that there are checks and balances, which prevents the centralization of power towards the mining cartel. It was a learning experience for those who were directly involved, and for the other participants of the network.
legendary
Activity: 3472
Merit: 10611
August 15, 2023, 07:06:34 AM
#31
There were Core Developers who supported it.
That's never a valid argument if you ask me. For one, we have had Gavin Andresen and Mike Hearn were also core developers once and they both went nutz and made questionable moves and statements. One supporting faketoshi and the other spreading FUD about bitcoin... Grin
legendary
Activity: 2898
Merit: 1823
August 15, 2023, 03:19:30 AM
#30
Jihan Wu and his friends from the mining cartel

They actually created the shitcoin called bcash using the same principles of BIP148, it was even called MASF (mocking the UASF thing). That is a minority group creating a fork disregarding the rest of the network (including miners' votes).

The miners don't speak for the whole network. If it did, then the network is centralized towards the Mining Cartel.

I never said they do anywhere! But you can't deny that miners are an important part of the network and attacks like BIP148 are completely ignoring/eliminating miners.


I never denied the importance of miners, but focusing the discussion during SegWit's activation, they did use miner-signalling as a political tool to delay, or even as an attempt to stop the soft fork. The UASF/BIP-148 was a necessary move to distribute power throughout the network.

Plus saying that, BIP-148 specifically, is an attack against the network is wrong. There were Core Developers who supported it. Some even preferred it.

https://en.bitcoin.it/wiki/Segwit_support

I'm sorry for the late reply, I didn't see your post.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
March 06, 2023, 11:39:46 AM
#29
This means that they will not be able to participate in transactions that require SegWit, and they may miss out on certain benefits such as lower fees.
Actually, they can. Constructing a SegWit transaction is possible regardless of the node you're running, even though I'm not sure if Core would allow you to do that.

A soft fork adds stricter rules, but they are still compatible with the old rules. Invalidating old, valid rules is not part of a soft fork
You've got it wrong. Invalidating the old rules is what's the soft fork is all about. These "stricter rules" you mention in the former sentence is the restriction of the old rules.
sr. member
Activity: 1022
Merit: 252
March 06, 2023, 10:54:44 AM
#28
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?

if a non-SegWit node wants to stay on the old version of the protocol, they can do so, but they will not be able to validate transactions that use the new SegWit rules. This means that they will not be able to participate in transactions that require SegWit, and they may miss out on certain benefits such as lower fees. A soft fork adds stricter rules, but they are still compatible with the old rules. Invalidating old, valid rules is not part of a soft fork
legendary
Activity: 990
Merit: 1108
March 05, 2023, 10:48:20 AM
#27
I sometimes hear the phrase "it breaks consensus" from hard fork critics. Did Bitcoin Cash break consensus?

Yes, they did, not just by allowing larger blocks, but by in fact *requiring* a block larger than 1MB in size.

As a result, BTC block 478559 was rejected by Bitcoin Cash for not exceeding 1MB [1]:

Code:
ERROR: AcceptBlock: bad-blk-too-small, size limits failed (code 16) (block 00000000000000000019f112ec0a9982926f1258cdcc558dd7c3b7e5dc7fa148)

It took a while longer for Bitcoin Cash to reach height 478559.

[1] https://connortumbleson.com/2017/08/02/bitcoin-cash-bcc-is-born/
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
March 05, 2023, 09:01:16 AM
#26
I sometimes hear the phrase "it breaks consensus" from hard fork critics. Did Bitcoin Cash break consensus? It surely upsets the network for a while, but if such upset were to break consensus, it isn't a strong consensus to begin with. Breaking backwards compatibility, technically speaking, does mean breaking consensus, but economically speaking, you are free to vote against the hard fork by selling the post-hardfork coins for the pre-hardfork.
legendary
Activity: 3472
Merit: 10611
March 04, 2023, 11:12:39 PM
#25
Jihan Wu and his friends from the mining cartel
They actually created the shitcoin called bcash using the same principles of BIP148, it was even called MASF (mocking the UASF thing). That is a minority group creating a fork disregarding the rest of the network (including miners' votes).

The miners don't speak for the whole network. If it did, then the network is centralized towards the Mining Cartel.
I never said they do anywhere! But you can't deny that miners are an important part of the network and attacks like BIP148 are completely ignoring/eliminating miners.
legendary
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
March 04, 2023, 06:50:31 PM
#24
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.

I didn't get the sense that many users were actually running a UASF-enabled client.  There was definitely a lot of noise, but I'm not sure how much of it was backed up by actions.  

Some of the UASF supporters were also engaged in this weird double-standard where they claimed that bcash was "stealing Core's code", yet they had to fork the GitHub themselves in order to create a UASF-enabled client.  Not to mention that you can't exactly "steal" open-source software which is shared freely.   Cheesy
legendary
Activity: 2898
Merit: 1823
February 27, 2023, 06:31:05 AM
#23
When you are thinking of BIP148 don't think about WHAT it activates, but think about HOW it activates it (or rather wants it activated) and maybe you understand my view better.


To put everything in context we are talking about Segwit = WHAT, and what happened during 2017 = HOW.

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.


You are confusing two separate matters. There is a difference between "wanting SegWit" and "wanting SegWit at any costs". Majority of people wanted SegWit but only a handful wanted it at any cost. And that is what BIP148 is, going against what has worked in all bitcoin soft-forks (eg reaching 95% majority) and splitting the network threatening bitcoin's security, reliability and blockchain's immutability just to activate SegWit.
In fact if you paid attention in those days you would have seen a lot of users state that they do not want SegWit IF it leads to a chain split.


Because why? Because Jihan Wu and his friends from the mining cartel were delaying, and politicizing the miner activation process instead of what truly its purpose is, which is just a signal to let everyone know that they are ready for an upgrade.

Shaolinfry made his proposal as a response, and "the rest is history", https://bitcointalksearch.org/topic/moving-towards-user-activated-soft-fork-activation-1805060

Every newbie who wants to learn more about Bitcoin should read that important proposal in that topic.

It wasn't like the laughable BCash.


It is like that more than you think. There is no clause in the proposal to check what the network thinks (ie. miner's vote), it just dictates that anybody who wants the change (whatever it is, whether SegWit or bcash or can be anything else in the future) can reject any block that doesn't activate it and split the chain!!!

That goes against everything bitcoin stands for and it is a malicious attack.


The miners don't speak for the whole network. If it did, then the network is centralized towards the Mining Cartel.
copper member
Activity: 821
Merit: 1992
February 26, 2023, 02:53:27 AM
#22
Also, we had the same kind of attacks for Taproot, but again, it was a minority: https://web.archive.org/web/20210416030248/https://bitcointaproot.cc/#faq
Quote
Is this a User-Activated SoftFork (UASF)?

No. This activation uses BIP 8 to ensure a safe and clean activation coordinated by miners. It is therefore a Miner-Activated SoftFork (MASF). However, it does not give miners the additional power to veto Taproot, and should miners neglect to coordinate an early activation, will still activate Taproot during late 2022. In that fallback scenario, it is accurate to consider it to have become a User-Activated SoftFork (UASF). Miners have publicly indicated that they also support Taproot themselves, so it is expected that activation under the normal MASF routine should proceed smoothly, and no UASF fallback will be needed.
So, it was not UASF only because things were activated by miners. But in case of not activating that, those users would cause a chain split.
legendary
Activity: 3472
Merit: 10611
February 25, 2023, 10:56:21 PM
#21
When you are thinking of BIP148 don't think about WHAT it activates, but think about HOW it activates it (or rather wants it activated) and maybe you understand my view better.

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.
You are confusing two separate matters. There is a difference between "wanting SegWit" and "wanting SegWit at any costs". Majority of people wanted SegWit but only a handful wanted it at any cost. And that is what BIP148 is, going against what has worked in all bitcoin soft-forks (eg reaching 95% majority) and splitting the network threatening bitcoin's security, reliability and blockchain's immutability just to activate SegWit.
In fact if you paid attention in those days you would have seen a lot of users state that they do not want SegWit IF it leads to a chain split.

It wasn't like the laughable BCash.
It is like that more than you think. There is no clause in the proposal to check what the network thinks (ie. miner's vote), it just dictates that anybody who wants the change (whatever it is, whether SegWit or bcash or can be anything else in the future) can reject any block that doesn't activate it and split the chain!!!
That goes against everything bitcoin stands for and it is a malicious attack.
legendary
Activity: 2898
Merit: 1823
February 25, 2023, 04:19:09 AM
#20
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.
legendary
Activity: 3472
Merit: 10611
February 24, 2023, 05:30:15 AM
#19
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!
legendary
Activity: 2898
Merit: 1823
February 24, 2023, 03:57:32 AM
#18
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.

Quote

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


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?
legendary
Activity: 3472
Merit: 10611
February 23, 2023, 10:44:25 AM
#17
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! Tongue
legendary
Activity: 2898
Merit: 1823
February 23, 2023, 07:43:09 AM
#16
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. Cool
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
February 23, 2023, 05:21:51 AM
#15
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.
legendary
Activity: 3472
Merit: 10611
February 23, 2023, 12:30:03 AM
#14
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"! Shocked

Quote
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.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
February 22, 2023, 11:27:47 PM
#13
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 Smiley
legendary
Activity: 3472
Merit: 10611
February 22, 2023, 11:02:02 PM
#12
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.
copper member
Activity: 1330
Merit: 899
🖤😏
February 22, 2023, 03:25:37 PM
#11

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?
legendary
Activity: 2898
Merit: 1823
February 21, 2023, 07:08:58 AM
#10


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? Cool
legendary
Activity: 990
Merit: 1108
February 21, 2023, 05:38:58 AM
#9
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.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
February 21, 2023, 05:29:15 AM
#8
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.
legendary
Activity: 2898
Merit: 1823
February 20, 2023, 11:09:24 PM
#7

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

Quote

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.
legendary
Activity: 3472
Merit: 10611
February 20, 2023, 06:21:07 AM
#6
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.
legendary
Activity: 4466
Merit: 3391
February 20, 2023, 04:31:40 AM
#5
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.

legendary
Activity: 3472
Merit: 10611
February 19, 2023, 11:38:38 PM
#4
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.

Quote
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".

Quote
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)
legendary
Activity: 2380
Merit: 5213
February 19, 2023, 02:21:44 PM
#3
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.
full member
Activity: 161
Merit: 230
February 19, 2023, 01:38:03 PM
#2
A soft fork is backwards compatible and works transparently with older software. A hard fork is not backwards compatible and breaks older software.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
February 19, 2023, 12:39:27 PM
#1
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?
Jump to: