[bisq-contrib] Phase 3 DAO

[Manfred Karrer]

Here is my reply to some questions from Neiman.


Hi Neiman,
> Hey Manfred,
> 
> Sorry it took me so long to reply. Here are my (long) comments.
> 
> Phase 3 is where the DAO starts looking like a real organization. Phases 1+2 focused on payment for contributers (workers). Phrase 3 expands the DAO with the functions of
> - hiring,
> - quitting,
> - firing, and
> - fining.
> 
> All of those are achieved with a lock-up mechanism (see below).
> 
> Since the current description is incomplete, I contribute more high-level thoughts.
> 
> The document focuses on mediator and arbitrator processes.
> 
> "Hiring" of a mediator\arbitrator is done by locking up funds (safety deposit).
> - 20,000 BSQ (arbitrator) or 1,000 BSQ (mediator). The sum is adjudged by voting, where a change is not valid retroactively.
> - lockup transaction is valid after 6 confirmations.
> - lockup transaction is a transaction to oneself with OP_RETURN type 0x04.
> 
> "Quiting" is done by unlocking the funds.
> - unlocking transaction is valid after 9000 confirmations (~2 months delay).
> - unlocking transaction is a transaction to oneself with OP_RETURN type 0x05.
> 
> Remark: The process contains an extra action: revoking a registration. It seems to me like another form of quitting, and I'm unclear as for the differences between "revoking" and "unlocking”.
> 

The locking/unlocking feature is more general purpose for all bonded roles (arbitrator but also seed node operators, etc., all roles where the role operator can cause damage in case of abuse).

The revoking is the first step when an arbitrator wants to stop working. So he removes himself from the list of active arbitrators (P2P network data) and all new offer makers from that moment on cannot add that arbitrator anymore to their supported arbitrator list in a new offer. But it can be that there are open trades where he was chosen as arbitrator and as the max. trade period is 6 days and as it could be that a dispute is opened just at the last day the arbitrator still need to be available for a few weeks to check those dispute cases.
We can start the unlocking of his bonds with the revoke time. We need to add an additional security measurement that the maker will check if the taker uses an arbitrator which is not in the list of active arbitrators. That way the arbitrator could not try to take existing offers himself with a manipulated trade app which still has himself as arbitrators because the maker would reject that take-offer attempt. We could even auto-generate a adjusted offer if the arbitration list changes to the time for offers which contain the revoked arbitrator would be very short.
There might be still some risks, so not sure if revoke and unlock time can be at the same moment or if we need to delay unlock time after all open disputes are closed.
But as the new arbitration system will require more concept work anyway I will leave that for later...
> 
> "fining" (making a fine) of arbitrators/mediators is done by confiscating some or all of the locked up funds. This is an interesting feature, reminding Ethereum's punitive approach to PoS (slasher algorithm for example). The process is:
> - Anyone can make a confiscation request (see remark below).
> - Confiscation request fee: 100 BSQ (can be changed by voting).
> - Request needs a quorum of 100,000 BSQ and 75% to be authorized (can be changed by voting).
> - Confiscated tokens get burned (though the owner still holds the "colored" Bitcoins)
> 
> Remarks on "fining":
> - Details are missing as to when and how a confiscation request is made.
> 

It is a normal request in the any period, so usually the first 3 weeks of the month (open for request period).

> - It's suggested that a confiscation will also be hard coded in the next Bisq version. I think it's an unnecessary complication.
> 

I added that to add extra security that the users need to confirm the confiscation by “voting” with a software update. Maybe its not really required but protects more against majority attacks.

