Release 2.1.0.0.3

fix: neon_node unprocessed_block behavior

Release 2.1.0.0.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)

Release 2.1.0.0.1

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).

Release 2.1.0.0.0

Merge pull request #3567 from stacks-network/develop

Stacks 2.1

Release 2.1.0.0.0-rc4

Merge pull request #3517 from stacks-network/btc-tx-more-info

Event observer: additional info for burn operations

Release 2.1.0.0.0-rc3

Merge pull request #3492 from stacks-network/feat/2.1.0.0.0-rc2

Feat/2.1.0.0.0 rc2

Release 2.05.0.6.0

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).

Release 2.05.0.5.1

Changed

• The new minimum Rust version is 1.61
• The act of walking the mempool will now cache address nonces in RAM and to a
  temporary mempool table used for the purpose, instead of unconditionally
  querying them from the chainstate MARF. This builds upon improvements to mempool
  goodput over 2.05.0.4.0 (#3337).
• The node and miner implementation has been refactored to remove write-lock
  contention that can arise when the node's chains-coordinator thread attempts to store and
  process newly-discovered (or newly-mined) blocks, and when the node's relayer
  thread attempts to mine a new block. In addition, the miner logic has been
  moved to a separate thread in order to avoid starving the relayer thread (which
  must handle block and transaction propagation, as well as block-processing).
  The refactored miner thread will be preemptively terminated and restarted
  by the arrival of new Stacks blocks or burnchain blocks, which further
  prevents the miner from holding open write-locks in the underlying
  chainstate databases when there is new chain data to discover (which would
  invalidate the miner's work anyway). (#3335).

Fixed

• Fixed pow documentation in Clarity (#3338).
• Backported unit tests that were omitted in the 2.05.0.3.0 release (#3348).
• Fixed event-emitter panic on PoisonMicroblock transaction (#3356)

Full Changelog: 2.05.0.4.0...2.05.0.5.1

Release 2.05.0.5.0

Changed

• The new minimum Rust version is 1.61
• The act of walking the mempool will now cache address nonces in RAM and to a
  temporary mempool table used for the purpose, instead of unconditionally
  querying them from the chainstate MARF. This builds upon improvements to mempool
  goodput over 2.05.0.4.0 (#3337).
• The node and miner implementation has been refactored to remove write-lock
  contention that can arise when the node's chains-coordinator thread attempts to store and
  process newly-discovered (or newly-mined) blocks, and when the node's relayer
  thread attempts to mine a new block. In addition, the miner logic has been
  moved to a separate thread in order to avoid starving the relayer thread (which
  must handle block and transaction propagation, as well as block-processing).
  The refactored miner thread will be preemptively terminated and restarted
  by the arrival of new Stacks blocks or burnchain blocks, which further
  prevents the miner from holding open write-locks in the underlying
  chainstate databases when there is new chain data to discover (which would
  invalidate the miner's work anyway). (#3335).

Fixed

• Fixed pow documentation in Clarity (#3338).
• Backported unit tests that were omitted in the 2.05.0.3.0 release (#3348).

Release 2.05.0.5.0-rc1

Merge pull request #3335 from stacks-network/feat/interruptable-miner

[DRAFT] [miner] Reduce fork and orphan rate with an interruptable miner