path: root/af/ad12f113d97f6c7b30465bf042618863ae744c

Return-Path: <bastien.teinturier@acinq.fr>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9C1F0C0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Dec 2021 08:34:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 88ECC4016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Dec 2021 08:34:47 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 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=acinq-fr.20210112.gappssmtp.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 NF_Z7BZqW8Ak
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Dec 2021 08:34:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com
 [IPv6:2607:f8b0:4864:20::b2f])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 612C740147
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Dec 2021 08:34:44 +0000 (UTC)
Received: by mail-yb1-xb2f.google.com with SMTP id v138so4146735ybb.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 08 Dec 2021 00:34:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=acinq-fr.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=UNvSPWvU2+nwAJfcr9r9G/dq9IhzcVPVmqAsZDRKRjQ=;
 b=B02+p4vhdmIEpzv+io7dqEFy5U9EisoMbkwv86ZUydKMUjBitH8m8LEekrtBPKTkQo
 zJcX+iPgH6929rBEddJYPioOyLUL9ifxTW3Uja7Scmty6DzWTMMUDBEdC9Lbxv2/S2f4
 Rm+zGGXfBqyqriMldNHY+Ubkfip56usYI8A4hwKWlsR0rLpDnqKfBHdAc+g937rXNVVa
 34b/MG5Dpmim5FKJJrHJOf3joV5T/bP5MXSv8qaT5+2Fa002iX/YhByGfFK/QvITEUHQ
 K9TxxdHgPsYjVEhNtXHCZamM78CvC96ugfTkkEAUZUiR0Xy1pCR5gPEjVWjqbcJ4Eb3m
 qdMA==
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=UNvSPWvU2+nwAJfcr9r9G/dq9IhzcVPVmqAsZDRKRjQ=;
 b=SAan2LJ29utKfXYVOWTqnQ2X1SQeQ+3Jbpc9YdJ54K4vesSolT+WCsqAY71FKzNrsc
 8Fvzx+w0U9hbkkmdVHnB9Il06ytx7RlQ5UrNavWyTBDhXc0ULsb3mPuVV/dNJvWp5jsL
 ORCU4L3wo2cWu2gaabTdGmgjQ6eO1ljdqG6bzn1zWHrGoDdGtcjj+rvHG2oR1Hm/fNUw
 EQLdKsr2d592w7EIj/Rm40zgcYX/SvC+0jPdFKUGPfQmqefQyj3zXiSbh40e9BSd+RYo
 3GVvPaEY24bV3XBJ6fHiEhJDJzGmvN1vYzg2OWwB8DC8gQp6NaqxxCBPE0iixqoTDDGX
 Ma2g==
X-Gm-Message-State: AOAM530E/MJ4qFyt7rzgKJkNym7Ddu77Wh9xQYEA4tzmDZKQ5w8vo0g0
 3ED0NfyVDOD6M5gLLcn3ptWv+wd4qax2BVvefFPzMQ==
X-Google-Smtp-Source: ABdhPJwAXp0xz2Th2S/2Jx1OEmdP6TS5KwOJHiIFxN622Rjum4ZIUY/PVkrQ87+l9oLoRy2MQncrL7fTdfuDtuLjzi4=
X-Received: by 2002:a25:abe2:: with SMTP id v89mr63172800ybi.521.1638952483306; 
 Wed, 08 Dec 2021 00:34:43 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhid2OH0GzXPvqWgsMag4J9zidsewEquT-JoOweVD5pxZg@mail.gmail.com>
In-Reply-To: <CAD5xwhid2OH0GzXPvqWgsMag4J9zidsewEquT-JoOweVD5pxZg@mail.gmail.com>
From: Bastien TEINTURIER <bastien@acinq.fr>
Date: Wed, 8 Dec 2021 09:34:32 +0100
Message-ID: <CACdvm3Oynv4gWdaGXATxc3SoYDD8kuiPq-d9F2itsmayP0qeZQ@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000924e6005d29e5c43"
X-Mailman-Approved-At: Wed, 08 Dec 2021 09:35:25 +0000
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-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 08:34:47 -0000

--000000000000924e6005d29e5c43
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jeremy,

