Bitcoin Forum

Bitcoin v0.3.24 is now available for download at
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/

This is another bug fix release.  We had hoped to have wallet encryption ready for release, but more urgent fixes for existing clients were needed -- most notably block download problems were getting severe.  Wallet encryption is ready for testing at https://github.com/bitcoin/bitcoin/pull/352 for the git-savvy, and hopefully will follow shortly in the next release, v0.4.

Notable fixes in v0.3.24, and the main reasons for this release:

F1) Block downloads were failing or taking unreasonable amounts of time to complete, because the increased size of the block chain was bumping up against some earlier buffer-size DoS limits.
F2) Fix crash caused by loss/lack of network connection.

Notable changes in v0.3.24:

C1) DNS seeding enabled by default.
C2) UPNP enabled by default in the GUI client.  The percentage of bitcoin clients that accept incoming connections is quite small, and that is a problem.  This should help.  bitcoind, and unofficial builds, are unchanged (though we encourage use of "-upnp" to help the network!)
C3) Initial unit testing framework.  Bitcoin sorely needs automated tests, and this is a beginning.  Contributions welcome.
C4) Internal wallet code cleanup.  While invisible to an end user, this change provides the basis for v0.4's wallet encryption.

Full changelog ("git shortlog v0.3.23.."):

Dawid Spiechowicz (1):
      added polish translation

Doug Huff (1):
      Add OSX App bundle and correct build instructions to reflect reality.

Eric Hosmer (3):
      Updated Visual C++ makefile.
      Further updated Visual C++ makefile.
      Add keystore.h to makefile.vs's header list.

Gavin Andresen (3):
      Boost unit-testing framework.
      Block-chain lock-in at 134444
      Do not use comma as thousands separator

Giel van Schijndel (2):
      rpc server: send '403 Forbidden' to rejected clients
      rpc: don't send 403 when using SSL to prevent DoS

Han Lin Yap (3):
      Double check translation and improved a translation string
      Update swedish translation
      Consistent Bitcoin example address

James Burkle (1):
      Edited init.cpp to include a check that -datadir exists

Jeff Garzik (6):
      FormatFullVersion: build fix related to recent translation improvement
      doc/release-process.txt: minor updates
      CWalletTx::GetAmounts(): pass NULL for CKeyStore*, rather than false     t
      Enable DNS seeding by default.
      Bump version to 0.3.24.
      Bump OSX version to 0.3.24 (missed in previous commit)

Joerie de Gram (1):
      Fix connection failure debug output

Jordan Lewis (8):
      Only include irc.h when needed
      Only include db.h when we have to.
      Only included rpc.h when necessary
      Only include net.h when we have to
      Only include init.h when we have to
      Only include strlcpy.h when we have to
      Remove some globally unused headers from headers.h
      Only include certain boost headers if necessary.

Matt Corallo (8):
      Update translations and remove obsolete translations.
      Add new DNSSeed dnsseed.bluematt.me.
      Only use dnsseeds and static seeds when not on testnet.
      Make UPnP default on Bitcoin but not on Bitcoind.
      Give more detailed error messages for connection failure.
      Added a couple minor things to match newer build process.
      Revert "Make UPnP default on Bitcoin but not on Bitcoind."
      Enable UPnP by default on bitcoin, but not on bitcoind (on gitian)

Pieter Wuille (6):
      move wallet code to separate file
      CWallet class
      Bugfixes walletclass
      Fix segfault when creating new wallet
      Limit response to getblocks to half of output buffer size
      Fix synchronization of default key

Shane Wegner (1):
      Fix missing includes needed for Boost 1.46.

Stéphane Gimenez (1):
      Fix AddressBook syncrhonization between a CWallet and CWalletDB

Wladimir J. van der Laan (1):
      add GetTotalBlocksEstimate() function, move magic number to constant

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

