Bitcoin Forum

Win32, Linux, MacOSX and source releases for bitcoin v0.3.23 have been uploaded to
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/

This is another quick bugfix release, trying to deal with the influx of new bitcoin users.

Priority for next version:  wallet encryption (https://github.com/bitcoin/bitcoin/pull/232)

Main items of note:

• P2P connect-to-node logic changed to reduce timeout a bit.  The network saw a huge influx of new users, who do not permit incoming connections.  This change is a short-term hack, to more quickly hunt for useful P2P connections.  Better "leaf node" logic is in the works, but this should let us limp along until then.  One may use -upnp to properly forward ports, and help the network.
• Transaction fee reduced to 0.0005 for new transactions (see note below)
• Client will relay transactions with fees as low as 0.0001 BTC (see note below)

NOTE:  There has been some fee confusion recently.  Free transactions are supported and relayed as they always have been, according to special anti-spam rules.  See https://en.bitcoin.it/wiki/Transaction_fees for details.

Full git changelog:

Dean Lee (1):
      Updated Chinese Simp translation

Doug Huff (3):
      Fix rfc1918 and rfc3927 compliance for ignoring non-internet-routable host
      Add common temp files to .gitignore.
      Demystify a few magic numbers.

Han Lin Yap (2):
      Added Swedish translation
      Remove unused variable

Jeff Garzik (4):
      Bump version to 0.3.23.
      Reduce minimum TX fee for new transactions, to 0.0005.
      Lower minimum relay TX fee to 0.0001 (from 0.0005) BTC.
      Add minimal release process docs.

Matt Corallo (1):
      Fix CPU Usage bug when using -nolisten and have no connections.

Nils Schneider (1):
      create keypool in LoadWallet()

Pieter Wuille (3):
      Update transactions already in the wallet when rescanning.
      Fix for small change outputs
      Faster timeout when connecting

There were no changes between -rc1 and -final.

MacOSX uploaded.

checksums:

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

5ca82c5b694fc432b4b342dde5cd1b145e265f13  bitcoin-0.3.23-linux.tar.gz
42e8a86a97edcafb12d09fa69b56ad0451baa140  bitcoin-0.3.23-macosx.zip
779c6bb227801a51084be9594dc185d0a054ed53  bitcoin-0.3.23-src.tar.gz
12952b1c4a15ce55564500dace18ee22eb2feaa8  bitcoin-0.3.23-win32-setup.exe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIVAwUBTfanjtodwg8tvwyoAQKpiw/9EnLaoU+X8tCn2fDxxVNwukxE5voMfRB+
zxx2Sp4RuCwwylkQe6QgvdyNU0lk3lRkIkmI3RpzgK4fkR0KyvIKX30oHRpnUBz1
ck5W9sK9fFfxML044sonSMVXwWxsStaHGdvkCxH1Tpy6ZGW15g1QuS9oo/l3jHu1
EGbvE6fU/dL8X35TOEnPScWGdl0gm3bZLWaZ52vN77MUtBF9Fu1NDuS9sw90fr5l
oMZH/BRbnFDARGiH5j/hd5fBKlJ3CS2lonAHdt6MUXbm8VPax4yu2N62dZ7xWVUb
L7Hl6XMTdDqT8q2Q57Xyg471C2BwGGX7MzBnYtGMQOTi8+4EtH40PSyskb9lv5Pd
VsFdkLxAS1HTJ/maM4FVoYs3Db6ELb+4pkCJRUXneFQkhwWEu2QxesYwl9pbbi3j
OdFqElCCQnEZ19vNLXEkh1OdRBPAqiuq3xmeHJ2V7kFOrT0ZEx8oDNe1og384AP0
iMg/jFMKFSdCJjJJwrovzxsXm6EJJeiyfdZ74Ph0aMO6ANMioep+oOENQyatfoH9
tLi9hmlJlREt1ALL+XY4ceoZWvBiWv5CCwBNtRE+NzlVoCJGRZXacAUqbXrohpbP
IZrDIZyv3PCKaVe0cgOJte3ygtxUtJweu/VLFx7CpTO3w12mLRpPxDk75zH/ogBV
h8UGunKnOQc=
=PEok
-----END PGP SIGNATURE-----

Why isn't anybody making a big deal out of this? What's wrong with you people?

*claps*

Thank you, sir. This is very much appreciated!

I agree, thank you very much indeed!

do you guys know when the link will be updated on bitcoin.org?
can we get a mod to alert the forum?

Can we finally for god's sake get a wallet encryption feature?!

With all the recent hacking attempts,I vouch for that as well.
It can easily become a mess if we fail to encrypt ourselves, some of us don't know how to do this.

Chinese version don't work though, always throw error. I had to delete zh-cn folder, so I can use the English version which doesn't have the error.

You can send them the code if you want it so badly. Or you could ask nicely and wait for the developers to volunteer some free time of their life into this.

How about re-reading the top post, which (a) mentions wallet encryption and (b) provides a link to code implementing wallet encryption.

edit: nm. Wallet encryption is addressed in the OP.

Can you pastebin the error, or take a screenshot?

Great job.

feature suggestion.  "check for updates" and auto install new version.   

Thanks!

Many people worry about such a feature being hijacked, and rightly so.  One SF hack, and you can steal many bitcoin wallets through a trojan'd binary + auto-update.

In theory this is possible through a chain of trust, but it is quite complicated.  Do not expect this any time soon.

Anyone mind telling me how to update my client?

Awesome!!!!!! :D
When each BTN was $30, I usually hesitated when having to pay $0.30 fee to send just a few bucks.

where is the win32 zipped version?

Kudos to the devs for pushing out a new version that addresses issues with the influx of new users.

And thanks for addressing wallet encryption timely! And the immediate availability of a Mac build is highly appreciated, too!

Downloading right now :-)

+1

backup your wallet.dat file before you do anything
once you install the new version you just have to replace that file
look fot it in

\AppData\Roaming\Bitcoin

Incorrect. Updating the client does not overwrite the data directory. (Backing up is of course always a good idea though.)

The unusual lack of a top level directory in this archive is rather inconvenient.
But many thanks for this new release :-)

Great job, thanks for the update!

FYI

I'm having issues connecting my "internal" client (on one computer) with the one I run on another computer that's port mapped and listed on the IRC channels. The internal client does not go on IRC, isn't port mapped and the config file adds the other client on the local network using addnode. This worked well with at least 0.3.21, never really tried 0.3.22. With 0.3.23 it seems the connection gets dropped easily, and once it's been dropped it doesn't seem to come back up. Even when it's initally up (1 connection) there are very few blocks being received, and very slowly, though.

From the internal client log, although it doesn't seem to be detailed enough:

ThreadOpenConnections started
trying connection 192.168.0.123:8333 lastseen=-335573.5hrs lasttry=-363351.2hrs
ThreadMessageHandler started
connected 192.168.0.123:8333
sending: version (85 bytes)
...
ProcessBlock: ACCEPTED
socket closed
disconnecting node 192.168.0.123:8333


(Both computers are Macs)

Is there a way to prioritize clients on the same local network? I'd like for my "external" client to feed blocks to the "internal" one as quickly as possible.

Standards slip when the boss is away speaking to the CIA!

But seriously, thanks for the great work.

This.

Fortunately there are only 6 or 7 files/directories inside, not too horrible unless you had a src or bin directory where you were when you extracted it
Also, thanks for the release

Might've found the culprit. This is from the "external" client's log:

sending: block (23423 bytes)
sending: inv (37 bytes)
socket send flood control disconnect (10030645 bytes)
disconnecting node 192.168.0.132:64860


If flood control is something recently added then I guess that would be where my problem comes from. It'd be great to be able to turn that off for clients on the same local network at least if not the possibility for a full whitelist.

Just open the exe with your favorite archiver

+1 nicely done guys!

Tried with Winrar and it doesn't work

My ESET NOD32 has just decided it doesn't like the BitCoin installer all of a sudden, it just quarantined and deleted it.  >:(

*disables ESET*

Do I get to say "I told you so" when all the NOOBs flood the forum complaining they forgot their wallet passphrase? (Or conversely, chose a weak password and had their funds stolen anyway.)

I suspect wallets will be a little more permanent than private keys used for authentication.

Is there a portable version for windows?

