Stacks Blockchain Versions Save

2.3.0.0.0 Tx and read-only calls to functions with traits as parameters are rejected with unchecked TypeValueError. Additional context and rationale can be found in SIP-023.

This release is compatible with chainstate directories from 2.1.0.0.x.

2.2.0.0.1

This is a consensus-breaking release to address a bug and DoS vector in pox-2's stack-increase function. Additional context and rationale can be found in SIP-022.

This release is compatible with chainstate directories from 2.1.0.0.x.

Upgrade timing estimate: https://stacks-network.github.io/when-rewards/2.2/

This software update is a hotfix to resolve improper unlock handling in mempool admission. This release's chainstate directory is compatible with chainstate directories from 2.1.0.0.1.

Fixed

• Fix mempool admission logic's improper handling of PoX unlocks. This would cause users to get spurious NotEnoughFunds rejections when trying to submit their transactions (#3623)

This release is a hotfix for various stacks-node behavior in 2.1.0.0.0. This version is compatible with 2.1.0.0.0 chainstate directories, so it does not require a resync to upgrade from 2.1.0.0.0.

Fixed

• Fix crash related to mempool bloom filter processing
• Handle the case where a bitcoin node returns zero headers (#3588)
• The default value for always_use_affirmation_maps is now set to false, instead of true. This was preventing testnet nodes from reaching the chain tip with the default configuration.
• Reduce default poll time of the chain-liveness thread which reduces the possibility that a miner thread will get interrupted (#3610).

Changed

• • The /v2/neighbors endpoint now reports a node's bootstrap peers, so other nodes can find high-quality nodes to boot from (#3401)
• • If there are two or more Stacks chain tips that are tied for the canonical tip, the node deterministically chooses one independent of the arrival order (#3419).
• • If Stacks blocks for a different fork arrive out-of-order and, in doing so, constitute a better fork than the fork the node considers canonical, the node will update the canonical Stacks tip pointer in the sortition DB before processing the next sortition (#3419).

Fixed

• • The node keychain no longer maintains any internal state, but instead derives keys based on the chain tip the miner is building off of. This prevents the node from accidentally producing an invalid block that reuses a microblock public key hash (#3387).
• • If a node mines an invalid block for some reason, it will no longer stall forever. Instead, it will detect that its last-mined block is not the chain tip, and resume mining (#3406).