📅 Original date posted:2018-05-09
📝 Original message:
Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
> On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev wrote:
>> Given the general enthusiasm, and lack of major criticism, for the
>> `SIGHASH_NOINPUT` proposal, [...]
>
> So first, I'm not sure if I'm actually criticising or playing devil's
> advocate here, but either way I think criticism always helps produce
> the best proposal, so....
>
> The big concern I have with _NOINPUT is that it has a huge failure
> case: if you use the same key for multiple inputs and sign one of them
> with _NOINPUT, you've spent all of them. The current proposal kind-of
> limits the potential damage by still committing to the prevout amount,
> but it still seems a big risk for all the people that reuse addresses,
> which seems to be just about everyone.
If I can convince you to sign with SIGHASH_NONE, it's already a problem
today.
> I wonder if it wouldn't be ... I'm not sure better is the right word,
> but perhaps "more realistic" to have _NOINPUT be a flag to a signature
> for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead,
> so that it's fundamentally not possible to trick someone who regularly
> reuses keys to sign something for one input that accidently authorises
> spends of other inputs as well.
That was also suggested by Mark Friedenbach, but I think we'll end up
with more "magic key" a-la Schnorr/taproot/graftroot and less script in
future.
That means we'd actually want a different Segwit version for
"NOINPUT-can-be-used", which seems super ugly.
> Maybe a different opcode maybe makes sense at a "philosophical" level:
> normal signatures are signing a spend of a particular "coin" (in the
> UTXO sense), while _NOINPUT signatures are in some sense signing a spend
> of an entire "wallet" (all the coins spendable by a particular key, or
> more accurately for the current proposal, all the coins of a particular
> value spendable by a particular key). Those are different intentions,
> so maybe it's reasonable to encode them in different addresses, which
> in turn could be done by having a new opcode for _NOINPUT.
In a world where SIGHASH_NONE didn't exist, this might be an argument :)
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:50:36
in reply to nevent1q…sg9u
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:50:36Event JSON
{
"id": "60a4c0222641d525158c5ac36448df626a70197ec26f8c363c08fd7812683b18",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315036,
"kind": 1,
"tags": [
[
"e",
"b96952336ac3c9bf98329984da334537047b985c3735bc2f731e82800af0b98a",
"",
"root"
],
[
"e",
"b560c9ecf4b3005dcb16d009150c4c1c41ff7cd514dc2b03898cfe5207fe0180",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2018-05-09\n📝 Original message:\nAnthony Towns via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e writes:\n\u003e On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev wrote:\n\u003e\u003e Given the general enthusiasm, and lack of major criticism, for the\n\u003e\u003e `SIGHASH_NOINPUT` proposal, [...]\n\u003e\n\u003e So first, I'm not sure if I'm actually criticising or playing devil's\n\u003e advocate here, but either way I think criticism always helps produce\n\u003e the best proposal, so....\n\u003e\n\u003e The big concern I have with _NOINPUT is that it has a huge failure\n\u003e case: if you use the same key for multiple inputs and sign one of them\n\u003e with _NOINPUT, you've spent all of them. The current proposal kind-of\n\u003e limits the potential damage by still committing to the prevout amount,\n\u003e but it still seems a big risk for all the people that reuse addresses,\n\u003e which seems to be just about everyone.\n\nIf I can convince you to sign with SIGHASH_NONE, it's already a problem\ntoday.\n\n\u003e I wonder if it wouldn't be ... I'm not sure better is the right word,\n\u003e but perhaps \"more realistic\" to have _NOINPUT be a flag to a signature\n\u003e for a hypothetical \"OP_CHECK_SIG_FOR_SINGLE_USE_KEY\" opcode instead,\n\u003e so that it's fundamentally not possible to trick someone who regularly\n\u003e reuses keys to sign something for one input that accidently authorises\n\u003e spends of other inputs as well.\n\nThat was also suggested by Mark Friedenbach, but I think we'll end up\nwith more \"magic key\" a-la Schnorr/taproot/graftroot and less script in\nfuture.\n\nThat means we'd actually want a different Segwit version for\n\"NOINPUT-can-be-used\", which seems super ugly.\n\n\u003e Maybe a different opcode maybe makes sense at a \"philosophical\" level:\n\u003e normal signatures are signing a spend of a particular \"coin\" (in the\n\u003e UTXO sense), while _NOINPUT signatures are in some sense signing a spend\n\u003e of an entire \"wallet\" (all the coins spendable by a particular key, or\n\u003e more accurately for the current proposal, all the coins of a particular\n\u003e value spendable by a particular key). Those are different intentions,\n\u003e so maybe it's reasonable to encode them in different addresses, which\n\u003e in turn could be done by having a new opcode for _NOINPUT.\n\nIn a world where SIGHASH_NONE didn't exist, this might be an argument :)\n\nCheers,\nRusty.",
"sig": "faea13b53a0f8f810b366c237eb5c2f68ac6c5b739fe7b5d33f45573fa7d0328575031a9ce1c3aee42a35c4a80747087739549527f97d12403a78cc514ebe6f1"
}