Re: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread
also there is one thing i noticed that probably was not clear from all of the write ups, but the award sizes should actually be a percentage of the total amount in tickets collected not set amounts like in the powerball. would it be difficult for you to adjust this? that is what I meant by picking a distribution method/algo. sorry i am not super good at reading code.
Code:
Send an appropriate amount of funds to support the prizes you are configuring. Because Powerball-style lotteries have set prizes, you cannot rely on ticket sales to cover payouts.
for example, getting all numbers correct gets 50% of total (split evenly if multiple tickets), 5 of 6 gets 30%, 4 of 6 gets 10%, 3 of 6 gets 7%, 2 of 6 gets 3%, 1 of 5 gets 0%.
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.
Quote
also another question regarding the "buy ticket" command
if there are multiple lotto's running, how does a buyer know which contract to buy the lotto ticket from? or is all that handled at the XCP layer?
sorry for all the noobish sounding questions but i'm using this as an excerise to learn how this ethereum stuff works
if there are multiple lotto's running, how does a buyer know which contract to buy the lotto ticket from? or is all that handled at the XCP layer?
sorry for all the noobish sounding questions but i'm using this as an excerise to learn how this ethereum stuff works
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.
ok, so i think you just need to put in an operator that says that if no one get 6 of 6 then, 5 of 6 inherits the pay out of 6 of 6, and if not 5 of 6 then 4 of 6 inherits the pay out of 5 of 6 and 6 of 6, and so forth. this way the lotto stays attractive and does not require someone to have $1M to run.
would that be possible for you to add that? please
so the contract is attached to the btc address that runs the contract? i'm just not understanding the mechanics of how this interfaces with the XCP/BTC system/network so that another address holder (not the initiator of the contract) can purchase a ticket. so the initiator runs this against counterpartyd (I have to figure out how that works), and then a player would also run this (i think) against his instance of counterpartyd, but what i do not understand is how the player is able to identify the contract on the blockchain to send a message that he is purchasing a ticket against that particular instantiation of the contract.
I know you are not familiar with how XCP works and the ethereum port, so it may be that someone else needs to answer how that actually happens.