[bitcoin-dev] Take 2: Removing the Dust Limit

[Jeremy <jlrubin@mit.edu>]

[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]

Bitcoin Devs (+cc lightning-dev),

Earlier this year I proposed allowing 0 value outputs and that was shot
down for various reasons, see
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html

I think that there can be a simple carve out now that package relay is
being launched based on my research into covenants from 2017
https://rubin.io/public/pdfs/multi-txn-contracts.pdf.

Essentially, if we allow 0 value outputs BUT require as a matter of policy
(or consensus, but policy has major advantages) that the output be used as
an Intermediate Output (that is, in order for the transaction to be
creating it to be in the mempool it must be spent by another tx)  with the
additional rule that the parent must have a higher feerate after CPFP'ing
the parent than the parent alone we can both:

1) Allow 0 value outputs for things like Anchor Outputs (very good for not
getting your eltoo/Decker channels pinned by junk witness data using Anchor
Inputs, very good for not getting your channels drained by at-dust outputs)
2) Not allow 0 value utxos to proliferate long
3) It still being valid for a 0 value that somehow gets created to be spent
by the fee paying txn later

Just doing this as a mempool policy also has the benefits of not
introducing any new validation rules. Although in general the IUTXO concept
is very attractive, it complicates mempool :(

I understand this may also be really helpful for CTV based contracts (like
vault continuation hooks) as well as things like spacechains.

Such a rule -- if it's not clear -- presupposes a fully working package
relay system.

I believe that this addresses all the issues with allowing 0 value outputs
to be created for the narrow case of immediately spendable outputs.

Cheers,

Jeremy

p.s. why another post today? Thank Greg
https://twitter.com/JeremyRubin/status/1468390561417547780


--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

[-- Attachment #2: Type: text/html, Size: 5392 bytes --]