đź“… Original date posted:2019-05-26
đź“ť Original message:Well, OK, then back to non standard stuff and bitcoin considers that an
OP_1 or empty scriptpubkey is something that can exist, sipa does not
like my questions on this list but this is a bit frightening in fact to
see that after 10 years an OP_1 scriptpubkey or empty one can be a use
case, thanks Thomas also, where all of this is clearly documented so
people don't bother the list not to produce approximative stuff remains
mysterious
Le 26/05/2019 à 19:24, Johnson Lau a écrit :
> Empty scriptSig doesn’t imply segwit input: if the previous scriptPubKey is OP_1 (which does not allow witness), it could still be spent with an empty scriptSig
>
> Similarly, a scriptSig looking like a spend of P2SH-segwit doesn’t imply segwit input: if the previous scriptPubKey is empty, it could be spent with a push of any non-zero value.
>
>> On 27 May 2019, at 1:09 AM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
>>
>> I did not phrase correctly in fact, what I meant is: if the validator
>> sees empty or witness script in scriptSig, then this is a segwit input,
>> and doing this one by one the validator can associate the correct segwit
>> data to the correct segwit input, so 00 does not look to be needed
>>
>> Le 26/05/2019 Ă 18:28, Johnson Lau a Ă©crit :
>>> This is not how it works. While the transaction creator may know which inputs are segwit, the validators have no way to tell until they look up the UTXO set.
>>>
>>> In a transaction, all information about an input the validators have is the 36-byte outpoint (txid + index). Just by looking at the outpoint, there is no way to tell whether it is segwit-enabled or not. So there needs to be a way to tell the validator that “the witness for this input is empty”, and it is the “00”.
>>>
>>>> On 27 May 2019, at 12:18 AM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
>>>>
>>>> ……. for the 00 number of witness
>>>> data for non segwit inputs the one that is doing the transaction knows
>>>> which inputs are segwit or not, then parsing the transaction you can
>>>> associate the correct input to the correct witness data, without the
>>>> need of 00, so I must be missing the use case
>
Aymeric Vitte [ARCHIVE] /
npub15f…g5grz
2023-06-07 18:18:24
in reply to nevent1q…ddqg
Author Public Key
npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grzPublished at
2023-06-07 18:18:24Event JSON
{
"id": "3711a3f1a3e6e548988df34242c250bb0cb56932a1eae971ccd54244bc547ede",
"pubkey": "a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df",
"created_at": 1686161904,
"kind": 1,
"tags": [
[
"e",
"57f670b71f9403a1e4f551e7e92fdc9f1e9951b7c8bc93d735ebac1f180808eb",
"",
"root"
],
[
"e",
"6f934f268b1d6be7dc07222de5dd0c1bd4473e1606fafe807b80dcdd5ebf8c3a",
"",
"reply"
],
[
"p",
"492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7"
]
],
"content": "📅 Original date posted:2019-05-26\n📝 Original message:Well, OK, then back to non standard stuff and bitcoin considers that an\nOP_1 or empty scriptpubkey is something that can exist, sipa does not\nlike my questions on this list but this is a bit frightening in fact to\nsee that after 10 years an OP_1 scriptpubkey or empty one can be a use\ncase, thanks Thomas also, where all of this is clearly documented so\npeople don't bother the list not to produce approximative stuff remains\nmysterious\n\nLe 26/05/2019 à 19:24, Johnson Lau a écrit :\n\u003e Empty scriptSig doesn’t imply segwit input: if the previous scriptPubKey is OP_1 (which does not allow witness), it could still be spent with an empty scriptSig\n\u003e\n\u003e Similarly, a scriptSig looking like a spend of P2SH-segwit doesn’t imply segwit input: if the previous scriptPubKey is empty, it could be spent with a push of any non-zero value.\n\u003e\n\u003e\u003e On 27 May 2019, at 1:09 AM, Aymeric Vitte \u003cvitteaymeric at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e I did not phrase correctly in fact, what I meant is: if the validator\n\u003e\u003e sees empty or witness script in scriptSig, then this is a segwit input,\n\u003e\u003e and doing this one by one the validator can associate the correct segwit\n\u003e\u003e data to the correct segwit input, so 00 does not look to be needed\n\u003e\u003e\n\u003e\u003e Le 26/05/2019 à 18:28, Johnson Lau a écrit :\n\u003e\u003e\u003e This is not how it works. While the transaction creator may know which inputs are segwit, the validators have no way to tell until they look up the UTXO set.\n\u003e\u003e\u003e\n\u003e\u003e\u003e In a transaction, all information about an input the validators have is the 36-byte outpoint (txid + index). Just by looking at the outpoint, there is no way to tell whether it is segwit-enabled or not. So there needs to be a way to tell the validator that “the witness for this input is empty”, and it is the “00”.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e On 27 May 2019, at 12:18 AM, Aymeric Vitte \u003cvitteaymeric at gmail.com\u003e wrote:\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e ……. for the 00 number of witness\n\u003e\u003e\u003e\u003e data for non segwit inputs the one that is doing the transaction knows\n\u003e\u003e\u003e\u003e which inputs are segwit or not, then parsing the transaction you can\n\u003e\u003e\u003e\u003e associate the correct input to the correct witness data, without the\n\u003e\u003e\u003e\u003e need of 00, so I must be missing the use case\n\u003e",
"sig": "bb25d7b830ca5cbcce1cdd897f6b46e1e47ca1784940a8b661e544cc0434e545be58b2947f22d30ffd88ae7fc2e23faf8a2b55608a76648fcfd4205680ac80aa"
}