📅 Original date posted:2019-05-26
📝 Original message:> On 26 May 2019, at 7:56 AM, Aymeric Vitte via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> 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
>
Witness is not script. There is no op_pushdata or any other opcodes.
Witness is a stack. For each input, the witness starts with a CCompactSize for the number of stack elements for this input. Each stack element in turns starts with a CCompactSize for the size of this element, followed by the actual data
> 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
>
A “00” element means the size of this element is zero. Since it’s zero size, no data is followed. This will create an empty element on the stack. It’s effectively same as OP_0 (Again, witness is not script)
A “0100” element means the element size is one, and the data for this element is “00”. So it will leave an 1-byte element on the stack.
> 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
The “00” here means "this input has no witness stack element”. You need this even for non segwit inputs, because there is no way to tell whether an input is segwit-enabled or not, until you look up the UTXO, which might not be always available. Transaction serialization couldn’t rely on contextual information.
However, if all inputs have no stack element, the spec requires you to always use the non-segwit serialization.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Johnson Lau [ARCHIVE] /
npub1fy…p2mv9
2023-06-07 20:18:22
in reply to nevent1q…yneg
Author Public Key
npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9Published at
2023-06-07 20:18:22Event JSON
{
"id": "0c191dbd9f6a08c90d122d31ecd7807dedc0c22e36dcb1cd7d63a2c78c709fad",
"pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7",
"created_at": 1686161902,
"kind": 1,
"tags": [
[
"e",
"57f670b71f9403a1e4f551e7e92fdc9f1e9951b7c8bc93d735ebac1f180808eb",
"",
"root"
],
[
"e",
"dad9557324afb479d729e11a75075232a4cbdf6774d94896c1d766908944cc6d",
"",
"reply"
],
[
"p",
"a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df"
]
],
"content": "📅 Original date posted:2019-05-26\n📝 Original message:\u003e On 26 May 2019, at 7:56 AM, Aymeric Vitte via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \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\nWitness is not script. There is no op_pushdata or any other opcodes.\n\nWitness is a stack. For each input, the witness starts with a CCompactSize for the number of stack elements for this input. Each stack element in turns starts with a CCompactSize for the size of this element, followed by the actual data\n\n\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\nA “00” element means the size of this element is zero. Since it’s zero size, no data is followed. This will create an empty element on the stack. It’s effectively same as OP_0 (Again, witness is not script)\n\nA “0100” element means the element size is one, and the data for this element is “00”. So it will leave an 1-byte element on the stack.\n\n\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\nThe “00” here means \"this input has no witness stack element”. You need this even for non segwit inputs, because there is no way to tell whether an input is segwit-enabled or not, until you look up the UTXO, which might not be always available. Transaction serialization couldn’t rely on contextual information.\n\nHowever, if all inputs have no stack element, the spec requires you to always use the non-segwit serialization.\n\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": "1d840a7b1a8cdca7b9d307b785eef4adbe95d97496e161dec21c2b7177c063f1966a7ad7e0033e6b51b4dee5f7d0e4943a606606775f189ff22238b44f135924"
}