On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev <bitcoin-...@lists.linuxfoundation.org> wrote: > Hi all, > > I'd like to pick up the discussion from a few months ago, and propose a new > sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous
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. So, one could even argue that the possibility that someone might use this flag means that it's generally unsafe to reuse a scriptpubkey. I don't think the same argument applies for NONE or the single-bug because they render even a single use insecure... The best mitigation I can think of is defence in depth to ensure that anyone who uses this sighash flag understands the consequences. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev