pull down to refresh
100 sats \ 2 replies \ @Scoresby OP 7 Sep \ parent \ on: DISCUSS: "Consensus is achieved by running code" bitcoin
I think Mike's post is about coming to consensus on changes to the protocol.
For instance, prior to taproot, taproot addresses were not consensus. Now they are. How did we get here?
What I found thought provoking was that he seems to be implying that if we are going to operate under rough consensus, releasing and running code may be an important tool.
I thought taproot was a soft fork though? Meaning, taproot addresses were consensus (at the protocol level, and thus older nodes see them as valid), but older nodes just wouldn't understand how to operate with them?
If by consensus you mean social consensus and not protocol consensus, then I agree, it's achieved by just running code. But if a group starts running code that is not within protocol consensus, we end up with a hard fork and two chains.
reply
Meaning, taproot addresses were consensus (at the protocol level, and thus older nodes see them as valid)
Simplified: Non-taproot enabled node skips spending constraints in the script: "the output of this tx doesn't spend more than the input, but i cannot check the witness program because it is undefined for me, so whatever."
If a set of miners would run these non-taproot nodes, then you could spend my taproot output in their blocks, because the constraint that only I can spend my output is in the taproot script. And of course enforcing miners would not accept these blocks, so you'd have chaintip fork galore. This to my memory happened with CSV due to unupdated block template construction scripts.
Therefore, softforks are consensus updates and they only work if all miners enforce them. If you don't get a very high adoption from miners, then the new feature is useless.
reply