3 ms·

Bitcoin is vulnerable in two ways: 1. The oldest (and largest) wallets directly stored their public key on the blockchain. This would mean that attackers could

Bitcoin is vulnerable in two ways: 1. The oldest (and largest) wallets directly stored their public key on the blockchain. This would mean that attackers could transfer money away from these wallets (many of them are dormant). 2. Relatively early, the blockchain shifted to only storing the hash of the public key, which seems less susceptible to a quantum computing attack. The risk in these wallets is that once you want to transfer bitcoins out, you need to temporarily publish your public key - this key is not stored on the blockchain, but might be stored by future attackers. In addition, at some point getting your private key will be so fast that the moment you publish a transaction request you'll many fake requests asking to transfer to another wallet. The solution is likely a soft fork - new addresses that are quantum resistant (similar to how in the past Bitcoin moved away from public key address into hash). The trick is that this needs to be deployed before attacks exist, and people need to transfer their Bitcoin into the new wallets.

Melting_Harps 6y ago
> 1. The oldest (and largest) wallets directly stored their public key on the blockchain. This would mean that attackers could transfer money away from these wallets (many of them are dormant). That doesn't mean the Public key has ever been exposed online and therefore not true. Look up cold storage best practices, I'm not going to line it out for you but what you said is entirely false and built on a flawed premise. > 2. Relatively early, the blockchain shifted to only storing the hash of the public key, which seems less susceptible to a quantum computing attack. The risk in these wallets is that once you want to transfer bitcoins out, you need to temporarily publish your public key - this key is not stored on the blockchain, but might be stored by future attackers. In addition, at some point getting your private key will be so fast that the moment you publish a transaction request you'll many fake requests asking to transfer to another wallet. You started it off with a valid observation, but then led into a non-sequitur, what does that have to do with Bitcoin's vulnerability if as we just said 1 is not true if done correctly. > The trick is that this needs to be deployed before attacks exist, and people need to transfer their Bitcoin into the new wallets. While I agree security on mainchain is an issue, we should dhave had taproot long ago, and mixing by default by now as tx fees get more and more expensive--all you're doing is mixing it with other adddresses to make the sum indistinguishable from it's source and that cost adds up as the netowrk gets more expensive to operate on. But also your premise is at odds with the fact that most of the traffic will be done on LN moving forward, and the bitcoin (token) will locked out of the network's mainchain (Bitcoin) to operate on LN and thus does not require your 'solution.' In short, these are non-concerns. Note how I didn't downvote you, and instead I challenged your arguments in order for others to benefit from this conversation, instead of being a child and downvoting simply because I disagree with your points. Edit: HAHA!

Melting_Harps 6y ago

> 1. The oldest (and largest) wallets directly stored their public key on the blockchain. This would mean that attackers could transfer money away from these wallets (many of them are dormant). That doesn't mean the Public key has ever been exposed online and therefore not true. Look up cold storage best practices, I'm not going to line it out for you but what you said is entirely false and built on a flawed premise. > 2. Relatively early, the blockchain shifted to only storing the hash of the public key, which seems less susceptible to a quantum computing attack. The risk in these wallets is that once you want to transfer bitcoins out, you need to temporarily publish your public key - this key is not stored on the blockchain, but might be stored by future attackers. In addition, at some point getting your private key will be so fast that the moment you publish a transaction request you'll many fake requests asking to transfer to another wallet. You started it off with a valid observation, but then led into a non-sequitur, what does that have to do with Bitcoin's vulnerability if as we just said 1 is not true if done correctly. > The trick is that this needs to be deployed before attacks exist, and people need to transfer their Bitcoin into the new wallets. While I agree security on mainchain is an issue, we should dhave had taproot long ago, and mixing by default by now as tx fees get more and more expensive--all you're doing is mixing it with other adddresses to make the sum indistinguishable from it's source and that cost adds up as the netowrk gets more expensive to operate on. But also your premise is at odds with the fact that most of the traffic will be done on LN moving forward, and the bitcoin (token) will locked out of the network's mainchain (Bitcoin) to operate on LN and thus does not require your 'solution.' In short, these are non-concerns. Note how I didn't downvote you, and instead I challenged your arguments in order for others to benefit from this conversation, instead of being a child and downvoting simply because I disagree with your points. Edit: HAHA!