path: root/fb/ec9e111f71d7a9cedb113aa0ba3f9e7ff6a661

Return-Path: <rsomsen@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 77FB6C0012;
 Wed,  8 Dec 2021 22:52:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 5FA45824A4;
 Wed,  8 Dec 2021 22:52:03 +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 5G4bxysubxxQ; Wed,  8 Dec 2021 22:52:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com
 [IPv6:2607:f8b0:4864:20::b29])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 1EC168246F;
 Wed,  8 Dec 2021 22:52:02 +0000 (UTC)
Received: by mail-yb1-xb29.google.com with SMTP id g17so9423372ybe.13;
 Wed, 08 Dec 2021 14:52:02 -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=l5W1OSZM+yo3/Mg7/r0bMkeeC/3IUyx7jtVXZP4vPrg=;
 b=JJgFQGHMApyVcum7Wjzg3wcjbFWHIXOxAN1iTB9A7jaw67p4IVnLHFrH26itawIDVd
 IfijNkxl6JFxURcQkNgRa3TV3T8SWdIZ+QCUQoy0+ynGh8wBTWmS/d06sE2U7sF+XDJ5
 iKxU9/Z9XEzPvNxzI8JTdgzddu8hFdU5hJaNM8J7kJTCptRz30XMSz4d7SXtPyDpqU2l
 PVC1Nl/pA2CLMZ6aK854cg7EoP+ZlDEdK0x6zIbcpaIQJfT7cWu0dXaFFfxxTudXyqAq
 sJpFoV4esBIbCLmCXtfx6dAIZ35x+QgUTujZ5IwfBd1eVW17SRq7KcgHwqcy6ROpwQXz
 qJEg==
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=l5W1OSZM+yo3/Mg7/r0bMkeeC/3IUyx7jtVXZP4vPrg=;
 b=HE4t6zb2trXEHuznxUJ+JA65PCiiwHRkVkLlf2S8vbSQN1g/RylteUnkPG0YjEUEfh
 GiGOW4YMo9Q/vzwCuY5HDyAbO2IGLLPyjSnrezMQTlwz9DdLwgqsjEtjSs/OQK4S1Lal
 Sy2Qp3wDwbf2Krqjk0UyTZaCSJv20z1Mg5Llqf8NxL/I50TYQqyu6GFTzrDqHPwTOqTk
 JKVqu34oweJtoERbw0kQW0fX7pac8lpMCf/WVFco20pKiKy7b4l1I4CHcIMufgFQQwTu
 hPJUO9ZzfrRpESxZ/MHxXnoBVeHetCsih3W2gQv0bKXDAY7Ol3fnZEPOASexw838J0LQ
 xYfw==
X-Gm-Message-State: AOAM5304Ibh21VvKyiI5dE6WJPmKgvvSvNFh3Yr8wG35z2dJ+sOzfBcj
 ZBJSlsqDW6wzRsojl3drr1fKOtLK4JqKuPaRNuE=
X-Google-Smtp-Source: ABdhPJwDWWZSGQbgSwdYFS36J9K0cZgHvuHG++NMtZrZ1q6i+oNE3kFNVd6wmrqsG7+pjYo6LlvV/2PCGXD4iGSZ/YA=
X-Received: by 2002:a25:94f:: with SMTP id u15mr1894884ybm.407.1639003921044; 
 Wed, 08 Dec 2021 14:52:01 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhid2OH0GzXPvqWgsMag4J9zidsewEquT-JoOweVD5pxZg@mail.gmail.com>
 <CACdvm3Oynv4gWdaGXATxc3SoYDD8kuiPq-d9F2itsmayP0qeZQ@mail.gmail.com>
 <CAPv7TjZBU2v2Nfw2_8Qz33rUWKJ=uJ7u+_5tFxjM94mk=RnmOA@mail.gmail.com>
 <CAD5xwhiSEoBxw=NVUHnZ+s22nTZhMoWYoDrC=aQfPyvwgtLrTQ@mail.gmail.com>
In-Reply-To: <CAD5xwhiSEoBxw=NVUHnZ+s22nTZhMoWYoDrC=aQfPyvwgtLrTQ@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Wed, 8 Dec 2021 23:51:50 +0100
Message-ID: <CAPv7TjYTK=xrOxMbpD1JKQ1vTpiWWoOeGt86erFGBOP5grFYNA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="0000000000007fd9e305d2aa5684"
X-Mailman-Approved-At: Wed, 08 Dec 2021 22:52:54 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev]  Take 2: Removing the Dust Limit
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: Wed, 08 Dec 2021 22:52:03 -0000

--0000000000007fd9e305d2aa5684
Content-Type: text/plain; charset="UTF-8"

Hi Jeremy,

Thanks for sharing your thoughts.

To summarize your arguments: the intentionally malicious path to getting
the 0 sat output confirmed without being spent is uneconomical compared to
simply creating dust outputs. And even if it does happen, the tx spending
from the 0 sat output may still be valid (as long as none of its inputs get
spent elsewhere) and could eventually get confirmed.

I think those are good points. I do still see a possibility where a user
non-maliciously happens to behave in a way that causes all of the above to
happen, but it does seem somewhat unlikely.

It could happen if all of the following occurs:
1. Another output happens to get spent at a higher feerate (e.g. because an
absolute timelock expires and the output gets used)
2. The tx spending the 0 sat output then happens to not make it into the
block due to the lower fees
3. The user then happens to invalidate the tx that was spending from the 0
sat output (seems rational at that point)

Assuming this is the only scenario (I am at least not currently aware of
others), the question then becomes whether the above is acceptable in order
to avoid a soft fork.

Cheers,
Ruben


On Wed, Dec 8, 2021 at 6:41 PM Jeremy <jlrubin@mit.edu> wrote:

> IMO this is not a big problem. The problem is not if a 0 value ever enters
> the mempool, it's if it is never spent. And even if C2/P1 goes in, C1 still
> can be spent. In fact, it increases it's feerate with P1's confirmation so
> it's somewhat likely it would go in. C2 further has to be pretty expensive
> compared to C1 in order to be mined when C2 would not be, so the user
> trying to do this has to pay for it.
>
> If we're worried it might never be spent again since no incentive, it's
> rational for miners *and users who care about bloat* to save to disk the
> transaction spending it to resurrect it. The way this can be broken is if
> the txn has two inputs and that input gets spent separately.
>
> That said, I think if we can say that taking advantage of keeping the 0
> value output will cost you more than if you just made it above dust
> threshold, it shouldn't be economically rational to not just do a dust
> threshold value output instead.
>
> So I'm not sure the extent to which we should bend backwards to make 0
> value outputs impossible v.s. making them inconvenient enough to not be
> popular.
>
>
>
> -------------------------------------
> Consensus changes below:
> -------------------------------------
>
> Another possibility is to have a utxo with drop semantics; if UTXO X with
> some flag on it is not spent in the block it is created, it expires and can
> never be spent. This is essentially an inverse timelock, but severely
> limited to one block and mempool evictions can be handled as if a conflict
> were mined.
>
> These types of 0 value outputs could be present just for attaching fee in
> the mempool but be treated like an op_return otherwise. We could add two
> cases for this: one bare segwit version (just the number, no data) and one
> that's equivalent to taproot. This covers OP_TRUE anchors very efficiently
> and ones that require a signature as well.
>
> This is relatively similar to how Transaction Sponsors works, but without
> full tx graph de-linkage... obviously I think if we'll entertain a
> consensus change, sponsors makes more sense, but expiring utxos doesn't
> change as many properties of the tx-graph validation so might be simpler.
>
>
>
>
>

--0000000000007fd9e305d2aa5684
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Jeremy,<div><br></div><div>Thanks for sharing your thou=
ghts.<div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-=
serif"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-family:ar=
ial,helvetica,sans-serif">To summarize your arguments: t</span><span style=
=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">he intentional=
ly malicious path to getting the 0 sat output confirmed without being spent=
 is uneconomical compared to simply creating dust outputs.=C2=A0</span><spa=
n style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">And eve=
n if it does happen, the tx spending from the 0 sat output may still be val=
id (as long as none of its=C2=A0inputs get spent elsewhere) and could event=
ually get confirmed.</span></div><div><span style=3D"color:rgb(0,0,0);font-=
family:arial,helvetica,sans-serif"><br></span></div><div><font color=3D"#00=
0000" face=3D"arial, helvetica, sans-serif">I think those are good points. =
I do still see a possibility where a user non-maliciously happens to behave=
 in a way that causes all of the above to happen, but it does seem somewhat=
 unlikely.</font></div><div><font color=3D"#000000" face=3D"arial, helvetic=
a, sans-serif"><br></font></div><div><font color=3D"#000000" face=3D"arial,=
 helvetica, sans-serif">It could happen if all of the following occurs:</fo=
nt></div><div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif"=
>1. Another output happens to get spent at a higher feerate (e.g. because a=
n absolute timelock expires and the output gets used)</font></div><div><fon=
t color=3D"#000000" face=3D"arial, helvetica, sans-serif">2. The tx spendin=
g the 0 sat output then happens to not make it into the block due to the lo=
wer fees</font></div><div><font color=3D"#000000" face=3D"arial, helvetica,=
 sans-serif">3. The user then happens to invalidate the tx that was spendin=
g from the 0 sat output (seems rational at that point)=C2=A0</font></div><d=
iv><font color=3D"#000000" face=3D"arial, helvetica, sans-serif"></font></d=
iv><div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif"><br><=
/font></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetic=
a,sans-serif">Assuming this is the only scenario (I am at least not current=
ly aware of others), the question then becomes whether the above is accepta=
ble in order to avoid a soft fork.</span></div><div><span style=3D"color:rg=
b(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><spa=
n style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">Cheers,=
</span></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helveti=
ca,sans-serif">Ruben</span></div><div><span style=3D"color:rgb(0,0,0);font-=
family:arial,helvetica,sans-serif"><br></span></div></div></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Dec 8, 20=
21 at 6:41 PM Jeremy &lt;<a href=3D"mailto:jlrubin@mit.edu">jlrubin@mit.edu=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<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)">IMO this is not a big =
problem. The problem is not if a 0 value ever enters the mempool, it&#39;s =
if it is never spent. And even if C2/P1 goes in, C1 still can be spent. In =
fact, it increases it&#39;s feerate with P1&#39;s confirmation so it&#39;s =
somewhat likely it would go in. C2 further has to be pretty expensive compa=
red to C1 in order to be mined when C2 would not be, so the user trying to =
do this has to pay for it.</div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)">If we&#39;re worried it might never =
be spent again since no incentive, it&#39;s rational for miners *and users =
who care about bloat* to save to disk the transaction spending it to resurr=
ect it. The way this can be broken is if the txn has two inputs and that in=
put gets spent separately.</div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)">That said, I think if we can say tha=
t taking advantage of keeping the 0 value output will cost you more than if=
 you just made it above dust threshold, it shouldn&#39;t be economically ra=
tional to not just do a dust threshold value output instead.</div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze: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)">So=
 I&#39;m not sure the extent to which we should bend backwards to make 0 va=
lue outputs impossible v.s. making them inconvenient enough to not be popul=
ar.</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,helvetica,sans-serif;font-size:small;co=
lor: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><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">-------------------------------------</div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)">Consensus changes below:</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)">-------------------------------------</div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)">Another possibility is to have a utxo with drop semantics; if UTXO X wit=
h some flag on it is not spent in the block it is created, it expires and c=
an never be spent. This is essentially an inverse timelock, but severely li=
mited to one block and mempool evictions can be handled as if a conflict we=
re mined.</div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,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:sm=
all;color:rgb(0,0,0)">These types of 0 value outputs could be present just =
for attaching fee in the mempool but be treated like an op_return otherwise=
. We could add two cases for this: one bare segwit version (just the number=
, no data) and one that&#39;s equivalent to taproot. This covers OP_TRUE an=
chors very efficiently and ones that require a signature as well.</div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)">This is relatively similar to how Transaction Sponsors works, but withou=
t full tx graph de-linkage... obviously I think if we&#39;ll entertain a co=
nsensus change, sponsors makes more sense, but expiring utxos doesn&#39;t c=
hange as many properties of the tx-graph validation so might be simpler.</d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(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 clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)"><br></div></div>
</blockquote></div>

--0000000000007fd9e305d2aa5684--