| Age | Commit message (Collapse) | Author |
|---|
|
Upstream: 9f68ed6b6d1a9c6436ce37913666165f2b180ee3 (PR #6539)
|
|
Normally bitcoin core does not display any network originated strings without
sanitizing or hex encoding. This wasn't done for strcommand in many places.
This could be used to play havoc with a terminal displaying the logs,
especially with printtoconsole in use.
Thanks to Evil-Knievel for reporting this issue.
Conflicts:
src/main.cpp
|
|
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.
Rebased-From: 1a25a7edf82706c3152e2d978d320ec465a34de1 7d2cb485116636595250fce4ea4eab16a877479b
Github-Pull: #5674
|
|
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.
Github-Merge: #5655
Rebased-From: 16a5c18cea7330bd68dc9d2f768eb518af88795b 56c1093dae0c523f9f643f00c67414691272a983 1dd8ee72afc26191da51d8d3a5590eab7c9368f6
|
|
Rebased-From: f9c571aad8261eb9a5cab9dce5b490bd253c5fe1
Github-Pull: #5565
|
|
TLS is subject to downgrade attacks when SSLv3 is available, and
SSLv3 has vulnerabilities.
The popular solution is to disable SSLv3. On the web this breaks
some tiny number of very old clients. While Bitcoin RPC shouldn't
be exposed to the open Internet, it also shouldn't be exposed to
really old SSL implementations, so it shouldn't be a major issue
for us to disable SSLv3.
There is more information on the downgrade attacks and disabling
SSLv3 at https://disablessl3.com/ .
|
|
b2d0162 Test resurrecting memory pool transactions during chain re-org (Gavin Andresen)
3dd8ed7 Delay writing block indexes in invalidate/reconsider (Pieter Wuille)
798faec Add 'invalidateblock' and 'reconsiderblock' RPC commands. (Pieter Wuille)
|
|
Another testing-only potential footgun command.
|
|
|
|
These can be used for testing reorganizations or for manual intervention in case of
chain forks.
|
|
|
|
|
|
These can be used for testing reorganizations or for manual intervention in case of
chain forks.
|
|
|
|
3c30f27 travis: disable rpc tests for windows until they're not so flaky (Cory Fields)
daf03e7 RPC tests: create initial chain with specific timestamps (Gavin Andresen)
a8b2ce5 regression test only setmocktime RPC call (Gavin Andresen)
|
|
1) const-ify internal helper ParseHashStr()
2) use HTTPError() helper when returning HTTP_NOT_FOUND
|
|
|
|
|
|
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.
|
|
|
|
message contains sensitive information. This keeps the message from being output to the debug log by bitcoind. Fixes a possible security risk when starting bitcoind in server mode without the 'rpcpassword' option configured, resulting in the "suggested" password being output to the debug log.
|
|
|
|
Github-Pull: #4856
|
|
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.
|
|
As discussed on IRC.
It seems bad to base a decision to delay based on the password length,
as it leaks a small amount of information.
|
|
Goal: Gain live insight into the mempool. Groundwork for future work
that caps mempool size.
|
|
Conflicts:
src/rpcserver.cpp
Github-Pull: #4539
Rebased-By: Wladimir J. van der Laan <laanwj@gmail.com>
Rebased-From: df3d321
|
|
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.
|
|
4eedf4f make RandAddSeed() use OPENSSL_cleanse() (Philip Kaufmann)
6354935 move rand functions from util to new random.h/.cpp (Philip Kaufmann)
001a53d add GetRandBytes() as wrapper for RAND_bytes() (Philip Kaufmann)
|
|
b45a6e8 Add test for getblocktemplate longpolling (Wladimir J. van der Laan)
ff6a7af getblocktemplate: longpolling support (Luke Dashjr)
|
|
|
|
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
|
|
a3e192a replaced MINE_ with ISMINE_ (JaSK)
53a2148 fixed bug where validateaddress doesn't display information (JaSK)
f28707a fixed bug in ListReceived() (JaSK)
519dd1c Added MINE_ALL = (spendable|watchonly) (JaSK)
23b0506 Fixed some stuff in TransactionDesc (JaSK)
80dda36 removed default argument values for ismine filter (JaSK)
d5087d1 Use script matching rather than destination matching for watch-only. (Pieter Wuille)
0fa2f88 added includedWatchonly argument to listreceivedbyaddress/...account (JaSK)
f87ba3d added includeWatchonly argument to 'gettransaction' because it affects balance calculation (JaSK)
a5c6c5d fixed tiny glitch and improved readability like laanwj suggested (JaSK)
d7d5d23 Added argument to listtransactions and listsinceblock to include watchonly addresses (JaSK)
952877e Showing 'involvesWatchonly' property for transactions returned by 'listtransactions' and 'listsinceblock'. It is only appended when the transaction involves a watchonly address. (JaSK)
83f3543 Added argument to listaccounts to include watchonly addresses (JaSK)
d4640d7 Added argument to getbalance to include watchonly addresses and fixed errors in balance calculation. (JaSK)
d2692f6 Watchonly transactions are marked in transaction history (JaSK)
ffd40da Watchonly balances are shown separately in gui. (JaSK)
2935b21 qt: Hide unspendable outputs in coin control (Wladimir J. van der Laan)
c898846 Add support for watch-only addresses (Pieter Wuille)
|
|
Also add to HelpMessage() what specifications are valid.
|
|
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
|
|
Accepts the transaction into mined blocks at a higher (or lower) priority
|
|
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.
|
