pull down to refresh
I know about async payment (which are not yet developed completely, I've asked before) and that wasn't my question. I specifically asked about partners that trust each other.
So let's paraphrase this. Immagine you owe somebody some sats and when you are both online, he sends you an invoice and you pay it.
What I am basically asking is how hard is it to do this automatically? And by automatically this probbably (i think) means negotiating payment ammount, recording sending node's id, detecting when sending node is online, communicating in some way thet the previously negltiated invoice can be paid (i am not cure whether this can be done through the lightning network, or directly between the two peers using normal tcp or udp connection), and paying the invoice. That's it.
I'm not sure there's a satisfactory solution, but it's interesting that a lightning channel is basically what you're describing: You're signing a transaction that's held offline, now how do you avoid a double spend scenario? In LN, you also sign a revocation transaction that would punish the sender if they tried to double spend. This gives both parties some degree of settlement finality, but the caveat is you have to be online at some minimum periodic rate to be able to broadcast the justice (revocation) transaction if the other party were to try to cheat.
The closest thing currently (still under development) is asynchronous payments. Async payments are an attempt to hold a payment (for up to two weeks maximum) in the event that the receiving node is currently offline. It works by messaging the next-to-last node with a request to notify the original sender (or their LSP) to release the htlc when the recipient node finally comes online. So long as the htlc is locked up on the first hop, the sender can also go offline after creating the htlc and their channel peer (probably an LSP) can wait to release it. This avoids long lived htlcs along the whole route. The sender needs to be able to reach their LSP/peer though - I'm not sure there's any way around that.
I'm sure there's lots of things you could do with sufficient trust, but we're talking IOUs now. For instance, I could create a one time use rune (bearer token) for my Core Lightning node that would allow the holder to connect to my node and tell it to pay an invoice of a specific amount. Just by handing over this rune (which could be written/appended offline), the recipient would have an IOU they could redeem when online, but there would be no guarantee that the liquidity would be there. That's a lot of trust for the recipient.