{"type":"rich","version":"1.0","author_name":"npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","author_url":"https://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-06-19\n📝 Original message:\nOn Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev wrote:\n\u003e I think you're assuming here that the attacker broadcast a particular\n\u003e state.  \n\nWhoops, I managed to confuse myself despite looking at Bastien's\nexcellent explainer.  The attacker would be broadcasting the latest\nstate, so the honest counterparty would only need to send one blind\nchild.  However, the blind child will only be relayed by a Bitcoin peer\nif the peer also has the parent transaction (the latest state) and, if\nit has the parent transaction, you should be able to just getdata('tx',\n$txid) that transaction from the peer without CPFPing anything.  That\nwill give you the preimage and so you can immediately resolve the HTLC\nwith the upstream channel.\n\nRevising my conclusion from the previous post:\n\nI think the strongman argument for the attack would be that the attacker\nwill be able to perform a targeted relay of the low-feerate\npreimage-containing transaction to just miners---everyone else on the\nnetwork will receive the honest user's higher-feerate expired-timelock\ntransaction.  Unless the honest user happens to have a connection to a\nminer's node, the user will neither be able to CPFP fee bump nor use\ngetdata to retrieve the preimage.\n\nSorry for the confusion.\n\n-Dave\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200619/917b77aa/attachment.sig\u003e"}