Skip to content

Verify decrees, never strand an operator, and start in seconds - #3

Merged
hotpixelgroup merged 2 commits into
masterfrom
improvements
Jul 27, 2026
Merged

Verify decrees, never strand an operator, and start in seconds#3
hotpixelgroup merged 2 commits into
masterfrom
improvements

Conversation

@hotpixelgroup

Copy link
Copy Markdown
Owner

Three of the five improvements. Notarisation and Windows deliberately excluded.

1. The silent update dead-end — a real defect

Both the installer and the app updated with merge --ff-only, and the app
swallowed the failure into a log nobody reads. A node that has been vibed even
once has diverged, so every engaged user silently stopped receiving updates
forever — security fixes included.
The more someone used the product, the more
stranded they became.

The console now owns updating: it reports what upstream has and replays the
operator's decrees on top with a rebase. Conflicts abort cleanly, name the code
upstream also touched, and leave the node exactly as it was.

A dirty working tree is now reported as itself rather than blamed on upstream —
an interrupted decree leaves precisely that state, and sending someone hunting an
imaginary conflict would be worse than saying nothing.

Verified on a diverged clone: 1 commit behind with 3 decrees → absorbed, decrees
replayed in order, behind back to 0.

2. Decrees are verified, not merely compiled

Compiling proves the code is grammatical, not that it is still a Bitcoin node.
Every build is now checked in a throwaway regtest datadir — mine 101 blocks, read
the chain, confirm it still rejects impossible amounts — before it becomes the
node the operator runs. On failure the old binary keeps running and the console
says so plainly.

Found a bug in the checker while testing it: bitcoind rejects -port=0 outright,
so the probe never started. Passes in 3s on a good binary.

3. A node in seconds, not minutes

First run meant a 5-to-90 minute compile before anything happened. A compiler is
only needed to vibe, not to run, so the installer and console now fetch a
published binary and defer the real build to the first decree.

release.yml builds for macOS arm64/x86_64 and Linux x86_64 on tag, proves each
validates before publishing, and records its source commit. That commit check is
the point:
a binary built from other source is not the node you are about to
edit. Verified both directions against a locally served release — mismatch
refused with both hashes named, match accepted and the binary confirmed runnable.

Checklist

  • I ran it
  • python3 -m py_compile contrib/vibes/bitcoin-vibes
  • sh -n on installer and launcher
  • UI: update banner is a role="status" live region, renders at 375px
  • src/ touched? No — consensus untouched, fresh install still stock Core

Note

The release workflow itself cannot be fully exercised until a tag is pushed; the
installer and console halves of it are verified locally as described.

hotpixelgroup and others added 2 commits July 26, 2026 14:56
Two fixes, the first a genuine defect.

1. The silent update dead-end. Both the installer and the app updated
   with 'merge --ff-only', and the app swallowed the failure into a log
   nobody reads. Since a node that has been vibed even once has diverged,
   every engaged user silently stopped receiving updates forever --
   security fixes included. The more someone used the product, the more
   stranded they became.

   The console now owns updating: it reports what upstream has, and
   replays the operator's decrees on top with a rebase. Conflicts abort
   cleanly and say which code upstream also touched, leaving the node
   exactly as it was. Verified end to end on a diverged clone: 1 commit
   behind with 3 decrees -> absorbed, decrees replayed in order, behind
   back to 0.

   A dirty working tree is reported as itself rather than blamed on
   upstream -- an interrupted decree leaves exactly that state, and
   sending someone hunting an imaginary conflict would be worse than
   saying nothing.

2. Decrees are now verified, not merely compiled. Compiling proves the
   code is grammatical, not that it is still a Bitcoin node. Every build
   is now checked in a throwaway regtest datadir -- mine 101 blocks,
   read the chain, confirm it still rejects impossible amounts -- before
   it becomes the node the operator runs. If it fails, the old binary
   keeps running and the console says so plainly.

   Found a bug in the checker itself while testing: bitcoind rejects
   '-port=0' outright, so the probe never started. Dropped it; -listen=0
   keeps it off the network anyway. Passes in 3s on a good binary.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
First run meant a 5-to-90 minute compile before anything happened,
which is where non-technical users quit. But a compiler is only needed
to *vibe*, not to *run*.

- .github/workflows/release.yml builds nodes for macOS arm64, macOS
  x86_64 and Linux x86_64 on tag, proves each one validates (mine 101,
  read the chain) before publishing, and records the commit it was
  built from.
- the installer and the console both look for a published node first and
  fall back to compiling. The node comes up in seconds; the real build
  happens on the operator's first decree, when the wait finally means
  something.

The commit check is the point, not decoration: a binary built from
different source is not the node somebody is about to start editing.
Verified both directions against a locally served release — a
mismatched COMMIT is refused with both hashes named, a matching one is
accepted and the binary confirmed runnable before use. Also verified it
declines gracefully when no release exists at all (HTTPError, not a
crash) and honours VIBES_NO_PREBUILT.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@hotpixelgroup
hotpixelgroup merged commit 6fa42e2 into master Jul 27, 2026
3 of 5 checks passed
@hotpixelgroup
hotpixelgroup deleted the improvements branch July 27, 2026 00:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant