When no `-rpcpassword` is specified, use a special 'cookie' file for
authentication. This file is generated with random content when the
daemon starts, and deleted when it exits. Read access to this file
controls who can access through RPC. By default this file is stored in
the data directory but it be overriden with `-rpccookiefile`.
This is similar to Tor CookieAuthentication: see
https://www.torproject.org/docs/tor-manual.html.en
Alternative to #6258. Like that pull, this allows running bitcoind
without any manual configuration. However, daemons should ideally never write to
their configuration files, so I prefer this solution.
CreateJoinSplit: add start_profiling() call
This solves the problem of profiling output from the CreteJoinSplit benchmarking binary displaying nonsensical large time values.
after a successful sign and send, meaning that the logged hash fragment
would be different from the txid logged by "AddToWallet". This issue
occured when sending from transparent addresses, as utxo inputs must be
signed. It did not occur when sending from shielded addresses.
Only increment new notes on reindex
Addresses another issue in #1904.
When an existing one of our notes was found again, its cache was reset and it was re-witnessed. This would cause encountered notes to get out-of-sync with the otherwise-ignored newer notes, which could be a problem if the wallet data happens to be written out during a reindex.
Additional well-formedness check for G2 elements
libsnark currently checks that G<sub>1</sub> and G<sub>2</sub> elements are well-formed by ensuring that they satisfy their respective curve equations, and although this is enough for G<sub>1</sub> (which is instantiated as an order r curve E/F<sub>p</sub>: y^2 = x^3 + b), G<sub>2</sub> is the order r *subgroup* of the composite order r(2q-r) curve E'/Fp<sup>2</sup>: y^2 = x^3 + b/e constructed via a sextic twisting isomorphism. This means we need to ensure these points are order r as well.
None of the proofs on the Zcash blockchain violate this check, and it may not even be possible for them to violate this check (bilinearity is not preserved). Let's be cautious and do it anyway.
Write witness caches when writing the best block
For steady-state operation, this reduces the average time between wallet disk
writes from once per block to once per hour.
On -rescan, witness caches are only written out at the end along with the best
block, increasing speed while ensuring that on-disk state is kept consistent.
Witness caches are now never recreated during a -reindex, on the assumption that
the blocks themselves are not changing (the chain is just being reconstructed),
and so the witnesses will remain valid.
Part of #1749.