"do not meet pay the minimum relay fee" ? I can understand English language quite well, but that I do not understand. So, if it's not an semantic nonsense, I would suggest to write it in more simple English.
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.
