Bitcoin Forum

Hey all, I had a random idea and I’m curious if anyone’s tried something like this. Please, no “just use Coinbase” or “2-of-3 multisig” replies—those aren’t what I’m talking about. 

Imagine a Bitcoin wallet with an Emergency Access feature, kind of like Proton’s system for email/files: 

• You pick a handful of trusted contacts (friends/family).
• If something happens and you can’t access your wallet, they can request access.
• There’s a wait period (a few days?)—during that time, you could approve or deny. If you do nothing, access is automatically granted.
• Ideally, it would preserve maximum security, so your keys aren’t exposed unnecessarily, but the funds are accessible to your trusted people.
  

I know it sounds wild—maybe it requires some kind of clever cryptography or smart contract wizardry—but I wanted to put it out there and see if anyone has brainstormed anything similar. 

Again: please skip the standard “use multisig” or “use Coinbase” responses—looking for something genuinely new or creative.

You’ve just explained what you want us to skip out of it but, to stay on course with this thread, skipped!

I don’t see how we would keep maximum security by having several persons to be an access point to our wallets in any loss or damage eventuality. What you end up with is more dangers to your wallet. This is because, though these guys might be trusted, it doesn’t mean they would always stay out of trouble or the company they keep would always be good ones.

One thing could lead to another and the need to access your wallet for some way out funds can arise, you don’t get to do nothing about some prompt because you didn’t notice and your funds is gone.

What you are suggesting isn’t weird, it’s typical with adding recovery emails to an email address. I just don’t think it suitable for Bitcoin wallet. There is security in privacy and that doesn’t mean, you don’t duplicate your seed phrase for accessibility elsewhere while keeping it private.

Let me start with this thing doesn’t have any business with bitcoin network, the bitcoin doesn’t know or care about anything related to how you access you bitcoin on the blockchain, how your private key or rather seed phrase that is supposed to be use for this been handle doesn’t actually concerns the network, that’s the dependent on your wallet client and custodianship

Who do you actually request access from, because if you use a non-custodial wallet only you have access to the private keys and if they have a feature that allows you to add members so that they can give them access later on request then that’s not a self custodial wallet but rather custodial wallet where the wallet developer itself has access to those keys or seed phrase and you no what that means, as long as it is not only you that have access to your keys then it is no longer safe

There can be wallet designed for this or even exchanges but definitely this will be centralized platforms that will definitely have access to you and your added members details plus the wallet keys to and this is in no where close to anything Maximum Security.

The ultimate maximum security is simply been your own bank and no other access to your keys, anything else is redundancy

This can only be done through Centralized exchanges/wallets because using non-custodial wallet the one point one can access your bitcoin is through your seed phrase/private key without it nothing can be done since you said multi sig is not a consideration here.
This definitely shows your ideal doesn't preserve maximum security.

How about time lock? It is not the same to what you explained but it is similar. The only difference is that not your family that will make the transaction but you and set it to the time the transaction will be broadcasted into the mempool. You can set it to be a month, 3 months, 6 months, a year or anytime that you want. If you are still alive, you can replace the transaction or cancel it and later make another time lock transaction.

Or third party holding platforms, OP can't take out self custody and expect maximum security. In a simple shell, OP can give out his private keys to trusted individual, it can be hidden in a vault only to be accessed in any emergency case, in this way maximum security has been bridged because not only him have access to the vault which holds private keys to the wallet.

This is still another risky thing to do because when you give this permission you have shared the control of your account and if something might happen and you accuse the two person it will bounce back on you, there is nothing you could do to them because you are the one that allowed it so actually if adding an emergency access is through this means I will confidently decline it because is unsafe measures besides just normal savings of wallet could also be this emergency access you are saying because is were you would run to when you cannot access your account. those emergency access you proposed looks kind of multisig method.

bitcoins are safe in my non custodial and open source wallet and I am the only person is responsible for my bitcoin. No one can request access to my non custodial wallets, and there should be no automatically granted access to my wallets - that truly sucks.

You don't understand when writing "keys are not exposed but trusted people can access my bitcoin fund. They can not have acces if they don't have my bitcoin private keys.

"Not your keys, not your coins" is a famous saying and advice in Bitcoin.
I have my Bitcoin private keys, I have my bitcoins, and I don't want anyone to access it without my allowance and inheritance awarded to them.

