path: root/99/ae147444c1dac2e86277d0f87421c2bb8ee552

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--