From rusty at rustcorp.com.au  Thu Nov 19 02:53:00 2015
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Thu, 19 Nov 2015 13:23:00 +1030
Subject: [Lightning-dev] Lightning, the death of BIP62,
	and Segregated Witness
Message-ID: <87si42n1ir.fsf@rustcorp.com.au>

Hi all!

        As you know, I designed a lightning variant which used only
non-experimental, in-planning BIPs[1].  One assumption was BIP62: in
particular, that anchor malleability wouldn't be an issue.  This was
flawed; BIP62 will never be deployed.

        There are several options from here:

1) Ignore it.  Malleated txs are non-standard.
2) Add a timeout to the anchor.  Limits the lifetime of the channel, and
   still means if it does happen you have to wait for the timeout.
3) Propose a reduced BIP62 which (say) only protects P2PKH, for a
   specific transaction version.
4) Take a leap of faith and assume Segregated Witness fixes all
   malleability.

I was debating between #1 and #3 for a while, but eventually settled on
#4.  Here's why:

1) While still pre-BIP, Pieter Wuille is working on a prototype now
   (Luke Jr came up with a sanish way of softforking it in).
2) Other parts of the lightning code (in particular, watching bitcoin
   transactions) become significantly simpler if malleability is
   ignored.
3) It's the right thing for Bitcoin; all smart contract systems want
   this.

This result is NOP for lightning in the short term; assuming SW is the
same as pretending malleability doesn't exist.  But if we need to add
malleability support later, it's going to be painful, since handling it
correctly in all the places it's missing will be hard.

Cheers,
Rusty.
PS.  Remember, every project has 3 major disasters.  Just wait until you
     see the next two!

[1] https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf