That’s pretty solidly left curve. Great work!

Here is a link to the podcast feed in case you want to subscribe early:

Bitcoin Optech

Podcast

Helping Bitcoin-based businesses integrate scaling technology.

This is a pretty interesting indeed: Quick summary courtesy of hark.now B-SSL_WP_Oct_11_2025.pdf _5 minutes_ Bitcoin offers perfect ownership, yet also perfect loss – a reality that discourages individuals from truly holding their own coins. The goal is to enable a model where users maintain independent control while benefiting from a cryptographically guaranteed recovery path, without introducing custodial trust or requiring protocol modifications. This is achieved through B-SSL, a trust-minimized vault structure built using existing Bitcoin consensus features. B-SSL leverages Taproot and Miniscript to commit multiple, independent spending paths within a single vault output. Each path incorporates its own key set and time-delay, creating a hierarchical security model. This structure provides a fast, configurable path for normal operation, a one-year fallback path ensuring continued sovereignty, and a three-year custodian path designed for unforeseen circumstances like disappearance or inheritance. The key structure is central to this design. A primary key, ‘A’, is held by the user, with a copy ‘A₁’ stored separately. A secondary key, ‘B’, is held by a custodian, alongside its copy ‘B₁’. A co-signer key, ‘C’, is utilized in both the configurable and long-delay paths. An optional convenience service, ‘CS’, can act as a gatekeeper, enforcing time-delays and emitting secret notifications – and may be self-hosted or custodian-hosted. All spending conditions are verified and enforced directly on-chain, ensuring a robust and recoverable self-custody solution. Spending is facilitated through three distinct paths, each designed with specific security and recovery properties. The primary operational path utilizes a configurable delay, ranging from two hours to fifteen days (relative CSV), activated upon user initiation. Keys A or A₁ combined with C govern this path, with an optional Convenience Service (CS) enforcing the delay and providing secret notifications to designated monitoring wallets. Should the CS be unavailable, users retain full control via fallback mechanisms. A crucial element is the User Fallback Path, secured with keys A and B and employing a one-year absolute CLTV. This ensures sovereign recovery capability irrespective of external service disruptions. Complementing this is the Custodian Recovery Path, utilizing keys B or B₁ alongside C, and a three-year CLTV. This path is specifically constructed to prevent custodian collusion; funds are inaccessible for three years post-inactivity, guaranteeing consensus-level security against premature movement. These paths are expressed through a Taproot/Miniscript policy, where each leaf remains independent – revealing one does not compromise the others. All delays are enforced directly by Bitcoin nodes through standard primitives like CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY, ensuring consensus-enforced timing. Beyond timing, the system provides resistance to both physical and cyber attacks through cryptographic delays and optional notifications, offering users critical reaction time. The CS itself operates as an off-chain layer, never possessing custodial power or private keys. Ultimately, the design prioritizes permanent recoverability and operates entirely within current Bitcoin rules, requiring no new opcodes. Its role is to release co-signature approval only after a configured delay, with the option to broadcast notifications of pending transactions. Custodial solutions present varying degrees of independence and security. A self-hosted configuration offers maximum privacy and control, relying on the user’s own infrastructure with minimal third-party dependence. Alternatively, a custodian-hosted configuration adds social and physical attack resistance through regulated external verification, though it offers less deterrence against physical coercion. Importantly, both approaches maintain full on-chain enforceability of the defined delays. To further mitigate risk, a secret notification mechanism can be implemented. When a transaction is initiated via the delay path, an encrypted notification is emitted to pre-defined guardian wallets or monitoring endpoints, providing actionable warning time before transaction finality and significantly reducing vulnerability to both physical and cyber attacks. Operational guidelines are critical; vault rotation should occur approximately every 2.5 years to avoid accidental custodian recovery path activation. Descriptors and public keys must be stored securely offline, and all paths thoroughly validated on regtest before mainnet deployment. Device compatibility with Taproot script-path signing and periodic verification of notification endpoints are also essential. Ultimately, this transforms Bitcoin custody into a demonstrably loss-resistant and attack-resilient process, replacing reliance on memory or trust with deterministic, verifiable spending policies secured by Bitcoin’s consensus rules. The introduction of human-safe time delays and recovery options makes long-term self-custody feasible for a wider range of users, institutions, and future generations. This paper is released for peer review and invites critique from developers, cryptographers, and security researchers.

Questions for author: 1. Why is CSV limited between 2h and 15 days? Is this a technical limit or a suggested limit for Custodians to offer. 2. Is/can there be an amount limit as well as or a combination of amount and time limits? So under 50,000 could be immediate, but over is 2h delay. (I guess no delay is somewhat gamable.) 3. Why in your taproot script is there A1 and B1 if these are supposed to be copies of A and B? 4. You mentions CS is optional, but does that then mean spending path 1 is impossible, leaving all spends to be 1 year delayed or does it just mean something else? 5. If you are notified of a spend that you did not authorize, what are your options? A+B are delayed for 1 year, if C is malicious, you are relying on trust to allow you to double spend and recover and even if not, don't you get stuck in a race to find who is willing to spend the highest fee? Define "malicious actor" as someone who found a copy of key A. You must trust the custodian to: 1. Enforce CSV in case of a malicious actor and send notifications. 2. Work with you to double spend the funds back to your control. So if the custodian and malicious actor work together, couldn't they just take your funds easily?

I forwarded your questions to the author via telegram (I don't think he is on nostr) and if he replies I will try to remember to post his replies I will probably forget though

Thanks, I actually thought you would ask in the pod but I guess you saw it just now. I appreciate the follow up

Did you get any replies? @Super Testnet

Not yet. I will try to ask him on the podcast today, which we start recording in an hour. Thank you for the reminder!

I finished the podcast, but it went pretty poorly. My connection cut out partway through the first question I was asked, and when I finally managed to reestablish it, no one could hear me. So I did not get to ask your questions to the author. I did, however, send him the questions on telegram again, so we'll see if he replies.