This is done in preparation for future work in which we'll allow custom
inputs and outputs to be provided when crafting the spending transaction
of an account.
Some of the test cases relied on a map's keys always being in the
order they were defined, which is not guaranteed by the runtime.
A data race is also fixed by creating a new instance of the verifier
for each run.
In this commit, we fix a few lingering errors in witness size
estimation. Both the witness paths were missing a single byte that
signals the number of witness elements. We also convert the OP_DATAs in
the witness script to a varint length, as that more accurately reflects
the way the field is interpreted, as we provide the witness stack as is,
rather than pushing elements onto the stack as if it were a sigScript.
Finally, we add a missing byte for the size of the witness script
itself.
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.
Otherwise, it's possible for an expiry request to be handled before the
first block notification that sets our best height is received, causing
us to not fulfill the request if the corresponding expiry had already
been reached.
Otherwise, we can risk transitioning an account from another state,
e.g., StateExpired back to StateOpen if the account confirms at the same
height it expires.
The new construction saves about 35 bytes over the existing one. The
reduction in size comes from only encoding each public key (the trader's
and auctioneer's) once and not using the extra opcodes for
OP_CHECKMULTISIG.
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.
