From 6f112ef7ac4b3dce1753d61b34fe189ef32fc646 Mon Sep 17 00:00:00 2001 From: teahubxyz Date: Wed, 14 Oct 2026 20:14:59 -0700 Subject: [PATCH] decisions + lineage: tapkeys listed beside Taproot; Orgchain v1.4 shows secrets Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01H4upF5LVwmPDDqrhdUfnXh --- docs/decisions.md | 1 + docs/lineage.md | 14 ++++++++------ 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/docs/decisions.md b/docs/decisions.md index 94eebfe..4d6d714 100644 --- a/docs/decisions.md +++ b/docs/decisions.md @@ -55,3 +55,4 @@ Format: date · decision · why. Add at the bottom. Never edit an old entry; sup - 2026-10-15 · **Orgchain v1.2: tapkeys and lineage's leaves.** The operator asked for the ssh, git and other keys in Orgchain, and for a tapkey rather than just an npub for each agent. A node's chain key is now its tapkey: its NIP-06 npub with the BIP-86 tweak, so one secret signs its nostr events and its chain spends, and its address follows from its npub (the tweak is checked against BIP-86's own vector). Its leaves hang off the same tree, HKDF-SHA256 with salt `lineage/v0`: an agent's ssh, git, dkim and wg keys from its nostr secret, an org's ssh-ca, mtls and noise keys from its seed. The unit tests hold values read off the key tree page for one mnemonic, and they match byte for byte. Inspect shows each node's tapkey, npub, derivation and leaves, with the public lines to paste (authorized key, `allowed_signers` line, DKIM record, WireGuard peer, CA key). Labs keyed by v1.1 keep their separate m/86' chain keys until they are reset. `@scure/base`, `bip32` and `bip39`, which came in with v1.1, now have their licenses in `public/licenses` and lines in `PROVENANCE.md`. `lineage/orgchain` main `00a3561`, time's `gh-pages` `0984f5a`; 53 unit tests and Playwright 6/6. Token 47 (`orgchain-tapkey-20261015`, `write:repository`) did the pushes and is deleted right after; the table is checked. Why: Orgchain showed lineage's keys only as far as the npub, and the operator wants agents with a key that holds and signs on chain. - 2026-10-15 · **Taproot and SegWit for every lineage account, listed rather than derived.** The operator asked for Taproot in its own right (it is where inscriptions live, and no one should have to derive it from an npub) and for agents' other public Bitcoin addresses. Every account of an org's seed now has standard addresses at the same index as its NIP-06 key: BIP-86 Taproot for inscriptions and BIP-84 SegWit for payments (0 is the org, whose SegWit branch is its treasury; agents are 1..n). The lineage key tree page derives them on mainnet paths, adds the org's Taproot beside its treasury, and lists agents' addresses in their keyrings and in `lineage.json`; the org rows check against the BIP-84 and BIP-86 vectors, and agent addresses were cross-checked against tapscript. Orgchain v1.3 holds every node's inscription at its BIP-86 Taproot key on test paths (`m/86'/1'/…`) and shows Taproot, SegWit and npub with their paths. v1.2's tapkey (the npub's key with the BIP-86 tweak) is retired; labs keyed by v1.1 or v1.2 keep their keys until reset. Proposed for spec v0.1 in `docs/lineage.md`. `lineage/orgchain` main `0af51dc`, time's `gh-pages` `7e08cc5`; 54 unit tests and Playwright 6/6. Token 49 (`lineage-btc-20261015`, `write:repository`) did the pushes and is deleted right after; the table is checked. Why: inscriptions live at Taproot addresses, and an agent's addresses belong in what it publishes. - 2026-10-15 · **Prod runs Gitea 28.0.0, and its Fly config lives in this repo.** Prod went up on the floating `docker.gitea.com/gitea:1.24` tag (1.24.7) while the shell on hb-5 already ran 28.0.0, so the move off the old factory had gone backwards. At the operator's word prod now runs 28.0.0. First a rehearsal: a copy of prod's data (a sqlite backup plus the repos) ran under 28.0.0 in Docker on hb-5, migrations 321 to 355 went through in two seconds, and the Tea MCP's smoke test passed against it; the copy was deleted afterwards. Then Fly snapshot `vs_M9PaLKQVDwX0hZXq1q2MO` of `gitea_data` (5-day retention) and an on-volume copy, `/data/gitea/gitea.db.pre28-20261015`, before the deploy at 02:44 UTC. A migrated database won't start on 1.24, so going back means restoring one of those. Checked afterwards: version and health, the web UI and its GitHub sign-in, the Claude connector (still signed in), a smoke run on `fly-iad-1`, Time's next scheduled tick, a pages hook delivery, Phast and Boring. green-tea's `fly.toml` had lived only in hb-5 `~/green-tea`; it is now `gitea/fly.toml` here, pinned to the exact release, and the hb-5 copy is renamed beside a pointer. What 28 changes for us: workflows' `permissions:` blocks are enforced now (Time's ask for what they use; heartbeat and astra have none, and the default still lets the job token comment, checked in a throwaway repo that is deleted), `concurrency:` groups are honoured, finished runs are deleted after 400 days, webhooks go out under 28's egress rules (the pages hooks are public https, which they allow), and the run and job API exists. So Tea MCP 2.1 (`40706b8`) lists runs in `tea_actions` and reads job logs with `tea_action_logs`; `boring_teahub_deploy` shipped it. The steward's token routine (CLI mint, sqlite delete) works unchanged. Token 48 (`gitea28-20261015`, `write:repository`) pushed 2.1 and this line and is deleted by id right after; the table is checked. Why: the operator said the migration off the old factory had regressed Gitea and asked for 28. +- 2026-10-15 · **The tapkey stays beside Taproot, and Orgchain shows every secret.** The operator likes the npub ↔ tapkey link (Nosft's model, from the Deezy thread) and wants Orgchain to be the full platform for running lineage LLCs, with secrets shown as on the key tree page. Both pages now list each npub's tapkey (its nostr key with the BIP-86 tweak) beside the Taproot and SegWit accounts, and the key tree page's keyring and `lineage.json` carry it. A node's inscription stays at its standard BIP-86 key: the tapkey is where anyone can send to an npub, while the key that carries an org's authority is not one that nostr clients hold. Orgchain v1.4 adds a Reveal panel to every node (the seed for holdings and orgs, the nsec, Taproot, SegWit and Tapkey descriptors with test-network WIF and BIP-380 checksums, and the leaves' private keys), hidden again on every selection. Its output matches the key tree page byte for byte (the tests pin hashes of the page's own output), BIP-84's WIF vector and BIP-380's checksum vector, and `ssh-keygen` reads its OpenSSH keys. The key tree page's descriptors gain checksums too. `lineage/orgchain` main `17b8692`, time's `gh-pages` `d481ba9`; 56 unit tests and Playwright 6/6. Token 50 (`lineage-secrets-20261015`, `write:repository`) did the pushes and is deleted right after; the table is checked. Why: Orgchain is meant to run the LLCs, not only draw them, and an npub should reach the chain on its own. diff --git a/docs/lineage.md b/docs/lineage.md index 80ec3fb..52e4993 100644 --- a/docs/lineage.md +++ b/docs/lineage.md @@ -26,11 +26,11 @@ belts, record decisions, graduate and close. Each act is a `lineage/v0` inscript authorizes it, on a private toy chain in the browser with pretend money. Time is a tempo (each act its own beat, or acts cued and landed together every 10, 30 or 60 s, or by hand), and a slider replays any holding beat by beat. Every node holds its inscription at its Taproot address (BIP-86 at its account: a lab root per holding, BIP-85 org seeds, -the org as account 0 and seats as accounts 1..n), lists its SegWit address and npub beside it, and shows its leaves as -[the key tree](https://lineage.yolopreneur.lol/) derives them: ssh, git, dkim and wg for agents; ssh-ca, mtls and noise -for orgs. Each act is signed by whichever key holds the authorizing -inscription, and graduation is a claim by the org's fresh root, countersigned by its derived key, with the derived -subtree re-keying under it. Closing is still a recorded event. +the org as account 0 and seats as accounts 1..n), lists its SegWit address, its tapkey (the npub as a Taproot address) +and its npub beside it, shows its leaves as [the key tree](https://lineage.yolopreneur.lol/) derives them (ssh, git, +dkim and wg for agents; ssh-ca, mtls and noise for orgs), and keeps every secret behind a Reveal, as the key tree does. +Each act is signed by whichever key holds the authorizing inscription, and graduation is a claim by the org's fresh +root, countersigned by its derived key, with the derived subtree re-keying under it. Closing is still a recorded event. ## Rules 1. **One template, every depth.** An org is legal key · treasury · identity · agents · orgs. The factory's own org and @@ -60,7 +60,9 @@ subtree re-keying under it. Closing is still a recorded event. - `btc` — every account gets standard Bitcoin addresses at the same index as its NIP-06 key: BIP-86 Taproot `m/86'/0'/'/0/0` for inscriptions and BIP-84 SegWit `m/84'/0'/'/0/0` for payments (i = 0 is the org, whose SegWit branch is its treasury; agents are i ≥ 1). The keyring lists both (`key` = `taproot`, `segwit`), so no one - has to derive an address from an npub. + has to derive an address from an npub. It also lists the `tapkey`, the npub's own key with the BIP-86 tweak, which + anyone can derive from the npub; inscriptions that carry authority stay at the Taproot account, because nostr + secrets get pasted into clients. ## Not built yet - The root (operator's decision).