From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B44F3C000A for ; 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 ; 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 ; 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 ; 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 To: darosior@protonmail.com Message-ID: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Good morning darosior,

Subject of the email looks interesting and I have few comments on= the things shared:

= > 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>
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 *cannot* = do.

Agree
<= 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
feerates.

Disagree that fee rates used in past= should matter.

>= Apart from judging that 500sat/vb is probably more reasonable than 10sat/v= byte, this unfortunately sounds pretty much crystal-ball-driven.
<= div dir=3D"auto">
Agree

> ## 7. Bumping and re-bumping
<= 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.

Agree

&g= t; You probably want to base your estimates on `estimatesmartfee`
=

Disagree. `estimatesmartfee` = RPC has few issues: https://github.com/bitcoin/bitcoin/pull/22722#issuecomm= ent-901907447

> #= # 9. Insurances
there is definitely room for an = insurance market.

Ag= ree. I think its possible using discreet log contracts with some trust assu= mptions and use of multi oracles.

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

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

--
Prayank

A3B1 E430 2298 178= F
------=_Part_227143_165604432.1638236851728--