This is a belt-and-suspenders fix to make sure CreateNewBlock() or external mining software can never produce a block that violates the MAX_BLOCK_SIGHASH rule.
It does this by rejecting transactions that do too much signature hashing -- they are not added to the memory pool, and so will not be considered for inclusion in new blocks.
How the code works: every transaction uses up some fraction of the MAX_BLOCK_SIZE limit and the MAX_BLOCK_SIGHASH limit. If a transaction uses up a larger fraction of the SIGHASH limit than the SIZE limit, it is rejected. That ensures that no matter which transactions are selected for the block, the SIZE limit will be hit before the SIGHASH limit.
This is a much simpler solution than modifying CreateNewBlock or external transaction selection software to keep track of the SIZE limit, the SIGOPS limit, AND the new SIGHASH limit.
This is belt-and-suspenders because, in practice, the 100,000-byte IsStandard size limit prevents the block SIGHASH limit from being hit.
The IsStandard code related to the old SIGOPS limit is left unchanged.
Conflicts:
src/main.cpp
Adds a ValidationCostTracker class that is passed to
CheckInputs() / CScriptCheck() to keep track of the exact number
of signature operations required to validate a block, and the
exact number of bytes hashed to compute signature hashes.
Also extends CHashWriter to keep track of number of bytes hashed.
Signature operations per block are limited to MAX_BLOCK_SIGOPS
(unchanged at 20,000)
Bytes hashed to compute signatures is limited to MAX_BLOCK_SIGHASH
(1.3 GB in this commit).
Conflicts:
src/main.cpp
src/miner.cpp
src/script/interpreter.h
Activation code for a two megabyte block size increase.
Activation condition:
750 of 1000 blocks with version bit 0x10000000 set, then a four-week
(28-day) grace period, after which miners may create 2MB
blocks.
Conflicts:
qa/pull-tester/rpc-tests.sh
qa/rpc-tests/bipdersig-p2p.py
src/chainparams.cpp
src/main.cpp
src/miner.cpp
Additionall; Fix unit test.
Instead of relying on default, specify block size.
b460004 release-notes: Minor corrections and clarifications re Priority (Luke Dashjr)
3450f4c release-notes: Significantly rewrite priority transactions section (Gregory Maxwell)
d0dbb6d release-notes: Remove suggestion to use 0.11 (Luke Dashjr)
73a0375 release-notes: Mention possibility of priority removal in 0.13, uncertainty of priority calculation being changed back, and request community input (Luke Dashjr)
4b8d2bc release-notes: Cover priority changes correctly, removing mentions of possible futures (Luke Dashjr)
If number of conflict confirms cannot be determined, this means
that the block is still unknown or not yet part of the main chain,
for example during a reindex. Do nothing in that case,
instead of crash with an assertion.
Fixes#7234.
Github-Pull: #7491
Rebased-From: 40e7b61835
A WWW-Authenticate header must be present in the 401
response to make clients know that they can authenticate,
and how.
WWW-Authenticate: Basic realm="jsonrpc"
Fixes#7462.
Github-Pull: #7472
Rebased-From: 7c06fbd8f5
- 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.
This corrects a bug the case of tying group size where the code may
fail to select the group with the newest member. Since newest time
is the final selection criteria, failing to break ties on it
on the step before can undermine the final selection.
Tied netgroups are very common.
With automatic tor HS support in place we should probably not be providing
absolute protection for local peers, since HS inbound could be used to
attack pretty easily. Instead, this counts on the latency metric inside
AttemptToEvictConnection to privilege actually local peers.
8c5f903 doc: In release notes, reduce length of pruning section (xor-freenet)
15c0263 doc: Minor spelling fix (xor-freenet)
54d3907 doc: Fix wrong claims about blockchain reorganization with pruning (xor-freenet)
a683d20 doc: Minor sentence length / capitalization fixes (xor-freenet)
58e3abf doc: In release notes, increase estimate of disk usage with pruning (xor-freenet)
be4b474 doc: In release notes, do not claim that pruning is leeching (xor-freenet)
46d7eb6 doc: Fix minimal disk usage with pruning enabled (xor-freenet)
fe074cc doc: Explain effects of -prune=<n> parameter in release notes (xor-freenet)
