path: root/a3/60bf540bf84e5c2e19819cf53866dd72e8e107

Return-Path: <jlrubin@mit.edu>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EC060C0012;
 Wed,  8 Dec 2021 01:28:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id DAE2D41C10;
 Wed,  8 Dec 2021 01:28:57 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id PSRWwGWNIIOV; Wed,  8 Dec 2021 01:28:57 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp4.osuosl.org (Postfix) with ESMTPS id BB54041C17;
 Wed,  8 Dec 2021 01:28:56 +0000 (UTC)
Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com
 [209.85.167.48]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1B81SrgH017779
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT);
 Tue, 7 Dec 2021 20:28:55 -0500
Received: by mail-lf1-f48.google.com with SMTP id n12so2417040lfe.1;
 Tue, 07 Dec 2021 17:28:54 -0800 (PST)
X-Gm-Message-State: AOAM531nJS8MYldN+0w70P3VcsDoez8FGJzqIP0t2VmSH1HVQhjltR5C
 ZY5CpQW9OdQVg8MSRqj/jrlZhKNJDfqJOLLT4+s=
X-Google-Smtp-Source: ABdhPJzZBVYTaEDW3M8MtrB0dJJt6mGH57VfsOxVsDTUhRHVCnYPCc4YbxZem/Lbg0S0SGXeFy/Go1RUqMOGDqknYn4=
X-Received: by 2002:a05:6512:c17:: with SMTP id
 z23mr44041722lfu.175.1638926933486; 
 Tue, 07 Dec 2021 17:28:53 -0800 (PST)
MIME-Version: 1.0
From: Jeremy <jlrubin@mit.edu>
Date: Tue, 7 Dec 2021 17:28:42 -0800
X-Gmail-Original-Message-ID: <CAD5xwhid2OH0GzXPvqWgsMag4J9zidsewEquT-JoOweVD5pxZg@mail.gmail.com>
Message-ID: <CAD5xwhid2OH0GzXPvqWgsMag4J9zidsewEquT-JoOweVD5pxZg@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000aef3d505d2986982"
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: [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 01:28:58 -0000

--000000000000aef3d505d2986982
Content-Type: text/plain; charset="UTF-8"

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/019307.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 policy
(or consensus, but policy has major advantages) that the output be used as
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 the
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 not
getting your eltoo/Decker channels pinned by junk witness data using Anchor
Inputs, very good for not getting your channels drained by at-dust outputs)
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 concept
is very attractive, it complicates mempool :(

I understand this may also be really helpful for CTV based contracts (like
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 outputs
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>

--000000000000aef3d505d2986982
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:#000000">Bitcoin Devs (+cc lightni=
ng-dev),</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000">Earlier this year I proposed allowing 0 value outputs and th=
at was shot down for various=C2=A0reasons, see=C2=A0<a href=3D"https://list=
s.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html">https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html</=
a></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
#000000">I think that there can be a simple carve out now that package rela=
y is being launched based on my research into covenants from 2017=C2=A0<a h=
ref=3D"https://rubin.io/public/pdfs/multi-txn-contracts.pdf">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:#0=
00000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">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 Output (t=
hat is, in order for the transaction to be creating it to be in the mempool=
 it must be spent by another tx) =C2=A0with the additional rule that the pa=
rent must have a higher feerate=C2=A0after CPFP&#39;ing the parent than the=
 parent alone we can both:</div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:#000000">1) Allow 0 value outputs for things like A=
nchor Outputs (very good for not getting your eltoo/Decker channels pinned =
by junk witness data using Anchor Inputs, very good for not getting your ch=
annels drained by at-dust outputs)</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">2=
) Not allow 0 value utxos to proliferate long</div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
#000000">3) It still being valid for a 0 value that somehow gets created to=
 be spent by the fee paying txn later</div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=
><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:#000000">Just doing this as a mempool po=
licy also has the benefits of not introducing any new validation rules. Alt=
hough in general the IUTXO=C2=A0concept is very attractive, it complicates =
mempool :(</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:#000000">I understand this may also be really helpful for CTV based=
 contracts (like vault continuation hooks) as well as things like spacechai=
ns.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:#000000">Such a rule -- if it&#39;s not clear -- presupposes a fully worki=
ng package relay system.</div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:#000000">I believe that this addresses all the issues=
 with allowing 0 value outputs to be created for the narrow case of immedia=
tely spendable outputs.</div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:#000000">Cheers,</div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=
><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:#000000">Jeremy</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000">p.s. why another p=
ost today? Thank Greg=C2=A0<a href=3D"https://twitter.com/JeremyRubin/statu=
s/1468390561417547780">https://twitter.com/JeremyRubin/status/1468390561417=
547780</a></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:#000000"><br></div><div><div dir=3D"ltr" class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https:=
//twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"htt=
ps://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div></div></div=
>

--000000000000aef3d505d2986982--