rich1.0Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypnjumphttps://yabu.me📅 Original date posted:2020-12-16 📝 Original message: Hey Z, On Tue, Dec 15, 2020 at 9:21 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote: > > 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. Hopefully this recovery system is used by people whose channels are in a HTLC free state 99.9999% of the time (and hopefully hardware failures do not somehow coincide with HTLCs!). As a user, it would be cool to be able to just lock up all my Bitcoin into channels with well-established lightning nodes. That way if fees go ballistic I can still move money around cheaply. One of the main concerns for this pattern of user behaviour is the recovery story I think. The first line of defence for routing nodes (people who are taking their role in LN seriously) has to be redundant data storage. This would be a poor last-resort solution for routing nodes. > 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. Right. I think this doesn't work with PTLCs though. > 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. I don't think so? You need to know the private key of the node to discover its channels! The points actually used in the channels would be randomized with shared secret from Diffie-Hellman so are unlinkable to the public keys of the two nodes under decisional Diffie-Hellman assumption. There is more minor but still real concern of "deniability" of unpublished closed channels if a large node operator later becomes corrupted or coerced by a malicious actor. Since the node operator still knows their secret key (obviously) they can still do a scan (same as you would do in recovery) on the whole chain and find any past channels they had with any nodes. A mitigation of this problem would be for users who want unpublished channels to turn the use-node-key-as-channel-key feature off for their keys in the channel so they would still be able to do a backup-free channel scan but the well-established node would lose the ability to do so. This means that after the channel is closed there would be no way for the large node to find the channel again assuming they honestly delete the data. Cheers, LL