本周的通訊介紹了對短暫錨點（ephemeral anchor）提案的更新，並提供了來自 Wizardsardine 的開發人員的有關 Miniscript 的貢獻領域報告。還包括每期固定內容，宣布新的軟體發布和發布候選版本，並總結了一些流行的比特幣基礎設施項目的重大變化。

News

消除短暫錨點 spend 中的可篡改性：Gregory Sanders 在 Delving Bitcoin 論壇上發布了一項對短暫錨點提案的微調。該提案允許交易包含一個零價值輸出和一個任何人都能 spend 的輸出腳本。由於任何人都可以 spend 輸出，因此任何人都可以使用 CPFP 費用提升創建輸出的交易。這對於多方合約協議（如 LN）非常方便，因為交易經常在準確預測應支付的費率之前簽名。短暫錨點允許合約的任何一方添加他們認為必要的費用。如果任何其他方或任何其他用戶出於任何原因想要添加更高的費用，他們可以用自己的更高費率的 CPFP 費用提升替換原始的 CPFP 費用提升。

建議使用由等效於 OP_TRUE 的輸出腳本組成的任何人都能 spend 腳本的類型，它可以由具有空輸入腳本的輸入 spend。正如 Sanders 本周發布的那樣，使用傳統的輸出腳本意味著 spend 它的子交易具有可篡改的 txid，例如，任何礦工都可以向輸入腳本添加數據以更改子交易的 txid。這可能使得除了費用提升之外，不明智地使用子交易，因為即使能夠確認，也可能會是以使任何孫交易（grandchild transactions）無效的不同 txid 得到確認。

Sanders 建議改用為未來 segwit 升級保留的輸出腳本之一。雖然這會略微增加塊空間，對於 segwit 來說是四個字節，而對於 OP_TRUE 來說是一個字節，但它消除了對交易可篡改性的所有擔憂。在該主題基礎上進行了一些討論後，Sanders 隨後提議提出兩點：一個適用於不關心可篡改性且希望最小化交易大小的 OP_TRUE 版本，以及一個略大但不允許子交易發生變化的 segwit 版本。主題中的其他討論集中在選擇用於 segwit 方法的額外字節，以創建一個值得記住的 bech32m 地址。

領域報告：Miniscript 之旅

我們對 Miniscript 的興趣始於 2020 年初，當時我們正在設計 Revault，這是一種僅使用當時可用的腳本原語的多方保險庫架構。

最初，我們展示了 Revault，使用了一組固定的參與者。當我們試圖將其推廣到生產環境中的更多參與者時，我們很快遇到了問題。

實際上，我們懷疑我們在演示中使用的腳本是安全的嗎？它是否可以以它宣傳的所有方式 spend？除了這些宣傳方式外，是否有其他方式 spend？

即使是這樣，我們如何將其推廣到不同的參與者並保持安全？如何做出一些優化，並確保生成的腳本具有相同的語義？

此外，Revault 正在使用預簽名的交易（以強制執行 spend 政策）。如何事先知道根據腳本的配置為費用提升分配的預算？如何確保 spend 這些腳本的任何交易都通過最常見的標準性檢查？

最後，即使假設我們的腳本符合預期的語義並且始終可 spend，我們如何具體 spend 它們？也就是說，我們如何為每種可能的配置生成令人滿意的見證（「簽名」）？如何使硬體簽名設備與我們的腳本兼容？

如果沒有 Miniscript，這些問題本應是一個阻礙因素。車庫的兩個人不會編寫一個可以臨時創建腳本的軟體，最重要的是，稱其為增強安全性的比特幣錢包。我們想要圍繞 Revault 的開發創建一家公司，但如果不能向投資者提供我們能夠推出安全產品的有效保證，我們將無法獲得資金。而沒有資金，我們將無法解決所有這些工程問題。

Miniscript 應運而生，「一種以結構化方式編寫（Bitcoin 腳本子集的）語言，支持分析、組合、通用簽名等。它具有一種允許組合的結構。對於各種屬性（spend 條件、正確性、安全性質、可篡改性等）進行靜態分析非常容易。」這正是我們需要的。憑藉這個強大的工具，我們可以向我們的投資者提供更好的保證，從而籌集資金，並開始開發 Revault。

