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