強制披露私鑰的比特幣腳本
上下文：我正在創建一個範常式式碼，用於展示 Elements 和比特幣之間的原子交換，目的是不能像簡單的HTLC 那樣簡單地連結交換交易，您可以在其中查找相同的雜湊/原像兩條鏈。這是因為要披露的密鑰實際上是密鑰的總和，(A+B)，並且為了聲明交換的另一方，使用了另一個總和密鑰，(A+C)。A、B 和 C 只有（一個或兩個）參與者知道。
我在 Elements 端使用 CHECKSIGFROMSTACK 來強制對方創建具有固定 R 值的簽名（k 是已知的，因此對方可以恢復密鑰）
我被指到<https://bitcointalk.org/index.php?topic=321228.msg13072047#msg13072047>，其中 gmaxwell 告訴您可以實現在未修改的比特幣上強制公開密鑰的相同效果。
他說他知道在未修改的比特幣上實現這一目標的兩種方法，其中之一是：
OP_SIZE 57 OP_LESSTHANOREQUAL OP_VERIFY <P> OP_CHECKSIGVERIFY我的問題：
- 在上面列出的腳本中，簽名的長度被強制小於或等於 57。這似乎依賴於已知的小 R 值，並且假設對於某些已知 k 大小相等或更小的其他 R 值在計算上是不可能的找到。
在這篇文章中<https://crypto.stackexchange.com/questions/60420/what-does-the-special-form-of-the-base-point-of-secp256k1-allow>給出了一個具有 90 個前導零位的 R 值. S 的大小需要 <= 29 字節，R 的長度為 21 字節（166 位），以使簽名符合 57 字節的限制（29+21+6+1=57）。為了使用這個已知的小 R 來滿足這個腳本，簽名的創建者需要搜尋要簽名的消息，這將導致 len(S) <= 29 的簽名。選擇這個嚴格的限制是為了減少“擺動空間”用於暴力破解 R ？
- 在未修改的比特幣上實現此目的的第二種方法是什麼？
- 如果這些方法有效，為什麼它們沒有被廣泛使用而不是 HTLC 構造，因為這些方法（或至少是所提出的方法）在實現方面並不復雜，但更私有（因為沒有公共共享雜湊/原像）？與 HTLC 相比，這些方法的缺點是什麼？
（注意：上面的問題更多是出於求知欲，而不是出於具體的實際目的，因為當 Schnorr 簽名將在比特幣上啟用時（我希望不會太長），適配器簽名https://github.com/apoelstra /scriptless-scripts/blob/master/md/atomic-swap.md將是創建原子交換的更好方法，而事務之間沒有微不足道的連結）
我已經進行了一些搜尋和研究，並且我還在 bitcoincore slack 的#elements 頻道上獲得了輸入，所以我覺得我現在可以回答這些（編輯：起初我對 CODESEPARATOR 方法感到困惑，但過了一段時間，我問 Anthony Towns，他在 Lighting-dev 列表中提供了他的消息的連結來解釋它。）
- 我認為選擇大小 57 是為了增加對找到其他小尺寸 R 值的可能性的保證，即大於 21 字節，但足夠小，以至於磨削較小的 S 可以克服大小限制。我還看到瞭如何使用這種技術的其他範例（<https://gist.github.com/nothingmuch/683042343c48a4ef07efd3d438e7ee56>），但它為大小限制設置了 60。可能假設以 72 個零位開頭的 R 值也不可行。也可能是57字節的限制是不必要的小。請注意，len(S) <= 29 的研磨在通用電腦上是可行的。這可以通過更改交易的其他輸入/輸出來完成，從而使 sighash 發生變化。相關的：<https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html>
- 在未修改的比特幣上實現此目的的第二種方法可能涉及到使用 OP_CODESEPARATOR。一個公鑰會有兩個簽名，但第二個簽名將使用不同的 sighash，因為在執行 CODESEPARATOR 後會檢查此簽名，並且將僅使用 CODESEPARATOR 之後的腳本部分計算 sighash。但是，雖然您可以為一個 pubkey 擁有兩個不同的簽名（在不同的消息上），但我不清楚如何在此處強制重用 nonce，如果不是使用與前面描述的相同的大小技巧，或者使用禁用的操作碼。
編輯：向 Anthony Towns 詢問此事，得到答复。有一種使用兩個程式碼分隔符和三個 checkmultisigs 的技術，以強制重用 R 的方式。請參閱<https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html>和https:// lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000363.html
其他相關連結：https ://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-December/016594.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-December/016592.html>我的實驗腳本：https ://gist.github.com/dgpv/7818a4009f4e90868c0920cc1e238653
請注意，CODESEPARATOR 對於比特幣中的非隔離見證輸入是非標準的，但對於隔離見證輸入應該是可以的。但仍然存在一些爭議：https : //lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016732.html（有人提議完全刪除 CODESEPARATOR，或者總是使用初始腳本計算 sighash，忽略CODESEPARATOR 的效果）
- HTLC 實現起來更簡單，創建 HTLC 的程序不需要能夠使用 bignums，以及具有在 bignums 上實現模逆的功能。HTLC 的尺寸通常也會更小。它們也更“知名”，因此很受歡迎。