BIP-374は、BIP-352で定義されているサイレントペイメント↓において、複数の署名者がいる場合に有用な機能になる。

techmedia-think.hatenablog.com

サイレントペイメントでは、

• 受信者は支払いを受け取るための一意のサイレントペイメントアドレスを公開し、
• 送金者は受信者のサイレントペイメントアドレスの鍵と自身の鍵を使ってECDHを実行し、支払先のアドレスを導出する（つまり送金者はトランザクションのインプットの署名に使った秘密鍵と同じ秘密鍵を使って支払先のアドレスを導出する）

ことで、公開するアドレスは1つのまま、支払に使用されるアドレスは毎回異なり、アドレスの再利用を防ぐことができる。

BIP-374の使いどころは、サイレントペイメントのトランザクションを作成する際に、複数の署名者（送金者）がいるケース。正直なユーザーがトランザクションのインプットと同じ秘密鍵を使って支払先のアドレスを導出したとしても、別のユーザーが署名に使用した秘密鍵とは異なる秘密鍵を使って支払先を導出した場合、その受信者はコインを受け取ることができない。

このような状況を回避するために、トランザクションの署名に使われた秘密鍵と支払先のアドレスの導出に使われた秘密鍵が同じであることを、秘密鍵を明らかにすることなく証明、検証する。

DLEQ証明の生成

証明者は、楕円曲線のベースポイントG、別の点Bと秘密鍵a、ランダムなスカラー値kを使って証明を生成する。

サイレントペイメントの文脈では、

• トランザクションのインプットの署名用の秘密鍵がaで対応する公開鍵がA = aG、
• 点Bは受信者のサイレントペイメントアドレスから取得した公開鍵、
• C = aBが導出する支払先の公開鍵*1

で、AとCが同じスカラー値aを元に導出されていることを証明する。

証明者は、ランダムに選択したkを使って

1. R1 = kGを計算
2. R2 = kBを計算
3. e = H(R1 || R2)とし、
4. s = k + ea を計算する
5. e || s をプルーフとする（各32 byte、合計64 byte）

DLEQ証明の検証

プルーフとA, B, G, Cを受け取った検証者は、

1. R1 = sG – eAを計算し、
2. R2 = sB – eCを計算する。

正しく生成された値であれば、

• sG – aA = (k + ea)G – eA = kG + eaG – eA = kG + eA – eA = kG = R1
• sB – eC = (k + ea)B – eC = kB + eaB – eC = kB + eC – eC = kB = R2

となる。そして最後に、e == H(R1 || R2)が成立するか検証する。

プロトコル自体はPoDLEと大体同じ。

※ エラーチェックや、ランダムデータの取り扱い、オプションのメッセージなど詳細なプロトコルについてはBIPを参照。

元記事へのリンク