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! Best, Nadav On Fri, Feb 12, 2021 at 11:26 PM ZmnSCPxj <zmnsc...@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 > 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? > > 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 >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
