There's some douche who's got 1000 cores crunching through hashes, so all of us are kind of left out to dry for now. =P

Ichi: Probably pretty fast, I saw a huge increase in performance to the tweaked version.  No tellin until you try it though.

It doesn't require a server.  You can just start the bitcoin client, and javascript can interface with it from JSON, AFAIK.

>_> It kind of defeats the purpose.  What advantage would it offer over building such functionality directly into the client (such as with the RPC and JSON interfaces)?

Oli: One alternative is to start the CUDA part hashing with a nonce of MAXINT and subtract one, and the host client start at one and go upwards.  Then, either one could find a hash and you're not repeating work.

No.  Go to http://www.random.org/integers/?mode=advanced

The random NUMBER generated BY the seed is between 1 and 100.  The seed is just kind of a "password" to make sure you always get the same random number.

Seed -> SHA256 -> hash I posted above.
  V
Random.org
  V
Answer you're trying to guess

Yup, that way I can reveal the seed at a later point, so you can see the winning number.  You'll also be able to verify that I didn't change the seed, because of the hash I posted above.  BUT, you can't cheat and find the result beforehand.

^.^ Woops, sorry, was just trying to defend a fellow bitcoiner.  And sure thing on the clarification.  It's a huge issue faced by any distributed system like this, ESPECIALLY if you're dealing with money/something of value.

Red: Noone said it was.  I mentioned uniquely identifying them by the hash of the first block they were produced in (granted that would be "unique" to 50 of them, but some kind of seed, or offset, or whatever would also work) and someone said that in general, uniquely identifying them would be a good idea.

Hm, never noticed it here.  But yea, a splash screen wouldn't be too bad an idea for those people who are experiencing that issue.

Red: It would still be a breaking change.  While it DOES provide versioning, clients only deal with others of the same version.  They don't automatically stop working or somehow learn to adapt to the new version when they see a client of another version.  Because of this, the old clients would continue on as usual, advancing the block chain.  The new clients, (0.4 for simplicity) would start rejecting the old (0.3.2).  Thus, you'd have a "0.4" blockchain, and a "0.3.2" blockchain that were exactly the same up until 0.4 was released, at which point they would diverge.  Transactions would only occur between clients of the same version, and when people finally switched over to 0.4, this new block wouldn't have the transactions from 0.3.2.  It can be done if absolutely necessary, and we'll just have to warn people that old transactions will be invalid, despite showing up as valid on the old clients.  Thus, we should avoid a breaking-change at all costs.

If, however, the sheet referenced the block chain instead, this information would be "extra", and thus safely ignored by older clients.  The block chain would still be valid when generated on older clients.

Another route to go would be to implement it this way, and then add it to the "todo list" for our first breaking change.  We then keep a list of things that would be breaking that we want to do until it gets sufficiently large/advantageous to risk the bifurcating block chain, and do it all in one version update.  This would still be a breaking change, but it would allow us to mitigate the negative effects.

:-S I always see the screen as SOON as I start it, and THEN it does all the disk i/o, connecting, etc stuff.

It's not a completely connected network in the sense that every client isn't connected to every other client.  If by completely connected you mean there's x degrees of separation between everyone, then yes, that's how it is.  Data gets "spread" throughout the network as time goes on, not instantaneously (though it is pretty fast).

This was mostly a thought experiment for satoshi, as I understand it.  If the userbase continues to grow substantially, then obviously a great amount of work will go into optimizing and revising the algorithm to support more advanced and intelligent distribution.

The unsalted hash of the seed for the solution (as per random.org) is given.

*nods* It wouldn't be a reliable way to operate the underlying system, as coins are split and merged in blocks, 50 are generated at once, etc, but it'd be a nice way to provide a bit of verification and safety to the balance sheets.

*shrug* I can hash it a second time, but it's not going to increase or decrease security.  I typed out a random alphanumeric seed anywhere between 1 and 64 characters long, so they'd have to bruteforce an ungodly number of options.  Hashing it a second time won't change that.

Well, I'm running a "fake" one right now.  http://bitcointalk.org/index.php?topic=534.0

Also, the chance of them brute forcing a 64 digit alphanumeric seed which I hashed with SHA-256 is very low.

This is a test run to show everyone how it works, and illustrate the benefit over a regular lotto.

This is not a real lottery.  No money required to play.  Please play so that I can judge how things would have gone.

Here's how it works:

1) I've chosen a random seed to be entered here:

http://www.random.org/integers/?mode=advanced

under the "pregenerated seed".  It's between 1 and 100 (inclusive).
The SHA-256 hash of the seed is: 627c22822c1dee884411b8f3a09b8545616bcf9837f080a6df26704f604b6d0d

2) You pay 1 "fakecoin" to enter, and PM me your guess.  1 guess per fakecoin.  I add this to the pot.

If you guessed correctly, you get 80% of the "fakecoins", 1% will go to me, and 19% will go into the next pot.  Otherwise, I post your guess on the "Failed guess" section and update the jackpot.

Current Jackpot: 34 fakecoins
Chances to win: 1/71
Failed Items:

• 1
• 2
• 3
• 5
• 7
• 11
• 13
• 14
• 17
• 19
• 22
• 33
• 41
• 44
• 50
• 55
• 66
• 77
• 88
• 91
• 92
• 93
• 94
• 95
• 96
• 97
• 98
• 99
• 100

Nice idea!  I love bump!

You'd make more than one dollar because of the transaction fees.  That's the whole point.  If it got to that point, then everyone would stop generating blocks, as it would be unprofitable, and the system would collapse.