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

[dab]

I say we boil water and count the number of Steam molecules that evaporate within a 30 second window, determined from when a penny is dropped from the top of a Sky scraper and hits the ground.

[1714178483]

1714178483

[1714178483]

1714178483

[1714178483]

1714178483

[Matthew N. Wright]

I say we boil water and count the number of Steam molecules that evaporate within a 30 second window, determined from when a penny is dropped from the top of a Sky scraper and hits the ground.

I've got the penny, you get the molecules.

[notme]

My hash appears in the referrer column 3 times, but the row with it in the purchaser column has 0 in the referrals column, and I only have 1 ticket credit.

Row is 152, hash is 3c7c2cc979c12fc5074efe3a15f852b40f837437d12653b1ffc71f35dd7697f3

[cablepair]

we would not be Bitcoin enthusiasts if we did not over intellectualize everything


now here is my vote on how we settle this and pick our winner :

[Matthew N. Wright]

My hash appears in the referrer column 3 times, but the row with it in the purchaser column has 0 in the referrals column, and I only have 1 ticket.

Row is 152, hash is 3c7c2cc979c12fc5074efe3a15f852b40f837437d12653b1ffc71f35dd7697f3

Checking.,

[FreshJR]

Your call Matt.  I only have 2 tickets so I don't really care.  It would be useful excercise in using the block chain to ensure no ability to cheat.   Random.Org is only random if you actually make it random not pick a buddy as the winner.  Not saying you would but using the blockchain as a double blind picking method reduces the need for implicit trust.

I totally agree. I want to learn this, but it still doesn't make sense to me completely, and that bothers me since I'm usually a fast mover on things. When the block comes around can you show me hands on what has to happen again?

Matt, the modulo (%) operator returns a remainder.

7 % 5 returns 2

So (hash) modulo (ticket #) will return a a random ticket number.

The hash looks like a complicated jargon of words but that is because it is represented in a different number format (Humans use base10 since we have 10 fingers, Computers use base 2 since switches can be on or off, hexadecimal is base16)

Base 2 - 0 1
Base 10 - 0 1 2 3 4 5 6 7 8 9
Base 16 - 0 1 2 3 4 5 6 7 8 9 A B C D E F

The last part of the hexadecimal hash can be converted into a decimal number (base 10), and the modulo operator can be used to choose the winner.

Since the hash is random and unpredictable, this will be the best way to choose a winner that can be independently verified.

The reverse bias has an extremely low chance of happening, and we can either accept it, or use the next block.  Your call.

I favor this method a lot more since it can be verified by anyone.  It is worth the wait

Now what some people were worried about was this.

*If the hash decimal equivalent is too large, then the last repeating remainder would not include all the tickets.  This would give earlier tickets just the slightest advantage.  This phenomenon happens since the max ticket number does not divide into the hash evenly.  The chances of this are extremely low, and the bias can even be ignored.

I can explain this more if you would like.  But it has been covered already by other posters.  

Just post here if you want me to re sum everything up in a single place.  Its not really complicated at all.

[Matthew N. Wright]

My hash appears in the referrer column 3 times, but the row with it in the purchaser column has 0 in the referrals column, and I only have 1 ticket credit.

Row is 152, hash is 3c7c2cc979c12fc5074efe3a15f852b40f837437d12653b1ffc71f35dd7697f3

Goddamnit. OpenOffice calc moved my calculation references when I pasted them. One moment.


EDIT: What happened is that the COUNTIF statement was counting starting the row of the referencing record, instead of starting at the top. To put it plainly, it was only checking rows below the current row instead of starting at the top of the page as it should have. I'm modifying each row in the B column manually to make sure this is done right.

Code:

=COUNTIF(C2:C154; #)

[Tomatocage]

For his next feat, Matthew N. Wright will attempt to operate a lemonade stand...

[DeathAndTaxes]

For his next feat, Matthew N. Wright will attempt to operate a lemonade stand...

A cryptographically secure, transparent, and verifiable one (with escrow coming in 2013).

[Matthew N. Wright]

For his next feat, Matthew N. Wright will attempt to operate a lemonade stand...

Is a golden showers booth close enough?

[dab]

For his next feat, Matthew N. Wright will attempt to operate a lemonade stand...

Is a golden showers booth close enough?

That'll do pig. That'll do.

[kano]

Your call Matt.  I only have 2 tickets so I don't really care.  It would be useful excercise in using the block chain to ensure no ability to cheat.   Random.Org is only random if you actually make it random not pick a buddy as the winner.  Not saying you would but using the blockchain as a double blind picking method reduces the need for implicit trust.

I totally agree. I want to learn this, but it still doesn't make sense to me completely, and that bothers me since I'm usually a fast mover on things. When the block comes around can you show me hands on what has to happen again?

Matt, the modulo (%) operator returns a remainder.

7 % 5 returns 2

So (hash) modulo (ticket #) will return a a random ticket number.

The hash looks like a complicated jargon of words but that is because it is represented in a different number form (Humans use base10 since we have 10 fingers, Computers use base 2 since switches can be on or off, hexadecimal is base16)

The last part of the hexadecimal hash can be converted into a decimal number (base 10), and the modulo operator can be used to choose the winner.

Since the hash is random and unpredictable, this will be the best way to choose a winner that can be independently verified.

The reverse bias has an extremely low chance of happening, and we can either accept it, or use the next block.  Your call.

I favor this method a lot more since it can be verified by anyone.  It is worth the wait

Now what some people were worried about was this.

*If the hash decimal equivalent is too large, then the last repeating remainder would not include all the tickets.  This would give earlier tickets just the slightest advantage.  This phenomenon happens since the max ticket number does not divide into the hash evenly.  The chances of this are extremely low, and the bias can even be ignored.

I can explain this more if you would like.  But it has been covered already by other posters. 

Just post here if you want me to re sum everything up in a single place.  Its not really complicated at all.

Yeah, again, go back to page 6

[filharvey]

3 blocks left......

[Matthew N. Wright]

UPDATE: I updated the spreadsheet to reflect the modified referral-finder code.

Note that only the referrals were having an issue. All other data is still already verified.

The updated total referrals count went from 30 to 44, so that means that my error was cheating people on the lower half of the spreadsheet out of 14 referrals.

Since I feel awful about this, I am going to give 100 free tickets to everyone*


(*This is a joke considering it wouldn't change your odds at all.)

[Blazr]

Oh and I know many people who use random.org and just stream the pick on ustream or justin tv.

Problem is, how would we know that the stream wasn't pre-recorded?

Also, how would we know that the person wasn't using a greasemonkey script to change the number on the random.org website?

I'm going to go put my tinfoil hat back on.

[Matthew N. Wright]

Oh and I know many people who use random.org and just stream the pick on ustream or justin tv.

Problem is, how would we know that the stream wasn't pre-recorded?

Also, how would we know that the person wasn't using a greasemonkey script to change the number on the random.org website?

I'm going to go put my tinfoil hat back on.

Don't bother. That is not a tinfoily thing to say. It's exactly what I would do if I were going to falsify the results. That is why I agree that the blockchain is a good direction for the future as well.

[Blazr]

Since I feel awful about this, I am going to give 100 free tickets to everyone*

(*This is a joke considering it wouldn't change your odds at all.)

Actually, that would change the odds. Pretend there is only 2 people in the raffle, I have 50 tickets, other person has 100 tickets. My odds of winning are 3:1.

You give us both 100 tickets each. I now have 150 tickets and other person has 200 tickets. My odds of winning are now 2.33:1

[rjk]

Here guys, I heard you needed some tinfoil.

[SgtSpike]

UPDATE: I updated the spreadsheet to reflect the modified referral-finder code.

Note that only the referrals were having an issue. All other data is still already verified.

The updated total referrals count went from 30 to 44, so that means that my error was cheating people on the lower half of the spreadsheet out of 14 referrals.

Since I feel awful about this, I am going to give 100 free tickets to everyone*


(*This is a joke considering it wouldn't change your odds at all.)

Ermm... giving 100 free tickets WOULD change your odds.
If I have 75/100 tickets, and another person has 25/100 tickets, then my odds of winning are 75%, and his are 25%.  Now you give both of us an extra 100 tickets.  I now have 175/300 tickets, and he has 125/300 tickets.  My new odds of winning are 58.3%, and his new odds of winning are 41.7%.

Just sayin.  

Also, Blazr, good point about using a pre-recorded stream.  I hadn't thought of that.  Maybe also showing some live chat at the same time would suffice, but then it is getting complicated.

EDIT:  WTF, totally ninja'd by Blazr.  >.<

[wogaut]

So the total is now 40620 tickets then?