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
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
Return-Path: <prayank@tutanota.de>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 17879C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 30 Apr 2021 20:28:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 023D26F9DC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 30 Apr 2021 20:28:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: YES
X-Spam-Score: 6.688
X-Spam-Level: ******
X-Spam-Status: Yes, score=6.688 tagged_above=-999 required=5
tests=[BAYES_50=0.8, BITCOIN_IMGUR=3.087, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
HOSTED_IMG_MULTI_PUB_01=3, HTML_MESSAGE=0.001,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=tutanota.de
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 5uTPh0-ptVBD
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 30 Apr 2021 20:28:45 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162])
by smtp3.osuosl.org (Postfix) with ESMTPS id C11A760643
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 30 Apr 2021 20:28:44 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
by w1.tutanota.de (Postfix) with ESMTP id 9DCE2FBF4E1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 30 Apr 2021 20:28:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1619814522;
s=s1; d=tutanota.de;
h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender;
bh=3wxisNpAj+Qbc6oWS+GoMBZ3msm1krRHyMshodcds74=;
b=S9IncWCSMDbg+6UEz8MoM0e6GLvLVrQMRsM1tWFAKvzgmlT90hAbZHQYqQahI17u
9nqD7kjaPo0oFydGzPx2Uhlp3kGeYR7x5g4CJY7gCf6yt+g/P1LAMp8X55FHd5RxAYa
zP1DN8ExhMGlZFGwh5fxLOt+9SFLVoy+qlkMyA2K64reEtmvwR1ij7Mzxg7JlQ1xl1U
jUqPs13zzY04fi0KjVuQhJKHtqNWuYSAZfBKCxSPEOdniMC/jz32QgxRkEPzs2fRfcp
1ehaBqmQG8hb+sXa1j3b/HsYtzXMptZYr6vIOyTnDwx1hUeUsnmQw7nwPAiC7FQbkep
b66fca9Pxw==
Date: Fri, 30 Apr 2021 22:28:42 +0200 (CEST)
From: Prayank <prayank@tutanota.de>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <MZZT0_o--3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_37866_860625817.1619814522630"
X-Mailman-Approved-At: Fri, 30 Apr 2021 21:40:05 +0000
Subject: [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: Fri, 30 Apr 2021 20:28:46 -0000
------=_Part_37866_860625817.1619814522630
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hello World,=20
I hope everyone is doing okay. Things are not good in India and even I was =
tested covid positive few days back. Recovered and feeling better now. Hopi=
ng everything gets back to normal soon.
There are different estimations used in wallets, explorers and other Bitcoi=
n projects. For example: `estimatesmartfee` in Bitcoin Core (One of the imp=
lementation for Bitcoin which is used more but not official as there is not=
hing official in Bitcoin).=C2=A0 Are different estimations misleading and a=
ffect the way fees are used in Bitcoin transactions? Will it be better if w=
e just share mempool stats and user can decide the fee rate accordingly?
If I compare this with BTCUSD orderbook on any exchange, are we trying to e=
stimate at what price buy order will get filled in certain time? Does that =
make sense?
Mempool Stats: https://i.imgur.com/r4XKk2p.png
BTCUSD Orderbook: https://i.imgur.com/ylGVHJB.png
I consider it misleading because lot of users think a transaction with fee =
rate 1-5 sat/vByte will be included in 1 week or maybe a transaction with X=
sat/VByte will be included in Y time which is not true. Users can decide t=
he fee rate and can do bidding, transaction will be included based on deman=
d, supply and miners.
Will it be better if the wallets used this approach?
1.Show mempool stats
2.Leave the fee rate for user to decide
3.RBF every transaction and follow different algorithms for automated biddi=
ng
A basic algorithm for automated bidding can be: https://i.stack.imgur.com/1=
SlPv.png
Such RBF algos can be helpful for users when Bitcoin wallets are open in ba=
ckground. Maybe it will work better for mobile wallets in which you can see=
a notification every time transaction is replaced with a new fee rate auto=
matically.
I wanted to know what others think about this approach of creating and usin=
g different RBF algos instead of predicting something that is difficult or =
doesn't make sense. Also if there was a way we could achieve this even if t=
he user goes offline. For example: Alice broadcasts Tx1 with 1 sat/vByte, i=
ts replaced with Tx2 (2 sat/vByte) after 2 blocks because Tx1 was not confi=
rmed. Alice decides to shut down her system or switch off mobile or mobile =
data. Tx2 is still not confirmed after another 2 blocks but it has some inf=
ormation as one OP_RETURN output which is used by Bitcoin nodes that see th=
is transaction in the mempool. Bob's node use this information to replace t=
he transaction with Tx3 and use fee rate 3 sat/vByte.
--
Prayank
------=_Part_37866_860625817.1619814522630
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
</head>
<body>
<div>Hello World, <br></div><div><br></div><div>I hope everyone is doing ok=
ay. Things are not good in India and even I was tested covid positive few d=
ays back. Recovered and feeling better now. Hoping everything gets back to =
normal soon.<br></div><div><br></div><div>There are different estimations u=
sed in wallets, explorers and other Bitcoin projects. For example: `estimat=
esmartfee` in Bitcoin Core (One of the implementation for Bitcoin which is =
used more but not official as there is nothing official in Bitcoin). =
Are different estimations misleading and affect the way fees are used in Bi=
tcoin transactions? Will it be better if we just share mempool stats and us=
er can decide the fee rate accordingly?<br></div><div><br></div><div>If I c=
ompare this with BTCUSD orderbook on any exchange, are we trying to estimat=
e at what price buy order will get filled in certain time? Does that make s=
ense?<br></div><div><br></div><div>Mempool Stats: <a href=3D"https://i.imgu=
r.com/r4XKk2p.png">https://i.imgur.com/r4XKk2p.png</a><br></div><div>BTCUSD=
Orderbook: <a href=3D"https://i.imgur.com/ylGVHJB.png">https://i.imgur.com=
/ylGVHJB.png</a><br></div><div><br></div><div>I consider it misleading beca=
use lot of users think a transaction with fee rate 1-5 sat/vByte will be in=
cluded in 1 week or maybe a transaction with X sat/VByte will be included i=
n Y time which is not true. Users can decide the fee rate and can do biddin=
g, transaction will be included based on demand, supply and miners.<br></di=
v><div><br></div><div>Will it be better if the wallets used this approach?<=
br></div><div>1.Show mempool stats<br></div><div>2.Leave the fee rate for u=
ser to decide<br></div><div>3.RBF every transaction and follow different al=
gorithms for automated bidding<br></div><div><br></div><div>A basic algorit=
hm for automated bidding can be: <a href=3D"https://i.stack.imgur.com/1SlPv=
.png">https://i.stack.imgur.com/1SlPv.png</a><br></div><div><br></div><div>=
Such RBF algos can be helpful for users when Bitcoin wallets are open in ba=
ckground. Maybe it will work better for mobile wallets in which you can see=
a notification every time transaction is replaced with a new fee rate auto=
matically.<br></div><div><br></div><div>I wanted to know what others think =
about this approach of creating and using different RBF algos instead of pr=
edicting something that is difficult or doesn't make sense. Also if there w=
as a way we could achieve this even if the user goes offline. For example: =
Alice broadcasts Tx1 with 1 sat/vByte, its replaced with Tx2 (2 sat/vByte) =
after 2 blocks because Tx1 was not confirmed. Alice decides to shut down he=
r system or switch off mobile or mobile data. Tx2 is still not confirmed af=
ter another 2 blocks but it has some information as one OP_RETURN output wh=
ich is used by Bitcoin nodes that see this transaction in the mempool. Bob'=
s node use this information to replace the transaction with Tx3 and use fee=
rate 3 sat/vByte.<br></div><div><br></div><div>--<br></div><div>Prayank<br=
></div><div><br></div> </body>
</html>
------=_Part_37866_860625817.1619814522630--
|