4909c17a1cc025c6f6c88d036f0b487c51c510f6  bitcoin-0.3.24-linux.tar.gz
58531249230f769fdc755822b41e0f18ba59512c  bitcoin-0.3.24-src.tar.gz
d4b5425eff673551a326d5326b92a06359dc1a3d  bitcoin-0.3.24-win32-setup.exe
520aed70ee28a0a91ed49dd983639cb1fab2a93c  bitcoin-0.3.24-win32.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIVAwUBThd13todwg8tvwyoAQKnVhAAnQzWKk5HrY5eMIprWwtsFZL0VOxAV2nV
Kn8NISmYk7PtfhzRm2sf0YYr369e7NtKAzdVNTRl+9m4RwQ6HhvzrChWG3OXxueA
AYg2JkS3oXbU2p4zOQT0/0ILp7iiHGhXCrEyd3bU5KkWOJhUnV0lS3ZzsELf8sab
I5MYQsrpZ9HZUI13e1ak/E0cub2gvxl+4D5Eg7EkNP71APR1MXGGzcfF7vlDYf4/
j1JTtkrBVZU6yFi8fNUxMQ/8G/0vyWLOOoCxaSvl5u5kssbI4rklhTA+BaqE1apx
xZN9Re0KjQ8cZiLQnVG9RhJsPhWe5tJRGqnKmaKF0gDELihFw9JLBDQkeSlhkhGx
wYtOfMClTDbd2qj5+dmvIrJPmDYHpGvmEO6xPsiv0qaNMZ1X/yMd9pp7nyCYosWB
u/vcPF0i4I27SDgRZ1TCPSgJgDQ4gEwKgzO69HywJw4KSkJq5MdecJDGRqTaYaf2
QI757pBXzFF3qORECSt5QIOjV1+bUc+1pB6450OfrZ+fTMMyWGF8t9t+TMAOwqoR
E0AMx2V+g+w6AXtpar4vsh0erexissREf6g1tW5ogy21Cv91MbIGZA9lUKNeU0Np
OgYSTNd5DvlbF7VpRZemSIz9gGWayqEi0G1oBQDo6DFcjeCS0okrIWPep4o1uoYz
xhxoauT2XEM=
=hgmn
-----END PGP SIGNATURE-----

Is there a certain procedure for updating a wallet without loosing the BTC in it?

yay

Make a backup before installing a new version just in case it doesn't work.

These installs seem to be getting more complex.  I'll stick with 0.3.21.  :(

To what does this refer?

The installation procedure is unchanged since 0.3.21 (or before).

Thanks for this Jeff.

Nice, guess I'll be upgrading my 0.3.21 sometime soon

Can we get an official Mac OS X binary up on the sourceforge and Bitcoin.org?

thanks for the great work.

Very nice!

It is coming soon.  OSX builds are always delayed a day or so, because they are not integrated into our gitian build process like linux/windows.

They are not any more complex than before, what do you think has made it "more complex"?  Just install and be done with it.  If worried about your wallet [which you should be], copy it aside, or in my case, I just take it as a good time to encrypt and back it up.  I can always recover it and it is a process I do anyway.

Thanks Jeff!

I like to keep up with the most recent version, but I'm unfortunately not sophisticated enough to build from source on OS X. I tried, but I failed miserably.

should not that be pushed to the natty repos. (Ubuntu in general) to update automatically with the update manager ?

So, what's the plan with this new version? send btc from old wallet into the new one? Convert the wallet.dat file?

What's the new file that we have to back up and encrypt to keep safe/secure?

Why would you have to do anything different?

Can someone complete the following line? I don't get it.

mine was fine, wallet survived install

That is referring to this git commit (https://github.com/bitcoin/bitcoin/commit/59f9c8e8c9a1baf181789053fa4ca254f83416b0):

Just to be clear...

The upgrade / wallet update procedures are the same as with the last several bitcoin versions.  There is nothing special about updating to this release, versus past releases.

The advice posted in this thread is standard, general advice that you should always follow when updating:  back up your wallet (you are doing this anyway, right?)

Same.

Win 7 32bit - On startup, UI loaded then locked up ("Not Responding") for a few seconds before the first connection was established.

It looks like someone forgot to apply a bugfix present in 0.3.24-RC1 in RC3 and the final release.

See here:
http://forum.bitcoin.org/index.php?topic=24841.msg323892#msg323892
http://forum.bitcoin.org/index.php?topic=25515.msg324019#msg324019

I assume it wasn't checked into the main source tree.

Waiting for 0.3.24.1 now :)

WTF? Does it still ask you for ridiculous fees?

When I got into bitcoin, a major selling point was "no fees".  I guess the greed got to them.

The upgrade went fine :) both on win vista 32bits and win7 64bits.

just tested it .. much better and responsive. The more important .. did not took 4 days to complete the chain.  :-*

Wait, it worked in RC1 but not RC3? RC1 did not have the fix applied.  RC3 (which is the same build as final, aside from some translations) did.

