path: root/a9/b9647a4a61730c6a150b65796447bec212e2d5

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 9D16EC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  7 Nov 2022 21:18:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 5D03340329
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  7 Nov 2022 21:18:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 5D03340329
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=fm1 header.b=v6qJvyCD
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 qj_DDw14GqPa
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  7 Nov 2022 21:17:59 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C056C40012
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com
 [64.147.123.21])
 by smtp2.osuosl.org (Postfix) with ESMTPS id C056C40012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  7 Nov 2022 21:17:58 +0000 (UTC)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
 by mailout.west.internal (Postfix) with ESMTP id 0093932009E4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  7 Nov 2022 16:17:54 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute3.internal (MEProxy); Mon, 07 Nov 2022 16:17:55 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=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=1667855874; x=1667942274; bh=zMoxRgGZYAXpXPpewcF5NfzJ7n/Z
 J3ALAJvW7B6gy9U=; b=v6qJvyCDSvLNLuL5l45v/HwIlf7cqzSrCR6xmdzmJyTZ
 VIYaVH+8uiniQs9sdtrqPIJ5oIJauDwmNBSsNrQRbAi+bKmq7sifNiR68ScP5BQ8
 e0f6z14sS9yt2Tkc99Zr19evuyOjgj6/5Ox1SchVD5ZJ4BZ64WExD3PnUXp5aiLw
 oEMLGvw3XCIw/V9ROn6tqWcz+YM2lr6qZOzNfsTysZuP2DgJStDL0Wz0BDJX/HFj
 f3l2IlO5TNd3fnYjAsXmA8wMoV+nC+miLJGwe1wyV2OBuLsJ0+EK2TZMLkQuVpo7
 9dR23gfwTqp+Zh8lSa4JUDg2quESwlkYVGomsu3DxQ==
X-ME-Sender: <xms:AnZpYwboNtrmEuWOpW0gFh5U6xIZ71_MF1fyg6oj-7q4vrO7yLLP8Q>
 <xme:AnZpY7ZKVJ9VnHsNWDlGoYsIcuAGIDROfRQvD8To9RZhUA3J5h3c2X3qm1m1ejkn9
 tgBZxOx7V3QG_eU8zc>
X-ME-Received: <xmr:AnZpY6-rKz3P72-UC_uv7ZhttmTaFof5pZE2kiNVd_aRdOAAdzVuVcL-gmgoXw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrvdekgddugeehucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre
 ertddtvdenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthho
 uggurdhorhhgqeenucggtffrrghtthgvrhhnpeeivddvleeikeejueekgfdtleefgeehhe
 elffeuheetgefhleevjeefleegvefffeenucffohhmrghinhepphgvthgvrhhtohguugdr
 ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe
 hpvghtvgesphgvthgvrhhtohguugdrohhrgh
X-ME-Proxy: <xmx:AnZpY6q_DpRW6MzZv__L0Yqns9DEzYSNgw_eS8XLS9nm9qoX4yuezg>
 <xmx:AnZpY7obdqNAEvuQwyFaJ4Ku-l54CJRBJQPbtzFHH3SiqoHLwOR2rA>
 <xmx:AnZpY4SGkRJcnIMezESdws4Sce3AhrY3auTJrHmLx9hyBsXjCV3Fog>
 <xmx:AnZpYy0mH7LlVBuf4XWevoRt-CxSmnBj9zcte0Af1j-dgzZ4fX4rTQ>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 <bitcoin-dev@lists.linuxfoundation.org>; Mon,
 7 Nov 2022 16:17:53 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
 id C7C1A5F83B; Mon,  7 Nov 2022 16:17:50 -0500 (EST)
Date: Mon, 7 Nov 2022 16:17:50 -0500
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y2l1/qXHxyctU9ir@petertodd.org>
References: <Y2ln2fJ+8+Q0qS0E@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="Bg9GP70IkZk5ny3o"
Content-Disposition: inline
In-Reply-To: <Y2ln2fJ+8+Q0qS0E@petertodd.org>
Subject: [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: Mon, 07 Nov 2022 21:18:00 -0000


--Bg9GP70IkZk5ny3o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 07, 2022 at 03:17:29PM -0500, Peter Todd via bitcoin-dev wrote:
> tl;dr: We can remove the problem of Rule #5 pinning by ensuring that all
> transactions in the mempool are always replaceable.

With Rule #5 solved, let's look at the other pinning attack on multi-party
transactions: BIP-125 Rule #3

tl;dr: In conjunction with full-RBF, nLockTime'd, pre-signed, transactions =
can
ensure that one party is not forced to pay for all the cost of a rule #3
replacement.


# What is the problem?

When a transaction contains inputs from multiple parties, each party can lo=
ck
up funds from the other party by spending their input with a transaction th=
at
is difficult/expensive to replace. Obviously, the clearest example of "diff=
icult to
replace" is a non-BIP-125 (Opt-in-RBF) transaction. But here, we'll assume =
that
full-rbf is implemented and all transactions are replaceable.

BIP-125 Rule #3 states that:

    The replacement transaction pays an absolute fee of at least the sum pa=
id
    by the original transactions.

The attack is that the malicious party, who we'll call Mallory, broadcasts a
transaction spending their input(s) with a low fee rate transaction that's
potentially quite large, during a time of high mempool demand. Due to the l=
ow
fee rate this transaction will take a significant amount of time to mine. T=
he
other parties to the transaction - who we'll collectively call Alice - are =
now
unable to spend their inputs unless they broadcast a transaction "paying fo=
r"
Mallory's.

This attack works because Mallory doesn't expect the conflicting tx to actu=
ally
get mined: he assumes it'll either expire, or Alice will get frustrated and
have to double spend it. By simple tying up money, Mallory has caused Alice=
 to
actually lose money.


# Fixing the problem with nLockTime

Conversely, in the case of an honest multi-party transaction, whose parties
we'll call Alice and Bob, the parties genuinely intend for one of two outco=
mes:

1) The multi-party transaction to get mined within N blocks.
2) The transaction to be cancelled (most likely by spending one of the inpu=
ts).

