Distribute trade fees paid in BTC to victims of the recent security issue

[chimp1984]

One option how we could deal with the losses from the recent security issue would be to distribute the trade fees paid in BTC to the victims until they have been reimbursed for their losses.

This would have the benefit to not force them into the BSQ ecosystem and does not directly add market pressure in case we would issue BSQ which would get sold to BTC by the victims and therefor could cause negative price dynamics. It is also easier to deal with as it does not add another exchange rate and its volatility risks.

The implementation could be done in a pretty simple and low risk fashion as done in bisq-network/bisq#4150.
We use the Filter object here to add a list of addresses which are used by a simple random selection algorithm to select the receiver. The filter is a P2P network object and can be adjusted dynamically and fast. The selection algorithm could be improved to weight those victims higher who have larger losses so that they distribution schedule becomes more fair.

Downside:

• It adds more trust to the Filter operator (a core dev). I assume thats a low real risk as any abuse would be detected quickly and the role operator is already a highly trusted contributor.
• Over-extending the scope of the Filter model. This is a different type of field than the other filter values. We abuse the feature of the Filter for a non-related use case.

Upside:

• Very easy and low risk to roll out
• Victims get reimbursed in BTC and not in BSQ
• Automatic spreading over period of time with fee revenue
• Does allocate a certain percentage of revenue (I guess its about 30-40%) for the reimbursement without involving DAO features
• Can be used later as well for other use cases. E.g. to pay part of core contributors compensation requests (directly in BTC, BSQ request gets reduced). This would remove one part of the required trust into the burning man. He would then only receive the funds from arbitration cases. But also that could be done with that model once the arbitration cases go down.

If the idea gets support from Bisq contributors we should reach out to the victims to ask for their opinion and if they are supporting that idea as well.

Please signal your support by up/down vote and leave comments.

[MwithM]

@chimp1984 I agree that, having BTC Bisq can use, reimbursement should be done in BTC, at least most part of it. But I don't understand why do we have to change the way Bisq deals the BTC it still manages. What has changed since the attack, regarding the DAO address holder, that needs to be changed? This model, although we know it's fragile and requires trust, is not what failed. Software implementation of donation address did.

This new implementation, although it's supposed to be easy and secure, is still a new complexity layer at software level and, also for DAO management (if we use it for other use cases).

My opinion, at this time, is that I agree on using BTC fees to reimburse victims, but there's no need to rush the filter solution because Bisq already can reimburse victims with the current system. I would discuss with the victims a small part of reimbursement/compensation request in BSQ as well. I know BSQ ecosystem is still fragile, but that's what reimbursement proposals are made for.

@ifarnung I'd like to know your reasons for rejecting this proposal.

[freimair]

another approach:

• leave anything as it is now (ie. trading fees paid in BTC go to donation address)
• the burning man reimburses the victims instead of buying BSQ

upside:

• no new changes required
• trust levels stay as they are

@chimp1984 although I like your idea of using it to pay core contribs more efficiently. but imho, this is another story.

[cbeams]

Could someone produce recent numbers on monthly trading fee revenues and their breakdown between BSQ and BTC?

[m52go]

Cycle (A)	Proof of Burn (B)	Arbitrator Reimbursement (C)	BTC Fees (D)
Cycle 8	66000	0	66000
Cycle 9	135210	48691	86519
Cycle 10	39500	0	39500
Cycle 11	82700	91866	-9166
Total	323410	140557	182853

BTC fees are calculated as B - C. These fees are denominated in BSQ, and BSQ price has fluctuated throughout this time, so the BTC equivalent must be estimated.

BTC fees collected since v1.2 was released (Cycle 8) total 140,340 BSQ. No data for Cycle 12 is included above because we don't know the corresponding arbitrator claims.

Here are monthly trade numbers broken down by the type of fee payment.

Year-Month	BSQ Trade Fee Payments	Whole BSQ Trades	Total Trades	BTC Trades	% BTC Trades
201904	924	462	2101	1639	78.01%
201905	1533	766.5	1800	1033.5	57.42%
201906	2723	1361.5	2822	1460.5	51.75%
201907	2130	1065	2214	1149	51.90%
201908	2389	1194.5	3037	1842.5	60.67%
201909	1712	856	2417	1561	64.58%
201910	1782	891	2298	1407	61.23%
201911	2142	1071	2256	1185	52.53%
201912	1849	924.5	2248	1323.5	58.87%
202001	2365	1182.5	2393	1210.5	50.59%
202002	2679	1339.5	2902	1562.5	53.84%
202003	2992	1496	3597	2101	58.41%

Whole BSQ Trades is BSQ Trade Fee Payments / 2 since trade fee payments can occur twice per trade.

Spreadsheet for reference.

[chimp1984]

One problem with using the burning man to pay directly the victims is that it is hard to find out which portion is from fees and which portion is from arbitration cases. The funds sent to the donation address because of opening an arbitration case should be reserved for the refund agent, otherwise we have a problem there....

@m52go
Thanks for the numbers, but I fear they are not very accurate as the refund agent did not do reimbursements and accounting in a steady fashion but got collected up a lot over time. From my guts feeling the BTC fee percentage seems too high. But would require more effort to get full data, e.g. by taking all inputs to the donation address and sum up all small amounts (fees) vs. big amounts (trade amounts). Another more correct approach would be to get all the trade amounts (+ sec. deposits) from refund agent cases and sum that up. Then subtract that from the totals of BTC of the donation address(es) to get the BTC fee.

[chimp1984]

One issue to consider is that this model would also have indirect effects on BSQ price as the burningman would basically never sell to normal traders but only to the refund agent. So BSQ sellers will have less opportunity to convert their BSQ. But it is questionable how much effect that has on contributors as in the reports of the burningman one can see that some traders made lots of trades, those are probably market makers (speculators) and not contributors, so the benefit of trading the BTC fees did not really reach the contributors as speculators outbid them by better prices.

[m52go]

@chimp1984 yes I meant these to be quick approximations from easily-available data...could do more intensive number-crunching if we want it (or remove the numbers above if they're so off that it hurts more than it helps).

[wiz]

I don't think this is the best approach. My thoughts are:

1. Let's not modify the Bisq code any further, especially in relation to the donation address code. This could potentially introduce new security vulnerabilities or attack vectors, by having untrusted people control the Bisq donation address. Additionally, it would be difficult to account for, i.e. when would each person get X BTC etc., and having to program this into the new filter implementation seems non-trivial. Finally, it introduces centralization in that whoever maintains the filter now single-handledly controls Bisq's revenue stream. We already have the well-tested and proven DAO in place to handle this type of situation, and just because the amount is large doesn't mean we should modify Bisq, we can instead simply spread out the payments over time to make it work.

2. If the burning man doesn't buy BSQ off the market and burn it, this will have the same exact effect as if we simply issue BSQ to victims and they sell it on the market. These market forces cancel each other out, and there is no magical way to prevent the BSQ price from falling because of this. You cannot just print $250K worth of money and not have the BSQ price reflect that.

3. Instead, I think we should simply issue BSQ to the victims as any other reimbursement request, but split up the amount over X monthly payments, to spread out the cost over time. For example, if there is $240K to be paid out, that would be $20K per month for 12 months, which would represent 1/3 of our current budget. It would be painful, but we could make it work. The burning man can prioritize buying BSQ from the victims each month at the issuance price, to make them whole in BTC as BTC, and everyone would be happy in the end, without having to modify any code.

[ifarnung]

I like the idea that the DAO routes some portion of its revenue to pay back the victims.

Adding a monthly budget expense of, for example, $20,000 on top of the $60,000 existing budget shouldn't break the BSQ market, though it will certainly influence it. Victims could be issued BSQ that the burning man would buy from them at a weekly burning for let's say 10000 sats each to make the math simple. Similar to the way the refund agent has priority in trading with the burning man, the victims would have priority to trade with the burning man and receive BTC.

I really don't like the idea of coding the distribution into the donation address:

• Overly complicated for one thing. (Sending and accounting for 1000s of tiny 5000 sat transactions?!)

• Lack of control over the distribution process for another. And I reject the idea that it somehow wouldn't effect the price of BSQ.

"This would have the benefit to not force them into the BSQ ecosystem and does not directly add market pressure in case we would issue BSQ which would get sold to BTC by the victims and therefor could cause negative price dynamics. It is also easier to deal with as it does not add another exchange rate and its volatility risks."

An absence of buying (by the burning man) is the same as selling, as far as its effect on the price, they are equal.

• I know we don't have an exact number on the percent of BTC fee revenues but if it were 50-60% that would likely be too large a percent of monthly revenues to route to the victims. It would be too disruptive to the DAO budget in my eyes.

• There's no legal guarantee for making the victims whole from this attack, it's a decision (good I think) that the DAO is making, right? It's an investment in the DAO's reputation and marketing, so let the DAO handle it like business expense. Bad precedent to be hooking up the donation address to various people, as well.

Unfortunately, this large loss is a dilution of the value of BSQ and therefore the exchange. Just like burning BSQ concentrates the value of BSQ, raising it; issuing BSQ dilutes the value of BSQ. The money reimbursed that could have been used to buy and burn BSQ but now will reside in the pocket of the attacker.

On a positive note, I think the DAO can overcome this hiccup and the quick response of the devs and the transparent response of the marketing team really gave me confidence in the project!

[chimp1984]

@wiz

by having untrusted people control the Bisq donation address

The filter is operated by a highly trusted and bonded core contributor.

having to program this into the new filter implementation seems non-trivial

See PR. Its pretty straight forward and I consider it low risk.

whoever maintains the filter now single-handledly controls Bisq's revenue stream.

Any abuse would be detected quickly and would lead to confiscation request of the bond. It is only the BTC fees not the BSQ fees, so not 100% of revenue stream.

2. If the burning man doesn't buy BSQ off the market and burn it, this will have the same exact effect as if we simply issue BSQ to victims and they sell it on the market. These market forces cancel each other out,

Theoretically yes, but in practice we have seen in the past that some past contributors have crashed the market by selling far below market price as they wanted to sell quickly larger amounts. That led to the super low BSQ price a couple of months ago. The burningman takes the best offer and does not create dump offers, so the impact on the market between a BM buying BSQ at best price and a victim trying to sell off as quickly as possible with maybe a 50% discount are not the same and indeed very dangerous to crash the BSQ market another time, and this time even harder as amounts are larger.

3. Instead, I think we should simply issue BSQ to the victims as any other reimbursement request, but split up the amount over X monthly payments, to spread out the cost over time. For example, if there is $240K to be paid out, that would be $20K per month for 12 months, which would represent 1/3 of our current budget. It would be painful, but we could make it work. The burning man can prioritize buying BSQ from the victims each month at the issuance price, to make them whole in BTC as BTC, and everyone would be happy in the end, without having to modify any code.

I have no problem using BSQ and no problem with the inflation, we just need to avoid sell-off risk and volatility risks and that is not trivial.

Using the BM here might be problematic from an coordination perspective (he takes best offer, what if victim set up an offer with best price but then not being online and another trader adds an offer with better price? Should BM wait and delay and complicate trade process until victim is back and adjusted his price or should he take the not-best price offer and therefore introduce new risks that victims might game that? Also adding anything to BM seems a bad idea, we want to get rid of him not extend his role.

[chimp1984]

• Overly complicated for one thing. (Sending and accounting for 1000s of tiny 5000 sat transactions?!)

No, its a random selection. Over time each get statistically the same. The fee is too small to split it up and that would require more code change.

• Lack of control over the distribution process for another.

That can be implemented. Atm the PR has a pure even distribution but using a weighting algo is rather trivial to add.

And I reject the idea that it somehow wouldn't effect the price of BSQ.

It would as the BM buys less BSQ but it would have less effect than a sell-of from victims.

An absence of buying (by the burning man) is the same as selling, as far as its effect on the price, they are equal.

See above comment. Theoretically yes, practically no.

Unfortunately, this large loss is a dilution of the value of BSQ and therefore the exchange.

The effect on the price will be only from BSQ sold on the market. Issuing locked up BSQ will have no direct effect as long demand is dominated by traders (and not value investors who might be more interested in the total number of BSQ longterm).

[cbeams]

I've given this proposal, proposal #206 and other ideas a lot of thought over the last days, and I've also spoken to all but one of the victims directly. After careful consideration, I'd like to weigh in here with my support for this filter-based approach, as I believe it to be the simplest and lowest-risk approach as well as being the least burdensome on victims.

Most concerns already voiced about this proposal have been addressed in the comments above, but there are certain key aspects of the implementation that have not been discussed at all. Below, I've re-articulated the proposal in such a way that I believe all key aspects are addressed. If desired, we can make what follows its own proposal to make things as clear as possible at voting time.

The DAO will repay victims for their losses

The DAO should and will repay victims for their losses because they were ultimately caused by an avoidable flaw in code written by DAO contributors.

The DAO will not repay victims immediately

An ideal plan would immediately repay victims the full amount of BTC they lost in a one-time lump sum payment. This is not possible because the DAO does not have a reserve from which to draw these funds.

An alternative plan would be to immediately repay victims by issuing an amount of BSQ equivalent to the amount of BTC lost. This approach cannot work, however, because current BSQ market liquidity is insufficient to handle such a large increase in supply. Victims would be unable to liquidate their BSQ for BTC in the near term without severely depressing the BSQ price, resulting in a losing situation for victims, contributors and all other BSQ stakeholders alike.

The DAO will repay victims over time

Because there is no way to repay victims immediately, repayment must occur over time as a function of actual trading fee revenues.

The DAO will repay victims using trading fees paid in BTC

The simplest and most direct way to repay victims over time is in BTC using Bisq trading fees paid in BTC (as opposed to trading fees paid in BSQ). @chimp1984 has laid out above how this can be implemented technically using Bisq's Filter mechanism.

Each victim will provide a bitcoin address to which repayments will be sent. In the filter implementation described above, one of these addresses will be randomly selected for each trade whose fees are paid in BTC, such that the victim directly and immediately receives that BTC.

A mechanism will be developed to track how much BTC has been received by each address over time, and when a given address has been fully repaid it will be removed from the filter such that no further payments are sent to it.

Note that #206 is an alternative proposal to repay victims in BTC, though through the indirection of BSQ and a 'Special Refund Agent' who works in conjunction with the Bisq 'Burning Man' role. While this proposal could work, it is more complex, and I believe this approach to pay directly in BTC from trading fees to be superior, with the benefits outweighing the downsides (of 'abusing' the filter mechanism and of putting control over these addresses in maintainers' hands).

The DAO will repay victims the USD value of funds lost at time of theft

Because the value of BTC can fluctuate significantly over time, it is not possible for the DAO to promise to repay victims the exact amount of BTC they lost. Given a significant increase in the value of BTC, it could become effectively impossible for the DAO to complete repayment. Likewise, should the price of BTC significantly decrease, victims would be repaid much less than the original value of their BTC at time of theft.

Rather, the DAO will repay (in BTC, as described above) the USD value of the BTC lost at the time of theft, i.e. at the time the trade was taken. All affected trades were taken on either March 28th or April 7th 2020, when the average daily price was $6,223.50 and 7,309.78 respectively.

The repayment tracking mechanism mentioned above will be developed such that the USD value of each payment made to each address is calculated according to the average daily price on the day the payment was made. This means that the total amount of BTC paid to each address will differ from the original amount of BTC lost based on the BTC/USD value at the time of each payment.

The DAO will repay victims as quickly as possible

The fastest way to repay victims according to the plan laid out above is to route them 100% of trading fees paid in BTC. More exact numbers need to be calculated, but current monthly revenues total between 20,000 and 30,000 USD worth of BTC and BSQ combined. BTC represents perhaps 40% of that figure, meaning that between 8,000 and 12,000 USD worth of BTC could be paid out to victims on a monthly basis. With a total of 235,831 USD worth of BTC having been lost, it would take between 20 and 30 months to repay victims at this rate. In any case, the amount of time repayment will take will be a function of both total trading volumes and the percentage of those trades that are paid for in BTC. Both numbers may change significantly over time.

As a protection to ensure that the DAO is able to continue operating, it will pay victims 100% of BTC trading fee revenues so long as that figure does not exceed 40% of total revenues.

The DAO will adjust its budgets accordingly

With victim repayments coming directly from BTC trading fees, realized revenue will be that much lower and the DAO's internal budgeting will be adjusted to reflect this new reality. That is, we will "tighten our belt" accordingly so that we do not issue too much BSQ.

[cbeams]

Note that I just edited the section above regarding comments about #206. See the diff for details.

[invertedbobb]

I agree with the general idea of this proposal, it seems less complex than the other one.
However, as at least one of the other victims has expressed, a pure USD conversion is very undesirable, for better or worse.
I think extra effort can be made to attempt to make victims whole in their lost BTC amounts.
Surely this could mean it takes longer to achieve, and this can't and shouldn't be to infinity.
But there could be a time-window set within which extra payouts would be made to the victims to get to the lost amount of BTC.
How about a double strategy? Using USD conversion first, when this results in the full amount of BTC being returned (lower btc price), all is good, if not (price is higher), the fees continue to get distributed for up to one or two years or until the BTC returned equals the losses.

[cbeams]

At @chimp1984's request, I've transcribed my write-up at #205 (comment) to its own proposal at #209, and I am closing this issue as superseded by it. The intention in doing this is to make the voting process more straightforward for everyone as the new write-up is more comprehensive in addressing various details. Please feel free to cross-post any outstanding feedback from this issue to that one.