Move WriteElement[s] to the codec package so that packages other than
clientdb can use it.
For the codec package, we avoid depending on other packages within Pool
so that no circular dependencies develop. This requires us to move some
of the uintXX casting logic in clientdb/codec.go to call sites.
In this commit, we add a new key within the order bucket that stores
just the node tier for a given order. The current code only _expects_ a
node tier to exist for Bid orders, however things have been designed
such that, we can easily add tier options for Ask orders as well.
Along the way we modify the `orderCallback` to include the node tier
information as its read from a distinct bucket. In the future, we'll
likely want to make this into a struct so the function signature doesn't
ever expand.
We add a couple of order specific events which we use to track the
activity around orders. Some events track the timestamps at which we
persist a change to orders, other events track more volatile occurrences
of the match making process.
In the future we might want to have the possibility to add additional
fields to a database object (like orders or accounts) without the need
for a migration. We add the code for that already, even if it's not
being used currently.
Traders are now able to close their accounts, whether or not they have
already expired, to arbitrary outputs or to a wallet output by default.
If an account hasn't expired, then the auctioneer's signature of the
closing transaction is required to successfully close the account.
In this commit, we overhaul the keys used in the multi-sig construction
of an account to prevent script reuse and provide plausible deniability
between account outputs to third parties. This is done by tweaking the
trader's key with two new components:
1. A per-batch key, which is obtained from the auctioneer during account
creation. Every time the account is modified or participates in a
cleared batch within the system, the per-batch key is incremented by the
curve's base point, resulting in a different key used in the account
script.
2. A shared secret derived using Diffie-Hellman between the trader's and
auctioneer's base keys. By using this secret, we provide plausible
deniability to third parties with knowledge of the base keys and
per-batch key.
The resulting tweaked key for the trader is then used as the tweak for
the auctioneer's base key.
This aims to satisfy the account.Store dependency required by the
account.Manager. We now extend our bolt database to store information
about any pending and confirmed accounts we've opened.
