Tools: Idea for a Bitcoin wallet backup service that is non-custodial and fully respects self-sovereignty and privacy

The Workflow: Using the Bank as a "Dumb Pipe" ## Phase 2: The Recovery (and Inheritance) ## The Threat Models (How everyone is protected) ## 1. User vs. "Rogue Company" (The Imposter Attack) ## 2. Protection: Company vs. "Lying User" (Defamation) ## 3. Protection: User vs. Government/Censorship ## 4. Protection: Service vs. Geopolitics ## Summary The ethos of Bitcoin is "Not your keys, not your coins." But the terrifying reality for most people is: "Lose your keys, lose your life savings." We are biological beings. We forget passwords, our houses catch fire, we make mistakes, and eventually, we die. Humans are messy, and that’s okay. Banks were originally invented to solve this problem—to provide physical security for our assets when we couldn't protect them ourselves. Today, we reject banks because of custody and censorship risks. But what if we could use the Bank's infrastructure (Identity Verification) without giving them Custody of our coins? I have thought of a protocol architecture that uses BitVM, Smart Contracts, and Bank Wire Memos to create a non-custodial backup system. It allows for inheritance, recovery, and protection against both hackers and rogue companies. This same concept can be applied to protect the user's Nostr keys, or for that matter, any confidential information. I want to share the architecture and the mitigation of specific threat possibilities - User vs. Company, Company vs. User, and Government vs. User. We don't need to partner with banks. We just need to use their output. Banks have already done the heavy lifting of verifying that you are a real human (KYC). We just need to use their public ledger. A Wire Transfer is a cryptographic signal that links a physical identity to a digital action. While I am focusing on wire transfer, note that here we can use other means like Notarized Affidavit, Personal Cheques, etc. also in place of or along with wire transfer to verify identity and create a paper trail. Phase 1: The Binding (Safety Before Key Generation) Years later, you lose your device. Or perhaps you pass away, and your heir needs access. Note for Inheritance: This solves the "Dead Man's Switch" problem. Heirs may not have the wallet's seed phrase, but they just need access to the bank account, and they perform a simple wire transfer. This is where the protocol shines. It protects the User, but it also protects the Service. Scenario: A user initiates a recovery, gets his keys, and then publicly claims: "The Service hacked me! I never asked for this recovery!" This is the critical defense mechanism. Scenario: A hostile government forces the Company (or seizes their servers) to initiate a recovery for your wallet, claiming they are you. You now have two options: Option A: The Veto (If you are safe) You use your original wallet or a secondary key to VETO the transaction on-chain. The attack fails immediately. Option B: Plausible Deniability (If you are under duress) If the government is standing over your shoulder forcing you to let the timer run out: Scenario: The Service's servers are destroyed or seized in a specific country. We are trying to bridge the gap between "Code is Law" and "Humans make mistakes." By using the Wire Memo as a high-fidelity, we can create a system where: Future Evolution: Native Bank APIs & Digital Signatures Currently, this protocol relies on a functional "hack" of the legacy system: the wire memo. This is also more of an approach for kick starting the process. However, as adoption grows, banks will recognize the utility (and market potential) of serving as a formal identity anchor for digital assets. We anticipate a shift toward direct API collaboration between banks and Backup Services. Instead of a service employee manually inputting the 8-to-10 digit code from a screen, the bank’s API could push a confirmation directly to the Service. Crucially, this allows us to integrate Bank-Signed Digital Signatures directly into the BitVM Zero-Knowledge circuit. The "Witness" essentially evolves from a legal paper trail into a cryptographic proof. This eliminates the need for human verification at the Service level, reduces the scope for error, and creates a fully automated, trust-minimized bridge between fiat identity and crypto custody. I believe this is how we onboard the next billion users—by giving them a safety net that relies on math and existing infrastructure, not on trusting a CEO. I am looking for feedback: Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - The Handshake: You connect a new Wallet (Hardware wallet preferred for security, but Software wallet works too) to the Backup Service Company's open-source client via internet. An End-to-End Encrypted (E2EE) tunnel is established. - The Code: The Wallet displays an 8-10 digit code on its screen. This is a hash of the current session. - The Signal: You visit your bank for a wire transfer. You send a "Dust" wire transfer (e.g., $1.00) to the Service' bank account. In principle, the backup service should reject wires which came with "Online Transfer" tag in consideration of the risk of hack of the user's net banking account. Crucial Step: In the Memo Field, you enter that 8-10 digit code. - Crucial Step: In the Memo Field, you enter that 8-10 digit code. - The Verification: The Service receives the wire. The employees see "John Doe" sent $1.00 with the correct code. They now know: "The person controlling John Doe's bank account is the person holding this connected Hardware Wallet." In the next step, when the hardware wallet connects to the company service software, the system first verifies that the 8-to-10 digit code generated by the wallet matches exactly what is recorded in the company's database for that specific session. This confirms that the wallet has been rightly identified as belonging to this specific user, effectively linking the wallet to the user via the bank's human identification process. - The Generation: To ensure the Service acts as "Blind Storage" and never sees the seed phrase as plain text, we use Witness Encryption logic via BitVM/Zero-Knowledge proofs. For setting the backup (Phase 1) of the original wallet, we use "Blind" Encryption Protocol (Witness Encryption). Instead of giving the Service a key, we use Commutative Encryption. Setup: You connect the wallet back to the service's client, your Wallet generates a random key ($K$) and encrypts the Seed Phrase. The Puzzle: Your Wallet encrypts $K$ into a Mathematical Puzzle (Witness Encryption). The rule is: "This puzzle can only be transformed if a valid Bank Wire Proof + 7 Days Time is provided." Storage: The Service stores the Encrypted Seed and the Puzzle. They physically cannot decrypt it because they lack the "Witness" (the Proof of Wire) to solve the encryption equation. - For setting the backup (Phase 1) of the original wallet, we use "Blind" Encryption Protocol (Witness Encryption). Instead of giving the Service a key, we use Commutative Encryption. - Setup: You connect the wallet back to the service's client, your Wallet generates a random key ($K$) and encrypts the Seed Phrase. - The Puzzle: Your Wallet encrypts $K$ into a Mathematical Puzzle (Witness Encryption). The rule is: "This puzzle can only be transformed if a valid Bank Wire Proof + 7 Days Time is provided." - Storage: The Service stores the Encrypted Seed and the Puzzle. They physically cannot decrypt it because they lack the "Witness" (the Proof of Wire) to solve the encryption equation. - Crucial Step: In the Memo Field, you enter that 8-10 digit code. - For setting the backup (Phase 1) of the original wallet, we use "Blind" Encryption Protocol (Witness Encryption). Instead of giving the Service a key, we use Commutative Encryption. - Setup: You connect the wallet back to the service's client, your Wallet generates a random key ($K$) and encrypts the Seed Phrase. - The Puzzle: Your Wallet encrypts $K$ into a Mathematical Puzzle (Witness Encryption). The rule is: "This puzzle can only be transformed if a valid Bank Wire Proof + 7 Days Time is provided." - Storage: The Service stores the Encrypted Seed and the Puzzle. They physically cannot decrypt it because they lack the "Witness" (the Proof of Wire) to solve the encryption equation. - Risk: Can the Service simply lie, claim they received a wire, and secretly decrypt my data? - Defense: The "Loud" Timer. The 7-Day Time-Lock is a Blockchain Logic, not a server clock. To start the timer, the Service must publish a "Recovery Initiation" transaction on the public ledger. You cannot hide a transaction on a public blockchain. The moment they press that button, the Watchtower detects the on-chain event and alerts you. Since the Encryption Puzzle requires the completion of the 7-day on-chain period, the Service cannot decrypt anything until the time is up. This gives you 7 days to broadcast a VETO transaction, which creates a mathematical block that makes the puzzle unsolvable forever. - The 7-Day Time-Lock is a Blockchain Logic, not a server clock. - To start the timer, the Service must publish a "Recovery Initiation" transaction on the public ledger. - You cannot hide a transaction on a public blockchain. - The moment they press that button, the Watchtower detects the on-chain event and alerts you. - Since the Encryption Puzzle requires the completion of the 7-day on-chain period, the Service cannot decrypt anything until the time is up. This gives you 7 days to broadcast a VETO transaction, which creates a mathematical block that makes the puzzle unsolvable forever. - Result: The Service holds your backup, but they cannot read it. They just act as a storage locker. - The 7-Day Time-Lock is a Blockchain Logic, not a server clock. - To start the timer, the Service must publish a "Recovery Initiation" transaction on the public ledger. - You cannot hide a transaction on a public blockchain. - The moment they press that button, the Watchtower detects the on-chain event and alerts you. - Since the Encryption Puzzle requires the completion of the 7-day on-chain period, the Service cannot decrypt anything until the time is up. This gives you 7 days to broadcast a VETO transaction, which creates a mathematical block that makes the puzzle unsolvable forever. - The Request: You (or your heir) buy a new wallet. You connect to the Service. - The Proof: You (or the heir via probate/law) send another $1.00 wire from the registered bank account. You include the new session code in the Memo. - The Match: The Service matches the Sender Name and the Memo Code. - The Time-Lock: The Service initiates a "Release Transaction" on the Smart Contract with a 3-to-7 Day Time-Lock. The count of the days depends on how much delay the user configured while opting the service. - The Release: When the Time-Lock and Bank Wire conditions are met (and no veto is issued), the Service does not decrypt the blob. The Smart Contract performs an Atomic Re-Encryption. It applies the New Wallet's Key (Key B) on top of the blob, and then effectively "subtracts" Key A. The ZK Circuit proves: "I know the Witness (Wire Transfer + Time) that decrypted Key A. But the ZK Proof does not reveal the Witness itself. The public (and the Service) only sees the Proof (a small string of characters) that says "This operation was valid," not the underlying secret that made it valid, therefore the old "decryption key" for Key A (the Witness) does not become public for anyone to use it to decrypt the original blob. - The Result: The blob transitions from being locked by the Old Wallet to being locked by the New Wallet without ever being decrypted in the middle. The Service holds the data, but the math prevents them from reading it. The user's wallet decrypts the data with Key B after receiving it. Funds are recovered. - Risk: What if a rogue employee at the Service tries to fake a request to steal your backup? - Defense A (Encryption): The employee cannot decrypt the blob. They only steal useless cyphertext. - Defense B (The Smart Contract): The logic is on BitVM, not the company server. The company cannot force an immediate release. They must wait the 7 days. - Defense C (The Watchtower): During that 7-day window, you (the user through his phone, email, and wallet) get an alert through a watchtower service. You can use your original wallet to VETO the transaction on the Smart Contract. You can prove to the public that company was trying to steal funds, as you didn't make any wire transfer request. If proven guilty then the company would have reputational and legal consequences. - Defense: The Service points to the Bank Ledger. They can publicly prove: "Here is a Wire Transfer from your specific Bank Account, on this specific date, containing the specific 8-digit Code that authorized this release." - Because the Wire Transfer is a regulated financial event, it acts as an immutable "Proof of Intent." The user cannot claim impersonation unless they admit their own bank was compromised. Supplementary checks (Video calls, SMS, Email communication) can exist as layers, of which the company can have a record with themselves - these layers may work in the same way as users are assisted by social media or financial companies when the user has forgotten the credentials for his account on their platform, but the "Base Layer" is the financial/legal record. - The Company is forced to press the "Wire Received" button even though you didn't send one. - The Defense: The 7-Day Timer starts. You (the user) receive an alert on your phone: "Recovery Initiated." - You use a special "Duress Signal" (e.g., pointing the recovery to a specific decoy address). - The Zero-Knowledge Proof generates a valid-looking decryption key. - However, this key decrypts a "Dummy Wallet" containing a small amount of "decoy" funds. - The government sees the wallet open, sees the funds, and believes they have succeeded. - Crucially: Because of the Zero-Knowledge nature of the proof, they cannot mathematically prove that this is a dummy wallet. Your real stash remains hidden and encrypted forever. - Defense: Since the data is encrypted blobs, it can be stored on IPFS or decentralized servers globally. As long as the user has their identity (Bank Account) and the Service has the "Oracle" key to verify the wire, the service can be spun up anywhere in the world. Furthermore, each user can avail service from multiple backup companies so that if one of them is knocked down then he has other ones as backup. - No new KYC is needed (Your bank already did it). - No Custody is given (Everything is encrypted client-side). - Inheritance is solved (Legacy banking rails handle the access control). - Are there edge cases in the "Dust Transaction" I'm missing? - Would you feel secure knowing your encrypted backup is held by a service, protected by a 7-day time-lock and your regional bank?