It essentially changes the rule to always allow CPFP-ing the commitment as long as there is an output available without any descendants. It changes the commitment from "you always need at least, and exactly, one non-CSV output per party. " to "you always need at least one non-CSV output per party. " I realize these limits are there for a reason though, but I'm wondering if could relax them. Also now that jeremyrubin has expressed problems with the current mempool limits. On Thu, Oct 24, 2019 at 11:25 PM Matt Corallo wrote: > 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 > > wrote: > > > > Matt Corallo > > 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 > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > >