diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/REST-interface.md | 12 | ||||
| -rw-r--r-- | doc/build-openbsd.md | 14 | ||||
| -rw-r--r-- | doc/developer-notes.md | 16 | ||||
| -rw-r--r-- | doc/init.md | 28 | ||||
| -rw-r--r-- | doc/release-notes.md | 326 | ||||
| -rw-r--r-- | doc/zmq.md | 2 |
6 files changed, 38 insertions, 360 deletions
diff --git a/doc/REST-interface.md b/doc/REST-interface.md index caf6782886..7a17c175bd 100644 --- a/doc/REST-interface.md +++ b/doc/REST-interface.md @@ -8,14 +8,14 @@ The interface runs on the same port as the JSON-RPC interface, by default port 8 Supported API ------------- -####Transactions +#### Transactions `GET /rest/tx/<TX-HASH>.<bin|hex|json>` Given a transaction hash: returns a transaction in binary, hex-encoded binary, or JSON formats. For full TX query capability, one must enable the transaction index via "txindex=1" command line / configuration option. -####Blocks +#### Blocks `GET /rest/block/<BLOCK-HASH>.<bin|hex|json>` `GET /rest/block/notxdetails/<BLOCK-HASH>.<bin|hex|json>` @@ -25,12 +25,12 @@ The HTTP request and response are both handled entirely in-memory, thus making m With the /notxdetails/ option JSON response will only contain the transaction hash instead of the complete transaction details. The option only affects the JSON response. -####Blockheaders +#### Blockheaders `GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex|json>` Given a block hash: returns <COUNT> amount of blockheaders in upward direction. -####Chaininfos +#### Chaininfos `GET /rest/chaininfo.json` Returns various state info regarding block chain processing. @@ -48,7 +48,7 @@ Only supports JSON as output format. * softforks : (array) status of softforks in progress * bip9_softforks : (object) status of BIP9 softforks in progress -####Query UTXO set +#### Query UTXO set `GET /rest/getutxos/<checkmempool>/<txid>-<n>/<txid>-<n>/.../<txid>-<n>.<bin|hex|json>` The getutxo command allows querying of the UTXO set given a set of outpoints. @@ -81,7 +81,7 @@ $ curl localhost:18332/rest/getutxos/checkmempool/b2cdfd7b89def827ff8af7cd9bff76 } ``` -####Memory pool +#### Memory pool `GET /rest/mempool/info.json` Returns various information about the TX mempool. diff --git a/doc/build-openbsd.md b/doc/build-openbsd.md index f4a9826d80..cd800464b4 100644 --- a/doc/build-openbsd.md +++ b/doc/build-openbsd.md @@ -1,6 +1,6 @@ OpenBSD build guide ====================== -(updated for OpenBSD 6.0) +(updated for OpenBSD 6.1) This guide describes how to build bitcoind and command-line utilities on OpenBSD. @@ -48,13 +48,13 @@ BOOST_PREFIX="${BITCOIN_ROOT}/boost" mkdir -p $BOOST_PREFIX # Fetch the source and verify that it is not tampered with -curl -o boost_1_61_0.tar.bz2 http://heanet.dl.sourceforge.net/project/boost/boost/1.61.0/boost_1_61_0.tar.bz2 -echo 'a547bd06c2fd9a71ba1d169d9cf0339da7ebf4753849a8f7d6fdb8feee99b640 boost_1_61_0.tar.bz2' | sha256 -c -# MUST output: (SHA256) boost_1_61_0.tar.bz2: OK -tar -xjf boost_1_61_0.tar.bz2 +curl -o boost_1_64_0.tar.bz2 https://netcologne.dl.sourceforge.net/project/boost/boost/1.64.0/boost_1_64_0.tar.bz2 +echo '7bcc5caace97baa948931d712ea5f37038dbb1c5d89b43ad4def4ed7cb683332 boost_1_64_0.tar.bz2' | sha256 -c +# MUST output: (SHA256) boost_1_64_0.tar.bz2: OK +tar -xjf boost_1_64_0.tar.bz2 -# Boost 1.61 needs one small patch for OpenBSD -cd boost_1_61_0 +# Boost 1.64 needs one small patch for OpenBSD +cd boost_1_64_0 # Also here: https://gist.githubusercontent.com/laanwj/bf359281dc319b8ff2e1/raw/92250de8404b97bb99d72ab898f4a8cb35ae1ea3/patch-boost_test_impl_execution_monitor_ipp.patch patch -p0 < /usr/ports/devel/boost/patches/patch-boost_test_impl_execution_monitor_ipp diff --git a/doc/developer-notes.md b/doc/developer-notes.md index d783a7a8ae..ad15aa662e 100644 --- a/doc/developer-notes.md +++ b/doc/developer-notes.md @@ -4,7 +4,7 @@ Developer Notes Various coding styles have been used during the history of the codebase, and the result is not very consistent. However, we're now trying to converge to a single style, which is specified below. When writing patches, favor the new -style over attempting to mimick the surrounding style, except for move-only +style over attempting to mimic the surrounding style, except for move-only commits. Do not submit patches solely to modify the style of existing code. @@ -37,6 +37,8 @@ code. - **Miscellaneous** - `++i` is preferred over `i++`. + - `nullptr` is preferred over `NULL` or `(void*)0`. + - `static_assert` is preferred over `assert` where possible. Generally; compile-time checking is preferred over run-time checking. Block style example: ```c++ @@ -275,7 +277,7 @@ Wallet - *Rationale*: In RPC code that conditionally uses the wallet (such as `validateaddress`) it is easy to forget that global pointer `pwalletMain` - can be NULL. See `test/functional/disablewallet.py` for functional tests + can be nullptr. See `test/functional/disablewallet.py` for functional tests exercising the API with `-disablewallet` - Include `db_cxx.h` (BerkeleyDB header) only when `ENABLE_WALLET` is set @@ -570,16 +572,14 @@ A few guidelines for introducing and reviewing new RPC interfaces: is specified as-is in BIP22. - Missing arguments and 'null' should be treated the same: as default values. If there is no - default value, both cases should fail in the same way. + default value, both cases should fail in the same way. The easiest way to follow this + guideline is detect unspecified arguments with `params[x].isNull()` instead of + `params.size() <= x`. The former returns true if the argument is either null or missing, + while the latter returns true if is missing, and false if it is null. - *Rationale*: Avoids surprises when switching to name-based arguments. Missing name-based arguments are passed as 'null'. - - *Exception*: Many legacy exceptions to this exist, one of the worst ones is - `getbalance` which follows a completely different code path based on the - number of arguments. We are still in the process of cleaning these up. Do not introduce - new ones. - - Try not to overload methods on argument type. E.g. don't make `getblock(true)` and `getblock("hash")` do different things. diff --git a/doc/init.md b/doc/init.md index e3db5b05ef..75f9013f29 100644 --- a/doc/init.md +++ b/doc/init.md @@ -10,14 +10,14 @@ can be found in the contrib/init folder. contrib/init/bitcoind.conf: Upstart service configuration file contrib/init/bitcoind.init: CentOS compatible SysV style init script -1. Service User +Service User --------------------------------- All three Linux startup configurations assume the existence of a "bitcoin" user and group. They must be created before attempting to use these scripts. The OS X configuration assumes bitcoind will be set up for the current user. -2. Configuration +Configuration --------------------------------- At a bare minimum, bitcoind requires that the rpcpassword setting be set @@ -46,10 +46,10 @@ relative to the data directory. `wallet` *only* supports relative paths. For an example configuration file that describes the configuration settings, see `contrib/debian/examples/bitcoin.conf`. -3. Paths +Paths --------------------------------- -3a) Linux +### Linux All three configurations assume several paths that might need to be adjusted. @@ -65,17 +65,17 @@ reasons to make the configuration file and data directory only readable by the bitcoin user and group. Access to bitcoin-cli and other bitcoind rpc clients can then be controlled by group membership. -3b) Mac OS X +### Mac OS X Binary: `/usr/local/bin/bitcoind` Configuration file: `~/Library/Application Support/Bitcoin/bitcoin.conf` -Data directory: `~/Library/Application Support/Bitcoin` -Lock file: `~/Library/Application Support/Bitcoin/.lock` +Data directory: `~/Library/Application Support/Bitcoin` +Lock file: `~/Library/Application Support/Bitcoin/.lock` -4. Installing Service Configuration +Installing Service Configuration ----------------------------------- -4a) systemd +### systemd Installing this .service file consists of just copying it to /usr/lib/systemd/system directory, followed by the command @@ -84,14 +84,14 @@ Installing this .service file consists of just copying it to To test, run `systemctl start bitcoind` and to enable for system startup run `systemctl enable bitcoind` -4b) OpenRC +### OpenRC Rename bitcoind.openrc to bitcoind and drop it in /etc/init.d. Double check ownership and permissions and make it executable. Test it with `/etc/init.d/bitcoind start` and configure it to run on startup with `rc-update add bitcoind` -4c) Upstart (for Debian/Ubuntu based distributions) +### Upstart (for Debian/Ubuntu based distributions) Drop bitcoind.conf in /etc/init. Test by running `service bitcoind start` it will automatically start on reboot. @@ -99,7 +99,7 @@ it will automatically start on reboot. NOTE: This script is incompatible with CentOS 5 and Amazon Linux 2014 as they use old versions of Upstart and do not supply the start-stop-daemon utility. -4d) CentOS +### CentOS Copy bitcoind.init to /etc/init.d/bitcoind. Test by running `service bitcoind start`. @@ -107,7 +107,7 @@ Using this script, you can adjust the path and flags to the bitcoind program by setting the BITCOIND and FLAGS environment variables in the file /etc/sysconfig/bitcoind. You can also use the DAEMONOPTS environment variable here. -4e) Mac OS X +### Mac OS X Copy org.bitcoin.bitcoind.plist into ~/Library/LaunchAgents. Load the launch agent by running `launchctl load ~/Library/LaunchAgents/org.bitcoin.bitcoind.plist`. @@ -118,7 +118,7 @@ NOTE: This approach is intended for those wanting to run bitcoind as the current You will need to modify org.bitcoin.bitcoind.plist if you intend to use it as a Launch Daemon with a dedicated bitcoin user. -5. Auto-respawn +Auto-respawn ----------------------------------- Auto respawning is currently only configured for Upstart and systemd. diff --git a/doc/release-notes.md b/doc/release-notes.md index 9398a3f8c2..aa1d1bea14 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -1,9 +1,9 @@ (note: this is a temporary file, to be added-to by anybody, and moved to release-notes at release time) -Bitcoin Core version *0.15.0* is now available from: +Bitcoin Core version *version* is now available from: - <https://bitcoin.org/bin/bitcoin-core-0.15.0/> + <https://bitcoin.org/bin/bitcoin-core-*version*/> This is a new major version release, including new features, various bugfixes and performance improvements, as well as updated translations. @@ -56,332 +56,10 @@ frequently tested on them. Notable changes =============== -Performance Improvements ------------------------- - -Version 0.15 contains a number of significant performance improvements, which make -Initial Block Download, startup, transaction and block validation much faster: - -- The chainstate database (which is used for tracking UTXOs) has been changed - from a per-transaction model to a per-output model (See [PR 10195](https://github.com/bitcoin/bitcoin/pull/10195)). Advantages of this model - are that it: - - avoids the CPU overhead of deserializing and serializing the unused outputs; - - has more predictable memory usage; - - uses simpler code; - - is adaptable to various future cache flushing strategies. - - As a result, validating the blockchain during Initial Block Download (IBD) and reindex - is ~30-40% faster, uses 10-20% less memory, and flushes to disk far less frequently. - The only downside is that the on-disk database is 15% larger. During the conversion from the previous format - a few extra gigabytes may be used. -- Earlier versions experienced a spike in memory usage while flushing UTXO updates to disk. - As a result, only half of the available memory was actually used as cache, and the other half was - reserved to accommodate flushing. This is no longer the case (See [PR 10148](https://github.com/bitcoin/bitcoin/pull/10148)), and the entirety of - the available cache (see `-dbcache`) is now actually used as cache. This reduces the flushing - frequency by a factor 2 or more. -- In previous versions, signature validation for transactions has been cached when the - transaction is accepted to the mempool. Version 0.15 extends this to cache the entire script - validity (See [PR 10192](https://github.com/bitcoin/bitcoin/pull/10192)). This means that if a transaction in a block has already been accepted to the - mempool, the scriptSig does not need to be re-evaluated. Empirical tests show that - this results in new block validation being 40-50% faster. -- LevelDB has been upgraded to version 1.20 (See [PR 10544](https://github.com/bitcoin/bitcoin/pull/10544)). This version contains hardware acceleration for CRC - on architectures supporting SSE 4.2. As a result, synchronization and block validation are now faster. -- SHA256 hashing has been optimized for architectures supporting SSE 4 (See [PR 10182](https://github.com/bitcoin/bitcoin/pull/10182)). SHA256 is around - 50% faster on supported hardware, which results in around 5% faster IBD and block - validation. In version 0.15, SHA256 hardware optimization is disabled in release builds by - default, but can be enabled by using `--enable-experimental-asm` when building. -- Refill of the keypool no longer flushes the wallet between each key which resulted in a ~20x speedup in creating a new wallet. Part of this speedup was used to increase the default keypool to 1000 keys to make recovery more robust. (See [PR 10831](https://github.com/bitcoin/bitcoin/pull/10831)). - -Fee Estimation Improvements ---------------------------- - -Fee estimation has been significantly improved in version 0.15, with more accurate fee estimates used by the wallet and a wider range of options for advanced users of the `estimatesmartfee` and `estimaterawfee` RPCs (See [PR 10199](https://github.com/bitcoin/bitcoin/pull/10199)). - -### Changes to internal logic and wallet behavior - -- Internally, estimates are now tracked on 3 different time horizons. This allows for longer targets and means estimates adjust more quickly to changes in conditions. -- Estimates can now be *conservative* or *economical*. *Conservative* estimates use longer time horizons to produce an estimate which is less susceptible to rapid changes in fee conditions. *Economical* estimates use shorter time horizons and will be more affected by short-term changes in fee conditions. Economical estimates may be considerably lower during periods of low transaction activity (for example over weekends), but may result in transactions being unconfirmed if prevailing fees increase rapidly. -- By default, the wallet will use conservative fee estimates to increase the reliability of transactions being confirmed within the desired target. For transactions that are marked as replaceable, the wallet will use an economical estimate by default, since the fee can be 'bumped' if the fee conditions change rapidly (See [PR 10589](https://github.com/bitcoin/bitcoin/pull/10589)). -- Estimates can now be made for confirmation targets up to 1008 blocks (one week). -- More data on historical fee rates is stored, leading to more precise fee estimates. -- Transactions which leave the mempool due to eviction or other non-confirmed reasons are now taken into account by the fee estimation logic, leading to more accurate fee estimates. -- The fee estimation logic will make sure enough data has been gathered to return a meaningful estimate. If there is insufficient data, a fallback default fee is used. - -### Changes to fee estimate RPCs - -- The `estimatefee` RPC is now deprecated in favor of using only `estimatesmartfee` (which is the implementation used by the GUI) -- The `estimatesmartfee` RPC interface has been changed (See [PR 10707](https://github.com/bitcoin/bitcoin/pull/10707)): - - The `nblocks` argument has been renamed to `conf_target` (to be consistent with other RPC methods). - - An `estimate_mode` argument has been added. This argument takes one of the following strings: `CONSERVATIVE`, `ECONOMICAL` or `UNSET` (which defaults to `CONSERVATIVE`). - - The RPC return object now contains an `errors` member, which returns errors encountered during processing. - - If Bitcoin Core has not been running for long enough and has not seen enough blocks or transactions to produce an accurate fee estimation, an error will be returned (previously a value of -1 was used to indicate an error, which could be confused for a feerate). -- A new `estimaterawfee` RPC is added to provide raw fee data. External clients can query and use this data in their own fee estimation logic. - -Multi-wallet support --------------------- - -Bitcoin Core now supports loading multiple, separate wallets (See [PR 8694](https://github.com/bitcoin/bitcoin/pull/8694), [PR 10849](https://github.com/bitcoin/bitcoin/pull/10849)). The wallets are completely separated, with individual balances, keys and received transactions. - -Multi-wallet is enabled by using more than one `-wallet` argument when starting Bitcoin, either on the command line or in the Bitcoin config file. - -**In Bitcoin-Qt, only the first wallet will be displayed and accessible for creating and signing transactions.** GUI selectable multiple wallets will be supported in a future version. However, even in 0.15 other loaded wallets will continue to remain synchronized to the node's current tip in the background. This can be useful if running a pruned node, since loading a wallet where the most recent sync is beyond the pruned height results in having to download and revalidate the whole blockchain. Continuing to synchronize all wallets in the background avoids this problem. - -Bitcoin Core 0.15.0 contains the following changes to the RPC interface and `bitcoin-cli` for multi-wallet: - -* When running Bitcoin Core with a single wallet, there are **no** changes to the RPC interface or `bitcoin-cli`. All RPC calls and `bitcoin-cli` commands continue to work as before. -* When running Bitcoin Core with multi-wallet, all *node-level* RPC methods continue to work as before. HTTP RPC requests should be send to the normal `<RPC IP address>:<RPC port>/` endpoint, and `bitcoin-cli` commands should be run as before. A *node-level* RPC method is any method which does not require access to the wallet. -* When running Bitcoin Core with multi-wallet, *wallet-level* RPC methods must specify the wallet for which they're intended in every request. HTTP RPC requests should be send to the `<RPC IP address>:<RPC port>/wallet/<wallet name>/` endpoint, for example `127.0.0.1:8332/wallet/wallet1.dat/`. `bitcoin-cli` commands should be run with a `-rpcwallet` option, for example `bitcoin-cli -rpcwallet=wallet1.dat getbalance`. -* A new *node-level* `listwallets` RPC method is added to display which wallets are currently loaded. The names returned by this method are the same as those used in the HTTP endpoint and for the `rpcwallet` argument. - -Note that while multi-wallet is now fully supported, the RPC multi-wallet interface should be considered unstable for version 0.15.0, and there may backwards-incompatible changes in future versions. - -Replace-by-fee control in the GUI ---------------------------------- - -Bitcoin Core has supported creating opt-in replace-by-fee (RBF) transactions -since version 0.12.0, and since version 0.14.0 has included a `bumpfee` RPC method to -replace unconfirmed opt-in RBF transactions with a new transaction that pays -a higher fee. - -In version 0.15, creating an opt-in RBF transaction and replacing the unconfirmed -transaction with a higher-fee transaction are both supported in the GUI (See [PR 9592](https://github.com/bitcoin/bitcoin/pull/9592)). - -Removal of Coin Age Priority ----------------------------- - -In previous versions of Bitcoin Core, a portion of each block could be reserved for transactions based on the age and value of UTXOs they spent. This concept (Coin Age Priority) is a policy choice by miners, and there are no consensus rules around the inclusion of Coin Age Priority transactions in blocks. In practice, only a few miners continue to use Coin Age Priority for transaction selection in blocks. Bitcoin Core 0.15 removes all remaining support for Coin Age Priority (See [PR 9602](https://github.com/bitcoin/bitcoin/pull/9602)). This has the following implications: - -- The concept of *free transactions* has been removed. High Coin Age Priority transactions would previously be allowed to be relayed even if they didn't attach a miner fee. This is no longer possible since there is no concept of Coin Age Priority. The `-limitfreerelay` and `-relaypriority` options which controlled relay of free transactions have therefore been removed. -- The `-sendfreetransactions` option has been removed, since almost all miners do not include transactions which do not attach a transaction fee. -- The `-blockprioritysize` option has been removed. -- The `estimatepriority` and `estimatesmartpriority` RPCs have been removed. -- The `getmempoolancestors`, `getmempooldescendants`, `getmempooolentry` and `getrawmempool` RPCs no longer return `startingpriority` and `currentpriority`. -- The `prioritisetransaction` RPC no longer takes a `priority_delta` argument, which is replaced by a `dummy` argument for backwards compatibility with clients using positional arguments. The RPC is still used to change the apparent fee-rate of the transaction by using the `fee_delta` argument. -- `-minrelaytxfee` can now be set to 0. If `minrelaytxfee` is set, then fees smaller than `minrelaytxfee` (per kB) are rejected from relaying, mining and transaction creation. This defaults to 1000 satoshi/kB. -- The `-printpriority` option has been updated to only output the fee rate and hash of transactions included in a block by the mining code. - -Mempool Persistence Across Restarts ------------------------------------ - -Version 0.14 introduced mempool persistence across restarts (the mempool is saved to a `mempool.dat` file in the data directory prior to shutdown and restores the mempool when the node is restarted). Version 0.15 allows this feature to be switched on or off using the `-persistmempool` command-line option (See [PR 9966](https://github.com/bitcoin/bitcoin/pull/9966)). By default, the option is set to true, and the mempool is saved on shutdown and reloaded on startup. If set to false, the `mempool.dat` file will not be loaded on startup or saved on shutdown. - -New RPC methods ---------------- - -Version 0.15 introduces several new RPC methods: - -- `abortrescan` stops current wallet rescan, e.g. when triggered by an `importprivkey` call (See [PR 10208](https://github.com/bitcoin/bitcoin/pull/10208)). -- `combinerawtransaction` accepts a JSON array of raw transactions and combines them into a single raw transaction (See [PR 10571](https://github.com/bitcoin/bitcoin/pull/10571)). -- `estimaterawfee` returns raw fee data so that customized logic can be implemented to analyze the data and calculate estimates. See [Fee Estimation Improvements](#fee-estimation-improvements) for full details on changes to the fee estimation logic and interface. -- `getchaintxstats` returns statistics about the total number and rate of transactions - in the chain (See [PR 9733](https://github.com/bitcoin/bitcoin/pull/9733)). -- `listwallets` lists wallets which are currently loaded. See the *Multi-wallet* section - of these release notes for full details (See [Multi-wallet support](#multi-wallet-support)). -- `uptime` returns the total runtime of the `bitcoind` server since its last start (See [PR 10400](https://github.com/bitcoin/bitcoin/pull/10400)). - -Low-level RPC changes ---------------------- - -- When using Bitcoin Core in multi-wallet mode, RPC requests for wallet methods must specify - the wallet that they're intended for. See [Multi-wallet support](#multi-wallet-support) for full details. - -- The new database model no longer stores information about transaction - versions of unspent outputs (See [Performance improvements](#performance-improvements)). This means that: - - The `gettxout` RPC no longer has a `version` field in the response. - - The `gettxoutsetinfo` RPC reports `hash_serialized_2` instead of `hash_serialized`, - which does not commit to the transaction versions of unspent outputs, but does - commit to the height and coinbase information. - - The `getutxos` REST path no longer reports the `txvers` field in JSON format, - and always reports 0 for transaction versions in the binary format - -- The `estimatefee` RPC is deprecated. Clients should switch to using the `estimatesmartfee` RPC, which returns better fee estimates. See [Fee Estimation Improvements](#fee-estimation-improvements) for full details on changes to the fee estimation logic and interface. - -- The `gettxoutsetinfo` response now contains `disk_size` and `bogosize` instead of - `bytes_serialized`. The first is a more accurate estimate of actual disk usage, but - is not deterministic. The second is unrelated to disk usage, but is a - database-independent metric of UTXO set size: it counts every UTXO entry as 50 + the - length of its scriptPubKey (See [PR 10426](https://github.com/bitcoin/bitcoin/pull/10426)). - -- `signrawtransaction` can no longer be used to combine multiple transactions into a single transaction. Instead, use the new `combinerawtransaction` RPC (See [PR 10571](https://github.com/bitcoin/bitcoin/pull/10571)). - -- `fundrawtransaction` no longer accepts a `reserveChangeKey` option. This option used to allow RPC users to fund a raw transaction using an key from the keypool for the change address without removing it from the available keys in the keypool. The key could then be re-used for a `getnewaddress` call, which could potentially result in confusing or dangerous behaviour (See [PR 10784](https://github.com/bitcoin/bitcoin/pull/10784)). - -- `estimatepriority` and `estimatesmartpriority` have been removed. See [Removal of Coin Age Priority](#removal-of-coin-age-priority). - -- The `listunspent` RPC now takes a `query_options` argument (see [PR 8952](https://github.com/bitcoin/bitcoin/pull/8952)), which is a JSON object - containing one or more of the following members: - - `minimumAmount` - a number specifying the minimum value of each UTXO - - `maximumAmount` - a number specifying the maximum value of each UTXO - - `maximumCount` - a number specifying the minimum number of UTXOs - - `minimumSumAmount` - a number specifying the minimum sum value of all UTXOs - -- The `getmempoolancestors`, `getmempooldescendants`, `getmempooolentry` and `getrawmempool` RPCs no longer return `startingpriority` and `currentpriority`. See [Removal of Coin Age Priority](#removal-of-coin-age-priority). - -- The `dumpwallet` RPC now returns the full absolute path to the dumped wallet. (it - used to return no value, even if successful (See [PR 9740](https://github.com/bitcoin/bitcoin/pull/9740)). - -- In the `getpeerinfo` RPC, the return object for each peer now returns an `addrbind` member, which contains the ip address and port of the connection to the peer. This is in addition to the `addrlocal` member which contains the ip address and port of the local node as reported by the peer (See [PR 10478](https://github.com/bitcoin/bitcoin/pull/10478)). - -- The `disconnectnode` RPC can now disconnect a node specified by node ID (as well as by IP address/port). To disconnect a node based on node ID, call the RPC with the new `nodeid` argument (See [PR 10143](https://github.com/bitcoin/bitcoin/pull/10143)). - -- The second argument in `prioritisetransaction` has been renamed from `priority_delta` to `dummy` since Bitcoin Core no longer has a concept of coin age priority. The `dummy` argument has no functional effect, but is retained for positional argument compatibility. See [Removal of Coin Age Priority](#removal-of-coin-age-priority). - -- The `resendwallettransactions` RPC throws an error if the `-walletbroadcast` option is set to false (See [PR 10995](https://github.com/bitcoin/bitcoin/pull/10995)). - -- The second argument in the `submitblock` RPC argument has been renamed from `parameters` to `dummy`. This argument never had any effect, and the renaming is simply to communicate this fact to the user (See [PR 10191](https://github.com/bitcoin/bitcoin/pull/10191)) - (Clients should, however, use positional arguments for `submitblock` in order to be compatible with BIP 22.) - -- The `verbose` argument of `getblock` has been renamed to `verbosity` and now takes an integer from 0-2. Verbose level 0 is equivalent to `verbose=false`. Verbose level 1 is equivalent to `verbose=true`. Verbose level 2 will give the full transaction details of each transaction in the output as given by `getrawtransaction`. The old behavior of using the `verbose` named argument and a boolean value is still maintained for compatibility. - -- Error codes have been updated to be more accurate for the following error cases (See [PR 9853](https://github.com/bitcoin/bitcoin/pull/9853)): - - `getblock` now returns RPC_MISC_ERROR if the block can't be found on disk (for - example if the block has been pruned). Previously returned RPC_INTERNAL_ERROR. - - `pruneblockchain` now returns RPC_MISC_ERROR if the blocks cannot be pruned - because the node is not in pruned mode. Previously returned RPC_METHOD_NOT_FOUND. - - `pruneblockchain` now returns RPC_INVALID_PARAMETER if the blocks cannot be pruned - because the supplied timestamp is too late. Previously returned RPC_INTERNAL_ERROR. - - `pruneblockchain` now returns RPC_MISC_ERROR if the blocks cannot be pruned - because the blockchain is too short. Previously returned RPC_INTERNAL_ERROR. - - `setban` now returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the supplied IP address - or subnet is invalid. Previously returned RPC_CLIENT_NODE_ALREADY_ADDED. - - `setban` now returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the user tries to unban - a node that has not previously been banned. Previously returned RPC_MISC_ERROR. - - `removeprunedfunds` now returns RPC_WALLET_ERROR if `bitcoind` is unable to remove - the transaction. Previously returned RPC_INTERNAL_ERROR. - - `removeprunedfunds` now returns RPC_INVALID_PARAMETER if the transaction does not - exist in the wallet. Previously returned RPC_INTERNAL_ERROR. - - `fundrawtransaction` now returns RPC_INVALID_ADDRESS_OR_KEY if an invalid change - address is provided. Previously returned RPC_INVALID_PARAMETER. - - `fundrawtransaction` now returns RPC_WALLET_ERROR if `bitcoind` is unable to create - the transaction. The error message provides further details. Previously returned - RPC_INTERNAL_ERROR. - - `bumpfee` now returns RPC_INVALID_PARAMETER if the provided transaction has - descendants in the wallet. Previously returned RPC_MISC_ERROR. - - `bumpfee` now returns RPC_INVALID_PARAMETER if the provided transaction has - descendants in the mempool. Previously returned RPC_MISC_ERROR. - - `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has - has been mined or conflicts with a mined transaction. Previously returned - RPC_INVALID_ADDRESS_OR_KEY. - - `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction is not - BIP 125 replaceable. Previously returned RPC_INVALID_ADDRESS_OR_KEY. - - `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has already - been bumped by a different transaction. Previously returned RPC_INVALID_REQUEST. - - `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction contains - inputs which don't belong to this wallet. Previously returned RPC_INVALID_ADDRESS_OR_KEY. - - `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has multiple change - outputs. Previously returned RPC_MISC_ERROR. - - `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has no change - output. Previously returned RPC_MISC_ERROR. - - `bumpfee` now returns RPC_WALLET_ERROR if the fee is too high. Previously returned - RPC_MISC_ERROR. - - `bumpfee` now returns RPC_WALLET_ERROR if the fee is too low. Previously returned - RPC_MISC_ERROR. - - `bumpfee` now returns RPC_WALLET_ERROR if the change output is too small to bump the - fee. Previously returned RPC_MISC_ERROR. - Credits ======= Thanks to everyone who directly contributed to this release: -- ロハン ダル -- Ahmad Kazi -- aideca -- Akio Nakamura -- Alex Morcos -- Allan Doensen -- Andres G. Aragoneses -- Andrew Chow -- Awemany -- Bob McElrath -- Brian McMichael -- BtcDrak -- Charlie Lee -- Chris Gavin -- Chris Stewart -- Cory Fields -- CryptAxe -- Dag Robole -- Daniel Aleksandersen -- Daniel Cousens -- darksh1ne -- Dimitris Tsapakidis -- Eric Shaw Jr -- Evan Klitzke -- fanquake -- Felix Weis -- flack -- Greg Griffith -- Gregory Maxwell -- Gregory Sanders -- gubatron -- Ian Kelling -- Jack Grigg -- James Evans -- James Hilliard -- Jameson Lopp -- Jeremy Rubin -- Jimmy Song -- João Barbosa -- Johnathan Corgan -- John Newbery -- Jonas Schnelli -- jonnynewbs -- Jorge Timón -- Kalle Alm -- Karl-Johan Alm -- Kewde -- keystrike -- KibbledJiveElkZoo -- Kibbled Jive Elk Zoo -- kirit93 -- kobake -- Kyle Honeycutt -- Lawrence Nahum -- Luke Dashjr -- Marco Falke -- Marcos Mayorga -- Marijn Stollenga -- Mario Dian -- Mark Friedenbach -- Marko Bencun -- Masahiko Hyuga -- Matt Corallo -- Matthew Zipkin -- Matthias Grundmann -- Michael Goldstein -- Michael Rotarius -- Mikerah -- Mike van Rossum -- Mitchell Cash -- NicolasDorier -- Nicolas Dorier -- Patrick Strateman -- Pavel Janík -- Pavlos Antoniou -- Pavol Rusnak -- Pedro Branco -- Peter Todd -- Pieter Wuille -- practicalswift -- René Nyffenegger -- Ricardo Velhote -- romanornr -- Russell Yanofsky -- Rusty Russell -- Ryan Havar -- shaolinfry -- Shigeya Suzuki -- Simone Madeo -- Spencer Lievens -- Steven D. Lander -- Suhas Daftuar -- Takashi Mitsuta -- Thomas Snider -- Timothy Redaelli -- tintinweb -- tnaka -- Warren Togami -- Wladimir J. van der Laan As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/). diff --git a/doc/zmq.md b/doc/zmq.md index 1019ff6653..38c58fb7fd 100644 --- a/doc/zmq.md +++ b/doc/zmq.md @@ -72,7 +72,7 @@ For instance: Each PUB notification has a topic and body, where the header corresponds to the notification type. For instance, for the notification `-zmqpubhashtx` the topic is `hashtx` (no null -terminator) and the body is the hexadecimal transaction hash (32 +terminator) and the body is the transaction hash (32 bytes). These options can also be provided in bitcoin.conf. |