An address pool caches a collection of addresses (type addr ) which are derived from a numeric index (type ix ).

Mapping from a numeric index to its corresponding address.

This mapping is supposed to be (practically) a one-way function: Given an addr , it is impossible to compute the preimage ix in practice. The purpose of the Pool data structure is to help inverting this function regardless. The idea is that addresses with small indices 0,1,… are Used before addresses with larger indices; specifically, only less than gap many addresses in sequence may be Unused before the next Used address. This usage scheme restricts the search space considerably and allows us to practically invert the addressFromIx function.

Partial, cached inverse of the addressFromIx . This map contains all cached addresses addr , their corresponding indices ix , and whether they are Used or Unused . See prop_sequence .

Sorted list of all addresses that are marked Used in the pool.

The pool gap determines how Used and Unused have to be distributed. See prop_gap and prop_fresh .

Look up an address in the pool.

Number of addresses cached in the pool.

Given an index ix , return the enumerated successor Just (succ ix) as long as the address corresponding to this successor is still in the pool.

This function is useful for address discovery in a light client setting, where the discovery procedure is: Start with index ix = 0 , query the corresponding address in an explorer, update address pool and repeat with successor ix until the latter returns Nothing . According to the BIP-44 standard, the account may not contain any other addresses than the ones discovered.

This function is not useful for generating change addresses, as it does not take Used or Unused status into account.

Create a new address pool.

Replace the collection of addresses in a pool, but only if this collection satisfies the necessary invariants such as prop_sequence etc.

Update an address to the Used status and create new Unused addresses in order to satisfy prop_fresh .

Does nothing if the address was not in the pool.

Remove all previously discovered addresses, i.e. create a new pool with the same addressFromIx and gap as the old pool.

Discover transactions and addresses by using an efficient query addr -> m txs and an address pool.

Replace the collection of addresses in a pool, but skips checking the invariants.

Internal invariant: The indices of the addresses in a pool form a finite sequence beginning with fromEnum 0 .

Internal invariant: If we order the addresses by their indices, then there are always less than gap many Unused addresses between two consecutive Used addresses, or before the first Used address.

Internal invariant: If we order the addresses by their indices, there are exactly gap many Unused addresses after the last Used address.

Internal invariant: All addresses in the pool have been generated from their index via the pool addressFromIx .

Internal invariant: The pool satisfies all invariants above.