What is the story of old addresses not safe and the need for new addresses?

[benjamin07]

Hi,

I stopped using Bitcoin a few years ago, back then I had the Bitcoin Core wallet so I just backed up my wallet.dat.

I heard / was told that since then the 'old addresses' are not good anymore and I need to do something like get a new address and transfer the coins from the old address to the new address?

Can you please tell me more about this? what i ned to do? I think last BitCoin core i used was 0.16.0 but that was just an update of the software. The wallet itself was created by an earlier version.

Thanks.

[pooya87]

Nothing has changed regarding the safety of different address types in bitcoin. Anything that was secure back in 2009 (when bitcoin was created) is just as secure today too whether it is P2PK, P2PKH, P2SH, P2WPKH,...  they are all secure.

What changed is addition of new features to bitcoin, specifically new scripts such as P2WPKH (aka SegWit addresses) and since transaction size calculation is also changed and SegWit transactions have lower weight it is recommended to use these addresses for lower transaction fees and bigger blocks.

[benjamin07]

Thanks Pooya

So I don't need to do anything security wise, that's great. Thank you.

What do I need to do to use the new SegWit addresses? I looked in the Send section and it is all still the same: Pay to etc and control over the transaction fee...

[ABCbits]

What do I need to do to use the new SegWit addresses? I looked in the Send section and it is all still the same: Pay to etc and control over the transaction fee...

You need to generate the SegWit address from "send" section first. There are 2 types of SegWit address, which are

1. P2SH-SegWit (sometimes called segwit address or p2sh segwit)

Code:

3NhtbwQZ71yHyE7y1eanttNbkHPkusdATD

2. P2WPKH (sometimes called native segwit or bech32)

Code:

bc1qlfyx65dyc8usd0m0p682yght6dy9gqvn3ttx7z

P.S. i don't remember if you can generate SegWit address from wallet.dat created by older version of Bitcoin Core (before SegWit is supported by Bitcoin Core)

[nc50lc]

I heard / was told that since then the 'old addresses' are not good anymore and I need to do something like get a new address and transfer the coins from the old address to the new address?

You must have heard about "Quantum Supremacy" which will make old unspent P2PK outputs vulnerable.
That includes both old and new reused addresses which have their public key exposed.

But the rumor is more of an FUD since it's still decades before Quantum computers can become a threat, don't sweat it.

P.S. i don't remember if you can generate SegWit address from wallet.dat created by older version of Bitcoin Core (before SegWit is supported by Bitcoin Core)

Go to "receive" section, tick "Generate native segwit (Bech32) address", lastly hit "Create new receiving address".
It will generate bc1 address even if the wallet is from old version (tested wallet.dat from v0.11.1) or isn't HD.

[Dabs]

If you don't need to spend your coins now, don't touch it. However, it may make sense to create a new wallet that is native segwit, then transfer to that new wallet with as low a fee as possible and just wait for the transaction to get included in a block.

Be sure to do some research about possible fork coins. If it was a few years ago like before 2017, your address may have BCH and BSV and BTG or other coins you can try to retrieve. But transfer your BTC first before trying to get those forks.

[mikeywith]

When people tell you old addresses/wallets are not good/safe, they are probably talking about the old ECDSA weak-randomness vulnerability which would put your funds at a huge risk if you spend twice from the same address, that was fixed using DSA RFC 6979 in 2013, so unless you come from that era, you shouldn't worry about this particular case.

The second reason as to why they would tell you so is the fact that once you spend from an address you reveal your public key that uses ECDSA which is "breakable" by shor's algorithm that quantum computers can utilize, so all your old addresses which you used to spend from are now theoretically at 'that' risk.

When you use a new address for every transaction - your public key is secured by both SHA-256 and RIPEMD-160 that are not vulnerable to Shor, a thick level of security if you may.

[pooya87]

"breakable" ... risk....vulnerable ...

You are using wrong terms here. There is no vulnerability or any risk involved in revealing your public key because the conversion from a private key to public key is irreversible, period. If some day it becomes reversible then we have a lot more to worry about than one user not revealing their public key because bitcoin would be broken by then and not just bitcoin, nearly all the internet would break. For example here is public key that google.com uses each time you visit their site (similar thing with banking system,...):

Code:

