Is there anything preventing Lightning Network from passing embedded data in OP_RETURN?

Question

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?)

Answer 1

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

Answer 2

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.

A recent update to LND allows additional data to be embedded in an Onion packet in a field called an Extra Onion Blob. 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 handles, or bittorrent magnet links over EOBs, which would enable clients which support these other protocols to receive data of arbitrary length.