I may be missing something, but I'm not sure how this changes anything? If you have a commitment transaction, you always need at least, and exactly, one non-CSV output per party. The fact that there is a size limitation on the transaction that spends for carve-out purposes only effects how many other inputs/outputs you can add, but somehow I doubt its ever going to be a large enough number to matter.
Matt On 10/24/19 1:49 PM, Johan Torås Halseth wrote: > Reviving this old thread now that the recently released RC for bitcoind > 0.19 includes the above mentioned carve-out rule. > > In an attempt to pave the way for more robust CPFP of on-chain contracts > (Lightning commitment transactions), the carve-out rule was added in > https://github.com/bitcoin/bitcoin/pull/15681. However, having worked on > an implementation of a new commitment format for utilizing the Bring > Your Own Fees strategy using CPFP, I’m wondering if the special case > rule should have been relaxed a bit, to avoid the need for adding a 1 > CSV to all outputs (in case of Lightning this means HTLC scripts would > need to be changed to add the CSV delay). > > Instead, what about letting the rule be > > The last transaction which is added to a package of dependent > transactions in the mempool must: > * Have no more than one unconfirmed parent. > > This would of course allow adding a large transaction to each output of > the unconfirmed parent, which in effect would allow an attacker to > exceed the MAX_PACKAGE_VIRTUAL_SIZE limit in some cases. However, is > this a problem with the current mempool acceptance code in bitcoind? I > would imagine evicting transactions based on feerate when the max > mempool size is met handles this, but I’m asking since it seems like > there has been several changes to the acceptance code and eviction > policy since the limit was first introduced. > > - Johan > > > On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell <ru...@rustcorp.com.au > <mailto:ru...@rustcorp.com.au>> wrote: > > Matt Corallo <lf-li...@mattcorallo.com > <mailto:lf-li...@mattcorallo.com>> writes: > >>> Thus, even if you imagine a steady-state mempool growth, unless the > >>> "near the top of the mempool" criteria is "near the top of the next > >>> block" (which is obviously *not* incentive-compatible) > >> > >> I was defining "top of mempool" as "in the first 4 MSipa", ie. next > >> block, and assumed you'd only allow RBF if the old package wasn't > in the > >> top and the replacement would be. That seems incentive > compatible; more > >> than the current scheme? > > > > My point was, because of block time variance, even that criteria > doesn't hold up. If you assume a steady flow of new transactions and > one or two blocks come in "late", suddenly "top 4MWeight" isn't > likely to get confirmed until a few blocks come in "early". Given > block variance within a 12 block window, this is a relatively likely > scenario. > > [ Digging through old mail. ] > > Doesn't really matter. Lightning close algorithm would be: > > 1. Give bitcoind unileratal close. > 2. Ask bitcoind what current expidited fee is (or survey your mempool). > 3. Give bitcoind child "push" tx at that total feerate. > 4. If next block doesn't contain unilateral close tx, goto 2. > > In this case, if you allow a simpified RBF where 'you can replace if > 1. feerate is higher, 2. new tx is in first 4Msipa of mempool, 3. > old tx isnt', > it works. > > It allows someone 100k of free tx spam, sure. But it's simple. > > We could further restrict it by marking the unilateral close somehow to > say "gonna be pushed" and further limiting the child tx weight (say, > 5kSipa?) in that case. > > Cheers, > Rusty. > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > <mailto: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
