Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-19 📝 Original message: Hi all! As you know, I ...
📅 Original date posted:2015-11-19
📝 Original message:
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
📝 Original message:
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