nymius / bdk-coin-select-simulation Goto Github PK

Describe the bug
The deposit count in the results.csv output, which samples the simulation results on each 500 withdraw attempts, is not being reported correctly.

To Reproduce
Steps to reproduce the behavior:
(on bash)

1. cd bdk-coin-select-simulation
2. rm -f simulation_results/
3. git checkout 3e0c309
4. cargo build --manifest-path ./Cargo.toml -p bdk-coin-select-simulation --release
5. cargo run --manifest-path ./Cargo.toml -r -p bdk-coin-select-simulation -- ./data/scenarios/bustabit-2019-2020-tiny.csv ./simulation_results
6. `head -n 2 simulation_results/results.csv | tail -n 1 | column -t -s, --json --table-columns $(head -n 1 simulation_results/results.csv) | jq -r '.table[] | .deposit_count'
7. head -n 500 data/scenarios/bustabit-2019-2020-tiny.csv | grep -v '^-' | wc -l

Expected behavior
The results of the steps 6 and 7 of the previous section should be equal.

Screenshots

Desktop (please complete the following information):

> lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.4 LTS
Release:        22.04
Codename:       jammy

> rustc --version
rustc 1.75.0 (82e1608df 2023-12-21)

> cargo --version
cargo 1.75.0 (1d8b05cdd 2023-11-20)

Additional context
During simulations is possible to cat the other simulation files, like utxos.csv or full_results.csv and get the data that has been already written to the document. However, this is not possible with results.csv.

It's not clear how failed payments should be managed, opening up the opportunity to extract multiple scenarios out of a single simulation.
Some policies that I thought about were:

• failed payments are rolled forward until the next payment request arrives (current policy).
• failed payments are dropped.
• failed payments are queued in order and are fulfilled once there is enough balance, one a time.
• failed payments are queued in order but fulfilled in a best effort basis, trying to pay the most of them if possible.

Could you provide more use cases for this?
This policies are only applicable to simulations, as in real life, individual wallets will inform their users about the failed payments, drop it immediately and wait for the user to top up the wallet to retry the payment. Or in enterprise situations, failed payments are going to be enqueued, but trigger other logic, like automatic top up policies, before proceeding paying.

Describe the solution you'd like
Something like a SimulationConfig context for which a single payment policy could be specified, which can be passed through command line parameters.

Describe alternatives you've considered
I've wondered if this is necessary at all. The policy could be hard coded, but this tools wants to be interoperable between different coin selection implementations, and provide flexibility for simulations, so I'm positive this is a needed feature.

Additional context
This came to my mind after seeing the high failure rate of the current simulated algorithm. A less restrictive failed payment policy could help to increase the success ratio.