Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id EB857C000B for ; Tue, 15 Feb 2022 21:37:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id B8227400FE for ; Tue, 15 Feb 2022 21:37:58 +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 8LdoQpfI6-F0 for ; Tue, 15 Feb 2022 21:37:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by smtp2.osuosl.org (Postfix) with ESMTPS id B408040018 for ; Tue, 15 Feb 2022 21:37:56 +0000 (UTC) Received: by mail-lf1-x136.google.com with SMTP id g39so87323lfv.10 for ; Tue, 15 Feb 2022 13:37:56 -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=EXPxqswaN2kseN6f7bScezXiGCmaNMkchsk351JkOgo=; b=TYwRtb3PWVtpwCoE2l7042ZHRvnuugFejJRND6uymnvvvht9jJG0ADln76zWhzx7g6 kw4hrwGyhOg8AAlmS7s75kmwxvYs0zhscJLYeZW8guJaiyC82fgAAciJXrB0pgybgKCq SanNuLHru4ViM9rZmtcAsB2wHuokXjeez+YZbmJCN0WjrTIf0Ld5/9KRC0GjMiSuqPa3 s0jbHEHk+ajp9ZtwM+Z5R1Bv2Uhn+JmJsGvSnebHjo3wUcUA/jLfhuk3H7fErEgIsdh8 HXpaFJ/VZt2YmT6U6eUWIpUvYtSBvBOWTiQyRtkIXKEIKgJf/E8si8JiWz3kEJIkPECm Z/oQ== 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=EXPxqswaN2kseN6f7bScezXiGCmaNMkchsk351JkOgo=; b=L+9X0EL35mo/7crbjBDvKLKf0CmqtI005811DvjCHEKimZUb7TO3pFTxDiDgRoNa/Z GUadE6BKMbGGsgxH2wDou5oz216ygFniXGqmUPQ9l/6gFtK1KZtO2d3HXB8ZuAq9PubK Zmdg9B95b/AXXPjpn43WtqDCSk7exVovXD99n9MegfZSPW8iRHf5IILCJBFgphXyIfKE 9TePwYezhTfDNPj7yi/8iR2X79Kd3Usmysu5J2dQ4dmVcAsvEHV2RO2Rft7a84brTAXp YYUrn044KByB85BpEuisgcgRzVGkKTEoB7w1Cgn5FSfAMqxrHeXYlHG/U2aDnoX42Q1c PIpQ== X-Gm-Message-State: AOAM530WXFbieCCFqAvOrf15uUuQMyasUzu5IoI0WgrJArtybj+hsPfg m2onsIYyZsMkGPwplMf9DzuswKM+iUfn6sKF8/4= X-Google-Smtp-Source: ABdhPJxEPecGiUW2/BaufpXfJ/o7mNt8MjAULNH7YXhIQBWVMC6tddI0EvgKTJud8bc6gyOHJDRbfSwPCT7FrnNicj0= X-Received: by 2002:a19:f00f:: with SMTP id p15mr746477lfc.670.1644961074470; Tue, 15 Feb 2022 13:37:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Rubin Date: Tue, 15 Feb 2022 13:37:43 -0800 Message-ID: To: "James O'Beirne" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000008363a005d81558eb" 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:37:59 -0000 --0000000000008363a005d81558eb Content-Type: text/plain; charset="UTF-8" James, Unfortunately, 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. Instead, you could introduce a time-bound for inclusion, e.g. 100 blocks. However, this time-bounded version has the issue that Roconnor raised which is that validity "stops" after a certain time, hurting reorganization. However, If you wanted to map this conceptually onto existing tx indexes, you could have an output with exactly the script `<100 blocks> OP_CSV` and then allow sponsor references to be pruned after that output is "garbage collected" by pruning it out of a block. This would be a way that sponsorship would be opt-in (must have the flag output) and then sponsors observations of txid existence would be only guaranteed to work for 100 blocks after which it could be garbage collected by a miner. It's not a huge leap to say that this behavior should be made entirely "virtual", as you are essentially arguing that there exists a transaction graph we could construct that would be equivalent to the graph were we to actually have such an output / spends relationship. Since the property we care about is about all graphs, that a specific one could exist that has the same dependency / invalidity relationships during a reorg is important for the theory of bitcoin transaction execution. So it really isn't clear to me that we're hurting the transaction graph properties that severely with changes in this family. It's also not clear to me that having a TXINDEX is a huge issue given that making a dust-out per tx would have the same impact (and people might do it if it's functionally useful, so just making it default behavior would at least help us optimize it to be done through e.g. a separate witness space/utreexo-y thing). Another consideration is to make the outputs from sponsor txn subject to a 100 block cool-off period. E.g., so even if you have your inverse timelock, adding a constraint that all outputs then have something similar to fCoinbase set on them (for spending timelocks only) would mean that little reorgs could not disturb the tx graph, although this poses a UX challenge for wallets that aim to bump often (e.g., 1 bump per block would mean you need to maintain 100 outputs). Lastly, it's pretty clear from a UX perspective that I should not want to pay miners who did *not* mine my transactions! Therefore, it would be natural to see if you pay a high enough fee that users might want to cancel their (now very desirable) stale fee bumps by replacing it with something more useful to them. So allowing sponsors to be in subsequent blocks might make it rational for users to do more transactions, which increases the costs of such an approach. All things considered, I favor the simple version of just having sponsors only valid for the block their target is co-resident in. Jeremy -- @JeremyRubin On Tue, Feb 15, 2022 at 12:53 PM James O'Beirne via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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. > > Worth noting that the transaction sponsors design is no worse an > offender on this count than, say, CPFP is, provided we adopt the change > that sponsored txids are required to be included in the current block > *or* prior blocks. (The original proposal allowed current block only). > > In other words, the sponsored txids are just "virtual inputs" to the > sponsor transaction. > > This is a much different case than e.g. transaction expiry based on > wall-clock time or block height, which I agree complicates reorgs > significantly. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000008363a005d81558eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
James,

