"Build an LDK Light Client" guide starter #21
Conversation
| devices with an unreliable access to Internet or often shutdown by their users are particularly | ||
| sensible to this issue. | ||
|
|
||
| This liveliness requirement is function of which Lightning situation is considered. |
There was a problem hiding this comment.
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.
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
| notification to the user at half of the CLTV delay warning about the requirement to connect back | ||
| to the network. | ||
|
|
||
| On the UX-side, as soon the HTLC is sent on the channel, the user balance should be decreased |
There was a problem hiding this comment.
I'm not sure we should be giving UX advice.
There was a problem hiding this comment.
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.
| to broadcast onchain the commitment transaction and a corresponding HTLC-Success. Requiring a long | ||
| CLTV delay at last hop offers a _time window_ for how long the mobile device can be offline. With | ||
| LDK, this can be easily done by checking `event::PaymentReceived` at reception. Ideally, the | ||
| Lightning application will send a notification to the user at half of the CLTV delay warning about |
There was a problem hiding this comment.
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.
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.
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...
| ## Chain Validation | ||
|
|
||
| A Lightning node needs access to the chain to verify channel utxo state. Failure to do so | ||
| might lead to accept payments on a non-existent or already-closed channel, thus provoking a loss of |
There was a problem hiding this comment.
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.
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?
| Assuming client wallet keys have not leaked, a channel funding sequence should be always valid. | ||
| Further, sending payment is only decreasing user balance. In case of the channel being already | ||
| closed, the user balance committed onchain will be higher, thus at its advantage (and a loss for | ||
| the counterparty...) |
There was a problem hiding this comment.
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.
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