pull down to refresh
131 sats \ 1 reply \ @conduition 15 Nov 2023 \ on: BTRY - Lottery powered by Bitcoin bitcoin
Very neat! I was mulling over the plausibility of this concept just yesterday, glad to see someone working on making it reality. As a curious engineer i hope you'll indulge me in some friendly questions :)
Please correct me if I'm wrong, but from a glance at the code, it seems like the winner is chosen by the server completely at random. How is that verifiable?
Specifically this is the function (in lottery/lottery.go) which chooses a winner from a set of bets.
It computes a die roll, weighted by bet size, which seems OK. But the actual entropy for the die roll is pulled from the server's internal RNG. I can't see where the 'provable fairness' or 'auditability' of the winner is derived from. Even though the source code is honest, the actual deployed server might be colluding to award prizes to specific player(s). Honest players would have no way of knowing.
Furthermore, the server could abstain from distributing prizes at all, keeping all the money paid into a lottery for itself. How can players tell if a prize was paid correctly, or paid at all?
It would make more sense to me if the winner was selected by hashing some undisputable but unpredictable future data, like the hash of a yet-to-be-mined block, along with a lottery-specific salt to prevent tampering by miners. With BitVM, you might even be able to set up a contract to punish the server if someone can prove the wrong winner was chosen. With a well-designed n-of-n multisig contract, the server could commit money to revealing a winner before a given date (or else be punished by players).
Happy to chat anytime if you find these ideas interesting. My github is here if you wanna tag me in any issues.
Thank you for your questions, perhaps I wasn't clear enough in the second part of the post but I will try to explain all your doubts.
it seems like the winner is chosen by the server completely at random. How is that verifiable?
When I mentioned provably fair random numbers I was referring to the Battles implementation, which is a completely different service.
As you said, the winning numbers are generated using an RNG (
/dev/random in linux).However, I did create an issue https://github.com/aftermath2/btry/issues/20 which changes the way in which lotteries duration are measured.
Switching to block-based lotteries would allow the numbers to be generated using the last block hash as an entropy source and that way the users would be able to verify that the numbers are fair.
Even though the source code is honest, the actual deployed server might be colluding to award prizes to specific player(s).
You are right, users have to trust BTRY that the deployed source-code is the one in the repository, unfortunately, I'm not sure it's possible to guarantee that the binary is not tampered.
I did include the current commit at the bottom of the page to make it harder for the server to cheat.
the server could abstain from distributing prizes at all, keeping all the money paid into a lottery for itself. How can players tell if a prize was paid correctly, or paid at all?
Prizes withdrawals are not listed because I wanted to avoid showcasing any information that could be considered sensitive.
However, you could listen to the SSE stream at
{url}/api/events?stream=events to the messages of type "payments" and receive updates every time a user makes a withdraw. All you will be able to see is the payment_id and status though.It would make more sense to me if the winner was selected by hashing some undisputable but unpredictable future data, like the hash of a yet-to-be-mined block
I'm not sure I understood this completely. If the data is unpredictable how can users verify it? A hash of a yet-to-be-mined block can be whatever the server wants to, so we wouldn't solve the problem.
As I mentioned before, we could use the latest block hash as a source of entropy because picking the numbers the server wants in that short period of time would be nearly impossible.
With BitVM, you might even be able to set up a contract to punish the server if someone can prove the wrong winner was chosen. With a well-designed n-of-n multisig contract, the server could commit money to revealing a winner before a given date (or else be punished by players).
That's a great idea! I haven't digged into BitVM much yet, but I would love to learn more about it and to implement something like that.
Happy to chat anytime if you find these ideas interesting. My github is here if you wanna tag me in any issues.
I'll tag you in the ones I mentioned above. I'm really interested in having technical conversations and discussing about any Bitcoin topic or even contributing to any projects you may have. I'm open to chatting if you want to!
reply