Andrés G. Aragoneses [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-11 📝 Original message: Hey ZmnSCPxj, On Thu, 11 ...
📅 Original date posted:2021-02-11
📝 Original message:
Hey ZmnSCPxj,
On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Andres,
>
> > 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?
>
> Correct.
> Though note that existing systems like Bisq, to my knowledge, have the
> same problem, a buyer of Bitcoin has to have a small amount of Bitcoin to
> offer as stake that can be revoked in case they attempt to defraud the
> counterparty.
> Without it, the counterparty takes on increased risk (which translate to
> larger exchange spread).
>
Yeah I understand Bisq's model.
However not all P2P exchanges work like this; e.g. localcryptos, hodlhodl,
localbitcoins, localcryptos...
>
> In any case, once you have that initial stake, you can then keep
> increasing your ability to provide stake so as to relieve your
> counterparties of risk and have them offer better exchange rates, so it is
> "only" an issue for initial onboarding.
> Presumably, in the later stable state, parents will provide children the
> initial stake needed for them to start transacting over such a system, just
> as they already provide their children with other "initial stakes"
> (education, food, shelter, etc.) anyway.
>
> >
> > So are you saying that this is not doable without PTLCs (with simple
> HTLCs) unless it's done like suggested?
>
> Yes, it is yet another reason we want PTLCs quickly.
>
> An alternative would be to have dual-hash HTLCs, which would be helpful in
> other escrow-related cases including escrow-facilitated cross-currency
> swaps.
>
Is there any disadvantage about using dual-hash HTLCs?
Is it supported by the current LN spec?
>
> Regards,
> ZmnSCPxj
>
>
> >
> > 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/ad341e90/attachment-0001.html>;
📝 Original message:
Hey ZmnSCPxj,
On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Andres,
>
> > 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?
>
> Correct.
> Though note that existing systems like Bisq, to my knowledge, have the
> same problem, a buyer of Bitcoin has to have a small amount of Bitcoin to
> offer as stake that can be revoked in case they attempt to defraud the
> counterparty.
> Without it, the counterparty takes on increased risk (which translate to
> larger exchange spread).
>
Yeah I understand Bisq's model.
However not all P2P exchanges work like this; e.g. localcryptos, hodlhodl,
localbitcoins, localcryptos...
>
> In any case, once you have that initial stake, you can then keep
> increasing your ability to provide stake so as to relieve your
> counterparties of risk and have them offer better exchange rates, so it is
> "only" an issue for initial onboarding.
> Presumably, in the later stable state, parents will provide children the
> initial stake needed for them to start transacting over such a system, just
> as they already provide their children with other "initial stakes"
> (education, food, shelter, etc.) anyway.
>
> >
> > So are you saying that this is not doable without PTLCs (with simple
> HTLCs) unless it's done like suggested?
>
> Yes, it is yet another reason we want PTLCs quickly.
>
> An alternative would be to have dual-hash HTLCs, which would be helpful in
> other escrow-related cases including escrow-facilitated cross-currency
> swaps.
>
Is there any disadvantage about using dual-hash HTLCs?
Is it supported by the current LN spec?
>
> Regards,
> ZmnSCPxj
>
>
> >
> > 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/ad341e90/attachment-0001.html>;