path: root/12/e0d5cb1d39e9858849f5d76a0f843021be5679

Return-Path: <darosior@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5C0AFC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Feb 2022 17:20:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 4B0DB40905
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Feb 2022 17:20:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 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, FREEMAIL_FROM=0.001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id CM8PTG3302_O
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Feb 2022 17:20:25 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
 [185.70.40.132])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 884DE408F3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Feb 2022 17:20:25 +0000 (UTC)
Date: Sat, 19 Feb 2022 17:20:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1645291222;
 bh=aQ9WnEkfrwqOjhPFrNY4KG6MAri+9s6Efyq6M0nVn3w=;
 h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
 References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID;
 b=C7QN5a+/jFOqgOWXTOV+khwCLB9A3jeOlsWZBfA0UNzvFW7Q3KlVYP1mA8ryO7K7x
 psY9/ZDLwaaL4y/HJBTZqwYYRDNiKyAO3KcumDFB0AN4/fnX4FPtbMHWPz2accDHIi
 eJPZLIpUpF82seYo55KJUq8dmOs3QLIFvzaExrp8a+UQtBfuBuSCQ76ExDNs+w0FPa
 PQ4e72nF5aV6ZXkWSEUxfYOQsdb/uggkQGKXzTZQfWp1T948sJ5QRlx+WljsoloFNj
 EX4oBbZQZDm92gDB3WDhvV/8Ho+abfbLhJWe/nrTd5TjMdoJ9e6s3iZkIzprvelKEY
 RRqqPncN75SHA==
To: Peter Todd <pete@petertodd.org>
From: darosior <darosior@protonmail.com>
Reply-To: darosior <darosior@protonmail.com>
Message-ID: <kJWi5A4sc0UEU4JrtSg3gbR_M1UTp15XW3Oj5B5cQZQvygFn9pIqrxVxCU0sFjG5L05fqDFH6nz2PnU0sE_zVNMGsCXzmtJeDAc1kEYmYKA=@protonmail.com>
In-Reply-To: <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>
 <YhC6yjoe3bAfBS+W@petertodd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 19 Feb 2022 18:10:47 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>,
 Jeremy <jlrubin@mit.edu>
Subject: Re: [bitcoin-dev] [Lightning-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 17:20:27 -0000

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

It's not an "attack"? There is no such thing as an out-of-date transaction,=
 if
you signed and broadcasted it in the first place. You can't rely on the fac=
t that
a replacement transaction would somehow invalidate a previous version of it=
.

------- Original Message -------

Le samedi 19 f=C3=A9vrier 2022 =C3=A0 10:39 AM, Peter Todd <pete@petertodd.=
org> a =C3=A9crit :

> 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 typ=
es
> > >
> > > of pinning attack.
> >
> > I think pinning is "formally defined" as sequences of transactions whic=
h
> >
> > prevent or make it less likely for you to make any progress (in terms o=
f
> >
> > 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 vers=
ion of
>
> a transaction being mined is progress.
>
> > If you want to call it something else, with a negative connotation, may=
be
> >
> > 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 m=
ess
> >
> > up OpenTimestamps calendars at relatively low cost by delaying the mini=
ng
> >
> > of timestamp txs.", this is incorrect. A third party can only accelerat=
e
> >
> > the mining on the timestamp transactions, but they can accelerate the
> >
> > mining of any such timestamp transaction. If you have a single output c=
hain
> >
> > that you're RBF'ing per block, then at most they can cause you to shift=
 the
> >
> > 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 th=
e
> >
> > later RBF'd calendar. Thus the interference is limited by how much you =
wish
> >
> > to pay to guarantee your commitment is in this block as opposed to the =
next.
>
> Your understanding of how OpenTimestamps calendars work appears to be
>
> incorrect. There is no chain of unconfirmed transactions. Rather, OTS cal=
endars
>
> 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 situat=
ions
>
> 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 n=
eed to
>
> get mined in a subsequent transaction. Those remaining commitments are al=
so
>
> 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 en=
tities
>
> use "in-place" replacement for update low-time-preference settlement
>
> transactions by adding new txouts and updating existing ones. Older versi=
ons of
>
> those settlement transactions getting mined rather than the newer version
>
> wastes money and delays settlement for the exact same reason it does in O=
TS.
>
> 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 settl=
ement
>
> 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 wer=
e at
> >
> > all valuable to perform, it could happen today.
>
> I just checked: all the BTC transaction accellerator services I could fin=
d look
>
> to be either scams, or very expensive. We need compelling reasons to make=
 this
>
> 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 =
some
> >
> > satoshis to your wallet.
>
> As I said above, no it doesn't.
>
> ----------------------------------
>
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> Lightning-dev mailing list
>
> Lightning-dev@lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev