i have heard about this problem from a couple of users and now i guess i know when and why this happens
imagine you have 100 KMD in a single UTXO
then you post several maker orders, eg 5 orders each selling 10 KMD
when a taker fills one of those orders a swap starts and kdf would need to send 10 KMD... since you have a single UTXO, it will send 100 KMD with 90 KMD change back to you... and here is the problem... theoretically you still have 90 KMD left, so the other 4 orders should stay up... but they don't, they are all cancelled and you need to manually repost them
i guess the reason is that while sending the 100 KMD with 90 KMD change, your balance is 0 till those 90 KMD make it back to your address (tx confirmed) and kdf kills all other orders because it thinks it has no KMD left
the problem is aggravated by the fact that kdf tends to reduce the number of UTXOs over time, when doing swaps... every time you sell KMD, it will use many/all/idk available UTXOs and create a single UTXO out of it (the change)... the number of UTXOs on KMD will only increase if you either send more manually to that address, or when you also buy KMD with a swap... if you only sell, you will quickly run into this problem
what can be done to mitigate this?
can we treat incoming txes with 0 confirmations as "balance"? so that in the above case the balance would be 100 at start, then 90 after first swap started (instead of 0)
does kdf actively/explicitly cancel those orders? based on the 0 balance assumption with 90 KMD incoming? if so can we remove that cancel_orders call from code?
i have heard about this problem from a couple of users and now i guess i know when and why this happens
imagine you have 100 KMD in a single UTXO
then you post several maker orders, eg 5 orders each selling 10 KMD
when a taker fills one of those orders a swap starts and kdf would need to send 10 KMD... since you have a single UTXO, it will send 100 KMD with 90 KMD change back to you... and here is the problem... theoretically you still have 90 KMD left, so the other 4 orders should stay up... but they don't, they are all cancelled and you need to manually repost them
i guess the reason is that while sending the 100 KMD with 90 KMD change, your balance is 0 till those 90 KMD make it back to your address (tx confirmed) and kdf kills all other orders because it thinks it has no KMD left
the problem is aggravated by the fact that kdf tends to reduce the number of UTXOs over time, when doing swaps... every time you sell KMD, it will use many/all/idk available UTXOs and create a single UTXO out of it (the change)... the number of UTXOs on KMD will only increase if you either send more manually to that address, or when you also buy KMD with a swap... if you only sell, you will quickly run into this problem
what can be done to mitigate this?
can we treat incoming txes with 0 confirmations as "balance"? so that in the above case the balance would be 100 at start, then 90 after first swap started (instead of 0)
does kdf actively/explicitly cancel those orders? based on the 0 balance assumption with 90 KMD incoming? if so can we remove that cancel_orders call from code?