| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This adds a -regetest-only undocumented (for regression testing only)
command-line option -blockversion=N to set block.nVersion.
Adds to the "has the rest of the network upgraded to a
block.nVersion we don't understand" code so it calls
-alertnotify when 51 of the last 100 blocks are up-version.
But it only alerts once, not with every subsequent new, upversion
block.
And adds a forknotify.py regression test to make sure it works.
Tested using forknotify.py:
Before adding CAlert::Notify, get:
Assertion failed: -alertnotify did not warn of up-version blocks
Before adding code to only alert once:
Assertion failed: -alertnotify excessive warning of up-version blocks
After final code in this pull:
Tests successful
|
|
The entire debug log would be huge, and could cause issues for automated tools
like travis. Printing 200 lines is an initial guess at a reasonable number,
more may be required.
|
|
Use the more portable $$ rather than $BASHPID
|
|
|
|
This adds a -whitelist option to specify subnet ranges from which peers
that connect are whitelisted. In addition, there is a -whitebind option
which works like -bind, except peers connecting to it are also
whitelisted (allowing a separate listen port for trusted connections).
Being whitelisted has two effects (for now):
* They are immune to DoS disconnection/banning.
* Transactions they broadcast (which are valid) are always relayed,
even if they were already in the mempool. This means that a node
can function as a gateway for a local network, and that rebroadcasts
from the local network will work as expected.
Whitelisting replaces the magic exemption localhost had for DoS
disconnection (local addresses are still never banned, though), which
implied hidden service connects (from a localhost Tor node) were
incorrectly immune to DoS disconnection as well. This old
behaviour is removed for that reason, but can be restored using
-whitelist=127.0.0.1 or -whitelist=::1 can be specified. -whitebind
is safer to use in case non-trusted localhost connections are expected
(like hidden services).
|
|
|
|
This should show how to run a python-based regression test
successfully in the pull-tester environment.
|
|
- Add license headers to source files (years based on commit dates)
in `src/test` as well as `qa`
- Add `README.md` to `src/test/data` specifying MIT license
Fixes #3848
|
|
qa/rpc-tests/wallet.sh runs a three-node -regtest network,
generates a fresh blockchain, and then exercises basic wallet
sending/receiving functionality using command-line RPC.
|
|
Also update pull-tester's error message.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Use the latest version, with limited memory usage, and path to
on-disk db (try mouting qa/tmp on a tmpfs)\
* enable -debug=net
* re-enable BitcoindComparisonTool in pull-tester
|
|
Not working on the pull-tester machine, 'make cov' hangs there.
|
|
Re-organize the pull-tester scripts a bit.
And disables running the blockchain tester, it is not working properly
on the pull-tester machine for reasons I cannot explain (fails to start).
|
|
|
|
|
|
|
|
|
|
|
