99Percent (OP)
Full Member
 Offline
Activity: 402
Merit: 100
🦜| Save Smart & Win 🦜
|
 |
July 15, 2011, 06:06:00 AM |
|
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. |
|
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1136
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
|
July 15, 2011, 06: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.
|
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 or hardware wallets instead.
|
|
|
|
error
|
|
July 15, 2011, 06: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.
|
3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1136
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
|
July 15, 2011, 06:14:52 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. |
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 or hardware wallets instead.
|
|
|
|
error
|
|
July 15, 2011, 06:16:11 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?! |
3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1136
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
|
July 15, 2011, 06:20:17 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. |
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 or hardware wallets instead.
|
|
|
|
error
|
|
July 15, 2011, 06:34:08 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. |
3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
|
|
|
|
wumpus
|
|
July 15, 2011, 06:42:41 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. |
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 File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts. |
|
|
theymos
Administrator
Legendary
Offline
Activity: 5194
Merit: 12972
|
|
July 15, 2011, 06:52:07 AM |
|
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 (OP)
Full Member
Offline
Activity: 402
Merit: 100
🦜| Save Smart & Win 🦜
|
|
July 15, 2011, 11:43:36 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. |
|
|
|
|
wumpus
|
|
July 15, 2011, 12:25:41 PM |
|
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 File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts. |
|
|
|
twmz
|
|
July 15, 2011, 12:34:48 PM |
|
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? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal. |
|
|
|
wumpus
|
|
July 15, 2011, 12:49:43 PM |
|
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 File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts. |
|
|
|
error
|
|
July 16, 2011, 05:45:01 AM |
|
Just to be clear, which version of Berkeley DB are the 'official' binaries built with?
|
3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
|
July 16, 2011, 05:46:46 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. |
|
|
|
|
|
