I’m sharing a new vault construction concept called B-SSL — Bitcoin Secure Signing Layer, a covenant-free Taproot vault design for self-custody that eliminates the risk of permanent key loss while maintaining full on-chain enforceability.
It uses existing Bitcoin primitives (Taproot, CHECKSEQUENCEVERIFY, CHECKLOCKTIMEVERIFY) and defines three spending paths:
• (A or A₁) + C after 2h–15d (CSV) — configurable user-initiated path
• A + B after 1y (CLTV) — fallback recovery
• (B or B₁) + C after 3y (CLTV) — custodian recovery / inheritance safeguard
A₁ and B₁ are mirrored backups of A and B.
Optionally, an off-chain “Convenience Service” (CS) can enforce delays and emit secret notifications to protect against physical attacks or coercion.
Goal:
This work is shared for peer review and discussion before implementation.
Feedback on Miniscript structure, policy expressiveness, and operational safety is very welcome.
I don’t think if you distribute the keys to yourself you can ever solve the problem of the loss of said keys , for the simple fact that one person who controls everything can very well lose everything .
Breakthrough like this rarely happen , a trustless key recovery system is the missing piece for self-custody to become for everyone, given the major blocker is undoubtedly the fear of losing the keys.
B-SSL marks the end between non-custodial and custodial because thanks to it everything will be non-custodial. The only task custodians will have is to hold the keys of the users while getting paid for it , except they can never ever steal the funds.
It’s a gift of freedom for every user who would otherwise never self-custody because of the fear of losing the keys (like, 80% of the world population?!) and I’m so blessed to have conceived it after 1y of hard work .
Could you describe a little more how the primary spending path works?
If a user wants to spend coins, they sign with key A and they need C to sign as well, correct? How are you implementing the CSV timelock on this spend path?
Let’s pretend that the user set this timelock to 1 day. The timelock will expire if their coins are in the wallet for more than one day, at which point, A and C can just sign with no delay. So what is the purpose this timelock serves?
I always imagined a vault was where a user sends coins to their wallet and can leave their coins in that wallet for an unspecified length of time and then enforce a delay when spending out of that wallet (usually by spending to an intermediate address), but I don’t think the construction you propose creates this effect, unless I’m misunderstanding something.
The purpose of signer C is to enforce time delay. While CSV starts to tick after transaction was received, the Convenience Service (which holds signer C) enforces time delay off-chain. Think of it as a secure environment that you can only interact for cosigning purposes. This environment will start counting time delay from the moment it receives spending transaction and will co-sign only when time delay has passed.
This environment will start counting time delay from the moment it receives spending transaction and will co-sign only when time delay has passed.
So if a user sets their CSV timelock to 15 days, that timer begins as soon as they send coins into the wallet and at this point key C cannot sign transactions because of the CSV timelock. But if more than 15 days pass, the CSV timelock expires and key C can sign. However, it sounds like key C will still not sign because key C is controlled by the CS which only begins counting down its time delay when it sees a transaction spending funds out of the vault.
If this is the case, why bother with the CSV timelock at all? I don’t believe I understand the purpose of the CSV timelock. Most users presumably would like to keep their coins in the vault for more than 15 days.
I invite you to focus on the end goal which is how to avoid two custodians to collude and then to assess the system in its entirety, if you analyze it part by part by not looking at the bigger picture then it could be difficult to make sense of it. If you want to join the Bitcoin Optech audio recap discussion by next Tue, maybe it could help :
Whitepaper: GitHub – B-SSL Whitepaper Repository
B-SSL uniquely achieves total key-loss resilience while preserving 100 % user sovereignty.