1.12.3.0: Bitcoin Computer integration + aarch64 startup fix

[reallyshadydev]

Release version: 1.12.3.0 (CLIENT_VERSION_REVISION bumped in configure.ac and src/clientversion.h; release notes in doc/release-notes/release-notes-1.12.3.0.md).

Summary

Addresses the WojakCoin integration feedback from the Bitcoin Computer team in bitcoin-computer/monorepo#456 (review comment).

• policy: apply -bytespersigop as fee-based policy instead of rejection — backport of Bitcoin Core 0.13's bytespersigop implementation (-bytespersigop option to additionally limit sigops in transactions we relay and mine bitcoin/bitcoin#7081). Sigop-dense transactions below the absolute MAX_STANDARD_TX_SIGOPS (16000) cap are no longer rejected from the mempool; CTxMemPoolEntry::GetTxSize() now returns max(real size, sigops * bytespersigop), so density raises the required fee for relay and mining instead. Bitcoin Computer transactions relay with default node settings — operators and miners no longer need bytespersigop=0 in wojakcoin.conf.
• rpc: add generatetoaddress (regtest) — the Bitcoin Computer test suite calls generateToAddress and can now run unmodified. generate is refactored onto a shared generateBlocks() helper, unchanged in behavior.
• depends: boost 1.59 → 1.70 — fixes the arm64 Docker startup failure (root cause) — the linux-aarch64 release binary dies with SIGSEGV right after scheduler thread start, which is why arm64 containers loop under restart: always. Reproduced natively on Apple Silicon (linux/arm64, no emulation); an unstripped CI-replica build shows the scheduler thread faulting on the process's first boost::function invocation — pthread_mutex_lock reached from CScheduler::serviceQueue() with a garbage this pointer out of the boost::bind member-function dispatch. Boost 1.59 (2015) headers are miscompiled by gcc 11 on the ubuntu-22.04-arm runner; the same binary works under linux/amd64 emulation, which is why the QEMU workaround "fixes" it. The new recipe is Bitcoin Core v0.21's proven boost.mk (1.70.0) adapted for this tree, plus a backport of boostorg/thread@74ff2db9 so boost.thread builds on glibc ≥ 2.34.
• depends: libevent 2.0.22 → 2.1.12-stable — modernizes the other 2014-era dependency (initially suspected for the arm64 crash; a native arm64 build with libevent 2.1.12 alone still crashed, isolating boost as the cause — kept as hardening since 2.1.x is what this tree already runs against on macOS).
• ci: smoke-boot the built daemon on regtest in both Linux release jobs — the arm64 job runs on the native ubuntu-22.04-arm runner (same environment class as arm64 Docker hosts), so aarch64-only startup failures fail the release with the daemon log, dmesg, and full gdb thread backtraces instead of shipping.
• build: bump version to 1.12.3.0, plus release notes documenting all of the above.

No consensus changes

All changes are policy/RPC/build-level. Block validity is untouched: MAX_BLOCK_SIGOPS enforcement in ConnectBlock, block size limits, and everything under src/consensus/ are unchanged. A block containing sigop-dense transactions was valid before and remains valid, so upgraded and non-upgraded nodes stay in consensus — matching the note in the Bitcoin Computer review that bytespersigop is a standardness setting, not a consensus rule.

Verification

Native linux/arm64 (Apple Silicon, colima/docker, no emulation):

• Published 1.12.2.0 arm64 image: exits 139 (SIGSEGV) after scheduler thread start — clean reproduction of the report.
• CI-replica depends build of this branch without the boost commit (libevent 2.1.12 only): still crashes → libevent ruled out as cause.
• CI-replica depends build with boost 1.70: boots through init (scheduler thread start → HTTP: creating work queue of depth 16 → RPC ready), generatetoaddress 5 mines to height 5, clean shutdown.

Full release workflow on this branch (run 30864031567): all four platforms build green — Linux aarch64 (including the new smoke test), Linux x86_64 (including the new smoke test), macOS arm64, and Windows x86_64. The aarch64 job's binary reports WojakCore Daemon version v1.12.3.0.

Regtest A/B (macOS arm64 build):

• A 1,560-byte transaction with 241 legacy sigops (12 bare 1-of-3 OP_CHECKMULTISIG outputs) is rejected by the pre-fix binary with 64: bad-txns-too-many-sigops and accepted by this branch (mempool reports the virtual size, 4,820 = 241 × 20), then mined into a valid block.
• generatetoaddress 101 <addr> works; pre-fix binary returns Method not found.

Follow-ups

• After the next release is cut (with the arm64 smoke test green), bump the image version and per-binary SHA256 pins in docker-wojakcoin-core; until then the Bitcoin Computer team's platform: linux/amd64 workaround stands.
• The Chess app module-size limitation from the same review is on the Bitcoin Computer side (module composition, their #485) — nothing needed in wojakcore.

[reallyshadydev]

Force-pushed with the verified root cause for the arm64 startup failure: it is a SIGSEGV in the scheduler thread's first boost::function invocation — depends boost 1.59 miscompiled by gcc 11 on the arm64 runner — not libevent as the earlier commit message guessed. Reproduced and fixed natively on Apple Silicon (linux/arm64, no emulation): the published 1.12.2.0 arm64 image exits 139; a CI-replica build with only the libevent bump still crashes; with boost 1.70 it boots to RPC and mines regtest blocks. Branch reworked into: bytespersigop policy, generatetoaddress, boost 1.70 (the fix), libevent 2.1.12 (modernization), and a native-arm64 CI smoke test. Details in the updated PR description.