You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
Nomenclature
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:
As a result, the Bisq revenue is spread like
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
Proposal
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:
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
Closing notes
This proposal is to communicate and hopefully agree on two basic things:
Implementation details should be discussed separately.
The text was updated successfully, but these errors were encountered: