Got my BFL Single today and I'm raffling it away for 0.5BTC!

[DeathAndTaxes]

$1028 for a $600 board (granted with delivery quickly instead of 4-6 weeks months).  Pretty nice.  Shows BFL Singles are underpriced relative to demand.

[deepceleron]

The current rate of exchange for raffle credits to tickets has been decided on as

0.1 credit = 1 tickets.

Wait wot? What does that mean for the guy with 1.05 credits, or the next guy with 1.25, or the guy with 1.3 credits who doesn't like the way you rounded up the other guy's credits. Hrm.

[DeathAndTaxes]

The current rate of exchange for raffle credits to tickets has been decided on as

0.1 credit = 1 tickets.

Wait wot? What does that mean for the guy with 1.05 credits, or the next guy with 1.25, or the guy with 1.3 credits who doesn't like the way you rounded up the other guy's credits. Hrm.

Also wouldn't the stupidly easy thing be to simply make it 0.01 credit = 1 ticket?  
No rounding, no issues, no unfairness.  
100 tickets per credit.
402.7 credits = 40,270 tickets

[notme]

$1028 for a $600 board (granted with delivery quickly instead of 4-6 weeks months).  Pretty nice.  Shows BFL Singles are underpriced relative to demand.

I'm not sure a raffle is an accurate price discovery mechanism.

[Matthew N. Wright]

What the FUCK.

Sorry guys, wasn't thinking. This is why I am posting everything I am doing to make sure this goes smoothly. It would obviously be 0.01 credit = 1 ticket. I was just looking at the 402.7 on my spreadsheet when I said that.

It will be obviously be 40,270 tickets.

[Epoch]

$1028 for a $600 board (granted with delivery quickly instead of 4-6 weeks months).  Pretty nice.  Shows BFL Singles are underpriced relative to demand.

Shows nothing of the kind. If this were an auction, then yes. But if this were an auction it wouldn't get anywhere near $1000. This is a raffle. Big difference.

[wogaut]

With all the back and forth, so what's the plan now for drawing a winner?

[Matthew N. Wright]

With all the back and forth, so what's the plan now for drawing a winner?

I'm waiting a response from deepceleron regarding his idea (since I have no idea what is involved with using the blockchain to tell a random number),

but I am also fine with just sending theymos the spreadsheet with all the emails SHA256 hashed with a salt (so that he doesn't know who is who) and using random.org to pick and certify the winner, then publishing the salt after the fact.

That however, is what the old me would do, and I enjoy learning new things especially when they involve more transparency.

[dab]

I thought he was referring to the block as the cutoff for entries. Not as a means of deciding the winner.

[Matthew N. Wright]

I thought he was referring to the block as the cutoff for entries. Not as a means of deciding the winner.

I think it was more about using it as a publicly verifiable random number, but I don't know what random number he would be getting from the block since I've never seen what a block looks like.

[dab]

Maybe block # % # of entries? (I as well have no idea what is contained inside a block so I'm just throwing ideas into the wind lol)

[Matthew N. Wright]

UPDATE: Talking to deepceleron about it right now. It's actually not that complicated, I'm just not familiar with the process.

[SaintFlow]

in other news: there is no such thing as a free lunch

[ohforf]

in other news: there is no such thing as a free lunch

The Members of the good old Salvation Army might prove otherwise. 
http://www.tampabay.com/news/humaninterest/salvation-army-begins-free-lunch-program-in-dade-city/1214986

[SgtSpike]

in other news: there is no such thing as a free lunch

The Members of the good old Salvation Army might prove otherwise. 
http://www.tampabay.com/news/humaninterest/salvation-army-begins-free-lunch-program-in-dade-city/1214986

Paid for by donations, not free.

[deepceleron]

Maybe block # % # of entries? (I as well have no idea what is contained inside a block so I'm just throwing ideas into the wind lol)

You are about right. The modulo (%) is what I proposed (page 3). I gave Matthew and others who may do raffles the tools so they could prove their raffle is being run fairly for anybody that may question how the winner is picked.

For some technical information:

Each bitcoin block has a SHA256(SHA256()) hash that is the main "block hash", a hash of the contents of the block (even more technically, a hash of the merkle tree of the transactions in the block). Like the SHA256 hashes of the emails you submitted to the raffle, hashing the transaction block turns readable data into unpredictable random-looking output (it is unpredictable by design; if you could predict it's output, you could break Bitcoin and crack hashed passwords easily). This is actually the puzzle that mining uses; since the output of SHA256 is unpredictable, it is very hard to find a hash that looks like something you specify. Bitcoin's mining challenge is to find a block hash that starts with many zeroes, the more zeroes we want at the beginning of a 256-bit hash (the smaller the value), the more difficult it becomes to find one.

This hash of a block is our random number picker. We specify a future block, so we know the fix is not in - we want to know that a lottery operator isn't picking the ticket number of a friend of his. Since it is so hard to even find a block hash (it's worth 50BTC), trying to manipulate the blockchain so a hash of a particular block is a particular number is nigh impossible. Since it is in the future, nobody without a time machine could have known the winner. Since the blockchain is published for all to use and see, we know that there is only one answer.

We could use the whole block hash, but that's a biiiig number and would break your calculator and programming environment, so it is not practical for everybody to use and independently verify. I proposed the last 10 digits as more reasonable - that is still a huge random number (in hexadecimal) with a value that will be between 0 and 1,099,511,627,775. I think one million million is a pretty big number.

For those that understand the modulo function, you see we must specify that the first raffle ticket number in our list is #0. We use the modulo function on the hash of a specific future block (that the organizer designates beforehand) to determine the winner:

(last-10-digits-of-block-hash) % (number-of-tickets) = winning ticket number

(I'll let you google modulo function if you don't know what that is.)

By all entrants seeing the list of ticket numbers beforehand, and being able to see how the winning ticket number is picked, it is hard to say that the winner was chosen unfairly. Scammers have to go back to simply not shipping the prize and disappearing. Someone like bitpay may fill this final need, by acting as an escrow agent for prizes for future raffles.

[cablepair]

Maybe block # % # of entries? (I as well have no idea what is contained inside a block so I'm just throwing ideas into the wind lol)

You are about right. The modulo (%) is what I proposed (page 3). I gave Matthew and others who may do raffles the tools so they could prove their raffle is being run fairly for anybody that may question how the winner is picked.

For some technical information:

Each bitcoin block has a SHA256(SHA256()) hash that is the main "block hash", a hash of the contents of the block (even more technically, a hash of the merkle tree of the transactions in the block). Like the SHA256 hashes of the emails you submitted to the raffle, hashing the transaction block turns readable data into unpredictable random-looking output (it is unpredictable by design; if you could predict it's output, you could break Bitcoin and crack hashed passwords easily). This is actually the puzzle that mining uses; since the output of SHA256 is unpredictable, it is very hard to find a hash that looks like something you specify. Bitcoin's mining challenge is to find a block hash that starts with many zeroes, the more zeroes we want at the beginning of a 256-bit hash (the smaller the value), the more difficult it becomes to find one.

This hash of a block is our random number picker. We specify a future block, so we know the fix is not in - we want to know that a lottery operator isn't picking the ticket number of a friend of his. Since it is so hard to even find a block hash (it's worth 50BTC), trying to manipulate the blockchain so a hash of a particular block is a particular number is nigh impossible. Since it is in the future, nobody without a time machine could have known the winner. Since the blockchain is published for all to use and see, we know that there is only one answer.

We could use the whole block hash, but that's a biiiig number and would break your calculator and programming environment, so it is not practical for everybody to use and independently verify. I proposed the last 10 digits as more reasonable - that is still a huge random number (in hexidecimal) with a value that will be between 0 and 1,099,511,627,776. I think one million million is a pretty big number.

For those that understand the modulo function, you see we must specify that the first raffle ticket number in our list is #0. We use the modulo function with hash of a future block that the organizer specifies to determine the winner:

(last-10-digits-of-block-hash) % (number-of-tickets) = winning ticket number

(I'll let you google modulo function if you don't know what that is.)

By all entrants seeing the list of ticket numbers beforehand, and being able to see how the winning ticket number is picked, it is hard to say that the winner was chosen unfairly. Scammers have to go back to simply not shipping the prize and disappearing. Someone like bitpay may fill this final need, by acting as an escrow agent for prizes for future raffles.

Excellent, I support this 100%

[Epoch]

For those that understand the modulo function, you see we must specify that the first raffle ticket number in our list is #0. We use the modulo function with hash of a future block that the organizer specifies to determine the winner:

(last-10-digits-of-block-hash) % (number-of-tickets) = winning ticket number

Excellent, I support this 100%

Agreed. This is a reasonable method.

[Glasswalker]

I also prefer this method.

So...

Where is the final list of hashed emails versus "tickets"?

And what block are we targeting for the "draw"?

I'm eager to win my BitForce! lol

[DeathAndTaxes]

Sounds like a good method.

For totally transparency just two things are needed.

A) A final list which should sha-256 email address, the # of tickets (and to avoid confusion the ticket # range).

Example:

hash                                           tickets      ticket #s    
jkfjhasdklfhdfjkhfdjkdhsafjkdhfadjk    120           0-119
fh89r7efuisey78a6s78sdtyfuidfjhh     200          120 - 319
...
fh89r7efuisey7fjsjs978sdtyfuidfjhh    100          40260 - 40359

B) and the block # which will be used and then we just need to wait for that block.  It should be far enough out to allow people to check the list for errors before the block arrives.