From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5C0AFC000B for ; 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 ; 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 ; 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 ; 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 From: darosior Reply-To: darosior Message-ID: In-Reply-To: References: 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 , lightning-dev , Jeremy 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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