bitcoin.sourceforge.net is down

In case you weren’t aware, the Bitcoin website is down.

http://bitcoin.sourceforge.net/

You are running bitweaver in TEST mode

* Click here to log a bug, if this appears to be an error with the

application. * Go here to begin the installation process, if you haven’t done so already. * To hide this message, please set the IS_LIVE constant to TRUE in your kernel/config_inc.php file.

I downloaded it and it runs. It and it is using plenty of CPU, so I think it’s working properly. It has not downloaded previously generated blocks. Is that a bug or a new feature?

The system tray in Gnome is not very reliable. Sometimes an icon will disappear leaving no way to get back to the program. I have verified that this can happen with bitcoin. It would be nice if starting bitcoin while it’s already running would just bring up the GUI of the already running bitcoin process.

That is what I meant. The blocks displayed in the status bar did not increase at all while i ran the program. I have attached my debug.log.

A good way for you to test the tray icon in Gnome is to remove the notification area and then add it back. If the icon is still displayed after adding the notification back, then it’s working correctly.

I generally set application preferences to not minimize to the tray, but to close to the tray. And I keep the application minimized. That way I don’t accidentally close the program and still have the convenience of being able to open the application from the tray. (I don’t display open windows in the ‘task bar’ but I have an icon that if clicked displays open windows as sub-menu items.) Then if the tray icon disappears, I go into the settings disable and re-enable the tray icon setting to get it to reappear. That’s currently not possible with the bitcoin preferences because the close to tray check mark can not be enabled without the minimize to tray check box being enabled.

Ok, blocks have now started to increase. It definitely takes longer for them to start increasing than with the Windows version. Also, I think they might be increasing at a slower rate than in with the Windows version. Is there perhaps debugging enabled in the Linux build that you sent me? Block are increasing at about 15 blocks per second (eyeball estimate while looking at a clock). I didn’t time how fast they increased in the Windows version, but it seems like it was much faster.

It took about a half hour for it to start incrementing quickly. Interestingly, the CPU usage increased before it started to increment steadily and then lowered when it started to increment steadily. Although this time the block incremented to 2 within the first few minutes. I have not yet generated any bitcoins. I’ll wait for as long as I have patience to generate a bitcoin, but if none are created by the time I lose patience, I’m going to move back to the wine version.

I’ve included my current debug.log.

When I launch bitcoin and the bitcoin port is not available, I get the following messages to the command line. I don’t get those messages when the bitcoin port is available. Would it be possible for bitcoin to pick another port if the default port is taken? The same think sometimes happens to me with my BitTorrent client. When I restart it, my previously open port is closed. All I have to do is change the port and it starts working again.

/usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgioremote-volume-monitor.so /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgiogconf.so

The reason I run two instances at the same time is to transfer bitcoins from one bitcoin instance to another. They of course would need to be accessing different data directories. Perhaps that could be specified as a command line argument. I currently have to move my bitcoin data folder to a virtual machine to do this. Shutting down bitcoin and restarting it with a different data directory is a poor solution because shutting down bitcoin while there are unconfirmed bitcoins risks losing those bitcoins.

Bitcoin was definitely not running when i get the busy port error. The process closes quickly and reliably from my experience, but it takes anywhere from 30 seconds to 3 minutes (estimation from memory) for the port to become available again. It occurred while switching from bitcoin 0.1.5 in Wine to the Linux build and again while switching from the Linux build to bitcoin 0.1.5 in Wine.

Another thing that I noticed is that the about dialog text does not fit correctly and it cannot be resized.

Another instance when I would like to run multiple instances is when I upgrade bitcoin. I will uncheck the generate coin check box in the outdated bitcoin, launch and start generating coins in the new bitcoin using a separate data directory, then when the old application’s coins have matured I will send them to the new application and then close the old application. I prefer do do clean installs rather than upgrading while maintaining old data.

Everyone that contributed to making this Linux build really did a great job! Thanks for the hard work. It has started maturing some bitcoins, so I’m going to continue to run the Linux client for the time being until I decide whether it’s at least as good or better at generating coins than the Windows version running in Wine.

The Linux build has generated a decent amount of bitcoins within the past 20 hours and I trust what you’re telling me about database errors, so all signs point toward me running the Linux build from now on. The only half annoying thing about the Linux build is that my computer’s fan has gone from 50% to 100%. :-P I know I can limit the CPU, so if it gets on my nerves too much and if I can live with less bitcoins being generated, perhaps I’ll do that. Or maybe I just need to start listening to more music…

I just lost 6 sets of maturing coins! I had 10 sets of bitcoins maturing. The last set was generated at about 0:22. It got to 2/unconfirmed before bitcoin got stuck. At 10:10, the bitcoin which was generated at 0:22 was still only at 2/unconfirmed. Since you had told me that I wasn’t going to lose coins, I shutdown and restarted bitcoin. On the bright side, it shutdown and started up very smoothly. But unfortunately, when the blocks updated, I lost 6 sets of bitcoins. Four sets were still unconfirmed, but two sets were confirmed. And there’s no trace of them now. Perhaps now that you have the ‘Show Generated Coins’ option available, you can put back in failed bitcoin generations. I just don’t like that those bitcoins just disappeared into thin air. I’m still running the Linux build at the moment, but the Wine version is suddenly looking much more attractive now that 6 out of the 10 sets of bitcoins I generated in the past 24 hours just vanished. I’ve included my debug.log.

My network connection is direct to my computer. My ISP requires that I run VPN to connect to the Internet. I then have a second NIC that shares my Internet with other devices. My IP address while using my computer is my actual IP address, but the devices connected through my second NIC use NAT. When I connect through a virtual machine, that also uses NAT. All this requires very little configuration. NetworkManager in Ubuntu has an option to share my Internet connection through the second NIC and VirtualBox has the option to use NAT.

I lost a couple packs of bitcoins again, so that problem is not yet fixed. It’s a bit more bearable now that I have an idea of what is going on. I figure for now I’ll just restart bitcoin whenever I see a pack of bitcoins starting to mature. I may go back and forth a bit between Linux and Wine, but I’ll definitely test every new version that comes out. At the moment I’m still running the Linux build.

I have been getting your attachments just fine. I just thought I’d spare Martti the large attachment.

I am not able to reproduce the bug. I don’t know whether the paste, the blocks finishing, a combination of the two or something else entirely caused the fault.

…

But after they started downloading, I took a look a look at my BitTorrent client, and sure enough, I had forgotten about a torrent and my upload was quite high, at the limit I had set for it.

I moved the data directory back to my SSD card and started bitcoin test 6. It encountered a segmentation fault today with Db::open in the log. I had changed the settings to only use one processor/core while I watched a 720p mkv movie. I noticed the segmentation fault after the film had ended.

I started with a fresh data directory with test7. Blocks started to download much faster. It only took about 15 seconds where it took a few minutes previously with the Linux build. It crashed once while it was downloading blocks with the following message in the terminal.

../include/wx/thrimpl.cpp(50): assert “m_internal” failed in TryLock(): wxMutex::TryLock(): not initialized [in child thread] Trace/breakpoint trap

I’ve included my log file, but I forgot to back it up before restarting bitcoin, so I’m not sure at what point in the log file the crash occurred.

Fortunately I haven’t encountered the segmentation fault yet. The frequency of segmentation faults in the previous builds varied quite a bit, so I’ll keep running it and let you know if i run into any problems.