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

Repay victims of the April 2020 security incident using BTC trading fees #209

Closed
cbeams opened this issue Apr 14, 2020 · 16 comments
Closed
Assignees
Milestone

Comments

@cbeams
Copy link
Member

cbeams commented Apr 14, 2020

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

What follows was originally posted at #205 (comment) and has been reposted here as its own proposal for clarity. This proposal supersedes #205, which has now been closed, but readers may still wish to review the comment thread there.

Background

On the dates of March 28th and April 7th 2020, a total of 34.86 bitcoin were stolen from 6 Bisq traders attempting to buy BTC in exchange for XMR. The blog post at https://bisq.network/statement-security-vulnerability-april-2020 explains the nature of the theft, and the pull request at bisq-network/bisq#4134 fixed the flaw that made it possible.

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 in #205 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 proposed Filter-based implementation, 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

UPDATE 2020-04-19: Per #209 (comment), this section will be separated out and voted on in a subsequent proposal. This section is left here for context, but SHALL NOT BE BINDING if this proposal is approved. The "tracking mechanism" mentioned below SHALL BE DEVELOPED in any case, however.

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.

UPDATE 2020-04-19: Per #209 (comment), the following paragraph will be separated out and voted on in a subsequent proposal. The paragraph is left here for context, but SHALL NOT BE BINDING if this proposal is approved.

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.

@MwithM
Copy link

MwithM commented Apr 14, 2020

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.

This doesn't match with "the DAO will repay victims as quickly as possible". I acknowledge and agree that there must be a minimum for the Bisq to keep working, or it will be impossible to compensate victims.
If monthly revenue increases to 100.000 instead of 30.000 USD, I don't see why Bisq should keep that 40% limit or not use the revenue increase to pay victims as soon as possible.
I would rather stablish a minimum budget for Bisq survival and the rest, or at least a high amount of it, should be used to compensate the victims.

@333shine
Copy link

I am one of the victims and I hope to receive the exact amount of BTC I lost.
(not the USD value of funds I lost at the time of theft)

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

I think that Bisq's monthly revenue in BTC will not down when BTC price pumps.

