📅 Original date posted:2018-11-24
📝 Original message:> On 23 Nov 2018, at 5:40 PM, Christian Decker via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Anthony Towns <aj at erisian.com.au> writes:
>> Commiting to just the sequence numbers seems really weird to me; it
>> only really prevents you from adding inputs, since you could still
>> replace any input that was meant to be there by almost any arbitrary
>> other transaction...
>
> It's a really roundabout way of committing to the inputs, I
> agree. I'm actually wondering if it makes sense to correct that
> additional blanked field in BIP118 at all since it seems there is no
> real use-case for NOINPUT that doesn't involve blanking the
> `hashSequence` as well.
I think we just make it as simple as this: Always commit to sequence of the same input. Commit to hashSequence if and only if all inputs and all outputs are signed.
The next-generation SIGHASH will introduce not only NOINPUT, but also signing of fees, previous scriptPubKey, and all input values, etc. So it won’t be a simple hack over BIP143. BIP118 might be better changed to be an informational BIP, focus on the rationale and examples of NOINPUT, and be cross-referenced with the consensus BIP.
Johnson Lau [ARCHIVE] /
npub1fy…p2mv9
2023-06-07 18:15:17
in reply to nevent1q…xxau
Author Public Key
npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9Published at
2023-06-07 18:15:17Event JSON
{
"id": "2f47c22cc4bfc72540becf303b1271f37c2c368a43db7699ae4a55e3fa194b33",
"pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7",
"created_at": 1686161717,
"kind": 1,
"tags": [
[
"e",
"1bd7a781e2cfd166ff9a33b1bac5fde47a675384fad1a2f913ed308d62699fea",
"",
"root"
],
[
"e",
"b6338a268ce432039652ce1f4625245b8f745bbd1225398e8595dab4f6dcf5de",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2018-11-24\n📝 Original message:\u003e On 23 Nov 2018, at 5:40 PM, Christian Decker via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e Anthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e\u003e Commiting to just the sequence numbers seems really weird to me; it\n\u003e\u003e only really prevents you from adding inputs, since you could still\n\u003e\u003e replace any input that was meant to be there by almost any arbitrary\n\u003e\u003e other transaction...\n\u003e \n\u003e It's a really roundabout way of committing to the inputs, I\n\u003e agree. I'm actually wondering if it makes sense to correct that\n\u003e additional blanked field in BIP118 at all since it seems there is no\n\u003e real use-case for NOINPUT that doesn't involve blanking the\n\u003e `hashSequence` as well.\n\nI think we just make it as simple as this: Always commit to sequence of the same input. Commit to hashSequence if and only if all inputs and all outputs are signed.\n\nThe next-generation SIGHASH will introduce not only NOINPUT, but also signing of fees, previous scriptPubKey, and all input values, etc. So it won’t be a simple hack over BIP143. BIP118 might be better changed to be an informational BIP, focus on the rationale and examples of NOINPUT, and be cross-referenced with the consensus BIP.",
"sig": "cb075956651eab49c6380b41bdd5d3b35f0f60e468e184ad1ce90c64619aa9df8bf75c939b8cc56b3072968d00491be5acff41bcce8b184779decfd4d6d10759"
}