Rebased by @laanwj:
- update for RPC methods added since 84d13ee: setmocktime,
invalidateblock, reconsiderblock. Only the first, setmocktime, required a change,
the other two are thread safe.
This avoids a regression for issues like #334 where high speed
repeated connections eventually run the HTTP client out of
sockets because all of theirs end up in time_wait.
Maybe the trade-off here is suboptimal, but if both choices will
fail then we prefer fewer changes until the root cause is solved.
It turns out that some miners have been staying with old versions of
Bitcoin Core because their software behaves poorly with persistent
connections and the Bitcoin Core thread and connection limits.
What happens is that underlying HTTP libraries leave connections open
invisibly to their users and then the user runs into the default four
thread limit. This looks like Bitcoin Core is unresponsive to RPC.
There are many things that should be improved in Bitcoin Core's behavior
here, e.g. supporting more concurrent connections, not tying up threads
for idle connections, disconnecting kept-alive connections when limits
are reached, etc. All are fairly big, risky changes.
Disabling keep-alive is a simple workaround. It's often not easy to turn
off the keep-alive support in the client where it may be buried in some
platform library.
If you are one of the few who really needs persistent connections you
probably know that you want them and can find a switch; while if you
don't and the misbehavior is hitting you it is hard to discover the
source of your problems is keepalive related. Given that it is best
to default to off until they're handled better.
Previously the minRelayTxFee was only enforced on user specified values.
It was possible for smartfee to produce a fee below minRelayTxFee which
would just result in the transaction getting stuck because it can't be
relayed.
This also introduces a maxtxfee option which sets an absolute maximum
for any fee created by the wallet, with an intention of increasing
user confidence that the automatic fees won't burn them. This was
frequently a concern even before smartfees.
If the configured fee policy won't even allow the wallet to meet the relay
fee the transaction creation may be aborted.
There are 3 pieces of data that are maintained on disk. The actual block
and undo data, the block index (which can refer to positions on disk),
and the chainstate (which refers to the best block hash).
Earlier, there was no guarantee that blocks were written to disk before
block index entries referring to them were written. This commit introduces
dirty flags for block index data, and delays writing entries until the actual
block data is flushed.
With this stricter ordering in writes, it is now safe to not always flush
after every block, so there is no need for the IsInitialBlockDownload()
check there - instead we just write whenever enough time has passed or
the cache size grows too large. Also updating the wallet's best known block
is delayed until this is done, otherwise the wallet may end up referring to an
unknown block.
In addition, only do a write inside the block processing loop if necessary
(because of cache size exceeded). Otherwise, move the writing to a point
after processing is done, after relaying.
Previously -proxy was not setting the proxy for IsLimited networks, so
if you set your configuration to be onlynet=tor you wouldn't get an
IPv4 proxy set.
The payment protocol gets its proxy configuration from the IPv4 proxy,
and so it would experience a connection leak.
This addresses issue #5355 and also clears up a cosmetic bug where
getinfo proxy output shows nothing when onlynet=tor is set.
- use __func__ instead of hard-coded function name for logging
- update -discover help message to reflect newly added parameter
interaction
- use DEFAULT_LISTEN in a parameter interaction check instead a hard coded
value
This is a simplified re-do of closed pull #3088.
This patch eliminates the privacy and reliability problematic use
of centralized web services for discovering the node's addresses
for advertisement.
The Bitcoin protocol already allows your peers to tell you what
IP they think you have, but this data isn't trustworthy since
they could lie. So the challenge is using it without creating a
DOS vector.
To accomplish this we adopt an approach similar to the one used
by P2Pool: If we're announcing and don't have a better address
discovered (e.g. via UPNP) or configured we just announce to
each peer the address that peer told us. Since peers could
already replace, forge, or drop our address messages this cannot
create a new vulnerability... but if even one of our peers is
giving us a good address we'll eventually make a useful
advertisement.
We also may randomly use the peer-provided address for the
daily rebroadcast even if we otherwise have a seemingly routable
address, just in case we've been misconfigured (e.g. by UPNP).
To avoid privacy problems, we only do these things if discovery
is enabled.
This is less surprising.
Avoids the overload-the-CPU default of using N threads for script
verification as well as N threads for generation where N is number of cores.
Start the RPC server before doing all the (expensive) startup
initialisations like loading the block index. Until the node is ready,
return all calls immediately with a new error signalling "in warmup"
with an appropriate status message (similar to the init message).
This is useful for RPC clients to know that the server is there (e. g.,
they don't have to start it) but not yet available. It is used in
Namecoin and Huntercoin already for some time, and there exists a UI
hooked onto the RPC interface that actively uses this to its advantage.
a873823 CAutoFile: Explicit Get() and remove unused methods (Wladimir J. van der Laan)
fef24ca Add IsNull() to class CAutoFile and remove operator ! (Ruben Dario Ponticeli)
c0195b1 Bugfix: Remove default from -zapwallettxes description (inaccurate) (Luke Dashjr)
0a08aa8 Parameterise command line option defaults, so translations are independent of them (Luke Dashjr)
Previous refactorings broke the ability to rebuild the chainstate by deleting the chainstate
directory, resulting in an incorrect "Incorrect or no genesis block found" error message. Fix
that.
Also, improve the performance of ActivateBestBlockStep by using the skiplist to only discover
a few potential blocks to connect at a time, instead of all blocks forever - as we likely bail
out after connecting a single one anyway.
7c70438 Get rid of the dummy CCoinsViewCache constructor arg (Pieter Wuille)
ed27e53 Add coins_tests with a large randomized CCoinViewCache test. (Pieter Wuille)
058b08c Do not keep fully spent but unwritten CCoins entries cached. (Pieter Wuille)
c9d1a81 Get rid of CCoinsView's SetCoins and SetBestBlock. (Pieter Wuille)
f28aec0 Use ModifyCoins instead of mutable GetCoins. (Pieter Wuille)
- explicit init of pcoinsdbview and pwalletMain (even if not needed, as
globals are init to NULL, it seems cleaner)
- remove check if (pwalletMain) in Shutdown() as delete is valid even if
pwalletMain is NULL
Always make a pid file, not only when `-daemon` specified.
This is useful for troubleshooting, for attaching debuggers and loggers
and such.
- Write the pid file only after the datadir lock was acquired
- Don't create or remove a pid file on WIN32, and also don't show the option
There is no reason to store thousands of orphan transactions;
normally an orphan's parents will either be broadcast or
mined reasonably quickly.
This pull drops the maximum number of orphans from 10,000 down
to 100, and adds a command-line option (-maxorphantx) that is
just like -maxorphanblocks to override the default.
Flushing after every line when printing to console is desirable when
running with systemd but setvbuf() has slightly different semantics
on Windows that causes warnings. Just do an explicit fflush() after
each line print to console instead.
Bypassing the main coins cache allows more thorough checking with the same
memory budget.
This has no effect on performance because everything ends up in the child
cache created by VerifyDB itself.
It has bugged me ever since #4675, which effectively reduced the
number of checked blocks to reduce peak memory usage.
- Pass the coinsview to use as argument to VerifyDB
- This also avoids that the first `pcoinsTip->Flush()` after VerifyDB
writes a large slew of unchanged coin records back to the database.
Split up util.cpp/h into:
- string utilities (hex, base32, base64): no internal dependencies, no dependency on boost (apart from foreach)
- money utilities (parsesmoney, formatmoney)
- time utilities (gettime*, sleep, format date):
- and the rest (logging, argument parsing, config file parsing)
The latter is basically the environment and OS handling,
and is stripped of all utility functions, so we may want to
rename it to something else than util.cpp/h for clarity (Matt suggested
osinterface).
Breaks dependency of sha256.cpp on all the things pulled in by util.
aa82795 Add detailed network info to getnetworkinfo RPC (Wladimir J. van der Laan)
075cf49 Add GetNetworkName function (Wladimir J. van der Laan)
c91a947 Add IsReachable(net) function (Wladimir J. van der Laan)
60dc8e4 Allow -onlynet=onion to be used (Wladimir J. van der Laan)
This commit adds per-network information to the
getnetworkinfo RPC call:
- Is the network limited?
- Is the network reachable
- Which proxy is used for this network, if any
Inspired by #2575.
* Replace -benchmark (and the related fBenchmark) with a regular debug option, -debug=bench.
* Increase coverage and granularity of individual block processing steps.
* Add cummulative times.
First and foremost, this defaults to OFF.
This option lets a node consider such transactions non-standard,
meaning they will not be relayed or mined by default, but other miners
are free to mine these as usual.
The option is only effective for either wallet-less builds or if
-disablewallet is specified as well.
Rebased-By: Wladimir J. van der Laan <laanwj@gmail.com>
Rebased-From: 34d5fc0 4e1a196 bd4307b d53a33b 7e09b36
Github-Pull: #4286
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).
- small changes to Shutdown(), buffer __func__, which is now used in
all LogPrintf() calls and format for better readability
- order using namespace alpabetically
