Hi Jeremy, I brought up the exact same thing at coredev, but unfortunately I came up with a way in which the 0 sat output could still enter the UTXO set under those rules:
- Parent P1 (0 sat per byte) has 2 outputs, one is 0 sat - Child C1 spends the 0 sat output for a combined feerate of 1 sat per byte and they enter the mempool as a package - Child C2 spends the other output of P1 with a really high feerate and enters the mempool - Fees rise and child C1 falls out of the mempool, leaving the 0 sat output unspent For this to not be a problem, the 0 sat output needs to provably be the only spendable output. As you pointed out to me a few days ago, having a relative timelock on the other outputs would do the trick (and this happens to be true for spacechains), but that will only be provable if all script conditions are visible prior to spending time (ruling out p2sh and taproot, and conflicting with standardness rules for transactions). It's worth noting out that you can't really make a policy rule that says the 0 sat output can't be left unspent (i.e. C1 can't be evicted without also evicting P1), as this would not mirror economically rational behavior for miners (they would get more fees if they evicted C1, so we must assume they will, if the transaction ever reaches them). This last example really points out the tricky situation we're dealing with. In my opinion, we'd only want to relay 0 sat outputs if we can guarantee that it's never economically profitable to mine them without them getting spent in the same block. Finally, here's a timestamped link to a diagram that shows where 0 sat outputs would be helpful for spacechains (otherwise someone would have to pay the dust up front for countless outputs): https://youtu.be/N2ow4Q34Jeg?t=2556 Cheers, Ruben On Wed, Dec 8, 2021 at 9:35 AM Bastien TEINTURIER <bast...@acinq.fr> wrote: > Hi Jeremy, > > Right now, lightning anchor outputs use a 330 sats amount. Each commitment > transaction has two such outputs, and only one of them is spent to help the > transaction get confirmed, so the other stays there and bloats the utxo > set. > We allow anyone to spend them after a csv of 16 blocks, in the hope that > someone will claim a batch of them when the fees are low and remove them > from the utxo set. However, that trick wouldn't work with 0-value outputs, > as > no-one would ever claim them (doesn't make economical sense). > > We actually need to have two of them to avoid pinning: each participant is > able to spend only one of these outputs while the parent tx is unconfirmed. > I believe N-party protocols would likely need N such outputs (not sure). > > You mention a change to the carve-out rule, can you explain it further? > I believe it would be a necessary step, otherwise 0-value outputs for > CPFP actually seem worse than low-value ones... > > Thanks, > Bastien > > Le mer. 8 déc. 2021 à 02:29, Jeremy via bitcoin-dev < > bitcoin-...@lists.linuxfoundation.org> a écrit : > >> 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> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-...@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
