path: root/1c/3ff9922d7a484649552fe41fddd1023e2a2853

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EB857C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 21:37:56 +0000 (UTC)
Received: by mail-lf1-x136.google.com with SMTP id g39so87323lfv.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
 <CALZpt+FwZTXEYYiJ=1XTXbDVECW41e9rNq8rn8AYr6m3yLAkPA@mail.gmail.com>
 <CAPfvXfJN9zeJDYka8BycU102xGdwQ2O9=Khgjag-eYLmXRdsdA@mail.gmail.com>
 <CALZpt+G0uXL04onty2N++6tWeX7Y=5KWw3x8-A0MvyUgZR-4Xw@mail.gmail.com>
 <CAGpPWDaZ=Qx_phzjFJXzQc0ePWfuJmGKsPrsvj9X1pBTBrRgWA@mail.gmail.com>
 <CAMZUoKnhyzJ=6W-=hxpmCyjiPyYMuS=eKjLN+bu5cuLRQ42nxA@mail.gmail.com>
 <CAPfvXfJnDajpxjpnhXNZiBTLqBmNEmj5CdFNx8UxEE4R1ydepA@mail.gmail.com>
In-Reply-To: <CAPfvXfJnDajpxjpnhXNZiBTLqBmNEmj5CdFNx8UxEE4R1ydepA@mail.gmail.com>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Tue, 15 Feb 2022 13:37:43 -0800
Message-ID: <CAD5xwhjYCrRU0+kJG0Pex2ga3rFxFQNyn0dX5+8io0hbEUSjsQ@mail.gmail.com>
To: "James O'Beirne" <james.obeirne@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <https://twitter.com/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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">James,</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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&#39;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 &quot;stops&quot; after a certain time, hurting reorganization.</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0=
,0,0)">However, If you wanted to map this conceptually onto existing tx ind=
exes, you could have an output with exactly the script `&lt;100 blocks&gt; =
OP_CSV` and then allow sponsor references to be pruned after that output is=
 &quot;garbage collected&quot; 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.</div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)">It&#39;s not a huge leap to say that this behavior should be made enti=
rely &quot;virtual&quot;, 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.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">So =
it really isn&#39;t clear to me that we&#39;re hurting the transaction grap=
h properties that severely with changes in this family. It&#39;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&#39;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</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">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).</div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">Lastly, it&#39;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.</div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0=
,0,0)">All things considered, I favor the simple version of just having spo=
nsors only valid for the block their target is co-resident in.</div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)">Jeremy</div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)"><br></div><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gmail_s=
ignature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=
=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><br>=
</div></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Tue, Feb 15, 2022 at 12:53 PM James O&#39;Beirne via b=
itcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr">&gt; The downside is that in a 6 block =
reorg any transaction that is moved<br>&gt; past its expiration date become=
s invalid and all its descendants<br>&gt; become invalid too.<br><br>Worth =
noting that the transaction sponsors design is no worse an<br>offender on t=
his count than, say, CPFP is, provided we adopt the change<br>that sponsore=
d txids are required to be included in the current block<br>*or* prior bloc=
ks. (The original proposal allowed current block only).<br><br>In other wor=
ds, the sponsored txids are just &quot;virtual inputs&quot; to the<br>spons=
or transaction.<br><br>This is a much different case than e.g. transaction =
expiry based on<br>wall-clock time or block height, which I agree complicat=
es reorgs<br>significantly.<br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000008363a005d81558eb--