23.0.0

Release Notes for Bitcoin Cash Node version 23.0.0

Bitcoin Cash Node version 23.0.0 is now available from:

https://bitcoincashnode.org

Overview

This is a major release of Bitcoin Cash Node (BCHN) that implements the May 15, 2021 Network Upgrade. This upgrade will remove the unconfirmed chain limit and enable transactions with multiple OP_RETURN outputs.

This version contains many corrections and improvements, such as:

• Introducing the Double Spend Proof (beta) feature compatible with other clients
• Removing the limits on number of unconfirmed ancestors and descendants, and the limits on the byte size of these chains
• Raising the default soft limit for block generation to 8MB
• Adding support for multiple OP_RETURN standardness (within existing data carrier size)
• Removal of CPFP functionality
• Changes in mempool eviction order
• New ZMQ functionality (related to dsproof)
• Minor RPC additions and changes (incl. dsproof related)
• Minor changes in error codes
• Improving the graphical user interface
• Extension of software expiry timeframe (to 15 May 2022)
• Switch from C++14 to C++17

Users who are running any of our previous releases (0.22.x) are urged to upgrade to v23.0.0 ahead of May 2021.

Usage recommendations

The update to Bitcoin Cash Node 23.0.0 is required for the May 15, 2021 Bitcoin Cash network upgrade.

About the CPFP & unconfirmed chain limit removal

The CPFP (child-pays-for-parent) and the unconfirmed transaction chain limit will both be deactivated on May 15, 2021 when MTP of the chain tip reaches 12:00 UTC. After that time, it will be possible to "chain" unconfirmed transactions beyond the current limit of 50, in a limitless way, without any negative performance consequence for the node.

This has been accomplished by removing the algorithmically complex and slow code we inherited from Bitcoin Core which tries to maintain what is known as "Child Pays for Parent" (CPFP) -- a way in which a child transaction can bump up the priority of its parent transaction via paying a larger fee. Maintaining this feature, which is not even being used on BCH, was the reason for the algorithmic complexity in the mempool code and why we had a limit of 50 for unconfirmed tx chains.

Additionally, we removed a lot of the slow "quadratic" (complex) per-tx stats that were being maintained (also inherited from Core, and also used in fee calculations). Removing those stats, which only were added so that Core could limit the blocksize and also get a hyper-fee-market, allowed us to unleash the true scalability of BCH. The mempool code was slow -- and it was only slow because of Bitcoin Core's philosophy about what Bitcoin should be.

One might wonder if allowing limitless unconfirmed transaction chains opens up avenues of attack or flood/DoS. It does not do this. Since now our mempool and mining algorithm is linear and not quadratic, there is no real difference between a transaction that has an unconfirmed parent and one that does not. They both now cost the same amount of CPU time to process (and in some cases the unconfirmed parent tx is actually faster to process due to not needing to hit the UTXO db).

Should some user perform a (costly) attack and flood the network with unconfirmed tx chains, the only consequence will be that he will drain his own resources in fees. Under mempool pressure, normal fee bump logic occurs. Transactions get evicted in a "lowest fee first" order and then the mempool's minimum fee for acceptance is bumped up by some small increment. This logic has always been in place and is the way we prevent floods.

In summary, removing the unconfirmed tx chain limit does not impact performance and/or availability whether under normal usage or under congestion.

Network changes

The dsproof-beta network message can be emitted and relayed when Double Spend Proofs are enabled (which they are by default).

For miners/pools running without a blockmaxsize configuration, the default soft limit of generated blocks will increase from 2MB to 8MB in this update. The default hard limit of 32MB remains unchanged in this release.

Added functionality

Double Spend Proofs (DSProof)

This release adds Double Spend Proofs that are compatible with the published dsproof-beta message specification and existing implementations in Bitcoin Unlimited and Flowee The Hub.

Double spend proofs are enabled by default, but can be turned off with the doublespendproof=0 configuration setting.

This functionality is still in beta. In future BCHN releases we plan to gradually add more application interfaces to query double spend proof information about transactions and to provide wallet user with double spend notifications.

Please refer to <doc/dsproof-implementation-notes.md> for more information details on the DSProof implementation in BCHN, and the sections on New RPC methods and New ZeroMQ notifications below for a listing of the new API calls.

maxgbttime and maxinitialgbttime configuration options

These two new command-line options may be of interest to miners (pools). They enable setting maximum time limits for getblocktemplate calls, instead of relying on blockmaxsize limits to limit the time taken to construct a template.

The -maxinitialgbttime setting determines the maximum number of milliseconds that can be spent adding transactions to block templates for the first template after an UpdateTip, whereas the -maxgbttime setting does the same thing but for all block templates
(not just the first).

This should allow pools to create larger block sizes on average without taking on significantly greater costs and risks.

The default settings for -max*gbttime are both 0 in this release, so it has no effect on node behavior when the default options are used.

-rejectsubversion configuration option

This can be used to reject peers which have certain fixed strings in their user agents. Useful for blocking non-compatible SV and ABC
peers. The option can be specified multiple times to filter several matches.

Example:

bitcoind -rejectsubversion="Bitcoin SV" -rejectsubversion="Bitcoin ABC"

Care should be taken to filter out only peers which are definitely not useful to your Bitcoin Cash node.

Deprecated functionality

In the getmempoolentry RPC call, the verbose modes of the getrawmempool/getmempoolancestors/getmempooldescendants RPC calls, and the JSON mode of the mempool REST call, the height field is deprecated and will be removed in a subsequent release. This field indicates the block height upon mempool acceptance.

The bip125-replaceable field in the result of gettransaction is deprecated and will be removed in a subsequent release.

The arc lint linting is considered deprecated and developers should use the ninja check-lint target instead.

Modified functionality