> One action is missing to complete the picture: "firing". This means, a request to unlock the arbitrator/mediator funds by the community, without confiscating them.
> ----------------------------------------------------------------------------------------------
> 
> The document suggest to extend this model to all Bisq roles:
> - managing the domain name,
> - managing the trademark,
> - managing of social media accounts,
> - seed nodes,
> 
> and so on.
> 
> I can't see clearly how the locking up model functions for most roles.
> 
> Specifically for email account, Bisq domain or Bisq trademark (but also for many others). First, not just anyone who lock ups money can manage the email of Bisq; some abilities are needed as well. In addition, it's difficult to safely pass the role of email manager from one participant to another using the lockup mechanism. Finally, The voting model is too slow to fire or fine bad players in emergency cases.
> 

The roles are not intended to be taken by “anyone” but only by those who are very involved in Bisq and giving a bonded role will be done initially by the core contributors (maintainers) and might be delegated later to voting.
When a role maintainer violates his duties (severely) then he loses his locked up BSQ by confiscation. We don’t have a mechanism to revoke him from the subject of his role.
E.g. if the domain holder start to do bullshit he risks to lose his bond, but the DAO has no way to get the domain from him. He still might continue to abuse his power by holding the domain but at least he has financial inventive not to abuse it. Roger Ver might have lost millions for his abuse of Bitcoin.com <http://bitcoin.com/> that way, but the DAO would not be able to take away the domain from him.

The confiscation should be an extremely rare (or better never happening) event. The bonding is just a mechanism to add extra security to those areas which cannot be decentralised because they operate on centralised systems or are by concept difficult to decentralise.

There might be some use cases where we want to extend that for a broader user group and use the bonding as kind of reputation tool (e.g. buy in higher trade limits by locking up BSQ). If we do that we would need to make the process faster and not having the software update requirement. For now I don’t consider that as a planned feature but maybe it emerges as a kind of lightweight bonding with different characteristics.
> 
> I may be wrong; But in order to convince future readers of the document, a detailed description of the process of at least one role is needed.
> 

Good point to add that!
Chris has written a very detailed role description and in fact each role operator should have done that, but due lack of time there are not too many atm.
https://github.com/bisq-network/roles/blob/master/twitter-admin.adoc <https://github.com/bisq-network/roles/blob/master/twitter-admin.adoc>
> One possible solution to this situation is to create "Bisq management board". The board is chosen using both voting (elections) and locking up mechanisms. The board then appoints the rest of the roles. Actually, it seems to me more reasonable for the board to also do the "fining" (confiscating funds) and firing of contributers. A mass vote is a danger for mobbing.
> 

Yes, I also think that specialised “management” roles will emerge at some point, not sure if boards are good for that. I did not want to think too far in the future as there is so much work open before we get there. But the governance will probably emerge to a more complex structure than the simple voting. I tried to mention that in phase 5.

> Even if we consider this option, I suggest to *not* allow the board change the Bisq parameters. These should be changed by voting of BSQ token holders, to create some basic separation of powers and anti-centralization structure.
> 

Yes it also makes political pressure less likely. Ideally the voting stake is anyway in control of those who worked the most and know the project best, but it should be open by principle and adding entry barriers like having a board might have a negative effect.

> Another question is who is capable of voting. Right now it's all token holders. This de facto creates a PoS governing. However, since most token holders received their tokens by contributing, the current situation is meritocracy. Meritocracy may change to pure PoS once Bisq token trading begins. That's why Phase 4 suggests to give extra weights voting of past contributers.
> 

Yes. I think it will take some time until BSQ is distributed that much to non-contributors that this becomes a risk or that it makes a big change if voting is POS-only or mixed with reputation (earned due contribution).
> 
> What do we lose by allowing only past contributer to vote with *only* the tokens they got by compensation (and still hold)? We can even limit it to only past contributers in the previous year (for example). That way we achieve a stronger meritocracy. It will be difficult, for the long term, to run an organization where anyone can just buy voting power.
> 

To only use that would create a chicken and egg problem. You can only vote if u have an accepted contribution request, but for getting a contribution request accepted someone need to vote.
Beside that he could only vote once as after using the funds in the vote tx it is spent. To trace that it is the same owner and allow the vote tx outputs to become new “reputation-colored-coins” might be complicate if possible at all.
I think to consider the reputation token as statically to the issuance tx bound tokens is easier. We can use the priv key of the input for a signature to proof ownership.

