Always leave a reasonable buffer of 50MB for usage from newly connected block (once over 50%) and increase the high water mark buffer to 200MB.
Github-Pull: #10133
Rebased-From: 1b55e07b7a
Since we are more accurately measuring pcoinsTip peak usage at twice the current in dynamic usage, it makes sense to double the default (this will lead to the same effective usage and peak usage as previously).
We should also double the buffer used to avoid flushing if above 90% but still sufficient space remaining.
Github-Pull: #10133
Rebased-From: 5b95a190e8
There is no point in even hashing a submitted block which doesn't have
a coinbase transaction.
This also results in more useful error reporting on corrupted input.
Thanks to rawodb for the bug report.
Github-Pull: #10146
Rebased-From: 4f15ea102d
a296c60 Update benchmarking with package statistics (Suhas Daftuar)
10028fb Add benchmarking for CreateNewBlock (Suhas Daftuar)
b5c3440 Mining: return early when block is almost full (Suhas Daftuar)
Tree-SHA512: 7c39d03a778abe00412743958981a1a55d22fc1843c9a3aef7a56506622e6f5d6b8962c586a339b6031e1ee4815d6981351cf527e8fbe5b265824c81d6c7199d
glibc-specific: On 32-bit systems set the number of arenas to 1. By
default, since glibc 2.10, the C library will create up to two heap
arenas per core. This is known to cause excessive virtual address space
usage in our usage. Work around it by setting the maximum number of
arenas to 1.
Github-Pull: #10120
Rebased-From: 625488ace5
The number of arguments is not checked MutateTxAddOutAddr(..), meaning
that
> ./bitcoin-tx -create outaddr=
accessed the vStrInputParts vector beyond its bounds.
This also includes work by jnewbery to check the inputs for
MutateTxAddPubKey()
Github-Pull: #10130
Rebased-From: eb66bf9bdd
Ensures that there is an item on the rpcconsole stack before adding something to the current stack so that a segmentation fault does not occur.
Github-Pull: #10060
Rebased-From: 4df76e270c
2cd2cd5 Test transaction selection when gbt called without segwit support (Suhas Daftuar)
569596c Don't require segwit in getblocktemplate for segwit signalling or mining (Suhas Daftuar)
Tree-SHA512: bf2672287713e5adc7e851791207e17490679f941d0b9ed38467ffede3aa3000d229151b8ae54323fc8037e0a8569b2fd910ec19f034fb85d9142289648793c3
4e2502b Add missing braces in semaphore posts in net (Matt Corallo)
d2548a4 Fix shutdown hang with >= 8 -addnodes set (Matt Corallo)
Tree-SHA512: 0b157793a2c7fabbc2ed24f974d206fc01c816189d6b6aa5a61bab562a0034f72b643a19b1e7920061e479fb27eddd4abf1c40e772a9573346b221a08e7e5ed9
We previously would block waiting for a CSemaphoreGrant in
ThreadOpenAddedConnections, when we did not need to. This would
block as the posts in CConnman shutdown were both to the wrong
semaphore and in the wrong location.
Github-Pull: #9953
Rebased-From: e007b243c4
Segwit's version bit will be signalled for all invocations of CreateNewBlock,
and not specifying segwit only will cause CreateNewBlock to skip transactions
with witness from being selected.
Github-Pull: #9955
Rebased-From: abe7b3d3ab
589cd63 Allow any subkey in verify-commits (Matt Corallo)
Tree-SHA512: e3175273c648ed2d990ac931efae5e4bf3bd5ddce7b591f5e64a6831f3c029b252bc5d241dd8d3874467747c3ded87aa1fa334ff53d940cde32c22e584a2c4d0
ld64 is threaded, and uses a worker for each CPU to parse input files. But
there's a bug in the parser causing dependencies to be calculated differently
based on which files have already been parsed.
As a result, builders with more CPUs are more likely to see non-determinism.
This looks to have been fixed in a newer version of ld64, so just disable
threading for now. There's no noticible slowdown.
Github-Pull: #9891
Rebased-From: 9e4d842afc
Bug was a missing ++i line in a new range for loop added in commit e2e2f4c
"Return errors from importmulti if complete rescans are not successful"
Github-Pull: #9829
Rebased-From: 306bd72157
50ae5c7 Document increase in memory usage due to mempool/dbcache sharing (Matt Corallo)
Tree-SHA512: e52a310a5ac1f94b30f367a7bf514b2cf0724530102953eef7f7c7e00a067db568b5e1b51129dfdb1a237e016c7a8b01cc6da8c06a24ab5b970c43d045adb204
Alex Morcos