We can ensure with high probability that the transaction can be cancelled/m=
ined
at some point after N blocks by pre-signing a transaction, with nLockTime s=
et
sufficiently far into the future, spending one or more inputs of the
transaction with a sufficiently high fee that it would replace transaction(=
s)
attempting to exploit Rule #3 pinning (note how the package limits in Bitco=
in
Core help here).

There's a few different ways to implement this, and exactly which one makes
sense will depend on the specifics of the multi-party protocol. But the gen=
eral
approach is to defeat the attack by ensuring that Mallory will have to pay =
the
cost of getting the multi-party transaction unstuck, at some point in the
future.

For example, in a two party transaction where there's a clearly more reputa=
ble
party (Alice), and an untrusted party (Mallory), Alice could simply require
Mallory to provide a nLockTime'd transaction spending only his input to fee=
s,
multiple days into the future. In the unlikely event that Mallory holds up =
the
protocol, he will be severely punished. Meanwhile, Alice can always cancel =
at
no cost.

In a many party transaction where both parties are equally (un)trustworthy =
the
protocol could simply have both parties sign a series of transactions,
nLockTimed at decreasingly far into a future, paying a decreasingly amount =
of
fees. If either party holds up the transaction intentionally, they'll both =
pay
a high cost. But again, at some point Mallory will have paid the full price=
 for
his attack. This approach also has the beneficial side effect of implementi=
ng
fee discovery with rbf. This approach is easier as the number of parties
increases, eg the Wasabi/Joinmarket transactions with hundreds of inputs and
outputs: they collectively already have to pay a significant fee to get the
transaction mined, making the extra poential cost needed to defeat pinning
minimal.


# Coordinator Spent Bonds with Package Relay/Replacement

For schemes with a central semi-trusted coordinator, such as Wasabi coinjoi=
ns,
with package relay/replacement we can use a two party punishment transaction
consisting of:

    tx1 - spends Mallory's input to a txout spendable by:
           IF
               <coordinator> CheckSig
           Else
               <delay> CheckSequenceVerify
               <mallory> CheckSig
           EndIf

    tx2 - spends tx1 output to as much fees as needed

Whether or not Mallory cheated with a double-spend is provable to third
parties; the second transaction ensures that Mallory can't simply release t=
x1
on their own to frame the coordinator. The use of CheckSequenceVerify ensur=
es
that if mallory did try to frame the coordinator, they don't have to do
anything to return the funds to Mallory.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--Bg9GP70IkZk5ny3o
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmNpdfwACgkQLly11TVR
Lzf3dA//aJMcCqvILg75j7AJjHXkmDQDj7l7v5Plm2xirtsTQ4ebMdUmQjjKLT5Z
c0qXujMYDp23fHjp+0hnho3meflNeZZgJTdTSwbeh/vvloSwPyhsrpwuOREvq/RO
DqV3K+vRH1hjHJWTCVw/VqyWXvb3SCYQ3Rqp51V01BSwCYOyVfvhxLmyA2ceuzKA
e3D9xpkUAhFN7OKSihTki6SwhfohVqzAVSolRlDmL3C1HHUOp4WKWrf/GaqAIYr/
fcgQWr8hLHYCJ+JCE9oRi2ktxc0Wh/iPsLxv9ydnaXAeohw4GncYHCc/mnVBjMwu
XCivUbGJWTncGU7SHMnW0lg713OOazNBv3o6jN14ttQ3FKyPe+b3lGRV1q/un5Ee
BPe+uHc+ZgjIuCXwK9x0i8NFojesQTiD11Hfj0s8eti6NAxqjkVvemGm1+ZaLCPh
y2xBsO9rZNrbs65XubAE2DAWfUYRyv0Xe6ZBjfC0OdaGb+XgzU2ElcHDAKEcQ0ZR
LeKMSwGX4wE95NbT44sIXUWqUiZsnnUXROwvZjrAFPI4EwLd2EerBndRAEUVSbrX
3p6A9zWd2UKJISlRZMnrmmbRDVfB2oubwgNl3zMJHSAWiag4CDc9KGSChKWOF3rF
weM9U9IV6XvXJBZr7+6+gi94uczjtKUIls6IZNlih09Z8AejRZs=
=TP/a
-----END PGP SIGNATURE-----

--Bg9GP70IkZk5ny3o--