There are n past issuance txs. The voter could add the signature of all those using the priv key of the issuance tx input (signing the tx or any arbitrary but fixed defined data, the pubkey is in the tx anyway) to the encrypted vote data he sends to the P2P network. That way we are not limited in data size and structure. After the vote reveal tx the users can verify that the sig matches with the pub key in the issuance txs (the txids are part of the P2P network data structure) and thus can see that the voter is the original contributor. From the original request tx we get the stake.
With all that the user can collect the cumulative stake from contribution and add it to the mix of the new vote tx.

E.g. A contributor had 2 previous issuance tx and makes a new vote.

Issuance tx 1: earned 5000 BSQ, 10 month old
Issuance tx 2: earned 8000 BSQ, 5 month old
Vote tx with stake 12000 BSQ

If we define that reputation is 80% and pure vote is 20% weight, as well that reputation loses weight every month (in blocks) by 5 % we get those values:

Issuance tx 1: 5000 BSQ, 10 month old -> 5000 * 0.5 = 2500 BSQ -> 2500 * 0.8 = 2000 BSQ
Issuance tx 2: 10000 BSQ, 5 month old -> 10000  * 0.75= 7500 BSQ -> 7500* 0.8 = 6000 BSQ
Vote tx with stake 12000 BSQ -> 12000 * 0.2 = 2400

So his overall stake is 2000+ 6000+ 2400 = 10400 BSQ

There is still a risk that the voter sells his private keys as there is no risk if he has moved the BSQ already. One way could be to only accept unspent requests, but thats a bit limiting to contributors.
There is also the issue that if he passes over his priv key then 2 voters could use that and it is hard to detect which one is the original. But that might be the key for the solution. We could define if a duplication is detected both are invalid so the buyer of the priv key has no guarantee that he can use it safely as the seller cannot proof to not have it anymore, thus he always can render future votes of the key-buyer invalid, making it not attractive for a buyer to enter that deal.

Example:
I want to sell the priv key from an old 10k BSQ contribution request. If you buy that from me you can increase your vote weight. After I received the money you cannot prevent that I still use my key in voting and if that happens in the same vote period it will get detected by the verifier and both votes become invalid. Thus you will not risk to spend money on that as I cannot guarantee that I will not re-use my key for future votes.

> This suggestion may cause one problem though: it's one less motivations to buy Bisq tokens.
> 

The balance need to be kept so that there is enough incentive still. But I think the costs for voting will keep those out anyway who are not genuinely interested.
Voting is more work on the project rather than a right to consume.
> 
> Three last remarks:
> 
> Sum of locked up funds:
> --------------------------------
> It's impossible to say if the lockup sums are too high or too low (or accurately high), since the value of the BSQ token is unknown. I'm aware that the lockup sums can be changed by voting, but I doubt if this will happen too often.
> 

Yes good point. As most roles are anyway in the hand of the founders and those who have already contributed a lot the risk is low for abuse. But high bonds are actually a security feature as that funds cannot be stolen fast ;-). E.g. if your BSQ wallet get stolen you can request a confiscation and the thief cannot get out the funds fast enough. As the confiscated BSQ are burned we can re-issue them in such cases without creating new supply. Such a new issuance would be just a normal comp. request and if the stakeholders agree you get your loss recovered.
Such we could also use in cases users get scammed by an arbitrator, so that they get compensated by the confiscated bond of the arbitrator, thus the DAO does not increase supply but re-assigning the confiscated BSQ (conceptually, not technically). But all that should be seen as exceptional cases.
> 
> In general, deposit sums should be approximately twice, or at most thrice, the amount of damage that can be caused. If an arbitrator can arbitrate trades of at most a 1000 BSQ, then 20,000 BSQ deposit is too high lockup sum for her/him.
> 

Yes some areas are hard to estimate, like value of the domain name.
Arbitrators could take all offers (with a second trader app where they act as taker) and then do the payout to themselves. That can be quite a lot of money (amount of all offers).
But for the new arbitration system we want to add extra security features to avoid such, but it is not defined in details yet.
Some rate limit of txs he can sign in a specific period would be good.
Another idea could be that a special monitor node observes the arbitrator txs and if it detects too many txs in short period it broadcasts an alert msg to the P2P network blocking the arbitrator so he cannot continue to take more offers (could still be tricked with queueing txs for later broadcast after he has taken all offers…).
Or we find a way to limit him when the offer gets created. So the maker counts the offers where the arbitrator is already used and if it meets a limit he will not use that arbitrator. Due the fluctuating nature of the offerbook that will not give us reliable limits but should limit the nr. of offers one arbitrator could steal to a certain range at least.

> The problem is not only that we have no idea how much BSQ tokens worth (I don't know how to solve this), but also that the value is likely to fluctuate significantly once trading begins. So 20,000 BSQ may be much too high in one month, and much too low the next one. Since people will not update their deposit based on the current price of BSQ, it is a serious source of problems.
> 

We will set the bonds with the 1 BSQ = 1 USD assumption which is the lower limit (e.g. I as main stake holder will not sell below and I assume most of the other contributors will not as well).
So if BSQ rises to 10 USD the bonds are 10 times too high, which might be annoying for bond holders but is good for security. As mentioned above even for the bond holder it adds security, so he might be ok with that. Otherwise he can start a new bond and then unlock the old one.
We should define the bonds in USD terms and adjust the required bonds in BSQ over time. But also potential damage will change with project size. Domain might need 50k USD for bonding atm, but might need 200k in 2 years?
> 
> Voting on Bisq DAO paramters:
> ------------------------------------------
> I think this action should be included in the description of phase 3. It becomes crucial now.
> 

There will be 2 types of proposals:
- Those which will be executed by code
- Those which will require devs to implement and release

The compensation request is in the first group and many parameters like trade fee as well.
But there will be more general requests which either are not possible to execute in code (e.g. feature requests) or are not supported now. So that adds a lot of flexibility and removes pressure that we need to implement all initially. If we see that there are often requests for changing e.g. the duration of the DAO phase (1 months atm) we might start to add support to make that automatically applied by vote result. But if we see that there is never such a request or once a year the extra effort and risk to implement that as a smart contract is not justified.

So I am not sure if I actually want to specify too much here but rather start with the most obvious and then see what people are requesting.
> 
> Bisq reserve:
> ------------------
> Bisq DAO compensation comes from its money reserve. Do we have a revenue model to keep this reserve alive for the long run?
> 

Not sure if I understand that. There is no reserve. There is only the initial issuance where we use 2.5 BTC (initially it was 25) to create 25M BSQ. Then at an accepted compensation request the requester uses his BTC input as source for the newly issued BSQ. E.g. If I request 10 000 BSQ (0.01000000 BTC or 1000000 Satoshi -> 1 BSQ = 100 Satoshi) I need to use 0.01 BTC as input and that might become BSQ after voting. Thus the “costs” for creating new BSQ is on the shoulder of the contributor but 0.01 BTC are about 100 USD atm and 10 000 BSQ should be min. 10 000 USD, so the relation of the “printing cost” to the created value is ok (it was not ok with 25 BTC as that would have caused a 0.1 BTC cost which would have been 1000 USD for issuing 10000 USD, that would have been even worse if BTC price goes up to 100K then the printing costs would have been 10 000 USD for creating 10 000 BSQ).
> 
> I hope those comments help somehow,
> 

As always! Thanks a lot!

Br,
Manfred

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-contrib/attachments/20180327/ade061e0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.bisq.network/pipermail/bisq-contrib/attachments/20180327/ade061e0/attachment-0001.sig>