Find a solution for more resiliance with price relays

[ManfredKarrer]

We are very dependent on BitcoinAverage as the only Fiat price provider. If there are issues (as we just faced) all percentage based prices cannot be taken.
We need secondary price sources and either fall back to that in case we have issues with BitcoinAverage or mix it. Thought there is some complexity as all price relays need to have the same source as otherwise take offer attempts can fail if the price what the maker and the taker sees is above a small tolerance window. E.g. If one peer gets the price from a relay which gets it from BitcoinAverage and the other peer is connected to a relay which is connected to coinmarketcap the price will be likely different and exceeds the tolerance window.
So it need some creative solution how to deal with those issues.

[Quenos]

I’m thinking of the following solution:

1. Taker requests price from maker upon taking the offer
2. If price differs more than small window, taker gets a warning that the price has changed, can then accept or reject

Maker’s price is always leading. If the taker is trading manually, she is probably still behind the computer and can interact. Bots will need to be reprogrammed to deal with protocoll change.

Do you think this is workable? Am I oversimplifying the issue?

[ManfredKarrer]

The sync of both traders price is already implemented. In the trade protocol the calculated price is compares and if it exceeds a small tolerance window it leads to a rejection.

The concern of that issue is to find more price providers and find a resilient way how we can mix those and stay backward compatible.

[Quenos]

Hmm, now I see what you mean. That really needs a creative solution.
Lantency issues already cause price differences, even when on the same data feed.

What could be done is adding/subtracting a certain % to the fall back feed(s). E.g. I know that the GDAX EUR/BTC is about 2% higher than BitcoinAverage. This, however, raises the question will it stay that way over time. How will this mark-up (down) be adjusted in the BISQ application if they are no longer valid?

What can be done to solve this is to let the nodes monitor their fall back price feed and create a moving average of the difference between fall back and BitcoinAverage. Question is, is that worth the trouble?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[wiz]

Fixed by bisq-network/projects#35