Concerned on libdb dependency for the wallet.dat file

SgtSpike

legendary

Activity: 1400

Merit: 1005

Quote from: casascius on July 15, 2011, 01:10:55 AM

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.

error

hero member

Activity: 588

Merit: 500

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

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Great!

twmz

hero member

Activity: 737

Merit: 500

Quote from: wumpus on July 15, 2011, 07:25:41 AM

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

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

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.

99Percent

full member

Activity: 411

Merit: 101

🦜| Save Smart & Win 🦜

Quote from: error on July 15, 2011, 01:34:08 AM

Quote from: casascius on July 15, 2011, 01:20:17 AM

Quote from: error on July 15, 2011, 01:16:11 AM

Quote from: casascius on July 15, 2011, 01:14:52 AM

Quote from: error on July 15, 2011, 01:13:47 AM

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.

theymos

administrator

Activity: 5222

Merit: 13032

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.

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: casascius on July 15, 2011, 01:20:17 AM

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.

error

hero member

Activity: 588

Merit: 500

Quote from: casascius on July 15, 2011, 01:20:17 AM

Quote from: error on July 15, 2011, 01:16:11 AM

Quote from: casascius on July 15, 2011, 01:14:52 AM

Quote from: error on July 15, 2011, 01:13:47 AM

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.

casascius

vip

Activity: 1386

Merit: 1140

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

Quote from: error on July 15, 2011, 01:16:11 AM

Quote from: casascius on July 15, 2011, 01:14:52 AM

Quote from: error on July 15, 2011, 01:13:47 AM

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

hero member

Activity: 588

Merit: 500

Quote from: casascius on July 15, 2011, 01:14:52 AM

Quote from: error on July 15, 2011, 01:13:47 AM

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

vip

Activity: 1386

Merit: 1140

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

Quote from: error on July 15, 2011, 01:13:47 AM

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

hero member

Activity: 588

Merit: 500

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

casascius

vip

Activity: 1386

Merit: 1140

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

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.

99Percent

full member

Activity: 411

Merit: 101

🦜| Save Smart & Win 🦜

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.

Topic: Concerned on libdb dependency for the wallet.dat file (Read 1713 times)