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.. 

[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.

[kanftka]

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.

I see what you mean. Yeah, I did not think about that fully. The backup part with the paper and hash was not really for quantum safety, more like a last option if everything else is lost. But you are right, if someone uses it when quantum stuff is real, it could be risky.

I will keep that in mind. Still just testing ideas and learning as I go. Thank you for pointing that out.

[Lucius]

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.
~snip~

I think you chose a bad example, because that man did not lose his private keys due to some technical reasons, but because at the time when the HDD ended up in the trash, he was not interested in that same BTC at all - otherwise he would not have kept it in an unlocked drawer with a pile of junk.

I'm not saying that every new technique someone comes up with won't be helpful, but the more complicated the technique, the fewer people will use it, and it's possible that even the more experienced ones will forget how to find the hidden treasure in xx years.

[kanftka]

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.

Yeah I see what you’re saying. Since Bitcoin can’t actually verify post quantum signatures directly at least not yet, then yeah, both the second and third options pretty much fall into the same bucket, it is just about revealing some kind of preimage to unlock the funds. One is a hash of a PQ public key, the other is just raw entropy from dice rolls or whatever.

The main difference in my head was the intention behind them, like the PQ one feels more like a tech driven backup, while the raw entropy one is more like a last resort, human level backup. But yeah, if someone sees the reveal before you spend, they can absolutely front run it. That is the scary part.

Also, i’ve been wondering, is there any way to actually reduce that front running risk on Bitcoin? Like, are there ways to structure it so that even if someone sees the reveal, they can’t act on it before you do? Or is it just about being fast and maybe spending in the same block you reveal?

Also, do you think it is even worth messing with this stuff right now? Or should this kind of fallback structure just stay as theory until Bitcoin actually supports PQ signatures natively

[ABCbits]

--snip--

Yeah I see what you’re saying. Since Bitcoin can’t actually verify post quantum signatures directly at least not yet, then yeah, both the second and third options pretty much fall into the same bucket, it is just about revealing some kind of preimage to unlock the funds. One is a hash of a PQ public key, the other is just raw entropy from dice rolls or whatever.

The main difference in my head was the intention behind them, like the PQ one feels more like a tech driven backup, while the raw entropy one is more like a last resort, human level backup. But yeah, if someone sees the reveal before you spend, they can absolutely front run it. That is the scary part.

The attacker doesn't care whether the data is arbitrary/randomly generated or PQ public key. This issue also discussed about spending reward for claiming reward on hash collision challenge, see REWARD offered for hash collisions for SHA1, SHA256, RIPEMD160 and other.

Also, i’ve been wondering, is there any way to actually reduce that front running risk on Bitcoin? Like, are there ways to structure it so that even if someone sees the reveal, they can’t act on it before you do? Or is it just about being fast and maybe spending in the same block you reveal?

On theory, you could try find mining pool (who you can trust) to include your TX on their mined block without broadcast it on other node mempool.

Also, do you think it is even worth messing with this stuff right now? Or should this kind of fallback structure just stay as theory until Bitcoin actually supports PQ signatures natively

Personally i wouldn't bother with non-common way to spend Bitcoin. It introduce risk losing access to your Bitcoin if you lost details about spending it.

[kanftka]

--snip--

Yeah I see what you’re saying. Since Bitcoin can’t actually verify post quantum signatures directly at least not yet, then yeah, both the second and third options pretty much fall into the same bucket, it is just about revealing some kind of preimage to unlock the funds. One is a hash of a PQ public key, the other is just raw entropy from dice rolls or whatever.

The main difference in my head was the intention behind them, like the PQ one feels more like a tech driven backup, while the raw entropy one is more like a last resort, human level backup. But yeah, if someone sees the reveal before you spend, they can absolutely front run it. That is the scary part.

The attacker doesn't care whether the data is arbitrary/randomly generated or PQ public key. This issue also discussed about spending reward for claiming reward on hash collision challenge, see REWARD offered for hash collisions for SHA1, SHA256, RIPEMD160 and other.

Yeah, makes total sense, the attacker doesn’t care whether it is random data or a PQ pubkey. Once the preimage is public, it is fair game. So yeah, same weakness either way. I will check out that hash collision bounty thread....

The mining pool trick is interesting, I’ve seen it done for privacy, but hadn’t thought about it as a way to dodge front running. don't seems is easy to pull off though, unless you really trust the pool.

Also, do you think something like adaptor sigs or even some clever Taproot construction could help here? Or does the core problem of reveal before spend still make that a dead end?

Personally i wouldn't bother with non-common way to spend Bitcoin. It introduce risk losing access to your Bitcoin if you lost details about spending it.

And yeah, I appreciate your rep a lot... You’re right straying too far from standard ways of spending BTC just increases the odds of locking yourself out, especially if there is any human error down the line. Thanks again for sharing your thoughts...