當時，Miniscript 距離成為任何比特幣應用程序開發人員可用的即插即用解決方案還有很長的路要走。（如果您是在 2023 年之後閱讀此文的新比特幣開發人員，要知道我們曾經需要用手寫比特幣腳本。）我們不得不將 Miniscript 集成到 Bitcoin Core 中（參見 PRs＃24147、＃24148 和＃24149），我們將其用作 Revault 錢包的後端，並說服簽名設備製造商在其固件中實現它。事實證明後者是最困難的部分。

這是一個先有雞還是先有蛋的問題：製造商在沒有用戶需求的情況下實施 Miniscript 的動力較低，而且沒有簽名設備的支持，我們無法發布 Revault。幸運的是，這個循環最終在 2021 年 3 月由 Stepan Snigirev 打破，他為 Specter DIY 引入了對 Miniscript 描述符的支持。然而，Specter DIY 很長一段時間被稱為僅僅是一個「功能原型」，Salvatore Ingala 在 2022 年首次將 Miniscript 引入到 Ledger Nano S(+) 的新比特幣應用中，這一應用於 2023 年 1 月發布，使我們能夠推出支持最受歡迎簽名設備的 Liana 錢包。

我們的 Miniscript 之旅還剩下一個發展。Liana 是一個專注於恢複選項的比特幣錢包。它允許用戶指定一些有時間鎖定的恢復條件（例如，第三方恢復密鑰通常無法 spend 資金，或者是一個逐漸擴展的多簽）。最初 Miniscript 僅適用於 P2WSH 腳本。不幸的是，在 Taproot 激活近 2 年後，每次 spend 時都必須在鏈上發布恢復路徑。為此，我們一直在努力將 Miniscript 移植到 Tapscript。

隨著大多數簽名設備已經實施或正在實施 Miniscript 支持（例如最近的 Bitbox 和 Coldcard），以及 Taproot 和 Miniscript 本地框架的不斷完善，使用安全基元在比特幣上進行合約更加容易。

有趣的是，開源工具和框架的資金支持降低了創新公司競爭的門檻，即促使項目的實施。過去幾年這一趨勢加速發展，讓我們對這個領域的未來充滿希望。

當然還存在風險，但至少我們有信心能夠解決鏈上的部分。預料之外的是，鏈下部分證明更具挑戰性。

版本發布和候選版本

以下是一些熱門比特幣基礎設施項目的新版本和候選版本，請考慮升級到新版本或幫助測試候選版本。

LND 0.17.1-beta 是這個閃電網路節點實現的維護版本，包括一些錯誤修復和小的改進。

Bitcoin Core 26.0rc2 是這個主要全節點實現的下一個主要版本的候選版本。有一個測試指南，以及定於 2023 年 11 月 15 日的比特幣核心 PR 審查俱樂部專注於測試的預定會議。

Core Lightning 23.11rc1 是這個閃電網路節點實現的下一個主要版本的候選版本。

代碼和文檔變更

Bitcoin Core、Core Lightning、Eclair、LDK、LND、libsecp256k1、硬體錢包接口（HWI）、Rust Bitcoin、BTCPay Server、BDK、比特幣改進提案（BIPs）、閃電 BOLTs 以及比特幣審訊中的一些顯著變更。

Bitcoin Core #28207 更新了磁盤上儲存內存池的方式（通常發生在節點關閉期間，但也可以通過 savemempool RPC 觸發）。先前，它是以基礎數據的簡單序列化形式儲存的。現在，該序列化結構會被每個節點獨立生成的隨機值進行異或運算，以混淆數據。在加載期間，使用相同的值進行異或運算以消除混淆。混淆防止有人能夠在交易中放入某些數據，以使特定的字節序列出現在保存的內存池數據中，這可能導致病毒掃描程序等程序將保存的內存池數據標記為危險。相同的方法之前已應用於在 PR #6650 中儲存 UTXO 集。任何需要從磁盤讀取內存池數據的軟體都應該可以輕鬆地應用 XOR 操作本身，或使用配置設置 -persistmempoolv1 以請求以未混淆的格式保存。請注意，向後兼容的配置設置計劃在將來的版本中刪除。

LDK #2715 允許節點選擇性地接受比應該交付的較小值的 HTLC。當上游對等方通過新的 JIT 通道支付節點時，這是有用的，該通道會對上游對等方產生一筆在鏈上的交易費用，他們希望從支付給節點的 HTLC 金額中扣除。

原文連結