The block 202612 PoW workaround previously applied to any block at
height 202612. Restrict it to the object hashes of the known historical
mainnet, testnet, and stagenet block hashing blobs so new chains do not
inherit the fixed PoW hash, which would prevent sync or mining past that
height if their difficulty is higher.
Reported-by: DataHoarder
Co-authored-by: jeffro256 <jeffro256@tutanota.com>
`libringct` was linking against `libcryptonote_basic` for a single, one-line convenience function: `cryptonote::get_blob_hash`.
Since `cryptonote_basic.h` includes `rctTypes.h`, this one function effectively made an explicit circular dependency between
the two libraries. `cryptonote_format_utils.cpp` was including header `rctSigs.h` from `libringct`, when only `rctOps.h` from
`libringct_basic` needed to be included. `libcryptonote_basic` wasn't explictly linking against `libringct_basic` nor
`libringct` like it should have. And `libblockchain_db` wasn't linking against `libcryptonote_basic` like it should have. We
can also downgrade `libblockchain_db`'s dependency on `libringct` to `libringct_basic`.
1. Use `std::is_standard_layout` and `std::is_trivially_copyable` instead of `std::is_pod` for KV byte-wise serialization, which fixes compile issue for Boost UUIDs
2. Use `std::has_unique_object_representations` instead of `alignof(T) == 1` for epee byte spans and epee hex functions
3. Removed reimplementation of `std::hash` for `boost::uuids::uuid
4. Removed `<<` operator overload for `crypto::secret_key`
5. Removed instances in code where private view key was dumped to the log in plaintext
- When background syncing, the wallet wipes the spend key
from memory and processes all new transactions. The wallet saves
all receives, spends, and "plausible" spends of receives the
wallet does not know key images for.
- When background sync disabled, the wallet processes all
background synced txs and then clears the background sync cache.
- Adding "plausible" spends to the background sync cache ensures
that the wallet does not need to query the daemon to see if any
received outputs were spent while background sync was enabled.
This would harm privacy especially for users of 3rd party daemons.
- To enable the feature in the CLI wallet, the user can set
background-sync to reuse-wallet-password or
custom-background-password and the wallet automatically syncs in
the background when the wallet locks, then processes all
background synced txs when the wallet is unlocked.
- The custom-background-password option enables the user to
open a distinct background wallet that only has a view key saved
and can be opened/closed/synced separately from the main wallet.
When the main wallet opens, it processes the background wallet's
cache.
- To enable the feature in the RPC wallet, there is a new
`/setup_background_sync` endpoint.
- HW, multsig and view-only wallets cannot background sync.
Related to https://github.com/monero-project/research-lab/issues/78
Added a relay rule that enforces the `unlock_time` field is equal to 0 for non-coinbase transactions.
UIs changed:
* Removed `locked_transfer` and `locked_sweep_all` commands from `monero-wallet-cli`
APIs changed:
* Removed `unlock_time` parameters from `wallet2` transfer methods
* Wallet RPC transfer endpoints send error codes when requested unlock time is not 0
* Removed `unlock_time` parameters from `construct_tx*` cryptonote core functions
tobtoht