📅 Original date posted:2021-02-13
📝 Original message:
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 <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
> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210212/015b8ab3/attachment-0001.html>;
Nadav Kohen [ARCHIVE] /
npub1ge…rtua0
2023-06-09 13:02:01
in reply to nevent1q…txtm
Author Public Key
npub1geqdlge6ysz9qlq3w758422flnkgqklpu9veu80ehjprcd04ugyqkrtua0Published at
2023-06-09 13:02:01Event JSON
{
"id": "41904e8cc567a8010649d43d0b414d357e6a328d53654a12ed6aa1bfa34db6d6",
"pubkey": "4640dfa33a2404507c1177a87aa949fcec805be1e1599e1df9bc823c35f5e208",
"created_at": 1686315721,
"kind": 1,
"tags": [
[
"e",
"314d09df8983f36a6cfef295360e46d7142fc01ed765a13fbdab5e1db6b5c415",
"",
"root"
],
[
"e",
"07e853d6916b05d2b095d933d46051e0ac0ddeb3eb62390f3bfdfa5aa893977e",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2021-02-13\n📝 Original message:\nHey ZmnSCPxj,\n\nYour earlier post about how to accomplish ORing points without verifiable\nencryption was super interesting.\n\nI think this contains a clever general NOT operation where you double the\npayment and use the point as a condition for the \"cancellation payment.\"\nThis is actually very similar to something that is used in my PTLC DLC\nscheme where many payments are failed in most cases :) But nice to add it\nto the toolkit, especially as a way to not use ORs for the price of\nover-collateralization which is acceptable in many use cases.\n\nOne comment to make though, is that this mechanism requires the atomic\nsetup of multiple payments otherwise Seller -\u003e Buyer will be set up after\nwhich Buyer may keep the free option and not set up the payment in return.\nLuckily with barrier escrows we can do atomic multi-payment setup to\naccomplish this!\n\nBest,\nNadav\n\nOn Fri, Feb 12, 2021 at 11:26 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning Andres,\n\u003e\n\u003e \u003e \u003e \u003e Is there any disadvantage about using dual-hash HTLCs?\n\u003e \u003e \u003e \u003e Is it supported by the current LN spec?\n\u003e \u003e \u003e\n\u003e \u003e \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 \u003e \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 \u003e\n\u003e \u003e But anyway any L2 wallet that interacts with this, will need to be aware\n\u003e of the escrow, so developing an 2HTLC extension for it to work with the\n\u003e current version of bitcoin (instead of waiting for Taproot) should be\n\u003e doable, right?\n\u003e\n\u003e Every forwarding node needs to support 2HTLC or PTLC, meaning it has to be\n\u003e a network-wide upgrade.\n\u003e Then once the network-wide upgrade is deployed, individual endpoints just\n\u003e have to understand this protocol.\n\u003e\n\u003e Because of the need of widespread upgrade, we would prefer to just upgrade\n\u003e once, from HTLCs to PTLCs, rather than have multiple network-wide upgrades.\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/20210212/015b8ab3/attachment-0001.html\u003e",
"sig": "b7ed4ba312640e508b113ef9cc772c04c95b47a246811aed0d99b5c98fda80b2f8d2e231fa6bc6316423df5c4d660ba2fea30fde8cf3dc1dc9edf5a26ce506c9"
}