Coin dist adventures

[darosior]

New algorithms for:

• The coin layout
• The Cancel coin selection
• The CF coin selection

They have a stronger rationale IMO and also much better results in my initial testings. Still WIP though!

[darosior]

Any instance i missed? ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Le lundi 25 octobre 2021 à 12:09 PM, JSwambo @.***> a écrit :

@JSwambo commented on this pull request.

Note: there's many Vb and Vm related things to clean up if they aren't used for fb_coins_dist

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[JSwambo]

Any instance i missed?

is_negligible and cancel_coin_selec_1 in statemachine.py and some plotting related stuff in simulation.py

... not that many actually

[darosior]

We should really ditch all the other coin selection but the one not consolidating.. All the heuristics they use are flawed.

[darosior]

Ok, pused an update. I think it's now final although i'm not 100% sure i recall my TODOs from 2 weeks ago..

[darosior]

Rebased on master after #93 merge. This is now ready for review.

Noticed an underpayment:

ERROR:root:     Not enough coin allocated to select for Cancel. 82888sats still needed after selecting [Coin(id=58, amount=169686, fan_block=350000, state=ProcessingState.CONFIRMED), Coin(id=59, amount=110831, fan_block=350000, state=ProcessingState.CONFIRMED), Coin(id=51, amount=110831, fan_block=350000, state=ProcessingState.CONFIRMED), Coin(id=84, amount=81404, fan_block=350000, state=ProcessingState.CONFIRMED)].

[darosior]

A side effect of this is the significant simulation runtime decrease due to having a lot less coins.

[JSwambo]

We should really ditch all the other coin selection but the one not consolidating.. All the heuristics they use are flawed.

I think they are flawed with the new coin distribution too. I think we should have some heuristic for consolidation though. If not... dust coins can accumulate.

The per-vault reserve dist is topped up as needed, and (I think) those coins will not become "dust" (at our anticipated max fee-rate) based on their definition at time of creation. They could become "dust" if we underestimate the max-feerate, in which case new coins which top-up the reserve dist must be created (with refill & cf transition). "dust" reserve coins just move to the bonus reserve.

The per-vault bonus reserve is more likely to accumulate actual dust over time, and I think those should be consolidated. Any coin that isn't able to bump the feerate of a cancel at the current feerate (or past 90 days, or similar) should considered as dust.

[darosior]

If not... dust coins can accumulate.

I don't disagree, however in all simulations i ran looking closely at the allocated coins dist the supply of small coins runs out pretty quickly. In practice we have large-ish small coins that get consumed most of the time during normal fee periods.

The per-vault reserve dist is topped up as needed, and (I think) those coins will not become "dust"

I agree. One aspect that we explicitly did not consider but turns out to be more important than i expected is about too large coins. Considering the current exchange rate of bitcoins compared to when we started this study, fees are higher denominated in $ but lower in BTC: we might have to split too-large coins in the future. Even, in practice, not have a perpetually increasing reserve feerate..

But all that is pretty far-fetched and i am still biased toward "price won't go up forever and CUMMAX is still what makes most sense" :).

or past 90 days

I think it's what makes the most sense. But you really don't want to be consolidating during a high-fee period so it needs to be:

• if wouldn't bump at ME90 feerate + we are in a decently low fee period

[darosior]

Ok i forgot to push :sob:. Here you go

[darosior]

Now cleaning up the CF coin selections