Hey everyone,
I’ve been diving into some research lately, not anything too intense, but it’s been on my mind for a while. The basic idea is this: if someone wants to hold onto their bitcoin for an extended period, say 10, 15, or even 20 years, how can they ensure that they or a trusted person can access it down the line without relying too much on hardware or wallets that might not exist anymore?
I get that most folks just stash their BTC with a seed phrase and call it good, or maybe they use multisig or hardware wallets, but honestly, I’m not fully convinced those methods are reliable in the long run. Seed phrases can be lost, hardware wallets might get messed up, and let’s face it, who knows what quantum computers might do to our security one day. For instance, check out the story of a guy who’s been trying to recover a lost Bitcoin hard drive worth around $800 million, even offering to buy a landfill.
That’s why I started exploring the concept of a vault structure using Taproot trees that allows multiple ways to access the funds, based on what’s still viable in the future.
I’m looking at a setup with three different ways to withdraw from the vault, all hidden unless needed. The first method is the standard route: after a specific period, say 3 years, someone can access it with their usual key. That’s the straightforward option. If that doesn’t work out maybe the key gets compromised or ECDSA becomes insecure there’s a second option. This one involves a pre-committed post-quantum key, like Falcon or something similar. The plan is to lock in a hash of that key, and later, the spender can unveil it.
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.
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.
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.
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.
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.
Yeah I see what youre saying. Since Bitcoin cant 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, ive 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 cant 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
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.
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.
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.
Yeah, makes total sense, the attacker doesnt 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, Ive seen it done for privacy, but hadnt 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?
And yeah, I appreciate your rep a lot... Youre 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...