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 7E5CEB1B; Tue, 8 Jan 2019 14:46:49 +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 [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C687976F; Tue, 8 Jan 2019 14:46:48 +0000 (UTC) Received: from [26.129.59.231] (mce2336d0.tmodns.net [208.54.35.206]) by mail.bluematt.me (Postfix) with ESMTPSA id 40BF41201A8; Tue, 8 Jan 2019 14:46:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Matt Corallo X-Mailer: iPhone Mail (16C101) In-Reply-To: <87wonfem03.fsf@rustcorp.com.au> Date: Tue, 8 Jan 2019 09:46:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <878t163qzi.fsf@rustcorp.com.au> <725fc55a-6263-a9fc-74a5-1017cb1cc885@mattcorallo.com> <87wonfem03.fsf@rustcorp.com.au> To: Rusty Russell X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE 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 14:46:49 -0000 I responded to a few things in-line before realizing I think we're out of sy= nc on what this alternative proposal actually implies. In my understanding i= s it, it does *not* imply that you are guaranteed the ability to RBF as fees= change. The previous problem is still there - your counterparty can announc= e a bogus package and leave you unable to add a new transaction to it, the d= ifference being it may be significantly more expensive to do so. If it were t= he case the you could RBF after the fact, I would likely agree with you. > On Jan 8, 2019, at 00:50, Rusty Russell wrote: >=20 > Matt Corallo writes: >> Ultimately, defining a "near the top of the mempool" criteria is fraught=20= >> with issues. While it's probably OK for the original problem (large=20 >> batched transactions where you don't want a single counterparty to=20 >> prevent confirmation), lightning's requirements are very different.=20 >> Instead is wanting a high probability that the transaction in question=20= >> confirms "soon", we need certainty that it will confirm by some deadline.= >=20 > I don't think it's different, in practice. I strongly disagree. If you're someone sending a batched payment, 5% chance i= t takes 13 blocks is perfectly acceptable. If you're a lightning operator, t= hat quickly turns into "5% chance, or 35% chance if your counterparty is mal= icious and knows more about the market structure than you". Eg in the past i= t's been the case that transaction volume would spike every day at the same t= ime when Bitmex proceed a flood of withdrawals all at once in separate trans= actions. Worse, it's probably still the case that, in case is sudden market m= ovement, transaction volume can spike while people arb exchanges and move co= ins into exchanges to sell. >> Thus, even if you imagine a steady-state mempool growth, unless the=20 >> "near the top of the mempool" criteria is "near the top of the next=20 >> block" (which is obviously *not* incentive-compatible) >=20 > 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 hol= d up. If you assume a steady flow of new transactions and one or two blocks c= ome 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, t= his is a relatively likely scenario. > 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. >=20 > 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. >=20 > But I think whatever's simplest to implement should win, and I'm not in > a position to judge that accurately. >=20 > Thanks, > Rusty.