Market price feed aggregator about proposals HOT 12 CLOSED

This seems like an important issue to fix, as well as the mempool fees estimator API from https://mempool.space/api/v1/fees/recommended

from proposals.

Always good to remove single points of failure. I'd say go for it. I always like to compare BitcoinAverage to say CoinMarketCap when outputting data. Serveral months ago there was about a $100 difference but recently they are fairly close to each other.

from proposals.

The idea of having many sources for data averaging seems an excellent idea, just as long as the posted prices of those exchanges are not pulled too from exterior sources. In other words, knowing how the aggregated price is obtained greatly benefits the averaging reliability.

from proposals.

I see at least 2 ways to achieve such a service (… with not the same cost).
How much do you think the bounty would/could be for that ?

from proposals.

@HarryMacfinned
Hm.... its always hard to estimate. Best would be to start with a detail concept/tech spec and see that as first bounty. If that gets approved its easier to estimate effort.

For a tech spec I would agree to about 500-1000 BSQ.
But its the stakeholders who vote on it in the compensation request who decide at the end. But maybe others can post their opinions so its easier to get an idea....

from proposals.

I've been slow in responding to this proposal, my apologies.

I would not want to see a new service developed. I'd want to see capabilities added to the existing bisq-pricenode service (one of the options @ManfredKarrer suggests above).

It's true that our reliance on BitcoinAverage and the other services are technically single points of failure and it would definitely be good to eliminate that, but I also don't see it as terribly high priority. If something catastrophic happened (BitcoinAverage goes down, gets hacked, whatever), we could mitigate it and redeploy a patched pricenode within a day.

In any case, I would happily work with an experienced Java developer to show them around the pricenode app, find the right approach to implementing these changes, and then let them on their own to implement a PR.

This feels more like a bounty issue for the pricenode than a net new proposal per se. We've gotten very little feedback on this proposal, and I wonder if that's why. It's kind of "down in the weeds". Anyway, even though per the proposals process this should have been closed one way or another a long time ago (my bad), I'll leave this open a bit longer to get any additional feedback.

from proposals.

To move that as an issue is ok for me. Maybe good to link to the rough overview. I agree that it is not super high priority but a weak point we should try to get fixed mid term, as well as it might be a good starter task for a new dev.

from proposals.

I have also been slow on this proposal and I apologize for that.
I did not at all forget this task and it is still in my objectives, but since I'm already slow on the rest (and occupied with other tasks) it gets delayed in my agenda. (Hot days have also a bad effect on my productivity).
imo it doesn't matter the task being here or there, the point is that we do not forget it.

I'm a bit technically curious about how we could redeploy a patched pricenode within a day ?

If this is indeed doable so rapidly ... then it seems the present proposal has little reason to exist.

from proposals.

@HarryMacfinned
I think a quick fix if for instance BitcoinAverage would be out of service would be to request the price from another exchange. It is just simple service request and then the data has to put in our json format. A more complex solution for having an own average would probably require more time. The bad thing in such an incident is that trader will likely complain as their % based offers might get executed to other prices as they expected.

from proposals.

It looks to me that this would be easy to pick up by a new developer, as there is no need to know about Bisq codebase.

from proposals.

It looks to me that this would be easy to pick up by a new developer, as there is no need to know about Bisq codebase.

Agree. But we need to be careful to be on the conservative side. We had often troubles when fees where going up fast the fee estimations did not reflect that good enough and led to stuck txs. So if anyone works on that would be good to check past behaviour and if we use a new model to be careful with fading in new model.

from proposals.

Closed as stalled. This discussion has moved to proposal #163

from proposals.