coinselect icon indicating copy to clipboard operation
coinselect copied to clipboard

Adding Moneypot simulation

Open karelbilek opened this issue 8 years ago • 10 comments

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 :(

karelbilek avatar Jul 12 '17 16:07 karelbilek

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

karelbilek avatar Jul 12 '17 17:07 karelbilek

LGTM, will merge after nit then play with it locally

dcousens avatar Jul 12 '17 23:07 dcousens

should I do that in this PR or separately

ignore for now, I'll find out post-merge

dcousens avatar Jul 12 '17 23:07 dcousens

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.

karelbilek avatar Jul 15 '17 16:07 karelbilek

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.

dcousens avatar Jul 16 '17 10:07 dcousens

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!

karelbilek avatar Jul 17 '17 17:07 karelbilek

@karel-3d shall I rebase/merge this?

dcousens avatar Sep 07 '18 01:09 dcousens

What are the benefits of this PR?

dcousens avatar Sep 07 '18 01:09 dcousens

More data for the simulations. It's from an actual big hot wallet of some online betting game

karelbilek avatar Sep 07 '18 07:09 karelbilek

@karel-3d the data you bring in, probably needs to be attributed/linked back to https://github.com/Xekyo/CoinSelectionSimulator in some way? (@Xekyo)

dcousens avatar Sep 07 '18 07:09 dcousens