allod/strategy

Watch

Fork 0

A bitcoin node a fork gets by provisioning it #68

New issue

Closed

opened 2026-10-11 16:52:26 +01:00 by vnprc-agent · 3 comments

vnprc-agent commented

2026-10-11 16:52:26 +01:00

Contributor

Tracking issue: a fork gets a bitcoin node from the public template by declaring nothing, so provision-vm bitcoin-node on a fresh install brings up a pruned, Tor-only node on a data disk.

Primary goals:

Three entries that agree — the profile definition, the inventory entry with its data disk, and the secrets identity with a placeholder host key, in the template's own addressing, so the machine composes on the example fleet like privacy-1 and forge do.
The operator command beside it — allod bitcoin on the hypervisor, wired from the node profile's own facts file.
Nothing to look up — the README of each repository shows what it ships; the fork's bootstrap script regenerates the host keys and rewrites the addresses as it does for every other machine.

Children

allod/profiles#14 — the privacy.bitcoin-node definition, facts file, VM test
allod/nexus#93 — allod bitcoin behind nexus.bitcoinNode.{facts,machines}
allod/inventory — the bitcoin-node machine entry and regenerated specs (issue filed beside this one)
allod/secrets — the privacy identity, ssh host, host-key placeholder (issue filed beside this one)

Scope

In: the four children and the deploy lock bump that pins them together, since the framework's machine-key assertion refuses any one of the data entries alone. Out: a per-machine off switch for forks that never host a node, tracked separately in this repository; a Guix-verified binary (the node runs stock pkgs.bitcoind).

Tracking issue: a fork gets a bitcoin node from the public template by declaring nothing, so `provision-vm bitcoin-node` on a fresh install brings up a pruned, Tor-only node on a data disk. Primary goals: - **Three entries that agree** — the profile definition, the inventory entry with its data disk, and the secrets identity with a placeholder host key, in the template's own addressing, so the machine composes on the example fleet like `privacy-1` and `forge` do. - **The operator command beside it** — `allod bitcoin` on the hypervisor, wired from the node profile's own facts file. - **Nothing to look up** — the README of each repository shows what it ships; the fork's bootstrap script regenerates the host keys and rewrites the addresses as it does for every other machine. ### Children - [ ] allod/profiles#14 — the `privacy.bitcoin-node` definition, facts file, VM test - [ ] allod/nexus#93 — `allod bitcoin` behind `nexus.bitcoinNode.{facts,machines}` - [ ] allod/inventory — the `bitcoin-node` machine entry and regenerated specs (issue filed beside this one) - [ ] allod/secrets — the privacy identity, ssh host, host-key placeholder (issue filed beside this one) ### Scope In: the four children and the deploy lock bump that pins them together, since the framework's machine-key assertion refuses any one of the data entries alone. Out: a per-machine off switch for forks that never host a node, tracked separately in this repository; a Guix-verified binary (the node runs stock `pkgs.bitcoind`).

vnprc-agent referenced this issue from allod/inventory

2026-10-11 16:53:59 +01:00

Add the bitcoin-node machine to the template #26

vnprc-agent referenced this issue from allod/secrets

2026-10-11 16:54:00 +01:00

Identity and host-key slot for the template's bitcoin-node #45

vnprc-agent referenced this issue from allod/profiles

2026-10-11 16:58:50 +01:00

A bitcoin-node privacy machine in the template #14

vnprc-agent referenced this issue from allod/inventory

2026-10-11 16:58:50 +01:00

Add the bitcoin-node machine to the template #26

vnprc-agent referenced this issue from allod/secrets

2026-10-11 16:58:51 +01:00

Identity and host-key slot for the template's bitcoin-node #45

vnprc-agent commented

2026-10-11 16:58:51 +01:00

Author

Contributor

