Skip to content
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

Add Entitlement verifications #68

Closed
chimp1984 opened this issue Feb 6, 2022 · 2 comments · Fixed by #92
Closed

Add Entitlement verifications #68

chimp1984 opened this issue Feb 6, 2022 · 2 comments · Fixed by #92

Comments

@chimp1984
Copy link
Contributor

For the social trading features we use entitlements.
An entitlement is the right to execute certain roles.

Here the enum entries and descriptions (provided numbers are TBD):

LIQUIDITY_PROVIDER=Liquidity provider as BTC Seller 
  Requirement: Burn at least 50 BSQ/DAO cycle for earning reputation
CHANNEL_ADMIN=Channel administrator 
  Requirement: Bonded DAO role as channel administrator
CHANNEL_MODERATOR=Channel moderator 
  Requirement: Invitation from the channel owner and burn 100 BSQ/DAO cycle. 
  Entitled to make a compensation request for 500 BSQ/DAO cycle
MEDIATOR=Mediator 
  Requirement: Bonded DAO role as mediator

There are 2 types for providing proofs: Burned BSQ and bonded roles.

For adding an entitled role to a user profile one need to fulfill the requirements of the role.

Process for burned BSQ is:

User starts to create new user profile. They get displayed the pubkey hash when they have choosen a robo hash icon.
Next they copy that pubkey hash, open Bisq1 DAO section at proof of burn and paste it as pre-image for the proof of burn tx.
They need to burn at least the required amount.
They publish the tx wait until the tx is confirmed.
After that they copy the tx ID and move back to Bisq 2 to paste it into the proof input text field and click the Verify button.
This triggers a request to BSQ explorer(s) and returns the tx data. If its a valid BSQ tx and the opReturn data matches the pubkey hash everything is correct and the txId gets attachted to the entitlement data and the entitlement role added to the user profile.
The user could add multiple different entitled roles.

After having created the user profile the entitled role is part of the profile and can be verified by other users.

Verification of proof of burn based entitlement:

Request the tx ID taken from the peers public user profile data from a BSQ explorer.
Check the opReturn data if it matches the pubkey hash. If so the linkage of the pub key to the burned BSQ is correct.
Any interaction with the peer is based on the key pair from which the pub key is derived, so any relevant interaction will only work if the pubkey was not fake. Such interactions are private signed and encrypted messages and data added to the P2P network like offers or chat messages. It must not be possible to use a foreign pubkey hash and publish data to other users.

For entitlements based on bonded roles the process is as follows:

Before creating a new user profile the user need to do a DAO request for a bonded role. We will likely re-use existing roles like Forum admin for the channel admin role or the current mediator role for mediators in the social trading area (there can be overlap of mediators who cover both areas).
We need to add a signing and verification tool for the bonded roles similar as we provide it for proof of burn.
With that tool the bonded role owner can sign their Bisq 2 pubkey hash and use the signature as provided proof next to the tx ID of the bond request tx.

For verifying the user can request the tx data from a BSQ explorer, take the EC pub key from the first BSQ input and verify the provided signature with that pub key hash of the user profile.

Once the DAO is integrated into Bisq 2 those explorer requests are not required anymore.

Here a screenshot of the WIP screen:

Screenshot 2022-02-05 at 20 52 43

@chimp1984 chimp1984 changed the title Add BSQ explorer lookup Add Entitlement verifications Feb 6, 2022
@ghost ghost self-assigned this Feb 6, 2022
@UX-P
Copy link

UX-P commented Feb 7, 2022

Next they copy that pubkey hash, open Bisq1 DAO section

Just to go over the exact landing pages for the BSQ burn process.
The user will copy the public hash key and be directed from Bisq 2 'user profile' to the Bisq 1 'proof of burn' landing page, without the user having to manually open Bisq 1.
Once the tx is confirmed, a button on the Bisq 1 'proof of burn' landing page will redirect the user to the profile page where they are required to paste the tx ID.
This route encourages a seamless user journey, does this work well in a technical prospective?

@chimp1984
Copy link
Contributor Author

Just to go over the exact landing pages for the BSQ burn process. The user will copy the public hash key and be directed from Bisq 2 'user profile' to the Bisq 1 'proof of burn' landing page, without the user having to manually open Bisq 1.
Once the tx is confirmed, a button on the Bisq 1 'proof of burn' landing page will redirect the user to the profile page where they are required to paste the tx ID. This route encourages a seamless user journey, does this work well in a technical prospective?

That is not easily doable as the users Bisq installation might vary and it would need to check if Bisq 1 is open...
The features where a user used Proof of burn or bonded roles are for experienced Bisq traders who have to be already familiar with Bisq and the DAO. Newbies do not need to touch those areas. So I think its ok to just give them instructions and they follow those.
Also the DAO will be integrated in Bisq 2 at some point and then we can easily navigate to the required screens inside Bisq 2. But as it will be some considerable effort to get the DAO integrated in Bisq 2 and its not a core requirement we will do that a bit later, so we need that intermediate solution with Bisq 1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants