Definitely 1000 - then you can tell everybody else to go home, because you will be the only winner of the $2,500 BFL single.

I used a noun, not an adjective, as in Marcellus Wallace, not medieval, and removed the article to sound more hangulgooey. I only know bedroom Korean though.

Yep, enter early! It's like a 1-in-58,640,620 advantage for the first entrant vs the last entrant with 10,000 entries! (i.e., not significant; you reduce your odds of winning 10,000 times more than this by simply using someone else's referral when entering this contest; you increase your odds 10,000 times more by waiting, by having more information to determine optimal number of tickets to buy).

There is profit potential for either entrants or Matthew, I don't think a profit is guaranteed (unless this is a free evaluation unit that must be given away, etc); most raffles/auctions/lotteries that have been tried around here have few participants. This is one of the more significant; we know the organizer actually has the fabulous prize, the prize is rare, and the organizer has some reputation. It goes down in a week - if MNW flakes, we'll get 건달 on him...

It gets the same answer, I'll have to see how many hash digits will overflow JS and I'll host a page. Will send you thanks!

Anybody want to make a javascript page to do the ticket-picker math I specify above? I'll try it if no genius can whip one up in minutes, I'd like to make sure many/any method can arrive at same answer for winner.

Input 1: Last 10 of hash (10 digits hexidecimal)
Input 2: Number of entries (base10 decimal)
Input 3: Do ticket numbers start at 0? (yes = 0, no = 1)
Output 1: Input 1 % Input 2 + Input 3

Right?? I was ready to hit send and buy that 0.5BTC BFL single!

I just updated the post, the example result 141 was in hex, you must convert it back to decimal = 321. I do specify the first ticket is #0. Another oops with the calculator procedure is that you'd be entering the number of tickets in hex, which gives wrong results if you input decimal, I'll fix that too.

This method cannot be independently verified.

• There can be false unpaid entries (even with payment verified on blockchain, they can be paid in by the organizer to himself).
• The winning ticket selection method cannot be seen or verified by all outside parties.

I can at least solve the second part. The bitcoin blockchain contains lots of completely random hashes that are NSA-recommended as unreversible, not predetermined, outside control of any one party, and published publicly.

Here is my recommended method to declare winning ticket numbers of any forum lottery:

1. Publish block# to determine winner. For this lottery's timeline, block 171420 (~8 days from now) after 120 confirmations could be the one to determine the winner (block 170267 used in example below),
2. Disclose ticket numbers (spreadsheet) beforehand (start at 0, list forum IDs, etc), allow all entrants to see they are present in list and that there are no mystery entries nobody can account for.
3. Determine total number of tickets at entrance cutoff time (lets say 711 in this example),
4. The random data to be used from the block will be the last 10 digits of the hash,
5. The winning ticket number will be determined by the modulo (remainder) function [python = math.fmod(int("hash_last_10", 16), num_of_entries)]. Winning number as output by Win7 x32 calculator if any disputes of solution.

Here is how to independently determine the winner with no programming on Windows calculator (fixed):

