Merge branch 'develop' into feat/tenure_boundary_heuristic

Author: rdeioris

CHANGELOG.md

@@ -7,13 +7,17 @@ and this project adheres to the versioning scheme outlined in the [README.md](RE
 
 ## [Unreleased]
 
-### Added
+## Added
 
+- The `BlockProposal` StackerDB message serialization struct now includes a `server_version` string, which represents the version of the node that the miner is using. ([#5803](https://github.com/stacks-network/stacks-core/pull/5803))
 - Add `vrf_seed` to the `/v3/sortitions` rpc endpoint
 
 ### Changed
 
 - Miner will stop waiting for signatures on a block if the Stacks tip advances (causing the block it had proposed to be invalid).
+- Logging improvements:
+  - P2P logs now includes a reason for dropping a peer or neighbor
+  - Improvements to how a PeerAddress is logged (human readable format vs hex)
 
 ### Fixed
 
@@ -24,12 +28,14 @@ and this project adheres to the versioning scheme outlined in the [README.md](RE
 ### Added
 
 - Add miner configuration option `tenure_extend_cost_threshold` to specify the percentage of the tenure budget that must be spent before a time-based tenure extend is attempted
+- Add miner configuration option `tenure_extend_wait_timeout_ms` to specify the time to wait before trying to continue a tenure because the next miner did not produce blocks
 
 ### Changed
 
 - Miner will include other transactions in blocks with tenure extend transactions (#5760)
 - Add `block_rejection_timeout_steps` to miner configuration for defining rejections-based timeouts while waiting for signers response (#5705)
 - Miner will not issue a tenure extend until at least half of the block budget has been spent (#5757)
+- Miner will issue a tenure extend if the incoming miner has failed to produce a block (#5729)
 
 ### Fixed
 

Dockerfile

@@ -1,4 +1,4 @@
-FROM rust:alpine as build
+FROM rust:bookworm AS build
 
 ARG STACKS_NODE_VERSION="No Version Info"
 ARG GIT_BRANCH='No Branch Info'
@@ -8,15 +8,13 @@ WORKDIR /src
 
 COPY . .
 
-RUN apk add --no-cache musl-dev
-
 RUN mkdir /out
 
 RUN cargo build --features monitoring_prom,slog_json --release
 
 RUN cp target/release/stacks-node /out
 
-FROM alpine
+FROM debian:bookworm-slim
 
 COPY --from=build /out/ /bin/
 

Dockerfile.debian

@@ -1,6 +1,6 @@
 FROM rust:latest
 
-WORKDIR /src/blockstack-core
+WORKDIR /src/stacks-core
 
 RUN apt-get update
 RUN apt-get install valgrind heaptrack -y

Dockerfile.memtest renamed to contrib/tools/Dockerfile.memtest

@@ -375,7 +375,6 @@ usage() {
 	echo "    ${COLBOLD}${0}${COLRESET}"
 	echo "        ${COLYELLOW}--testing${COLRESET}: only check a small number of blocks"
 	echo "        ${COLYELLOW}-t|--terminal${COLRESET}: more terminal friendly output"
-	echo "        ${COLYELLOW}-u|--upload${COLRESET}: upload results to s3"
 	echo "        ${COLYELLOW}-n|--network${COLRESET}: run block replay against specific network (default: mainnet)"
 	echo "        ${COLYELLOW}-b|--branch${COLRESET}: branch of stacks-core to build stacks-inspect from (default: develop)"
 	echo "        ${COLYELLOW}-r|--reserved${COLRESET}: how many cpu cores to reserve for system tasks"
@@ -387,7 +386,7 @@ usage() {
 
 
 ## install missing dependencies
-for cmd in curl tmux git wget tar gzip grep cargo pgrep aws; do
+for cmd in curl tmux git wget tar gzip grep cargo pgrep; do
 	command -v "${cmd}" >/dev/null 2>&1 || {
 		case "${cmd}" in
 			"cargo")
@@ -396,9 +395,6 @@ for cmd in curl tmux git wget tar gzip grep cargo pgrep aws; do
 			"pgrep")
 				package="procps"
 				;;
-			"aws")
-				package="awscli"
-				;;
 			*)
 				package="${cmd}"
 				;;

contrib/tools/block-replay.sh

@@ -16,10 +16,10 @@
 Normal releases in this repository that add new features are released on a monthly schedule.
 The currently staged changes for such releases are in the [develop branch](https://github.com/stacks-network/stacks-core/tree/develop).
 It is generally safe to run a `stacks-node` from that branch, though it has received less rigorous testing than release tags or the [master branch](https://github.com/stacks-network/stacks-core/tree/master).
-If bugs are found in the `develop` branch, please do [report them as issues](https://github.com/stacks-network/stacks-core/issues) on this repository.
+If bugs are found in the `develop` branch, please do [report them as issues](https://github.com/stacks-network/stacks-core/issues) in this repository.
 
 For fixes that impact the correct functioning or liveness of the network, _hotfixes_ may be issued.
-These are patches to the main branch which are backported to the develop branch after merging.
+These are patches to the default branch which are backported to the develop branch after merging.
 These hotfixes are categorized by priority according to the following rubric:
 
 - **High Priority**. Any fix for an issue that could deny service to the network as a whole, e.g., an issue where a particular kind of invalid transaction would cause nodes to stop processing requests or shut down unintentionally. Any fix for an issue that could cause honest miners to produce invalid blocks.
@@ -58,27 +58,33 @@ The timing of the next Stacking cycle can be found [here](https://stx.eco/dao/to
 
    - A label should be applied to each such issue/PR as `X.Y.Z.A.n-blocker`.
 
-3. Since development is continuing in the `develop` branch, it may be necessary to cherry-pick some commits into the release branch.
+3. Perform a [block-replay](../contrib/tools/block-replay.sh) using an existing chainstate, or sync from genesis
+
+4. Since development is continuing in the `develop` branch, it may be necessary to cherry-pick some commits into the release branch or open a PR against the release branch.
 
    - Create a feature branch from `release/X.Y.Z.A.n`, ex: `feat/X.Y.Z.A.n-pr_number`.
    - Add cherry-picked commits to the `feat/X.Y.Z.A.n-pr_number` branch
    - Merge `feat/X.Y.Z.A.n-pr_number` into `release/X.Y.Z.A.n`.
 
-4. Open a PR to update the [CHANGELOG](../CHANGELOG.md) in the `release/X.Y.Z.A.n` branch.
+5. If necessary, open a PR to update the [CHANGELOG](../CHANGELOG.md) in the `release/X.Y.Z.A.n` branch.
 
    - Create a chore branch from `release/X.Y.Z.A.n`, ex: `chore/X.Y.Z.A.n-changelog`.
+   - Update [versions.toml](../versions.toml) to match this release:
+     - Update the `stacks_node_version` string to match this release version.
+     - Update the `stacks_signer_version` string to match `stacks_node_version`, with an appending `0` for this release version.
    - Add summaries of all Pull Requests to the `Added`, `Changed` and `Fixed` sections.
-   - Update the `stacks_node_version` string in [versions.toml](../versions.toml) to match this release.
 
      - Pull requests merged into `develop` can be found [here](https://github.com/stacks-network/stacks-core/pulls?q=is%3Apr+is%3Aclosed+base%3Adevelop+sort%3Aupdated-desc).
 
        **Note**: GitHub does not allow sorting by _merge time_, so, when sorting by some proxy criterion, some care should be used to understand which PR's were _merged_ after the last release.
 
-5. Once `chore/X.Y.Z.A.n-changelog` has merged, a build may be started by manually triggering the [`CI` workflow](../.github/workflows/ci.yml) against the `release/X.Y.Z.A.n` branch.
+   - This PR must be merged before continuing to the next steps
+
+6. A build may be started by manually triggering the [`CI` workflow](../.github/workflows/ci.yml) against the `release/X.Y.Z.A.n` branch.
 
-6. Once the release candidate has been built and binaries are available, ecosystem participants shall be notified to test the tagged release on various staging infrastructure.
+   - **Note**: A `stacks-signer` release will also be produced when this workflow is run
 
-7. The release candidate will test that it successfully syncs with the current chain from genesis both in testnet and mainnet.
+7. Once the release candidate has been built and binaries are available, ecosystem participants shall be notified to test the tagged release on various staging infrastructure.
 
 8. If bugs or issues emerge from the rollout on staging infrastructure, the release will be delayed until those regressions are resolved.
 
@@ -90,7 +96,7 @@ The timing of the next Stacking cycle can be found [here](https://stx.eco/dao/to
 
 10. Finally, the following merges will happen to complete the release process:
     - Release branch `release/X.Y.Z.A.n` will be merged into the `master` branch.
-    - Then, `master` will be merged into `develop`.
+    - Then, `release/X.Y.Z.A.n` will be merged into `develop`.
 
 ## Consensus Breaking Release Process