{"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 09:44:11AM +0200, Bastien TEINTURIER via Lightning-dev wrote:\n\u003e The gist is here, and I'd appreciate your feedback if I have wrongly\n\u003e interpreted some of the ideas:\n\u003e https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12\n\nQuoted text below is from the gist:\n\n\u003e The trick to protect against a malicious participant that broadcasts a\n\u003e low-fee HTLC-success or Remote-HTLC-success transaction is that we can\n\u003e always blindly do a CPFP carve-out on them; we know their txid\n\nI think you're assuming here that the attacker broadcast a particular\nstate.  However, in a channel which potentially had thousands of state\nchanges, you'd have to broadcast a blind child for each previous state\n(or at least each previous state that pays the attacker more than the\nlatest state).  That's potentially thousands of transactions times\npotentially dozens of peers---not impossible, but it seems messy.\n\nI think there's a way to accomplish the same goal for less bandwidth and\nzero fees.  The only way your Bitcoin peer will relay your blind child\nis if it already has the parent transaction.  If it has the parent, you\ncan just request it using P2P getdata(type='tx', id=$txid).[1]  You can\nbatch multiple txid requests together (up to 50,000 IIRC) to minimize\noverhead, making the average cost per txid a tiny bit over 36 bytes.\nIf you receive one of the transactions you request, you can extract the\npreimage at no cost to yourself (except bandwidth).  If you don't\nreceive a transaction, then sending a blind child is hopeless\nanyway---your peers won't relay it.\n\nOverall, it's hard for me to guess how effective your proposal would be\nat defeating the attack.  I think the strongman argument for the attack\nwould be that the attacker will be able to perform a targeted relay of\ntheir outdated state to just miners---everyone else on the network\nwill receive the counterparty's honest final-state close.  Unless the\ncounterparty happens to have a connection to a miner's node, the\ncounterparty will neither be able to CPFP fee bump nor use getdata to\nretrieve the preimage.\n\nIt seems to me it's practical for a motivated attacker to research which\nIP addresses belong to miners so that they can target them, whereas\nhonest users won't practically be able to do that research (and, even if\nthey could, it would create a centralizing barrier to new miners\nentering the market if users focused on maintaining connections to\npreviously-known miners).\n\n-Dave\n\n[1] You'd have to be careful to not attempt the getdata too soon after\n    you think the attacker broadcast their old state, but I think that\n    only means waiting a single block, which you have to do anyway to\n    see if the honest final-commitment transaction confirmed.  See\n    https://github.com/bitcoin/bitcoin/pull/18861\n\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/09974bd2/attachment.sig\u003e"}