Block-based lottery duration

[aftermath2]

Description

Currently there is one lottery every 24 hours starting at 00:00 UTC. However, we could switch to a block-based duration of 144 blocks per lottery and use the 144th block header hash as a source of entropy to generate the winning numbers.

That way, users would be able to prove that the numbers were generated randomly and not arranged or manipulated. Right now, they must trust that the code running in the production server is indeed the one present in this repository's master branch.

[conduition]

Hi @aftermath2, I went down a bit of a rabbit hole and designed a whole protocol for this over the last couple days. It allows provably fair outcomes and grants players the ability to prove misbehavior by the server with irrefutable succinct proofs.

• https://conduition.io/scriptless/lottery/
• http://conduit4u4zsimbgvcatj6lyy36ot6k7w7bvbvivgwhbgzs7gfds7qad.onion/scriptless/lottery/
• https://github.com/conduition/conduition.io/pull/4

Excerpt from the introduction:

In this document, I'll describe a protocol for a provably fair Bitcoin lottery in which players can pay into the jackpot using Lightning. If everyone cooperates, the winner can even receive their prize using Lightning too. This enables large scale federated lotteries with very low barriers to entry, and highly flexible ticketing systems, where 1 satoshi paid into the jackpot is literally equivalent to one ticket in the lottery. Players maintain total anonymity from one-another.

The lottery's jackpot capital is backed on-chain by a market maker. The market maker is trusted, but verifiable: While the market maker could choose to award the jackpot to the wrong player (collusion is possible), any other honest player can immediately recognize this misbehavior, and publish a non-interactive fraud proof to warn others.

The market maker can publish irrefutable proofs demonstrating they picked winners fairly, and can commit himself to a deadline, where he must award the jackpot by a given block height, or else be financially punished.

Given more advancements in BitVM, it could even be possible for the market maker to commit himself to honest winner selection, allowing players to financially punish the market maker for choosing a winner dishonestly.

Needs review as i'm sure I missed stuff.

Naturally it would be a lot of work to convert BTRY into a cryptographically provable lottery; i'm not sure if that was your original intent or not. I hope this provides some interesting food for thought at least :smile:

[aftermath2]

@conduition This is awesome! Very interesting solution and concepts. I'll take some time to review it further, point by point and leave some comments here. Thank you for taking the time and effort to craft a protocol.

Naturally it would be a lot of work to convert BTRY into a cryptographically provable lottery; i'm not sure if that was your original intent or not. I hope this provides some interesting food for thought at least

It wasn't my original idea but because I came up with this issue a few days before publishing the MVP. It's definitely something worth getting into and hopefully developing the logic necessary to make it work.

[aftermath2]

Hello @conduition, sorry for taking so long to respond. I have analyzed the protocol specification and I absolutely love the concepts you have used to make it work. There are some points/questions I would like to discuss:

• The protocol mentions factoring on-chain fees in the ticket costs, the problem with this is that we don't know how many users will participate in the lottery, so we don't how much to charge them at the time they make the deposit. Or are tickets settled once the full set of participants is known?

  An alternative could be to deduct on-chain and service fees from the the total jackpot output value. The users could still verify that $\hat{v}$ = $v_1 + v_2 + ... v_n + service fees + TXinit fee$

• The winner transaction is only spendable by the participant that holds the winning ticket secret $t_i$. However, all ticket secrets $t_1 ... t_n$ are generated by the market maker, so couldn't he just spend the transaction or collude with a participant and give him all the ticket secrets? Shouldn't the ticket secret be generated by the participant and just share the correspoding $T$?

• The 3rd point in "Lottery registration" mentions

  It should be as small as possible, because paying the deposit does not assure the player they can participate in the lottery?

  I'm not sure what this means, a user who made a deposit shouldn't always participate in the lottery?

• Under "How to Make Tickets Valuable", the protocol says

  If a player stops cooperating at any time before the $TXinit$ is published, the market maker can simply exclude them, take their deposit as a fee, and try again with the remaining players.

  I'm trying to think of how this would be implemented in practice. Do all participants need to be online during the whole process or could they disconnect and reconnect whenever they desire? With the market maker providing the lottery information they need to make the calculations each time