The funding feerate field was previoulsy unused, so we rename it to
"max batch fee rate" in order to use it to communicate to the server the
maximum fee rate we are willing to pay to be included in a batch.
We also increase the default value to 500 sat/vbyte.
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.
In this commit, we change the key stored within the internal order kit
into a raw pubkey array. Along the way we fix a bug in the verifier
tests due to using a map with pointer keys rather than the actual value
itself.
This commit aims to address a current gap within the system where trader
account states can become desynchronized if they participated in a batch
and they never received a Finalize message from the auctioneer.
From now on, if an account spend arrives while a trader has a pending
batch, then we assume they weren't able to receive its Finalize message,
and use the spend as an indication that the batch has been finalized.
This works because if a trader signs for a batch and disconnects, the
batch should have already been persisted, and if the batch was actually
finalized (i.e., broadcast without any changes), then the account should
have been spent.
If trader A provides a signature for a batch, disconnects, and trader B,
who is also in the auction, bails, then the auctioneer will re-attempt
matchmaking. If trader A hasn't reconnected by and a successful batch is
made without them, then the updates would need to be rolled back.
Previously, since we would overwrite the main account and order state,
we'd lack information in order to do so. By staging the update under a
distinct bucket, we can now do so properly by simply removing the state
within it.
This commits serves as preparatory work for committing a pending batch
before providing signatures to the auctioneer. This is achieved by first
storing the batch as pending upon receiving a new batch and marking it
as complete upon receiving a finalize message.
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.
In this commit, we add a persistent store backed by bolt for the client
portion of CLM in which we'll store critical information required for
its proper operation.
