From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: <20210810061441.6rg3quotiycomcp6@ganymede> <20210812220339.GA3416@erisian.com.au> <50s2eg2qZ_BSHhI1mT_mHP7fkDQ8EXnakOb9NmDfZlx_hN44l37UmopfAr2V4ws4yhx0YihNYBIOelJ01vhITI8K4G1UgmobTwf9FyJq_Yo=@protonmail.com> In-Reply-To: <50s2eg2qZ_BSHhI1mT_mHP7fkDQ8EXnakOb9NmDfZlx_hN44l37UmopfAr2V4ws4yhx0YihNYBIOelJ01vhITI8K4G1UgmobTwf9FyJq_Yo=@protonmail.com> From: Billy Tetrud Date: Thu, 26 Aug 2021 14:21:25 -0700 Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000015e76605ca7cf4aa" X-Mailman-Approved-At: Thu, 26 Aug 2021 22:06:06 +0000 Cc: lightning-dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

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'm not sure how to evaluate the magnitude of this future cost.



= =C2=A0

On Fri, Aug 20, 2021 at 8:12 PM ZmnSCPxj via bitcoin= -dev <bitcoin-d= ev@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 m= aintenance=C2=A0(storing the output potentially forever) is lower than thei= r immediate reward in fees.
> - 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.
> - 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 p= revailing mempool feerates, causes an incentive to increase network central= ization=C2=A0(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 outpu= t *would have been* created that is less than the dust limit, the output is= instead put into fees.
http= s://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.m= d#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 m= iners, so the existence of a dust limit might very well be incentivize-comp= atible for miners, regardless of centralization effects or not.


Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000015e76605ca7cf4aa--