There never was the need to pay fees for bitcoin transactions. It was only that this specific client did not accept weird transactions from peers without fees to prevent spam. With Bitcoin you are free to use whatever client you want - and changed as you like.

Smooth install, noticeable improvements. Great work! :)

Patiently anticipating the wallet encryption patch, if its implemented right it will be a excellent addition.

Well, I tested RC1 and it started without any problems.
Now I tried the final and I got the error message.
Out of curiosity, I also tried RC3 which failed too.

What kind of error message?

Very, very odd.  I guess I'll stop including that file and see if 0.4 works.  I really don't get why including that file does not work, but not including it does, but only on RC1 and I really dont feel like digging through MinGW headers to find out.  I don't think its nearly worth a 0.3.24.1 just to support Windows 2000, as you shouldn't be using a EOL OS ever (if you even remotely care about security).

The one here: http://forum.bitcoin.org/index.php?topic=24841.msg323892#msg323892

I won't demand a release just for that :) I'm well aware that it's EOL, but well, it's running on that one machine just fine. It's just on to run a bunch of services 24/7; nobody really uses it for browsing. It looked like a pretty simple fix, that's why I suggested adding it.

Well, I tried, Ill try again with 0.4, if you are willing, PM me and Ill churn out a couple more builds for you to test so that its for sure fixed in 0.4.

For those of you who (1) can't wait for a Mac build, (2) trust a random stranger on the Internet to provide you with their copy of Bitcoin, (3) want the changes I've made to Bitcoin (Which I hope is setting required transaction fee to 0 for creating transactions and relaying), and (4) use a 64-bit Snow Leopard system, I've posted my build up at http://dl.dropbox.com/u/16187822/Bitcoin-0.3.24-pc.dmg (http://dl.dropbox.com/u/16187822/Bitcoin-0.3.24-pc.dmg). I highly suspect that I'm the only person who wants this, but who knows?

MD5(Bitcoin-0.3.24-pc.dmg)= 6a55039636266301b445638c55fcacb3
SHA1(Bitcoin-0.3.24-pc.dmg)= 288493d1986f50cd0be7b0bbb1377dc103a8ca18
SHA256(Bitcoin-0.3.24-pc.dmg)= 89462c2889b76627e143caa974d13bffaf5c8bb59995d700538852ed430548cd

While I appreciate the effort... I'm afraid I don't qualify for #1 or #2.

Thanks for posting it for others though :)

LOL, I know it shouldn't be necessary to understand all the inner workings of the Bitcoin concept in order to use it, but this statement is pretty hilarious in light of the facts.  There's nobody to whom "the greed" could "get".  The fees are an optional feature (i.e. you can still send transactions without them) with three related functions:
- DoS prevention
- incentivizing mining
- transaction priority management

The fees get paid to the miners who process your transaction, not "the man".

I dont know where bugreports is collected, so i post it here

http://img534.imageshack.us/img534/7549/btcerrtrans.png (http://img534.imageshack.us/i/btcerrtrans.png/)

#: ../../../src/ui.cpp:2681
msgid "&Open Bitcoin"
msgstr "&Oткpыть Bitcoin"

#: ../../../src/ui.cpp:2682
msgid "&Send Bitcoins"
msgstr "&Oткpыть Bitcoin"            <-- error

Basically this screen shows "Open Bitcoin" two times where it should be Open Bitcoin and Send Bitcoins in RU

Please make this thread sticky until the next version and keep repeating that :)
There is so much traffic now many people might not see this thread.

Is there some gpg signature to verify the integrity of the files?

Yes.  See the original post in this thread.

We use github, put in a bug at https://github.com/bitcoin/bitcoin/issues/395 (https://github.com/bitcoin/bitcoin/issues/395).  If someone can translate to russian, that is what would be needed here.

I'm not on github so will post translation here

Open Bitcoin - Oткpыть Bitcoin (Биткoин), this one is right
Send Bitcoins - Oтпpaвить Bitcoins (Биткoины)

In parenthesis singular and plural word Bitcoin in case it's needed

Certainly there is. Mining pools currently get 50 BTC for every block plus total transaction fees for that same block. For many of them transaction fees are the only revenue source. The minimum transaction fee effectively is a mining pool 'tax' for all network users. I understand the need to protect against DoS attacks. However, what is the point of protecting against an attack if there is no attack? If you're not flexible, always keeping your shield charged to the maximum, it is just a waste of resources!