Unf= ortunately, there are technical reasons for sponsors to not be monotone. Mo= stly that it requires the maintenance=C2=A0of an additional permanent TX-In= dex, making Bitcoin's state grow at a much worse=C2=A0rate. Instead, yo= u could introduce a time-bound for inclusion, e.g. 100 blocks. However, thi= s time-bounded version has the issue that Roconnor raised which is that val= idity "stops" after a certain time, hurting reorganization.
=

However, If you wanted to map this conceptually onto existing tx ind= exes, you could have an output with exactly the script `<100 blocks> = OP_CSV` and then allow sponsor references to be pruned after that output is= "garbage collected" by pruning it out of a block. This would be = a way that sponsorship would be opt-in (must have the flag output) and then= sponsors observations of txid existence would be only guaranteed to work f= or 100 blocks after which it could be garbage collected by a miner.

It's not a huge leap to say that this behavior should be made enti= rely "virtual", as you are essentially arguing that there exists = a transaction graph we could construct that would be equivalent to the grap= h were we to actually have such an output / spends relationship. Since the = property we care about is about all graphs, that a specific one could exist= that has the same dependency / invalidity relationships during a reorg is = important for the theory of bitcoin transaction execution.

So = it really isn't clear to me that we're hurting the transaction grap= h properties that severely with changes in this family. It's also not c= lear to me that having a TXINDEX is a huge issue given that making a dust-o= ut per tx would have the same impact (and people might do it if it's fu= nctionally useful, so just making it default behavior would at least help u= s optimize it to be done through e.g. a separate witness space/utreexo-y th= ing).=C2=A0

Another consideration is to make the outputs from= =C2=A0sponsor txn subject to a 100 block cool-off period. E.g., so even if = you have your inverse timelock, adding a constraint that all outputs then h= ave something similar to fCoinbase=C2=A0set on them (for spending timelocks= =C2=A0only) would mean that little reorgs could not disturb the tx graph, a= lthough this poses a UX challenge for wallets that aim to bump often (e.g.,= 1 bump per block would mean you need to maintain 100 outputs).

Lastly, it's pretty clear from a UX perspective that I should not wan= t to pay miners who did *not* mine my transactions! Therefore, it would be = natural to see if you pay a high enough fee that users might want to cancel= their (now very desirable) stale fee bumps by replacing it with something = more useful to them. So allowing sponsors to be in subsequent blocks might = make it rational for users to do more transactions, which increases the cos= ts of such an approach.

=

All things considered, I favor the simple version of just having spo= nsors only valid for the block their target is co-resident in.


Jeremy






On Tue, Feb 15, 2022 at 12:53 PM James O'Beirne via b= itcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> The downside is that in a 6 block = reorg any transaction that is moved
> past its expiration date become= s invalid and all its descendants
> become invalid too.

Worth = noting that the transaction sponsors design is no worse an
offender on t= his count than, say, CPFP is, provided we adopt the change
that sponsore= d txids are required to be included in the current block
*or* prior bloc= ks. (The original proposal allowed current block only).

In other wor= ds, the sponsored txids are just "virtual inputs" to the
spons= or transaction.

This is a much different case than e.g. transaction = expiry based on
wall-clock time or block height, which I agree complicat= es reorgs
significantly.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000008363a005d81558eb--