Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create financial reserves and fix a resource leak #216

Closed
freimair opened this issue Apr 28, 2020 · 2 comments
Closed

Create financial reserves and fix a resource leak #216

freimair opened this issue Apr 28, 2020 · 2 comments
Labels
a:proposal https://bisq.wiki/Proposals re:processes

Comments

@freimair
Copy link

freimair commented Apr 28, 2020

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Nomenclature

  • contributor someone who spends her time and resources to evolve Bisq and the DAO. Examples are developers, support staff, marketing staff, team leads, first-timers, ...
  • speculative trader someone who uses Bisq as an exchange. Pays her trading fees but does not add direct value to the Bisq software or the Bisq DAO.

Problem Statement

There is a resource leak in Bisq that can cause Bisq revenue to not reach contributors. In detail, the issue affects the part of Bisq revenue that is created by trading fees which are payed in BTC. These fees go to Bisqs donation address and are later used to burn BSQ.

Leak description

The burning man process is to buy at top price. What first seems like a legit solution shows some drawbacks when viewed from a contributors perspective.

Imagine the following scenario:

  • A trader, Alice, puts up a buy offer over 1k BSQ for a price of 0,...6 BTC/BSQ.
  • A contributor, Bob, takes the offer.
  • Alice put up a sell offer over 1k BSQ for a price of 0,...9 BTC/BSQ.
  • The burning man takes the offer.

As a result, the Bisq revenue is spread like

  • Bob, the contributor, gets 0,...6 BTC
  • Alice, the trader gets 0,...3 BTC
  • from Bisq revenue generated by BTC trading fees.

Leak effects

The leak is not new, however, as more and more speculative traders join the BSQ market, its effects become more apparent and severe. Effects are

  • Bisq revenue goes to speculative traders instead of contributors
  • contributors receive less USD compensation
  • Bisq might start loosing contributors
  • if that happens, Bisq is dead

Proposal

  • stop doing trading events
  • leave profit (if there is any) at Bisqs donation address
  • use the profit to refund the refund agent (nothing changed)
  • if there is anything left, keep it at Bisqs donation address
    • for future use in refunding the refund agent (we had multiple trading events in the past where not even the refund agent could be fully refunded)
    • for future use as source for compensating victims of incoming attacks
How does that address the problem?

Well, if the donation address does not participate in the free market, revenue cannot go to contributors but neither can it go to speculative traders. Hence, there is no leak.

But then contributors cannot have it either!

Well, yes. However, following the recent (small!) security incident, a large part of Bisqs revenue is to be used to refund victims anyways. Eventually, there will be another incident with the needs of refunding the victims.

What if no new incident happens?

There are multiple options of course:

  • keep it, create a "reserve" for next insert time period here
  • distribute it among contributors somehow
  • all of the above
What happens to the burning man?

The burning man role requires less efforts on scheduling and creating public trade events

What about #209

There has been this 40% number. We can amend that by doing for example

  • we can have 10% reserves (this proposal), 40% refund, 50% contributors out of the total Bisq revenue
  • we can have 80% of revenue created by trading fees payed in BTC routed to the victims of the recent incident and 20% to be kept in reserve.
  • other options are possible as well

Closing notes

This proposal is to communicate and hopefully agree on two basic things:

  • create awareness of the resource leak (and present a fix)
  • introduce the concept of "financial reserves" in order to up the chances of Bisq being able to cope with future attacks.

Implementation details should be discussed separately.

@freimair
Copy link
Author

freimair commented Apr 29, 2020

Amendment

Although I said that implementation details are to be discussed separately, some of you correctly pointed out that our DAO has limits we hit by deciding to keep funds.

Problem

Although the Bisq DAO is an organization and theoretically can hold funds, we have no way of doing that other than entrusting these funds to one member of the DAO. This member would become a trusted third party and more importantly, a central point of failure facing potential threats (basically, our burning man).

There might be something to solve that Problem

However, keybase is our friend and the community is awesome. @stejbac quickly layed out an idea about using multi-party signatures with threshold and @energyburn kicked in and posted a great paper which seems to be almost tailored to our DAO.

The paper describes multi-party threshold signatures to sign off BTC transactions. "Multi-party threshold" means that there is a group of people (multi-party) and if a certain number of these people agree on doing a transaction (threshold), a transaction can be authorized. A single individual cannot authorize a transaction.

Closing words

Of course that whole thing needs more tweaking and thinking, and the math isn't exactly straight forward and simple to grasp, and it would certainly require complex UI to do this if it is at all possible.

However, having such a thing might allow any DAO to hold funds without having a single point of failure. And that would be a huge breakthrough imho.

@MwithM
Copy link

MwithM commented Aug 17, 2020

Closed as stalled.

@MwithM MwithM closed this as completed Aug 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:proposal https://bisq.wiki/Proposals re:processes
Projects
None yet
Development

No branches or pull requests

2 participants