The minimum transaction fee should be a dynamically defined variable by the system. Its value must depend on <some data related to things happening on the Bitcoin network> including DoS attacks (or other attacks) already commenced and in progress.

Can we have an option to change the language on the fly please? I am on a Chinese language windows7 system, so all my Chinese software would work flawlessly, but I prefer my English software to be actually in English, because the translation is often horrid(and the Chinese translation for bitcoin client is really confusing). Right now, I delete the zh_cn folder, each time the program updates, and it's a chore.

Have you considered submitting better translations? :)

Hi,
just checked out the link on sourceforge but the mac version seems to be still 0.3.23 , right?
Or is just the file named wrongly?

Thanks!

When I need to do so (for example read a manpage in English instead of my locale), I use environment variables. If you're using an Unix-like system, you can run bitcoin with the following command on the shell prompt: LANG=en_US bitcoin

Slightly better is to use LC_ALL, lest some things be displayed strangely.

Bump.  All users are encouraged to upgrade to 0.3.24, to avoid block chain download issues currently seen in the field.

I'd be happy to if there was a Mac version.  ;D

Why not sticky release threads until the next release?

just to be clear, if i don't have issues myself, do i help others by upgrading?

also, +1 on sticky

Edit: just upgraded, working smoothly.
block download started instantly, got >25 connections within a minute and upnp didn't kill my already forwarded port :)

only thing is the tests won't run, am i doing something wrong?

Yes, most definitely.

Nodes requesting block chain downloads can have their downloads cut off abruptly, on older versions of bitcoin.

The more people running 0.3.24, the less this awful behavior will be seen.

Repeat after me: There is no minimum transaction fee.

and then:

Repeat:  The overwhelming majority of transactions are zero fee.

The software requires a for relay for transactions which the adaptive technical detection for DOS-attack-like transactions can't distinguish from an attack, and for transactions which are unusually burdensome (many kbytes of data).   The adaptive detection doesn't depend on the instantaneous network status:  Its can't easily because in a decentralized system there is no singular status, and if nodes disagree about the status the protection isn't effective (if its fail open) or it makes txn get stuck in unspendable limbo at random (if its fail closed).

Instead the adaptivity depends on the character of the transaction itself— it's value, the time since its inputs were last spent, the size of the outputs, and the amount of data used to represent it.   These are all factors which are directly relevant to a DOS attack because they objectively measure the effort it takes to perform the attack and the impact on the whole network of performing the attack.  This is a usable criteria because it's objective and can be acted on uniformly by independent nodes.

Above the cutoff priority txns are handled in a priority oriented manner which gives the soft "only messes things up if there is an attack" behavior that you seem to think we lack.   .... You only think we lack it because it actually works.   Unfortunately, the soft behavior can only work to a limited extent because in order to handle things in a priority order nodes must have first undertaken the non-trivial costs of storing and forwarding the transaction— so at some point the system has to simply say "No, I refuse to use memory for this, I refuse to use bandwidth for this". Otherwise the attacker can exhaust these resources even if non-spammish transactions always beat them into the blocks.  If the threshold at which transactions aren't remembered (which makes them _very unlikely_ to go through) is too dynamic then you'll continually end up with transactions which are stuck in limbo polluting your wallet, and potentially polluting the wallet of the receiver if they happened to hear the txn.  

These zombie unconfirmed transactions can end up like a spreading cancer, since their (or their change) will eventually get used as inputs as a last resort thus spreading the confirmation delays to additional transactions which would otherwise confirm quickly.

At yes, the setup is far from perfect— for example because, unfortunately, a lot of new users make transactions which are technically indistinguishable from a DOS attack... and because the proper fee for DOS-like-txn depends on the current "value" of bitcoin, which changes in unpredictable ways.

On the flip side, the worst case for these newbie transactions is that it causes some users to have to pay a 0.0005 BTC fee per transaction sometimes.  This is less than a penny. The gross burden on the disk space of full nodes to store the transaction (around 10 megabytes for a normal sized transaction, assuming 40k full nodes) is currently a similar cost.  The fee structure also creates a nice opportunity to educate people about more pro-social usage of bitcoin (e.g. making all payments with zillions of 0.01 txn is unnecessarily burdensome on the network).

Certainly there is a lot of room for improvement, but whining— especially whining which exaggerates and misrepresents the situation is not helpful.

Sure looks like a minimum transaction fee to me.

Did you bother to read the post, or did you just Cntrl-F for 0.0005?

