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 71D67D4C; Tue, 8 Jan 2019 05:50:48 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (ozlabs.org [203.11.71.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8AF94764; Tue, 8 Jan 2019 05:50:46 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 43YhFJ3f04z9sMM; Tue, 8 Jan 2019 16:50:44 +1100 (AEDT) From: Rusty Russell To: Matt Corallo In-Reply-To: <725fc55a-6263-a9fc-74a5-1017cb1cc885@mattcorallo.com> References: <878t163qzi.fsf@rustcorp.com.au> <725fc55a-6263-a9fc-74a5-1017cb1cc885@mattcorallo.com> Date: Tue, 08 Jan 2019 16:20:20 +1030 Message-ID: <87wonfem03.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 08 Jan 2019 17:11:14 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org, lightning-dev@lists.linuxfoundation.org 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: Tue, 08 Jan 2019 05:50:49 -0000 Matt Corallo writes: > Ultimately, defining a "near the top of the mempool" criteria is fraught > with issues. While it's probably OK for the original problem (large > batched transactions where you don't want a single counterparty to > prevent confirmation), lightning's requirements are very different. > Instead is wanting a high probability that the transaction in question > confirms "soon", we need certainty that it will confirm by some deadline. I don't think it's different, in practice. > 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? The attack against this is to make a 100k package which would just get into this "top", then push it out with a separate tx at slightly higher fee, then repeat. Of course, timing makes that hard to get right, and you're paying real fees for it too. Sure, an attacker can make you pay next-block high fees, but it's still better than our current "*always* overpay and hope!", and you can always decide at the time based on whether the expiring HTLC(s) are worth it. But I think whatever's simplest to implement should win, and I'm not in a position to judge that accurately. Thanks, Rusty.