This primarily affects blocks when bitcoin is launched with -reindex, as
that causes the block files to be loaded as CBufferedFile objects one at
a time as the reindex progresses.
Co-Authored-By: Luke Dashjr <luke-jr+git@utopios.org>
Github-Pull: #14485
Rebased-From: 289e88b3133107f8a54184d8316559c7cf8ddb12
On default legacy wallets, the backup filename starts with an "-" due
to the wallet name being empty. This is inconvenient for systems who
treat what follows the initial "-" character as flags.
Github-Pull: #29586
Rebased-From: a951dba3a9
I need to try and patch around Qts buildsystem to keep #21778 moving
along (the issue being that even when you tell Qt to build using
Clang on Linux, it still calls out to GCC, breaking our ability to have
a macOS release build env that doesn't have a GCC toolchain installed,
and thus no ld binary).
Before trying to patch Qt any further, update to the latest LTS
release, and update the current patch set.
Github-Pull: #29732
Rebased-From: 430f319f73
Addnode (manual) peers connected to us via the cjdns network are currently not
detected by CConnman::GetAddedNodeInfo(), i.e. fConnected is always false.
This causes the following issues:
- RPC `getaddednodeinfo` incorrectly shows them as not connected
- CConnman::ThreadOpenAddedConnections() continually retries to connect them
Github-Pull: #30085
Rebased-From: 684da97070
This didn't work for two reasons:
1.) GetSnapshotCoinsDBPath() was used to retrieve the path.
This requires coins_views to exist, but the initialisation only happens later
(in CompleteChainstateInitialization) so the node hits an assert in
CCoinsViewDB& CoinsDB() and crashes.
2.) The snapshot was already activated, so it has the mempool attached.
Therefore, the mempool needs to be transferred back to the ibd
chainstate before deleting the snapshot chainstate.
Github-Pull: #29726
Rebased-From: e57f951805
Without explicitly declaring the move, these UniValues get copied,
causing increased memory usage. Fix this by explicitly moving the
UniValue objects.
Used by `rest_block` and `getblock` RPC.
Github-Pull: #30094
Rebased-From: b77bad309e
Fixes: #809
Previously it was possible through the GUI to enter an IP address:port
into the "Proxy IP" configuration box. After the node was restarted the
errant setting would prevent the node starting back up until manually
removed from settings.json.
Github-Pull: https://github.com/bitcoin-core/gui/pull/813
Rebased-From: 10c5275ba4
The default max file size for LevelDB is 2 MiB, which results in the
LevelDB compaction code generating ~4 disk cache flushes per second when
syncing with the Bitcoin network.
These disk cache flushes are triggered by fdatasync() syscall issued by the
LevelDB compaction code when reaching the max file size.
If the database is on a HDD this flush rate brings the whole system to a
crawl.
It also results in very slow throughput since 2 MiB * 4 flushes per second
is about 8 MiB / second max throughput, while even an old HDD can pull
100 - 200 MiB / second streaming throughput.
Increase the default db file size for LevelDB to 128 MiB instead so the flush
rate drops to about 1 flush / 2 seconds and the system no longer gets so
sluggish.
The db file size value chosen also matches the MAX_BLOCKFILE_SIZE file
size setting already used by the block storage.
As described in #10542 (and numerous other places), message signing in
Bitcoin Core only supports message signing using P2PKH addresses, at
least until a new message-signing standard is agreed upon.
Therefore update the possibly-misleading error message presented to the
user in the GUI to detail more specifically the reason their message
cannot be signed, in the case that a non P2PKH address is entered.
Github-Pull: gui#819
Rebased-From: fb9f150759
The 32 to 64-bit time_t transition causes a build failure in the built-in
zlib about conflicting _TIME_BITS and _FILE_OFFSET_BITS.
Note that zlib doesn't use time_t at all, so it is a false alarm.
Take the following patch from upstream zlib:
a566e156b3.patch
Closes#29980.
Github-Pull: #29985
Rebased-From: 2e266f33b5