The average user doesn't care about all the technical details in that post.  They care that people keep saying there's no minimum fee, when there is. 

I don't care that there's a fee.  I have mine set to 0.01 for all transactions, anyway.  just STOP SAYING there is no minimum fee when clearly there is.  It's confusing.

[edited for typo]

Its also confusing when people say there is a minimum fee.  The satoshi client forces you to apply a fee on transactions only in very rare cases when your transaction looks like spam.

Same here, there's some '#define BOOST_TEST_DYN_LINK' missing.
But, anyway, there are just two boring tests available for now.
So, be patient :)

Really?  I've been using 0.3.23 for a while and I've had to pay the transaction fee on every single transaction except for about 5/100.  For me, the *rare cases* are when it doesn't make me pay a fee.  Did something change in 0.3.24?

Right. This is my point.  There is no minimum fee:  I, and a great many other people using unmodified .24, send zero fee transactions all the time.  Thus: The minimum fee is zero.

If you went to a car lot shopping for used cars, would you say that there is a minimum fee of $90,000 because thats the price on some of the cars?  No.

It doesn't help that we've used some fairly confusing terminology in the software, we should be more careful about that in the future. But it still doesn't excuse people claiming that there is a minimum fee. :-/

If you don't want technical details — thats fine.   "There is a particular fee required for transactions that look too much like a DOS attack to the system" is an accurate statement.  "There is a minimum fee" is misleading and contributing to poor health of the bitcoin network by causing people to stay on older versions.

Care to share an example transaction so we can see why?

I can only guess you're making payments with outputs smaller than 0.01 BTC?

Went to grab some example payments and I noticed a pattern ;)

It seems that in any batch of payments, the first payment I send is free, and any subsequent payments charge the transaction fee.

I guess sending more than one transaction within a short time period requires the fee.

I normally send a few payments at once, as I'm paying out a bunch of members from our site :)

You should really look into using sendmany, then.

This is what sendmany is for. I highly recommend you use it: You can pay many people with a single transaction, and a single fee (if required).

What is sounds like is happening in your case is that the change from the first transaction is being respent right away, and respending right away is a DOS-attack-like behavior (e.g. an attacker would ping pong coin rapidly to generate traffic). Bitcoin should normally avoid doing this— preferring to use older inputs, but if there aren't enough other inputs in the wallet to satisfy the payments without using the fresh change then it will use it.

If e.g. you have a single 50 BTC input in your wallet and you've been sending out 1 BTC payments you end up with transactions like  50->{1,49} ; 49->{1,48} ; etc.    So if you simply do a send of 50 to yourself: {10a,10b,10c,10d} to break the input up, then the software should instead prefer to spend 10a->{1, 9}; 10b->{1, 9} rather than reusing the change right away and probably avoid the fees.

Either of these cases should be sufficient to avoid the fees in your case, and the sendmany puts less load on the blockchain as well.

Thanks for all of the info!

Sendmany looks like it could really save me some time :)

I'll take a look at sendmany...and in the meantime, I'll try the input trick.  I've definitely been spending from one or two inputs, so that is very likely the culprit.

Again, thanks! Much appreciated!

I just have to say thanks very much to all devs, for putting in all the time and energy!

Just went on a little tipping spree; wish I could do more...

I don't understand where the wallet.dat file is. All I see is a wallet.cpp and wallet.h. How can I copy/encrypt/delete wallet.dat?

See https://en.bitcoin.it/wiki/Data_directory

Wallet.dat contains your personal keys and transactions - it is created and maintained by the program, not packaged with it.

wallet.cpp and wallet.h are source files for the program that manage the wallet.

Yes but when you install bitcoin on a fresh computer, shouldn't it create a new wallet.dat file?

No, only when you have run the program.

Ok, so when bitcoin is running, shouldn't wallet.dat be in the same directory as wallet.h and wallet.cpp?

No, wallet.* are source code for the program, they don't belong with the wallet largely because the entire source directory is not needed to run the program.

Ok, here's what I'm trying to figure out. With prior versions, there was a wallet.dat file which I encrypted. Then I quit bitcoin, opened it up again and a new wallet.dat was made. I made the encrypted wallet my savings wallet and the new one my temporary. I could then swap one out for the other depending on what I needed to do.

I've got both wallets right now and I'm not sure how to import either the temp one or the savings one into bitcoin. I really don't want to proceed further because I don't want to harm my savings wallet.

