<p>Payments are handled by means of an established bi-directional payment channel.  While this may seem like a payment could travel in one direction <em>to</em> an offline participant in an open channel, in practice this would be difficult if not impossible.</p>

<p>The problem is that a channel exists as a protocol between two active participants.  There are no other computers involved.  If one of the two computers is not online, who does the sender send the transaction to?  Where is the transaction stored after the sender goes offline, but before the recipient comes back online?  In Bitcoin, these problems are solved by relay nodes and miners.  Once a transaction is in the mempools of enough nodes, the sender does not have to worry about retransmitting a transaction.  The point-to-point nature of the lightning network does not allow for this.</p>

<p>A work around could be a payment service, which is always online to receive and send payments on behalf of a user (for a fee, of course).  Another option is simply sending a regular Bitcoin transaction to an offline recipient.</p>

CC BY-SA 3.0
2016-09-27T18:03:55.020Z
Would it be possible to use some sort of 'mailbox' service, where all you need is a third party server that stores forwarded encrypted messages for you, until you come online?
Pieter Wuille
CC BY-SA 3.0
2016-09-27T18:33:23.810Z
@PieterWuille, that's sort of what I was thinking about, but at that point you lose quite a bit of benefit to LN.  It would no longer be a fast off-chain transaction, and you'd need to keep channels open with disconnected peers.  The benefit would be that channels don't have to be reopened when a peer comes back online.  Depending on your use case, I think at some point an on-chain transaction is more appropriate.
Jestin
CC BY-SA 3.0
2017-07-06T09:34:33.533Z
Sorry to bring this thread back up, but this seems rather problematic for everyday LN users. If I open a channel with a user, and we do 10 transactions, and after the 10th I go offline for longer than the channel's lifetime. When I come back, could it be possible that the user on the other end commited "old transactions" to the blockchain rather than the 10th? How can this be solved by third-parties? Do I have to trust them to behave honestly and not commit old transactions? Or is there a way for me to sort of "revert" the old transactions once I present the new one to the blockchain?
Luca Matteis
CC BY-SA 3.0
2017-07-06T12:35:03.683Z
The smart contracts involved rely on active participants.  If you don't want to stay active, you could find yourself ripped off.  I don't see this as a huge problem, since you can always choose to close a channel before going offline.   It's also fairly easy to stay connected for long periods.  If neither of those options are sufficient, than you can use an online wallet service that is always online, and will likely guarantee your transactions by mitigating the overall risk of all their customers.  In any case, it will likely give bitcoin far more options and utility.
Jestin
CC BY-SA 3.0
2016-09-27T15:11:14.543Z
2016-09-27T15:11:14.543Z
Jestin
<p>Basic examples in LN always mention payments from an online end user to other online end user. But let's say we want to send a micropayment donation to a blog that does not have an always online LN client.</p>

<p>With an on-chain transaction, the payer can send the money and the money will be there even if the payee can't check that within a week time. How about LN?</p>

<p>What are the current proposals for such payments? And what are the requirements for such end users who want to receive payments? Do we require the payee to get online at least once a day, once a week, or no such requirements are there?</p>

<lightning-network><offline-transactions>
In Lightning Network, what are the proposals for solutions to transfers to offline end users?
Wapac
# In Lightning Network, what are the proposals for solutions to transfers to offline end users?

(Asked by: username_0 on 2016-09-27)

Basic examples in LN always mention payments from an online end user to other online end user. But let's say we want to send a micropayment donation to a blog that does not have an always online LN client.

With an on-chain transaction, the payer can send the money and the money will be there even if the payee can't check that within a week time. How about LN?

What are the current proposals for such payments? And what are the requirements for such end users who want to receive payments? Do we require the payee to get online at least once a day, once a week, or no such requirements are there?

**Tags:** lightning-network, offline-transactions


---

## 1 answers

### Answer by username_1 on 2016-09-27. Score: 5

Payments are handled by means of an established bi-directional payment channel. While this may seem like a payment could travel in one direction *to* an offline participant in an open channel, in practice this would be difficult if not impossible.

The problem is that a channel exists as a protocol between two active participants. There are no other computers involved. If one of the two computers is not online, who does the sender send the transaction to? Where is the transaction stored after the sender goes offline, but before the recipient comes back online? In Bitcoin, these problems are solved by relay nodes and miners. Once a transaction is in the mempools of enough nodes, the sender does not have to worry about retransmitting a transaction. The point-to-point nature of the lightning network does not allow for this.

A work around could be a payment service, which is always online to receive and send payments on behalf of a user (for a fee, of course). Another option is simply sending a regular Bitcoin transaction to an offline recipient.

> **Comments:**
> **username_2**: Would it be possible to use some sort of 'mailbox' service, where all you need is a third party server that stores forwarded encrypted messages for you, until you come online?  
> **username_1**: @username_2, that's sort of what I was thinking about, but at that point you lose quite a bit of benefit to LN.  It would no longer be a fast off-chain transaction, and you'd need to keep channels open with disconnected peers.  The benefit would be that channels don't have to be reopened when a peer comes back online.  Depending on your use case, I think at some point an on-chain transaction is more appropriate.  
> **username_3**: Sorry to bring this thread back up, but this seems rather problematic for everyday LN users. If I open a channel with a user, and we do 10 transactions, and after the 10th I go offline for longer than the channel's lifetime. When I come back, could it be possible that the user on the other end commited "old transactions" to the blockchain rather than the 10th? How can this be solved by third-parties? Do I have to trust them to behave honestly and not commit old transactions? Or is there a way for me to sort of "revert" the old transactions once I present the new one to the blockchain?  
> **username_1**: The smart contracts involved rely on active participants.  If you don't want to stay active, you could find yourself ripped off.  I don't see this as a huge problem, since you can always choose to close a channel before going offline.   It's also fairly easy to stay connected for long periods.  If neither of those options are sufficient, than you can use an online wallet service that is always online, and will likely guarantee your transactions by mitigating the overall risk of all their customers.  In any case, it will likely give bitcoin far more options and utility.  

---

