Olaoluwa Osuntokun

Today I'm hosting the @bitcoinoptech show for newsletter #403 @reardencode as co-host We have @roasbeef as guest to talk about Post-quantum BIP86 recovery using zk-STARK proofs of BIP32 seeds x.com/i/broadcasts/1…

@ALewin @realtbast @benthecarman after simple comes "mega complex" taproot chans ofc I called it simple then as a more encompassing version that would've gone to adapter sigs and PTLCs everywhere was on the table

@realtbast @benthecarman @roasbeef Cool! just meant whatever comes after “simple” 😅

Taproot Channels merged into the BOLTs! github.com/lightning/bolt…

Bitcoin is an agent's best friend. With L402 SDK, agents can discover an API, pay 1 sat on Lightning, and get access. All from a single prompt. Devs, vibe coders, and agents are building the AI economy with Lightning. You can too. ⚡

📢 LND v0.21.0 rc1 is ready for testing. Basic Onion Messaging support lands in this release, along with the Payments store migrating to native SQL. Production Simple Taproot channels are also finalized. Details here: github.com/lightningnetwo…

@januszg_ @niftynei but any of them can publish Txn1, no? so then if you aren't watching/aware you risk losing funds you thought were actually settled

@roasbeef @niftynei does this not solve for that? iiuc, the timelocks are relative to one of the prev owners broadcasting their exit transaction. only then, you need to react as current owner. but there's no timebomb per se

a number of bitcoin wallets have told me the reason they integrated @spark over an any given ark implementation is due ark having VTXO expiry it's been a handful at this point. i prefer arkade (and am excited for bark), but it's an interesting data point nonetheless

@niftynei @januszg_ don't outputs in Spark also expire? IIUC, there's a decrementing time lock system, so if you don't claim on chain (or get a newly rooted output?), then a prior owner can go to chain to race you as their lock is now expired

@januszg_ @spark oh that is interesting 🧐

Lightning Terminal is a web dashboard for managing Lightning nodes at scale. Automatically manage routing fees and channel opens. Visualize routing data. Monitor your node from anywhere. We just shipped passkey support for device-based auth and persistent sessions. Authenticate once. Stay logged in across page reloads. No passwords needed. Connect your node and build the future with bitcoin. terminal.lightning.engineering

Agents want money. Bitcoin makes it possible. And now it works with agent-native workflows. Today we're releasing L402 SDK as part of our suite of AI tools, a client SDK for agentic payments on Lightning with L402. Embeds directly into library-based agent frameworks. TypeScript and Python bindings. Works with Vercel AI SDK and LangChain. 📖 Import a library instead of using a CLI 🛡️ Per-request, hourly, daily, and per-domain budget controls 🌐 WASM for browsers, serverless functions, edge environments Start building the agent economy with machine-scale payments on Lightning. github.com/lightninglabs/…

IIUC there's no non-interactive key exchange (DH) in quantum land right now, it's just KEM or key encapsulation mechanisms so that means going back to the much larger packet that includes the shared secret for each hop encrypted in the packet, likely Kyber here eg: eprint.iacr.org/2023/1960

Bitcoin PQC is fun enough, but what about Lightning Network and more specifically on Onion Routing? Seems susceptible to HNDL that would reveal the whole route and recipient to any involved node in a route? (possibly to all the failed routing attempts too?) @roasbeef @snyke

@conordeegan are you following these threads? groups.google.com/a/list.nist.go… groups.google.com/a/list.nist.go… spawned from this paper: eprint.iacr.org/2024/018 see also: github.com/sfluhrer/sphin…

Introducing THINCS 🤔 SLH-DSA is the most conservative standardised post-quantum signature scheme we have. Its security reduces entirely to hash function properties (no lattice assumptions or algebraic structure). The tradeoff is size; the smallest fast variant produces 17,088-byte signatures and the smallest compact variant still comes in at 7,856 bytes. This is because the standardised parameter sets all support up to 2^64 signatures per key, and the signatures are massive as a result. Most signing keys will never need anywhere near that many signatures. To put 2^64 in perspective, signing once per second would take 42 times the age of the universe to exhaust the key. A firmware key might sign a few thousand times, a CA root a few hundred. If you know your actual budget, the underlying construction lets you trade that unused capacity for much smaller signatures at the same security level. As ecosystems start adopting hash-based signatures, there will be applications where tuning the scheme to the actual signing requirement makes more sense than using the general-purpose defaults. This is why I built THINCS. It is a Rust CLI. You give it a total amount of signatures you need it to support and a security level, and it finds and builds the smallest possible signature scheme that meets your requirements. You can then keygen, sign, and verify with it directly.

@conduition_io also got proof aggregation working as well! #scaling-results" target="_blank" rel="nofollow noopener">github.com/Roasbeef/bip32… gonna post a bit later today working on two incremental variants one re heterogeneous batches (combine a batch w/ a new proof), and an MMR version (flatter inclusion proofs for verifeir)

Scratch that, i misread: It's actually just TWO seconds.

I always wondered how well a STARK-based rescue protocol could work. This is awesome stuff from Laolu, actually putting in the work: 14 seconds to definitively prove ownership of a pre-quantum wallet, 20ms to verify, and it can only improve from here with better arithmetization.

