From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7E0DBE7C; Thu, 24 Oct 2019 21:25:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [69.59.18.99]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BB0D989D; Thu, 24 Oct 2019 21:25:31 +0000 (UTC) Received: from [IPv6:2620:6e:a000:233::100] (unknown [IPv6:2620:6e:a000:233::100]) by mail.bluematt.me (Postfix) with ESMTPSA id 26C26E1053; Thu, 24 Oct 2019 21:25:21 +0000 (UTC) To: =?UTF-8?Q?Johan_Tor=c3=a5s_Halseth?= , Rusty Russell References: <878t163qzi.fsf@rustcorp.com.au> <725fc55a-6263-a9fc-74a5-1017cb1cc885@mattcorallo.com> <87wonfem03.fsf@rustcorp.com.au> <87zhr0gvw0.fsf@rustcorp.com.au> From: Matt Corallo Message-ID: <83915e8a-f49a-8233-0389-934c189f770c@mattcorallo.com> Date: Thu, 24 Oct 2019 21:25:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion , lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 21:25:32 -0000 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 >