From nadav at suredbits.com Sat Feb 13 05:47:50 2021 From: nadav at suredbits.com (Nadav Kohen) Date: Fri, 12 Feb 2021 23:47:50 -0600 Subject: [Lightning-dev] Escrow Over Lightning? In-Reply-To: References: <5F48CD40-A1C7-4D72-8616-19BA3B1F033A@gmail.com> <825EEUgcuH2-nkbpWjxRIvqowD2W6moorCatcbnAIFKaXjOCRHHkFHcp3UaXt7aOlkF3WoZoMIfbbvJZgBkKvk263LasfXFJ345WRJywzZw=@protonmail.com> <6d8QNfAwhsXdetXX64NXMD5Y-hjGaCtK40UIsJxoxb0CPjwJlSRZf6BfVDllCG9U70iJvxW2aBXyS6lMKztLffPXmcP5Xn7eMkpQiD2wtao=@protonmail.com> Message-ID: 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: