<p>Not sure if I might miss a point of your question. But to me it seems that what you suggest is conceptionally not possible.</p>

<p>Lightning payments work fundamentally different than Bitcoin transactions. In particular lightning payments themselfes don't have any Bitcoin script inside them. The onion format for the payment is really just an amount, a payment hash and a next hop.</p>

<p>The lightning nodes themselves use the data from the onion to construct htlc outputs in their respective local channels (commitment transactions) this is where Bitcoin transactions are used to fulfill the contracts needed for lightning. The sender however has no influence on the used scripts. So there is no way to squeeze in any OP_CODES </p>

CC BY-SA 4.0
2019-02-13T12:22:20.007Z
You could design a lightning-like protocol that adds op_return outputs in each commitment tx, all else being equal.
James C.
CC BY-SA 4.0
2019-02-13T09:43:46.833Z
2019-02-13T09:43:46.833Z
Rene Pickhardt
<p>To add to Rene's answer, it is possible to send some additional data with a Lightning payment which does not require any bitcoin script.</p>

<p>A recent update to LND allows additional data to be embedded in an Onion packet in a field called an <a href="https://github.com/lightningnetwork/lightning-onion/pull/31" rel="nofollow noreferrer">Extra Onion Blob</a>. The data which can be added is limited by size, and the size depends on the route size used to make the payment. The smaller the route, the more data you can fit in, because the EOB makes use of otherwise unused onion hops in the fixed-size onion packet. In practice this means tens of bytes of data, and perhaps a little bit more than the 80 byte limit of an OP_RETURN. Currently, the EOB is only used for spontaneous payments, but it will support embedding of other kinds data with a type-length-value.</p>

<p>Unlike an OP_RETURN, which is broadcast, the data sent in an EOB will only reach a single destination. If you wish for multiple people to receive it, then you will need to send multiple payments. Lightning supports broadcast type information in its gossip protocol, which can be extended with extra data, but this is really reserved for transferring routing information and clients are free to ignore data beyond what is required, and causing spam over the broadcast network may find you frequently blacklisted.</p>

<p>An obvious next step would be to transfer <a href="https://ipfs.io/" rel="nofollow noreferrer">IPFS</a> handles, or bittorrent magnet links over EOBs, which would enable clients which support these other protocols to receive data of arbitrary length.</p>

CC BY-SA 4.0
2019-02-13T12:36:58.833Z
2019-02-13T12:36:58.833Z
Mark H
<p>As long as you pay a BTC fee for all the routing node incentives and the last layer in the onion routing includes a transaction with OP_RETURN, wouldn't that allow using OP_RETURN for various applications?</p>

<p>I realize the current implementations don't do this, but am I missing if there's anything that prevents it fundamentally?</p>

<p>Thanks!</p>

<p>(If the issue is that the local channel at the end won't keep track of OP_RETURN on next update, couldn't the last transaction include virtually opening a channel to the original node (the person who sent it originally) that is OP_RETURN-aware and thus would keep updating it?)</p>

CC BY-SA 4.0
2019-02-13T09:39:55.007Z
It's not in the current lightning specification to create OP_RETURN outputs but there is nothing that prevents a similar payment channel protocol to include this. The OP_RETURN in subsequent channel states would have to be valid according to your protocol/application. What do you mean with the local channel not keeping up with OP_RETURN and the last transaction opening a channel to the original node?
James C.
<blockchain><lightning-network><op-return><lightning-network-daemon><tokens>
Is there anything preventing Lightning Network from passing embedded data in OP_RETURN?
Cloud Strife
# Is there anything preventing Lightning Network from passing embedded data in OP_RETURN?

(Asked by: username_0 on 2019-02-13)

As long as you pay a BTC fee for all the routing node incentives and the last layer in the onion routing includes a transaction with OP\_RETURN, wouldn't that allow using OP\_RETURN for various applications?

I realize the current implementations don't do this, but am I missing if there's anything that prevents it fundamentally?

Thanks!

(If the issue is that the local channel at the end won't keep track of OP\_RETURN on next update, couldn't the last transaction include virtually opening a channel to the original node (the person who sent it originally) that is OP\_RETURN-aware and thus would keep updating it?)

**Tags:** blockchain, lightning-network, op-return, lightning-network-daemon, tokens

> **Comments:**
> **username_1**: It's not in the current lightning specification to create OP_RETURN outputs but there is nothing that prevents a similar payment channel protocol to include this. The OP_RETURN in subsequent channel states would have to be valid according to your protocol/application. What do you mean with the local channel not keeping up with OP_RETURN and the last transaction opening a channel to the original node?  

---

## 2 answers

### Answer by username_2 on 2019-02-13. Score: 2

Not sure if I might miss a point of your question. But to me it seems that what you suggest is conceptionally not possible.

Lightning payments work fundamentally different than Bitcoin transactions. In particular lightning payments themselfes don't have any Bitcoin script inside them. The onion format for the payment is really just an amount, a payment hash and a next hop.

The lightning nodes themselves use the data from the onion to construct htlc outputs in their respective local channels (commitment transactions) this is where Bitcoin transactions are used to fulfill the contracts needed for lightning. The sender however has no influence on the used scripts. So there is no way to squeeze in any OP\_CODES

> **Comments:**
> **username_1**: You could design a lightning-like protocol that adds op_return outputs in each commitment tx, all else being equal.  

---

### Answer by username_3 on 2019-02-13. Score: 0

To add to username_2's answer, it is possible to send some additional data with a Lightning payment which does not require any bitcoin script.

A recent update to LND allows additional data to be embedded in an Onion packet in a field called an [Extra Onion Blob](https://github.com/lightningnetwork/lightning-onion/pull/31). The data which can be added is limited by size, and the size depends on the route size used to make the payment. The smaller the route, the more data you can fit in, because the EOB makes use of otherwise unused onion hops in the fixed-size onion packet. In practice this means tens of bytes of data, and perhaps a little bit more than the 80 byte limit of an OP\_RETURN. Currently, the EOB is only used for spontaneous payments, but it will support embedding of other kinds data with a type-length-value.

Unlike an OP\_RETURN, which is broadcast, the data sent in an EOB will only reach a single destination. If you wish for multiple people to receive it, then you will need to send multiple payments. Lightning supports broadcast type information in its gossip protocol, which can be extended with extra data, but this is really reserved for transferring routing information and clients are free to ignore data beyond what is required, and causing spam over the broadcast network may find you frequently blacklisted.

An obvious next step would be to transfer [IPFS](https://ipfs.io/) handles, or bittorrent magnet links over EOBs, which would enable clients which support these other protocols to receive data of arbitrary length.


---

