<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 20, 2021, 06:52 Jeremy via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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):</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">the argument can be reduced to:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- dust limit is a per-node relay policy.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- 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.</div></div></blockquote></div></div><div dir="auto">-Here, u r assuming miners not running full nodes, or even stateless nodes as in Utreexo</div><div dir="auto">-otherwise they suffer from storing dust UTXOS/their effect on proof length, right?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- if txn relaying nodes censor something that a miner would mine, users will seek a private/direct relay to the miner and vice versa.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- if direct relay to miner becomes popular, it is both bad for privacy and decentralization.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- therefore the dust limit, should there be demand to create dust at prevailing mempool feerates, causes an incentive to increase network centralization (immediately)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">the tradeoff is if a short term immediate incentive to promote network centralization is better or worse than a long term node operator overhead.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">///////////////////</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">my take is that:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">1) having a dust limit is worse since we'd rather not have an incentive to produce or roll out centralizing software, whereas not having a dust limit creates an mild incentive for node operators to improve utreexo decentralizing software.</div></div></blockquote></div></div><div dir="auto">Why not having dust limit improves Utreexo, I think (and tried to suggest many times) separate storing of dust&other non spendable UTXOS (and their hashes) so that they do not affect other UTXOS proofs ( and not brought into main memory unless called as a TXO)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">2) it's hard to quantify the magnitude of the incentives, which does matter.</div></div></blockquote></div></div><div dir="auto">I honestly don't get the long term perspective of miners Incentivised to storing small dust UTXOS instead of having their values added to the fee.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" rel="noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>