bisq-network / proposals

@bisq-network improvement proposals
https://bisq.wiki/Proposals
44 stars 16 forks source link

Proposal to decentralize dispute resolving in bisq #458

Closed ChrisSon15 closed 2 months ago

ChrisSon15 commented 3 months ago

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Decentralized Justice

When two parties do a trade it happens sometimes that they have a dispute, which they cannot resolve among themselves. This needs to be resolved by a third party (oracle-problem). A decentralized approach to this problem is known since the mid-ages. In some jurisdiction we have juries, that consists of random people summoned as jurors and a judge to administrate the process, see Jury. Wikipedia states "In modern times, juries are often initially chosen randomly, usually from large databases identifying the eligible population of adult citizens residing in the court's jurisdictional area", see here. Jurors are randomly selected from a large list of eligible persons to ensure they are impartial. If the random subset of the list can be made with no central bottleneck, and this subset can vote on the dispute independent of a central influence, then this process can be called decentralized. I guess some smart guy was into decentralization already in the mid-ages (probably they were on a gold standard!). Today such jury-type is still active for example grand juries here in the US.

applying a jury-type arbitration to Bisq

If we want to apply the experience from the justice system to the bisq ecosystem, we would need to find the jurors among the bisq users themselves and get those selected users to look at the facts of the dispute and give them a technical means to vote for the outcome. And all of that in a decentralized manner. This would release the DAO from having to deal with dispute and the whole process of reimbursing traders etc.

As far as privacy is concerned, this could be perceived as a decrease of privacy as the information about the trades is shared with a group of jurors. The good part obviously is that the resolution of conflicts remains solely in the hands of the bisq users and therefore the DAO is a pure software development organisation. Also, with this Bisq could follow the ethical standard to 'Never touch someone else's money.'

This would be an important key towards true decentralization of Bisq.

Though this concept is explained in only a few sentences, it does have quite some complexity to it to implement it right. But given the complex system of arbitration and reimbursement today, which will be replaced, it could be well worth it.

To adopt this to Bisq, the two traders would need to set up the jury-system without a central entity. This makes it harder but not impossible. Here is the general idea and requirements, how to tackle this will be discussed later:

  1. In preparation phase, when the bisq offer is taken, both parties need to agree on a list of potential jurors. Also, they need to agree on an initial randomness. Then both parties can pick the same random group of jurors.
  2. They need to collect a public key from each juror, this is needed for casting a vote, see later.
  3. Instead of the current Redirect Txs, they will sign new type of Verdict Tx.This new transaction would need to pay out to the trader with most votes.
  4. When the Warning Tx has been confirmed, then the new Verdict Tx can be posted. If it's posted by either party, then each party must reach out to the jurors requesting a vote for their case (a vote would be a specific signature). Also, a chat channel need to be established between the traders and the jurors, so the traders can send in the arguments and evidence for their case. It would make sense to have also a supporter from the DAO in the chat room, to support the jurors on how this should work. This would actually be similar to the role a judge has in real world juries.
  5. When the jurors have made up their mind, they will send a signature to the trader they favorite.
  6. When one of the traders has the majority of votes (=signatures) then he can get the payout.

There are several issues to solve.

Why would someone participate as juror?

In the justice system jurors participation is compulsory. Even though some degree of punishment would be possible in bisq, it's not favorable. Since the loosing party has a deposit, a certain percentage of the deposit of the loosing party should be distributed among the jurors to compensate for their time. From a UI perspective the bisq application should firmly guide the user that received a juror summon, that he definitely should do it. Another idea would be, if a user wants to lift the trade amount for his account, that he gets a popup, says that with lifting the trade limit he also has the responsibilities to possibly act as juror.

If we would like to design this as opt-in, that means users sign up as potential Jurors, we would have several options to incentivise users, e.g. by an advantages like higher trade volume, nice little trust symbol in the avatar, expected earnings,... If the incentives for participating in the jury are high enough, also an opt-out could work. This probably needs some more discussions.

How to get to a list of users, which could be jurors?

It is important to find a large enough set of candidates to make fraud sufficient unlikely. There are many criteria where we can search for eligible candidates. It's of course important that these candidates were recently active.

The total set of bisq users could be filtered by

The peers which are visible to one user in bisq may differ quite a bit to the peers seen by someone else, it needs to sync the list / agree on sublist, which is sufficiently large to not have a bias.

