Lightning dice [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2021-02-03T01:31:39+00:00


Summary:

In the context, the writer discusses a protocol that addresses the issue of potential cheating in gambling systems. The protocol involves vetting Bob's claim by sending relevant information to Carol to verify if she pays out the Payment-Triggered Lightning Contract (PTLC). However, this protocol may face challenges due to the lack of spam defenses in the lightning network. It is highlighted that PTLC payments need to be serialized to prevent multiple payouts to Bob. Moreover, multiple verifiers can cause delays by forcing Carol to wait for the PTLC timeout.To overcome these challenges, the writer suggests using stuckless payments as a possible solution. Stuckless payments would allow parallel validation, improving the efficiency of the process. The author then proposes a rough design for a provably fair gambling system on the Lightning Network, similar to Satoshi Dice. This system's security model allows for proving if the casino cheats but does not provide a way to obtain rewards solely through proof. To make the system more compatible with the Lightning Network, the payout is not guaranteed cryptographically. This approach also requires less capital compared to other methods.The first step in setting up the wager involves Bob and Carol agreeing to a standard bet with a 1.8% chance of winning and a 50x payout. The maximum stake is set at 200 satoshi, with a maximum payout of 10,000 satoshi. The bet is implemented by both parties randomly choosing numbers (b and c), and the winner is determined based on the relationship between these numbers. Two messages, m1 and m2, are used to initiate the bet. M1 specifies the amount owed by Carol to Bob under certain conditions, while m2 contains the values of b and c chosen by both parties.


Updated on: 2023-07-31T23:23:02.607805+00:00