Topic: Soft forks - page 2. (Read 224 times)

it seems disingenuous to describe the bolded behavior as a soft fork imo. it would be clearer to simply call the "safe" soft-fork plainly soft forks, and to popularize the "new rules can invalidate old rules" behavior as a... "permissive hard fork" is the expression that occurs to me from the top of my head. Maybe it's the wrong expression in some ways, but it's less misleading than the "impermissive" soft fork. If segwit had been implemented in such a way that, for instance, invalidated a common pre-fork consensus parameter, there would have been a least some orphaned blocks on that basis (and more likely an entire chain split, and a very likely failure of the segwit compliant fork). I am aware of no such event happening.

more simply; if a self-described soft fork can potentially produce a hard fork, then we need better words to describe what's really going on

Aside from that part of your statement you are correct.
It's (fairly) easy to get NOMP working.
I did it in less then half an hour over the weekend to get something fixed:
https://www.reddit.com/r/defcoin/comments/dxr3xe/network_outage/

1) A few lines in the conf file for a coin
2) Copy / paste a few apt-get install lines that are listed everywhere.
3) 2 Quick edits of 2 pool configuration files.
4) Beer

I have no idea if the above would work / does work / can be made to work with SegWit.
There are other pools that do, most do take more effort then the 30 minute NOMP setup.

Am I going to find out?: No
Could I find out?: Yes
Why?: Not going to run any real pool and I just don't have the time.
With a quick search (~10 minutes while having my AM coffee) could I find the answer: No, I did not.


-Dave

yep

(but before you said "old nodes will accept new rules", which is not the same, and self-evidently not possible)



nope, you're wrong

if nodes that observe a soft-fork's rules rejected blocks containing previously valid transactions, that would fork the chain. which isn't possible in this case, because the segwit soft-fork does not reject any rules that were valid before it's activation, that's the definition of a soft fork

but I don't see much point in arguing this further, tell us which blocks have been rejected by any soft-fork's rule set, that would constitute evidence of your claim



yes.

But the old way of doing it is still valid, because soft-fork

There is confusion about terms because "soft fork" just means that the blocks under the new behaviour will still be accepted by old nodes. Under that definition mining with pre-softfork behaviour wouldn't necessarily work.

Yet the development community prefers a much stricter set of criteria-- perhaps call it "safe soft-forks", where at least no widely used or recent software prior to the fork will inadvertently initiate a fork which is invalid with respect to the new rule. These "safe soft-forks" also have other properties like great care taken to avoid inadvertently depriving users from access to their funds (unless they were doing something absurd like using policy prohibited extension opcodes or version numbers).   Unless it's impossible to avoid, you should expect "safe softforks" to always be used.

Per the question, per consensus rules you can mine bitcoin blocks without the segwit coinbase commitment even with transactions -- just not any segwit ones.  However, all the mining interfaces in current bitcoind mandate that you use segwit to avoid misconfiguration where miners accidentally don't and then miss out on a ton of fees (and cause nuisance delays to users). Bitcoin nodes also don't fetch blocks from non-witness capable peers and so on.

The effort to add the witness commitment is pretty trivial,  probably smaller than the effort of working around all the ways that the rest of the software expects you to have it. Plus the fees you miss by not having transactions are a couple grand per block -- a good 2% of the mining income right now.

I sorry to say that, but this is still wrong.  See here for what a soft fork is: https://en.bitcoin.it/wiki/Softfork

I.e. it means that only additional restrictions are added (in the case of segwit, that the witness must be valid in addition to the old-style signature).  This means that old nodes accept all new blocks, but it also means that transactions that would be accepted by old nodes may be invalid according to the new rules.

Now it could be that in the particular case of segwit mining, you are fine running old code, as long as noone maliciously sends you transactions that are valid according to old rules but invalid according to new ones.  But that would then be just by chance and not a general property of soft forks.  Also, at least according to my understanding (I'm not a miner and haven't looked at the details recently), aren't segwit blocks supposed to have a new commitment in the coinbase, which old mining software wouldn't create?