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: 62b9a557fca2aa55803c336ffcceccc50ccf0c3e
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: 2d1d6581eca4508838cd339cc19c72efc42d6ea0 0e24bbf679c95784ed5514a6a1f2fbf99dd97725
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: 325c725fb6205e38142914acb9ed1733d8482d46 89d113e02a83617b4e971c160d47551476dacc71
"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: b768108d9c0b83330572711aef1e569543130d5e
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: eb306664e786ae43d539fde66f0fbe2a3e89d910 9ef2a25603c9ec4e44c4f45c6a5d4e4386ec86d3 27fae3484cdb21b0d24face833b966fce5926be5 901b01d674031f9aca717deeb372bafa160a24af
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: 5400ef6bcb9d243b2b21697775aa6491115420f3
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
1) Chainparams: Explicit CChainParams arg for main:
-AcceptBlock
-AcceptBlockHeader
-ActivateBestChain
-ConnectTip
-InitBlockIndex
-LoadExternalBlockFile
-VerifyDB parametric constructor
2) Also pickup more Params()\. in main.cpp
3) Pass nPruneAfterHeight explicitly to new FindFilesToPrune() in main.cpp
d1c3762 Revert "Revert "Enable policy enforcing GetMedianTimePast as the end point of lock-time constraints"" (Gregory Maxwell)
e4e5334 Restore MedianTimePast for locktime. (Gregory Maxwell)
a6efc01 Bugfix: Omit wallet-related options from -help when wallet is disabled (Luke Dashjr)
5f9260f Bugfix: If genproclimit is omitted to RPC setgenerate, don't change it; also show correct default in getmininginfo (Luke Dashjr)
420a82f Bugfix: Describe dblogsize option correctly (it refers to the wallet database, not memory pool) (Luke Dashjr)
caa3d42 Bugfix: RPC: blockchain: Display correct defaults in help for verifychain method (Luke Dashjr)
Revert "Revert "Add rules--presently disabled--for using GetMedianTimePast as endpoint for lock-time calculations""
This reverts commit 40cd32e835.
After careful analysis it was determined that the change was, in fact, safe and several people were suffering
momentary confusion about locktime semantics.
This reverts commit 9d55050773.
As noted by Luke-Jr, under some conditions this will accept transactions which are invalid by the network
rules. This happens when the current block time is head of the median time past and a transaction's
locktime is in the middle.
This could be addressed by changing the rule to MAX(this_block_time, MTP+offset) but this solution and
the particular offset used deserve some consideration.
