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 E127EBD8; Mon, 7 Jan 2019 15:18:55 +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 E6FEB7FB; Mon, 7 Jan 2019 15:18:54 +0000 (UTC) Received: from [10.233.42.100] (gw.vpn.bluematt.me [144.217.106.88]) by mail.bluematt.me (Postfix) with ESMTPSA id 070551201A8; Mon, 7 Jan 2019 15:18:52 +0000 (UTC) From: Matt Corallo To: Rusty Russell References: <878t163qzi.fsf@rustcorp.com.au> Message-ID: <725fc55a-6263-a9fc-74a5-1017cb1cc885@mattcorallo.com> Date: Mon, 7 Jan 2019 15:18:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <878t163qzi.fsf@rustcorp.com.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 X-Mailman-Approved-At: Mon, 07 Jan 2019 15:36:49 +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: Mon, 07 Jan 2019 15:18:56 -0000 Sorry for the late reply. Hmm, I included the old RBF-pinning proposal as a comparison. Personally, I find it both less clean and less convincingly secure. 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. 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), its easy to see how the package would fail to confirm within a handful of blocks given block time variance. Giving up the ability to RBF/CPFP more than once in case the fee moves away from us seems to be a rather significant restriction. THe original proposal is somewhat of a hack, but its a hack on the boundary condition where packages meet our local anti-DoS rules in violation of the "incentive compatible" goal anyway (essentially, though miners also care about anti-DoS). This proposal is very different and, similar to how it doesn't work if blocks randomly come in a bit slow for an hour or two, isn't incentive compatible if blocks come in a bit fast for an hour or two, as all of a sudden that "near the top of the mempool" criteria makes no sense and you should have accepted the new transaction(s). As for package relay, indeed, we can probably do soemthing simpler for this specific case, but itdepends on what the scope of that design is. Suhas opened an issue to try to scope it out a bit more at https://github.com/bitcoin/bitcoin/issues/14895 Matt > On Dec 3, 2018, at 22:33, Rusty Russell wrote: > > Matt Corallo writes: >> As an alternative proposal, at various points there have been >> discussions around solving the "RBF-pinning" problem by allowing >> transactors to mark their transactions as "likely-to-be-RBF'ed", which >> could enable a relay policy where children of such transactions would be >> rejected unless the resulting package would be "near the top of the >> mempool". This would theoretically imply such attacks are not possible >> to pull off consistently, as any "transaction-delaying" channel >> participant will have to place the package containing A at an effective >> feerate which makes confirmation to occur soon with some likelihood. It >> is, however, possible to pull off this attack with low probability in >> case of feerate spikes right after broadcast. > > I like this idea. > > Firstly, it's incentive-compatible[1]: assuming blocks are full, miners > should always take a higher feerate tx if that tx would be in the > current block and the replaced txs would not.[2] > > Secondly, it reduces the problem that the current lightning proposal > adds to the UTXO set with two anyone-can-spend txs for 1000 satoshis, > which might be too small to cleanup later. This rule would allow a > simple single P2WSH(OP_TRUE) output, or, with IsStandard changed, > a literal OP_TRUE. > >> Note that this clearly relies on some form of package relay, which comes >> with its own challenges, but I'll start a separate thread on that. > > Could be done client-side, right? Do a quick check if this is above 250 > satoshi per kweight but below minrelayfee, put it in a side-cache with a > 60 second timeout sweep. If something comes in which depends on it > which is above minrelayfee, then process them as a pair[3]. > > Cheers, > Rusty. > [1] Miners have generally been happy with Defaults Which Are Good For The > Network, but I feel a long term development aim should to be reduce > such cases to smaller and smaller corners. > [2] The actual condition is subtler, but this is a clear subset AFAICT. > [3] For Lightning, we don't care about child-pays-for-grandparent etc.