• Verify the block hash from two independent sources (ideally one being your local blockchain),
• Open Windows Calculator. Select View->Programmer. Select "Hex" radio button,
• Paste last 10 digits of hash into calculator (73ef1acb71 in block 170267 in this example),
• Press "Dec" radio button to convert to decimal (497932749681)
• Press "Mod",
• Enter number of tickets (711)
• Press =
• (If the list of ticket numbers started at ticket #1 instead of ticket #0, add 1)
• See winner (example winning ticket number is #276)
  

Learned that phishers still can't spell:

Dear Comcast Customer,

Our team has detected anusual activity from your account, and it was put it on hold.

Must be because I was using my Anus laptop.

It sounds like you want this:
4.20mm Pitch Mini-Fit® BMI Plug Housing + crimp terminals

to this:

2.5mmID x 5.5mmOD, +12V center

Just a guess...I'm thinking you need ~80+ watts (10A spec), which will require all six pins of the 75 watt PCIe power connector.

Note: Pins 1 & 3 of PCIe power are 12V @ 8A max physical; note that in the PCI-SIG spec, Pin 2 is not connected, and pin5 is ground-sensing (i.e. required but minimal current TO a ground). Probably most power supplies are dumb and wire like the colors show, but you need to follow the specs making a cable or you will find the exception.

That's an interesting one I hadn't heard of before. I just had a SP2 system I put a 5830 in, but it didn't do anything with it until I installed every update and ran four different malware scanners on it.

deepceleron's law #6: The amount of beatings required to make someone forget something is much higher than the amount of beatings to make them remember it.

A strange phrasing for someone that registered today...

A rephrasing of the first post: "You might not recognize this new account I just made, but if you blindly send me bitcoins, I promise I'll email you a serial number ('legal', just ignore actual software license terms). Any offer is fine (this $700 software serial number doesn't mean much to me). I have a sad story too, with no information to back it up, I hear those motivate people to do things they normally wouldn't." Skepticism is logical.

I'll revise this post a bit upon reflection (really needs video to illustrate). There's another case I forgot:
Where 80% of all mining pools are ignoring blocks with zero transactions:

64% of the time:

[Normal block] ══╤══>[block by ignoring pool]══>[more blocks]
                 ┖┄>[no-transaction block]┄┄┄┄> orphaned

20% of the time

[Normal block] ══╤══>[no-transaction block]══>[block by normal pool]══>[more blocks]
                 ┖┄┄>[block by ignoring pool]┄┄> orphaned

16% of the time (or maybe 8%?)

[Normal block] ══╤══>[block by ignoring pool]══>[block by ignoring pool]┄┄> orphaned
                 ┖┄>[no-transaction block]══>[block by normal pool]══>[more blocks]

In the 16% case above, the "no transaction block" could have a higher difficulty hash, the normal pools would see this and still be hashing using the no-transaction block, and not be using the ignoring pool's block of lower difficulty - once one finds another block and publishes, they still win. By building on the blocks of an ignoring pool you might lose your block finding reward too... and it continues further than I can illustrate with text...

Even if 80% of the network agrees to ignore them, the "block ignorers" lose 20% of their mining income on those by making orphan blocks beaten by someone who isn't ignoring.

There always are transactions waiting. It would only be a threat if "bad miner" has more hashrate than everybody else and starts ignoring any blocks except the ones they mine themselves.

The problem is that pool operators can't reasonably ignore the no-transaction blocks. If they ignored them and continued looking for a block solve based on the previous block before it, some other pool that isn't ignoring them will build on them and grow a longer blockchain. Blocks without transactions are not "bad", look at the first year of Bitcoin mining. If these guys are ignoring transactions, that's also more transaction fees to be claimed by the rest who do include transactions.

I outlined possibilities why they might not be including transactions - including transactions requires a constant stream of network data from miner to control server. Not doing so reduces their hosting demands and reduces their exposure to detection if they are making unauthorized use of resources.

That can't be your GPU voltage, or it would be a smoky pile of smoke. Plus, see edited original post and above for new GPU MHz to benchmark at, so we can measure who's the best at tweaking their mining software.

New coins are generated at the same rate whether they get some of them or not; you knew that ~7200 new BTC were being made every day when you signed up (or didn't you read the terms and conditions?)

Yup, 195.234.103.99 (on Alpha Networks Austria) seems to be doing the same thing, not including any transactions, so it's the same operation or someone that liked the idea. They are finding a block every ~1.5 hours, which is some serious hashing.

That address and block is indeed deepbit, they don't pay any fees when sending, which means that miners may have to wait a long time to get their payouts. The payout address has a big balance of mature coins though (edit: correction - they are currently paying unconfirmed coins). The only pool including free transactions that break fee rules is Eligius.

Like you suggest, Eligius pays out by designating the 50BTC block-finding reward be split and paid directly to it's miners and not to their own wallet, which means they don't need a fee since they aren't re-sending coins, but the newly-minted coins need to mature 120 blocks before they can be spent.