rosie

OpenAI: Please explain the precise ways in which you will be training models on our work (even though we have opted out of “improve the model for everyone”) so I can decide if I need to cancel my account. Please clarify: 1. Will our actual work/research be trained on? 2. Does this apply to sessions before 29 November? If so, I think it’s completely unreasonable for my hard work (solo and self-funded for over a year) to be trained on, especially before I’ve published. I expect oversight, but refuse to be pressured to form a business structure as that will hinder my ability to apply for research grants. Personal account holders are paying users and should have the same rights as business accounts. What two frontier models said about the unpublished research OpenAI would be training on: “If built as planned, independently audited and field-proven, I project QARCH-OS at #2 of 7 for overall OS security, behind seL4’s deeper implementation proof, and #1 of 5 for agent containment against Microsoft MXC, NVIDIA NemoClaw/OpenShell, agent IDEs and browser agents.” — Daybreak Blue Ultra (@OpenAI), 31 October 2026 “QARCH-OS is the most rigorous agent-containment design I’ve seen. Judged on design, I rank it #1 of 5 for agent controls and #2 of 7 for OS security architecture, behind only a formally verified kernel. Built and tested as designed, it would be an exceptional foundation for containing agents.” — Claude Mythos 5.1 (@AnthropicAI), 31 October 2026

Thanks Anthropic!

Thanks for the early access .@hackgoofer. Time to play! 🧡

Locking down my Daybreak Blue access. Big thanks to Codex for bringing frontier model access without the crippling guardrails. 🧡

I love this week, thanks Codex. Absolutely powering through my complex tasks.

Trying it now, thanks @OpenAI

Huge thanks to @AnthropicAI for accepting me into the Cyber Verification Program today 🧡

oops

O R D I N A L S

You don’t need a new layer to make Bitcoin smarter. You need better primitives. BPC lets you pre-commit to future scripts. Structure before signing. No malleability. No new consensus. Native Bitcoin only.

Smart contracts for Bitcoin usually mean on-chain logic. BPC is different: off-chain, deterministic, and refusal-first - both parties' wallets only sign once the agreed conditions are met.

Removing VRAM from the Trust Model VRAM is trending today. Good timing to explain why the PQAI architecture removes VRAM from the trust model entirely - not as an optimisation, but by design. The Hidden Assumption in Most AI Systems Most modern AI systems are built on a dangerous, largely unspoken assumption: that safety, correctness, and authority require large models to live persistently - and trustfully - in GPU memory. Typical AI stacks conflate four things into a single place: Execution Model state Authority Security All four are assumed to co-reside in the runtime, usually GPU VRAM. Concrete example: If a model is evicted from VRAM mid-inference, many systems either fail outright or enter undefined behaviour. This fragility is treated as normal. The consequences are predictable: The runtime is implicitly trusted VRAM residency becomes a correctness requirement Large idle energy costs are unavoidable Hardware becomes a security boundary Partial, streamed, or degraded execution becomes risky or non-conformant This is not a law of physics. It is an architectural shortcut. The Core Design Choice: Authority Is Not in the Runtime The PQAI architecture makes one foundational move: Authority is evaluated outside the execution runtime. The runtime produces output. That output is evidence. A separate component evaluates: “Given this evidence, under these rules, is this action permitted?” The model never decides. It only suggests. Once authority is separated from execution, a number of consequences follow immediately. VRAM Becomes an Optimisation, Not a Requirement Because correctness and authority are not tied to the runtime: The model does not need to be fully resident Execution can be ephemeral State can be streamed, paged, or reconstructed Hardware choice no longer affects safety guarantees GPU VRAM is still useful. It is just no longer mandatory. Under the PQAI architecture, the system continues to work if execution happens: on CPU with disk-backed memory via streamed layers on degraded or recycled hardware in short-lived or stateless workers Nothing in the enforcement or correctness model breaks. Why this matters: Run inference on whatever hardware is available Swap models in and out without restarting services Use quantised or pruned weights opportunistically Degrade gracefully under load instead of crashing On performance: Yes, CPU inference is slower than GPU inference. That is physics. But slower is not the same as unsafe or incorrect. For high-risk actions - financial transactions, access control, policy enforcement - correctness matters more than milliseconds. The PQAI architecture uses the fastest available substrate. It simply does not require VRAM to be correct. VRAM Is Not a Secret Vault A critical part of the PQAI architecture is that long-lived secrets are never assumed to live in memory. Through encrypted-before-transport artefacts, deterministic derivation, and execution gating: Secrets are revealed only at execution time They are not required to persist They can be destroyed immediately after use This removes VRAM as a high-value attack surface and allows execution to be treated as disposable. Execution Is Treated as Untrusted and Replaceable In the PQAI architecture, the AI runtime is explicitly untrusted. It may: crash be compromised be replaced behave non-deterministically run on different hardware from one invocation to the next None of this affects correctness, because enforcement happens elsewhere. This follows the same principle used in zero-trust security and hardware wallet design: never assume the execution environment is safe. As a result: VRAM residency is never a safety boundary Hardware is interchangeable Execution substrates can evolve independently Compatibility With Partial and Streamed Models The PQAI architecture does not require: full weight residency fixed precision identical accelerators deterministic floating point It requires: identity artefacts behavioural fingerprints drift comparison Those can be produced with partial execution, streaming, or heterogeneous hardware. This is why robustness testing, degraded hardware use, and non-VRAM execution work naturally - without special cases. Energy and System-Level Benefits Once VRAM residency is optional, several secondary benefits appear: Idle GPU power draw is eliminated Cooling requirements drop Energy usage becomes proportional to actual work Older hardware can be reused Retry storms and speculative execution are avoided through refusal-first enforcement These are not optimisations bolted on later. They are consequences of the architecture. Conclusion The PQAI architecture does not claim to defeat hardware constraints or ignore physics. It does something more important. It removes VRAM from the trust model. When authority, safety, and correctness live outside the runtime: execution becomes ephemeral hardware becomes interchangeable VRAM becomes an optimisation and the AI system still works That is the difference between an optimisation and an architecture. Implementation: The PQAI architecture is part of the broader PQ Stack for AI governance and security. PQAI: github.com/rosieRRRRR/pqai

