{"type":"rich","version":"1.0","title":"Lloyd Fournier [ARCHIVE] wrote","author_name":"Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)","author_url":"https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-12-17\n📝 Original message:\nOn Thu, Dec 17, 2020 at 1:56 AM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e A common occurrence is that hardware failure is not detected until when\nthe hardware is used, especially when used by casual users.\n\u003e\n\u003e Consider the sequence of events:\n\u003e\n\u003e * Part of the storage device fails.\n\u003e   * Due to being a casual user, the user does not use state-of-the-art\nchecksumming filesystems like ZFS and does not monitor disk health by\nS.M.A.R.T.\n\u003e * A high-onchain-fee condition exists.\n\u003e * The casual user attempts to send out a payment consisting of almost all\nfunds in their LN channels via several HTLCs on MPP or other multipath.\n\u003e * Because of the activity generated, the filesystem assigns the LN\ndatabase to the failing part.\n\u003e * Storage fails with most funds in outgoing HTLCs.\n\nNote that this is fine if the payment goes through. Their counterparty will\nhave to go on-chain to claim the payment (since your node is down due to\ndata-loss) and then you claim whatever is left from your seed.\nThe main risk here is for routing nodes which are hopefully only using this\ntechnique as a very poor last resort.\nIf you actually manage to get online and try to restore before the on-chain\nsettlement then just attaching outgoing HTLCs to the mutual close would be\nfine -- that way the peer can still claim the money from you if the payment\ngoes through and you can get the refund if not.\n\nThe same could apply to incoming HTLCs as long as you can reproduce your\nHTLC pre-image deterministically.\n\nPS good to hear you are a ZFS user too\n\n\u003e\n\u003e Thus, merely activating the wallet and using HTLCs may result in a\n*detectable* failure of the hardware (which was already failing before,\njust not noticed by the casual user).\n\u003e\n\u003e On the other hand, we can consider this situation as having a complexity\npenalty.\n\u003e\n\u003e As someone who has seen a lot of storage devices slowly fail in unique\nand interesting (and data-losing) ways, I am always going to assume that\nstorage devices are going to fail at any time, including a few hours after\ninstallation.\n\u003e\n\u003e It would be preferable if HTLCs and PTLCs are not gifted.\n\nYes I am convinced.\n\n\u003e \u003e\n\u003e \u003e \u003e Using static-key channels (i.e. channel keys are our node keys)\nallows us to recover even the outgoing channel with outgoing HTLC that has\nbeen forgotten by the outgoing peer.\n\u003e \u003e\n\u003e \u003e Right. I think this doesn't work with PTLCs though.\n\u003e\n\u003e Yes, loss of the adaptor signature means we cannot recover in this case.\n\nLet's think about this again. There is no reason why the oblivious mutual\nclose has to be the only thing the peer sends you upon connection. They can\nalso send you the necessary signatures for each PTLC output on the mutual\nclose because you can't do anything with this unless you choose to receive\nthe mutual close signature. You verify these each time you connect without\ndata loss so optimistically you should be able to recover both incoming and\noutgoing PTLCs\n\n\u003e Right, that would work.\n\u003e\n\u003e How about just using a multiplicative tweak of your own privkey and the\npubkey of the other node (i.e. just use the \"raw\" ECDH point), that would\nwork as 2-of-2 in 2p-ECDSA, and I believe (but do not know) should also be\nsignable using MuSig/MuSig2 under taproot?\n\nI think multiplicative combination of keys does *not* work for Schnorr\nmultisignatures.\n\n\u003e\n\u003e \"Peer selling private information\" is always going to be an issue with\nunpublished channels, and this seems to be an inherent issue with that\nmodel.\n\u003e\n\u003e Note that due to the existence of proof-of-discrete-log-equivalence, a\nnode operator can *prove* to someone buying private information that a\nparticular outpoint onchain is actually an unpublished channel.\n\u003e If I have privkey `z` and you have pubkey `L`, I can show `z * G` (my\nnode pubkey), `L` (your \"unpublished\" (ha, ha) node pubkey), and `z * L`\n(our ECDH secret), plus a proof-of-discrete-log-equivalence that the `z` in\n`z * G` is the same `z` in `z * L`, in order to convice them of the ECDH\nsecret.\n\u003e I suspect part of the proof-of-discrete-log-equivalance can be gated as\nwell by a ZKCP on payment point+scalar the proof is provided only on\npayment.\n\u003e The selling node operator does not even need to reveal `z`.\n\u003e\n\u003e As the ECDH secret is what tweaks the channel keys, that is enough to\nconvince any surveilling buyer.\n\u003e Further, `z` is not revealed, and channel funds cannot be stolen by just\nknowledge of the ECDH secret, thus protecting the interests of the selling\nforwarding node.\n\u003e\n\u003e Now of course, I could just be making up `L` (i.e. LL could be a\nsockpuppet of mine).\n\u003e However, between these two choices:\n\u003e\n\u003e * I lock up a set number of millisatoshi in a Z + L channel where L is a\nsockpuppet, and sell this fake information to surveillors.\n\u003e * I lock up a set number of millisatoshi in a Z + L channel where L is a\ngenuine user node that thinks unpublished channels are private, and sell\nthis genuine information to surveillors.\n\u003e\n\u003e Which is more lucrative for me?\n\u003e The latter case would be more lucrative for me, as I not only earn from\nselling your data to surveillors, I also earn routing fees.\n\u003e The former case can only earn me selling fake data to surveillors, with\nno opportunity to earn forwarding fees.\n\nCorrect and interesting analysis. I agree that you don't want to\naccidentally opt in to having your peer have a way to cryptographically\nprove you have a channel with them.\nExcept in the situation where you are already cryptographically proving to\neveryone you have a channel with them in the channel announcement.\n\n\u003e\n\u003e \u003e A mitigation of this problem\n\u003e \u003e would be for users who want unpublished channels to turn the\n\u003e \u003e use-node-key-as-channel-key feature off for their keys in the channel\n\u003e \u003e so they would still be able to do a backup-free channel scan but the\n\u003e \u003e well-established node would lose the ability to do so.\n\u003e\n\u003e If the user has all channels unpublished, it is not (normally) gossiped.\n\u003e So the well-established node would not have the ability to recover *all*\nchannels by backup-free scans of published nodes in the first place, only\nthose that are to published nodes.\n\u003e\n\u003e Or do you refer to something else?\n\nI was thinking about public nodes with un-announced channels.\nFor completely private/unpublished nodes then I agree with your statement\nthat there is no hope no matter how you compute the keys to recover\nautomatically.\n\n\u003e\n\u003e It might be easier for the \"client\" here to make up different node IDs\nfor each \"server\" it connects to, by e.g. hashing its base privkey with the\nserver pubkey and using the hash as the privkey for its fake node ID with\nthat server.\n\u003e\n\nRight. Something like this is what I was suggesting for public nodes who\nwant to have unpublished channels that they want to be able to channel scan\nfor but *do not want the other party* to be able to do so (to avoid\nconcerns you made clear earlier).\nI think there's no strong reason to make up a new node id -- it can just be\nan option in open_channel  like \"use this key instead of my node id for\neverything in this channel\".\n\nCheers,\n\nLL\n\n\n\nOn Thu, Dec 17, 2020 at 1:56 AM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning LL,\n\u003e\n\u003e \u003e \u003e \u003e -   What do you do if the channel state has HTLCs in flight? I don't\n\u003e know -- I guess you can just put them onto the settlement tx? That way it's\n\u003e possible the payment could still go through. Alternatively you could just\n\u003e gift the money to the party offering the recovery settlement.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Gifting the money is not a good option --- we allow HTLCs to be almost\n\u003e as high as the total channel value minus fees and reserve.\n\u003e \u003e \u003e Thus all the claimable value could potentially be in an outgoing HTLC.\n\u003e \u003e \u003e Worse, if our node is a forwarding node, it would be easy for a third\n\u003e party to arrange to have our funds in various HTLCs.\n\u003e \u003e\n\u003e \u003e Hopefully this recovery system is used by people whose channels are in\n\u003e \u003e a HTLC free state 99.9999% of the time (and hopefully hardware\n\u003e \u003e failures do not somehow coincide with HTLCs!).\n\u003e \u003e As a user, it would be cool to be able to just lock up all my Bitcoin\n\u003e \u003e into channels with well-established lightning nodes. That way if fees\n\u003e \u003e go ballistic I can still move money around cheaply.\n\u003e \u003e One of the main concerns for this pattern of user behaviour is the\n\u003e \u003e recovery story I think. The first line of defence for routing nodes\n\u003e \u003e (people who are taking their role in LN seriously) has to be redundant\n\u003e \u003e data storage.\n\u003e \u003e This would be a poor last-resort solution for routing nodes.\n\u003e\n\u003e A common occurrence is that hardware failure is not detected until when\n\u003e the hardware is used, especially when used by casual users.\n\u003e\n\u003e Consider the sequence of events:\n\u003e\n\u003e * Part of the storage device fails.\n\u003e   * Due to being a casual user, the user does not use state-of-the-art\n\u003e checksumming filesystems like ZFS and does not monitor disk health by\n\u003e S.M.A.R.T.\n\u003e * A high-onchain-fee condition exists.\n\u003e * The casual user attempts to send out a payment consisting of almost all\n\u003e funds in their LN channels via several HTLCs on MPP or other multipath.\n\u003e * Because of the activity generated, the filesystem assigns the LN\n\u003e database to the failing part.\n\u003e * Storage fails with most funds in outgoing HTLCs.\n\u003e\n\u003e Thus, merely activating the wallet and using HTLCs may result in a\n\u003e *detectable* failure of the hardware (which was already failing before,\n\u003e just not noticed by the casual user).\n\u003e\n\u003e On the other hand, we can consider this situation as having a complexity\n\u003e penalty.\n\u003e\n\u003e As someone who has seen a lot of storage devices slowly fail in unique and\n\u003e interesting (and data-losing) ways, I am always going to assume that\n\u003e storage devices are going to fail at any time, including a few hours after\n\u003e installation.\n\u003e\n\u003e It would be preferable if HTLCs and PTLCs are not gifted.\n\u003e On the other hand, it might not be possible (as you note about PTLCs).\n\u003e\n\u003e \u003e\n\u003e \u003e \u003e Using static-key channels (i.e. channel keys are our node keys) allows\n\u003e us to recover even the outgoing channel with outgoing HTLC that has been\n\u003e forgotten by the outgoing peer.\n\u003e \u003e\n\u003e \u003e Right. I think this doesn't work with PTLCs though.\n\u003e\n\u003e Yes, loss of the adaptor signature means we cannot recover in this case.\n\u003e\n\u003e \u003e\n\u003e \u003e \u003e Using static-key channels does have slightly weaker privacy:\n\u003e \u003e \u003e\n\u003e \u003e \u003e -   Published nodes reveal all their channels with other published\n\u003e nodes on the blockchain.\n\u003e \u003e \u003e     -   While it is true that published nodes already reveal their\n\u003e channels with published nodes, they are currently only revealed on the LN\n\u003e gossip network, which is not archived; historical channels that are now\n\u003e closed are not informed to current surveillors.\n\u003e \u003e \u003e         -   On the other hand, all it takes is one \"LN wayback\n\u003e machine\" to record all LN gossip, which are self-attesting and include a\n\u003e signature from the node.\n\u003e \u003e \u003e -   Unpublished nodes risk revealing their channels with published\n\u003e nodes via the blockchain.\n\u003e \u003e \u003e     -   Invoices created by unpublished nodes currently reveal their\n\u003e public key.\n\u003e \u003e \u003e         Payers can then uncover all the channels of that node.\n\u003e \u003e \u003e\n\u003e \u003e\n\u003e \u003e I don't think so? You need to know the private key of the node to\n\u003e \u003e discover its channels! The points actually used in the channels would\n\u003e \u003e be randomized with shared secret from Diffie-Hellman so are unlinkable\n\u003e \u003e to the public keys of the two nodes under decisional Diffie-Hellman\n\u003e \u003e assumption.\n\u003e\n\u003e Right, that would work.\n\u003e\n\u003e How about just using a multiplicative tweak of your own privkey and the\n\u003e pubkey of the other node (i.e. just use the \"raw\" ECDH point), that would\n\u003e work as 2-of-2 in 2p-ECDSA, and I believe (but do not know) should also be\n\u003e signable using MuSig/MuSig2 under taproot?\n\u003e\n\u003e\n\u003e \u003e\n\u003e \u003e There is more minor but still real concern of \"deniability\" of\n\u003e \u003e unpublished closed channels if a large node operator later becomes\n\u003e \u003e corrupted or coerced by a malicious actor. Since the node operator\n\u003e \u003e still knows their secret key (obviously) they can still do a scan\n\u003e \u003e (same as you would do in recovery) on the whole chain and find any\n\u003e \u003e past channels they had with any nodes.\n\u003e\n\u003e \"Peer selling private information\" is always going to be an issue with\n\u003e unpublished channels, and this seems to be an inherent issue with that\n\u003e model.\n\u003e\n\u003e Note that due to the existence of proof-of-discrete-log-equivalence, a\n\u003e node operator can *prove* to someone buying private information that a\n\u003e particular outpoint onchain is actually an unpublished channel.\n\u003e If I have privkey `z` and you have pubkey `L`, I can show `z * G` (my node\n\u003e pubkey), `L` (your \"unpublished\" (ha, ha) node pubkey), and `z * L` (our\n\u003e ECDH secret), plus a proof-of-discrete-log-equivalence that the `z` in `z *\n\u003e G` is the same `z` in `z * L`, in order to convice them of the ECDH secret.\n\u003e I suspect part of the proof-of-discrete-log-equivalance can be gated as\n\u003e well by a ZKCP on payment point+scalar the proof is provided only on\n\u003e payment.\n\u003e The selling node operator does not even need to reveal `z`.\n\u003e\n\u003e As the ECDH secret is what tweaks the channel keys, that is enough to\n\u003e convince any surveilling buyer.\n\u003e Further, `z` is not revealed, and channel funds cannot be stolen by just\n\u003e knowledge of the ECDH secret, thus protecting the interests of the selling\n\u003e forwarding node.\n\u003e\n\u003e Now of course, I could just be making up `L` (i.e. LL could be a\n\u003e sockpuppet of mine).\n\u003e However, between these two choices:\n\u003e\n\u003e * I lock up a set number of millisatoshi in a Z + L channel where L is a\n\u003e sockpuppet, and sell this fake information to surveillors.\n\u003e * I lock up a set number of millisatoshi in a Z + L channel where L is a\n\u003e genuine user node that thinks unpublished channels are private, and sell\n\u003e this genuine information to surveillors.\n\u003e\n\u003e Which is more lucrative for me?\n\u003e The latter case would be more lucrative for me, as I not only earn from\n\u003e selling your data to surveillors, I also earn routing fees.\n\u003e The former case can only earn me selling fake data to surveillors, with no\n\u003e opportunity to earn forwarding fees.\n\u003e\n\u003e \u003e A mitigation of this problem\n\u003e \u003e would be for users who want unpublished channels to turn the\n\u003e \u003e use-node-key-as-channel-key feature off for their keys in the channel\n\u003e \u003e so they would still be able to do a backup-free channel scan but the\n\u003e \u003e well-established node would lose the ability to do so.\n\u003e\n\u003e If the user has all channels unpublished, it is not (normally) gossiped.\n\u003e So the well-established node would not have the ability to recover *all*\n\u003e channels by backup-free scans of published nodes in the first place, only\n\u003e those that are to published nodes.\n\u003e\n\u003e Or do you refer to something else?\n\u003e\n\u003e It might be easier for the \"client\" here to make up different node IDs for\n\u003e each \"server\" it connects to, by e.g. hashing its base privkey with the\n\u003e server pubkey and using the hash as the privkey for its fake node ID with\n\u003e that server.\n\u003e\n\u003e\n\u003e \u003e This means that\n\u003e \u003e after the channel is closed there would be no way for the large node\n\u003e \u003e to find the channel again assuming they honestly delete the data.\n\u003e\n\u003e If forwarding nodes are expected to have storage redundancy, deletion of\n\u003e data could be difficult as well --- there may be lots of replicas of that\n\u003e data in various places (including obsolete replicas that the node operator\n\u003e might not particularly care about, being obsolete), and deletion might not\n\u003e catch them all.\n\u003e \"Honestly delete\" seems like a best-effort to me.\n\u003e\n\u003e On the other hand, if the model is that privacy is to be trusted to your\n\u003e peers, then this is no worse than unpublished channels, which has the same\n\u003e model.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201218/d47a1446/attachment-0001.html\u003e"}