(I talk on the premise that Bisq's monthly revenue will increase when the trading volume increase)

There is no obvious negative correlation with BTC price and Bisq trading volume.
Therefore, it can be said that Bisq's monthly revenue in BTC is not always down when BTC price pumps.
On the contrary, Bisq's monthly revenue in BTC increased when BTC price was up in the last year(e.g. last June to August).

as to XMR/BTC market:
XMR/BTC trading volume accounts for a large portion of Bisq's trading volume this year.
This is just my guess but BTC/USD price does not affect XMR/BTC trading volume because XMR sellers always hold BTC and only care about XMR premium price( they mainly seek arbitrage opportunities ).

Here are BTC's monthly average price and Bisq's monthly trading volume in BTC since Jan 2019.

Month BTC average price(in USD) Bisq’s trading volume(in BTC) XMR/BTC trading volume(in BTC)
2020/3 6951 476 326
2020/2 9661 563 473
2020/1 8297 320 233
2019/12 7260 401 320
2019/11 8391 459 374
2019/10 8348 518 382
2019/9 9838 1122 914
2019/8 10646 2498 2428
2019/7 10698 1624 1556
2019/6 9333 2850 2773
2019/5 7191 1018 940
2019/4 5118 1349 1235
2019/3 3930 464 356
2019/2 3675 657 558
2019/1 3661 962 651

source of BTC average price: https://www.coingecko.com/en/coins/bitcoin/historical_data/usd?start_date=2019-01-01&end_date=2020-04-14

Still, there is a possibility that Bisq's monthly revenue drops significantly in the future.
But I am fine if my monthly repayment amount drops when Bisq's monthly revenue drops.

@huey735
Copy link
Member

huey735 commented Apr 14, 2020

I'd like to hear from the other victims too. Like @333shine, I assume most of you are interested in btc, not bsq, usd, xmr. Correct?
All this conversation involving these other assets brings unnecessary confusion to the conversation. And like @MwithM said above, the btc limit shouldn't be a percentage but rather an amount. If we agree to reimbursing the victims, anything but essential expenses should be directed to them. As essential I mean the Development, Ops and Support Teams.

@freimair
Copy link
Member

a pragmatic approach would be to try to keep track of the refunds payed to the victims in USD AND BTC. Then we have the data and we can decide on the go.

@invertedbobb
Copy link

invertedbobb commented Apr 14, 2020

I would be fine getting reimbursed in either BTC or XMR, preferably BTC as that is what i was supposed to get out of the trade and my trade strategy is based on that. @huey735
But XMR is great all by itself so I would be okay with that too.

As @333shine indicated if revenue for Bisq becomes lower i don't mind getting back less per month and having to wait longer. The amount matters more to me than the time-frame in which it would be reimbursed.

@333shine
Copy link

I have the same idea with @invertedbobb

@cbeams
Copy link
Member Author

cbeams commented Apr 15, 2020

@freimair wrote

a pragmatic approach would be to try to keep track of the refunds payed to the victims in USD AND BTC. Then we have the data and we can decide on the go.

This is the plan, as per the following excerpts from the proposal:

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.
[...]
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.

@Akira45-0
Copy link

I am one of the victims and I would also like to receive BTC, as this was the purpose of the trade.

@invertedbobb
Copy link

@freimair wrote

a pragmatic approach would be to try to keep track of the refunds payed to the victims in USD AND BTC. Then we have the data and we can decide on the go.

This is the plan, as per the following excerpts from the proposal:

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.
[...]
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.

I'm confused. The first and last part seem to be (partially) in conflict?
English is not my native language, i apologize if i misunderstand something.

@cbeams
Copy link
Member Author

cbeams commented Apr 19, 2020

The proposal phase for Cycle 12 is almost over. I'd like to summarize where we are in this conversation and see if it's appropriate to submit this proposal to the DAO for an immediate vote.

Below, I will list each of the major sections of the proposal as laid out in the description above, and I'll summarize the areas where I believe we have consensus and where we don't.

The DAO will repay victims for their losses

I believe we have consensus.

The DAO will not repay victims immediately + The DAO will repay victims over time

I believe we have consensus.

The DAO will repay victims using trading fees paid in BTC

I believe we have consensus.

The DAO will repay victims directly using Bisq's Filter mechanism

This part is detailed in @chimp1984's original proposal at #205. I believe we have consensus on doing it this way.

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

We do not yet have consensus here. The following counter-proposals are on the table:

  1. In Repay victims of the April 2020 security incident using BTC trading fees #209 (comment), victim @333shine argues that the DAO should pay out the exact amount of BTC lost to each victim, regardless of any movement in the BTC/USD price. The argument here is that Bisq's volume and therefore trading fees will likely increase with any increase in price, making it feasible to pay back the full amount. Multiple victims have indicated in the comments that if Bisq's trading fees do not increase accordingly, that they are fine waiting as long as it takes for the DAO to repay the original BTC amount lost.

  2. @invertedbobb proposed in Distribute trade fees paid in BTC to victims of the recent security issue #205 (comment):

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.

I suggest that we defer this decision by moving it to a separate proposal to be voted on in the next cycle (Cycle 13). Doing so will allow us to approve everything else in this proposal and to get victim repayments started as quickly as possible. It will take many months in any case to get anywhere near repaying the full value, be it the original BTC amount lost or the BTC equivalent of the USD value of the funds lost at time of theft. As detailed in the proposal, we will track both of these values from the start, so we will be able to implement either decision.

The DAO will repay victims as quickly as possible

I believe we have consensus on this section, with the exception of the following point:

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.

In #209 (comment), @MwithM counter-proposes the following:

If monthly revenue increases to 100.000 instead of 30.000 USD, I don't see why Bisq should keep that 40% limit or not use the revenue increase to pay victims as soon as possible.
I would rather establish a minimum budget for Bisq survival and the rest, or at least a high amount of it, should be used to compensate the victims.

Like with the section above, I believe we can defer this specific decision to a separate proposal to be voted on in Cycle 13. The most important thing at this point is to develop the payment tracking mechanism and begin routing payments to victims as soon as possible.


I will add notes to the original proposal text above indicating the sections where we do not have consensus, and where I suggest we defer decision-making to a subsequent proposal. I will then submit this proposal to the DAO such that it can be voted on immediately in Cycle 12.

@cbeams
Copy link
Member Author

cbeams commented Apr 19, 2020

Per the comment above, please see the "UPDATE 2020-04-19" notes added to the original proposal description with the sections of text that have been struck through to indicate their deferral to a subsequent proposal.

@cbeams cbeams added this to the Cycle 12 milestone Apr 19, 2020
@cbeams cbeams self-assigned this Apr 19, 2020
@cbeams
Copy link
Member Author

cbeams commented Apr 19, 2020

This proposal has been submitted to the DAO for voting in Cycle 12 with transaction ID 3022d9acabc4e3805cd7317ad2bb311d264c74078f4c65c19227c2eec1d849e1.

@cbeams
Copy link
Member Author

cbeams commented Apr 20, 2020

Regarding #209 (comment), @invertedbobb wrote:

I'm confused. The first and last part seem to be (partially) in conflict?
English is not my native language, i apologize if i misunderstand something.

They are not in conflict. It just means that the repayment tracking mechanism will track both the total value of BTC repaid to each address as well as the total USD value according to the USD/BTC price at the time of each BTC payment.

@cbeams
Copy link
Member Author

cbeams commented May 1, 2020

This proposal was approved in Cycle 12, so now we need to set about implementing the solution and creating the follow-on proposals. The task list below captures the next steps as I see them:

@cbeams
Copy link
Member Author

cbeams commented May 1, 2020

@bisq-network/proposals-maintainers, please leave this proposal open until the task list above is completed, thanks.

@cbeams
Copy link
Member Author

cbeams commented May 7, 2020

Closing as accepted. Re the task list above, I've moved creating the follow-on proposals to a dedicated issue at bisq-network/admin#78. Please subscribe to that to stay informed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants