I also thought that the obvious thing to do was to have it seen as a spend-to-all output, but the fact that there is an OP-0 followed by a push of the key hash makes me think that this is rather seen as an unspendable coin
It's true in a degree since old nodes would see it as "
non-standard".
There are "
consensus" and "
standard" rules; the former is required to follow by all nodes while the latter is per-client preference (
the majority's preference is the standard).
As you know it, since it doesn't have a
OP_CHECKSIG like a typical P2PKH ScriptSig it will just see a script that doesn't require a signature to spend which doesn't follow the standards but consensus valid.
So a typical non-upgraded client may be able create a transaction that spends it, but it wont be able to relay it to other nodes that follow the standards (
both pre-SegWit and SegWit nodes for different reasons),
It has to be included to a block since it's still valid for pre-Segwit Nodes, just non-standard.
But since the Bitcoin network has more SegWit nodes, upgraded nodes wont accept that block since a transaction in it doesn't pass the "
special witness validation" that is demonstrated in your link.
And it wont propagate even if he select those few non-SegWit nodes as his peers.
Ah, we might be hitting something I fundamentally misunderstood in bitcoin here. I'd like to understand because clearly there's an inconsistency in how I understand things, and I can't put my finger on it, so this might be the thing I'm missing (and is somehow why I opened this thread in the first place).
By non-standard, I *thought* one meant a "basement-made" script that isn't one of the standard scripts like P2PKH or the like, but I *thought* that the universal mechanism was always the same:
the output has an output script which is called the "scriptpubkey", and the input that wants to spend it has a script which we call "scriptsig". For the standard transaction methods, like P2PKH and the like, the form of these scripts is, well, standard (and for Segwit transactions, they are even absent because Segwit doesn't use explicit scripting any more) ; but of course one is "free" to write the scriptpubkey and the scriptsig one wants, and that is "non standard".
(this is how I understand "non standard").
Now I understand that different nodes can propagate different transactions, as long as they are not MINED. But I *thought* that the blockchain was UNIQUE, and that once a transaction made it into the blockchain, there's no talking anymore about whether a node transmits it or not, because by the nature itself of the blockchain, there cannot be alternatives. It is the entire concept of the blockchain that it is a unique ledger of which no alternative versions can circulate long time. So I'm not talking about the transactions in the mem pool or those that are transmitted on the network, but about the stuff that has been mined into the block chain.
Now, I also understood (thanks to this thread) that since segwit, there's an "optional appendix" to the blockchain, which are the witness fields, and that old nodes actually might have the blockchain pruned of these extra fields which they don't regard. So there are in fact 2 "versions" of the block chain, one with, and one without witness "fat", but it is nevertheless the same backbone block chain, with the same blocks, and the same transactions, only without the witness fields.
So to come back to this non-standard: I *thought* that whatever standard or non-standard scripts, in ALL cases, a transaction can only be valid if all of its inputs satisfy that:
1) the referred output in a given input exists on the blockchain before it (unless it is a coinbase transaction)
2) the referred output has not yet been referred to by a previous input in a previous transaction on the blockchain
==> in other words, the input refers to an UTXO
and, here it comes:
3)
if you put the input <script sig> and concatenate it with the referred output <script pub key> you obtain a full script, that *when you execute it, you obtain at the end a stack simply containing "1" and nothing else*.==> in other words, the input has the valid autorisation to spend the output.
4) a few supplementary rules such as eventual lockout times and so on if applicable
I *thought* that in order to accept a block on the block chain, for all nodes (old and new), it needed:
1) to have
a valid header (that is, it refers to a previous valid block to which it is the successor, it has the right Merkle root of all transactions, it has a right hash, and this hash reflects the difficulty level of that block, and it has an acceptable time stamp)
2)
every transaction in the block is validated as mentionned above (with special rules for the coinbase transaction).
And if I put all this of my fundamental (mis?)understandings together, I have a problem which I mentionned before:
In my understanding,
if you concatenate the <script sig> of a segwit transaction INPUT which is EMPTY (because it resides in special form in the witness field), with the <script pub key> of the previous segwit transaction output (which essentially pushes the key hash on the stack), you DO NOT END UP with a stack simply containing "1" and nothing else, so in my understanding, this transaction should be considered INVALID. And hence a block containing such a transaction should be rejected, and hence the entire block chain after this block.
To me, the OPCHECKSIG was simply a way to obtain that "1" on the stack because it is an operator that takes (in reverse polish notation like the old HP calculators) 2 elements off the stack, namely a public key and the signature, and checks whether that signature was produced with the given public key: if so, it pushes a "1" on the stack, if not, it pushes a "0" on the stack. So this is, in my understanding, just the way to obtain our stack with a final "1" in it and nothing else.
This is where I get stuck.
