Topic: Please help test:Bitcoin versions 0.4.1 and 0.5 - page 2. (Read 5298 times)

Is version 0.5 safe enough to recover a backed up wallet from? 0.4 isn't downloading the block chain when I try to recover.

Good morning,


This seems to fix my problem, bitcoin starts now after it has rewritten the wallet.dat.

Its so pretty

Is it just me, or is downloading the blockchain significantly faster?

You can use the appropriate BerkeleyDB utilities with the two caveats:

1) they need to be from the exactly same build as the BerkeleyDB library that you linked to;

2) manually create "DB_CONFIG" file contailing one line "set_lg_dir database".

Win7 x86, 0.5rc7 - everything is ok. New UI - nice.

Release Candidate 7 binaries are available at:
  https://sourceforge.net/projects/bitcoin/upload/Bitcoin/bitcoin-0.5.0/test/

Difference between rc6 and rc7 :  rc7 does not remove BDB (Berkeley database) log/* files, because that is causing un-readable wallets on some people's machines (all the reports were from people running 64-bit version of Linux, but that might have just been coincidence-- I could never reproduce the problem in any of my test environments).

What that means:  old private keys can remain in a file on your disk even after wallet encryption, but they will eventually be removed.  Details:

BDB closes the old logfile and opens a new one when it get close to 10megabytes big.

When bitcoin shuts down cleanly, it asks BDB to remove any unused log files, and BDB will remove all but one file from database/log.*

So: if you encrypt your wallet, unencrypted private keys will be in the old part of the log file. But after running for a half a day or so, BDB will close that old log file and open a new one. Then, the next time you restart bitcoin, the old log file containing the unencrypted keys is removed.

This seems like a reasonable compromise between security and safety for now; a better wallet encryption solution for the next version of bitcoin (for example, one that doesn't require shutting down and restarting after encrypting the wallet) is a good idea, but out of scope for this release.

Version: 0.5.0rc6 upgraded from bitcoin(-qt) git from 15th October with wallet encryption enabled
OS: Slackware64 13.37, have multilib environment but bitcoin is built 64bit.

It starts and says wallet needed to be rewritten, restart to complete.
After that it fails with:


Argument ist ungültig is german for: invalid argument

Notes:
I am using berkley db 4.6
upnp is disabled by adding "USE_UPNP=-" after the qmake command (bitcoin-qt.pro says this is not supported, but it worked)
and this wallet has some manually imported privatekeys which I did with pywallet.py (was done before encryption)

With a new generated wallet it seems to work fine so far.

So the automatic rewriting of the wallet.dat fails for me, how to find out more about
what happend, is db_verify useful?

Thats what it shows after it was rewritten, my backup shows no error if I do that.

Was previously using: 0.4
Installed: 0.5rc6
OS: Mac OS X 10.6.8
Processor: Intel Core 2 Duo (64-bit, as I think just about everything is now)
Not using the in-client wallet encryption before or after.

Installed fine. I appreciate that the executable has a different name so that by default both 0.4 and 0.5rc are installed side by side. Is the plan to have the actual release be Bitcoin.app instead of Bitcoin-qt.app, or to keep them separate? (I might suggest that if keeping them separate, a name like Bitcoin-0.5.app might be more user-friendly.

The app seems to run in 32-bit mode, which isn't really a problem, but it's one of the few apps on my system that does.

I could send coins fine, and really appreciate the multiple-recipient feature is built into the GUI rather than needing to use the command line. On a related-in-my-mind-but-maybe-not-anyone-else's note, I find sending to multiple users useful in part so that I can add on a recipient that's an address in my same wallet, because if I'm sending a small transaction, by making the transaction bigger (by tacking on, say, a 10 BTC payment to my own wallet), I can have it pick different source transactions and not ask to pay a fee. I don't think that the suboptimality of the coin picking algorithm in certain cases is anything new, but it's nice that I can do the add-more-coins workaround in the client itself now.

Also tested and seems to work: receiving coins, upnp, and all my data seems to still be there! (I do of course have backups of my wallet, but it's nice to have such a big upgrade and not need to use them.)

Thank you for all your work!

Absolutely no guarantee is made that old, pre-rc6 private keys will not end up unencrypted somewhere on the disk.

There is no guarantee that newly generated, post-rc6 private keys will not end up on the disk, either, although the code tries to keep that from happening (locking memory so it is not swapped to disk, for example).

There should be no files containing unencrypted private keys after rc6 rewrites the wallet, though.

Thanks for helping test!

Virtualbox can run 64 bit guest on 32 bit OS with VT-x. Of course it would be helpful to know exactly what distro (and Qt version etc) the error was produced on, and if it was a fresh Bitcoin install or an upgrade.

I made a test WinXP environment for this, where I set up a 0.3.24 install and received and sent coins on it (and the private key does end up in the log files as well as a few more times in the wallet after receiving and resending), and then defragged, cleared temp files, and wiped the free space with 0s before imaging. I specified only 4 keypool keys on first execution, but bitcoin added the 100 the next run(why?) I verified that 0.4.1rc5 deleted all logs on shutdown even without running encryption. More testing of encryption will come, I'll see if the private key is present on the disk image at all after 0.3.24->0.4.1, 0.4->0.4.1, and ->0.5 when converting and encrypting (which requires care to not inadvertently put the key on the disk by searching -> MUI registry entries, save keys in text files, pywallet --web -> browser cache, etc).

Wrote a long evaluation full of brilliant similes and unparalleled insight. Then my jerkass browser crashed, so here's a list of whiny complaints about the GUI instead:

Good:
1. Hate modal windows. Send/receive on tabs is an improvement.
2. (all of the changes I didn't complain about, obviously)

Good-impaired:
1. The old icon/logo looked better.
2. Don't see the point of the "overview" tab. Everything presented there could (and should) be available in the transactions tab instead.
3. Your total balance should be available on every tab and in the same location (top left IMO).
4. Not a fan of tooltip-heavy software.
5. Should be able to see the number of confirmations without hovering.
6. Should be able to see connections and block total without hovering.
7. Any way to disable the -Transaction Received- tray message?
8. "Minimize to tray instead of taskbar" doesn't seem to do anything. When it's on, the program (when minimized) "disappears" from the taskbar and then instantly reappears there again.
9. I think it would be more convenient if all the buttons were in the same general area. Right now three of the tabs have buttons at the bottom of the window. Seems like a minor issue, but things like that can get annoying pretty quickly (especially if you run the GUI client maximized).
10. Splash image looks a bit cheesy.

I don't have a Linux64-with-GUI machine available to try to debug this, and I've failed to reproduce it on an Ubuntu 10.10 'maverick' server.

If you can, please test (and, if you can, help debug) on 64-bit Linux.  This is the last issue holding up the release.

tested Bitcoin-Qt.app  on 10.6.8 Mac OS
I only backed up the /Users/mila/Library/Application Support/Bitcoin
last used by 0.3.24-beta bitcoin client.

worked me for me easy and smooth.
The sorting of addresses in old version was broken, now it works fine (once sort by addresses was selected, switch to sort by label was not working anymore), sort desc/asc by address labels work ok.
Send to many transaction - big thumbs up! Thank you very much.
I appreciate very much easier use of the client app (p.ex. when creating new address, cursor & focus move to the new window and I can start typing immediately, in 0.3.2x I had to click on the field first). It saves me a lot of time.

neutral:
my client needed a while to start. nice to see the changing text while waiting
and the changes in look are a subtle move to the better ; )

Next time I'll try wallet encryption. Since I did not use the 0.4 client, I can not test re-encryption. I could restore 0.3.24 backup and try 0.4, encrypt wallet and then test something in 0.5.0 if you write me what exactly to do?

Just tried testing 0.5.0 on Linux64..  Here's the result:

************************
EXCEPTION: NSt8ios_base7failureE       
CAutoFile::read : end of file       
bitcoin in Runaway exception       

terminate called after throwing an instance of 'std::ios_base::failure'
  what():  CAutoFile::read : end of file

[1]+  Aborted                 ./bitcoin-qt


Obviously, it did not start up.

Updated to release candidate 6:
 https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.1/test/
 https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/test/

Two changes were made between rc5 and 6:
1) When you encrypt your wallet for the first time, a new keypool is created before Bitcoin-Qt/bitcoind shuts down. This prevents losing bitcoins if you backed up your newly-encrypted wallet, received coins to new addresses, and then later restored from the backup.

There is still a potential problem when you upgrade a previously-encrypted wallet:  in that case, the wallet file is rewritten on startup and will be left with an empty keypool (new keys cannot be written because in this case the code doesn't have your wallet passphrase). The release notes suggest backing up the re-encrypted wallet after generating a new address.

2) Be less aggressive about deleting the database/log.* file(s) on shutdown -- with rc6, they are only deleted if the wallet is successfully encrypted/re-encrypted (to make sure unencrypted private keys are not left in them).

Please report only show-stopper bugs in this thread-- normal bug reports or feature suggestions should go into the github issue tracker:
  https://github.com/bitcoin/bitcoin/issues

Please DO add to this thread if you've done some testing, giving what you tested (0.4.1? 0.5.0 ? win32 exe ?  zip ? linux ?), what operating system you tested on, and if you were testing a fresh install or upgrading (and if upgrading, was your wallet encrypted before?).

Great work on the GUI

Testing the 0.5 client... minor typos and things:

1. On the "Receive coins" screen, when you mouse over the list of addresses, the tooltip says "Double-click to edit address or label".  Since you can't actually edit the receiving addresses, the tooltip should say "Double-click to edit label".  Be sure not to change the tooltip on the "Address book" screen, since you can edit both the label and the address there.

2. On the "Transactions" screen, when you mouse over the list of transactions, at the end of the tooltip, add "Double-click for more details", since people may not know they can do that.

3. On the "Receive coins" list, why not completely remove the "delete" button instead of just disabling it?

4. On the "Send coins" screen, the tooltip for the address book button is misspelled: "Choose adress from address book" (missing a "d")

Suggestions:

1. Always show the balance on the left side of the status bar at the bottom (regardless of the tab I'm on)

2. On the "Receive coins" and "Address book" tabs, have filter controls at the top to filter the list by label and/or address (just like in the transactions list)

3. On the Send tab, when you choose milli or micro BTC, show the same text as the tooltip to the right of the drop-down box.  People don't always leave their mouse still enough to see the tooltips, and a lot people won't understand what mBTC and µBTC are.

4. On the Transactions tab, add a column on the right that shows what the balance was after each transaction.

5. ON the Send tab, add a line right above the "Send" button with text like this:  "Sending X BTC, balance after sending will be Y BTC."


Edit: Awesome job on the new UI, it's a big improvement over 0.4.x

I have found a concern relating to Bitcoin (all versions) on Windows on an active directory domain member.

The Bitcoin data directory is under %APPDATA%, an alias for CSIDL_APPDATA. On WinVista and Win7 this typically resolves to "C:\Users\{logon}\AppData\Roaming", on Win2000/XP to "C:\Documents and Settings\{logon}\Application Data".

The problem this presents is that this folder is used for roaming user profiles. When logging on to a domain that uses roaming profiles, the entire directory is synchronized with the server. This would mean sending up to 1GB of blockchain between the server and logon computer before the user can use their station. Admins may also opt to have the entire profile be a user network share without local storage.

In addition, this means that the private wallet data is stored on both the logon computer and the server. If the user logs on to another network machine, the user profile is then completely copied to the second machine. This also means anyone with "power user" rights can read the profile data on the second machine. This becomes less of a concern with an encrypted wallet, but you are still spreading your Bitcoin data anywhere you log in, with a copy for the admins to read too.

Windows Vista/7 have lessened the data transfer concern with the addition of %LOCALAPPDATA%, "C:\Users\{logon}\AppData\Local" typical. This is non-roaming profile data, used for caches, temp files, the entire install and user data of Google Chrome, etc. This seems like a more appropriate location for the Bitcoin data directory. For Win2000/XP/Me, the analogous location is C:\Documents and Settings\{logon}\Local Settings\Application Data, but XP doesn't have the environment variable. Here are some XP methods to determine the directory.

In this line of examination, one might wonder if it isn't appropriate to take all program data except the wallet out of userland. If Mom, Dad, and little Billy all use bitcoin with their own computer logins, there doesn't need to be three complete blockchain downloads. The program data could be moved to CSIDL_COMMON_APPDATA (C:\ProgramData), and the user data could be only the wallet, and perhaps a 'last_block' counter file that indicates for a rescan for any wallet transactions after the user's last seen transaction block; forces a complete rescan if the counter isn't present...

Tested and have found no problems.

However, if i may make a suggestion, I came across a possible usage caveat today. I was withdrawing some coins from bitcoinica, so I opened the client and clicked on "Address book" then copied the address i had labeled "Bitcoinica" to the clipboard. However that address is actually the address for depositing coins into bitcoinica not a receiving address. On the "address book" tab i think it should be clearly labeled they are addresses for sending coins. Or combine the "Receive coins" tab and "Address book" tab with sending and receiving address tables on top of each other.