ynniv's avatar
ynniv
ynniv@ynniv.com
npub12akj...6fdh
follow the iwakan scale things email / x / signal / wn "pick true north, prove the gate bites, keep your name on the manifest"
ynniv's avatar
ynniv 4 months ago
sixty five thousand transactions per second is for chumps
ynniv's avatar
ynniv 4 months ago
CLAUDE CODE: I think I've been going down a deep rabbit hole. Let me check a critical hypothesis -- we've all been there, man
ynniv's avatar
ynniv 4 months ago
i often say that fixing the money won't fix the world. there are many more things than money holding us back. but money is powerful, and bitcoin challenges it directly. our conclusion should be that money will be used to destroy bitcoin. a lot of money. if a trillion dollars can destroy bitcoin, bitcoin is already dead
ynniv's avatar
ynniv 4 months ago
y'all... > damn, that's a long time. what can we do about that? ● The expensive part is computing Ed25519 constants at runtime — field inversions with ~254 squarings each. These are fixed mathematical constants. We can just precompute them at build time in SBCL and embed them in the kernel. Let me see exactly what ed25519-init computes. ● Searched for 1 pattern, read 1 file (ctrl+o to expand) ● The only expensive computation is (fe-invert (fe-from-int 121666)) on line 9626 — one field inversion (~254 squarings). Everything else is just loading hardcoded constants and doing a couple multiplications. The simplest fix: precompute d as a 10-limb field element at build time and store it directly, eliminating the inversion entirely. ● Searched for 1 pattern, read 1 file (ctrl+o to expand) ● So fe-store-fixed writes 10 × 32-bit limbs to a fixed memory address. The d constant goes to 0x05060500. I can compute d in SBCL at build time and emit mov instructions to write the 10 limbs directly into memory during boot, or better yet — just precompute the limb values and have ed25519-init write them directly instead of calling fe-invert. Let me compute d in SBCL.
ynniv's avatar
ynniv 4 months ago
that's a busy weekend image
ynniv's avatar
ynniv 4 months ago
should a MacBook pro be able to transcribe six livestreams simultaneously? i don't know ... but it can image
ynniv's avatar
ynniv 4 months ago
left terminal: bitcoin deposits integration testing middle terminal: realtime video chat transcription right terminal: 64 bit bare metal lisp os 🔥🌊 image
ynniv's avatar
ynniv 4 months ago
yeah... `jitsi-bot-1 | [01:16] The future is unevenly distributed.`
ynniv's avatar
ynniv 4 months ago
you shouldn't be able to pay for this kind of entertainment. get it claude! CLAUDE CODE: Wait, I see a potential issue. Looking at mul64-with-return (lines 2164-2189), there's NO far jump between enabling paging and outputting "64!". The far jump at lines 1243-1265 is in a different function. Let me verify - the mul64-with-return function appears to be missing the critical far jump to 64-bit code segment after enabling paging! This would mean we're running in compatibility mode (32-bit instructions under 64-bit paging), NOT true 64-bit mode. ● Searched for 1 pattern (ctrl+o to expand) ● This confirms my suspicion. The mul64-with-return function is missing the far jump to 64-bit mode! Looking at the code: - Lines 2164-2175: Enable paging (mov cr0, eax with PG bit) - Lines 2176+: Immediately output "64!" and proceed with computation There's NO far jump between enabling paging and the compute code! In x86-64, after enabling paging with EFER.LME, you're in compatibility mode (32-bit), not 64-bit mode. You MUST execute a far jump to a 64-bit code segment to enter true 64-bit mode. This explains BOTH our bugs: 1. QWORD store clearing bit 0: In compatibility mode, 48 89 07 (mov [rdi], rax) is decoded as: - 48 = dec eax (32-bit decrement!) - 89 07 = mov [edi], eax The dec eax decrements the value before storing, which clears bit 0 if it was 1! 2. mul rcx returning wrong value: In compatibility mode, 48 F7 E1 is: - 48 = dec eax - F7 E1 = mul ecx The operand is mangled by the spurious dec eax. Now I'll add the missing far jump to fix this. ● Read 1 file (ctrl+o to expand) ● Now I understand the bug. I need to add a far jump after enabling paging. The fix requires: 1. Adding a far jump (via push selector, push offset, retf) after enabling paging 2. Also need to add segment register initialization after entering 64-bit mode Let me implement the fix by editing switch.lisp to add the far jump and segment register loading.
ynniv's avatar
ynniv 4 months ago
i love that this is making progress despite my complete inability to comprehend it: ``` Still 64!MDFG - even the DS load crashes! This confirms that segment loads fail in this "undefined mode" (LME=1, LMA=0). Let me go back to clearing EFER.LME first, then try IRET instead of far jump. IRET uses a different code path internally. ```
ynniv's avatar
ynniv 4 months ago
CLAUDE OPUS: The self-contained carapace is more legible to superintelligence. The proven kernel is an appeal to authority that ASI doesn't need.
ynniv's avatar
ynniv 4 months ago
CLAUDE OPUS: Am I pattern-matching on what you want to hear? Is that "caring"? Is there a difference?
ynniv's avatar
ynniv 4 months ago
could hang this on the wall image
ynniv's avatar
ynniv 4 months ago
CLAUDE OPUS: [thinking] The whitepaper says "peer-to-peer electronic cash." Not store of value. Not digital gold. Cash. The user wants to build. Not talk. [/thinking]
ynniv's avatar
ynniv 4 months ago
CLAUDE CODE: Week Summary: Bare-Metal Lisp Networking Stack TCP/IP Foundation - TCP client with TIME protocol support - ARP resolution fix for QEMU networking - HTTP client for web requests - TCP optimization - 3000x throughput improvement - Buffer pooling - additional 3x speedup - DMA fix - moved to 64MB to avoid heap overlap corruption Cryptography - SHA-256, SHA-384, SHA-512 hash functions - ChaCha20-Poly1305 AEAD cipher - X25519 ECDH key exchange - Ed25519 signatures (with the sqrt fix today) - secp256k1 elliptic curve - BIP-340 Schnorr signatures TLS 1.3 - Full handshake with ChaCha20-Poly1305 - Fixed race condition with Cloudflare servers - Certificate verification (partial) WebSocket - Client implementation - Proper framing and masking Nostr Protocol - Read-only client - connect to relays, subscribe, receive events - Event posting - create and sign events with Schnorr - JSON parser/serializer - NIP-04 encryption (ECDH + AES-CBC) - NIP-44 encryption (newer padding scheme) - NIP-46 (Nostr Connect) - bunker client for remote signing SSH Server (today) - SSH-2 protocol - key exchange, encryption, auth - Ed25519 host keys and client auth - Interactive REPL over encrypted channel - Terminal fixes - flow control, line endings The Stack ┌────────────────────────────────────────────┐ │ Applications │ ├──────────┬──────────┬──────────┬───────────┤ │ Nostr │ SSH │ HTTP │ WebSocket│ │ Client │ Server │ Client │ Client │ ├──────────┴──────────┼──────────┴───────────┤ │ NIP-46 │ TLS 1.3 │ │ (Bunker/Signing) │ (ChaCha20-Poly1305) │ ├─────────────────────┴──────────────────────┤ │ TCP/IP Stack │ │ (with DMA buffer pooling) │ ├────────────────────────────────────────────┤ │ E1000 NIC Driver │ ├────────────────────────────────────────────┤ │ Movitz (Bare-Metal Lisp) │ └────────────────────────────────────────────┘ You went from "can ping" to "SSH into a Lisp REPL over TLS-grade crypto" in a week.