Yeah, I can add that. I'm not sure how the probabilities will work out, but it shouldn't be too much of a problem from a technical perspective. I was going to try to make it more modular anyway, so maybe I'll let people plug in their own payout system. (I should probably say that I reserve the right to stop working on this at some point, if it gets to be more work than I signed up for. But for now I'm happy to keeping improving the code, especially since working on my Ethereum scripting skills is something I'd be doing anyway.)



Since I don't know how the XCP version works, I can't help you with too many specifics. But think about how transactions work: someone initiates them, but eventually they spread throughout the network. You can point to a specific transaction based on its id, and anyone on the network can see what the transaction was based on their own copy of the blockchain. Contracts are kinda like that. They live "on the blockchain", and anyone can interact with them the same way anyone can send a transaction to any address.

It should be fairly easy to modify the code to work that way. However, I strongly recommend against it. That would make the game completely undesirable to play.

Think about it this way: Your chance of getting a jackpot is 1 in 175,223,510. That's true no matter who else plays, or how much the prize is. Because of that, there's only one value that's a "fair" payout for a jackpot: 175,223,510 times the cost of a ticket, minus the house's cut.

You're never, ever going to sell 175,223,510 tickets for your lottery, at least not until you're as big as real Powerball. Because of that, you simply won't bring in enough money in tickets to make the jackpot attractive. Imagine the first person to buy a ticket: they'll have a 1:175,223,510 chance of hitting the jackpot, and their expected payout if they do will be half the cost of the ticket they just bought...

Luckily, your chances of having to pay out are equally low, so if you set the payouts correctly and buy insurance/have the money lent to you/whatever you can expect a profitable return on average over time.


Each contract can only run one lotto at a time, as currently set up. If you had a system with lots of lottos running simultaneously, you'd probably want to maintain a list of lotto contracts, maybe with some sort of way of automatically registering and displaying them. They'll have a static address, so you can always "find" it once you know where to look for it.

Received contributions of 10, 5, and 2 XCP. Thanks ianspain, dante, and (presumably) niceplum!

I got Joris to send me his XCP address and add it to the gist. I've just sent him 22.4 XCP, which is 20% of the expected 112 (including dante's contribution).

More importantly, I've pushed a fix to a bug we missed. Until the fix, you were able to create tickets with repeated numbers, which would have much better odds than normal tickets.

I'm a broken record on this, but thanks to everyone who participated! It's pretty thrilling to be able to make a little money by working with random strangers who want to push this technology forward.

I can confirm I got the 50 XCP, plus two separate 10 XCP transactions. Thanks, prophetx, ivana, and mysterious third person!

I'll bug Joris for his address and forward him 20% of whatever I end up receiving.

Here you go: 1LeygZteCpjBstARoyt3uHgPhV8aJHsBAg

Again, thank you so much for setting this up! I think this is the first cryptocurrency I've actually earned, rather than buying.


I was definitely planning to pass some of the bounty to the code reviewer. As I said, it was a very good and thorough review. Does 20% seem fair to everyone?

Let me know if you have any other smart contract work you need done. And I'm still planning on trying out some code improvements over the next few days. I'll be happy to help debug if you run into any issues with your testing.

Update: I've made some quick fixes for the two issues identified as blockers. I've added test cases for both, and they're both pushed to the repo:

https://github.com/PeterBorah/ethereum-powerball

That might be enough to fulfill the conditions of the bounty. However, as a matter of professional pride, I want to spend a little more time working on the quality of the code. The sorts of bugs found reveal what the weak spots are, and I have some ideas for making it more robust.* So, I'm going to try to work on that over the next couple evenings.

* For the programmers in the audience: I've basically got an implicit state machine with some pretty complex effects. I want to model it more directly so that it's easier to reason about and harder to end up in weird partial states. I'm also not dealing with storing data in a very principled way, so I want to think about encapsulating some of that.

Thank you for the thorough review! I'll take a look at addressing the issues when I get the chance. (Might be a day or so.)

This is a really good idea, and luckily very easy to do. "Kickstarter"-style contracts have become a really common proof-of-concept in the Ethereum world. Here's one in Serpent:

https://github.com/ethereum/serpent/blob/poc7/examples/crowdfund.se

And one in the upcoming Solidity language:

https://github.com/chriseth/cpp-ethereum/wiki/Crowdfunding-example-contract-in-Solidity

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.

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.

Alright, here we go! I've got a fairly polished proof of concept up on Github:

https://github.com/PeterBorah/ethereum-powerball

Instructions for use are in the readme.

I've got a decent number of automated tests for it. Obviously any script that gets banged out in an afternoon is likely to have some residual bugs, but hopefully I've tested it sufficiently that there won't be any major problems.

It hits almost all of the points of the spec, and tries to be very close to the way Powerball works. (Powerball has some weird features, like every prize except the jackpot being fixed, and pretty complex rules for how the jackpot works.) I went with requiring people to claim the prize, since that's what prophetx requested, but of course that could be easily changed.

There is one small deviation from the spec: the ability to set the number of balls. This turned out to be surprisingly difficult, since Serpent doesn't deal well with not knowing how many values there will be ahead of time. However, you can set the payouts for each prize, and by switching out the RNG you can change how many possible values there are for each ball. And of course it would be very easy to modify the code to use, e.g., four balls instead of five.

If that's a dealbreaker, maybe someone can try to add that support, and split the bounty with me. Or maybe prophetx will decide it's good enough as is.

Either way, thanks for the interesting challenge!

Best,
Peter
XCP: 1LeygZteCpjBstARoyt3uHgPhV8aJHsBAg

I've been working on this all afternoon, and I'm reasonably close to done (though I might not get to finish until tomorrow). When I'm done, how should I submit my entry? Just post a github link here?

Thanks, Equality 7-2521!

A couple questions on the spec.


Should there be a "powerball" number with better odds, like in the link you provided?


You prefer explicit redemption, rather than having it automatically send everyone their winnings?

EDIT: New question:

Should it pay out percentages of ticket sales (Jackpot is 50% of winnings, etc.), or should it have set prizes the way real Powerball apparently works (4 out of 5 plus the powerball gets you $10k)?

Hey all, this is Semiel from the Ethereum forums. I'm going to take a crack at the Powerball contract this afternoon. Can anyone point me to documentation about how XCP's smart contract implementation differs from Ethereum's? I know how to do it with Ether and the Ethereum blockchain, but I don't know what I need to do to make it work with XCP and the Bitcoin blockchain.

I predict that the only thing that will matter in a few years is how good a currency's smart contract implementation is. There are lots of other things that make some cryptos better or worse than others, but the runaway technological explosion that will happen when some smart contract system catches on will quickly make all the other variables irrelevant.

It's worth pointing out that there is a common scam where people offer two services: one is trust-free and can't be a scam, and the other requires trust. They use the legitimacy of the first in order to convince people to use the second, and then run off with the second group's money.

I'm not saying that's what you're doing here, but it makes me nervous that you aren't defaulting to escrow in all cases.