How to randomly pick from the list?

Once we have the list, the 2 parties needs to generate a random seed. It should not rely on anything which is already available, because otherwise the list could be crafted such that only favourable persons appear. I suggest to generate real random value and use an 'encrypt and reveal' scheme to exchange the random values. The final random value to be used by both parties could be $ r= sha256(r_A||r_B)$.

How does the pubkey from the juror come to the traders?

When the user creates the bisq account, a pubkey /secret key should be created. When making an offer, the pubkey should be made public in addition to the tor-address. traders will collect these pubkey along with the tor address for potential use as juror. A user could change the pubkey when changing the tor-address.

New redirection Tx, the Verdict Tx

The redirection Tx from the last proposal would need to be replaced by a transaction called the Verdict Tx. The verdict transaction is a taproot transaction where the output has many script spends. The first script spend would be secured by a k-of-n threshold multisignature such that a majority of signature of the jurors is needed to get the payout. So the jurors votes by signing a transaction. Alice and Bod send their payout transaction to the jurors. If a juror wants to vote for Alice he signs her transaction and sends the signature back to Alice. If Alice has collected the majority of signatures, she can post her transaction. Its unlikely, that Bob will also get a majority of signatures for his transaction.

But what if some jurors don't vote? There are many more spend scripts of that output, which have a relative time lock. After a time duration Alice only needs the majority minus one vote. After 2 durations she only needs majority minus 2 votes and so on. Hoping that Alice and Bob won't have the same amount of votes, in which case there would be a race to get the transaction through.

here is how that would work in bitcoin script from script spend i:

OP_CSV <time_i>
OP_DROP
<pubkey Juror_1>
OP_CHECKSIG
...
<pubkey juror_n>
OP_CHECKSIGADD
OP_PUSHDATA k_i
OP_GREATERTHANOREQUAL 

where
$n$ is the number of Jurors \ $k_i = \lfloor \frac n 2 \rfloor +1 -i ;$ number of votes needed to win in that cycle. \ $d$ duration time for one voting cycle (which may be set to 2 days).\ $time_i = i \cdot d;$ duration of cycle i

Communication

There will be quite some UI work in the bisq app for the jurors. Besides the need of having a chat channel, they need to be informed about the upcoming jury they should participate in, they need some educational text (probably a link to a wiki site). Then they need to review some evidence, which should be submitted by the traders as pictures and finally some UI controls to make their vote.

Jurors Impartiality

Since trader can chat with the jurors, they may try to bribe them. Adding a supporter from the DAO to it, doesn't change the situation, its just one more to bribe. The only person having a genuine interest against bribery is the other trader. Since that trader is also in the chat, it is likely that such a bribery will be detected. And increasing number n of jurors makes it also more difficult. We could come up with measures against bribery explicitly, but I think it's unlikely anyway.

Conclusion

Giving the work of arbitration back to the community empowers the community to be more self-sufficient. This independence from the DAO makes it more censorship resistant.

clearwater-trust commented 3 months ago

Here are my thoughts:

Considering the MAJORITY of ARBITRATION cases are UNRESPONSIVE TRADERS. What is needed is not a jury or judge but an oracle of sanity. If the trader is unresponsive, the jury is overkill.

Plus, if I understand the current dispute protocol correctly, if the trade is especially problematic, it can be handled through DAO voting, which for all intents and purposes is a highly motivated jury already in place.

Inserting so many steps in the dispute process will kill throughput for stuck traders, something we want to avoid like the fake covid.

I disagree in whole with your conclusion. Your reference to regulation and resistance is suspect and wrong.

With all respect to everyone everywhere. Love and peace to all.

Thank you for your thoughts and discussion on this important topic.

suddenwhipvapor commented 3 months ago

Thank you for your proposal. The whole idea is very fascinating, on a purely theoretical level, and at the same time it is indeed daunting in its feasibility. Other than what @clearwater-trust observed about arbitration being mostly due to unresponsive peers, and probably to a much lesser extent, to traders rejecting mediation proposal out of spite, so leaving really complex cases, those addressed by this proposal, as a small minority, the toughest issues I see are:

These are my first impressions, yet your idea is still conceptually very beautiful!

HenrikJannsen commented 3 months ago

