[Lightning-dev] Lightning, the death of BIP62, and Segregated Witness
rusty at rustcorp.com.au
Thu Nov 19 02:53:00 UTC 2015
As you know, I designed a lightning variant which used only
non-experimental, in-planning BIPs. 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
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
3) It's the right thing for Bitcoin; all smart contract systems want
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.
PS. Remember, every project has 3 major disasters. Just wait until you
see the next two!
More information about the Lightning-dev