I find it distracting to see the # confirmations for each transaction. Do I really need to know that there are 20,132 confirmations to a transaction? And, oh look, it just went up to 20,133. Anything beyond a few dozen is overkill IMO. I propose that beyond a certain number, say 100, we just display it as confirmed.

Even more useful would be to display the date by old transactions. That would help me remember what they were.

The danger is if people are buying bitcoins in the expectation that the price will go up, and the resulting increased demand is what is driving the price up. That is the definition of a BUBBLE, and as we all know, bubbles burst.

Did you build this yourself from source?

The "old-school cypherpunk" is Perry Metzger, who is (still) the moderator of the Cryptography mailing list, where Satoshi first announced Bitcoin.

Would it work, on a new machine with no wallet, to create the .bitcoin directory, with wallet.dat a symlink to an empty file on your 5MB volume? Then when you launch the client for the first time, would it create the wallet on the encrypted volume? Or would it just overwrite the symlink file with wallet data?

It's pretty strange really that we all see a good chance that bitcoins will hit a dollar in the relatively near future. How many investments can be expected to triple in value in that time frame? Is gold going to be $3500 any time soon? Apple stock going to triple? Maybe Facebook, if you could get some. That seems like a pretty sure thing.

We are really lucky to be in at the beginning of a possibly explosive new phenomenon. Considering the odds against most money-tripling investments, Bitcoin looks like a good place for a percentage of your portfolio.

If the private keys in the wallet were encrypted, then the virus couldn't get them until you entered your password to make a payment. This might give you a chance to discover and eliminate the virus before it can do harm.

Maybe try putting

return false;

as the first line of Detect128BitSSE2(), see if that fixes it. If so, and you're really energetic, move the return down to just before, then just after the memcpy, to confirm that's where the problem is.

How much for an ounce of unobtanium?

Bitcoin uses elliptic curve cryptography for its keys and signatures, but the specific curve used is pretty unusual. It is called secp256k1, from a standard called SEC2, published by a group called SECG, http://www.secg.org/index.php?action=secg,docs_secg.

Taking the name secp256k1 apart, sec comes from the standard, p means that the curve coordinates are a prime field, 256 means the prime is 256 bits long, k means it is a variant on a so-called Koblitz curve, and 1 means it is the first (and only) curve of that type in the standard. This is all fine and common, except for the Koblitz part. Koblitz curves are a special kind of elliptic curves that have some internal structure that can be used to speed up calculations. Standards bodies have tended to shy away from Koblitz curves out of fear that this internal structure could someday be exploited to yield a new attack. Indeed certain Koblitz curves, but not secp256k1, lose a couple dozen bits of security to a known attack.

Most standards use what are called random curves when they are using prime fields. SEC2 also includes random curves, and the very next one after secp256k1 is called secp256r1. This curve, secp256r1, is widely standardized and used, including by the U.S. government, which calls it P-256.

I don't know the rationale behind using secp256k1. It has the potential for speed - I've seen estimates from 33% to 50% speedup - but the techniques are quite esoteric as it is not a conventional Koblitz curve, and I doubt that the OpenSSL implementation exploits this. I'm not losing much sleep over the theoretical possibility of an attack on secp256k1, but it is likely to be less widely implemented. I looked at BouncyCastle, a widely used Java crypto library, and they had commented out the code for secp256k1. Whereas secp256r1 (P-256) might well be a default curve for the native crypto keys in future OS's.

It wouldn't be a change to make lightly, but we might want to consider changing to this more widely used standard curve. We'd have to mark the new keys to distinguish them, and be prepared to handle both kinds of signatures.

One question is whether we would ever reach a point where clients could eliminate support for the old curve? Maybe just miners could retain support, and the fact that a transaction got into a block with some confirmations would be good enough evidence that it was valid.

Why would it ever stop mining for coins?

Interestingly, the dollar sign originated with two vertical bars rather than one, according to several theories.

http://en.wikipedia.org/wiki/Dollar_sign
http://en.wikipedia.org/wiki/Cifrão

Also, supposedly Unicode allows the character to be rendered either with one line or two, entirely depending on the taste of the font designer.

Let me unpack this idea into parts.

1. Sharing your compute power in a massively parallel effort that has some value.

2. Doing this specifically with GPU.

3. Getting paid for it.

4. Getting paid specifically with bitcoins.

#1 is widely done, eg Folding@Home to improve biological models. There are a ton of these. For #2, I imagine that some do use GPUs, as people are very competitive. #3 is hard. If you're getting paid, someone is paying, so we are mostly looking at commercial applications. But these tend to be sensitive or secret, not suitable for wide sharing. For example, an obvious application would be rendering graphics for a new movie. But the producers wouldn't want their scenes to be leaked.

To solve these problems and then focus only on people who want to receive bitcoins would be doubly difficult.

According to Gavin's https://github.com/gavinandresen/bitcointools/blob/master/NOTES.txt, serialization of any vector object gets preceded by a count of the number of elements in the vector, in the variable-length 1/3/5/9 byte format. I added this count field to the new wiki, e.g. to addr messages. Also, block messages contain a vector of their transactions, so that part is also preceded by a variable-length count.

In addition to documenting the on-the-wire protocol, I think we should document the rules a peer should follow. Some rules are for behaving cooperatively, such as participating in the flood-based broadcasting. Others are for using the network safely, how and when to validate incoming blocks and other data. I think you have some of this in the original wiki page RHorning, but I'm not sure it has all propagated to the new wiki.

The creation of the site was described here: http://bitcointalk.org/index.php?topic=854.0;all

As long as OpenSSL outputs keys in this format, it will work. I doubt they'd change it due to compatibility.

That's very generous, but I don't feel right taking the bounty for 5 minute's work. I'll send back the 50. Is that address in the top post yours?

btc=1Hy9dexzNzjvQYkYy6zKRVZMU8k2j5vuPt

Try doing tail -c 65 after the base64 -d. Your pubkey has ASN.1 cruft.

According to https://en.bitcoin.it/wiki/Mining_Hardware_Comparison, the 5770 draws about 100W and generates 150 Mhash/s. According to http://www.alloscomp.com/bitcoin/calculator.php, this should generate a block every 5 days. 5 days is 120 hours, times 100W is 12 kWh. Around here it's $0.20 per kWh, so that's about $2.50 per block for electricity. A block of 50 bitcoins is worth about $15 now, less $2.50 is $12.50 profit. The $99 card will be paid off after 8 blocks, so that's about 40 days at current difficulty. After that it's pure profit.

Most people assume difficulty will continue to rise, but I think it will level off soon, because except for unusual deals like this one, GPU mining is close to becoming unprofitable.