dab
Jr. Member
Offline
Activity: 42


March 16, 2012, 08:47:31 PM 

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.





Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.

Matthew N. Wright


March 16, 2012, 08:48:27 PM 

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
Legendary
Offline
Activity: 1750


March 16, 2012, 08:49:20 PM 

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


March 16, 2012, 08:50:03 PM 

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


March 16, 2012, 08:50:17 PM 

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


March 16, 2012, 08:51:45 PM 

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


March 16, 2012, 08:52:46 PM 

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. =COUNTIF(C2:C154; #)




Tomatocage
Legendary
Offline
Activity: 1526
brb keeping up with the Kardashians


March 16, 2012, 08:57:42 PM 

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




DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Gerald Davis


March 16, 2012, 08:59:27 PM 

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


March 16, 2012, 08:59:54 PM 

For his next feat, Matthew N. Wright will attempt to operate a lemonade stand...
Is a golden showers booth close enough?




dab
Jr. Member
Offline
Activity: 42


March 16, 2012, 09:05:48 PM 

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
Legendary
Online
Activity: 2156
Linux since 1997 RedHat 4


March 16, 2012, 09:08:44 PM 

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

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1 KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code Help keep Bitcoin secure by mining on pools with full block verification on all blocks  and NO empty blocks!



filharvey


March 16, 2012, 09:11:18 PM 

3 blocks left......

▄████▄ ▄████████▄ ▄████████████▄ ▄████████████████▄ ████████████████████ ▄█▄ ▄███▄ ▄███▄ ▄████████████████▀ ▄██████████ ▄▄▄▀█████▀▄▄▄▄▀█████▀▄▄▄ ▀██▄ ▄██▀ ▀██▄ ▄██▀ ▀██▄ ▄██▀ ██ ▄█████▄▀▀▀▄██████▄▀▀▀▄█████▄ ▀██▄ ▄██▀ ▀██▄ ▄██▀ ▀██▄ ▄██▀ ▄█▄ ▀██████████████▄ ████████████████████████████ ▀██▄ ▄██▀ ▀██▄ ▄██▀ ▀██▄ ▄██▀ ▀█▀ ██ ▀████████████████████████▀ ▀██▄ ▄██▀ ▀██▄ ▄██▀ ▄█▄ ▀██▄ ▄██▀ ██ ▀████████████████████▀ ▀███▀ ▀███▀ ▀█▀ ▀███▀ ▄███████████████████████████████████▀ ▀████████████████▀ ▀████████████▀ ▀████████▀ ▀████▀
 ║║ ║█ ║█ ║║  .
 .
║║ ██ ║║
 .
 .
║║ ██ ║║
 .
 ║║ █║ █║ ║║  



Matthew N. Wright


March 16, 2012, 09:18:44 PM 

UPDATE: I updated the spreadsheet to reflect the modified referralfinder 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


March 16, 2012, 09:20:03 PM 

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 prerecorded? 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.

Busy ATM.



Matthew N. Wright


March 16, 2012, 09:21:36 PM 

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 prerecorded? 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


March 16, 2012, 09:23:44 PM 

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

Busy ATM.



rjk


March 16, 2012, 09:24:12 PM 

Here guys, I heard you needed some tinfoil.




SgtSpike
Legendary
Offline
Activity: 1358


March 16, 2012, 09:24:56 PM 

UPDATE: I updated the spreadsheet to reflect the modified referralfinder 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 prerecorded 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
Donator
Sr. Member
Offline
Activity: 448


March 16, 2012, 09:25:20 PM 

So the total is now 40620 tickets then?




