Good morning aj, and list,
> Note that Bob could abort the protocol with a winning bet before > requesting the payout from Carol -- he already has enough info to prove > he's won and claim Carol isn't paying him out at this point. > One way of dealing with this is to vet Bob's claim by sending b,R2 and a > PTLC invoice of (50bet,S2) to Carol with yourself as the recipient -- youcan > construct all that info from Bob's claim that Carol is cheating. If > Carol isn't cheating, she won't be able to tell you're not Bob and > will try paying the PTLC; at which point you know Carol's not cheating. > This protocol does't work without better spam defenses in lightning -- > PTLC payments have to be serialised or Carol risks sending the payout > to Bob multiple times, and if many people want to verify Carol is(n't) > cheating, they can be delayed by just one verifier forcing Carol to wait > for the PTLC timeout to be reached. For this particular issue, would not stuckless payments be possible to allow parallelism of validation at least? Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
