Soft Fork | Can the users who didn't update their client still mine blocks?

[mkhan.mushahid]

In case of a soft fork, users who don't update their client software will still be able to see new blocks being mined but will they be able to mine blocks themselves?

If no , then was Bitcoin's SegWit softfork an exception? Because as far as I know, even the ones who didn't update their software can still mine blocks.
If yes, wouldn't it lead to two types of blocks being mined?

[1714018228]

1714018228

[1714018228]

1714018228

[1714018228]

1714018228

[1714018228]

1714018228

[BlackHatCoiner]

In case of a soft fork, users who don't update their client software will still be able to see new blocks being mined but will they be able to mine blocks themselves?

Nodes that don't have the updated version of a Bitcoin client will reject any blocks that will contain SegWit transactions. Thus, they'll follow their own chain that will quickly become abandoned.

If no , then was Bitcoin's SegWit softfork an exception?

It wasn't an exception, it was as being said, a “soft fork”. It means that it is backwards-compatible, but the majority of the miners have to agree upon the new rules.

If yes, wouldn't it lead to two types of blocks being mined?

Well, if the majority of the miners switched to other rules, then the old chain would be abandoned and there'd be less effort given to it which would make block generation slower. But, I guess that theoretically, yes. The “old” nodes could continue mining with their own rules.

Note that the reason for Bitcoin Cash's creation was a minority that disagreed with SegWit. An expert could correct me if that's false.

[pooya87]

