Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
In this PR, a new feature called "hold invoice" is added to
Instead of immediately locking in and settling the htlc when the payment arrives, the htlc for a hold invoice is only locked in and not yet settled. At that point, it is not possible anymore for the sender to revoke the payment, but the receiver still can choose whether to settle or cancel the htlc and invoice.
From the sender perspective, a hold invoice payment request looks identical to a regular payment request. There is no way for the sender to know when a hold invoice is paid to.
Hold invoices enable several new use cases:
To enable hold invoice functionality,
Creation of a hold invoice
To add a holdinvoice, invoke:
Waiting for acceptance
Typically an application wants to receive a notification when the htlc is accepted. This event isn't notified through the general
Settling or canceling
Once the htlc has been accepted in
This PR leaves some issues unaddressed:
cfromknecht left a comment
@joostjager sorry for the delay, just found a bunch of pending comments I thought I had shared.
This PR looks pretty complete to me apart from some higher level changes we've discussed elsewhere. Feel free to ignore any comments that may be irrelevant now, i'll just leave all them here
Previously it was difficult to use the invoice registry in unit tests, because it used zpay32 to decode the invoice. For that to succeed, a valid signature is required on the payment request. This commit injects the decode dependency on a different level so that it is easier to mock.
In the TestChannelLinkMultiHopUnknownPaymentHash test, a preimage was modified to trigger an unknown payment hash failure. The way the mock is implemented, it would take the hash of that modified preimage and store it. It basically stores a completely different invoice. For this test, it is just as good to store no invoice at all.
In further commits the behaviour of invoice registry becomes more intrinsically connected to the link. This commit prepares for that by allowing link and registry to be tested as a single unit.
You mention that
however in the invoices.proto there is no rhash returned in the addHoldInvoiceResponse
should we be expected to decode the payment_request to get this?
Sent from my iPhone
On Jun 13, 2019, at 15:20, Joost Jager ***@***.***> wrote: Yes, we will remove the build tag in the future and make it part of default lnd. Eventually we want to also start removing redundant calls from the main rpc server. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.