Topic: Soft Fork | Can the users who didn't update their client still mine blocks? (Read 330 times)

seems gmax wants to cause more confusion
argument 1:
--there was never a "blocksize" limit in the rules of the system
--the system actually implemented a very specific rule which limited size in a very specific way

which is it
in short gmax(there are no rules) gmax(there are rules) thus debunking HIMSELF in under 1 sentence gap

argument 2:
--segwit took its place and blocks can be as big as almost 4,000,000 bytes in size
--weight is constructed in such a way that 4mill weight implies 1m size from the perspective of the old rule
--and yet old nodes say "any block bigger than 1,000,000 bytes in size is invalid"

so the rules are not specific. they are gludgy by doing a miscounting or division/multiplication trick  and removal of parts of transaction data for old nodes. and miscounting bytes for new nodes

even deeper debate can be that the "almost 4,000,000 bytes". does not and never will equate to an almost 4x transaction count of the 1mb pre2017 ruleset
..
so if gmax can clarify argument 1.. if there actually was a specific rule..
it would then help to clarify argument 2 about the gludgy math trick to make 1.5mb average right now appear as a 1mb rule to old nodes requires trimming off the witness(scripts)  and be 1mb of data with missing sections
but be 1.5mb of real hard drive on new nodes whilst being told its 4m weight
yep 1.5mb of real data being described as 4m weight. does not mean the blockchains 4m weight rule is a 4mb rule.. nor a "almost 4,000,000 bytes" as the true bytes are only ~1.5mb
hense cludgy

....
if he was simply trying to make a point about the human perspective vs the computer code rules.
he would have been far better using the raw tx, block data  vs cores GUI human visual. to say:

    Spoon boy : Do not try and spend the BTC. That's impossible. Instead... only try to realize the truth.
    Neo : What truth?
    Spoon boy : There is no BTC.
    Neo : There is no BTC?
    Spoon boy : Then you'll see, that it is not the BTC that spends, it is only your sats.

The txn as committed to by the transaction hash doesn't have that flag and *that* is what the rule actually enforces.  The system's consensus rules don't care anything about what you send across network connections or store on your disk, and it certainly doesn't care about what nodes far away from you send across wires.  They care only about the stuff that contribute to the cryptographic commitments in the blocks, and they care about them only in extremely specific, and often obscure ways.

Similarly here: The original rule said something about the data that went into transaction hashes.  Weight is constructed in such a way that 4m weight implies 1M size from the perspective of the old rule.

The thing is-- the rule is *exactly* what it is.  The rule isn't what some person assumed it to be, only what it actually was.  There was never a "block size" limit in the rules of the system, not in the general, informal, and human sense of the term: the system actually implemented a very specific rule which limited size in a very specific way. Just as you wouldn't say that including a hash of a 2TB document in an op_return didn't violate the size limit. The thing it did kinda mapped to a limit on the size of the blocks, but no complex mathematical object (which is what the rules are) ever maps exactly to our natural concepts.  This is why designing cryptosystems is so hard: It's way too easy to let our intuitive understanding cloud our vision of the true behavior. The Bitcoin system itself only enforces the true behavior, not our human intuition, enforcing that is left up to us.


    Spoon boy : Do not try and bend the spoon. That's impossible. Instead... only try to realize the truth.
    Neo : What truth?
    Spoon boy : There is no spoon.
    Neo : There is no spoon?
    Spoon boy : Then you'll see, that it is not the spoon that bends, it is only yourself.


This is also why some people's intuition that soft forks are automatically 'safe' is wrong. They're only safe if the community uses them in safe ways, and a lot of thought and engineering goes into the softforks people right to try to maximize their safety.  Nothing about any of this is automatically safe.  Soft forks really do only restrict rules since that is the necessary (and pretty much sufficient) criteria for compatibility and that sounds fairly benign but the rules they restrict are the inhuman rules of The Blind Idiot God at the heart of the system, not the human intuition that approximates them that lives in our hearts as what we believe to be Bitcoin.  The true rules of Bitcoin and our intuitions almost always match, sure, but they differ in the details and the details are critically important.

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.

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

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)

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.

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.

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.

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.

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

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

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.

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.
 

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.

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

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


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.

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

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.

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.

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.

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?

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.

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.