Good morning LL,
> - What do you do if the channel state has HTLCs in flight? I don't know -- I
> guess you can just put them onto the settlement tx? That way it's possible
> the payment could still go through. Alternatively you could just gift the
> money to the party offering the recovery settlement.
Gifting the money is not a good option --- we allow HTLCs to be almost as high
as the total channel value minus fees and reserve.
Thus all the claimable value could potentially be in an outgoing HTLC.
Worse, if our node is a forwarding node, it would be easy for a third party to
arrange to have our funds in various HTLCs.
If we allow HTLCs to keep going on even while we are in recovery, we need to be
able to "bind" as well incoming and outgoing HTLCs if our node was a forwarding
node.
In particular, consider this situation:
* We are a forwarding node.
* We forward a payment whose outgoing expires in 1 day and whose incoming
expires in 2 days.
* This means we have at least two channels, one with the incoming HTLC and
another with the outgoing HTLC.
* We hit our head and get amnesia.
* It takes us a day to realize we were formerly a Lightning Network forwarding
node.
* The peer with the outgoing HTLC knows or learns the preimage.
* Since we were unresponsive (i.e. still recovering from whatever gave us
amnesia) that peer has dropped the channel onchain.
* The peer has resolved the onchain HTLC with the hashlock branch.
* Because the outgoing peer has resolved everything it cares about, it forgets
about the channel.
* We call all public nodes and ask about channels we might have with them.
* The incoming peer claims we have a channel with them containing an HTLC going
to us.
* The outgoing peer has forgotten about us and does not tell us about the
channel.
Thus, we cannot recover the outgoing channel, since the peer has already closed
it and resolved everything it is interested in.
(let us suppose that the `to_self_delay` is smaller than our `cltv_delta`
setting)
Using static-key channels (i.e. channel keys are our node keys) allows us to
recover even the outgoing channel with outgoing HTLC that has been forgotten by
the outgoing peer.
Using static-key channels does have slightly weaker privacy:
* Published nodes reveal all their channels with other published nodes on the
blockchain.
* While it is true that published nodes already reveal their channels with
published nodes, they are currently only revealed on the LN gossip network,
which is not archived; historical channels that are now closed are not informed
to current surveillors.
* On the other hand, all it takes is one "LN wayback machine" to record all
LN gossip, which are self-attesting and include a signature from the node.
* Unpublished nodes risk revealing their channels with published nodes via the
blockchain.
* Invoices created by unpublished nodes currently reveal their public key.
Payers can then uncover all the channels of that node.
* An unpublished node could use a faked node id, by combining the payment
hash/point with its privkey to generate a new keypair to use as faked node id
(I AM NOT A CRYPTOGRAPHER AND THIS TECHNIQUE IS POTENTIALLY GOING TO LOSE ALL
YOUR FUNDS AND PRIVACY AND KILL YOUR DOG).
On receiving an unparseable onion, it could try combining its privkey with
the payment hash/point and try to open the onion that way, in case it is an
incoming payment with the faked node id.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
