📅 Original date posted:2018-05-09
📝 Original message:
> 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.
The typical address re-use doesn't apply here as this is a sighash flag that
would only really be used for doing various contracts on Bitcoin. I don't
see any reason why "regular" wallets would update to use this sighash flag.
We've also seen first hand with segwit that wallet authors are slow to pull
in the latest and greatest features available, even if they solve nuisance
issues like malleability and can result in lower fees.
IMO, sighash_none is an even bigger footgun that already exists in the
protocol today.
-- Laolu
On Tue, May 8, 2018 at 7:41 AM Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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.
>
> 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.
>
> Is there any reason why an OP_CHECKSIG_1USE (or OP_CHECKMULTISIG_1USE)
> wouldn't be equally effective for the forseeable usecases? That would
> ensure that a _NOINPUT signature is only ever valid for keys deliberately
> intended to be single use, rather than potentially valid for every key.
>
> It would be ~34 witness bytes worse than being able to spend a Schnorr
> aggregate key directly, I guess; but that's not worse than the normal
> taproot tradeoff: you spend the aggregate key directly in the normal,
> cooperative case; and reserve the more expensive/NOINPUT case for the
> unusual, uncooperative cases. I believe that works fine for eltoo: in
> the cooperative case you just do a SIGHASH_ALL spend of the original
> transaction, and _NOINPUT isn't needed.
>
> 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.
>
> A new opcode has the theoretical advantage that it could be deployed
> into the existing segwit v0 address space, rather than waiting for segwit
> v1. Not sure that's really meaningful, though.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180509/ba4835de/attachment-0001.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 12:50:36
in reply to nevent1q…taq9
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 12:50:36Event JSON
{
"id": "b560c9ecf4b3005dcb16d009150c4c1c41ff7cd514dc2b03898cfe5207fe0180",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686315036,
"kind": 1,
"tags": [
[
"e",
"b96952336ac3c9bf98329984da334537047b985c3735bc2f731e82800af0b98a",
"",
"root"
],
[
"e",
"aa4d91fa3a22cdd96b3367b75ef5395141f8b6f42d9fd7a1ef4bbce66e4f9de8",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2018-05-09\n📝 Original message:\n\u003e The current proposal kind-of limits the potential damage by still\ncommitting\n\u003e to the prevout amount, but it still seems a big risk for all the people\nthat\n\u003e reuse addresses, which seems to be just about everyone.\n\nThe typical address re-use doesn't apply here as this is a sighash flag that\nwould only really be used for doing various contracts on Bitcoin. I don't\nsee any reason why \"regular\" wallets would update to use this sighash flag.\nWe've also seen first hand with segwit that wallet authors are slow to pull\nin the latest and greatest features available, even if they solve nuisance\nissues like malleability and can result in lower fees.\n\nIMO, sighash_none is an even bigger footgun that already exists in the\nprotocol today.\n\n-- Laolu\n\n\nOn Tue, May 8, 2018 at 7:41 AM Anthony Towns via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev\n\u003e 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\u003e\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\u003e\n\u003e Is there any reason why an OP_CHECKSIG_1USE (or OP_CHECKMULTISIG_1USE)\n\u003e wouldn't be equally effective for the forseeable usecases? That would\n\u003e ensure that a _NOINPUT signature is only ever valid for keys deliberately\n\u003e intended to be single use, rather than potentially valid for every key.\n\u003e\n\u003e It would be ~34 witness bytes worse than being able to spend a Schnorr\n\u003e aggregate key directly, I guess; but that's not worse than the normal\n\u003e taproot tradeoff: you spend the aggregate key directly in the normal,\n\u003e cooperative case; and reserve the more expensive/NOINPUT case for the\n\u003e unusual, uncooperative cases. I believe that works fine for eltoo: in\n\u003e the cooperative case you just do a SIGHASH_ALL spend of the original\n\u003e transaction, and _NOINPUT isn't needed.\n\u003e\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\u003e\n\u003e A new opcode has the theoretical advantage that it could be deployed\n\u003e into the existing segwit v0 address space, rather than waiting for segwit\n\u003e v1. Not sure that's really meaningful, though.\n\u003e\n\u003e Cheers,\n\u003e aj\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180509/ba4835de/attachment-0001.html\u003e",
"sig": "d4294d48d830fd736f2e490b8d0f758cade27504f835c05fe6a11cce3d22299341730a6823c282f1e5b896d7adb813ef75b441b160235a730436e1c637e9a9ab"
}