Proposal Summary
The following proposal is intended to adapt the existing PTLC protocol into
Payment Route Reservation[1] flow. Modifying the original PTLC protocol
slightly, we get support for reusable static invoices with atomic proof of
payment and payer proofs, that don't
Using payment correlation attacks adversary can try to link the sender and
receiver of payment by observing traffic from the potential sender to the
potential receiver. Such observations can be made by the adversary nodes if
they are present on the payment path or if the adversary is able to mo
There are two more improvements I missed in my first mail.
The first one is that all the nodes on the route get the same amount to
reserve. So there is no need to put the amount inside the onion. This way node
can fail reservation faster if there is no reservation balance left without
opening
If ASCII graphics are not rendering correctly, you can read the proposal on the
mailing list archive, where for some reason are rendered correctly -
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003867.html
Cheers,
g0b1el
__
Hi, lightning devs
It's my first mail, so first, I'd like to say a big thanks to everyone involved
in the development of the lightning network.
I've just finished going through this mailing list, so I'm not sure if Payment
Route Reservation is already proposed in some other place. If there is
