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.
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.
The size limit makes a lot of sense for the server, as it never has to
accept very large data.
The client, however, can request arbitrary amounts of data with
`listtransactions` on a large wallet.
Fixes#4604.
Split up HTTPReply into HTTPReply and HTTPReplyHeader, so that
the message data can be streamed directly.
Also removes a c_str(), which would have prevented binary
output with NUL characters in it.
Port over https://github.com/chronokings/huntercoin/pull/19 from
Huntercoin: This implements a new RPC command "getchaintips" that can be
used to find all currently active chain heads. This is similar to the
-printblocktree startup option, but it can be used without restarting
just via the RPC interface on a running daemon.
This removes some inconsistencies in what worked and didn't work in
safemode. Now only RPCs involved in getting balances or sending
funds are disabled.
Previously you could mine but not submit blocks— but we may need more
blocks to resolve a fork that triggered safe mode in the first place,
and the non-submission was not reliable since some miners submit
blocks via multiple means. There were also a number of random commands
disabled that had nothing to do with the blockchain like verifymessage.
Thanks to earlz for pointing out that there were some moderately cheap
ways to maliciously trigger safe mode, which brought attention to
the fact that safemode wasn't used in a very intelligent way.
- add a small wrapper in util around RAND_bytes() and replace with
GetRandBytes() in the code to log errors from calling RAND_bytes()
- remove OpenSSL header rand.h where no longer needed
Changes:
* Add Add/Have WatchOnly methods to CKeyStore, and implementations
in CBasicKeyStore.
* Add similar methods to CWallet, and support entries for it in
CWalletDB.
* Make IsMine in script/wallet return a new enum 'isminetype',
rather than a boolean. This allows distinguishing between
spendable and unspendable coins.
* Add a field fSpendable to COutput (GetAvailableCoins' return type).
* Mark watchonly coins in listunspent as 'watchonly': true.
* Add 'watchonly' to validateaddress, suppressing script/pubkey/...
in this case.
Based on a patch by Eric Lombrozo.
Conflicts:
src/qt/walletmodel.cpp
src/rpcserver.cpp
src/wallet.cpp
After pull #4288, RPC messages indicating errors have a Content-Length unrelated
to their actual contents, rendering bitcoin-cli and curl unable to decode the
reply.
This patch sets the Content-Length field based on the actual content returned.
Additionally, pull #4288 clobbered the error descriptions provided in
ErrorReply, which bitcoin-cli relies upon; this patch moves #4288 http-error
descriptions to an HTTPError method, allowing HTTPReply to pass content on
unchanged.
1) support varying content types
2) support only sending the header
3) properly deliver error message as content, if HTTP error
4) move AcceptedConnection class to header, for wider use
This commit removes all the unnecessary dependencies (key, core,
netbase, sync, ...) from bitcoin-cli.
To do this it shards the chain parameters into BaseParams, which
contains just the RPC port and data directory (as used by utils and
bitcoin-cli) and Params, with the rest.
Cancelling the RPC acceptors can sometimes result in an error about
a bad file descriptor.
As this is the shutdown sequence we need to continue nevertheless,
ignore these errors, log a warning and proceed.
Fixes#4352.
New RPC methods: return an estimate of the fee (or priority) a
transaction needs to be likely to confirm in a given number of
blocks.
Mike Hearn created the first version of this method for estimating fees.
It works as follows:
For transactions that took 1 to N (I picked N=25) blocks to confirm,
keep N buckets with at most 100 entries in each recording the
fees-per-kilobyte paid by those transactions.
(separate buckets are kept for transactions that confirmed because
they are high-priority)
The buckets are filled as blocks are found, and are saved/restored
in a new fee_estiamtes.dat file in the data directory.
A few variations on Mike's initial scheme:
To estimate the fee needed for a transaction to confirm in X buckets,
all of the samples in all of the buckets are used and a median of
all of the data is used to make the estimate. For example, imagine
25 buckets each containing the full 100 entries. Those 2,500 samples
are sorted, and the estimate of the fee needed to confirm in the very
next block is the 50'th-highest-fee-entry in that sorted list; the
estimate of the fee needed to confirm in the next two blocks is the
150'th-highest-fee-entry, etc.
That algorithm has the nice property that estimates of how much fee
you need to pay to get confirmed in block N will always be greater
than or equal to the estimate for block N+1. It would clearly be wrong
to say "pay 11 uBTC and you'll get confirmed in 3 blocks, but pay
12 uBTC and it will take LONGER".
A single block will not contribute more than 10 entries to any one
bucket, so a single miner and a large block cannot overwhelm
the estimates.
Add -rpcbind command option to specify binding RPC service on one
or multiple specific interfaces.
Functionality if -rpcbind is not specified remains the same as before:
- If no -rpcallowip specified, bind on localhost
- If no -rpcbind specified, bind on any interface
Implements part of #3111.
Fixes#4156.
The problem is that the boost::asio::io_service destructor
waits for the acceptors to finish (on windows, and boost 1.55).
Fix this by keeping track of the acceptors and cancelling them before
stopping the event loops.
Make sure conn object always gets cleaned up by using a
`boost::shared_ptr`.
This makes valgrind happy - before this commit, one connection object
always leaked at shutdown, as well as can avoid other leaks, when
for example an exception happens.
Also add an explicit Close() to the !ClientAllowed path to make it similar
to the normal path (I'm not sure whether it is needed, but it
can't hurt).
According to the [boost::asio documentation](http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio/reference/basic_socket_acceptor/async_accept/overload2.html),
the function signature of the handler must be:
void handler(
const boost::system::error_code& error // Result of operation.
);
We were binding *all* the arguments, instead of all but the error,
resulting in nullary function that never got the error. Fix this
by adding an input argument substitution.
`-rpcallowip` currently has a wacky wildcard-based format. After this
commit it will accept the more standard format, for example:
- Ranges with netmask 127.0.0.0/255.255.255.0, ::/0
- Ranges with cidr 12.3.4.5/24, 12:34:56:78:9a:bc:de:00/112
- Loose IPs ::1, 127.0.0.1
Trying to use the old *?-based format will result in an error message at
launch.
Adds two new info query commands that take over information from
hodge-podge `getinfo`.
Also some new information is added:
- `getblockchaininfo`
- `chain`: (string) current chain (main, testnet3, regtest)
- `verificationprogress: (numeric) estimated verification progress
- `chainwork`
- `getnetworkinfo`
- `localaddresses`: (array) local addresses, from mapLocalHost (fixes#1734)
Use sensible categories (overall control, P2P, blockchain/UTXO and
mining, wallet, wallet-enabled mining) and sort within each.
Also remove unnecessary #ifdef ENABLE_WALLET from `rpcnet.cpp`.
Functionality-neutral change.
Taught bitcoind to close the HTTP connection after it gets a 'stop' command,
to make it easier for the regression tests to cleanly stop.
Move bitcoinrpc files to correct location.
Tidied up the python-based regression tests.
contrib/devtools/fix-copyright-headers.py script to be able to perform this maintenance task with ease during the rest of the year, every year. Modifications to contrib/devtools/README.md to document what fix-copyright-headers.py does.
After the tinyformat switch sprintf() family functions support passing
actual std::string objects.
Remove unnecessary c_str calls (236 of them) in logging and formatting.
Currently it is only possible to use `walletpassphrase` to unlock the
wallet when bitcoin is started in server mode.
Almost everything that manipulates the wallet in the RPC console
needs the wallet to be unlocked and is thus unusable without -server.
This is pretty unintuitive to me, and I'm sure it's even more confusing
to users.
Solve this with a very minimal change: by making the GUI start a
dummy RPC thread just to handle timeouts.
The following mining-related RPC calls don't use the wallet:
- getnetworkhashps
- getmininginfo
- getblocktemplate
- submitblock
Enable them when compiling with --disable-wallet.
Jeff Garzik