Request for comment for Bonded roles concept #952
Replies: 5 comments 2 replies
-
CompensationIt makes sense to have something, be it 1% or some other amount in the same range. There is a risk that the bond could be confiscated and the opportunity cost of locking up the BSQ both warrant compensation. ModeratorsIs the idea of moderators to publish a list of misbehaving ids that users can than opt in to ignore or not, or some other mechanism? Sounds good as long as it's easy to opt out. Bridge servicesI think merging the DAO bridge service and reputation service in one role would be better. It also looks like something that anyone can run themselves if they have a bisq1 node. How does the reputation service work? Wouldn't it be better for users to prove to each other that they have the bisq1 reputation, using the reputation service a verifier rather than keeping a centralized data base with the account age/id links? Importing the bisq2 id hash to bisq1 and sign it there and export that signature to bisq2. Alice can show the signature to Bob, who then needs to verify that the associated pubkey has the reputation required. He can do that through his own bisq1 node, or through the reputation service. Bob will learn about the link between Alice's account age pubkey and the bisq2 id, but that sounds better than the service provider learning about the link. Not sure if time stamping should be merged into the other bridging services. |
Beta Was this translation helpful? Give feedback.
-
|
BSQ bond enforcement We have discussed this extensively and I absolutely agree, we can't have some contributors lock their bond and some others don't.
On this case would there be a time-lock after unlocking the old bond? Compensation I completely agree, it makes sense to incentivize people who have been long term contributors in a system such as a DAO where unfortunately the standard are contributors leaving soon. Commitment in the project should be compensated. Moderators and Mediators It seems those two roles are very similar In the sense that it's what we currently do now as mediators/support agents on matrix. I like the invite channels options, I would start them straight away as bisq2.0 deploys and in fact I would be happy to do so.
can't weigh in too much into the details because I don't know enough about that but this idea seems interesting from @sqrrm Thank you for the proposal and for your organizational structure work. |
Beta Was this translation helpful? Give feedback.
-
|
I was going to suggest that locked amount for a deposit becomes lower with time, but getting a % of it from cycle's compensation acts in a similar way. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, true but also would be an added incentive to keep the bond safe. I think with distributed BM relatively high profit rate not paying interest rate would be basically an additional financial burden. |
Beta Was this translation helpful? Give feedback.
-
|
Btw. I found a solution which does not require new bonds for existing bond holders (e.g. mediators, seed node ops). |
Beta Was this translation helpful? Give feedback.
-
|
Looks good. Will all existing bond role types be eligible for compensation if they have a locked bond in place? Would seem fair to me if any contributor with a bond locked to perform a role would be eligible to request compensation each cycle.
Why not have contributors not re-use bonds but create new bonds specific for Bisq 2. Theory being that they potentially can do twice the damage so should be bonded twice? |
Beta Was this translation helpful? Give feedback.
-
Yes I think if we agree on an interest rate it should be applied to all bond holders.
Not sure if its too much of a financial burden then for contributors, specially those who have not enough BSQ yet earned/saved. |
Beta Was this translation helpful? Give feedback.
-
I would like to share the ideas how to deal with bonded roles in Bisq 2 and ask for comment and feedback.
Bonded roles
There are 2 types of bonded roles.
All roles require a BSQ bond and DAO voting.
System roles cannot be delegated to users due security reasons or requirement for system wide (weak) consensus.
Delegable roles can be operated by any users themself and assigned via JVM arguments. They are based on publicly available data and do not require to be in consensus with other Bisq 2 users.
Technically there are roles which are operated by users (Mediator, Moderator, Security manager, Release manager) and roles which are operated by nodes (Seed node, DAO bridge service, Bisq 1 reputation service, Timestamp service, Blockchain explorer API node, Market price API node).
The former will use the profileID at registration which includes the networkId. The latter will provide in the registration data a list of networkIds to allow the role owner to provide multiple nodes.
For Seed nodes and DAO bridge service we need a hard coded root node to start with. The DAO bridge service will then distribute the other roles to the Bisq 2 P2P network (using AuthorizedData which is protected by a signature and the role owners pubkey).
System roles
Delegable roles
BSQ bond enforcement
In Bisq 1 we never enforced the BSQ bonds and it led to a unjust situation where some have bonded and others not.
In Bisq 2 we enforce BSQ bonds by design (a DAO API node gets the DAO data and provides it to Bisq 2 for verifying if a role is bonded).
With DAO API node its a bit of a chicken and egg problem, so we need a hard coded (and bonded) root node which provides DAO data for verifying other bonded roles. This root node can fade out after bootstrapping.
Each role need to register in the UI after a BSQ bond is locked up and will then see additional UI screens according to their role (invisible to others). Those screens will make operating the role more convenient (e.g. alert sender has a list of past alert and can delete those, moderators get a list of banned users,...).
The implementation details for making the bonds verifiable are not worked out yet, but likely it will be handled via the bonded role user name in the DAO proposal which need to contain certain data in a certain format to make the role owner identifiable for Bisq 2. For instance we could use the format: BISQ2_[role type]_[hash of profile ID].
Downside of that approach is that existing roles like mediators cannot re-use their bonds. But we could consider that those are unlocking their existing bond and create a new bond according to Bisq2 requirements and re-use that for Bisq 1, so there will be no additional burden.
In Bisq 1 we need to repurpose some not used
BondedRoleTypesfor those new Bisq 2 roles if none of the existing is covering it.I prefer to not add new BondedRoleTypes to not risk consensus issues in the DAO.
There have been resistance in the past from some contributors who did not want to lock up the BSQ bond because of the financial burden. But that is exactly the idea behind the bond, to add a financial burden for securing the role.
Compensation
The financial burden for the BSQ bond should be reflected in the compensation requests. I would suggest that we use a clear formula for that. E.g. x % of the locked up BSQ per cycle gets added for compensation requests. If x is 1% then a 10 000 BSQ bond would generate 100 BSQ per cycle on "interests" or 12% per year. I guess that's not that bad... The % should be aligned across all bond holders and I request here potential bond holders to comment for a suggestion. If no feedback is provided I will go with the 1%.
Beside the compensation for the BSQ bond all roles will get compensated according to the costs and effort to operate that role.
System roles
Mediators
Similar as in Bisq 1, mediators are used for Bisq Easy traded in case of problems, but they have no enforcement power. They can provide information to moderators for banning a user who severely violated trade rules.
Moderators
Users can report other users to moderators for violations of chat or trade rules. The moderator investigates the case and if they consider the violation severe they can ban that users profile ID.
Moderators can delete chat messages as well (technically its not deleting but adding a ban flag associated to the message, as only the message author can delete it).
In future we might consider to make some channels "invite-only" to protect against spam or other abuse. The 'events' section might be a candidate for that. Once that is in place the moderator might be the role to grant write access to a channel.
As Bisq 2 provides support for multiple identities that banning might not have a big effect as a spamming user could easily create a new profile and continue.
If spam becomes a problem we might add protection with proof of work and/or reputation features.
Security manager
The security manager can broadcast a alert message to the network.
Alerts can be ignored by the user via JVM arguments so that they do not create a systemic risk.
There are several AlertTypes:
Release manager
The release manager can broadcast a update notification to the network.
Notification types:
DAO bridge service
The DAO bridge service requests DAO data from a Bisq 1 API and broadcast the relevant data to the Bisq 2 network.
This data is required for verifying bonded roles and for reputation sources (burned BSQ, bonded BSQ).
Users can verify the DAO data provided by the DAO bridge service by requesting the DAO data itself from a Bisq 1 API node and checking if the distributed data was correct. If they would detect invalid data they have to report it to the developers and if it turns out the DAO bridge service has provided incorrect data intentionally a confiscation proposal will be created to request the DAO for confiscating the operators bond.
Bisq 1 reputation service
The Bisq 1 reputation service provides data from Bisq 1 via an API for reputation sources (account age and signed account age witness).
The role owner learns about the connection of the Bisq 1 account (pub key) and the linked Bisq 2 identity (profile ID). For security reasons the role persists that data so in cases of scams or severe violations of trade rules (it will be mainly for sellers) we can block that user on Bisq 1 as well by figuring out the link back to Bisq 1. This is a trade off of privacy and security, but as we cannot avoid anyway that the oracle is not persisting the data (even the code would not support it the oracle operator could add themself that functionality) I think its justified to side for the security aspect here.
A potential improvement could be to encrypt that data when persisting it and use an encryption key controlled by another bonded role, so it would add a layer of separation. But as said the oracle owner could circumvent that anyway and they need to see the plain data for verification purposes. Only some zero knowledge proof might avoid that problem, but I guess that's a bit too much for that purpose.
Timestamp service
Used for time-stamping function for profile age of Bisq 2 users.
We had earlier open timestamps implemented and considered that to be used, but it was very cumbersome to use and we dropped it. Still we could go back to OTS or a custom blockchain based time stamping. But as the impact of the profile age on reputation is very small I think its not worth the added complexity, dependency to an external service and UX drawbacks (considerable time delay). If we get back to OTS this would become a delegable role.
The above 3 roles (DAO bridge, Bisq 1 reputation and Timestamp service) might get merged into one role. Not sure about a good term for it yet.
Delegable roles
Seed node operators
Seed nodes play a less critical role as in Bisq 1 as the data delivery concept is different and more distributed to normal nodes.
Blockchain explorer API node
Used for requesting state of a tx during the trade process (if btc payment is confirmed).
We support mempool API only as otherwise we would need to write multiple parsers.
Market price API node
Used for requesting market prices. If % based price is used it carries additional security risks and justifies that we require a bonded role as well.
Other non bonded service provider roles
There are some additional Blockchain explorer use cases which will not require a bonded role.
When a user clicks on an address or tx it opens a block explorer web page.
We provide a curated list of recommended explorers and the user can add their own one, including user-operated ones.
This will be similar as in Bisq 1 and handled in the preferences screen.
Questions? Feedback?
Any feedback? Any additional input or suggestions for roles (with new trade protocols there will come more)?
Beta Was this translation helpful? Give feedback.
All reactions