[Lightning-dev] [bitcoin-dev] Removing the Dust Limit

ZmnSCPxj ZmnSCPxj at protonmail.com
Fri Oct 8 22:47:11 UTC 2021

Good morning Pieter,

> Indeed - UTXO set size is an externality that unfortunately Bitcoin's consensus rules fail to account
> for. Having a relay policy that avoids at the very least economically irrational behavior makes
> perfect sense to me.
> It's also not obvious how consensus rules could deal with this, as you don't want consensus rules
> with hardcoded prices/feerates. There are possibilities with designs like transactions getting
> a size/weight bonus/penalty, but that's both very hardforky, and hard to get right without
> introducing bad incentives.

Why is a +weight malus *very* hardforky?

Suppose a new version of a node adds, say, +20 sipa per output of a transaction (in order to economically discourage the creation of additional outputs in the UTXO set).
Older versions would see the block as being lower weight than usual, but as the consensus rule is "smaller than 4Msipa" they should still accept any block acceptable to newer versions.

It seems to me that only a -weight bonus is hardforky (but then xref SegWit and its -weight bonus on inputs).

I suppose the effect is primarily felt on mining nodes?
Miners might refuse to activate such a fork, as they would see fewer transactions per block on average?


More information about the Lightning-dev mailing list