some additional answers/clarifications
> 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 would remove it entirely -- i don't think there's a difference between
the two realistically.
>
> Allowing 0-value or
Under no circumstances do I think we should *increase* the dust limit. That
would have a mildly confiscatory effect on current Lightning Channel
operators, among others.
Generally, the UTXO set will grow. We should work to accommodate the worst
case scenario under current consensus rules. I think
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
If it weren't for the implications in changing standardness here, I think we should consider increasing the dust limit
instead.
The size of the UTXO set is a fundamental scalability constraint of the system. In fact, with proposals like
assume-utxo/background history sync it is arguably *the*
For the Lightning point, even if the dust limit was removed Lightning
would still be trimming any HTLCs below the amount they cost to redeem
in fees, so that wouldn't make any difference.
Nonetheless I think reason 1 should be enough.
2021-08-08 11:52 (GMT-07:00), Jeremy said:
> We should
We should remove the dust limit from Bitcoin. Five reasons:
1) it's not our business what outputs people want to create
2) dust outputs can be used in various authentication/delegation smart
contracts
3) dust sized htlcs in lightning (
