rich1.0ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://yabu.me📅 Original date posted:2020-12-15 📝 Original message: 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