Re: [bitcoin-dev] A fee-bumping model

[Prayank <prayank@tutanota.de>]

[-- 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 --]