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
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
|
Return-Path: <prayank@tutanota.de>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id B44F3C000A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Nov 2021 01:47:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 9479A4047A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Nov 2021 01:47:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=tutanota.de
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 5VF3nr2l3zdC
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Nov 2021 01:47:34 +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 smtp4.osuosl.org (Postfix) with ESMTPS id D53E740478
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Nov 2021 01:47:33 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
by w1.tutanota.de (Postfix) with ESMTP id B5C69FBF4F4;
Tue, 30 Nov 2021 01:47:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1638236851;
s=s1; d=tutanota.de;
h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender;
bh=Y376EuTWMnVrSP52k4DWEA6QglNFGNrw0ZTtMVrHmRM=;
b=CqA9jsdTiqTgJOx1ezmqAg5HTzbbaZzx0gYTsOcvXtK1upNDYXHDqmDFD02STkIe
qSfBfx5WQsxZD4Uu7IwCSqkAXg00CbmwiyNRjKjBvIaunEjCE8pK1lQzt1lHsw4SJ2/
w4GQuTfJgwQO4kRX6y/LwCjElO7wAtHZLrJQB5pAfF2G1Bdf6WVM3JRFEGFsaIja0c7
vhzMnpSQEY0XHA5o92cETzZdE/qIJuzM6/r/aAla0YIq28GdwJnCMLel9vvhBW/QH15
ku6Rnljm0v99LDl3jxWu6biCQHq+1TCSlBAREOCvWz8XrRI/uxIryA64kyKZr9m/TMj
2c99rH+Glg==
Date: Tue, 30 Nov 2021 02:47:31 +0100 (CET)
From: Prayank <prayank@tutanota.de>
To: darosior@protonmail.com
Message-ID: <MpiWcV7--3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_227143_165604432.1638236851728"
X-Mailman-Approved-At: Tue, 30 Nov 2021 09:14:39 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A fee-bumping model
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: Tue, 30 Nov 2021 01:47:35 -0000
------=_Part_227143_165604432.1638236851728
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Good morning darosior,
Subject of the email looks interesting and I have few comments on the thing=
s shared:
> The part of Revault we are interested in for this study is the delegation=
process, and more specifically the application of spending policies by net=
work monitors (watchtowers). Participants regularly exchange the Cancel tra=
nsaction signatures for each deposit, sharing the signatures with the watch=
towers they operate.Watchtowers can enforce spending policies (say, can't U=
nvault outside of business hours) by having the Cancel transaction be confi=
rmed before the expiration of the timelock.
What are the privacy issues associated with such watchtowers?
> ## 4. We are still betting on future feerate
The problem is still missing one more constraint. "Ensuring confirmation at=
any time" involves ensuring confirmation at *any* feerate, which you *cann=
ot* do.
Agree
> historical feerate: We currently use the maximum of the 95th percentiles =
over 90-days windows over historical block chain
feerates.
Disagree that fee rates used in past should matter.
> Apart from judging that 500sat/vb is probably more reasonable than 10sat/=
vbyte, this unfortunately sounds pretty much crystal-ball-driven.
Agree
> ## 7. Bumping and re-bumping
First of all, when to fee-bump? At fixed time intervals? At each block conn=
ection? It sounds like, given a large enough timelock, you could try to gre=
ed by "trying your luck" at a lower feerate and only re-bumping every N blo=
cks. You would then start aggressively bumping at every block after M block=
s have passed.
Agree
> You probably want to base your estimates on `estimatesmartfee`
Disagree. `estimatesmartfee` RPC has few issues: https://github.com/bitcoin=
/bitcoin/pull/22722#issuecomment-901907447
> ## 9. Insurances
there is definitely room for an insurance market.
Agree. I think its possible using discreet log contracts with some trust as=
sumptions and use of multi oracles.
I had one idea about creating insurance project for LGBTQ community in Indi=
a as they don't have enough options like others. Have shared the details he=
re:=C2=A0https://gist.github.com/prayank23/f30ab1ab68bffe6bcb2ceacec599cd36=
=20
As final point, I guess you already know about this presentation by Jack Ma=
llers in which he has described how we could create derivatives for users t=
o hedge fees: https://youtu.be/rBCG0btUlTw
--=20
Prayank
A3B1 E430 2298 178F
------=_Part_227143_165604432.1638236851728
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>Good morning darosior,<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Subject of the email looks interesting and I have few comments on=
the things shared:<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
> The part of Revault we are interested in for this study is the delegat=
ion process, and more specifically the application of spending policies by =
network monitors (watchtowers). Participants regularly exchange the Cancel =
transaction signatures for each deposit, sharing the signatures with the wa=
tchtowers they operate.Watchtowers can enforce spending policies (say, can'=
t Unvault outside of business hours) by having the Cancel transaction be co=
nfirmed before the expiration of the timelock.<br></div><div dir=3D"auto"><=
br></div><div dir=3D"auto">What are the privacy issues associated with such=
watchtowers?<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">> #=
# 4. We are still betting on future feerate<br></div><div dir=3D"auto">The =
problem is still missing one more constraint. "Ensuring confirmation at any=
time" involves ensuring confirmation at *any* feerate, which you *cannot* =
do.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Agree<br></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">> historical feerate: We cu=
rrently use the maximum of the 95th percentiles over 90-days windows over h=
istorical block chain<br></div><div dir=3D"auto">feerates.<br></div><div di=
r=3D"auto"><br></div><div dir=3D"auto">Disagree that fee rates used in past=
should matter.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">>=
Apart from judging that 500sat/vb is probably more reasonable than 10sat/v=
byte, this unfortunately sounds pretty much crystal-ball-driven.<br></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Agree<br></div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">> ## 7. Bumping and re-bumping<br></div><=
div dir=3D"auto">First of all, when to fee-bump? At fixed time intervals? A=
t each block connection? It sounds like, given a large enough timelock, you=
could try to greed by "trying your luck" at a lower feerate and only re-bu=
mping every N blocks. You would then start aggressively bumping at every bl=
ock after M blocks have passed.<br></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">Agree<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&g=
t; You probably want to base your estimates on `estimatesmartfee`<br></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">Disagree. `estimatesmartfee` =
RPC has few issues: https://github.com/bitcoin/bitcoin/pull/22722#issuecomm=
ent-901907447<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">> #=
# 9. Insurances<br></div><div dir=3D"auto">there is definitely room for an =
insurance market.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Ag=
ree. I think its possible using discreet log contracts with some trust assu=
mptions and use of multi oracles.<br></div><div dir=3D"auto"><br></div><div=
dir=3D"auto">I had one idea about creating insurance project for LGBTQ com=
munity in India as they don't have enough options like others. Have shared =
the details here: https://gist.github.com/prayank23/f30ab1ab68bffe6bcb=
2ceacec599cd36 </div><div><br></div><div dir=3D"auto">As final point, I gue=
ss you already know about this presentation by Jack Mallers in which he has=
described how we could create derivatives for users to hedge fees: https:/=
/youtu.be/rBCG0btUlTw<br></div><div><br></div><div dir=3D"auto">-- <br></di=
v><div>Prayank<br></div><div><br></div><div dir=3D"auto">A3B1 E430 2298 178=
F<br></div> </body>
</html>
------=_Part_227143_165604432.1638236851728--
|