/cc @bisq-network/support-agents (so everyone is aware of this work in progress)

Delivery criteria

• Wiki documentation of the case tracking process is complete
• All support agents understand how to track their cases and are actually doing so
• Script(s) exist that process closed support case issues and produce the simple metrics discussed in the Q1 2020 Update call (#5), including:
  • Support cases per cycle
  • Support cases per trade
  • Mean time to response
  • Mean time to resolution
  • Support cases per known issue / critical bug (this one is probably not scriptable per se, but a process can be put in place to make getting the information feasible)

Tasks

• Decide to use bisq-network/support repo issues for tracking
• Announce this decision in the support team kickoff call (#19)
• Create support repo Case Tracking project board
• Automate adding newly created issues to the Case Tracking Board (#6)
• Give @bisq-network/support-agents Triage access to the support repo
• Experiment with issue title formats and encrypting sensitive data contents with Keybase (#7)
• Define metadata fields for programmatic parsing of closed support cases (bisq-network/support#336)
• Create new support case issue label in the support repository
• Create support case issue template containing the metadata fields mentioned above, and YAML front matter that labels issues as 'support case' (bisq-network/support#336)
• Figure out a dead-simple way that all support agents can quickly convert their local time in keybase to UTC/zulu time to copy and paste into the date metadata fields of each new issue
• Create a short screencast showing how to follow the case tracking process (@cbeams)
• Finish documenting the process for tracking support cases on the Support Agent wiki page
  • Include a link to the screencast
• Get bisq-network/admin#18 (wiki notifications) implemented
• Send a message to @bisq-network/support-agents linking to the wiki and asking everybody to read it and take action, and to please 👍 this message to indicate you got it and will do. Mention / link to the screencast. Ask to respond with any questions or feedback, and to make edits to the wiki as appropriate (#18 needs to be done first!). Also ask agents to #reference this issue when they create their first case tracking issue, so we can easily realize when the task immediately following below is finished.
• Leave this issue open until all current @l1-support-agents and @intern-support-agents have created at least one support case issue correctly
  • @bisq-knight
  • @leo816
  • @huey735
  • @mwithm
  • @bayernator
  • @wiz (?)
  • @m52go (?)
• Write script / application that queries the GitHub Issues API to produce the metrics listed above in delivery criteria
• Make it a duty of the support team lead role to run that script and report on those metrics every cycle.

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

"In the wake of the Apr 7th security incident, it's clear that we need to take our security practices to the next level. " (cbeams)

The purpose of this project is to create and follow a roadmap to establish a security team in terms of management structure, its duties, authority and responsibilities.

Rationale

I propose and drive the following strategy to get to a point where a "security team" can be effective:

short intro video I will create a short video presentation where I introduce the idea of a security team by taking a look at the past and also by taking a look at the future, what happened already, what will happen eventually. In the course of the presentation I will be asking questions on how such a security team can look like, in terms of definitions, agenda and also how it can integrate with the Bisq DAO.
call agenda I will create a (template) gdoc accompanying the presentation where everyone is welcome to share their thoughts on the questions I asked. This very gdoc will become the agenda for the kickoff-call held week 20/2020.
call The call will have discussions and decisions on the agenda points. One followup call can be held if the discussion needs regrouping. I will host and moderate these calls.
let the DAO decide The outcome of the call(s) is going to be formed into a Bisq proposal ready to be accepted or rejected by the Bisq DAO in cycle 13 (around May 20th, 2020).
done If and only if the DAO approves the proposal, the information will be transcribed into the Bisq wiki and the security team can take up its work.

Why should it be done now?

bisq-network/admin#75

Criteria for delivery

• the DAO decided on the security team structure
• if it is decided that there is a security team similar to Dev/Growth/Ops/Support, then
  • create a proposal in bisq proposals
  • deliver a Team description in the bisq wiki
  • include duties
  • include authorities
  • include responsibilities
  • include an agenda covering short, mid and long term goals

Tasks

• create gdocs to hold agenda for the kickoff call
• create and publish kickoff presentation
• schedule and hold kickoff call
  - [ ] schedule and hold follow-up call if necessary
• create proposal to be voted on by the DAO to seal the security team
• transcribe contents of approved proposal to Bisq wiki

Notes

I set the labels according to the progress that is already made. Please adjust if necessary. Also, I skipped some headline because it seemed to me that it is already decided that we do this project and cannot guess why the admin team wants the security team.

Description

We have reason to believe that account signing protections rolled out in 2019 have not reached a critical mass of propagation in certain markets and may be impeding liquidity growth. This project exists to assess the actual state of propagation and take actions to improve it where necessary.

Rationale

As it is critical to prevent scam attempts in markets with high liquidity with payment methods with a relatively high charge back risk we need to get the newly introduced account signing into a state where we reach and exceed past trading volumes again.

Criteria

Based on the account signing evaluation I see this project delivered when we reach following goals in our major markets (EUR, USD) within the next three months:

• 75% of offers in offer book are made with signed accounts
  • USD (Zelle)
  • EUR (SEPA, SEPA Instant)
• 50+% of trades are above 0.01 BTC
  • USD (Zelle)
  • EUR (SEPA, SEPA Instant)

Tasks

• @ripcurlx to evaluate current state of account signing propagation (bisq-network/admin#10)
• @ripcurlx to evaluate current account signing process to find UX issues
• @ripcurlx to write up plan / tasks necessary to improve account signing propagation where necessary (UI/UX)
• @ripcurlx to write up plan / tasks necessary to improve account signing propagation where necessary (Signing process)

Estimates

Will be posted as soon as required tasks are clear to make this project a success.

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

A lightweight and stable monitor for seed nodes to detect if a seed node is not in the expected state. Instead of requesting the data itself (which is pretty heavy) we request an inventory list with the number of p2p data objects as well as other relevant data. We include also some performance and load specific data.
When a seed node is not in the expected state it sends an alert/notification to the operator.

Rationale

We have 2 monitor projects [1], [2] (as well a ping monitor used by @wiz) for monitoring seed nodes. But both do not provide the quality that it can be used for notifications as they produce too many false positives. Also those monitor projects request all the data causing heavy load for the seed nodes and the monitor itself, which is probably the main reason why they are not as stable as they should be.

Criteria for delivery

Notifactions for real problems is the main goal we need to achieve.

It is alreay implemented in a basic form. See below the open tasks we want to add.
Current URL: http://46.101.179.224/
Source: https://github.com/chimp1984/bisq/tree/add-InventoryMonitor-module

Measures of success

Very low rate of false positives for notifications. It cannot be excluded that some alerts might be caused by not critical reasons due the nature of the data and uncertainties with blockchain related behaviour. See below at the data type and priority descriptions for more context.

Risks

I don't see any risk here. In the opposite the current monitors cause heavy load and with that risk for seed nodes. Once that project is completed we can shut down http://104.248.88.175 and maybe consider to remove the p2p data requests from https://monitor.bisq.network to reduce seed node load.

Tasks

• Rethink the file name strategy for json files. Json files are written with the timestamp in ms as file name. A better approach for dealing with historical data would be to use a global persisted counter and use that as file name.
• Add checks for data deviations (get average data of all seeds per request and compare individual how far it is away from average. maybe use past requests as well for certain data?). Apply level of warning/alert
• Add notification via keybase for alerts. First use a new custom channel to not spam ops while developing. Once false positive rate is low enough point to ops
• Add web app reading the json data and displaying recent request results
• Add a sub view (on top) with compressed warnings/alerts info. Should be empty most of the time (e.g. "all seeds are ok").
• Add support for displaying historical data. Show the warnings/alerts info summary seems to be the most important.
• Add button to zoom into a request cycle to see details data
• Remove http server from java app once not needed anymore

Estimates

I will delay all my comp. requests until Bisq is more profitable, so from my side there is no budget needed.
@jmacxx : 500 USD (#45 (comment))

Notes (following is copied over from original post)

High level concept:

Instead of requesting the data and then check if all seeds deliver the expected data we add a new request message and the seeds tells us how many objects per data type they have (as well as some other data). This reduces load from 8 MB (we had to exclude the largest data as it would have been much more then) to a few kb. It also does not require that the monitor runs the full Bisq code base but only a tor node and only need to understand the messages which do not contain domain specific dependencies, so its very lightweight both for monitor and seeds.

Goal:

Goal is to get a reliable monitor which can be used for alerting operators if a seed is not in the state it should be.
To achieve that we try to be lightweight and keep things as simple as possible. Flexibility to add new metric types is a goal as well. UI should provide a quick overview, so that with a quick look at it one can see if all is ok, or if there are issues with any seed.

With the https://monitor.bisq.network/ project that goal was never met as false positive rate and instability of the monitor made it impossible to use it for that purpose.

This project is not aiming to compete with feature richness and sophisticated UI of https://monitor.bisq.network. It is intended for devs and operators not for users, thought it is public and users can see it as well, but it is not a goal that it is user-friendly for people who are not familiar with the context.

Current state:

Currently we write html data and provide it via a simple http server inside the monitor app (in java). Parallel we write json data for each response. The data are a hash map of string keys and string values to be flexible for future changes and updates. Type conversion from string to integer or long need to be done per key type. Flexibility is here preferred over type safety.

Example json:

"requestStartTime": 1602948574936,
  "responseTime": 1602948576319,
  "inventory": {
    "blindVoteHash": "3f3b46ecd254e6d3739f8ef76ca1b2e5db92dc19",
    "BlindVotePayload": "316",
    "proposalHash": "dad7456b93944c10f93325b1f78817a92d579ee9",
    "usedMemory": "890",
    "sentMessagesPerSec": "2.24",
    "TempProposalPayload": "66",
    "numConnections": "30",
    "MailboxStoragePayload": "585",
    "AccountAgeWitness": "64253",
    "jvmStartTime": "1602932539817",
    "TradeStatistics3": "76325",
    "receivedMessagesPerSec": "12.86",
    "numBsqBlocks": "81436",
    "daoStateHash": "3fbc3417575aa125c191d69d4ee00b25910d44a2",
    "RefundAgent": "1",
    "Filter": "2",
    "sentData": "639.861 MB",
    "ProposalPayload": "514",
    "receivedData": "939.049 MB",
    "Mediator": "3",
    "Alert": "1",
    "OfferPayload": "437",
    "SignedWitness": "4588",
    "daoStateChainHeight": "653182"

Currently there are 7 seed nodes updated to provide those data and we request every 5 minutes.

Priorities per data types

Prio 1:

blindVoteHash, proposalHash need to be the same for all seed nodes at the blocks when those get set (I need to look up when that is and it would be good to add those blocks to the hashmap).
daoStateHash needs to be the same for all seeds with the same block. Changes with each block.
If any of those data is not matching its a severe failure and the op need to be alerted.

Deviation of numBsqBlocks and daoStateChainHeight must be in low range. It is super rare that > 3 blocks are created in very short time. So I would suggest deviation of > 3 blocks is an alert. Still could be valid case but a look up in blockexplorers will resolve that for ops.

Prio 2:

Mediator and RefundAgent must not be 0 (thought RefundAgent could be theoretically). If not its severe error.

Prio 3:

Mediator and RefundAgent should be the same most of the time. Only when a mediator revokes or get added there might be a difference as some seeds might get it earier then others. Those events are vary rare.
Similar is true for Filter and Alert. They should be the same most of the time, just when new ones get published deviation is expected but even then rather rare.

Prio 4:

ProposalPayload, BlindVotePayload and TempProposalPayload should be the same most of the time. Here its a bit more complex as after a certain block those data cannot be added anymore so that they are valid for the DAO, thought technically they can be added. I would suggest to accept low level of deviation (e.g. 10%) but should some color if the data is not the same as that is the 95% case.

Prio 5:

SignedWitness, AccountAgeWitness, MailboxStoragePayload, TradeStatistics3: Those get added all the time but at a low pace. Deviations of < 10% are normal. > 30% should be considered as error.

Prio 6:

OfferPayload gets added and removed all the time. If a big marketmaker goes online/offline it is expected that 100 offers or more are different. We have about 300-550 offers. As far I observed it is rare that deviation is > 100. I would suggest deviation < 10% is normal. 10 - 30% is light warning but still can be a valid case. 30 - 50% should get a severe warning but still no alert. > 50% should send alert to op.

Others:

• jvmStartTime: seeds restart once a day: if that time > 1 day and 2 hours send alert.
  usedMemory: So far 500MB - 1 GB seems to be normal. If > 1 GB send warning to op.

• numConnections: depends on maxConnections set by op (we should prob. add the maxCon param, currenty they use 30 but they could use diff. values per seed). If numConnections > 2 x maxConnections send an alert.

• sentMessagesPerSec, receivedMessagesPerSec, sentData, receivedData: Lets obsever a bit normal values and then add alerts if deviation gets larger as usual. Also recent changes in P2P network should lower receivedMessagesPerSec still to get as low as sentMessagesPerSec, might need a while until most users have updated.

[1] https://monitor.bisq.network/
[2] http://104.248.88.175/

This project was initially titled 'Bitcoin 2020' but has been renamed since the Bitcoin 2020 conference has been unexpectedly postponed.

Board: https://grow.bisq.cc/b/jPBBopYuLdGYdDpvF/markets

Description

Bisq growth efforts in recent past have been relatively muted. Aside from documentation, resources to make using Bisq simple have been scarce.

This effort aims to encourage volume in USD, EUR, and XMR throughout the month of March, through a series of content to encourage beginners and lurkers/tire-kickers, bots to promote good offers, and new payment methods to make bigger trades more quickly and easily...capped off with Bitcoin 2020 at the end of the month.

In addition to more volume, the content created with this initiative should serve as a foundation for ongoing growth efforts after March 2020 (more on this below).

Metrics:

• number of offers that go live in 24-hour period (not to be confused with number of offers live at any given moment)
  • goal: 1100; currently 600-700 on average but tops out around 800-900 on good days
• number of trades in 1 day
  • goal: 200; current record is 223 but that was more of an outlier (would like to see 200 trades hit on a more regular basis)
• average number of daily trades for March (would like to see February's average of 100 beat by 15+ percent)
  • goal: 115; previous record 100

Tasks

Content/Communications

• Announce March campaign across Bisq community channels: "Make the Market March" where we encourage all users to make 1 offer on Bisq
  • Running a Bitcoin node validates blocks for the Bitcoin network, but running a Bisq node does no good for the Bisq network without posting an offer.
  • Hammer home idea that Bisq liquidity is built by users - each user is their own source of liquidity to the network! So posting an offer really should be mandatory for anyone running Bisq.
  • Encourage all users to post at least 1 offer on every Thursday in March, hoping to hit higher and higher outstanding offers each week
• Create web page as 1-stop destination with summary of efforts and progress
• Release data on most likely-to-succeed Bisq offers
• Release new video/article/guide every day covering some key aspect of Bisq onboarding questions, trading process, etc.
• Hold calls on Thursdays to cover lingering concerns, objections, and feedback from community as final push for hitting weekly offer goal (sourced from #pulse Keybase channel)
• Loop in key communities like /r/bisq, /r/Bitcoin, /r/Monero, /r/BitcoinBeginners, /r/xmrtrader, etc. in weeks 2-3 to push even harder for higher offer numbers
  • Get in touch with moderators ~2 weeks in advance of desired posting date

Tools (experimental but relatively low-effort)

• Deploy Twitter bot to show off attractive Bisq offers (on a new handle), occasionally retweeting them from the main Bisq account, with aim of reducing time it takes for offers to be taken and thus increasing momentum
• Deploy inline Telegram bot so users can showcase real-time Bisq offer book on-demand in groups

Payment Methods

• Introduce payment methods in v1.2.8 that enable higher trading limits from day 1 of downloading Bisq (higher limits with no signing), multiplying fiat trade sizes and offering a host of additional benefits

Event

Only the magazine is slated to continue as planned...all other event preparations are postponed.

• Design magazine back cover
• Design banner ad designs
  - [ ] Design stickers for distribution at event
  - [ ] Design t-shirts for sale and distribution at the event
  - [ ] Establish details for ID selfie photo booth: what's happening, what do we need to bring, who's bringing, etc
  - [ ] Figure out how we can use the TV at the booth
  - [ ] Collect list of all known contributors and users who will attend
  - [ ] Create plan/schedule for volunteering (key responsibilities) at the event

Project Board

https://github.com/orgs/bisq-network/projects/17

Refer to the project board to track progress of issues and PRs.

Description

The API Project’s scope includes exposing a Core API using gRPC, and serving a Linux / OSX based gRPC CLI and RESTful web clients.

The API should be able to perform all functions now provided by the Bisq desktop UI. The release process is incremental;
approved contributions to the API project will be merged into the main branch as work progresses.

Rationale

The most important justification for a gRPC based API is scaling Bisq to increase trading volume and liquidity. This will be accomplished by supporting trading bots, enabling development of new RESTful HTTP clients, opening opportunities for Bisq integration into products such as myNode, facilitating automated functional testing (narrow and broad), and full end to end testing. Automated testing may also lead to faster improvements to mature, core components now in use by the UI.

Criteria for delivery

As mentioned above, delivery of the API will be incremental, and small bits of the API have already been merged into the main branch.

Before code supporting this simplest trade use case can be merged into the main branch, security risks must be discovered, analyzed and mitigated.

Releasing a programmatic interface to the Bisq protocol presents opportunity and risk; risk analysis must be a priority for each phase of the development / test / release cycle as soon a the API supports any trading on mainnet.

Tasks

The short, near term goal is to demonstrate the minimum, simplest API and gRPC CLI capable of performing all tasks required by a basic trading scenario: protecting a wallet, funding a wallet, creating a payment method, listing offers, creating & taking an offer, through completing the trade protocol and moving received funds to a Bisq wallet. After demonstrating this use case, feedback will be studied, bugs fixed, work on supporting more payment methods will begin, and decisions will be made about the next phase of development.

Some of the work to support the simplest trading use case have been merged into the main branch. Tasks lists used for planning and tracking this work are listed below.

• Implement wallet protection rpc methods
• Implement simplest possible trading script

Currently, an API Test Harness PR is in review. If approved and merged, some polishing will done on the test harness, test cases will be added, and work on the API itself will be restarted.

After the gRPC based CLI is stabilized, passes risk assessments, supports enough features, and is accepted by sufficient numbers of users, work will begin on supporting RESTful HTTP clients. The current plan is to use a go based reverse-proxy / grpc-gateway to transform HTTP 1.1 requests into HTTP 2 (gRPC), and back. (The scope of this project does not include building HTTP RESTful clients.)

History

Earlier discussions are in the comments here .

The earliest proof of concept was merged from PR 3888 .

• @Bisq-knight to add two draft KB articles
• @m52go to take a look, provide any initial editorial feedback
• @cbeams to add category info and announce to @bisq-network/support

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

This is a project proposal to migrate Bisq pricenodes away from using the earn.com fee estimation API in favor of an open-source self-hosted mempool fee estimation API backend, that we can decentralize further by having all Bisq btcnode operators run.

Rationale

Whenever the Bitcoin market sees major price action, trading volume suddenly spikes, which results in a huge rush of new transactions into the Bitcoin mempool, and "next block" fees rise very quickly:

This sudden rise in mempool fees causes a major issue in Bisq whereby any trades taken during the time when the mempool fees start to rise use far too low of a fee, and they do not get confirmed for several hours or even days later, until the mempool clears out. The cause of this issue is that Bisq currently uses Earn.com fee estimation API which is slow and not well maintained. The https://mempool.space backend uses realtime data from Bitcoin nodes, so it is extremely fast to return realtime fee estimates, compared to the Earn.com API which is always lagging behind:

This issue was first reported by @ManfredKarrer in bisq-network/bisq#1077 but at the time, a better mempool fee estimation API service did not exist. But now we have a great open-source and self-hosted solution, the mempool project. Of course I am bias, since I am a maintainer/contributor to this project, but IMO it really is the best mempool project for Bitcoin and we have worked very hard making it so.

Recently during the past few days we have seen this issue reproduce again, and now users are complaining in support that their deposit TX have still not confirmed even after waiting for 12 hours. So therefore I propose that we pull the trigger on ditching Earn.com API once and for all.

Criteria for delivery

After all Bisq pricenodes upgrade to the new code that will query our federated btcnode mempool fee estimation backend service, we can consider it delivered.

Measures of success

After all Bisq nodes start receiving the self-hosted mempool fee data, and users no longer experience this issue due to sudden fee spikes, we can consider it a success.

Risks

I've been running the mempool backend and hosting https://mempool.space for over 6 months, and it has never crashed, so I feel it is quite stable to run in production. However, we could keep Earn.com API as a backup data source to mitigate the risk of any issues with our own self-hosted API service.

Tasks

• Modify the Bisq pricenode code to use the mempool fee estimation backend
• Have all Bisq btcnode operators are running the mempool fee estimation backend
• Have all Bisq pricenodes upgrade to the new code that will query our federated btcnode mempool fee estimation backend service

Estimates

Dev: $2000 USD
Ops: $1000 USD

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

@pedromvpg created a while back a great new design including new-user-onboarding:
https://xd.adobe.com/view/a83c2327-4730-4ec2-8938-e318b2749588-fd6f/ (not a finished version but should give a good impression)

For too long we did not manage to get that implemented. To boost that I contacted a few JavaFX experts to see if we can find a UI developer to get that done as well to have a long term committed dedicated UI expert in our team. I had a call now with a promising candidate and I would like to start an iterative process to get the work started. He is available from march on, so we should get our parts ready over the next weeks.

As the scope of the whole project is rather large and hard to estimate I cannot provide a meaningful estimation of costs.
It requires more discussion how we can manage and structure the work so that it meets the goal to get deliveries in an iterative process. My below suggestings are meant to get the ball rolling and any improvements are very welcome!

The UI developer is new to Bitcoin and the DAO model is a bit too new for him to feel comfortable with. To not make that a barrier I will offer to prefund his work so he will work as sub-contractor for myself and I will do the compensation requests for him (if anybody else want to play that role please get in touch). Mid/long term he should fade into the normal DAO contributor model. I also made clear that we are looking for a long term commitment and even if there might not be enough work for a fulltime UI developer that he stay committed for at least 10-20 hours so we can rely on a longterm UI/UX expert.

Rationale

New users get a bit lost with the concept of Bisq and the involved complexity. To make it easier for new users @pedromvpg created a new-user-onboarding design where users are guided throught the first steps.
The larger redesign improves the look and feel of the app and improves also the trade related areas, so it should lead to be better user experience for traders.
By applying a new design we intend also to rewrite the UI code base, as that got too much technical debt over time. Also with the API we have a secondary "client" and some code should be moved our from the desktop module to a new presentation module which can be shared by the API code base.

Criteria for delivery

We will approach an iterative delivery plan. Goal is to get short term deliveries (about 1 month) which can be rolled out. See below for more details.

Measures of success

Hard to measure as development of revenue has many factors including external ones (BTC bull market vs. bear market). We could make some survey to find out if users liked the changes.

Risks

There are several risks which should be limited by the iterative rollout plan. There is the risk of introducing new bugs and that the project gets stalled for whatever reason. Below I suggest some alternative paths in case the integration effort or code rewrite effort would be too high.

Tasks

• Get onboarding design ready for implementation
• Evaluate suggested iterative delivery plan
• Figure out how many screen would require adoption with left navigation layout and how to solve the issues
• Get estimations for first tasks from UI dev

Estimates

It is very hard to estimate but I think it wil be in the range of 30000 - 60000 USD. If we get to the higher limit we need to adjust our delivery plan (e.g. reduce scope of code re-write, disitribute some integration work to existing Bisq devs,...)

Delivery plan

To limit risks I suggest following delivery plan.

Optional research project: Performance test app to see if FXML should be used or not

From my experince FXML has some overhead specially for the XML parsing which leads to some noticable delay. If the UI dev has strong arguments for using FXML I would like to see a performance comparision using a test project where the same UI screens are implemented in FXML and in plain Java. If it turns out the performance difference is not critical we can use FXML otherwise not. There should be several views in a similar conext as used in Bisq (e.g. tabs) and some heavy content with different components to get some realistic simulation. I think parsing results are cached so difference might be visible only at first screen changes.
As stated this is optional if the UI dev prefers FXML to be sure to not suffer performance loss. If we decide against FXML I would prefer to get rid completely of FXML and not even use it for the base containers as it is used now.
As all the following work depends on that decision to use FXML or not we should do that in the very beginning.

Click dummy for new-user-onboarding

This is a JavaFx standalone application implementing the design and styling (light and dark mode) with all user interactivity using mock data (random data similar to real Bisq data). There is no domain knowledge about Bisq and the Bisq code base needed. One open challenge is how we deal with the payment method screens. There are a lot of payment methods. An area which will need a bit more discussion how to deal with it.

Integrate new-user-onboarding

Integrate the click dummy for new-user-onboarding into Bisq. Once integrated this will be released as the first user facing delivery.

Click dummy for new menu structure and layout

Like above an independent app implementing the design in dark mode style (light mode is not included in first version but should be considered for later). The content area can be filled with placeholders.

Integrate new menu structure and layout

Integrate the new menu structure and layout into Bisq. Reuse or create a new persistable navigation framework.
Apply all content into the new content container. This will likely require some adjustment as the available width will be smaller with the new design as the menu is on the left side. In case that some views cannot be adjusted without degrading usability too much we need to consider to implement those views with the new design as well. This package is a bit hard to estimate and delivery time will depend on the complexity and effort to get an acceptable solution without getting too far with implemting the new designs of the other content views.
Once an acceptable solution is implemented it gets rolled out in a release.

Click dummy for create-offer and take-offer views

Same as above, independent design-only implementation. We should get a bit deeper here into user interaction and add the validation model as well. Currently we use a dynamic validation where on focus out the validation gets triggered. This has some issues as it is not always obvious to the user that focus out will re-evaluate validation state. Also there are quite some complexity in those views which lead to some weird behaviour/bugs. A more simple model would be to triggger validation only when clicking the action button. Has to be discussed and evaluated which validation concept we will use.

Integrate create-offer and take-offer views

Integrate create-offer and take-offer views into Bisq. This will be one of the more challenging tasks as that area carries most of the more complex domain logic. It also requires to move much of the validation, formatting, calculation code to a new presentation module so it is available for re-use for API or potential other new applications (e.g. mobile?).

Continue with all other views

If a click dummy is needed for the remaining views can be decided later. Goal is to get one view completed and then move to the next one. At each release we include what is ready to get shipped. We should start with the views which the traders use most (wallet, portfolio, market,...). As the DAO is a kind of sub-application we can leave that to the end. Maybe the new design will find also a different solution to not include the DAO as main menue item but as something different (no concrete idea yet, but I think it is not perfect as it is now).

Misc

There are some other areas like loading screen, windows/popups, notifications,... which need to be considered as well.

With that iterative deployment plan we can limit the risks in case the project gets stalled for whatever reason to have at least part of our goal delivered. Alternatively if it turns out the effort for integration and/or effort for rewrite is too high we could limit the tasks for the UI dev to implementing the click dummies only and an existing Bisq dev who is already familiar with the code base can work on the integration. Code rewrite can be considered optional in that scenario as well (though it is a clear goal).

Team

As the new UI dev is new to Bitcoin and to Bisq (as well as trading domain) we need some domain experts to guide the project.
It would be great if @pedromvpg and @ripcurlx can be a main lead for getting the UX right.
If @pazza83 would be available as trade domain expert would be great as well.
I can be available for dev related support and dev onboarding.

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

Implement segwit in bisq according the plan drafted in bisq-network/proposals#226

Rationale

Bisq users keep asking for this feature. Segwit has been out for several years. A bitcoinj version with segwit support was released in March 2019.

As described in bisq-network/proposals#226, the goals are :

• Reduce btc miner fees both for btc deposit/withdrawal txs and trade protocol txs.
• Allow users to extract btc to native segwit addresses.
• Migrate out from bitcoinj 0.14 because it is not being maintained.
• Get access to the non-segwit-related features in bitcoinj 0.15 in case a dev wants to use them in the future.
• Avoid potential malleability attacks (there is no documented feasible malleability attack to bisq, but it is good to be on the safe side)

Why now?

• Btc miner fees increased a lot recently.
• Oscar Guindzberg is available to implement it.

Criteria for delivery

• bisq using a customized bitcoinj based on bitcoinj 0.15.8
• Users allowed to receive/extract btc using both native segwit addresses ("bc1xxxxxx") and legacy addresses ("bc1xxxxxx")
• Trade protocol updated to use segwit.
• Bisq version with all those changes released.
• Support provided after segwit support is released and activated: support users, implement hot fixes ASAP if needed.

Measures of success

Any combination of:

• Reduced btc miner fees.
• Users want to upgrade to the latest bisq version to be able to use segwit.
• Bitcoiners stop seeing Bisq as an unmaintained project for lack of support of segwit.
• A bitcoinj 0.15 feature is used by a bisq developer.
• Feasible malleability attack documented for bisq pre-segwit trade protocol.

Risks

The biggest risk is migration. Bisq had problems in the past because of migrations that turned out to be a headache. e.g. the new trade protocol. The plan this time is to let already created offers and unfinished trades finish in peace after migration. Oscar Guindzberg committed to plan migration thoroughly and be available to provide after-migration support if needed. @chimp1984 is going to review Oscar's work.

Tasks

• Migrate to bitcoinj 0.15.8.
• Allow users to extract to native segwit addresses.
• Implement segwit for bisq btc wallet.
• Implement segwit for the Trade protocol.
• post deployment support.

Oscar Guindzberg is going to do all these tasks

Estimates

The total estimate is USD 45000.
There are a couple of milestones:

• Migrate to bitcoinj 0.15.8 - USD 5000.
• Allow users to extract to native segwit addresses - USD 5000.
• Segwit for bisq btc wallet - USD 10000.
• Segwit for the Trade protocol - USD 20000.
• Post deployment support - USD 5000.

The entire project will be implemented by Oscar Guindzberg.

See bisq-network/proposals#247

Notes

Some challenging parts of the project are:

• Add missing parts to bitcoinj.
• Several parts of the bisq code should be reviewed in detail to make sure everything is adapted to segwit (See bisq-network/proposals#226 phase 3).
• The code being updated might change while Oscar is still coding, so some merging and rework is expected.
• Define and implement a smooth migration strategy where existing offers and unfinished trades are kept alive (This requires more work than the original proposal in bisq-network/proposals#226 where Oscar suggested to kill existing offers and unfinished trades)
• Do integration testing, specially for migration.

Board: https://github.com/orgs/bisq-network/projects/8

Description

This project defines a project management process for the Bisq DAO.

Rationale

See also: https://bisq.wiki/Project_management#Purpose and https://bisq.wiki/Project_management#Philosophy

Many if not most of the things we set out to accomplish under the Bisq DAO are best thought of and managed as projects. There are exceptions, such as simple bug fixes or carrying out the regular duties of a given role, but most efforts we undertake require multiple tasks and multiple contributors across multiple teams in order to be properly delivered. Modeling what we do as projects captures this reality and allows us to better manage it.

Projects provide a suitable unit of abstraction for budget allocation. As we have rolled out budgeting over the last weeks (#2), it has become clear that it is difficult to effectively allocate budget on a task-by-task basis. A better approach is to define a project up front and to estimate a budget for that project that includes all known tasks and teams that will be involved.

Projects allow us to scale out and deliver on more efforts in parallel. The project management process is designed such that any contributor can own a project from proposal to implementation to completion. Such a project owner is responsible for every aspect of their project, including getting it approved, ensuring it stays on track and on-budget and reporting on it in a bi-weekly review. This of course does not mean that a project owner is responsible for doing all the work necessary to deliver the project, but rather that the owner is responsible for ensuring the work does get done. In this way, we avoid the pitfall of centralizing all management to team leads, and instead build a culture of effective self-management with appropriate checks and balances.

Projects allow us to course correct on and/or disengage from efforts that are under-performing. If a project is blowing its budget, is suffering from scope creep, or has an owner that has gone awol, a project may be re-scoped or dropped entirely, allocating its budget elsewhere. Such decisions are made as part of the bi-weekly review process.

Relationship to goals, proposals and processes

Projects are related to, but distinct from Goals. Goals define high-level strategic outcomes for Bisq and the Bisq DAO as a whole (see the Bisq Q1 2020 Update for our current goals). Projects are the tactical means by which we achieve those goals.

Projects are related to, but distinct from Proposals. Proposals have become overused and in many cases, even when approved formally or informally, are effectively unimplementable or otherwise unmanageable because they do not define work and outcomes in enough detail. Going forward, proposals will continue to serve their function as a decision making mechanism within the DAO, but projects will be the favored approach to managing efforts that require tasks, resources and time to accomplish.

Projects have an important relationship to Processes. Processes such as proposals, compensation request reviews, DAO voting, role reporting, code reviews, and many others are activities that do not have a beginning and an end, but go on indefinitely and ultimately constitute the way things work in the Bisq DAO. In some cases, the outcome of a project will be to establish a new process. The project you are reading about right now is one such example.

Resources

See https://bisq.wiki/Project_management#Resources

Roles and teams

See https://bisq.wiki/Project_management#Roles_and_teams

Process

See https://bisq.wiki/Project_management#Process

Criteria for delivery

• The project management process proposed here has been proposed and approved (bisq-network/proposals#182)
• The project management process is documented on the wiki at https://bisq.wiki/Project_management
• An issue template is in place in the projects repository that captures the outline of a well-formed project definition (bisq-network/admin#43)
• The bi-weekly project review meeting is scheduled and announced
  • UPDATE 2020.06.12: currently considering merging this review meeting with the new dev calls proposed at bisq-network/proposals#231
• Existing projects are represented on the master projects board according to the documented process, i.e. with regard to columns and labels
• Project owners of existing projects have agreed to attend the bi-weekly review meeting, and understand how to do a written report if they cannot make the call
• Links exist that make the new process documentation easily discoverable
  • UPDATE 2020.06.12: Links exist in a number of places, but should double check that dev onboarding docs, contributing.md, etc have them as well.
• Two full cycles have elapsed with the new process in place and all work that qualifies as a project is actually captured and being managed as a project. Team leads are directing contributors to propose projects where appropriate and are not allocating budget to multi-task efforts if they have not been proposed and approved as a project.
• Learnings from the two full cycles have been incorporated into process and captured in the wiki documentation.

Tasks

See the project board at https://github.com/orgs/bisq-network/projects/8.

Estimates

This project is purely administrative, and administrative activities are not subject for compensation at the current time, so there is no cost estimate. It does consume the time and effort of the project owner (@cbeams TBD), and of all those that help review and otherwise engage with the process proposed here, but these costs are considered to be integral to working within the dao, i.e. a cost of doing business.

During startup, Bisq is required to send >4MB of data to seednodes in order to get its initial data. This is an issue because

• these requests tend to timeout on slow internet connections and leave the users stranded.
• the protocol as is does not scale and thus, startup will eventually become a much bigger issue

The primary goal of this project is to reduce the amount of data to be sent on startup.

Why/why now?

• the solution as is does not scale
  • the initial request grows on average about 100kB each release given growth efforts are NOT successful (1MB of additional data to be sent on startup in just 5 months, in other words: +50% of data)
  • Internet speeds might not keep up with that
• the more successful growth efforts are, the worse it gets
• fixes bisq-network/bisq#2547
• fixes bisq-network/bisq#2549
• fixes bisq-network/bisq#3763
• might lessen bisq-network/bisq#3797
• might help limit RAM and ROM usage/requirements
• EDIT: might lessen disk io and CPU load as well, therefore fixes bisq-network/bisq#4003

Details: Problem statement, Numbers, Proposal, ...

Risks

• as always with p2p network stuff, it might break everything (not if we do our jobs properly)
• if we fail to address the issue, the network might suffer (because the current solution does not scale)

Alternative approaches

• bisq-network/bisq#3896
  • needs protocol change
  • is most likely overburdened to handle today's load alone
  • cuts down to O(ln(n)) (?) vs. O(1) for historical data
  • can complement this approach for data produced in between releases
  • future work

Tasks

• feasibility study
• proof-of-concept implementation with benchmarks
• make implementation production ready
• thorough testing
• upgrade seed nodes before releasing the feature
• release the feature

Criteria for Delivery

• benchmark data
• test reports for application startup on all major OSs
• upgraded seednodes
• release

Estimates

This project is about migrating from Tor Hidden Services version 2 to Tor onion services version 3 and the required steps to do so.

Rationale

Why do we want to update?

• we expect significant improvements during startup
• improves security/privacy
• might fix bisq-network/bisq#3987
• might prevent clients/seednodes from occasionally being denied access to the Tor network
• we have to upgrade at some point, HSv2 might someday hit EOL

Why do we want to update now?

• a recent tor update now defaults to HSv3
• the tor binary is due to be updated anyways
• might just do the HSv3 switch now

Risks

• the HSv3 has proven itself for years now, so very little risk there
• if we do not move forward, we may risk getting left behind and then do the work in a hurry

Tasks

Milestone: Get Bisq ready to talk to HSv3

• done

Milestone: Proof of concept

• done

Milestone: Ship it

• done

Milestone: Allow old clients to upgrade

Since Tor has officially deprecated Tor onion services v2 source we should prepare Bisq as well. Final deadline (v2 is no longer available) is 2021-07-15, although, we can delay adapting to new tor binaries and thus gain a few days, on the other hand, Tor will show warnings in upcoming releases (as soon as 2020-09-15, i.e. next week) and we do not know how good their v2 "DNS" servers will hold up. Finally, on 2021-10-15 there will be no v2 "DNS" servers anymore and thus, v2 onion addresses will not be accessible anymore.

Tasks

• reenable HS version reporting on the monitor to see our progress in migrating to v3
• create the necessary tools to migrate properly (by reenabling bisq-network/bisq#3044 as it is 90% there)
• create test suit, test code and testpad
• find a solution to optionally transfer reputation from one onion address to another?
• create a timeline with measures to motivate users to switch to new onion addresses
• execute the timeline

Criteria for delivery

• enable users to renew onion addresses, warning them that reputation is not transfered
• transfer reputation when migrating from Tor Hidden Services version 2 to Tor onion services version 3 (?)
• all clients have moved to v3 onion addresses

Estimates

• USD 4350,00 for work done on bisq-network/bisq#3044 in the past
• USD 1550,00 for bringing the PR up to speed and over the finish line
• USD 2250,00 for testing
• USD 1000,00 for creating the tools necessary to execute the timeline
• USD 1500,00 for creating and executing the timeline

Please note that compensation for the first three points should be available as soon as these tools make it into master. There is no point in delaying the compensation for a year. The tools necessary for executing the timeline may only be created according to the timeline.

Milestone: Cleanup

Tasks

• revert bisq-network/bisq#4027

The Get started guide is now complete. Feedback on it would be great. For the most part i've transcribed what was on docs.bisq.network and added or refined the information.

Most use cases are quick and to the point. The Take an offer use case is a tad longer but it is a more detailed use case and requires a longer walk through.

Please advise if this issue would be better off in a different location such as /wiki or /support

Project board: https://github.com/orgs/bisq-network/projects/10

• Decide on and communicate how we will handle bond interest (bisq-network/admin#30)
• Assess the state of all roles and bonds (bisq-network/admin#4)
• Follow up with owners to close any gaps
• Transcribe http://docs.bisq.network/roles.html documentation to wiki 'Roles' article
  • @cbeams to create stub at https://bisq.wiki/Roles
• Seed the wiki with at least two reference examples of "good" role documentation
  • https://bisq.wiki/Bisq_Maintainer (bisq-network/admin#39)
  • TBD
• Assign role owners to create / update their own role documentation on the wiki
• Respective team leads to review those new role articles

Board: https://github.com/orgs/bisq-network/projects/9

Description

This is a project proposal to create XMR/Fiat markets on Bisq using BTC as the security deposit.

I have documented this proposal following discussion of it on Busq's GitHub discussions: [#5285 ](Monero to fiat trades using BTC as the multi-sig #5285)

Rationale

XMR/BTC is the most liquid market on Bisq. This market generates more revenue for Bisq than all of the other markets combined. Efforts are being made with atomic swaps that when/if implemented will make the future of this market, and the revenue generated from it, uncertain.

Being able to use Bisq for XMR/Fiat trades is overwhelming popular with Monero community. See my recent Reddit Post Would you like to be able to use Bisq to buy Monero directly with fiat?

Why is it important?

The project is important for a number of reasons. These include:

There are currently no ways (at least that I know of) for people buy or sell Monero using fiat on a decentralized exchange and with no KYC requirements. Options seem to be centralized exchanges (eg Binance and Kraken) or centralized P2P exchanges such as Local Monero or AgoraDesk. These options require KYC.

On Monero community are also frequently asking about how to buy XMR using fiat and get referred to a centralized exchange such as Kraken or to a P2P marketplaces. Bisq gives great on and off ramps to BTC user, I think it could extend these on and off ramps to Monero users.

Allowing users to buy and sell in peer to peer on a decentralized exchange is core to the principles of Bisq. Enabling Monero to fiat trades on Bisq would be of a major benefit to the Monero community, It would be well used and would increase Bisq trading revenues.

• Enable people to buy Monero with fiat with no KYC on a decentralized exchange
• Enable people to sell Monero for fiat with no KYC on a decentralized exchange
• Enable Bisq to increase trade revenues (Monero to fiat)
• Bring more Monero users to the platform for (XMR/BTC trades, Bisq main revenue source)
• If it proves popular, it would be a good base to then develop XMR as a base pair for Bisq (see below for why I think adding more base pairs are needed for the long term success of Bisq).
• Also if the protocol can be developed to allow BTC as the trade pair it opens up the options of anything being traded for anything. I think Bisq being used as an escrow service has a lot of possibilities. I will create a separate post about this in the future.

Why should it be done now?

When I started using Bisq I did so because of the great on / ramps for fiat it provides. It is fantastic for people looking to acquire some BTC in decentralized way without KYC. Bisq is still great for this use case. However the more the crypto landscape has changed (big increases in prices across the board), the more I think Fiat > BTC is not where Bisq will get most of it's revenue from in the future. I think the largest revenue and growth for Bisq can come from users trading one crypto for another. My project might be about Monero to fiat trades, but really to goal is for Bisq to strengthen its appeal and use case for another community other than Bitcoin. If this model is successful there would be no reason to use it as a way to onboard other crypto communities into Bisq. I feel like Monero is the best fit for Bisq due to it sharing Bisq's values in terms of privacy and also the high number of Monero users already on the platofrm.

I want to see Bisq succeed in growing its trading volume in BTC terms. I want it to grow it's revenue in BTC terms. If Bisq is reliant on being an on/off ramp for fiat, the increase in the price of Bitcoin is a threat to Bisq achieving this. The higher the prices the more risk there is, and the more users will run into bank imposed limits (both in terms of fiat volume and individual fiat transaction amounts). I see Bisq as needing to move into more markets to increase it's trade volume in BTC terms. The more markets it has the easier it is to generate revenue both as an on / off ramp for fiat and also the a place to go for decentralized. no KYC P2P crypto to crypto.

The speed of price increased in the crypto space is very fast and this is why I think that efforts should be made now to onboard more communities.

Bisq is currently has a great reputation in the Monero community and they are in need of a solution to buy and sell XMR with no KYC. Bisq should see this as an opportunity and capitalize on it.

What will happen if we don't do it or delay doing it?

If nothing is done to address the issues above than I worry that Bisq will be unable to realistically grow it's denominated BTC revenues relying on fiat trades alone. I make the assumption that growing Bisq in these terms is something the majority pf Bisq stakeholders want but I imagine there are a range of opinions on the philosophical goals for Bisq and whilst generating revenue and being self sustaining are important, their may be differing views on how important, or not, it is to grow in BTC terms.

Current threats of not doing anything are:

• It is only a matter of time before new exchanges are created, or existing exchanges are adapted, to cater for Monero users wanting to buy / sell using fiat with no KYC. This could threaten Bisq's XMR/BTC markets and revenues. It could also threaten some of the current BTC/fiat sellers. For example if the mempool is too high traders could instead trade XMR>fiat for lower fees.
• XMR/BTC atomic swaps when implemented would likely threaten Bisq's XMR/BTC markets and revenues.
• BTC prices are likely continue to rise resulting in a decrease in BTC denominated revenue for Bisq the DAO. This will affect Bisq's growth.

Criteria for delivery

My project proposal is to create XMR/fiat trade where BTC is used as the multi-sig.

I have chosen to keep BTC as the multi-sig for the following reasons:

• It reduces development time.
• It can be a template for adding other altcoins
• It is a proof of concept for trading anything for anything using BTC as a multi-sig
• Has the benefit of all the security that BTC brings with it.

What would a XMR/Fiat trade look like?

Sellers of XMR would deposit 115% BTC to cover trade amount and security deposit. When trade complete seller would receive their full security deposit back.

Buyers of XMR would deposit 15% BTC to cover security deposit. When trade complete buyer would receive their full security deposit back.

Example of user Selling XMR

Example for 10 XMR trade (€1,900)

• Sell XMR / Buy Fiat
• XMR seller makes an offer to sell 10 XMR for €1,900
• XMR seller would deposit 115% of trade amount in BTC (0.046 BTC)
• When XMR buyer accepts offer they would deposit 15% of trade amount in BTC (0.006 BTC)
• 0.052 BTC locked in multi-sig
• XMR buyer sends €1,900 to XMR Seller's bank account
• XMR seller confirms receipt of €1,900, sends 10 XMR
• XMR buyer confirms 10 XMR have been received (or trade auto-confirmed)
• BTC deposit is released to buyer and seller
• If trade goes wrong it can enter mediation

Example of user Buying XMR

Example for 10 XMR trade (€1,900)

• Buy XMR / Sell Fiat
• XMR buyer makes an offer to buy 10 XMR for €1,900
• XMR buyer would deposit 15% of trade amount in BTC (0.006 BTC)
• When XMR seller accepts offer they would deposit 115% of trade amount in BTC (0.046 BTC)
• 0.052 BTC locked in multi-sig
• XMR buyer sends €1,900 to XMR Seller's bank account
• XMR seller confirms receipt of €1,900, sends 10 XMR
• XMR buyer confirms 10 XMR have been received (or trade auto-confirmed)
• BTC deposit is released to buyer and seller
• If trade goes wrong it can enter mediation

Checklist

• Get feedback from Bisq / Monero community regarding project
• Confirm trade protocol can be changed to enable to above
• Confirm what changes to GUI would be needed (more market pairs etc)
• Confirm a developer that has the resources to complete the project
• Develop any necessary user experience designs for the dev to work with
• Confirm any in app text changes / additions needed
• Developer to complete changes to protocol
• Test
• Deploy
• Write and publish wiki on XMR/Fiat
• Promote XMR/Fiat market to Bisq / Monero community
• List trade pair with services like Coin Geko / Coin Market Cap etc
• Troubleshoot
• Retrospective analysis

At the end of the project Bisq users will be able to buy and sell Monero for fiat with no KYC on a decentralized exchange.

Measures of success

Success would be measured in terms of trade volume on the following markets:

• XMR/Fiat (no trade revenue exists so all revenue would be additional)
• XMR/BTC volume (increase would be expected overtime as more Monero users use Bisq)

Risks

There would likely be a risk to adding a new trade protocol for the 115% deposit. There would also likely be some work required to maintain this. I would defer to the devs for assessment of these risks.

Monero also likely brings with it more regulatory risks. I think I would be right in saying more countries have banned the trading of Monero than they have the trading of BTC. For example I think exchanges based in Australia had pressure placed upon them to remove the ability for users to purchase Monero. My view point, however, is the regulatory risks are not a reason for this to be avoided, in fact I think they are a reason to push forward. It reminds me of the poem First_they_came_...

Estimates

I would be happy to do this alongside a dev. But if someone else wanted to project manage it I would be happy to defer to them. If the idea is approved in principle I would be happy to agree a fixed USD amount for completing all the aspects.

I am not sure what the dev budget would be.

Notes

This project is not for XMR to be added as base currency, but it is the logical next step should this project be successful. I have not been contributing long enough to have been involved in the previous Propose how to integrate Monero wallet into Bisq, Bisq Monero Wallet and the rejection of the proposal Bisq DAO Cycle 6: Results.

Therefore, I might be missing some of the history/information, and I don't know if my proposal is significantly different, or if things have changed.

I am making this proposal as I think that revenue from fiat to BTC on/off ramps revenues will likely decrease over the coming years and I for Bisq to succeed in the long term I see it as a place where more crypto to crypto exchanges can take place. I am also passionate about privacy, decentralization, open societies, and the ability to Bitcoin and other cryptos to help people achieve personal and financial freedom. I feel is this project where to implemented it would be of benefit to both the Bisq and Monero community.

Board: https://github.com/orgs/bisq-network/projects/2

Description

This project is about migrating from Tor Hidden Services version 2 to Tor onion services version 3 and the required steps to do so.

Rationale

Why do we want to update?

• we expect significant improvements during startup? - yes
• improves security/privacy? - yes (better crypto, no longer sha1)
• solves our connection issue with seednodes,...? - unknown, maybe
• we expect a positive performance impact on the Bisq network? - ?
• we expect fewer timeouts? - ?
• we have to upgrade at some point - is that so? - no reason that we know of now
• fixes issue: bisq-network/bisq#3987? - ?

Why do we want to update now?

Risks

Criteria for delivery

• All new Bisq clients are v3 by default
• [ ]

Measures of success

Milestones

Proof of concept

• upgrade v2 to v3 in a branch, deploy a test network and test all platforms, mix of v2 clients and v3
• measure performance improvements, if any
• decide whether to move forward

Ship it

• all new clients use v3 hostnames
• all existing seednodes use v2
• one new seednode use v3 hostname
• wait and see how it goes over time
• look to support team to report potential issues
• checkpoint - do we go on with milestone 3? at what scope?

Allow old clients to upgrade

• support renewal feature
• reputation migration?

Tasks

• add support for Tor onion services v3 in our legacy clients
• evaluate performance improvements -> what would be a success for this upgrade?
• update tor binary and use v3 onion services by default for new clients
• enable users to renew onion addresses, warning them that reputation is not transfered
• transfer reputation when migrating from Tor Hidden Services version 2 to Tor onion services version 3

Estimates

This is a Bisq Network project. Please familiarize yourself with the project management process.

Board: https://github.com/orgs/bisq-network/projects/16

Description

Repay victims of the April 2020 security incident per the plan detailed in proposal bisq-network/proposals#209 (approved in Cycle 12).

Rationale

The rationale is covered in the proposal linked above.

Criteria for delivery / Measures of success

All victims have been repaid per the plan laid out in the proposal above and the follow-on proposals that nail down certain specifics. Once everything has been clearly decided, this section may be updated to reflect the exact plan.

Risks

n/a, completing this project is required. Risks of not doing so were assessed prior to the approval of the proposal linked above.

Tasks

See the project board at https://github.com/orgs/bisq-network/projects/16

Estimates

No estimates given as completing this project is not a budget-discretionary item.

This is a Bisq Network project. Please familiarize yourself with the project management process.

Approved in bisq-network/proposals#163 and fixes bisq-network/bisq#1074

Description

This project will remove the need for Bisq network to trust BitcoinAverage as a data oracle and provide fiat and altcoin prices, by implementing our own weighted average price index for fiat and altcoin prices calculated from querying 10 or more Bitcoin Exchange APIs directly.

Rationale

Currently the Bisq Pricenode Operators all subscribe to expensive Bitcoin Average API subscription plans, which is a large recurring expense for the Ops team budget. It's a no-brainer to do this project financially, since we will no longer have to pay these recurring monthly expenses for API subscriptions, but much more importantly in terms of our goals to improve reliability and censorship-resistance, this project will remove a very centralized TTP and CPOF for Bisq by decentralizing the data sources. If BitcoinAverage were to suddenly ban Bisq, we would be in trouble.

Criteria for delivery

When all the items in Part 1 below are completed, we can consider this project to have been delivered.

Measures of success

After we have shut down all Bisq Pricenodes using Bitcoin Average, and Bisq is running stable using the new decentralized providers, we can consider this project to be successful.

Risks

The new code could crash our Pricenodes.
The new code could calculate prices incorrectly.
The pricenodes might disagree on the price for a certain fiat or crypto asset, causing network issues.
More risks probably exist which we cannot know.

Tasks

Part 1: Implementation

• Add 35+ basic providers, supporting all the fiat and altcoin prices that Bisq needs bisq-network/bisq#4315

Part 2: Documentation

• Add a new page to the wiki, documenting how the prices are calculated )which exchange gets which weight, for which currency, etc.) https://bisq.wiki/Bisq_Price_Indices
• Link to this documentation from inside Bisq (About / credits + top right dropdown "data provided by BitcoinAverage") bisq-network/bisq#4406

Part 3: Testing

• After we have a working setup with several providers + weighted average per currency pair, begin full testing bisq-network/bisq#4403
• Based on testing results, add new providers if necessary, and tweak average weights if necessary, etc. - deemed not necessary

Part 4: Migration

• After all Pricenode Operators have new Tor V3 onions running the new Pricenode code, pick a time for everyone to repoint their old V2 pricenode onions to their new pricenodes, migrating the entire network at the same time bisq-network/ops#8

Estimates for budget allocation

Dev: $5000
Ops: $3000

Board: https://github.com/orgs/bisq-network/projects/13

@bisq-network/team-leads and @bisq-network/compensation-maintainers, please read and respond to this asap, as it deals with the orderly processing of Cycle 10 compensation requests, thanks.

Criteria for delivery

• All Cycle 10 compensation requests submitted by the Monday Feb 10th deadline have been reviewed by their respective team leads
• Review feedback has been acknowledged and applied by each contributor
• The Compensation board has been used to facilitate the review process
• The process is documented on the wiki and ready to go for Cycle 11
• The new process has been announced to @bisq-network/dao
• Existing compensation documentation has been updated to link to the process

Tasks

• @m52go to ask all contributors to submit their compensation request GitHub issues one week prior to the end of the proposal phase in order to allow for team lead review and subsequent adjustments prior to submitting the proposal via the DAO (#9)
• @cbeams to put together Compensation board
• @cbeams to assign compensation requests to team leads as appropriate
• @cbeams to write up proposed review process (see below)
• @cbeams to grant write access to bisq-network/compensation to all @bisq-network/team-leads such that they are able to transition issues on the Compensation Requests board
• @bisq-network/team-leads to review proposed process and provide feedback
  • @m52go
  • @ripcurlx
  • @wiz
  • @leo816 (with an eye toward taking over this aspect of the support team lead role)
• @bisq-network/compensation-maintainers to review proposed process and provide feedback
  • @MwithM
• @bisq-network/team-leads to review their respective team members' compensation requests per the process
• Contributors to submit proposals to dao per the process
• @bisq-network/team-leads to transition issues to Proposal Submitted as each proposal is submitted
• @cbeams to migrate compensation repo-level compensation board to new org-level compensation board and update links / documentation here appropriately (new as of Feb 17)
• @cbeams to close the old compensation repo-level board and add a comment here to explain the change
• Document this process on the wiki (bisq-network/admin#32)
  • @cbeams to create https://bisq.wiki/Compensation article containing an outline of the process proposed below as well as transcription of several sections to get the ball rolling
  • @cbeams to ask @MwithM to complete writing that article in his role as compensation maintainer and create an issue to track that work (bisq-network/admin#32)
  • @MwithM to follow up on that issue
• @bisq-network/compensation-maintainers to close compensation requests with appropriate labels when voting is complete (bisq-network/admin#40)
• @cbeams to announce the new process to @bisq-network/dao (https://github.com/orgs/bisq-network/teams/dao/discussions/4)
• @cbeams to update existing documentation at https://docs.bisq.network/compensation.html to reflect these changes
  • PR submitted at bisq-network/bisq-docs#194
  • PR merged

Proposed Process

Submit compensation request GitHub issues

Contributors who wish to request compensation for the current cycle should submit a compensation request GitHub issue no later than 1 week prior to the end of the current cycle proposal phase.

WIP (Work in Progress) compensation requests may be submitted with a [WIP] prefix in the title, e.g. [WIP] For Cycle 10.

When a contributor removes the [WIP] prefix from a compensation request issue, they should also add a comment stating This issue is ready for team lead review.

Add new compensation requests to the Compensation board

@bisq-network/compensation-maintainers should be watching the bisq-network/compensation repository, and upon being notified of a new compensation request issue, should add the issue as to the Compensation board, putting [WIP] requests in the In Progress column, and putting non-WIP requests in the In Review column.

When a compensation request issue is transitioned to the In Review column, @bisq-network/compensation-maintainers should also assign the appropriate team lead(s) to that issue. The compensation maintainer must actually look at the content of the request and determine which team lead or leads are responsible. A given compensation request may include dev and growth work, for example, and so both @ripcurlx and @m52go should be assigned to review. When in doubt, the compensation maintainer should simply post a comment in the compensation request issue asking which team leads are appropriate.

Team lead review

When a team lead is assigned to a compensation request issue, they should propmtly review it with regard to whether the work meets the definition of delivered, and whether it fits within the team budget. The team lead should add feedback and comments as a appropriate, and assign the contributor to the issue to indicate that they are expected to respond to the review.

When the review process is complete, i.e. all team lead feedback has been addressed, the team lead should (a) transition the issue to the Review Complete column and (b) add a comment asking the contributor to submit their DAO proposal and to post the resulting TXID in a comment.

Submit compensation request DAO proposals

Once a compensation request has been transitioned to the Review Complete column, the contributor is free to submit their request as a DAO proposal per the usual process. When complete, the contributor should add a comment that reads DAO proposal transaction ID: <txid>.

When @bisq-network/compensation-maintainers or @bisq-network/team-leads see the DAO proposal transaction ID comment, they should transition the issue to the Proposal Submitted column.

Close compensation requests after voting

Per the usual process, when the vote reveal phase is complete, @bisq-network/compensation-maintainers should close each proposal in the Proposal Submitted column appropriately, indicating via comment and label whether the request was:approved or was:rejected.
When a team lead is assigned

Notes

When the above process has been completed, the Compensation board should be empty save for any new [WIP] compensation requests for future cycles that may have come in during the process.

The process above assumes prompt action from both @bisq-network/compensation-maintainers and @bisq-network/team-leads with regard to responding to issue state changes, transitioning issues on the board appropriately, etc. If anyone has doubts about their ability to do this in a timely fashion (same-day), please speak up.

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

Prepare roll out of API for January or February release

Rationale

API seems to be pretty complete now, so lets prepare the last steps for deployment.

Criteria for delivery

API usage is sufficiently documented and announced. Protection tools are in place.

Measures of success

Users are using the API, no major problems.

Risks

• Scripts could cause heavy load for network if incorrectly used.
• Trade peers can suffer in case of bugs.
• Hidden bugs can be revealed by using the network and protocols in a different manner as from the UI app.
• Security risks if a malicious actor gets access to API users wallet.

Tasks

Protection

• Add a flag to preferences to deny API takers
• Add a enum entry to AvailabilityResult in case the maker denied API takers
• Add "disable API" flag to filter, which would prevent trading with API users
• API checks if API is disabled by filter
• API handles AvailabilityResult.MAKER_DENIED_API_USER response
• Add more fields to filter for network wide filtering of certain data

@ghubstan
Can you add the protection mechanism which are in place from the API side and which are planned but not implemented yet? E.g. protect against endless loops,...

Track API usage

• Add referral ID to offer so we can track how much API is used in offers
• Maybe show icon in offer book (not sure if that is needed?)
• Add a field to trade statistics so we can track how much API is used in trades

Documentation

• Add descition about security model (authentication,...)
• Add wiki/docs page for overview (maybe @ghubstan can provide basic content and @m52go finalizes it?)

Scripts:

• Add a few simple example scripts for usage. Some use cases for added value what cannot be done in the UI would be good like "create offer if price > x"
• Find some tech savvy traders who are willing to Beta test and provide input to scripts
• Find some traders experienced with APIs to provide some sample scripts

Estimates

I will work on the app related protection tasks. I estimate 2000 USD.
@sqrrm , @ghubstan , @m52go Could you add your estimates as well?

Notes

@ghubstan @sqrrm @cbeams @ripcurlx @m52go @pazza83 Do you have any further input?

Edited some dev tasks...

Description

Implement new-user-onboarding and new UI design as discussed in #47

Rationale

Bisq is a P2P exchange that is accessed via a software client that while extremely functional has remained largely unchanged from a user interface and user experience perspective.
In order to increase the accessibility of Bisq for new and existing users the user interface and user experience should be redesigned.

Goals

The goals of the redesign should be to:

• Enable Bisq to capitalize on it's clear competitive advantages
• Improve user conversion rates
• Increase user loyalty and retention
• Increase growth in number of users
• Maximize revenue for the DAO
• Reduce support issues and associated costs
• Improve the trading experiences for users
• Enable is to be designed in a way that meets a variety of user needs and requirements

Why now?

The UI designs, being done by @pedromvpg, have in a state nearing completion for a while, the barrier to implementing them was lack of UI developer resources. @chimp1984 has recently been in touch with a developer that is keen to get involved in a UI resign. Having a dev in place and most of the designs already complete means it is a good time to start a UI redesign.

The risks of not doing it now are that Bisq may struggle to have the UI developer resources at hand to implement the project.

Criteria for delivery

The project is fairly large and will be implemented in the following stages:

• Coding and onboarding stage
• Client redesign stage
• Home redesign stage
• User feedback and review stage

A rough project plan can be seen here: https://docs.google.com/spreadsheets/d/1RvjngdWhKX8L47tLkEP9eiJjfSb-SyUWvHnDYZP5YcQ/edit#gid=1115838130

Coding and onboarding stage

The first two aspects will be:

1. Performance test FXML vs Plain Java (there is a certain amount of coding needed as recommend by @ripcurlx prior to changing the design)
2. New user onboarding process, see @pedromvpg's designs here: https://xd.adobe.com/view/a83c2327-4730-4ec2-8938-e318b2749588-fd6f/

The reason for the above two being first is that they can be designed and implemented first without effecting the other aspects of the client.

Client redesign stage

Once the above have been successfully completed the project will move into redesigning the user interface of the following sections:

• Menu structure and layout
• Create-offer and take-offer views
• Portfolio section
• Funds section
• Accounts section
• Settings section
• DAO section
• Markets section

The current designs for the above by @pedromvpg can be seen here: https://xd.adobe.com/view/b01dfd7a-3f79-4744-8df9-08394d2ea1ea-e54e/grid/

The above sections will be more clearly outlined following completion of the intial stage.

• Home redesign stage

It is expected that once the client has been redesigned it will be necessary to resign the home screen to pull in the necessary data to make trading on Bisq an effective, efficient and satisfying experience.

• User feedback and review stage

The final stage will be allow for a period of user review and feedback before implementing any changes.

Measures of success

The success of the project will be measured against the goals:

Objective measurements:

It is preferable to measure goals in objective terms. Goals that can be measured objectively include:

• Are Bisq's competitive advantages clear?
• Is Bisq seeing an increased number of peers connecting to the platform
• Is their an increase in trading fees?
• Is their a decrease in support enquiries relative to number of users

Anecdotal measurements

Where goals can not be measured objectively due anecdotal measurements will be used to assess the changes in:

• User conversion rates
• User loyalty and retention
• Trading experiences for users
• The design meeting a variety of user needs and requirements

Risks

Changing the way users interact with Bisq will not come without risks.

I will defer to the devs for risk in implementing a new UI.

Other risks to be considered are:

Risks of project being stalled / delivered incomplete. This will be mitigated by breaking the project into sections and ensuring that any work delivered can be picked up by another contributor.

Design is subjective, there is the risk, or reality, that not all users are going to prefer a new design. This risk will be mitigated by trying to involve users from the outset and giving users the opportunity to express their opinions and input on any new designs.

Tasks

• Confirm UI dev is happy to take on project.
• New UI dev to complete the performance test FXML vs Plain Java (to be reviewed by @ripcurlx).
• @pazza83 and @pedromvpg to confirm onboarding designs.
• UI Dev to complete onboarding designs.
• @pazza83 and @pedromvpg to confirm client redesigns, and get feedback from Bisq community before finalizing designs
• UI Dev to complete client redesign.
• @pazza83 and @pedromvpg to confirm home section redesign, and get feedback from Bisq community before finalizing designs.
• UI Dev to complete home redesign.
• Bisq community User feedback and review stage.
• @pazza83, @pedromvpg and New UI dev to implement any changes

Roles

• @pazza83 will project manage
• @pedromvpg will complete designs
• New UI dev will complete dev work
• @ripcurlx will oversee new UI dev with regards technical aspects

Estimates

The estimates will be broken down into the various stages.

Each section will have confirmed costs from all contributors involved in the various stages.

The costs for the initial stage of Performance test FXML vs Plain Java will be confirmed by @ripcurlx and the new UI dev.

@chimp1984 previously put the cost for the whole project somewhere between $30-60k USD.

Notes

The new UI dev is new to Bitcoin and the DAO model.

@chimp1984 previously made the following offer:

To not make that a barrier I will offer to prefund his work so he will work as sub-contractor for myself and I will do the compensation requests for him (if anybody else want to play that role please get in touch). Mid/long term he should fade into the normal DAO contributor model. I also made clear that we are looking for a long term commitment and even if there might not be enough work for a fulltime UI developer that he stay committed for at least 10-20 hours so we can rely on a long-term UI/UX expert.

I have offered to pre fund the work of the UI dev so that the new UI can be completed. It is still to be confirmed how this will work exactly but I think in principle myself, the new UI dev and other contributors are happy with this model, although progressing to a DAO model for the long-term would be preferable.

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

Replace the very old BSQ Explorer codebase by adding support for BSQ into Mempool.Space, and replace our current BSQ Explorers with Mempool Nodes so Bisq gains an integrated BTC and BSQ Explorer with Mempool Fee Estimation API support.

Rationale

• Bisq's current BSQ Explorer sucks. Mempool Explorer is awesome. Having a modern explorer website for $BSQ will add a huge value to the Bisq infrastructure.
• Bisq's current BSQ Explorer cannot display unconfirmed transactions. When users click on an unconfirmed BSQ transaction from within the Bisq app, the BSQ Explorer crashes with a strange NaN error. The Mempool explorer will simply show this as an unconfirmed transaction, not showing any BSQ details until confirmed, and display realtime TX tracking until it does get confirmed, letting users know exactly what is going on with their BSQ transaction.
• Bisq's current BSQ Explorer backend often gets stuck due to various issues and is a headache for BSQ Explorer operators to maintain. Mempool Explorer is very stable and easy to maintain.
• Bisq ops team will reduce monthly expenses by eliminating the BSQ Explorer Operator roles, since the Mempool Node Operators will gain built-in BSQ Explorer functionality.
• Bisq will gain its own federation of self-hosted Bitcoin Explorers, so the Bisq app can be modified to use the same explorer for both BTC and BSQ transactions. This will reduce reliance on external TTPs such as Blockstream etc.
• Bisq will increase its number of Mempool Fee Estimation backends, increasing the reliability of the Pricenodes to deliver accurate Fee estimation to all Bisq lite nodes.

Criteria for delivery

When the BSQ Explorer Operators reach Rough Consensus that Mempool has implemented all the tasks below and can replace the BSQ Explorers entirely, we can consider the project to be delivered.

Measures of success

When all BSQ Explorer Operators migrate to using Mempool, the Bisq users are happy with the change, and the role of the BSQ Explorer Operator is eliminated saving us money each month, we can consider the project to be a success.

Risks

Not much risk, since Mempool explorer is quite stable, and we can always go back to the current BSQ Explorer code if a major issue arises that can't be immediately fixed for some reason. The only risk I can see is that some transactions are incorrectly displayed until all the bugs are worked out, which can be mitigated with lots of testing before migrating.

Tasks

• Implement full BSQ support into the Mempool backend, including parsing the JSON data dumped from a Bisq node every time it changes on disk
• Implement full BSQ support into the Mempool frontend, including displaying the BSQ transaction metadata, for all BSQ transaction types, as it updates in realtime
• Must support all functionality of existing BSQ Explorer, and replace seamlessly including identical URL schemas, API endpoints, etc.
• Scope of BSQ support in Mempool can be expanded in the future to add new features such as displaying DAO vote results, DAO financials, etc. - @bisq-network/growth team might like this feature for integrating with Bisq main website.

Estimates

Dev: $3000
Ops: $1000

Notes

Mempool: https://mempool.space/
Mempool on GitHub: https://github.com/mempool/mempool

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

We need to update our Java and JavaFX version to be able to fix critical memory and UX issues with the current Java(10)/JavaFX(11) version we are using. Also we need to move to a LTS java version to receive ongoing security updates.

Rationale

After Oracle ripped out the javapackager (required to create binaries for macOS, Windows and Linux OSes), we got stuck with the last Java version still including the javapackager - Java 10. The support for Java 10 ended already in March 2018 which means we didn't receive security updates since that point of time. Issues regarding the situation we are in are stacking more and more up and we need to have a path to update to a LTS java version sooner than later. This was blocked for a long time by the lack of a javapackager replacement. It seems to be that the Packaging Tool is ready (resolved 2020-02-05) so it make sense to start the upgrade work now.

Issues related / likely related to this project

• Bisq requesting permissions for keystrokes on all apps [osx catalina]
• System tray not visible on some Linux distributions
  
• Improve spinner performance
• Application freezes on take offer screen
• Memory Leak - Ubuntu 18.04 LTS
• Bisq using way too much RAM on windows
• Bisq UI very laggy/slow on Windows 8
• Java Heap Space - Qubes
• Bisq taking more than 2GB of memory during startup
• Hangs the whole OS on startup. Ubuntu 19.10
• Investigate if -BjvmOptions for linux build is still needed
• High resource usage and responsiveness problemsHigh resource usage and responsiveness problems
• Does not start in VirtualBox Debian (latest) guest
• Java heap space error MacOS Bisq
• Java Heap Space Windows 10, low resource VM
• Java Heap crash on ubuntu 19.10, bisq 1.2.5
• bisq freezes entire pc on arch linux
• Bisq using up too much memory on Linux even after closing
• Java Heap Space

Criteria for delivery / Measures of success

This project is delivered if Bisq can be built with a LTS Java version and the latest JavaFX version and it still is possible to build binaries for Linux (deb, rpm), Windows (exe) and macOS (dmg).

Risks

The efforts could increase exponentially, because of unknown obstacles (we did have this issues in the past already). This could slows down all other development if severe changes to the build pipeline are necessary. To mitigate this risks we should focus on the absolute minimum requirement for each milestone to find out about critical issues as early as possible.

Tasks/Milestones

• Use jpackage from JavaFX 15 and build binaries for Linux (deb, rpm), Windows (exe) and macOS (dmg) using Java 11 JDK (closest LTS)
• Update JavaFX from 11 to 15
• Add Rasperry Pi zip
• Optional: Use jlink to build a custom made JRE to reduce size of installer (maybe also improves required memory footprint)
• Optional: Extend build pipeline to include notarization step for macOS as well (bisq-network/bisq#3402). See answers for
• Optional: Create a deterministic build

Estimates

It is hard to estimate as it is lots of investigation and try and error involved. But @cd2357 seems to be quite far already (see bisq-network/bisq#4242)

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

The business logic of sending messages needs some love. During bisq-network/bisq#4047, it became apparent, that the logic might miss sending messages entirely. Main takeaways from the project:

• long term: ground work that improves reliability.
• short term: maybe get rid of spurious message loss (during trade or mediation)

Rationale

Why is it important?

• Messages are submitted to the connection asynchronously, thus, chances are that messages do not get sent because threads are abandoned, killed, time out, or a connection is closed before all message in queue are sent
• definitely explains why we see nasty walls of exceptions on app shutdown quite frequently
• concrete example: removeOfferMessages on shutdown may or may not be sent, depending on the timeouts and therefore on the performance of the host, network load, message load of the bisq app, seed node load, ...
• it can happen for more crucial messages (messages are messages are messages, there are no priorities built into them)
• might explain why we see messages getting lost

IMO:

• I consider this a high priority task
• given my >1,5 years experience with the p2p part of Bisq
• the p2p message handling needs cleanup and refactoring, technology is outdated, changing stuff is a minefield, there is synchronization everywhere which immediately causes deadlocks on the slightest change, attack counter measures are scattered throughout the code to make it almost impossible to understand how/if they work, yet alone understand, control and tweak them, copy-and-pasted spagetti code provides plenty of places for bugs to hide in
• however, I cannot provide a concrete issue # that will be fixed by working on this

Why should it be done now? What will happen if we don't do it or delay doing it?

• consider it as basic maintenance
• thus, no, it does not have to be done now
• delaying it will work as well

however,

• we might just see a more robust network
• less lost messages
• eliminate unforeseen deadlock situations
• confine timing issues to the Connection, where they can be (at least) handled somehow
• track messages and see if they are actually sent

Criteria for delivery

• have a test suit for message sending BL
• more robust code

Measures of success

• cleaner code
• maybe catch a few bugs we are not aware of yet

Risks

• as always, changing the P2P part of Bisq is highestest risk
• this one only touches the message sending business logic, so the risk is somewhat confined. Yet, if nobody can send messages, the network is going to die as well.

Tasks

• create test suit for message sending business logic (ie. on Connection level)
• implement a proper message queue for messages to be sent
• implement a proper connection shutdown process, move away from dropping anything instantly
• gradually remove "external" message scheduling mechanics

Estimates

hard to say, as the project will only show its true face once we are knee-deep into it.

Notes

• supersedes bisq-network/bisq#4105
• followup to bisq-network/bisq#4047

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

This project is about replacing the storage infrastructure with a real database we can query using SQL.

Rationale

Why is it important?

Until now, data stores have been persisted by serializing data to Protobuffer and then writing that to disk. Because of that and as the data stores grow, we see

• massive disk I/O
• high CPU loads
• higher then necessary RAM requirements.

This project is about replacing the storage infrastructure with a real database we can query using SQL.

• does eliminate the need for serializing all data every time (ie. reduce CPU load significantly)
• does eliminate the need for replacing the whole databases every time (ie. reduce disk I/O)
• lets us lazy-load data to RAM on demand (although not included in this project)

Why should it be done now?

Needs to be streamlined and fixed before growth is hugely successful.

Aside from that it will address the following issues in one way or the other

• bisq-network/bisq#4003
• bisq-network/bisq#3936
• bisq-network/bisq#3918
• bisq-network/bisq#3787
• bisq-network/bisq#3786
• bisq-network/bisq#3657
• bisq-network/bisq#3343
• bisq-network/bisq#3307

probably

• bisq-network/bisq#4071 (thanks @wiz)

probably more

What will happen if we don't do it or delay doing it?

if we do not do it, CPU, RAM and IO issues will grow until Bisq no longer works. If we delay it, the user experience is affected even more.

Criteria for delivery

• refactored storage infrastructure
• test suit

Measures of success

• reduce CPU load caused by serializing the datablobs
• reduce IO load caused by rewriting the whole database on every change

Risks

As always with changes in the P2P part, the risks are substantial.

Tasks

• create test suit
• settle on a database technology
• proof-of-concept implementation
• make it production ready
• test

Estimates

EDIT: adjusted the numbers by factoring in recent developments and difficulties.

Notes

followup to #25

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

Reduce or in best case eliminate arbitrator cases (refund agent cases).

Rationale

The v2 of the Bisq trade protocol was designed to handle a handful of arbitrator cases each month. Right now it is more like 1+ cases per day which is not sustainable and creates an unnecessary load on arbitrators.

This resulted in multiple proposals:

• Concerning the refund agent system
• Allow seller to be offline and still get the payout tx signed for altcoins
• Action Protocol for Mediators
• Allow trader negotiation of disputed BTC payout
• Proposal to increase trade deposit to 30%
• Trading protocol change: release of funds in 2of2 multisig to be signed by seller in first place

PRs:

• Deposit improvements

It is required that we solve this problem one way or the other to reduce total trade time in case of arbitration and not to loose the arbitrator before an acceptable alternative is available.

Criteria for delivery / Measures of success

• 3 arbitration cases/cycle if we have 3000 trades/cycle
• refunds without arbitrator (mediator & DAO)

Risks

Tasks

• Communicate penalty of trade protocol violation within trade process
• Improve badge notification system to show indicator only if there is an open task to fulfill
• Add desktop notifications
• Enable mobile notifications for trading peer if available

Estimates

This project has no estimates as it is more an epic story. The tasks or proposals that we agree on working will have estimates instead.

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

Implement a new menu based CLI installer for all types of headless Bisq nodes, with optional components and configuration set interactively.

Rationale

Currently, we have the following one-command installation scripts:

• Bisq Seednode https://github.com/bisq-network/bisq/blob/master/seednode/install_seednode_debian.sh
• Bisq Pricenode https://github.com/bisq-network/bisq/blob/master/pricenode/install_pricenode_debian.sh
• Bisq Markets https://github.com/bisq-network/bisq-markets/blob/master/install_bisq_markets_debian.sh
• Bisq Explorer https://github.com/bisq-network/bisq-explorer/blob/master/install_bsq_explorer_debian.sh

with optional add-on components having their own installation scripts:

• Bisq Monitor Collector https://github.com/bisq-network/bisq/blob/master/monitor/install_collectd_debian.sh
• Bisq Network Size Analytics https://github.com/bisq-network/bisq/blob/master/pricenode/install_networksize_debian.sh
• Bisq Network HSV Analytics https://github.com/bisq-network/bisq/blob/master/pricenode/install_hsversion_debian.sh

While these initial one-command installation scripts were successful at improving on the difficult installation processes for setting up each node instance type, there is a lot of duplicate code in these separate installation scripts, they are spread out over several repositories, and they are becoming difficult to maintain.

Additionally, now that we have a new mempool-based Bisq Explorer, the Bisq Explorer Operators need a quick and easy way of creating a new instance, which currently lacks an installer script and several operators are still running the old explorer.

Moreover, once the GRPC API project is completed, many users will want a quick and easy one-command installer to setup a headless Bisq node on their Raspberry Pi at home, possibly with their own Bisq Pricenode as well, since a subscription to Bitcoin Average is no longer required.

Criteria for delivery

The new unified installer should be able to install any type of Bisq node from the list above, with any number of additional optional components, configured through a CLI menu interface.

By executing a single command similar to

curl -sSL https://bisq.network/installer | sudo bash

any user should be able to install a headless Bisq instance, which could in theory then later be used with the future bisq-cli interface to perform features via GRPC API, serve as a seednode, etc. etc. etc.

Measures of success

When all the existing one-command installation scripts have been replaced, all types of headless Bisq nodes can be installed easily with the installer, and all optional components easily added, the project can be considered a success.

Risks

The new installer might be so awesome, that Bitcoin and Bisq takes over the world and nation states cease to exist, transforming the world into a new age of peace and prosperity.

Tasks

TBD

Estimates

$3000

Description

In order to make more informed decisions in the field of growth efforts, we have to better understand our markets. @m52go came up with the idea that we need to understand why a particularly good day (in terms of trading volume) happened, so that we may learn to tweak the environment to make such a "good day" more likely. Understanding a bygone offer book seems like a good place to start. However, memorizing the whole offer book is impractical and a potential privacy leak.

Proposed solution

Thus, we agreed on 3 additional data histogram streams (for each market) to be included on https://monitor.bisq.network/ (based on this):

1. trader distribution by offers
   This lets us make statements like
   • the top 20% of all traders produce 80% of all offers
   • 40% of traders only have 1 or 2 offers open
2. trader distribution by volume
   • the top 20% of all traders have 90% of volume on offer
   • 60% of traders have < 0.2 BTC on offer
3. volume per offer
   • 80% of offers cause only 10% of volume
   • there are no offers for volumes between 0.2 BTC and 1 BTC

These data also allows for statements like

• there are offers for every volume, small to big
• we have many traders with a good spread of volume per offer, if we loose a couple of these, the market is still healthy
• a very small number of traders create most of the volume, if we loose a couple of these, the market might die

Implementation details

Note that these metrics are designed to give a quick idea on how the offer books looked like. The data is no simple statistical data stream providing averages, extrema or percentiles, instead, we use data binning. Here is an example graph showing "trader distribution by offers":

additionally, we know that the top trader has 12 offers.

The data of the 4 time stamps in the graph above are crafted for demonstration purposes:

• T=4: there are 13 traders, all of them have 10, 11, or 12 offers. There is no "casual" trader.
• T=3: there are 15 traders, one of them has 12 offers, all others have 1, 2 or 3 offers each.
• T=2: there are 15 traders, every kind of trader is present, the most casual trader up to and including the most involved trader.
• T=1: the actual measured BSQ buy market offer book of 2020-02-25 16:00 CET.

If these metrics turn out to be useful, we can think of creating the same set of data streams for trades.

Criteria for Delivery

Make the data visible as graphs on https://monitor.bisq.network/.

Tasks

• design metrics
• proof of concept implementation
• update monitoring daemon
• deploy monitoring daemon
• configure https://monitor.bisq.network/

Estimates

USD 750,00 as already stated

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

In the absence of a truly-improved onboarding wizard, we can improve and add text throughout the software to make Bisq easier to use.

I think this initiative is different from #12 because it has more to do with in-the-moment usage of the software, which is distinct from onboarding (thoughts welcome if I'm wrong about this).

Rationale

There is lots of documentation and videos now on the wiki and YouTube, but most users don't ever read or watch it. This leads to rough onboarding, confusion, more support questions, and in extreme cases—abandonment.

Criteria for delivery

A list of improvements will be suggested, and this project can be considered delivered when those improvements are implemented in the software.

Measures of success

We should see reduced support queries for simple common items like how to back up data directories, etc. Otherwise I'm not sure which metrics to track to measure success...we could do a sample set of user-testing before and after, but I'm not sure it's worth the time.

I seek to address issues and pain points that we see repeatedly throughout social and support channels, so the problems are worth solving by definition.

Risks

No risks. This effort requires mostly string changes.

Tasks

• determine pain points in current software from common questions on Keybase, forum, GitHub, etc. as well as support staff
• devise solution for pain point (improved string, improved modal, etc)
• implement solution in software

Estimates

100 USD for surveying and determining pain points
300 USD maximum for string changes (displayStrings.properties file)
Budget for software changes is for developers to decide, but should not be significant

Notes

None.

Description

See bisq-network/bisq#3916

Citing essential data points and KPIs for desktop client from issue above

Data points to collect within a give timeframe per app version:

• Number of active nodes (nodes that are part of the network)
• Number of available offers
• Number of trades

KPIs needed:

• Ratio between Number of available offers and Number of active nodes
• Ratio between Number of trades and Number of available offers

Rationale

If we don't have a baseline and metrics in place to measure our success we'll never be able to tell if some change was a success or a big failure.

As we don't want to include general tracking within the client, which would hurt user privacy, we'll monitor public available information and try to generate as-good-as-it-gets metrics out of it.

Our most important use case is to enable users to buy/sell BTC. Following KPIs help us to measure our success:

• Number of active nodes > Number of available offers
  If this conversion number increases compared to the previous timeframe, we either have attracted more market makers or improved the client and enabled the user to create an offer more easily.
  To be able to check if we got more market makers on board we could monitor the offerbook to check by how many nodes the offers have been created with. If the ratio Number of available offers/Number of nodes stays roughly the same we can assume that the conversion increase is either by better user targeting in our growth efforts or by improvements within the client.
• Number of available offers > Number of trades
  As the trade statistics object is published already before the trade is settled (while both parties need to be online) we can't take it as a metric if we improved the trade process itself. If this conversion number increases compared to the previous timeframe, it could mean:
  • we targeted the right type of people that are happy to take existing trades
  • we improved UX that people are able to find and take existing offers more easily
  • we have enough liquidity with a reasonable spread for quick transactions

Criteria for delivery

KPIs

Within https://monitor.bisq.network/ it should be possible to select a time frame and app version (or all app versions) and display the KPIs above.

Metrics

Within https://monitor.bisq.network/ it should be possible to select a time frame to show the version spread between active nodes

Tasks

here is the tasks list

• design metrics via
• proof-of-concept via and via
• create log scraper scripts and monitoring infrastructure
• unplanned: create one-cmd-installer for general monitoring and scraper script deployment via
• unplanned: create pricenode installer via
• unplanned: adapt the monitoring scripts to work with the new pricenode installer via
• deploy data gathering infrastructure
  - [x] unplanned: fix monitoring daemon (this broke the monitor))
  - [ ] adapt monitoring daemon to collect trade rate data
• deploy new monitoring daemon sourced another metric we already have
• configure graphs at monitor.bisq.network: KPIs and version spread metrics (via)

Estimates

Based on the numbers posted in bisq-network/bisq#3916 this project will need roughly USD 2200 to deliver this project.

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

Currently, in order to determine how funds were allocated in a particular cycle, compensation requests must be manually analyzed and aggregated. This is time-consuming and error-prone.

This mini-project seeks to establish and implement a new structure for compensation requests that can be parsed by a script.

Rationale

The project reorganization implemented in Cycle 10 established a budgeting structure with team leads. This has helped the project look forward and plan how resources should be allocated. But planning is useless if one cannot look backward and evaluate results.

Criteria for delivery

This project should result in:

• a new template for compensation requests
• a bot that "lints" compensation requests as they are made (and edited) to ensure they fit the new template and can indeed be parsed
• a bot that parses compensation requests after a cycle's voting period ends, and adds a breakdown of issuance by functional team as a comment on each compensation request issue

The existing compensation request template and wiki documentation will need to be updated to reflect the new requirements, along with announcements in all major Keybase channels to ensure contributors are aware (#compensation, #dev, #chinese, #transifex, etc).

The project will be complete when the items above are complete: linter, parser, and related communications.

Measures of success

Contributors must make correctly-formed compensation requests on their own (this will demonstrate awareness of the initiative). The linter must alert compensation request makers of mistakes. The parser must make comments on approved compensation request issue with issuence numbers broken down by team.

The project can be considered a success if team leads actually use the issuance numbers provided by the parser bot for budgeting and tracking issuance over time.

Risks

Not applicable as no Bisq code is touched.

The most significant risk is probably a bot that reports incorrect numbers for some reason, but such a mistake should be discovered quickly and only impacts reporting (not issuance or software or anything else).

Tasks

I don't think this project is complex enough to warrant a whole GitHub board, so here's a checklist.

• Finalize compensation request format (Markdown table, YAML, etc)
• Clarify planned results (e.g., issuance breakdown by functional team, anything else?)
• Create and test linting bot
• Create and test parsing bot
• Determine ops for bots (who will host them, where, costs, etc)
• Edit wiki documentation and compensation request template to reflect changes
• Announce changes to contributors
• Follow implementation for 1 cycle: 1 proposal phase and 1 results phase
• Hand off ownership of bots to contributor who can host and maintain the code over time (and establish new roles if necessary)
• Ensure results are used for budgeting

Estimates

Since this is largely a reporting initiative, it probably makes most sense to come out of the growth budget. Ongoing server costs should come from ops.

Maybe 1500 USD is sufficient for the whole project, as described above (initial implementation and documentation)? This is based on it taking a day to create the bots. Ongoing costs for the bots should be very low/negligible. Open to feedback if it any of this is off.

Notes

Tracking issuance in a more automated way is the first step of a bigger drive to report issuance, burn, and trading volume better.

Compensation request details are an important first step to enabling other reporting, so a new project can be created to pursue further reporting once this project has been successfully completed.

Board: https://github.com/orgs/bisq-network/projects/11

• @ripcurlx to list current set of known bugs at https://docs.google.com/spreadsheets/d/199UV61b3A8QylMmYZMw-FT79N9VgKRvYAwC9pF4TWE0/edit#gid=0
• @cbeams to create Critical Bugs board
  • @cbeams to add a few items from the spreadsheet to the board to get things started
• @ripcurlx to go through spreadsheet and add critical bugs to the new board (bisq-network/admin#33)
• @ripcurlx to transcribe any notes and linked issues from the spreadsheet to the actual critical bug issues (bisq-network/admin#33)
• @leo816 to work with @ripcurlx to make sure critical bugs listed in private support spreadsheet are reflected on the new board
• @cbeams to stub out documenting the Critical Bugs board and process on the wiki
  • @ripcurlx (has been asked) to complete it
• @cbeams (@ripcurlx?) to announce the board and process to bisq-network/dev (or all of bisq-network/dao?)
• Link to the critical bugs wiki article from new developer entry points, including:
  • CONTRIBUTING.md in the main repo (bisq-network/bisq#3996)
  • https://docs.bisq.network/contributor-checklist.html (bisq-network/bisq-docs#193)
  • https://bisq.wiki/Development_Process page
• @cbeams to create https://bisq.wiki/Bisq_Maintainer role documentation and add link to Critical Bugs process (bisq-network/admin#39)

Description

This is a proposal for introducing an explicit Java interface between Bisq and BitcoinJ, with the purpose of improving maintainability of our Bitcoin network code.

Rationale

In summary

Why is it important?

• Our Bitcoin network code is very difficult to maintain, which threatens reliability and blocks some features (SegWit). This would improve maintainability and be a stepping stone towards SegWit.

• While our BitcoinJ fork is old, upstream BitcoinJ itself is widely regarded as outdated. It is possible that in the future we will want to make drastic changes, like switching Bitcoin clients. Reducing coupling between Bisq and BitcoinJ would improve our flexibility when making those kinds of changes.

Why now? What happens if we wait?

• Our BitcoinJ code is not being audited (much less improved), because it is difficult to understand. The sooner we resume taking care of this code the better. At this time, reacting to a BitcoinJ vulnerability (salt over shoulder) would be very awkward.

• Delaying work on our Bitcoin network code is also delaying SegWit.

In depth

Maintenance of Bitcoin network code

Bisq is currently tightly coupled with BitcoinJ, and our usage of it, being scattered throughout the rest of the code, is difficult to audit and to maintain. Abstracting our usage of BitcoinJ into an explicit interface would facilitate audits, maintenance of Bisq, maintenance of our BitcoinJ fork, and general comprehension of Bisq's internals.

Restoring maintainability of our BitcoinJ fork

BitcoinJ is a Bitcoin network client that is used by and tightly coupled with Bisq. Maintaining the BitcoinJ part of our codebase has proven challenging. Notable illustrations being that we're using a two year-old release of BitcoinJ (0.14.7, Mar 30, 2018) and that we have a dedicated role for its maintenance (which has not been filled since May, 2019).

Among other things, returning to beIng able to maintain our BitcoinJ fork (and thus being able to upgrade it) will allow us to support SegWit/Bech32 addresses, which is an often asked for feature.

Tight coupling and maintainability

Our BitcoinJ fork's maintenance involves understanding how we use BitcoinJ, which is made difficult by tight coupling. To illustrate what is meant by tight coupling here is the long list of unique BitcoinJ imports we use in Bisq (excluding tests, minor formatting added):

grep -r --include=\*\.java -E "import( static)* org.bitcoinj" ./*/src/main -h | sort -u

Output moved to pastebin.com for the sake of readability:
https://pastebin.com/raw/Jd0nA6Nk

And, below is the even longer list of (non-test) source files that import BitcoinJ classes (with minor formatting added):

grep -r --include=\*\.java -E "import( static)* org.bitcoinj" ./*/src/main -l | sort -u

Output moved to pastebin.com for the sake of readability:
https://pastebin.com/raw/Ap0wf3Pd

To maintain our BitcoinJ fork you'd have to make at least some kind of sense of the above usages of it, which is (I think evidently) intimidating and difficult. The primary way that the proposed interface would help is by structuring our Bisq usage.

Make sense of BitcoinJ usage by introducing an intermediary interface

The proposed interface would aim to hide the bulk of BitcoinJ specific logic and to centralize essential Bisq Bitcoin network logic.

BitcoinJ imports can be put into two categories: essential and auxiliary. I define auxiliary imports as those that serve to handle output from and pass input to the essential imports. The essential imports (such as Wallet, PeerGroup, BlockStore, net.discovery) are the exclusive focus of this refactor effort, in part due to the sheer number of aux imports, and, at the same time, because hiding essential imports behind an interface should be enough to see an appreciable improvement in maintainability.

In other words, the proposed interface would not hide all of the above listed imports, but only the most important ones. This also means that this wouldn't be a complete decoupling of BitcoinJ, though it would pave the way for one, if it were to ever happen.

Criteria for delivery

• new intermediary interface abstracts away the most important BitcoinJ-specific logic;
• there's a concensus that the new interface's clarity meets our standards.

Measures of success

• positive difference in Bitcoin network code readability and maintainability;
• reduced learning curve and complexity of resuming work on BitcoinJ fork.

Risks

Our Bitcoin network code is one of the most sensitive areas of Bisq; however, the risk of introducing bad changes should be minimal since this is a refactoring effort (meaning rearranging code without changing algorithms).

Tasks

This refactor effort is exploratory by nature, so making a precise plan is not possible ahead of time. Currently the plan is to analyse BitcoinJ usage and abstract it away behind the new interface, in order of descending importance, until only the least critical BitcoinJ code is left.

Estimates

Budget not yet discussed.

Description

Currently Bisq does not support sending funds from its wallet to external SegWit / Bech32 addresses. Being able to do so is amongst Bisq's most requested features. See detailed comment thread at bisq-network/bisq#1139.

Criteria for delivery

Tasks

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

The support and mediation provided by the Bisq contributors has a lot of room to improve. The goal of this project is to come up with ways to create standards and resources that the contributors and traders can refer to and use for better experience.

Rationale

It's important we have an agreed upon set of solutions, standards and responses that all support agents and mediators can refer to so that suggestions don't change drastically from person to person and from case to case.

Criteria for delivery

• code of conduct document for mediation
• list of most common bugs and their known fixes
• script to make mediation uniform
• table of penalties, case by case

Measures of success

Risks

None

Tasks

• Update library of known bugs and their fixes
• Create a code of conduct for mediation on the wiki
• Create a script for support and mediation on the bisq-network/support repository
• Create table of penalties

Estimates

Not defined.

Notes

Board: https://github.com/orgs/bisq-network/projects/14

Description

Introduce a MediaWiki instance at https://bisq.wiki, initially for the purpose of a Bisq support knowledge base, but eventually to replace docs.bisq.network.

This project is Phase 1: standing up and effectively rolling out the wiki
Transcribing and potentially decommissioning docs.bisq.network is Phase 2 and will be managed as a separate, follow-on project.

Rationale

Why a wiki: ease of use, quick access, no technical / process barriers. Review after-the-fact, not before. Our current docs infrastructure is great, but has a high barrier to participation. This wiki will be open to the public / community. Inspiration: the Bitcoin wiki at https://en.bitcoin.it.

Why Mediawiki: most capable, most widely known and used, open source, same as used by the Bitcoin wiki, so familiar for the community.

Criteria for delivery

• @bisq-network/support-agents are referencing KB articles in support cases as appropriate, editing and writing new KB articles as appropriate. (How do we measure this?)
• Wiki has a Bisq branded look and feel
• Wiki has a useful main page that directs users to various kinds of content within
• One or more docs from docs.bisq.network have been migrated to wiki. docs.bisq.network does NOT have to be decommissioned completely for this project to be considered delivered.
• Placeholder docs exist on wiki for all docs.bisq.network pages that have not been moved consisting of just a link back to the docs site. This is in order to be able to quickly treat the wiki as a complete / canonical source of information.
• Many @bisq-network/dao contributors have created a login and made edits
• Multiple users (outside the Bisq DAO) have created logins and made edits, i.e. we have reason to believe that we have effectively gotten the word out.

Tasks

Tasks are managed on the project board at https://github.com/orgs/bisq-network/projects/14.

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

Following from the success of #37, this project expands the Bisq Explorer backend to serve the Markets API endpoints, and implements a new Bisq Market website frontend to show market data and vital non-technical performance metrics for the Bisq network on 1 screen through a combination of graphs, tables, and text so that users and BSQ stakeholders can easily get a pulse of network activity and health.

Rationale

• The current Bisq Markets API is again having major issues. Despite running on very powerful hardware, the API is overloaded because of the inefficient PHP architecture which doesn’t use a database and re-parses over 50MB of JSON data for each and every request. The Bisq Explorer backend is written in NodeJS and keeps all Bisq data indexed in RAM for fast serving of API requests.

• The current bisq.network/markets website is slow and outdated, has old assets that are no longer traded, the graph and pull-down search have various issues, and the data does not update in realtime. The angular frontend architecture that Bisq Explorer uses is very fast and modern and is updated in realtime.

• The current bisq.network/stats graphs are currently updated by a human at the end of each cycle. The growth team wants to enhance the bisq.network/stats with full Markets and DAO metrics, updated in realtime, with information about all trade events and how the trade volume goes into Bisq trading revenue DAO expenses, issuance, burning, etc.

Criteria for delivery Milestone 1: New Backend to replace existing Markets API

• Re-implement all Bisq Markets API endpoints and functionality into NodeJS backend that parses bisq-statsnode's JSON data and keeps it all in RAM for quick access
• Add support for the NodeJS cluster module so we can load balance across multiple NodeJS processes
• Migrate the production Bisq Markets API service to new NodeJS architecture
• Repoint markets.bisq.network to bisq.markets hostname

Criteria for delivery Milestone 2: New Frontend (part 1 of 2) with new APIs in backend

General

• Implement subscriptions for realtime Bisq Markets data updates over websocket connection into NodeJS backend
• Implement new Angular component on mempool frontend for bisq.markets that displays updated Markets data and graphs updated in realtime

Front page table

• List all currently traded assets similar to https://coinmarketcap.com/exchanges/bisq/

Front page graph

• Display realtime updated graph similar to https://cryptowat.ch/charts/BISQ:BTC-USD

Criteria for delivery Milestone 3: New Frontend (part 2 of 2) with new APIs in backend

General

• Implement widgets for statistics that can be embedded into main Bisq website such as BSQ issuance/burnt per cycle, etc.

Cycle voting metrics

• Number of proposals
• Number of votes
• Total voting weight

Trading statistics, by cycle

• Trading activity broken down by market
• Ordered by number of trades, trading volume, etc
• Overall cycle figures such as average trades per day, average trade size, premium paid, etc.

BSQ issuance, by cycle

• Total issuance, categorized by issuance type (compensation or reimbursement; total issuance should not include refundagent reimbursement)
• Total issuance, categorized by team
• Include top 5-10 titles of compensation request line items (ordered by amount, descending) to give a quick idea of what work each team accomplished in the cycle

BSQ burn, by cycle

• Total burn, categorized by type (proof_of_burn should be included but pointed out)
• Total BSQ supply, as it stood at the end of each respective cycle
• Also show trend over time somewhere (ideally BSQ issuance and burn over time could be overlayed on this graph)

Proposals voted upon in each DAO cycle

• Will start labeling proposals submitted to DAO for voting on GitHub (e.g., dao-cycle-15-vote) so relevant list can be obtained automatically
• No need for any details on outcome; simply list titles of proposals with link to corresponding GitHub issue

Miscellaneous

• Repayment status for security incident

Measures of success

When the following are achieved, we can consider this project to be a success:

• Bisq Markets API is fast again using new implementation
• The new Bisq Markets website is live on bisq.markets
• The main bisq.network website is using the new markets widgets
• The growth team is happy with the new realtime Markets/DAO reporting pages

Risks

• The Markets API must be re-implemented exactly as it currently works, so existing integrations do not break. Current documentation is listed at https://markets.bisq.network/api

• The legacy hostnames that serve the Bisq Markets API include market.bitsquare.io, market.bisq.io, markets.bisq.network, and others. These must be redirected to the new API hostname on bisq.markets`

Estimates

Ops: $5000 USD for Milestone 1 for Bisq Markets API
Growth: $2500 USD for Milestone 2 for Bisq Markets Website part 1, $2500 USD for Milestone 3

This is a Bisq Network project. Please familiarize yourself with the project management process.

Description

Design a plan for migrating to bitcoinj 0.15 and using segwit in bisq. Implementation is not part of this project.

Rationale

Benefits of using segwit:

• Users could withdraw btc from their bisq wallet to an external segwit (bech32) address.
• Pay less fees in btc transactions when segwit is used.
• Eliminate a transaction malleability exploit in the trade protocol which can cause the deposit TX and payout TX
  to become invalidated.
• Extra: get access to all the new features in bitcoinj 0.15 (not immediate benefit, but the potential is there)

A design/plan project is created because there are options to evaluate, decisions to make and it would be very hard to estimate implementation before design/plan is done.

Criteria for delivery

• Document with a design/plan for using segwit in bisq. Alternatives, roadblocks, pro/cons and migration concerns should be described.

Measures of success

• An implementation project is started.
• Once implemented...
• User withdraw btc from their Bisq wallet to a external segwit (bech32) addresses.
• btc transactions are cheaper, users perceive it is cheaper to use bisq.
• Malleability exploit in the trade protocol is gone.
• bitcoinj 0.15 features are used by bisq devs.

Risks

• Since this is a plan/design project, the only risk is its outcome is not implemented.

Tasks

• Plan migration to bitcoinj 0.15
• List different parts of bisq where segwit could be adopted and evaluate cost/benefit of each one.
• List segwit migration alternatives and evaluate cost/benefit of each one.
• Write an implementation plan for the chosen alternative.

Estimates

4000 USD

Notes