From: Prayank <prayank@tutanota•de>
To: darosior@protonmail•com
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A fee-bumping model
Date: Tue, 30 Nov 2021 02:47:31 +0100 (CET) [thread overview]
Message-ID: <MpiWcV7--3-2@tutanota.de> (raw)
[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]
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 delegation 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 watchtowers they operate.Watchtowers can enforce spending policies (say, can't Unvault outside of business hours) by having the Cancel transaction be confirmed 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 *cannot* 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 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-bumping every N blocks. You would then start aggressively bumping at every block after M blocks 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 assumptions and use of multi oracles.
I had one idea about creating insurance project for LGBTQ community in India as they don't have enough options like others. Have shared the details here: https://gist.github.com/prayank23/f30ab1ab68bffe6bcb2ceacec599cd36
As final point, I guess 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 178F
[-- Attachment #2: Type: text/html, Size: 3588 bytes --]
next reply other threads:[~2021-11-30 1:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-30 1:47 Prayank [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-11-29 14:27 darosior
2021-11-30 1:43 ` Antoine Riard
2021-11-30 15:19 ` darosior
2021-12-07 17:24 ` Gloria Zhao
2021-12-08 14:51 ` darosior
2021-12-09 0:55 ` Antoine Riard
2021-12-08 23:56 ` Antoine Riard
2021-12-09 13:50 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MpiWcV7--3-2@tutanota.de \
--to=prayank@tutanota$(echo .)de \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=darosior@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox