是否有任何東西阻止閃電網路在 OP_RETURN 中傳遞嵌入數據？
只要你為所有的路由節點獎勵支付BTC費用，並且洋蔥路由的最後一層包含一個帶有OP_RETURN的交易，那不是允許在各種應用程序中使用OP_RETURN嗎？
我意識到目前的實現並沒有這樣做，但是如果有什麼從根本上阻止它，我會錯過嗎？
謝謝！
（如果問題是最後的本地通道不會在下次更新時跟踪 OP_RETURN，那麼最後一個事務是否不能包括虛擬打開一個通道到原始節點（最初發送它的人），即 OP_RETURN-知道並因此會繼續更新它嗎？）
不知道我是否會錯過你的問題。但對我來說，您的建議似乎在概念上是不可能的。
閃電支付的工作方式與比特幣交易根本不同。特別是閃電支付本身沒有任何比特幣腳本。支付的洋蔥格式實際上只是一個金額、一個支付雜湊和一個下一跳。
閃電節點本身使用來自洋蔥的數據在其各自的本地通道（承諾交易）中建構 htlc 輸出，這是使用比特幣交易來履行閃電所需的合約的地方。但是，發送者對使用的腳本沒有影響。所以沒有辦法擠入任何 OP_CODES
為了補充 Rene 的答案，可以使用不需要任何比特幣腳本的閃電支付發送一些額外的數據。
最近對 LND 的更新允許在稱為Extra Onion Blob的欄位中將附加數據嵌入到 Onion 數據包中。可以添加的數據受大小限制，大小取決於用於支付的路由大小。路由越小，您可以容納的數據就越多，因為 EOB 在固定大小的洋蔥數據包中使用了其他未使用的洋蔥跳。實際上，這意味著數十字節的數據，並且可能比 OP_RETURN 的 80 字節限制多一點。目前，EOB 僅用於自發支付，但它將支持嵌入具有類型-長度-值的其他類型數據。
與廣播的 OP_RETURN 不同，EOB 中發送的數據只會到達一個目的地。如果您希望多人接收它，那麼您將需要發送多筆付款。Lightning 在其 gossip 協議中支持廣播類型的資訊，可以通過額外的數據進行擴展，但這實際上是為傳輸路由資訊保留的，客戶端可以隨意忽略超出要求的數據，並且通過廣播網路引起的垃圾郵件可能會經常找到你列入黑名單。
一個明顯的下一步是通過 EOB 傳輸IPFS句柄或 bittorrent 磁力連結，這將使支持這些其他協議的客戶端能夠接收任意長度的數據。