[bisq-network/bisq] [WIP] Add list to filter to set btc fee receiver addresses (#4150)

Chris Beams notifications at github.com
Fri May 8 07:11:36 UTC 2020

@cd2357 wrote:

> why not just pay these funds out manually? Seems to achieve the same effect, with much less effort, complexity and risk.

The main reason is that it puts the manual distributor of those funds in a potentially sensitive legal position. None of us are lawyers, but we're always trying to avoid this kind of situation.

> Arguments for:
> * There are only 6 people affected

True; doing a single, manual, end-of-cycle batch payment to these six addresses wouldn't be hard.

> * It would also make tracking the payments easier

Payment tracking is already handled by https://github.com/bisq-network/admin/issues/77; there's nothing that need be made easier.

> * more flexibility in how much budget is used for this refund per cycle ([bisq-network/proposals#209 (comment)](https://github.com/bisq-network/proposals/issues/209#issuecomment-613289972))

This is a good point. It's basically an unresolved issue how we will manage this effectively under the current plan.

> * more flexibility in who gets how much when (see concerns about fairness of of payout algo in PR description)

I'd argue this should still be algorithmic / deterministic / rules-based even if payouts are being done manually. Still, having a human do it means being able to double-check that payment amounts are actually in line with the fairness intended by those rules.
> * if it's done by a human (and not by an algorithm), the "refund agent" could also talk to those people and cover @chimp1984 's points above (type of address, etc)

This isn't an issue. I'm already in communication with all 6 victims and have, as per https://github.com/bisq-network/bisq/pull/4150#issuecomment-625656603, already let them know about chimp's "type of address" comment.


In the end, I don't personally have a very strong argument why we shouldn't do this manually on a once-per-cycle basis. bisq-network/proposals#206 suggested a manual approach, but it involved a new "special refund agent" role and was more complicated, involving BSQ.

If the donation address holder were willing to do this work, I don't think I'd have a strong opposition to it. Even though we already decided via a DAO vote to go with the filter-based, automated approach, it's probably not too late to reconsider.

It is attractive to me to avoid the need entirely for this review and testing effort, and to redirect everyone's time to other, more productive activities. Another thing that is attractive about doing it manually is that it avoids concerns about what happens down the road when we're removing addresses that have been fully paid out. There is a certain risk that filter messages may not reach a node, and in the case of an address removal message failing to propagate, that node would keep making payments to the address indefinitely. We're aware of this problem and have acknowledged that we must lock down a solution before any addresses are close to being fully repaid. We should fix the underlying propagation/delivery reliability issue in any case, of course, but it would be good to remove this particular risk if we can.

So I'm open to this idea. I particularly like the fact that we can better manage how much gets paid out at the end of each cycle against our budget limits. I hate to re-open the implementation conversation and have to put this to another vote, but as per https://github.com/bisq-network/admin/issues/78, we have more proposals and voting to do on this matter anyway.

Thoughts? @burningman2, wdyt?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200508/2eb4f6b0/attachment.html>

More information about the bisq-github mailing list