rich1.0npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdhttps://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdnjumphttps://nostr.ae📅 Original date posted:2020-06-19 📝 Original message: On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev wrote: > I think you're assuming here that the attacker broadcast a particular > state. Whoops, I managed to confuse myself despite looking at Bastien's excellent explainer. The attacker would be broadcasting the latest state, so the honest counterparty would only need to send one blind child. However, the blind child will only be relayed by a Bitcoin peer if the peer also has the parent transaction (the latest state) and, if it has the parent transaction, you should be able to just getdata('tx', $txid) that transaction from the peer without CPFPing anything. That will give you the preimage and so you can immediately resolve the HTLC with the upstream channel. Revising my conclusion from the previous post: I think the strongman argument for the attack would be that the attacker will be able to perform a targeted relay of the low-feerate preimage-containing transaction to just miners---everyone else on the network will receive the honest user's higher-feerate expired-timelock transaction. Unless the honest user happens to have a connection to a miner's node, the user will neither be able to CPFP fee bump nor use getdata to retrieve the preimage. Sorry for the confusion. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200619/917b77aa/attachment.sig>