Hi Lloyd, >In my opinion, this protocol is theoretical breakthrough as well as a practical protocol. Well done!
Thanks for the kind praise, and for providing a summary of what you think makes the protocol useful. Your different perspective is undoubtedly useful for others who are trying to understand it. >We might call this a "Forced Refund *TLC" Good description, I like it. >The advantages that Ruben's two tx protocol has over this is that timelocks and monitoring is only needed on one of the chains. Well put, and I agree with your point that the traditional 4 tx protocol can also be turned into 2 tx with an online requirement. One minor thing to add is that this would make the 4 tx protocol more clunky in the non-cooperative case (a 4 tx timeout). In the SAS protocol it comes at no cost. Cheers, Ruben On Tue, May 12, 2020 at 1:30 PM Ruben Somsen <rsom...@gmail.com> wrote: > Hi ZmnSCPxj, > > >Would this not work? > > I considered and rejected that model for the following reason: there are > moments where both Alice and Bob can claim the BTC. If they both attempt to > do so, it also reveals both secrets, causing the LTC to also be claimable > by both parties. This chaotic scenario is a failure mode that did not seem > acceptable to me. The revoke transaction was specifically added to mitigate > that issue (invalidating any attempt of Bob to claim the coins and reveal > his secret). That said, it doesn't particularly seem in either party's > interest wait until a moment where two timelocks become valid, so maybe it > is not quite as bad as I thought. However, it still means that the > incompetence/malevolence of one party can lead to losses for both parties. > I have my doubts a gain in privacy in the uncooperative case is worth that > risk. > > Of course it also reverts the protocol to 3 transactions, instead of 2, > but regardless, not having to watch the chain is probably more practical in > many cases. As an aside, if both chains support timelocks then we can > ensure that the more expensive chain only receives one transaction. > > >if relative locktimes are used as often as absolute locktimes for > block-sniping-prevention and a decent Scriptless Script system, then all > protocol aborts should be doable with no information leaks > > I see your point, interesting observation. > > >A sidenote as well, that if Alice typically uses an HD wallet, the UTXO > on the LTC side would not be in that HD, and if Alice wants to cold-store > the LTC, it should move the money as well into an HD pubkey. > > Agreed, I had that listed as one of the disadvantages: "Access to money is > contingent on remembering secrets (backup complexity)" > > Cheers, > Ruben > > > On Tue, May 12, 2020 at 8:50 AM Lloyd Fournier <lloyd.fo...@gmail.com> > wrote: > >> A quick correction to my post: >> >>> >>> Here's where the truly novel part comes in. Ruben solves this by >>> extending the standard *TLC contract: >>> 1. Bob redeem with secret >>> 2. Alice refund after T1 >>> 3. Bob redeem without secret after T2 >>> >>> This is actually: >> >> 1. Bob redeem with redeem secret >> 2. Alice refund after T1 with refund secret >> 3. Bob redeem without secret after T2 >> >> The fact that Alice reveals a secret when she refunds is crucial. >> >> LL >> >
_______________________________________________ bitcoin-dev mailing list email@example.com https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev