Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coin allocation #12

Open
darosior opened this issue Jun 18, 2021 · 4 comments
Open

Coin allocation #12

darosior opened this issue Jun 18, 2021 · 4 comments
Assignees

Comments

@darosior
Copy link
Member

darosior commented Jun 18, 2021

We should consider a consumed vault to be spent and forget it after a long enough period, say 144 blocks. A one day reorg would already raise more significant concerns about PoW than we need to worry for our poor coin re-allocation mechanism for fee-bumping wallets.

Once a vault is forgotten, if it still had coins allocated to it (ie if it was spent cleanly, or Canceled without needing to use the entire reserve [0]) they are marked as "unregistered".

Freshly refilled coins are laid-out as described in #5 and marked as "unregistered".

When we are asked to watch a new vault (currently at vault creation but should probably be at vault delegation instead), we pick one "Vm coin" and n "Vb coin"s (see #5 for the definition of Vm and Vb and some discussion around it) from the pool of "unregistered" coins. We follow this process:

  • select the coin from the pool which value v is closer to Vm with a maximum gap of 0.2 * Vm, this is the "Vm coin". If no such coin exist, fail (FIXME: we should instead consolidate? Or actually just multiple have Vm coins?).
  • select any set of size larger than 5 and smaller than 10 of coins from the pool which total value t is (R*S - Vm)*0.95 <= t <= (R*S - Vm)*1.05 [1], these are the n "Vb coin"s. If no such set exist, fail (FIXME: dig more into the margins and bounds there)

[0] Note how this is likely given the very high value of the reserve.
[1] This is in order to be able to work with coins which value is not exactly close to Vb without having to consolidate them. In practice however the "Vb coins"s are expected to be somewhat consistent in size over a medium timeframe.

@JSwambo
Copy link
Member

JSwambo commented Jun 28, 2021

We should consider a vault to be spent and forget it after a long enough period, say 144 blocks.

What? Why would a WT want to forget about a vault? Why wouldn't the WT watch a delegated vault until it is consumed with spend/cancel/emer?

@darosior
Copy link
Member Author

I meant after it's consumed obviously. Editing now to make it clearer

@darosior
Copy link
Member Author

For posterity: the code doesn't actually implement that, but something reasonably similar. It falls back to selecting any coin instead of failing too.

@darosior
Copy link
Member Author

So actually the current coin selection falls back to allocate coins out of the distribution instead of failing. I think it should fail as it could allocate too many coins to a vault while the Cancel coin selection algorithm is O((n-1)!) AFAICT.

cc @JSwambo

@darosior darosior changed the title How to allocate coins from the pool to a newly watched vault Coin allocation Nov 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants