Weird entry showing up in listreceivedbyaccount

[genjix]

I have never had more than 100 BTC in my account ever.

What is this first entry all about?

Code:

[
    {
        "account" : "",
        "label" : "",
        "amount" : 212.67000000,
        "confirmations" : 1441
    },
    {
        "account" : "127.0.0.1",
        "label" : "127.0.0.1",
        "amount" : 5.04000000,
        "confirmations" : 1
    },
    {
        "account" : "Your Address",
        "label" : "Your Address",
        "amount" : 5.25000000,
        "confirmations" : 3
    },
    {
        "account" : "betcoin",
        "label" : "betcoin",
        "amount" : 14.34000000,
        "confirmations" : 6368
    }
]

[genjix]

ok I'm worried something is very wrong here.

- I backed up my wallet.dat
- Downloaded, made svn
- Sent my sister 10 BTC (still not showing after 3 confirmations for her).
- When I try to open the old bitcoin I get:

Code:

************************
EXCEPTION: 22DbRunRecoveryException       
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery       
bitcoin in AppInit()       



************************
EXCEPTION: 22DbRunRecoveryException       
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery       
bitcoin in CMyApp::OnUnhandledException()       

terminate called after throwing an instance of 'DbRunRecoveryException'
  what():  DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
Aborted

Have I ruined everything??

[nanotube]

if you have a recent backup, use it, and try to open it in the .17 release client. preferably gui, so you can see all transactions at a glance.

[genjix]

if you have a recent backup, use it, and try to open it in the .17 release client. preferably gui, so you can see all transactions at a glance.

Nope. I restored my backup and still the same thing happens in .17 release client.

EDIT: nevermind ignore this stupidity. My sister hadn't downloaded all the blocks yet. That's why it wasn't showing up yet.

However my OP still stands.

[nelisky]

Are we seeing the first "pretty much impossible" collision here?

Time to look for a transaction with that value and age on your histories, folks...

[bencoder]

Are we seeing the first "pretty much impossible" collision here?

How are the addresses generated?

Although obviously there's technically a huge huge number of them, they are limited by the randomisation function used to generate them, unless the openssl libs do something a lot more clever (got as far as EC_KEY_generate_key, but got lost in the openssl source). Typically randomisation will be seeded by the clock value, which will probably be in milliseconds, so there seems that there's a definite/significant possibility of collisions. Hopefully someone can educate me on why this isn't a problem.

[Gavin Andresen]

genjix, you're the third person to run into this problem; I'm looking into it.

I suspect the problem is running a later svn version and then running the same wallet with an earlier svn version; the format of wallet transactions changed recently to support the 'accounts' feature.

Your bitcoins are still safe in the wallet (all the private keys are still in there).  Stay tuned...

[nelisky]

genjix, you're the third person to run into this problem; I'm looking into it.

I suspect the problem is running a later svn version and then running the same wallet with an earlier svn version; the format of wallet transactions changed recently to support the 'accounts' feature.

Your bitcoins are still safe in the wallet (all the private keys are still in there).  Stay tuned...

3rd person... ok, I cried wolf here with the collision thing

Nothing to see, move along now...

[jimbobway]

I archived my wallet to be opened 16 years from now.  Will I run into a similar problem?

[Gavin Andresen]

I archived my wallet to be opened 16 years from now.  Will I run into a similar problem?

Peer into my crystal ball with me as we predict the future....

No, seriously, upward compatibility (reading old wallet.dat's into new versions of bitcoin) shouldn't be an issue.

And Satoshi and I are discussing possible fixes for the upgrade/downgrade/upgrade scenario that we think is causing this.

[nelisky]

I archived my wallet to be opened 16 years from now.  Will I run into a similar problem?

Peer into my crystal ball with me as we predict the future....

No, seriously, upward compatibility (reading old wallet.dat's into new versions of bitcoin) shouldn't be an issue.

And Satoshi and I are discussing possible fixes for the upgrade/downgrade/upgrade scenario that we think is causing this.

Ok, so I'm repeating myself quite a bit these days, must be the age catching up, but if we want real long term backups, we need a way to both export and import the priv keys...

[genjix]

I'll just jump back in here and confirm that everything is fine. Transactions I make to old other bitcoin clients do show up. And overall my balance works and everything. Guess I'm stuck with the command line non-gui bitcoind for the time being 

I heard that you need to backup your wallet after every transaction otherwise the backup is invalid. Is this true?

Can anyone recommend me an auto-backup configuration for Ubuntu?

[caveden]

I heard that you need to backup your wallet after every transaction otherwise the backup is invalid. Is this true?

Not anymore, now there is a pool of addresses stocked in advance. Every time the client needs one, it gets from this pool. The pool default size is 100 I guess.
The client needs new addresses every time you send money and every time you create an address for reception. The reception itself doesn't need new keys.

[genjix]

I heard that you need to backup your wallet after every transaction otherwise the backup is invalid. Is this true?

Not anymore, now there is a pool of addresses stocked in advance. Every time the client needs one, it gets from this pool. The pool default size is 100 I guess.
The client needs new addresses every time you send money and every time you create an address for reception. The reception itself doesn't need new keys.

Great. So I can just update every week manually? (Presuming I use less than 100 addresses in that time)

What happens once 100 addresses are exceeded and you backed up your wallet 101 addresses ago?

PS: Anyone can recommend some kind of automatic backup software for Linux?

[caveden]

What happens once 100 addresses are exceeded and you backed up your wallet 101 addresses ago?

Then you have at least one address which is not backed up.

[Gavin Andresen]

PS: Anyone can recommend some kind of automatic backup software for Linux?

My automatic backup strategy is:

Cron task that runs a shell script twice a day.

The shell script does:
call bitcoind backupwallet to create a time/date-stamped wallet file
gpg encrypt the wallet with my public key
copy the result to an off-machine backup location
 (I'm using Amazon S3, which is itself redundantly backed up to multiple geographic locations automatically)

Shell script looks like:

Code:

#!/usr/bin/env bash

GPGU="Gavin Andresen"

TS=$(date "+%Y%m%d-%H-%M")

WALLET=/tmp/clearcoinwallet${TS}
WALLET_E=/tmp/clearcoinwallet${TS}.crypt

~/bin/bitcoind backupwallet $WALLET
/usr/bin/gpg -r "$GPGU" --output $WALLET_E --encrypt $WALLET
~/bin/s3cmd put $WALLET_E s3://NAME_OF_MY_S3_BUCKET
rm $WALLET $WALLET_E

I'd suggest doing something similar (replace the s3cmd with an scp to copy somewhere if you're not an S3 user; you could even ftp somewhere, since the wallet is encrypted it doesn't matter if somebody is eavesdropping).

[genjix]

thanks! that's great. I'm going to set this up with cron.

http://www.bitcoin.org/wiki/doku.php?id=more_faqs

I added it there.

[nanotube]

gpg encrypt the wallet with my public key
copy the result to an off-machine backup location

i do the same thing... but let me ask you - how about your private half of the gpg keypair? do you have any backups of that, and if so, where do you keep them and how do you keep them safe, etc.? cuz with gpg encrypted backups, if you lose your key, you're sol?

[Gavin Andresen]

My private gpg key is kept in my LastPass Vault (as a secure note), along with all of my passwords.

I'm a big fan of LastPass; Steve Gibson did a good review of their tech and why it's safe on a Security Now podcast a while back.

[theymos]

The private key is symmetrically encrypted, so you don't need to worry that much about keeping the file secret. I changed the cipher used from CAST5 to AES, though.