Topic: Bitcoin version 0.3.22 (Read 18188 times)

0.3.23 will lower the fee.

You are probably combining a shitload of tiny coins, thus making a large (in kB) transaction.

It will take a long time, unfortunately (could be a few hours), due to massive influx of new bitcoin users.  We should have that fixed in 0.3.23.

A useful workaround is -dnsseed

Updated MAC OSX link on http://www.bitcoin.org/ to point to 0.3.22, rather than 0.3.21.  Sorry I missed that detail, folks.

MAC OSX version of 0.3.22 uploaded to SF (see top post for URL).  Thanks laszlo!

This is a result of the Windows lockup on getworks.  If you call getwork, RPC thread will lock and stop responding.  Thus your miner is timing out.  As stated, Windows users who mine from a windows-hosted Bitcoin should not upgrade until 0.3.23 comes out.  There are no other known problems with this release. Sorry about that, my fault.

No wallet encryption???

No.  This only impacts miners on Windows.

So, should the rest of us downgrade?  Meaning those of us using 64-bit operating systems or only using the client for wallet management.  The reason that I ask is because of some of the network changes on the back end (not visible in the user interface).  It seems to be working for me, but I thought it would be worth asking in any event.

I get the dreaded 'problems communicating with rpc server' with this version and it never connects. Old version works fine.

OK, finally tracked this and one other 100% cpu bug down.
Other one is fixed in Pull req 304.
This one I traced back to CryptoPP ASM not working when cross compiled from Linux (as this release was) causing 100% CPU or segfault in some cases in sha.cpp X86_SHA256_HashBlocks.
DO NOT UPGRADE IF you depend on the ability to mine from a Win32 host
Ill do some more searching and see if I can figure out which flags are breaking it, or disable CryptoPP ASM for 0.3.23.
This is entirely my fault, sorry about this.

I'd like to have more options available in the clients, maybe "Bitcoin Pro" or something.
On the macro level
- Multi-wallet support, or at least ability to switch wallets between program loads (i.e.load alternate wallet file)
On the micro level
 - ability to see the mean/median/mode fees that the nodes charged for the last few blocks
 - ability to adjust fee below (i.e. ignore) the .0005 level / tax or any future level tax, as a personal judgement, possibly to one of preset values (described above) (adding an additional field above or below send amount on the send popup screen seems the best interface to allow fee choices)
 - showing each public address balance separately from the total private wallet balance (i.e. 3rd column in address book for balance *and* additional tab for public address balances)
 - ability to manually choose which public addresses are sending BTC instead of the client choosing (extra option for public address to debit, best is ability to choose from all public address balances in any increments up to that accounts balance.
e.g. send screen reads:  
"DEBIT AMOUNT ______ BTC FROM _____ ACCOUNT" <---filling both entries here opens an additional line
"DEBIT AMOUNT ______ BTC FROM _____ ACCOUNT" etc.
Drop down menus preferred but use of address book feature would work, showing balances as above.
 - ability to pay multiple accounts at once. Similar to above,
"CREDIT AMOUNT _______ BTC TO  _______ ACCOUNT" <---filling both entries here opens an additional line
"CREDIT AMOUNT _______ BTC TO  _______ ACCOUNT" etc.

I know several pools have these features, not sure if there's end-user interface for it though.


Name your price/s, although I suspect there are many other users who would enjoy these features.

edit, I'm going to post this to the development thread, please follow up there instead of here.

My client slowly worked up to 24 connections.  My pool payout showed instantaneously in the new client.  Seems all is good.  Probably best if everybody updates to get everybody communicating the same via IRC.

It isn't even version 1.0 yet.  I would call it beta too.  There is now a worthless CPU miner in there and honestly, the GUI should be separate from the package ... yes, beta is valid.   It is a working beta however, there can be no doubt about that.

Why does about always seem to say "-BETA" ? Is this a beta? Same thing with the previous version.

Funny ... Linux has been suffering for several years from the equivalent of the infamous Windows "DLL Hell" which has largely been solved for most application development on Windows [.NET largely minimized it, although it is not gone ... GAC issues can still be a problem, but otherwise, installers tend to include the run-time requirements if missing on the OS].  I have done a lot of work with Linux since December 1996 (Redhat, Slackware and some Debian in the early days, later built my own distribution and work closely with the build your own Linux crowd where we built from source to optimize for our machines and that naturally led to Gentoo).  For all my server needs however, FreeBSD (which I have been using since early 1997 I think ... version 2.2 anyway] has been my platform of choice [excluding Microsoft needs ... which is my professional work] and they keep compatibility libraries available [if you install them, or compile them if you rebuild the OS from source] and even with Linux emulation they do a reasonable good job [RPM based IIRC].  I simply built everything from source and rarely had an issue unless one of their ports was broken or sometimes when I was compiling something not in ports ... naturally that takes work anyway.  LIBC compatibility is pretty much a non-issue in FreeBSD period.  I so wish NVidia and ATI/AMD would focus efforts on drivers for FreeBSD as well [NVidia does, but I don't believe they even closely match Windows drivers in Windows, ATI/AMD ... nothing that I am aware of].

Linux is just a kernel [and you could include supporting utilities], unfortunately.  The rest is the operating system built around it, most largely similar, but all built according to what the distribution prefers and laid out in different ways such that you often can't safely install any packages from other distributions even if they use the same packaging system [i.e. deb and RPM].  Even with better vendor support with Linux, I still do not get near the performance mining using ATI drivers on Ubuntu 11.04.  Trying to install the latest 11.05 catalyst hit the libc nightmare and I didn't want to take any more time and found my old Vista license activated fine on the machine I was using and it works great

Is this new version built against newer libraries for a good reason?  I'm gonna have to stick with an older version too it seems. 

And if it somehow wasn't, it should be backed up securely before any upgrade anyway [unless it is empty I suppose].

An update just changes the software.  Your wallet is compatible across software upgrades.

It makes payments very slow to occur though [or appeared to], so I am not sure the incentive is there for most people except the ability to enter 0.005 transaction fees [or receive payment out to eight digits I believe was also added although most pools don't support that yet].  I don't think there is a great incentive to upgrade.  I will update in any event to do my part, but if adoption remains low and receiving payments proves latent, then I will go back.

This is the result of splitting up the IRC channel. The new 'split-up' channels are relatively empty now, compared to the original single channel. This should improve significantly as more users switch to 0.3.22.