DIP - Lottery Contract

A Lottery would be very similar to a regular dispenser with one major difference - it’s random whether you receive the token or not.

Say you set up a lottery for a DOGEMEME card. You specify the price, 10 doge, and the chance to win the card, 5%.

Someone sends 10 doge to the lottery, and the protocol register the request. Hardcoded in the protocol is a random number generator, and the output [0,1) is determined by the block hash and transaction hash. In this case, if the result <0.05 the token is sent.

Essentially the lottery contract can inherit all the properties of a dispenser with win-probability as an extra parameter.

And just like several dispensers can be combined, you can combine lotteries - or even combine dispensers and lotteries.

Example 1 - Dispenser/Lottery Combo
You set up a dispenser with 10 doge per DOGEMEME. In addition you have a ultra rare DOGX card, and you set up a lottery for 10 doge = 1% chance of winning. Anyone who buys DOGMEME then also has a small chance of getting DOGX.

Example 2 - Card Pack
You’re the creator of several cards. You want to make an element of surprise for collectors of your card (like with physical card packs). You sell 10 different cards on the same address, all with price 10 doge but different probabilities CARDONE to CARDEIGHT = 50%, CARDNINE = 10% and CARDTEN = 1%. Anyone sending 10 doge to your address will receive a random combination of these cards.

Example 3 - Big Prize
You own a very valuable card. You estimate the price at 100,000 doge. You set up a dispenser 100 doge = 0.1%. If you (the seller) are unlucky, the first ticket gets the doge. You just gave it away for 100 doge … but the opposite may come true too. All the first 1000 tickets may be losers and you may receive well more than 100,000 doge before a winner is announced.


How the random number can be generated.

  • Dec(block_hash + tx_id + lottery_id) % 1e8 = random_number

The random number is an integer in the range [0, 99,999,999].

The block hash is completely unpredictable, i.e. a great source of randomness.

What can theoretically skew the outcome is a withholding attack. In case a miner runs a lottery and finds a winning block, he can choose not to announce (withhold) this block. This comes at the expense of losing a block reward.

A current block is worth about $900. This means that prizes above this level can be skewed in case the lottery operator colludes with miners. Notice that if he colludes with, say, 10% of the miners, the probability is just slightly skewed.

For Bitcoin the block reward is currently around $150,000, so for Counterparty this would rarely even be a theoretical concern.

TX ID, Lottery ID
In the above formula I added tx_id and lottery_id. This to make each payout independent. Since lotteries can be bundled, this makes it so that some may win, some may lose,