[bisq-network/projects] Migrate Bisq pricenodes from earn.com fee estimation API to our own self-hosted mempool fee estimation API service (#27)

[Chris Beams]

The current situation is pretty extreme, I agree. At time of writing, `estimatesmartfee` is recommending fee rates between 4 and 6 sats/byte:

```
$ bitcoin-cli estimatesmartfee 1 ECONOMICAL
{
  "feerate": 0.00004439,
  "blocks": 2
}
$ bitcoin-cli estimatesmartfee 1 CONSERVATIVE
{
  "feerate": 0.00065398,
  "blocks": 2
}
```

while earn.com is reporting 110 sats/byte as the "fastest and cheapest" rate:

<img width="808" alt="image" src="https://user-images.githubusercontent.com/301810/80946360-29214300-8dee-11ea-9491-a914003efd95.png">

Based on that value, Bisq is currently requiring 94 sats/byte. Clearly way too much with the mempool having been relatively uncongested for many hours.

I see a couple alternative options here to what @wiz proposes.

The first is that we switch from using the earn.com API to using the whatthefee.com API. We considered doing this in late 2017 when @FelixWeis was first standing up the service, but never did it in the end, and fees have been pretty low for the most part since. This change would be the lowest-risk, because it's just swapping out one API for another. No new moving parts to establish, no role duties to modify, etc. Even if we do go ahead with @wiz's proposal, I would still propose that we do this first (and it doesn't have to be whatthefee; any reputable estimation service with a web API would be up for discussion).

For reference, here are https://whatthefee.io/ current estimations:

<img width="369" alt="image" src="https://user-images.githubusercontent.com/301810/80946787-178c6b00-8def-11ea-9eeb-a135e6fe13f4.png">

The second alternative I'd offer is to make running a (possibly pruned) full node a requirement for pricenode operators such that the pricenode can call directly into the full node's `estimatesmartfee` RPC. This would be the most decentralized / censorship resistant approach, as it would eliminate the use of a centralized API altogether. It would require more significant changes to the pricenode code, but nothing too difficult. The main hurdle / burden would be having operators need to run their own node. With that said, it's not so different than @wiz's proposal that we run a federation of mempool.space services. Those operators would need to run full nodes too, and the only thing these would be used for / used by is the pricenodes. @wiz, I'm not sure what advantages mempool.space has over getting estimates via `estimatesmartfee`; can you comment?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/projects/issues/27#issuecomment-623323130
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200504/53411007/attachment-0001.html>