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.

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.

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.

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.

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.

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.

I have the same idea with @invertedbobb

@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 am one of the victims and I would also like to receive BTC, as this was the purpose of the trade.

@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.

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.

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.

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

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.

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 to create project to track this overall effort (see Repay April 2020 security incident victims projects#31, https://github.com/orgs/bisq-network/projects/16)
• @cbeams to create an issue to track collecting victim repayment details (Collect victim repayment details admin#76)
• @cbeams to comment on @chimp1984's [WIP] Add list to filter to set btc fee receiver addresses bisq#4150 PR implementing the filter-based approach, indicating that we need to get it reviewed and merged (see [WIP] Add list to filter to set btc fee receiver addresses bisq#4150 (comment))
  • @ripcurlx to assign @cbeams is managing this
• @cbeams to create an issue to track implementing the "repayment tracking mechanism" described in this proposal
  • @cbeams to announce request for proposals/volunteers in #dev
  • @ripcurlx to ensure this gets assigned @jmacxx is assigned
• @cbeams to create proposal about how repayments will be denominated as discussed in Repay victims of the April 2020 security incident using BTC trading fees #209 (comment) (see Create follow-on repayment proposals re denomination and per-cycle limits admin#78)
• @cbeams to create proposal about maximum per-cycle repayment limits as discussed in Repay victims of the April 2020 security incident using BTC trading fees #209 (comment) (see Create follow-on repayment proposals re denomination and per-cycle limits admin#78)

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

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.