Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4B87FC000B for ; Wed, 16 Feb 2022 02:54:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 2A36A82862 for ; Wed, 16 Feb 2022 02:54:48 +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: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNCe57BZ9gb7 for ; Wed, 16 Feb 2022 02:54:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by smtp1.osuosl.org (Postfix) with ESMTPS id 83256827CA for ; Wed, 16 Feb 2022 02:54:46 +0000 (UTC) Received: by mail-ej1-x631.google.com with SMTP id h8so1405182ejy.4 for ; Tue, 15 Feb 2022 18:54:46 -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 :cc; bh=ccBIAYaF5YF6SQyQAJ5wA8e5Jp6MMdcWuHN+9Dt7cdw=; b=afz9lnXXNOMjkbR3oG7HoTSTtsupoAyJZrSqQzcmhClGFAsXkBLrENbgrwk3u+Xj+m jTr83iHFJ4yKFvyGbbBC59mcVadqIucxSFEIe7PYDcpdJZzj9UH+5ePb3d/YV9m7YZr9 xuVPD7znLJU7tTwgTpZAtDrh4LydGbJbgneRJK1bfOyFe9RRUuWF2VyGvNt3JzZSHAdT RVvTDJt55FQHvYDBlb/9jE/Xt8XOOtnU5zeox9U4WAlozucDQTJs8djdL3Qf8r7RwVva EX5/Va6EmsJDhe1iTI5sGtFbG6G5U/gM3LI5/1fC5PiX+qt5kSPL1LW9FgbqpwvyvA/y UeKg== 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:cc; bh=ccBIAYaF5YF6SQyQAJ5wA8e5Jp6MMdcWuHN+9Dt7cdw=; b=X8PkgRYxu7ZSyoT4W+WigOrKW1nR6rTkFKcgVMA6hchjGS1in+AZfWSaU5eqKTY3Z7 E3lG5IG6LLmnEuJF+S4JeX2XlYGBkdevN0SPk4tS1DNpBlCBoTBs2BrtngzfJYZXdQ2T Y5A1s/qTZOlOTndTKIKh7c1zb3eHDx5ApLgVCC0/OQemyU/DAo2BptZ+AdMDPKbB/Xi/ EJTepnjHSX46t77QE0gPyL3vWHNJfwF46eckTcUd8NcZOuADWFzbCVXY9ajJewuXZZe9 rRt6tAAg5u4w1afA0NNCfamgOK6crUEIHCTGsWXIF1ZWD+HDgCm5PRx5aKaLGK5wujIy iVYg== X-Gm-Message-State: AOAM5310kLTwnO3VSqA04exYyFB2kSpBWbsHLJQ8GXcB7cBz0rYK4xpG 3D9Xt9Wab6IV+ExsFh1FtSkSsrEB+A5oZOkfmFNaEmPu X-Google-Smtp-Source: ABdhPJwthjU1v7Rpdh16iZL++cXe0fXgGinIWD2mS8gRLBXckDWwjJBdC8eDif82KEch7VMTBVZg0xAOk3kTp8ayehQ= X-Received: by 2002:a17:906:93f7:b0:6cc:6319:6c43 with SMTP id yl23-20020a17090693f700b006cc63196c43mr718168ejb.176.1644980084199; Tue, 15 Feb 2022 18:54:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Billy Tetrud Date: Tue, 15 Feb 2022 20:54:28 -0600 Message-ID: To: Jeremy Rubin , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000094d69905d819c52a" X-Mailman-Approved-At: Wed, 16 Feb 2022 13:35:05 +0000 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: Wed, 16 Feb 2022 02:54:48 -0000 --00000000000094d69905d819c52a Content-Type: text/plain; charset="UTF-8" @Jeremy > there are technical reasons for sponsors to not be monotone. Mostly that it requires the maintenance of an additional permanent TX-Index, making Bitcoin's state grow at a much worse rate What do you mean by monotone in the context of sponsor transactions? And when you say tx-index, do you mean an index for looking up a transaction by its ID? Is that not already something nodes do? > The sponsors proposal is a change from Epsilon-Strong Reorgability to Epsilon-Weak Reorgability It doesn't look like you defined that term in your list. Did you mean what you listed as "Epsilon: Simple Existential Reorgability"? If so, I would say that should be sufficient. I'm not sure I would even distinguish between the "strong" and "simple" versions of these things, tho you could talk about things that make reorgs more or less computationally difficult on a spectrum. As long as the computational difficulty isn't significant for miners vs their other computational costs, the computation isn't really a problem. @Russell > The current consensus threshold for transactions to become invalid is a 100 block reorg What do you mean by this? The only 100 block period I'm aware of is the coinbase cooldown period. > 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. Could you explain how you would build a wallet like that with a sponsor transaction as described by Jeremy? What damage do you think such a wallet could do? As far as I can tell, such a wallet is very unlikely to do more damage to the network than it does to the user of that wallet. On Tue, Feb 15, 2022 at 3:39 PM Jeremy Rubin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000094d69905d819c52a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Jeremy

