From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id D214FC016E; Fri, 19 Jun 2020 19:59:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id C5FA18968F; Fri, 19 Jun 2020 19:59:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOHbRrL1lQ0p; Fri, 19 Jun 2020 19:59:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87]) by whitealder.osuosl.org (Postfix) with ESMTPS id ECBF789682; Fri, 19 Jun 2020 19:59:32 +0000 (UTC) Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1jmNAh-0002mU-8w; Fri, 19 Jun 2020 15:59:31 -0400 Date: Fri, 19 Jun 2020 15:58:46 -0400 From: "David A. Harding" To: Bastien TEINTURIER Message-ID: <20200619195846.fclw4ilngvbbf2kk@ganymede> References: <67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com> <62P_3wvv8z7AVCdKPfh-bs30-LliHkx9GI9Og3wqIK6hadIG0d6MJJm077zac1erpPUy31FqgZjkAjEl9AQtrOCg4XA5cxozBb7-OIbbgvE=@protonmail.com> <4c4f3a06-0078-ef6a-7b06-7484f0f9edf1@mattcorallo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jtgixlvhk3n3d3gp" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Cc: Bitcoin Protocol Discussion , lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 19:59:33 -0000 --jtgixlvhk3n3d3gp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 19, 2020 at 09:44:11AM +0200, Bastien TEINTURIER via Lightning-dev wrote: > The gist is here, and I'd appreciate your feedback if I have wrongly > interpreted some of the ideas: > https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12 Quoted text below is from the gist: > The trick to protect against a malicious participant that broadcasts a > low-fee HTLC-success or Remote-HTLC-success transaction is that we can > always blindly do a CPFP carve-out on them; we know their txid I think you're assuming here that the attacker broadcast a particular state. However, in a channel which potentially had thousands of state changes, you'd have to broadcast a blind child for each previous state (or at least each previous state that pays the attacker more than the latest state). That's potentially thousands of transactions times potentially dozens of peers---not impossible, but it seems messy. I think there's a way to accomplish the same goal for less bandwidth and zero fees. The only way your Bitcoin peer will relay your blind child is if it already has the parent transaction. If it has the parent, you can just request it using P2P getdata(type='tx', id=$txid).[1] You can batch multiple txid requests together (up to 50,000 IIRC) to minimize overhead, making the average cost per txid a tiny bit over 36 bytes. If you receive one of the transactions you request, you can extract the preimage at no cost to yourself (except bandwidth). If you don't receive a transaction, then sending a blind child is hopeless anyway---your peers won't relay it. Overall, it's hard for me to guess how effective your proposal would be at defeating the attack. I think the strongman argument for the attack would be that the attacker will be able to perform a targeted relay of their outdated state to just miners---everyone else on the network will receive the counterparty's honest final-state close. Unless the counterparty happens to have a connection to a miner's node, the counterparty will neither be able to CPFP fee bump nor use getdata to retrieve the preimage. It seems to me it's practical for a motivated attacker to research which IP addresses belong to miners so that they can target them, whereas honest users won't practically be able to do that research (and, even if they could, it would create a centralizing barrier to new miners entering the market if users focused on maintaining connections to previously-known miners). -Dave [1] You'd have to be careful to not attempt the getdata too soon after you think the attacker broadcast their old state, but I think that only means waiting a single block, which you have to do anyway to see if the honest final-commitment transaction confirmed. See https://github.com/bitcoin/bitcoin/pull/18861 --jtgixlvhk3n3d3gp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl7tGPYACgkQ2dtBqWwi adPzhQ/+I3eoyM13TVuP/EKYvere7YrNkeyft+2lPxoUowhWH822My6g3r/4Bx/m UKhWIZTlxBQ7+rIrFULbyC3Df9znO01/D0QfTwIlCPRLW15sDaaHDaQfFKiP6gAT KyaU+iUiwUAn1+ve09omCywly6wQ0RVh8MGDBYeFdGufAkl7GTR5tAlAYpxUx8g4 V1+7qQZzHeUamZAk2SD324+NcjHxz1HHLsgSAPXb3aJ+wXF89XNiTr4zFov8mWT1 iQmEvfUTm/hzaD+9kn9URDp2Mte2MXR3LLbAGkEbVfawd1KBHB465ldFPtyDRQyM +uucdc2afSk2PpE17ea+SoZqW3OpYlvklrcRwwy48td6NvHm105T1uSkRwdm5r/W fy2jvn4Y+EMz1hkkE0Z8JVS4WS9D/us3kpVNKGLAzgw7MQOwdd0tq+JjDjn5RV0+ JEzKoXYA11fdYOrVuvE1Jge6O25vv8R4zFRP7DMfnWCD7mC4VGwEZYW0JaNAhMRJ TUQ9JCxgPkOb7mnGtNWpCDFc9QjZ161Q43CbJ30EwOvJfwLUZrKgfIeDB4gyO0pu 5BFQxneI8PEE1l0Fyi0bw7Ys3AHcyMkN5I01VKlnMEZhNyhKCjiE+YF1nXKHmJyp Q5q2o3SzpABp3JidAS3ggan9ACs+b5oM1TEMvI+z7GIuZxC4NL4= =puRl -----END PGP SIGNATURE----- --jtgixlvhk3n3d3gp--