related posts
20 sats \ 2 replies \ @fanis 12 Feb 2023
Great writeup! Just a few points that popped in my head while reading:
I don't really see the opposition between PTLCs and Trampoline. To me, this two aspects are complementary, if anything:
- Trampoline defines which nodes are responsible for holding the payment (could also be LSP, and LSP could also be Trampoline nodes),
- PTLC is just a better way to do conditional payments than HTLC. PTLCs could for example be part of the solution regarding proofs of payment in an asynchronous setup (see Optech #236 for a summary on that).
Regarding the communication channel (useful for example to notify the offline receiving node that there's money waiting for them), I think the current consensus is to use things such as Onion Messages, which are much more Lightning-related than Nostr.
Cheers!
reply
30 sats \ 1 reply \ @TheBTCManual OP 12 Feb 2023
How would the two implementations differ in terms of routing fees? and what happens in each one should the person you pay become a zombie channel or a party force closes?
Thanks so much for the feedback, I've updated the article to include the mention of onion messaging as a solution and added a breakdown of onion messaging to my list of topics to tackle soon. :)
reply
0 sats \ 0 replies \ @fanis 15 Feb 2023
I'm not sure I understand 😅 What would be the "two implementations"? PTLCs vs Trampoline?
I believe that your paragraph on PTLCs refers to this proposition by Matt Corallo (and other more recent discussions on the matter). In this context, there is still a third party who delays forwarding: the sender's LSP. PTLCs are useful here because they enable the receiver to just give a bunch of invoices to their LSP beforehand, knowing that said LSP won't be able to reuse them and still funds (which could happen with HTLCs).
Moreover, the above scenario could be tweaked to include Trampoline nodes along the route, and the LSPs involved could even be Trampoline nodes themselves.
In this regard I think that stating that "PTLC’s offers less risk than trampoline relays do since trampoline relays will require a third party to delay forwarding the funds until the offline node can restore its connection" is not true, since in the PTLCs scenario there is still a third party delaying the payment - and I can't really think of a way to get around that. But I might be missing something here, so happy to be corrected and learn!
Cheers!
reply
10 sats \ 1 reply \ @ealvar26 12 Feb 2023
This is a great writeup thanks for posting!
Do you think watch towers help solve some of the issues listed for async payments?
reply
0 sats \ 0 replies \ @TheBTCManual OP 12 Feb 2023
I am not sure what data watchtowers would be privy to regarding these individual transactions be it with a hodl invoice, pre-image or a PTLC, so I'm not sure how they would find out if a async payment failed or wasn't passed on the case of a trampoline relay
From my understanding and messing about watch towers only check channel states to see if both parties have an agreed on final state.
Hopefully, I can hit up a few people for answers and turn it into a post because its a good topic
reply