Schnorr 簽名如何在整個交易中聚合？
我正在研究 MuSig 協議，但無法掌握某些部分。這是我迄今為止的理解：
在目前的比特幣 CHECKMULTISIG 格式中，簽名的大小隨著額外的“m”個簽名者的數量線性增長。CHECKMULTISIG 的工作方式是每個簽名者產生自己獨立的簽名，我們將所有這些單獨的值嵌入到腳本中。因此，5 個解鎖腳本中的 3 個可能會讀取 [sig 1][sig 2][sig 5]…為簡單起見，我將所有單個 sig 值的編譯稱為“組簽名”。在給定的範例中，此簽名欄位將是標準 P2PKH 長度的 3 倍。
在“幼稚”的 Schnorr 多重簽名方案中，我們可以讓簽名者在預先承諾階段以互動方式將他們各自的公鑰相加，而不是將所有潛在的公鑰和 [更大的] 組簽名放到區塊鏈上以供驗證者計算“聚合”密鑰，與傳統公鑰同義。然後，外部成員可以將 BTC 發送到此聚合密鑰，由組成員控制。對於要花費的小組，每一方將使用他們唯一的個人密鑰創建一個部分簽名，並互動地將所有這些簽名值相加以創建一個小組簽名。此時，我們留下了一個組簽名（即基本 P2PKH sig 的大小）和附加到區塊鏈的聚合公鑰，為我們節省了大量空間。但是，除非在 KOSK 模型下執行，否則該方案是不安全的。我們轉向另一個 Schnorr 變體 MuSig，它可以提供可證明安全的密鑰聚合，同時在普通公鑰上下文中執行。
2018 年 Blockstream部落格文章指出：
我們實際上可以為整個交易獲取一個簽名，而不是將自己限制為每個輸入一個簽名。密鑰聚合不能用於多個輸入，因為公鑰由輸出送出，並且可以獨立使用。
我無法理解這一段。我猜測必須在腳本中引用每個聚合密鑰，因為前一個發件人的 scriptpubkey 會強制證明以解鎖產權負擔。我很難理解跨多個輸入部分的聚合簽名是如何完成的。
這是我們目前使用的數字簽名方案 (ECDSA) 中不存在的 Schnorr 數字簽名 (ECSDSA) 的一個功能。您不應該將兩種多重簽名方案一起比較，目前的設計是一種解決方法。
Schnorr 允許您通過在簽名過程中組合私鑰/公鑰並基於它們生成單個簽名 (r,s) 來將多個簽名“聚合”為僅*一個簽名。*因此，您應該在 Schnorr 交易 scriptSig 中只看到一個簽名和一個公鑰，並且輸出腳本 (scriptPubkey) 也應該只使用一個公鑰。
查看簡化集體簽名方案的答案，以大致了解我們如何只有一個簽名/公鑰，MuSig 在此過程中添加了一些額外的步驟以防止某些攻擊。
注意： 這是一個擴展評論，但太長了。很遺憾，我不能直接回答你的問題。
但只是為了確保您了解 Schnorr 提案中的差異（因為您的問題實際上與 MuSig 無關）：
Schnorr 簽名具有三個“級別”的簽名操作。
- 內部腳本本身（例如使用 MuSig 在腳本中聚合其簽名），
- 在塊驗證中，Schnorr 允許在塊內對其簽名進行批量驗證。這比單獨驗證簽名要快得多，
- 在事務中，Schnorr 允許聚合來自同一事務中不同輸入的簽名。
你的問題是關於第 3 點的，據我所知，BIP 尚未正式化，仍在開發中。
如果您還沒有看過這篇博文，底部還有很多很好的參考資料。