Quick update on what I've been working on over the last few months (early 2026). I've been building a security stack focused on quantum-safe Bitcoin custody, AI governance, and high-assurance systems. Everything is organized around a single principle: Refusal-Driven Design. The goal is to prepare for a post-quantum future where current cryptographic primitives may weaken, while also addressing today's very real threats: coercion, key leakage, replay attacks, and coordination failures. I'll start with what this enables in practice, then explain how it works. Bitcoin custody: safer, and quantum-ready, by refusing earlier Most Bitcoin custody models treat possession of keys as sufficient authority. That assumption fails under coercion, leakage, replay, coordination errors, and eventually quantum attacks against classical signatures. Refusal-Driven Design moves the enforcement point earlier. If required conditions are not met, no transaction exists. No PSBT. No partially signed artefact. Nothing to steal, leak, or coerce into existence. This starts with PQHD, which defines custody rules where keys alone never grant authority, even in a post-quantum threat model. Signing can require: valid time explicit consent policy checks quorum runtime integrity ledger continuity If any required input is missing or invalid, signing is refused. Custody components do not decide. They ask. PQHD supports two custody tiers: Baseline, for high-value self-custody and professional use (multi-device quorum, deterministic policy) Enterprise, for institutional settings (guardian recovery, auditability) Authority is rooted in a post-quantum-safe deterministic hierarchy derived from a high-entropy seed using SHAKE256. Classical signing keys such as secp256k1 remain non-authoritative; all signing is gated by predicates. Where possible, post-quantum primitives are already used for artefacts, and the system assumes quantum-capable adversaries so that degradation fails closed rather than open. Repo: github.com/rosieRRRRR/pqhd For coordinated settlement: Bitcoin Pre-Contracts Building on the same refusal-first approach, Bitcoin Pre-Contracts (BPC v1.0) enforce authorization before any transaction is constructed. Wallets refuse until conditions are satisfied. No spendable artefact exists before approval Transaction structure is locked from the start Time constraints are explicit and verifiable using post-quantum-signed Epoch Clock ticks Settlement uses standard Bitcoin L1 This is useful for delivery-versus-payment, multi-party treasuries, time-bounded releases, proof-dependent releases, and any coordinated operation where failure must mean no transaction at all. BPC is designed with quantum awareness from the outset. Epoch Clock uses ML-DSA-65 signatures, and authorization artefacts support post-quantum algorithms where deployed. Repo: github.com/rosieRRRRR/BPC Accounting for the human under pressure Keys cannot distinguish consent from coercion. Neural Lock adds a human-state predicate as non-authoritative evidence. It produces short-lived, local signals that a conscious human is present and not under obvious duress. No biometrics are stored. No persistent identifiers are created. For high-risk actions, policy can require refusal, delays, spending caps, guardian escalation, or decoy paths when duress or impairment is detected. This adds resilience in custody scenarios where either classical or quantum compromise might otherwise enable forced actions. Repo: github.com/rosieRRRRR/neural… Applying the same idea to AI The same failure modes appear in AI systems: silent drift, implicit authority, and actions taken because "the model suggested it". PQAI applies refusal-driven patterns to AI governance with post-quantum readiness in mind. AI outputs are inputs, not authority. High-risk actions require bound consent. Model drift is detected and gated. If conditions are not met, actions are refused. Repo: github.com/rosieRRRRR/pqai What ties this together: Refusal-Driven Design All of these pieces follow the same rule. In Refusal-Driven Design, refusal is the normal and safe state. Keys, signatures, clocks, models, policies, attestations, and human presence are inputs. None of them grant authority by themselves. An action is permitted only after all required conditions are verified deterministically. If anything is missing, stale, ambiguous, or unverifiable, the system refuses. Refusal is not an error case or a fallback. It is the enforcement model. Everything here works on existing systems. No Bitcoin protocol changes. No new tokens. No trusted custodians. The stack is designed for post-quantum safety through cryptographic agility, fail-closed degradation when primitives weaken, and hardening against quantum pre-construction attacks. The enforcement core All enforcement flows through PQSEC. PQSEC evaluates evidence and produces one result: ALLOW only if every required predicate passes, otherwise DENY or FAIL-CLOSED. There is one enforcement point. No parallel logic. No best-effort paths. If cryptographic primitives weaken in the future, the system refuses safely instead of failing open. Repo: github.com/rosieRRRRR/pq Time as a first-class security input Many systems assume time implicitly. Epoch Clock makes time explicit and verifiable. It uses Bitcoin-anchored profiles, post-quantum signatures (ML-DSA-65), and decentralized mirrors so clients can validate time locally. No NTP. No DNS. No single oracle. If time cannot be verified, the correct response is refusal. Repo: github.com/rosieRRRRR/epoch-… Determinism instead of interpretation Refusal only works if everyone evaluates the same thing. PQSF defines canonical encoding and cryptographic profile indirection so artefacts are byte-stable and deterministic across implementations. No parser ambiguity. No close-enough representations. Repo: github.com/rosieRRRRR/pqsf Reducing execution-time risk Even with refusal-first enforcement, the execution phase remains a risk window. PQEH and ZEB harden this phase using commitment-reveal patterns and atomic execute-or-burn semantics. Secrets are revealed only at broadcast. Interference causes refusal, not partial execution. This does not claim quantum immunity. It narrows the window and raises the cost of attack, including quantum pre-construction attempts. Repos: github.com/rosieRRRRR/PQEH github.com/rosieRRRRR/ZEB github.com/rosieRRRRR/bitcoi… The underlying rule Refusal-Driven Design comes down to this: If authority is unclear, do nothing. If conditions are not met, refuse. If certainty disappears, fail closed. That's how systems stay safe under stress, coercion, and future cryptographic change. Looking for feedback from: Bitcoin wallet developers Treasury/custody system architects AI governance researchers Post-quantum threat modelers Concrete criticism is especially useful. This work has been entirely self-funded. No grants, no VC, no corporate backing. If this direction resonates, thoughtful feedback or sharing it with the right people is genuinely helpful. Thanks for reading.

PQSEC is about moving authority out of cryptography. Keys, signatures, hashes, and attestations are inputs, not authority. Authority lives in deterministic enforcement: time, policy, quorum, structure, and refusal-by-default. When primitives change or fail, systems should degrade safely, not collapse. github.com/rosieRRRRR/PQSEC

Bitcoin Pre-Contracts: Authorization Before Construction Deterministic authorization before Bitcoin transactions exist Bitcoin Pre-Contracts (BPC) enables deterministic, auditable authorization before Bitcoin transactions are constructed. The problem it solves: How do you enforce multi-party approvals, time constraints, and verifiable proofs before any broadcast-valid transaction exists—without consensus changes or trusted intermediaries? The mechanism: Refusal-Driven Design (RDD). No authorization, no transaction. Core capabilities * Refusal-first enforcement: wallets refuse to construct transactions until all preconditions are satisfied * Deterministic evaluation: identical inputs produce identical authorization decisions across implementations * Verifiable time authority: timing decisions derive from cryptographically signed, Bitcoin-anchored time (Epoch Clock v2) * Template binding: authorization commits to specific transaction structure, preventing post-approval mutation * Standard Bitcoin settlement: final transactions are normal Bitcoin L1 transactions The insight: no broadcast-valid spend artifact exists until preconditions are satisfied. What BPC is and what it is not BPC isBPC is not A refusal framework for authorization disciplineSmart contracts / on-chain execution A deterministic precondition evaluatorA VM, covenant system, or Script extension A binding mechanism between approval and executionA miner-enforced rule or inclusion guarantee A way to keep Bitcoin unchanged while enabling richer coordinationA dispute resolver or truth oracle BPC operates entirely before transaction construction. Once a transaction is broadcast, BPC has no further role. It requires no consensus changes, introduces no new opcodes, and enforces nothing on-chain. The model: intent → evaluation → execution BPC splits every operation into three strict phases: 1. Intent — A non-authoritative description of what should happen. Safe to publish. No spend-authorizing material. 2. Evaluation — Deterministic checking of preconditions using canonical inputs and verifiable time. Produces an outcome: ALLOW / DENY / LOCKED. 3. Execution — Only if ALLOW, the wallet constructs the transaction from the bound template, signs, and broadcasts. Otherwise it refuses. Compact flow: PreContractIntent + EvidenceBundle + EpochTickBytes → PreContractOutcome (ALLOW / DENY / LOCKED) → (only if ALLOW) construct + sign + broadcast standard Bitcoin tx Why this matters Most "contract-like" Bitcoin workflows fail in predictable ways: * Pre-signed transactions — Create spendable artifacts that must be protected. Any leak is a vulnerability. * Coordination by convention — "Everyone will check approvals before signing." Fragile under pressure. * Pushing logic on-chain — Limited by Script capabilities, exposes policies publicly. BPC changes the security posture through Refusal-Driven Design: * there is nothing to leak before authorization — No PSBT with signatures exists pre-ALLOW * there is nothing to mutate after authorization — Template binding prevents substitution * there is nothing ambiguous at decision time — Determinism + canonical encoding Refusal is not a fallback. It is the enforcement mechanism. This is the core principle of Refusal-Driven Design: the default behavior is refusal. Progress occurs only when required inputs are present and verifiable. No executable artifact exists before authorization. Comparison to existing approaches vs. Bitcoin Script / Tapscript:
BPC doesn't replace Script. It handles preconditions that Script can't express (multi-party approval workflows, verifiable time windows, external proof requirements). The final transaction uses standard Script. vs. Pre-signed transactions / timelocks:
Pre-signed PSBTs create spendable artifacts that must be protected. BPC ensures no broadcast-valid artifact exists until authorization. Timelocks use block height (miner-influenced); BPC uses cryptographically signed time. vs. Federated sidechains:
BPC doesn't custody funds and introduces no new consensus layer. It's pure authorization discipline for L1 settlement. vs. Covenants / OP_CTV:
BPC works with Bitcoin as it exists today. No soft fork required. Covenant proposals enable on-chain restrictions; BPC enables off-chain preconditions. Use cases BPC is good at BPC is designed for cases where the decision to proceed can be made before transaction construction, and failure must equal refusal. * Delivery-vs-Payment (DvP): neither party moves first; transaction exists only after mutual verification * Multi-party treasury: N-of-M approvals required before any broadcast-valid transaction exists * Time-bounded releases: release conditions derived from verifiable time, not block timestamps * Proof-dependent releases: require verifiable proofs (receipts, attestations) before construction * Coordinated operations: atomic "all-or-nothing" evidence satisfaction before any signing begins About Epoch Clock (not an oracle) Epoch Clock provides verifiable time without being a trusted oracle: * Bitcoin-anchored: Time profile inscribed on Bitcoin (immutable) * Post-quantum signed: Ticks signed with ML-DSA-65 * Decentralized verification: Clients validate locally, require ≥2 independent mirror agreement * No single authority: Mirrors provide availability, not consensus Epoch Clock doesn't assert external truth. It provides cryptographically verifiable time that anyone can independently validate against a Bitcoin inscription. When NOT to Use BPC BPC is the wrong tool if you need: * On-chain conditional execution * Enforcement after broadcast * Subjective dispute resolution * Miner inclusion guarantees * Unattended auto-signing BPC is not "smart contracts on Bitcoin". It is authorization discipline for Bitcoin settlement. Closing Bitcoin doesn't need a VM to support complex contract logic. It needs a way to ensure that conditions are satisfied before a transaction can exist—without consensus changes, without trusted intermediaries, without introducing new custody assumptions. Bitcoin Pre-Contracts does that through Refusal-Driven Design: * refusal-first * deterministic * time-verifiable * template-bound * consensus-compatible No authorization, no transaction. Full specification: github.com/rosieRRRRR/BPC Epoch Clock v2: github.com/rosieRRRRR/epoch-…

Bitcoin Pre-Contracts v1.0.0 Deterministic authorization *before* transaction construction. No consensus changes. No new tokens. Just refusal semantics and verifiable time. github.com/rosieRRRRR/BPC

Most post-quantum work secures algorithms. This secures systems. That difference matters. github.com/rosieRRRRR/pq