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.
-update install-deps.sh so it will clean up after itself and can be invoked from root directory.
-add python3-pip and python3-setuptools to ci matrix jobs that run qa and qa/README.md which are needed in order to install ltc-scrypt.
-update archive source to dogecoin/ltc-scrypt:v1.0.1.
-update qa/README.md to include sudo prior to apt-get install directive and add instructions to invoke install-deps.sh script from root directory.
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.
This adds more defensiveness around dumping or backing up wallets, so
that the directory and filepaths are always available (even if they were
on transient storage that was removed), and that they never overwrite
other files.
Tests that depend on enable_mocktime() because they use the cached
chain are testing things that need actual time. Because we're
mocking time more often when we are processing messages, these
tests fail (because to the node, no time expires)
This rewrites these tests to no longer use the cached chain.
Tests affected:
- listtransactions.py
- receivedby.py
Adds the time field to addr messages from protocol version 31402,
but serialize/deserialize without it for version messages. This
allows us to test p2p addr messages.
See src/version.h and c891967b
The algorithm here is important and took some time to get right. Instead
of comparing whether the current number of connected nodes minus the
number of unevictable nodes is greater than the number of max
connections, check that:
* there are any evictable nodes (connected nodes minus unevictable
nodes)
* there are more nodes connected than requested (connected nodes minus
max connections)
While we could wait for nodes to disconnect organically, it's more
important to run the eviction logic frequently enough that we can tell
when it will have an effect.
Whitelisted connections and protected inbound connections are
unevictable, and max connections should account for inbound connections.
Because the evictor will never evict protected inbound connections, the
maximum connection count should always be at least as large as the
protected connection count.
Note that the tests for this use a delay and test that the delay has not
expired. This helps improve determinism in the testing. Otherwise, a
strict test for a fixed number of disconnections is susceptible to
things like CPU jitter, especially when running through CI.
Patrick ran this test for 1000 runs on busy CPUs and saw no failures.
This uses the constant in src/net.h for the minimum allowed number of
connections.
The limit of new max connections is silently capped to the number of
available file descriptors. This value is not exposed in the UI or
RPC messages so as not to leak interesting or important system details.
The floor of maximum connections is set to the number of connections
required for this node to operate.
This makes the best attempt to reduce the number of connections by
reusing the eviction logic. This reuses the core of that algorithm at
the expense of deterministic behavior. In other words, starting with a
max connections value of 125 and then changing the max connections to 3
does not mean that this will immediately evict 122 connections.
Eventually the number of connections will reduce to the limit.
While the body of the condition will add latency to network processing,
the integer comparison between max connections and size of the
connections vector should be quick in most cases.
Note the extraction of connection disconnect/delete helpers so as to
reuse the same logic in multiple places. While this may not be strictly
necessary for the algorithm, it reduces the possibility that this entire
loop will get stuck doing busy work when trying to evict connections to
get under the maximum threshold.
Current REST API always returns empty UTXO when invoked without
`/checkmempool/` URL part.
Cherry-picked from: bitcoin/bitcoin 9cb9af8c
Conflicts: limited scope to only the QA test, as rest.cpp
implementation is incompatible with Dogecoin 1.14
Adds a custom mininode implementation to test connects and
disconnects based on the number of allowed locators
Inspired by: fa85c985
Original Author: MarcoFalke <falke.marco@gmail.com>
Cherry-picked from: fa48baf23
Conflicts:
- Missing chain().lock(), moved assignment until after locking
cs_main.
- Different structure and version of test framework required:
- Different block heights
- Different way of documenting test steps
- Removal of wallet check, our tests don't run without a wallet
Allows easy integration with mining software that expects either
a "_target" (Namecoin) or a "target" (Dogecoin) field when
creating auxpow blocks using the -rpcnamecoinapi startup arg.
This saves pools effort in integrating the API they need whenever
a new Dogecoin Core release comes out.
- RPC caching source cherry-picked from: btccom@f4b613b2
- Adds addl test scenarios to createauxblock.py tests
Allows pool operators to run multiple sub-pools with different
target addresses from a single dogecoind instance. Without this
enhancement, subsequent calls to createauxblock with differing
addresses ignore the address given and instead just return the
block containing the address that initially triggered generation
of the cached block. This can quickly lead to unpredictable
results as race scenarios between sub-pools come into play.
Note that, like with getauxblock, the cache only resets on aux
block creation, not submission, so submitauxblock will accept
multiple submissions at the same height until createauxblock is
called, resulting in chaintip forks.
Co-Authored-By: leezhen <jasper.li@bitmain.com>
The pruning test was outdated in that it was written to test BTC's 288
MIN_BLOCKS_TO_KEEP and 550 MiB MIN_DISK_SPACE_FOR_BLOCK_FILES.
To fix we recalculate arithmetic to accomodate our corresponding 1440
MIN_BLOCKS_TO_KEEP and 2200 MiB MIN_DISK_SPACE_FOR_BLOCK_FILES which
is representative as minimum val we can pass to configure a node to
automatically prune: -prune=2200.
Copied mine_large_blocks from 03d6d238 to speed up the test.
Separated the manual testing from the main test because the values
depend on Bitcoin configuration.
Test both hard and soft dust limits for a range of configurations,
making sure that the dust limit parameters work as expected.
Currently implements commonly seen client configurations:
- a 1.10.0-like node that has only a 1 DOGE soft dust limit
- a 1.14.2-like node that has only a 1 DOGE hard dust limit
- a 1.14.5-like node that has a 0.01 soft and 0.001 hard dust limit
- a node that accepts everything standard
Other changes:
- renamed the test to better reflect the test subject
- made sure that all nodes reject non-standard transactions
Changes the dust policy to require transactions to add the dust
limit itself rather than the relay or wallet fee to the fees paid
when creating dust outputs.
This both disincentivizes dust outputs the same as before when dust
and minumum fee were equal and greatly simplifies the rule, as it
no longer requires 2 variables to calculate dust, but just one:
"If an output is under x, add x to the fee."
As of writing, 97% of the relay network (for me: 2251 of 2328
peers) enforces a 1 DOGE hard dust limit making attempts to send
smaller outputs extremely unlikely to make it through to miners.
This setting is a temporary measure until a significant portion of
the network accepts lower dust thresholds. The threshold can be
changed by wallet users using the -discardthreshold parameter.
Creates a wallet-specific, configurable dust limit that enables
gradual implementation of the dust limit. Each transaction created
with the wallet will adhere to this threshold rather than the dust
limits used for relay, so that the wallet stays usable while the
network changes (lowers) its dust limits.
This change only implements the parameter but does not change its
default value.
