Andrés G. Aragoneses [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-13 📝 Original message: Hey ZmnSCPxj, On Fri, 12 ...
📅 Original date posted:2021-02-13
📝 Original message:
Hey ZmnSCPxj,
On Fri, 12 Feb 2021 at 08:52, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Andres,
>
> > 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...
> >
>
> At least localbitcoins is custodial, and this scheme is non-custodial
> (though the escrow must still be trusted to actually judge correctly in
> case of dispute, so non-custodiality might be a very thin assurance).
>
>
True, I shouldn't have included LB in that list of examples; the other two
are non-custodial though.
> >
> >
> > > 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?
>
> It is no supported by current LN spec, and PTLCs are overall superior
> (they are equivalent to having any number of hashes, not just 2 that
> dual-hash HTLCs can do).
> So if we need to change the LN spec anyway, PTLCs are still the better
> choice, since they enable a lot more, and we probably want to support that
> in the future anyway, so we might as well do HTLC->PTLC rather than
> HTLC->2HTLC->PTLC.
>
But anyway any L2 wallet that interacts with this, will need to be aware of
the escrow, so developing an 2HTLC extension for it to work with the
current version of bitcoin (instead of waiting for Taproot) should be
doable, right?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210213/ff3292bc/attachment.html>;
📝 Original message:
Hey ZmnSCPxj,
On Fri, 12 Feb 2021 at 08:52, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Andres,
>
> > 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...
> >
>
> At least localbitcoins is custodial, and this scheme is non-custodial
> (though the escrow must still be trusted to actually judge correctly in
> case of dispute, so non-custodiality might be a very thin assurance).
>
>
True, I shouldn't have included LB in that list of examples; the other two
are non-custodial though.
> >
> >
> > > 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?
>
> It is no supported by current LN spec, and PTLCs are overall superior
> (they are equivalent to having any number of hashes, not just 2 that
> dual-hash HTLCs can do).
> So if we need to change the LN spec anyway, PTLCs are still the better
> choice, since they enable a lot more, and we probably want to support that
> in the future anyway, so we might as well do HTLC->PTLC rather than
> HTLC->2HTLC->PTLC.
>
But anyway any L2 wallet that interacts with this, will need to be aware of
the escrow, so developing an 2HTLC extension for it to work with the
current version of bitcoin (instead of waiting for Taproot) should be
doable, right?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210213/ff3292bc/attachment.html>;