Skip to content

ilghan/bssl-whitepaper

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

7 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

B-SSL: Bitcoin Secure Signing Layer A Covenant-Free Vault Architecture for Loss-Resistant, Attack-Resilient Self-Custody

📄 Full Whitepaper: B-SSL_Whitepaper.pdf

Author: Francesco Madonna – BitVault SA Contact: [email protected] License: Apache 2.0 Peer Reviewed by: Mordom, ….. [Shoot me an email and have your name added here]

Abstract Billions of dollars in Bitcoin have been permanently lost because users misplace or destroy their private keys. At the same time, custodial solutions reintroduce the counterparty risk Bitcoin was designed to eliminate. This paper presents B-SSL (Bitcoin Secure Signing Layer) — a trust-minimized vault structure that makes irreversible key loss and physical compromise practically impossible, using only existing Bitcoin consensus features. It is a Taproot-based, covenant-free system that layers time-locks, mirrored keys, and optional secret notifications to provide recoverable, human-safe self-custody. B-SSL requires no new opcodes, no forks, and can be deployed on Bitcoin mainnet under current consensus rules. This document is released for academic and technical review purposes only.

1. Motivation Bitcoin offers perfect ownership but also perfect loss. Every lost key discourages individuals from holding their own coins. The goal of B-SSL is to enable a model where users can hold Bitcoin independently, yet maintain a cryptographically guaranteed recovery path — without introducing custodial trust or modifying the protocol.

2. Design Overview B-SSL uses Taproot and Miniscript to commit multiple independent spending paths within a single vault output. Each path has its own key set and time-delay. Together they create a hierarchical security model:

  1. A fast, configurable path for normal operation.
  2. A one-year fallback path ensuring sovereignty.
  3. A three-year custodian path for disappearance or inheritance events. All spending conditions are verified and enforced directly on-chain.

3. Key Structure Key Holder Description A User Primary key. A₁ User Copy of A kept in a separate location. B User Secondary key. B₁ Custodian Copy of B held by custodian. C Custodian Co-signer key used in configurable and long-delay paths. CS Convenience Service Optional gatekeeper enforcing time-delays and emitting secret notifications. May be self-hosted or custodian-hosted.

4. Spending Paths

Path 1 — Configurable User Path (2 h – 15 d CSV) Keys: (A or A₁) + C Delay: Configurable 2 hours – 15 days (relative CSV) Gatekeeper: CS (optional) Used for ordinary operations. When the user initiates a spend, CS can enforce the chosen delay and emit a secret notification to monitoring wallets or guardians. If the CS is unavailable, the user still retains full control through fallback paths.

Path 2 — User Fallback Path (1 y CLTV) Keys: A + B Delay: 1 year (absolute CLTV) Gatekeeper: None Ensures that users always maintain sovereign recovery capability, regardless of service availability.

Path 3 — Custodian Recovery Path (3 y CLTV) Keys: (B or B₁) + C Delay: 3 years (absolute CLTV) Gatekeeper: None This path makes impossible for the two custodians to collude and steal funds. It also acts as a dead-man or inheritance safeguard. Only after three years of inactivity can custodians jointly recover funds; before that period, spending is impossible at the consensus level.

5. Taproot / Miniscript Policy tr(, or( and(or(pk(A), pk(A1)), and(pk(C), older(VAR_CSV))), # 2h–15d (A/A1 + C) or( and(after(H_1Y), and(pk(A), pk(B))), # 1y (A + B) and(after(H_3Y), and(or(pk(B), pk(B1)), pk(C))) # 3y (B/B1 + C) ) ) ) VAR_CSV is configurable between 2 hours and 15 days (72–10 800 blocks). Each Tapscript leaf is independent; revealing one does not expose the others.

6. Security Properties

  1. Consensus-enforced timing: All delays are enforced by Bitcoin nodes through CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY.
  2. Custodian non-collusion: The 3-year CLTV guarantees that no custodian combination can move funds prematurely.
  3. Physical and cyber-attack resistance: The combination of cryptographic delays and optional secret notifications provides users with reaction time against coercion or hacking attempts.
  4. Permanent recoverability: The one-year user path ensures that coins remain recoverable under any external failure.
  5. Covenant-free: Operates with current Bitcoin rules — no new opcodes requiredù.

7. The Convenience Service (CS) The CS is an off-chain enforcement and notification layer. It never holds private keys or custodial power. Its role is to release co-signature approval only after the configured delay and optionally broadcast notifications of pending transactions.

Mode Hosted by Advantages Considerations
Self-hosted CS User’s own infrastructure Maximum independence and privacy. Offers less deterrence against physical coercion.
Custodian-hosted CS Third-party or regulated custodian Adds social and physical-attack resistance through external verification. Minimal reliance on third-party uptime.

Both modes preserve full on-chain enforceability of the delays.

8. Secret Notification Mechanism When a transaction is initiated through the configurable delay path, the CS may emit an encrypted secret notification to pre-defined guardian wallets or monitoring endpoints. These entities can verify that a spend attempt has been initiated and alert the user before the time-delay expires. This hybrid of on-chain enforced delay and off-chain notification significantly reduces the risk of successful physical or cyber attacks by providing actionable warning time before transaction finality.

9. Operational Guidelines • Vault rotation: approximately every 2.5 years to avoid accidental activation of the custodian recovery path. • Backup retention: store descriptors and public keys in secure offline media. • Testing: validate all paths on regtest before mainnet deployment. • Hardware support: confirm device compatibility with Taproot script-path signing. • Monitoring: periodically verify notification endpoints and alert channels.

10. Impact B-SSL turns Bitcoin custody into a loss-resistant and attack-resilient process. It replaces reliance on memory or trust with deterministic, verifiable spending policies secured by Bitcoin’s consensus rules. By introducing human-safe time delays and recovery options, it makes long-term self-custody feasible for individuals, institutions, and future generations.

11. Call for Review This paper is released for peer review and academic analysis. The author invites Bitcoin developers, cryptographers, and security researchers to test and critique the B-SSL design.

Feedback and correspondence can be directed to: 📧 [email protected]

12. Disclaimer This document is provided for research and discussion purposes only. It does not constitute a commercial product description or implementation disclosure. Certain aspects of the system may be subject to patent applications filed or pending by the author or BitVault SA. Publication of this paper does not waive or transfer any intellectual property rights.

13. Conclusion B-SSL demonstrates that secure, recoverable self-custody can be achieved today using standard Bitcoin primitives. By integrating layered time-delays, mirrored keys, and optional secret notifications, it provides a vault design that is both technically sound and human-centric. Bitcoin custody no longer has to choose between security and survivability — B-SSL unites both.

----- END -------

About

Public concept whitepaper: Bitcoin Secure Signing Layer (B-SSL)

Resources

License

Security policy

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors