feature request: splitting utxos

[particle4dev]

Currently, when I want to split UTXOs I use the same buy API. It would be nice if utxos has their own API like splitting UTXOs, joining UTXOs. Thanks https://github.com/KomodoPlatform/dicoapp-e/blob/master/app/containers/BuyPage/saga/load-buy-coin-process.js#L78 \cc @ArtemGr @artemii235

[ArtemGr]

And here's a pointer to the pointer with examples.

@particle4dev , I wonder if you have a draft of the new UTXO splitting API in mind? We can probably figure the API later while refactoring the splitting code there, but on the other hand having a draft of it here in the issue might lift the "fog of war" somewhat.

[particle4dev]

Hi @ArtemGr,

I really need these API in my app. We can improve the speed and success rate of a swap by preparing the necessary alice utxos (fee, vol). Right now it happens “like” a magic in marketmaker app. I want to control it in UTXO level. There’s a trick to splitting UTXO is send tx to yourself but UTXO should have their own API. The API is pretty simple. It can look like this:

Category: UTXO

Methods:

splittingUTXOs
{
  "userpass": "$userpass",
  "method": "splittingUTXOs",
  "coin": "KMD",
  “amount”: 1000 // in satoshi
}

joiningUTXOs
{
  "userpass": "$userpass",
  "method": "joiningUTXOs",
  "coin": "KMD",
  “amount”: 1000 // in satoshi
}

[artemii235]

Hi, as we've discussed at discord it's highly likely that this API won't be needed anymore. I plan to refactor UTXO selection - even MM itself won't split UTXOs to place order, the UTXO related code is being removed from orderbook at all. No need for extra preparation steps from GUI side.

[particle4dev]

@artemii235 uhm, that's nice. Is it available in mm1? or it's only in mm2

[artemii235]

It's planned in MM2 only - it's 1 of main goals of MM2 to implement such improvements as it's hard to do it in MM1. Also by low level we mean the interaction with coin daemons/electrum servers, nothing prevents GUI from sending requests bypassing MM at all. Or we can implement a proxy method in MM2 that will bypass the request to corresponding coin daemon - in case GUI developer wants to do something on his own. It'll be universal replacement of splitUtxos or other custom methods.

[particle4dev]

thanks @artemii235, I do remember your comment. Just need a confirmation :)

Also by low level we mean the interaction with coin daemons/electrum servers, nothing prevents GUI from sending requests bypassing MM at all.

This is where I misunderstand, I thought I have to interact with mm app. Got it now. Thanks

[ArtemGr]

the UTXO related code is being removed from orderbook at all. No need for extra preparation steps from GUI side

I figured that would be the case, and wondered if, for dICO, we can refactor it into a different API method instead of removing it altogether.

Or we can implement a proxy method in MM2 that will pass the request to corresponding coin daemon .. It'll be universal replacement of splitUtxos or other custom methods

This sounds even better! GUI can then reuse it's MM2 auth and communication channels. Given that MM2 has to communicate with the said wallet daemons anyway (and will likely check the installation and health of the wallets in the future), this seems like a win-win solution to me. We might even use this proxy ourselves from the MM2 automatic tests (e.g. using mm.rpc (json! ({})) to check a wallet or set it up for a test).

Hi, as we've discussed at discord it's highly likely that this API won't be needed anymore. I plan to refactor UTXO selection - even MM itself won't split UTXOs to place order,

This is interesting! Will the split happen at some other time later in the swap?

[artemii235]

@ArtemGr Hi! This is interesting! Will the split happen at some other time later in the swap? - yes, UTXO selection on order broadcast have significant drawbacks:

1. It's required to split UTXOs and it is not really clear process now.
2. I think it's not right to select UTXOs before the swap started, there is no guarantee that your order will match but your UTXOs are getting locked already. The Bob side can use his balance to place selling orders with different pairs (like KMD/BTC and KMD/ETH at 1 time hoping 1 of them will match), we can do same for Alice. so yes, I want to select which UTXOs to spend just before sending the transaction after the swap has started already. I figured that would be the case, and wondered if, for dICO, we can refactor it into a different API method instead of removing it altogether. if we consider the refactoring mentioned above splitUtxos is not needed, that's the main idea I'm trying to describe :slightly_smiling_face:

Proxy method: This sounds even better!, yes, the developers using MM will be able to directly communicate with underlying daemons at their own risk. This covers splitUtxos and a lot of other custom methods that might be required for someone.

[particle4dev]

