[bisq-network/proposals] BSQ/DAO oracle (#33)

Wed Jul 25 10:33:22 UTC 2018

While completing the BSQ/DAO we think of any potential use cases which would make sense to support so we are flexible enough to support any of those in future. If it is consensus relevant it would otherwise require a hard fork as old not-updated clients would get a different result if we add new features which they don't know how to interpret. 

Of course we don't want to add complexity and effort for stuff what we even don't know for sure but there are features which are already implemented for special purpose DAO use cases (like bonding or parameter change) and those might be extended for a more general purpose variant without much effort.

## Voting on parameters 
I will give here an overview about the already implemented and planned features and how they can be extended to more generic types.

1. **Voting on DAO parameters to change the DAO itself**
We have already the voting for parameter change implemented (see list of current params here [[1](https://github.com/ManfredKarrer/bisq-core/blob/voting/src/main/java/bisq/core/dao/state/ext/Param.java)]). Many DAO parameters like the fees for proposals, voting or trade or the required quorum and threshold for voting or even the nr. of blocks of the different DAO phases (like the voting phase) can be changed by voting and will be applied in the next voting cycle. There is a hard coded enumeration of such parameters and adding new ones is a hard fork. All of those parameters (beside the BTC trade fee) has direct effects on BSQ/DAO consensus. So we are not very flexible with that approach.

2. **Voting on parameters to change Bisq behavior**
We have planned (not impl. yet but rather trivial) a variant to case 1 but without consequences for the BSQ/DAO consensus though consequences in Bisq: The "Remove altcoin" proposal is such a use case. If the proposal gets accepted the altcoin will get removed from the supported currencies (technically it gets filtered away from the currency list so users cannot use it anymore but is still in the code).

3. **Voting on a statement without triggering anything in Bisq**
Another proposal type which we have in planned (not impl. yet but even more trivial) is the "Generic proposal": Here a user can make any statement to be voted on. It does not has any code-based consequences but the result might give some signal. E.g. If a user makes a request for "Bisq should put priority on SegWit" and if it gets accepted by voting it will not auto-magically add segWit support :-) to Bisq but might give a strong signal to developers to pot priority on that topic. 

4. **Voting on arbitrary statements and exposing the result as an oracle**
We could use the same concept as in case 2 but with a more flexible data structure. So again it will not has direct effect on the BSQ/DAO consensus but it could be used in a code-based context new yet-not-known use cases. For a flexible data structure we can use a hashMap (key and value are strings) and users can make a proposal where they define the key and the value what should be voted on, so it is completely open which keys and values will be used here and how and by whom they will get interpreted later. If that proposal gets accepted by voting it could be used either in a Bisq context and a new software release could add code to interpret that "accredited-by-voting" data. Users who have updated will execute that data others will ignore it. 

It also could be used outside of a Bisq context and others could access that data and use it in their context (e.g. some smart contracts or as non-code based signal). If the data consumers would run Bisq they can access the data securely otherwise if accessed via an API or webpage they need to trust the data provider (there could be several to reduce risks).

## Potential use cases

### Reputation
One use case which came to my mind would be a kind of reputation poll. One could ask the Bisq stakeholders a question like: "Would you trust Craig Wright with giving him a loan of 100 000 USD?" (key: "trustCraigWrightWith100kForLoad", value: "yes"). It should has a pgp signed statement (on the linked Github issue) and the stakeholder can vote with accept/decline or ignore. If the outcome was the he got majority acceptance the proposal requester could use that outcome in a lending market as sign for reputation (that BSQ stakeholders would trust him I doubt it in that example ;-)). The peer giving him the loan could either run Bisq to look up the result himself or there might be some APIs which present those oracle results to the outside world. 

Maybe we could add here additionally a "burn BSQ" feature so it will have some extra costs (can be defined by the requester) for requesting an oracle result. That would add some weight to the result as it shows that the requester was willing to take some risk to lose that BSQ in case he would not receive acceptance.

I don't have other concrete use cases in mind yet, but I think to **expose the power of meritocracy based voting** could be an important extension and the technical effort and complexity is rather low. 

## Trust model/limitations
The trust model for those oracles is based on the group who produces the voting: The BSQ stakeholders. Voting is backed by 2/3 meritocracy and 1/3 stake. That has to be kept in mind and adds clearly limitation of the possible use cases. E.g. using the oracle for financial products (prediction markets) might be problematic. 

Other limitations come from the BSQ/DAO market capitalization and connected volatility and manipulation risks as well as trust in the BSQ implementation as well as ultimately in BTC (as BSQ is based on BTC).

Please let me know what do you think and if you have some ideas with other use cases!

[1] https://github.com/ManfredKarrer/bisq-core/blob/voting/src/main/java/bisq/core/dao/state/ext/Param.java 

-- 
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/proposals/issues/33
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20180725/770753e0/attachment.html>