|
In light of Team Liquid's CS:GO giveaway, I wanted to devise a way to ensure a fair drawing. This blog post explains the method I've come up with which is based on the drawing method of reddit's "Millionaire Makers" giveaway. Please let me know if there's any improvements to be made or if I missed something!
Data Recording:
Using the Twitter API, you can only get the latest 100 retweets. I wrote a script that polls the API every 30 seconds, fetching the latest 100 retweets and recording the date and user id.
Drawing Method:
The bitcoin network will be used as a source of randomness and timestamping. The merkle root of the first bitcoin block mined after the contest closes will be used as a source of randomness. The block timestamp must have a timestamp after the contest closing date to be considered valid.
A string will be created consisting of the numerical user_id of every entrant (including duplicates where multiple entries are allowed). The user_ids will be placed in ascending order and separated by a single space with no newlines. The SHA256 hash of this string will form the entrants hash, and can be used by an entrant to verify they were included in the drawing. The merkle root (m) and entrants hash (e) will be hashed together using SHA256 to create the drawing hash, in the format SHA256(m||e).
The first 8 bytes of the drawing hash will be converted to a little endian unsigned 64 bit integer. This integer modulus the number of entries will be calculated to come up with the winning entry number. The entry number is an index into a list of entrants sorted first by ascending entry date, then by ascending user id.
The winning account will be checked manually to ensure it is following the giveaway account and otherwise complies with contest rules. If the winning entry is deemed ineligible, the drawing hash is passed through another iteration of SHA256 and the process repeated until a valid winner is found.
Prior to releasing the winner, wait until the next bitcoin block is mined to ensure the block used in the drawing is not orphaned and thus is available publicly for provable fairness.
Fairness
A hash of the drawing method as described here can be embedded into the bitcoin blockchain, acting as a secure timestamp to ensure the method does not change. As the transactions and nonce used to find a block in the bitcoin blockchain are unpredictable, it is impossible to know the winner beforehand until the block is mined.
Issues
Since it is difficult to obtain a full list of retweets from Twitter, it is hard for a 3rd party to verify the index picked matches the list of entrants. This can be mitigated by releasing a full list of entrants after the drawing, allowing each entrant to check their presence in the giveaway. By mixing a hash of the entrants list into the drawing hash, this ensures that the list of entrants released matches those that were used for the drawing.
As only the latest 100 retweets are available from the API, it is possible that some retweets may be missed during high activity periods such as when the tweet is first published. This can be improved by using a high polling rate (every few seconds) for the first few minutes after the tweet is published.
 
|
awesome read, you must have had so much fun designing this drawing method
|
Default language on these forums is English 
+ Show Spoiler +But seriously, yer a wizard Rich! 
|
What is the reason you're using such a complicated way to generate a random number? Acting as a secure timestamp to ensure the method does not change... Why would this matter?
Math.Random(); instead?
In any case, it's fantastic that you've put some thought in to how to check who is actually a new follower. Every 30s is more often that necessary probably.
|
On March 20 2016 04:26 Thaniri wrote:
What is the reason you're using such a complicated way to generate a random number? Acting as a secure timestamp to ensure the method does not change... Why would this matter?
Math.Random(); instead?
In any case, it's fantastic that you've put some thought in to how to check who is actually a new follower. Every 30s is more often that necessary probably.
He wants to make it transparent so that everybody can check if the result was truly random and not secretly handpicked. It still seems unnecessarily complicated though. There is probably a better solution. But sometimes the solution isnt as important as the process of solving the problem.
|
|
|
France9034 Posts
Using the Twitter API, you can only get the latest 100 retweets
Oh, interesting. I wonder how many of these giveways actually go to one of the last 100 accounts that RT'd, 
|
I'm a software developer and I'm sitting here, like "lol wut a nerd"
|
Bearded Elder29902 Posts
|
I miss HOt_Bid. He would have come here saying stuff like : "Did you consider using the Huffman coding, compression algortyhm with your arithmetic SQL shmug" or something like that :p
|
Why not just take the number of participants as the seed to a pseudo random function? It's reproducible since the same seed will result in the same generated number and the outcome changes with every new participant, so you don't know the result at the start, but everyone can validate the result at the end.
Or take the unix timestamps of the last 5 participants, add them up and use those as seed?
Or the unix timestamp of the last minus the one of the first?
Ah, well, as long as you have fun, keep it up 
|
GRAND OLD AMERICA16375 Posts
Using the Twitter API, you can only get the latest 100 retweets. I wrote a script that polls the API every 30 seconds, fetching the latest 100 retweets and recording the date and user id.
I've done something similar with the Twitter API, wrote an app that creates and generates crowd sourced news based on your location and I'd have to say that there's a lot of forced limitations within the API that I dont really like :/ . It's no wonder the company is going under the tank as a result.
IMO, for the polling, it might be better to just poll all the retweets when you do the raffle itself; you already have the ability to get the history so you can get the oldest 100 RTs, then use that latest RT's id as your new since_id for your next poll as your starting index
|
A flaw in the system could be users making (lots of) fake accounts tot improve their winning chance.
|
We could add a check for the winning account to make sure it has tweets and followers and wasn't registered after the contest started. Dummy accounts on Twitter are quite obvious .
|
Decrementing the index on failure to following the rules could be abused. I could submit 1 legitimate entry, then have some script immediately submit 50 illegitimate entries. All of the illegitimate entries would lead to my legit entry winning if you follow the decrement scheme. This abuse would be pretty easily detected though... just a thought.
|
Good point. I suppose in the case of an invalid entry, a completely new random winner should be chosen instead.
|
What language did you write this in? Just curious.
|
I've done some proof of concept stuff in perl. I'm debating making it into a web service for people to use in giveaways.
|
2nd Worst City in CA8938 Posts
On March 20 2016 22:56 Ragnarork wrote:Oh, interesting. I wonder how many of these giveways actually go to one of the last 100 accounts that RT'd,
From my experience, Tweetdraw, which a lot of people use for these simple "Follow and RT" giveaways, isn't limited to the last 100 RTs. The last giveaway I ran which had thousands of retweets, the winner was someone who RT'd on the first day (the giveaway lasted for almost a week).
|
On March 21 2016 18:55 FFW_Rude wrote:
I miss HOt_Bid. He would have come here saying stuff like : "Did you consider using the Huffman coding, compression algortyhm with your arithmetic SQL shmug" or something like that :p
Haha I know. Or something like "r1ch have u tried modding ur bitcoin miner with an asic and several 7950s"
|
|
|
|
|
|
EPT
