📅 Original date posted:2018-07-03
📝 Original message:
Gregory Maxwell <greg at xiph.org> writes:
> I know it seems kind of silly, but I think it's somewhat important
> that the formal name of this flag is something like
> "SIGHASH_REPLAY_VULNERABLE" or likewise or at least
> "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially
> insecure for traditional applications where a third party might pay to
> an address a second time, and should only be used in special protocols
> which make that kind of mistake unlikely. Otherwise, I'm worried
> that wallets might start using this sighash because it simplifies
> handling malleability without realizing that when a third party reuses
> a script pubkey, completely outside of control of the wallet that uses
> the flag, funds will be lost as soon as a troublemaker shows up (but
> not, sadly, in testing). This sort of risk is magnified because the
> third party address reuser has no way to know that this sighash flag
> has (or will) be used with a particular scriptpubkey.
Absolutely agree that we should be signaling the danger of using noinput
as clearly as possible to developers, and I'm more than happy to adopt
the _unsafe suffix suggested by jb55. I think using non-sighash_all
sighashes is always a huge danger, as you have correctly pointed out, so
maybe we should be marking all of them as being unsafe, or make sure to
communicate that danger on a higher level (docs).
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:51:07
in reply to nevent1q…fm4q
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:51:07Event JSON
{
"id": "c3bfdd21c3956fb7184025d48d2a46374f38eb3f01fd33f24591be37ddec78de",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315067,
"kind": 1,
"tags": [
[
"e",
"663916e8f170f60127f6aa3243b92b3d69f1c7433c345d342b16ceac1b085088",
"",
"root"
],
[
"e",
"2f363b3afee6ebea9bd8f05ca8afd2ce1883cfcd59a103838b81fa0b54af9f4d",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2018-07-03\n📝 Original message:\nGregory Maxwell \u003cgreg at xiph.org\u003e writes:\n\u003e I know it seems kind of silly, but I think it's somewhat important\n\u003e that the formal name of this flag is something like\n\u003e \"SIGHASH_REPLAY_VULNERABLE\" or likewise or at least\n\u003e \"SIGHASH_WEAK_REPLAYABLE\". This is because noinput is materially\n\u003e insecure for traditional applications where a third party might pay to\n\u003e an address a second time, and should only be used in special protocols\n\u003e which make that kind of mistake unlikely. Otherwise, I'm worried\n\u003e that wallets might start using this sighash because it simplifies\n\u003e handling malleability without realizing that when a third party reuses\n\u003e a script pubkey, completely outside of control of the wallet that uses\n\u003e the flag, funds will be lost as soon as a troublemaker shows up (but\n\u003e not, sadly, in testing). This sort of risk is magnified because the\n\u003e third party address reuser has no way to know that this sighash flag\n\u003e has (or will) be used with a particular scriptpubkey.\n\nAbsolutely agree that we should be signaling the danger of using noinput\nas clearly as possible to developers, and I'm more than happy to adopt\nthe _unsafe suffix suggested by jb55. I think using non-sighash_all\nsighashes is always a huge danger, as you have correctly pointed out, so\nmaybe we should be marking all of them as being unsafe, or make sure to\ncommunicate that danger on a higher level (docs).",
"sig": "102f702607885e8dc8a2a577b246092da44d847f4f1a126fccd82c3fb27215702e1935213af30193907391c4ed0e72f75e3a66a3ae28a3717e2208ec1c3e5d96"
}