[ANN] Bitcoin version 0.3.23 released

[cschmitz]

This is a huge setback for using BTC as micropayments.

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.

[elements]

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?

[djproject]

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.

[error]

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?

[jgarzik]

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.

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

I for one would rather see slower Bitcoin adoption than Bitcoin bloat.

I am quite sympathetic to this PoV...

[netrin]

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.

[Nescio]

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

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

[jgarzik]

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

[joan]

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.

[Nescio]

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

[nanotube]

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:

Code:

$ gdb bitcoind
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/dfolkins/bin/bitcoind...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/dfolkins/bin/bitcoind 
[Thread debugging using libthread_db enabled]
[New Thread 0xb7abbb70 (LWP 2010)]
[New Thread 0xb72bab70 (LWP 2011)]
[New Thread 0xb6ab9b70 (LWP 2012)]
[New Thread 0xb62b8b70 (LWP 2013)]
[New Thread 0xb5ab7b70 (LWP 2014)]
[New Thread 0xb52b6b70 (LWP 2015)]
[New Thread 0xb4aa7b70 (LWP 2016)]
[New Thread 0xb42a6b70 (LWP 2017)]
[Thread 0xb72bab70 (LWP 2011) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb5ab7b70 (LWP 2014)]
0x002e150b in vfprintf () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0x002e150b in vfprintf () from /lib/tls/i686/cmov/libc.so.6
#1  0x002e2ec2 in ?? () from /lib/tls/i686/cmov/libc.so.6
#2  0x002dde13 in vfprintf () from /lib/tls/i686/cmov/libc.so.6
#3  0x0038203d in __vfprintf_chk () from /lib/tls/i686/cmov/libc.so.6
#4  0x08056458 in ?? ()
#5  0x080847d9 in ?? ()
#6  0x08091c7a in ?? ()
#7  0x08092853 in ?? ()
#8  0x0015296e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#9  0x0036ea4e in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)

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.

[nanotube]

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

[netrin]

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.

[Joise]

Some minor updates to the released files:

[ ... ]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

[ ... ]

-----END PGP SIGNATURE-----

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.

[Nescio]

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

[Schleicher]

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

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.

[Joise]

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

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.

[foo]

2. Win32 .zip archive added.

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

[Nescio]

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.

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.

[Joise]

You can get the public key   [ ... ]

Of course.

[ ... ] and trace the web from there.

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>" ?