Billy Tetrud [ARCHIVE] on Nostr: 📅 Original date posted:2021-08-26 📝 Original message: One interesting thing I ...
📅 Original date posted:2021-08-26
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210826/952bece6/attachment.html>;
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210826/952bece6/attachment.html>;