pull down to refresh

Clients that had not upgraded would treat new segwit transactions @ prior costs as valid, would consider them part of longest chain.
I believe this is why it's considered impossible to roll back segwit without a hard fork.
Clients that had not upgraded would treat new segwit transactions @ prior costs as valid, would consider them part of longest chain.
Fees and tx standard rules such as OP_RETURN size and count are simply relay/inclusion policy, not block consensus. So you need just a single path to a similarly configured miner to push and get it included. You'll wait longer of course if only a subset of miners accepts it under their policy. This is why someone running Peter Todd's libre relay fork can actually push a bigger OP_RETURN today. F2pool seems to allow these as they mined the taunt the other day. The same goes for changing fee calc.
this is why it's considered impossible to roll back segwit without a hard fork.
This part is correct.
reply
110 sats \ 0 replies \ @Murch 1 May
Depends on what you exactly mean with "rolling back segwit".
  • Counting witness bytes as 1 vB instead of 1 wu would be a soft fork.
  • Forbidding segwit outputs and/or inputs would be a soft fork.
  • Removing the segwit rules and returning segwit outputs to being anyone_can_spend would be a hard fork.
reply
deleted by author
there is zero appetite for a hard fork. and even soft forks are extremely contentious/disagreed upon.
it's a feature not a bug dude
reply
I would gladly sell whatever extra hardfork coins get created.. but def don't want to see that
reply
Right, non-upgraded nodes would accept the old rules or the new rules, but upgraded nodes and miners would enforce the new rules. If a majority of the network and hashrate enforces the new rules, the best chain converges on the new rules. That’s the definition of a soft fork.
reply