-
Couldn't load subscription status.
- Fork 47
"Build an LDK Light Client" guide starter #21
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fee estimaiton review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be worth talking about the differences between CSV and CLTV-based deadlines. Specifically, if you do not have any pending HTLCs around, checking the chain once per day (depending on your CLTV setting) may suffice. However, pending HTLCs change the situation significantly, where you need to check much more aggressively.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It really depends. If you're using timelock offset tricks on your outgoing/incoming HTLCs, the CSV delay is actually your "should-be-back-online" constraint.
docs/mobile.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we should be giving UX advice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the other side, I would say our event named are a bit confusing PaymentReceived when we get an incoming HTLC doesn't guarantee will get the payment. We might need interactivity with the payer to obtain the preimage or HTLC might have to be claimed onchain if counterparty doesn't cooperate...Dropped it for now, maybe secure UX tips should be documented elsewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a discussion about how you may wish to use a lightning node that all your clients open channels with and use that to send Apple/Google push notifications to wake your app up? I believe that approach was...spotty at best when @arik-so looked into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup. At least on iOS, there is basically no way to guarantee that a push notification will invoke background processing both promptly enough and with sufficient time to handle any necessary calculations.
The one exception to that rule is VoIP apps, which have special permissions for server-invoked operations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean your background task may never have any CPU ticks ? Even if you take few hours of margin of errors ?
Do we need a discussion about how you may wish to use a lightning node that all your clients open channels with and use that to send Apple/Google push notifications to wake your app up?
It doesn't have to open channels, just a e&a transport ? But in fine trust sounds similar to a watchtower...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that accepting payments on an already-closed channel is ok, as long as the CLTV timeout hasn't passed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But you won't get this new accepted payment as your balance is already committed onchain ? If you provide a service in exchange you don't compensation for it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually think we can just say "you can run totally normally once you're within the CLTV delay of the channel".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean CLTV delay minus best-chain tip OR CSV delay ? Effectively I think both holds you're done with headers-sync.
Updated at 5fb28f9, addressing few comments already.
@ConorOkus @haleyberkoe Do you think it can be valuable if I spend time recycling the ideas exposed there on how much LDK is flexible for mobile clients in a well-cleaned blog post, oriented app-devs not protocol-devs ?
Yes sounds good @ariard . I think @moneyball is planning to work with you on this.
Inspired by https://bitcoindevkit.org/blog/2021/01/fee-estimation-for-light-clients-part-1/
For now, the only covered sections are Fee-Estimation, Liveliness & Watchtowers, Chain Validation.
Future sections could be Key-Management, Backups, Routing, Liquidity management, General Security & Privacy Recommendations.
The purpose of this documentation is to introduce a developer familiar with Lightning about the specific challenges of running Lightning on a mobile device, and what LDK is offering as solutions. It should be enriched in the future with graphical illustrations, direct links to code examples or external Bitcoin documentation of interest (bitcoin wiki, BIPs, best practices, ...)
Close #11