Slightly used, in good condition.
Looking for 2000 900 BTC OBO, thanks!

http://www.compusa.com/applications/searchtools/item-details.asp?EdpNo=4398715&csid=ITD&body=MAIN#detailspecs

Yea, I tried that too, after seeing it at 90C temps for a while I decided to not generate with my MBP

It's great that it's working for you - I'm not sure if it's possible to ask the OS to switch to the high performance video automatically, as far as I know you have to go to the power settings and tweak it manually, like you did.

Is it possible to statically link the c++ library?  If it is possible, is it something that is an acceptable practice or does it cause problems?  Maybe just include the library with the program?  When I said static I was only referring to openssl

The data that is being hashed is based on the previous block.  For a node to accept a new block into its chain it must 'connect' to the top block otherwise it just ignores it.  This means the problem is changing each time a new block is created because you must now connect to that one instead of the one you were previously using.  This is why if you have a flaky connection or excessively high latency, you end up wasting computing time working on hashing a block that would never be accepted by the other nodes.

We would need to write code to use this hardware, there is no automatic acceleration, btw.

That does sound interesting, I might go pick one of those up to experiment.

I like MMORPGs and bitcoins, so this sounds interesting to me, please elaborate

Aside from the housekeeping fields needed to make sense of the data, the rest of the data that is being hashes is just random.  Everyone's is different and you never get any closer to solving it.  Every time it is twiddled and re-hashed you have the same chance of finding a solution.  This is just like buying raffle tickets.  Everyone's numbers are different and they could all be winners, however the guy who gets more raffle tickets might win more often, if this process was repeated over and over.  Computers that can try hashing faster have more raffle tickets but every hash calculation has the same chance of being a winner.

Maybe because you're giving out nickels some people are just asking for a ton of them to supplement their generation income.

It is ok to use the same address more than once for manual transactions but for someone running a merchant site or other such service it would be best if they generated a new address each transaction to prevent analysis of their income.  If you see they sell bags of heroin for 500 BTC for a small one and 5000 BTC for a big one, and they always use the same address, you can just count how many bags they've sold, it's like having your accounting books open for everyone to see.

This is great, thank you!

I think this would be interesting.  I myself play one of those games occasionally - I think there is probably a good crossover between geeks that play computer games and geeks that like bitcoin.

I was going to try creating one but Satoshi pointed out that the 32 bit windows one will work for everyone.. the only reason we need a 64 bit linux one is because not everyone has a multilib system that can use the 32 bit one.  The only difference between building a normal 32 bit version and a 64 bit version is that the 64 bit one will use more memory.  The Mac OS version is both 32 and 64 bit, the system selects the proper version automatically when you start the app.

It is not lowered, it only goes up.

It will not be lost.  They will see it show up in their transaction list once all the blocks are downloaded.  Every other node has a copy of the transaction too.

I wonder what other possibilities there are though.. some of the new people hooked up hundreds of computers (someone said 300 workstations?) so the network adjusted difficulty.  To give you some perspective, in all the time it has been running the difficulty rose to 23.  The previous jump was very large, it went from 19 to 23.  When all the new users showed up it jumped from 23 to 45.  It's based on fast the new blocks are showing up, if they're being generated very quickly then the difficulty jumps accordingly to target 1 block every 10 mins average.

I'm not sure which random number thing you're referring to, but here is a quick outline of how the generation works:

Prepare a block of memory organized as a struct - certain fields like the hash of the previous block, the current time and some other housekeeeping information is filled in.  The struct has an integer field and another 'expansion' field where the data is free form.  This free form data is altered (simple increment of a number) and then the struct is hashed.  The resulting hash is interpreted as a large integer.  If it is equal to or less than the current difficulty function then the proof of work has been found and this block is added locally and broadcast to other nodes.

This is similar to having a 100 sided die - if you roll below 70 you win.  To make the game harder you have to roll below 50, then 40, etc.  Basically there is no known shortcut to go from a desired hash value to the original input, we only know how to do it quickly in the other direction, so it is simply a brute force iterative process.  Statistically, less blocks of data will be below the target value, the lower the target value is.  Finding a block that hashes below the difficulty value proves that you worked on the problem, or got lucky and hit it on the first try, but over a long period of time you won't keep getting lucky, you'll have to try lots and lots of different values.

I will give you some coins to start out with if you post your address.  I think generating faster would be more difficult for the network to arbitrate as it scales up.  The target of the algorithm is 1 block per 10 minutes, that is how the difficulty is adjusted.  If the generation difficulty targeted a block per 1 minute (but maybe worth 1 BTC instead of 50) then latency would invalidate a lot more generated coins.

A generated block must be based on the previous block, so if a new blocks is received from the network, the header that's being hashed must be updated to point at the new highest block.  If two nodes both generate block #70,000 then whichever one's broadcast propagates first wins.  It is expected that collisions will occur during normal operation but there would be a lot more if the difficulty was scaled down.

I think what you're saying makes perfect sense and we would like to keep the difficulty low for as long as possible to allow new users to get coins quickly.  Unfortunately it is not possible to keep it low forever because of the technical details.

It generates a new address and puts it in the main window for you if a payment is received for the previous address.  This is so each time you click 'copy to clipboard' to send it to someone, it's easier to get a unique one.  The old one is still valid and it's still in your address book.

Try renicing bitcoin and see if it helps.   Find the pid in top or ps and then renice +19 1234 where 1234 is the pid.

It will always use max CPU to generate but the generating thread is scheduled at a low priority so it should yield to other processes.  I can compile code and do other things on my windows machine with 0.3 running and it doesn't seem to slow it down for me at least.