From nadav at suredbits.com Thu Apr 16 14:42:08 2020 From: nadav at suredbits.com (Nadav Kohen) Date: Thu, 16 Apr 2020 09:42:08 -0500 Subject: [Lightning-dev] Barrier Escrow (Was: Re: A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)) In-Reply-To: References: Message-ID: Good morning ZmnSCPxj and all, I had this thought too! I wrote a blog post series summarizing much of this old thread and here are the two posts about Barrier Escrows: https://suredbits.com/payment-points-and-barrier-escrows/ https://suredbits.com/payment-points-implementing-barrier-escrows/ What I end up proposing is that a barrier escrow implement the following interface: 1. *barrier-commit* takes as input a list of points (P_1, ?, P_n) and returns a point E if a. None of the input points have been seen before b. The exact inputs (P_1, ?,P_n) has been received before in which case the point E returned is the same point as was returned last time 2. *barrier-reveal* takes as input a single scalar, x, and if it has seen x*G as part of an input list to barrier-commit (P_1, ?, P_n), to which it returned the point E, then it waits to receive barrier-reveal requests for each of the n points before it then returns the scalar pre-image to E. In this way, each participant contributes a point commitment and if any party is cheating, it can be detected by the other parties. As I discuss in the second post, the first interaction can happen in many ways but I personally suggested something along the lines of using invoice offers if possible. Best, Nadav On Thu, Apr 16, 2020 at 3:32 AM ZmnSCPxj wrote: > Good morning Nadav, and list, > > Resurrecting this very old thread, but I have been thinking of barrier > escrows again lately. > > The mitigation in > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002215.html > does not work, because one of the participants can always just create a > single payment of the entire amount with its own generated `Z`, and the > barrier escrow would be unable to differentiate this from the case where it > "should" have gotten the payment from multiple participants. > Additional checks can be done to prevent this, but this moves the trust > requirement to the barrier escrow. > > Regards, > ZmnSCPxj > > -------------- next part -------------- An HTML attachment was scrubbed... URL: