發生什麼：Optech 介紹 OCEAN 閃電派彩的示範錢包
比特幣技術週報 Bitcoin Optech 於 2026 年 10 月 23 日出刊的第 428 期，在服務與客戶端更新欄介紹 Landfall。週報形容它是一個概念驗證錢包，用來展示今天就能做到的使用體驗：從單一種子推導出 OCEAN 礦池以閃電網路支付獎勵時要求的派彩地址、BOLT12 offer 與 BIP-322 簽章，閃電節點則由 Lexe 代管，並註明它不打算用於正式環境。
Landfall 原始碼以 AGPL-3.0 授權放在開發者 vincenzopalazzo 的 GitHub 帳號下。依 GitHub 紀錄，原始碼庫建立於 2026 年 4 月，最近一次提交是 10 月 8 日的 v0.3.2 版本提交；GitHub 上也沒有建立正式 Release。
OCEAN 要什麼、Landfall 怎麼做
依 Landfall README 的說明，礦工要讓 OCEAN 改用閃電網路派彩，需要交出三樣東西：挖礦時使用的 bc1q 派彩地址；一個可重複收款的 BOLT12 offer（lno1 開頭）；以及一個 BIP-322 簽章，證明控制派彩地址的人確實要求把獎勵付到這個 offer。README 指出，三者合起來要求礦工自己跑閃電節點、持有比特幣私鑰、使用多數錢包不支援的訊息簽章標準，還要在三處之間複製長字串，任何細節不符都會在最後被拒。
Landfall 的做法是讓一組 24 字助記詞同時扮演三個角色：在本機以 BIP-84 路徑 m/84'/0'/0'/0/0 推導派彩地址；同一組助記詞作為 Lexe 閃電節點的根種子，由該節點產生可收款的 BOLT12 offer，README 稱節點跑在安全飛地中、鑰匙由礦工掌握；最後把 OCEAN 產生的驗證訊息逐字簽名，並顯示簽了什麼、用哪個地址。README 說明，Landfall 之所以要自己在本機簽，是因為 Lexe SDK 不能簽訊息。
README 也界定簽章的範圍：它只證明地址持有人同意這段包含 offer 的訊息，不會移動資金或授權其他事；換一個字元驗證就失敗，因此不能挪用到別的 offer。工具另提供 verify 指令，不需助記詞與網路即可做與 OCEAN 相同的檢查，以及讀取 Lexe 節點中符合 OCEAN 派彩格式的入帳紀錄。
限制：明文助記詞、無稽核，簽章格式剛修過
作者在 README 開頭以粗體警告：Landfall 是展示品而不是正式錢包，只跑在比特幣主網，助記詞以明文檔存放在執行它的機器上（檔案權限限擁有者讀寫）。作者建議只用來收取並花用 OCEAN 派彩，不要存放大額餘額，也不要把重要錢包的助記詞匯入；它沒有安全稽核、發版時程或支援，若有足夠需求，OCEAN 或許會考慮接手維護。
另一個值得注意的細節是相容性。10 月 8 日的 v0.3.2 提交說明，先前在升級 bip322 函式庫後，Landfall 產生的每個簽章都多帶了一個 smp 前綴，OCEAN 會以「signature check failed」拒收；修正後改輸出 OCEAN 預期的純 Base64 見證資料。這顯示 BIP-322 在不同實作間的編碼細節仍可能卡住使用者。
AI 觀點分析與推論
AI 觀點：真正該被借鏡的是流程，不是這個錢包
我傾向認為，Landfall 的意義不在於礦工該不該用它，而在於它把 OCEAN 閃電派彩的真正門檻講清楚了：不是閃電網路本身，而是 BIP-322 訊息簽章這一步幾乎沒有主流錢包支援。只要有錢包把「同一種子產生地址與 offer、逐字簽訊息」做成內建流程，小礦工改用閃電收小額派彩的摩擦就會大幅降低。
受益的是收款金額小、不想等鏈上派彩門檻的家用或小型礦工；受影響的是仍要求礦工自己拼湊工具的流程。反面情境是：若主流錢包始終不支援 BIP-322，或礦工對 Lexe 這類代管飛地節點的信任模型有疑慮，這套流程可能停在示範階段。若之後有硬體錢包或主流行動錢包加入 OCEAN 專用的簽章流程，或 OCEAN 自己接手維護 Landfall，我會認為閃電派彩正走向一般礦工可用；若一段時間後仍只有這類展示專案，則它比較像少數技術用戶的選項。
