Closed artemii235 closed 5 years ago
artemii235
commented
6 years ago Worth to add also that such concept will allow to hide specific coins support details under abstractions. Generally order matching module shouldn't know anything about coin protocol. Now it's strictly depended on UTXOs.
artemii235
commented
5 years ago jl777
I think it might be needed for mm2 to lock utxo that are reserved internally to allow it to interoperate with other native utxo consumers, like wallet, dicebet, etc.
we have some interaction with mm1 and dice betting, my guess is they shared the same utxo for input
artem.pikulin
Encrypted by a verified device
Hi James, do you mean lockunspent RPC method?
jl777
Encrypted by a verified device
yes
you also need to make sure to unlock it if it didnt end up being used. the syntax for that call is a bit backwards
artem.pikulin
I see, yes, it can be very useful, thanks!
This issue is created to discuss the RFC available at https://github.com/artemii235/SuperNET/blob/etomic/iguana/exchanges/utxo_handling_refactor_rfc.md. Some related discussions already happened in this issue: https://github.com/artemii235/SuperNET/issues/47
UTXO handling refactoring
This document is written to suggest and discuss possible ways of refactoring UTXO handling code in MM2.0.
Problems and Goals
BarterDEX main goal is to allow any user with any technical background to download app, send coins to address and be able to trade with any other user without knowledge about underlying technology. UX should be similar to centralized exchanges.
Most of coins supported on BarterDEX are different bitcoin forks based on UTXO protocol: https://bitcoin.org/en/developer-guide#block-chain-overview.
Current MM implementation is very dependent on set of UTXOs. As example when you want to deposit coins to BarterDEX address you will get a message that you should send 3 small transactions instead of big one. This is due to how MM handles address utxos. According to protocol https://github.com/SuperNETorg/komodo/wiki/barterDEX-Whitepaper-v2#overview-of-atomic-swaps-protocol each side of swap (in case of success) requires at least 2 utxos: for Alice dexfee and payment OR Bob deposit and payment. From Alice (buying side) these utxos are selected at time of broadcasting the order. MM also searchs for utxos that are close to the amount required for trade. If such utxos are not found order will either fail or cause splitting to cut some big utxo to smaller pieces.
Such things confuse the user a lot: let's imagine that one sent 5 BEER to his BarterDEX address and wants to buy 2 PIZZA at 1:1 rate. His utxo will either split causing to pay additional fees (which might be very high sometimes) or he will get message that he needs to send tx close to amount of he wants to trade (additional fees are also included). This is not like centralized exchages work. Users expect that they are able to trade ANY amount which is lower or equal to their deposit.
Another drawback: address becomes full of small utxos after split and these are not usable for any trade, my test addresses (on Jenkins CI) generate hundreds of unusable utxos in very short time. It's painful and costly (in case of dynamic fee) to merge them back, MM doesn't do this automatically.
1 more drawback: according to the set of found utxos MM can adjust trading amount and price to match the order. Users won't like such behavior, they expect that they will spend exact quantity of a coin to receive exact number of another one.
Also the orders do not match if price difference is larger than 10%. It's confusing when you see 1:1 selling order, place 2:1 buy, but it doesn't match.
Requirements we should meet
Goals. What's planned to do
virtuallylock the amount required to trade. Available amount will be equal tocurrent_balance - locked_amount.3, address has 3 utxo amounts:2,1,1. Use2and1utxo to send payment.