Bitcoin ABC 0.21.9 Release Notes

Bitcoin ABC version 0.21.9 is now available from:

https://download.bitcoinabc.org/0.21.9/

This release includes the following features and fixes:

Wallet changes

When creating a transaction with a fee above -maxtxfee (default 0.1 BCH), the RPC commands walletcreatefundedpsbt and fundrawtransaction will now fail instead of rounding down the fee. Beware that the feeRate argument is specified in BCH per kilobyte, not satoshi per byte.

Coin selection

Reuse Avoidance

A new wallet flag avoid_reuse has been added (default off). When enabled, a wallet will distinguish between used and unused addresses, and default to not use the former in coin selection.

Rescanning the blockchain is required, to correctly mark previously used destinations.

Together with “avoid partial spends” (present as of Bitcoin ABC v0.19.9), this addresses a serious privacy issue where a malicious user can track spends by peppering a previously paid to address with near-dust outputs, which would then be inadvertently included in future payments.

New RPCs

RPC changes

The getblockstats RPC is faster for fee calculation by using BlockUndo data. Also, -txindex is no longer required and getblockstats works for all non-pruned blocks.

Several RPCs have been updated to include an “avoid_reuse” flag, used to control whether already used addresses should be left out or included in the operation. These include:

In addition, sendtoaddress has been changed to avoid partial spends when avoid_reuse avoid_reuse is enabled. is enabled (if not already enabled via the -avoidpartialspends command line flag), as it would otherwise risk using up the “wrong” UTXO for an address reuse case.

The listunspent RPC has also been updated to now include a “reused” bool, for nodes with “avoid_reuse” enabled.

Miscellaneous RPC changes

Configuration

The outbound message high water mark of the ZMQ PUB sockets are now configurable via the options:

-zmqpubhashtxhwm=n

-zmqpubhashblockhwm=n

-zmqpubrawblockhwm=n

-zmqpubrawtxhwm=n

Each high water mark value must be an integer greater than or equal to 0. The high water mark limits the maximum number of messages that ZMQ will queue in memory for any single subscriber. A value of 0 means no limit. When not specified, the default value continues to be 1000. When a ZMQ PUB socket reaches its high water mark for a subscriber, then additional messages to the subscriber are dropped until the number of queued messages again falls below the high water mark value.

Change in automatic banning

Automatic banning of peers for bad behavior has been slightly altered: