Alright, I guess I'll connect the dots for you. Although, I have to say, the site's pretty clear as far as what the hash does, and the previous round is there for you already, but whatever.
Thank you. Perhaps I'm slow?
I was just curious if your method prevented you from knowing the winner or being able to manipulate it.
Does random.org hide what the string actually is until certain date or do you know the string for who wins the whole time?
Are the numbers used for the order based off of blockexplorer for when they paid? Would 0 be the first ticket and 5 the 6th ticket?
No problem, I'm sure the truth-verification system is confusing for most first-timers. The string/winning numbers are hidden from me and set at the start of the round, so there's no way to manipulate the system. I can change the source code to display the winners if I need to, but the display in my terminal is minimized anyway since there's so much output data, so all of the number-display functionality that was present in dev has been stripped out. I have no competitive edge, even if I was ethically unopposed to participating in RaffleBit(service op shouldn't stand to gain beyond what's disclosed to customers).
In programming terms, yeah...0 is the first ticket, and 5 the 6th. The numbers of the tickets are based on the order in which they appeared in the blockchain, but not based on blockexplorer.
This is what I'm talking about, as far as verbose output, and the priority for space over seeing winning numbers. It also demo's what my actual interaction with the backend of RaffleBit looks like. <h1>Address to play:<h1><h2> 1Ga7XzikxLKP9uLEUTpkkiBA9PzTZ2qmEK</h2>
Tickets total/sold: 158 / 17
<h2>1.649BTC contributed to 15.326BTC total jackpot<br>10.76% of all tickets purchased</h2>
iterations to make: 17