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
|
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 95F96D0A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Jun 2019 05:50:30 +0000 (UTC)
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 95DAEE5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Jun 2019 05:50:29 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 45Q8pW1X4Wz9sND; Fri, 14 Jun 2019 15:50:27 +1000 (AEST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: "David A. Harding" <dave@dtrt.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <20190609140334.upcqalp24zrecwye@ganymede>
References: <871s0c1tvg.fsf@rustcorp.com.au>
<F252D824-5BE6-4B03-B59D-D40EAFBAEE84@mattcorallo.com>
<871s07nvi1.fsf@rustcorp.com.au>
<20190609140334.upcqalp24zrecwye@ganymede>
Date: Fri, 14 Jun 2019 15:20:17 +0930
Message-ID: <874l4spvfq.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: Fri, 14 Jun 2019 06:25:50 +0000
Subject: Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)
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: Fri, 14 Jun 2019 05:50:30 -0000
"David A. Harding" <dave@dtrt.org> writes:
> On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote:
>> If that's true, I don't think this proposal makes it worse.
>
> Here's a scenario that I think shows it being at least 20x worse.
[ Snip ]
Indeed :(
To be fair, if I have a transaction of median size (250 bytes) and I use
the current estimatefee 2 of '0.00068325' I get to replace is 68 times;
that's $0 for an additional 1GB across all nodes.
So, I don't think the current rules are sufficient. But I understand
the desire not to make things worse. I'll roll in some changes and
re-propose.
> It's already hard for wallet software to determine whether or not its
> transactions have successfully been relayed.
As the deadline approaches, a lightning wallet would RBF with increasing
desparation until it gets into a block. It doesn't really matter *why*
the tx isn't going through, there's nothing else it can do.
> This proposal requires LN
> wallets not only be able to guess where the next-block feerate boundary
> is in other nodes' individual mempools (now and in the future for the
> time it takes the transaction to propagate to ~100% of miners), but it
> possibly requires that under the condition that the LN wallet can't
> guess too low because it might not get another chance for relay in the
> limited time available before contract expiration.
I think you mean any proposal which relies on a deadline? If so, that
bus has already left.
When you see a block you can guess the fees required for the next block.
You need some smoothing to avoid wild spikes, but in practice you can
start this "desperation mode" 10 blocks before your deadline.
Without RBF changes, it needs to assume that it needs to replace a
400kSipa tx @ feerate-for-next-block. With some RBF change, it need
only replace @feerate-for-next-block.
> Considered that way, I worry that these constraints produce a recipe for
> paying extremely high feerates. If that's an actual risk, is that
> actually significantly better than dealing with the existing transaction
> pinning issue where one needs to pay a high total fee in order to evict
> a bunch of junk descendents? Paying lots of fees may not be the optimal
> solution to the problem of having to pay lots of fees. :-)
I don't understand this at all, sorry.
Cheers,
Rusty.
|
