Nadav Kohen [ARCHIVE] on Nostr: 📅 Original date posted:2020-04-16 📝 Original message: Good morning ZmnSCPxj and ...
📅 Original date posted:2020-04-16
📝 Original message:
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 <ZmnSCPxj at protonmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200416/574fa4c6/attachment.html>;
📝 Original message:
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 <ZmnSCPxj at protonmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200416/574fa4c6/attachment.html>;