Concerned on libdb dependency for the wallet.dat file

[99Percent]

I am an archlinux user and my bitcoin client doesn´t run anymore, because Arch automatically upgraded libdb to 5.1 but bitcoin needs to have 4.7

For more info on this see this discussion;

My concern here is portability of the wallet.dat. For maximum portability the client really shouldn´t rely on any library. I can understand that you will want to use a database for the block chain data but not for the wallet. It is simply not necessary. Correct me if I am wrong but the wallet is a series of private keys and be saved in a simple text file for maximum portability (even printable for paper backup).

I strongly suggest in the next release to remove the wallet from a database file and store it a simple text file.

[casascius]

Seems unlikely to happen given a stated intent to go to a wallet with encryption.

If it were my client, I would write a client that saved no private keys in its databases whatsoever.  It would track your balance knowing only the public keys / bitcoin addresses,  and would never require private keys except to perform a spend transaction.  They could be kept offline, perhaps on a flash drive which is plugged in just long enough to do the transaction, in a file whose name is chosen by the user and not known in advance.

If it were my client, I would probably also offer an option that used an actual SQL server as a back end, so that other applications could query the balance of arbitrary bitcoin addresses and watch for incoming payments, and otherwise locally do everything "blockexplorer" can.  The client would merely keep the database in sync with the P2P network.

[error]

Wow. After reading that, the best suggestion I can make is to never, ever use Arch Linux for anything even remotely important.

[casascius]

Wow. After reading that, the best suggestion I can make is to never, ever use Arch Linux for anything even remotely important.

By the same standards one should never use the Bitcoin client for anything important.

[error]

Wow. After reading that, the best suggestion I can make is to never, ever use Arch Linux for anything even remotely important.

By the same standards one should never use the Bitcoin client for anything important.

By what standard do you come to that conclusion?!

[casascius]

Wow. After reading that, the best suggestion I can make is to never, ever use Arch Linux for anything even remotely important.

By the same standards one should never use the Bitcoin client for anything important.

By what standard do you come to that conclusion?!

Perhaps by the number of times I've had to redownload the block chain just to get things working again after experiencing mysterious symptoms, typically related to the databases either being corrupted or losing sync with the wallet...

I believe the wallet (private keys) should be nowhere in the databases.  Instead, there should be a "File" menu under which there can be found "Open Wallet" "New Wallet" "Save Wallet" "Close Wallet", all of which operate on a simple file, preferably text, but optionally encrypted text.  The databases and wallet should not have any cross-dependencies whatsoever.

[error]

Wow. After reading that, the best suggestion I can make is to never, ever use Arch Linux for anything even remotely important.

By the same standards one should never use the Bitcoin client for anything important.

By what standard do you come to that conclusion?!

Perhaps by the number of times I've had to redownload the block chain just to get things working again after experiencing mysterious symptoms, typically related to the databases either being corrupted or losing sync with the wallet...

I believe the wallet (private keys) should be nowhere in the databases.  Instead, there should be a "File" menu under which there can be found "Open Wallet" "New Wallet" "Save Wallet" "Close Wallet", all of which operate on a simple file, preferably text, but optionally encrypted text.  The databases and wallet should not have any cross-dependencies whatsoever.

Sure, I can see the argument and it has merit. The wallet really should not depend on an external library with a long history of pointless format breakage between minor releases.

But that is only tangentially related to Arch deciding to break their Bitcoin build and then yelling at upstream about it.

[wumpus]

I believe the wallet (private keys) should be nowhere in the databases.  Instead, there should be a "File" menu under which there can be found "Open Wallet" "New Wallet" "Save Wallet" "Close Wallet", all of which operate on a simple file, preferably text, but optionally encrypted text.  The databases and wallet should not have any cross-dependencies whatsoever.

Well then, start coding Mind the scalability issues, though, as it should also work with ten thousands of keys you might understand why a database could be useful.

I personally think it would be better to support the upgrade path 4.7->4.8->5.1, that if you upgrade to a newer bdb the database automatically gets converted.

[theymos]

Does Bitcoin even use any of Berkeley DB's features with the wallet? The wallet is loaded into memory on startup, so database performance isn't very important, and I don't think Bitcoin does much (any?) concurrent access.

Berkeley DB is an easy package. It has no dependencies of its own, and compilation is simple. It would take you less than ten minutes to build the 4.7 version for Bitcoin's use.

[99Percent]

Wow. After reading that, the best suggestion I can make is to never, ever use Arch Linux for anything even remotely important.

By the same standards one should never use the Bitcoin client for anything important.

By what standard do you come to that conclusion?!

Perhaps by the number of times I've had to redownload the block chain just to get things working again after experiencing mysterious symptoms, typically related to the databases either being corrupted or losing sync with the wallet...

I believe the wallet (private keys) should be nowhere in the databases.  Instead, there should be a "File" menu under which there can be found "Open Wallet" "New Wallet" "Save Wallet" "Close Wallet", all of which operate on a simple file, preferably text, but optionally encrypted text.  The databases and wallet should not have any cross-dependencies whatsoever.

Sure, I can see the argument and it has merit. The wallet really should not depend on an external library with a long history of pointless format breakage between minor releases.

But that is only tangentially related to Arch deciding to break their Bitcoin build and then yelling at upstream about it.

Arch has a rolling release system, so it must continuously be upto date in all the installed packages. It didn´t intentionally break their Bitcoin build. You can still use Bitcoin on it, except that the wallet.dat would be saved in libdb5.1 format and therefore not transportable to another non libdb5.1 system.

Casascius suggestion is the best idea IMO. If I had the time I would try to code a push for it.

[wumpus]

Why not just add a "export wallet as JSON/XML/CSV" option (and ditto import), and leave the default database format as it is? This is best of both worlds, as the wallet is in an efficient binary format for day-to-day use, and when you want to send it to another machine (or back it up) you can export it in the text format.

[twmz]

Why not just add a "export wallet as JSON/XML/CSV" option (and ditto import), and leave the default database format as it is? This is best of both worlds, as the wallet is in an efficient binary format for day-to-day use, and when you want to send it to another machine (or back it up) you can export it in the text format.

Good idea!

https://github.com/bitcoin/bitcoin/pull/220

[wumpus]

Great!

[error]

Just to be clear, which version of Berkeley DB are the 'official' binaries built with?

[SgtSpike]

Seems unlikely to happen given a stated intent to go to a wallet with encryption.

If it were my client, I would write a client that saved no private keys in its databases whatsoever.  It would track your balance knowing only the public keys / bitcoin addresses,  and would never require private keys except to perform a spend transaction.  They could be kept offline, perhaps on a flash drive which is plugged in just long enough to do the transaction, in a file whose name is chosen by the user and not known in advance.

If it were my client, I would probably also offer an option that used an actual SQL server as a back end, so that other applications could query the balance of arbitrary bitcoin addresses and watch for incoming payments, and otherwise locally do everything "blockexplorer" can.  The client would merely keep the database in sync with the P2P network.

I approve of this client.