=C2=A0>=C2=A0there are technica= l reasons for sponsors to not be monotone. Mostly that it requires the main= tenance=C2=A0of an additional permanent TX-Index, making Bitcoin's stat= e grow at a much worse=C2=A0rate

What do y= ou mean by monotone in the context of sponsor transactions? And when yo= u say tx-index, do you mean an index for looking up a transaction by its ID= ? Is that not already something nodes do?=C2=A0

&= gt;=C2=A0The sponsors proposal is a change from Epsilon-Strong Reorgability to= Epsilon-Weak Reorgability

It doesn't= look like you defined that term in your list.=C2=A0Did you mean wha= t you listed as "Epsilon: Simple Existential Reorgability"? If so, I= would say that should be sufficient. I'm not sure I would even disting= uish between the "strong" and "simple" versions of thes= e things, tho you could talk about things that make reorgs more or less com= putationally difficult on a spectrum. As long as the computational difficul= ty isn't significant for miners vs their other computational costs, the= computation isn't really a problem.

@= Russell
> The current consensus threshold for transacti= ons to become invalid is a 100 block reorg

What do= you mean by this? The only 100 block period I'm aware of is the coinba= se cooldown period.=C2=A0

>=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 violates this = tx validity principle.

Could you explain how you w= ould build a wallet like that with a sponsor transaction as described by Je= remy? What damage do you think such a wallet could do? As far as I can tell= , such a wallet is very unlikely to do more damage to the network than it d= oes to the user of that wallet.=C2=A0

On Tue, Feb 15, 2022 at 3:= 39 PM Jeremy Rubin via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.or= g> wrote:
The difference between sponsors and this issue is more subtle. The = issue Suhas raised was with a variant of sponsors trying to address a secon= d 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=C2=A0transaction graph ca= n be reorged into a different series of blocks, and it is not computational= ly difficult to find such an ordering.
Ep= silon-Strong Reorgability: The transaction graph can be arbitrarily reorged= into any series of blocks as long as dependency order/timelocks are respec= ted, up to Epsilon blocks.
Epsilon: Simple Existential Reorgability: The=C2=A0transacti= on graph can be reorged into a different series of blocks, and it is not co= mputationally 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 them= selves are already locked in.

<= div class=3D"gmail_default">Perfect Reorgability doesn't exist in Bitco= in because unconfirmed transactions can be double spent which invalidates d= escendants. Notably, for a subset of the graph which is CTV Congestion cont= rol tree expansions, perfect reorg ability would exist, so it's not jus= t a bullshit concept to think about :)
The sponsors proposal is a change from= Epsilon-Strong Reorgability to Epsilon-Weak Reorgability. It's not cle= ar to me that there is any functional reason to rely on Strongness when Bit= coin's reorgability is already not Perfect,=C2=A0so a reorg generator w= ith malicious intent can already disturb the tx graph. Epsion-Weak Reorgabi= lity=C2=A0seems to be a sufficient property.

Do you disagree with that?
=

Best,

Jer= emy


On Tue, Feb 15, 2022 at 12:25 PM Russell = O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org&= gt; wrote:
=C2=A0
>> 2. (from Su= has) "once a valid transaction is created, it should not become invali= d later on unless the inputs are double-spent."
> This doesn&#= 39;t seem like a huge concern to me=C2=A0

I agree that t= his shouldn't be a concern. In fact, I've asked numerous people in = numerous places what practical downside there is to transactions that becom= e invalid, and I've heard basically radio silence other than one off ha= nd remark by satoshi at the dawn of time which didn't seem to me to hav= e good reasoning. I haven't seen any downside whatsoever of transaction= s that can become invalid for anyone waiting the standard 6 confirmations -= the reorg risks only exists for people not waiting for standard finalizati= on. So I don't think we should consider that aspect of a sponsorship tr= ansaction that can only be mined with the transaction it sponsors to be a p= roblem unless a specific=C2=A0practical problem case can be identified. Eve= n if a significant such=C2=A0case was identified, an easy solution would be= to simply allow sponsorship transactions to be mined on or after the spons= ored 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 tran= sactions to become invalid is a 100 block reorg, and I see no reason to cha= nge this threshold.=C2=A0 I promise to personally build a wallet that alway= s 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/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000094d69905d819c52a--