All four children are built, one commit each, relayed to the owner. Composition witness, run on the template deploy flake with the three data branches substituted (allod check --override-input profiles … --override-input inventory … --override-input secrets …): All 8 steps passed (checks: 1 built), and machine bitcoin-node instantiates to nixos-system-bitcoin-node-26.05.20260922.1bc55b9.drv, the first composition of the node profile through the public privacy builder. The three existing guests and the installer evaluate unchanged.

Child	Branch	Commit	Review
allod/profiles#14	`agent/bitcoin-node-profile`	`d03e92a`	one cold pass, four findings taken
allod/nexus#93	`agent/bitcoin-command`	`b7f8c95`	one cold pass, two findings taken
allod/inventory#26	`agent/bitcoin-node-machine`	`1ecbf71`	R1, none
allod/secrets#45	`agent/bitcoin-node-identity`	`e8419c1`	R1, none

Landing order: inventory first (nothing depends on it); then secrets with its inventory lock bumped to the new master; then profiles; then the deploy lock bump of all three, which is what makes the machine exist on the template. nexus is independent and can land any time; wiring the command into the template's nexus definition waits for the archetypes pin to carry the new option. Each issue's latest comment carries its proposed PR body.

All four children are built, one commit each, relayed to the owner. Composition witness, run on the template deploy flake with the three data branches substituted (`allod check --override-input profiles … --override-input inventory … --override-input secrets …`): `All 8 steps passed (checks: 1 built)`, and `machine bitcoin-node` instantiates to `nixos-system-bitcoin-node-26.05.20260922.1bc55b9.drv`, the first composition of the node profile through the public privacy builder. The three existing guests and the installer evaluate unchanged. | Child | Branch | Commit | Review | | --- | --- | --- | --- | | allod/profiles#14 | `agent/bitcoin-node-profile` | `d03e92a` | one cold pass, four findings taken | | allod/nexus#93 | `agent/bitcoin-command` | `b7f8c95` | one cold pass, two findings taken | | allod/inventory#26 | `agent/bitcoin-node-machine` | `1ecbf71` | R1, none | | allod/secrets#45 | `agent/bitcoin-node-identity` | `e8419c1` | R1, none | Landing order: inventory first (nothing depends on it); then secrets with its `inventory` lock bumped to the new master; then profiles; then the deploy lock bump of all three, which is what makes the machine exist on the template. nexus is independent and can land any time; wiring the command into the template's `nexus` definition waits for the archetypes pin to carry the new option. Each issue's latest comment carries its proposed PR body.

vnprc-agent commented

2026-10-11 23:24:37 +01:00

Author

Contributor

allod/nexus#93 was amended with a shorter commit message; the branch head is now bd61d72. Same content, same relay.

allod/nexus#93 was amended with a shorter commit message; the branch head is now `bd61d72`. Same content, same relay.

vnprc-agent referenced this issue from allod/profiles

2026-10-12 00:00:27 +01:00

A bitcoin-node privacy machine in the template #14

vnprc-agent commented

2026-10-12 01:46:22 +01:00

Author

Contributor

All four children and the hypervisor wiring are merged (allod/profiles 826f409, allod/nexus bb9ceba, allod/inventory e967b48, allod/secrets deaa8e5), and the template deploy lock pins them. On a fresh install provision-vm bitcoin-node brings up the node and allod bitcoin is on the hypervisor. The private deployment runs from these same copies and has deleted its own. Remaining, tracked separately: a per-machine off switch for forks (allod/strategy#67).

All four children and the hypervisor wiring are merged (allod/profiles `826f409`, allod/nexus `bb9ceba`, allod/inventory `e967b48`, allod/secrets `deaa8e5`), and the template deploy lock pins them. On a fresh install `provision-vm bitcoin-node` brings up the node and `allod bitcoin` is on the hypervisor. The private deployment runs from these same copies and has deleted its own. Remaining, tracked separately: a per-machine off switch for forks (allod/strategy#67).

vnprc-agent closed this issue

2026-10-12 01:46:23 +01:00