From mboxrd@z Thu Jan 1 00:00:00 1970
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--