Investigate the possibility of switching from our 2/3 multisig scheme to 2/2
erciccione opened this issue · comments
Our trade protocol is based on Monero's 2/3 multisignature. Which means a trade involves 3 parties: buyer, seller and arbitrator. A normal trade without disputes doesn't require any active involvement of the arbitrator, but in case of unresolved disputes, the arbitrator can use their key to send funds to one or the other party.
in case of a protocol based on 2/2 multisignature, users' funds are time-locked and in case of unresolved dispute they are sent to the operators, who then decide who should receive a refund.
I'm investigating the benefits and drawbacks of adopting a 2/2 multisig scheme in Haveno.
Bisq's discussion and reasoning for their switch from 2/3 to 2/2: bisq-network/proposals#52.
Pros:
- Arbitrators have much less power, this makes their role much less sensitive. As a result would be easier to assign the role.
- Simpler protocol, which makes the 2 traders the only controller of their funds (unless there is an unsolved dispute)
cons:
Cons:
- This option could be considered more centralized than 2/3, since all funds would be sent to a centralized entity (Haveno operators) in case of unsuccessful mediation (meaning operators will have to decide who is right in the dispute). With 2/3, the arbitrator or the operators have never full custody of user's funds.
- The legal risks mentioned by Bisq as a reason for the switch to the 2/2 protocol:
some jurisdictions might interpret holding a key in a Multisig tx as shared control over the funds and therefor interpret the arbitrator as financial intermediary
As far as i understood this definition of "financial intermediaries" doesn't match the one provided by the FATF. Would be curious to see if there are countries who actually adopt this approach and to know what consequences this would have on the operators, even if they are based on a country that doesn't make such restrictive interpretation.
At the moment i don't see any clear benefit in switching to a 2/2 multisig scheme, but i'm very interested in feedback from the community on this matter. I'll keep this issue updated with new findings.
At the moment i don't see any clear benefit in switching to a 2/2 multisig scheme
The new proposed rules for Europe (#11 (comment)) could make a difference. The good news is that decentralized exchanges are not being regulated. The bad news is that we need to make sure Haveno fits in their concept of "decentralized exchange".
We will probably need lawyers or regulations experts to look into this. We will have to allocate some funds for this task
In the US, holding one key in 2/3 multisig is quite unlikely to constitute money transmission activities, since the keyholder never had custody of the funds.
On the technical feasibility of adding Timelocks to Monero (which will make possible switching to the 2/2 protocol). From monero-dev on IRC:
ErCiccione:
What would be needed to have timelocks in Monero? I know this question comes up from time to time, but timelocked transactions (like Bitcoin) would make Haveno more trustless, as it would get us closer to a 2/2 multisig protocol instead of the current 2/3 (where an arbitrator has one of the keys)
moneromooo:
A good look at what semantics would be best. A look at whether use of timelocks would introduce too much tx heterogeneity. Someone to do the work (which I do not expect to be hard).
It is possible to emulate bitcoin style timelocks by including a locked input in a tx fwiw.
ErCiccione:
with emulate you mean that it basically has the same effect? Meaning a transaction containing a locked input would be relayed after N days or discarded
moneromooo
I mean that my basic understanding of what locking does in bitcoin (prevent a tx from being mined before height N) can be done in monero by including an input locked till N-1 in the tx.
Now, my understanding of bitcoin's locking is vague, there might be subtleties I'm not aware of.
UkoeHB:
moneromooo: there has been some thought about deprecating monero's current locktime feature ( https://github.com/monero-project/research-lab/issues/78 ). I think bitcoin's NLocktime could be mimicked by adding a `mineable_heights` range rule. I.e. a tx can't be mined except in the heights [a, b].
@SamsungGalaxyPlayer thanks for the input. That's my understanding too. Bisq was worried that 2/3 could be considered like having partial control over the funds, but i haven't found any info about countries practically adopting this approach. The EU doesn't seem to use this approach as well.
moneromooo
I mean that my basic understanding of what locking does in bitcoin (prevent a tx from being mined before height N) can be done in monero by including an input locked till N-1 in the tx.
Now, my understanding of bitcoin's locking is vague, there might be subtleties I'm not aware of.
In other words, create tx A whose output unlocks at height N, create tx B which spends tx A's output, and tx B cannot be mined until tx A's output unlocks.
For Haveno, this would be mean creating the trader deposit txs to multisig, mining them (because creating txs from unmined outputs is not supported, but could be with wallet changes, is my understanding), and then creating a tx which spends the multisig deposits and some input which doesn't unlock for some time.
@moneromooo Is it possible for each tx output to have its own unlock time, or must all tx outputs have the same unlock time?
Plain xmr 2/2 could work I think:
- B wants to buy from seller S something worth 100€
- they make a 2/2 multisig wallet
- B deposits N€ worth of xmr to multisig
- S deposits N€ worth of xmr to multisig
- repeat steps 3-4 until S agrees to proceed to step 6
- S mails the item to B
- B signs and sends to S a transaction withdrawing 100€ worth of xmr to S
- S signs and sends to B a transaction withdrawing N€ worth of xmr to B
- B signs and sends to S a transaction withdrawing N€ worth of xmr to S
- repeat steps 8-9 until multisig is empty
Iterating enough times in steps 3-4 and 8-9 should guarantee that the other party loses at least a comparable amount of xmr in case things don't work out. Possibility of things not working out should decrease with increasing deposit(s). Presumably good reputation of S/B would lower the corresponding deposit and/or decrease the number of iterations. With timelocks only one iteration might be needed if both could sign a transaction burning everything in the future before any deposits are made.
After steps 3 & 4, if the counterparty disappears, one side would be stuck with lost funds in the 2/2 multisig wallet. I think this is unacceptably high risk. If both parties can pre-sign a tx to transfer all multisig funds to e.g. a donation address with the possibility of refund, it's workable.
unacceptably high risk
1 € (more than the other party) is unacceptably high risk?
Each trader would risk the full amount they deposit to multisig if the other trader disappears.
Hence both traders have good incentive to finish the trade or to come to some other sort of agreement.