04 8e 57 d1 a6 a4 84 c1 ff 04 57 9b cb 5a 5b f6 58 41 51 3f 0d e8 90 72 b9 1e 33 9a e3 d0 2a 63 4c 57 72 05 0c c2 59 b9 99 fc c8 ef 8a cc b1 e7 a6 e7 12 74 da d7 97 54 3c 44 ca 1d 9b 82 85 cb aa

[ranochigo]

When people tell you old addresses/wallets are not good/safe, they are probably talking about the old ECDSA weak-randomness vulnerability which would put your funds at a huge risk if you spend twice from the same address, that was fixed using DSA in 2013, so unless you come from that era, you shouldn't worry about this particular case.

Are you talking about the reused r values in the signature? That was fixed by wallets adopting deterministic signature generation which results in the r values being unique for each signature, aka. RFC 6979. If it's not, could you point me to some information regarding this?

[mikeywith]

You are using wrong terms here.

No, I am not, those terms are used in research papers. you can google elliptic curve Shor's algorithm +break/vulnerable/risk and you will find a bag full of studies and research papers that use those terms, I fully agree that as of right now and while quantum computing isn't a current threat and won't be until they become powerful enough to efficiently run Shor's algorithm, I don't see why those terms are "wrong".

Are you talking about the reused r values in the signature?

Yes exactly what I was referring to, should have made that a bit clearer "edited my previous post", and yes, they fixed this with the rfc-6979 update in 2013 this is why I mentioned if his wallet isn't from 2013 or prior to that, he shouldn't worry about that.

[Dabs]

It's always a good idea to move your coins to new addresses safely maybe once a year, and get updated on any developments. Even if you mined when it all started, you'd have moved maybe 12 times? And you'd get all the forks.

Fiat banks normally have some sort of "once a year" transaction minimum otherwise they may consider your account "abandoned". Bitcoin does not have this limit, but still a good idea to check on it. It's a process for you.

[pooya87]

No, I am not, those terms are used in research papers. you can google elliptic curve Shor's algorithm +break/vulnerable/risk and you will find a bag full of studies and research papers that use those terms, I fully agree that as of right now and while quantum computing isn't a current threat and won't be until they become powerful enough to efficiently run Shor's algorithm, I don't see why those terms are "wrong".

An algorithm can only be considered vulnerable if and only if the attack is plausible now or in very near future. If the possibility of it being broken exists some day in the far future then we can't call it a vulnerability because that is the nature of all cryptography algorithms to be broken some day.

For example you can say SHA1 is vulnerable because today we can successfully and easily find a collision, which makes it already broken. But SHA2 is not vulnerable and we can't break it so there is no risk even though some day in the future we will be able to find a collision just like what we did to SHA1.

[NotATether]

Are you talking about the reused r values in the signature?

Yes exactly what I was referring to, should have made that a bit clearer "edited my previous post", and yes, they fixed this with the rfc-6979 update in 2013 this is why I mentioned if his wallet isn't from 2013 or prior to that, he shouldn't worry about that.

This sounds like something that each wallet software or possibly a shared library that they each use has to fix on their own. This RFC6979 patch would have to be applied by them all in order for them to be considered safe, right?

What is the guarantee that some lesser-known wallets (not common wallets like Core and Electrum) aren't using this RFC and aren't reusing r values?

[ranochigo]

This sounds like something that each wallet software or possibly a shared library that they each use has to fix on their own. This RFC6979 patch would have to be applied by them all in order for them to be considered safe, right?

Not exactly. RFC 6979 only ensures that the r values are not reused by implementing a deterministic signature, it doesn't necessarily mean that non-RFC6979 signatures are vulnerable.

What is the guarantee that some lesser-known wallets (not common wallets like Core and Electrum) aren't using this RFC and aren't reusing r values?

If you're reusing r values, then your funds would probably have already been stolen. The risk really only exist in the poorly designed wallet (either included intentionally or accidentally), mitigation is to use more well known and audited wallets. I don't see it as a big issue if wallets don't implement it as long as they don't reuse the r values. It should probably be one of the few basic checks on the transactions/signature before any release.

[pooya87]

What is the guarantee that some lesser-known wallets (not common wallets like Core and Electrum) aren't using this RFC and aren't reusing r values?

