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

Reply via email to