Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2021-03-15 📝 Original message: Hi All, I just finished ...
📅 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
📝 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