Release Notes v0.17.3
Clone this wiki locally
Binaries and source code will be available from:
The primary purpose of this new minor version release is to increase the safety of the BTG blockchain against deep-chain reversions by introducing rolling checkpoint finalization.
Please report bugs using the issue tracker at GitHub:
v0.17.3 is a simple drop-in replacement for v0.17.1 or v0.17.2. (If you are upgrading from v0.15.2, there are potentially breaking changes due to some deprecated commands and some changes in the bitcoingold.conf file structure; see v0.17.1 release notes, including configuration sections and 'label' and 'account' APIs for wallet.)
For upgrade instructions from prior versions and release notes, please refer to Release Notes v0.17.1.
Wallets created in 0.17.1 and later are not compatible with versions prior to 0.17.1 and will not work if you try to use newly created wallets in older versions. Existing wallets that were created with older versions are not affected by this.
BTG Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.8+, and Windows 10. Windows Vista and later should work, while Windows XP is not supported.
BTG Core should also work on most other Unix-like systems but is not frequently tested on them.
From 0.17.1 onwards macOS <10.10 is no longer supported. 0.17.1 is built using Qt 5.9.x, which doesn't support versions of macOS older than 10.10.
A finalized block is one which the node considers non-replaceable. Any chain of blocks which builds on top of a block deeper than the last finalized block will be rejected. Whenever a new block is validated, the node checks if a prior block is eligible for finalization and, if so, it will mark it finalized.
Default Block Eligibility Requirements:
- depth >= 9 blocks
- age >= 4800 seconds (based on the receiving node's timestamp.)
The majority of the time (>60%), a block will be finalized at 9 blocks deep (for a transaction, that's 10 confirmations), but it may be several blocks deeper depending on chain speed at the time.
- A node receiving a conflicting chain of blocks from the network will not roll back further than the most recently finalized block, preventing deep chain reorganizations.
- Manual changes to the blockchain (via
reconsiderblock) can still cause rollbacks beyond the finalized block.
- Finalization is not persistent between node restarts, meaning a newly restarted node will have no finalized block for at least 4800 seconds.
The new RPC
getfinalizedblock will report the blockhash of the most recent finalized block.