{"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:2020-06-20\n📝 Original message:\nHello Dave and list,\n\nThanks for your quick answers!\n\nThe attacker would be broadcasting the latest\n\u003e state, so the honest counterparty would only need to send one blind\n\u003e child.\n\u003e\n\nExactly, if the attacker submits an outdated transaction he would be\nshooting himself in the foot,\nas we could claim the revocation paths when seeing the transaction in a\nblock and get all the\nchannel funds (since the attacker's outputs will be CSV-locked).\n\nThe only way your Bitcoin peer will relay your blind child\n\u003e is if it already has the parent transaction.\n\u003e\n\nThat's an excellent point that I missed in the blind CPFP carve-out trick!\nI think this makes the\nblind CPFP carve-out quite hard in practice (even using getdata - thanks\nfor detailing that option)...\n\nIn the worst case scenario where most miners' mempools contain the\nattacker's tx and the rest of\nthe network's mempools contains the honest participant's tx, I think there\nisn't much we can do.\nWe're simply missing information, so it looks like the only good solution\nis to avoid being in that\nsituation by having a foot in miners' mempools. Do you think it's\nunreasonable to expect at least\nsome LN nodes to also invest in running nodes in mining pools, ensuring\nthat they learn about\nattackers' txs and can potentially share discovered preimages with the\nnetwork off-chain (by\ngossiping preimages found in the mempool over LN)? I think that these\nrecent attacks show that\nwe need (at least some) off-chain nodes to be somewhat heavily invested in\non-chain operations\n(layers can't be fully decoupled with the current security assumptions -\nmaybe Eltoo will help\nchange that in the future?).\n\nThank you for your time!\nBastien\n\n\n\nLe ven. 19 juin 2020 à 22:53, David A. Harding \u003cdave at dtrt.org\u003e a écrit :\n\n\u003e On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev\n\u003e wrote:\n\u003e \u003e I think you're assuming here that the attacker broadcast a particular\n\u003e \u003e state.\n\u003e\n\u003e Whoops, I managed to confuse myself despite looking at Bastien's\n\u003e excellent explainer.  The attacker would be broadcasting the latest\n\u003e state, so the honest counterparty would only need to send one blind\n\u003e child.  However, the blind child will only be relayed by a Bitcoin peer\n\u003e if the peer also has the parent transaction (the latest state) and, if\n\u003e it has the parent transaction, you should be able to just getdata('tx',\n\u003e $txid) that transaction from the peer without CPFPing anything.  That\n\u003e will give you the preimage and so you can immediately resolve the HTLC\n\u003e with the upstream channel.\n\u003e\n\u003e Revising my conclusion from the previous post:\n\u003e\n\u003e I think the strongman argument for the attack would be that the attacker\n\u003e will be able to perform a targeted relay of the low-feerate\n\u003e preimage-containing transaction to just miners---everyone else on the\n\u003e network will receive the honest user's higher-feerate expired-timelock\n\u003e transaction.  Unless the honest user happens to have a connection to a\n\u003e miner's node, the user will neither be able to CPFP fee bump nor use\n\u003e getdata to retrieve the preimage.\n\u003e\n\u003e Sorry for the confusion.\n\u003e\n\u003e -Dave\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200620/6caf18ec/attachment.html\u003e"}