such as the zip file for the last version?

As far as I known, quite a few users don't like to install softwares on their computer. They would like a portable version。

Thanks for the update, devs :)  You guys rock

Happy the mandatory fee was lowered, disappointed it is still undisableable without recompiling the sourcecode.  (Just tried sending myself .00001BTC as a test, and it refused to send it without a .0005BTC fee).

Any fixed-size hardcoded minimum transaction fee in the original client is an example of centralized authority controlling bitcoin:  by hardcoding 0.0005 as the minimum, Bitcoin.org is signaling that they do not expect 0.0005BTC to become particularly burdensome in the foreseeable future.  Granted, such an assumption is quite probably true, but I still feel it ought to be the market who decides such things, not Bitcoin.org.  In particular, bitcoin granularity is effectively capped now at .0001BTC (for original client users).  For example, many people have talked about Satoshi (units equal to 0.00000001BTC), but if an original client user wants to actually spend a Satoshi, they will be charged a 5,000,000% fee.  So it is tantamount to false advertising to casually discuss these units as if they are already usable.

Proposed Guiding Principle: To the extent it is possible without unduly inconveniencing the developers, the main client should be designed in such a way that if all further client development were halted due to unforeseen catastrophe, freezing the client at the current version, this version should scale arbitrarily.

The present client does not scale.  Assuming 21million BTC, a .0005BTC transaction fee is 2.38*10^-9 percent of the ENTIRE bitcoin economy [1].  This might intuitively seem tiny, but bear in mind that 2.38*10^-9 percent of the current USD economy is [2] around $20 (assuming 829billion USD in circulation [3]).

[1] http://www.wolframalpha.com/input/?i=what+percent+of+21000000+is+.0005
[2] http://www.wolframalpha.com/input/?i=2.38*10^{-9}+%25+of+829000000000 (http://www.wolframalpha.com/input/?i=2.38*10^{-9}+%25+of+829000000000)
[3] http://www.newyorkfed.org/aboutthefed/fedpoint/fed01.html

I previously ran RC1 of .23, when trying to update to this version my Antivir, ESED NOD32, complains that bitcoind.exe is a potential Win32/Genetik Trojan. One might wonder what was changed from RC1 to this Version to trigger that or if someone had actually compiled the .exe with a trojan. Please clarify.

an update of the signatures of ESET has removed the warning, so a false positive.

I'm also happy that the mandatory fee was lowered. But I still don't see, why there has to be a mandatory fee at all.
Sure miners need to have an incentive but there are miners out there who support free transactions.

Shouldn't the client give you the option to send money with fee (priority) and without fee (low priority)?
Currently the client simply gives you an error message that you can only send your transaction if you accept the minimum fee of 0.0005 BTC

This is a huge setback for using BTC as micropayments.

Bitcoin is not suitable for micropayments. And never was. The fees are not just to enrich the miners but to conserve the resources.

In my opinion, the lowering of the fee is premature and will result in fattening of the block chain which will be pain in the neck without a thin client ready.  With the current average block size of 20kB
http://blockexplorer.com/q/avgblocksize
the blockchain grows by about 100 MB per month and if the fees are decreased, it's going to be only worse.

You do realize though that a lot of advertisement has been made stating that bitcoin is THE micropayment solution.

Especially for digital content (YouTube, etc).
Assume one bitcoin will once be worth a thousand dollars or more. Who would then pay for digital content, if the minimum amount was let's say 0.01 BTC.

See my point?

If a solution cannot be found in the regard, maybe people should not promote bitcoin as a micropayment solution...

No one with any authority has said such a thing.

It is not. There is a network-wide cost of processing each transaction. Currently each client has a copy of the whole blockchain. Each client verifies (twice) every single transaction. Soon, you will need a fat server to even use bitcoins because there is no other way. Reducing the fee before the constraints are solved is premature. I for one would rather see slower Bitcoin adoption than Bitcoin bloat.

Given the current exchange rate, the fee is barely 1 dollar cent. That is alot lower than any micropayment service out there. Even if the BTC Value shoots up to 100$, we would still be at a fee of only 5 cents, which is still very competetive to commercial micropayment providers. I am sure that if the BTC Value goes into 3 digit dollars, we will see a further reduction of the fee in the next iterations of the client.
No need for huge setback etc drama.

Just as an example watch the "we use bitcoins"-video. (http://www.youtube.com/watch?v=Um63OQz3bjo&feature=player_embedded#at=21)

@ 0'19'' it shows a price tag with a regular transaction fee of $0.30 and says "fees are much lower"; under the tag it shows "0.01 B"

This clearly is a promotion of how cheap transactions fees allegedly are.

Now at a BTCUSD=19.00 this means transaction fees are 19 cents - with the exchange rate rising even more.

(Sure, I do realize that at the time when the video was produced it had probably not been foreseen, that the exchange rate would rise at the speed it did, but anyways it still is contradicting - especially to newbies/potential adopters , I think).

Ok, new fee is reduced - check
Ok, 0.0005 BTC is "much lower" than 0.30 USD but just a week ago it was even more (when the rate was 31 USD and min trans fee was 0.01 BTC).

I still think, that a percentage with a cap for larger payments would be a better system.
Like say 0.25 % Fees: min. 0.00000001 max 0.125 BTC (so every transaction exceeding 50 BTC will be charged with 0.125 BTC transaction fee)

PRO: any amount can be sent
CON: larger amount would pay more than today

So content creators and charity could really benefit from it, while the "many, many" drug dealers and buyers would "subsidize" the small scale economy.
 

What do you think?



PS: I thought there was a built in way that old blocks do not have to be fully downloaded - couldn't that solve the problem of massive data transfer?

Speaking of block chain bloat:  the existing state of affairs actually incentivizes the practice of "bitcoin change":  If a merchant wants to sell something for 1 Satoshi, he can make a deal with his customer:  the customer sends the merchant 1BTC and the merchant sends the customer back 0.99999999BTC.  This way, no transaction fee is required.  However, it clogs up the block chain more than if the customer simply sent the Satoshi directly.

Bitcoin already does this. What exactly are you getting at?

See the big bold text in the top post -- most transactions are free.


I am quite sympathetic to this PoV...

Great job getting a new version out. I've run it on multiple machines and it works well and feels 'snappier'. Am I seeing all the addresses in the wallet (even those unused 'hidden' addresses) - not sure, but if so, cool. Looking forward to wallet merge/split and encryption! I was hoping that some of my 'missing' bitcoins would magically appear. I'll just have to wait for the another version. :)

Where does it say that it was 0.01 last week? Client version 0.3.22 is dated 2011-06-08, so the fee was 0.0005 BTC last week. 0.3.21 is dated 2011-05-02, a month and a half old (no idea if that had 0.01 BTW).

Unless I'm missing something 0.0005 BTC equals 0.015 USD at $30/BTC, not 0.30 USD. That seems low enough already :)
With the current client and at the current price that drops 0.0019 USD (note the extra zero).

Some minor updates to the released files:

1. Linux tarball regenerated with properly named directory inside.
2. Win32 .zip archive added.
3. PGP-signed SHA1SUM.asc added to SF

The following are the updated checksums:

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

d7a34e1151dedfba5af1bf7496ed041f5b4955e5  bitcoin-0.3.23-linux.tar.gz
42e8a86a97edcafb12d09fa69b56ad0451baa140  bitcoin-0.3.23-macosx.zip
779c6bb227801a51084be9594dc185d0a054ed53  bitcoin-0.3.23-src.tar.gz
12952b1c4a15ce55564500dace18ee22eb2feaa8  bitcoin-0.3.23-win32-setup.exe
89194d3b3ee87f450f520cf365b863e0fab8bc9f  bitcoin-0.3.23-win32.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIVAwUBTfp5k9odwg8tvwyoAQIJ9Q/9GHiSA8oEuQM29qu1laCD45AY9lnsJeNN
ZNRiAE92WJ7SiSKxW6V1M1phMk4IMG/0MmR8L/PRqJfWDg+6FQzAzpZLobH0Hnfl
MujhKIhRcP1zs7m/t/zwjQxRXT+N6UotfdwvO+GLbBnUSVZC2zr/9XdSs65gLIhq
lMkJUwYLEBvuXvo98Sbp5MeXHdfWUqAQufuYnMvRsCT9BcX5cP8cmaxvICLANRbc
89kU+7JQ7fauiHTnYJ0GkK/xIyCnlwfGsEe8GQsIgWF0RBpayszCxSOsuzFYMsED
7cIjN9AscDiJ3UmhXSg6xbRi4LZGXm195TmMdxJdRNHWqjfpFkxEXoW7iuUvxVDU
tiMMA+yXMTUSdbn2IxdZFLqKpgXcpf05T91g9w/ll1VMxkmOOcTSZc5dCbMMUn0z
kA12PagjDlH+xz3Qab9GNV13XlHKbG0VT8AsE1No+HJCV8qugMdI6hgZqMDucbmQ
U2KiG0EpwNx2G31l2K99yIxuumE7nDslhkfzSosVXhgHwqzr4ukl5ykFwfZnJjHF
BJ0zrcWCViGes+3awHwASQvlIGcvXprEzC0ZKEsbalZkAoCYYiGoZbNHtEMq3lZq
d0siUzwEPA31xfS/dACbX8ml8jC0jBmEy296WZ2LX7pZOcqa2ayMbGE81tg+5Nvy
UYihPYX4FS0=
=9NXu
-----END PGP SIGNATURE-----

Windows: properties of file "bitcoin-0.3.23-win32-setup.exe" is still displaying 0.3.22 as version.
It's very minor but reporting it just in case the packager has been using an outdated .nsi file.

The line at the top of the page occasionally says: News: Version 0.3.22 is now available. (not 0.3.23)

trying to run the 32bit linux binary, on a fresh install of 32bit ubuntu lucid with the latest updates, and getting a segmentation fault, both with bitcoin and bitcoind, and both with and without the .bitcoin data directory.

gdb traceback below:

on the same machine, absolutely no problems running previous version of bitcoin, 0.3.22.


EDIT: aha! it segfaults when there's no internet connection. when internet connection is available, works ok. earlier versions used to be just fine without net, but this one segfaults, so it seems one of the network-code changes has introduced a bug.

can anyone confirm the no-internet-connection segfault for 0.3.23 or linux?

My first run crashed. I don't recall whether the net was connected, but assume it was.

Hi Jeff,

great.

One extremely dumb question - how does one verify that signature?
I can't find it in http://pgp.cs.uu.nl/, for example.

Windows: http://support.microsoft.com/kb/841290 or http://www.nirsoft.net/utils/hashmyfiles.zip
Linux: $ sha1sum bitcoin-0.3.23-linux.tar.gz

If you are using gpg4win then you can use Kleopatra.
Save the signature in a file and open it with Kleopatra.
Make sure you have added a key server in Kleopatra's options first.

That's not the point. The checksums are fine and gpg says
the signature in itself is correct. What I didn't found is how
to verify that the signature belongs indeed to Jeff.
For signatures on Linux kernel sources, for example,
there is a big web of trust to which most open source
contributors belong.

If you know Jeff personally, that's of course no problem at all.
But in general, signatures without references to such a trust web
cannot warrant that the binaries have not been replaced by
someone else. It's surely paranoid to think about that,
but for a payment system it's also the definitive worst case if
it happens one day.

Good, please link to it from www.bitcoin.org also.

Paste the signature from above to e.g. /tmp/foo.asc
$ gpg /tmp/foo.asc
it asks for the data file (bitcoin client), this will spit out the key ID (2DBF0CA8)
If you plug that into the site you listed, it will complain about it not being in the strong set, but offer you a search (first link):
http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint=on&search=0x2DBF0CA8

You can get the public key and trace the web from there.

Of course.


I seem to miss the point. Are you aware that anyone can generate and upload
a key with some uid like "Jeff Garzik <jgarzik@exmulti.com>" ?

Yes, that's why you need to trace the web of trust. If it's a long chain of Bitcoin related people but all on an island, it might all be fake. At some point some of those people will have ties to say well known kernel developers, who in turn have a large web of trust. Those are unlikely to be fake so you can have reasonable trust in this key, unless somehow one or more people were duped into signing the key of course.

Yes, I have started getting segfaults with 0.3.23 and it is probably due to loss of connection there is wireless involved.  Ubuntu 10.10 64-bit.