特許7451797即時オフラインのブロックチェイントランザクションのセキュリティを高めるのに適しているコンピュータにより実装されるシステム及び方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-03-08
(45)【発行日】2024-03-18
(54)【発明の名称】即時オフラインのブロックチェイントランザクションのセキュリティを高めるのに適しているコンピュータにより実装されるシステム及び方法
(51)【国際特許分類】
H04L 9/32 20060101AFI20240311BHJP
G06Q 20/06 20120101ALI20240311BHJP
【ＦＩ】
H04L9/32 200C
G06Q20/06 300
【請求項の数】
15
【外国語出願】
(21)【出願番号】P 2023036708
(22)【出願日】2023-03-09
(62)【分割の表示】P 2020554473の分割
【原出願日】2019-03-25
(65)【公開番号】P2023071977
(43)【公開日】2023-05-23
【審査請求日】2023-03-09
(31)【優先権主張番号】1806112.7
(32)【優先日】2018-04-13
(33)【優先権主張国・地域又は機関】GB
(73)【特許権者】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】トレヴェサン，トーマス
【審査官】中里 裕正
(56)【参考文献】
【文献】特開平３－７３０６５（ＪＰ，Ａ）
【文献】特表平４－５００４４０（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１７／００６１３９６（ＵＳ，Ａ１）
【文献】PEREZ-SOLA, C. et al.，Double-spending Prevention for Bitcoin zero-confirmation transactions，Cryptology ePrint Archive，Papar 2017/394，[online]，2017年05月09日，pp.1-19，https://eprint.iacr.org/2017/094
【文献】RUFFING, T., KATE, A. and SCHRODER, D.，Liar, Liar, Coins on Fire!: Penalizing Equivocation by Loss of Bitcoins，Proceedings of th 22nd ACM SIGSAC Conference on Computer and Communications Security，2015年10月，pp.219-230
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ ９／３２
Ｇ０６Ｑ ２０／０６
ＪＳＴＰｌｕｓ／ＪＭＥＤＰｌｕｓ／ＪＳＴ７５８０（ＪＤｒｅａｍＩＩＩ）
ＩＥＥＥ Ｘｐｌｏｒｅ
ＴＨＥ ＡＣＭ ＤＩＧＩＴＡＬ ＬＩＢＲＡＲＹ
(57)【特許請求の範囲】
【請求項1】
暗号プロトコルを実装するためのコンピュータにより実装される方法であって、当該コンピュータにより実装される方法は、第1の公開鍵(PK1)及び第1の秘密鍵(sk1)を含む第1の暗号鍵対を生成するステップと、
第2の公開鍵(PK2)及び第2の秘密鍵(sk2)を含む第2の暗号鍵対を生成するステップと、
前記第1の秘密鍵及び第2の秘密鍵(sk1;sk2)から補償鍵(ck)を構築するステップであって、前記補償鍵(ck)は、前記第1の秘密鍵(sk1)が公開された場合に、前記第2の秘密鍵(sk2)を計算することを可能とする、ステップと、
前記第1の秘密鍵(sk1)が公開された場合に、前記補償鍵(ck)が、前記第2の秘密鍵(sk2)を計算することを可能とするという暗号証明を構築するステップであって、前記暗号証明は、前記第1の秘密鍵及び第2の秘密鍵(sk1;sk2)が公開されることを必要としない、ステップと、
前記第1の秘密鍵(sk1)が公開された場合に、前記第2の秘密鍵(sk2)を計算することができるように、前記暗号証明が前記補償鍵(ck)を検証するということを確認するステップと、を含み、
それにより、前記第1の秘密鍵(sk1)を公開する情報が開示された場合に、
前記第1の秘密鍵(sk1)及び前記補償鍵(ck)から前記第2の秘密鍵(sk2)を計算し、
前記第2の秘密鍵(sk2)を使用して、前記第2の公開鍵(PK2)と関連する暗号資産にアクセスする、
コンピュータにより実装される方法。
【請求項2】
前記第2の公開鍵(PK2)と関連する暗号資産は、ロック時間Tの間、時間ロックされ、それにより、前記ロック時間Tが満了した後にのみ、前記暗号資産にアクセスすることが可能である、請求項1に記載のコンピュータにより実装される方法。
【請求項3】
前記暗号証明は、非対話型ゼロ知識証明である、請求項1又は2に記載のコンピュータにより実装される方法。
【請求項4】
前記非対話型ゼロ知識証明は、フィアットシャミアの発見的問題解決の適用によって非対話型ゼロ知識証明に変換されるゼロ知識シグマ(Σ)プロトコルに基づいている、請求項3に記載のコンピュータにより実装される方法。
【請求項5】
前記補償鍵は、ck＝sk2・sk1 －1 mod n
によって計算され、
ckは、前記補償鍵であり、sk1は、前記第1の秘密鍵であり、sk2は、前記第2の秘密鍵であり、nは、前記第1の秘密鍵及び第2の秘密鍵から前記第1の公開鍵及び第2の公開鍵を生成するのに使用される楕円曲線基準点Gの次数であり、前記第1の公開鍵及び第2の公開鍵の生成は、前記楕円曲線基準点Gの楕円曲線点乗算を含む、請求項1乃至4のうちのいずれか1項に記載のコンピュータにより実装される方法。
【請求項6】
前記暗号証明は、安全な乱数rを生成すること、
コミットメントR＝r×Gを計算することであって、Rxは、点Rのx座標である、こと、
ハッシュH(Rx)を計算することであって、セットxは、H(R)のうち最も左のln個のビットであり、lnは、nのビット長さである、こと、
z＝sk1x＋rを計算すること、
によって構築され、
前記暗号証明は、タプルπ＝(ck,R,x,z)である、請求項5に記載のコンピュータにより実装される方法。
【請求項7】
検証器は、C＝ck×Gを計算し、
x＝最も左のln H(Rx) であり、
z×G＝x×PK1＋R であり、
z×G＝x×PK2＋ck×R である
ということを検証し、
確認される場合に、値ckを有効であるとして受け入れる、
ことによって、前記タプルを認証する、請求項6に記載のコンピュータにより実装される方法。
【請求項8】
資金調達トランザクションを構築するステップであって、前記資金調達トランザクションは、前記第1の公開鍵(PK1)及び前記第1の秘密鍵(sk1)と関連する支出出力と、前記第2の公開鍵(PK2)及び前記第2の秘密鍵(sk2)と関連する預金出力と、を含み、前記預金出力は、ロック時間Tの間、時間ロックされる、ステップと、ブロックチェーンに組み込むために、ブロックチェーンネットワークに前記資金調達トランザクションをブロードキャストするステップと、
購入トランザクションを構築するステップであって、前記購入トランザクションは、前記ブロックチェーンネットワークを介して、前記資金調達トランザクションの前記支出出力から検証器の決済アドレスへと、資金を転送し、前記購入トランザクションは、前記第1の秘密鍵(sk1)を使用して署名される、ステップと、
前記検証器に、前記購入トランザクション、前記第1の公開鍵及び第2の公開鍵(PK1;PK2)、前記補償鍵(ck)、及び前記暗号証明を送信するステップと、をさらに含む、請求項1乃至7のうちのいずれか1項に記載のコンピュータにより実装される方法。
【請求項9】
前記購入トランザクション、前記第1の公開鍵及び第2の公開鍵(PK1;PK2)、前記補償鍵(ck)、及び前記暗号証明を受信するステップと、前記購入トランザクションが、前記第1の公開鍵(PK1)と関連する前記支出出力から前記決済アドレスへと転送される前記資金を正しく指定しているということを検査するステップと、
前記第2の公開鍵(PK2)と関連する前記預金出力が、必要とされる預金額を含んでいるということを検査するステップと、
前記暗号証明が、前記補償鍵(ck)を検証し、それによって、前記第1の秘密鍵(sk1)が公開された場合に、前記第2の秘密鍵(sk2)を計算することが可能であるということを検査するステップと、
前記購入トランザクションを認可し、前記ブロックチェーンネットワークに前記購入トランザクションをブロードキャストするステップと、
第2の競合する購入トランザクションが、前記ブロックチェーンネットワークにブロードキャストされ、前記ロック時間Tが満了する前に、前記資金調達トランザクションの前記支出出力からの資金を支出する場合に、
前記購入トランザクション及び第2の購入トランザクションの署名から前記第1の秘密鍵(sk1)を計算するステップと、
前記第1の秘密鍵(sk1)及び前記補償鍵(ck)から前記第2の秘密鍵(sk2)を計算するステップと、
前記資金調達トランザクションの前記預金出力から前記ブロックチェーンのアドレスに資金を転送するトランザクションを構築するステップと、
前記第2の秘密鍵(sk2)を使用して前記トランザクションに署名するステップと、
前記ブロックチェーンネットワークに前記トランザクションをブロードキャストし、それによって、前記ロック時間Tが満了した後に、ベンダーによって、前記資金調達トランザクションの前記預金出力における前記資金を取得することが可能である、ステップと、をさらに含む、請求項8に記載のコンピュータにより実装される方法。
【請求項10】
前記支出出力は、前記支出出力から資金を転送することが、固定の一時的な鍵(k)に基づくトランザクション署名を必要とするように構成される、請求項8又は9に記載のコンピュータにより実装される方法。
【請求項11】
前記支出出力は、fixed-r-pay-to-public-key (FR-P2PK)出力であり、それによって、前記支出出力から資金を転送することは、あらかじめ指定されているr値を利用するトランザクション署名を必要とする、請求項10に記載のコンピュータにより実装される方法。
【請求項12】
前記預金出力は、前記支出出力よりも大きい、請求項8乃至11のうちのいずれか1項に記載のコンピュータにより実装される方法。
【請求項13】
コンピュータ実行可能な命令を含むコンピュータ読み取り可能な記憶媒体であって、前記コンピュータ実行可能な命令は、実行されるときに、請求項1乃至12のうちのいずれか1項に記載の方法を実行するように1つ又は複数のプロセッサを構成する、コンピュータ読み取り可能な記憶媒体。
【請求項14】
電子デバイスであって、インターフェイスデバイスと、
前記インターフェイスデバイスに結合される1つ又は複数のプロセッサと、
前記1つ又は複数のプロセッサに結合されるメモリと、を含み、前記メモリは、コンピュータ実行可能な命令を格納し、前記コンピュータ実行可能な命令は、実行されるときに、請求項1乃至12のうちのいずれか1項に記載の方法を実行するように前記1つ又は複数のプロセッサを構成する、
電子デバイス。
【請求項15】
ブロックチェーンネットワークの中のノードであって、当該ノードは、請求項1乃至12のうちのいずれか1項に記載の方法を実行するように構成される、ノード。
【発明の詳細な説明】
【技術分野】
【0001】
本明細書は、一般的に、暗号プロトコルの実装に適しているコンピュータにより実装される方法及びシステムに関する。暗号プロトコルは、第2の秘密鍵が公開されたときに、一方の当事者が有効な秘密鍵を導き出すことを可能とする。そのような暗号プロトコルのある1つの応用は、ブロックチェーンネットワーク(blockchain network)を使用する即時オフラインのトランザクション(instant off-line transactions)のセキュリティを高めるための暗号プロトコルである。本発明は、これらには限定されないが、ビットコインブロックチェーン(Bitcoin blockchain)と関連する使用に特に適している。
【背景技術】
【0002】
本明細書においては、すべての形態の電子的なコンピュータベースの且つ分散型の台帳を含む"ブロックチェーン(blockchain)"という語を使用する。これらは、合意に基づくブロックチェーン技術(consensus-based blockchain technology)及びトランザクションチェーン技術(transaction-chain technology)、許可された台帳(permissioned ledger)及び許可されていない台帳(un-permissioned ledger)、共有されている台帳(shared ledgers)、及び、それらの変形を含む。ブロックチェーン技術の最も広く知られている用途は、ビットコイン台帳(Bitcoin ledger)であるが、他のブロックチェーンの実装が、提案されそして開発されている。本明細書においては、利便性及び説明の目的のために、ビットコインを参照することが可能であるが、本発明は、ビットコインブロックチェーンと関連する使用には限定されず、複数の代替的なブロックチェーンの実装及びプロトコルは、本発明の範囲に属するということに留意すべきである。
【0003】
ブロックチェーンは、合意に基づく電子的な台帳であり、その合意に基づく電子的な台帳は、コンピュータベースの非中心化された分散型のシステムとして実装され、そのコンピュータベースの非中心化された分散型のシステムは、複数のブロックから構成され、それらの複数のブロックは、同様に、複数のトランザクション及び他の情報から構成される。ビットコインの場合に、各々のトランザクションは、ブロックチェーンシステムの中の複数の参加者(participants)の間のディジタル資産(digital asset)の制御の移転(transfer of control)を符号化するデータ構造であり、少なくとも1つの入力及び少なくとも1つの出力を含む。各々のブロックは、複数のブロックがともにチェーン化されている前のブロックのハッシュを含み、開始(inception)以降にそのブロックチェーンに書き込まれているすべてのトランザクションの永続的且つ変更不可能な記録(permanent unalterable record)を構成する。複数のトランザクションは、それらのトランザクションの入力及び出力の中に埋め込まれているスクリプト(scripts)として知られている複数の小規模のプログラムを含み、それらの複数の小規模のプログラムは、どのようにして及びいずれの者が、それらのトランザクションの出力にアクセスすることが可能であるかを指定する。ビットコインプラットフォームにおいては、これらの複数のスクリプトは、スタックベースのスクリプト化言語(stack-based scripting language)を使用して記述される。
【0004】
ある1つのトランザクションがブロックチェーンに書き込まれるためには、そのトランザクションは、"検証されている(validated)"必要がある。複数のネットワークノードのうちのいくつかは、マイナー(採掘者)(miners)として機能し、各々のトランザクションが有効であるということを保証するために作業を実行し、無効なトランザクションは、そのネットワークから拒否される。例えば、複数のノードにインストールされている複数のソフトウェアクライアントは、未使用のトランザクションの出力(unspent transaction outputs (UTXO))を参照するトランザクションに対してこの検証作業を実行する。その施錠スクリプト(locking scripts)及び開錠スクリプト(unlocking scripts)を実行することによって、検証を実行してもよい。それらの施錠スクリプト及び開錠スクリプトを実行して、真である(TRUE)と評価し、且つ、特定の他の条件を満足する場合に、そのトランザクションは有効であり、ブロックチェーンにそのトランザクションを書き込むことが可能である。このようにして、ある1つのトランザクションがそのブロックチェーンに書き込まれるためには、そのトランザクションは、(ｉ) そのトランザクションを受信するノードによって検証される必要があり、そのトランザクションが検証される場合には、そのノードは、そのネットワークの中の他のノードへとそのトランザクションを中継し、(ii) マイナーが構築する新たなブロックに追加される必要があり、そして、(iii) マイニングされる(採掘される)(mined)必要がある、すなわち、過去のトランザクションの公開的な台帳に追加される必要がある。そのブロックチェーンに十分な数のブロックを追加して、そのトランザクションを実質的に不可逆にするときに、そのトランザクションは、確認されていると考えられる。
【0005】
ブロックチェーン技術は、暗号通貨の実装の使用として最も広く知られているが、ディジタル起業家は、新しいシステムを実装するために、ビットコインがベースとなる暗号セキュリティシステム及びブロックチェーンに格納することが可能であるデータの双方の使用の検討を開始している。暗号通貨の領域に限定されない自動化されたタスク及びプロセスのためにブロックチェーンを使用することが可能である場合には、きわめて有利であろう。そのような解決方法は、適用の際により広い用途を確保しつつ、(例えば、イベントの恒久的な改ざん防止記録(permanent, tamper proof records of events)、分散処理等の)ブロックチェーンの利点を利用することが可能であろう。
【0006】
研究の1つの分野は、"スマート契約(smart contracts)"の実装のためのブロックチェーンの利用である。これらは、機械読み取り可能な契約又は合意の条件の実行を自動化するように設計されているコンピュータプログラムである。自然言語によって記述される伝統的な契約とは異なり、スマート契約は、結果を生成するために入力を処理することが可能であり、その次に、それらの結果に依存してアクションを実行させることが可能である規則を含む機械実行可能なプログラムである。
【発明の概要】
【0007】
本明細書において説明されている本発明の第1の態様によれば、証明器が暗号プロトコルを実装するためのコンピュータにより実装される方法であって、当該コンピュータにより実装される方法は、
第1の公開鍵(PK1)及び第1の秘密鍵(sk1)を含む第1の暗号鍵対を生成するステップと、
第2の公開鍵(PK2)及び第2の秘密鍵(sk2)を含む第2の暗号鍵対を生成するステップと、
前記第1の秘密鍵及び第2の秘密鍵(sk1;sk2)から補償鍵(ck)を構築するステップであって、前記補償鍵(ck)は、前記第1の秘密鍵(sk1)が公開された場合に、前記第2の秘密鍵(sk2)を計算することを可能とする、ステップと、
前記第1の秘密鍵(sk1)が公開された場合に、前記補償鍵(ck)が、前記第2の秘密鍵(sk2)を計算することを可能とするという暗号証明を構築するステップであって、前記暗号証明は、前記第1の秘密鍵及び第2の秘密鍵(sk1;sk2)が公開されることを必要としない、ステップと、
前記第1の秘密鍵(sk1)が公開された場合に、前記補償鍵(ck)が前記第2の秘密鍵(sk2)を計算することを可能とするという前記暗号証明を検証器が認証するように、前記検証器に、前記第1の公開鍵及び第2の公開鍵(PK1;PK2)、前記補償鍵(ck)、及び前記暗号証明を送信するステップと、を含む、コンピュータにより実装される方法が提供される。
第1の公開鍵(PK1)及び第1の秘密鍵(sk1)を含む第1の暗号鍵対を生成するステップと、
第2の公開鍵(PK2)及び第2の秘密鍵(sk2)を含む第2の暗号鍵対を生成するステップと、
前記第1の秘密鍵及び第2の秘密鍵(sk1;sk2)から補償鍵(ck)を構築するステップであって、前記補償鍵(ck)は、前記第1の秘密鍵(sk1)が公開された場合に、前記第2の秘密鍵(sk2)を計算することを可能とする、ステップと、
前記第1の秘密鍵(sk1)が公開された場合に、前記補償鍵(ck)が、前記第2の秘密鍵(sk2)を計算することを可能とするという暗号証明を構築するステップであって、前記暗号証明は、前記第1の秘密鍵及び第2の秘密鍵(sk1;sk2)が公開されることを必要としない、ステップと、
前記第1の秘密鍵(sk1)が公開された場合に、前記補償鍵(ck)が前記第2の秘密鍵(sk2)を計算することを可能とするという前記暗号証明を検証器が認証するように、前記検証器に、前記第1の公開鍵及び第2の公開鍵(PK1;PK2)、前記補償鍵(ck)、及び前記暗号証明を送信するステップと、を含む、コンピュータにより実装される方法が提供される。
【0008】
本明細書において説明されている本発明の第2の態様によれば、検証器が暗号プロトコルを実装するためのコンピュータにより実装される方法であって、当該コンピュータにより実装される方法は、
証明器から、第1の態様にしたがった前記コンピュータにより実装される方法を使用して構築された前記第1の公開鍵及び第2の公開鍵(PK1;PK2)、前記補償鍵(ck)、及び前記暗号証明を受信するステップと、
前記第1の秘密鍵(sk1)が公開された場合に、前記第2の秘密鍵(sk2)を計算することができるように、前記暗号証明が前記補償鍵(ck)を検証するということを確認するステップと、を含み、
それにより、前記第1の秘密鍵(sk1)を公開する情報が開示された場合に、前記検証器は、
前記第1の秘密鍵(sk1)及び前記補償鍵(ck)から前記第2の秘密鍵(sk2)を計算し、
前記第2の秘密鍵(sk2)を使用して、前記第2の公開鍵(PK2)と関連する暗号資産にアクセスする、コンピュータにより実装される方法が提供される。
証明器から、第1の態様にしたがった前記コンピュータにより実装される方法を使用して構築された前記第1の公開鍵及び第2の公開鍵(PK1;PK2)、前記補償鍵(ck)、及び前記暗号証明を受信するステップと、
前記第1の秘密鍵(sk1)が公開された場合に、前記第2の秘密鍵(sk2)を計算することができるように、前記暗号証明が前記補償鍵(ck)を検証するということを確認するステップと、を含み、
それにより、前記第1の秘密鍵(sk1)を公開する情報が開示された場合に、前記検証器は、
前記第1の秘密鍵(sk1)及び前記補償鍵(ck)から前記第2の秘密鍵(sk2)を計算し、
前記第2の秘密鍵(sk2)を使用して、前記第2の公開鍵(PK2)と関連する暗号資産にアクセスする、コンピュータにより実装される方法が提供される。
【0009】
第2の公開鍵(PK2)と関連する暗号資産は、ロック時間Tの間、時間ロックすることが可能であり、それにより、そのロック時間Tが満了した後にのみ、その暗号資産にアクセスすることが可能である。さらに、暗号証明は、非対話型ゼロ知識証明であってもよい。そのような非対話型ゼロ知識証明は、フィアットシャミア(Fiat-Shamir)の発見的問題解決の適用によって非対話型ゼロ知識証明に変換されるゼロ知識シグマ(Σ)プロトコルに基づいていてもよい。
【0010】
式: ck＝sk2・sk1
－1 mod nによって、補償鍵を計算することが可能であり、
ckは、補償鍵であり、sk1は、第1の秘密鍵であり、sk2は、第2の秘密鍵であり、nは、第1の秘密鍵及び第2の秘密鍵から第1の公開鍵及び第2の公開鍵を生成するのに使用される楕円曲線基準点Gの次数であり、第1の公開鍵及び第2の公開鍵の生成は、その楕円曲線基準点Gの楕円曲線点乗算を含む。
ckは、補償鍵であり、sk1は、第1の秘密鍵であり、sk2は、第2の秘密鍵であり、nは、第1の秘密鍵及び第2の秘密鍵から第1の公開鍵及び第2の公開鍵を生成するのに使用される楕円曲線基準点Gの次数であり、第1の公開鍵及び第2の公開鍵の生成は、その楕円曲線基準点Gの楕円曲線点乗算を含む。
【0011】
暗号証明は、
安全な乱数rを生成すること、
コミットメントR＝r×Gを計算することであって、Rxは、点Rのx座標である、こと、
ハッシュH(Rx)を計算することであって、セットxは、H(R)のうち最も左のln個のビットであり、lnは、nのビット長さである、こと、
z＝sk1x＋rを計算すること、
によって構築されてもよく、
暗号証明は、タプル(tuple)π＝(ck,R,x,z)である。
安全な乱数rを生成すること、
コミットメントR＝r×Gを計算することであって、Rxは、点Rのx座標である、こと、
ハッシュH(Rx)を計算することであって、セットxは、H(R)のうち最も左のln個のビットであり、lnは、nのビット長さである、こと、
z＝sk1x＋rを計算すること、
によって構築されてもよく、
暗号証明は、タプル(tuple)π＝(ck,R,x,z)である。
【0012】
検証器は、
C＝ck×Gを計算し、
x＝最も左のln H(Rx) であり、
z×G＝x×PK1＋R であり、
z×G＝x×PK2＋ck×R である
ということを検証し、
確認される場合に、その値ckを有効であるとして受け入れる、
といったように、タプルを認証してもよい。
C＝ck×Gを計算し、
x＝最も左のln H(Rx) であり、
z×G＝x×PK1＋R であり、
z×G＝x×PK2＋ck×R である
ということを検証し、
確認される場合に、その値ckを有効であるとして受け入れる、
といったように、タプルを認証してもよい。
【0013】
上記の暗号方法のある1つの応用は、ブロックチェーンネットワークを使用する即時オフライントランザクションのセキュリティを高めるための暗号方法である。そのような応用においては、証明器は、
資金調達トランザクションを構築し、前記資金調達トランザクションは、前記第1の公開鍵(PK1)及び前記第1の秘密鍵(sk1)と関連する支出出力と、前記第2の公開鍵(PK2)及び前記第2の秘密鍵(sk2)と関連する預金出力と、を含み、前記預金出力は、ロック時間Tの間、時間ロックされ、
前記ブロックチェーンに組み込むために、ブロックチェーンネットワークに前記資金調達トランザクションをブロードキャストし、
購入トランザクションを構築し、前記購入トランザクションは、前記ブロックチェーンネットワークを介して、前記資金調達トランザクションの前記支出出力から前記検証器の決済アドレスへと、資金を転送し、前記購入トランザクションは、前記第1の秘密鍵(sk1)を使用して署名され、
前記検証器に、前記購入トランザクション、前記第1の公開鍵及び第2の公開鍵(PK1;PK2)、前記補償鍵(ck)、及び前記暗号証明を送信する。
資金調達トランザクションを構築し、前記資金調達トランザクションは、前記第1の公開鍵(PK1)及び前記第1の秘密鍵(sk1)と関連する支出出力と、前記第2の公開鍵(PK2)及び前記第2の秘密鍵(sk2)と関連する預金出力と、を含み、前記預金出力は、ロック時間Tの間、時間ロックされ、
前記ブロックチェーンに組み込むために、ブロックチェーンネットワークに前記資金調達トランザクションをブロードキャストし、
購入トランザクションを構築し、前記購入トランザクションは、前記ブロックチェーンネットワークを介して、前記資金調達トランザクションの前記支出出力から前記検証器の決済アドレスへと、資金を転送し、前記購入トランザクションは、前記第1の秘密鍵(sk1)を使用して署名され、
前記検証器に、前記購入トランザクション、前記第1の公開鍵及び第2の公開鍵(PK1;PK2)、前記補償鍵(ck)、及び前記暗号証明を送信する。
【0014】
そのような応用においては、検証器は、
前記証明器から、前記購入トランザクション、前記第1の公開鍵及び第2の公開鍵(PK1;PK2)、前記補償鍵(ck)、及び前記暗号証明を受信し、
前記購入トランザクションが、前記第1の公開鍵(PK1)と関連する前記支出出力から前記決済アドレスへと転送される前記資金を正しく指定しているということを検査し、
前記第2の公開鍵(PK2)と関連する前記預金出力が、必要とされる預金額を含んでいるということを検査し、
前記暗号証明が、前記補償鍵(ck)を検証し、それによって、前記第1の秘密鍵(sk1)が公開された場合に、前記第2の秘密鍵(sk2)を計算することが可能であるということを検査し、
前記購入トランザクションを認可し、前記ブロックチェーンネットワークに前記購入トランザクションをブロードキャストし、
第2の競合する購入トランザクションが、前記ブロックチェーンネットワークにブロードキャストされ、前記ロック時間Tが満了する前に、前記資金調達トランザクションの前記支出出力からの資金を支出する場合に、前記検証器は、
前記購入トランザクション及び第2の購入トランザクションの署名から前記第1の秘密鍵(sk1)を計算し、
前記第1の秘密鍵(sk1)及び前記補正鍵(ck)から前記第2の秘密鍵(sk2)を計算し、
前記資金調達トランザクションの前記預金出力から前記ブロックチェーンのアドレスに資金を転送するトランザクションを構築し、
前記第2の秘密鍵(sk2)を使用して前記トランザクションに署名し、
前記ブロックチェーンネットワークに前記トランザクションをブロードキャストし、それによって、前記ロック時間Tが満了した後に、前記ベンダーによって、前記資金調達トランザクションの前記預金出力における前記資金を取得することが可能である。
前記証明器から、前記購入トランザクション、前記第1の公開鍵及び第2の公開鍵(PK1;PK2)、前記補償鍵(ck)、及び前記暗号証明を受信し、
前記購入トランザクションが、前記第1の公開鍵(PK1)と関連する前記支出出力から前記決済アドレスへと転送される前記資金を正しく指定しているということを検査し、
前記第2の公開鍵(PK2)と関連する前記預金出力が、必要とされる預金額を含んでいるということを検査し、
前記暗号証明が、前記補償鍵(ck)を検証し、それによって、前記第1の秘密鍵(sk1)が公開された場合に、前記第2の秘密鍵(sk2)を計算することが可能であるということを検査し、
前記購入トランザクションを認可し、前記ブロックチェーンネットワークに前記購入トランザクションをブロードキャストし、
第2の競合する購入トランザクションが、前記ブロックチェーンネットワークにブロードキャストされ、前記ロック時間Tが満了する前に、前記資金調達トランザクションの前記支出出力からの資金を支出する場合に、前記検証器は、
前記購入トランザクション及び第2の購入トランザクションの署名から前記第1の秘密鍵(sk1)を計算し、
前記第1の秘密鍵(sk1)及び前記補正鍵(ck)から前記第2の秘密鍵(sk2)を計算し、
前記資金調達トランザクションの前記預金出力から前記ブロックチェーンのアドレスに資金を転送するトランザクションを構築し、
前記第2の秘密鍵(sk2)を使用して前記トランザクションに署名し、
前記ブロックチェーンネットワークに前記トランザクションをブロードキャストし、それによって、前記ロック時間Tが満了した後に、前記ベンダーによって、前記資金調達トランザクションの前記預金出力における前記資金を取得することが可能である。
【0015】
前記支出出力は、前記支出出力から資金を転送することが、固定の一時的な鍵(k)に基づくトランザクション署名を必要とするように構成されてもよい。前記支出出力は、fixed-r-pay-to-public-key (FR-P2PK)出力であってもよく、それによって、前記支出出力から資金を転送することは、あらかじめ指定されているr値を利用するトランザクション署名を必要とする。さらに、前記預金出力は、前記支出出力よりも大きくてもよく、システムのセキュリティを向上させてもよい。
【0016】
本発明の複数の実施形態は、さまざまな形態で提供されてもよい。例えば、コンピュータ読み取り可能な記憶媒体を提供することが可能であり、そのコンピュータ読み取り可能な記憶媒体は、実行されると、本明細書において説明されている方法を実行するように1つ又は複数のプロセッサを構成するコンピュータ実行可能な命令を含む。また、電子デバイスを提供することが可能であり、その電子デバイスは、インターフェイスデバイス、そのインターフェイスデバイスに結合される1つ又は複数のプロセッサ、及び、それらの1つ又は複数のプロセッサに結合されるメモリを含み、そのメモリは、実行されると、本明細書において説明されている方法を実行するようにそれらの1つ又は複数のプロセッサを構成するコンピュータ実行可能な命令を格納している。また、ブロックチェーンネットワークのノードを提供することが可能であり、そのノードは、本明細書において説明されている方法を実行するように構成される。
【図面の簡単な説明】
【0017】
本発明のこれら及び他の態様は、本明細書において説明されている複数の実施形態から明らかであり、且つ、それらの複数の実施形態を参照して解明される。次に、複数の添付の図面を参照して、且つ、単なる例示として、本発明の複数の実施形態を説明する。
【0018】
【図1】本明細書において説明されているある1つの技術的なプロトコルの高レベルの概略図を示している。
【図2】証明器(P)と検証器(V)との間の動作及び通信のフローを示している。
【図3】セットアップトランザクションの概略図を示している。
【図4】さまざまな実施形態を実装することが可能であるコンピューティング環境を図示する概略図である。
【発明を実施するための形態】
【0019】
この明細書は、システム及び方法を説明し、それらのシステム及び方法は、トランザクションが有効なブロックの中に含まれているという確認を待つ必要なく、又は、トランザクションがネットワークによって受信されているということを確認する必要さえなく、即時に且つオフラインで(instantly and off-line)、商品及びサービスのための支払として、ビットコイン署名トランザクションを受け入れることを可能とする。ビットコインスクリプトの中に実装されている1回限りの署名(one-time signature)の概念に基づいて、この方法は、支払者(payer)が、店頭で(at the point-of-sale)支払受け取り者(payee)にある特定の補償鍵(a special compensation key)を提供することに関連しており、その支払い受取人によって、二重の支出(double-spend)が行われる場合に(及び、そのような場合にのみ)、"公開された(revealed)"秘密鍵と組み合わせられるときに、時間ロックされている預金出力(time-locked deposit output)を請求するのに、その特定の補償鍵を使用することが可能である。この補償鍵の有効性は、新しいタイプのゼロ知識証明(zero-knowledge-proof)によって保証され、そのゼロ知識証明は、非常に効率的である、すなわち、そのゼロ知識証明は、最大で5ミリ秒の範囲で生成可能であり、且つ、最大で30ミリ秒の範囲で検証可能である。小売りの場でこのシステムを使用すると、ベンダーが、集合的な損失リスクなしに、且つ、第三者サービスを信頼する必要なしに、高い価値の品目のための即時の暗号通貨の支払いをオフラインで受け入れることを可能とするであろう。
【0020】
ビットコインの発明は、ネットワーク、すなわち、ブロックチェーンの中のあらゆるノードにおいて複製される唯一の変更不可能な台帳に、有効なトランザクションを追加することによって、ディジタルトークンを二重に支出するという問題に対する第1の完全に分散化された解決方法を提供してきた。一方で、この台帳に追加されるためには、ブロックの中でトランザクションを確認する必要があり、そして、不可逆的と考えられるのに十分な(ブロック深度による)作業量の証明(proof-of-work)(ブロックチェーンにおける分散型合意形成の仕組みであり、膨大な計算を通じて暗号を最初に解いた者に合意形成の権利が与えられる)を追加する必要がある。このシステムは、極めて高い安全性を有するとともに、極めて高い信頼性を有することが証明されているが、一方で、有意な時間を必要とする、すなわち、(平均で)10分ごとにのみ、ビットコインネットワークの中で新たなブロックを採掘し(マイニングし)(mined)、一方で、(特に、需要が高く、ブロックサイズが限定されている場合には)ある特定のトランザクションが次のブロックの中に含まれるという保証はない。このゆっくりとした確認時間は、多くのアプリケーションにおいて、特に、小売り設定(retail setting)において及び販売時点(point-of-sale (POS))において、ビットコインの安全な使用を妨げ、小売り設定において及びPOSにおいては、現金及びクレジットカード/デビットカードの支払いと競合するために、安全なトランザクションは、およそ数秒又はそれ以下の間に完了される必要がある。非接触型のカード決済のための仕様書は、非接触型のカード決済が、500ミリ秒よりも小さな時間で完了され及び確認される必要があるということを明記しているということに留意すべきである。
【0021】
有効であり(すなわち、正しく形成され、未使用のトランザクションの出力(UTXOs)のための有効な署名を有し)、且つ、ビットコインネットワークにブロードキャストされているが、いまだにブロックに含まれてはいないトランザクションは、ゼロ確認トランザクション(zero-confirmation transactions (ZCT))として知られている。小売業者は、商品/サービスのための支払としてZCTを受け入れることを選択してもよいが、その際には、それらの小売業者は、資金が二重に支出される場合があるというリスク、すなわち、同じUTXOを支出する個別の有効なトランザクションが、最初にブロックチェーンにおいて確認されるというリスクを受け入れる必要がある。このことは、小売業者のトランザクションを無効にし、そして、それらの小売業者は、対応する資金を失うであろう。これは、二重支出攻撃(double-spending attack)(又は、レース攻撃(race attack))として知られ、顧客によって行われ、その顧客は、そのとき、顧客が店頭時の交換(point-of-sale exchange)によって受け取る商品/サービスを効果的に盗む。
【0022】
この攻撃の最終的な目的は、トランザクションが小売業者に支払われる前に、二重の支出(攻撃)トランザクションが最初に確認される(confirmed first)(最初に採掘される(mined first))ようにすることである。有効なトランザクションがビットコインネットワークにブロードキャストされるときに、その有効なトランザクションは、個々のマイニングノードの(採掘者が新しいブロックに含めることを選択することが可能である未確認のトランザクション(unconfirmed transactions)のリストである)メンバープール(mempool)に追加される。マイニングノードは、それらのマイニングノードが希望するいずれかの有効なトランザクションを含めるか、又は、除外することができるが、それらのマイニングノードは、経済的なインセンティブにしたがうので、トランザクションは、通常は、それらのマイニングノードが提示する手数料に基づいて優先順位を付けられる。したがって、たとえ、矛盾するトランザクションを最初に受け取った場合であっても、攻撃者は、より高い料金を支払うことによってトランザクションに高い優先順位をつけるように、採掘者を動機づけることが可能である。このことは、ビットコインコアクライアント(Bitcoin Core client)において、料金によって置き換える(Replace-By-Fee (RBF))機能を使用して自動的に生起する。このことは、本明細書の以降の部分でより詳細に議論される。
【0023】
ゼロ確認トランザクションを受け入れる際の安全性の欠如は、決済システムとしてのビットコインの使用及びより広範な経済におけるビットコインの採用に対する大きな障害である。小売業者の中には、低価格の購入によってZCTを受け入れ、二重支出攻撃のコストをビジネスモデルに吸収しているものも存在するが、これは、非常に限界があり、それらの小売業者は、(通常は、5乃至10秒必要となる)ネットワーク全体にトランザクションが伝搬していることの確認のためにオンライン動作する必要がある。複数署名のトランザクションを使用し、(GreenAddress、Bitpay Instant等の)信頼できる第三者を必要とする複数の他の技術的解決方法も提案され、そして、実装されている。Lightning Networkは、中間決済ハブを介して顧客及び小売業者を結びつける事前資金拠出型の決済チャネルを必要とし、この決済ルーティングは、未解決の技術的問題であるが、支払者及び支払い受取者の双方がオンラインで動作する必要があり、(仮に、ネットワークが機能している場合には)ネットワークを介して資金ルートを交渉し、そして、決済を確認するのに少なくとも5秒乃至10秒を要する可能性が高い。
【0024】
資金拠出型の決済チャネル(funded payment channels)又は信頼できる第三者を必要としない代替的なアプローチが、最近の論文[Perez-Sola 2017]の中で説明されている。2つの異なる有効な(署名された)トランザクションが同じ出力を支出して生成されている場合に、この代替的なアプローチは、出力を制御する秘密鍵が公開されるようにすることによって、二重の支出攻撃を非インセンティブ化する(dis-incentivise)ことを目的としている、すなわち、攻撃者は、双方のトランザクションを観察する(そして、その次に、秘密鍵を決定することが可能である)いずれかのものに対する出力によって資金のすべてを失うおそれがある。このことは、一時的な署名鍵(r値)に前もってコミットするように支払者(顧客)に強制し、標準的なビットコイン署名(ECDSA)を"1回限りの署名"に変換することによって達成される。一方で、このアプローチは、重大な欠点を有する、すなわち、第1に、ビットコインネットワークの性質及びトランザクションを伝播させる方法に起因して、(手遅れとなる時点である)矛盾するトランザクションの双方のうちの一方をマイニングしてブロックに入れる前に、ネットワーク参加者のすべてによってそれらの矛盾するトランザクションの双方を観察することは困難である場合がある。第2に、だまし取られてしまった小売業者のための補償は存在しない、すなわち、二重の支出の試行の結果を請求しようとする当事者は、ネットワークを観察しているいずれかのものであってもよいが、もっとも可能性が高いのはマイナー(採掘者)である(詳細については以降の部分を参照する)。第3に、小売業者がオフラインで動作し、ネットワークに、署名されたトランザクションを送信することが不可能である(そして、また、その署名されたトランザクションがすべてのノードに伝搬されているということを確認することが不可能である)場合には、この方法は、役に立たない。
【0025】
この明細書においては、これらの欠点を克服し、そして、攻撃用のトランザクションが最初に確認される場合であっても、顧客によって二重の支出の攻撃が実行されるという状況の下で、小売業者(及び、その小売業者のみ)が補償にアクセスすることを可能とする方法を提示する。このことは、顧客が、並列的な1回限りの署名出力にリンクされている時間ロックされた出力に預金を配置することに関連しているとともに、その顧客が、小売業者に、補償鍵を提供することに関連しており、1回限りの署名鍵と組み合わせられるときに、預金のロックを解除するのに、その補償鍵を使用することが可能である。補償鍵の有効性は、新しいタイプのゼロ知識証明によって強化される、すなわち、このことは、効率が非常に高く、少数の楕円曲線演算のみを必要とする新しいプロトコルによって具体化される。
【0026】
楕円曲線ディジタル署名アルゴリズム
【0027】
ビットコインシステム(及び、他の同様の暗号通貨システム)においては、未使用のトランザクション出力(unspent transaction outputs (UTXO))は、楕円曲線ディジタル署名アルゴリズム(elliptic curve digital signature algorithm (ECDSA))を使用して保護される。トランザクションの出力は、通常は、(公開鍵のハッシュである)アドレスに支払い、トランザクション入力によって"支出され"(ロック解除され)てもよく、そのトランザクション入力は、対応する公開鍵及び有効な署名を提供する(その有効な署名は、そのトランザクションを認可し、対応する秘密鍵を使用することによってのみ生成することが可能である)。
【0028】
(楕円曲線の点である)公開鍵Pは、(次数nの楕円曲線基準点Gを有する)secp256k1楕円曲線に対する(記号×によって示される)点乗算によって秘密鍵dから導出され、P＝d×Gである。これは、ビットコインにおいて使用される楕円曲線仕様である。本明細書において説明されているプロトコルは、すべて、他のいずれかのブロックチェーンシステムと互換性があり、ビットコインシステムに限定されるものではない。
【0029】
(例えば、ビットコイントランザクション等の)メッセージmの署名は、以下のように生成される。
1. z＝H(m)を計算する(Hは、SHA-256ハッシュ関数である)。
2. 安全なランダム整数k←Znを生成する。このランダム整数は、いわゆる一時的な鍵である。
3. 点K＝k×Gを計算する。
4. r＝Kx mod nを計算する(Kxは、点Kのx座標である)。
5. s＝k－1(z＋rd)mod nを計算する。
6. 署名は、値(r,s)の対である。
1. z＝H(m)を計算する(Hは、SHA-256ハッシュ関数である)。
2. 安全なランダム整数k←Znを生成する。このランダム整数は、いわゆる一時的な鍵である。
3. 点K＝k×Gを計算する。
4. r＝Kx mod nを計算する(Kxは、点Kのx座標である)。
5. s＝k－1(z＋rd)mod nを計算する。
6. 署名は、値(r,s)の対である。
【0030】
メッセージm及び公開鍵Pに対する署名の検証は、以下のように実行される。
1. z＝H(m)を計算する。
2. w＝s－1mod nを計算する。
3. u1＝zw mod n及びu2＝rw mod nを計算する。
4. 点Y＝u1×G＋u2×Pを計算する。
5. Yx≡r(mod n)である場合に、その署名は、有効である。
有効な署名は、秘密鍵(d)についてのいかなる情報も公開することなく、その秘密鍵(d)が、メッセージを認可するのに使用されたということを証明する。以下で説明されるように、その値kが、また、秘密に保たれる場合にのみ、このことは、真となり、複数の異なる署名が、kの複数の異なるランダム値を使用するということとなる。
1. z＝H(m)を計算する。
2. w＝s－1mod nを計算する。
3. u1＝zw mod n及びu2＝rw mod nを計算する。
4. 点Y＝u1×G＋u2×Pを計算する。
5. Yx≡r(mod n)である場合に、その署名は、有効である。
有効な署名は、秘密鍵(d)についてのいかなる情報も公開することなく、その秘密鍵(d)が、メッセージを認可するのに使用されたということを証明する。以下で説明されるように、その値kが、また、秘密に保たれる場合にのみ、このことは、真となり、複数の異なる署名が、kの複数の異なるランダム値を使用するということとなる。
【0031】
1回限りの署名
【0032】
ECDSA署名スキームは、(DSA、Schnorr、及びElGamal等のほとんどの他の一般的なスキームとも共有されている)よく知られた脆弱性を有し、同じ一時的な鍵(k)が双方の署名のために使用される場合には、秘密鍵を導出するのに、(同じ秘密鍵を使用するが、2つの異なるメッセージの)2つの異なる署名を使用することが可能である。
【0033】
同じ(未知の)一時的な鍵kを使用して計算される2つの異なるメッセージ(すなわち、ハッシュz1及びz2)の2つのECDSA署名(sig1＝(r1,s1)及びsig2＝(r2,s2))が与えられると、sig1及びsig2を観察しているとともに、また、z1及びz2を知るいずれかの者は、以下のようにその秘密鍵を計算することが可能である。
1. rの値は、kから直接的に計算されるので、rの値は、双方の署名について同じである(すなわち、r＝r1＝r2)
2. ECDSAの定義から、ks1＝(z1＋rd)mod n及びks2＝(z2＋rd)mod nとなる。
3. 一時的な鍵は、そのとき、
として決定されてもよい。
4. 秘密鍵は、そのとき、
として決定されてもよい。
1. rの値は、kから直接的に計算されるので、rの値は、双方の署名について同じである(すなわち、r＝r1＝r2)
2. ECDSAの定義から、ks1＝(z1＋rd)mod n及びks2＝(z2＋rd)mod nとなる。
3. 一時的な鍵は、そのとき、
【数1】
4. 秘密鍵は、そのとき、
【数2】
【0034】
この脆弱性は、いくつかの高度なプロファイルハッキングにおいて利用され、ECDSAの実装バグは、新しい署名の各々について新しい安全なkの値の生成に失敗している。一方で、その脆弱性は、また、ある1つの署名についてある1つの特定の(しかし、秘密の)k(したがって、r)の値を使用することを署名者に"強制する"ことによって、それらの署名者が、ある1つの特定の秘密鍵を使用して1つのメッセージのみに署名することが可能であるか、又は、それらの署名者が、その鍵を公開するおそれがあるといった、潜在的に有用な特徴につながる。これは、いわゆる1回限りの署名である、すなわち、その秘密鍵は、単一のメッセージに署名するのに使用することが可能であるにすぎない。
【0035】
([Perez-Sola 2017]によれば)未確認のビットコイントランザクション(unconfirmed bitcoin transactions)の二重の支出の防止又は少なくとも非インセンティブ化に役立てるのにこの特性を使用してもよいということが示唆されている。その基本的な考え方は、ある顧客が、署名されたトランザクションをあるベンダーに提供し、そのベンダーは、有効なUTXOから商品/サービスの購入価格を支払う(そして、その顧客への返却代金としてそのUTXOの残りの部分を支払う)ということである。その顧客が、その次に、(顧客自体にUTXOのすべてを払い戻す)攻撃用のトランザクションを作成し、その攻撃用のトランザクションをブロードキャストする場合に、それらの2つの個別の署名は、双方のトランザクションを観察するいずれかの者にそのUTXOを制御する秘密鍵を公開するであろう。二重の支出を実行する顧客は、そのとき、第三者に対してそのUTXOの中の資金の全体を損失するリスクを負うことになる。
【0036】
この非インセンティブ化メカニズムが機能するために、顧客は、同じ一時的な鍵(k)を使用して、双方の署名を生成する必要がある。ある特別のタイプのトランザクション出力、すなわち、(以下で説明される)いわゆるFixed-r Pay-to-Public-Keyを作成することによって、前もって、その署名の(rがkのみに依存する)k値にその顧客がコミットするようにさせることによって、このことを実現してもよい。その顧客は、前もってこのことを設定する必要がある、すなわち、kの値を選択し(そして、秘密鍵と共に安全にそのkの値を格納し)、そして、ある出力の中に十分な資金を支払っておく必要があり、その出力は、そのコミットされたkに対応するrの値を有する署名を必要とする。
【0037】
Fixed-r Pay-to-Public-Key-Hash
【0038】
([Perez-Sola 2017]によれば)ある特定のr値を有する署名によってのみFixed-r Pay-to-Public-Key (FR-P2PK)タイプのトランザクション出力をロック解除することが可能であり、その特定のr値は、トランザクションを作成するときにコミットされる。(顧客が)この資金調達トランザクションを作成するプロセスは、以下のとおりである。
1. 顧客は、ランダムな一時的な鍵k及び秘密鍵dを選択する。
2. 顧客は、自身の公開鍵P＝d×Gを計算する。
3. 顧客は、r＝(k×G)x mod nを計算する。
4. 顧客は、出力(ScriptPubKey)を使用して、トランザクションを作成し、その出力(ScriptPubKey)は、
ScriptPubKey (また、P2PK-Hashトランザクション又はpay-to-script hash(P2SH)トランザクションの中でこの基本フォーマットを使用することが可能である):
OP_DUP <pubKey> OP_CHECKSIGVERIFY OP_SIZE <0x47> OP_EQUALVERIFY <sigmask> OP_AND <r> OP_EQUAL
であり、<sigmask>は、(署名と同じサイズの)71バイトの配列であり、その71バイトの配列は、署名配列の中でr値が位置している複数の場所において、及び、sighash-typeフラグの場所において、1sを有するとともに、他の場所のすべてにおいて0sを有し、(sighash-typeフラグの場所において、sighash-typeフラグは、また、SIGHASH_ALL (0x01)に制約されて、複数の異なる署名が、複数の異なるトランザクション支出出力について形成されるということを保証する)。<r>は、71バイトの配列であり、その71バイトの配列は、署名配列に対応する場所においてrの値を含むとともに、それ以外の場所のすべてにおいて0sを含む(また、sighash-typeの場所において0x01を含む)。
5. 顧客は、その次に、ネットワークにこの資金調達トランザクションをブロードキャストし、POSにおいてゼロ確認トランザクションを実行することを必要とする前に、ブロックチェーンでの確認を待つ。
1. 顧客は、ランダムな一時的な鍵k及び秘密鍵dを選択する。
2. 顧客は、自身の公開鍵P＝d×Gを計算する。
3. 顧客は、r＝(k×G)x mod nを計算する。
4. 顧客は、出力(ScriptPubKey)を使用して、トランザクションを作成し、その出力(ScriptPubKey)は、
ScriptPubKey (また、P2PK-Hashトランザクション又はpay-to-script hash(P2SH)トランザクションの中でこの基本フォーマットを使用することが可能である):
OP_DUP <pubKey> OP_CHECKSIGVERIFY OP_SIZE <0x47> OP_EQUALVERIFY <sigmask> OP_AND <r> OP_EQUAL
であり、<sigmask>は、(署名と同じサイズの)71バイトの配列であり、その71バイトの配列は、署名配列の中でr値が位置している複数の場所において、及び、sighash-typeフラグの場所において、1sを有するとともに、他の場所のすべてにおいて0sを有し、(sighash-typeフラグの場所において、sighash-typeフラグは、また、SIGHASH_ALL (0x01)に制約されて、複数の異なる署名が、複数の異なるトランザクション支出出力について形成されるということを保証する)。<r>は、71バイトの配列であり、その71バイトの配列は、署名配列に対応する場所においてrの値を含むとともに、それ以外の場所のすべてにおいて0sを含む(また、sighash-typeの場所において0x01を含む)。
5. 顧客は、その次に、ネットワークにこの資金調達トランザクションをブロードキャストし、POSにおいてゼロ確認トランザクションを実行することを必要とする前に、ブロックチェーンでの確認を待つ。
【0039】
この出力を支出するために、顧客は、資金調達トランザクションにおいてコミットしたのと同じrの値を使用する署名を作成する必要がある。その署名を生成するために、顧客は、その次に、対応するkの値及び秘密鍵dを知っている必要がある。(異なるトランザクションにおける)第2の署名の生成(及びブロードキャスト)は、その後、秘密鍵を公開することになるであろう。
【0040】
課題
【0041】
[Perez-Sola 2017]において提示されている理論的根拠は、FR-P2PK出力を支出して即時の購入を行うことを顧客に要求することによって、それらの顧客が、(第2の署名されたトランザクションをブロードキャストすることによって)二重の支出を試みる場合に、それらの顧客は、その出力の全体を失うリスクを負うということである。そのFR-P2PKの出力の額が、購入の価値と等しい(すなわち、その顧客に払い戻される"返却代金(change)"出力が存在しない)場合には、その顧客は、二重の支出攻撃を試みることによって、何も失うことはない立場にある。したがって、小売業者は、FR-P2PKの出力が購入額よりも有意に大きな額を含むことを要求してもよく、それによって、それらの顧客が二重の支出を試みる場合に、その顧客は、(購入額よりもより大きい場合がある)"返却代金"の出力を失うリスクを負う。この場合に、顧客は、二重の支出を試みずに、一方で、顧客が不利益を受ける可能性はどれくらいか、及び、誰が利益を得るのかについてインセンティブを有する。
【0042】
この文脈における二重の支出攻撃のダイナミクスは、マイニングノードが、複数の矛盾するトランザクションを処理する(すなわち、優先順位をつけ及び/又は中継する)手法に依存し、ネットワークのコンセンサスルールとは無関係であるとともに、採掘者(マイナー)が実行しているクライアントの実装のみに依存する。クライアントは、"最初に見た(first seen)"ルールに基づいて動作する場合がある、すなわち、それらのクライアントが受信する最初の有効なトランザクションが、メンバープール(mempool)に追加され、同じ出力を参照するその後のトランザクションは無視されるにすぎない。この場合に、二重の支出攻撃の間に、2つの矛盾するトランザクションがネットワークのいたる所に伝播する手法に依拠して、複数の異なる採掘者は、メンバープールの中に複数の異なるトランザクションを有してもよい。一方で、ネットワークをモニタリングしている採掘者のすべては、依然として、ブロードキャストされた矛盾するトランザクションから秘密鍵を取得し、そして、ブロックに含まれるべき自分自身のトランザクションを作成することが可能である、すなわち、それらの採掘者は、そのようにするように動機づけられる。
【0043】
((2016年2月にリリースの)現行のビットコインコアクライアントバージョン0.12以降で実装されている)異なるクライアントルールは、"料金によって置き換える(replace-by-fee)"(RBF)機能であり、そのRBF機能は、不十分な料金を有する固着したトランザクション(stuck transactions)を人々が"動かす(bump)"のを支援することを意図している。RBFマイニングクライアント(mining clients)は、自身のメンバープール(mempool)の中のいずれかのトランザクションを、同じUTXOを支出しているがより高い採掘者料金(miner fee)を含んでいる他のトランザクションと置き換えるであろう。このことは、標準的な二重の支出攻撃をはるかに容易にする、すなわち、顧客は、より高い料金を有する第2のトランザクションをブロードキャストするだけで足り、その顧客は、小売業者の決済トランザクションを最初に手数料を受信した場合であっても、採掘者のメンバープールの中の元の小売業者の決済トランザクションを置き換えるであろう。この場合に、ネットワークをモニタリングするいずれかの者は、双方のトランザクションを観察し、秘密鍵を抽出し、そして、より高い料金を提供するFR-P2PK出力の全体を支出する自分自身のトランザクションを作成することが可能である。このことは、いわゆる"焦土(scorched earth)"シナリオにつながり、その焦土シナリオにおいては、多くの観察者は、料金を前払いすることが可能であり、その料金は、出力値の100%になる傾向がある。
【0044】
要約すると、FR-P2PK出力の二重の支出攻撃の可能な結果は、
1. 最初に確認された初期の小売業者のトランザクション、
2. 最初に確認された攻撃用のトランザクション、及び、
3. 最初に確認された採掘者のトランザクション、
である。
1. 最初に確認された初期の小売業者のトランザクション、
2. 最初に確認された攻撃用のトランザクション、及び、
3. 最初に確認された採掘者のトランザクション、
である。
【0045】
採掘者の双方が、"正直であり"且つ"最初に見た"クライアントルールを実行する場合には、攻撃のタイミング及びネットワークトポロジーに依存して、1及び2は、同様の可能性を有する。採掘者が経済的なインセンティブにしたがって行動し、又は、RBFクライアントルールにしたがって行動する場合には、最終的な結果は、採掘者が完全なFR-P2PK出力を請求することになり、小売業者が補償を受ける可能性が全くないということになる。
【0046】
小売業者が、トランザクションをブロードキャストすることが不可能である(そして、そのトランザクションがネットワークによって受信されたということを検証することが不可能である)場合に、攻撃用のトランザクションは、もちろん、最初に確認される。小売業者は、その次に、それらの小売業者が所有する署名及びブロックチェーンにおける署名から秘密鍵を取得することが可能であるが、一方で、資金が支出されてしまえば、その秘密鍵は、役に立たない。
【0047】
シグマプロトコル
【0048】
この明細書(の次節)において説明されている技術的解決方法のうちの1つは、シグマ(Σ)プロトコルを利用し、そのΣプロトコルは、証明器と検証器との間の複数のメッセージを伴うある1つのタイプの対話型のゼロ知識証明システムである。Σプロトコルは、通常、証明器が、検証器(α)に初期コミットメントを送信し、その検証器が、その次に、ランダムチャレンジ(x)によって応答し、そして、その次に、証明器が、最終応答(z)によって回答する、という3つの動作を含む。検証器は、その次に、複写物(α,x,z)(transcript(α,x,z))に基づいて、そのステートメントを受け入れ又は拒否する。
【0049】
([Damgard 2010]によれば)Σプロトコルは、証明器のみに知られている証人(w)の知識又は陳述(statement)を証明するのに使用される。([Bootle 2015]によれば)プロトコルが、証人に関する陳述が真実であるという事実を除き、検証器にその証人に関するいかなる情報も明らかにしない場合には、そのプロトコルは、ゼロ知識である。次節において説明されているΣプロトコルは、([Schnorr 1990]によれば)離散的対数の知識を証明するための基本的なシュノール(Schnorr)プロトコル及び([Bootle 2015]によれば)2つのグループ要素の離散的対数の等価性を証明するためのシグマプロトコルから導き出され、同形特性を有する一方向性関数(実施形態においては、この一方向性関数は、楕円曲線点乗算であってもよい)を使用する。
【0050】
([Fiat 1986]によれば)フィアットシャミア(Fiat-Shamir)の発見的問題解決を適用することによって、対話型Σプロトコルを非対話型スキームに変換することが可能である、すなわち、このことは、ランダムチャレンジの値(x)を、証明器が行うコミットメントのハッシュの出力と置き換えるにすぎない。(暗号ハッシュ関数の出力が、真にランダムであると考えられる)ランダムなオラクルモデルにおいては、証明器は、不正を行うことが不可能であり、検証器は、生成されたチャレンジの値の有効性を検査することが可能である。
【0051】
技術的解決方法
【0052】
以下の複数の節は、提案されているスキームを可能にする技術的解決方法をより詳細に説明する。それらに続く節は、その次に、完全なスキームの中で上記の革新的事項をどのようにして採用して、上記のFR-P2PK方法の欠点を克服するかについて説明する。
【0053】
本質的に、"完全なスキーム(complete scheme)"は、(第2の既知の公開鍵に対応する)第2の秘密鍵が公に公開されるときに、一方の当事者(及び一方の当事者のみ)が(既知の公開鍵に対応する)有効な秘密鍵を導き出すことを可能とする方法を提供する。この方法が安全で且つトラストレス(trustless)(ブロックチェーン技術において、管理者が存在しないか、又は、管理者による承認を必要としない)となるようにするために、暗号証明(cryptographic proof)とともに(補償鍵(compensation key)と称される)情報の一意の部分を第1の当事者に提供する必要があり、その暗号証明は、情報のこの一意の部分が、公開された秘密鍵と組み合わせるときに、それらの第1の当事者が有効な秘密鍵を導き出すことを可能とするという暗号証明である。この証明は、フィアットシャミアの発見的手法の適用によって非対話型証明に変換されるゼロ知識Σプロトコルに基づいている。
【0054】
2つの当事者(又は、2つのネットワークノード)が、プロトコルに関与している、すなわち、それらの2つの当事者は、証明器(P: 当事者1)及び検証器(V: 当事者2)である。P及びVの双方は、非対称暗号機能及び仕様について合意している。一般的に、これは、ある1つの生成器G(楕円曲線基準点G)を有する次数nのグループ
から構成され、離散的対数問題が扱いにくいと想定される。ビットコインプロトコルと互換性を有する構成においては、([SEC 2010]によれば)この仕様は、secp256k1楕円曲線であり、そのsecp256k1楕円曲線は、(次数nの)基本生成器点Gを含む。その楕円曲線における点乗算は、記号×によって示される。各々の当事者は、エントロピーの適切なソースを有する暗号的に安全な擬似乱数生成器(CSPRNG)を採用する。双方の当事者は、(例えば、SHA-256等の)暗号ハッシュ関数Hについて合意する。
【数3】
【0055】
初期セットアップ
【0056】
証明器は、最初に、2つの安全な且つランダムな秘密鍵を生成する、すなわち、
sk1←Zn
sk2←Zn
である。
sk1←Zn
sk2←Zn
である。
【0057】
証明器は、その次に、対応する公開鍵を計算する、すなわち、
PK1＝sk1×G
PK2＝sk2×G
である。
PK1＝sk1×G
PK2＝sk2×G
である。
【0058】
ある1つの構成において、これらの鍵は、その次に、ビットコインブロックチェーンにおけるアドレスとして使用されてもよく、それらのアドレスは、(次の節で説明されているように)ディジタル資産を制御するのに使用される。
【0059】
プロトコル
【0060】
1つの目的は、証明器が、sk1が公開された場合に、(鍵ckを検証器に安全に送信することによって)検証器が、sk2を計算する能力を有することを可能とすること、及び、(鍵ck及び公開鍵が与えられるときに)それらの検証器がその能力を有するということを検証器が認証する(検証する)こと、である。このことは、以下の手順によって達成される。すなわち、
1. 証明器は、値
ck＝sk2・sk1 －1 mod n
を計算する。
2. 証明器は、"値ckと公開鍵PK1及びPK2とが与えられる場合に、PK2についてのその秘密鍵は、ckで乗算されたPK1についての秘密鍵に等しい"という陳述(S)に対してコンパクトな非対話型のゼロ知識証明を計算し、その計算は、
(i) 安全な乱数r←Znを生成し、
(ii) コミットメントR＝r×Gを計算し、Rxは、点Rのx座標であり、
(iii) ハッシュH(Rx)を計算する。H(R)の最も左のln個のビットとしてxを設定する。なお、xは、シグマプロトコルの中で検証器が生成する"チャレンジ"値である。ここでは、ハッシュH(Rx)は、Hを使用するランダムなオラクルモデルにおいて、フィアットシャミアの発見的問題解決を使用して生成される。これにより、非対話型証明が得られる。
(iv) z＝sk1x＋rを計算する。
(v) その証明は、タプルπ＝(ck,R,x,z)である。
といった手順によって行われる。
3. 証明器は、検証器との間で安全な通信チャネルを確立し、それらの検証器に、公開鍵PK1及びPK2とともにタプルπを送信する。小売業者の設定の際に、このことは、物理的に近接させて近距離通信(NFC)デバイスを使用して実現されてもよい。オンラインの設定の際には、このことは、公開鍵暗号システムを使用して又はDiffie-Hellman鍵交換によって実現されるであろう。
4. 検証器は、
(i) C＝ck×Gを計算し、
(ii) x＝最も左のln個のH(Rx) (x＝left-most of ln H(Rx))、
z×G＝x×PK1＋R、及び、
z×C＝x×PK2＋ck×R、であるということを検証し、
(iii) 確認した場合には、有効であるとして値ckを受け入れる、
といった手順によって、タプルπを認証するとともに、したがって、陳述(S)が真であるということを認証する。
1. 証明器は、値
ck＝sk2・sk1 －1 mod n
を計算する。
2. 証明器は、"値ckと公開鍵PK1及びPK2とが与えられる場合に、PK2についてのその秘密鍵は、ckで乗算されたPK1についての秘密鍵に等しい"という陳述(S)に対してコンパクトな非対話型のゼロ知識証明を計算し、その計算は、
(i) 安全な乱数r←Znを生成し、
(ii) コミットメントR＝r×Gを計算し、Rxは、点Rのx座標であり、
(iii) ハッシュH(Rx)を計算する。H(R)の最も左のln個のビットとしてxを設定する。なお、xは、シグマプロトコルの中で検証器が生成する"チャレンジ"値である。ここでは、ハッシュH(Rx)は、Hを使用するランダムなオラクルモデルにおいて、フィアットシャミアの発見的問題解決を使用して生成される。これにより、非対話型証明が得られる。
(iv) z＝sk1x＋rを計算する。
(v) その証明は、タプルπ＝(ck,R,x,z)である。
といった手順によって行われる。
3. 証明器は、検証器との間で安全な通信チャネルを確立し、それらの検証器に、公開鍵PK1及びPK2とともにタプルπを送信する。小売業者の設定の際に、このことは、物理的に近接させて近距離通信(NFC)デバイスを使用して実現されてもよい。オンラインの設定の際には、このことは、公開鍵暗号システムを使用して又はDiffie-Hellman鍵交換によって実現されるであろう。
4. 検証器は、
(i) C＝ck×Gを計算し、
(ii) x＝最も左のln個のH(Rx) (x＝left-most of ln H(Rx))、
z×G＝x×PK1＋R、及び、
z×C＝x×PK2＋ck×R、であるということを検証し、
(iii) 確認した場合には、有効であるとして値ckを受け入れる、
といった手順によって、タプルπを認証するとともに、したがって、陳述(S)が真であるということを認証する。
【0061】
ここで、公開鍵(PK1)に対応する秘密鍵(sk1)が、(例えば、FR-P2PK出力を二重に支出した結果として)公開された場合に/ときに、検証器は、
sk2＝ck・ck1
にしたがって、sk2の値を決定することが可能である。
sk2＝ck・ck1
にしたがって、sk2の値を決定することが可能である。
【0062】
パフォーマンス
【0063】
プロトコルのプロトタイプ実装は、ビットコイン楕円曲線仕様(secp256k1)及びpyビットコインツールライブラリを採用して、パイソン(Python)(プログラミング言語の1つ)によって開発されている。この実装におけるプロトコルの各々のステップの速度性能は、インテルコアi7ラップトップに基づいて試験され、その結果は、(10回平均として)以下の表に示される。
【表1】
【0064】
ゼロ確認保護即時決済スキーム
【0065】
既存のFR-P2PKの1回限りの署名スキームの重大な欠点を克服するとともに、二重の支出攻撃に対する小売業者の保護と関連して、販売時点において即時の且つトラストレスのゼロ確認決済を行うことを可能にする上記で説明されている方法を、より大規模なスキームにおいて使用することが可能である。
【0066】
簡単に言うと、そのスキームは、FR-P2PKの出力に資金を送る"支出者(spender)"又は顧客に依存するとともに、これは、"即時の"POS購入を実行しようとするのに先立つ、同じトランザクションから、時間ロックされた出力(time-locked output)への"預金"額に依存している。その後、購入を行うときに、その顧客は、小売業者のアドレスに支払うFR-P2PK出力からのトランザクション支出に署名し、そして、FR-P2PK鍵が二重の支出の試みによって公開される場合に、並列的な時間ロックされた出力を請求するための対応する有効性証明及び補償鍵とともに、この署名されたトランザクションをその小売業者に送信する。二重の支出の試みを行う場合に(たとえ、二重の支出の試みが成功している場合であっても)、その小売業者は、ロック時間の後に、時間ロックされた出力の資金を請求することが可能である。いかなる二重の支出の試みも行われない場合には、その顧客は、時間ロックされた出力を再請求する(re-claim)ことが可能である。
【0067】
この場合に、小売業者は、購入を進めることを可能とするために、オンラインで動作する必要はなく、又は、ネットワークを介してのトランザクションの伝播をモニタリングする必要もない、すなわち、たとえ二重の支出攻撃用のトランザクションが最初に確認される場合であっても、それらの小売業者は、依然として、補償を請求することが可能であるということに留意すべきである。
【0068】
セットアップトランザクション
【0069】
そのスキームは、即時の購入に先立って、セットアップトランザクションを実行することをその顧客に要求し、そのセットアップトランザクションは、即時購入を行うことが可能である期間の間、時間ロックされる預金出力及び(予想される購入額を取り扱うための)FR-P2PK出力の双方への資金調達に関与する。預金出力の中に閉じ込められている(locked-up in the deposit output)額は、小売業者の要件に依存することとなる、すなわち、それらの小売業者は、購入を進めるために、購入価格と等しいか又はそれよりも大きな預金額を要求してもよい。それらの小売業者は、また、(それらの小売業者がオフラインで動作している場合に)ロックされている預金に対して最小の残り時間を要求してもよい、すなわち、そのロック時間(T)は、その次に、それらの顧客が支出する計画及び個人的なキャッシュフローに基づいて、顧客によって決定されるであろう。例えば、ある個人は、週末に大量の購入を行うことを計画している場合があり、そのため、それらの個人は、48時間の間、預金資金をロックするであろう(又は、それらの個人の財布は、自身の支出習慣に基づいて、自動的に預金資金をロックするであろう)。
【0070】
資金調達トランザクション(Tx0)は、そのとき、
資質出力:
額: S
固定のr値の署名(FR-P2PK)を使用してPK2に支払う
預金出力:
額: D
(OP_CHECKLOCKTIMEVERIFYを使用して)時間Tの後に、PKDに支払う、
というロック条件を有する2つの出力を含むであろう。
資質出力:
額: S
固定のr値の署名(FR-P2PK)を使用してPK2に支払う
預金出力:
額: D
(OP_CHECKLOCKTIMEVERIFYを使用して)時間Tの後に、PKDに支払う、
というロック条件を有する2つの出力を含むであろう。
【0071】
対応する完全なビットコイントランザクションスクリプトは、後の節において示される。
【0072】
セットアップトランザクションの作成の時点において、顧客が即時に支出する財布は、PK FR-P2PKを生成するのに使用されるksの値、(公開鍵PKsに対応する)秘密鍵sks、及び(公開鍵PKDに対応する)秘密鍵skDを安全に格納する。これは、スマートフォンアプリとして実装されてもよく、QRコード（登録商標）又はNFC無線によって小売業者と通信する。財布は、また、skD＝ck・sksである対応する証明π＝(ck,R,x,z)及び補償鍵ckを計算し、これらの値を安全に格納する。
【0073】
販売時点のトランザクション
【0074】
顧客は、その次に、時間Tの前に、小売業者を使用して購入を行う。顧客又は小売業者のいずれも、その購入の時点において、オンラインで動作している必要はないが、一方で、小売業者は、(セットアップトランザクションを含む)UTXOセットの直近のコピーを有している必要があり、また、時間Tの前に確認されたPOSトランザクションをブロードキャストすることができる必要であるとともに、そのPOSトランザクションを有することができる必要がある。
【0075】
トランザクションは、その次に、NFC無線(すなわち、財布アプリを実行する顧客のスマートフォン及び小売業者のカードリーダ)によって又は何らかの他の安全な通信チャネルを介して発生する顧客と小売業者との間の通信によって、以下のように進行する。
1. 小売業者のデバイスは、顧客に決済アドレス(公開鍵のハッシュ)及び決済額を送信する。
2. 顧客のアプリは、(おそらく、承認するためのPINコードを入力した後に)額を表示し、そして、確認を要求するであろう。
3. 顧客のアプリは、その次に、標準的なビットコイントランザクションTxRを構築し、その標準的なビットコイントランザクションTxRは、セットアップトランザクション(Tx0)のFR-P2PK出力を支出し、小売業者のアドレスに決済額を支払う(及び、アプリが生成するアドレスに返却代金を支払う)。
4. 顧客のアプリは、その次に、秘密鍵sksを使用するとともに、コミットされた一時的な鍵ksを使用して、TxRに署名する。
5. 顧客のアプリは、その次に、小売業者のデバイスに署名されたTxR、PKS、PKD、ck、及びπを送信する。
6. 小売業者のデバイスは、その次に、
(i) TxRが有効であるということ(正しい額及び正しいアドレス)、
(ii) TxRがPKSを使用して正しく署名されているということ、
(iii) PKSについてのUTXOが少なくとも1つの購入額を含んでいるということ、
(iv) PKDについてのUTXOが(小売業者のポリシーにしたがって)要求された預金を含んでいるということ、
(v) PKDについてのUTXOのための時間ロックTが要求された遅延を含んでいるということ、
(vi) 証明πが補償鍵ckを有効にしているということ(ステップ4は4.2節である)、
という検査を実行する。
7. トランザクションは完了し、購入は認可される。
1. 小売業者のデバイスは、顧客に決済アドレス(公開鍵のハッシュ)及び決済額を送信する。
2. 顧客のアプリは、(おそらく、承認するためのPINコードを入力した後に)額を表示し、そして、確認を要求するであろう。
3. 顧客のアプリは、その次に、標準的なビットコイントランザクションTxRを構築し、その標準的なビットコイントランザクションTxRは、セットアップトランザクション(Tx0)のFR-P2PK出力を支出し、小売業者のアドレスに決済額を支払う(及び、アプリが生成するアドレスに返却代金を支払う)。
4. 顧客のアプリは、その次に、秘密鍵sksを使用するとともに、コミットされた一時的な鍵ksを使用して、TxRに署名する。
5. 顧客のアプリは、その次に、小売業者のデバイスに署名されたTxR、PKS、PKD、ck、及びπを送信する。
6. 小売業者のデバイスは、その次に、
(i) TxRが有効であるということ(正しい額及び正しいアドレス)、
(ii) TxRがPKSを使用して正しく署名されているということ、
(iii) PKSについてのUTXOが少なくとも1つの購入額を含んでいるということ、
(iv) PKDについてのUTXOが(小売業者のポリシーにしたがって)要求された預金を含んでいるということ、
(v) PKDについてのUTXOのための時間ロックTが要求された遅延を含んでいるということ、
(vi) 証明πが補償鍵ckを有効にしているということ(ステップ4は4.2節である)、
という検査を実行する。
7. トランザクションは完了し、購入は認可される。
【0076】
トランザクション完了
【0077】
小売業者は、その次に、(確認時間を可能にする)時間Tの前に、ビットコインネットワークにトランザクションTxRをブロードキャストする。時間Tの後に、顧客は、その次に、新たなアドレスに預金出力を支出することが可能である。
【0078】
二重の支出攻撃
【0079】
顧客が、FR-P2PK出力を支出する(POS購入の前又は後の)いずれかの時点において、第2の攻撃用のトランザクションTxAをブロードキャストする場合に、二重の支出の試みは生起する。小売業者がまだTxRブロードキャストしていない場合に、TxAは、最初にそのブロックチェーンにおいて確認される。TxR及びTxAが同じ時点でブロードキャストされる場合に、2つの署名から秘密鍵skSを計算することが可能であり、採掘者は、ブロックに含めるために自身のトランザクションを前もって実行することが可能である。攻撃用のトランザクションが、(失敗した攻撃に起因して)TxRが確認された後にブロードキャストされる場合に、小売業者は、また、(購入価格を受信するのみならず)預金を請求することが可能である。いずれにしても、小売業者が、メンバープールの中の矛盾するトランザクション又はブロックチェーンにおいて確認されている矛盾するトランザクションのいずれかを観察する場合には、時間Tの前に、それらの小売業者は、TxRの署名及びTxAの署名からskSを計算することが可能である。
【0080】
小売業者は、その次に、
skD＝ck・skS
を計算する。
skD＝ck・skS
を計算する。
【0081】
顧客は、その次に、それらの顧客が制御するアドレスに預金出力を支出するトランザクションを構築し、そして、鍵skDを使用してそのトランザクションに署名する。このトランザクションは、その後、ロック時間Tが満了した直後に、ネットワークにブロードキャストされる。顧客は、また、鍵skDを知っており(又は、自身の財布アプリからその鍵を取得することが可能であり)、そして、同時に預金出力の支出を試みてもよい。この結果、小売業者又は顧客のトランザクションが明確なレースの中で最初に確認される確率は、厳密に50対50となるであろう(他の当事者がskDを取得し、前もってトランザクションを実行することは不可能である)。このことは、以前のスキームよりも小売業者にとってはるかに優れているが、一方で、小売業者は、このリスクに対抗するために、より高い(2倍の)預金額を要求することを望んでもよい(それによって、平均的には、それらの小売業者は、トランザクションにおいて決して損失を被ることはない)。
【0082】
利点
【0083】
提示されているスキームは、すべてが二重の支出トランザクションに起因する損失から保護されつつ、ネットワークへのトランザクションのブロードキャスト又はいずれかのブロック確認のいずれかを要求することなく、一方の当事者が、ビットコイントランザクションを使用するいずれかの他の当事者に即時且つオフラインで決済を行う方法を提供する。2つの当事者の間には、いかなる決済チャネルも必要とされず、支払い受取人は、確信をもって決済を受け入れるのに、単純な証明を検証するだけでよい。
【0084】
そのスキームは、いくつかのマイナス面を有する、すなわち、第1に、預金金額は、支払者によってある時間長の間、ロックされることを要求され、そのようなロックは、顧客の利用可能な資金及び流動性資産を一時的に減少させる。加えて、支払者は、システムをセットアップするために追加的なオンチェーントランザクション(on-chain transaction)を実行することを要求され、このトランザクションは、(署名マスクのために)比較的大きいサイズである。また、財布アプリケーションによって、及び、大量の購入を見込んで、そのスキームを自動化することが可能であるが、即時の且つオフラインのトランザクションを前もってセットアップする必要がある。
【0085】
上記のスキームは、最先端の技術に対する実質的な改良であり、即時の且つオフラインの決済を可能とし、その即時の且つオフラインの決済は、信頼できるハードウェアモジュール又は信頼できる第三者に依存することなく、受取人に対する損失リスクの総計を排除することを可能とするが、そのような即時の且つオフラインの決済を可能にするいかなる他のシステムも提案されてはいない。
【0086】
コアプロトコルのセキュリティ証明
【0087】
本明細書においては、プロトコルの鍵妥当性部分の証明のための正当化を提供し、その正当化は、ゼロ知識証明システムの要求される特性を満足する。
【0088】
検証器が、陳述が実際に真であるときに、その陳述が真であるということを常に確信している場合には、証明システムは、完全であるといわれる。
【0089】
このことは、
R＝r×G及びPK1＝sk1×Gであるので、
z＝sk1＋rであり、したがって、z×G＝x×(sk1×G)＋r×G＝x×PK1＋Rであり、
また、sk2＝ck・sk1であるので、
z×C＝x×(sk1・ck×G)＋ck×(r×G)＝x×PK2＋ck×Rである、
といったように、実証されてもよい。
R＝r×G及びPK1＝sk1×Gであるので、
z＝sk1＋rであり、したがって、z×G＝x×(sk1×G)＋r×G＝x×PK1＋Rであり、
また、sk2＝ck・sk1であるので、
z×C＝x×(sk1・ck×G)＋ck×(r×G)＝x×PK2＋ck×Rである、
といったように、実証されてもよい。
【0090】
証明器が真実ではない陳述の検証器を納得させることが不可能な場合には、証明システムは、妥当であるといわれる。不正な証明器が、誤った陳述が圧倒的な確率で真であるということを検証器に納得させることができないであろう場合には、このシステムは、統計的に妥当である。
【0091】
統計的な妥当性(statistical soundness)を実証するために、同じ鍵及びブラインド化(r)値(blinding (r) values)を使用して生成されるが、複数の異なるチャレンジ(x)の値を有する(検証器がそれらのタプルを受け入れる点で有効である)2つの有効なタプルπを考慮する(この証明の場合には、複数のランダムチャレンジは、フィアットシャミア(Fiat-Shamir)のランダムオラクルモデルに基づいて、妥当であるrとは独立して生成されると仮定する)。
π1＝(ck,R,x1,z1)
π2＝(ck,R,x2,z2)
π1＝(ck,R,x1,z1)
π2＝(ck,R,x2,z2)
【0092】
ここでは、タプルの対から証言(witness)(すなわち、秘密鍵)を抽出することが可能であるということを示すことを目的とし、したがって、その証言は、2つの個別のチャレンジを与えられた上で、存在する必要がある。したがって、ある1つの単一のチャレンジが検証につながる場合に、その証明器が、その陳述(statement)が真であるということを知ることなく、正しく答えることが可能である確率は、1/nである(nは、可能なチャレンジの数、すなわち、Gの次数である)。
z1×G＝x1×PK1＋Rからz2×G＝x2×PK1＋Rを減算し、
(z1－z2)×G＝(x1－x2)×PK1を得る。
したがって、
となる。
また、z1×C＝x1×PK1＋ck×Rからz2×C＝x2×PK2＋ck×Rを減算し、
(z1－z2)×C＝(x1－x2)×PK2を得る。
したがって、
となる。
このことは、タプルの対から値sk1及び値sk2を計算することが可能であり、そして、その証明が、統計的な妥当性を満たしているということを示している。
z1×G＝x1×PK1＋Rからz2×G＝x2×PK1＋Rを減算し、
(z1－z2)×G＝(x1－x2)×PK1を得る。
したがって、
【数4】
また、z1×C＝x1×PK1＋ck×Rからz2×C＝x2×PK2＋ck×Rを減算し、
(z1－z2)×C＝(x1－x2)×PK2を得る。
したがって、
【数5】
このことは、タプルの対から値sk1及び値sk2を計算することが可能であり、そして、その証明が、統計的な妥当性を満たしているということを示している。
【0093】
プロトコルの複写物(transcripts of the protocol)(すなわち、通信)が、シミュレーションされ、情報(特に、証言sk1及び証言sk2)を漏洩させない場合には、証明システムは、ゼロ知識といわれる。このことは、Special-Honest Verifier Zero Knowledge (SHVZK)の仮定の下で行われてもよく、SHVZKにおいては、チャレンジxは、検証器によって正直に且つランダムに生成される。
【0094】
その目的は、シミュレータ(S)の存在を実証することであり、そのシミュレータは、ランダムなチャレンジが与えられた場合に、(証人の知識を使用して、証明器によって作成される)現実のものと判別可能ではない複写物(transcript)を生成することが可能である。そのシミュレータは、その証人を知らないが、検証器を完全に制御する(そして、対話を"巻き戻す(re-wind)"ことが可能であり、したがって、前もってそのチャレンジを知ることが可能である)。
【0095】
そのシミュレーションは、
1. Sは、入力としてチャレンジの値xを利用し、
2. Sは、ランダム値zを選択し、
3. Sは、
R＝z×G－x×PK1
を計算する、
といったように、有効な複写物を生成することが可能である。
1. Sは、入力としてチャレンジの値xを利用し、
2. Sは、ランダム値zを選択し、
3. Sは、
R＝z×G－x×PK1
を計算する、
といったように、有効な複写物を生成することが可能である。
【0096】
結果として生じるタプルπ＝(ck,R,x,z)は、検査
z×G＝x×PK1＋(z×G－x×PK1)
z×C＝x×PK2＋ck×(z×G－x×PK1)
にしたがって有効となる。したがって、
z×ck×G＝x×ck×PK1＋ck×z×G－ck×x×PK1
となる。
フィアットシャミア(Fiat-Shamir)を使用し、そして、チャレンジの値をハッシュ関数の出力と置き換えることによって、正直な検証器の仮定を除くことが可能である。
z×G＝x×PK1＋(z×G－x×PK1)
z×C＝x×PK2＋ck×(z×G－x×PK1)
にしたがって有効となる。したがって、
z×ck×G＝x×ck×PK1＋ck×z×G－ck×x×PK1
となる。
フィアットシャミア(Fiat-Shamir)を使用し、そして、チャレンジの値をハッシュ関数の出力と置き換えることによって、正直な検証器の仮定を除くことが可能である。
【0097】
セットアップトランザクション
【0098】
この節は、セットアップトランザクションTx0の形式のある1つの例を示している。この例においては、出力スクリプトは、公開鍵に対する支払いであるが、それらの出力スクリプトは、アドレス(公開鍵のハッシュ)に対する支払いへと容易に修正される場合があり、そのスタックにおいて公開鍵を必要とする。そのトランザクションは、また、(isStandard()規則が課される場合に)引き換えスクリプト(redeem scripts)として提供される2つの出力スクリプトを使用してpay-to-script-hash (P2SH)として構築されてもよい。
【表2】
【0099】
コンピューティング環境
【0100】
図4は、さまざまな実施形態を実装することが可能であるコンピューティング環境を図示している概略的な図である。コンピューティングデバイス2600の例示的な且つ簡略化されたブロック図が提供され、そのコンピューティングデバイス2600は、本開示の少なくとも1つの実施形態を実現するのに使用されてもよい。さまざまな実施形態において、コンピューティングデバイス2600は、上記で解説されそして上記で説明されているシステムのうちのいずれかを実装するのに使用されてもよい。例えば、コンピューティングデバイス2600は、データサーバ、ウェブサーバ、携帯用コンピューティングデバイス、パーソナルコンピュータ、又はいずれかの電子コンピューティングデバイスとして使用するように構成されてもよい。図4に示されているように、コンピューティングデバイス2600は、1つ又は複数のレベルのキャッシュメモリ及びメモリコントローラを有する(集合的に2602の標識を付されている)1つ又は複数のプロセッサを含んでもよく、それらの1つ又は複数のプロセッサは、メインメモリ2608及び永続的な記憶装置2610を含むストレージサブシステム2606と通信するように構成されてもよい。メインメモリ2608は、示されているように、ダイナミックランダムアクセスメモリ(DRAM)2618及び読み取り専用メモリ(ROM)2620を含んでもよい。ストレージサブシステム2606及びキャッシュメモリ2602は、本開示において説明されているトランザクション及びブロックと関連する詳細等の情報の格納のために使用されてもよい。1つ又は複数のプロセッサ2602は、本開示において説明されているいずれかの実施形態のステップ又は機能を提供するのに利用されてもよい。
【0101】
1つ又は複数のプロセッサ2602は、また、1つ又は複数のユーザインターフェイス入力デバイス2612、1つ又は複数のユーザインターフェイス出力デバイス2614、及びネットワークインターフェイスサブシステム2616と通信してもよい。
【0102】
バスサブシステム2604は、コンピューティングデバイス2600のさまざまな構成要素及びサブシステムが、意図されるように互いに通信することを可能とするメカニズムを提供してもよい。バスサブシステム2604は、単一のバスとして概略的に示されているが、バスサブシステムの代替的な実施形態は、複数のバスを利用してもよい。
【0103】
ネットワークインターフェイスサブシステム2616は、他のコンピューティングデバイス及びネットワークへのインターフェイスを提供してもよい。ネットワークインターフェイスサブシステム2616は、コンピューティングデバイス2600からデータを受信し、及び、コンピューティングデバイス2600から他のシステムにデータを送信するためのインターフェイスとして機能してもよい。例えば、ネットワークインターフェイスサブシステム2616は、データ技術者が、ネットワークにデバイスを接続することを可能としてもよく、それによって、そのデータ技術者は、データセンター等の遠隔の位置にある間に、そのデバイスにデータを送信し、及び、そのデバイスからデータを受信することを可能としてもよい。
【0104】
ユーザインターフェイス入力デバイス2612は、キーボード等の1つ又は複数のユーザ入力デバイス、一体化されたマウス、トラックボール、タッチパッド、又はグラフィックスタブレット等のポインティングデバイス、スキャナ、バーコードスキャナ、ディスプレイに組み込まれているタッチスクリーン、音声認識システム、マイクロフォン等の音声入力デバイス、及び、他のタイプの入力デバイスを含んでもよい。一般的に、"入力デバイス"の語の使用は、コンピューティングデバイス2600に情報を入力するためのすべての可能なタイプのデバイス及びメカニズムを含むことを意図している。
【0105】
1つ又は複数のユーザインターフェイス出力デバイス2614は、ディスプレイサブシステム、プリンター、又はオーディオ出力デバイス等の非視覚的ディスプレイ等を含んでもよい。ディスプレイサブシステムは、陰極線管(CRT)、液晶ディスプレイ(LCD)、発光ダイオード(LED)ディスプレイ等のフラットパネルデバイス、又は投影又は他のディスプレイデバイスであってもよい。一般的に、"出力デバイス"の語の使用は、コンピューティングデバイス2600から情報を出力するためのすべての可能なタイプのデバイス及びメカニズムを含むことを意図している。1つ又は複数のユーザインターフェイス出力デバイス2614は、例えば、ユーザインターフェイスを提示して、アプリケーションとの間の対話が適切であるときに、説明されているプロセス及びそれらのプロセスの変形を実行するアプリケーションとの間のそのようなユーザ対話を容易にするのに使用されてもよい。
【0106】
ストレージサブシステム2606は、コンピュータ読み取り可能な記憶媒体を提供してもよく、そのコンピュータ読み取り可能な記憶媒体は、本開示の少なくとも1つの実施形態の機能を提供することが可能である基本プログラミング構成及びデータ構成を格納する。(プログラム、コードモジュール、命令等の)アプリケーションは、1つ又は複数のプロセッサによって実行されるときに、本開示の1つ又は複数の実施形態の機能を提供することが可能であり、ストレージサブシステム2606の中に格納されてもよい。これらのアプリケーションモジュール又は命令は、1つ又は複数のプロセッサ2602によって実行されてもよい。ストレージサブシステム2606は、追加的に、本開示にしたがって使用されるデータを格納するためのリポジトリを提供してもよい。例えば、メインメモリ2608及びキャッシュメモリ2602は、プログラム及びデータのための揮発性記憶装置を提供してもよい。永続的な記憶装置2610は、プログラム及びデータのための永続的な(不揮発性の)記憶装置を提供してもよく、フラッシュメモリ、1つ又は複数のソリッドステートドライブ、1つ又は複数の磁気ハードディスクドライブ、関連する取り外し可能なメディアを有する1つ又は複数のフロッピーディスクドライブ、関連する取り外し可能なメディアを有する(例えば、CD-ROM又はDVD又はブルーレイ等の)1つ又は複数の光ドライブ、及び他の同様の記憶媒体を含んでもよい。そのようなプログラム及びデータは、本開示において説明されている1つ又は複数の実施形態のステップを実行するためのプログラムのみならず本開示において説明されているトランザクション及びブロックと関連するデータを含んでもよい。
【0107】
コンピューティングデバイス2600は、携帯用コンピュータデバイス、タブレットコンピュータ、ワークステーション、又は以下で説明されているいずれかの他のデバイスを含むさまざまなタイプのコンピューティングデバイスであってもよい。追加的に、コンピューティングデバイス2600は、他のデバイスを含んでもよく、そのような他のデバイスは、(例えば、USB、ヘッドフォンジャック、ライトニングコネクタ(Lightning connector)等の)1つ又は複数のポートによってコンピューティングデバイス2600に接続されてもよい。コンピューティングデバイス2600に接続されることが可能であるデバイスは、光ファイバコネクタを受け入れるように構成される複数のポートを含んでもよい。したがって、このデバイスは、複数の光信号を複数の電気信号に変換するように構成されてもよく、それらの複数の電気信号は、処理のために、そのデバイスを接続するポートを介してコンピューティングデバイス2600に送信されてもよい。コンピュータ及びネットワークの絶えず変化する性質のために、図4に示されているコンピューティングデバイス2600の説明は、そのデバイスの好ましい実施形態を解説するためのある特定の例として意図されているにすぎない。図4に示されているシステムよりもより多くの構成要素又はより少ない構成要素を有する多くの他の構成が可能である。
【0108】
範囲
【0109】
また、上記で言及されている複数の実施形態及び例は、本発明を限定するのではなく例示するものであり、当業者が、添付の特許請求の範囲が定義する本発明の範囲から離れることなく、多くの代替的な実施形態を設計することが可能であるということに留意すべきである。
【0110】
特許請求の範囲において、括弧の中に記載されている参照符号は、請求項に記載されている発明を限定するものと解釈されるべきではない。"含んでいる"及び"含む"等の語は、いずれかの請求項又は明細書全体の中に列挙されている要素又はステップ以外の要素又はステップの存在を除外するものではない。本明細書において、"含む"は、"含む又はから構成される"を意味し、"含んでいる"は、"含んでいる又はから構成されている"を意味する。ある要素の単数形の言及は、そのような要素の複数形の言及を除外するものではなく、その逆もまた同様である。本発明は、複数の個別の要素を含むハードウェアによって実装されてもよく、また、適切にプログラムされているコンピュータによって実装されてもよい。複数の手段を列記しているデバイスの請求項においては、これらの複数の手段のうちのいくつかは、ハードウェアの1つの同じ項目によって具体化されてもよい。複数の特定の特徴が相互に異なる従属請求項に記載されているという事実のみでは、これらの手段の組み合わせを有益に利用することは不可能であるということを示すものではない。
【0111】
[参考文献]
[1] [Perez-Sola 2017]: Perez-Sola, Cristina, et al. "Double-spending Prevention for Bitcoin zero-confirmation transactions" IACR Cryptology ePrint Archive 2017 (2017): 394
[2] [Damgard 2010]: Damgard, Ivan. "On Σ-protocols, 2010" (URL: www.cs.au.dk/ivan.Sigma.pdf)
[3] [Lindell 2015]: Lindell, Yehuda. "An Efficient Transform from Sigma Protocols to NIZK with a CRS and Non-Programmable Random Oracle" TCC (1). 2015.
[4] [Fiat 1986]: Amos Fiat and Adi Shamir: How to Prove Yourself: Practical Solutions to Identification and Signature Problems. CRYPTO 1986: pp. 186-194
[5] [Bootle 2015]: Bootle, Jonathan, et al. "Efficient zero-knowledge proof systems" Foundations of Security Analysis and Design VIII. Springer, Cham, 2015. 1-31.
[6] [Schnorr 1990]: C P Schnorr, Efficient identification and signatures for smart cards, in G Brassard, ed. Advances in Cryptology - Crypto '89, 239-252, Springer-Verlag, 1990. Lecture Notes in Computer Science, nr 435
[7] [SEC 2010]: Standards for Efficient Cryptography (SEC) (Certicom Research, (URL:http://www.secg.org/sec2-v2.pd)
[1] [Perez-Sola 2017]: Perez-Sola, Cristina, et al. "Double-spending Prevention for Bitcoin zero-confirmation transactions" IACR Cryptology ePrint Archive 2017 (2017): 394
[2] [Damgard 2010]: Damgard, Ivan. "On Σ-protocols, 2010" (URL: www.cs.au.dk/ivan.Sigma.pdf)
[3] [Lindell 2015]: Lindell, Yehuda. "An Efficient Transform from Sigma Protocols to NIZK with a CRS and Non-Programmable Random Oracle" TCC (1). 2015.
[4] [Fiat 1986]: Amos Fiat and Adi Shamir: How to Prove Yourself: Practical Solutions to Identification and Signature Problems. CRYPTO 1986: pp. 186-194
[5] [Bootle 2015]: Bootle, Jonathan, et al. "Efficient zero-knowledge proof systems" Foundations of Security Analysis and Design VIII. Springer, Cham, 2015. 1-31.
[6] [Schnorr 1990]: C P Schnorr, Efficient identification and signatures for smart cards, in G Brassard, ed. Advances in Cryptology - Crypto '89, 239-252, Springer-Verlag, 1990. Lecture Notes in Computer Science, nr 435
[7] [SEC 2010]: Standards for Efficient Cryptography (SEC) (Certicom Research, (URL:http://www.secg.org/sec2-v2.pd)
【図1】
【図2】
【図3】
【図4】