Mempool expiry works slightly differently now. Previously, the expiry of an old mempool tx would be checked thoroughly every time a new tx was accepted to the mempool, but this consumed a bit of extra memory to accomplish precisely and efficiently. Instead, we save on memory by doing a fast (imprecise) check each time a new tx is added to the mempool. This check may miss some txs that should be expired. In order to catch those txs, we now also run a perfect (slower) expiry check of the mempool periodically. A new CLI arg, -mempoolexpirytaskperiod= was added to control the frequency of this thorough check (in hours). The new argument's default value is "24" (once per day).

Removed functionality

Manpages are no longer available in the autotools build system. You must switch to the CMake build system to continue using manpages. Note the autotools build system has been deprecated since v22.0.0.

New RPC methods

validateblocktemplate

The 'validateblocktemplate' RPC call has been added. This call checks if a block template would be accepted if the hash solution
were solved. The semantics of this call are the same as on BCHUnlimited from where a substantial portion of this new functionality has been ported. It is intended to be used by services that test compatibility of block generation with BCHN's consensus rules.

getdsproof and getdsprooflist

getdsproof retries more information about a specific double spend proof.

getdsprooflist lists the double spend proofs that are known about transactions in the node's mempool.

Please refer to the documentation pages for getdsproof and getdsprooflist for details about additional arguments and the returned data.

New ZeroMQ (ZMQ) notifications

BCHN can now publish notification of both hashes and full raw double spend proofs generated or accepted by the node.

The notifications can be enabled via the -zmqpubhashds=address and -zmqpubrawds=address configuration options where address must be a valid ZeroMQ endpoint. Please refer to the ZMQ API documentation for further details.

Low-level 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.

In the getmempoolentry RPC call, the verbose modes of the getrawmempool/getmempoolancestors/getmempooldescendants RPC calls, and the JSON mode of the mempool REST call, the fields fee and modifiedfee are removed. These fields were deprecated since v0.20.4. Please use the fees subobject instead.

The (non-default) option in the getnetworkhashps RPC call to calculate average hashrate using "blocks since last difficulty change" has been re...

22.2.0

Release Notes for Bitcoin Cash Node version 22.2.0

Bitcoin Cash Node version 22.2.0 is now available from:

https://bitcoincashnode.org

Overview

This is a minor release of Bitcoin Cash Node that implements some interface enhancements and includes a number of other corrections and improvements.

Users who are running any of our previous releases are recommended to upgrade to v22.2.0 as part of regular maintenance.

Usage recommendations

Installing this version is optional, but we strongly recommend that users of 22.1.0 upgrade to this release for the corrections, performance improvements and post-upgrade checkpoints contained in it.

Network changes

Policy has been changed to enforce standard transactions on testnet4. This is to have a test network that is close to mainnet.
If you wish to experiment with non-standard transactions, please use testnet3 or scalenet.

