📅 Original date posted:2019-05-26
📝 Original message:The scriptSig when evaluated populates the stack so opcodes can operate
on them. A witness is essentially a list of data elements, quite similar
to the script stack (the witness is passed in as the script stack in fact)
OP_0 when evaluated pushes a _zero length_ value onto the stack, hence
the 00 (the varlen) in the witness serialization. OP_1 (51 in decimal)
pushes 0x01 to the stack, so when serialized would be 0101.
It may help to consider the entire witness structure as
vector<vector<data element>> and it's length must equal the number of
inputs - so a non-segwit input must have a zero sized witness.
On 5/26/19 12:56 AM, Aymeric Vitte via bitcoin-dev wrote:
> I realized recently that my segwit implementation was not correct,
> basically some time ago, wrongly reading the specs (and misleaded by
> what follows), I thought that scriptsig would go into witness data as it
> was, but that's not the case, op_pushdata is replaced by varlen
>
> Now reading correctly the specs, they seem to be not totally correct,
> then the first question is: why OP_0 is 00 in witness data and not 0100?
> Does this apply to other op_codes? This does not look logical at all
>
> The second question is: why for non segwit inputs there is a 00 length
> in segwit data, what is the rational for that? It should just be nothing
> since you don't need this to reconciliate things
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Thomas Kerin [ARCHIVE] /
npub1e4…nt5am
2023-06-07 18:18:23
in reply to nevent1q…7wzk
Author Public Key
npub1e4azew50kk9xzvfpqxzlyftkjt6kken0kf9lnncpdj524f9y4cqsfnt5amPublished at
2023-06-07 18:18:23Event JSON
{
"id": "fcd5c408c4020b741473e6216ff8d029f1a71b9de9127927dd0e997f603332dd",
"pubkey": "cd7a2cba8fb58a6131210185f2257692f56b666fb24bf9cf016ca8aaa4a4ae01",
"created_at": 1686161903,
"kind": 1,
"tags": [
[
"e",
"57f670b71f9403a1e4f551e7e92fdc9f1e9951b7c8bc93d735ebac1f180808eb",
"",
"root"
],
[
"e",
"bb235e2ddc68acc3b6ec7bf4dafabd7ba8e46b1158c787c515818b9c89da196e",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2019-05-26\n📝 Original message:The scriptSig when evaluated populates the stack so opcodes can operate\non them. A witness is essentially a list of data elements, quite similar\nto the script stack (the witness is passed in as the script stack in fact)\n\nOP_0 when evaluated pushes a _zero length_ value onto the stack, hence\nthe 00 (the varlen) in the witness serialization. OP_1 (51 in decimal)\npushes 0x01 to the stack, so when serialized would be 0101.\n\nIt may help to consider the entire witness structure as\nvector\u003cvector\u003cdata element\u003e\u003e and it's length must equal the number of\ninputs - so a non-segwit input must have a zero sized witness.\n\nOn 5/26/19 12:56 AM, Aymeric Vitte via bitcoin-dev wrote:\n\u003e I realized recently that my segwit implementation was not correct,\n\u003e basically some time ago, wrongly reading the specs (and misleaded by\n\u003e what follows), I thought that scriptsig would go into witness data as it\n\u003e was, but that's not the case, op_pushdata is replaced by varlen\n\u003e\n\u003e Now reading correctly the specs, they seem to be not totally correct,\n\u003e then the first question is: why OP_0 is 00 in witness data and not 0100?\n\u003e Does this apply to other op_codes? This does not look logical at all\n\u003e\n\u003e The second question is: why for non segwit inputs there is a 00 length\n\u003e in segwit data, what is the rational for that? It should just be nothing\n\u003e since you don't need this to reconciliate things\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "1c8f0dba6c4222c5cce5682f6d2f3f366d07e92951698962c917c6db5e3798a569c081db6b29f6f50c2f304547a5a683e15922f5fc7b666bb62195144c3a4507"
}