- Add core_io function DecodeAuxPow implementing a save means to
parse a hex encoded auxpow string into a CAuxPow instance
- Parse both the hash and the hex in the receiving methods, and
return meaningful errors when they fail.
1. Providing a malformed hash now returns RPC_INVALID_PARAMETER
(-8) instead of the generic -1
2. Providing a malformed auxpow hex now returns
RPC_DESERIALIZATION_ERROR (-22) instead of the generic -1
- Implements getmocktime instead of time.sleep to prevent races
- Enforce success of all mocktime operations
- Do not increment mocktime with 0 seconds
- Use fresh incoming peers for each test
- Explicitly do test teardown
- Remove TXID_RELAY_DELAY as this no longer exists in the dogecoind
implementation
- Add the inflight throttling test to replace the removed inflight
limit test
- Add an expiry fallback test
Maintaining up to 100000 INVs per peer is excessive. A Dogecoin
Core node will never send more than 7 invs per second.
Backported from: de11b0a4
Original Author: Pieter Wuille <pieter@wuille.net>
The major changes are:
* Announcements from outbound (and whitelisted) peers are now
always preferred over those from inbound peers. This used to be
the case for the first request (by delaying the first request
from inbound peers), and a bias after. The 2s delay for requests
from inbound peers still exists, but after that, if viable
outbound peers remain for any given transaction, they will
always be tried first.
* No more hard cap of 100 in flight transactions per peer, as
there is less need for it (memory usage is linear in the number
of announcements, but independent from the number in flight,
and CPU usage isn't affected by it). Furthermore, if only one
peer announces a transaction, and it has over 100 in flight and
requestable already, we still want to request it from them. The
cap is replaced with an additional 2s delay (possibly combined
with the existing 2s delays for inbound connections).
Backported from: 242d1647
173a1d2d
Original Author: Pieter Wuille <pieter@wuille.net>
Conflicts:
- replaced GenTx with uint256 because no segwit
- removed additional 2s penalty for non-segwit peers
- used int64_t instead of std::chrono::microseconds per utiltime
- implemented TxRequest as g_txrequest instead of as a member of
PeerManager, which we don't have
- removed the Dogecoin-specific strict max inflight test
- make exceptions for whitelisted nodes as there is no fine-
grained permission system
1. Allow more time for notifications to be delivered under load
2. Assure that in a non-hostile reorg the tracked transaction
isn't mined prematurely by mining 80-bytes blocks
3. Test all 4 messages for the doublespend scenario at once to
not error out when the conflict races the new transaction
This allows us to more strictly test the reorg behavior while
reducing race issues
adds:
- maxoutamount - highest value output
- minoutamount - lowest value output
- dustouts - number of outputs under our soft dust limit
Each of these ignores OP_RETURN and coinbase outputs
adds a line when no copyright for Dogecoin Core Developers exists
but the file has been edited by us, to the last year found in git
log, or extends the year range on an existing line when a file
has been modified since the year previously listed.
Excludes subtrees.
Tests 5 scenarios:
1. Notifying for a new transaction into mempool
2. Notifying again for a mined known transaction
3. Notifying for a reversal and subsequent remine
4. Notifying for a reversal and subsequent doublespend
5. Notifying for a transaction that wasn't in mempool first
This logs either positional arguments or named arguments if no
positional arguments exist when using --tracerpc to allow deep
examination of calls that use named arguments.
The __call__ function rejects any calls made using both positional
and named arguments, therefore we can print either in this
construction.
I have made an attempt to update fee rate in p2p-feefilter.py to recommended minimum transaction fee of 0.01 DOGE/kb to reflect fee rate changes made in 1.14.4 release , it is linked with issue #3201
This adds two helper functions. One function gets a height parameter from the
incoming RPC request. The other performs the scanning. We can use both
functions for reducing code in other RPC calls that can/should take height
parameters and perform rescanning.
This allows users to avoid rescanning the entire chain when importing a
new private key, if they provide the height of the block from which to
start. Note that any transactions to or from the corresponding wallet
will only be indexed if they occur at or after the given height.
The height argument is `height`, consistent with the `height` argument to
`rescan`.
Tests 5 scenarios for transaction download scheduling:
1. Whether eventually, after a series of timeouts, all our peers
that announced a transaction are sent a getdata request
2. Whether outbound peers are prioritized over inbound peers when
a getdata request takes longer than optimal
3. That we honor the maximum in-flight capacity, that this is on
a per-peer basis and that it resets itself after timeout
4. That when we have an inflight getdata request when a peer
disconnects, we recover after the initial 30 second timeout
and fetch the transaction from another peer
5. That we recover after a peer sends us a notfound message for
a tx we had an inflight getdata request for.
the p2p-policy test has a number of issues because it is a real-
time relay test that can at the moment not be mocked and it is
insufficiently hardened against signature length variation.
This makes 2 changes to the test to make it more reliable:
1. Increase the maximum wait time for transactions to be relayed to
2 minutes instead of 30 seconds. This gives us more certainty
that the PoissonNextSend() function doesn't schedule outside of
our window.
2. Whenever we sign a transaction with an unexpected signature
length, retry constructing the transaction (with a different
input). Fees are changed to be 100% exact.
Note that this makes the test potentially take a longer time to
complete, so we move it up in the list of the test runner, to
be triggered early.
Each node keeps a registry of manually added nodes (through the
addnode parameter, rpc call or UI) but there are currently no
limits imposed on that usage, which is a bit sloppy and can lead
to situations where memory is being used for storing addresses
that are never connected to, because the maximum number of
connections used for addnode entries is hardcoded as 8. This
could prevent smaller systems that host nodes (like those
running on an ARM SoC) to optimally use the available memory.
This enhancement limits the addnode functionality as follows:
1. Whenever over 799 nodes are added to the registry, require
the user to remove an entry before a new one can be added
2. Disallow very large addresses (more than 256 characters).
This limit provides for at least 4 levels of subdomains as
specified under RFC1035.
See https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1
Verification levels must be between 0 and 4 inclusive, and block heights should
always be positive. While code in the scan process handles the latter case with
a default value, it's better to verify and reject invalid input where it first
enters the system.
