Skip to content

Coin allocation #12

@darosior

Description

@darosior

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions