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

Investigate the possibility of switching from our 2/3 multisig scheme to 2/2 #14

Closed
erciccione opened this issue Nov 24, 2021 · 10 comments

Comments

@erciccione
Copy link
Contributor

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.

@erciccione
Copy link
Contributor Author

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

@SamsungGalaxyPlayer
Copy link

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.

@erciccione
Copy link
Contributor Author

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

@erciccione
Copy link
Contributor Author

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

@woodser
Copy link

woodser commented Nov 27, 2021

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?

@iljah
Copy link

iljah commented Nov 10, 2022

Plain xmr 2/2 could work I think:

  1. B wants to buy from seller S something worth 100€
  2. they make a 2/2 multisig wallet
  3. B deposits N€ worth of xmr to multisig
  4. S deposits N€ worth of xmr to multisig
  5. repeat steps 3-4 until S agrees to proceed to step 6
  6. S mails the item to B
  7. B signs and sends to S a transaction withdrawing 100€ worth of xmr to S
  8. S signs and sends to B a transaction withdrawing N€ worth of xmr to B
  9. B signs and sends to S a transaction withdrawing N€ worth of xmr to S
  10. 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.

@woodser
Copy link

woodser commented Nov 10, 2022

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.

@iljah
Copy link

iljah commented Nov 11, 2022

unacceptably high risk

1 € (more than the other party) is unacceptably high risk?

@woodser
Copy link

woodser commented Nov 11, 2022

Each trader would risk the full amount they deposit to multisig if the other trader disappears.

@iljah
Copy link

iljah commented Nov 11, 2022

Hence both traders have good incentive to finish the trade or to come to some other sort of agreement.

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

No branches or pull requests

5 participants
@iljah @SamsungGalaxyPlayer @woodser @erciccione and others