There was a previous assumption that blockindex would be quite small. With addressindex
and spentindex enabled the blockindex is much larger and the amount of cache allocated for
it should also increase. Furthermore, enabling compression should decrease the amount of
disk space required and less data to write/read. The default leveldb max_open_files is set to
1000, for the blockindex the default is set to 1000 with compression. The 64 value that is
current is kept for the utxo database and does not enable compression. Two additional options
are added here to be able to configure the values for leveldb and the block index:
- `-dbmaxopenfiles` A number of files for leveldb to keep open
- `-dbcompression` Boolean 0 or 1 to enable snappy leveldb compression
There was a bug where the spending address index could have the same key
as the receiving address index if the input and output indexes matched. This lead
to the output always overwriting the input index leading to incorrect balances
with missing spent amounts. This patch separates the two so that they have unique
keys so balances will be correctly calculated.
Now that #7804 fixed the timeout handling, reduce the block timeout from
20 minutes to 10 minutes. 20 minutes is overkill.
Conflicts:
src/main.h
Github-Pull: #7832
Rebased-From: 62b9a557fc
Currently, we're keeping a timeout for each requested block, starting
from when it is requested, with a correction factor for the number of
blocks in the queue.
That's unnecessarily complicated and inaccurate.
As peers process block requests in order, we can make the timeout for each
block start counting only when all previous ones have been received, and
have a correction based on the number of peers, rather than the total number
of blocks.
Conflicts:
src/main.cpp
src/main.h
Self check after the last peer is removed
Github-Pull: #7804
Rebased-From: 2d1d6581ec0e24bbf679
SequenceLocks functions are used to evaluate sequence lock times or heights per BIP 68.
The majority of this code is copied from maaku in #6312
Further credit: btcdrak, sipa, NicolasDorier
- Add whitelistforcerelay to control forced relaying.
Also renames whitelistalwaysrelay.
Nodes relay all transactions from whitelisted peers, this
gets in the way of some useful reasons for whitelisting
peers-- for example, bypassing bandwidth limitations.
The purpose of this forced relaying is for specialized gateway
applications where a node is being used as a P2P connection
filter and multiplexer, but where you don't want it getting
in the way of (re-)broadcast.
This change makes it configurable with whitelistforcerelay.
- Blacklist -whitelistalwaysrelay; replaced by -whitelistrelay.
Github-Pull: #7439
Rebased-From: 325c725fb689d113e02a
"permit" is currently used to configure transaction filtering, whereas replacement is more to do with the memory pool state than the transaction itself.
Add a configuration option `-permitrbf` to set transaction replacement policy
for the mempool.
Enabling it will enable (opt-in) RBF, disabling it will refuse all
conflicting transactions.
Conflicts:
src/init.cpp
src/main.cpp
src/main.h
Github-Pull: #7386
Rebased-From: b768108d9c
1) Fix mempool limiting for PrioritiseTransaction
Redo the feerate index to be based on mining score, rather than fee.
Update mempool_packages.py to test prioritisetransaction's effect on
package scores.
2) Update replace-by-fee logic to use fee deltas
3) Use fee deltas for determining mempool acceptance
4) Remove GetMinRelayFee
One test in AcceptToMemoryPool was to compare a transaction's fee
agains the value returned by GetMinRelayFee. This value was zero for
all small transactions. For larger transactions (between
DEFAULT_BLOCK_PRIORITY_SIZE and MAX_STANDARD_TX_SIZE), this function
was preventing low fee transactions from ever being accepted.
With this function removed, we will now allow transactions in that range
with fees (including modifications via PrioritiseTransaction) below
the minRelayTxFee, provided that they have sufficient priority.
Github-Pull: #7062
Rebased-From: eb306664e79ef2a2560327fae3484c901b01d674
We used to have a trickle node, a node which was chosen in each iteration of
the send loop that was privileged and allowed to send out queued up non-time
critical messages. Since the removal of the fixed sleeps in the network code,
this resulted in fast and attackable treatment of such broadcasts.
This pull request changes the 3 remaining trickle use cases by random delays:
* Local address broadcast (while also removing the the wiping of the seen filter)
* Address relay
* Inv relay (for transactions; blocks are always relayed immediately)
The code is based on older commits by Patrick Strateman.
Github-Pull: #7125
Rebased-From: 5400ef6bcb
But keep translating them in the GUI.
This - necessarily - requires duplication of a few messages.
Alternative take on #7134, that keeps the translations from being wiped.
Also document GetWarnings() input argument.
Fixes#5895.
This replaces using inv messages to announce new blocks, when a peer requests
(via the new "sendheaders" message) that blocks be announced with headers
instead of inv's.
Since headers-first was introduced, peers send getheaders messages in response
to an inv, which requires generating a block locator that is large compared to
the size of the header being requested, and requires an extra round-trip before
a reorg can be relayed. Save time by tracking headers that a peer is likely to
know about, and send a headers chain that would connect to a peer's known
headers, unless the chain would be too big, in which case we revert to sending
an inv instead.
Based off of @sipa's commit to announce all blocks in a reorg via inv,
which has been squashed into this commit.
Rebased-by: Pieter Wuille
