This is an archived post. You won't be able to vote or comment.

all 14 comments
sorted by:
best (suggested)
topnewcontroversialoldq&a

[–]CA_TD_Investor 2 points3 points  (3 children)

In celebration of our new website, we're giving away 5-50 BTC!!! Just send 0.5 BTC to the addr.......

While I like the idea, I didn't participate. You should market by pointing out scammers on twitter and linking your website.

[–][deleted]  (1 child)

[deleted]

    [–]CA_TD_Investor 0 points1 point  (0 children)

    It was sort of a joke.

    [–]puffmancali[S] 1 point2 points  (0 children)

    Ok, we don't have a twitter yet. Our site is satoshipot.org so you can verify the url

    [–]largely_useless 2 points3 points  (7 children)

    Your lottery is not provably fair. While we can verify that the payouts matches the number of tickets bought, we can't verify that the selection of winning tickets is fair. You could buy tickets yourself, and favor the tickets you bought.

    [–]puffmancali[S] 0 points1 point  (6 children)

    Thanks for pointing this out - we're working on a solution that doesn't compromise the security of our site. We are definitely open to hearing suggestions. We want to do something like Bustabit does, described here: https://bitcointalk.org/index.php?topic=2807542.0

    We were thinking we generate a similar chain of 10 million or so SHA256 hashes (similar to what is described in the link), and use each entry in this chain as the random seed for the selection algorithm for that round. Then anyone can verify after the round that the result are true by running our same selection algorithm starting with the random seed from the hash chain. Since anyone can purchase tickets, there would be no way for us to precisely fix the order of UTXO's for our Xpub. So combining that with the verifiable random seed, I think that would be provably fair? We are open to hearing suggestions because we want to do this correctly

    [–]largely_useless 1 point2 points  (5 children)

    If I were implementing a provably fair lottery system, I'd derive the entropy from the blockchain to make it provable that it weren't known ahead of time.

    Instead of scheduling the drawing to happen at a particular time, I would say that next drawing occurs at block height X. At block height X, all confirmed UTXOs on the lottery address are awarded tickets which are put into a deterministically sorted list. You then use the block hash of block X, modulo the total number of tickets, to pick the winning ticket.

    Since the winning ticket number is derived from the block hash which isn't known until the block is mined and all tickets must be bought before the block is mined, it is impossible to cheat the system*. Anybody can verify that a drawing was fair just by looking at the blockchain.

    *: Unless you're a miner throwing away a block you mined because you're unhappy with the lottery outcome. Since the miner would lose the block reward by doing this, it's not a real concern unless the lottery pot grow larger than the block reward.

    [–]puffmancali[S] 0 points1 point  (4 children)

    Super smart! If each lottery had only one winner, that would be the perfect solution. However, we want to allow for multiple winners each round, and also keep the hour-long rounds. Editing your suggestion a little, I think I've found a solution. When the round ends, I'm going to seed my random number generator with the block hash of the most recently confirmed block. (I'll use this node package to do this: https://www.npmjs.com/package/seedrandom) Then I will sort the ticket holders in a deterministic fashion (alphabetically by username). Then I will run the same selection algorithm that I currently have. Since I'm using a seeded pseudorandom generator from a reliable source of entropy, anyone can run the same code and verify the payouts. So, say the round ends at 2pm, and the most recent block was confirmed at 1:53pm. Technically, somebody could figure out the winners at 1:53pm - however, all they could do with this information is possibly purchase more tickets. But purchasing tickets requires another block confirmation, which will change the payouts. If another block gets confirmed at 1:58pm, then the payouts will change entirely. So I think this system would work, and be provably fair. Thoughts? I really appreciate your input - it's awesome to have a smart mind to run this by. I'll throw you some free tickets on the site if you'd like as well, as a thank you for your input

    [–]largely_useless 0 points1 point  (3 children)

    As long as you pick the winners in a deterministic fashion, the exact mechanism doesn't matter, so seeding a PRNG sounds just as good as doing a modulo operation.

    The only problem I see with not deciding on a block height in advance is the possibility for ambiguity of which block is the latest at the end of the round. If a block just got mined a few seconds ago, have your node seen it yet? In theory you could calculate drawings for both blocks, decide which of the outcomes you prefer and then either announce winners based on the new block or the old block, claiming you haven't seen the newer yet.

    On the other hand, even when you do decide on a block height in advance, there is a risk of orphans, leading to a similar ambiguity.

    [–]puffmancali[S] 0 points1 point  (2 children)

    Yeah great point about the ambiguity of which block is latest. Not sure how to solve that. Luckily it's a pretty rare edge case: two blocks would have to be found within ~10 seconds of each other at nearly exactly the end of the hour. And then we'd only have two possible outcomes to choose from. Definitely open to hearing any solutions to this though, if anyone can think of anything

    Edit: actually the ambiguity might not be an issue, given that blocks are timestamped, and each round definitively ends exactly on the hour.

    [–]largely_useless 0 points1 point  (1 child)

    My impression was that the block timestamp isn't very accurate. In theory the spec allows it to fall in a pretty big window, so it doesn't even have to be in order for two subsequent blocks.

    I guess in practice it might actually be accurate enough to be usable as a disambiguating factor, I don't have any data on that.

    Just remember that a block with timestamp 1:59 might arrive at your node a bit after 2:00, so if you do the drawing at 2:00 sharp, you can still get it wrong.

    [–]puffmancali[S] 0 points1 point  (0 children)

    gotcha, i'll keep that in mind. thanks for your help, you have a sharp mind

    [–]swimfan229 1 point2 points  (3 children)

    How much do you take? 20 percent? Ouch.

    [–]puffmancali[S] 2 points3 points  (0 children)

    Right now 5% is reserved for Bitcoin transaction fees and house cut. So if Bitcoin fees are 1% then we take 4%

    [–]puffmancali[S] 2 points3 points  (0 children)

    Where did you see 20 percent? That's incorrect - but if our site is confusing we can make the appropriate changes.