path: root/9f/96da66deabd7441a395dadd19ff3f452facc62

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 831F2C000E;
 Thu, 26 Aug 2021 21:21:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 601288264A;
 Thu, 26 Aug 2021 21:21:49 +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 GGO4aI_zJKWr; Thu, 26 Aug 2021 21:21:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [IPv6:2a00:1450:4864:20::535])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 168B581BCB;
 Thu, 26 Aug 2021 21:21:45 +0000 (UTC)
Received: by mail-ed1-x535.google.com with SMTP id g22so6677804edy.12;
 Thu, 26 Aug 2021 14:21:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=d0xak60LZdDh0rZ91YaIE9cBNpFGXbEvbNChW802zIA=;
 b=rusQTB9dXmcficexNGTG8LEE3PiRa5/+NTMogvOylhglBocTti70pM1s+xQ6ou6/+W
 WQ4sulYRfL3iMbdBH+tR8K2fyOz8CX6IJNmtGnZrmOt2NXCXvoZohlCaydpTLZrsAAQ/
 J1RCyoboYNW986mSfdBPM3yIq90iFxgdYCq3HvfnPlMB3Jp46FaFnjzF6/T0VHWNUUbD
 6Q+cvDULFPZ8EFceRqabnxsO4dNjIe354whNF+yhLJ+gTuSQAOQps/6tn+W3fUS5nFWx
 S4RZbWvjFrshTCe2U4ilvrhNQScbB9XAdi6z5DxO7LxmgQpDpnQNolPiJm1aSomHBm+R
 Hq5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=d0xak60LZdDh0rZ91YaIE9cBNpFGXbEvbNChW802zIA=;
 b=rIbfh2XJOWqUBpitMfIU6OsyWQTXSPX6VQZriFAQxyeL1L7b0IPteod7bCTseko6mq
 fODHhUVbkGuRdosjlvPxaORlRrFQgy6DC/KoA5pJ96YOe+XeEB/ganVngSkB4ypPqg39
 EWb485Nya3/xMg9lWw5TGoBeVJS6E15O28ELYK9qcQ2dQ7R8MzSDuACSYc2QToA14TB1
 owIid+Hr4sWX12f0CUpJAnLfUIq9EzQ9eIdVsIH3mlS/SE7Ujr30f5RrRVjMDksL9xe2
 ewgmjyjOCfdCiuiy7mMeWFjLq/p04doVcXFG2eljXrHXblJauLfGjnQ81yNsIXZ3kR5C
 FXeQ==
X-Gm-Message-State: AOAM530DohAdPdPHsFhi4fTqwIY2ZEGau6A/nyju3exPPex+gITQ7Tc7
 WrD9B3vpL7jX/+tZd4zra76yxOhPGQHnzmv+Iax4Ki3swoiL8g==
X-Google-Smtp-Source: ABdhPJyfrXniuPHX2MKTfNBngdH6tjqE6JcRcwciCsU7YqMOjzSHsvKd/13Xzu/UKIgmSGlv0GFUoWQ2jyM5vswH3cI=
X-Received: by 2002:aa7:d455:: with SMTP id q21mr1509996edr.5.1630012903383;
 Thu, 26 Aug 2021 14:21:43 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
 <CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com>
 <20210810061441.6rg3quotiycomcp6@ganymede>
 <CALZpt+G0CRitWLwUTA+7NnnZWNNrsEmFTMW3VmFSQ=vzXZOQGA@mail.gmail.com>
 <20210812220339.GA3416@erisian.com.au>
 <CAD5xwhiEDa2KjF265iDZ1ism4AFzh3S3D4cJSESVVKNwv9L7zA@mail.gmail.com>
 <50s2eg2qZ_BSHhI1mT_mHP7fkDQ8EXnakOb9NmDfZlx_hN44l37UmopfAr2V4ws4yhx0YihNYBIOelJ01vhITI8K4G1UgmobTwf9FyJq_Yo=@protonmail.com>
In-Reply-To: <50s2eg2qZ_BSHhI1mT_mHP7fkDQ8EXnakOb9NmDfZlx_hN44l37UmopfAr2V4ws4yhx0YihNYBIOelJ01vhITI8K4G1UgmobTwf9FyJq_Yo=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 26 Aug 2021 14:21:25 -0700
Message-ID: <CAGpPWDbseo6eYT1a54YB2-fpxpzj2cg9DL+s2_rpoa+dGfnhaQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000015e76605ca7cf4aa"
X-Mailman-Approved-At: Thu, 26 Aug 2021 22:06:06 +0000
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] 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: Thu, 26 Aug 2021 21:21:49 -0000

--00000000000015e76605ca7cf4aa
Content-Type: text/plain; charset="UTF-8"

One interesting thing I thought of: the cost of maintenance of the dust
creates a (very) small incentive to mine transactions that *use* dust
outputs with a slightly lower fee that contain dust, in order to reduce the
future maintenance cost for themselves. However, the rational discount
would likely be vanishingly small.  It would be interesting to add
something to the consensus rules to decrease the vbytes for a transaction
that consumes dust outputs such that the value of removing them from the
system (saving the future cost of maintenance) is approximately equal to
the amount that the fee could be made lower for such transactions. Even
measuring this as a value over the whole (future) bitcoin network, I'm not
sure how to evaluate the magnitude of this future cost.





On Fri, Aug 20, 2021 at 8:12 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Jeremy,
>
> > one interesting point that came up at the bitdevs in austin today that
> favors remove that i believe is new to this discussion (it was new to me):
> >
> > the argument can be reduced to:
> >
> > - dust limit is a per-node relay policy.
> > - it is rational for miners to mine dust outputs given their cost of
> maintenance (storing the output potentially forever) is lower than their
> immediate reward in fees.
> > - if txn relaying nodes censor something that a miner would mine, users
> will seek a private/direct relay to the miner and vice versa.
> > - if direct relay to miner becomes popular, it is both bad for privacy
> and decentralization.
> > - therefore the dust limit, should there be demand to create dust at
> prevailing mempool feerates, causes an incentive to increase network
> centralization (immediately)
> >
> > the tradeoff is if a short term immediate incentive to promote network
> centralization is better or worse than a long term node operator overhead.
>
> Against the above, we should note that in the Lightning spec, when an
> output *would have been* created that is less than the dust limit, the
> output is instead put into fees.
>
> https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs
>
> Thus, the existence of a dust limit encourages L2 protocols to have
> similar rules, where outputs below the dust limit are just given over as
> fees to miners, so the existence of a dust limit might very well be
> incentivize-compatible for miners, regardless of centralization effects or
> not.
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div><br></div><div><span style=3D"color:rgb(0,0,0);font-f=
amily:arial,helvetica,sans-serif">One interesting thing I thought of: the c=
ost of maintenance of the dust creates a (very) small incentive to mine tra=
nsactions that *use* dust outputs with a slightly lower fee that contain du=
st, in order to reduce the future maintenance cost for themselves. However,=
 the rational discount would likely be vanishingly small.=C2=A0 It would be=
 interesting to add something to the consensus rules to decrease the vbytes=
 for a transaction that consumes dust outputs such that the value of removi=
ng them from the system (saving the future cost of maintenance) is approxim=
ately equal to the amount that the fee could be made lower for such transac=
tions. Even measuring this as a value over the whole (future) bitcoin netwo=
rk, I&#39;m not sure how to evaluate the magnitude of this future cost. </s=
pan><br></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvet=
ica,sans-serif"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-=
family:arial,helvetica,sans-serif"><br></span></div><div><span style=3D"col=
or:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div=
><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">=
=C2=A0</span><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Fri, Aug 20, 2021 at 8:12 PM ZmnSCPxj via bitcoin=
-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">Good morning Jeremy,<br>
<br>
&gt; one interesting point that came up at the bitdevs in austin today that=
 favors remove that i believe is new to this discussion (it was new to me):=
<br>
&gt;<br>
&gt; the argument can be reduced to:<br>
&gt;<br>
&gt; - dust limit is a per-node relay policy.<br>
&gt; - it is rational for miners to mine dust outputs given their cost of m=
aintenance=C2=A0(storing the output potentially forever) is lower than thei=
r immediate reward in fees.<br>
&gt; - if txn relaying nodes censor something that a miner would mine, user=
s will seek a private/direct relay to the miner and vice versa.<br>
&gt; - if direct relay to miner becomes popular, it is both bad for privacy=
 and decentralization.<br>
&gt; - therefore the dust limit, should there be demand to create dust at p=
revailing mempool feerates, causes an incentive to increase network central=
ization=C2=A0(immediately)<br>
&gt;<br>
&gt; the tradeoff is if a short term immediate incentive to promote network=
 centralization is better or worse than a long term node operator overhead.=
<br>
<br>
Against the above, we should note that in the Lightning spec, when an outpu=
t *would have been* created that is less than the dust limit, the output is=
 instead put into fees.<br>
<a href=3D"https://github.com/lightningnetwork/lightning-rfc/blob/master/03=
-transactions.md#trimmed-outputs" rel=3D"noreferrer" target=3D"_blank">http=
s://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.m=
d#trimmed-outputs</a><br>
<br>
Thus, the existence of a dust limit encourages L2 protocols to have similar=
 rules, where outputs below the dust limit are just given over as fees to m=
iners, so the existence of a dust limit might very well be incentivize-comp=
atible for miners, regardless of centralization effects or not.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<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>

--00000000000015e76605ca7cf4aa--