The exact same way you always did.  Nothing in terms of wallet handling has changed.

Weird. Before, when I encrypted and moved the savings wallet.dat, for example, I'd reopen bitcoin and a new wallet.dat would be created. I'm either not remembering where bitcoin keeps wallet.dat or something's different. Or I'm an idiot and forgot wtf is going on.

How do you protect your wallet?

This was already answered above: https://en.bitcoin.it/wiki/Data_directory


http://en.bitcoin.it/wiki/Securing_your_wallet

So the answer is b). I'm an idiot.

Thanks, I see it now. I've no idea why the huge brain fart.

Not enough BitBrew this morning? :)

Guys,

 I have two Bitcoin clients running on two different computers:

 Computer A: Bitcoin 0.3.23
 Computer B: fresh installed Bitcoin 0.3.24

 But the new Bitcoin 0.3.24 does not behave the way it did before... I mean, I sent B$0.01 (two times, second time I've sent through MyBitcoin automatic forwarding) from Computer A (0.3.23) to Computer B (0.3.24) but, at the Bitcoin 0.3.24, NO NEW ADDRESS automatically appeared at "my receiving address" in the AddressBook (I can see the new address at the main interface screen, but no anywhere else)! But it happens in Bitcoin 0.3.23... Why this have changed?!

 Where can I manage my automatically generated new Bitcoin Addresses?

 Take a look:



 NOTE: I open a post on tech support forum, "Bitcoin 0.3.24 different behavior in "address"":
 http://forum.bitcoin.org/index.php?topic=28343.0 (http://forum.bitcoin.org/index.php?topic=28343.0)

Thanks!
Thiago

I believe this is intended behavior... I was reading a post about how the self-generated random addresses were confusing to new users so they eliminated them. Once I locate the post I'll put it here:

(gotta run, did some searches but never found it... I will check back later... I think it was in the Dev and Tech board)

I appreciate it! Thank you BTW!

But the auto generation of new addresses is still running on background!

We need to have two kind of interfaces, "advanced" and "normal", showing and not showing the auto-generated address. If the address exists in background, I need to see it in somewhere at the software, so, where is it?!

At the "normal" user interface, instead of hiding the auto generated address, the Bitcoin should distinc between the "user created address" and the "auto generated address"... From the point of view of Bitcoin, it is just "address", I know, but, from the user perspective, will be some kind of distinction between them.

Sorry but, if I'm not able to manage my own addresses, automatic generated by the software or manually by me, this is a bad thing...  :(

I just want to see and manage all my address...   :-\

This kind of change cannot happen without public consultancy... Where the development beta tests ocurr? I want to participate.

If very rare means 100% of all sending transactions I have ever done, then yes.  It is extremely rare.

I made a ~6 BTC deposit and was prompted a 'minimum' fee of .03 ...

This has never been a feature.  We've had the generation of a 100 key keypool for a long time (to prevent loss of coins due to coins being sent after latest backup), and the autogeneration of change keys since Bitcoin was released.  There is almost no additional value to being able to control the change keys aside from the "I want to mange all my keys to feel cool".
The specific problem you see here is probably a coding oversight and needs more investigation.

#bitcoin-dev on freenode, the Bitcon-development mailing list, and the release candidates are posted on the forum before reaching stable.

Then your transaction clearly looked like spam to the client.  This most likely means your transaction's inputs were quite large in number, ie Bitcoin was pulling from a *ton* of very small inputs.  The fee stuff only ever shows up for people dealing with very small amounts, sending transactions very quickly after receiving the coins which will be used as txins, or sending large transactions, either many txins or many txouts.  You fall in the last case, that doesn't mean that transactions often see the minimum fee, in fact a minimum fee of 0.03 means your transaction was *massive*.

I know this behavior confuses at beginning, I got confused too but, my point is, new users should have the easiest interface and better user experience, no doubt, but, what about the others?

People who already are using the version 0.3.23 extensively and liked the software behavior... These peoples needs a option to access more advanced features of the software...

Or the Bitcoin auto-generated addresses that come and go are completely disposable? Not working after one transaction and it just disappear?

It sounds like 'the joint' is not running 0.3.24 either, and so, is using an older fee schedule with much higher fees.

No, they continue to exist in the same way as in 0.3.23, it just looks like it was a bug in 0.3.24, this change was not on purpose.

I can't find the original post! I guess I could have dreamed it? or perhaps the other dev's didn't agree with the move by one dev and he has altered the original post? Or I am crazy?

Maybe all of the above?

It was never the intended behavior, it was an oversight during the very large code cleanup.  Will be fixed in 0.4 (already fixed on github)

I guess Mac users don't get the new shiny.  ???

No idea where Laszlo has been, haven't seen him...(he does the Mac builds).

Yea... I is wanting the Mac version as well.

Sad face :(

I'm pretty sure I'm constantly getting issues downloading the block chain. I don't start my client very often (pretty much only when I send out coins) and it always takes FOREVER to even start the download.

Maybe I should take up a collection for OSX server edition

(only half kidding)

Still not legal to VM it on non-apple hardware, meaning you still have to do all the standard OSx86 hacks.

This is a result of not enough people on the network in general upgrading, not you not upgrading.  This is why people are pushing so hard to get people to upgrade to .24, it helps the network considerably and people no longer get problems downloading the chain. 
We really need a Mac build...

Mac build notion seconded!

Thirded! ;D

I want mac build too.   :'(

Is the Mac build problem a case of trust (we only want one person handling it) or a lack of Mac users with the knowledge to compile it?

(Yes, "me too").

Its a "the regular builder of Bitcoin-Mac is no longer an active community member and somehow missed the email that notified him 0.3.24 was out" problem.  The builds are on their way now.

Mac OSX version of bitcoin client finally posted at
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/

Updated sums (stored as SHA1SUMS.asc on SF):
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

4909c17a1cc025c6f6c88d036f0b487c51c510f6  bitcoin-0.3.24-linux.tar.gz
fed0afebe0b0c0f77a637600ac4abecbe5d098ed  bitcoin-0.3.24-macosx.zip
58531249230f769fdc755822b41e0f18ba59512c  bitcoin-0.3.24-src.tar.gz
d4b5425eff673551a326d5326b92a06359dc1a3d  bitcoin-0.3.24-win32-setup.exe
520aed70ee28a0a91ed49dd983639cb1fab2a93c  bitcoin-0.3.24-win32.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIVAwUBTiTMHNodwg8tvwyoAQL8CRAAgraSWP12lbwrhpiElvB7LIWoPbiE1dUx
i2ZO4MVJYKMbyuHu55j1Uq7a4ZqpNhXqq7U6efnoDTCl9sdpyhKxiql0SpsYBLs1
IehX4UEVGVMUE5uepmOs+cYnYuAhNzvxNqKFPv3D7uEOXPmSxlUa4s0GEnTgVR1l
0GFYf2T615MoGAak3+afahp4WB4XlHshttHT2P3o2/7N4Oh7iwFFtkmOj/Sb3Prc
C8skW83kUZ4i8W1HlZTmtr4YlQbKnx6bF6mbkTY1aQa1AV/8htenALkmR2+eCgsd
EY9WM8qruxnVLt/ao+VYw5jYLSYVKHt31ZD4rJM+5lKcTtU1NmNsGloen+hdLwC+
hggqnUQmvBzM7SKqvg4zI9SbgGR5fS3poTrFX7yDKZyLSPcjBND/lWi8evRiSEP0
yftCKL7zotdRy6QTG7tI1Fye1fyYuQdTB1nimE+7VJ8Q2O4DwE0iZKMuXm3GfaOr
T20Znvns9caMKED9T1gg42QgYM6EMMbeukBUkIXPt2tloDnn2tMzvvrKzgGBS1Lc
qv2ndhBCunBxNCQCHly4T2Rz8TJnm2XglS0d/VygcMuMSL0San5DwXYNnN4P0xD/
MXOdqrxcusIzKBbSHWPqInRmYUTymDtcqXWK3Cz6kRUXjBkRoSvDs8PBAvnaC236
1xol6uyMqZo=
=aMy0
-----END PGP SIGNATURE-----

Thanks for the mac build.  It's even generating connections without that weird terminal connection trick I had to do before.  Go dev team!!!   :D

The MD5 of the bitcoin-0.3.24-win32-setup.exe download from the bitcoin.org front page doesn't match your MD5 sig

The MD5 of my download is b9a71a0a25ac090a3c0e370e01366ae8

All officially posted and signed build checksums are SHA1 (note the length difference from MD5).

Hi,

Anyone have the version 0.3.24 in .exe ?

I found it on this russian site, but it is safe ?

https://bits.media/files/

Thank you for your help.