Yes but at a slightly reduced security because the (miner's) node that is not upgraded can not fully verify previous block that the miner wants to build on so they will essentially rely on cost of mining a bad block being high.
They can also reject the non-standard new transactions (eg. the transactions spending a SegWit output) to avoid risking inclusion of a fake transaction in the block they mine.

Nodes that don't have the updated version of a Bitcoin client will reject any blocks that will contain SegWit transactions. Thus, they'll follow their own chain that will quickly become abandoned.

Technically if an old client receives a block containing SegWit transactions rejects it because it can not deserialize that block (SegWit txs have a 0001 flag that old client would interpret as tx having 0 inputs and be invalid). But old clients receive stripped blocks that don't contain any witness (or that flag) and they will accept these blocks as valid. Which is why there is no chain split as you suggested after SegWit softfork and any old client is still on the same chain as others.

[mkhan.mushahid]

I am confused. Let's start again. I am in 2018. I haven't updated my software yet after the SegWit Update. Can I successfully continue mining and get bitcoins as a reward?

[vjudeu]

1. You cannot mine new blocks. If you will, they will be rejected by new nodes.
2. Yes, your node will receive Segwit blocks and accept them as valid (without processing Segwit signatures).
3. There is small risk that your node will switch to some chain that will be invalid (for example will include Segwit spending transaction without any signatures or with invalid signatures), but will have more Proof of Work.

[ranochigo]

The blocks in Bitcoin contains a version field. It was used for soft fork signalling by the miners to indicate support for the various forks and new rules/features. Mining a block that is below Version 4 will result in the reference client rejecting them; though ASICBoost introduced quite a variety of alien versionbits, support for Taproot is still signalled via that with speedy activation. I believe Core still checks for the minimum nVersion of the blocks and generating a block with an old client could potentially produce blocks that can be invalid.

[DannyHamilton]

I am confused.

This is probably because the answer is Yes, and No, and more importantly Maybe.

It all depends on exactly how the soft fork is implemented.

It is entirely possible to implement some soft-fork changes in a way that is 100% backwards-compatible, so that miners running the old software can still participate.  It's also possible to implement some soft-fork changes in a way that prevents miners from participating with old software.  So, in the end, it comes down to the specific implementation details of the exact change that you want to know about.

For example, let's imagine that a soft-fork is implemented that restricts block sizes to a maximum of 250KB.  This is backwards compatible with existing nodes and wallets since they'll already accept blocks of any size from a few hundred bytes to well over a megabyte.  So, everyone (regardless of whether they are on the old or new software) will accept these smaller blocks from the new software. However, if the vast majority of miners and nodes on the new software are treating any block larger than 250KB as invalid, then a miner running the old software runs a significant risk of creating a block that is too large and having his block rejected by everyone on the new software.  Any node or other miner that is ALSO still running the old software will temporarily accept his block, creating a temporary fork. However, since there isn't much mining power behind that fork, eventually (probably within a block or two) the chain built by the miners on the new software will grow longer than the fork with the "big block" from the old software.  At that point, ALL nodes (regardless of whether they are tunning the new or old software) will abandon the fork with the "big block", so the miner will not receive any spendable bitcoins.

Now, lets imagine a softfork that takes an "anyone can spend" transaction type and turns it into a new transaction type where specific conditions MUST be met to spend the output. If something else isn't done (such as updating the block version number) to prevent miners on old software from participating, and the implementation of the new behavior isn't outside the capabilities of the original transaction type, then a miner on the old software can participate if they are willing to accept some risk. In general, he'll only receive valid transactions, since nodes on the new software are validating the transactions before they relay the transaction to him. So, he'll build a block using the transactions that he receives, solve the nonce, and then broadcast his solved block.  As long as he's only received valid transactions, his block will be accepted by everyone on the new software.  He is vulnerable to being attacked though.  If someone connects directly to his system and feeds him invalid transactions that look like "anyone can spend" to him, but actually fail the new conditions, he won't know.  He'll include these invalid transactions in his blocks and his blocks will be rejected by everyone else.  As such, it is in his interest to either update his software to participate in the new rules, OR modify his software to specifically REJECT blocks created by the new rules and thereby create a hard-fork altcoin that he can try to convince others to join.

[franky1]

unless the topic creator is a pool using an outdated stratum server.. this topic is redundant
no one solo mines from their personal PC. so its a null topic

however if the topic creator is a pool using outdated stratum software
there are a couple scenarios

firstly. ill explain. old software may not recognise new tx formats. but a lil code trick is implied that new transactions use a flag that basically says, accept it without validating it
and thus any transaction with this flag wont be validated. but will be auto-treated as good.

and so if the transaction is good, meets the rules the whole network validates and accepts. and old software just accepts without validation.. no chain split as everyone is accepting

but if the transaction is dodgy. (from a malicious pool that added in a bad tx)
whole network rejects the block but old software blindly accepts the block
so suddenly old software is at a different height with different block-tip hash

however in most cases the network then produces a good block of same block height and then builds ontop of that. in which case the old software realises the new block is on a different parent. and then orphans his accepted(dodgy) block and then uses the valid parent and child blocks to stay on the network as thats the new heighest blockheight/tip

the only time an old software would continue to build on bad blocks the rest of the network has rejected. is if the old software is getting blocks from a pool thats continually building on bad blocks.and the old software is not getting any different versions from any other peers

[gmaxwell]

Nodes that don't have the updated version of a Bitcoin client will reject any blocks that will contain SegWit transactions.

Not true.  Old nodes don't know how to process witness data, but their peers will remove it before handing them the blocks.

Note that the reason for Bitcoin Cash's creation was a minority that disagreed with SegWit. An expert could correct me if that's false.

Glad to provide a correction.

Not true, though BCH promoters have (due to dishonesty or confusion) tried to claim this was so later.  BCH was created in advance of segwit's activation, it's incompatible because they changed how the difficulty update worked, causing their difficulty to go very low and causing them to mine over 100k coins ahead of schedule. They made a number of other changes, e.g. eliminating the original Bitcoin signature scheme and making the segwit signature scheme mandatory.

They subsequently went on to make a number of other incompatible changes, such as eliminating the requirements that transactions can't spend outputs created by transactions later in blocks.

1. You cannot mine new blocks. If you will, they will be rejected by new nodes.

Nodes prior to segwit (and taproot) can continue to mine. They will not include segwit-using or taproot-using transactions, and leaving those out will reduce their income.  If a malicious (or broken) party mines a segwit or taproot invalid block any non-upgraded miners may begin mining a successor on that invalid tip, wasting their time, until that tip has been overtaken by enforcing miners.  Because of this it's not a good idea to mine with outdated software, but at least in the presence of these changes you can do so.

As danny points out, other softforks may be more or less compatible than the two this post discusses.

[franky1]

to truly correct the details of the segwit-bch (im a btc maximalist not an altnet lover)

this graph shows the actual flags in the actual blockchain and thus real proof of what happened rather then the social propaganda some people imply

what you see is the red line is the actual flag of wanting segwit
even upto mid july less than half wanted to flag for segwit

so what was then implemented was another flag to ask the network will they ignore non segwit(legacy blocks) to make the segwit flag appear as 100%

so thats the blue line. and when that got its lower threshold met for in june. it then triggered the ignoring/rejecting legacy blocks and only accept segwit blocks from july 23rd onwards
and as you can see the redline rose from 45% to 100%

at the start of august segwit locked in but the segwit transaction format rules were not activated yet
however the pools not doing segwit flags being rejected by the network made their own block at the same time segwit flat got to 100%
(the then started accepting legacy blocks again in september once segwit was locked in)


the first block of BCH and the second block were not seconds apart(no 100k blocks mad fast from fork) the second block was HOURS later. and so they had to reduce their difficulty because blocks were taking hours
.....
so looking at the chart and actual block data. you find the bch split occured due to those not flagging for segwit were pushed off the network(legacy blocks) before segwit actually got locked in.

the funnier part was those opposing segwit done so simply by using normal unedtited unupdated software without any flags.. basically running the normal rules of 2009-2017
however segwit required new software with new flags and then new temporary rules to ignore normal legacy blocks
and these segwit advocates were blaming non segwitters by saying the non segwitters didnt put in certain replay protections into their code..
..um old software already complied and used for years is default software so its the new software of segwit that should have had replay protections when segwit decides to fork away from default blocks

but hey even after 4 years many will prefer to say some social drama propaganda of those opposing segwit. even though the blockchain data shows which flag caused which changes to which versions of nodes.


but in short. if the segwit admiration brigade did not implement the blue line flag to mandate a fork. segwit would probably have remained stagnant at under 50% and never have been activated

i predict showing real blockchain data of flag statistics will earn me another ban. because the truth hurts too much

[pooya87]

but a lil code trick is implied that new transactions use a flag that basically says, accept it without validating it
and thus any transaction with this flag wont be validated.

This is wrong. There is no "flag". The old clients simple don't know that they have to take additional steps. This has been true about all previous soft forks that changed something in scripts.
For example:
- P2SH: old clients don't know they have to interpret top stack element as a redeem script, they see it as a simple hash and equality comparison.
- OP_CLV: old client don't know they have to interpret the stack element as a locktime, they treat it as OP_NOP
- SegWit: old clients simply see it as 2 push OPs (OP_0 and some arbitrary data that casts to true), they don't know it has to be converted to a script
- Taproot: old clients simply ignore anything in witness

Among these SegWit is slightly difference since the actual translation has to be stripped, but after that the behavior is the same.

[gmaxwell]

but a lil code trick is implied that new transactions use a flag that basically says, accept it without validating it
and thus any transaction with this flag wont be validated.

This is wrong. There is no "flag". The old clients simple don't know that they have to take additional steps. This has been true about all previous soft forks that changed something in scripts.
For example:
- P2SH: old clients don't know they have to interpret top stack element as a redeem script, they see it as a simple hash and equality comparison.
- OP_CLV: old client don't know they have to interpret the stack element as a locktime, they treat it as OP_NOP
- SegWit: old clients simply see it as 2 push OPs (OP_0 and some arbitrary data that casts to true), they don't know it has to be converted to a script
- Taproot: old clients simply ignore anything in witness

Among these SegWit is slightly difference since the actual translation has to be stripped, but after that the behavior is the same.

The conclusion you reach is right, but pedantically the old software does know that the transactions are doing something they don't understand.  This, however, doesn't cause them to skip any validation: they do all the same validation they always did.  They don't, as you note, do the *additional* steps added by the change, as they have no idea what they are.  But whenever at all possible softforks in Bitcoin are designed so that old nodes still know something new is going on-- and this allows them to avoid relaying, avoid displaying in wallets until confirmed, and avoid mining them (as they might be invalid with respect to the new rules the new rules).

This is possible because the community (and Satoshi) carved out a bunch of the unused encoding space of transactions for the purpose of encoding new features using it. Older nodes (even going back to Satoshi) recognize the use of new stuff and understand the risks.
 

[NotATether]

I am confused. Let's start again. I am in 2018. I haven't updated my software yet after the SegWit Update. Can I successfully continue mining and get bitcoins as a reward?

TL;DR summary of the above posts:

If your mining software is connected to an old bitcoind version, and meanwhile new version bits are activated, you will still be able to mine blocks but you will be unable to include transactions which require the new version bits, because you don't know how to verify them.

This also applies to segwit I.e, you can mine blocks but can't include any segwit transactions because the old bitcoind doesn't understand how to verify them.

[franky1]

but a lil code trick is implied that new transactions use a flag that basically says, accept it without validating it
and thus any transaction with this flag wont be validated.

This is wrong. There is no "flag".

..OPs (OP_0 and some arbitrary data that casts to true),

i say flag you say op code.  .. analogy=same thing. just different buzzwords

segwit transactions are blindly accepted because they use the "opcode" trick
happy now that im more grammatically friendly
even though the point is still the same

[DaveF]

As with many things, just because you can does not mean you should.
And actually you really SHOULD NOT do it.
Since nobody else flat out said it, figured it was worth putting out there.

You can get an older version of bitcoind and then get some older stratum server / pool software to work.
But please, don't do it. You stand a really good chance of having other issues and loosing BTC.

-Dave

[PrimeNumber7]

For example, let's imagine that a soft-fork is implemented that restricts block sizes to a maximum of 250KB.  This is backwards compatible with existing nodes and wallets since they'll already accept blocks of any size from a few hundred bytes to well over a megabyte.  So, everyone (regardless of whether they are on the old or new software) will accept these smaller blocks from the new software. However, if the vast majority of miners and nodes on the new software are treating any block larger than 250KB as invalid, then a miner running the old software runs a significant risk of creating a block that is too large and having his block rejected by everyone on the new software.  Any node or other miner that is ALSO still running the old software will temporarily accept his block, creating a temporary fork. However, since there isn't much mining power behind that fork, eventually (probably within a block or two) the chain built by the miners on the new software will grow longer than the fork with the "big block" from the old software.  At that point, ALL nodes (regardless of whether they are tunning the new or old software) will abandon the fork with the "big block", so the miner will not receive any spendable bitcoins.

Now, lets imagine a softfork that takes an "anyone can spend" transaction type and turns it into a new transaction type where specific conditions MUST be met to spend the output. If something else isn't done (such as updating the block version number) to prevent miners on old software from participating, and the implementation of the new behavior isn't outside the capabilities of the original transaction type, then a miner on the old software can participate if they are willing to accept some risk. In general, he'll only receive valid transactions, since nodes on the new software are validating the transactions before they relay the transaction to him. So, he'll build a block using the transactions that he receives, solve the nonce, and then broadcast his solved block.  As long as he's only received valid transactions, his block will be accepted by everyone on the new software.  He is vulnerable to being attacked though.  If someone connects directly to his system and feeds him invalid transactions that look like "anyone can spend" to him, but actually fail the new conditions, he won't know.  He'll include these invalid transactions in his blocks and his blocks will be rejected by everyone else.  As such, it is in his interest to either update his software to participate in the new rules, OR modify his software to specifically REJECT blocks created by the new rules and thereby create a hard-fork altcoin that he can try to convince others to join.

In both of these examples, the miner is risking generating an invalid block. In the case of a soft fork limiting the maximum block size, miners will try to maximize their revenue, and will include transactions fill their block. In the case of a soft fork restricting a previously 'anyone-can-spend' transaction, the miner is at risk of allowing someone to spend an output they should not be able to spend according to the soft fork rules.

A soft fork will always restrict some subset of transactions so that transactions that were previously valid are now invalid. A non-upgraded node is going to verify all post-soft-fork blocks as valid (assuming they are valid), and will have knowledge of the correct blockchain as long as he is connected to at least one honest node, and there is no 51% attack involving miners generating blocks violating soft fork rules. This leaves not-upgraded nodes vulnerable to sybil  and 51% attacks, but I don't see any reason why these attackers would not follow soft fork rules.

A miner running a non-upgraded node is at risk of including a now-invalid transaction in their blocks. There is a chance a miner running a non-upgraded node will produce only invalid blocks in production. This lowers the chance of a miner running a non-upgraded node of receiving an invalid block to close to zero.

[pooya87]

A soft fork will always restrict some subset of transactions so that transactions that were previously valid are now invalid.

Not necessarily true. The change can be anything, whether expansion or restriction of the rules.
I don't like different definitions of soft/hard fork because they usually don't match the reality. The best definition of a soft/hard fork IMO is this:
A soft fork is a change in protocol where old clients don't have to upgrade but in a hard fork they have to upgrade.

[PrimeNumber7]

A soft fork will always restrict some subset of transactions so that transactions that were previously valid are now invalid.

Not necessarily true. The change can be anything, whether expansion or restriction of the rules.
I don't like different definitions of soft/hard fork because they usually don't match the reality. The best definition of a soft/hard fork IMO is this:
A soft fork is a change in protocol where old clients don't have to upgrade but in a hard fork they have to upgrade.

If rules are relaxed, a transaction (or block) that was valid prior to the fork, may be valid after the soft fork. This means that a node that has not upgraded after a soft fork would believe an invalid transaction is invalid that is in fact valid under post fork rules. This means a soft fork cannot relax transaction/block rules.

You cannot provide any examples of a soft fork that removed or relaxed rules for transactions or blocks.

[gmaxwell]

A miner running a non-upgraded node is at risk of including a now-invalid transaction in their blocks.

It depends on the construction of the soft-fork. Whenever possible the softforks constructed by the community don't pose that risk because they use explicit forward compatibility -- old code will know to not mine those transactions.

(Their risk, instead, is following an invalid block should someone create one, e.g. because they were malicious or because they incompetently edited their software and broke the protection)

The change can be anything, whether expansion or restriction of the rules.

I'm mystified why you would say this, perhaps you are confusing rules with the system's capabilities?

Bitcoin is a system of restrictions-- every capability comes from something it won't allow you to do.  Imagine bitcoin without restriction-- it would have no scarcity!

So softforks can only restrict the set of things considered valid, fortunately that's exactly what one needs to do to add new capabilities.

[pooya87]

I'm mystified why you would say this, perhaps you are confusing rules with the system's capabilities?

Bitcoin is a system of restrictions-- every capability comes from something it won't allow you to do.  Imagine bitcoin without restriction-- it would have no scarcity!

Maybe I'm having trouble with the English language but "to restrict" sounds like limiting the existing rules, I prefer calling it "to change" the rules which may even include expansion of the rules. For example sigop count was already a restriction in protocol and SegWit didn't restrict it more, instead it changed how it works.

So softforks can only restrict the set of things considered valid, fortunately that's exactly what one needs to do to add new capabilities.

Lets consider SegWit transactions; to a pre-SegWit node any transaction that starts with 010000000001... (has the 2 byte SegWit flag) is an invalid transaction because the decoder sees this as a tx with 0 inputs. So we changed the existing restrictions or rather expanded "the set of things considered valid" we didn't restrict/limit it.

Or the block size which answers the following too:

You cannot provide any examples of a soft fork that removed or relaxed rules for transactions or blocks.

Before SegWit any block that was bigger than 1,000,000 bytes in size was invalid, this rule was completely removed and new computation took its place and today blocks can be as big as almost 4,000,000 byte in size (I'm not talking about weight but raw bytes).

This is why I think definition of a soft/hard fork should not be about these restrictions but about whether or not the old nodes are forced to upgrade.