pull down to refresh

How worried do I need to be about public key when sending an on-chain transfer?
298 sats \ 15 comments \ @stack_harder 12 Dec bitcoin
Ok, so I first heard about this from one of my posts here and it was news to me. It popped up again recently during some quantum AI fud stuff that's been going around.
The idea is that public key exposure in Bitcoin transactions could theoretically become a risk vector with the advent of quantum computing.
I basically only send an onchain transfer to myself to consolidate utxos, and even that doesn't often happen because it takes me a very long time to hit amounts actually worth consolidating.
Even my buys are now on robosats that I swap on boltz.
So my main question is, do we think the quantum risk will probably just be mitigated with a quantum-resilient algo update or soft fork or something?
And, really, with me ( and more people) using lightning, do I really need even to be worrying about revealing my pub key when sending the very rare on-chain transfer?
write
preview
related posts
135 sats \ 9 replies \ @DarthCoin 12 Dec
do we think the quantum risk will probably just be mitigated with a quantum-resilient
No risk. Read here #804883
do I really need even to be worrying about revealing my pub key when sending the very rare on-chain transfer?
pub key is literally PUBLIC so is already revealed. Important is to not link it with your real identity (always use aliases and decoys).
Please watch this short explanation about "QC doom scenario" and please keep calm, nothing will happen.
reply
20 sats \ 7 replies \ @bordalix 12 Dec
pub key is literally PUBLIC so is already revealed
Not true.
When receiving a P2PKH payment, what is revealed is the pubkey hash, the pubkey stays hidden. The pubkey is only revealed when the unlocking script gets to the mempool and stays revealed on the blockchain when the transaction is confirmed.
So, if for some remote chance QC is able to break ECDSA (i.e. find the private key from the pubkey), your UTXO could be "hijacked" only when the attacker finds your pubkey, which is only when you try to spend it and the spending transaction arrives to the mempool.
This means the attacker has around 10 minutes to do it (could be longer), or else the transaction would be confirmed and the UTXO is no longer "hijackable" since it's already spent.
This is another reason to not re-use addresses (remember, a P2PKH address has the pubkey hash in it).
IMHO QC will never break ECDSA, but I could be wrong.
reply
0 sats \ 6 replies \ @DarthCoin 12 Dec
yeah I don't know why people still reuse addresses and even using old legacy ones.
reply
0 sats \ 4 replies \ @stack_harder OP 13 Dec
if people never re-use an address, won't that mean having to potentially do a shitton of utxo consolidation at some point ?
reply
32 sats \ 2 replies \ @bordalix 13 Dec
Those are not related:
  • Every time you receive a payment, you get a new UTXO regardless of the address you gave to receive the payment
  • Every time you pay you could get a new UTXO (your change, if any) regardless of the address you use to receive the change
Re-using addresses does not reduce (or increment) the number of UTXOs
reply
0 sats \ 1 reply \ @stack_harder OP 13 Dec
i have to admit, there's always something extra to confuse me about utxos, thanks for explaining though.
so far, my utxo consolidation has been sending to a new address , i only did it once.
as an example, say i i do my monthly dca of 100k sats
over 12 months i have 12 addresses in my ledger that each have 100k sats
my understanding is that i can make a new address, send each of those 12 balances there and i have now consolidated.
is this new recipient address now consolidated, or did i just make ton more utxo addresses?
reply
0 sats \ 0 replies \ @bordalix 13 Dec
You don't consolidate addresses, you consolidate UTXOs.
Your assumption is correct, you get 1 new UTXO every month, and at the end of the year you consolidate 12 UTXOs into 1.
The above is true if you use 13 different addresses, the same address for every UTXO or even a mix: it doesn't matter.
This site is excellent explaining Bitcoin: https://learnmeabitcoin.com/technical/transaction/utxo/
reply
10 sats \ 0 replies \ @DarthCoin 13 Dec
That is another reason not to reuse addresses. Also could be a target for the so called "dust attack".
reply
0 sats \ 0 replies \ @bordalix 12 Dec
Satoshi's coins are locked to his pubkey (P2PK), not to the pubkey hash, because P2PKH was "invented" later. This means an attacker will first go for Satoshi coins, where he has all the time in the world (instead of 10 minutes) to try to steal the coins.
So, if someday some of the Satoshi's coins move, we should start worrying. Until then is business as usual.
reply
0 sats \ 0 replies \ @stack_harder OP 12 Dec
too bad Andreas isn't on SN. so i suppose we would just have to move our funds a new type of quantum secure address.
this brings up another question for me actually related to kyc btc that i will post in a different thread.
out of curiosity, what effect would quantum computing have on the lightning network?
reply
21 sats \ 2 replies \ @OgFOMK 12 Dec
You can not determine your public key by receiving or sending from an address. The trick is when you reveal your public key then any watch wallet can see all your transactions under that key.
If you feel like your public key is exposed then you get another private key /public key set up and you send your sats to this. You can still keep the other original wallet for purposeful interface. Just use it as a hot wallet for smaller transactions. Or just use it to sign stuff.
Either way you can keep and control how the information is used.
I used Atomic wallet when I was shitcoining. I had the key phrase and I had no idea that my re-used address was a liability. What was worse is that the basic Atomic wallet Bitcoin address was the public key! It was stupid. I wrapped up my Bitcoin and I saved my key and emptied it. I still watch that wallet and have the private key.
Since that time I've migrated several instances and I'm much better at only using the public key to watch and not disclose or show. I have generated addresses that I use for individual transactions and those addresses do not reveal the public key or private key.
If you read Mastering Bitcoin by Andreas Antonopolous. You can see how key generation has many derivative uses and you can use subsets of keys to make keys that are like subnets of the Internet. This allows you to assign blocks of addresses that fall under a derivative without exposing to top echelon.
The easy way is to just get a new seed by careful generation and send UTXOS to a new addresses generated due each transaction and keep the pub key under your hat.
reply
10 sats \ 1 reply \ @stack_harder OP 12 Dec
none of this is an issue when mostly using lightning though, right ?
reply
10 sats \ 0 replies \ @OgFOMK 12 Dec
When you use lightning your channels are multi-signature and just sats sitting in an account where upon settlement they go to the person who the balance belongs to. Sending back and forth takes a lot of hops, hands and other channels.
It's a different relationship than on chain. Security is better. Just make sure to protect your keys and don't advertise your wealth.
reply
10 sats \ 1 reply \ @DesertDave 12 Dec
If quantum computers are a problem for some bitcoiners, it is a problem for all of Bitcoin. And if it is a problem for Bitcoin, it's a problem for all computing everywhere. Right?
reply
0 sats \ 0 replies \ @stack_harder OP 12 Dec
sure, banks will be equally fucked etc, I'm quite interested in how much i might accidentally reveal by the simple act of even sending some btc on chain (even though i basically don't, because I'm just stacking). like who is watching etc
worst case scenario understanding and planning basically :)
reply