Z-man 的 PTLC 建構是否可以使用 libsecp256k1-zkp 實現？
在郵件列表中Z-man 詳細介紹了一個 PTLC 結構，他聲稱這“幾乎完全是一種 MuSig 儀式”。我的問題是這個 MusigTweak 是否是 secp256k1-zkp 中所謂的
adaptor（最後一個參數secp256k1_musig_session_combine_nonces）？並且實際上已經實施了嗎？MusigTweak 是如何計算的？是否是每跳調整的支付點，這意味著它將成為連接到付款人的跳的支付點？
在某種程度上，這是沒有意義的，因為 MusigTweak 需要三個參數，而且兩個渠道合作夥伴的支付點是相同的。但另一方面，也許 Z-man 正在描述如何在 libsecp256k1-zkp 內部進行調整，我可以放心地將調整後的支付點用於雙方的
adaptor論點，因為實現將根據索引對適配器進行不同的處理簽名者的？
我的問題是這個 MusigTweak 是否是 secp256k1-zkp 中所謂的適配器（secp256k1_musig_session_combine_nonces 的最後一個參數）？
不，“Z-man”所指的 MusigTweak 在 secp256k1-zkp 中不稱為適配器。正常的 MuSig 儀式和“幾乎完全 MuSig”儀式之間的區別不是 MuSigTweak。MuSigTweak 僅確定密鑰的聚合方式，並在送出cad7cc8f34d17166da2dabae20188ea6e747ac69
secp256k1_musig_coefficient的 secp256k1-zkp 實現中呼叫。在 MuSig 論文中，MuSigTweak 被稱為. secp256k1_musig_session_combine_nonces 的適配器參數是指Z-man 的描述中的（基點在哪裡）。a_i``t*G``G並且實際上已經實施了嗎？
是的，差不多。Z-man 在這裡描述的是原始適配器簽名方案。它不太適合多跳鎖（又名帶有支付點的閃電），因為創建方
t在創建適配器簽名時必須知道。因此，libsecp256k1-zkp 中的實現使用了適配器簽名變體，該變體在原始Lightning in Scritpless Script郵件列表文章和用於區塊鏈可擴展性和互操作性的匿名多跳鎖論文中引入。如果您想了解更多關於多跳鎖定協議的資訊，我建議您查看無腳本腳本 repo中的圖表。libsecp256k1-zkp對使用該技術的無腳本腳本原子交換進行了單元測試。
MusigTweak 是如何計算的？是否是每跳調整的支付點，這意味著它將成為連接到付款人的跳的支付點？
適配器點
t*G是每跳調整的支付點，而不是 MuSigTweak。