(57)【要約】  ブロックチェーン上の複数のユーザの間でトランザクション・ミキシングを行うシステムが提供される。ブロックチェーンは、例えばビットコイン・ブロックチェーンである。システムは、（ｉ）リソースの制御を第１のユーザの送信元アドレスから第２のユーザの受信アドレスに送信するように構成された第１のコミットメント・トランザクションを準備するステップと、（ｉｉ）リソースの制御を第２のユーザの送信元アドレスから別のユーザの受信アドレスに送信するように構成された第２のコミットメント・トランザクションを準備するステップと、（ｉｉｉ）リソースの制御を別のユーザの送信元アドレスから（ａ）第１のユーザの受信アドレス、又は（ｂ）さらに別のユーザの受信アドレスのいずれかに送信するように構成された更なるコミットメント・トランザクションを準備するステップであって、トランザクション・チェーンを完了するためにオプション（ａ）が実行されるまでステップ（ｉｉｉ）を繰り返す、ステップと、（ｉｖ）トランザクション・チェーンを実行するステップと、を実施するように構成されている。ユーザのうちの少なくとも１人が複数のユーザからランダムに選択される。
2020517011.tif 000002
【特許請求の範囲】
【請求項１】
ブロックチェーン上の複数のユーザの間でトランザクション・ミキシングを行うためのシステムであって、当該システムは、
（ｉ）リソースの制御を第１のユーザの送信元アドレスから第２のユーザの受信アドレスに送信するように構成された第１のコミットメント・トランザクションを準備するステップと、
（ｉｉ）リソースの制御を前記第２のユーザの送信元アドレスから別のユーザの受信アドレスに送信するように構成された第２のコミットメント・トランザクションを準備するステップと、
（ｉｉｉ）リソースの制御を前記別のユーザの送信元アドレスから
（ａ）前記第１のユーザの受信アドレス、又は
（ｂ）さらに別のユーザの受信アドレス次のいずれかに送信するように構成された更なるコミットメント・トランザクションを準備するステップであって、トランザクション・チェーンを完了するためにオプション（ａ）が実行されるまでステップ（ｉｉｉ）を繰り返す、ステップと、
（ｉｖ）前記トランザクション・チェーンを実行するステップと、を実施するように構成されており、
前記ユーザのうちの少なくとも１人が前記複数のユーザからランダムに選択される、
システム。
【請求項２】
少なくとも１つのコミットメント・トランザクションが、少なくとも１つの前記コミットメント・トランザクションの実行条件を満たすことに応答して、それぞれのリソースの制御を送信するように構成される、請求項１に記載のシステム。
【請求項３】
それぞれの実行条件を満たすように構成された少なくとも１つの実行トランザクションを準備するステップを実行するようにさらに構成される、請求項２に記載のシステム。
【請求項４】
少なくとも１つの前記コミットメント・トランザクションの実行条件には、それぞれのシークレット値の供給が含まれる、請求項２又は３に記載のシステム。
【請求項５】
少なくとも１つのシークレット値が前記第１のユーザによって選択され、少なくとも１つの実行条件には前記選択されたシークレット値の供給が含まれる、請求項４に記載のシステム。
【請求項６】
少なくとも１つのシークレット値が、（ｉ）前記選択されたシークレット値の供給、及び（ｉｉ）少なくとも１つの他のシークレット値の供給の少なくとも１つに応答して計算可能である、請求項５に記載のシステム。
【請求項７】
少なくとも１つのコミットメント・トランザクションが、返還条件が満たされると、それぞれのリソースの制御をそれぞれのユーザに戻すように構成される、請求項１乃至６のいずれか一項に記載のシステム。
【請求項８】
ロック時間（LcokTime）を含む少なくとも１つの返還トランザクションを準備するステップを実行するようにさらに構成され、前記少なくとも１つの返還トランザクションは、前記ロック時間の満了時に少なくとも１つのそれぞれの返還条件を満たすように構成される、請求項７に記載のシステム。
【請求項９】
少なくとも１つの準備されたトランザクションをブロックチェーンに送信するようにさらに構成される、請求項１乃至８のいずれか一項に記載のシステム。
【請求項１０】
前記トランザクション・チェーンが準備された順序と逆の順序で前記トランザクション・チェーンを実行するようにさらに構成される、請求項１乃至９のいずれか一項に記載のシステム。
【請求項１１】
前記リソースが互いに同一である、請求項１乃至１０のいずれか一項に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、ブロックチェーン・トランザクションに関し、より具体的には、３人以上のユーザを含むグループ内のブロックチェーン・トランザクションの交換に関する。本発明は、ビットコイン（ＢＴＣ）ブロックチェーンでの使用に特に適しているが、これに限定されるものではない。
【背景技術】
【０００２】
この文書では、あらゆる形態の電子的なコンピュータベースの分散型台帳を含めるために「ブロックチェーン」という用語を使用している。これらの形態には、コンセンサスベースのブロックチェーン及びトランザクション・チェーン技術、アクセス許可された台帳とアクセス許可されていない台帳、共有台帳、及びこれらのバリエーションが含まれる。ブロックチェーン技術の最も広く知られている用途はビットコイン台帳であるが、他のブロックチェーン実施態様が提案され開発されている。本明細書では、便宜上及び例示の目的でビットコインについて参照しているが、本発明はビットコイン・ブロックチェーンでの使用に限定されるものではなく、代替のブロックチェーン実施態様及びプロトコルが本発明の範囲内にあることに留意されたい。
【０００３】
ブロックチェーンはピアツーピアの電子台帳であり、この台帳はブロックで構成されるコンピュータベースの非中央型の分散システムとして実施され、ブロックはトランザクションで構成される。各トランザクションは、ブロックチェーンシステムのユーザ同士の間でのデジタル資産の制御の移転をエンコードするデータ構造であり、少なくとも１つの入力と少なくとも１つの出力とを含む。各ブロックには以前のブロックのハッシュが含まれており、これらブロックは、一緒にチェーンで繋がれており、その開始からブロックチェーンに書き込まれた全てのトランザクションの永続的な変更不可能なレコードを作成する。トランザクションには、それらの入力及び出力に埋め込まれたスクリプトとして知られている小さなプログラムが含まれており、スクリプトは、トランザクションの出力に誰がどの様にアクセスできるかを指定する。ビットコイン・プラットフォームでは、これらのスクリプトはスタックベースのスクリプト言語を使用して記述される。
【０００４】
トランザクションをブロックチェーンに書き込むためには、「検証」する必要がある。ネットワークノード（マイナー（採掘者）：miners）は、各トランザクションが有効であることを確認する作業を行い、無効なトランザクションはネットワークから拒否される。ノードにインストールされたソフトウェアクライアントは、そのロック及びロック解除スクリプトを実行することにより、未使用（unspent）トランザクション（ＵＴＸＯ）でこの検証作業を行う。ロック及びロック解除スクリプトの実行がＴＲＵＥと評価された場合に、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれる。こうして、トランザクションをブロックチェーンに書き込むためには、そのトランザクションは、ｉ）トランザクションを受信する第１のノードで検証する（トランザクションが検証されると、ノードはその検証したトランザクションをネットワーク内の他のノードに中継する）；ｉｉ）マイナーによって構築された新しいブロックに追加する；ｉｉｉ）採掘する、すなわち過去のトランザクションの公的な台帳に追加する必要がある。
【０００５】
ブロックチェーン技術は暗号通貨の実施態様の使用で最も広く知られているが、デジタル起業家は、ビットコインがベースとする暗号セキュリティシステムと、ブロックチェーンに保存して新しいシステムを実施できるデータとの両方の使用を模索し始めている。暗号通貨の領域に限定されない自動化されたタスク及びプロセスにブロックチェーンを使用できれば、非常に有利である。このようなソリューションによって、ブロックチェーンの利点（例えば、イベントの永続的な改ざん防止記録、分散処理等）を活用しながら、アプリケーションの用途を広げることができる。
【０００６】
現在の研究の１つの分野は、「スマートコントラクト（smart  contracts：契約の自動化）」の実装にブロックチェーンを使用することである。これらスマートコントラクトは、機械可読な契約又は同意の条件の実行を自動化するように設計されたコンピュータプログラムである。自然言語で記述される従来のコントラクト（契約）とは異なり、スマートコントラクトは、結果を生むために入力を処理できる規則を含むマシン実行可能プログラムであり、その結果、それらの結果に応じて動作を実行させることができる。
【０００７】
ブロックチェーンに関連するもう１つの関心分野は、「トークン」（つまり、「カラードコイン」）を使用して、ブロックチェーンを介して実世界のエンティティを表現し且つそのエンティティで転送することである。潜在的に機密又は秘密のアイテムは、識別可能な意味や価値を有さないトークンで表すことができる。こうして、トークンは、実世界のアイテムをブロックチェーンから参照できるようにする識別子として機能する。
【０００８】
広く公開された（open,  public）台帳を提供するブロックチェーンは、利害関係者に、特定のデジタルコイン、デジタル資産、又はデジタルリソースの制御の一連のアドレスに亘る動きを追跡する機能を与える。例えば、通貨としてのビットコインの有効性及び成功は、ビットコインの実際の、知覚される（プロパティの有無による）代替可能性（fungibility）に結びついている。代替可能性は、あるユニットの商品と同じ種類の他のユニット商品との互換性プロパティである（http://www.investopedia.com/terms/f/fungibility.asp）。公開され、分散される台帳は、システムを信頼するための手段として機能する際に有用であるが、アドレス同士の間でトランザクションを追跡できるため、特定の履歴トランザクションに関連するデジタル資産を解析して相関させることができる。ビットコインの追跡不可能性（fungibility）に対処するために、セキュリティ及び匿名化ソリューションが開発された。多くの実世界の商取引は、法律上の理由、商業上の理由、又はその両方のために本質的に機密情報であるため、これは有益である。従って、ブロックチェーンの公共性にもかかわらず、ブロックチェーンシステムは、そのような商取引のセキュリティと機密性との両方を確保できなければならない。
【０００９】
ビットコインの匿名性の研究には、ZeroCash（Ben-Sasson,  E.,  et  al.  (2014),  “Zerocash:  Decentralized  Anonymous  Payments  from  …”,  http://zerocash-project.org/media/pdf/zerocash-oakland2014.pdf）及びMonero（Mackenzie,  A.,  Noether,  S.,  et  al.  (2015),  “Improving  Obfuscation  in  …”,  https://lab.getmonero.org/pubs/MRL-0004.pdf）等のアルトコインの開発が含まれている。同様に、ビットコイン互換性ソリューションが開発された。これらの互換性のあるソリューションの中で、コイン・ミキシング及び関連するバリエーションが最も一般的であるが、TumbleBit（Heilman,  E.,  Alshenibr,  L.,  Baldimtsi,  F.,  Scafuro,  A.  and  Goldberg,  S.  2016  TumbleBit:  An  untrusted  Bitcoin-compatible  anonymous  payment  hub.  Cryptology  ePrint  Archive,  Report  2016/575;  https://eprint.iacr.org/2016/575.pdf）、及びステルス・アドレスの使用  (Franco,  P.,  (2014),  “Understanding  Bitcoin:  Cryptography  …”,  http：//eu.wiley.com/WileyCDA/WileyTitle/productCd-1119019168.html）等の他の独創的な匿名化技術も存在する。これら全てのソリューションに共通するのは、（ユーザが支払人である場合、又はユーザが受取人である場合の）特定のビットコイン・トランザクション及びアドレスからユーザの関連付けを解除する手段である。
【００１０】
コイン・ミキシング・ソリューションの場合に、ユーザはビットコインをサービスに入力し、それらビットコインはユーザが選択した出力アドレスに転送される。出力アドレスに送信する前に資金がプールされているため、どの出力アドレスがユーザのものであるかを解明することは困難である。
【発明の概要】
【００１１】
本発明者らは、背景技術の段落で説明したブロックチェーンのトランザクション・ミキシング手法に関するいくつかの技術的及びセキュリティ関連の問題を特定した。このようなトランザクション・ミキシング手法には、ミキシング・サービス・プロバイダーが必要である。これにより、追加のリソース要件がシステムに導入され、この中央型トランザクション・ミキシング・サービス・プロバイダーを提供するための管理間接費（overhead）が追加される。さらに、中央型トランザクション・ミキシング・サービス・プロバイダーの提供により、ブロックチェーンシステムの分散型のピアツーピア・アーキテクチャが希薄化され又は損なわれる。このような中央型システムは、ユーザから制御（control）を取り去る。さらに、このような中央型システムは、システムに攻撃の焦点を与える。さらに、トランザクション・ミキシング・サービス・プロバイダーは、ユーザのデジタル資産をプールから盗み取り、入力アドレスと出力アドレスとの間のリンクを意図的に又は意図せずに外部に公開する可能性があり、こうしてセキュリティ及び機密性が低下する。多くの点で、中央型トランザクション・ミキシング・サービス・プロバイダーの提供は、中央型機関の要件を無効にすることを目的とした、非中央型ピアツーピア・ブロックチェーンシステムの基本的な精神を損なわせる。
【００１２】
上記に照らして、解決すべき１つの技術的問題は、既存のソリューションよりも非中央型、安全、及び機密性の高い方法でブロックチェーンのトランザクション・ミキシングを実現可能にし、且つ背景技術の段落で説明した既存のシステムの方法のように第３者のトランザクション・ミキシング・サービス・プロバイダーによる管理ではなく、システムのユーザにより制御されるソリューションをどの様に提供するかである。
【００１３】
こうして、本発明によれば、添付の特許請求の範囲で規定される方法及びシステムが提供される。
【００１４】
本発明は、コンピュータで実施されるシステムを提供することができる。これは、ブロックチェーンで実施されるシステム、セキュリティシステム、及び／又は制御システムとして説明できる。
【００１５】
追加的又は代替的に、本発明は、ブロックチェーン上の複数のユーザの間でトランザクション・ミキシングを行うためのシステムを提供することができ、このシステムは、（ｉ）リソースの制御を第１のユーザの送信元アドレスから第２のユーザの受信アドレスに送信するように構成された第１のコミットメント・トランザクションを準備するステップと；（ｉｉ）リソースの制御を第２のユーザの送信元アドレスから別のユーザの受信アドレスに送信するように構成された第２のコミットメント・トランザクションを準備するステップと；（ｉｉｉ）リソースの制御を別のユーザの送信元アドレスから（ａ）第１のユーザの受信アドレス又は（ｂ）さらに別のユーザの受信アドレスのいずれかに送信するように構成された更なるコミットメント・トランザクションを準備するステップであって、トランザクション・チェーンを完了するためにオプション（ａ）が実行されるまでステップ（ｉｉｉ）を繰り返す、ステップと；（ｉｖ）トランザクション・チェーンを実行するステップと；を実施するように構成され、ユーザのうちの少なくとも１人が複数のユーザからランダムに選択される。
【００１６】
「ユーザ」という用語は、人間又はプロセッサベースのリソースを指す場合がある。
【００１７】
このようなシステムを提供することにより、複数のユーザが、セキュリティと機密性を高めたリソースの交換を可能にするトランザクション・チャネルを構築することができる。トランザクション・ミキシング・システムは、チェーン内の複数のユーザから少なくとも１人のユーザがランダムに選択されるブロックチェーン・トランザクション・チェーンを形成及び実行する点で異なる。チェーンは、コミットメント・トランザクションを使用して設定される。複数のユーザの間でデジタル資産を交換するためのそのようなシステムは、背景技術の段落で説明した従来技術の構成と比較すると、より安全であり、追加のシステム間接費を必要としない。例えば、システムは、この中央型トランザクション・ミキシング・サービス・プロバイダーを提供するためにシステムに追加のリソース要件と追加の管理間接費を導入するような気がするミキシング・サービス・プロバイダーを必要としない。さらに、中央型トランザクション・ミキシング・サービス・プロバイダーの提供により、ブロックチェーンシステムの非中央型のピアツーピア・アーキテクチャが希薄化され又は損なわれる。このような中央型システムは、ユーザから制御を取り去る。さらに、このような中央型システムは、システムに攻撃の焦点を与える。さらに、トランザクション・ミキシング・サービス・プロバイダーは、ユーザのデジタル資産をプールから盗み取り、入力アドレスと出力アドレスとの間のリンクを意図的に又は意図せずに外部に公開する可能性があり、こうしてセキュリティが低下する。対照的に、本システムでは、コミットメント・トランザクションのチェーンを介してトランザクションを準備及び実行することは、第３者ではなくユーザによって実行される。つまり、システムは、第３者によって実施／制御されないプロトコルを利用する。
【００１８】
本発明の１つの技術的効果は、新しい方法で動作するように形成されたコンピュータシステムをもたらす。さらに、コンピュータシステムは、システムがハッキングやデータ操作に対してより堅牢である限り、より効率的且つ効果的に実行されるという意味で、より優れたコンピュータシステムである。
【００１９】
少なくとも１つのコミットメント・トランザクションが、少なくとも１つのコミットメント・トランザクションの実行条件を満たすことに応答して、それぞれのリソースの制御を送信するように構成され得る。
【００２０】
これにより、トランザクション・チェーンの少なくとも一部が実行され得る速度が向上するという利点がある。
【００２１】
システムは、それぞれの実行条件を満たすように構成された少なくとも１つの実行トランザクションを準備するステップを実行するように構成され得る。
【００２２】
これにより、トランザクション・チェーンの少なくとも一部が実行され得る速度がさらに向上するという利点がある。
【００２３】
少なくとも１つのコミットメント・トランザクションの実行条件には、それぞれのシークレット値の供給が含まれ得る。
【００２４】
これにより、第１のユーザにリスクを与えることなくトランザクション・チェーンを構築することができる一方、トランザクション・チェーンのその後の実行をより安全に行うことができる。
【００２５】
少なくとも１つのシークレット値が第１のユーザによって選択され得、少なくとも１つの実行条件には選択されたシークレット値の供給が含まれ得る。
【００２６】
これにより、ユーザのセキュリティを簡単な方法で高めるという利点がある。
【００２７】
少なくとも１つのシークレット値が、（ｉ）選択されたシークレット値の供給、及び（ｉｉ）少なくとも１つの他のシークレット値の供給の少なくとも１つに応答して計算可能である。
【００２８】
これにより、トランザクション・チェーンの実行を完了するのにかかる時間を大幅に増やすことなく、様々なシークレット値を使用可能にすることにより、システムのセキュリティを高めるという利点がある。
【００２９】
少なくとも１つのコミットメント・トランザクションが、返還（return）条件が満たされると、それぞれのリソースの制御をそれぞれのユーザに戻すように構成され得る。
【００３０】
これにより、ユーザからの少なくとも１つのリソースの窃盗に対するセキュリティを高めるという利点がある。
【００３１】
システムは、ロック時間を含む少なくとも１つの返還トランザクションを準備するステップを実行するように構成され、少なくとも１つの返還トランザクションは、ロック時間の終了時に少なくとも１つのそれぞれの返還条件を満たすように構成され得る。
【００３２】
これにより、システムの使用中に許可される最大時間を制限し、それにより必要なコンピュータリソースの量を削減できるという利点がある。
【００３３】
システムは、少なくとも１つの準備されたトランザクションをブロックチェーンに送信するように構成され得る。
【００３４】
これは、少なくとも１つの準備されたトランザクションをブロックチェーンに保存することにより、少なくとも１つの準備されたトランザクションの改ざんを防止し、それによりセキュリティを高めるという利点がある。
【００３５】
システムは、トランザクション・チェーンが準備された順序と逆の順序でトランザクション・チェーンを実行するように構成され得る。
【００３６】
これにより、第１のユーザが、完了したコミットメント・トランザクションのチェーンの実行を開始することができ、これにより、複数のユーザのうちの１人のユーザに対するリスクを分離することにより、セキュリティを高める。
【００３７】
リソースは互いに同一である、以前のいずれかに記載のシステム。
【００３８】
これにより、システムの使用が簡素化されるという利点がある。
【００３９】
追加的又は代替的に、ブロックチェーン上の複数のユーザの間のトランザクション・ミキシングに参加するためのコンピュータで実施される方法を提供することができ、この方法は、（ｉ）第１のコミットメント・トランザクションの実行条件が満たされると、第１のリソースの制御を第１のユーザの送信元アドレスから第２のユーザの受信アドレスに送信するように構成された第１のコミットメント・トランザクションをブロックチェーンに送信するステップと；（ｉｉ）第３のリソースの制御を第３のユーザの送信元アドレスから第１のユーザの受信アドレスに送信するように構成された第２のコミットメント・トランザクションのブロックチェーンへの送信に応答して、第３のコミットメント・トランザクションの実行条件を満たすように構成された実行トランザクションをブロックチェーンに送信するステップと；を含み、ユーザのうちの少なくとも１人が複数のユーザからランダムに選択される。
【００４０】
追加的又は代替的に、ブロックチェーン上の複数のユーザの間のトランザクション・ミキシングに参加するためのコンピュータで実施される方法を提供することができ、この方法は、（ｉ）第１のコミットメント・トランザクションの条件が満たされると、リソースの制御を第１のユーザの送信元アドレスから第２のユーザの受信アドレスに送信するように構成された第１のコミットメント・トランザクションをブロックチェーンに送信するステップと；（ｉｉ）第１のコミットメント・トランザクションの条件を満たすように構成された第１の実行トランザクションのブロックチェーンへの送信に応答して、第２のコミットメント・トランザクションの条件を満たすように構成された第２の実行トランザクションをブロックチェーンに送信するステップと；を含み、ユーザのうちの少なくとも１人は複数のユーザからランダムに選択される。
【００４１】
特定の構成によれば、少なくとも１人の個人が、両方のアドレスの間のリンクを隠し、且つ中央型コイン・ミキシング・サービス・プロバイダーを必要としない安全な方法で達成される方法で、ビットコインを自分のアドレスから別のアドレスに移動できるようにすることが望ましい場合がある。これは、個人がグループ交換プロトコルに参加し、各メンバーがグループｘの交渉された金額のビットコインを別のランダムメンバーに支払い、及び別のランダムメンバーが交渉された金額のビットコインをユーザｘに支払うシステムを提供することで実現できる。交換プロトコルは、ユーザが自分の資金を新しいアドレスに効率的に移動し、グループ交換のメンバーがビットコインを失うリスクを負わないように設計されている。
【図面の簡単な説明】
【００４２】
本発明のこれら及び他の態様は、本明細書に記載の実施形態を参照して説明され、これらの実施形態から明らかになろう。ここで、本発明の実施形態を、単なる例として、添付の図面を参照して説明する。
【図１】従来技術の支払チャネルで使用されるトランザクションを示す図である。
【図２】従来技術のアトミック・クロスチェーン取引アルゴリズムを示す図である。
【図３】本発明の第１の実施形態の支払チャネルを示す図である。
【図４】本発明の支払チャネルが作成される順序を示す図である。
【図５】第１の実施形態の支払チャネルのチェーンを示す図である。
【図６】第１の実施形態のコミットメント・トランザクションの例を示す図である。
【図７】第１の実施形態の返金トランザクションの例を示す図である。
【図８】第１の実施形態の支払トランザクションの例を示す図である。
【図９】図１の支払チャネルを構築するためのアルゴリズムを示す図である。
【図１０】第１の実施形態の支払チャネルを構築するためのアルゴリズムを示す図である。
【図１１】第１の実施形態の支払チャネルのチェーンを構築するためのアルゴリズムを示す図である。
【図１２】第１の実施形態の支払トランザクションを送信するプロセスのアルゴリズムを示す図である。
【図１３】本発明の第２の実施形態の支払チャネルを示す図である。
【図１４】第２の実施形態の支払チャネルを構築するためのアルゴリズムを示す図である。
【図１５】第２の実施形態の支払チャネルのチェーンを構築するためのアルゴリズムを示す図である。
【図１６】第２の実施形態の支払チャネルのチェーンを示す図である。
【図１７】第２の実施形態の支払チャネルのチェーンの実行の表現を示す図である。
【図１８】第２の実施形態の支払トランザクションを送信するプロセスのアルゴリズムを示す図である。
【図１９】返金トランザクションを含む第２の実施形態の支払チャネルのチェーンを示す図である。
【図２０】第２の実施形態の返金トランザクションのロック時間要件を示す図である。
【図２１】第２の実施形態のコミットメント・トランザクションの例を示す図である。
【図２２】第２の実施形態の返金トランザクションの例を示す図である。
【図２３】第２の実施形態の支払トランザクションの例を示す図である。
【図２４】第２の実施形態で使用するスクリプトの例を示す図である。
【発明を実施するための形態】
【００４３】
本明細書では、本発明を具現化するグループランダム交換（ＧＲＥ）プロトコルと呼ばれるプロトコルについて説明し、このプロトコルは、ユーザがあるアドレスから別のアドレスに資金を移動する一方、ユーザのアドレス同士の間のリンクを覆い隠し、ユーザが自分の資金を盗まれる可能性を排除するためのものである。このプロトコルは、グループの各メンバーがｘＢＴＣを他の１人のメンバーに支払い、それにより全員が支払いを受け取ることに同意するグループの概念に基づいて構築される。
【００４４】
ユーザがｘＢＴＣを誰に支払うかはランダムであり、誰がユーザにｘＢＴＣを支払うかもランダムである。これにより、ユーザは自分のｘＢＴＣをあるアドレスに送信し得るが、ランダムに決定された別のユーザからの別のアドレスでｘＢＴＣの受信を受け取る。このランダム性により、プロトコルの外部の誰かがブロックチェーンを解析し、ユーザの入力アドレスと出力アドレスとの間のリンクを決定することを困難にさせる。
【００４５】
さらに、ＧＲＥプロトコルは、あるグループのｎ人のユーザの間でこの交換を行うことができ、グループ内のユーザは自分の資金を失うリスクはない。プロトコルは、該当する場合は返金（refund）トランザクションを使用して、プロトコルの実行の際に計画通りに進まない場合にユーザが自分の資金を回収できるようにする。
【００４６】
ＧＲＥプロトコルは、既存の２つのビットコイン関連技術に基づいている。これら技術うちの第１の技術は、支払チャネル（’Introduction  to  Micropayment  Channels’  http://super3.org/introduction-to-micropayment-channels/）であり、これは、一対（２人）のユーザの間のブロック外のビットコイン・トランザクション用に設計された技術であり、特に返金トランザクションの使用を組み込む。これらの技術のうちの第２の技術は、アトミック・クロスチェーン取引（ＡＣＣＴ）（’Atomic  cross-chain  trading’  https://en.bitcoin.it/wiki/Atomic_cross-chain_trading）であり、これは、ある暗号通貨をｘコイン有するユーザが、自分のｘコインを、別の暗号通貨をｙコイン有する別のユーザと交換するように設計されたプロトコルである。これは「公正な交換」として行われ、第１のユーザは、第２のユーザが第１のユーザが所有しているコインを徴収できるようにしない限り、第２のユーザのコインを取得できない。
【００４７】
ＡＣＣＴは２人のユーザの間の交換について説明するが、本発明は、２人以上のユーザの間でのグループ交換を提供するＧＲＥプロトコルに関連しており、ＧＲＥプロトコルでは、第１のユーザが支払いを行う第２のユーザは、第１のユーザに支払いを行うユーザではない。
【００４８】
支払チャネル
支払チャネルは、全てのトランザクションをブロックチェーンにコミット（commit）せずに、ユーザが複数のビットコイン・トランザクションを作成できるように設計された技術である。一般的な支払チャネルの実施態様では、ほぼ無制限の支払いを行うことができるが、支払チャネルは、２つのトランザクションをブロックチェーンに追加するだけで十分である。
【００４９】
ブロックチェーンに追加されるトランザクション数を減らすこと及び関連するコストを削減することに加えて、支払チャネルには速度の利点もあり、重要なことに、物事が計画通りに進まなかったり、又はいずれかのユーザが特定の支払いセットを超えて先に進まないことを決定したりする場合に、ユーザが自分の資金を回収することができる。支払チャネルの実施態様の説明を以下に概説する。
【００５０】
アリス（Alice）がサービスに対してボブ（Bob）に支払う必要があるシナリオを考えてみる。状況に応じて、一定期間に亘ってアリスからボブへの複数の支払いが必要になる場合がある。アリスは、可能な交換セットでボブに最大１５ＢＴＣ（合計）を使うことを予定している。これを容易にするために、アリスとボブとの間に支払チャネルが確立され、次のように動作する。
・アリスは、アリスとボブとの両方によって管理される、２オブ２（2-of-2）マルチシグネチャのPay  to  Scriptハッシュ（Ｐ２ＳＨ）トランザクションＴＣを作成し、アリスから発信される１５ＢＴＣをコミット（付託）する。この時点では、トランザクションはビットコイン・ネットワークに送信されていない（このようなマルチシグネチャのアドレスでは、２人の個人（アリスとボブ）がこのアドレスからお金を使うトランザクションに署名する必要がある）。
・アリスは、別個の返金トランザクションＴｒ，０を作成し、「マルチシグネチャ管理ファンド」から全ての資金をアリスに戻す。このトランザクションには、１００ブロックのｎＬｏｃｋＴｉｍｅ値が含まれる（ｎＬｏｃｋＴｉｍｅ（ｎロック時間）は、指定した時間が経過した後にのみビットコイン・トランザクションを実行できるようにするビットコイン・トランザクション・パラメータである）。ボブはトランザクションに署名する。この返金トランザクションは、ｎＬｏｃｋＴｉｍｅが発生した後に、アリスとボブと間の交換が食い違う場合に、アリスに返金することができる。
・アリスは元のトランザクションＴＣに署名する。
・この時点で、アリスとボブは、アリスからボブに行われた（ブロックチェーン外の）支払いを反映するために、新しい返金トランザクションの作成に進むことができる。これらの返金トランザクションは、その時点でアリスがボブに支払うために必要な純額（net  sum  of  money）を反映する。例として、アリスがボブに５ＢＴＣを支払う場合に、５ＢＴＣをボブに送信し、１０ＢＴＣをアリスに送り返す出力を有する新しい返金トランザクションＴｒ，ｉが作成される。アリスがボブに別の５ＢＴＣを支払う必要がある場合に、１０ＢＴＣをボブに送信し、５ＢＴＣをアリスに返り返す出力を有する新しい返金トランザクションＴｒ，ｉ＋１が作成される。新しい返金トランザクション毎に、両者が詳細に同意すると仮定すると、両当事者はトランザクションに署名するが、必ずしもトランザクションをネットワークに送信するわけではない。
・作成された連続する各返金トランザクションは、以前の返金トランザクションのｎＬｏｃｋＴｉｍｅよりも短いことに留意されたい。
・ｎＬｏｃｋＴｉｍｅ（Ｔｒ，ｉ＋１）＜ｎＬｏｃｋＴｉｍｅ（Ｔｒ，ｉ）
・ユーザがＴｒ，ｉに署名するのを拒否した場合に、被害を受けたユーザは単にＴｒ，ｉ−１を送信すればよい。最悪シナリオの場合に、アリスはＴｒ，０に署名し、このＴｒ，０をネットワークに送信して（ｎＬｏｃｋＴｉｍｅが経過した後に）自分の全ての資金を回収する。
・構築された最終的な返金トランザクションは、アリスからボブに送金された資金の純額を表す。このトランザクションはネットワークに送信される。
【００５１】
図１は、支払チャネルで使用されるトランザクションを示している。Ｍは、アリスからボブに送信できる最大金額を表す。ｘｉは、アリスがボブに支払う必要がある現在の資金の純額である。Ｓｓｔｏｐは、初期の返金トランザクションのｎＬｏｃｋＴｉｍｅである。ｎは、アリスとボブとの間で進行中の（ブロック外の）支払いで作成された返金トランザクションの数である（これは初期の返金トランザクションを除く）。ｓは、ある当事者が以前の返金トランザクションを送信する他の当事者にリスクを与える前に、両方のユーザが返金トランザクションに同意するために割り当てられた時間であり、アリスとボブとの間の交換を事実上終了させる時間である。
【００５２】
以下に留意されたい。
ｔ＋ｎ＊ｓ  ＜Ｓｓｔｏｐ、ここでtは現在の時間であり、
（Ｓｓｔｏｐ−ｎ＊ｓ）≧ｓ。
【００５３】
図１のトランザクションＴＣ及びＴr，ｎは、ブロックチェーンに表示されるトランザクションである。
図９は、アリスとボブとの間の支払チャネルを構築する際に含められるステップを含むフローチャートを示している。
【００５４】
アトミック・クロスチェーン取引
デジタル交換の場合に、「公正な交換（fair  exchange）」プロトコルが必要になることがよくある。交換は、あるユーザＵｓｅｒＡが値ｘを所有しており、それをＵｓｅｒＢが所有する値ｙと交換したいシナリオを表す。公正な交換プロトコルにより、２人のユーザが、（ｉ）支払いの受入れと交換との両方を行うこと、又は（ｉｉ）支払いの受入れも交換も行わないことのいずれかを実行できる。Even,  S.  and  Yacobi,  Y.,  1980.  Relations  among  public  key  signature  systems  (Vol.  268).  Technical  Report  175,  Technion,  Haifa,  Israel,  （http://ftp.cs.technion.ac.il/users/wwwb/cgi-bin/tr-get.cgi/1980/CS/CS0175.pdf）では、信頼できる第３者がいなければ決定論的な公正な交換は不可能であることが示されている。
【００５５】
ＡＣＣＴの場合に、この創作者は２人のユーザが別々の暗号通貨の間でコインを交換するための公正な交換プロトコルを考案した。このソリューションでは、暗号通貨のブロックチェーンが信頼できる第３者として機能する。ＡＣＣＴのアルゴリズムを図２に示す。ここで、アリスＡは、ｖアルトコインと引き換えに、ｗＢＴＣをボブＢに支払う。
【００５６】
これはＡＣＣＴ（タイムアウト付き）である。プロセスが一時停止された場合に、いつ停止しても元に戻すことができる。
【００５７】
図２を参照すると、ユーザＡ及びＢがＡＣＣＴを使用している間のイベントのタイムラインの例は次のとおりである。
１）の前：（ブロードキャストすべき）公開されているものがないため、何も起こらない。
１）と２）の間：Ａは７２時間後に返金トランザクションを使用して、自分のお金を取り戻すことができる。
２）と３）の間：Ｂは２４時間後に返金を受け取ることができる。Ａは返金を受け取るために２４時間以上を要する。
３）後：２）までにトランザクションが完了し、
−Ａは２４時間以内に自分の新しいコインを使う必要がある。そうでない場合に、Ｂは返金を請求して自分のコインを保持することができる。
−Ｂは７２時間以内に自分の新しいコインを使う必要がある。そうでない場合に、Ａは返金を請求して自分のコインを保持することができる。
安全のため、ＡとＢとの両方が期限までに多くの時間をかけてプロセスを完了する必要がある。
【００５８】
グループランダム交換
本発明は、グループランダム交換（ＧＲＥ）プロトコルに関する。本発明は、ｎ＞２のｎ人のユーザのグループ内でビットコインを交換するためのソリューションを提供する。グループ内の各ユーザは、自分の所有しているビットコインの量を同じ量のビットコインに交換できる。
【００５９】
ただし、プロトコルに変更を加えないと、２人のユーザの間で交換されるビットコインの量が等しくならない可能性がある。ＵｉとＵ（ｉ＋１）  ｍｏｄ  ｎとの間で交換される値は、ユーザのペアが自分達でネゴシエートできる任意の値であり得る。
【００６０】
ｘＢＴＣが交換される合意金額であると想定し、影響を受ける全てのユーザにとって望ましい場合に、ユーザは（ｘ＋ａ）ＢＴＣを支払うことができるが、ユーザは（ｘ−ｂ）ＢＴＣを引き出すことができる。例えば、ユーザＵ１には交換用の１０ＢＴＣがある。８ＢＴＣがＵ１に利用可能な最良のオファーである場合に、Ｕ１はユーザＵ０から８ＢＴＣを受け取る。Ｕ１はこれを行うが、更なるユーザＵ２が１０ＢＴＣの受取りを要求する可能性が残っていることを理解している。換言すれば、Ｕ１が支払う値は、Ｕ１がこれらの条件を受け入れる場合に限り、Ｕ１に支払われる値である必要はなく、Ｕ１が要求する場合に、Ｕ１が支払う値はＵ１に支払われる値である場合がある。
【００６１】
これ以降、説明は、説明目的で、各ユーザがｘＢＴＣを支払ってｘＢＴＣの支払いを受け取るシナリオにのみ限定される。
【００６２】
さらに、ユーザはプロトコル内でトークンを交換することができる。トークンは、トークンの制御が資産又はリソースの制御を提供するように、トークンに関連付けられたスマートコントラクトに従って資産又はリソースを表す。
【００６３】
ユーザが所有するビットコインの正味の変化は、取引手数料が無視されると仮定すると、交換プロトコルに参加した後も変わらない（取引手数料は全てのビットコイン・トランザクションに関連する費用である）。第１のユーザがＵｓｅｒＡである場合に、ＵｓｅｒＡは総額ｘＢＴＣをＵｓｅｒＢに支払い、ＵｓｅｒＣはｘＢＴＣをＵｓｅｒＡに支払う。ここで、ＵｓｅｒＢはＵｓｅｒＣと同じユーザではない。さらに、各ユーザは、支払いの送信に関連付けられた送信元アドレスと、支払いの受信に関連付けられた受信アドレスとを有しており、送信元アドレスと受信アドレスとは異なる。ただし、プロトコルに参加することで、ビットコイン・アドレスに保管されたユーザのビットコインは、同じユーザによって所有又は管理される別のアドレスに実際に転送される。交換プロトコル・プロセスにより、アドレス同士の間でのビットコインの転送は、ブロックチェーンの解析において、資金の転送を明確にしない方法で達成される。
【００６４】
ＡＣＣＴは一対のユーザの間の相互交換のみを概説するが、ＧＲＥプロトコルはＡＣＣＴとは異なり、ＧＲＥプロトコルは次の場合の交換を記述する。
・３人以上のユーザが存在する。
・支払いを受け取る及び支払いを行うプロセスにおいて、第１のユーザが支払いを行う第２のユーザは、第１のユーザが支払いを受け取るユーザではない。
【００６５】
ＧＲＥプロトコルは、これを次の方法で達成する。
・プロトコルのユーザは、自分のビットコインを失うリスクはない。
・第１のユーザが支払いを行う第２のユーザは、第１のユーザに支払いを行うユーザと同様にランダムである。
【００６６】
第１のタイプのグループランダム交換−シークレット値
グループランダム交換プロトコルは、２つの方法のうちの１つで動作し、各方法は本発明を具現化する。次に、本発明の構成について説明する。
【００６７】
ｎ人のユーザＵｉ｜（ｉ）∈［０，ｎ−１］のセットが、本発明の構成のＧＲＥプロトコルに参加して、ｘＢＴＣを交換することを考えると、プロトコルは次のように動作する。
・順序付けられたセット｛Ｕ０，Ｕ１，…，Ｕｎ−２，Ｕｎ−１｝を実現するために、ユーザはランダム化される。
・これらのユーザの１人は「開始者（initiator）」又は「開始ユーザ」と見なされる。この目的のために、Ｕ０は開始者と見なされる。
・開始者Ｕ０は乱数ｋを選択し、Ｈ（ｋ）を計算する。ここで、Ｈ（・）は決定論的なハッシュ関数を表す。
・ｋの値はＵ０によってプライベートに保持されるが、値Ｈ（ｋ）はＧＲＥの全てのユーザに配信される。
・支払チャネルＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎを構築し、ｋの値を取得し、Ｕ（ｉ＋１）  ｍｏｄ  ｎに支払いを行う実行トランザクションＴｐａｙをビットコイン・ネットワークに送信するために各ユーザＵｉに与えられる時間量を表す時間値ｓが選択される。グループ内の任意のユーザは、他のユーザのコンセンサスを考慮して、時間ｓを選択することができる。好ましい実施形態では、開始者は、単にプロトコルに対してｓを選択する。時間ｓは、秒又はブロック数で表される。
・別の値Ｓが、ビットコイン・ネットワークに送信される、ユーザに対する最初の支払いの開始時間として選択される。グループ内のユーザは、他のユーザのコンセンサスを考慮して、Ｓを選択することができる。好ましい実施形態では、開始者は、単にプロトコルに対してｓを選択する。ＳはＵｎｉｘ時間又はブロックの高さで指定された時点を表し、ｓは時間範囲を表すことに留意されたい。
・全ての一対のユーザの間に一方向の支払チャネルが確立され、支払いの方向は、ＵｉがＵ（ｉ＋１）  ｍｏｄ  ｎに支払いを行うような方向（ここではＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎで表される）である。例として、ｎ＝７と仮定すると、ＧＲＥの支払チャネルは、Ｕ０→Ｕ１，Ｕ１→Ｕ２，…，Ｕ６→Ｕ０で構成される。
・支払チャネルＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎの作成プロセスを図３及び図１０に示す。ここで、σ（Ｕｉ）はＵｉの署名を表す。
ｏ初期コミットメント・トランザクションＴＣによって、（ｉ）ＵｉとＵ（ｉ＋１）  ｍｏｄ  ｎとの両方の署名、又は（ｉｉ）ｋ及びＵ（ｉ＋１）  ｍｏｄ  ｎの署名（図６を参照）のいずれかを提供することによってのみ使うことができるｘＢＴＣが利用可能になる。
ｏここでは１つの返金トランザクションのみが必要である。返金機能Ｔｒ，０によって、全てのｘＢＴＣをＵｉに返す（図７を参照）。
ｏ返金トランザクションＴｒ，０には、ｎＬｏｃｋＴｉｍｅ値Ｓ＋（ｎ−ｉ）ｓが含まれる。
ｏ初期コミットメント・トランザクションＴＣがビットコイン・ネットワークに送信される前に、Ｕ（ｉ＋１）  ｍｏｄ  ｎが返金トランザクションＴｒ，０に署名する必要がある。
ｏ支払チャネルには、ＴＣのコミット済みｘＢＴＣからＵ（ｉ＋１）  ｍｏｄ  ｎにｘＢＴＣを支払う支払トランザクションＴｐａｙが含まれる。
ｏＵ（ｉ＋１）  ｍｏｄ  ｎへの支払トランザクションＴｐａｙの＜scriptSig＞には、値ｋが含まれる（図８を参照）。
・支払チャネルＵｉ−１→Ｕｉが支払チャネルＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎの前に設定されるため、一対のユーザの間の支払チャネルを規則正しい順序で作成することが重要である。これは、第１の支払チャネルＵ０→Ｕ１の作成から始まり、ここでＵ０が開始者であり、最後の支払チャネルＵｎ−１→Ｕ０で終了する。図４は、支払チャネルの構築順序を示している。
【００６８】
一部の構成では、ユーザＵｉが支払いを行う際にリスクを負う前に、次のことを確認できるようにするので、シーケンスの順序が重要である。
・ＵｉへのＴｐａｙトランザクションが存在し、トランザクションＴｐａｙがビットコイン・ネットワークで受け入れられるためには、Ｕｉがｋの知識を有しているだけでよい。
・支払チャネルＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎ（Ｕｉが使う）のＴｐａｙにある基準は、支払チャネルＵｉ−１→Ｕｉ（Ｕｉが受け取る）のＴｐａｙの基準と同じである。
【００６９】
開始者Ｕ０のみが、支払いに先立って受取りを優先する必要はない。ただし、ｋの値を知っているユーザはＵ０だけなので、Ｕ０をだますことはできない。従って、Ｕ０がプロセスを快適に開始するまで（ｋのリリース（解除）と一致するまで）ＧＲＥプロトコルにおいてだれでも引出しを行うことができない。
【００７０】
ＧＲＥインスタンスのＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎ支払チャネルのセットを作成するプロセスを図１１に示す。
【００７１】
最終的な支払チャネルＵｎ−１→Ｕ０は、時刻Ｓに又はその前に終了するものと想定される。この最終的な支払チャネルが構築されると、トランザクションのチェーン、つまりトランザクション・チェーンは、プロトコルの全てのユーザのリンク付けを完了したと言うことができる。
【００７２】
図５は、ＧＲＥプロトコルの全てのユーザの間に存在するＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎの支払チャネルの表現を示している。矢印は、支払チャネルとＴｐａｙ支払いの方向とを示す。矢印の外部に隣接する式は、ブロックチェーンによって受け入れられるトランザクションＴｐａｙの基準を表す。σ（Ｕｉ）はＵｉの署名を表すことに留意されたい。矢印の内部に隣接する式は、ｓの期間値を表す。
【００７３】
円形の配置に照らして、Ｕｉ｜ｉ∈［０，ｎ−１］の順序がランダムであるという事実は、ユーザＵｉに支払いを行う人とユーザＵｉが支払いを受け取る人が両方ともランダムであることを意味する。さらに、ユーザＵｉに支払いを行う人とユーザＵｉが支払いを受ける人は異なる。
【００７４】
開始者Ｕ０は、既存の支払チャネルＵｎ−１→Ｕ０のトランザクションＴｐａｙを使って、ｋの値を明らかにする。Ｕ０はこのｋの値をＵｎ−１に直接伝えることができる、又は、この値はブロックチェーンから取得することができる。
【００７５】
同様に、各ユーザＵｉは、値ｋをその支払者Ｕｉ−１に直接伝えることができる。Ｕｉが見つからない場合に、ユーザＵｉ−１は（少なくとも時間ｓ内に）ブロックチェーン台帳でこの値を見つけることができる。
【００７６】
この出願の提出時においてブロックチェーンがトランザクションを確認するのに平均１０分かかるため、ｓの値は、そのｓの値が表す期間が、ユーザＵｉが必要に応じてその期間内に、トランザクションがビットコイン・ネットワークに送信された後の（支払チャネルＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎの）トランザクションＴｐａｙにおいてｋの値を見つけるのに十分であるように選択する必要がある。ｓの値には、一対のユーザの間の支払チャネルの構築にかかる推定時間も含める必要がある。従って、ｓはｓ＝ｓｋ＋εになるように選択することができ、ここで、ｓｋはｋを見つけてＴｐａｙを送信するための推定時間であり、εは支払チャネルを構築するための推定時間である。
【００７７】
開始ユーザＵ０が、Ｕｎ−１とＵ０との間の既存の支払チャネルのＴｐａｙトランザクションをネットワークに送信したため、ｋの値をＵｎ−１に公開すると、次に、ｋの値を（Ｕｎ−１からＵ２への）逆の順序で他の全てのユーザＵｉに公開することができる。これは、各ユーザＵｉが、支払いを受け取ることができるトランザクション（Ｕｉ−１からＵｉへの支払チャネルのＴｐａｙ）を送信する際に権限が与えられる（invested）という前提に基づいている。このトランザクションを送信するユーザＵｉは、（以前に利用可能になっていた）ＵｉからＵｉ＋１への支払チャネルのＴｐａｙからｋの値を取得する必要がある。ＵｉがＵｉ−１からＵｉへの支払チャネルのそのトランザクションＴｐａｙを送信することにより、次に、ｋの値がユーザＵｉ−１に利用可能になる。このプロセスは、Ｕｎ−１からＵ１まで全てをカスケードし（次々に行われ）、換金する（cashing  in）各ユーザＵｉがｋをユーザＵｉ−１に明らかに、ユーザＵｉ−１も換金することができるようにする。
【００７８】
より形式的には、支払チャネルを実行するＴｐａｙトランザクションの送信シーケンスは次のようになる。
［Ｔｐａｙ：Ｕｎ−１→Ｕ０］，［Ｔｐａｙ：Ｕｎ−２→Ｕｎ−１］，…，［Ｔｐａｙ：Ｕ１→Ｕ２］，［Ｔｐａｙ：Ｕ０→Ｕ１］
【００７９】
Ｔｐａｙトランザクションのセットが完了すると、ＧＲＥが首尾よく終了する。各ユーザはｘＢＴＣを支払い、各ユーザはｘＢＴＣを受け取る。
【００８０】
ＧＲＥインスタンスのためにＴｐａｙ：Ｕｎ−１→Ｕ（ｉ＋１）  ｍｏｄ  ｎトランザクションを送信するプロセスについて図１２に示す。
【００８１】
以下では、一対のユーザの間の支払チャネルＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎで使用されるビットコイン・トランザクションの構築について説明する。これらの支払チャネルは、３つの主要なトランザクションで構成されている。
・２−ｏｆ−２マルチシグネチャ・トランザクションＴＣへの入金：このトランザクションは、支払チャネルのコミットメント・コンポーネントを表し、コミットメント・トランザクションと呼ばれる場合がある。ここで、トランザクションを通じて、ユーザＵｉは指定された数のビットコインｘＢＴＣを送信／コミット（付託）して、次のいずれかによって管理する。
ｏ２−ｏｆ−２マルチシグネチャ（Ｕｉ，Ｕ（ｉ＋１）  ｍｏｄ  ｎ）、又は
ｏ値ｋの知識及びＵ（ｉ＋１）  ｍｏｄ  ｎの署名。
・返金トランザクションＴｒ，０：このトランザクションは、指定された時間が経過した後に（コミットメント・トランザクションから）ユーザＵｉに返されるｘＢＴＣの返金を表す。このトランザクションを首尾よく実行するには、ユーザＵｉ及びＵ（ｉ＋１）  ｍｏｄ  ｎの署名が必要である。
・支払トランザクションＴｐａｙ：このトランザクションは、ＵｉからＵ（ｉ＋１）  ｍｏｄ  ｎへのｘＢＴＣの支払いである。このトランザクションを首尾よく実行するには、値ｋの知識及びＵ（ｉ＋１）  ｍｏｄ  ｎの署名が必要である。支払トランザクションは、実行トランザクションとも呼ばれる場合がある。
【００８２】
トランザクションの詳細は、＜scriptSig＞、＜scriptPubkey＞、ｎＬｏｃｋＴｉｍｅ、及び様々なトランザクションの出力値に限定されるが、これらは説明しているＧＲＥプロトコルに最も関連しているため、他の関数及び値を使用できることに留意されたい。
【００８３】
第２のタイプのグループランダム交換−シークレットの変更
次に、本発明の更なる構成について説明する。
上記の構成のＧＲＥプロトコルの場合に、各支払チャネルに共通の値ｋは、ＧＲＥがそのユーザに提供し得る匿名性のレベルの制限として機能し得る。これは、ｋ及び／又はそのハッシュＨ（ｋ）の共有使用により、外部オブザーバーがＧＲＥの特定のインスタンスに関連するトランザクションのセットを簡単に関連付けることができるためである。これにより、あるアドレスから別のアドレスへのユーザの資金移動を追跡するために必要なオブザーバーの労力が軽減される。
【００８４】
同じシークレット値を全ての支払チャネルで使用する上述した構成とは対照的に、以下で説明する構成では、ＧＲＥ交換の際に支払チャネル毎に異なるシークレット値を使用する。さらに、シークレット値はチャネル毎に異なるが、トランザクションがブロックチェーンに送信されたときのシークレット値の公開は、シーケンスの次の支払チャネルでのシークレット値のその後の公開に十分な情報を提供する。
【００８５】
この機能を実現するために、この構成では、Ｅ（ｍ）＋Ｅ（ｎ）＝Ｅ（ｍ＋ｎ）のような楕円曲線（ＥＣ）暗号化のプロパティを利用し、ここで、Ｅ（ｘ）＝ｘＧであり、Ｇは楕円曲線上の基点である。ただし、ＥＣ暗号化の代わりに、実質的に類似した準同型の特性を有する他のタイプの暗号化を使用してもよい。
【００８６】
楕円曲線は、以下の式によって記述される点のセットである。
ｙ２≡ｘ３＋ａｘ＋ｂ  （ｍｏｄ  ｐ）
ここで、
【数１】
2020517011.tif 000003
であり、ｐは素数である。
【００８７】
ビットコイン・スクリプト内で必要なＥＣ算術機能は、スカラーによるポイント乗算である。これは次のような演算である。
【数２】
2020517011.tif 000004
ここで、ｎは自然数、Ｐは楕円曲線上の点、＋はＥＣ上の点を加算するための演算子である。
【００８８】
次に、スカラー乗算には、特定のＥＣグループ演算であるポイントの加算とポイントの倍増とが必要である。
・ポイントの加算Ｐ＋Ｑ：この演算では、ＥＣ上の新しい点をこの曲線の交点の否定（negation：交点ではない点）として計算する。これは、Ｒ＝Ｐ＋Ｑと記述することができる。
・ポイントの倍増Ｐ＋Ｐ：ポイントの加算を使用してＰの２倍のポイントを計算することができる。これは、Ｒ＝Ｐ＋Ｐ＝２Ｐと記述することができる。
【００８９】
より具体的には、ＥＣ上にＰ（ｘ１，ｙ１）とＱ（ｘ２，ｙ２）の２つのポイントが与えられた場合に、
Ｐ＋Ｑ＝（ｘ３，ｙ３）
ここで、
ｘ３＝ｍ２−ｘ１−ｘ２  ｍｏｄ  ｐ
ｙ３＝ｍ（ｘ１−ｘ３）−ｙ１  ｍｏｄ  ｐであり、そして
【数３】
2020517011.tif 000005
【００９０】
上述したように、同じシークレット値を全ての支払チャネルで使用する構成のＧＲＥ回路内の支払チャネル毎の基準として、値ｋ（及びタンデムでのＨ（ｋ））の使用は、匿名性への欲求に関連して、制限であると証明することができる。
【００９１】
ユーザがビットコインの移動に関連してＧＲＥ交換での匿名性を望む場合に、Ｕ１がｘＢＴＣを支払うアドレスは、ユーザがｘＢＴＣを受け取るアドレスと異なることが予想される。このアドレス同士の間の切断は、ビットコイン・ブロックチェーン内で支払トランザクション及び受取トランザクションの互いに関連付けを解除することを目的としている。
【００９２】
ただし、ＧＲＥプロトコルの知識を有する外部オブザーバーは、あるタイプの基準を含むスクリプトを使用したビットコイン・トランザクションがＧＲＥのインスタンスのアーティファクトであることを知っている。さらに、ｋ及びそのハッシュがこれらのＧＲＥインスタンスのサブセット内で見つかるため、外部オブザーバーは、ＧＲＥの特定のインスタンスに関連する全てのトランザクションを識別できるか、又は可能なトランザクションのセットのサイズを少なくとも大幅に削減できる。成功を保証するわけではないが、これにより、外部のオブザーバーはＧＲＥインスタンスにおけるビットコインの動きを追跡するためにより良い位置に置かれる。
【００９３】
この構成では、ＧＲＥプロトコルを使用し、各支払チャネルでは、異なる一意のシークレット値（ｓｖ）と、シークレット値の対応する暗号化バージョンとが使用される。この構成では、ハッシュ関数自体は使用されず、ＥＣ暗号化に置き換えられることに留意されたい。これにより、外部オブザーバーが特定のＧＲＥインスタンスに属するトランザクションのセットを識別する能力が低下する。
【００９４】
この構成の異なるシークレット値は、次の条件を満たすことが期待される。
ａ．シークレット値は推測するのが難しいはずである。
ｂ．支払チャネルＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎのＴｐａｙを実行する際にｓｖ（ｉ＋１）  ｍｏｄ  ｎの公開によって、ＧＲＥシーケンスの次の支払チャネルＵｉ−１→Ｕｉ（反時計回り）のｓｖ１を公開するか、又は少なくとも容易に計算できるようにする必要がある。
ｃ．外部オブザーバーがシークレット鍵（又はシークレット鍵（secret  key）暗号化（暗号文））同士の間の関係を特定するのは難しいはずである。
ｄ．交換に参加するユーザは、自分の資金を失うリスクがないはずである。
【００９５】
ハッシュ関数の代替としてＥＣ暗号化を使用して、以前の基準を満たすことができる。ＥＣ暗号化では、スカラー値にＥＣ上の基点Ｇが乗算される。スカラー値ｋはシークレット鍵であり、Ｑ＝ｋＧは暗号化された出力である。Ｑからｋを決定することは、「困難な（hard）」離散対数問題である。
【００９６】
さらに、楕円曲線演算の加算演算子の場合に、基点Ｇに対してｍＧ＋ｎＧ＝（ｍ＋ｎ）Ｇである。
【００９７】
ＥＣ暗号のこの特性により、条件ｂ．について別のシークレット値が順に明らかになる。
【００９８】
ｎ人のユーザ｛Ｕ１｜ｉ∈［０，ｎ−１］｝のグループがＧＲＥプロトコルに参加して、ｘＢＴＣを交換することを考えると、本発明のこの構成のプロトコルは以下のように動作する。
・ユーザは、楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）曲線（例えば、ｓｅｃｐ２５６ｋ１のパラメーター（ｐ，ａ，ｂ，Ｇ，ｎ，ｈ）を定める。
・ユーザは、順序付きセット｛Ｕ０，Ｕ１，…，Ｕｎ−２，Ｕｎ−１｝を実現するためにランダム化される。
・これらのユーザのうちの１人が「開始者」と見なされる。この目的のために、Ｕ０が開始者と見なされる。
・開始者Ｕ０は乱数ｋｓを選択し、ｋｓＧを計算する。ここで、Ｇは楕円曲線上の基点を表す。
・ｋｓの値はＵ０によってプライベートに保持される。
・他の各ユーザＵ１〜Ｕｎ−１が、乱数を選択する。Ｕ１がｋ１を選択し、Ｕ２がｋ２を選択し、・・・、Ｕｎ−１がｋｎ−１を選択する。これらの他の各ユーザは、自分が選択した値をＵ０に安全に送信する。Ｕ０は、第２の乱数ｋ０も選択する。
・支払チャネルＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎを構築し、必要なシークレット値を取得し、Ｕ（ｉ＋１）  ｍｏｄ  ｎに支払いを行う実行トランザクションＴｐａｙをビットコイン・ネットワークに送信するために各Ｕｉに与えられる時間量を表す時間値ｓが選択される。  時間ｓは、秒又はブロック数で表される。
・別の値Ｓが、ビットコイン・ネットワークに送信される、ユーザに対する最初の支払いの開始時間として選択される。ＳはＵｎｉｘ時間又はブロックの高さで指定された時点を表し、ｓは時間範囲を表すことに留意されたい。
【００９９】
全ての一対のユーザの間に一方向の支払チャネルが確立され、支払いの方向は、ＵｉがＵ（ｉ＋１）  ｍｏｄ  ｎに支払いを行うような方向である。例として、ｎ＝７と仮定すると、ＧＲＥの支払チャネルは、Ｕ０→Ｕ１，Ｕ１→Ｕ２，…，Ｕ６→Ｕ０で構成される。
【０１００】
支払チャネルＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎの作成プロセスを以下で説明し、図１３及び図１４に示す。
・初期コミットメント・トランザクションＴＣにより、＜scriptPubkey＞により、「ＵｉとＵ（ｉ＋１）  ｍｏｄ  ｎとの両方の署名」又は「ｓｖ（ｉ＋１）  ｍｏｄ  ｎ及びＵ（ｉ＋１）  ｍｏｄ  ｎの署名」のいずれかによってのみ使うことができるｘＢＴＣが利用可能になる。
・この目的のために、１つの返金トランザクションのみが必要である。この返金トランザクションＴｒ，０は、全てのｘＢＴＣをＵｉに返す。
・支払チャネルの返金トランザクションＴｒ，０には、ｎＬｏｃｋＴｉｍｅ値Ｓ＋（ｎ−ｉ）ｓが含まれる。
・返金トランザクションＴｒ，０は、初期コミットメント・トランザクションＴＣがビットコイン・ネットワークに送信される前に、Ｕ（ｉ＋１）  ｍｏｄ  ｎが署名する必要がある。
・支払チャネルには、ＴＣのコミット済みｘＢＴＣからＵ（ｉ＋１）  ｍｏｄ  ｎにｘＢＴＣを支払う支払トランザクションＴｐａｙが含まれる。
・Ｕ（ｉ＋１）  ｍｏｄ  ｎへの支払トランザクションＴｐａｙの＜scriptSig＞には、値ｓｖ（ｉ＋１）  ｍｏｄ  ｎが含まれることが予想される。
【０１０１】
支払チャネルＵｉ−１→Ｕｉが支払チャネルＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎの前に設定されるため、一対のユーザの間の支払チャネルを規則正しい順序で作成することが重要である。これは、第１の支払チャネルＵ０→Ｕ１の作成から始まり、Ｕ０が開始者であり、最後の支払チャネルＵｎ−１→Ｕ０で終了する。
【０１０２】
一部の構成では、ユーザＵｉが、支払いを行い、この支払いに関連するリスクを負う前に、ＵｉがＴｐａｙ支払いをＵ（ｉ＋１）  ｍｏｄ  ｎに行った場合に、Ｕｉに対してＵｉが首尾よく実行できるＴｐａｙトランザクションが存在することを確認できるようにするので、シーケンスの順序が重要である。
【０１０３】
図１５及び図１６を参照して、この構成で使用されるシークレット値の準備について説明する。
１.  ｓｖ０のデフォルト値がｓｖ０＝ｋｓとして設定される。ｋｓは、ユーザのＧＲＥプロトコルリスト内の開始者Ｕ０によって選択されたランダム値であることを思い出されたい。このｋｓ値はプロトコルのセキュリティの中心であり、Ｕ０のみが知っており、全ての支払チャネルが作成されてＵ０の履行が完了するまで秘密にされる。
２.  Ｕ０は、楕円曲線の基点Ｇをデフォルトのｓｖ値ｋｓに乗算することにより、そのデフォルトのｓｖ値ｋｓを暗号化する。Ｑｉがｓｖｉ値の暗号化されたバージョンである場合に、デフォルトのｓｖの暗号化されたバージョンはＱ０＝ｓｖ０Ｇ＝ｋｓＧである。
３.  作成された第１の支払チャネルＵ０→Ｕ１では、Ｕ１はその乱数ｋ１をＵ０に伝え、Ｕ０は「暗号化されたバージョンのシークレット鍵」Ｑ０をＵ１に伝える。
４.  作成された支払チャネルＵ０→Ｕ１のｓｖ値は、ｓｖ１＝ｓｖ０＋ｋ１であり、その暗号文は次のとおりである。
Ｑ１＝Ｑ０＋ｋ１Ｇ
ｏ新しいシークレット値（ｋｓ＋ｋ１）は、Ｑ１の計算に存在し、Ｑ１＝ｋｓＧ＋ｋ１Ｇ＝（ｋｓ＋ｋ１）Ｇを与えること、
ｏユーザＵ１はｋｓを知らず、タンデムで（in  tandem）トランザクションのシークレット値を有すること、及び
ｏＵ１とＵ０との両方が、Ｑ１の他方の計算を計算及び検証することができることに留意されたい。
５.  ステップ３及び４は、ＧＲＥＣＳ回路の他の全ての支払チャネルに一般化することができる。この一般化について以下に説明する。
・Ｕ（ｉ＋１）  ｍｏｄ  ｎは、乱数ｋ（ｉ＋１）  ｍｏｄ  ｎをＵｉに伝える。Ｕｉは、暗号化されたバージョンのシークレット鍵ＱｉをＵ（ｉ＋１）  ｍｏｄ  ｎに伝える。
・作成された支払チャネルのｓｖ値は、ｓｖ（ｉ＋１）  ｍｏｄ  ｎ＝ｓｖｉ＋ｋ（ｉ＋１）  ｍｏｄ  ｎになる。その暗号化された値は次のとおりである。
Ｑ（ｉ＋１）  ｍｏｄ  ｎ＝Ｑｉ＋ｋ（ｉ＋１）  ｍｏｄ  ｎＧ
・支払チャネルについて、
ｏ新しいシークレット値ｓｖ（ｉ＋１）  ｍｏｄ  ｎ＝ｋｓ＋ｋ１＋ｋ２＋…＋ｋｉ＋  ｋ（ｉ＋１）  ｍｏｄ  ｎは、以下で与えられるＱ（ｉ＋１）  ｍｏｄ  ｎの計算で確認することができること、
【数４】
2020517011.tif 000006
ｏユーザＵ（ｉ＋１）  ｍｏｄ  ｎは、ｋｓ及びｓｖの以前の他の全ての反復が暗号化されているため、トランザクションのシークレット値を知らないこと、及び
ｏＵ（ｉ＋１）  ｍｏｄ  ｎとＵｉとの両方が、Ｑ（ｉ＋１）  ｍｏｄ  ｎの他方の計算を計算及び検証することができることに留意されたい。
・以前のプロセスは、最終的な支払チャネルＵｎ−１→Ｕ０にも適用されることに留意されたい。こうして、秘密の乱数ｋｓに加えて、Ｕ０は第２の乱数値ｋ０も作成する必要がある。ｋ０は、シークレット値に追加される最終的な値である。最終的なシークレット値には、ｓｖ０ではなくｓｖｆｉｎａｌというラベルが付けられていることに留意されたい。
６.  開始者Ｕ０のみが、自分に支払いを行う支払チャネルを、自分が支払いを行う支払チャネルの前に確立することを優先する必要はない。これは、Ｕ０が、全ての支払チャネルの全てのＴｐａｙトランザクションで必要とされるｋｓの値を知っている唯一の人物であるため、Ｕ０をだますことができないためである。従って、Ｕ０がプロセスを快適に開始するまで（最終的なシークレット値のリリースと一致するまで）、この構成のＧＲＥプロトコルのユーザは引出しを行うことができない。
ｓｖｆｉｎａｌ＝ｋｓ＋ｋ１＋ｋ２＋…＋ｋｎ−１＋ｋ０（ｋｓの値を含む）。
【０１０４】
最終的な支払チャネルＵｎ−１→Ｕ０は、時刻Ｓに又はその前に確定する。ユーザを接続する支払チャネルのセットは、図１６に示されるように円として視覚化できる。図１６は、この構成のプロトコルの全てのユーザの間に存在すＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎ支払チャネルの表現を示す。矢印は、支払チャネルとＴｐａｙ支払いの方向とを示す。矢印の外部に隣接する値は、ブロックチェーンによって受け入れられるトランザクションＴｐａｙ：Ｕｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎに必要なシークレット値を表す。矢印の内部に隣接する値は、ｓの期間値を表す。Ｑｉ値は、支払チャネルのシークレット値の暗号化された値を表す。
【０１０５】
円形の配置に照らして、｛Ｕｉ｜ｉ∈［０，ｎ−１］｝の順序がランダムであるという事実は、ユーザＵｉに支払いを行うユーザがランダムであり、Ｕｉが支払いを行うユーザがランダムであることを意味する。同様に、ユーザＵｉに支払いを行うユーザは、Ｕｉが支払いを行うユーザとは異なる。
【０１０６】
開始者Ｕ０は、既存の支払チャネルＵｎ−１→Ｕ０のトランザクションＴｐａｙを使って、ｓｖｆｉｎａｌ＝ｋｓ＋ｋ１＋ｋ２＋…＋ｋｎ−１＋ｋ０の値を明らかにする。上述したように、値ｋｓ及びｋ０を作成したのはＵ０であり、全てのユーザはｋｉ値をＵ０に送信する必要があった。
【０１０７】
Ｕ０はｓｖｆｉｎａｌのこの値をＵｎ−１に直接伝えることができる、又は、この値をブロックチェーンから取得することができる。
【０１０８】
Ｕｎ−１はここでｓｖｆｉｎａｌを知っているが、これは、Ｕｎ−１が支払チャネルＵｎ−２→Ｕｎ−１を介して支払いを受け取るために必要なシークレット値ではない。
ｓｖｆｉｎａｌ＝ｋｓ＋ｋ１＋ｋ２＋…＋ｋｎ−１＋ｋ０、であるが、
ｓｖｎ−１＝ｋｓ  ＋ｋ１  ＋ｋ２  ＋…＋ｋｎ−１である。
【０１０９】
しかしながら、Ｕｎ−１はｓｖｆｉｎａｌからｋ０を引くことでｓｖｎ−１を容易に計算し、支払いのためにＴｐａｙトランザクションを送信することができる。Ｕｎ−１は、支払チャネルトランザクションの構築における以前のプロセスからｋ０を知っているだろう。
【０１１０】
同様に、各ユーザＵ（ｉ＋１）  ｍｏｄ  ｎは、値ｓｖ（ｉ＋１）  ｍｏｄ  ｎをその支払人Ｕｉに直接伝えることができる。Ｕ（ｉ＋１）  ｍｏｄ  ｎが取得できなない場合に、ユーザＵｉは、（少なくとも時間ｓ内に）ブロックチェーン台帳で値ｓｖ（ｉ＋１）  ｍｏｄ  ｎを取得することができる。
【０１１１】
ｓｖ（ｉ＋１）  ｍｏｄ  ｎから、ユーザＵｉは、ｓｖ（ｉ＋１）  ｍｏｄ  ｎからｋ（ｉ＋１）  ｍｏｄ  ｎを引くことによりｓｖｉを計算することができる。これにより、Ｔｐａｙ：Ｕｉ−１→Ｕｉを介してＵｉが支払いを受け取ることができる。
【０１１２】
ブロックチェーンがトランザクションを確認するのに平均１０分かかるため、ｓの値は、そのｓの値が表す期間が、ユーザＵｉが必要に応じてその期間内に、トランザクションがビットコイン・ネットワークに送信された後のトランザクションＴｐａｙ：Ｕｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎにおいてｓｖ（ｉ＋１）の値を見つけるのに十分であるように選択する必要がある。トランザクションを確認するための平均時間が変化する場合に、それに応じてｓを選択することができる。
【０１１３】
ｓの値には、一対のユーザの間の支払チャネルの構築にかかる推定時間も含める必要がある。従って、ｓはｓ＝ｓｓｖ＋εになり、ここで、ｓｓｖはｓｖ（ｉ＋１）  ｍｏｄ  ｎを見つけてＴｐａｙ：Ｕｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎを送信するための推定時間であり、εは支払チャネルを構築するための推定時間である。
【０１１４】
開始者Ｕ０が、Ｕｎ−１とＵ０との間の既存の支払チャネルのＴｐａｙトランザクションをネットワークに送信したため、ｓｖｆｉｎａｌの値をＵｎ−１に公開すると、次に、ｓｖｉの値を反時計回りの方法（Ｕｎ−１からＵ１へ）で他の全てのユーザＵｉに公開することができる（図１７を参照）。これは、各ユーザＵｉが、支払いを受け取ることができるトランザクション（Ｕｉ−１からＵｉへの支払チャネルのＴｐａｙ）を送信する際に権限が与えられるという前提に基づいている。
【０１１５】
上記トランザクションを送信するユーザＵｉは、ＵｉからＵ（ｉ＋１）  ｍｏｄ  ｎへの支払チャネルのＴｐａｙからｓｖ（ｉ＋１）  ｍｏｄ  ｎの値を取得する必要があり、その値からＵｉがｓｖｉを導出する。ＵｉがＵｉ−１からＵｉへの支払チャネルのそのトランザクションＴｐａｙを送信することにより、次に、ｓｖｉの値がユーザＵｉ−１に利用可能にされ、ユーザＵｉ−１はｓｖｉ−１を導出する。このプロセスは、ドミノがＵｎ−１からＵ１まで全て落ちるようにカスケードし、換金する各ユーザＵｉがｓｖｉ−１をユーザＵｉ−１に明らかにし、ユーザＵｉ−１も換金することができるようにする。
【０１１６】
より形式的には、支払チャネルの（実行／送信される）Ｔｐａｙトランザクションのシーケンスは次のようになる。
［Ｔｐａｙ：Ｕｎ−１→Ｕ０］，［Ｔｐａｙ：Ｕｎ−２→Ｕｎ−１］，…，［Ｔｐａｙ：Ｕ１→Ｕ２］，［Ｔｐａｙ：Ｕ０→Ｕ１］
【０１１７】
Ｔｐａｙトランザクションのセットが完了すると、プロセスは首尾よく終了する。各ユーザはｘＢＴＣを支払い、各ユーザはｘＢＴＣを受け取る。
【０１１８】
この構成でのＴｐａｙ：Ｕｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎトランザクションを送信するプロセスについて図１８に示す。ここで、ｔは現在の時間であり、ＰＣは支払チャネルであり、Ｕｉ＋１＝Ｕ（ｉ＋１）  ｍｏｄ  ｎであり、ｂｃはブロックチェーンである。支払チャネルＵｎ−１→Ｕ０の場合に、ｓｖ値の名前はｓｖｆｉｎａｌである。
【０１１９】
全ての返金トランザクションＴｒ，０のブロックチェーンへの送信は、ｎＬｏｃｋＴｉｍｅ値によって制限される。ｎＬｏｃｋＴｉｍｅパラメーターのこの値は、Ｔｒ，０がその時間に又はそれ以降にブロックチェーンによってのみ受け入れられるような絶対時間値を表す。Ｕｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎのｎＬｏｃｋＴｉｍｅ値はＳ＋（ｎ−ｉ）ｓである。
【０１２０】
ユーザＵｉは、Ｕ（ｉ＋１）  ｍｏｄ  ｎが、署名し損ない、ｎＬｏｃｋＴｉｍｅ値の前にＱ（ｉ＋１）  ｍｏｄ  ｎのｓｖ（ｉ＋１）  ｍｏｄ  ｎを明らかにできない場合に、Ｔｒ，０：Ｕｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎを送信する。
【０１２１】
ＵｉがＴｒ，０：Ｕｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎを送信する場合に、これは、支払トランザクションＴｐａｙ：Ｕｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎが実行されておらず、これからも決して実行されないことを意味する。これは、ｓｖ（ｉ＋１）  ｍｏｄ  ｎが公開されないため、Ｕｉ−１がブロックチェーンから支払トランザクションＴｐａｙ：Ｕｉ−１→Ｕｉに必要なｓｖｉを計算することができないことを意味する。
【０１２２】
Ｕｉ−１は、自分の返金トランザクションＴｒ，０：Ｕｉ−１→Ｕｉを送信する前に、Ｕｉ−１→ＵｉのｎＬｏｃｋＴｉｍｅ値まで又はそれ以降まで待機する必要がある。
【０１２３】
これらの返金送信プロセスは、Ｔｒ，０：Ｕ０→Ｕ１を送信する開始者Ｕ０までの全てのユーザに対して、反時計回りに繰り返される。これらの各トランザクションは、特定の時点に又はそれ以降でのみ発生し得る。この返金トランザクションのシーケンスの例を図１９に示す。ここで、Ｕ４は署名に失敗し且つｔ＝Ｓ＋４ｓの前にＴｐａｙ：Ｕ３→Ｕ４のｓｖ４の生成に失敗する。返金トランザクションは、反時計回りを指す矢印で表される。支払又は実行トランザクションは、時計回りを指す矢印で表される。
【０１２４】
返金トランザクションを正確なｎＬｏｃｋＴｉｍｅ値で送信する必要がないことに留意することが重要である。返金トランザクションはその時点又はその後に適用することができる。これは、ＵｉがＵ（ｉ＋１）  ｍｏｄ  ｎに延長時間ｔｘを与えて、署名し、Ｔｐａｙ：Ｕｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎのｓｖ（ｉ＋１）  ｍｏｄ  ｎを生成することができることを意味する一方で、これは、その結果、Ｕｉが、Ｔｐａｙ：Ｕｉ−１→Ｕｉのｓｖｉを生成するための時間が短くなる（ＵｉがＵｉ−１によって延長時間を与えられていない場合）ことを意味する。図２０を参照されたい。ここでＵ０に延長時間ｔｘが与えられると、Ｕｎ−１がｓｖｎ−１を計算して、Ｔｐａｙ：Ｕｎ−１→Ｕ０のＵ０による遅くなった送信によってＴｐａｙ：Ｕｎ−２→Ｕｎ−１をブロックチェーンに送信する時間が短くなる。
【０１２５】
以下では、この構成のプロトコルの一対のユーザの間の支払チャネルＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎで利用されるビットコイン・トランザクションの構築について説明する。これらの支払チャネルは、３つの主要なトランザクションで構成される。
・２−ｏｆ−２マルチシグネチャ・トランザクションＴＣへの入金：このトランザクションは、支払チャネルのコミットメント・コンポーネントを表し、コミットメント・トランザクションと呼ばれる場合がある。ここで、トランザクションを通じて、ユーザＵｉは指定された数のビットコインｘＢＴＣを送信／コミットして、次のいずれかで管理する。
ｏ２−ｏｆ−２マルチシグネチャ（Ｕｉ，Ｕ（ｉ＋１）  ｍｏｄ  ｎ）、又は
ｏ値ｓｖ（ｉ＋１）  ｍｏｄ  ｎの知識及びＵ（ｉ＋１）  ｍｏｄ  ｎの署名。
・返金トランザクションＴｒ，０：このトランザクションは、指定された時間が経過した後に（コミットメント・トランザクションから）ユーザＵｉに返されるｘＢＴＣの返金を表し、ユーザＵｉはブロックチェーンへの送信の適格主体となる。このトランザクションを首尾よく実行するには、ユーザＵｉ及びＵ（ｉ＋１）  ｍｏｄ  ｎの署名が必要である。
・支払トランザクションＴｐａｙ：このトランザクションは、Ｕｉのコミット済み資金からユーザＵ（ｉ＋１）  ｍｏｄ  ｎへのｘＢＴＣの支払いである。このトランザクションを首尾よく実行するには、シークレット値ｓｖ（ｉ＋１）  ｍｏｄ  ｎの知識及びユーザＵ（ｉ＋１）  ｍｏｄ  ｎの署名が必要である。支払トランザクションは、実行トランザクションとも呼ばれる場合がある。
【０１２６】
図２１〜図２４のトランザクションの詳細は、＜scriptSig＞、＜scriptPubkey＞、ｎＬｏｃｋＴｉｍｅ、及び様々なトランザクションの出力値に限定されるが、これらはこの構成に最も関連するトランザクション要素であることに留意されたい。
【０１２７】
トランザクションの詳細を図２１〜２４に示す。以下に、楕円曲線オペコードの詳細を説明する。
【０１２８】
この構成では、楕円曲線暗号化を使用する。シークレット値ｋが与えられると、そのＥＣ暗号化された値はＱ＝ｋＧであり、ここで、Ｇは楕円曲線上の基点である。
【０１２９】
このＥＣ暗号化は、全ての支払チャネルで同じシークレット値を使用する構成のＧＲＥのハッシュ関数に相当する暗号化として機能する。ただし、ＥＣ加算の準同型の特性により、この構成の支払チャネルでｓｖ値の変更が可能になる一方、ｓｖの最終バージョンｓｖｆｉｎａｌの公開から始まるシークレット値のドミノカスケードが可能になる。
【０１３０】
各支払チャネルＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎについて、コミットメント・トランザクションＴＣには、返金とは別に、暗号化された値Ｑ（ｉ＋１）  ｍｏｄ  ｎを生成するシークレット値ｓｖ（ｉ＋１）  ｍｏｄ  ｎが提示された場合にのみ、コミット済み資金を使うことができることを規定する条件が含まれる。このコミット済み資金の非返金支出（non-refund  spending）は、支払チャネルのＴｐａｙによって行われる。
Ｑ（ｉ＋１）  ｍｏｄ  ｎ＝ｓｖ（ｉ＋１）  ｍｏｄ  ｎＧ
ここで、ｓｖ（ｉ＋１）  ｍｏｄ  ｎ＝ｋｓ＋ｋ１＋ｋ２  ＋・・・＋ｋｉ＋ｋ（ｉ＋１）  ｍｏｄ  ｎである。
【０１３１】
ｓｖ（ｉ＋１）  ｍｏｄ  ｎが正しいかどうかを判断するために、次のＥＣオペコードが使用され、乗算Ｑ＝ｋＧが提供される。このオペコードはＯＰ＿ＥＣＰＭＵＬＴと呼ばれる。ＯＰ＿ＥＣＰＭＵＬＴは、エンコードされた楕円曲線ポイント及び数値を受け取り、スカラーによる楕円曲線乗算を行う。ＯＰ＿ＥＣＰＭＵＬＴは、エンコードされた楕円曲線ポイントとして結果を出力する。
【０１３２】
支払チャネルＵｉ→Ｕ（ｉ＋１）  ｍｏｄ  ｎのトランザクションＴＣ、Ｔｒ，０、及びＴｐａｙのスクリプトを図２１〜図２４に示す。特に、図２４は、コミットメント・トランザクションＴＣの＜scriptPubKey＞が、上記のオペコードＯＰ＿ＥＣＰＭＵＬＴを使用して、支払トランザクションＴｐａｙの＜scriptSig＞とどの様に結合され、コミット済みｘＢＴＣのロックを解除するかを示している。
【０１３３】
本発明の構成は、全ての支払チャネルに同じシークレット値又は全ての支払チャネルに異なるシークレット値のいずれかを使用するものとして上述したが、この記述より、シークレット値を変更すること及びシークレット値を変更しないことの組合せを使用するように構成を組み合わせるのは当業者の権限の範囲内である。
【０１３４】
さらに、電子メール、ファイル転送プロトコル、ピアツーピア共有等の他の通信チャネルを使用して、本発明の任意の構成のユーザが情報を通信することができ、この情報が、シークレット値又はそれに関連する情報、１つ又は複数のトランザクションの詳細、１つ又は複数のトランザクション自体の完全又は不完全なバージョンに関連することができ、且つブロックチェーン以外の通信チャネルが使用される範囲が、本発明の所与の一対のユーザの間に存在する信頼性のレベルに依存し得ることを理解されたい。
【０１３５】
上記の本発明の構成は、ユーザ同士の間のビットコインの転送のみに言及しているが、ユーザは、代わりに、情報、契約、トークン等のプロトコルを使用して他のリソースを交換できることを理解されたい。トークンは、トークンの制御が資産又はリソースの制御を与えるように、トークンに関連付けられたスマートコントラクトに従って資産又はリソースを表す。スマートコントラクト自体は、ブロックチェーン外に格納することも、１つ以上のトランザクション内に格納することもできる。
【０１３６】
本明細書において、用語「システム」は、上述したＧＲＥプロトコル、プロトコル自体、及びコンピュータハードウェアに保存されたプロトコルのうちの少なくとも１つの構成のステップを実行するように構成されたコンピュータハードウェア及び／又はソフトウェアのシステムを包含するために使用される。
【０１３７】
上述した実施形態は、本発明を限定するのではなく例示するものであり、当業者は、添付の特許請求の範囲によって規定される本発明の範囲から逸脱することなく多くの代替実施形態を設計できることに留意されたい。特許請求の範囲において、括弧内に置かれた参照符号は、特許請求の範囲を限定するものとして解釈すべきではない。「備える、有する、含む（comprising,  comprises）」等の語は、請求項又は明細書全体に列挙されているもの以外の要素又はステップの存在を排除するものではない。本明細書において、「備える、有する、含む（comprises,  comprising）」は「含む、有する（includes,  including）」又は「から構成される（consists  of,  consisting  of）」を意味する。要素の単数形の参照は、そのような要素の複数形の参照を除外するものではなく、その逆も同様である。本発明は、いくつかの別個の要素を含むハードウェアによって、及び適切にプログラムされたコンピュータによって実装され得る。いくつかの手段を列挙する装置クレームでは、これらの手段のいくつかは、ハードウェアの同一のアイテムによって具現化され得る。特定の手段が互いに異なる従属請求項に記載されているという単なる事実は、これらの手段の組み合わせが有利に使用できないことを示すものではない。
【図１】
2020517011.tif 000007
【図２】
2020517011.tif 000008
【図３】
2020517011.tif 000009
【図４】
2020517011.tif 000010
【図５】
2020517011.tif 000011
【図６】
2020517011.tif 000012
【図７】
2020517011.tif 000013
【図８】
2020517011.tif 000014
【図９】
2020517011.tif 000015
【図１０】
2020517011.tif 000016
【図１１】
2020517011.tif 000017
【図１２】
2020517011.tif 000018
【図１３】
2020517011.tif 000019
【図１４】
2020517011.tif 000020
【図１５】
2020517011.tif 000021
【図１６】
2020517011.tif 000022
【図１７】
2020517011.tif 000023
【図１８】
2020517011.tif 000024
【図１９】
2020517011.tif 000025
【図２０】
2020517011.tif 000026
【図２１】
2020517011.tif 000027
【図２２】
2020517011.tif 000028
【図２３】
2020517011.tif 000029
【図２４】
2020517011.tif 000030
【国際調査報告】
2020517011.tif 000031
2020517011.tif 000032