diff options
| author | darosior <darosior@protonmail.com> | 2022-02-19 17:20:19 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-02-19 17:20:27 +0000 |
| commit | 579c15e4cd4ac65a4cb67d4163db8862e3ed8c34 (patch) | |
| tree | 9755dbe5b35304c25363edf644ee33665a31b534 | |
| parent | 2f93c3bf381fb2d21757ee1ad6f038dda0d75ba7 (diff) | |
| download | pi-bitcoindev-579c15e4cd4ac65a4cb67d4163db8862e3ed8c34.tar.gz pi-bitcoindev-579c15e4cd4ac65a4cb67d4163db8862e3ed8c34.zip | |
Re: [bitcoin-dev] [Lightning-dev] [Pre-BIP] Fee Accounts
| -rw-r--r-- | 12/e0d5cb1d39e9858849f5d76a0f843021be5679 | 249 |
1 files changed, 249 insertions, 0 deletions
diff --git a/12/e0d5cb1d39e9858849f5d76a0f843021be5679 b/12/e0d5cb1d39e9858849f5d76a0f843021be5679 new file mode 100644 index 000000000..f3716c5bf --- /dev/null +++ b/12/e0d5cb1d39e9858849f5d76a0f843021be5679 @@ -0,0 +1,249 @@ +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 + |