<div dir="ltr">Hey ZmnSCPxj,<div><br></div><div>Your earlier post about how to accomplish ORing points without verifiable encryption was super interesting.<br><div><br></div><div>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.</div><div><br></div><div>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!</div><div><br></div><div>Best,<br>Nadav</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 12, 2021 at 11:26 PM ZmnSCPxj <<a href="mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Andres,<br>
<br>
> > > Is there any disadvantage about using dual-hash HTLCs?<br>
> > > Is it supported by the current LN spec?<br>
> ><br>
> > 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).<br>
> > 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.<br>
><br>
> 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?<br>
<br>
Every forwarding node needs to support 2HTLC or PTLC, meaning it has to be a network-wide upgrade.<br>
Then once the network-wide upgrade is deployed, individual endpoints just have to understand this protocol.<br>
<br>
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.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>