@sadeeq_ismaela @Eunovo9 hmm, not up to date on the silent payment mechanics but from what I know if one of the final ECDH (?) keys were generated using BIP 32, then you could make specific claim re that

@roasbeef This can also be used to recover funds sent to a silent payment, as long as they use BIP32 to generate the spend keys, correct? @Eunovo9 should be formally specified in bip352? However, quantum breaks the privacy of silent payments, which sucks.

in the face of quantum adversary, a commonly discussed emergency soft fork for Bitcoin would be to disable the Taproot keyspend path (eprint.iacr.org/2025/1307), effectively turning it into something that resembling BIP-360 assuming an existing precautionary soft-fork to add a pq signature scheme, this would safely allow holders to maintain unilaterally custody of their funds a downside to this proposal is that any keyspend-only (normal schnorr sig) would be locked indefinitely inspired by eprint.iacr.org/2023/362, I set out to address the option problem in section 6, to create a variant of seed-lifting that doesn't reveal the wallet's master secret! 🤓 the end result is a zk-STARK proof that proves: "public key P was generated using a private key k, which itself was derived via BIP-32/BIP-86 with a master wallet secret S" this generalizes beyond Taproot, and would allow the rightful owners of any BIP-32 derived wallets to move their funds in het case of a spend disabeling emergency softfork 🛡️ the final proof takes 50 seconds to run on my MacBook with Metal GPU acceleration, uses 12 GB of RAM during proving, with a final proof size of 1.7 MB the proving code/statement is largely unoptimized, and it's possible to aggregate several proofs into a single smaller proof ⨻ an actual production deployment would likely use a smaller optimize circuit for this specific statement, this demo serves to demonstrate that such a proof is well within reach w/ today's hardware+software to generate the proof I forked TinyGo to add a risc0 RISC-V ELF compilation target for TinyGo: github.com/Roasbeef/tinyg… then I used some helper utilities and a C FFI wrapped risc0 library to create a generalized toolkit for TinyGo zk-STARK proofs: github.com/Roasbeef/go-zk… the final guest+host lives in the bip32-pq-zkp repo: github.com/Roasbeef/bip32… such a proof scheme is yet another tool in the post quantum toolkit for Bitcoin developers to prepare for an eventual PQ world 🤠 full details in my post to the Bitcoin dev mailing list: groups.google.com/g/bitcoindev/c…

@DesheShai working on two other follow ups: heterogeneous bathing, so basically being able to add on a new unbalanced sub-tree an MMR accumulator, which can keep the verifier chain flatter as you accumulate them on progressively

I got proof aggregation working last night as well, this permits a part (presumably a mining pool) to aggregate N proofs into one fixed sized proof These are numbers for the simpler statement that does leak an xpriv (but not the seed), but the full key proof w/ be the same final size: #scaling-results" target="_blank" rel="nofollow noopener">github.com/Roasbeef/bip32…

Our greatest concern with this proposition was proof sizes. We were afraid they'd be in the megabytes. Thank god for the community of STARK hackers who effectively proved the practical feasibility of our proposal.

@Digvijay_BTC yeah so this works for any private keys that were generated by running an initial seed thru a hash function, BIP 32 being the most widely standardized version of that there were earlier bespoke versions of it too (simple hash counter)

@roasbeef So, Satoshi and other early Bitcoiners won't be able to recover their stack once frozen?

@theinstagibbs @conduition_io then you can do another batch aggregation K onto it, but the verifier has another merkle tree layer to fully check optimal design here is an MMR-like structure, so then you have a "flatter" claim verification tree

@theinstagibbs @conduition_io next step here would be supporting nested batches, so prove batch D = {a, b, c}, then H = {e, f ,g}, then a final proof of D+H the verifier for a leaf now needs to openings at each level to confirm a leaf is there

thanks to @conduition_io, there's a new variant of the proof (claim at the xpub/xpriv level, with xpriv skipping the pubkey operations all together) that's *much* faster to prove the xpub based proof takes 14 seconds to prove on my machine, with a composite proof size of 500 KB and 200 KB succint, requiring 11 GB during the proof the priv xpriv proofs takes 2 seconds to prove! using just 3 GB of memory 😎 let the games of STARK proof golf continue! 🏆 added some new docs on the repo to explain the diff proofs: * #reduced-variant-claims" target="_blank" rel="nofollow noopener">github.com/Roasbeef/bip32… * #reduced-proof-variants" target="_blank" rel="nofollow noopener">github.com/Roasbeef/bip32… * #reduced-variants" target="_blank" rel="nofollow noopener">github.com/Roasbeef/bip32…

@An__OG do yo thang

@roasbeef No thanks. I'll wait for a sure thing. No way I'd trust an exposed key path spend.

Crazy how productive one can be with these tools... So if anyone needs to verify a BIP-322 generic message signature in a browser or with Golang, here you go: github.com/btcsuite/btcd/… github.com/bitcoin/bips/p… npmjs.com/package/bip322…

I'm hooked on Claude Code... In just one day I wrote a BIP-322 verifier library in Golang, with test vectors for almost all script types (p2pkh, p2sh-p2wkh, p2wkh, p2wsh, p2tr, including multisig and time locks), created a BIP PR and then published a NPM package for it...