Gregory Maxwell <g...@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). _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev