On Sun, Aug 08, 2021 at 11:52:55AM -0700, Jeremy wrote: > We should remove the dust limit from Bitcoin. Five reasons:
Jeremy knows this, but to be clear for other readers, the dust limit is a policy in Bitcoin Core (and other software) where it refuses by default to relay or mine transactions with outputs below a certain amount. If nodes or miners running with non-default policy choose to relay or mine those transactions, they are not penalized (not directly, at least; there's BIP152 to consider). Question for Jeremy: would you also allow zero-value outputs? Or would you just move the dust limit down to a fixed 1-sat? I think the dust limit is worth keeping: > 1) it's not our business what outputs people want to create Every additional output added to the UTXO set increases the amount of work full nodes need to do to validate new transactions. For miners for whom fast validation of new blocks can significantly affect their revenue, larger UTXO sets increase their costs and so contributes towards centralization of mining. Allowing 0-value or 1-sat outputs minimizes the cost for polluting the UTXO set during periods of low feerates. If your stuff is going to slow down my node and possibly reduce my censorship resistance, how is that not my business? > 2) dust outputs can be used in various authentication/delegation smart > contracts All of which can also use amounts that are economically rational to spend on their own. If you're gonna use the chain for something besides value transfer, and you're already wiling to pay X in fees per onchain use, why is it not reasonable for us to ask you to put up something on the order of X as a bond that you'll actually clean up your mess when you're no longer interested in your thing? > 3) dust sized htlcs in lightning ( > https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light) > force channels to operate in a semi-trusted mode Nope, nothing is forced. Any LN node can simply refuse to accept/route HTLCs below the dust limit. > which has implications > (AFAIU) for the regulatory classification of channels in various > jurisdictions Sucks for the people living there. They should change their laws. If they can't do that, they should change their LN node policies not to route uneconomic HTLCs. We shouldn't make Bitcoin worse to make complying with regulations easier. I also doubt your proposed solution fixes the problem. Any LN node that accepts an uneconomic HTLC cannot recover that value, so the money is lost either way. Any sane regulation would treat losing value to transaction fees the same as losing value to uneconomical conditions. Finally, if LN nodes start polluting the UTXO set with no economic way to clean up their mess, I think that's going to cause tension between full node operators and LN node operators. > agnostic treatment of fund transfers would simplify this > (like getting a 0.01 cent dividend check in the mail) I'm not sure I understand this point. It sounds to me like you're comparing receiving an uneconomic output to receiving a check that isn't worth the time to cash. But the costs of checks are borne only by the people who send, receive, and process them. The costs of uneconomic outputs polluting the UTXO set are borne by every full node forever (or for every archival full node forever if non-archival nodes end up using something like utreexo). > 4) thinly divisible colored coin protocols might make use of sats as value > markers for transactions. I'm not exactly sure what you're talking about, but if Alice wants to communicate the number n onchain, she can do: if n < dust: nSequence = 0x0000 + n # should probably check endianess else: nValue = n There's at least 15 bits of nSequence currently without consensus or policy meaning, and the dust limits are currently in the hundreds of sat, so there's plenty of space. Alice could probably also communicate the same thing by grinding her output script's hash or pubkey; again, with dust limits just being hundreds of sats, that's not too much grinding. > 5) should we ever do confidential transactions we can't prevent it without > compromising privacy / allowed transfers I'm not an expert, but it seems to me that you can do that with range proofs. The range proof for >dust doesn't need to become part of the block chain, it can be relay only. I haven't looked since they upgraded to bulletproofs, but ISTR the original CT implementation leaked the most significant digits or something (that kept down the byte size of the proofs), so maybe it was already possible to know what was certainly not dust and what might be dust. In short, it's my opinion that the dust limit is not creating any real problems, so it should be kept for its contribution to keeping full nodes faster, cheaper, and more efficient. -Dave P.S. As I prepared to send this, Matt's email arrived about "If it weren't for the implications in changing standardness here, I think we should consider increasing the dust limit instead." I'm in agreement with both parts of that statement.
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
