coinselect
coinselect copied to clipboard
Adding Moneypot simulation
Adding data from Moneypot simulation from Murch, from https://github.com/Xekyo/CoinSelectionSimulator
The data are described on pages 43/44 (in PDF, on pages 53/54) in the thesis http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf - this is the "derived analysis".
Note that some of the analysis are extremely slow; for my own experiments, I needed to comment out bestof since it took just too much time. I have also added time to the printed table; but I was not sure about the unit - since both simulations use the same "table" logic, but the time is different in orders of magnitude. (The same actually applies to the other values.)
The table starts to also be so big it doesn't fit on my terminal anymore :(
The standard test error is some npm craziness
https://github.com/standard/standard/issues/949 https://github.com/npm/npm/issues/17717
works with yarn though :)
I can fix the npm issue with an edited travis.yml; should I do that in this PR or separately
LGTM, will merge after nit then play with it locally
should I do that in this PR or separately
ignore for now, I'll find out post-merge
Hm, I finally found out why I have different results from murch's simulation.
It seems in his simulation, if a wallet/strategy cannot make a tx because it has too small "balance", the outgoing transaction is waiting until the "balance" is high enough.
It's actually more complex - if he is comparing more wallets/strategies and any of them don't have enough money, all of them are waiting (that is, receiving new utxos) until all of them have enough balance. (And "enough balance" is actually "all outgoing outputs + some artificial constant." :))
In this repo, the transaction just won't happen (and is counted in the DNF percentage).
So the ending "total costs" are not directly comparable.
I kinda like the idea of "waiting until there is enough balance", if not exactly how the other repo is doing it, since that simulates user's behavior more.
I kinda like the idea of "waiting until there is enough balance", if not exactly how the other repo is doing it, since that simulates user's behavior more.
Agreed, DNF is still a possibility, but, certainly less likely.
I wonder how the "wait" approach might impact results though, since you are allowing some algorithms to wait for more optimum UTXOs, which may disadvantage others unfairly.
OK, I have added fixes for the script size, plus correct MP data, plus waiting for the queue (needs #18 first)
I do this torrent of commits, since I finally made the two repos behave exactly the same to the satoshi, so I needed to make a lot of changes :)
this should be all though!
@karel-3d shall I rebase/merge this?
What are the benefits of this PR?
More data for the simulations. It's from an actual big hot wallet of some online betting game
@karel-3d the data you bring in, probably needs to be attributed/linked back to https://github.com/Xekyo/CoinSelectionSimulator in some way? (@Xekyo)