path: root/7e/33037d781370b53dc4b9fda646839557fc8c71

Return-Path: <user@petertodd.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 92DC4C000B;
 Sat, 19 Feb 2022 09:39:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 71A49400F6;
 Sat, 19 Feb 2022 09:39:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level: 
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=petertodd.org header.b="dtYlIE/V";
 dkim=pass (2048-bit key) header.d=messagingengine.com
 header.b="BtX18V5v"
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 E_eu-ZL4c3qP; Sat, 19 Feb 2022 09:39:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com
 [66.111.4.27])
 by smtp2.osuosl.org (Postfix) with ESMTPS id EEFC0400EA;
 Sat, 19 Feb 2022 09:39:30 +0000 (UTC)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
 by mailout.nyi.internal (Postfix) with ESMTP id A896D5C0278;
 Sat, 19 Feb 2022 04:39:26 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute3.internal (MEProxy); Sat, 19 Feb 2022 04:39:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petertodd.org;
 h=cc:cc:content-type:date:date:from:from:in-reply-to
 :in-reply-to:message-id:mime-version:references:reply-to:sender
 :subject:subject:to:to; s=fm1; bh=867AesOLNNVd4bro5LpzVW5LLFYPk8
 bZz8GztjLXaaQ=; b=dtYlIE/Ve8CXDY7Sr2VZPeYt+5uUlh9SVhmf8Fyn1j4fqG
 jBnk5ZysHqGuUWi3uv0WiWOVQ9kk/G1RXex8G8ePV3uHVIAc6N5/t95wIjxtCyEP
 WiRP+xXJYKTn9DXkfuapJZNkhckS7KGe6d7MQ53HOOxQPvPtjnRxWxnE6kTaOsog
 iqAuldiuM+saMEzrsiuWNol1aT9dDdLa1SnZYmXqZDdolFuXcjrtdjvNMHDXFnVU
 /TAE00ZDtOljsMeJeS0wvMWRTsf3RTsMvQbnoHFUch8PdiVmRdF2N9NqWvhcTIqX
 7vtjSAQGhfZT18hjGUQYGvroPKF24MrqwC+yvK8w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-type:date:date: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=fm2; bh=867AesOLNNVd4bro5
 LpzVW5LLFYPk8bZz8GztjLXaaQ=; b=BtX18V5vPWMbZf1pterLmDmGTsxwsKzFE
 gPAKghHstdNTytSlizfDbQFSGG8sbBSQU+agcjPBvvoBXkshFcOjunTaTJ8OWaQ6
 CJ9T4PMU31o6/9Gx81c59Vbbr8GNp4/lYQ7wdqlL/mCyIgK1WoFgxGBo4JYq1kMZ
 SSsXP6ynspQm9phjCz1tDQe88+UtKqTJFOuYEsd6M8QGA0ZioejyLmmIhH9IExUp
 FqDjKOTGLwSBL7ir3R50SlCuuJLLryLPA25R8CEJ01gSB/6RBAyqkktt65w1CsM6
 QenuWdapMoYvazP9jKTv3ZH6N/jN7PLNDYC4yLMQG4jzODmUT+x9A==
X-ME-Sender: <xms:zroQYtdX6DwRhhLEKLPzmjzu3GnxldvoUxs3c_SIwwnNkD_NywX9eA>
 <xme:zroQYrOsAmKcyyS4MJ44SPJFC6pbdtpwCHfAljtLPahkRoT2LyyUD_PCyaCVNQyf7
 dpQrlR-8BDTrLWX2Ow>
X-ME-Received: <xmr:zroQYmiysIhxikqKsFiPB3CryijuxlyVIA2Yz5wJN0gSH_Bdb0Z8V6IAUx5_>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrkedvgddtiecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgvrhcu
 vfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtthgvrh
 hnpeeivddvleeikeejueekgfdtleefgeehheelffeuheetgefhleevjeefleegvefffeen
 ucffohhmrghinhepphgvthgvrhhtohguugdrohhrghenucevlhhushhtvghrufhiiigvpe
 dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehushgvrhesphgvthgvrhhtohguugdrohhr
 gh
X-ME-Proxy: <xmx:zroQYm_SSOBrGuFz6SqXWjmiaFaGhsVWnQudDQnebFStUGhPkOyXRw>
 <xmx:zroQYpsXqWgw3SESTvDeZbwYC6oof_-XhT5UkYVt2CSMHHg8K3CsTw>
 <xmx:zroQYlHr_iiW3UPp6H_k8jlnRGOIVZ-sPMqTl8LytBR4_yUWK4Zdow>
 <xmx:zroQYi5dp-5xAJpcKjjKhZDt0PgAVyGJhTi6fFYhhkPXf9GSvPQpfA>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat,
 19 Feb 2022 04:39:26 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
 id 0A78C5FBAA; Sat, 19 Feb 2022 04:39:22 -0500 (EST)
Date: Sat, 19 Feb 2022 04:39:22 -0500
From: Peter Todd <pete@petertodd.org>
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Message-ID: <YhC6yjoe3bAfBS+W@petertodd.org>
References: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
 <YgS3sJvg6kG3WnVJ@petertodd.org>
 <CAD5xwhi3Ja8gdU2h_6-1ck4kdU0TiC2Kx5O-61=f9=6JQSMs=A@mail.gmail.com>
 <YhAwr7+9mGJAe2/p@petertodd.org>
 <CAD5xwhi=sKckFZew75tZTogoeFABraWtJ6qMC+RgZjcirxYyZw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="umXuJ6oCaN7OvgAF"
