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.
A common occurrence is that hardware failure is not detected until when the hardware is used, especially when used by casual users. Consider the sequence of events: * Part of the storage device fails. * Due to being a casual user, the user does not use state-of-the-art checksumming filesystems like ZFS and does not monitor disk health by S.M.A.R.T. * A high-onchain-fee condition exists. * The casual user attempts to send out a payment consisting of almost all funds in their LN channels via several HTLCs on MPP or other multipath. * Because of the activity generated, the filesystem assigns the LN database to the failing part. * Storage fails with most funds in outgoing HTLCs. Thus, merely activating the wallet and using HTLCs may result in a *detectable* failure of the hardware (which was already failing before, just not noticed by the casual user). On the other hand, we can consider this situation as having a complexity penalty. As someone who has seen a lot of storage devices slowly fail in unique and interesting (and data-losing) ways, I am always going to assume that storage devices are going to fail at any time, including a few hours after installation. It would be preferable if HTLCs and PTLCs are not gifted. On the other hand, it might not be possible (as you note about PTLCs). > > > 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. Yes, loss of the adaptor signature means we cannot recover in this case. > > > 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. Right, that would work. How about just using a multiplicative tweak of your own privkey and the pubkey of the other node (i.e. just use the "raw" ECDH point), that would work as 2-of-2 in 2p-ECDSA, and I believe (but do not know) should also be signable using MuSig/MuSig2 under taproot? > > 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. "Peer selling private information" is always going to be an issue with unpublished channels, and this seems to be an inherent issue with that model. Note that due to the existence of proof-of-discrete-log-equivalence, a node operator can *prove* to someone buying private information that a particular outpoint onchain is actually an unpublished channel. If I have privkey `z` and you have pubkey `L`, I can show `z * G` (my node pubkey), `L` (your "unpublished" (ha, ha) node pubkey), and `z * L` (our ECDH secret), plus a proof-of-discrete-log-equivalence that the `z` in `z * G` is the same `z` in `z * L`, in order to convice them of the ECDH secret. I suspect part of the proof-of-discrete-log-equivalance can be gated as well by a ZKCP on payment point+scalar the proof is provided only on payment. The selling node operator does not even need to reveal `z`. As the ECDH secret is what tweaks the channel keys, that is enough to convince any surveilling buyer. Further, `z` is not revealed, and channel funds cannot be stolen by just knowledge of the ECDH secret, thus protecting the interests of the selling forwarding node. Now of course, I could just be making up `L` (i.e. LL could be a sockpuppet of mine). However, between these two choices: * I lock up a set number of millisatoshi in a Z + L channel where L is a sockpuppet, and sell this fake information to surveillors. * I lock up a set number of millisatoshi in a Z + L channel where L is a genuine user node that thinks unpublished channels are private, and sell this genuine information to surveillors. Which is more lucrative for me? The latter case would be more lucrative for me, as I not only earn from selling your data to surveillors, I also earn routing fees. The former case can only earn me selling fake data to surveillors, with no opportunity to earn forwarding fees. > 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. If the user has all channels unpublished, it is not (normally) gossiped. So the well-established node would not have the ability to recover *all* channels by backup-free scans of published nodes in the first place, only those that are to published nodes. Or do you refer to something else? It might be easier for the "client" here to make up different node IDs for each "server" it connects to, by e.g. hashing its base privkey with the server pubkey and using the hash as the privkey for its fake node ID with that server. > 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. If forwarding nodes are expected to have storage redundancy, deletion of data could be difficult as well --- there may be lots of replicas of that data in various places (including obsolete replicas that the node operator might not particularly care about, being obsolete), and deletion might not catch them all. "Honestly delete" seems like a best-effort to me. On the other hand, if the model is that privacy is to be trusted to your peers, then this is no worse than unpublished channels, which has the same model. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
