1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
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.
|