I think it's not right to select UTXOs before the swap started, there is no guarantee that your order will match but your UTXOs are getting locked already. The Bob side can use his balance to place selling orders with different pairs (like KMD/BTC and KMD/ETH at 1 time hoping 1 of them will match), we can do same for Alice. so yes, I want to select which UTXOs to spend just before sending the transaction after the swap has started already. Hi @artemii235 It’s a good idea but we should think it carefully This case could happen if we allow a user to place selling orders with different pairs.
 Let say, I want to sell 10 KMD so I open 8 selling orders (KMD/BTC, KMD/LTC, KMD/COQUI …). 8 users see my orders and want to make a swap but only one person who made the swap early is successful. 
7 users will see their swap is failed I think this is not good for user experience. We only satisfy one user, 7 users will have a bad experience with our app. Moreover, a user can not expect the result (which pairs will be successful - KMD/ BTC, KMD/LTC …) which can also make bad of user experience.

[artemii235]

@particle4dev Hi, even on centralized exchange your order might not match if someone buys/sells before you. It's ok if user will receive the message that other order was cancelled/removed for some reason. Next: if user wants to trade exactly KMD with BTC what is the reason for him to place KMD/LTC order? There are 2 possible use cases, let's assume that one has 200 KMD:

1. He wants to exchange 200 KMD to BTC or LTC and he doesn't care to which one exactly it'll be exchanged, he puts orders for 2 pairs with his total 200 amount.
2. He wants to exchange half to BTC and LTC, he places 2 orders with 100 KMD, if the orders match he will get exactly what he expected.

Such approach gives us additional flexibility, but we don't force the user to trade different pairs at 1 time. It can be nice feature: you can use your full balance for different concurrent orders, but, of course, you must not do it.

[particle4dev]

On centralized exchange, I believe they use a order matching system to match buy/sell orders. If a user’s order has not matched yet, it still there in orderbook. No error to user.

Such approach gives us additional flexibility, but we don't force the user to trade different pairs at 1 time. It can be nice feature: you can use your full balance for different concurrent orders, but, of course, you must not do it.

I got it but it also can be a nightmare.
Let's suppose I want to sell LTC and KMD. I make 5 selling orders for KMD and 4 selling orders for LTC

• How many percent can user match with 2 orders: 1/5 * 1/4 = 5/100
• How many percent can user match with 1 orders: 1/5 3/4 + 4/5 1/4 = 35/100
• How many percent can user match with 0 orders: 4/5 * 3/4 = 60/100 So there is 60% of user who will see the app is not work. I know my assumption sound stupid but it explains to my opinion.

[artemii235]

Sorry, I didn't really understand how you calculate the chances. Let's use the very simple model, e.g we have only 3 markets: KMD/BTC, KMD/LTC, KMD/ETH. Let's assume that probabilities of your order being filled in 5 minutes are: 60% for KMD/BTC, 30% for KMD/LTC and 10% for KMD/ETH. When you put orders on different markets your should apply logical OR operation. Your order will match on KMD/BTC OR KMD/LTC OR KMD/ETH. Logical OR means that chances must be added to each other. So, in our simplified model if we place orders in all 3 markets 1 of them will be surely matched in 5 minutes with 100% (60 + 30 + 10) chance. Moreover it's responsibility of GUI UX and documentation to help user understand how to deal with it. Placing your full balance for orders on different markets might be even optional for experienced traders only. And the most important, such functionality is already implemented in MM1 and it's marketed as improvement: https://github.com/SuperNETorg/komodo/wiki/barterDEX-Whitepaper-v2#improvements-implemented-in-barterdex It also implements Liquidity Multiplication that allows the same funds to be used for asks in multiple "orderbooks", where the first to fill gets the trade. This allows 100 BTC worth of funds to create thousands of BTC worth of liquidity and provides a special advantage for traders that like to wait for below market dumps. While this feature is something that any other exchange could implement, very few if any do. All orderbook entries are 100% backed by real funds, yet the same funds can be part of 25 different "orderbooks". .

[particle4dev]

Ah, sorry if you are misunderstanding. My assumption is for buying side, not for the selling side. 
For the selling side, if barterdex list 20 KMD/XXX pair and you make 3 selling orders for KMD so there will be 3/20 percent that your order can be matched. Thanks for the link, I will read it tonight :)

[particle4dev]

It also depends a lot on liquidity so that why I think my assumption sound stupid. It does not reflect reality

[artemii235]

Yes, it's not correct to suppose that every pair have same chances for order to be matched in some period of time. There is always more liquidity on some markets (like pair with BTC) and less on other markets. Ofc you have little chance to match on market like KMD/COINEX: https://coinmarketcap.com/currencies/coinex-token/#markets - just random coin from the very bottom of Coinmarketcap. So if you place orders on a lot of low liquidity markets and not getting matched it's not problem of the app, it's problem of market itself. That's my previous example is based on top currencies.

[artemii235]

Closing the issue as there is no need to split UTXOs in MM2 at all.