全文

固定收款資訊，不必等於固定鏈上地址

BIP352 的 Silent Payments 讓公開收款資訊與實際鏈上輸出分開，接收者透過掃描找出屬於自己的付款。這項設計想減少反覆公開同一收款地址造成的連結，但不代表所有交易資訊都隱藏。理解它時，可以把公開的聯絡方式與每次交付的位置分開：外界知道如何付款，不必直接看到所有付款都指向同一地址。代價是錢包需要處理辨識收款的工作；方便分享收款資訊，與方便恢復、同步和辨識餘額，是不同的產品問題。

共同簽名之外，還要共同驗證計算

十月三十日的 Optech 週報介紹一項多方錢包提案，將各簽署者的計算貢獻組合成可驗證的結果。它關心的不只是誰批准支出，也包括接收者能否找到那筆錢。假設一間組織由兩個部門共同管理付款，兩邊都看過金額，卻只相信協調者給出的最終收款輸出，仍可能漏掉中間計算是否正確。這是假設的審批情境，不是已發生事故。本站的分析是，顯示相同付款金額與證明計算一致，必須分別驗收，不能只用簽名數量代表全部安全性。

證明要綁定這一次協作

原提案以 AggDLEQ 聚合證明，並把簽署者、交易與工作階段等脈絡帶進協作流程。對非密碼學讀者而言，可以把它理解為不能只拿到一張「算過了」的證明，還要知道證明的是哪一次工作。假設兩筆同額付款同時進行，僅靠金額標記就無法充分區分它們；參與者與目標不同，也不能互換資料。這個例子只解釋脈絡綁定的必要性，不是重現提案方程式。工程驗證還須測試中止、重新開始與部分參與者失聯時，介面是否會把未完成的流程誤報為成功。

相容性是進展，安全性仍有待審查

提案作者指出，部分聯合不可偽造性論證依賴難度尚未解決的假設；討論串也保留了符號修正。這些都表示它應被當作待審查研究，而非所有錢包已具備的成熟功能。評估新方案時，可以分開看三份證據：格式能否互通、實作是否依規格執行，以及安全主張是否成立。某個測試付款成功，只能回答其中一小部分。對一般使用者，值得追蹤的是正式審查與明確產品支援；對開發者，則是讓相容性展示、失敗測試與安全假設各自可檢驗，避免用單一成功畫面取代完整驗證。