{"type":"rich","version":"1.0","author_name":"npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","author_url":"https://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-05-05\n🗒️ Summary of this message: The introduction of dual funded transactions in lightning has created challenges in protecting against liquidity griefing attacks from malicious peers. An elegant solution is to never lock utxos used in dual funded transactions, but this falls short when using 0-conf. Nodes offering 0-conf services expose themselves to liquidity griefing. Another related issue is that nodes that want to offer 0-conf channels must ensure that the utxos they use for 0-conf are isolated from the utxos they use for non 0-conf.\n📝 Original message:\nGood morning list,\n\nOne of the challenges created by the introduction of dual funded\ntransactions [1] in lightning is how to protect against liquidity\ngriefing attacks from malicious peers [2].\n\nLet's start by reviewing this liquidity griefing issue. The dual funding\nprotocol starts by exchanging data about the utxos each peer adds to the\nshared transaction, then exchange signatures and broadcast the resulting\ntransaction. If peers lock their utxos as soon as they've decided to add\nthem to the shared transaction, the remote node may go silent. If that\nhappens, the honest node has some liquidity that is locked and unusable.\n\nThis cannot easily be fixed by simply unlocking utxos *after* detecting\nthat the remote node is fishy, because the remote node would still have\nsucceeded at locking your liquidity for a (small) duration, and could\nstart other instances of that attack with different node_ids.\n\nAn elegant solution to this issue is to never lock utxos used in dual\nfunded transactions. If a remote node goes silent in the middle of an\ninstance of the protocol, your utxos will automatically be re-used in\nanother instance of the protocol. The only drawback with that approach\nis that when you have multiple concurrent instances of dual funding with\nhonest peers, some of them may fail because they are double-spent by one\nof the concurrent instances. This is acceptable, since the protocol\nshould complete fairly quickly when peers are honest, and at worst, it\ncan simply be restarted when failure is detected.\n\nBut that solution falls short when using 0-conf, because accidentally\ndouble-spending a 0-conf channel (because of concurrent instances) can\nresult in loss of funds for one of the peers (if payments were made on\nthat channel before detecting the double-spend). It seems like using\n0-conf forces us to lock utxos to avoid this issue, which means that\nnodes offering 0-conf services expose themselves to liquidity griefing.\n\nAnother related issue is that nodes that want to offer 0-conf channels\nmust ensure that the utxos they use for 0-conf are isolated from the\nutxos they use for non 0-conf, otherwise it is not possible to properly\nlock utxos, because of the following race scenario:\n\n- utxoA is selected for a non 0-conf funding attempt and not locked\n  (to protect against liquidity griefing)\n- utxoA is also selected for a 0-conf funding attempt (because it is\n  found unlocked in the wallet) and then locked\n- the funding transaction for the 0-conf channel is successfully\n  published first and that channel is instantly used for payments\n- the funding transaction for the non 0-conf channel is then published\n  and confirms, accidentally double-spending the 0-conf channel\n\nThis can be fixed by using a \"soft lock\" when selecting utxos for a non\n0-conf funding attempt. 0-conf funding attempts must ignore soft locked\nutxos while non 0-conf funding attempts can (should) reuse soft locked\nutxos.\n\nIn eclair, we are currently doing \"opportunistic\" 0-conf:\n\n- if we receive `channel_ready` immediately (which means that our peer\n  trusts us to use 0-conf)\n- and we're the only contributor to the funding transaction (our peer\n  doesn't have any input that they could use to double-spend)\n- and the transaction hasn't been RBF-ed yet\n\nThen we immediately send `channel_ready` as well and start using that\nchannel (because we know we won't double spend ourselves). This is nice\nbecause it lets us use 0-conf in a way where only one side of the\nchannel needs to trust the other side (instead of both sides trusting\neach other).\n\nUnfortunately, we cannot do that anymore when mixing 0-conf and non\n0-conf funding attempts, because the utxos may be soft locked,\npreventing us from \"upgrading\" to 0-conf.\n\nYou have successfully reached the end of this quite technical post,\ncongrats! My goal with this post is to gather ideas on how we could\nimprove that situation and offer good enough protections against\nliquidity griefing for nodes offering 0-conf services. Please share\nyour ideas! And yes, I know, 0-conf is a massive implementation pain\npoint that we would all like to remove from our codebases, but hey,\nusers like it ¯\\_(ツ)_/¯\n\nCheers,\nBastien\n\n[1] https://github.com/lightning/bolts/pull/851\n[2] https://github.com/lightning/bolts/pull/851#discussion_r997537630\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230505/9638cc46/attachment-0001.html\u003e"}