Skip to content

v0.12.3

Choose a tag to compare

@jdogresorg jdogresorg released this 01 Sep 22:39
· 315 commits to master since this release
v0.12.3
0fe3cce

XChain Platform v0.12.3.

A patch train for the validator onboarding path. src/release-manifest.json pins xchain-node and xchain-hub at v0.12.3 and the other eleven components at the tags they already carry, unchanged. A component's version is the platform version at which it last changed, so a gap means unchanged that release, not skipped.

Verifying this release

gpg --verify SHA256SUMS.asc SHA256SUMS
shasum -a 256 -c SHA256SUMS

The signing key is published at xchain-documentation/operations/release-signing.md and in tools/release/ in every train repo. Any other key is not an official release.

Installing this exact set

xchain-node install v0.12.3 <service> <coin> <network>

What is in this train

Both fixes address the same window: the time between broadcasting a STAKE and that stake activating, which is when a new validator is most likely to conclude something is broken.

  • A hub rejected a peer that was not in the effective signer set by reporting an invalid signature, because the membership check shared a return path with the signature check. An operator whose stake had not activated yet was told their signature was bad, which sends them looking for a key problem that does not exist. A membership miss now says what it is, and names the activation delay.
  • A hub running in validator mode reports whether its own key is in the signer set, once when it is outside and once when it is admitted. Previously the only evidence was a rejection line in the logs of the peers dropping it, which its operator cannot read.
  • validator unstake said the escrowed XCHAIN became spendable when the stake left the active set. Leaving the set takes 6 blocks on Bitcoin; the coins are released by the staking cooldown, 1000 blocks, about a week later. Both clocks are now printed, by stake as well as unstake.
  • Both delays are read per chain from the coin registry rather than assumed to be Bitcoin's. The hardcoded value was wrong for Litecoin (24 blocks) and Dogecoin (60).

Everything here is state-neutral: operator-facing text, log lines and a reject reason. The membership gate, its ordering ahead of the signature check, and its fail-closed behaviour are unchanged, so a v0.12.2 and a v0.12.3 hub make identical admission decisions and interoperate on the wire.

Full per-component detail is in each repository's CHANGELOG at its tag.