Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Retroactively credit incoming payments if notification failed #35

Open
kincaidoneil opened this issue Jun 6, 2019 · 1 comment
Open

Comments

@kincaidoneil
Copy link
Member

kincaidoneil commented Jun 6, 2019

In the current implementation, the plugin must be online in order to credit an incoming Lightning payment. If the plugin is offline but the LND node is online, the sender may have sent a settlement, but it wouldn't be credited.

There should be a protocol or mechanism to retroactively credit settlements to get peers' balances back in sync if the receiver goes offline, then comes back online, or for some reason they fail to get the notification.

@kincaidoneil kincaidoneil changed the title Retroactively credit incoming payments if notifications fail Retroactively credit incoming payments if notification failed Jun 6, 2019
@kincaidoneil
Copy link
Member Author

kincaidoneil commented Jun 23, 2019

while ensuring no invoice is credited more than once

Persist the monotonically increasing settle_index and replay notifications beginning with the last one credited to ensure no invoice is credited more than once.

The plugin could iterate through previously paid invoices to ensure each was credited, and the counter ensures no invoice is credited more than once.

And, instead of persisting the invoices sent to each peer to determine which account each settled invoice should be credited to, require the counterparty to include their accountId in the memo field of the payment. (There might need to be a subprotocol to advertise, "hey, use this accountId if you send me any payments!")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant