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.
Split bitcoinrpc up into
- rpcserver: bitcoind RPC server
- rpcclient: bitcoin-cli RPC client
- rpcprotocol: shared common HTTP/JSON-RPC protocol code
One step towards making bitcoin-cli independent from the rest
of the code, and thus a smaller executable that doesn't have to
be linked against leveldb.
This commit only does code movement, there are no functional changes.
I'm writing some wallet regression tests using -regtest mode, and
need to generate an initial multi-hundred-block chain. Repeatedly
calling setgenerate to generate one block is slow and doesn't
work properly, because block creation happens asynchronously.
This adds two features to setgenerate in -regtest mode:
1) Instead of being interpreted as number of threads to start, the
third argument is the number of blocks to generate.
2) setgenerate will not return until the block creation threads
have created the requested number of blocks.
Based on the proposal, update the help message of rpc methods
- strings arguments are in double quotes rather than square brackets
- numeric arguments have no quotes (and no default value)
- optional parameters are surrounded by round brackets
- json arguments are strings but don't use double quotes
Added 3 sections for the details
- Arguments: lists each argument, it's type, required or not, a default, and a description
- Result: The method result, with json format if applicable, type, and a description
- Examples: examples calls using bitcoin-cli and curl for json rpc call
Problems
- maybe this is too verbose
- lines might be too long
- description are not good or complete
- examples may be too much
Use misc methods of avoiding unnecesary header includes.
Replace int typedefs with int##_t from stdint.h.
Replace PRI64[xdu] with PRI[xdu]64 from inttypes.h.
Normalize QT_VERSION ifs where possible.
Resolve some indirect dependencies as direct ones.
Remove extern declarations from .cpp files.
This required some code movement (what was CWalletTx::AcceptToMemoryPool
doing in main?), and adding a few explicit includes that used to be
implicit through init.h.
- this extends the accepted ciphersuites with TLSv1.2 ones
- also removes !AH, as I could not find documentation on it and the change
did not result in a changed ciphersuite list (checked via openssl
ciphers -v)
- closes#3096 (which also contains more details)
New RPC "ping" command to request ping.
Implemented "pong" message handler.
New "pingtime" field in getpeerinfo, to provide results to user.
New "pingwait" field, to show pings still in flight, to better see newly lagging peers.
There have been several incidents where mainnet experimentation with
raw transactions resulted in insane fees. This is hard to prevent
in the raw transaction api because the inputs may not be known.
Since sending doesn't work if the inputs aren't known, we can catch
it there.
This rejects fees > than 10000 * nMinRelayTxFee or 1 BTC with the
defaults and can be overridden with a bool at the rpc.
Fixes issue#2838; this is a tweaked version of pull#2845 that
should not leak the length of the password and is more generic,
in case we run into other situations where we need
timing-attack-resistant comparisons.
Pieter Wuille