diff options
| author | Rusty Russell <rusty@rustcorp.com.au> | 2019-01-08 16:20:20 +1030 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-01-08 05:50:48 +0000 |
| commit | 8d2e03976837586c197e577791a073f8b5582946 (patch) | |
| tree | e352519ca428cc6f01577e2e0a9b9590615c6b6e | |
| parent | e1680c32b1932c90fb72346477afae77566e3e8e (diff) | |
| download | pi-bitcoindev-8d2e03976837586c197e577791a073f8b5582946.tar.gz pi-bitcoindev-8d2e03976837586c197e577791a073f8b5582946.zip | |
Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)
| -rw-r--r-- | 43/ae64ba3b7783d47224a846f1fd96cd02e783d3 | 78 |
1 files changed, 78 insertions, 0 deletions
diff --git a/43/ae64ba3b7783d47224a846f1fd96cd02e783d3 b/43/ae64ba3b7783d47224a846f1fd96cd02e783d3 new file mode 100644 index 000000000..7e068291d --- /dev/null +++ b/43/ae64ba3b7783d47224a846f1fd96cd02e783d3 @@ -0,0 +1,78 @@ +Return-Path: <rusty@ozlabs.org> +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 <rusty@rustcorp.com.au> +To: Matt Corallo <lf-lists@mattcorallo.com> +In-Reply-To: <725fc55a-6263-a9fc-74a5-1017cb1cc885@mattcorallo.com> +References: <c3f68b73-84c6-7428-4bf6-b47802141392@mattcorallo.com> + <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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 08 Jan 2019 05:50:49 -0000 + +Matt Corallo <lf-lists@mattcorallo.com> 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. + |