Difference between revisions of "Bisq 2 Roles"

From Bisq Wiki
Jump to navigation Jump to search
(Rewrite page for clarity & flow. Improve descriptions of System/Delegable roles, process for becoming a role holder, bonding & confiscation details. Fix typos, add TOC & internal links.)
 
(9 intermediate revisions by one other user not shown)
Line 1: Line 1:
−
Bisq 2 has contributors that take responsibility for specific bonded roles for the network resources and processes.  
+
In [[Bisq 2]], certain network functions and processes rely on contributors who take responsibility for specific '''bonded roles'''. These roles require locking [[Introduction to the DAO|BSQ]] as a bond, approved by the [[Introduction to the DAO|DAO]], ensuring accountability and security for the network's decentralized infrastructure.
  
−
There are 2 types of bonded roles.
+
There are two main types of bonded roles in Bisq 2: System Roles and Delegable Roles.
  
−
* System roles
+
__TOC__
−
* Delegable roles
 
  
−
== System roles ==  
+
== System Roles ==
  
−
System roles cannot be delegated to users due security reasons or requirement for system wide (weak) consensus.
+
System roles must be performed by the specifically authorized contributor approved by the DAO. For security reasons, these roles cannot be delegated to others.
  
 
=== Mediator ===
 
=== Mediator ===
  
−
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.
+
[[Mediator|Mediators]] in Bisq 2 primarily assist users of the [[Bisq Easy]] trade protocol if they encounter issues during a trade. Mediators cannot control user funds and have no direct enforcement powers. However, if a trader is behaving poorly (e.g., attempting scams), mediators can provide information to Moderators, who may then ban users for severe or repeated violations of trade rules.
  
 
=== Moderator ===
 
=== Moderator ===
  
−
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 help ensure the smooth operation of the [[Bisq Easy]] trade protocol in [[Bisq 2]]. Their responsibilities include:
  
−
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).
+
* Monitoring offers to remove spam.
 +
* Handling reports from users or mediators regarding violations of [[Bisq Easy]] rules.
 +
* Investigating potential violations.
 +
* Banning user profile IDs found to be in violation.
 +
* Flagging chat messages that violate communication rules.
  
−
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.
+
Note: Due to [[Bisq 2]]'s support for multiple identities, banning a profile ID may have limited effect, as users can potentially create new profiles.
  
−
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.
+
=== Security Manager ===
  
−
If spam becomes a problem we might add protection with proof of work and/or reputation features.
+
The Security Manager role is similar to the "filter operator" role in Bisq 1. Key functions include:
  
−
=== Security manager ===
+
* Publishing data to block malicious or malfunctioning roles/nodes.
 +
* Halting trading for specific protocols during critical security incidents.
 +
* Broadcasting alert messages to the network or specific users.
  
−
Similar to Filter operator in Bisq 1. Can publish data to block other roles/nodes and other security related things (block trading). User can deactivate per program argument security manager, so the security manager has reduced power.
+
Users retain control, as they can choose to deactivate the security manager's filtering influence or ignore alerts if they wish. Alert types include:
  
−
The security manager can broadcast a alert message to the network or to specific users. Alerts can be ignored by the users should they wish.
+
* '''INFO:''' Informational popup message.
 +
* '''WARN:''' Warning popup message.
 +
* '''HALT_TRADE:''' Custom emergency popup message that disables trade operations for a specified protocol.
 +
* '''BAN:''' Broadcasts data about a banned role (no text message).
  
−
The types of alters include:
+
=== Update Manager ===
  
−
* INFO (info popup with a text message)
+
The Update Manager (or Release Manager) broadcasts notifications about new software versions to the network. Notification types include:
−
* WARN (warn popup with a text message)
 
−
* HALT_TRADE (custom emergency popup with a text message and disable all trade operations for the defined trade protocol)
 
−
* BAN (no text message, data of the banned role)
 
  
−
=== Update manager ===
+
* '''PRE_RELEASE:''' Notifies users about new pre-releases (users can opt-in via settings; default is off).
 +
