Future Proof Bitcoin Storage: A Taproot Vault with Multi-Era Spending Paths...

[kanftka]

Hello everyone,

So for some time now, I’ve been doing some research, nothing too fancy though, but just something I kept thinking about and started looking into bit by bit. The idea was simple: If someone wants to keep bitcoin for a long time, like 10 years, 15 or even 20, how do they make sure they or someone they trust can still access it without depending too much on hardware or wallets that might not even exist by then?

I know most people just store their BTC with a seed phrase and call it a day, or maybe do multisig or hardware wallets, but honestly I don’t fully trust those setups long term. A seed phrase can get lost, hardware wallets can get bricked, and let us be honest, even quantum computers might mess things up for us one day. For example: Man in yearslong battle to retrieve lost Bitcoin hard drive worth around $800 million offers to buy landfill... That is why I started looking at the idea of a kind of vault structure that works with Taproot trees and gives more than one way to unlock it, depending on what is still available in the future.

The structure I am looking into includes three different ways to spend from the vault, all hidden unless needed. One path is the usual one: after a set number of years, let’s say 3, someone can spend it using their normal key. That’s the easy route. If that fails maybe the key gets compromised, or ECDSA becomes weak, then there is a second way. That one uses a pre-committed post-quantum key, like Falcon or something similar. The idea is that a hash of that key is locked in, and in the future, the spender can reveal the proof and access the funds. I am still reading up on how best to handle the reveal side of things, since Bitcoin doesn’t verify PQ sigs natively, but the commit reveal approach seems like a reasonable fallback.

Now, in case everything else fails, no key, no PQ stuff, maybe the person managing it is even gone. The third option is where it gets interesting. This is where a simple hash of raw entropy comes in, something generated with dice rolls or coin flips and written down on paper. If that paper is kept safe and the longer time lock maybe 15 years is respected, then the person can recreate the preimage and spend the funds. It is like an emergency backup, something that doesn’t need any device, just good memory or good record keeping.
https://bitcoinops.org/en/topics/taproot/

From what I’ve read and tested out using simulation tools and Miniscript examples, this sort of setup seems doable. The use of Taproot script trees hides all paths unless revealed, and only the chosen path is shown on chain. It keeps things compact and flexible. Still, I’m unsure about a few parts like whether SHA256 or HASH160 is more ideal for the entropy part, or if there is a better way to structure the PQ commitment without bloating the script. But from a research point of view, this approach is worth exploring further.

This is just a research idea I’m gathering together, mostly to understand what is possible and where the current limitations are. I kept imagining a situation where everything we use today is outdated, and all someone has is a piece of paper with some randomness on it, or maybe a dusty backup of a strange looking key they stored decades ago. It would be good to have something designed with that future in mind.

Anyway, I’m posting this here to see if anyone else has looked into similar things or has other ideas. This is just a rough outline of something I’ve been thinking about and researching.

I will love you’ll feedback.. 

[Hatchy]

Don't mess with things you have no knowledge about, even if the goal is to enhance security, complexity often works against it. Each additional layer and fallback mechanism, especially this typed introduces new opportunities for implementation bugs, logical errors, and mistakes in setup or execution. A single misstep in generating, or storing any of these multiple keys or entropy sources could lead to irretrievable loss. I like the idea of you trying to think out of the box, but I usually advice people to stick with well known means of storing our keys.. multi coin wallet is fine, if you wish to share access to your funds to trusted members.

As of quantum computer, we should not worry much about that now because it's still decades away from been close to developed.

[d5000]

Just a couple of days ago I mentioned a similar concept in another thread, which is much simpler but would cater to a slightly different use case: a cold wallet which you should be able to "forget about", even if quantum computing becomes a thing, but it should be possible to be accessed at any time.

With your idea it shares the concept to use a hashlock, but in this case as an additional requirement to the ECDSA key. This means to spend the coins you must know both the private key and the secret.

However, there's a flaw in this concept, and this flaw would (if I understand your setup corrently) also affect your solution: It doesn't at all protect against the "short-exposure" quantum computing attack, because the secret (the preimage) will be revealed at spending time. This means the QC attacker can still replace and double-spend the transaction if it's in the mempool. And against the "long-exposure" quantum computing attack, simply never spending from cold wallet addresses is enough.

This means, the hashlock does not lead to additional security, but instead to a potential vulnerability. I get that you mean that as an "emergency backup" and is meant for lost keys and not necessarily as a post-quantum mechanism, but you have to take this potential risk into account.

[ABCbits]

If that fails maybe the key gets compromised, or ECDSA becomes weak, then there is a second way. That one uses a pre-committed post-quantum key, like Falcon or something similar. The idea is that a hash of that key is locked in, and in the future, the spender can reveal the proof and access the funds. I am still reading up on how best to handle the reveal side of things, since Bitcoin doesn’t verify PQ sigs natively, but the commit reveal approach seems like a reasonable fallback.

Now, in case everything else fails, no key, no PQ stuff, maybe the person managing it is even gone. The third option is where it gets interesting. This is where a simple hash of raw entropy comes in, something generated with dice rolls or coin flips and written down on paper. If that paper is kept safe and the longer time lock maybe 15 years is respected, then the person can recreate the preimage and spend the funds. It is like an emergency backup, something that doesn’t need any device, just good memory or good record keeping.

There's no OPCODES to verify signature that comes from different cryptography. So it seems 2nd and 3rd option feels same, where the proof is just quantum public key rather than quantum signature. And if you broadcast the TX publicly, there's risk of double spend (for theft purpose) since the spending condition is based on providing arbitrary data rather than signed signature. CMIIW.

[stwenhao]

whether SHA256 or HASH160 is more ideal for the entropy part

Every TapScript output uses SHA-256 internally, so if you keep using that, then it should be fine. If SHA-256 will ever be broken, then it can break everything, including Proof of Work, all ECDSA signatures, and also large parts of the Internet behind Bitcoin. Which means, that many things already rely on SHA-256, and you can do that too, because if the world will burn, then the security of your coins will be doomed anyway, if the attacker will be able to overwrite Proof of Work, which created your coins in the first place.

Of course, SHA-256 can be patched in a similar way, as SHA-1 was, by making a hardened version, which will protect it only from particular attack vectors.