That might make a Segwit transaction in a block look legit to a node.
But what happens if a miner interprets a Segwit transaction as "pay to anybody" and creates a block that violates the "additional validation" performed by newer miner/node software?
> But what happens if a miner interprets a Segwit transaction as "pay to anybody" and creates a block that violates the "additional validation"
They don't because segwit (or taproot, for that matter) script is flagged using input-space that the old software knows is "from the future" so that it knows it doesn't know how to validate it. As a result, they won't relay it, won't mine it, and won't display it in their wallets until confirmed. But if someone else puts it in a block they'll accept it.
If someone goes and lobotomizes their own software so that it'll mine stuff it knows it doesn't understand, then they could produce an invalid block. But anyone that is upgraded just ignores their block like it never happened.
This is why the activation of such things is normally triggered by a super-majority of hashpower being upgraded: It's for the benefit of parties that haven't upgraded so that even if there are some bad-data-maniacs out there pulling expensive stunts, their invalid blocks are quickly left behind and even non-upgraded nodes won't see many confirmations before the bad block is removed. (And upgraded nodes won't see any at all, of course.)
In the case of taproot 90% of the hashrate has to signal support during any one of several two week signaling periods to trigger activation. If that doesn't happen, people will figure out why and try again (potentially with different activation criteria).
Yes, but everyone who is not upgraded does not. So there will be two chains that hold value. One run by a network of pre-taproot software and one run by a network of post-taproot software.
Nah, because the post-taproot software will have more hashpower (due to how it activates), the taproot enabled blocks are acceptable to old nodes, and Bitcoin follows the valid chain with the most hashpower.
Bitcoin has introduced changes like this a good dozen times in the past, it doesn't create two separate chains in practice.
The only way it can create two separate chains is if the unupgraded side has a super majority hashpower, one of them modifies their software to mine something invalid under the new 'future' rules... and no humans intervene to prevent that outcome (e.g. by getting hashpower to move). In practice this doesn't happen because the activation is triggered by 90% hashpower indicating that it will enforce. (and won't turn active until November, giving people plenty of time to upgrade)
Does the old software really have to be modified to "mine something invalid under the new 'future' rules"? Isn't it possible to simply craft a transaction that is invalid according to the new software but valid according to the old software?
The definition of valid is different in different contexts.
To old nodes taproot transactions are valid when they've been included in a block, but are invalid when they are relayed on the network.
This is accomplished by taking all the parts of the transaction that are reserved for future extensions and making their use invalid for the purpose of relay, mining selection, or wallet display in advance.
So you can make a transaction that is invalid to new nodes, but valid-in-blocks to old but it'll still be invalid to them for other uses. It's sufficient that new stuff be considered valid in blocks by old nodes for the system to still come to consensus, since only the blocks are included in consensus.
[Thanks for all the questions, BTW, it's been an interesting discussion.]
Tricky. I agree that the sum of these circumstances make it somewhat hard to say if something like taproot creates a new currency or not. As long as the longest chain is the one with taproot transactions, then probably not.
All the nodes (even the old ones) run on the rule that the longest chain (the one with more work) is the valid one so the chain with the one invalid block won’t be longest because no one will build on it. As a result even the old nodes which don’t know the new rules won’t accept the blocks based on the longest chain rule.
This is not possible with a miner activated soft fork, because the upgraded fork will have the longest chain. This is guaranteed by the activation process, which requires a supermajority of miners to agree.
This longest chain is valid for both upgraded and not-upgraded participants. So that's the consensus that everybody follows.
But what happens if a miner interprets a Segwit transaction as "pay to anybody" and creates a block that violates the "additional validation" performed by newer miner/node software?