Andrés G. Aragoneses [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-11 📝 Original message: This looks cool but would ...
📅 Original date posted:2021-02-11
📝 Original message:
This looks cool but would hinder UX too much for certain scenarios: e.g. if
the escrow in place is part of a bitcoin exchange, then you require the
bitcoin buyer to have bitcoin already, which makes it harder to on-ramp new
users (which could maybe only have fiat). Am I right?
So are you saying that this is not doable without PTLCs (with simple HTLCs)
unless it's done like suggested?
On Thu, 11 Feb 2021 at 14:01, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Nadav and Andres,
>
> Thank you for bringing up this topic again.
>
> Let me provide a new twist to this old idea.
>
> This is the entire logic of the contract to the seller:
>
> SELLER && (BUYER || ESCROW)
>
> Now, a big issue is that simple `&&` is trivial for PTLCs, it is the `||`
> which is difficult and requires ECDH and proof that the ECDH was done
> correctly.
>
> But we can observe the De Morgan Theorem:
>
> A || B <=> !(!A && !B)
>
> So how about we *invert* the logic?
>
> So what we do is, we make *two* payments of the same amount:
>
> * Seller -> Buyer , claimable by BUYER && ESCROW key.
> * Buyer -> Seller, claimable by SELLER key.
>
> So the ritual is this:
>
> * Seller -> Buyer claimable by BUYER && ESCROW.
> * Buyer -> Seller claimable by SELLER.
> * Seller hands over item.
> * Buyer judges whether to accept, or complain to Escrow.
>
> Now let us consider our cases:
>
> * Buyer is satisfied with the product.
> * Buyer fails the Seller->Buyer payment after seller claims the
> Buyer->Seller payment, so Seller is paid and has no more obligations.
> * Buyer is dissastisfied and wants the Escrow to judge:
> * Escrow judges Buyer is right: Escrow reveals ESCROW key to Buyer, who
> then clawbacks the payment to the seller.
> * Escrow judges Seller is right: Escrow deletes ESCROW privkey ("not
> ESCROW"), and the Seller->Buyer payment eventually times out, ending the
> obligation of the Seller.
>
> The "reverse" payment is effectively the inversion of logic by the De
> Morgan theorem, and the "normal case" (buyer ultimately pays seller) has
> the Escrow not revealing the privkey.
> In addition, in the case where Buyer is satisfied (i.e. both Buyer and
> Seller agree the trade is beneficial) the Escrow is never involved (the
> Escrow might have a timeout for the temporary ESCROW keypair, which it will
> eventually delete; since all payments on LN need a timeout anyway, this is
> fine) and thus does not know about the trade, except that some trade was
> requested (since it must provide a temporary ESCROW pubkey).
>
> This even provides a simple BUYER + ESCROW keypair that gives the seller a
> proof-of-refund, and of course the simple SELLER gives the buyer a
> proof-of-payment as well.
> It only just requires twice as much Bitcoins getting locked.
>
> Thoughts?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210211/c6a316f0/attachment.html>;
📝 Original message:
This looks cool but would hinder UX too much for certain scenarios: e.g. if
the escrow in place is part of a bitcoin exchange, then you require the
bitcoin buyer to have bitcoin already, which makes it harder to on-ramp new
users (which could maybe only have fiat). Am I right?
So are you saying that this is not doable without PTLCs (with simple HTLCs)
unless it's done like suggested?
On Thu, 11 Feb 2021 at 14:01, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Nadav and Andres,
>
> Thank you for bringing up this topic again.
>
> Let me provide a new twist to this old idea.
>
> This is the entire logic of the contract to the seller:
>
> SELLER && (BUYER || ESCROW)
>
> Now, a big issue is that simple `&&` is trivial for PTLCs, it is the `||`
> which is difficult and requires ECDH and proof that the ECDH was done
> correctly.
>
> But we can observe the De Morgan Theorem:
>
> A || B <=> !(!A && !B)
>
> So how about we *invert* the logic?
>
> So what we do is, we make *two* payments of the same amount:
>
> * Seller -> Buyer , claimable by BUYER && ESCROW key.
> * Buyer -> Seller, claimable by SELLER key.
>
> So the ritual is this:
>
> * Seller -> Buyer claimable by BUYER && ESCROW.
> * Buyer -> Seller claimable by SELLER.
> * Seller hands over item.
> * Buyer judges whether to accept, or complain to Escrow.
>
> Now let us consider our cases:
>
> * Buyer is satisfied with the product.
> * Buyer fails the Seller->Buyer payment after seller claims the
> Buyer->Seller payment, so Seller is paid and has no more obligations.
> * Buyer is dissastisfied and wants the Escrow to judge:
> * Escrow judges Buyer is right: Escrow reveals ESCROW key to Buyer, who
> then clawbacks the payment to the seller.
> * Escrow judges Seller is right: Escrow deletes ESCROW privkey ("not
> ESCROW"), and the Seller->Buyer payment eventually times out, ending the
> obligation of the Seller.
>
> The "reverse" payment is effectively the inversion of logic by the De
> Morgan theorem, and the "normal case" (buyer ultimately pays seller) has
> the Escrow not revealing the privkey.
> In addition, in the case where Buyer is satisfied (i.e. both Buyer and
> Seller agree the trade is beneficial) the Escrow is never involved (the
> Escrow might have a timeout for the temporary ESCROW keypair, which it will
> eventually delete; since all payments on LN need a timeout anyway, this is
> fine) and thus does not know about the trade, except that some trade was
> requested (since it must provide a temporary ESCROW pubkey).
>
> This even provides a simple BUYER + ESCROW keypair that gives the seller a
> proof-of-refund, and of course the simple SELLER gives the buyer a
> proof-of-payment as well.
> It only just requires twice as much Bitcoins getting locked.
>
> Thoughts?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210211/c6a316f0/attachment.html>;