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

Research on solutions for DIDs (decentralized IDs) in Bisq #55

Open
eyalron33 opened this issue May 1, 2021 · 2 comments
Open

Research on solutions for DIDs (decentralized IDs) in Bisq #55

eyalron33 opened this issue May 1, 2021 · 2 comments
Labels
a:proposal bisq.wiki/Project_management#Proposal needs:triage bisq.wiki/Project_management#Triage

Comments

@eyalron33
Copy link

Description

Research on solutions for DIDs (decentralized IDs), The proposal is to create a document that includes a market survey, the current state of IDs in Bisq, and one or more proposals for protocols for DIDs in Bisq, considering Bisq needs and capabilities.

Rationale

A core idea proposed for future versions of Bisq is "social tradings", see bisq-network/proposals#330 and #51 . Any kind of social interaction in a decentralized platform like Bisq needs a clear, easy way for users to maintain and manage their IDs.

The current Bisq treatment of user IDs is almost ad-hoc, including onion IDs and account age witnesses. At the same time, there was plenty of progress in DIDs (decentralized IDs) in the last few years, including various blockchain projects, and W3C SPECs focusing specifically on DIDs.

The proposal here is to research the state-of-the-art, survey possible solutions for DIDs, and create one or more proposals of how DIDs can be integrated explicitly into Bisq, considering Bisq needs and technology. Knowing the unique requirements of Bisq and how previous solutions were made for it, I imagine that most of the proposals would not be a "straightforward" adaptation of existing technology, but more tailored solutions for Bisq needs, based on existing ideas.

No matter which future direction Bisq ends up taking, having DIDs as a tool opens new directions to which Bisq can head.

This proposal was raised following a discussion considering what I wrote about DIDs in #51 (comment).

Criteria for delivery

  • A research document that includes:

    • current state of IDs in Bisq (even if it is informal or implicit),
    • a market survey of the current state of the art which is relevant to Bisq,
    • a few proposals of DIDs fitting Bisq needs based on the market survey.
  • Creating one or more proposal for DIDs in Bisq, and leading a discussion about them

  • The scope of the different solutions should include:

    • privacy,
    • blockchain agnostic if possible,
    • user-friendly (UX)m
    • easy integration into Bisq.

Measures of success

The provided results are considered sufficient for choosing one proposed solution to be used as a base for an RFC.

Risks

  • Proposed solutions are not adapted by Bisq

Tasks

  • [] Summarize the current state of IDs in Bisq.
  • [] Market research on state-of-the-art DID solutions.
  • [] Create several proposed solutions for Bisq.
  • [] Communicate proposals with Bisq contributers.
  • [] Write up the proposed documents, including Bisq's current state, market research, and proposed solutions.
  • [] (optional) Create basic RFC, though maybe this needs to be in a future proposal that would follow more community discussion of which is the preferred solution.

Estimate

The work should take about 3 weeks and cost 3k USD.

Notes

A bit myself. I was involved in Bisq, under the nickname Neiman, from the end of 2017 till the release of Bisq DAO in 2019.

I was mostly involved in the design of Bisq protocols, such as the design of the Bisq DAO algorithms and the current trading protocol. You can see a document I wrote back putting the Bisq DAO into a theoretical abstract computer science framework (here, or lectures I gave about Bisq (Fosdem, Amsterdam Bitcoin Wednesday) at the time.

@eyalron33 eyalron33 added a:proposal bisq.wiki/Project_management#Proposal needs:triage bisq.wiki/Project_management#Triage labels May 1, 2021
@chimp1984
Copy link

chimp1984 commented May 1, 2021

Just a few notes to avoid potential confusion:
The intended identity system is fully under control of the user. The user can choose between maximal privacy (appear always like a new users with zero reputation/fresh identity) or an identity used for reputation which enables new features like usage for trade protocols, access to certain features without financial cost.

Any permissionless and open system needs to protect against abuse. This protection can be achieved by different means.
If no reputaton is in place financial costs or proof of work are the best protection against abuse. To avoid such costs (e.g. bonds, security deposits, fees) users can choose to provide some sort of reputation based on identity (e.g. a key pair).

Current Bisq has several forms of identity/reputation:

  • Onion address is currently global and re-used (we want to avoid that in Bisq 2.0)
  • Public signature and encryption keys are global (we want to avoid that in Bisq 2.0)
  • Account age and account age witness (only used for fiat accounts where it is enabled)
  • Local reputatiuon based on the onion address and past trades (see number of past trades, tag trader, block trader)
  • Merit in the DAO (past earned BSQ of contributors)
  • Bonded reputation in DAO
  • Bonded roles in DAO (for contributors taking a bonded role)
  • Burned BSQ used as reputation
  • P2P network internal peer management (a node which produces too much traffic or invalid messages gets limited or blocked)
  • And informal reputation via the different platforms used in the project (keybase, Github, Forum,....)

For protection of the p2p network proof of work is considered as further dos protection, thought that might have limitations (mobile use case) and an access token based approach is considered as well. So if the node cannot generate enough pow an access token can be used instead (e.g. based on BSQ bond/fee or some other model).
Other intended features like chats, allowing users to add custom payment methods, assets, contracts,... require protection against abuse as well.
And finally it will allow new trade protocols with a lower security but with lower costs and higher convenience.

All those things will be optional. Users still can use Bisq with high security protocols only and either have limited access to those new features (chat) or only read access. And Bisq 2.0 will fix a few privacy issues present in the current Bisq model (global onion address and keys). So it will increase privacy, make it more censorship resistant and optionally allows users who prefer cheaper trade protocols options to trade off some level of privacy with convenience/lower costs.

@chimp1984
Copy link

As identity will play a key role in the p2p network layer I can share my preliminary view on it.

An identity is a key pair. For most cases and network it includes also the network address(es) (onion address, i2p address).
Each interaction (take offer) comes with its own isolated new identity. So taking 2 different offers from the same maker will appear as its 2 independent traders if both use the strict mode to isolate each trade.
The user can manage their identities and can decide to prefer reputation-based features which will require to re-use identity for building up reputation (e.g. like in current Bisq where you can see you have traded x times with same trader, thus giving some level of security that this user is likely not a scammer).
User will be also able to attach more meta data to an identity like their social media account if they wish to do that. They get informed about the trade offs between privacy <-> reputation but they can make their choices.

Maybe there will be possible more complex featueres where a signature of one identity can be used as backing security for another identity, similar as in the account age witness model. But that needs more thoughts.
There might be also options to re-gain privacy by using cryptographic techniques like blind signatures, but again that will require more time to figure out how this could be used in that context.

So basics from my side:

  • Identity is 100% user controlled and can be customized to different use cases.
  • Default is each interaction appears like a fresh identity.
  • Other extreme of the spectrum is that the user uses only 1 global identity and connects that even to outside real-life or semi-real life identities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:proposal bisq.wiki/Project_management#Proposal needs:triage bisq.wiki/Project_management#Triage
Projects
None yet
Development

No branches or pull requests

2 participants