📅 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>;
Andrés G. Aragoneses [ARCHIVE] /
npub13e…tkq6u
2023-06-09 13:02:00
in reply to nevent1q…vccd
Author Public Key
npub13e0usm0e4q8qmxvgyq85xapy84hrsks3yp376dqx0ma5ahedsq4s2tkq6uPublished at
2023-06-09 13:02:00Event JSON
{
"id": "53f66bb68ae33629c7d15c135ee73f52c94a3137c9a7893c5a6a2f8c9a59feb0",
"pubkey": "8e5fc86df9a80e0d9988200f4374243d6e385a112063ed34067efb4edf2d802b",
"created_at": 1686315720,
"kind": 1,
"tags": [
[
"e",
"314d09df8983f36a6cfef295360e46d7142fc01ed765a13fbdab5e1db6b5c415",
"",
"root"
],
[
"e",
"68f9420a463a94c9ce1d9cfc2f9f11db9788d16db5d595972ba45e0639ee28f0",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2021-02-13\n📝 Original message:\nHey ZmnSCPxj,\n\nOn Fri, 12 Feb 2021 at 08:52, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning Andres,\n\u003e\n\u003e \u003e Hey ZmnSCPxj,\n\u003e \u003e\n\u003e \u003e On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e Good morning Andres,\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e This looks cool but would hinder UX too much for certain scenarios:\n\u003e e.g. if the escrow in place is part of a bitcoin exchange, then you require\n\u003e the bitcoin buyer to have bitcoin already, which makes it harder to on-ramp\n\u003e new users (which could maybe only have fiat). Am I right?\n\u003e \u003e \u003e\n\u003e \u003e \u003e Correct.\n\u003e \u003e \u003e Though note that existing systems like Bisq, to my knowledge, have the\n\u003e same problem, a buyer of Bitcoin has to have a small amount of Bitcoin to\n\u003e offer as stake that can be revoked in case they attempt to defraud the\n\u003e counterparty.\n\u003e \u003e \u003e Without it, the counterparty takes on increased risk (which translate\n\u003e to larger exchange spread).\n\u003e \u003e\n\u003e \u003e Yeah I understand Bisq's model.\n\u003e \u003e However not all P2P exchanges work like this; e.g. localcryptos,\n\u003e hodlhodl, localbitcoins, localcryptos...\n\u003e \u003e\n\u003e\n\u003e At least localbitcoins is custodial, and this scheme is non-custodial\n\u003e (though the escrow must still be trusted to actually judge correctly in\n\u003e case of dispute, so non-custodiality might be a very thin assurance).\n\u003e\n\u003e\nTrue, I shouldn't have included LB in that list of examples; the other two\nare non-custodial though.\n\n\n\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e \u003e In any case, once you have that initial stake, you can then keep\n\u003e increasing your ability to provide stake so as to relieve your\n\u003e counterparties of risk and have them offer better exchange rates, so it is\n\u003e \"only\" an issue for initial onboarding.\n\u003e \u003e \u003e Presumably, in the later stable state, parents will provide children\n\u003e the initial stake needed for them to start transacting over such a system,\n\u003e just as they already provide their children with other \"initial stakes\"\n\u003e (education, food, shelter, etc.) anyway.\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e So are you saying that this is not doable without PTLCs (with simple\n\u003e HTLCs) unless it's done like suggested?\n\u003e \u003e \u003e\n\u003e \u003e \u003e Yes, it is yet another reason we want PTLCs quickly.\n\u003e \u003e \u003e\n\u003e \u003e \u003e An alternative would be to have dual-hash HTLCs, which would be\n\u003e helpful in other escrow-related cases including escrow-facilitated\n\u003e cross-currency swaps.\n\u003e \u003e\n\u003e \u003e Is there any disadvantage about using dual-hash HTLCs?\n\u003e \u003e Is it supported by the current LN spec?\n\u003e\n\u003e It is no supported by current LN spec, and PTLCs are overall superior\n\u003e (they are equivalent to having any number of hashes, not just 2 that\n\u003e dual-hash HTLCs can do).\n\u003e So if we need to change the LN spec anyway, PTLCs are still the better\n\u003e choice, since they enable a lot more, and we probably want to support that\n\u003e in the future anyway, so we might as well do HTLC-\u003ePTLC rather than\n\u003e HTLC-\u003e2HTLC-\u003ePTLC.\n\u003e\n\nBut anyway any L2 wallet that interacts with this, will need to be aware of\nthe escrow, so developing an 2HTLC extension for it to work with the\ncurrent version of bitcoin (instead of waiting for Taproot) should be\ndoable, right?\n\n\n\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210213/ff3292bc/attachment.html\u003e",
"sig": "dc05980c2158a194e2c6f6bc7d1f4aabb0c2cf394c51dc43eb2bbee20192eecb7a9e45b21100f2d21baac07fcf52c5c05ef4b4b19444d6be3b00a748728c30ce"
}