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
129
130
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8E479C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 May 2021 04:02:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 673B540F9C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 May 2021 04:02:19 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.4
X-Spam-Level:
X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5
tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-0.7,
RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id A6JrO6gSnkgy
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 May 2021 04:02:17 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch
[185.70.40.141])
by smtp4.osuosl.org (Postfix) with ESMTPS id 80A1140F9B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 May 2021 04:02:17 +0000 (UTC)
Date: Mon, 03 May 2021 04:02:07 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1620014533;
bh=QYMf+TS5T5NfpEFaZEZALER3QTf7IVrys7RVpsjxOY8=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=Op1NI6Z7Oqwl0bQtwQxMXImCNCPfbKqDzJJkyWS2LHLeP33UkG/ea7EinYdv4j3b7
yxMxBL2RnC2SY9AYPpU2wVhFuFKJkFES3+kbBKIR0DR1ErkZ+A6rCTBXpvAllZnPn/
gvceImYTKPXhV5Ni9mEhlxHU4wp8/sQsNmPGAlLo=
To: Prayank <prayank@tutanota.de>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <FD5iXWFzOy1VYbksNsxzhBg-NGiiedTutilM0qpo4jqU15BAjhaZ4hQSqUTJATW8Fjk2kOzKPoGNgZVRIppZlHf1d_7wcYOu9vZIEZ1-x9U=@protonmail.com>
In-Reply-To: <MZZT0_o--3-2@tutanota.de>
References: <MZZT0_o--3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Fee estimates and RBF
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 03 May 2021 04:02:19 -0000
Good morning Prayank,
I believe a "true" full-RBF wallet should be what every onchain wallet aspi=
res to.
However, I think a lot of the effort necessary here has to do with sheer en=
gineering issues.
For example, if you think "RBF does not exist", you can do things like:
* Spend an unconfirmed input from a third party.
* This is not actually safe since an unconfirmed tx might have a conflict=
ing transaction get confirmed, but a lot of onchain wallets support this fo=
r non-RBF unconfirmed inputs because 99.9% of the time this never happens.
* When you spend from a (confirmed or unconfirmed) input, delete it from yo=
ur db forever (because you do not have to worry about alternate transaction=
s spending the same input).
* This simplifies db design, you do not have to keep track of states like=
"has been spent but tx is not confirmed yet", "has two different alternate=
transactions spending it that have not confirmed", "is on a transaction th=
at is not confirmed and therefore this input might disappear completely" et=
c.
In particular, if we want a "true" full-RBF wallet:
* Suppose the user wants to spend some amount to address A.
* The user imposes a limit on up to how much to spend on fees to have thi=
s spend happen.
* The wallet optimistically creates a low-fee send transaction.
* After some time, the wallet bumps up the fee by creating a new transactio=
n.
* The wallet keeps bumping up, up to the designated limit, the longer the=
transaction is not confirmed.
Of note is that there is a *race condition* in the above case.
When the wallet is bumping up and constructing a new transaction with highe=
r fee, a miner could find a new block that has the old transaction with low=
er fee.
Now consider the subsequent user story.
* After some time, the user wants to spend another amount to address B.
* Again the user imposes a limit on how much to spend on fees to have thi=
s spend happen.
* The wallet RBFs the existing transaction to include the spend to address =
B.
Again, a race condition can occur --- while the wallet is feebumping a new =
transaction that includes the new output, a random miner can find a new blo=
ck that includes the old transaction.
Thus, the wallet really needs to keep track of any "pending spends" and cor=
relate them with actual transactions.
Further, of course it is convenient to be able to spend money even while it=
is unconfirmed.
But the sender of the unconfirmed input might be using the same software as=
this wallet as well, meaning that the actual transaction output might chan=
ge as the original spender keeps fee-bumping it over time.
I confess I have not been thinking of this as well as I should have.
Regards,
ZmnSCPxj
|