This release reduces the interval between INV announcements (and introduces a new command-line configurable option, -txbroadcastinterval, with millisecond resolution. The default value is set to 500 ms for incoming connections (and half that for outgoing) instead of 5 seconds incoming (2 sec outgoing).

The rate at which new INV messages are broadcast has important implications for scalability.

In order to mitigate spam attacks, the node will limit the rate at which new transaction invs are broadcast to each peer. The default is to limit this to 7 tx/sec per MB of excessive block size. That is, with a 32 MB blocksize limit, no more than 224 tx INVs are allowed
to be broadcast each second. The broadcast rate limit is adjustable through the -txbroadcastrate configuration option.

Change of -maxmempool default value

The default value for -maxmempool has been changed to 10 times the excessiveblocksize, i.e. 320 MB on mainet and 2560 MB on scalenet. If your node does not have sufficient free memory to accommodate such a maxmempool setting when running on scalenet, we recommend to upgrade your memory capacity or override this default.

Added functionality

Configurable transaction broadcast interval and rate

Two new configuration have been added which control the INV broadcast interval and rate, with millisecond resolution.

These options have important impact on user experience and scalability, and have been configured with settings that improve on the previous conditions.

For more information on these impact of these options, please refer to the detailed description in:

https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/merge_requests/746

Thread names in logs

Log lines can be prefixed with the name of the thread that caused the log. To enable this behavior, use-logthreadnames=1.

Deprecated functionality

The getnetworkhashps RPC has an option to calculate average hashrate "since last difficulty change". This option works incorrectly, assuming that difficulty changes every 2016 blocks. The option is considered irrelevant with the per-block DAA adjustments introduced in 2017 and is scheduled for removal in a future release.

Removed functionality

No functionality is removed in this release.

New RPC methods

No new RPC methods are added in this release,

Low-level 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.

A discrepancy was noticed in the argument and result value names of getexcessiveblock and setexcessiveblock RPC calls between the interface documentation, actual required argument names, error message and name of returned result. A two-step procedure will be followed to correct this.

1. In this release, the RPC help and error messages for the setexcessiveblock command have been corrected to maxBlockSize to align the name of the argument, previously blockSize, with the name required when the "named argument" form of the call is used.

2. In a future release, the parameter name maxBlockSize introduced by this version will be renamed to 'excessiveBlockSize' in order to make it the same as the result value of the getexcessiveblock RPC call.

Regressions

Bitcoin Cash Node 22.2.0 does not introduce any known regressions compared to 22.1.0.

Known Issues

Some issues could not be closed in time for release, but we are tracking all of them on our GitLab repository.

• MacOS versions earlier than 10.12 are no longer supported. Additionally, Bitcoin Cash Node does not yet change appearance when macOS "dark mode" is activated.

• Windows users are recommended not to run multiple instances of bitcoin-qt or bitcoind on the same machine if the wallet feature is enabled. There is risk of data corruption if instances are configured to use the same wallet folder.

• Some users have encountered unit tests failures when running in WSL environments (e.g. WSL/Ubuntu). At this time, WSL is not considered a supported environment for the software. This may change in future. The functional failure on WSL is tracked in Issue #33. It arises when competing node program instances are not prevented from opening the same wallet folder. Running multiple program instances with the same configured walletdir could potentially lead to data corruption. The failure has not been observed on other operating systems so far.

• doc/dependencies.md needs revision (Issue #65).

• test_bitcoin can collide with temporary files if used by more than one user on the same system simultaneously. (Issue #43)

• For users running from sources built with BerkeleyDB releases newer than the 5.3 which is used in this release, please take into consideration the database format compatibility issues described in Issue #34. When building from source it is recommended to use BerkeleyDB 5.3 as this avoids wallet database incompatibility issues with the official release.

• There is a documentation build bug that causes some ordered lists on docs.bitcoincashnode.org to be rendered incorrectly (Issue #141).

• The test_bitcoin-qt test executable fails on Linux Mint 20 (see Issue #144). This does not otherwise appear to impact the functioning of the BCHN software on that platform.

• An 'autotools' build (the old build method) fails on OSX when using Clang. (Issue #129)

• With a certain combination of build flags that included disabling the QR code library, a build failure was observed where an erroneous linking against the QR code library (not present) was attempted (Issue #138).

• The 'autotools' build is known to require some workarounds in order to use the 'fuzzing' build feature (Issue #127).

• Some functional tests are known to fail spuriously with varying probability. (see e.g. Issue #148, and a fuller listing in #162).

• Possible out-of-memory error when starting bitcoind with high excessiveblocksize value (Issue #156)

• There are obstacles building the current version on Ubuntu 16.04 (see #187). These are worked around by our packaging system, but users trying to build the software from scratch are advised to either upgrade to more recent Ubuntu, or retrofit the necessary toolchains and perform the same build steps for Xenial as registered in our packaging repository, or build in a VM using the gitian build instructions, or run our reproducible binary release builds.

• The getnetworkhashps RPC call is not adapted to per-block DAA (see #193). It has an option to calculate average hashrate "since last difficulty change" and wrongly assumes difficulty changes every 2016 blocks. This irrelevant option will likely be removed in the next release.

• A problem was observed on scalenet where nodes would sometimes hang for around 10 minutes, accepting RPC connections but not responding to them (see #210).

• arc lint will advise that some src/ files are in need of reformatting or contain errors. This is because code style checking is currently a work in progress while we adjust it to our own project requirements (see Issue #75). One file in doc also violates the lint tool (Issue #153), and a new script in test/benchmark/ likewise contains code that is flagged by the current linting configuration. There are also RPC parameter type inconsistencies that flag linting checks (see #182).

---

Changes since Bitcoin Cash Node 22.1.0

New documents

None.

Removed documents

None.

Notable commits grouped by functionality

Security or consensus relevant fixes

• ab6226a Add checkpoints for Axion activation on Bitcoin Ca...

22.1.0

Release Notes for Bitcoin Cash Node version 22.1.0

Bitcoin Cash Node version 22.1.0 is now available from:

https://bitcoincashnode.org

Overview

This is a minor release of Bitcoin Cash Node that implements some interface enhancements and includes a number of other corrections and improvements.

Users who are running any of our previous releases are recommended to upgrade to v22.1.0 ahead of November 2020.

We remind that the 0.21.x family of BCHN releases does not implement the new rules for the coming November 2020 upgrade. Users must upgrade to a release in the 22.x family before November 15th, 2020.

Usage recommendations

Installing this version is optional, but we recommend that users of 22.0.0 upgrade to this minor release for the corrections contained in it.

This update is compatible with the November 15, 2020 Bitcoin Cash network upgrade.

Network changes

New test network options.

This release delivers the ability to access two new test networks:

• testnet4 (more lightweight test network to be kept spam-free)
• scalenet (for high-throughput tests, including at block sizes beyond
  current main network maximum)

Please refer to doc/test-networks.md or https://docs.bitcoincashnode.org/doc/test-networks/ for further information.

New seeder configuration

Added configuration to access new DNS seeders from loping.net and a new electroncash.de mainnet seeder.

• dnsseed.electroncash.de (mainnet)
• seed.bch.loping.net (mainnet)
• seed.tbch.loping.net (testnet3)
• seed.tbch4.loping.net (testnet4)
• seed.sbch.loping.net (scalenet)

Removed the defunct seeder entry deadalnix.me.

Added functionality

extversion

This release implements the 'extversion' extended versioning handshake protocol (ref. BCHN merge requests !558 and !753), previously implemented by Bitcoin Unlimited. We thank Greg Griffith and the Bitcoin Unlimited developers for their efforts to achieve this implementation in BCHN.

The extversion handshaking is disabled by default and can be enabled using the -useextversion CLI argument or the useextversion=1 configuration file setting.

Nodes indicate extversion support by setting service bit 11 (EXTVERSION).

Right now the BCHN implementation of ExtVersion supports only 1 key -- the "Version" key.

The specification can be found in doc/xversionmessage.md or at https://docs.bitcoincashnode.org/doc/xversionmessage/ .

indexdir

A new indexdir configuration option allows the user to specify a path under which the leveldb 'index' folder is stored.

The use case for this new option is to store the index on a separate volume of faster access media while the blocks can be stored on slower media.

If the argument is not specified, the index is stored in the usual place (in the blocks/index/ folder).

finalizeheaders

A new finalizeheaders configuration option (enabled by default) rejects block headers which are below the finalized block height (if a block has indeed been finalized already).

Finalized blocks are not supposed to be re-organized under any circumstances (just like checkpointed blocks). There is therefore no need to accept headers for alternate chains below the last finalized block.

Nodes which submit such blocks are penalized according to a penalty score determined by the finalizeheaderspenalty option (default is 100, meaning such nodes will be disconnected).

In practice this works to quickly disconnect nodes from old chains like the "Clashic" network which sometimes submit headers of forked off chains with vastly lower block heights.

New debugging tracepoints

Two new debugging tracepoints have been added:

• debug=finalization
• debug=parking

These can be used to log events related to automatic finalization and parking/unparking.

Deprecated functionality

No functionality is deprecated in this release.

Removed functionality

No functionality is removed in this release.

New RPC methods

No new RPC methods are added in this release, however some argument aliases are added to existing calls (for backward compatibility) and a new optional parameter is added to the sendtoaddress method (for improved coin selection performance).

Low-level RPC changes

An optional coin selection ('coinsel') argument has been added to the sendtoaddress RPC method.

An alias blockhash has been added for the hash_or_height parameter of the getblockheader call, for backward compatibility.

An alias dummy has been added for the parameters argument of the submitblock call, for backward compatibility.

Regressions

Bitcoin Cash Node 22.1.0 does not introduce any known regressions compared to 22.0.0.

Known Issues

Some issues could not be closed in time for release, but we are tracking all of them on our GitLab repository.

• MacOS versions earlier than 10.12 are no longer supported. Additionally,
  Bitcoin Cash Node does not yet change appearance when macOS "dark mode"
  is activated.

• Windows users are recommended not to run multiple instances of bitcoin-qt
  or bitcoind on the same machine if the wallet feature is enabled.
  There is risk of data corruption if instances are configured to use the same
  wallet folder.

• Some users have encountered unit tests failures when running in WSL
  environments (e.g. WSL/Ubuntu). At this time, WSL is not considered a
  supported environment for the software. This may change in future.

  The functional failure on WSL is tracked in Issue #33.
  It arises when competing node program instances are not prevented from
  opening the same wallet folder. Running multiple program instances with
  the same configured walletdir could potentially lead to data corruption.
  The failure has not been observed on other operating systems so far.

• doc/dependencies.md needs revision (Issue #65).

• arc lint will advise that some src/ files are in need of reformatting
  or contain errors. - this is because code style checking is currently a work in
  progress while we adjust it to our own project requirements (see Issue #75).
  One file in doc also violates the lint tool (Issue #153), and a new
  script in test/benchmark/ likewise contains code that is flagged by
  the current linting configuration.

• test_bitcoin can collide with temporary files if used by more than
  one user on the same system simultaneously. (Issue #43)

• For users running from sources built with BerkeleyDB releases newer than
  the 5.3 which is used in this release, please take into consideration
  the database format compatibility issues described in Issue #34.
  When building from source it is recommended to use BerkeleyDB 5.3 as this
  avoids wallet database incompatibility issues with the official release.

• There is a documentation build bug that causes some ordered lists on
  docs.bitcoincashnode.org to be rendered incorrectly (Issue #141).

• There is a report that the test_bitcoin-qt test executable fails on
  Linux Mint 20 (see Issue #144). This does not otherwise appear to impact
  the functioning of the BCHN software on that platform.

• An 'autotools' build (the old build method) fails on OSX when using Clang.
  (Issue #129)

• With a certain combination of build flags that included disabling
  the QR code library, a build failure was observed where an erroneous
  linking against the QR code library (not present) was attempted (Issue #138).

• The 'autotools' build is known to require some workarounds in order to
  use the 'fuzzing' build feature (Issue #127).

• Some functional tests are known to fail spuriously with varying probability.
  (see e.g. Issue #148, and a fuller listing in #162).

• Possible out-of-memory error when starting bitcoind with high excessiveblocksize
  value (Issue #156)

---

Changes since Bitcoin Cash Node 22.0.0

New documents

• doc/test-networks.md : an overview of the test networks supported by BCHN

Removed documents

None.

Notable commits grouped by functionality

Network fixes

No changes.

Interfaces / RPC

• 3379ccd Fix getblocktemplate sigop/blocksize limits to reflect -excessiveblocksize setting
• 558a4a3 Add -expirerpc to list of intentionally undocumented CLI arguments
• c21c8ee Implement Extversion
• ac8192a Fix to EXTVERSION handshake causing peers to punish each other for misbehavior (simplified)
• ad701aa [rpc] Override error messages in sendtoaddress
• 1e90a52 Add 'finalization' & 'parking' debugging tracepoints
• 5c62505 Add indexdir parameter to bitcoind
• 4466...

22.0.0

Release Notes for Bitcoin Cash Node version 22.0.0

Bitcoin Cash Node version 22.0.0 is now available from:

https://bitcoincashnode.org

Overview

This is a major release of Bitcoin Cash Node that implements the November 15, 2020 Network Upgrade. This will upgrade the difficulty targeting used in Bitcoin Cash to a commonly agreed new algorithm called ASERT.

Additionally, this version contains many corrections and improvements.

User who are running any of our previous releases (0.21.x) are urged to upgrade to v22.0.0 well ahead of November 2020.

Usage recommendations

The update to Bitcoin Cash Node 22.0.0 is required for the November 15, 2020 Bitcoin Cash network upgrade.

Semantic version numbering

As of version 22.0.0, Bitcoin Cash Node uses Semantic Versioning for its version numbers. Hence our version numbers no longer start with a zero.

Semantic versioning makes it easy to tell from the change in version number what are the impacts on interfaces and backward compatibility:

• A major version (first number) change indicates that an interface changed in a way that makes the new software incompatible with older releases.

• A minor version change indicates added functionality that is backwards compatible.

• A patch version (third number) change indicates that a new release only contains bug fixes which are backward compatible.

Network changes

Changes to automatic banning

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

• Automatic bans are now referred to as "discouraged" in log output, as
  they're not (and weren't even before) strictly banned: incoming connections
  are still allowed from them (as was the case before this change), but they're
  preferred for eviction.

• Automatic bans will no longer time-out automatically after 24 hours.
  Depending on traffic from other peers, automatic bans may time-out at an
  indeterminate time.

• Automatic bans will no longer be persisted across restarts. Only manual bans
  will be persisted.

• Automatic bans will no longer be returned by the listbanned RPC.

• Automatic bans can no longer be lifted with the setban remove RPC command.
  If you need to remove an automatic ban, you must clear all automatic bans with
  the clearbanned false true RPC command, or restart the software to clear
  automatic bans.

• All extant automatic bans ("node misbehaving") that are currently stored in the
  node's banlist.dat file will be converted into "manual bans" and will expire
  within 24 hours after first running this version of BCHN.

Regtest network now requires standard transactions by default

The regression test chain, that can be enabled by the -regtest command line flag, now requires transactions to not violate standard policy by default. Making the default the same as for mainnet, makes it easier to test mainnet behavior on regtest. Be reminded that the testnet still allows non-standard
txs by default and that the policy can be locally adjusted with the -acceptnonstdtxn command line flag for both test chains.

Graceful expiration of this version on May 15, 2021

A mechanism has been added to this version such that it will gracefully expire on May 15, 2021, at the time of the network upgrade which is tentatively scheduled to occur then. Once this software expires, the RPC subsystem will disallow RPC commands. This feature can be disabled with the -expire=0 option. Furthermore, the date of expiration can be altered with the -tachyonactivationtime=<n> option.

This feature has been added as a safety measure to prevent this version of the node software from mining or otherwise transacting on an incompatible chain, should an upgrade take place on May 15th, 2021. This version will begin to warn via RPC "warnings", via a GUI message, and via periodic messages to the log starting 30 days prior to May 15th, 2021.

Once the future consensus rules of the May 15th, 2021 upgrade to the Bitcoin Cash network have been determined, a new version of Bitcoin Cash Node will be made available well in advance of May 15th, 2021. It is recommended that all users of Bitcoin Cash Node update their nodes at that time so as to ensure
uninterrupted operation.

Related configuration options:

• -expire: Specify expire=0 in the configuration file or -expire=0 on the CLI to disable the aforementioned graceful expiration mechanism (default: 1).

• -tachyonactivationtime=<n>: This option controls when the expiration mechanism (if enabled) will expire the node and disable RPC ( seconds since epoch, default: 1621080000).

Deprecated functionality

Autotools build system

The autotools build system (autogen, configure, ...) is deprecated and will be removed in a future release. CMake is the replacement build system, look at the documentation for the build instructions. To continue using the autotools build system, pass the --enable-deprecated-build-system flag to
configure.

CashAddr enabled by default in bitcoin-tx

The bitcoin-tx tool has fully supported CashAddr since v0.21.2. CashAddr in JSON output was disabled by default, but relying on this default was deprecated. Version 22.0.0 now changes the default to enabled. Specify -usecashaddr=0 to retain the old behavior.

Removed functionality

medianfeerate field removed from getblockstats

The medianfeerate field in getblockstats output has been removed. The 50th percentile from the feerate_percentiles array should be used instead.

-datacarrier removed

The bitcoind/bitcoin-qt option -datacarrier was deprecated in v0.21.2 and has now been removed in v22.0.0. Instead, use the existing option -datacarriersize to control relay and mining of OP_RETURN transactions, e.g. specify -datacarriersize=0 to reject them all.

BIP9 support removed

Bitcoin Cash Node 22.0.0 removed the (incomplete) BIP9 support. In earlier versions, it already was inactive due to no available proposals to vote on. The empty softforks field in getblockchaininfo has been removed.

Prototypical Avalanche removed

The Avalanche prototype features have been removed from this release pending specification and evaluation.

Windows 32-bit build removed

The 32-bit Windows target is no longer supported and has been removed from the release shipment.

Users that wish to build for 32 bits Windows should be aware that this will not be tested by the Bitcoin Cash Node team and be prepared to resolve issues on their own.

New RPC methods

No changes.

Low-level RPC changes

• The sigops and sigoplimit values returned by the getblocktemplate
  and getblocktemplatelight methods are now calculated according to the
  SigChecks specification.

• The clearbanned method now optionally can take two additional boolean
  arguments (both default to true if unspecified). These arguments can be used
  to control whether manual or automatic bans are to be cleared (or both).

• The listbanned method no longer lists automatic bans.

• The listbanned method's results array has changed slightly. All entries
  now have their banned_reason as "manually added" (since listbanned can
  now only ever show manual bans). The "node misbehaving" value for this key
  will never appear. This key is now deprecated and may be removed altogether
  in a future release of BCHN.

• The setban method can no longer lift individual automatic bans. Use
  clearbanned instead to clear all bans, or clearbanned false true to
  clear all automatic bans (while preserving all manual bans).

Regressions

Bitcoin Cash Node 22.0.0 does not introduce any known regressions compared to 0.21.2.

Known Issues

Some issues could not be closed in time for release, but we are tracking all of them on our GitLab repository.

• MacOS versions earlier than 10.12 are no longer supported. Additionally,
  Bitcoin Cash Node does not yet change appearance when macOS "dark mode"
  is activated.

• Windows users are recommended not to run multiple instances of bitcoin-qt
  or bitcoind on the same machine if the wallet feature is enabled.
  There is risk of data corruption if instances are configured to use the same
  wallet folder.

• Some users have encountered unit tests failures when running in WSL
  environments (e.g. WSL/Ubuntu). At this time, WSL is not considered a
  supported environment for the software. This may change in future.

  The functional failure on WSL is tracked in Issue #33.
  It arises when competing node program instances are not prevented from
  opening the same wallet folder. Running multiple program instances with
  the same configured walletdir could potentially lead to data corruption.
  The failure has not been observed on other operating systems so far.

• doc/dependencies.md needs revision (Issue #65).

• arc lint will advise that some src/ files are in need of reformatting or
  contain errors - this is because code style checking is currently a work in
  progress while we adjust it to our own project requirements (see Issue #75).
  One file in doc also violates the lint tool (Issue #153)

• test_bitcoin can collide with temporary files if used by more than
  one user on the same system simultaneously. (Issue #43)

• For users running from sources built with BerkeleyDB releases newer than
  the 5.3 which...

0.21.2

Release Notes for Bitcoin Cash Node version 0.21.2

Bitcoin Cash Node version 0.21.2 is now available from:

https://bitcoincashnode.org

Overview

This release of Bitcoin Cash Node contains many corrections and
improvements that we feel are useful, but it is strictly an optional
installation for those already running previous v0.21.x versions.

Bitcoin Cash Node started as a drop-in replacement for Bitcoin ABC for
the May 2020 network upgrade, to provide an alternative with minimal
changes necessary to disable the Infrastructure Funding Proposal (IFP)
soft forks.

With the network upgrade behind us, Bitcoin Cash Node starts to pursue its
own roadmap of improvement and innovation.

This release delivers performance improvements and a new mining RPC,
the getblocktemplatelight and submitblocklight calls.

GBT Light mining RPC added

Two new light-weight RPC calls were added: getblocktemplatelight and
submitblocklight. These RPCs reduce the round-trip time for mining
software when retrieving new block templates. Transaction data is never
sent between mining software and bitcoind. Instead, job_id's are
returned and bitcoind later reconstructs the full block based on this
job_id and the solved header + coinbase submitted by the miner, leading
to more efficient mining.

A full description and specification for this facility accompanies this
release.

Three new CLI / configuration options were added to manage GBT Light:

• -gbtcachesize=<n> - Specify how many recent getblocktemplatelight
  jobs to keep cached in memory (default: 10). Jobs not in the memory
  cache will be loaded from disk.
• -gbtstoredir=<dir> - Specify a directory for storing
  getblocktemplatelight data (default: <datadir>/gbt/).
• -gbtstoretime=<secs> - Specify time in seconds to keep
  getblocktemplatelight data in the -gbtstoredir before it is
  automatically deleted (0 to disable autodeletion, default: 3600).

As usual, all of the above CLI arguments may also be specified in the
.conf file for the node (but without the preceding - character).

Account API removed

The 'account' API was deprecated in ABC v0.20.6 and has been fully removed
in BCHN v0.21.2.

The 'label' API was introduced in ABC v0.20.6 as a replacement for accounts.

See the release notes from v0.20.6 for a full description of the changes
from the 'account' API to the 'label' API.

CashAddr in bitcoin-tx

The bitcoin-tx tool now has full CashAddr support. CashAddr in JSON output
can be controlled with the new -usecashaddr option, which is turned off
by default, but relying on this default is deprecated. The default will
change to enabled in v0.22. Specify -usecashaddr=0 to retain the old
behavior.

Generation and publishing of Markdown documentation

New scripts have been introduced which convert UNIX manpage documents,
program help outputs (including RPC call help) to Markdown format.
This generated documentation is committed under the doc/cli and
doc/json-rpc folders.

Additionally, the Markdown files in the doc folder are now converted
to HTML via the mkdocs tool (see mkdocs.yml description file in
base folder of the source tree). The generated HTML is deployed to
https://docs.bitcoincash.org .

-datacarrier deprecated

The bitcoind/bitcoin-qt option -datacarrier is deprecated and will be
removed in v0.22. Instead, use the existing option -datacarriersize to
control relay and mining of OP_RETURN transactions, e.g. specify
-datacarriersize=0 to reject them all.

Usage recommendations

The update to Bitcoin Cash Node 0.21.2 is optional.

We recommend Bitcoin Cash Node 0.21.2 as a replacement for
Bitcoin ABC 0.21.x

MacOS versions earlier than 10.12 are no longer supported.
Additionally, Bitcoin Cash Node does not yet change appearance when macOS
"dark mode" is activated.

Windows users are recommended not to run multiple instances of bitcoin-qt
or bitcoind on the same machine if the wallet feature is enabled.
There is risk of data corruption if instances are configured to use the same
wallet folder.

Some users have encountered unit tests failures when running in WSL
environments (e.g. WSL/Ubuntu). At this time, WSL is not considered a
supported environment for the software. This may change in future.

Note regarding BIP9 and getblockchaininfo

BIP9 is inactive due to no available proposals to vote on and it may be
removed in a future release.

New RPC methods

• listwalletdir returns a list of wallets in the wallet directory which is
  configured with -walletdir parameter.
• getblocktemplatelight and submitblocklight are described in the
  dedicated section "GBT Light mining RPC added"

Low-level RPC changes

The -usehd option has been finally removed. It was disabled in version
ABC 0.16. From that version onwards, all new wallets created are
hierarchical deterministic wallets.
Version 0.18 made specifying -usehd invalid config.

Regressions

Bitcoin Cash Node 0.21.2 does not introduce any known regressions compared
to 0.21.1.

Known Issues

Some issues could not be closed in time for release, but we are tracking
all of them on our GitLab repository.

• doc/bips.md needs revision (to be fixed in Issue 68).

• doc/dependencies.md needs revision (to be fixed in Issue 65).

• arc lint will advise that some src/ files are in need of reformatting or
  contain errors - this is because code style checking is currently a work in
  progress while we adjust it to our own project requirements (see Issue 75).

• test_bitcoin can collide with temporary files if used by more than
  one user on the same system simultaneously. (Issue 43)

• We discovered a functional failure in Windows environment under a specific
  condition in Issue 33.
  It arises when competing node program instances are not prevented from
  opening the same wallet folder. Running multiple program instances with
  the same configured walletdir could potentially lead to data corruption.
  The failure has not been observed on other operating systems so far.

• For users running from sources built with BerkeleyDB releases newer than
  the 5.3 which is used in this release, please take into consideration
  the database format compatibility issues described in Issue 34.
  When building from source it is recommended to use BerkeleyDB 5.3 as this
  avoids wallet database incompatibility issues with the official release.

• BCHN project is currently considering improvements to specification and
  RPC outputs related to the SigOps -> SigChecks change that took effect
  on 15 May 2020. (ref. Issues 71, 72)

---

Changes since Bitcoin Cash Node 0.21.1

New documents:

• getblocktemplatelight.md
• publishing-documentation.md
• rapidcheck.md
• doc/cli/ : command line program documentation (manual pages converted to Markdown)
  • bitcoin-cli.md
  • bitcoin-qt.md
  • bitcoin-seeder.md
  • bitcoin-tx.md
  • bitcoind.md
  • bitcoin-seeder.1
• docs/json-rpc/ : RPC API documents (one help file for each call)
  • (complete list of files omitted for brevity)

Removed documents:

• gitian-building-create-vm-fedora.md
• gitian-building-setup-gitian-fedora.md
• translation_strings_policy.md

Notable commits grouped by functionality:

Security or consensus relevant fixes

• No changes

Interfaces / RPC

• fdf771a New RPCs: getblocktemplatelight and submitblocklight
• 01cec0d Accept CashAddr prefixes in bitcoin-tx input
• 918b068 Enable CashAddr by default in all binaries, add -usecashaddr option to bitcoin-tx
• 0669b99 Deprecate -datacarrier CLI option

Peformance optimizations

• c7bd2aa RPC performance enhancement for getmininginfo
• c0ae6e6 Minor performance fix for uint256 (base_blob) type
• dd08df5 Update default assume valid and minimum chain work (chain params) after Phonon activation

GUI

• No changes

Code quality

• 2b9d92e Do not translate any CLI options
• 5f36558 Make -regtest CLI option visible
• ae6d398 Nit help text for CLI option -help-debug
• bb46f30 Add CLI option -?? as shorthand for -help-debug and make it imply -?/-help/-h
• 26a79e8 Nits for -acceptnonstdtxn and -debuglogfile help texts
• 6965dcf Rename lis...

0.21.1

Release Notes for Bitcoin Cash Node version 0.21.1

Bitcoin Cash Node version 0.21.1 is now available from:

https://bitcoincashnode.org

Overview

This is a second, minor release of Bitcoin Cash Node before the May 2020
network upgrade. While it contains many corrections and improvements that
we feel are useful, it is not a required installation for the May 2020
network upgrade.

Bitcoin Cash Node is a drop-in replacement for Bitcoin ABC.
It is based on Bitcoin ABC 0.21.0, with minimal changes necessary to
disable the Infrastructure Funding Proposal (IFP) soft forks.
For exchanges and users, this client will follow the longest chain whether
it includes IFP soft forks or not. For miners, running this client ensures
the getblocktemplate RPC call will return a block with version bits that
vote "NO" for the IFP soft forks. Additionally, unlike Bitcoin ABC,
getblocktemplate will not automatically insert IFP white-list addresses
into the coinbase transaction.

This release contains one security fix and one correction which has been
identified as potentially relevant to consensus.

Security fix

This release contains a patch for a denial-of-service security vulnerability
in CVE-2019-18936 UniValue::read() in UniValue 1.0.3 and 1.0.4 allows a segfault via malformed JSON.

Attackers with limited JSON RPC access could exploit this vulnerability to
crash the node with a malicious JSON RPC instruction. Attackers with full
JSON RPC access do not need to exploit - they would be able to simply stop
a node. Attackers without JSON RPC access cannot exploit this vulnerability.
As a mitigation, untrusted inputs can be sanitised before sending them on
to the JSON RPC server. Note that the "malformed" JSON is technically valid,
just deeply nested. Upstream fix first released in Bitcoin Core 0.19.1.

Consensus-relevant fix

The backport of D4936 from Bitcoin ABC ("update 'cousins' during UpdateFlags")
corrects a problem where some blocks incorrectly retained invalid markings when
reconsiderblock was called.

This is a not a consensus change that affects unattended operation, but
it can be relevant in certain operational and maintenance scenarios.

Usage recommendations

We recommend Bitcoin Cash Node 0.21.1 as a drop-in replacement for
Bitcoin ABC 0.21.0.

The update from Bitcoin Cash Node 0.21.0 to 0.21.1 is optional.
Either version will work for May 2020 network upgrade.

Windows users are recommended not to run multiple instances of bitcoin-qt
or bitcoind on the same machine if the wallet feature is enabled.
There is risk of data corruption if instances are configured to use the same
wallet folder.

Some users have encountered unit tests failures when running in WSL
environments (e.g. WSL/Ubuntu). At this time, WSL is not considered a
supported environment for the software. This may change in future.

Note regarding BIP9 and getblockchaininfo

BIP9 is inactive due to no available proposals to vote on and it may be
removed in a future release.

Regressions

Bitcoin Cash Node 0.21.1 does not introduce any known regressions compared
to 0.21.0.

Known Issues

Some issues could not be closed in time for release, but we are tracking
all of them on our GitLab repository.

• doc/bips.md needs revision (to be fixed in Issue 68).

• doc/dependencies.md needs revision (to be fixed in Issue 65).

• arc lint will advise that some src/ files are in need of reformatting or
  contain errors - this is because code style checking is currently a work in
  progress while we adjust it to our own project requirements (see Issue 75).

• test_bitcoin can collide with temporary files if used by more than
  one user on the same system simultaneously. (Issue 43)

• A functional failure in Windows environment was observed in Issue 33.
  It arises when competing node program instances are not prevented from
  opening the same wallet folder. Running multiple program instances with
  the same configured walletdir could potentially lead to data corruption.
  The failure has not been observed on other operating systems so far.

• For users running from sources built with BerkeleyDB releases newer than
  the 5.3 which is used in this release, please take into consideration
  the database format compatibility issues described in Issue 34.
  When building from source it is recommended to use BerkeleyDB 5.3 as this
  avoids wallet database incompatibility issues with the official release.

• BCHN project is tracking some ongoing discussions related to details of the
  SigChecks specification and the output of getblocktemplate RPC call after
  the May upgrade (ref. Issues 71, 72). In the event that software changes
  become necessary we will advise users via our communication channels and
  inform of another minor release before May.

---

Changes since Bitcoin Cash Node 0.21.0

New documents:

• xversionmessage.md : (protocol) xversion / extversion draft specification
• ninja_targets.md : (development) describes build system targets
• bchn-gitlab-usage-rules-and-guidelines.md : (process) rules for working on BCHN
• release-notes/release-notes-0.21.0.md : previous version release notes
• build-unix-arch.md : (build, refactor) split out from build-unix.md
• build-unix-deb.md : (build, refactor) split out from build-unix.md
• build-unix-rpm.md : (build, refactor) split out from build-unix.md

Removed documents:

• gitian-building/gitian-building-mac-os-sdk.md : obsoleted instructions

Notable commits grouped by functionality:

Security or consensus relevant fixes

• 83252d0 [CVE-2019-18936] Pull UniValue subtree from Bitcoin Core
• 5a761db [validation.cpp] update 'cousins' during UpdateFlags (Bitcoin ABC)

Interfaces / RPC

• 0c019c5 Add help text for -parkdeepreorg and -automaticunparking
• 9d36ab1 Make hidden reorg protection RPC commands visible
• d0ed11f getblocktemplate RPC help fixes

Peformance optimizations

• 54d94d1 Don't park blocks when there is no actual reorg
• 4e9a173 The parked block marker, pindexBestParked, is set to null if it is about to be cleared.
• 3be2000 UniValue & RPC Interface: Significant performance improvements
• 472118a UniValue performance speedups for .write()

GUI

• 6ce344f Qt: Fix #47; quirk when switching versions after selecting Satoshi (sats)
• 9f1598b Qt: Set AA_EnableHighDpiScaling before QApplication instance creation
• a512311 Add 'GRAPHENE' and 'CF' GUI labels in nodes' supported services
• bbf89bb New splash screens (#29)
• cd18a55 Decent testnet/regtest logo/icon colours (#27)
• fc3ce07 Dark NSIS installer wizard image
• d0c078b Reorganise main window title (#38)
• b2bf997 Modify Bitcoin Qt desktop file to reflect we are Bitcoin Cash Node

Code quality

• 6786e42 Fix many PVS static analyzer warnings and/or errors
• 38e9fde Fix two compiler warnings (clang 11.0.0)
• 80e4cff sha256_shani.cpp + clang: suppress -Wcast-align warnings
• a40df80 [secp256k1] Remove a warning in multiset test
• 0bc6f69 Mute self assign warning in uint256_tests.cpp
• f7cdc60 [lint] Fix Python script linting transgressions
• 185b3a6 Restore the arcanist configs (revert of 767c572)
• 6c139ae [CMAKE] Factorize the test suite target name construction

Documentation updates

• ff23d72 [doc] Add revised xversion spec (draft) - provided by Greg Griffith (Bitcoin Unlimited)
• 41f2204 d50e0f2 939f729 f67fa40 ae737a6 335cdc0 Update contributing, build, developer and gitian docs
• 86e229c 7dea808 Fix up obsolete ABC references
• aaf8a1d 313ef3a Add confirmed disclosure relationships (BCHD, Flowee, Knuth, Verde)
• 2b2deda 4e61089 Describe correct steps to build and run the benchmarks
• 90be3b5 961b7a3 Update FreeBSD instructions & add info to build bitcoin-qt
• d8129cc [doc] Add BCHN ...

0.21.0

Release Notes for Bitcoin Cash Node version 0.21.0

Bitcoin Cash Node version 0.21.0 is now available from:

https://bitcoincashnode.org

This is the first release of Bitcoin Cash Node as a drop-in replacement for Bitcoin ABC 0.21.0. It is based on Bitcoin ABC 0.21.0, with minimal changes necessary to disable the Infrastructure Funding Proposal (IFP) soft forks. For exchanges and users, this client will follow the longest chain whether it includes IFP soft forks or not. For miners, running this client ensures the getblocktemplate RPC call will return a block with version bits that vote "NO" for the IFP soft forks. Additionally, unlike Bitcoin ABC, getblocktemplate will not automatically insert IFP white-list addresses into the coinbase transaction.

Minimal changes from Bitcoin ABC 0.21.0 to Bitcoin Cash Node 0.21.0:

• All IFP soft fork logic, signaling logic and the hard-coded whitelist have been removed.
• Rebranding from Bitcoin ABC to Bitcoin Cash Node.
• Qt GUI settings are automatically copied from Bitcoin ABC on first use of Bitcoin Cash Node.

Note regarding BIP9 and getblockchaininfo below: BIP9 is inactive due to no available proposals to vote on and it may be removed in a future release.

All other upgrade changes from ABC 0.21.0 are untouched and included below for reference.

---

This release includes the following features and fixes:

• The RPC getrpcinfo returns runtime details of the RPC server.
  At the moment it returns the active commands and the corresponding execution time.
• ischange field of boolean type that shows if an address was used for change output was added to getaddressinfo method response.
• Bump automatic replay protection to Nov 2020 upgrade.
• Re-introduction of BIP9, info available from the getblockchaininfo RPC.
• Various bug fixes and stability improvements.

New RPC methods

• getnodeaddresses returns peer addresses known to this node.
  It may be used to connect to nodes over TCP without using the DNS seeds.

Network upgrade

At the MTP time of 1589544000 (May 15, 2020 12:00:00 UTC) the following behaviors will change:

• The default for max number of in-pool ancestors (-limitancestorcount) is changed from 25 to 50.
• The default for max number of in-pool descendants (-limitdescendantcount) is changed from 25 to 50.
• OP_REVERSEBYTES support in script.
• New SigOps counting method (SigChecks) as standardness and consensus rules.

Usage recommendations

We recommend Bitcoin Cash Node 0.21.0 as a drop-in replacement for ABC 0.21.0.

The files in this release contain some resource links such as email addresses
(e.g. [email protected]) which are still being brought into operation and
may be unavailable for some time after the initial release. We ask for your
patience and will advise when ready via the project's communication channels
(website, Slack, Telegram, Twitter, Reddit).

Regressions

Bitcoin Cash Node 0.21.0 does not introduce any known regressions compared to ABC 0.21.0.