You should build using the nmake command from the visual studio command prompt as described in the information distributed with the source.

This is the same problem I've encountered with a couple of friends I've talked to about bitcoin. A lot of people don't have the economic insight to understand why bitcoins have certain intrinsic advantages over other currencies. To them it's just play money you can generate with some obscure algorithm on a computer and then convert into "real" money. At best they see it as some form of speculation or pyramid scheme (which currently is a deflating factor imho) and in the worst case they see it as some unworldly hippie thing.

Some serious thought should be put into making people understand the intrinsic benefits of bitcoins, but I'm not sure how to do that either. Most people simply don't care and just use whatever money their government wants them to use.

Can you explain to me (or give me a link that explains it) how Heisenberg's principle applies to forex markets? At first, this sounds a bit like gibberish to me. :s

Could you elaborate on that?

Not sure if I trust this, might be a scam to rip off your coins or something.

How can you guarantee 10% weekly interest? Is this a Ponzi scheme?

That doesn't sound very scalable... Does anyone remember the gnutella bottlenecks? If not, read up on this: http://en.wikipedia.org/wiki/Gnutella#Design

Also not relaying alerts signed with a different key basically means there's only one person in the whole world that can send messages through the network. Isn't that kind of against the spirit of p2p and decentralization in general?

What you have calculated is the power requirements of system with a single Phenom II X4 processor, the article talks about 6 such processors in one system.

A single Phenom II X4 consumes at full load approximately 125W (see TDP: http://en.wikipedia.org/wiki/AMD_Phenom), 6 such cores would consume about 750W, so a full system including memory, video, motherboard, will draw about 900W, assuming a 1000W power supply unit (a somewhat pricey device which is oddly forgotten in the article) with an efficiency of around 80% you can expect drawing over 1 kW 24/7 running such a system. Assuming 1kW and you pay 0.15ct for each kWh that would be about 3.60 every day on power consumption. That's a little bit more than the value of generating one block (which gives you 50 bitcoins).

As you're expected to generate one block each day, you would actually lose money generating bitcoins, even when you got that $2000 system for free. Of course this is assuming you pay a more or less standard price for electricity, don't have any excess self-generated electricity, you don't recycle waste heat, ...

I think all of them can go away since SHA-256 expects it's bytestream to be big-endian. The fastest way to find out I think is to run the code through a debugger on both a BE and LE machine at the same time and compare results at every step.

The ByteReverse macro should probably be skipped before doing SHA-256 transforms.

@sgtstein: Intel's Sandy Bridge (to be released Q4 2010) will also support AVX 256-bit SIMD registers. That means 8 simultaneous hash calculations/thread would be possible, in principle.

Does anybody has any reports on 4-way SSE2 on the Pentium D (Presler)? What kind of performance can I expect? I have an old Pentium D+mobo laying around and I would fire it up as a mining server if performance would be ok. Probably won't be the most efficient khash/Watt though.

I have that one too, not sure what it means.

EDIT: Just thought a bit about it, and maybe it means that there was an attempt to validate a transaction whose previous transaction in the chain hasn't been validated yet. Possibly a minor concurrency thing, not really an issue.

I'm thinking about writing a minimal-dependency C library implementation of Bitcoin. There's the other thread here where people are reverse engineering the protocol for a python client. More and more alternative implementations will appear when Bitcoin gains more momentum, especially since the stock implementation can't possibly cover all the Bitcoin use cases (think of a laundromat that accepts Bitcoins for example). Alternative implementations will happen and decent protocol standardization is the only way to prevent potential problems with multiple implementations inter-operating on the network. Multiple implementations will make the network grow faster, standardization will make the network more robust. Both will dramatically increase security, as a lot more potential problems will be discovered.

I'm looking into the possibility of integrate Bitcoin functionality into an existing GPL software product, the problem is that it seems to be hard. The one true implementation brings with it some additional dependencies such as wxWindows (which is actually pointless if you're just interested in the functionality and not the GUI), BerkeleyDB (which is a bit much for storing just a bunch of keypairs), openSSL (which is reasonable as it's use is very wide-spread, but i'm not entirely sure why it is required as the set of crypto functions in Bitcoin is fairly limited afaik) and Boost (which is huge to introduce in an existing project when it's only needed for Bitcoin functionality). Especially on Windows is including those libraries far from a straightforward task and building a 64-bit binary for Windows is just a pain.

I don't really have a problem with the fact that a one true implementation is preferred, because I understand more implementations will introduce complications in this early stage, the examples where this method is successful are few (Perl is maybe one of the very few exceptions probably because it's very well-documented). I think in the long run multiple implementations are going to be required if Bitcoin is to grow (a lot) larger. Keep in mind that in time perhaps other devices with much more esoteric platforms may want to be able to have Bitcoin functionality as well (smartphones were already mentioned, but think about automated payment servers, set-top boxes, vending machines, pay-toilets, ...). Bittorrent, which is mentioned here as an example, is currently running on the firmware of some people's networked harddrives. Maybe on-chip implementations of Bitcoin will be made one day.

Being able to run Bitcoin in javascript (with an AJAX proxy) would be a significant advantage for the application I'm thinking about.

I think what would be needed is a very low-dependency reference implementation, which can easily be translated into other programming languages without introducing new bugs or incompatibilities. In time the protocol should be standardized and perhaps even go for recognition by standards bodies. That's the best way to guarantee long-term survival of the network. Every platform in the world that could be capable of using Bitcoin has at least a decent C compiler and the current de facto standard way to have a low-dependency reference implementation is to have C library which can be easily compiled on all major platforms without (or with absolute minimal) dependencies. The stock client should also use that C library.

Hi, I've tested your version and it works really well. With the stock version I get about 4500 khash/s and now I get 4900 khash/s, that's almost a 10% increase, which is really nice.

I'm also trying to build bitcoin myself to tweak performance a bit, but haven't gotten past the default debug build yet. It would be nice if you could share your compilation settings?