Content-Disposition: inline
In-Reply-To: <CAD5xwhi=sKckFZew75tZTogoeFABraWtJ6qMC+RgZjcirxYyZw@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>,
 Jeremy <jlrubin@mit.edu>
Subject: Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
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: Sat, 19 Feb 2022 09:39:32 -0000


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

On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
> > As I said, it's a new kind of pinning attack, distinct from other types
> of pinning attack.
>=20
> I think pinning is "formally defined" as sequences of transactions which
> prevent or make it less likely for you to make any progress (in terms of
> units of computation proceeding).

Mentioning "computation" when talking about transactions is misleading:
blockchain transactions have nothing to do with computation.

> Something that only increases possibility to make progress cannot be
> pinning.

It is incorrect to say that all use-cases have the property that any versio=
n of
a transaction being mined is progress.

> If you want to call it something else, with a negative connotation, maybe
> call it "necromancing" (bringing back txns that would otherwise be
> feerate/fee irrational).

Necromancing might be a reasonable name for attacks that work by getting an
out-of-date version of a tx mined.

> In particular, for the use case you mentioned "Eg a third party could mess
> up OpenTimestamps calendars at relatively low cost by delaying the mining
> of timestamp txs.", this is incorrect. A third party can only accelerate
> the mining on the timestamp transactions, but they *can* accelerate the
> mining of any such timestamp transaction. If you have a single output cha=
in
> that you're RBF'ing per block, then at most they can cause you to shift t=
he
> calendar commits forward one block. But again, they cannot pin you. If you
> want to shift it back one block earlier, just offer a higher fee for the
> later RBF'd calendar. Thus the interference is limited by how much you wi=
sh
> to pay to guarantee your commitment is in this block as opposed to the ne=
xt.

Your understanding of how OpenTimestamps calendars work appears to be
incorrect. There is no chain of unconfirmed transactions. Rather, OTS calen=
dars
use RBF to _update_ the timestamp tx with a new merkle tip hash for to all
outstanding per-second commitments once per new block. In high fee situatio=
ns
it's normal for there to be dozens of versions of that same tx, each with a
slightly higher feerate.

OTS calendars can handle any of those versions getting mined. But older
versions getting mined wastes money, as the remaining commitments still nee=
d to
get mined in a subsequent transaction. Those remaining commitments are also
delayed by the time it takes for the next tx to get mined.

There are many use-cases beyond OTS with this issue. For example, some enti=
ties
use "in-place" replacement for update low-time-preference settlement
transactions by adding new txouts and updating existing ones. Older version=
s of
those settlement transactions getting mined rather than the newer version
wastes money and delays settlement for the exact same reason it does in OTS.

If fee accounts or any similar mechanism get implemented, they absolutely
should be opt-in. Obviously, using a currently non-standard nVersion bit is=
 a
possible approach. Conversely, with CPFP it may be desirable in the settlem=
ent
case to be able to *prevent* outputs from being spent in the same block. Ag=
ain,
an nVersion bit is a possible approach.

> By the way, you can already do out-of-band transaction fees to a very
> similar effect, google "BTC transaction accelerator". If the attack were =
at
> all valuable to perform, it could happen today.

I just checked: all the BTC transaction accellerator services I could find =
look
to be either scams, or very expensive. We need compelling reasons to make t=
his
nuisance attack significantly cheaper.

> Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
> third party for OTS, you should be relatively happy because it cost you
> less fees overall, since the undoing of your later RBF surely returned so=
me
> satoshis to your wallet.

As I said above, no it doesn't.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmIQusQACgkQLly11TVR
LzdHwA//YzXF2H90ybUwaNQzhcXlmt5Br+hvKYnddFD/7+PJi5VSLawDGU+X/JVJ
le+nAgv1FCAnxGN5YU5U82zrXaO2z4Pp1XO8VaVF9T+hEGYcXRooWM5GbCcC0pST
wFK1Wy9rj3yeIKXIhr1KuFnDdEpvYOjri63AXAeo1d3OAjD77Km1C+C/pdLqdrnc
ojjrfG+HgZtCfYbZD//S1M4m8X5L45EIsz4+r5ZTVHy/P5/YR9M3Z9jQBtWsjT1u
osaaD1OOjf3pdKze8OwlZSyEO3k5C0cjHkf2VXJSJXtwmU4brQZqY1rqJtgmLkAP
553mbWtfZdXh3Sw+L8Ab7hQQ4NMAl+E1Ex6VAhYoFJgnpR5w13Uo+VnRfAfDfits
BgFfP0ECXN6tt4zN4QaAroW0JddhGA25N0EX8jFxoMiZQkBb4SrGgF+SnkMQo+cu
ZYnIBtsUhqeMrJXcgT/7GCbHCt6RJ6dJqp+28qUXp5ruOkE7lE9Vp58pmLJVaIRS
LH8ySmq1BYSpNWwCrxofBwUBUKSqi8UKtG1mTKZ4wav2M5zvDTBVAknlAuldQukO
0H4fAF7UagPCQAgRiBs53Eq6XZogY2TLM7lTyF4Nt/ulMI7spu7SR2ibI4IwXxeD
+oUbxi+LCwxfU5VTw1o8dn2QaoTFPH/B8dQh2KC41pvJao/2bJo=
=Rhmr
-----END PGP SIGNATURE-----

--umXuJ6oCaN7OvgAF--