WEBVTT Automatically timed original source text; AI narration; timing not manually listen-through verified. 00:00:00.000 --> 00:00:01.820 Breakout Session: SHRINCS. 00:00:02.300 --> 00:00:11.940 Notes from the breakout session led by Jonas Nick at the Post-Quantum Bitcoin Workshop at Stanford, 28 August 2026, written by Localhost Research. 00:00:12.380 --> 00:00:13.880 This is an AI recording. 00:00:14.260 --> 00:00:19.200 Find the original text and more information on btctranscripts.com. 00:00:19.380 --> 00:00:20.100 Motivation 00:00:20.100 --> 00:00:37.430 Building on the day's hash-based signature discussion (SPHINCS+/SLH-DSA): over the past summer, the team examined how to adapt these schemes for Bitcoin — specifically via different parameterizations. 00:00:38.010 --> 00:00:52.480 The most prominent lever is the signature budget: reducing it shrinks signatures, but only up to a point — go too far and the scheme is no longer stateless. It's a spectrum, with a hard limit. 00:00:53.430 --> 00:00:56.710 Core design: a stateful/stateless hybrid 00:00:57.720 --> 00:01:03.400 Original insight: if signing only a few times statefully, signatures can be very compact. 00:01:03.920 --> 00:01:10.860 Model: a signing device generates a seed; you write the seed down; the state never leaves the device. 00:01:11.530 --> 00:01:16.710 If the seed is imported into a new device, that device must use the stateless path. 00:01:17.590 --> 00:01:21.670 Q: Why present both tree roots rather than a hash of both? 00:01:22.270 --> 00:01:35.900 Merging gives two options: (a) append the stateless pubkey root to every signature (~16 bytes) for black-box compatibility, or (b) omit it and lose black-box compatibility. 00:01:36.580 --> 00:01:39.600 Both roots are presented to preserve compatibility. 00:01:40.720 --> 00:01:41.660 Operational note 00:01:42.390 --> 00:01:48.630 Helpfully, state is public — the host in a hardware-wallet setup can act as belt-and-suspenders. 00:01:49.280 --> 00:02:11.690 if the signing device can store even a single hash securely as a commitment to the state, then the host device doesn't need to be trusted. The commitment offers a way for low-memory signers to authenticate the state given by a host. The host can even guess-and-check from blockchain data to re-derive the correct state based on the commitment. 00:02:12.580 --> 00:02:18.040 You cannot use stock SLH-DSA parameters for this. 00:02:19.220 --> 00:02:27.350 Multisig setups offer additional fault tolerance for state loss. Signers can check and store state for each other. 00:02:28.030 --> 00:02:34.230 This however requires consensus among signers, BFT, and additional interactivity. 00:02:35.470 --> 00:02:42.330 MuSig already has interactivity, so perhaps acceptable. However, very few actually use MuSig! 00:02:42.860 --> 00:02:58.450 Wallets could reserve specific state for the assumed state-loss scenario. If you lose state, you use one of the reserved counters, that way you don't have to fall back to the stateful path. You would however rollover to a new keypair thereafter. 00:03:00.230 --> 00:03:02.310 FXMSS — flexible tree structures 00:03:02.960 --> 00:03:08.400 To sign many times via the stateful path, balance the tree to maximize capacity. 00:03:09.240 --> 00:03:14.620 Tradeoff with unbalanced trees: smaller early signatures, larger later ones. 00:03:15.520 --> 00:03:32.700 Structures can be mixed and matched — the format is flexible enough to design exotic layouts (e.g., very small first signatures, switching to balanced trees at the 8th signature, after which sizes blow up to a constant but with a large budget). 00:03:33.810 --> 00:03:38.780 Recommendation: only two standard structures — balanced or unbalanced. 00:03:39.790 --> 00:03:43.850 Q: Do different structures need different consensus-level verifiers? 00:03:44.440 --> 00:03:49.990 No — the verifier is agnostic to tree shape, like the Taproot verifier. 00:03:50.900 --> 00:03:54.460 Q: How do you handle restoring on multiple devices? 00:03:55.310 --> 00:04:05.240 Each device must have a unique ID, which is mixed into the KDF when deriving keys. IDs can be public but seed stays secret. 00:04:05.950 --> 00:04:08.230 Some concerns about statefulness voiced: 00:04:08.530 --> 00:04:14.950 If you lose the state, you fall back on the stateless scheme that is huge (in terms of computation and size) 00:04:15.500 --> 00:04:24.280 State replay is a major challenge, you lose the funds. Managing data consistency is always a big issue. 00:04:25.240 --> 00:04:29.400 How to manage 2 different signers that share the same seed (happens often) 00:04:30.180 --> 00:04:35.260 How to manage potential TSS (even if it seems quite difficult to design) 00:04:36.050 --> 00:05:44.500 You would have to manage one state per key-pair. Users sometimes have 100s of UTXOs, 100s of accounts, 10s of different chains. All these states must be properly managed. Storing them in the device could be a possibility, however it doesn't scale, and comes with drawbacks when you need to recover your seed. So you could implement a merkle tree of monotonic counters, store the root in the device and the states outside. So that the device knows if the state is valid or not, and wouldn't sign with an invalid state. It requires a close collaboration between the software in the host and the device. Today the device is essentially stateless, the whole state is onchain and can be retrieved by the wallet. So, with SHRINCS, if a user creates his accounts with Ledger Wallet app, the state would be stored in the app. As soon as he goes to Metamask, these states wouldn't be shared... Potentially wallets could decide to only manage the stateless signature path 00:05:45.410 --> 00:06:08.810 It's also important to be able to recover funds ONLY from the seed. With SHRINCS, it's not that obvious. Recovering your wallet, you would lose the states and fallback to the stateless path. HOWEVER, you still need the Wallet ID to sign on the stateless path, that is for now not derived from the seed. We need a solution for that.