* '''RELEASE:''' Notifies users about a new official release.
 +
* '''FORCED_UPDATE:''' Displays a warning popup about a mandatory update to a minimum required version. Trade operations may be halted until the user updates.
  
−
The release manager can broadcast a update notification to the network.
+
== Delegable Roles ==
  
−
The types of notification types include:
+
Delegable roles perform tasks based on publicly available data and do not need to maintain consensus with other peers. Any user can potentially operate these roles themselves, often configured via JVM arguments.
  
−
* PRE_RELEASE: Send update notification for new pre-release (user can enable to get notified about pre-releases in settings, default is off).
+
=== Seed Node ===
−
* RELEASE: Send update notification about a new release.
 
−
* FORCED_UPDATE: Warn popup with a text message about the need for update to the required min version. All trade operations will be halted until updated.
 
  
−
== Delegable roles ==
+
Seed nodes serve as initial contact points for the P2P network. They provide network routing information and filtered Bitcoin blockchain data to new nodes joining the network or light clients. When a Bisq node starts, it contacts several seed nodes to sync network data. At least one hardcoded (root) seed node is necessary for bootstrapping the network.
  
−
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.
+
=== Oracle Node ===
  
−
=== Seed node ===
+
[[Bisq 2 Roles|Oracle nodes]] provide essential data services bridging Bisq 1 information and Bisq 2 functions. There must always be at least one operational oracle node. Services include:
  
−
Seed nodes act as providers for the P2P network data and filtered blocks from the Bitcoin blockchain for lite nodes. When a node starts, it requests all P2P network data from several seed nodes.  
+
==== DAO Bridge Service ====
 +
This service retrieves [[Introduction to the DAO|DAO]] data (like bond status and reputation events - BSQ burns/bonds) from a Bisq 1 API and broadcasts it reliably to the [[Bisq 2]] network.
  
−
There must be at least one hard coded (root) seed node.
+
* '''Verification:''' Users can independently verify the integrity of this data by querying a Bisq 1 API node themselves. If discrepancies suggesting intentionally incorrect data are found and reported, a DAO proposal can be made to confiscate the offending oracle operator's bond.
  
−
=== Oracle node ===
+
==== Reputation Service ====
 +
This service retrieves data relevant to reputation sources like Bisq 1 [[Account_limits|account age and signed account age]] via a Bisq 1 API and broadcasts it to the [[Bisq 2]] network.
  
−
Oracle nodes provide three services. There always has to be at least one oracle node.
+
==== Time-Stamping Service ====
 +
This service provides timestamps used for calculating the age of [[Bisq 2]] user profiles.
  
−
==== DAO bridge service ====
+
=== Explorer Nodes ===
  
−
The DAO bridge service requests DAO data from a Bisq 1 API and broadcasts the relevant data to the Bisq 2 network. This data is required to verify bonded roles and for reputation sources (Users that have burned BSQ or bonded BSQ).
+
Explorer nodes provide information about blockchain transaction states, used during the trade process. For example, they might inform users when a Bitcoin payment transaction receives sufficient confirmations.
  
−
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.
+
=== Market Price Node ===
  
−
==== Reputation service ====
+
Market Price Nodes supply current market price information (e.g., BTC/USD, BTC/EUR) used for setting offer prices relative to the market. Because trades rely on this data, operators of these nodes are required to be bonded.
  
−
The reputation service request data from Bisq 1 via an API for reputation sources (account age and signed account age witness) and broadcasts the relevant data to the Bisq 2 network.
+
== Becoming a Bonded Role Holder in Bisq 2 ==
  
−
==== Time-stamping service ====
+
Contributors performing bonded roles are typically established Bisq contributors who have been formally approved by the [[Introduction to the DAO|DAO]] through a voting process. This ensures accountability for these critical network functions.
  
−
The time-stamping service provides a time-stamping function for profile age of Bisq 2 users.
+
The general process is:
  