I second @suddenwhipvapor and agree with @clearwater-trust that the DAO is already a jury system which can be used for arbitration (conceptually in place, in practice I guess it was never used/needed).

I agree strongly that finding an alternative to the current arbitration model would be good but I think we have to carefully weight the pro and cons and build on our experience.

I think to have multiple jurors per trade would make the communication process much more complex and error prone (also from human side, like juror not responding in time, making bad decisions due lack of knowledge/experience,...).

The privacy issues have been mentioned already and would be (specially from users perspective) a major problem. To proof a Fiat payment often requires to share personally identifiable data (also an account number without name is basically a pointer to a real life ID even not readable by the arbitrator). As there is no good solution known to avoid that problem we should at least limit it to the smallest group possible.

I also think that arbitration is a specialized task and normal users who don't have the knowledge about the trade rules, experience with payment methods and charge-back tactics are not well equipped for that. It also requires to be always up to date with new releases which might contain changes or new features and to be daily online.

Another problem with a random group is Sybil attacks: Depending on the model, it might be challenging or impossible to avoid that a motivated scammer provides a majority of the jurors as Sybil nodes. The classical protection is that we require some sort of skin in the game. Be it financial commitments or built-up reputation (by contributing to Bisq via the DAO). For normal users that is either undesirable or unfeasible. You mentioned metrics derived from trade data, but keep in mind that such a model would be implemented in Bisq 2 and likely not in Bisq 1 and in Bisq 2 we don't plan to have something like trade statistics. And also in Bisq 1 those data are not secure data and could be manipulated if there are enough incentives.

The current system is designed for multiple arbitrators, so adding arbitrators which are randomly chosen and bonded by a DAO bond would improve the system. The reason why that did not happen is, that there are not that many suited/interested candidates and there are not that many cases so that the ratio of work and compensation is in a healthy balance (arbitrator has to be online daily, if they would get one case every 2-3 weeks it would rise the cost per case).

To have an automated and guaranteed payout mechanism in contrast to the current model where the reimbursement from the DAO is a voluntary act would be desirable but will lead to the very problems which Bisq avoids with today's model.

It does not matter how many jurors you have, there is always the risk of collusion (or more severe - Sybil attacks, or compromised opsec of the juror). To use the DAO as binding/automated decision maker (not as it is used now) might be technically possible (maybe by using DLC or threshold signatures?) but would make the DAO voting process vulnerable for manipulation. E.g. The scammer will buy up enough BSQ to vote in his own favor. Note, that this is not the case now, as if the arbitrator (assuming they are honest) make a proposal the wanna-be-scammer cannot vote in his favor if the proposal is against his favor. If the arbitrator would be dishonest and make a proposal against the honest trader, the honest trader has all motivations to share enough evidence to the DAO stakeholders to reject that proposal (and potentially confiscate the arbitrators bond). Sure ,here a motivated scammer also could buy up lot of BSQ to vote in favor of the incorrect proposal, but then all DAO contributors and stakeholders have an incentive to vote against that and many have also vote weight from merit (past contributions) and not only BSQ stake. Thus as long there is a majority of BSQ stakeholders who care about Bisq and who are honest, the scammer has no chance to win. And if that would not be the case, then the DAO and Bisq has failed and deserves to get forked. The scammer will have then stress to sell quickly the purchased BSQ because it will become quickly worthless. Furthermore here the market effects (and problems from shallow liquidity) when a scammer would like to buy up a huge amount of BSQ for vote manipulation, which would make his attack more expensive, less calculable and more risky to fail.

MwithM commented 3 months ago

Obliged jurors would definitely not work. There are unresponsive traders, there would be lots of unresponsive jurors. Juror/mediator/arbitrator concepts are mixed in your proposal, I guess because details are left open for discussion. The incentives for a sybil attack there would be huge, specially if jurors where known before dispute begins. You try to mitigate this by a reputation system, but that would kill multisig's trading protocol biggest advantage, which is not having to know who you're dealing with.

Who would serve the grey areas where support/mediation task is involved? Like, a peer pays late but it says that it was their banks fault, or a user wants to check with a third party that using another payment method is correct? This task is not meant for inexperienced traders.

Thanks for this starting this conversation, I am expressing thoughts I had in my mind for long in this proposal, so I don't hijack yours.

suddenwhipvapor commented 2 months ago

Closing as stalled,ping me if wishing to reopen it.