Don't delete the wallet Why ?

[Oluwa-btc]

https://bitcointalk.org/index.php?topic=1327.msg15136#msg15136

Could this be broken down a bit for me please ?
I'll preciate this.

Thanks xx

[1715372620]

1715372620

[1715372620]

1715372620

[1715372620]

1715372620

[1715372620]

1715372620

[1715372620]

1715372620

[garlonicon]

Because if you delete your wallet, then you will have no access to your coins. Also, if you use deterministic wallet, then there is no reason to do this to save storage space, because your backup can have constant size.

[nc50lc]

The keyword is "just in case";
Which can be broken down to a number of sentences that start with "In case".

Examples: In case you need the historical data from the wallet / In case you've accidentally sent bitcoins to it.

[PrimeNumber7]

Because if you delete your wallet, then you will have no access to your coins. Also, if you use deterministic wallet, then there is no reason to do this to save storage space, because your backup can have constant size.

I would point out that deterministic wallets do use additional space for each additional address that receives a transaction, while the wallet is in use. The reason for this is that HD wallet software will need to monitor all addresses in the wallet from the first address until the gap limit number of addresses has not received a transaction. While a deterministic wallet is not in use, the only storage space needed is the 12 or 24 word seed.

When you delete a wallet file, you lose all access to the private keys in that wallet. When you have received a transaction, that generally means you have provided an address in your wallet to someone in order for them to send you a transaction. There is the risk that either you or the person you gave the address to will accidently send a subsequent transaction to one of your old addresses. Deleting old wallet files will also prevent you from being able to prove your association with previous transactions.

[n0nce]

In my opinion, there are only downsides to deleting wallets. I can't believe anyone telling me they don't have a few MB on their hard drive to keep a list of 'old wallet backups' (empty wallets that they would otherwise delete).

There are a few reasons to keep those wallets though; as nc50lc said, 'just in case'. For instance, let's say you bought 10BTC for $1,000 USD on 1/1/2013 and had a normal paying job at that time. You could afford those coins by saving up a little bit, without an issue. Let's assume a scenario where Bitcoin is worth $1M USD in 2033 and you now own 10 million US dollars in Bitcoin. If you still have the wallet where you received those coins in 2013, even if the coins left the wallet (with or without paper trail), you can prove you owned 10BTC in 2013 when it was really cheap and just claim you never sold or bought and just mixed and / or transferred them between wallets.
You can do that by signing a message with the old wallet's private key, which proves you were once in possession of a wallet with that balance and also the time is proven by the block's timestamp.

This will become relevant as purchase amounts and exchange rate rise, because laws (AML and similar) do kick in and questions will be asked. If you can't prove you bought 10BTC at a time where it was possible to do so for almost everyone, authorities will have to assume you acquired those BTC in recent time through fraudulent means (if you don't have a job that pays dozens of millions a year, which would then be a way to prove you were able to 'recently acquire them').

That's just one reason to keep the private keys. For proving past ownership of coin if it becomes necessary in the future (laws change all the time, your location of residency might change, etc. etc.) - remember in Bitcoin we think long term..

Edit: more on the topic I addressed here can be found on one or two pages of this thread.

[DaveF]

Bit of a discussion about it here: https://bitcointalk.org/index.php?topic=5325660.0
And the last couple of posts in that thread: https://bitcointalk.org/index.php?topic=5325660.msg59564965#msg59564965

It's not like you are talking saving 100s of GB of blockchain data, it is barely a few megs of storage, not like people are saying you have to save something big and expensive to store.

-Dave

[pooya87]

Lest we forget shitcoins.
Historically there has been at least one shitcoin airdrop that gave free coins (could be converted to real money) to those who had a balance at a certain time in the past. I'm talking about CLAM. There could be others, you could also find out there were some copycat shitcoin like bcash that forked while you had a balance and you could get that free money too.

[PrimeNumber7]

Because if you delete your wallet, then you will have no access to your coins. Also, if you use deterministic wallet, then there is no reason to do this to save storage space, because your backup can have constant size.

I would point out that deterministic wallets do use additional space for each additional address that receives a transaction, while the wallet is in use. The reason for this is that HD wallet software will need to monitor all addresses in the wallet from the first address until the gap limit number of addresses has not received a transaction. While a deterministic wallet is not in use, the only storage space needed is the 12 or 24 word seed.

But with modern storage, size of HD or non-HD wallet doesn't matter since it's very small compared with modern storage capacity.

In general, if you are using a HD wallet, when you are actually using the wallet, you will need to keep the used addresses (and transaction history) in RAM, which is more expensive than HDD or SDD storage. For most casual users who use bitcoin on a personal basis, this should not be a big deal, however, for heaver users, such as businesses, this can quickly add up. The appropriate solution would be for the business to periodically create new HD wallets and retain copies of their old seed.

[pooya87]

In general, if you are using a HD wallet, when you are actually using the wallet, you will need to keep the used addresses (and transaction history) in RAM, which is more expensive than HDD or SDD storage. For most casual users who use bitcoin on a personal basis, this should not be a big deal, however, for heaver users, such as businesses, this can quickly add up. The appropriate solution would be for the business to periodically create new HD wallets and retain copies of their old seed.

I don't see any reason to keep the transaction history in memory since it is not something you need to have ready for access. The addresses don't need to be kept in memory either, if saved in a database it just needs to be accessible. But even if you keep addresses in memory it still shouldn't be that expensive, a million of them could take up to about 300-350 MB of RAM. My running browser takes up more memory than that.

[Kakmakr]

Also, if there are a fork ..like we had with Bitcoin (BTC) ... You will be able to extract the same amount of coins from that "address" as prior to the fork.

I made that mistake once with Paper wallets that I swept into a new Electrum wallet and I threw away the paper wallets. (A while after that, I read someone advertised that they extracted a bunch of fork coins from their wallets and I remembered about that, but it was too late.)

One of the forked coins was Bitcoin Cash... so I could have used that money to buy more bitcoins. 

[Charles-Tim]

Also, if there are a fork ..like we had with Bitcoin (BTC) ... You will be able to extract the same amount of coins from that "address" as prior to the fork.

You can only be able to have access to the forked coins after blockchain split, not before or prior to the hardfork/blockchain split.

I made that mistake once with Paper wallets that I swept into a new Electrum wallet and I threw away the paper wallets. (A while after that, I read someone advertised that they extracted a bunch of fork coins from their wallets and I remembered about that, but it was too late.)

You sweeped from paper wallet to Electrum wallet? Then, your paper wallet if having no bitcoin again will not get any forked coins. If your Electrum wallet is still having the coins, then you can send your bitcoin to another newly created Electrum wallet, then import the private key of the old Electrum wallet on the forked coin supported wallet to claim the forked coin.

[HCP]

Can I turn the question around and ask why you think you need to delete an old wallet? What do you think you can gain from deleting a wallet as opposed to having it on your harddrive?

[Zilon]

It's like saying don't throw away the access to your funds. you can keep them aside other than wiping it off completely and by keeping aside it means having a backup to your private key or seed phrase. This is because once the access to your wallet is gone no one will ever recover the wallet except the stumble on the private key. An empty wallet can be deleted if it has no future use but once a single transaction is done on a wallet it get registered on the blockchain and with yours coins in there if it get misplaced it an everlasting loss

[PrimeNumber7]

In general, if you are using a HD wallet, when you are actually using the wallet, you will need to keep the used addresses (and transaction history) in RAM, which is more expensive than HDD or SDD storage. For most casual users who use bitcoin on a personal basis, this should not be a big deal, however, for heaver users, such as businesses, this can quickly add up. The appropriate solution would be for the business to periodically create new HD wallets and retain copies of their old seed.

I don't see any reason to keep the transaction history in memory since it is not something you need to have ready for access. The addresses don't need to be kept in memory either, if saved in a database it just needs to be accessible. But even if you keep addresses in memory it still shouldn't be that expensive, a million of them could take up to about 300-350 MB of RAM. My running browser takes up more memory than that.

No current wallet software (that I am aware of) that is publically available will keep the list of addresses it needs to watch outside of RAM. I am not sure about how transactions are stored, however, they are readily available enough for me to believe they are also stored in RAM.

A business could implement their own custom HD wallet software, but I don't think they could store the addresses in their wallet outside of RAM. If they did store the addresses outside of RAM, the custom software would need to access every address every time a block is found, which would be inefficient.

[n0nce]

In general, if you are using a HD wallet, when you are actually using the wallet, you will need to keep the used addresses (and transaction history) in RAM, which is more expensive than HDD or SDD storage. For most casual users who use bitcoin on a personal basis, this should not be a big deal, however, for heaver users, such as businesses, this can quickly add up. The appropriate solution would be for the business to periodically create new HD wallets and retain copies of their old seed.

I don't see any reason to keep the transaction history in memory since it is not something you need to have ready for access. The addresses don't need to be kept in memory either, if saved in a database it just needs to be accessible. But even if you keep addresses in memory it still shouldn't be that expensive, a million of them could take up to about 300-350 MB of RAM. My running browser takes up more memory than that.

No current wallet software (that I am aware of) that is publically available will keep the list of addresses it needs to watch outside of RAM. I am not sure about how transactions are stored, however, they are readily available enough for me to believe they are also stored in RAM.

A business could implement their own custom HD wallet software, but I don't think they could store the addresses in their wallet outside of RAM. If they did store the addresses outside of RAM, the custom software would need to access every address every time a block is found, which would be inefficient.

Well, if you use a hardware wallet you usually have a watch-only wallet in the software, with the ability to generate addresses on the fly from the xpub, which is permanently stored on disk.

Of course, every time you access something, for the CPU to be able to compute on it, it is temporarily loaded into RAM. But not all addresses (aren't there infinitely many of them? ) have to be kept in RAM at the same time. When the software periodically checks balances, it loads xpub into RAM, generates addresses from that (kept in RAM), checks the balances and then probably writes them to disk as a sort of cache. When it's done, the RAM is flushed.

The addresses are probably even removed from RAM right after being checked, so you might actually only have one address in RAM at a time; meaning no matter how many wallets and transactions you have, memory usage should be minimal.

I know for a fact, that BlueWallet shows me the last few transactions and wallet balances as soon as I open it; then immediately starts to look if there are any changes. But it does show cached values that have been written to disk right away & only starts updating afterwards.

[pooya87]

Of course, every time you access something, for the CPU to be able to compute on it, it is temporarily loaded into RAM. But not all addresses (aren't there infinitely many of them? ) have to be kept in RAM at the same time. When the software periodically checks balances, it loads xpub into RAM, generates addresses from that (kept in RAM), checks the balances and then probably writes them to disk as a sort of cache. When it's done, the RAM is flushed.

That sounds very inefficient. Your client has to be able to update the state of your wallet (address balances, transactions, UTXOs) every time it also updates the chainstate. The addresses have to either be stored in a database which it would access after each block or already be in the memory (the scripts and UTXOs at least) so that it can check it against each tx in that block and update their state.
If you want to derive each address each time, it would be a waste of computing power.

I know for a fact, that BlueWallet shows me the last few transactions and wallet balances as soon as I open it; then immediately starts to look if there are any changes. But it does show cached values that have been written to disk right away & only starts updating afterwards.

That may be because your SPV client is connecting to a server, sends it your addresses and then keeps an open socket listening for the updates the servers sends back. So it doesn't need to keep that much data in memory. Also if your wallet UI is showing a list of your addresses, then they are already in your memory!

[n0nce]

~

Honestly, I've checked a few wallets' code and they're all written in higher languages like Python or Java, where I'm not sure you can know exactly when something's in RAM and when not, because all that memory management is abstracted away.
I know for a fact though, that memory issues are relatively rare today even in much more complex programs, due to all the abstraction that is available, caching and super fast pagefiles due to flash storage. Also RAM prices are pretty affordable and even phones are getting more and more of it.

Of course, to show something on screen, it has to be loaded into RAM, as I said^{'Of course, every time you access something, for the CPU to be able to compute on it, it is temporarily loaded into RAM'}. But I don't believe it has to stay there forever if you close the 'address view' for instance. It is highly implementation-dependent, but it can surely be done in a way that won't fill up your RAM.

[pooya87]

Honestly, I've checked a few wallets' code and they're all written in higher languages like Python or Java, where I'm not sure you can know exactly when something's in RAM and when not, because all that memory management is abstracted away.

You can know it, the only difference in these type of languages is that you don't have to manually allocate memory and discard it later, the framework does it for you. For example in c# as long as there is an alive reference to the memory somewhere you know it still remains in memory but as soon as that reference is no longer used, the garbage collector automatically gets rid of it.

[PrimeNumber7]

In general, if you are using a HD wallet, when you are actually using the wallet, you will need to keep the used addresses (and transaction history) in RAM, which is more expensive than HDD or SDD storage. For most casual users who use bitcoin on a personal basis, this should not be a big deal, however, for heaver users, such as businesses, this can quickly add up. The appropriate solution would be for the business to periodically create new HD wallets and retain copies of their old seed.

I don't see any reason to keep the transaction history in memory since it is not something you need to have ready for access. The addresses don't need to be kept in memory either, if saved in a database it just needs to be accessible. But even if you keep addresses in memory it still shouldn't be that expensive, a million of them could take up to about 300-350 MB of RAM. My running browser takes up more memory than that.

No current wallet software (that I am aware of) that is publically available will keep the list of addresses it needs to watch outside of RAM. I am not sure about how transactions are stored, however, they are readily available enough for me to believe they are also stored in RAM.

A business could implement their own custom HD wallet software, but I don't think they could store the addresses in their wallet outside of RAM. If they did store the addresses outside of RAM, the custom software would need to access every address every time a block is found, which would be inefficient.

Well, if you use a hardware wallet you usually have a watch-only wallet in the software, with the ability to generate addresses on the fly from the xpub, which is permanently stored on disk.

Of course, every time you access something, for the CPU to be able to compute on it, it is temporarily loaded into RAM. But not all addresses (aren't there infinitely many of them? ) have to be kept in RAM at the same time. When the software periodically checks balances, it loads xpub into RAM, generates addresses from that (kept in RAM), checks the balances and then probably writes them to disk as a sort of cache. When it's done, the RAM is flushed.

The addresses are probably even removed from RAM right after being checked, so you might actually only have one address in RAM at a time; meaning no matter how many wallets and transactions you have, memory usage should be minimal.

I know for a fact, that BlueWallet shows me the last few transactions and wallet balances as soon as I open it; then immediately starts to look if there are any changes. But it does show cached values that have been written to disk right away & only starts updating afterwards.

I am referring to businesses that have thousands of transactions per day, which works out to millions of transactions over time.

Someone who is using an HD wallet on a personal basis will generally not have so many transactions that storing all the addresses in RAM will ever be an issue.

When you open a HD wallet with most (all) wallet software implementations, the wallet will calculate the address of the 0 index, check if there are any transactions, and if not will check the next index, and will continue this process until there have been the gap limit number of consecutive addresses that have not received a transaction.

Most HD wallet software implementations will send a list of addresses to check for transactions to a server, so it would need to keep the list of addresses in RAM. Thinking about it a little bit, I think it would be possible for a custom implementation follow the above process while only keeping the list of transactions from the most recent block in RAM. Doing the above would trade "space" for "time" in updating wallet balances after each block is found.

[n0nce]

I am referring to businesses that have thousands of transactions per day, which works out to millions of transactions over time.

A transaction and also an address aren't very large, though.
One address: 160 bits = 20 Bytes => 1M addresses = 20MBytes = 20MB

One transaction: around 500 Bytes => 1M transactions = 500MB

Even a factor of 10 higher (that's a lot) due to implementation inefficiencies and whatnot would be 5GB of RAM for a business.
People often have their Chrome process eating this amount of RAM on their normal personal laptops. I believe a business can afford buying 0.5 to 5GB more RAM.

I believe we've drifted off-topic quite a bit, though.