-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal to decentralize dispute resolving in bisq #458
Comments
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. |
Thank you for your proposal.
These are my first impressions, yet your idea is still conceptually very beautiful! |
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. 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). |
Obliged jurors would definitely not work. There are unresponsive traders, there would be lots of unresponsive jurors. 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. |
Closing as stalled,ping me if wishing to reopen it. |
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:
Verdict Tx
.This new transaction would need to pay out to the trader with most votes.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:
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.
The text was updated successfully, but these errors were encountered: