diff options
| author | Peter Todd <pete@petertodd.org> | 2023-01-13 18:37:04 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-01-13 23:37:17 +0000 |
| commit | 92e8b7f4e8e307c0cc44bc48437c7db908e6e852 (patch) | |
| tree | e933a7981f8a9bc6ae5a29743989d02cf655aa81 | |
| parent | 7be4f5868567987d40d203feae6198ee1aa3c3d6 (diff) | |
| download | pi-bitcoindev-92e8b7f4e8e307c0cc44bc48437c7db908e6e852.tar.gz pi-bitcoindev-92e8b7f4e8e307c0cc44bc48437c7db908e6e852.zip | |
Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive
| -rw-r--r-- | 78/0f94086e7c2aa60bdee0c4aaffcb37e7e043dc | 205 |
1 files changed, 205 insertions, 0 deletions
diff --git a/78/0f94086e7c2aa60bdee0c4aaffcb37e7e043dc b/78/0f94086e7c2aa60bdee0c4aaffcb37e7e043dc new file mode 100644 index 000000000..6e2151aa4 --- /dev/null +++ b/78/0f94086e7c2aa60bdee0c4aaffcb37e7e043dc @@ -0,0 +1,205 @@ +Return-Path: <pete@petertodd.org> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id A5EE6C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 13 Jan 2023 23:37:17 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id 64ABE400D3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 13 Jan 2023 23:37:17 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 64ABE400D3 +Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key, + unprotected) header.d=messagingengine.com header.i=@messagingengine.com + header.a=rsa-sha256 header.s=fm3 header.b=GCSWWDvD +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.602 +X-Spam-Level: +X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Received: from smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id Kk_Ap3adI6Ho + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 13 Jan 2023 23:37:15 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 87997400C8 +Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com + [64.147.123.19]) + by smtp2.osuosl.org (Postfix) with ESMTPS id 87997400C8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 13 Jan 2023 23:37:15 +0000 (UTC) +Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) + by mailout.west.internal (Postfix) with ESMTP id 85C1F3200927; + Fri, 13 Jan 2023 18:37:09 -0500 (EST) +Received: from mailfrontend2 ([10.202.2.163]) + by compute5.internal (MEProxy); Fri, 13 Jan 2023 18:37:09 -0500 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= + messagingengine.com; h=cc:cc:content-type:date:date:feedback-id + :feedback-id:from:from:in-reply-to:in-reply-to:message-id + :mime-version:references:reply-to:sender:subject:subject:to:to + :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= + fm3; t=1673653029; x=1673739429; bh=rHyHXbAqGHCaZSx3VFm8/xE+lbCE + nbrdwujDAbN4dIU=; b=GCSWWDvDCAoDC0pdsAY9BIFjlMmW6SYKCEFf05hE+ogd + meT5LT1Pf2axqD1sXSGeoxOYtghNt3x0KnTIUTcW9KWlwpNNygXxAuC4sKA/0qAy + iS2iEJBCvGW2okY/cC5PWEuXHpaaOWISnCToVs15mVO/2DVa/TaICfUjbj6rnYUW + Fps3DaJ5bSsjqg6REUHMAm/J8M5hzFyHVB27JrU1x/7/Xtz+cvX5a4HRAwJMFWpO + z7en2+KTCAUWAOJYpy3p5gp8Y1j1bTtnniUaz2EWI3lonOaPQPLig7/3VGwA+zQW + 6RxP+rS1yINY4nJ4lkMXIn+zzKom0CD3elzQW535oQ== +X-ME-Sender: <xms:JOvBY4N0DEFnl6zgqvdJv3AUQ0AxSf2cfq8ToNi7BGc2BI0JgT-mYw> + <xme:JOvBY-9ptS2XrnQ_96rFryJuDNDTjUGgNlhicOpuuCze3TjbrjAN9PkREnNroqI_d + ih9bvTctoSfQp4MBkk> +X-ME-Received: <xmr:JOvBY_QsH1V-RIkwEwfg8n5vf5EDgHim1qU8l7i4-d4tf2nEneMaJoavKsoaXQ> +X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrleelgdduvdcutefuodetggdotefrodftvf + curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu + uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkfhggtggujgesghdtre + ertddtvdenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthho + uggurdhorhhgqeenucggtffrrghtthgvrhhnpeelvdellefftddukeduffejgfefjeeuhe + eileeftdfgteduteeggeevueethfejtdenucffohhmrghinhepphgvthgvrhhtohguugdr + ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe + hpvghtvgesphgvthgvrhhtohguugdrohhrgh +X-ME-Proxy: <xmx:JOvBYwvIfI43eOtme1FU2QSr_ax-Gmfp3YResGTnSRsetK-m9tC49w> + <xmx:JOvBYwfTQvcL7V5mXMebU_iQI1lFtD83C438-TCZ9K-PdrbvK9wHrQ> + <xmx:JOvBY03AZm7ni9KW52GG9LHW-Cy2E4ET5J5kLpL4tJLPUdpdWTOmqQ> + <xmx:JevBY44CeJCtnqo9zvLJgLoVy4uVwX5nbOh6MqWKGXmi_zfwG4-RBA> +Feedback-ID: i525146e8:Fastmail +Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, + 13 Jan 2023 18:37:08 -0500 (EST) +Received: by localhost (Postfix, from userid 1000) + id 5AA9C5F82C; Fri, 13 Jan 2023 18:37:04 -0500 (EST) +Date: Fri, 13 Jan 2023 18:37:04 -0500 +From: Peter Todd <pete@petertodd.org> +To: "David A. Harding" <dave@dtrt.org> +Message-ID: <Y8HrINYYYiw+V9v+@petertodd.org> +References: <Y7ySzDjzx5eDjOH9@petertodd.org> + <aaaeda2950e61127a3218c523927a0d8@dtrt.org> + <Y70mNHsX4JcKYZyi@petertodd.org> + <6089e1f0140684435bf5e87b0c13d561@dtrt.org> + <Y704non5DD5mtxs1@petertodd.org> + <6cebd312ca960e634729cc574c2e97b0@dtrt.org> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha512; + protocol="application/pgp-signature"; boundary="V0vev2iJbgUJXWrn" +Content-Disposition: inline +In-Reply-To: <6cebd312ca960e634729cc574c2e97b0@dtrt.org> +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty + Protocols Significantly More Expensive +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 13 Jan 2023 23:37:17 -0000 + + +--V0vev2iJbgUJXWrn +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Tue, Jan 10, 2023 at 10:14:47AM -1000, David A. Harding wrote: +> On 2023-01-10 00:06, Peter Todd wrote: +> > Remember, we'd like decentralized coinjoin implementations like +> > Joinmarket to +> > work. How does a decentralized coinjoin implement "conflict monitoring"? +>=20 +> 1. Run a relay node with a conflict-detection patch. Stock Bitcoin Core +> with -debug=3Dmempoolrej will tell you when it rejects a transaction +> for conflicting with a transaction already in the mempool, e.g.: +>=20 +> 2022-11-01T02:53:17Z +> 867b85d68d7a7244c1d65c4797006b56973110ac243ab5ee15a8c4d220060c58 from +> peer=3D58 was not accepted: txn-mempool-conflict +>=20 +> I think it would be easy to extend this facility to list the inputs +> which conflicted. So if Alice sees a conflict created by Mallory, +> she can create a new coinjoin transaction without Mallory. This +> method has the advantage of being fast and attributing fault, +> although it does require Alice's node be online at the time Mallory's +> conflict is propagated. + +So for something as simple as reliable coinjoining - an important privacy +feature that we'd like all wallets to use - you expect people to run +well-connected 24/7 nodes running specialty software? + +Even if you run a node as you suggest, there's certainly no guarantee that +you'd learn about any double-spend without doing a severe sybil attack agai= +nst +the network; the 8 outgoing nodes a typical node has samples a tiny fractio= +n of +the network. And *even if* you sybil attack to try to detect conflicts ther= +e's +still no guarantee as attackers can use all kinds of special techniques to = +get +transactions into miner mempools and not others. + +> 2. Simply assume a conflict exists for otherwise unexplainable failures. +> For example, if Alice sees several new blocks whose bottom feerates +> are well below the feerates of an unconfirmed coinjoin transaction +> that Alice helped create and broadcast, she can assume it's a +> conflict that is preventing preventing confirmation of the coinjoin. +> She can find an entirely different set of collaborators and create a +> non-conflicting transaction without ever needing to know which inputs +> from the original transaction conflicted. This method has the +> disadvantage of being slow (on the order of hours) and not attributing +> fault, although it doesn't require Alice has any information beyond +> copies +> of recent blocks. + +You're suggesting that to avoid enabling full-rbf, coinjoin's and other +decentralized multi-party protocols risk getting coins tied up for hours tr= +ying +to do conflict resolution rather than just fixing the underlying problem wi= +th +what's literally a one-line code change that 17% of the v24.x nodes have +decided to enable. + +> I didn't list these methods or others before because the specific method +> used to +> detect conflicts doesn't matter to the realization that software which +> uses conflict detection and evasion to defeat the $17.00 attack also +> defeats the $0.05 attack without any need for full-RBF. + +Fact is, full-rbf defeats those attacks much better. And I'm amazed that you +don't consider raising the cost of attacks on coinjoins and similar +decentralized protocols by almost three orders of magnitude to be important: +why are you prioritizing a few highly centralized, often AML/KYC'd, unconfi= +rmed +tx acceptance services over decentralized protocols which provide privacy a= +nd +security to a lot more users? + +--=20 +https://petertodd.org 'peter'[:-1]@petertodd.org + +--V0vev2iJbgUJXWrn +Content-Type: application/pgp-signature; name="signature.asc" + +-----BEGIN PGP SIGNATURE----- + +iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmPB6x8ACgkQLly11TVR +LzeAuBAArPiq6tF53SMPKYvaTtWAIB4bptWJkw+a+1YpQZNi2Z2M12ECyun2lVIu +x04xYuanmgHDZ2D7fNiK58pMQjVp73Q9ZSc/EYAr67/S/AuSLo9IWh3NaLnaZVtE ++4yuJiJlREV3b6hIaQmqoog/LYsDEYJLW/pv5C+NMqmsi2c5TIEX9AtozOWGcNqG +lPNYggJBFx9Lm0jMmoLECYXBfICZbgJulJNKSl8aZoCTB1bbK2LSYz7tE4WNNgyA +C2NyDSKDG0I1/ltEhz0fXP1bXCZYmjMzRC2CwUlrIxwgzTfbabQpBGi+T0JQAEYL +rpL9/LENZgY/3puoU9/MY43/6Bhdh5lIls/J0f/PxSW5zp14qflmm61ZYJu1qZne +WUqs4ySoPxf4I5xIdz4llfHEJP7X6i5GYBIoM+zD08yJbyOHfxNQbKn0MC0aok76 +X/ncpMpNBe3MJT1nEeQrkqiG1D9ErLV2/vR6y+KYXuqIcj6Zbcx52alxZLoaKXq2 +4xFw1Q8LUH8CU6bGhf0onqJFNlcB5L+LVdTHEbuFe80qlwfvEOumz1V9OJvfTfiN +mv/DhFD2rT8MvxrtqraU2qhN81y9Jrx7JKUy04HIOp+XqwOZKk4bdPXQ15MdY+Hx +nN8tLR03Ro7+Ru34obaRTbGoXRWPO8dj7rsollyTJgUExdB9vXc= +=g6ko +-----END PGP SIGNATURE----- + +--V0vev2iJbgUJXWrn-- + |