[Lightning-dev] Escrow Over Lightning?

Nadav Kohen nadav at suredbits.com
Sat Feb 13 05:47:50 UTC 2021

Hey ZmnSCPxj,

Your earlier post about how to accomplish ORing points without verifiable
encryption was super interesting.

I think this contains a clever general NOT operation where you double the
payment and use the point as a condition for the "cancellation payment."
This is actually very similar to something that is used in my PTLC DLC
scheme where many payments are failed in most cases :) But nice to add it
to the toolkit, especially as a way to not use ORs for the price of
over-collateralization which is acceptable in many use cases.

One comment to make though, is that this mechanism requires the atomic
setup of multiple payments otherwise Seller -> Buyer will be set up after
which Buyer may keep the free option and not set up the payment in return.
Luckily with barrier escrows we can do atomic multi-payment setup to
accomplish this!


On Fri, Feb 12, 2021 at 11:26 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Andres,
> > > > 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
> >
> > 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?
> Every forwarding node needs to support 2HTLC or PTLC, meaning it has to be
> a network-wide upgrade.
> Then once the network-wide upgrade is deployed, individual endpoints just
> have to understand this protocol.
> Because of the need of widespread upgrade, we would prefer to just upgrade
> once, from HTLCs to PTLCs, rather than have multiple network-wide upgrades.
> Regards,
> ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210212/015b8ab3/attachment-0001.html>

More information about the Lightning-dev mailing list