*** ALERT *** Upgrade to 0.3.6

is this in the SVN?

I appreciate the quickness of this security update, but unfortunately none of the Linux builds work (32bit or 64 bit) because the file is missing. I'm assuming if I go find the file it will work, not sure what luck others will have though using the new build.
Error

Code:

./bitcoin: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory

are satoshi and Olipro working together?
if not, any chance you could? 
i'm well pleased with the speed enhancements Olipro is making, but i would like bc to be secure!

Quote from: satoshi on July 29, 2010, 07:13:06 PM (https://bitcointalk.org/index.php?topic=626.msg6451#msg6451)

Please upgrade to 0.3.5 ASAP! We fixed an implementation bug where it was possible that bogus transactions could be accepted. Do not accept Bitcoin transactions as payment until you upgrade to version 0.3.5!

Like Olipro, got a lot of people doing custom builds out there -- in fact, I must use a custom build on several machines.
May we assume SVN has all necessary updates?

Quote from: andy_3_913 on July 29, 2010, 07:30:42 PM (https://bitcointalk.org/index.php?topic=626.msg6457#msg6457)

are satoshi and Olipro working together?
if not, any chance you could? 
i'm well pleased with the speed enhancements Olipro is making, but i would like bc to be secure!

So far, the new build (stock) has given a 100% speed increase on my Celeron Machines that couldn't run those custom builds before. I'll compare the new release to the older *optimized* builds to see what the speed difference is just out of curiosity. 

Quote from: knightmb on July 29, 2010, 07:34:22 PM (https://bitcointalk.org/index.php?topic=626.msg6459#msg6459)

Quote from: andy_3_913 on July 29, 2010, 07:30:42 PM (https://bitcointalk.org/index.php?topic=626.msg6457#msg6457)

are satoshi and Olipro working together?
if not, any chance you could? 
i'm well pleased with the speed enhancements Olipro is making, but i would like bc to be secure!

So far, the new build (stock) has given a 100% speed increase on my Celeron Machines that couldn't run those custom builds before. I'll compare the new release to the older *optimized* builds to see what the speed difference is just out of curiosity. 

So far I'm seeing a comparable hashing rate to the most recent of the Olipro 32-bit binaries. It might even be slightly faster.

With the official Linux-64bit build, run on Fedora 13, I see it failing badly:

Code:

************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in AppInit()
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in CMyApp::OnUnhandledException()
terminate called after throwing an instance of 'DbRunRecoveryException'
what(): DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery

Praying my bitcoins aren't eaten...

Quote from: jgarzik on July 29, 2010, 07:42:15 PM (https://bitcointalk.org/index.php?topic=626.msg6462#msg6462)

With the official Linux-64bit build, run on Fedora 13, I see it failing badly:

Code:

************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in AppInit()
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in CMyApp::OnUnhandledException()
terminate called after throwing an instance of 'DbRunRecoveryException'
what(): DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery

Praying my bitcoins aren't eaten...

I think you'll be ok, it blew up on me too. Run the older version, you should still see all your coins. Backup first for the next Linux release 

Quote from: jgarzik on July 29, 2010, 07:42:15 PM (https://bitcointalk.org/index.php?topic=626.msg6462#msg6462)

With the official Linux-64bit build, run on Fedora 13, I see it failing badly:

Same result on another machine. BDB errors, and death. 0.3.5 on 64bit Linux is questionable. You didn't mix up the builds with 32-bit Linux, did you?
debug.log says:

Code:

Bitcoin version 0.3.5 beta
Default data directory /g/g/.bitcoin
Bound to port 8333
Loading addresses...
dbenv.open strLogDir=/garz/bitcoin/data/database strErrorFile=/garz/bitcoin/data/db.log
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in AppInit()

Quote from: knightmb on July 29, 2010, 07:47:37 PM (https://bitcointalk.org/index.php?topic=626.msg6464#msg6464)

I think you'll be ok, it blew up on me too. Run the older version, you should still see all your coins. Backup first for the next Linux release 

Double-ACK 
older version (SVN 117 + listtransactions + getinfo KHPS) works fine, all bitcoins there. And yes, I should back up before following "please upgrade" instructions... 

Quote from: davidonpda on July 29, 2010, 07:51:38 PM (https://bitcointalk.org/index.php?topic=626.msg6466#msg6466)

Can windows users upgrade to the 3.5 for now?

Yes, I've tested on Windows XP, 2003, and 7 all went through just fine. You'll enjoy the speed increase as well. 
[err, wait I guess, new version about to spawn]

Ha! One of the changes in there is updated some v "0.3.3" stuff to "0.3.6" but that isn't the important part of the update. :-)

SVN r119 seems to work fine here. No BDB explosion.

Tested the Windows build across XP, 2003, Vista, 7 (both 32 and 64bit builds), no issues installing or running client. So far so good, looking forward to the Linux client. 

Still a no go on the Linux build though, this is the console error I get. I checked to make sure the file was there, but the versions don't match I guess?
64bit Client Error, will try out 32bit client and see if the error is similar.

Code:

./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)

The machine I tested this on uses nothing but the stock builds, no modified builds were used prior.
Same error for 32bit client

Code:

./bitcoin: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)

Linux - Mandriva 2010.0 [64bit and 32bit] OS systems setup

0.3.6 binaries for linux works fine on two my machines (64 and 32 bits) with Debian squeeze/sid

Quote from: bitcoinex on July 29, 2010, 09:27:15 PM (https://bitcointalk.org/index.php?topic=626.msg6493#msg6493)

0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)

That's good to know, might just need to update mine, checking to see what versions I have currently installed.

Quote from: knightmb on July 29, 2010, 09:23:21 PM (https://bitcointalk.org/index.php?topic=626.msg6492#msg6492)

Still a no go on the Linux build though, this is the console error I get. I checked to make sure the file was there, but the versions don't match I guess?
64bit Client Error, will try out 32bit client and see if the error is similar.

Code:

./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)

The machine I tested this on uses nothing but the stock builds, no modified builds were used prior.
Same error for 32bit client

Code:

./bitcoin: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)

I'm getting this too on 32-bit Ubuntu 9.10.
It works fine on 32-bit and 64-bit Ubuntu 10.04.

Quote from: bitcoinex on July 29, 2010, 09:27:15 PM (https://bitcointalk.org/index.php?topic=626.msg6493#msg6493)

0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)

If you (and others) are willing, please post your OS + OS version, when posting success/failure reports.
I will echo a recommendation to satoshi from another forum member: build linux binaries on an older Linux OS, to ensure wider compatibility. Maybe something as old as CentOS 5 (caveat: requires custom openssl, boost, db4 and wx builds).

Ah, mine is linked to 2.10.1, I'll bring my system up to bleeding edge to see if that solves it 
[edit] Well turns out I can't package wise as they top out at 2.10 for now

Quote from: jgarzik on July 29, 2010, 09:30:08 PM (https://bitcointalk.org/index.php?topic=626.msg6497#msg6497)

Quote from: bitcoinex on July 29, 2010, 09:27:15 PM (https://bitcointalk.org/index.php?topic=626.msg6493#msg6493)

0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)

If you (and others) are willing, please post your OS + OS version, when posting success/failure reports.
I will echo a recommendation to satoshi from another forum member: build linux binaries on an older Linux OS, to ensure wider compatibility. Maybe something as old as CentOS 5 (caveat: requires custom openssl, boost, db4 and wx builds).

I would agree, would help those of us not on the bleeding edge of distro packages. 

Quote from: jgarzik on July 29, 2010, 09:30:08 PM (https://bitcointalk.org/index.php?topic=626.msg6497#msg6497)

Quote from: bitcoinex on July 29, 2010, 09:27:15 PM (https://bitcointalk.org/index.php?topic=626.msg6493#msg6493)

0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)

If you (and others) are willing, please post your OS + OS version, when posting success/failure reports.
I will echo a recommendation to satoshi from another forum member: build linux binaries on an older Linux OS, to ensure wider compatibility. Maybe something as old as CentOS 5 (caveat: requires custom openssl, boost, db4 and wx builds).

sorry. I'm checked binaries on Debian GNU/Linux squeeze/sid

v0.3.6 works on FreeBSD/i386 7.2,7.3 and on FreeBSD/amd64 8.0
Compiles cleanly without any warnings, and appears to be working fine.

Maybe the points listed in http://bitcointalk.org/index.php?topic=612.0 would help making the Linux binary distribution works for the widest audience.
Getting the project to build under the OpenSUSE OBS service should allow the maintainer to get distribution specific compliation for free.

0.3.6 works great on Win7 Pro 64-Bit.

Ubuntu Linux 9.10
Error:
/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11' not found 

Quote from: WMFrend on July 29, 2010, 10:08:14 PM (https://bitcointalk.org/index.php?topic=626.msg6511#msg6511)

Ubuntu Linux 9.10
Error:
/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11' not found 

$ dpkg -l|grep -i glibc
ii libdb1-compat 2.1.3-9 The Berkeley database routines [glibc 2.0/2.
?

On Debian testing 32-bit, I get a few build errors, all resembling:

Code:

script.cpp:114: error: ‘OP_NOP1’ was not declared in this scope

I got these when attempting to "make bitcoind" without "make clean" or "make" first. It looks like the bitcoind build instructions don't compile the headers first, but they also don't delete the headers.h.gch, so the old headers are used if present.
If anyone else gets this error, the simplest solution is to "make clean" and retry the build.

Quote from: satoshi on July 29, 2010, 09:43:15 PM (https://bitcointalk.org/index.php?topic=626.msg6502#msg6502)

"./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)" isn't a new problem that started with 0.3.6 is it? This was built on the same OS installations as 0.3.0.
Unfortunately I upgraded to Ubuntu 10.04 before 0.3.0. I will not upgrade anymore. I don't know when I might have time to reinstall to downgrade, but at least by not upgrading, it'll gradually fix itself.

That's strange, 0.3.3 worked fine on it. It's no biggie, I need to upgrade that machine anyway.

Quote from: WMFrend on July 29, 2010, 10:08:14 PM (https://bitcointalk.org/index.php?topic=626.msg6511#msg6511)

Ubuntu Linux 9.10
Error:
/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11' not found 

dpkg -l | egrep "(libc6|glibc)"
# This will display what version you currently have installed
# I guess you have glibc version 2.10 or older installed.
apt-get update
apt-cache showpkg libc6 | less
# Look (near the bottom) for the versions available for a 2.11 version
#Maybe you can just upgrade with:
apt-get upgrade libc6
# Above instruction for a real debian system, they might work with Ubuntu

Quote from: satoshi on July 29, 2010, 11:12:12 PM (https://bitcointalk.org/index.php?topic=626.msg6542#msg6542)

We don't really need pre-compiled header. It only makes it compile slightly faster. I think I'll just get rid of it. Even still, you'd still need to remember to "make -f makefile.unix clean" or delete headers.h.gch one more time to get rid of the leftover file.
Damn that GLIBC_2.11. I thought I'd been careful not to accept any of the updates.

I was going to compile a GLIBC_2.10 version until I noticed that I had to keep installing more and more to get through the check errors, LOL. Looks like I just need to fire up a Virtual Box with all the dev packages loaded to do this in a virtual machine to make life easier.

Could someone help me understand why it matters that hashing is 2x faster? If everyone were to upgrade the coin inflation rate would still remain the same. Thus there is a "slight" advantage to early adopters. I guess some could say it gives "honest nodes" more time and thus makes it even harder for dishonest nodes to gain an edge.
The #1 aspect if a currency is divisibility and fixed supply and the relative value of the coins will adjust automatically relative to the supply of goods available to buy. So I would think we would want to focus on aspects other than "generation speed" first.

Quote from: bytemaster on July 30, 2010, 01:05:40 AM (https://bitcointalk.org/index.php?topic=626.msg6566#msg6566)

Could someone help me understand why it matters that hashing is 2x faster? If everyone were to upgrade the coin inflation rate would still remain the same. Thus there is a "slight" advantage to early adopters. I guess some could say it gives "honest nodes" more time and thus makes it even harder for dishonest nodes to gain an edge.
The #1 aspect if a currency is divisibility and fixed supply and the relative value of the coins will adjust automatically relative to the supply of goods available to buy. So I would think we would want to focus on aspects other than "generation speed" first.

Quite simply to level the playing field for coin generation and to help maintain block generation at a stable rate. If everyone was limited to just 100 khash/s by the client, someone would just compile a client that does not have the limit and load it up on a server farm where they could generate 10,000 khash/s per machine. It would put the coin generation supply in the hands of who ever had a large amount of money to invest in servers and discourage everyone else from trying to mint coin. If we could trust that clients would only act as transaction nodes and that everyone would get a fair shot at coin generation then no one would care if the client was generating at 5 khash/s all the time.
So in a perfect world, no one would care that they can generate 2 or 3 times faster than someone else, but we don't live in a perfect world. 

My khash rate went from 700 to 1700.Sweet!

Quote from: Odin on July 29, 2010, 09:45:06 PM (https://bitcointalk.org/index.php?topic=626.msg6504#msg6504)

Maybe the points listed in http://bitcointalk.org/index.php?topic=612.0 would help making the Linux binary distribution works for the widest audience.
Getting the project to build under the OpenSUSE OBS service should allow the maintainer to get distribution specific compliation for free.

Great point. I got the bitcoind (without the wx GUI) compiling for Ubuntu 10.04 
I'll try to get the other version to work too, but it's quite annoying that BC needs such a new version of libdb and wx...
https://build.opensuse.org/package/show?package=bitcoind&project=home:cdecker (https://build.opensuse.org/package/show?package=bitcoind&project=home:cdecker)

0.3.6 up and running on w2k/xp32/xp64/w7
nice speed-updates on all systems,
guess we can prepare for another major step up in difficulty, now that all nodes do 2-3times the hashes they did before.
is that a good or a bad thing?

Fastest possible stock build removes any advantage other 'special' builds would have. Which is good because generation will be more uniformly distributed. It's important for the official build to be always the fastest available. It should use any known optimization (including CUDA, OpenCL, ability to work on the Cell proc etc).
The one and only effect for now - another difficulty adjustment, still same chance to generate until more users/cores came in.

would an auto-update function built into bc be possible?

Quote from: andy_3_913 on July 30, 2010, 04:04:51 PM (https://bitcointalk.org/index.php?topic=626.msg6667#msg6667)

would an auto-update function built into bc be possible?

It's something that I have already suggested here :|
http://bitcointalk.org/index.php?topic=259.0

Quote from: Joozero on July 30, 2010, 04:49:25 PM (https://bitcointalk.org/index.php?topic=626.msg6673#msg6673)

Quote from: andy_3_913 on July 30, 2010, 04:04:51 PM (https://bitcointalk.org/index.php?topic=626.msg6667#msg6667)

would an auto-update function built into bc be possible?

It's something that I have already suggested here :|
http://bitcointalk.org/index.php?topic=259.0

sorry! 

32Bit and 64Bit versions for Ubuntu 10.04 are available on the openSuse Build Service: https://www.bitcoin.org/smf/index.php?topic=644.0

I can only imagine the pain you went through to get these builds because I'm trying to build the program on a Ubuntu 9.04 box and so far I can't seem to find all the dependencies to compile no matter how much I keep installing packages and compiling source, LOL.

Quote from: satoshi on July 30, 2010, 07:53:06 PM (https://bitcointalk.org/index.php?topic=626.msg6711#msg6711)

I can't understand why you're having so much pain. I just followed the instructions in build-unix.txt. I made a couple little corrections for Boost 1.37, which I'll put on SVN the next time I update it, noted below:
Dependencies
------------
sudo apt-get install build-essential
sudo apt-get install libgtk2.0-dev
sudo apt-get install libssl-dev
sudo apt-get install libdb4.7-dev
sudo apt-get install libdb4.7++-dev
sudo apt-get install libboost-all-dev (or libboost1.37-dev)

That part I highlighted is what got me. You can't install all the libboost packages with that command (I tried to cheat with a * also), but part of my issue is I took it too literal like install *everything* that had to do with libboost, LOL.
Really, all that was needed was the libboost1.37-dev package and that made all the compile errors go away. Everything else worked out just fine as far as compiling your own wxWidgets, compiling Boost 1.4, etc.
So that last command should simply be
sudo apt-get install libboost1.37-dev
On a side note, I compiled mine on a Ubuntu 64bit system, so the finished program came out 64bit aware. I'm testing it out on some 64bit systems to see how well things go.