BSQ/DAO oracle about proposals HOT 4 CLOSED

I like designing the DAO to allow for support of this feature eventually, as long as that future-flexibility does not increase current complexity too much. The idea of different DAOs being able to "talk to each other" by a generic ask-Bisq-Oracle feature by a user running full nodes for both DAOs does seem like it could be a very powerful idea, even if we can't completely visualize how such features would be used in the boundless future.

Re:

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.

I believe if we changed the logic to handle unknown / higher valued enum values for the DAO parameters by assuming our code does not understand them, we could be able to support them as a soft fork, if at least majority of BSQ stakeholders upgraded to a version that does understand the new parameters. In such a case maybe we also want to hint to the user that they could be running an old release and can consider upgrading. (Protobuf allows this pseudo-forward compatibility already for new / higher-id fields, which are ignored by clients running old releases without knowledge of those fields.)

from proposals.

Re hard coded parameters:
Yes for some cases soft forks might work but if it could render some BSQ invalid (e.g. changing the voting fee to a higher value (we could be tolerant if the paid fee is higher as expected from the params) would invalidate a vote and therefore can lead to a different result in issuance. Not all such cases will lead to a different state of BSQ (e.g. if the vote would not have influenced the total vote result) but we don't know in advance.
For proposals and voting we can enforce that users have to be on the latest version (we use version bytes in all important data). But to enforce passive BSQ users who only use it for paying trading fee or trading it on the market it a bit harder. If a hard fork is needed we can signal that to users. We will probably have a consensus check built in anyway so if a users has a different state then the majority of full nodes he will get alerted by sending out requests for a hash chain of the BSQ state and compare the responses with own state. We can create a hash of the BSQ state data at each block and use the previous hash to create a new consensus hash. This one will be then used for the next - similar like the BTC blocks are chained by referring to the last blocks hash.

from proposals.

It seems like it will be possible, via soft-forks, to add new products (credit, things, work, financial derivatives based on underlying assets or on a contract, ...) which I think is highly desirable. Such amendments will split the network but in a friendly way. The subset of users that want to trade e. g. movies can do so amongst themselves and nobody else sees it. Make sure it will be easy to add and vote on parameters that act on such products (e. g. fees).
Arbitrators will be oracles for some contracts in case of conflicts and the supermajority of merito-token holders will be a stronger and more expensive arbitrator if needed.
Maybe users should be able to choose a subset of (specialist) arbitrators that vote on a statement. I. e. instead of choosing an arbitrator a set of arbitrators are chosen in case something is very difficult or sensitive. This will reduce the ability for arbitrators to scam. High quality arbitrators will then be highly paid in btc after they have established a reputation (outside of Bisq.).

from proposals.

I think that idea is not further developed. I will leave it open still as it might still be interesting to read up and might lead to future continuation or extension.

from proposals.