Hence the warning that we keep giving users that they must never use closed source wallets. The "guarantee" is that you simply look at their source code of an open source project (or ask someone else to do it) and easily see what they're doing.

[mikeywith]

This sounds like something that each wallet software or possibly a shared library that they each use has to fix on their own.

Right.

An algorithm can only be considered vulnerable if and only if the attack is plausible now or in very near future.

Not sure if all the cryptography experts and professors who do this full time agree with this definition, the word "vulnerable" is widely used on the acedmic level as long as there is at least a theoretical threat on something.

Hence the warning that we keep giving users that they must never use closed source wallets. The "guarantee" is that you simply look at their source code of an open source project (or ask someone else to do it) and easily see what they're doing.

Looking at the source code alone isn't enough, it's easy to tell people to use open source wallets but then how do you know the version on your device is actually the one you read the code for? I mean unless you compile the whole code yourself there is really no guarantee that what you use is what you see on Github.

[BASE16]

You are using wrong terms here. There is no vulnerability or any risk involved in revealing your public key because the conversion from a private key to public key is irreversible, period.

It's most certainly reversible.
A keypair has a 1:1 relationship.
Add 1 to your private key and you will have added 1G to your public key.
Likewise, Add 1G to your public key and you will have added 1 to your private key.
I know that you know this so why would you make the impossible claim.

The only two things that (currently) prevent reverse engineering a private key is the enormous capacity of the key space, and the lack of computational power to process these ultra large numbers.
Otherwise it would be peanuts and done in seconds.

Last time i checked there were approximately about 35000 P2PK (with funds) still floating around.

[pooya87]

Looking at the source code alone isn't enough, it's easy to tell people to use open source wallets but then how do you know the version on your device is actually the one you read the code for? I mean unless you compile the whole code yourself there is really no guarantee that what you use is what you see on Github.

Building from source is one solution but generally that's when deterministic or reproducible builds come in. For example anyone who builds bitcoin core or electrum should always come up with the same exact binaries. This makes the binaries that are published safer for those who don't build from source themselves because (for popular projects) you know that there are people checking the reproducibility.

[benjamin07]

Hi,

thanks for your replies, here is my answer to your questions:
1. I'm not sure what year I started but maybe 2014: is there a way I can find out from the address what era does it belong to?
2. I was, am, and will always use Bitcoin Core full node only: i found a way to limit how many GB it keeps of the blockchain so I don't have the problem of disk storage anymore.

I got the confusion when someone said that if you keep using the same address over and over again then your wallet can get hacked. This story came at the same tiem as quatum computing fuss was going on. I always used the same address because it used to get confused between wallet and addrees: i thought they were the same. Now I still don't understand the following:
1. one wallet can have many addresses: i've tested this it's easy to confirm
2. The number of Bitcoins is contained in the Wallet, not in a particular address: not sure?
3. I don't need to create a new wallet.dat, i only need to create a new address in the same wallet.dat: not sure?

[nc50lc]

thanks for your replies, here is my answer to your questions:
1. I'm not sure what year I started but maybe 2014: is there a way I can find out from the address what era does it belong to?

There's no address in the blockchain, so base it from the timestamp of the block(s) where the transactions are included, and its script type if identifiable.

I got the confusion when someone said that if you keep using the same address over and over again then your wallet can get hacked. This story came at the same tiem as quatum computing fuss was going on. I always used the same address because it used to get confused between wallet and addrees: i thought they were the same. Now I still don't understand the following:
1. one wallet can have many addresses: i've tested this it's easy to confirm
2. The number of Bitcoins is contained in the Wallet, not in a particular address: not sure?
3. I don't need to create a new wallet.dat, i only need to create a new address in the same wallet.dat: not sure?

The wallet is the client, in your case: Bitcoin Core; the address is the easy-to-copy representation of the script to receive bitcoins, or simply it's the string that starts with '1', '3' or 'bc1'.
Yes, your wallet can create as many addresses as your machine can handle, you don't need to create a new wallet.dat.
The balance displayed is based from the total value of all of your UTXO, unspent transaction outputs (in other words: unspent received transactions),
those are in the blockchain, your wallet only contains the keys that enable you to spend them.

Lastly, currently there's no risk in keeping your old outputs but there's no harm on sending them to a new script type for future-proofing purposes, aside from the transaction fee.
The decision is yours.