How do legacy nodes verify SegWit transactions?
I read something about that they consider them "anyone can spend" transactions. But doesn't that mean they thought they could have spend that output, too?
They don't. From their point of view segwit outputs are weird scripts that anyone can satisfy – anyone can spend outputs.
That's basically how all soft forks work: we tighten the rules on something that previously didn't really have rules. Eg my own soft fork, CheckLockTimeVerify, reused NOP3, which previously did nothing at all.
reply
Thanks for your answer. But I am still confused
They don't. From their point of view segwit outputs are weird scripts that anyone can satisfy – anyone can spend outputs.
Isn't this a contradiction? They think anyone can spend it but they don't think they can? I think that's where my confusion is: Wouldn't legacy wallets show a false balance by including these "anyone can spend" outputs as spendable outputs?
For me, a node validating transactions is similar to a wallet checking which utxos it can spend. Or is there something wrong with this analogy?
reply
You're assuming Bitcoin nodes have intelligence that they don't. They don't "think". They're computer programs that follow rules. Pre-segwit rules allow those outputs to be spent by anyone; post-segwit rules don't.
As for wallets, they would never create such scripts so they'd never show those scripts as part of their balance.
reply
You're assuming Bitcoin nodes have intelligence that they don't. They don't "think". They're computer programs that follow rules. Pre-segwit rules allow those outputs to be spent by anyone; post-segwit rules don't.
Okay, this makes sense and clears things up, thanks!
As for wallets, they would never create such scripts so they'd never show those scripts as part of their balance.
Okay, interesting. Thanks! I have to look more into how wallets behave
reply
How I think about it
Segwit transaction outputs are locked by a condition that looks like this 0x0014<20 byte-key-hash>. An old node would look at that and interpret it as push an empty array on the stack, then push 20 bytes on the stack. There are no signature checks or anything. By it's rules, anybody could spend it, even by just putting 0x00 in the scriptSig of the input that spends the utxo. A post-segwit node would look at 0x0014<20 byte-key-hash> and see it as a template for a P2WPKH transaction and only verify it if it provided the correct pubkey and signature in the witness part of the transaction.
Let's say you had a pre-segwit node and were running a separate program that looks for transaction outputs whose locking conditions are only data pushes and then spends them. After segwit, your program would not work because it would try to spend the outputs, but the rest of the network would say you need to have signature in the witness part of the transaction.
reply
187 sats \ 1 reply \ @ek 1 Jun 2023
After segwit, your program would not work because it would try to spend the outputs, but the rest of the network would say you need to have signature in the witness part of the transaction.
I see, thanks!
I think that's also where the discussion about "what is a full node" comes up since a legacy node does not validate the new rules thus it does not validate all rules. So is it no longer a full node?
I encountered this topic recently in a TG group I am in. People were discussing what a full node is in the context of banning ordinals.
reply
Interesting! I've never thought about a full node in that way but my initial reaction is that it still counts as full because i can send/receive any bitcoin with a wallet that uses that node.
reply