Fix casting error in GetFilteredNotes
Use int for minDepth like upstream instead of size_t which can lead to casting problems if a wallet tx has a depth of -1.
Also don't use FindMyNotes as mapNoteData has already been set on wallet tx.
@str4d As dicussed. This should be merged before other PRs related to wallet.
People seem to agree that dnsseed.* is a more intuitive address.
The original address was committed to beta1 as a result of a misunderstanding.
The DNS seeder service will be updated to coincide with at beta2 release.
Upstream patch: Fix and improve relay from whitelisted peers
https://github.com/bitcoin/bitcoin/pull/7106
a9f3d3db5c0c8d1697998ed9b3e192ddbf9a31f4
An extra commit modifies the log message string, otherwise there are are a number of commits that need be to backported to add methods e.g. GetDebugMessage. These commits modify the interface in consensus/validation.h so there are conflicts to be resolved. e.g.
9003c7c
a9ac95c
5f12263
fbf44e6
This makes sure that retransmits by a whitelisted peer also actually
result in a retransmit.
Further, this changes the logic to never relay in case we would assign
a DoS score, as we expect to get DoS banned ourselves as a result.
The setAskFor duplicate elimination was too eager and removed entries
when we still had no getdata response, allowing the peer to keep
INVing and not responding.
mapAlreadyAskedFor does not keep track of which peer has a request queued for a
particular tx. As a result, a peer can blind a node to a tx indefinitely by
sending many invs for the same tx, and then never replying to getdatas for it.
Each inv received will be placed 2 minutes farther back in mapAlreadyAskedFor,
so a short message containing 10 invs would render that tx unavailable for 20
minutes.
This is fixed by disallowing a peer from having more than one entry for a
particular inv in mapAlreadyAskedFor at a time.
