diff options
| author | Peter Todd <pete@petertodd.org> | 2022-11-09 07:41:30 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-11-09 12:41:36 +0000 |
| commit | d68427ae3609349af5ccc1ada0aa3131f14504a2 (patch) | |
| tree | 08d4bf25dc5db1307cde405aff0987ca379473d0 | |
| parent | 26ceb93144f82c04f7c348c53029e2385cfed0bb (diff) | |
| download | pi-bitcoindev-d68427ae3609349af5ccc1ada0aa3131f14504a2.tar.gz pi-bitcoindev-d68427ae3609349af5ccc1ada0aa3131f14504a2.zip | |
Re: [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime
| -rw-r--r-- | 99/ae147444c1dac2e86277d0f87421c2bb8ee552 | 225 |
1 files changed, 225 insertions, 0 deletions
diff --git a/99/ae147444c1dac2e86277d0f87421c2bb8ee552 b/99/ae147444c1dac2e86277d0f87421c2bb8ee552 new file mode 100644 index 000000000..092bcf59a --- /dev/null +++ b/99/ae147444c1dac2e86277d0f87421c2bb8ee552 @@ -0,0 +1,225 @@ +Return-Path: <pete@petertodd.org> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 556C9C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 9 Nov 2022 12:41:36 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 159E581310 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 9 Nov 2022 12:41:36 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 159E581310 +Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key, + unprotected) header.d=messagingengine.com header.i=@messagingengine.com + header.a=rsa-sha256 header.s=fm1 header.b=KL/zJJsg +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 smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id e1ZxnN9I-dQT + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 9 Nov 2022 12:41:34 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 90D9A8130F +Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com + [64.147.123.21]) + by smtp1.osuosl.org (Postfix) with ESMTPS id 90D9A8130F + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 9 Nov 2022 12:41:34 +0000 (UTC) +Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) + by mailout.west.internal (Postfix) with ESMTP id 9591D32009D3; + Wed, 9 Nov 2022 07:41:32 -0500 (EST) +Received: from mailfrontend1 ([10.202.2.162]) + by compute3.internal (MEProxy); Wed, 09 Nov 2022 07:41:32 -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= + fm1; t=1667997692; x=1668084092; bh=cO056ZAky29DqtZa+zTZKbsnWG4Y + 3D3/TDotPUgFtT0=; b=KL/zJJsgyFMwnAAEky2Eug2j1hyQIQh+hDhoSpj/IOfM + TXMrsC50DlLBw/gvv9MMGMESaGeDwKs6SCuCpL9Hkc6PdnwM9VADzswpV224AVxT + oscpivQaI3e2P4m/4T/UwiuWhtvmMcRSRIfnC2a8x3ZImunHuuaOTV6ocDgEUdDk + hcXxNw9jvoAVGf64/ID4urrp7lq8e38PRqSsShWYDHB31EgL/Zr2QAom7incKbvy + AZ+DnZY3B69svjlqkrPM9yj11+r4hy9GBXnva0YH58tX/94oeuyw5/LlfrAXz5SF + dI7v4h/bmvijqAYWIcwk/q4zbjUBWzLx63vr6+XNkw== +X-ME-Sender: <xms:_J9rYxFO8vNCqIpUR71UcQCQlvNOGFTk29D5ptKZ0tIdXEI279oBZQ> + <xme:_J9rY2Wf8I1V8I8bo9H74BS-ghE46DXw33eUN0h6uDjvTfEF6RnQSd9C6wPQ_InqV + bBqO5fIXcV7XB7urAg> +X-ME-Received: <xmr:_J9rYzL0JB06lzs0Zq5OOsnlyFalGtGlaHlNDLAF8tkadh9qdW4EATk0G9YX> +X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedvgdegvdcutefuodetggdotefrodftvf + curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu + uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc + fjughrpeffhffvvefukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrvghtvghr + ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg + hrnhepledvleelffdtudekudffjefgfeejueehieelfedtgfetudetgeegveeutefhjedt + necuffhomhgrihhnpehpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuihiivg + eptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehpvghtvghrthhouggurdho + rhhg +X-ME-Proxy: <xmx:_J9rY3FRHFu-rx-IrLjaucRAsqn_5C6Cto2GNn-RpT6qTA71j0cZ_g> + <xmx:_J9rY3X3qYobmBG4PNXXlKK7i1W8FbuTvRvLnh6ZmFcjKAfOX-rjXQ> + <xmx:_J9rYyMXdNVb0B2mnX6HQnUIsduiCdxRx1hPNZEJX3w2q2qFffzGtg> + <xmx:_J9rYyQeDZkPHjLazceJjuuzBpTbebpYL5YrYPh39pvMauTq448tkA> +Feedback-ID: i525146e8:Fastmail +Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, + 9 Nov 2022 07:41:31 -0500 (EST) +Received: by localhost (Postfix, from userid 1000) + id AE9905F81E; Wed, 9 Nov 2022 07:41:30 -0500 (EST) +Date: Wed, 9 Nov 2022 07:41:30 -0500 +From: Peter Todd <pete@petertodd.org> +To: Antoine Riard <antoine.riard@gmail.com> +Message-ID: <Y2uf+hRBdLxOl6LT@petertodd.org> +References: <Y2ln2fJ+8+Q0qS0E@petertodd.org> <Y2l1/qXHxyctU9ir@petertodd.org> + <CALZpt+GgH7B-sSWndNfrMp8qza=LmZQ6BWGGFjFxcutat7Nxww@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha512; + protocol="application/pgp-signature"; boundary="7mIKDqQd2eJ71wgz" +Content-Disposition: inline +In-Reply-To: <CALZpt+GgH7B-sSWndNfrMp8qza=LmZQ6BWGGFjFxcutat7Nxww@mail.gmail.com> +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning + with nLockTime +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: Wed, 09 Nov 2022 12:41:36 -0000 + + +--7mIKDqQd2eJ71wgz +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Mon, Nov 07, 2022 at 05:55:59PM -0500, Antoine Riard wrote: +> Hi Peter, +>=20 +> > We can ensure with high probability that the transaction can be cancell= +ed/mined +> > at some point after N blocks by pre-signing a transaction, with nLockTi= +me set +> > sufficiently far into the future, spending one or more inputs of the +> > transaction with a sufficiently high fee that it would replace transact= +ion(s) +> > attempting to exploit Rule #3 pinning (note how the package limits in B= +itcoin +> > Core help here). +>=20 +> From my understanding, there are many open questions to such a +> pre-signed high-fee solution aiming to address Rule #3 pinning. +> Determining the high-fee to guarantee replacements with high odds. I +> think it should be superior to current top network mempools sat/vb * +> MAX_STANDARD_TX_WEIGHT, otherwise an adversary can pin the multi-party +> funded transaction on the ground of Core's +> replacement rule ("The replacement transaction's feerate is greater +> than the feerates of all directly conflicting transactions''). Though +> note the difficulty, the sat/vb is an unknown fact at time of +> signatures exchange among the multi-party funded transaction +> participants. Solving this issue probably requires from then to +> overshoot, and adopt a historical worst-case mempool feerate. + +First of all, since this is a punishment scenario, overshooting in general = +is a +good thing provided that the bad actor is the one paying for the overshoot. + +I may be mistaken on this point. But IIRC rule #6, "The replacement +transaction's feerate is greater than the feerates of all directly conflict= +ing +transactions.", refers to the overall package feerate including all +transactions that would need to be mined. + +This is relevant as we have two scenarios for pinning that could try to exp= +loit +rule #6 while pinning, and neither works: + +1) A large, low fee rate, transaction is spent by a high fee rate transacti= +on. +In this case the package fee rate of the second tx is still low, because the +low fee rate tx would need to be mined first. + +2) A small, high fee rate tx, is spent by a large low fee rate tx. In this = +case +the second low fee rate tx is irrelevant, because the high fee rate tx will= + get +mined soon, breaking the pin and costing the attacker money. + + +Now, if my understanding of rule #6 is incorrect, obviously we should fix t= +hat! +It's incentive incompatible to reject a high fee rate replacement that over= +all +pays more in fees (rule #3), on the basis that we expect a *different* mine= +r to +mine the low fee rate tx it spends. Because unless we're expecting the +transaction to somehow get mined by someone else in the near future, why ar= +en't +we mining what pays more money now? + +> This "historically-worst" sat/vb introduces two new issues, first I +> think this is an economic lower bound on the funds that can be staked +> in the collaborative transaction. Second I believe this constitutes a +> griefing vector, where a participant could deliberately pin to inflict +> an asymmetric damage, without entering into any fee competition. This +> griefing vector could be leveraged as hard as being triggered by a +> miner-as-participant in so-called miner harvesting attacks. +>=20 +> Further, I think this solution relying on nLocktime doesn't solve the +> timevalue DoS inflicted to the participants UTXOs, until the +> pre-signed high-fee transaction is final. If participants prefer to +> save the timevalue of their contributed UTXOs over operation success, +> a better approach could be for them to unilaterally spend after a +> protocol/implementation timepoint (e.g LN's funding timeout recovery +> mechanism). +>=20 +> A more workable solution I believe could be simply to rely on +> package-relay, an ephemeral anchor output, and a special replacement +> regime (e.g nVersion=3D3) to allow the multi-party funded transaction +> coordinator to unilateral fee-bump, in a step-by-step approach. I.e +> without making assumptions on the knowledge of network mempools and +> burning directly the worst amount in fees. + +Note that if you are considering miner harvesting attacks as part of the th= +reat +model, it's not clear to me that the v3 rules that depend on miners arbitra= +rily +rejecting transactions from their mempools are actually sufficiently incent= +ive +compatible to work. + +--=20 +https://petertodd.org 'peter'[:-1]@petertodd.org + +--7mIKDqQd2eJ71wgz +Content-Type: application/pgp-signature; name="signature.asc" + +-----BEGIN PGP SIGNATURE----- + +iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmNrn/cACgkQLly11TVR +LzdTTA//VMoanYSvWIxcN1GpRyLdr9ZXktlQGDqJvJEY/A70MymJCpH3Jm/cv8j4 +FhgG70JZrMgXojjfF4PGASLBP7H3I5h0KET8/aIY8zw+55ywekUu5kombXAcAs6A +bENi69hDVFE3yboudb7GCazO99k4WtEiQHByndMroLwgRaHCGWUg0tOQdwFaY1I2 +bvPrDoGDLCJIJY4r0PA+JGSdQgxywXUfabsUxRgReqKwWsdWsyD6jXb4WcGFkrL1 +Cd7fr9Z1TTIflQbmFswoRKoeuGzPHphmRGT1Zqq77G1ypP6EY8BomWHSt6JnIZTY +ymNUyHjpxBVrV3vsSxFm5Qj4nhnan9pIGZ0NSOHebdyHh/H0lXTtbI9strCpCUye +WG6LomTCA6u2KQZBJbDX4J2bGwKiyI6MzFnIgtE17yrjTj6YSlAg+ZHH3oFk5+NQ +/tAhd81piAL3MJv2vUI3OhuvzDOfPj27/ikAH1R4+KXGZ8hUL7Q3Yx5i6gGWNRmf +a/f4UhkcZbNBgo+k5a9BUsbbkpVX85FvzBdCyh5pDIMMvOqMyFOJ9CWZYHs3P0sS +VTpCkibLPNZbCt4UL/8fZeap7/dhyzkqBaUXtwGo5Sb13eCaaKPkvstAz7wPFR98 +l8zoUrTBMgd33cQDJpB1g2CDZ57l7TCvAlzfnJQ7k3otiLAssBo= +=Q2Iw +-----END PGP SIGNATURE----- + +--7mIKDqQd2eJ71wgz-- + |