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
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
Return-Path: <lf-lists@mattcorallo.com>
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 <lf-lists@mattcorallo.com>
To: Rusty Russell <rusty@rustcorp.com.au>
References: <c3f68b73-84c6-7428-4bf6-b47802141392@mattcorallo.com>
<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 <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: 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 <rusty@rustcorp.com.au> wrote:
>
> Matt Corallo <lf-lists@mattcorallo.com> 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.
|
