📅 Original date posted:2021-03-15
📝 Original message:
Hi All,
I just finished writing a (very) rough draft of the Funding Timeout
Recovery proposal (a.k.a. "So long, and thanks for all the sigs"). You
can find the full proposal here [1].
The proposal details how the fundee can assist the funder quickly
recover a botched funding. This is an alternative to using the
pre-signed commitment transaction, which likely overestimates the
feerate, and also locks the funder's funds with a timeout since it is a
unilateral close.
The trick is to have the fundee sign a blank check with the
funding_privkey, used to setup the 2-of-2, and using `sighash_none` to
make the signature independent from the outputs. The funder can then use
that signature to create a close transaction however she wants,
including adjustable feerates, and any desired outputs.
In addition it also includes a recovery mechanism for malleated funding
transactions, which can happen from time to time, if there are
non-segwit inputs, or if the funding transaction is edited externally to
the lightning node prior to broadcasting it. This extension is however
optional.
There are a couple of open questions at the bottom, and I would be very
interested in everyone's opinion on the safety. I think we're ok due to
the funding_privkey = channel mapping, but I'm open to further analysis.
Since this is rather short-notice for today's spec meeting I'll probably
add it to the agenda for next time instead, to give everybody time to
familiarize themselves with the proposal, before delving into details
:-)
Cheers,
Christian
[1] https://github.com/lightningnetwork/lightning-rfc/pull/854
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 13:02:09
in reply to nevent1q…45rt
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 13:02:09Event JSON
{
"id": "692e6d3f79e04ec433c2f81f1aea8006805f1cee405c5cfc1485813e437c1b50",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315729,
"kind": 1,
"tags": [
[
"e",
"fc72aa227b00100c3b553f6c777ede00940495fedf68c0742f4380a62e9b57ee",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2021-03-15\n📝 Original message:\nHi All,\n\nI just finished writing a (very) rough draft of the Funding Timeout\nRecovery proposal (a.k.a. \"So long, and thanks for all the sigs\"). You\ncan find the full proposal here [1].\n\nThe proposal details how the fundee can assist the funder quickly\nrecover a botched funding. This is an alternative to using the\npre-signed commitment transaction, which likely overestimates the\nfeerate, and also locks the funder's funds with a timeout since it is a\nunilateral close.\n\nThe trick is to have the fundee sign a blank check with the\nfunding_privkey, used to setup the 2-of-2, and using `sighash_none` to\nmake the signature independent from the outputs. The funder can then use\nthat signature to create a close transaction however she wants,\nincluding adjustable feerates, and any desired outputs.\n\nIn addition it also includes a recovery mechanism for malleated funding\ntransactions, which can happen from time to time, if there are\nnon-segwit inputs, or if the funding transaction is edited externally to\nthe lightning node prior to broadcasting it. This extension is however\noptional.\n\nThere are a couple of open questions at the bottom, and I would be very\ninterested in everyone's opinion on the safety. I think we're ok due to\nthe funding_privkey = channel mapping, but I'm open to further analysis.\n\nSince this is rather short-notice for today's spec meeting I'll probably\nadd it to the agenda for next time instead, to give everybody time to\nfamiliarize themselves with the proposal, before delving into details\n:-)\n\nCheers,\nChristian\n\n[1] https://github.com/lightningnetwork/lightning-rfc/pull/854",
"sig": "5d83ae0d9c0f144e63f6801bdf9b9746658e4bb1d25300043396bf933220135e88411c8fca508fd3119f193e8a763c518d56d432c0996a8f82cc51f84ac9849a"
}