Bitcoin Forum
December 03, 2016, 12:33:25 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Concerned on libdb dependency for the wallet.dat file  (Read 1439 times)
99Percent
Full Member
***
Offline Offline

Activity: 179



View Profile
July 15, 2011, 06:06:00 AM
 #1

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.
1480725205
Hero Member
*
Offline Offline

Posts: 1480725205

View Profile Personal Message (Offline)

Ignore
1480725205
Reply with quote  #2

1480725205
Report to moderator
1480725205
Hero Member
*
Offline Offline

Posts: 1480725205

View Profile Personal Message (Offline)

Ignore
1480725205
Reply with quote  #2

1480725205
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


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


View Profile WWW
July 15, 2011, 06:10:55 AM
 #2

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.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
July 15, 2011, 06:13:47 AM
 #3

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

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


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


View Profile WWW
July 15, 2011, 06:14:52 AM
 #4

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.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
July 15, 2011, 06:16:11 AM
 #5

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?!

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


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


View Profile WWW
July 15, 2011, 06:20:17 AM
 #6

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.


Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
July 15, 2011, 06:34:08 AM
 #7

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.

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
July 15, 2011, 06:42:41 AM
 #8

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 Smiley 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.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
July 15, 2011, 06:52:07 AM
 #9

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
99Percent
Full Member
***
Offline Offline

Activity: 179



View Profile
July 15, 2011, 11:43:36 AM
 #10

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
Hero Member
*****
qt
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
July 15, 2011, 12:25:41 PM
 #11

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.


Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
twmz
Hero Member
*****
Offline Offline

Activity: 737



View Profile
July 15, 2011, 12:34:48 PM
 #12

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

Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
July 15, 2011, 12:49:43 PM
 #13

Great!

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
July 16, 2011, 05:45:01 AM
 #14

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

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
July 16, 2011, 05:46:46 AM
 #15

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.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!