Right now, lightning anchor outputs use a 330 sats amount. Each commitment
transaction has two such outputs, and only one of them is spent to help the
transaction get confirmed, so the other stays there and bloats the utxo set=
.
We allow anyone to spend them after a csv of 16 blocks, in the hope that
someone will claim a batch of them when the fees are low and remove them
from the utxo set. However, that trick wouldn't work with 0-value outputs,
as
no-one would ever claim them (doesn't make economical sense).

We actually need to have two of them to avoid pinning: each participant is
able to spend only one of these outputs while the parent tx is unconfirmed.
I believe N-party protocols would likely need N such outputs (not sure).

You mention a change to the carve-out rule, can you explain it further?
I believe it would be a necessary step, otherwise 0-value outputs for
CPFP actually seem worse than low-value ones...

Thanks,
Bastien

Le mer. 8 d=C3=A9c. 2021 =C3=A0 02:29, Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> Bitcoin Devs (+cc lightning-dev),
>
> Earlier this year I proposed allowing 0 value outputs and that was shot
> down for various reasons, see
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/01930=
7.html
>
> I think that there can be a simple carve out now that package relay is
> being launched based on my research into covenants from 2017
> https://rubin.io/public/pdfs/multi-txn-contracts.pdf.
>
> Essentially, if we allow 0 value outputs BUT require as a matter of polic=
y
> (or consensus, but policy has major advantages) that the output be used a=
s
> an Intermediate Output (that is, in order for the transaction to be
> creating it to be in the mempool it must be spent by another tx)  with th=
e
> additional rule that the parent must have a higher feerate after CPFP'ing
> the parent than the parent alone we can both:
>
> 1) Allow 0 value outputs for things like Anchor Outputs (very good for no=
t
> getting your eltoo/Decker channels pinned by junk witness data using Anch=
or
> Inputs, very good for not getting your channels drained by at-dust output=
s)
> 2) Not allow 0 value utxos to proliferate long
> 3) It still being valid for a 0 value that somehow gets created to be
> spent by the fee paying txn later
>
> Just doing this as a mempool policy also has the benefits of not
> introducing any new validation rules. Although in general the IUTXO conce=
pt
> is very attractive, it complicates mempool :(
>
> I understand this may also be really helpful for CTV based contracts (lik=
e
> vault continuation hooks) as well as things like spacechains.
>
> Such a rule -- if it's not clear -- presupposes a fully working package
> relay system.
>
> I believe that this addresses all the issues with allowing 0 value output=
s
> to be created for the narrow case of immediately spendable outputs.
>
> Cheers,
>
> Jeremy
>
> p.s. why another post today? Thank Greg
> https://twitter.com/JeremyRubin/status/1468390561417547780
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Hi Jeremy,<div><br></div><div>Right now, lightning anchor =
outputs use a 330 sats amount. Each commitment</div><div>transaction has tw=
o such outputs, and only one of them is spent to help the</div><div>transac=
tion get confirmed, so the other stays there and bloats the utxo set.</div>=
<div>We allow anyone to spend them after a csv of 16 blocks, in the hope th=
at</div><div>someone will claim a batch of them when the fees are low and r=
emove them</div><div>from the utxo set. However, that trick wouldn&#39;t wo=
rk with 0-value outputs, as</div><div>no-one would ever claim them (doesn&#=
39;t make economical sense).</div><div><br></div><div>We actually need to h=
ave two of them to avoid pinning: each participant is</div><div>able to spe=
nd only one of these outputs while the parent tx is unconfirmed.</div><div>=
I believe N-party protocols would likely need N such outputs (not sure).</d=
iv><div><br></div><div>You mention a change to the carve-out rule, can you =
explain it further?</div><div>I believe it would be a necessary step, other=
wise 0-value outputs for</div><div>CPFP actually seem worse than low-value =
ones...</div><div><br></div><div>Thanks,</div><div>Bastien</div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer=
. 8 d=C3=A9c. 2021 =C3=A0=C2=A002:29, Jeremy via bitcoin-dev &lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfound=
ation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">Bitcoin Devs (+cc lightning-dev),</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)">Earlier this year I propose=
d allowing 0 value outputs and that was shot down for various=C2=A0reasons,=
 see=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2021-August/019307.html" target=3D"_blank">https://lists.linuxfoundation.=
org/pipermail/bitcoin-dev/2021-August/019307.html</a></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I think t=
hat there can be a simple carve out now that package relay is being launche=
d based on my research into covenants from 2017=C2=A0<a href=3D"https://rub=
in.io/public/pdfs/multi-txn-contracts.pdf" target=3D"_blank">https://rubin.=
io/public/pdfs/multi-txn-contracts.pdf</a>.</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)">Essentially, if we =
allow 0 value outputs BUT require as a matter of policy (or consensus, but =
policy has major advantages) that the output be used as an Intermediate Out=
put (that is, in order for the transaction to be creating it to be in the m=
empool it must be spent by another tx) =C2=A0with the additional rule that =
the parent must have a higher feerate=C2=A0after CPFP&#39;ing the parent th=
an the parent alone we can both:</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;color:rgb(0,0,0)">1) Allow 0 value outputs for t=
hings like Anchor Outputs (very good for not getting your eltoo/Decker chan=
nels pinned by junk witness data using Anchor Inputs, very good for not get=
ting your channels drained by at-dust outputs)</div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)">2) Not allow 0 value utxos to proliferate long</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">3) It still being valid for a 0 value that someho=
w gets created to be spent by the fee paying txn later</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)">Just doi=
ng this as a mempool policy also has the benefits of not introducing any ne=
w validation rules. Although in general the IUTXO=C2=A0concept is very attr=
active, it complicates mempool :(</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)">I understand this may also =
be really helpful for CTV based contracts (like vault continuation hooks) a=
s well as things like spacechains.</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)">Such a rule -- if it&#39;s =
not clear -- presupposes a fully working package relay system.</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)=
">I believe that this addresses all the issues with allowing 0 value output=
s to be created for the narrow case of immediately spendable outputs.</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)">Cheers,</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)">Jeremy</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)">p.s. why another post today=
? Thank Greg=C2=A0<a href=3D"https://twitter.com/JeremyRubin/status/1468390=
561417547780" target=3D"_blank">https://twitter.com/JeremyRubin/status/1468=
390561417547780</a></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;fo=
nt-size:small;color:rgb(0,0,0)"><br></div><div><div dir=3D"ltr"><div dir=3D=
"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@=
JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank=
"></a></div></div></div></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>

--000000000000924e6005d29e5c43--