Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1DFD0C000B for ; Tue, 15 Feb 2022 21:38:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 19C3740129 for ; Tue, 15 Feb 2022 21:38:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=gmail.com 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 E4Ph8HAwVaZm for ; Tue, 15 Feb 2022 21:38:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by smtp2.osuosl.org (Postfix) with ESMTPS id 6C6BA400FE for ; Tue, 15 Feb 2022 21:38:24 +0000 (UTC) Received: by mail-lf1-x132.google.com with SMTP id u20so156369lff.2 for ; Tue, 15 Feb 2022 13:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ACJlPYAo41gajLWA3eodcEWccfuVvHs3mfJXoLdYZO8=; b=VprZ69oQltYexK8hmz2b6eYWjGM26t9gnPPnMvOadbknNstIBgJE2oU9LmeOcJyaQw pGbYHaD7Idx0LkoscV/N2w6m+HgarL7dXC43ThYfOeG90kWnCX69m9I0nDU4BrmVRbNQ I9tf+ipvBq2AxN89WuKLPTRm2jm3ulVrKPVxUshX6DT/QyUlSx8KnFHbtVhoLWJuMwHK mZm3bIgbG71sX4zVMETDIsRo8+ws4PqXCL+64YoQ5R+B8XJWAnG/JcpZ7Ueuw4YvlK14 YQ8v4tNZwROyL1LtEgsar4jr/83OqgMrbSOAoY+yX9Ka2xGkkWOIWgOuY8GAWNKytaQv F+Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ACJlPYAo41gajLWA3eodcEWccfuVvHs3mfJXoLdYZO8=; b=JiEyV5rVmNu5R3lseEsuxJ/FrwSB0fX7kH9Gh67O0htrXVpJnsV9eSbEOmCSLbtv/h 2wshAUU9OgXUlF9++O/jZehUeh1fcgplh7rxXYpv9LMLkjNWUFverM27TIL5Nhk3lt5x +ssqjC7x5NBwmZZuIDfMPfYxdGtfIqUUJcOhn/q8PrB0S7U47eHkOS9sllj1o5FM0lr+ AdjXhCYKIrbQ8qSVfy5wmacIORFeMQy7eew0ciWyFfbFOMcJd5kfc9NbWKL+r6YPGZkU LxX4cT2lxOO28aNodmTOK3zdMM4oJfikidQQEJzkf8rO6JYf6q0B2sjO+H2oH0d0bF78 WgnQ== X-Gm-Message-State: AOAM533grKaU9aSOfrh815sK0mxBx6VaHM2yBvkNu8ND0qoBCHEwArlZ 5+QJa6t1PawhFzjPd4u3FlJqYiFFp2Z4cAXSHOHv9Y5tgaJV3g== X-Google-Smtp-Source: ABdhPJwQFUijQ1Ot9ffN6ndZusuPttxFIPdbxj6hBx41Ytn67SgGJo0kkBxbsSHb+fBl1dMqn4cEnuxeI8hRBtBZXGw= X-Received: by 2002:a05:6512:2288:: with SMTP id f8mr758293lfu.363.1644961102313; Tue, 15 Feb 2022 13:38:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Rubin Date: Tue, 15 Feb 2022 13:38:11 -0800 Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000002c3b5c05d8155af5" Subject: Re: [bitcoin-dev] Thoughts on fee bumping 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: Tue, 15 Feb 2022 21:38:26 -0000 --0000000000002c3b5c05d8155af5 Content-Type: text/plain; charset="UTF-8" The difference between sponsors and this issue is more subtle. The issue Suhas raised was with a variant of sponsors trying to address a second criticism, not sponsors itself, which is secure against this. I think I can make this clear by defining a few different properties: Strong Reorgability: The transaction graph can be arbitrarily reorged into any series of blocks as long as dependency order/timelocks are respected. Simple Existential Reorgability: The transaction graph can be reorged into a different series of blocks, and it is not computationally difficult to find such an ordering. Epsilon-Strong Reorgability: The transaction graph can be arbitrarily reorged into any series of blocks as long as dependency order/timelocks are respected, up to Epsilon blocks. Epsilon: Simple Existential Reorgability: The transaction graph can be reorged into a different series of blocks, and it is not computationally difficult to find such an ordering, up to epsilon blocks. Perfect Reorgability: The transaction graph can be reorged into a different series of blocks, but the transactions themselves are already locked in. Perfect Reorgability doesn't exist in Bitcoin because unconfirmed transactions can be double spent which invalidates descendants. Notably, for a subset of the graph which is CTV Congestion control tree expansions, perfect reorg ability would exist, so it's not just a bullshit concept to think about :) The sponsors proposal is a change from Epsilon-Strong Reorgability to Epsilon-Weak Reorgability. It's not clear to me that there is any functional reason to rely on Strongness when Bitcoin's reorgability is already not Perfect, so a reorg generator with malicious intent can already disturb the tx graph. Epsion-Weak Reorgability seems to be a sufficient property. Do you disagree with that? Best, Jeremy -- @JeremyRubin On Tue, Feb 15, 2022 at 12:25 PM Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > >> >> 2. (from Suhas) "once a valid transaction is created, it should not >> become invalid later on unless the inputs are double-spent." >> > This doesn't seem like a huge concern to me >> >> I agree that this shouldn't be a concern. In fact, I've asked numerous >> people in numerous places what practical downside there is to transactions >> that become invalid, and I've heard basically radio silence other than one >> off hand remark by satoshi at the dawn of time which didn't seem to me to >> have good reasoning. I haven't seen any downside whatsoever of transactions >> that can become invalid for anyone waiting the standard 6 confirmations - >> the reorg risks only exists for people not waiting for standard >> finalization. So I don't think we should consider that aspect of a >> sponsorship transaction that can only be mined with the transaction it >> sponsors to be a problem unless a specific practical problem case can be >> identified. Even if a significant such case was identified, an easy >> solution would be to simply allow sponsorship transactions to be mined on >> or after the sponsored transaction is mined. >> > > The downside is that in a 6 block reorg any transaction that is moved past > its expiration date becomes invalid and all its descendants become invalid > too. > > The current consensus threshold for transactions to become invalid is a > 100 block reorg, and I see no reason to change this threshold. I promise > to personally build a wallet that always creates transactions on the verge > of becoming invalid should anyone ever implement a feature that violates > this tx validity principle. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000002c3b5c05d8155af5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The difference between sponsors and this issue is more subtle. The issu= e Suhas raised was with a variant of sponsors trying to address a second cr= iticism, not sponsors itself, which is secure against this.

I think I can mak= e this clear by defining a few different properties:

Strong Reorgability: The= transaction graph can be arbitrarily reorged into any series of blocks as = long as dependency order/timelocks are respected.
Simple Existential Reorgability: The=C2=A0transaction graph can be= reorged into a different series of blocks, and it is not computationally d= ifficult to find such an ordering.
Epsilo= n-Strong Reorgability: The transaction graph can be arbitrarily reorged int= o any series of blocks as long as dependency order/timelocks are respected,= up to Epsilon blocks.
Epsilon: Simple Existential Reorgability: The=C2=A0transaction g= raph can be reorged into a different series of blocks, and it is not comput= ationally difficult to find such an ordering, up to epsilon blocks.
Perfect Reorgability: The transaction graph can = be reorged into a different series of blocks, but the transactions themselv= es are already locked in.

Perfect Reorgability doesn't exist in Bitcoin b= ecause unconfirmed transactions can be double spent which invalidates desce= ndants. Notably, for a subset of the graph which is CTV Congestion control = tree expansions, perfect reorg ability would exist, so it's not just a = bullshit concept to think about :)

The sponsors proposal is a change from Eps= ilon-Strong Reorgability to Epsilon-Weak Reorgability. It's not clear t= o me that there is any functional reason to rely on Strongness when Bitcoin= 's reorgability is already not Perfect,=C2=A0so a reorg generator with = malicious intent can already disturb the tx graph. Epsion-Weak Reorgability= =C2=A0seems to be a sufficient property.
=
Do you disagree with that?

Best,
=

Jeremy<= /div>


On Tue, Feb 15, 2022 at 12:25 PM Russell O'Connor via= bitcoin-dev <b= itcoin-dev@lists.linuxfoundation.org> wrote:
=C2=A0
>> 2. (from Suhas) "once a valid tra= nsaction is created, it should not become invalid later on unless the input= s are double-spent."
> This doesn't seem like a huge conce= rn to me=C2=A0

I agree that this shouldn't be a conc= ern. In fact, I've asked numerous people in numerous places what practi= cal downside there is to transactions that become invalid, and I've hea= rd basically radio silence other than one off hand remark by satoshi at the= dawn of time which didn't seem to me to have good reasoning. I haven&#= 39;t seen any downside whatsoever of transactions that can become invalid f= or anyone waiting the standard 6 confirmations - the reorg risks only exist= s for people not waiting for standard finalization. So I don't think we= should consider that aspect of a sponsorship transaction that can only be = mined with the transaction it sponsors to be a problem unless a specific=C2= =A0practical problem case can be identified. Even if a significant such=C2= =A0case was identified, an easy solution would be to simply allow sponsorsh= ip transactions to be mined on or after the sponsored transaction is mined.=

The downside is that in a= 6 block reorg any transaction that is moved past its expiration date becom= es invalid and all its descendants become invalid too.

The current consensus threshold for transactions to become invalid= is a 100 block reorg, and I see no reason to change this threshold.=C2=A0 = I promise to personally build a wallet that always creates transactions on = the verge of becoming invalid should anyone ever implement a feature that v= iolates this tx validity principle.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000002c3b5c05d8155af5--