Bitcoin Forum

Download URL: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/

This is largely a bugfix and TX fee schedule release.  We also hope to make 0.3.23 a quick release, to fix problems that the network has seen due to explosive growth in the past week.

Notable changes:

• Client will accept and relay TX's with 0.0005 BTC fee schedule (users still pay 0.01 BTC per kb, until next version)
• Non-standard transactions accepted on testnet
• Source code tree reorganized (prep for autotools build)
• Remove "Generate Coins" option from GUI, and remove 4way SSE miner.  Internal reference CPU miner remains available, but users are directed to external miners for best hash production.
• IRC is overflowing.  Client now bootstraps to channels #bitcoin00 - #bitcoin99
• DNS names now may be used with -addnode, -connect (requires -dns to enable)

RPC changes:

• 'listtransactions' adds 'from' param, for range queries
• 'move' may take account balances negative
• 'settxfee' added, to manually set TX fee

Recommendations:  If you have trouble connecting to the network, try one or more of these techniques:

• -dnsseed
• -upnp, or forward port 8333 on your router

Full git shortlog for this release, showing all changes and their authors, is here: http://pastebin.com/CQYnGsau

19a53c245f2a96de4f12264b8c2980adf85a814e  bitcoin-0.3.22-linux.tar.gz
874f74858cbee9710cd0c2d2fc753e550dc31d31  bitcoin-0.3.22-src.tar.gz
67f66a403f176b70e92314c9e0b4108dc6758eb9  bitcoin-0.3.22-win32-setup.exe
c2eb20ca19bc14ef8677f9dacac6cea2c84c2668  bitcoin-0.3.22-win32.zip

SHA1 sums, pgp-signed: http://paste.pocoo.org/show/401127/

Are there any plans to release a leaner bitcoind (console-only application)? This may encourage other GUI front-ends.

Requesting "Eligius" and "0-fee" patched builds for Windows...! :P

requesting BitTorrent link to official dists above too (so as not to overload sourceforge)

thanks

SourceForge has plenty of mirrors.  You're not going to overload it.  :)

I'm a little out of the loop with the development, but just downloaded the client and noticed that it still has only .00 instead of .000. I was under the impression that we were gonna add the third zero in this version

how come the message isn't pgp signed? for the last release, it was signed by gavin.
https://forum.bitcoin.org/index.php?topic=6642.0

Thank you! With this rapid rise in BTC value the 0.01 per kb fees are getting expensive!

It handles smaller values just fine, just type 1.001 in the send dialog, and your balance will change appropriately.  No change was made to the default number of decimal places.

There ya go:

SHA1 sums, pgp-signed: http://paste.pocoo.org/show/401127/

ok, thanks. just being a little paranoid. :P

I am ready to wait. Whether it is possible to pay in the version 0.3.22 the commission absolutely? Or it is necessary to use 0.3.20.2?

Well, that version solved a lot of problems with GUI issues  ("cut" windows, error messages).
But it still did not allow to use 0.0005 fee.  (OP mentioned it). So i am still stick to 0.3.20.

Can you be more specific?  -paytxfee=0.0005 should work.

xf2_org,
-paytxfee=0.0000
Will work?

Yes, that works.  That should reset your client back to default behavior: free transactions, unless it's clearly not possible for your transaction to fit into the free area of a block.

Thanks, now I will try :)

And after you tried it once - try again. And post the results. My 0.3.22 refuse to do it, after one free (or 0.0005 btc) tx, again. I am trying this for some number of blocks (14) and that did not happend.

txid?

The limit of 0.01 BTC on small value transactions still exists.  That has not changed.

If you are sending values smaller than 0.01 BTC, a fee is required.

