📅 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
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:45:06
in reply to nevent1q…4hrk
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:45:06Event JSON
{
"id": "33aa4d9140c02260a13cb9801eea3dacfb95d660b5a300ec8526e6b7dbfe56b4",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314706,
"kind": 1,
"tags": [
[
"e",
"1af72c6403b0bf6c208cd96111979b74febacb268ea0e46444fb1495c20b46af",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2015-11-19\n📝 Original message:\nHi all!\n\n As you know, I designed a lightning variant which used only\nnon-experimental, in-planning BIPs[1]. One assumption was BIP62: in\nparticular, that anchor malleability wouldn't be an issue. This was\nflawed; BIP62 will never be deployed.\n\n There are several options from here:\n\n1) Ignore it. Malleated txs are non-standard.\n2) Add a timeout to the anchor. Limits the lifetime of the channel, and\n still means if it does happen you have to wait for the timeout.\n3) Propose a reduced BIP62 which (say) only protects P2PKH, for a\n specific transaction version.\n4) Take a leap of faith and assume Segregated Witness fixes all\n malleability.\n\nI was debating between #1 and #3 for a while, but eventually settled on\n#4. Here's why:\n\n1) While still pre-BIP, Pieter Wuille is working on a prototype now\n (Luke Jr came up with a sanish way of softforking it in).\n2) Other parts of the lightning code (in particular, watching bitcoin\n transactions) become significantly simpler if malleability is\n ignored.\n3) It's the right thing for Bitcoin; all smart contract systems want\n this.\n\nThis result is NOP for lightning in the short term; assuming SW is the\nsame as pretending malleability doesn't exist. But if we need to add\nmalleability support later, it's going to be painful, since handling it\ncorrectly in all the places it's missing will be hard.\n\nCheers,\nRusty.\nPS. Remember, every project has 3 major disasters. Just wait until you\n see the next two!\n\n[1] https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf",
"sig": "fff45b8436abe9d77fca6a4da6045ad7fb408552b6c9d07fd807569d0ea8f6ca7f5bf3cf23287a0e63ac3aa6dddbd244c7314d1e0fb86b7ccc3c0f7a4fa184c6"
}