−
=== Explorer nodes ===
+
1.  A potential contributor creates a proposal outlining their intention and qualifications for a specific role on the [https://github.com/bisq-network/proposals/issues Bisq GitHub Proposals Repository].
 +
2.  The proposal is discussed publicly within the community on the GitHub issue.
 +
3.  If there is rough consensus, the contributor then creates a formal "Bonded Role Proposal" within the Bisq (v1) application. They must have sufficient [[Introduction to the DAO|BSQ]] available to cover the required bond amount for the role.
 +
4.  The proposal is submitted to the [[Introduction to the DAO|DAO]] for stakeholder voting.
 +
5.  If the vote passes, the specified [[Introduction to the DAO|BSQ]] bond is automatically locked, the contributor's role is registered, and they can begin performing their duties. If rejected, the [[Introduction to the DAO|BSQ]] is returned.
  
−
Lookup for trade transactions for informational purpose. Pose little but non-zero risk.
+
For more general information on contributing to Bisq, see the [[Contributor_checklist|Contributor Checklist]]. Note that not all contribution tasks require bonding, providing an easier path for new contributors to get involved and build reputation.
  
−
===Market price node ===
+
== BSQ Bonding for Roles/Nodes ==
  
−
Same as Bisq 1 price nodes.
+
All System and Delegable roles described here require the contributor to lock a [[Introduction to the DAO|BSQ]] bond via a successful [[Introduction to the DAO|DAO]] vote.
  
−
== How does someone get to perform a bonded role in Bisq 2 ==
+
The [[Bisq 2 Roles|oracle node]] plays a key role in verifying that other bonded roles have a valid, active BSQ bond setup. However, the oracle cannot verify itself or the root seed node (due to a "chicken and egg" problem). These root nodes are still required to set up their own BSQ bonds independently.
  
−
Contributors for the roles are usually have established Bisq contributors that have been approved by a DAO vote to perform a certain role.
+
The bonding process is transparent. Any user can manually verify the status of bonds for roles/nodes through the [[Introduction to the DAO|DAO]] section of the Bisq 1 application.
  
−
For increased security a contributor must make a proposal to become a contributor for a specific role that is voted on by the Bisq DAO. If the vote is successful that a BSQ bond will be locked up automatically for that contributors specific role.
+
== Confiscation of BSQ Bonds ==
  
−
The process for performing a role in Bisq 2 is usually as follows:
+
If a contributor operating a bonded role acts maliciously or harmfully, any community member can propose the confiscation of their [[Introduction to the DAO|BSQ]] bond.
  
−
# A potential contributor posts a proposal to [https://github.com/bisq-network/proposals/issues Bisq GitHub Proposals Repository] putting their case forward for performing a certain role for Bisq.
+
The confiscation process is as follows:
−
# The proposal is discussed on the GitHub issue.
 
−
# Once there is rough consensus for the proposal to be accepted the potential contributor then makes a proposal for a bonded roles from the Bisq application. They would need to ensure that they have enough BSQ available for the BSQ bond.
 
−
# The proposal is put to the Bisq DAO for voting. If the proposal is accepted the BSQ bond is locked and the user can then work in their new role. If the proposal is rejected the BSQ is returned to the user that made the proposal.
 
  
−
For more information on becoming a contributor for Bisq see the [[Contributor_checklist|Contributor Checklist]].
+
1.  A user posts a proposal on the [https://github.com/bisq-network/proposals/issues Bisq GitHub Proposals Repository], detailing the harmful behavior and rationale for confiscation.
 +
2.  The proposal is discussed publicly, allowing the bondholder an opportunity to respond.
 +
3.  If rough consensus for confiscation is reached, the user requesting confiscation creates a formal "Confiscate Bond Proposal" in the Bisq 1 application.
 +
4.  The proposal is submitted to the [[Introduction to the DAO|DAO]] for stakeholder voting.
 +
5.  If the vote passes (meeting high thresholds detailed below), the bond is burned (destroyed), the role is unregistered, and the contributor loses their bond and ceases performing the role. If rejected, no action is taken.
  
−
Not all roles require bonding so it is often easier to get started on a non-bonded role and develop your reputation prior to contributing for a role that requires bonding.
+
Confiscating a bond is a significant penalty reserved for serious offenses. To prevent misuse, the [[Introduction to the DAO|DAO]] requires exceptionally high support for confiscation proposals:
 +
* Minimum Quorum: 200,000 BSQ participating in the vote.
 +
* Minimum Acceptance: 85% approval (compared to >50% for typical proposals).
  
−
== BSQ bonding for roles/nodes ==
+
This system minimizes the risk of misbehavior in high-trust roles while providing a community-driven mechanism for accountability. For more background, see [[Introduction_to_the_DAO#Ensure_honesty_in_high-trust_roles|Ensuring honesty in high-trust roles]].
−
 
 
−
All roles/nodes require a BSQ bond and DAO voting.
 
−
 
 
−
The oracle node verifies that all Bisq 2 bonded roles/nodes have a BSQ bond setup.
 
−
 
 
−
Their are 2 nodes that cannot be verified by the oracle node. These are the root seed node and the root oracle node (as this would present a chicken and egg problem).
 
−
 
 
−
Both these root nodes however are required to have also their own BSQ bond set up.
 
−
 
 
−
The bonding process is transparent all users are able to manually verify that all bonded roles / nodes have valid BSQ bonds. This is can be done though the DAO section of the Bisq 1 application.
 

Latest revision as of 16:19, 15 April 2025

In Bisq 2, certain network functions and processes rely on contributors who take responsibility for specific bonded roles. These roles require locking BSQ as a bond, approved by the DAO, ensuring accountability and security for the network's decentralized infrastructure.

There are two main types of bonded roles in Bisq 2: System Roles and Delegable Roles.

System Roles

System roles must be performed by the specifically authorized contributor approved by the DAO. For security reasons, these roles cannot be delegated to others.

Mediator

Mediators in Bisq 2 primarily assist users of the Bisq Easy trade protocol if they encounter issues during a trade. Mediators cannot control user funds and have no direct enforcement powers. However, if a trader is behaving poorly (e.g., attempting scams), mediators can provide information to Moderators, who may then ban users for severe or repeated violations of trade rules.

Moderator

Moderators help ensure the smooth operation of the Bisq Easy trade protocol in Bisq 2. Their responsibilities include:

  • Monitoring offers to remove spam.
  • Handling reports from users or mediators regarding violations of Bisq Easy rules.
  • Investigating potential violations.
  • Banning user profile IDs found to be in violation.
  • Flagging chat messages that violate communication rules.

Note: Due to Bisq 2's support for multiple identities, banning a profile ID may have limited effect, as users can potentially create new profiles.

Security Manager

The Security Manager role is similar to the "filter operator" role in Bisq 1. Key functions include:

  • Publishing data to block malicious or malfunctioning roles/nodes.
  • Halting trading for specific protocols during critical security incidents.
  • Broadcasting alert messages to the network or specific users.

Users retain control, as they can choose to deactivate the security manager's filtering influence or ignore alerts if they wish. Alert types include:

  • INFO: Informational popup message.
  • WARN: Warning popup message.
  • HALT_TRADE: Custom emergency popup message that disables trade operations for a specified protocol.
  • BAN: Broadcasts data about a banned role (no text message).

Update Manager

The Update Manager (or Release Manager) broadcasts notifications about new software versions to the network. Notification types include:

  • PRE_RELEASE: Notifies users about new pre-releases (users can opt-in via settings; default is off).
  • RELEASE: Notifies users about a new official release.
  • FORCED_UPDATE: Displays a warning popup about a mandatory update to a minimum required version. Trade operations may be halted until the user updates.

Delegable Roles

Delegable roles perform tasks based on publicly available data and do not need to maintain consensus with other peers. Any user can potentially operate these roles themselves, often configured via JVM arguments.

Seed Node

Seed nodes serve as initial contact points for the P2P network. They provide network routing information and filtered Bitcoin blockchain data to new nodes joining the network or light clients. When a Bisq node starts, it contacts several seed nodes to sync network data. At least one hardcoded (root) seed node is necessary for bootstrapping the network.

Oracle Node

Oracle nodes provide essential data services bridging Bisq 1 information and Bisq 2 functions. There must always be at least one operational oracle node. Services include:

DAO Bridge Service

This service retrieves DAO data (like bond status and reputation events - BSQ burns/bonds) from a Bisq 1 API and broadcasts it reliably to the Bisq 2 network.

  • Verification: Users can independently verify the integrity of this data by querying a Bisq 1 API node themselves. If discrepancies suggesting intentionally incorrect data are found and reported, a DAO proposal can be made to confiscate the offending oracle operator's bond.

Reputation Service

This service retrieves data relevant to reputation sources like Bisq 1 account age and signed account age via a Bisq 1 API and broadcasts it to the Bisq 2 network.

Time-Stamping Service

This service provides timestamps used for calculating the age of Bisq 2 user profiles.

Explorer Nodes

Explorer nodes provide information about blockchain transaction states, used during the trade process. For example, they might inform users when a Bitcoin payment transaction receives sufficient confirmations.

Market Price Node

Market Price Nodes supply current market price information (e.g., BTC/USD, BTC/EUR) used for setting offer prices relative to the market. Because trades rely on this data, operators of these nodes are required to be bonded.

Becoming a Bonded Role Holder in Bisq 2

Contributors performing bonded roles are typically established Bisq contributors who have been formally approved by the DAO through a voting process. This ensures accountability for these critical network functions.

The general process is:

1. A potential contributor creates a proposal outlining their intention and qualifications for a specific role on the Bisq GitHub Proposals Repository. 2. The proposal is discussed publicly within the community on the GitHub issue. 3. If there is rough consensus, the contributor then creates a formal "Bonded Role Proposal" within the Bisq (v1) application. They must have sufficient BSQ available to cover the required bond amount for the role. 4. The proposal is submitted to the DAO for stakeholder voting. 5. If the vote passes, the specified BSQ bond is automatically locked, the contributor's role is registered, and they can begin performing their duties. If rejected, the BSQ is returned.

For more general information on contributing to Bisq, see the Contributor Checklist. Note that not all contribution tasks require bonding, providing an easier path for new contributors to get involved and build reputation.

BSQ Bonding for Roles/Nodes

All System and Delegable roles described here require the contributor to lock a BSQ bond via a successful DAO vote.

The oracle node plays a key role in verifying that other bonded roles have a valid, active BSQ bond setup. However, the oracle cannot verify itself or the root seed node (due to a "chicken and egg" problem). These root nodes are still required to set up their own BSQ bonds independently.

The bonding process is transparent. Any user can manually verify the status of bonds for roles/nodes through the DAO section of the Bisq 1 application.

Confiscation of BSQ Bonds

If a contributor operating a bonded role acts maliciously or harmfully, any community member can propose the confiscation of their BSQ bond.

The confiscation process is as follows:

1. A user posts a proposal on the Bisq GitHub Proposals Repository, detailing the harmful behavior and rationale for confiscation. 2. The proposal is discussed publicly, allowing the bondholder an opportunity to respond. 3. If rough consensus for confiscation is reached, the user requesting confiscation creates a formal "Confiscate Bond Proposal" in the Bisq 1 application. 4. The proposal is submitted to the DAO for stakeholder voting. 5. If the vote passes (meeting high thresholds detailed below), the bond is burned (destroyed), the role is unregistered, and the contributor loses their bond and ceases performing the role. If rejected, no action is taken.

Confiscating a bond is a significant penalty reserved for serious offenses. To prevent misuse, the DAO requires exceptionally high support for confiscation proposals:

  • Minimum Quorum: 200,000 BSQ participating in the vote.
  • Minimum Acceptance: 85% approval (compared to >50% for typical proposals).

This system minimizes the risk of misbehavior in high-trust roles while providing a community-driven mechanism for accountability. For more background, see Ensuring honesty in high-trust roles.

Retrieved from "https://bisq.wiki/index.php?title=Bisq_2_Roles&oldid=3957"