Transaction is over 0.70 btc.

   Let me describe the whole story. Some services (like http://bitcoin-contact.org/) require btc address validation.
To do that you need send some specific amound of BTC from own address to the same address - twice (second time, after at least one confirmation of first tx).  So, that can be case of spam transactions defend. But i am  applied fee 0.0005 in both cases (first gone without troubles and now has 20 confirmations), so it should not be.
   Also, i  am using addnode with ip`s that  receive free or very small fees. Last BTC i am have received to my wallet, have at least 2000 confirmations.

First transaction:
http://blockexplorer.com/tx/8bf1483fa075a0a64593d2b332acaeee3af15d83e13c749dbdd1298e28d5aeca

0.01 BTC - demands the commission 0.01 BTC :(
0.10 BTC - hasn't proved to be true yet

Anyway I come back on 0.3.20.2.
At me with it problems aren't present.
Simply it would be desirable "the new" version :(

It would be nice if an admin would update this:
News: Version 0.3.21 is now available.

Thanks!

What about a MacOS version?

This.

bitcoin.org and weusecoins.com are still linking to the old version. As a result, in the just last few hours, we've gained ~100 0.3.21 users, and just a handful of 0.3.22 users. We still only have just 189 0.3.22 nodes online - barely more than at the end of RC testing. We need to do a better job of getting the word out.

Forgot "-Preliminary development of double-secret CIA backdoor and un-anonymizing framework" in the notes.

Windows 7 Pro x64, RPC command "getwork" causes the rpc server to lock up, thread uses full CPU usage (25% on Q6600.)
Application has to be terminated via task manager.

No issue in 0.3.21, no other rpc commands seem to cause any problems, just "getwork"
First discovered problem by launching a local GPU miner (Phoenix), then verified it was the getwork command by testing with PHP client and just using the bitcoin command line.

Tested in a XP VM, same result.

Here you are: a 0-fee sir http://ifile.it/jyzwhpi . I'll talk to luke about the eligius version and make a binary soon.

Just out of curiosity, I tested your binary. My 'getwork' issue is resolved with it. Could you please send the source used to compile it? I'd like to do a diff on it and the official release :-/

Got errors on my ubuntu:

/home/bitcoin/bin/bitcoind: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /home/bitcoin/bin/bitcoind)
/home/bitcoin/bin/bitcoind: /lib/libc.so.6: version `GLIBC_2.11' not found (required by /home/bitcoin/bin/bitcoind)


$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 9.04
Release:        9.04
Codename:       jaunty

As far as I know Ubuntu builds work only on newer Ubuntu releases, you have too old one.

Just updated my client on OpenSUSE 11.4.  Was running 0.3.21 fine but this one doesn't seem to be doing anything...

It's been running for about 20 mins.  Output of getinfo:

 # ./bitcoind getinfo
{
    "version" : 32200,
    "balance" : 0.00000000,
    "blocks" : 0,
    "connections" : 0,
    "proxy" : "",
    "generate" : false,
    "genproclimit" : -1,
    "difficulty" : 1.00000000,
    "hashespersec" : 0,
    "testnet" : false,
    "keypoololdest" : 1307348470,
    "paytxfee" : 0.00000000,
    "errors" : ""
}


I've forwarded 8333 to it to see if that helps but no.  It has a connection to irc.lfnet.org but nothing on port 8333.  I've checked my firewall logs too and nothing so far!

Any ideas?

EDIT: Seems to be working now, just took a lot longer than expected!

Was that supposed to be a link? I'm also looking for a Mac version ... and btw, on bitcoins.org, it still says 0.3.21.

Yeah, thought so. :(
Too bad i cannot upgrade this box. Back to the old version it seems...

Sure, no need to upload the whole source, i just downloaded the zip file from the first post and in main.h changed the line that read  return dPriority > COIN * 144 / 250; into : return true;

This patch was proposed by the user Raulo here, and is not mine.

When I upgrade to this new version, will my original Bitcoin address be saved?

Thanks  :)

Please dont do that, that changes several other unrelated things that shouldn't be.  If you really want the option to more granularly control the fee, please build my better fee ui branch instead. Works much better and doesnt have adverse side effects on other uses of transaction acceptance.
Also, that wont change build results, can you give more information on your build environment?

Beware that this version still seems to have the bug where initial wallet.dat creation does not fill the keypool with 100 pregenerated keypairs. Someone just lost a lot of BTC because of that (see http://forum.bitcoin.org/index.php?topic=11104.0 (http://forum.bitcoin.org/index.php?topic=11104.0)).

Actually that guy lost his coins before keypool was created, in fact, keypool was created as a response to that person's post.
That said, yes you are right, before you backup the first time, make sure you get some coins and/or send some.

It's taken this new install 4 hours so far to rescan the block count.  It's up to 121625 and still probably has 30 mins or so to go....very annoying!

No, the keypool feature was created as a response of someone else (see http://forum.bitcoin.org/index.php?topic=782.msg8620 (http://forum.bitcoin.org/index.php?topic=782.msg8620)). The creation of at least one new address must be triggered in order for the keypool to be filled, and that is still the case for version 0.3.22. So is there a reason why a new wallet.dat contains only 1 keypair until you create a new address? Seems like a bug to me...

I also am sticking to the old client.  The new client makes connections very slowly and I had a very small amount sent to me that never appeared.  Went back to the previous client and will wait it out until my small transaction appears.

I don't know why the P2P bit of the code seems so slow to connect and does not connect to many peers at all, but I don't like it.

Oh sorry, anyway close enough.  But yes, its a bug and there is a pull to fix it, probably to be pulled very soon or fixed in some form or another.

Is it working on Ubuntu 11.04 with compiz now?

Yes.

The P2P code did not change at all.  This is the behavior of the network, not the new version, because so many new users joined without forwarding their port 8333.

No, I am afraid it is not.  I use uPnP in any event.  I restarted the new version and it very very slowly found the first connection and over the next 10 or more minutes got as high as 9 peers.  I closed it, uninstalled and went back to the previous version.  Started.  A few seconds after it started one then two connections and then they flooded in well above 115 connections [I often have more than 150 connections].  After a time, the client usually drops to 45-60 peers typically.  There is DEFINITELY a difference with the way the new client is working as far as P2P goes.  Maybe uPnP was broken?

Same behavious here, except I don't use UPnP (and I'm not behind NAT).

Cheers,

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.

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.

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

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

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.  :(

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 :)

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

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.

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.

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.

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 get the dreaded 'problems communicating with rpc server' with this version and it never connects. Old version works fine.

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.

No.  This only impacts miners on Windows.

No wallet encryption???

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.

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

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.

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

0.3.23 will lower the fee.

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