Using Locktime for inheritance planning, backups or gifts (https://bitcointalk.org/index.php?topic=5180850.0)

Why not keep the keys where you are the only one that can access this, and very accessible for you , why you need friends, this supposed to be anonymous, do you wan't to expose to others funds, actually this will encourage crime, what if they found out you have lots of money and they wan't to take it, this will put your life in danger, i would not suggest this things, even in centralized exchange, this is not how it works.

To entrust other parties with your seed phrase or wallet keys might be a good ideal on granting accessibility to those trustee in case of rightful owners absence while need be for beneficiary to have access to the wallet. If be it that it is to tighten security access with a corporative or organization wallet address, multisig vault could be okay while it maybe frustrating or requiring so additional process to have access to the wallet if total signatories are not signed in at the needful time so we most note it potential accessibility and security risks.
But if we must entrust our private keys to others, for the benefit of not over trusting, activating a lock vault will be very necessary so that, until the timeframe to have access to the wallet is matured before you can process outgoing transactions with the wallet. This may not ideally be the best but would give better safe confidence while you are still alive as the chief custodians.

Technically it can through Bitcoin script
A programming language that helps in creating complex transactions involving specific conditions.

Conditions like one OP is speaking about.

What I can think of is using Bitcoin scripts. One on Timelock
can help with that.
One path that would verify your Pubkeys directly Incase of an override and the other path to meet the conditions set by you
Including the wait period which you can measure in block time.


There's a current BIP in 2025 BIP 347 OP_CAT that would make such vault action easier

I would not want to use such a wallet, just as i do not recommend that people opt-in for Ledger recover service. Features like this may sound helpful, but over all it gives a false sense of security. I do not want to use a wallet that has the possibility of sending out my seed phrase, it does not even matter if i opt-in or not, just for the fact that it is possible is a red flag.

If you truly have 'trusted' people that you will pick for something like this, then just use a recommended wallet and give your seed phrase backup to the said people, problem solved.

You use locktime. When you use locktime, it is either you use a block height or a certain time to prevent miners from adding your transaction in the blockchain until that time is over or your transaction will be mined after the specific block height that you set it to. You can read this if it suits what you want.

https://learnmeabitcoin.com/technical/transaction/locktime/

No idea why you wrote something completely wrong. People can use Shamir's Secret Sharing to accomplish this and other ways. It is quite easy and preserves security, no CEX is needed. https://www.ledger.com/academy/topics/security/shamirs-secret-sharing


Don't do this part on chain, so many things can go wrong and there are many limitations. You can do this with some key shards stored in bank vaults or other vault operators. This has a collusion by family and safe operator attack possibility, but that is a very unlikely scenario. No reputable company would risk destroying itself to steal from a single average person such as you.

This is terrible advice and can be devastating. In cases where access to a seed or private key is shared, there is no way to prove who stole coins. This means that it could be you trying to frame your trusted people, it could be them, or it could be a third party that somehow gained the seed from you or them. You could lose valuable people just because someone managed to somehow secretly steal the seed from you. Horrible.

Even the first thing in your list is already questionable. But perhaps if you change the "few days" into few months, it's better. Otherwise, you might be surprised your wealth is gone after a week-long retreat, vacation, adventure, pilgrimage, or whatever.

I can't wrap my head around the setup in which your funds are protected by private keys which you alone know and control and yet your trusted contacts may actually access those funds. Doesn't this setup imply another party that's actually in control of your funds? Or is this like a time-lock feature which the owner himself/herself initiated?

For me, it's probably enough that you write down your backup. In case of emergency, your family might have to turn the house upside down to look for it. If they fail, then perhaps your coins are meant to perish with you.

If there are automatic mechanism of assigning access to my bitcoin, Bitcoin private keys, wallets without me and my signature from my Bitcoin private key, I see it is extremely dangerous and I don't support any idea to develop it technically.

It should be ignored at the start rather than trying to develop it, test it with testnet and make the Bitcoin community separating. It will trigger another scam wave with many shitcoins created in names of Bitcoin forks while true Bitcoin users who understand about Bitcoin blockchain properly don't need this development and definitely don't need to have more scam Bitcoin forks.

How Many Bitcoin Forks Are There? You will be surprised!!! (https://bitcointalk.org/index.php?topic=5221882)

I have heard about the SSS but the scenario you gave something different and it means the wallet have to be aware of these trusted users. Anyway your link was still helpful to get better idea of SSS, the take here is rather than using ledger or unknown third party, one will opt for their trusted friends and family, if I'm correct?

And all these will be done through the wallet like how proton mail/files operate and being signaled with time limit(days) if such access will be granted by the actual owner?

I understand what you mean here, but at the end, it still renders access to a third party from knowing about our worth or sharing control with us regarding the use of our wallet, which this feature may only be implemented by centralized services or third party platforms that are willing to offer for such, but i don't see it a good idea anyway from my end, but you may never get the kind of feature from a non custodial wallet and the developers cant implement on such.

I kinda get what you are trying to say, but I must correct you. The wallet is not aware of anything it is not a living thing. When you create the secret sharing setup, you decide on the number of shards and the number required to re-assemble the wallet. For the last part, definitely only do it with either yourself or with trusted parties. Do not involve Ledger or third parties in this.

No digital services need to be involved, and this is more secure and reliable. I will give a simple example that is not optimized, but just it shows how it works. You create a 3 out of 5 sharding setup, you give 1 to your wife and 1 to your best friend. You keep one of yours in a bank vault that stipulates should you be unable to access it for a few days, that your wife can enter. In this way, if you are in a coma or something like that your wife can get your shard, combine it with hers and with your best friend's shard to recover the wallet.

I don't think OP is referring to access recovery but giving accessibility to third parties as trustees to have access to the wallet just in case of emergency whereas, the initiated or biological owner of the Bitcoin wallet is not present to have access or make used of the Bitcoins in the wallet.
So it is going to be like trusting the wallets securities keys to the authorised third parties while the wallet owner also holds the accessible keys for the Wallet.

This is not going to be a multisig because the privacy keys are the same which means just a key in of the one entry recognized keys would access the wallet. Like said, this is going to be weird trusting your private keys to other parties but though for some inevitable future occurances, it is okay if only we trusts the right one and in a case like this, trusting your privacy to more than one person would be more risky because you would not who will be responsible in term of funds lost in the wallet.

So without undermining how risky this trust issues maybe, using the timing lock wallet feature will atleast strengthen some loopholes but yet safety is not guaranteed in the case of timeout. Also, consider your need to sell make use of your funds in an emergency if need be.
However, this feature is an already existence as it part of the Blockchain mechanism. So no need to experiment like it is not an already existing feature @ OP.

This concept is not new, dude.  It is already addressed by dead-man's switches (Sarcophagus), multisig safes (Gnosis Safe), Shamir secret-sharing & social recovery wallets (Argent).  However you know each has drawbacks,  Shamir requires safe share custody, guardians increase the risk of social engineering & dead-man relayers can malfunction.  By default I do not support auto grant. you could go for design that includes hardware-wallet multisig (2-of-3) & long timelocks, along with Shamir backups or a decentralised relayer for emergency release.  you know such smart idea just build for abuse first, not convenience, lol..

There are two solutions.
1. A centralized solution in which a custodian or executor controls the bitcoins and who 'trusted people' can appeal to.
2. A decentralized solution in which the Bitcoin protocol can be used.

#1 is something like Coinbase or Casa and #2 is multi-sig. Why do you reject the obvious solutions? Why do you look for something more complex or obscure?

If you want a different solution, please provide a use case in which those solutions are inadequate. Otherwise, the best answer is always going to be “just use Coinbase” or “2-of-3 multisig”.

Note that there are different ways to achieve multisig other than a Bitcoin multisig transaction. One is to use the Shamir's Secret Sharing (https://en.wikipedia.org/wiki/Shamir's_secret_sharing) method to share a private key among multiple people. It is effectively an external form of multisig.

Honestly, I don’t see Sarcophogus working for Bitcoin at all. For one, it’s built on Ethereum — why would I want to tie my Bitcoin to a completely different network? Then there are the attestation fees, which add up if you try to use it long-term, and the whole resurrection-date thing is impossible to predict reliably. Plus, it depends on oracles or monitoring nodes, so if any of those fail, your emergency access fails too. Conceptually it’s interesting, but practically it just doesn’t solve the problem for Bitcoin.

you dont need to use Sarcophagus, mate. i quoted that to say that the concept is already in the market, nothing new at all.. for bitcoiner  the best play i would suggest building a native solution, such as hardware wallet like Trezor 2-of-3 multisig with Shamir based backups & long timelocks, is a better strategy for Bitcoin since it keeps it user controlled, on chain & self sovereign. try to avoid Ledger cause the new version has backdoor able to backup keys, though they denying such claim by saying bla bla..

This doesn't sound wild. It simply sounds stupid to me.
1.What kind of "emergency access" feature has a waiting period of a few days? Waiting for a few days to get the funds defeats the whole purpose of "emergency access" to the funds.
2.Do you realize how weak the security of such wallet would be, if several friends and family members have access to the funds inside the wallet? What if someone scams your friends and family? What if someone kidnaps you and asks them to release the funds?
3.Not exposing the private keys won't matter at all, since several people would have access to the funds.
4.Cold wallets don't have a centralized entity, which would decide which funds should be released for valid emergency purposes and which funds won't be released, because someone is lying and trying to scam the wallet owner.

@davis196

So far, no one has offered a viable solution. I still believe a decentralized mechanism *must* exist—one that depends solely on the Bitcoin network itself, without relying on any custodians or third parties.

There is not, it has been explained to you already. What you want requires smart contracts, which are not available on Bitcoin.

Since you seem to be using chatGPT, you can ask it yourself whether this functionality looks like something for a smart contract.