Re: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread
yes the prize amounts cannot be the same as powerball since it is unrealistic to use fixed pay outs unless this is being done by a large entity who already has the funds. the payout as i mentioned above should ensure that at least 33% of the tickets get something. does it do that?
You're going to need a big bankroll regardless, if you want to run any sort of lottery. That's because, by definition, if you're working with fixed probabilities there's no guarantee reality will follow exactly the expected distribution. What if only one person enters, and they win a prize? (The situation is different with a raffle, where the probabilities and payouts change together.) Real lotteries solve this problem by buying insurance and things like that.
I originally followed the probabilities of the real Powerball for payouts, which means that you have about a 1/35 chance of winning a prize. I just pushed a change giving the ability to payout on fewer matched numbers, so that you can bring that number down if you like. If you give a small payout for even a single match, my back of the envelope calculations say people should have about a 50% chance of winning.
cool thanks!
Hopefully one of the dev's can check your code soon, so you can get the award. I'll keep bugging them but I guess it is the weekend.
No worries! Thanks for setting this all up!
I should say, if there's anything you don't like about the way I interpreted the spec, let me know. I'm happy to make any tweaks that are necessary. I want everyone on both sides to feel good about how this went.
ok thanks
i am going to sleep now, it took me way longer than i thought to drive on a1a from miami beach.
i'll bug people tomorrow about checking the code
worst case i will try to see how to run it myself on the test net - i guess i might as well try since this (ethereum contracts) is a major new feature of XCP
so here is the review of you code, there are a couple issues that need to get resolved.
https://gist.github.com/jorisbontje/353f69515a16cef7de7b
a snippet from the conclusion:
Code:
Then intend of the code is good, but in the implementation I have identified a couple flaws:
As stated under 6, the redemption deadline isn't fully implemented. This is problematic as it conflicts with the administrator being able to withdraw funds after the deadline.
Winning numbers can be redrawn multiple times after the lottery deadline, potentially overriding previous drawings. https://github.com/PeterBorah/ethereum-powerball/blob/master/contracts/lotto.se#L62-L81 As this can be triggered by anyone this is a serious concern. Suggested is to 'freeze' the lottery after the lottery deadline until the redemption deadline has expired as well.
Relying on block.prevhash is a security risk as this can be abused by miners / mining pools using a block withholding attack. If this is a real threat depends on the payout amount of the lotto. Since the RNG is configurable, I'd consider this to be currently good enough for the bounty.
Minor feedback for improvement:
use def init for automatic initialization upon contract creation
specify explicitly in requirements.txt which pyethereum / ethereum-serpent library are supported
create user interface ;)
As stated under 6, the redemption deadline isn't fully implemented. This is problematic as it conflicts with the administrator being able to withdraw funds after the deadline.
Winning numbers can be redrawn multiple times after the lottery deadline, potentially overriding previous drawings. https://github.com/PeterBorah/ethereum-powerball/blob/master/contracts/lotto.se#L62-L81 As this can be triggered by anyone this is a serious concern. Suggested is to 'freeze' the lottery after the lottery deadline until the redemption deadline has expired as well.
Relying on block.prevhash is a security risk as this can be abused by miners / mining pools using a block withholding attack. If this is a real threat depends on the payout amount of the lotto. Since the RNG is configurable, I'd consider this to be currently good enough for the bounty.
Minor feedback for improvement:
use def init for automatic initialization upon contract creation
specify explicitly in requirements.txt which pyethereum / ethereum-serpent library are supported
create user interface ;)