Nostr Web Client

The Bitcoin SSL paper is interesting. I will hopefully go on the Bitcoin Optech Podcast on Tuesday to discuss it with the author. He thinks he has a solution to the Vault problem that could give a lot of people peace of mind, and I think he is probably right. Here's why.

First, here's a link to the paper: https://github.com/ilghan/bssl-whitepaper/blob/main/B-SSL_WP_Oct_11_2025.pdf

Their model has users put funds into a vault with a timelock of max 15 days til they can spend it via the "cooperative" path, otherwise there is a "sad path" by which the user can unilaterally recover it after 1 year, or a "very sad" path by which a custodial service can sweep the funds for the user after 3 years.

The 15 day timelock on the "happy path" is meant to insure users against kidnappers, who are less likely to kidnap you for your bitcoins if they have to keep you captive for 15 days and convince a service provider to cosign your tx.

But this protection is undermined if you send your money into the vault around the time you sign up for the vault service and then let it sit there for 15+ days. If you did that, the timelock would expire, and kidnappers would not have to worry about keeping you captive for 15 days.

To fix this, you either have to stop your money from entering the vault until you are preparing to spend it, or you have to cycle it: every 15 days, you must send your money out of the vault and straight back into it again.

Thankfully, both options are doable with presigned transactions, which can be created and stored when you sign up for the service. So this problem is fixable without introducing extra liveness assumptions for the user.

Also, if cycling is used, there are regular mining fees to pay, but these can be rolled into the service fees charged by the vault service provider or VSP. The VSP can just charge their users a monthly or annual service fee and then use some of that money to broadcast/pay for their cycling transactions without further action needed by their customers.

Besides transaction cycling, I came up with another, cheaper solution and proposed it to the author, which is this: have the user's money start off in Key Q. Sign a transaction that moves the money into the vault, then delete Key Q, and store the signature with the service provider, as well as keeping a copy yourself.

As a result, if you get kidnapped, your money can *only* enter the vault, where it then has to wait 15 days. This method avoids the extra costs involved with transaction cycling, and is simpler. But it requires secure key deletion, which is difficult to do, though not impossible.

I think this vault proposal may give a lot of people peace of mind. I had a conversation with a nocoiner recently and his first question was, "what if someone kidnaps you and demands that you send them your bitcoins or they will kill you?"

I wish I had known about this idea so I could tell him how bitcoin fixes this.

Tune in to Optech Podcast on Tuesday for more!

Affinity**For*Disobedience 3mo ago

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.

Reply to this note

Please Login to reply.

Discussion

No replies yet.