特開2024-20571ブロックチェーン上でトランザクション・ミキシングを行うためのコンピュータで実施されるシステム及び方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024020571
(43)【公開日】2024-02-14
(54)【発明の名称】ブロックチェーン上でトランザクション・ミキシングを行うためのコンピュータで実施されるシステム及び方法
(51)【国際特許分類】
H04L 9/32 20060101AFI20240206BHJP
G06Q 20/38 20120101ALI20240206BHJP
【ＦＩ】
H04L9/32 200Z
G06Q20/38 310
【審査請求】有
【請求項の数】16
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2023201169
(22)【出願日】2023-11-29
(62)【分割の表示】P 2022185464の分割
【原出願日】2018-04-11
(31)【優先権主張番号】1706071.6
(32)【優先日】2017-04-18
(33)【優先権主張国・地域又は機関】GB
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＵＮＩＸ
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ジョーゼフ，ダニエル
(57)【要約】 （修正有）
【課題】ブロックチェーン上の複数のユーザの間でトランザクション・ミキシングを行うシステム及び方法を提供する。
【解決手段】方法は、リソースの制御を第１のユーザの送信元アドレスから第２のユーザの受信アドレスに送信するステップ、リソースの制御を第２のユーザの送信元アドレスから別のユーザの受信アドレスに送信するステップ、リソースの制御を別のユーザの送信元アドレスから、第１のユーザの受信アドレス又はさらに別のユーザの受信アドレスのいずれかに送信することを、トランザクション・チェーンを完了するために、所定のオプションが実行されるまで繰り返すステップと、トランザクション・チェーンを実行するステップと、を実施する。ユーザのうちの少なくとも１人が複数のユーザからランダムに選択される。
【選択図】なし
【解決手段】方法は、リソースの制御を第１のユーザの送信元アドレスから第２のユーザの受信アドレスに送信するステップ、リソースの制御を第２のユーザの送信元アドレスから別のユーザの受信アドレスに送信するステップ、リソースの制御を別のユーザの送信元アドレスから、第１のユーザの受信アドレス又はさらに別のユーザの受信アドレスのいずれかに送信することを、トランザクション・チェーンを完了するために、所定のオプションが実行されるまで繰り返すステップと、トランザクション・チェーンを実行するステップと、を実施する。ユーザのうちの少なくとも１人が複数のユーザからランダムに選択される。
【選択図】なし
【特許請求の範囲】
【請求項1】
ブロックチェーンでの複数のユーザの間でトランザクション・ミキシングを行うためのコンピュータで実施される方法であって、当該方法は、
（ｉ）開始者（Ｕ０）が乱数ｋｓ、ｋ０を選択し、デフォルトのシークレット値がｓｖ０＝ｋｓであり、残りの複数のユーザがそれぞれの乱数ｋｉを選択し、前記開始者のシークレット値の暗号化されたバージョンＱ０＝ｓｖ０Ｇ＝ｋｓＧを生成すること、
（ｉｉ）開始者の送信元アドレスから第２のユーザＵ１の受信アドレスにリソースの制御を送信するように構成された第１の支払いチャネルを準備し、第１のユーザは支払いを行うユーザであり、前記第２のユーザは前記第１の支払いチャネルの支払いを受け取るユーザであること、
（ｉｉｉ）前記第２のユーザの送信元アドレスから更なるユーザＵ２の受信アドレスにリソースの制御を送信するように構成された第２の支払いチャネルを準備し、前記第２の支払いチャネルは前記第１の支払いチャネルの後に準備され、前記第２のユーザは支払いを行うユーザであり、前記更なるユーザは前記第２の支払いチャネルの支払いを受け取るユーザであること、
（ｉｖ）更なるユーザの送信元アドレスから（ａ）前記開始者の受信アドレス又は（ｂ）更に別のユーザの受信アドレスのいずれかにリソースの制御を送信するように構成された更なる支払いチャネルを準備し、オプション（ａ）を実行してトランザクション・チェーンが完了するまでステップ（ｉｉｉ）を繰り返し、前記更なる支払いチャネルは、前記第２の支払いチャネルの後に準備され、前記更なるユーザは支払いを行うユーザであり、前記第１のユーザ又は前記更に別のユーザは前記更なる支払いチャネルの支払いを受け取るユーザであること、
（ｖ）前記トランザクション・チェーンが準備された順序とは逆の順序で前記トランザクション・チェーンを実行し、それぞれの支払いチャネルの前記シークレット値は、前記それぞれの支払いチャネルの前記支払いトランザクションが前記逆の順序で前記ブロックチェーンに送信されるように、前記逆の順序で前記ユーザに明らかにされること、を実行することを含み、
第２のユーザ、更なるユーザ、更に別のユーザは、前記複数のユーザの中からランダムに選択される、
方法。
（ｉ）開始者（Ｕ０）が乱数ｋｓ、ｋ０を選択し、デフォルトのシークレット値がｓｖ０＝ｋｓであり、残りの複数のユーザがそれぞれの乱数ｋｉを選択し、前記開始者のシークレット値の暗号化されたバージョンＱ０＝ｓｖ０Ｇ＝ｋｓＧを生成すること、
（ｉｉ）開始者の送信元アドレスから第２のユーザＵ１の受信アドレスにリソースの制御を送信するように構成された第１の支払いチャネルを準備し、第１のユーザは支払いを行うユーザであり、前記第２のユーザは前記第１の支払いチャネルの支払いを受け取るユーザであること、
（ｉｉｉ）前記第２のユーザの送信元アドレスから更なるユーザＵ２の受信アドレスにリソースの制御を送信するように構成された第２の支払いチャネルを準備し、前記第２の支払いチャネルは前記第１の支払いチャネルの後に準備され、前記第２のユーザは支払いを行うユーザであり、前記更なるユーザは前記第２の支払いチャネルの支払いを受け取るユーザであること、
（ｉｖ）更なるユーザの送信元アドレスから（ａ）前記開始者の受信アドレス又は（ｂ）更に別のユーザの受信アドレスのいずれかにリソースの制御を送信するように構成された更なる支払いチャネルを準備し、オプション（ａ）を実行してトランザクション・チェーンが完了するまでステップ（ｉｉｉ）を繰り返し、前記更なる支払いチャネルは、前記第２の支払いチャネルの後に準備され、前記更なるユーザは支払いを行うユーザであり、前記第１のユーザ又は前記更に別のユーザは前記更なる支払いチャネルの支払いを受け取るユーザであること、
（ｖ）前記トランザクション・チェーンが準備された順序とは逆の順序で前記トランザクション・チェーンを実行し、それぞれの支払いチャネルの前記シークレット値は、前記それぞれの支払いチャネルの前記支払いトランザクションが前記逆の順序で前記ブロックチェーンに送信されるように、前記逆の順序で前記ユーザに明らかにされること、を実行することを含み、
第２のユーザ、更なるユーザ、更に別のユーザは、前記複数のユーザの中からランダムに選択される、
方法。
【請求項2】
前記シークレット値（ｓｖｉ）を準備することは、
前記複数のユーザの順序をランダム化し、開始者（Ｕ０）を選択し、
前記残りの複数のユーザは、ｋｉの値を前記開始者に送信することを選択し、
前記開始者が、前記デフォルトのシークレット値ｓｖ０＝ｋｓを暗号化し、これに楕円曲線の基点Ｇを乗算して、前記シークレット値の暗号化されたバージョンＱ０＝ｓｖ０Ｇ＝ｋｓＧを生成することをさらに含む、請求項１に記載の方法。
前記複数のユーザの順序をランダム化し、開始者（Ｕ０）を選択し、
前記残りの複数のユーザは、ｋｉの値を前記開始者に送信することを選択し、
前記開始者が、前記デフォルトのシークレット値ｓｖ０＝ｋｓを暗号化し、これに楕円曲線の基点Ｇを乗算して、前記シークレット値の暗号化されたバージョンＱ０＝ｓｖ０Ｇ＝ｋｓＧを生成することをさらに含む、請求項１に記載の方法。
【請求項3】
シークレット鍵sｖ（ｉ＋１） ｍｏｄ ｎ及びそれぞれの暗号化された値Ｑ（ｉ＋１）ｍｏｄ ｎが、前記それぞれの支払いチャネルの前記支払いを受け取るユーザと前記支払いを行うユーザとの間の前記それぞれの支払いチャネルを形成するために決定される、請求項１又は請求項２に記載の方法。
【請求項4】
前記それぞれの支払いチャネルに対する前記シークレット鍵sｖ（ｉ＋１） ｍｏｄ ｎを準備することは、
前記それぞれの支払いチャネルの前記支払いを受け取るユーザ（Ｕ（ｉ＋１） ｍｏｄ ｎ）が、その乱数ｋ（ｉ＋１） ｍｏｄ ｎを前記支払いを行うユーザ（Ｕｉ）に伝え、
前記支払いを行うユーザが、Ｑｉ＝（ｋｓ＋ｋ１＋ｋ２＋・・・＋ｋｉ）Ｇを前記支払いを受け取るユーザに伝え、
前記シークレット鍵sｖ（ｉ＋１） ｍｏｄ ｎ＝ｓｖｉ＋ｋ（ｉ＋１） ｍｏｄ ｎとその暗号化された値Ｑ（ｉ＋１）ｍｏｄ ｎ＝Ｑｉ＋ｋ（ｉ＋１） ｍｏｄ ｎＧとを作成し、及び
Ｑ（ｉ＋１）ｍｏｄ ｎを使用して、前記支払いを行うユーザと前記支払いを受け取るユーザとの間に前記支払いチャネルを作成することによって形成される、請求項３に記載の方法。
前記それぞれの支払いチャネルの前記支払いを受け取るユーザ（Ｕ（ｉ＋１） ｍｏｄ ｎ）が、その乱数ｋ（ｉ＋１） ｍｏｄ ｎを前記支払いを行うユーザ（Ｕｉ）に伝え、
前記支払いを行うユーザが、Ｑｉ＝（ｋｓ＋ｋ１＋ｋ２＋・・・＋ｋｉ）Ｇを前記支払いを受け取るユーザに伝え、
前記シークレット鍵sｖ（ｉ＋１） ｍｏｄ ｎ＝ｓｖｉ＋ｋ（ｉ＋１） ｍｏｄ ｎとその暗号化された値Ｑ（ｉ＋１）ｍｏｄ ｎ＝Ｑｉ＋ｋ（ｉ＋１） ｍｏｄ ｎＧとを作成し、及び
Ｑ（ｉ＋１）ｍｏｄ ｎを使用して、前記支払いを行うユーザと前記支払いを受け取るユーザとの間に前記支払いチャネルを作成することによって形成される、請求項３に記載の方法。
【請求項5】
前記支払いトランザクションを前記ブロックチェーンに送信することができるように、前記支払いを行うユーザは、sｖ（ｉ＋１） ｍｏｄ ｎからｋ（ｉ＋１） ｍｏｄ ｎを減算することによって、前記シークレット値sｖ（ｉ＋１） ｍｏｄ ｎを計算する、請求項４に記載の方法。
【請求項6】
前記第１、第２、及び更なる支払いチャネルはそれぞれ、コミットメント・トランザクション、返金トランザクション、及び支払いトランザクションを含む、請求項１乃至５のいずれか一項に記載の方法。
【請求項7】
前記第１、第２、及び更なる支払いチャネルを準備することは、
前記支払いを行うユーザ（Ｕｉ）が、前記それぞれの支払いチャネルの前記支払いを行うユーザと前記支払いを受け取るユーザ（Ｕｉ＋１）との間の前記コミットメント・トランザクションを作成し、
前記支払いを行うユーザが、それぞれの前記支払いチャネルの前記支払いを行うユーザと前記支払いを受け取るユーザとの間の前記返金トランザクションを作成し、該返金トランザクションは、指定された時間に又はその後に、それぞれの前記支払いチャネルの前記支払いを行うユーザに返金するように準備され、
前記それぞれの支払いチャネルの前記支払いを行うユーザが、前記返金トランザクションに署名し、及び
前記支払いを行うユーザが前記返金トランザクションに署名することを条件として、前記それぞれの支払いチャネルの前記支払いを行うユーザが、前記コミットメント・トランザクション署名し、該コミットメント・トランザクションを前記ブロックチェーンに送信することを含む、請求項６に記載の方法。
前記支払いを行うユーザ（Ｕｉ）が、前記それぞれの支払いチャネルの前記支払いを行うユーザと前記支払いを受け取るユーザ（Ｕｉ＋１）との間の前記コミットメント・トランザクションを作成し、
前記支払いを行うユーザが、それぞれの前記支払いチャネルの前記支払いを行うユーザと前記支払いを受け取るユーザとの間の前記返金トランザクションを作成し、該返金トランザクションは、指定された時間に又はその後に、それぞれの前記支払いチャネルの前記支払いを行うユーザに返金するように準備され、
前記それぞれの支払いチャネルの前記支払いを行うユーザが、前記返金トランザクションに署名し、及び
前記支払いを行うユーザが前記返金トランザクションに署名することを条件として、前記それぞれの支払いチャネルの前記支払いを行うユーザが、前記コミットメント・トランザクション署名し、該コミットメント・トランザクションを前記ブロックチェーンに送信することを含む、請求項６に記載の方法。
【請求項8】
前記第１、第２、及び更なる支払いチャネルには、それぞれ、前記コミットメント・トランザクション、前記返金トランザクション、前記支払いトランザクションが含まれ、
前記コミットメント・トランザクションは、前記支払いチャネルのコミットメント・コンポーネントを表す２－ｏｆ－２マルチシグネチャ・トランザクションを含み、前記それぞれの支払いチャネルの前記支払いを行うユーザは、２－ｏｆ－２マルチシグネチャ（Ｕｉ、Ｕ（ｉ＋１） ｍｏｄ ｎ）、又は前記それぞれの支払いチャネルのシークレット値（sｖ（ｉ＋１） ｍｏｄ ｎ）及びＵ（ｉ＋１） ｍｏｄ ｎの署名の知識のいずれかによって管理される指定された数のビットコインにコミットメントし、
前記返金トランザクションは、指定された時間が経過した後に、前記コミットメント・トランザクションの前記指定された数のビットコインを前記支払いを行うユーザに返金することを表し、前記返金トランザクションは、ユーザＵｉ及びＵ（ｉ＋１） ｍｏｄ ｎの署名によって実行され、
前記支払いトランザクションは、ＵｉからＵ（ｉ＋１） ｍｏｄ ｎへの前記指定された数のビットコインの支払いであり、前記支払いトランザクションは、前記それぞれの支払いチャネルのシークレット値及びＵ（ｉ＋１） ｍｏｄ ｎの前記署名との知識を通じて実行される、請求項６又は７に記載の方法。
前記コミットメント・トランザクションは、前記支払いチャネルのコミットメント・コンポーネントを表す２－ｏｆ－２マルチシグネチャ・トランザクションを含み、前記それぞれの支払いチャネルの前記支払いを行うユーザは、２－ｏｆ－２マルチシグネチャ（Ｕｉ、Ｕ（ｉ＋１） ｍｏｄ ｎ）、又は前記それぞれの支払いチャネルのシークレット値（sｖ（ｉ＋１） ｍｏｄ ｎ）及びＵ（ｉ＋１） ｍｏｄ ｎの署名の知識のいずれかによって管理される指定された数のビットコインにコミットメントし、
前記返金トランザクションは、指定された時間が経過した後に、前記コミットメント・トランザクションの前記指定された数のビットコインを前記支払いを行うユーザに返金することを表し、前記返金トランザクションは、ユーザＵｉ及びＵ（ｉ＋１） ｍｏｄ ｎの署名によって実行され、
前記支払いトランザクションは、ＵｉからＵ（ｉ＋１） ｍｏｄ ｎへの前記指定された数のビットコインの支払いであり、前記支払いトランザクションは、前記それぞれの支払いチャネルのシークレット値及びＵ（ｉ＋１） ｍｏｄ ｎの前記署名との知識を通じて実行される、請求項６又は７に記載の方法。
【請求項9】
前記指定された時間は、前記支払いを行うユーザが前記支払いチャネルのそれぞれの前記シークレット値を見つけ、支払いトランザクションを送信し、それぞれの前記支払いチャネルを構築するのに十分な期間である、請求項８に記載の方法。
【請求項10】
前記それぞれの支払いチャネルの前記シークレット値は、前記支払いを受け取るユーザから前記支払いを行うユーザへの直接通信によって明らかにされるか、又は逆の順序に従って、直前に送信された支払いトランザクションの前記ブロックチェーンから取得することによって明らかにされる、請求項１乃至９のいずれか一項に記載の方法。
【請求項11】
少なくとも１つのコミットメント・トランザクションが、該少なくとも１つのコミットメント・トランザクションの実行条件を満たすことに応答して、それぞれのリソースの制御を送信するように構成される、請求項１乃至１０のいずれか一項に記載の方法。
【請求項12】
実行条件は、前記コミットメント・トランザクションの＜scriptPubKey>においてＱ（ｉ＋１）ｍｏｄ ｎを使用することを含む、請求項９に記載の方法。
【請求項13】
前記トランザクション・チェーンの最終支払いチャネルは、時間Ｓ又はそれより前に確定される、請求項１乃至１２のいずれか一項に記載の方法。
【請求項14】
前記リソースは互いに同一である、請求項１乃至１３のいずれか一項に記載の方法。
【請求項15】
前記複数のユーザのそれぞれが、前記残りの複数のユーザのうちの１人に対する支払いを行うユーザ（Ｕｉ）であり、前記複数のユーザのそれぞれが、前記残りの複数のユーザのうちの異なる１人に対する支払いを受け取るユーザ（Ｕｉ＋１）である、請求項１乃至１４のいずれか一項に記載の方法。
【請求項16】
請求項１乃至１５のいずれか一項に記載の方法のステップを実行するように構成された少なくとも１つのプロセッサを含むコンピューティングシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、概して、ブロックチェーン・トランザクションに関し、より具体的には、３人以上のユーザを含むグループ内のブロックチェーン・トランザクションの交換に関する。本発明は、ビットコイン（ＢＴＣ）ブロックチェーンでの使用に特に適しているが、これに限定されるものではない。
【背景技術】
【0002】
この文書では、あらゆる形態の電子的なコンピュータベースの分散型台帳を含めるために「ブロックチェーン」という用語を使用している。これらの形態には、コンセンサスベースのブロックチェーン及びトランザクション・チェーン技術、アクセス許可された台帳とアクセス許可されていない台帳、共有台帳、及びこれらのバリエーションが含まれる。ブロックチェーン技術の最も広く知られている用途はビットコイン台帳であるが、他のブロックチェーン実施態様が提案され開発されている。本明細書では、便宜上及び例示の目的でビットコインについて参照しているが、本発明はビットコイン・ブロックチェーンでの使用に限定されるものではなく、代替のブロックチェーン実施態様及びプロトコルが本発明の範囲内にあることに留意されたい。
【0003】
ブロックチェーンはピアツーピアの電子台帳であり、この台帳はブロックで構成されるコンピュータベースの非中央型の分散システムとして実施され、ブロックはトランザクションで構成される。各トランザクションは、ブロックチェーンシステムのユーザ同士の間でのデジタル資産の制御の移転をエンコードするデータ構造であり、少なくとも１つの入力と少なくとも１つの出力とを含む。各ブロックには以前のブロックのハッシュが含まれており、これらブロックは、一緒にチェーンで繋がれており、その開始からブロックチェーンに書き込まれた全てのトランザクションの永続的な変更不可能なレコードを作成する。トランザクションには、それらの入力及び出力に埋め込まれたスクリプトとして知られている小さなプログラムが含まれており、スクリプトは、トランザクションの出力に誰がどの様にアクセスできるかを指定する。ビットコイン・プラットフォームでは、これらのスクリプトはスタックベースのスクリプト言語を使用して記述される。
【0004】
トランザクションをブロックチェーンに書き込むためには、「検証」する必要がある。ネットワークノード（マイナー（採掘者）：miners）は、各トランザクションが有効であることを確認する作業を行い、無効なトランザクションはネットワークから拒否される。ノードにインストールされたソフトウェアクライアントは、そのロック及びロック解除スクリプトを実行することにより、未使用（unspent）トランザクション（ＵＴＸＯ）でこの検証作業を行う。ロック及びロック解除スクリプトの実行がＴＲＵＥと評価された場合に、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれる。こうして、トランザクションをブロックチェーンに書き込むためには、そのトランザクションは、ｉ）トランザクションを受信する第１のノードで検証する（トランザクションが検証されると、ノードはその検証したトランザクションをネットワーク内の他のノードに中継する）；ｉｉ）マイナーによって構築された新しいブロックに追加する；ｉｉｉ）採掘する、すなわち過去のトランザクションの公的な台帳に追加する必要がある。
【0005】
ブロックチェーン技術は暗号通貨の実施態様の使用で最も広く知られているが、デジタル起業家は、ビットコインがベースとする暗号セキュリティシステムと、ブロックチェーンに保存して新しいシステムを実施できるデータとの両方の使用を模索し始めている。暗号通貨の領域に限定されない自動化されたタスク及びプロセスにブロックチェーンを使用できれば、非常に有利である。このようなソリューションによって、ブロックチェーンの利点（例えば、イベントの永続的な改ざん防止記録、分散処理等）を活用しながら、アプリケーションの用途を広げることができる。
【0006】
現在の研究の１つの分野は、「スマートコントラクト（smart contracts：契約の自動化）」の実装にブロックチェーンを使用することである。これらスマートコントラクトは、機械可読な契約又は同意の条件の実行を自動化するように設計されたコンピュータプログラムである。自然言語で記述される従来のコントラクト（契約）とは異なり、スマートコントラクトは、結果を生むために入力を処理できる規則を含むマシン実行可能プログラムであり、その結果、それらの結果に応じて動作を実行させることができる。
【0007】
ブロックチェーンに関連するもう１つの関心分野は、「トークン」（つまり、「カラードコイン」）を使用して、ブロックチェーンを介して実世界のエンティティを表現し且つそのエンティティで転送することである。潜在的に機密又は秘密のアイテムは、識別可能な意味や価値を有さないトークンで表すことができる。こうして、トークンは、実世界のアイテムをブロックチェーンから参照できるようにする識別子として機能する。
【0008】
広く公開された（open, public）台帳を提供するブロックチェーンは、利害関係者に、特定のデジタルコイン、デジタル資産、又はデジタルリソースの制御の一連のアドレスに亘る動きを追跡する機能を与える。例えば、通貨としてのビットコインの有効性及び成功は、ビットコインの実際の、知覚される（プロパティの有無による）代替可能性（fungibility）に結びついている。代替可能性は、あるユニットの商品と同じ種類の他のユニット商品との互換性プロパティである（http://www.investopedia.com/terms/f/fungibility.asp）。公開され、分散される台帳は、システムを信頼するための手段として機能する際に有用であるが、アドレス同士の間でトランザクションを追跡できるため、特定の履歴トランザクションに関連するデジタル資産を解析して相関させることができる。ビットコインの追跡不可能性（fungibility）に対処するために、セキュリティ及び匿名化ソリューションが開発された。多くの実世界の商取引は、法律上の理由、商業上の理由、又はその両方のために本質的に機密情報であるため、これは有益である。従って、ブロックチェーンの公共性にもかかわらず、ブロックチェーンシステムは、そのような商取引のセキュリティと機密性との両方を確保できなければならない。
【0009】
ビットコインの匿名性の研究には、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）等の他の独創的な匿名化技術も存在する。これら全てのソリューションに共通するのは、（ユーザが支払人である場合、又はユーザが受取人である場合の）特定のビットコイン・トランザクション及びアドレスからユーザの関連付けを解除する手段である。
【0010】
コイン・ミキシング・ソリューションの場合に、ユーザはビットコインをサービスに入力し、それらビットコインはユーザが選択した出力アドレスに転送される。出力アドレスに送信する前に資金がプールされているため、どの出力アドレスがユーザのものであるかを解明することは困難である。
【発明の概要】
【0011】
本発明者らは、背景技術の段落で説明したブロックチェーンのトランザクション・ミキシング手法に関するいくつかの技術的及びセキュリティ関連の問題を特定した。このようなトランザクション・ミキシング手法には、ミキシング・サービス・プロバイダーが必要である。これにより、追加のリソース要件がシステムに導入され、この中央型トランザクション・ミキシング・サービス・プロバイダーを提供するための管理間接費（overhead）が追加される。さらに、中央型トランザクション・ミキシング・サービス・プロバイダーの提供により、ブロックチェーンシステムの分散型のピアツーピア・アーキテクチャが希薄化され又は損なわれる。このような中央型システムは、ユーザから制御（control）を取り去る。さらに、このような中央型システムは、システムに攻撃の焦点を与える。さらに、トランザクション・ミキシング・サービス・プロバイダーは、ユーザのデジタル資産をプールから盗み取り、入力アドレスと出力アドレスとの間のリンクを意図的に又は意図せずに外部に公開する可能性があり、こうしてセキュリティ及び機密性が低下する。多くの点で、中央型トランザクション・ミキシング・サービス・プロバイダーの提供は、中央型機関の要件を無効にすることを目的とした、非中央型ピアツーピア・ブロックチェーンシステムの基本的な精神を損なわせる。
【0012】
上記に照らして、解決すべき１つの技術的問題は、既存のソリューションよりも非中央型、安全、及び機密性の高い方法でブロックチェーンのトランザクション・ミキシングを実現可能にし、且つ背景技術の段落で説明した既存のシステムの方法のように第３者のトランザクション・ミキシング・サービス・プロバイダーによる管理ではなく、システムのユーザにより制御されるソリューションをどの様に提供するかである。
【0013】
こうして、本発明によれば、添付の特許請求の範囲で規定される方法及びシステムが提供される。
【0014】
本発明は、コンピュータで実施されるシステムを提供することができる。これは、ブロックチェーンで実施されるシステム、セキュリティシステム、及び／又は制御システムとして説明できる。
【0015】
追加的又は代替的に、本発明は、ブロックチェーン上の複数のユーザの間でトランザクション・ミキシングを行うためのシステムを提供することができ、このシステムは、（ｉ）リソースの制御を第１のユーザの送信元アドレスから第２のユーザの受信アドレスに送信するように構成された第１のコミットメント・トランザクションを準備するステップと；（ｉｉ）リソースの制御を第２のユーザの送信元アドレスから別のユーザの受信アドレスに送信するように構成された第２のコミットメント・トランザクションを準備するステップと；（ｉｉｉ）リソースの制御を別のユーザの送信元アドレスから（ａ）第１のユーザの受信アドレス又は（ｂ）さらに別のユーザの受信アドレスのいずれかに送信するように構成された更なるコミットメント・トランザクションを準備するステップであって、トランザクション・チェーンを完了するためにオプション（ａ）が実行されるまでステップ（ｉｉｉ）を繰り返す、ステップと；（ｉｖ）トランザクション・チェーンを実行するステップと；を実施するように構成され、ユーザのうちの少なくとも１人が複数のユーザからランダムに選択される。
【0016】
「ユーザ」という用語は、人間又はプロセッサベースのリソースを指す場合がある。
【0017】
このようなシステムを提供することにより、複数のユーザが、セキュリティと機密性を高めたリソースの交換を可能にするトランザクション・チャネルを構築することができる。トランザクション・ミキシング・システムは、チェーン内の複数のユーザから少なくとも１人のユーザがランダムに選択されるブロックチェーン・トランザクション・チェーンを形成及び実行する点で異なる。チェーンは、コミットメント・トランザクションを使用して設定される。複数のユーザの間でデジタル資産を交換するためのそのようなシステムは、背景技術の段落で説明した従来技術の構成と比較すると、より安全であり、追加のシステム間接費を必要としない。例えば、システムは、この中央型トランザクション・ミキシング・サービス・プロバイダーを提供するためにシステムに追加のリソース要件と追加の管理間接費を導入するような気がするミキシング・サービス・プロバイダーを必要としない。さらに、中央型トランザクション・ミキシング・サービス・プロバイダーの提供により、ブロックチェーンシステムの非中央型のピアツーピア・アーキテクチャが希薄化され又は損なわれる。このような中央型システムは、ユーザから制御を取り去る。さらに、このような中央型システムは、システムに攻撃の焦点を与える。さらに、トランザクション・ミキシング・サービス・プロバイダーは、ユーザのデジタル資産をプールから盗み取り、入力アドレスと出力アドレスとの間のリンクを意図的に又は意図せずに外部に公開する可能性があり、こうしてセキュリティが低下する。対照的に、本システムでは、コミットメント・トランザクションのチェーンを介してトランザクションを準備及び実行することは、第３者ではなくユーザによって実行される。つまり、システムは、第３者によって実施／制御されないプロトコルを利用する。
【0018】
本発明の１つの技術的効果は、新しい方法で動作するように形成されたコンピュータシステムをもたらす。さらに、コンピュータシステムは、システムがハッキングやデータ操作に対してより堅牢である限り、より効率的且つ効果的に実行されるという意味で、より優れたコンピュータシステムである。
【0019】
少なくとも１つのコミットメント・トランザクションが、少なくとも１つのコミットメント・トランザクションの実行条件を満たすことに応答して、それぞれのリソースの制御を送信するように構成され得る。
【0020】
これにより、トランザクション・チェーンの少なくとも一部が実行され得る速度が向上するという利点がある。
【0021】
システムは、それぞれの実行条件を満たすように構成された少なくとも１つの実行トランザクションを準備するステップを実行するように構成され得る。
【0022】
これにより、トランザクション・チェーンの少なくとも一部が実行され得る速度がさらに向上するという利点がある。
【0023】
少なくとも１つのコミットメント・トランザクションの実行条件には、それぞれのシークレット値の供給が含まれ得る。
【0024】
これにより、第１のユーザにリスクを与えることなくトランザクション・チェーンを構築することができる一方、トランザクション・チェーンのその後の実行をより安全に行うことができる。
【0025】
少なくとも１つのシークレット値が第１のユーザによって選択され得、少なくとも１つの実行条件には選択されたシークレット値の供給が含まれ得る。
【0026】
これにより、ユーザのセキュリティを簡単な方法で高めるという利点がある。
【0027】
少なくとも１つのシークレット値が、（ｉ）選択されたシークレット値の供給、及び（ｉｉ）少なくとも１つの他のシークレット値の供給の少なくとも１つに応答して計算可能である。
【0028】
これにより、トランザクション・チェーンの実行を完了するのにかかる時間を大幅に増やすことなく、様々なシークレット値を使用可能にすることにより、システムのセキュリティを高めるという利点がある。
【0029】
少なくとも１つのコミットメント・トランザクションが、返還（return）条件が満たされると、それぞれのリソースの制御をそれぞれのユーザに戻すように構成され得る。
【0030】
これにより、ユーザからの少なくとも１つのリソースの窃盗に対するセキュリティを高めるという利点がある。
【0031】
システムは、ロック時間を含む少なくとも１つの返還トランザクションを準備するステップを実行するように構成され、少なくとも１つの返還トランザクションは、ロック時間の終了時に少なくとも１つのそれぞれの返還条件を満たすように構成され得る。
【0032】
これにより、システムの使用中に許可される最大時間を制限し、それにより必要なコンピュータリソースの量を削減できるという利点がある。
【0033】
システムは、少なくとも１つの準備されたトランザクションをブロックチェーンに送信するように構成され得る。
【0034】
これは、少なくとも１つの準備されたトランザクションをブロックチェーンに保存することにより、少なくとも１つの準備されたトランザクションの改ざんを防止し、それによりセキュリティを高めるという利点がある。
【0035】
システムは、トランザクション・チェーンが準備された順序と逆の順序でトランザクション・チェーンを実行するように構成され得る。
【0036】
これにより、第１のユーザが、完了したコミットメント・トランザクションのチェーンの実行を開始することができ、これにより、複数のユーザのうちの１人のユーザに対するリスクを分離することにより、セキュリティを高める。
【0037】
リソースは互いに同一である、以前のいずれかに記載のシステム。
【0038】
これにより、システムの使用が簡素化されるという利点がある。
【0039】
追加的又は代替的に、ブロックチェーン上の複数のユーザの間のトランザクション・ミキシングに参加するためのコンピュータで実施される方法を提供することができ、この方法は、（ｉ）第１のコミットメント・トランザクションの実行条件が満たされると、第１のリソースの制御を第１のユーザの送信元アドレスから第２のユーザの受信アドレスに送信するように構成された第１のコミットメント・トランザクションをブロックチェーンに送信するステップと；（ｉｉ）第３のリソースの制御を第３のユーザの送信元アドレスから第１のユーザの受信アドレスに送信するように構成された第２のコミットメント・トランザクションのブロックチェーンへの送信に応答して、第３のコミットメント・トランザクションの実行条件を満たすように構成された実行トランザクションをブロックチェーンに送信するステップと；を含み、ユーザのうちの少なくとも１人が複数のユーザからランダムに選択される。
【0040】
追加的又は代替的に、ブロックチェーン上の複数のユーザの間のトランザクション・ミキシングに参加するためのコンピュータで実施される方法を提供することができ、この方法は、（ｉ）第１のコミットメント・トランザクションの条件が満たされると、リソースの制御を第１のユーザの送信元アドレスから第２のユーザの受信アドレスに送信するように構成された第１のコミットメント・トランザクションをブロックチェーンに送信するステップと；（ｉｉ）第１のコミットメント・トランザクションの条件を満たすように構成された第１の実行トランザクションのブロックチェーンへの送信に応答して、第２のコミットメント・トランザクションの条件を満たすように構成された第２の実行トランザクションをブロックチェーンに送信するステップと；を含み、ユーザのうちの少なくとも１人は複数のユーザからランダムに選択される。
【0041】
特定の構成によれば、少なくとも１人の個人が、両方のアドレスの間のリンクを隠し、且つ中央型コイン・ミキシング・サービス・プロバイダーを必要としない安全な方法で達成される方法で、ビットコインを自分のアドレスから別のアドレスに移動できるようにすることが望ましい場合がある。これは、個人がグループ交換プロトコルに参加し、各メンバーがグループｘの交渉された金額のビットコインを別のランダムメンバーに支払い、及び別のランダムメンバーが交渉された金額のビットコインをユーザｘに支払うシステムを提供することで実現できる。交換プロトコルは、ユーザが自分の資金を新しいアドレスに効率的に移動し、グループ交換のメンバーがビットコインを失うリスクを負わないように設計されている。
【図面の簡単な説明】
【0042】
本発明のこれら及び他の態様は、本明細書に記載の実施形態を参照して説明され、これらの実施形態から明らかになろう。ここで、本発明の実施形態を、単なる例として、添付の図面を参照して説明する。
【図1】従来技術の支払チャネルで使用されるトランザクションを示す図である。
【図2】従来技術のアトミック・クロスチェーン取引アルゴリズムを示す図である。
【図3】本発明の第１の実施形態の支払チャネルを示す図である。
【図4】本発明の支払チャネルが作成される順序を示す図である。
【図5】第１の実施形態の支払チャネルのチェーンを示す図である。
【図6】第１の実施形態のコミットメント・トランザクションの例を示す図である。
【図7】第１の実施形態の返金トランザクションの例を示す図である。
【図8】第１の実施形態の支払トランザクションの例を示す図である。
【図10】第１の実施形態の支払チャネルを構築するためのアルゴリズムを示す図である。
【図11】第１の実施形態の支払チャネルのチェーンを構築するためのアルゴリズムを示す図である。
【図12】第１の実施形態の支払トランザクションを送信するプロセスのアルゴリズムを示す図である。
【図13】本発明の第２の実施形態の支払チャネルを示す図である。
【図14】第２の実施形態の支払チャネルを構築するためのアルゴリズムを示す図である。
【図15】第２の実施形態の支払チャネルのチェーンを構築するためのアルゴリズムを示す図である。
【図16】第２の実施形態の支払チャネルのチェーンを示す図である。
【図17】第２の実施形態の支払チャネルのチェーンの実行の表現を示す図である。
【図18】第２の実施形態の支払トランザクションを送信するプロセスのアルゴリズムを示す図である。
【図19】返金トランザクションを含む第２の実施形態の支払チャネルのチェーンを示す図である。
【図20】第２の実施形態の返金トランザクションのロック時間要件を示す図である。
【図21】第２の実施形態のコミットメント・トランザクションの例を示す図である。
【図22】第２の実施形態の返金トランザクションの例を示す図である。
【図23】第２の実施形態の支払トランザクションの例を示す図である。
【図24】第２の実施形態で使用するスクリプトの例を示す図である。
【発明を実施するための形態】
【0043】
本明細書では、本発明を具現化するグループランダム交換（ＧＲＥ）プロトコルと呼ばれるプロトコルについて説明し、このプロトコルは、ユーザがあるアドレスから別のアドレスに資金を移動する一方、ユーザのアドレス同士の間のリンクを覆い隠し、ユーザが自分の資金を盗まれる可能性を排除するためのものである。このプロトコルは、グループの各メンバーがｘＢＴＣを他の１人のメンバーに支払い、それにより全員が支払いを受け取ることに同意するグループの概念に基づいて構築される。
【0044】
ユーザがｘＢＴＣを誰に支払うかはランダムであり、誰がユーザにｘＢＴＣを支払うかもランダムである。これにより、ユーザは自分のｘＢＴＣをあるアドレスに送信し得るが、ランダムに決定された別のユーザからの別のアドレスでｘＢＴＣの受信を受け取る。このランダム性により、プロトコルの外部の誰かがブロックチェーンを解析し、ユーザの入力アドレスと出力アドレスとの間のリンクを決定することを困難にさせる。
【0045】
さらに、ＧＲＥプロトコルは、あるグループのｎ人のユーザの間でこの交換を行うことができ、グループ内のユーザは自分の資金を失うリスクはない。プロトコルは、該当する場合は返金（refund）トランザクションを使用して、プロトコルの実行の際に計画通りに進まない場合にユーザが自分の資金を回収できるようにする。
【0046】
ＧＲＥプロトコルは、既存の２つのビットコイン関連技術に基づいている。これら技術うちの第１の技術は、支払チャネル（’Introduction to Micropayment Channels’ http://super3.org/introduction-to-micropayment-channels/）であり、これは、一対（２人）のユーザの間のブロック外のビットコイン・トランザクション用に設計された技術であり、特に返金トランザクションの使用を組み込む。これらの技術のうちの第２の技術は、アトミック・クロスチェーン取引（ＡＣＣＴ）（’Atomic cross-chain trading’ https://en.bitcoin.it/wiki/Atomic_cross-chain_trading）であり、これは、ある暗号通貨をｘコイン有するユーザが、自分のｘコインを、別の暗号通貨をｙコイン有する別のユーザと交換するように設計されたプロトコルである。これは「公正な交換」として行われ、第１のユーザは、第２のユーザが第１のユーザが所有しているコインを徴収できるようにしない限り、第２のユーザのコインを取得できない。
【0047】
ＡＣＣＴは２人のユーザの間の交換について説明するが、本発明は、２人以上のユーザの間でのグループ交換を提供するＧＲＥプロトコルに関連しており、ＧＲＥプロトコルでは、第１のユーザが支払いを行う第２のユーザは、第１のユーザに支払いを行うユーザではない。
【0048】
支払チャネル
支払チャネルは、全てのトランザクションをブロックチェーンにコミット（commit）せずに、ユーザが複数のビットコイン・トランザクションを作成できるように設計された技術である。一般的な支払チャネルの実施態様では、ほぼ無制限の支払いを行うことができるが、支払チャネルは、２つのトランザクションをブロックチェーンに追加するだけで十分である。
支払チャネルは、全てのトランザクションをブロックチェーンにコミット（commit）せずに、ユーザが複数のビットコイン・トランザクションを作成できるように設計された技術である。一般的な支払チャネルの実施態様では、ほぼ無制限の支払いを行うことができるが、支払チャネルは、２つのトランザクションをブロックチェーンに追加するだけで十分である。
【0049】
ブロックチェーンに追加されるトランザクション数を減らすこと及び関連するコストを削減することに加えて、支払チャネルには速度の利点もあり、重要なことに、物事が計画通りに進まなかったり、又はいずれかのユーザが特定の支払いセットを超えて先に進まないことを決定したりする場合に、ユーザが自分の資金を回収することができる。支払チャネルの実施態様の説明を以下に概説する。
【0050】
アリス（Alice）がサービスに対してボブ（Bob）に支払う必要があるシナリオを考えてみる。状況に応じて、一定期間に亘ってアリスからボブへの複数の支払いが必要になる場合がある。アリスは、可能な交換セットでボブに最大１５ＢＴＣ（合計）を使うことを予定している。これを容易にするために、アリスとボブとの間に支払チャネルが確立され、次のように動作する。
・アリスは、アリスとボブとの両方によって管理される、２オブ２（2-of-2）マルチシグネチャのPay to Scriptハッシュ（Ｐ２ＳＨ）トランザクションＴＣを作成し、アリスから発信される１５ＢＴＣをコミット（付託）する。この時点では、トランザクションはビットコイン・ネットワークに送信されていない（このようなマルチシグネチャのアドレスでは、２人の個人（アリスとボブ）がこのアドレスからお金を使うトランザクションに署名する必要がある）。
・アリスは、別個の返金トランザクションＴｒ，０を作成し、「マルチシグネチャ管理ファンド」から全ての資金をアリスに戻す。このトランザクションには、１００ブロックのｎＬｏｃｋＴｉｍｅ値が含まれる（ｎＬｏｃｋＴｉｍｅ（ｎロック時間）は、指定した時間が経過した後にのみビットコイン・トランザクションを実行できるようにするビットコイン・トランザクション・パラメータである）。ボブはトランザクションに署名する。この返金トランザクションは、ｎＬｏｃｋＴｉｍｅが発生した後に、アリスとボブと間の交換が食い違う場合に、アリスに返金することができる。
・アリスは元のトランザクションＴＣに署名する。
・この時点で、アリスとボブは、アリスからボブに行われた（ブロックチェーン外の）支払いを反映するために、新しい返金トランザクションの作成に進むことができる。これらの返金トランザクションは、その時点でアリスがボブに支払うために必要な純額（net sum of money）を反映する。例として、アリスがボブに５ＢＴＣを支払う場合に、５ＢＴＣをボブに送信し、１０ＢＴＣをアリスに送り返す出力を有する新しい返金トランザクションＴｒ，ｉが作成される。アリスがボブに別の５ＢＴＣを支払う必要がある場合に、１０ＢＴＣをボブに送信し、５ＢＴＣをアリスに返り返す出力を有する新しい返金トランザクションＴｒ，ｉ＋１が作成される。新しい返金トランザクション毎に、両者が詳細に同意すると仮定すると、両当事者はトランザクションに署名するが、必ずしもトランザクションをネットワークに送信するわけではない。
・作成された連続する各返金トランザクションは、以前の返金トランザクションのｎＬｏｃｋＴｉｍｅよりも短いことに留意されたい。
・ｎＬｏｃｋＴｉｍｅ（Ｔｒ，ｉ＋１）＜ｎＬｏｃｋＴｉｍｅ（Ｔｒ，ｉ）
・ユーザがＴｒ，ｉに署名するのを拒否した場合に、被害を受けたユーザは単にＴｒ，ｉ－１を送信すればよい。最悪シナリオの場合に、アリスはＴｒ，０に署名し、このＴｒ，０をネットワークに送信して（ｎＬｏｃｋＴｉｍｅが経過した後に）自分の全ての資金を回収する。
・構築された最終的な返金トランザクションは、アリスからボブに送金された資金の純額を表す。このトランザクションはネットワークに送信される。
・アリスは、アリスとボブとの両方によって管理される、２オブ２（2-of-2）マルチシグネチャのPay to Scriptハッシュ（Ｐ２ＳＨ）トランザクションＴＣを作成し、アリスから発信される１５ＢＴＣをコミット（付託）する。この時点では、トランザクションはビットコイン・ネットワークに送信されていない（このようなマルチシグネチャのアドレスでは、２人の個人（アリスとボブ）がこのアドレスからお金を使うトランザクションに署名する必要がある）。
・アリスは、別個の返金トランザクションＴｒ，０を作成し、「マルチシグネチャ管理ファンド」から全ての資金をアリスに戻す。このトランザクションには、１００ブロックのｎＬｏｃｋＴｉｍｅ値が含まれる（ｎＬｏｃｋＴｉｍｅ（ｎロック時間）は、指定した時間が経過した後にのみビットコイン・トランザクションを実行できるようにするビットコイン・トランザクション・パラメータである）。ボブはトランザクションに署名する。この返金トランザクションは、ｎＬｏｃｋＴｉｍｅが発生した後に、アリスとボブと間の交換が食い違う場合に、アリスに返金することができる。
・アリスは元のトランザクションＴＣに署名する。
・この時点で、アリスとボブは、アリスからボブに行われた（ブロックチェーン外の）支払いを反映するために、新しい返金トランザクションの作成に進むことができる。これらの返金トランザクションは、その時点でアリスがボブに支払うために必要な純額（net sum of money）を反映する。例として、アリスがボブに５ＢＴＣを支払う場合に、５ＢＴＣをボブに送信し、１０ＢＴＣをアリスに送り返す出力を有する新しい返金トランザクションＴｒ，ｉが作成される。アリスがボブに別の５ＢＴＣを支払う必要がある場合に、１０ＢＴＣをボブに送信し、５ＢＴＣをアリスに返り返す出力を有する新しい返金トランザクションＴｒ，ｉ＋１が作成される。新しい返金トランザクション毎に、両者が詳細に同意すると仮定すると、両当事者はトランザクションに署名するが、必ずしもトランザクションをネットワークに送信するわけではない。
・作成された連続する各返金トランザクションは、以前の返金トランザクションのｎＬｏｃｋＴｉｍｅよりも短いことに留意されたい。
・ｎＬｏｃｋＴｉｍｅ（Ｔｒ，ｉ＋１）＜ｎＬｏｃｋＴｉｍｅ（Ｔｒ，ｉ）
・ユーザがＴｒ，ｉに署名するのを拒否した場合に、被害を受けたユーザは単にＴｒ，ｉ－１を送信すればよい。最悪シナリオの場合に、アリスはＴｒ，０に署名し、このＴｒ，０をネットワークに送信して（ｎＬｏｃｋＴｉｍｅが経過した後に）自分の全ての資金を回収する。
・構築された最終的な返金トランザクションは、アリスからボブに送金された資金の純額を表す。このトランザクションはネットワークに送信される。
【0051】
図１は、支払チャネルで使用されるトランザクションを示している。Ｍは、アリスからボブに送信できる最大金額を表す。ｘｉは、アリスがボブに支払う必要がある現在の資金の純額である。Ｓｓｔｏｐは、初期の返金トランザクションのｎＬｏｃｋＴｉｍｅである。ｎは、アリスとボブとの間で進行中の（ブロック外の）支払いで作成された返金トランザクションの数である（これは初期の返金トランザクションを除く）。ｓは、ある当事者が以前の返金トランザクションを送信する他の当事者にリスクを与える前に、両方のユーザが返金トランザクションに同意するために割り当てられた時間であり、アリスとボブとの間の交換を事実上終了させる時間である。
【0052】
以下に留意されたい。
ｔ＋ｎ＊ｓ ＜Ｓｓｔｏｐ、ここでtは現在の時間であり、
（Ｓｓｔｏｐ－ｎ＊ｓ）≧ｓ。
ｔ＋ｎ＊ｓ ＜Ｓｓｔｏｐ、ここでtは現在の時間であり、
（Ｓｓｔｏｐ－ｎ＊ｓ）≧ｓ。
【0053】
図１のトランザクションＴＣ及びＴr，ｎは、ブロックチェーンに表示されるトランザクションである。
図９は、アリスとボブとの間の支払チャネルを構築する際に含められるステップを含むフローチャートを示している。
図９は、アリスとボブとの間の支払チャネルを構築する際に含められるステップを含むフローチャートを示している。
【0054】
アトミック・クロスチェーン取引
デジタル交換の場合に、「公正な交換（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）では、信頼できる第３者がいなければ決定論的な公正な交換は不可能であることが示されている。
デジタル交換の場合に、「公正な交換（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）では、信頼できる第３者がいなければ決定論的な公正な交換は不可能であることが示されている。
【0055】
ＡＣＣＴの場合に、この創作者は２人のユーザが別々の暗号通貨の間でコインを交換するための公正な交換プロトコルを考案した。このソリューションでは、暗号通貨のブロックチェーンが信頼できる第３者として機能する。ＡＣＣＴのアルゴリズムを図２に示す。ここで、アリスＡは、ｖアルトコインと引き換えに、ｗＢＴＣをボブＢに支払う。
【0056】
これはＡＣＣＴ（タイムアウト付き）である。プロセスが一時停止された場合に、いつ停止しても元に戻すことができる。
【0057】
図２を参照すると、ユーザＡ及びＢがＡＣＣＴを使用している間のイベントのタイムラインの例は次のとおりである。
１）の前：（ブロードキャストすべき）公開されているものがないため、何も起こらない。
１）と２）の間：Ａは７２時間後に返金トランザクションを使用して、自分のお金を取り戻すことができる。
２）と３）の間：Ｂは２４時間後に返金を受け取ることができる。Ａは返金を受け取るために２４時間以上を要する。
３）後：２）までにトランザクションが完了し、
－Ａは２４時間以内に自分の新しいコインを使う必要がある。そうでない場合に、Ｂは返金を請求して自分のコインを保持することができる。
－Ｂは７２時間以内に自分の新しいコインを使う必要がある。そうでない場合に、Ａは返金を請求して自分のコインを保持することができる。
安全のため、ＡとＢとの両方が期限までに多くの時間をかけてプロセスを完了する必要がある。
１）の前：（ブロードキャストすべき）公開されているものがないため、何も起こらない。
１）と２）の間：Ａは７２時間後に返金トランザクションを使用して、自分のお金を取り戻すことができる。
２）と３）の間：Ｂは２４時間後に返金を受け取ることができる。Ａは返金を受け取るために２４時間以上を要する。
３）後：２）までにトランザクションが完了し、
－Ａは２４時間以内に自分の新しいコインを使う必要がある。そうでない場合に、Ｂは返金を請求して自分のコインを保持することができる。
－Ｂは７２時間以内に自分の新しいコインを使う必要がある。そうでない場合に、Ａは返金を請求して自分のコインを保持することができる。
安全のため、ＡとＢとの両方が期限までに多くの時間をかけてプロセスを完了する必要がある。
【0058】
グループランダム交換
本発明は、グループランダム交換（ＧＲＥ）プロトコルに関する。本発明は、ｎ＞２のｎ人のユーザのグループ内でビットコインを交換するためのソリューションを提供する。グループ内の各ユーザは、自分の所有しているビットコインの量を同じ量のビットコインに交換できる。
本発明は、グループランダム交換（ＧＲＥ）プロトコルに関する。本発明は、ｎ＞２のｎ人のユーザのグループ内でビットコインを交換するためのソリューションを提供する。グループ内の各ユーザは、自分の所有しているビットコインの量を同じ量のビットコインに交換できる。
【0059】
ただし、プロトコルに変更を加えないと、２人のユーザの間で交換されるビットコインの量が等しくならない可能性がある。ＵｉとＵ（ｉ＋１） ｍｏｄ ｎとの間で交換される値は、ユーザのペアが自分達でネゴシエートできる任意の値であり得る。
【0060】
ｘＢＴＣが交換される合意金額であると想定し、影響を受ける全てのユーザにとって望ましい場合に、ユーザは（ｘ＋ａ）ＢＴＣを支払うことができるが、ユーザは（ｘ－ｂ）ＢＴＣを引き出すことができる。例えば、ユーザＵ１には交換用の１０ＢＴＣがある。８ＢＴＣがＵ１に利用可能な最良のオファーである場合に、Ｕ１はユーザＵ０から８ＢＴＣを受け取る。Ｕ１はこれを行うが、更なるユーザＵ２が１０ＢＴＣの受取りを要求する可能性が残っていることを理解している。換言すれば、Ｕ１が支払う値は、Ｕ１がこれらの条件を受け入れる場合に限り、Ｕ１に支払われる値である必要はなく、Ｕ１が要求する場合に、Ｕ１が支払う値はＵ１に支払われる値である場合がある。
【0061】
これ以降、説明は、説明目的で、各ユーザがｘＢＴＣを支払ってｘＢＴＣの支払いを受け取るシナリオにのみ限定される。
【0062】
さらに、ユーザはプロトコル内でトークンを交換することができる。トークンは、トークンの制御が資産又はリソースの制御を提供するように、トークンに関連付けられたスマートコントラクトに従って資産又はリソースを表す。
【0063】
ユーザが所有するビットコインの正味の変化は、取引手数料が無視されると仮定すると、交換プロトコルに参加した後も変わらない（取引手数料は全てのビットコイン・トランザクションに関連する費用である）。第１のユーザがＵｓｅｒＡである場合に、ＵｓｅｒＡは総額ｘＢＴＣをＵｓｅｒＢに支払い、ＵｓｅｒＣはｘＢＴＣをＵｓｅｒＡに支払う。ここで、ＵｓｅｒＢはＵｓｅｒＣと同じユーザではない。さらに、各ユーザは、支払いの送信に関連付けられた送信元アドレスと、支払いの受信に関連付けられた受信アドレスとを有しており、送信元アドレスと受信アドレスとは異なる。ただし、プロトコルに参加することで、ビットコイン・アドレスに保管されたユーザのビットコインは、同じユーザによって所有又は管理される別のアドレスに実際に転送される。交換プロトコル・プロセスにより、アドレス同士の間でのビットコインの転送は、ブロックチェーンの解析において、資金の転送を明確にしない方法で達成される。
【0064】
ＡＣＣＴは一対のユーザの間の相互交換のみを概説するが、ＧＲＥプロトコルはＡＣＣＴとは異なり、ＧＲＥプロトコルは次の場合の交換を記述する。
・３人以上のユーザが存在する。
・支払いを受け取る及び支払いを行うプロセスにおいて、第１のユーザが支払いを行う第２のユーザは、第１のユーザが支払いを受け取るユーザではない。
・３人以上のユーザが存在する。
・支払いを受け取る及び支払いを行うプロセスにおいて、第１のユーザが支払いを行う第２のユーザは、第１のユーザが支払いを受け取るユーザではない。
【0065】
ＧＲＥプロトコルは、これを次の方法で達成する。
・プロトコルのユーザは、自分のビットコインを失うリスクはない。
・第１のユーザが支払いを行う第２のユーザは、第１のユーザに支払いを行うユーザと同様にランダムである。
・プロトコルのユーザは、自分のビットコインを失うリスクはない。
・第１のユーザが支払いを行う第２のユーザは、第１のユーザに支払いを行うユーザと同様にランダムである。
【0066】
第１のタイプのグループランダム交換－シークレット値
グループランダム交換プロトコルは、２つの方法のうちの１つで動作し、各方法は本発明を具現化する。次に、本発明の構成について説明する。
グループランダム交換プロトコルは、２つの方法のうちの１つで動作し、各方法は本発明を具現化する。次に、本発明の構成について説明する。
【0067】
ｎ人のユーザＵｉ｜（ｉ）∈［０，ｎ－１］のセットが、本発明の構成のＧＲＥプロトコルに参加して、ｘＢＴＣを交換することを考えると、プロトコルは次のように動作する。
・順序付けられたセット｛Ｕ０，Ｕ１，…，Ｕｎ－２，Ｕｎ－１｝を実現するために、ユーザはランダム化される。
・これらのユーザの１人は「開始者（initiator）」又は「開始ユーザ」と見なされる。この目的のために、Ｕ０は開始者と見なされる。
・開始者Ｕ０は乱数ｋを選択し、Ｈ（ｋ）を計算する。ここで、Ｈ（・）は決定論的なハッシュ関数を表す。
・ｋの値はＵ０によってプライベートに保持されるが、値Ｈ（ｋ）はＧＲＥの全てのユーザに配信される。
・支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎを構築し、ｋの値を取得し、Ｕ（ｉ＋１） ｍｏｄ ｎに支払いを行う実行トランザクションＴｐａｙをビットコイン・ネットワークに送信するために各ユーザＵｉに与えられる時間量を表す時間値ｓが選択される。グループ内の任意のユーザは、他のユーザのコンセンサスを考慮して、時間ｓを選択することができる。好ましい実施形態では、開始者は、単にプロトコルに対してｓを選択する。時間ｓは、秒又はブロック数で表される。
・別の値Ｓが、ビットコイン・ネットワークに送信される、ユーザに対する最初の支払いの開始時間として選択される。グループ内のユーザは、他のユーザのコンセンサスを考慮して、Ｓを選択することができる。好ましい実施形態では、開始者は、単にプロトコルに対してｓを選択する。ＳはＵｎｉｘ時間又はブロックの高さで指定された時点を表し、ｓは時間範囲を表すことに留意されたい。
・全ての一対のユーザの間に一方向の支払チャネルが確立され、支払いの方向は、ＵｉがＵ（ｉ＋１） ｍｏｄ ｎに支払いを行うような方向（ここではＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎで表される）である。例として、ｎ＝７と仮定すると、ＧＲＥの支払チャネルは、Ｕ０→Ｕ１，Ｕ１→Ｕ２，…，Ｕ６→Ｕ０で構成される。
・支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎの作成プロセスを図３及び図１０に示す。ここで、σ（Ｕｉ）はＵｉの署名を表す。
ｏ初期コミットメント・トランザクションＴＣによって、（ｉ）ＵｉとＵ（ｉ＋１） ｍｏｄ ｎとの両方の署名、又は（ｉｉ）ｋ及びＵ（ｉ＋１） ｍｏｄ ｎの署名（図６を参照）のいずれかを提供することによってのみ使うことができるｘＢＴＣが利用可能になる。
ｏここでは１つの返金トランザクションのみが必要である。返金機能Ｔｒ，０によって、全てのｘＢＴＣをＵｉに返す（図７を参照）。
ｏ返金トランザクションＴｒ，０には、ｎＬｏｃｋＴｉｍｅ値Ｓ＋（ｎ－ｉ）ｓが含まれる。
ｏ初期コミットメント・トランザクションＴＣがビットコイン・ネットワークに送信される前に、Ｕ（ｉ＋１） ｍｏｄ ｎが返金トランザクションＴｒ，０に署名する必要がある。
ｏ支払チャネルには、ＴＣのコミット済みｘＢＴＣからＵ（ｉ＋１） ｍｏｄ ｎにｘＢＴＣを支払う支払トランザクションＴｐａｙが含まれる。
ｏＵ（ｉ＋１） ｍｏｄ ｎへの支払トランザクションＴｐａｙの＜scriptSig＞には、値ｋが含まれる（図８を参照）。
・支払チャネルＵｉ－１→Ｕｉが支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎの前に設定されるため、一対のユーザの間の支払チャネルを規則正しい順序で作成することが重要である。これは、第１の支払チャネルＵ０→Ｕ１の作成から始まり、ここでＵ０が開始者であり、最後の支払チャネルＵｎ－１→Ｕ０で終了する。図４は、支払チャネルの構築順序を示している。
・順序付けられたセット｛Ｕ０，Ｕ１，…，Ｕｎ－２，Ｕｎ－１｝を実現するために、ユーザはランダム化される。
・これらのユーザの１人は「開始者（initiator）」又は「開始ユーザ」と見なされる。この目的のために、Ｕ０は開始者と見なされる。
・開始者Ｕ０は乱数ｋを選択し、Ｈ（ｋ）を計算する。ここで、Ｈ（・）は決定論的なハッシュ関数を表す。
・ｋの値はＵ０によってプライベートに保持されるが、値Ｈ（ｋ）はＧＲＥの全てのユーザに配信される。
・支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎを構築し、ｋの値を取得し、Ｕ（ｉ＋１） ｍｏｄ ｎに支払いを行う実行トランザクションＴｐａｙをビットコイン・ネットワークに送信するために各ユーザＵｉに与えられる時間量を表す時間値ｓが選択される。グループ内の任意のユーザは、他のユーザのコンセンサスを考慮して、時間ｓを選択することができる。好ましい実施形態では、開始者は、単にプロトコルに対してｓを選択する。時間ｓは、秒又はブロック数で表される。
・別の値Ｓが、ビットコイン・ネットワークに送信される、ユーザに対する最初の支払いの開始時間として選択される。グループ内のユーザは、他のユーザのコンセンサスを考慮して、Ｓを選択することができる。好ましい実施形態では、開始者は、単にプロトコルに対してｓを選択する。ＳはＵｎｉｘ時間又はブロックの高さで指定された時点を表し、ｓは時間範囲を表すことに留意されたい。
・全ての一対のユーザの間に一方向の支払チャネルが確立され、支払いの方向は、ＵｉがＵ（ｉ＋１） ｍｏｄ ｎに支払いを行うような方向（ここではＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎで表される）である。例として、ｎ＝７と仮定すると、ＧＲＥの支払チャネルは、Ｕ０→Ｕ１，Ｕ１→Ｕ２，…，Ｕ６→Ｕ０で構成される。
・支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎの作成プロセスを図３及び図１０に示す。ここで、σ（Ｕｉ）はＵｉの署名を表す。
ｏ初期コミットメント・トランザクションＴＣによって、（ｉ）ＵｉとＵ（ｉ＋１） ｍｏｄ ｎとの両方の署名、又は（ｉｉ）ｋ及びＵ（ｉ＋１） ｍｏｄ ｎの署名（図６を参照）のいずれかを提供することによってのみ使うことができるｘＢＴＣが利用可能になる。
ｏここでは１つの返金トランザクションのみが必要である。返金機能Ｔｒ，０によって、全てのｘＢＴＣをＵｉに返す（図７を参照）。
ｏ返金トランザクションＴｒ，０には、ｎＬｏｃｋＴｉｍｅ値Ｓ＋（ｎ－ｉ）ｓが含まれる。
ｏ初期コミットメント・トランザクションＴＣがビットコイン・ネットワークに送信される前に、Ｕ（ｉ＋１） ｍｏｄ ｎが返金トランザクションＴｒ，０に署名する必要がある。
ｏ支払チャネルには、ＴＣのコミット済みｘＢＴＣからＵ（ｉ＋１） ｍｏｄ ｎにｘＢＴＣを支払う支払トランザクションＴｐａｙが含まれる。
ｏＵ（ｉ＋１） ｍｏｄ ｎへの支払トランザクションＴｐａｙの＜scriptSig＞には、値ｋが含まれる（図８を参照）。
・支払チャネルＵｉ－１→Ｕｉが支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎの前に設定されるため、一対のユーザの間の支払チャネルを規則正しい順序で作成することが重要である。これは、第１の支払チャネルＵ０→Ｕ１の作成から始まり、ここでＵ０が開始者であり、最後の支払チャネルＵｎ－１→Ｕ０で終了する。図４は、支払チャネルの構築順序を示している。
【0068】
一部の構成では、ユーザＵｉが支払いを行う際にリスクを負う前に、次のことを確認できるようにするので、シーケンスの順序が重要である。
・ＵｉへのＴｐａｙトランザクションが存在し、トランザクションＴｐａｙがビットコイン・ネットワークで受け入れられるためには、Ｕｉがｋの知識を有しているだけでよい。
・支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎ（Ｕｉが使う）のＴｐａｙにある基準は、支払チャネルＵｉ－１→Ｕｉ（Ｕｉが受け取る）のＴｐａｙの基準と同じである。
・ＵｉへのＴｐａｙトランザクションが存在し、トランザクションＴｐａｙがビットコイン・ネットワークで受け入れられるためには、Ｕｉがｋの知識を有しているだけでよい。
・支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎ（Ｕｉが使う）のＴｐａｙにある基準は、支払チャネルＵｉ－１→Ｕｉ（Ｕｉが受け取る）のＴｐａｙの基準と同じである。
【0069】
開始者Ｕ０のみが、支払いに先立って受取りを優先する必要はない。ただし、ｋの値を知っているユーザはＵ０だけなので、Ｕ０をだますことはできない。従って、Ｕ０がプロセスを快適に開始するまで（ｋのリリース（解除）と一致するまで）ＧＲＥプロトコルにおいてだれでも引出しを行うことができない。
【0070】
ＧＲＥインスタンスのＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎ支払チャネルのセットを作成するプロセスを図１１に示す。
【0071】
最終的な支払チャネルＵｎ－１→Ｕ０は、時刻Ｓに又はその前に終了するものと想定される。この最終的な支払チャネルが構築されると、トランザクションのチェーン、つまりトランザクション・チェーンは、プロトコルの全てのユーザのリンク付けを完了したと言うことができる。
【0072】
図５は、ＧＲＥプロトコルの全てのユーザの間に存在するＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎの支払チャネルの表現を示している。矢印は、支払チャネルとＴｐａｙ支払いの方向とを示す。矢印の外部に隣接する式は、ブロックチェーンによって受け入れられるトランザクションＴｐａｙの基準を表す。σ（Ｕｉ）はＵｉの署名を表すことに留意されたい。矢印の内部に隣接する式は、ｓの期間値を表す。
【0073】
円形の配置に照らして、Ｕｉ｜ｉ∈［０，ｎ－１］の順序がランダムであるという事実は、ユーザＵｉに支払いを行う人とユーザＵｉが支払いを受け取る人が両方ともランダムであることを意味する。さらに、ユーザＵｉに支払いを行う人とユーザＵｉが支払いを受ける人は異なる。
【0074】
開始者Ｕ０は、既存の支払チャネルＵｎ－１→Ｕ０のトランザクションＴｐａｙを使って、ｋの値を明らかにする。Ｕ０はこのｋの値をＵｎ－１に直接伝えることができる、又は、この値はブロックチェーンから取得することができる。
【0075】
同様に、各ユーザＵｉは、値ｋをその支払者Ｕｉ－１に直接伝えることができる。Ｕｉが見つからない場合に、ユーザＵｉ－１は（少なくとも時間ｓ内に）ブロックチェーン台帳でこの値を見つけることができる。
【0076】
この出願の提出時においてブロックチェーンがトランザクションを確認するのに平均１０分かかるため、ｓの値は、そのｓの値が表す期間が、ユーザＵｉが必要に応じてその期間内に、トランザクションがビットコイン・ネットワークに送信された後の（支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎの）トランザクションＴｐａｙにおいてｋの値を見つけるのに十分であるように選択する必要がある。ｓの値には、一対のユーザの間の支払チャネルの構築にかかる推定時間も含める必要がある。従って、ｓはｓ＝ｓｋ＋εになるように選択することができ、ここで、ｓｋはｋを見つけてＴｐａｙを送信するための推定時間であり、εは支払チャネルを構築するための推定時間である。
【0077】
開始ユーザＵ０が、Ｕｎ－１とＵ０との間の既存の支払チャネルのＴｐａｙトランザクションをネットワークに送信したため、ｋの値をＵｎ－１に公開すると、次に、ｋの値を（Ｕｎ－１からＵ２への）逆の順序で他の全てのユーザＵｉに公開することができる。これは、各ユーザＵｉが、支払いを受け取ることができるトランザクション（Ｕｉ－１からＵｉへの支払チャネルのＴｐａｙ）を送信する際に権限が与えられる（invested）という前提に基づいている。このトランザクションを送信するユーザＵｉは、（以前に利用可能になっていた）ＵｉからＵｉ＋１への支払チャネルのＴｐａｙからｋの値を取得する必要がある。ＵｉがＵｉ－１からＵｉへの支払チャネルのそのトランザクションＴｐａｙを送信することにより、次に、ｋの値がユーザＵｉ－１に利用可能になる。このプロセスは、Ｕｎ－１からＵ１まで全てをカスケードし（次々に行われ）、換金する（cashing in）各ユーザＵｉがｋをユーザＵｉ－１に明らかに、ユーザＵｉ－１も換金することができるようにする。
【0078】
より形式的には、支払チャネルを実行するＴｐａｙトランザクションの送信シーケンスは次のようになる。
［Ｔｐａｙ：Ｕｎ－１→Ｕ０］，［Ｔｐａｙ：Ｕｎ－２→Ｕｎ－１］，…，［Ｔｐａｙ：Ｕ１→Ｕ２］，［Ｔｐａｙ：Ｕ０→Ｕ１］
［Ｔｐａｙ：Ｕｎ－１→Ｕ０］，［Ｔｐａｙ：Ｕｎ－２→Ｕｎ－１］，…，［Ｔｐａｙ：Ｕ１→Ｕ２］，［Ｔｐａｙ：Ｕ０→Ｕ１］
【0079】
Ｔｐａｙトランザクションのセットが完了すると、ＧＲＥが首尾よく終了する。各ユーザはｘＢＴＣを支払い、各ユーザはｘＢＴＣを受け取る。
【0080】
ＧＲＥインスタンスのためにＴｐａｙ：Ｕｎ－１→Ｕ（ｉ＋１） ｍｏｄ ｎトランザクションを送信するプロセスについて図１２に示す。
【0081】
以下では、一対のユーザの間の支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎで使用されるビットコイン・トランザクションの構築について説明する。これらの支払チャネルは、３つの主要なトランザクションで構成されている。
・２－ｏｆ－２マルチシグネチャ・トランザクションＴＣへの入金：このトランザクションは、支払チャネルのコミットメント・コンポーネントを表し、コミットメント・トランザクションと呼ばれる場合がある。ここで、トランザクションを通じて、ユーザＵｉは指定された数のビットコインｘＢＴＣを送信／コミット（付託）して、次のいずれかによって管理する。
ｏ２－ｏｆ－２マルチシグネチャ（Ｕｉ，Ｕ（ｉ＋１） ｍｏｄ ｎ）、又は
ｏ値ｋの知識及びＵ（ｉ＋１） ｍｏｄ ｎの署名。
・返金トランザクションＴｒ，０：このトランザクションは、指定された時間が経過した後に（コミットメント・トランザクションから）ユーザＵｉに返されるｘＢＴＣの返金を表す。このトランザクションを首尾よく実行するには、ユーザＵｉ及びＵ（ｉ＋１） ｍｏｄ ｎの署名が必要である。
・支払トランザクションＴｐａｙ：このトランザクションは、ＵｉからＵ（ｉ＋１） ｍｏｄ ｎへのｘＢＴＣの支払いである。このトランザクションを首尾よく実行するには、値ｋの知識及びＵ（ｉ＋１） ｍｏｄ ｎの署名が必要である。支払トランザクションは、実行トランザクションとも呼ばれる場合がある。
・２－ｏｆ－２マルチシグネチャ・トランザクションＴＣへの入金：このトランザクションは、支払チャネルのコミットメント・コンポーネントを表し、コミットメント・トランザクションと呼ばれる場合がある。ここで、トランザクションを通じて、ユーザＵｉは指定された数のビットコインｘＢＴＣを送信／コミット（付託）して、次のいずれかによって管理する。
ｏ２－ｏｆ－２マルチシグネチャ（Ｕｉ，Ｕ（ｉ＋１） ｍｏｄ ｎ）、又は
ｏ値ｋの知識及びＵ（ｉ＋１） ｍｏｄ ｎの署名。
・返金トランザクションＴｒ，０：このトランザクションは、指定された時間が経過した後に（コミットメント・トランザクションから）ユーザＵｉに返されるｘＢＴＣの返金を表す。このトランザクションを首尾よく実行するには、ユーザＵｉ及びＵ（ｉ＋１） ｍｏｄ ｎの署名が必要である。
・支払トランザクションＴｐａｙ：このトランザクションは、ＵｉからＵ（ｉ＋１） ｍｏｄ ｎへのｘＢＴＣの支払いである。このトランザクションを首尾よく実行するには、値ｋの知識及びＵ（ｉ＋１） ｍｏｄ ｎの署名が必要である。支払トランザクションは、実行トランザクションとも呼ばれる場合がある。
【0082】
トランザクションの詳細は、＜scriptSig＞、＜scriptPubkey＞、ｎＬｏｃｋＴｉｍｅ、及び様々なトランザクションの出力値に限定されるが、これらは説明しているＧＲＥプロトコルに最も関連しているため、他の関数及び値を使用できることに留意されたい。
【0083】
第２のタイプのグループランダム交換－シークレットの変更
次に、本発明の更なる構成について説明する。
上記の構成のＧＲＥプロトコルの場合に、各支払チャネルに共通の値ｋは、ＧＲＥがそのユーザに提供し得る匿名性のレベルの制限として機能し得る。これは、ｋ及び／又はそのハッシュＨ（ｋ）の共有使用により、外部オブザーバーがＧＲＥの特定のインスタンスに関連するトランザクションのセットを簡単に関連付けることができるためである。これにより、あるアドレスから別のアドレスへのユーザの資金移動を追跡するために必要なオブザーバーの労力が軽減される。
次に、本発明の更なる構成について説明する。
上記の構成のＧＲＥプロトコルの場合に、各支払チャネルに共通の値ｋは、ＧＲＥがそのユーザに提供し得る匿名性のレベルの制限として機能し得る。これは、ｋ及び／又はそのハッシュＨ（ｋ）の共有使用により、外部オブザーバーがＧＲＥの特定のインスタンスに関連するトランザクションのセットを簡単に関連付けることができるためである。これにより、あるアドレスから別のアドレスへのユーザの資金移動を追跡するために必要なオブザーバーの労力が軽減される。
【0084】
同じシークレット値を全ての支払チャネルで使用する上述した構成とは対照的に、以下で説明する構成では、ＧＲＥ交換の際に支払チャネル毎に異なるシークレット値を使用する。さらに、シークレット値はチャネル毎に異なるが、トランザクションがブロックチェーンに送信されたときのシークレット値の公開は、シーケンスの次の支払チャネルでのシークレット値のその後の公開に十分な情報を提供する。
【0085】
この機能を実現するために、この構成では、Ｅ（ｍ）＋Ｅ（ｎ）＝Ｅ（ｍ＋ｎ）のような楕円曲線（ＥＣ）暗号化のプロパティを利用し、ここで、Ｅ（ｘ）＝ｘＧであり、Ｇは楕円曲線上の基点である。ただし、ＥＣ暗号化の代わりに、実質的に類似した準同型の特性を有する他のタイプの暗号化を使用してもよい。
【0086】
楕円曲線は、以下の式によって記述される点のセットである。
ｙ２≡ｘ３＋ａｘ＋ｂ （ｍｏｄ ｐ）
ここで、
であり、ｐは素数である。
ｙ２≡ｘ３＋ａｘ＋ｂ （ｍｏｄ ｐ）
ここで、
【数1】
【0087】
ビットコイン・スクリプト内で必要なＥＣ算術機能は、スカラーによるポイント乗算である。これは次のような演算である。
ここで、ｎは自然数、Ｐは楕円曲線上の点、＋はＥＣ上の点を加算するための演算子である。
【数2】
【0088】
次に、スカラー乗算には、特定のＥＣグループ演算であるポイントの加算とポイントの倍増とが必要である。
・ポイントの加算Ｐ＋Ｑ：この演算では、ＥＣ上の新しい点をこの曲線の交点の否定（negation：交点ではない点）として計算する。これは、Ｒ＝Ｐ＋Ｑと記述することができる。
・ポイントの倍増Ｐ＋Ｐ：ポイントの加算を使用してＰの２倍のポイントを計算することができる。これは、Ｒ＝Ｐ＋Ｐ＝２Ｐと記述することができる。
・ポイントの加算Ｐ＋Ｑ：この演算では、ＥＣ上の新しい点をこの曲線の交点の否定（negation：交点ではない点）として計算する。これは、Ｒ＝Ｐ＋Ｑと記述することができる。
・ポイントの倍増Ｐ＋Ｐ：ポイントの加算を使用してＰの２倍のポイントを計算することができる。これは、Ｒ＝Ｐ＋Ｐ＝２Ｐと記述することができる。
【0089】
より具体的には、ＥＣ上にＰ（ｘ１，ｙ１）とＱ（ｘ２，ｙ２）の２つのポイントが与えられた場合に、
Ｐ＋Ｑ＝（ｘ３，ｙ３）
ここで、
ｘ３＝ｍ２－ｘ１－ｘ２ ｍｏｄ ｐ
ｙ３＝ｍ（ｘ１－ｘ３）－ｙ１ ｍｏｄ ｐであり、そして
Ｐ＋Ｑ＝（ｘ３，ｙ３）
ここで、
ｘ３＝ｍ２－ｘ１－ｘ２ ｍｏｄ ｐ
ｙ３＝ｍ（ｘ１－ｘ３）－ｙ１ ｍｏｄ ｐであり、そして
【数3】
【0090】
上述したように、同じシークレット値を全ての支払チャネルで使用する構成のＧＲＥ回路内の支払チャネル毎の基準として、値ｋ（及びタンデムでのＨ（ｋ））の使用は、匿名性への欲求に関連して、制限であると証明することができる。
【0091】
ユーザがビットコインの移動に関連してＧＲＥ交換での匿名性を望む場合に、Ｕ１がｘＢＴＣを支払うアドレスは、ユーザがｘＢＴＣを受け取るアドレスと異なることが予想される。このアドレス同士の間の切断は、ビットコイン・ブロックチェーン内で支払トランザクション及び受取トランザクションの互いに関連付けを解除することを目的としている。
【0092】
ただし、ＧＲＥプロトコルの知識を有する外部オブザーバーは、あるタイプの基準を含むスクリプトを使用したビットコイン・トランザクションがＧＲＥのインスタンスのアーティファクトであることを知っている。さらに、ｋ及びそのハッシュがこれらのＧＲＥインスタンスのサブセット内で見つかるため、外部オブザーバーは、ＧＲＥの特定のインスタンスに関連する全てのトランザクションを識別できるか、又は可能なトランザクションのセットのサイズを少なくとも大幅に削減できる。成功を保証するわけではないが、これにより、外部のオブザーバーはＧＲＥインスタンスにおけるビットコインの動きを追跡するためにより良い位置に置かれる。
【0093】
この構成では、ＧＲＥプロトコルを使用し、各支払チャネルでは、異なる一意のシークレット値（ｓｖ）と、シークレット値の対応する暗号化バージョンとが使用される。この構成では、ハッシュ関数自体は使用されず、ＥＣ暗号化に置き換えられることに留意されたい。これにより、外部オブザーバーが特定のＧＲＥインスタンスに属するトランザクションのセットを識別する能力が低下する。
【0094】
この構成の異なるシークレット値は、次の条件を満たすことが期待される。
ａ．シークレット値は推測するのが難しいはずである。
ｂ．支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎのＴｐａｙを実行する際にｓｖ（ｉ＋１） ｍｏｄ ｎの公開によって、ＧＲＥシーケンスの次の支払チャネルＵｉ－１→Ｕｉ（反時計回り）のｓｖ１を公開するか、又は少なくとも容易に計算できるようにする必要がある。
ｃ．外部オブザーバーがシークレット鍵（又はシークレット鍵（secret key）暗号化（暗号文））同士の間の関係を特定するのは難しいはずである。
ｄ．交換に参加するユーザは、自分の資金を失うリスクがないはずである。
ａ．シークレット値は推測するのが難しいはずである。
ｂ．支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎのＴｐａｙを実行する際にｓｖ（ｉ＋１） ｍｏｄ ｎの公開によって、ＧＲＥシーケンスの次の支払チャネルＵｉ－１→Ｕｉ（反時計回り）のｓｖ１を公開するか、又は少なくとも容易に計算できるようにする必要がある。
ｃ．外部オブザーバーがシークレット鍵（又はシークレット鍵（secret key）暗号化（暗号文））同士の間の関係を特定するのは難しいはずである。
ｄ．交換に参加するユーザは、自分の資金を失うリスクがないはずである。
【0095】
ハッシュ関数の代替としてＥＣ暗号化を使用して、以前の基準を満たすことができる。ＥＣ暗号化では、スカラー値にＥＣ上の基点Ｇが乗算される。スカラー値ｋはシークレット鍵であり、Ｑ＝ｋＧは暗号化された出力である。Ｑからｋを決定することは、「困難な（hard）」離散対数問題である。
【0096】
さらに、楕円曲線演算の加算演算子の場合に、基点Ｇに対してｍＧ＋ｎＧ＝（ｍ＋ｎ）Ｇである。
【0097】
ＥＣ暗号のこの特性により、条件ｂ．について別のシークレット値が順に明らかになる。
【0098】
ｎ人のユーザ｛Ｕ１｜ｉ∈［０，ｎ－１］｝のグループがＧＲＥプロトコルに参加して、ｘＢＴＣを交換することを考えると、本発明のこの構成のプロトコルは以下のように動作する。
・ユーザは、楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）曲線（例えば、ｓｅｃｐ２５６ｋ１のパラメーター（ｐ，ａ，ｂ，Ｇ，ｎ，ｈ）を定める。
・ユーザは、順序付きセット｛Ｕ０，Ｕ１，…，Ｕｎ－２，Ｕｎ－１｝を実現するためにランダム化される。
・これらのユーザのうちの１人が「開始者」と見なされる。この目的のために、Ｕ０が開始者と見なされる。
・開始者Ｕ０は乱数ｋｓを選択し、ｋｓＧを計算する。ここで、Ｇは楕円曲線上の基点を表す。
・ｋｓの値はＵ０によってプライベートに保持される。
・他の各ユーザＵ１～Ｕｎ－１が、乱数を選択する。Ｕ１がｋ１を選択し、Ｕ２がｋ２を選択し、・・・、Ｕｎ－１がｋｎ－１を選択する。これらの他の各ユーザは、自分が選択した値をＵ０に安全に送信する。Ｕ０は、第２の乱数ｋ０も選択する。
・支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎを構築し、必要なシークレット値を取得し、Ｕ（ｉ＋１） ｍｏｄ ｎに支払いを行う実行トランザクションＴｐａｙをビットコイン・ネットワークに送信するために各Ｕｉに与えられる時間量を表す時間値ｓが選択される。
時間ｓは、秒又はブロック数で表される。
・別の値Ｓが、ビットコイン・ネットワークに送信される、ユーザに対する最初の支払いの開始時間として選択される。ＳはＵｎｉｘ時間又はブロックの高さで指定された時点を表し、ｓは時間範囲を表すことに留意されたい。
・ユーザは、楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）曲線（例えば、ｓｅｃｐ２５６ｋ１のパラメーター（ｐ，ａ，ｂ，Ｇ，ｎ，ｈ）を定める。
・ユーザは、順序付きセット｛Ｕ０，Ｕ１，…，Ｕｎ－２，Ｕｎ－１｝を実現するためにランダム化される。
・これらのユーザのうちの１人が「開始者」と見なされる。この目的のために、Ｕ０が開始者と見なされる。
・開始者Ｕ０は乱数ｋｓを選択し、ｋｓＧを計算する。ここで、Ｇは楕円曲線上の基点を表す。
・ｋｓの値はＵ０によってプライベートに保持される。
・他の各ユーザＵ１～Ｕｎ－１が、乱数を選択する。Ｕ１がｋ１を選択し、Ｕ２がｋ２を選択し、・・・、Ｕｎ－１がｋｎ－１を選択する。これらの他の各ユーザは、自分が選択した値をＵ０に安全に送信する。Ｕ０は、第２の乱数ｋ０も選択する。
・支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎを構築し、必要なシークレット値を取得し、Ｕ（ｉ＋１） ｍｏｄ ｎに支払いを行う実行トランザクションＴｐａｙをビットコイン・ネットワークに送信するために各Ｕｉに与えられる時間量を表す時間値ｓが選択される。
時間ｓは、秒又はブロック数で表される。
・別の値Ｓが、ビットコイン・ネットワークに送信される、ユーザに対する最初の支払いの開始時間として選択される。ＳはＵｎｉｘ時間又はブロックの高さで指定された時点を表し、ｓは時間範囲を表すことに留意されたい。
【0099】
全ての一対のユーザの間に一方向の支払チャネルが確立され、支払いの方向は、ＵｉがＵ（ｉ＋１） ｍｏｄ ｎに支払いを行うような方向である。例として、ｎ＝７と仮定すると、ＧＲＥの支払チャネルは、Ｕ０→Ｕ１，Ｕ１→Ｕ２，…，Ｕ６→Ｕ０で構成される。
【0100】
支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎの作成プロセスを以下で説明し、図１３及び図１４に示す。
・初期コミットメント・トランザクションＴＣにより、＜scriptPubkey＞により、「ＵｉとＵ（ｉ＋１） ｍｏｄ ｎとの両方の署名」又は「ｓｖ（ｉ＋１） ｍｏｄ ｎ及びＵ（ｉ＋１） ｍｏｄ ｎの署名」のいずれかによってのみ使うことができるｘＢＴＣが利用可能になる。
・この目的のために、１つの返金トランザクションのみが必要である。この返金トランザクションＴｒ，０は、全てのｘＢＴＣをＵｉに返す。
・支払チャネルの返金トランザクションＴｒ，０には、ｎＬｏｃｋＴｉｍｅ値Ｓ＋（ｎ－ｉ）ｓが含まれる。
・返金トランザクションＴｒ，０は、初期コミットメント・トランザクションＴＣがビットコイン・ネットワークに送信される前に、Ｕ（ｉ＋１） ｍｏｄ ｎが署名する必要がある。
・支払チャネルには、ＴＣのコミット済みｘＢＴＣからＵ（ｉ＋１） ｍｏｄ ｎにｘＢＴＣを支払う支払トランザクションＴｐａｙが含まれる。
・Ｕ（ｉ＋１） ｍｏｄ ｎへの支払トランザクションＴｐａｙの＜scriptSig＞には、値ｓｖ（ｉ＋１） ｍｏｄ ｎが含まれることが予想される。
・初期コミットメント・トランザクションＴＣにより、＜scriptPubkey＞により、「ＵｉとＵ（ｉ＋１） ｍｏｄ ｎとの両方の署名」又は「ｓｖ（ｉ＋１） ｍｏｄ ｎ及びＵ（ｉ＋１） ｍｏｄ ｎの署名」のいずれかによってのみ使うことができるｘＢＴＣが利用可能になる。
・この目的のために、１つの返金トランザクションのみが必要である。この返金トランザクションＴｒ，０は、全てのｘＢＴＣをＵｉに返す。
・支払チャネルの返金トランザクションＴｒ，０には、ｎＬｏｃｋＴｉｍｅ値Ｓ＋（ｎ－ｉ）ｓが含まれる。
・返金トランザクションＴｒ，０は、初期コミットメント・トランザクションＴＣがビットコイン・ネットワークに送信される前に、Ｕ（ｉ＋１） ｍｏｄ ｎが署名する必要がある。
・支払チャネルには、ＴＣのコミット済みｘＢＴＣからＵ（ｉ＋１） ｍｏｄ ｎにｘＢＴＣを支払う支払トランザクションＴｐａｙが含まれる。
・Ｕ（ｉ＋１） ｍｏｄ ｎへの支払トランザクションＴｐａｙの＜scriptSig＞には、値ｓｖ（ｉ＋１） ｍｏｄ ｎが含まれることが予想される。
【0101】
支払チャネルＵｉ－１→Ｕｉが支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎの前に設定されるため、一対のユーザの間の支払チャネルを規則正しい順序で作成することが重要である。これは、第１の支払チャネルＵ０→Ｕ１の作成から始まり、Ｕ０が開始者であり、最後の支払チャネルＵｎ－１→Ｕ０で終了する。
【0102】
一部の構成では、ユーザＵｉが、支払いを行い、この支払いに関連するリスクを負う前に、ＵｉがＴｐａｙ支払いをＵ（ｉ＋１） ｍｏｄ ｎに行った場合に、Ｕｉに対してＵｉが首尾よく実行できるＴｐａｙトランザクションが存在することを確認できるようにするので、シーケンスの順序が重要である。
【0103】
図１５及び図１６を参照して、この構成で使用されるシークレット値の準備について説明する。
１. ｓｖ０のデフォルト値がｓｖ０＝ｋｓとして設定される。ｋｓは、ユーザのＧＲＥプロトコルリスト内の開始者Ｕ０によって選択されたランダム値であることを思い出されたい。このｋｓ値はプロトコルのセキュリティの中心であり、Ｕ０のみが知っており、全ての支払チャネルが作成されてＵ０の履行が完了するまで秘密にされる。
２. Ｕ０は、楕円曲線の基点Ｇをデフォルトのｓｖ値ｋｓに乗算することにより、そのデフォルトのｓｖ値ｋｓを暗号化する。Ｑｉがｓｖｉ値の暗号化されたバージョンである場合に、デフォルトのｓｖの暗号化されたバージョンはＱ０＝ｓｖ０Ｇ＝ｋｓＧである。
３. 作成された第１の支払チャネルＵ０→Ｕ１では、Ｕ１はその乱数ｋ１をＵ０に伝え、Ｕ０は「暗号化されたバージョンのシークレット鍵」Ｑ０をＵ１に伝える。
４. 作成された支払チャネルＵ０→Ｕ１のｓｖ値は、ｓｖ１＝ｓｖ０＋ｋ１であり、その暗号文は次のとおりである。
Ｑ１＝Ｑ０＋ｋ１Ｇ
ｏ新しいシークレット値（ｋｓ＋ｋ１）は、Ｑ１の計算に存在し、Ｑ１＝ｋｓＧ＋ｋ１Ｇ＝（ｋｓ＋ｋ１）Ｇを与えること、
ｏユーザＵ１はｋｓを知らず、タンデムで（in tandem）トランザクションのシークレット値を有すること、及び
ｏＵ１とＵ０との両方が、Ｑ１の他方の計算を計算及び検証することができることに留意されたい。
５. ステップ３及び４は、ＧＲＥＣＳ回路の他の全ての支払チャネルに一般化することができる。この一般化について以下に説明する。
・Ｕ（ｉ＋１） ｍｏｄ ｎは、乱数ｋ（ｉ＋１） ｍｏｄ ｎをＵｉに伝える。Ｕｉは、暗号化されたバージョンのシークレット鍵ＱｉをＵ（ｉ＋１） ｍｏｄ ｎに伝える。
・作成された支払チャネルのｓｖ値は、ｓｖ（ｉ＋１） ｍｏｄ ｎ＝ｓｖｉ＋ｋ（ｉ＋１） ｍｏｄ ｎになる。その暗号化された値は次のとおりである。
Ｑ（ｉ＋１） ｍｏｄ ｎ＝Ｑｉ＋ｋ（ｉ＋１） ｍｏｄ ｎＧ
・支払チャネルについて、
ｏ新しいシークレット値ｓｖ（ｉ＋１） ｍｏｄ ｎ＝ｋｓ＋ｋ１＋ｋ２＋…＋ｋｉ＋ ｋ（ｉ＋１） ｍｏｄ ｎは、以下で与えられるＱ（ｉ＋１） ｍｏｄ ｎの計算で確認することができること、
ｏユーザＵ（ｉ＋１） ｍｏｄ ｎは、ｋｓ及びｓｖの以前の他の全ての反復が暗号化されているため、トランザクションのシークレット値を知らないこと、及び ｏＵ（ｉ＋１） ｍｏｄ ｎとＵｉとの両方が、Ｑ（ｉ＋１） ｍｏｄ ｎの他方の計算を計算及び検証することができることに留意されたい。
・以前のプロセスは、最終的な支払チャネルＵｎ－１→Ｕ０にも適用されることに留意されたい。こうして、秘密の乱数ｋｓに加えて、Ｕ０は第２の乱数値ｋ０も作成する必要がある。ｋ０は、シークレット値に追加される最終的な値である。最終的なシークレット値には、ｓｖ０ではなくｓｖｆｉｎａｌというラベルが付けられていることに留意されたい。
６. 開始者Ｕ０のみが、自分に支払いを行う支払チャネルを、自分が支払いを行う支払チャネルの前に確立することを優先する必要はない。これは、Ｕ０が、全ての支払チャネルの全てのＴｐａｙトランザクションで必要とされるｋｓの値を知っている唯一の人物であるため、Ｕ０をだますことができないためである。従って、Ｕ０がプロセスを快適に開始するまで（最終的なシークレット値のリリースと一致するまで）、この構成のＧＲＥプロトコルのユーザは引出しを行うことができない。
ｓｖｆｉｎａｌ＝ｋｓ＋ｋ１＋ｋ２＋…＋ｋｎ－１＋ｋ０（ｋｓの値を含む）。
１. ｓｖ０のデフォルト値がｓｖ０＝ｋｓとして設定される。ｋｓは、ユーザのＧＲＥプロトコルリスト内の開始者Ｕ０によって選択されたランダム値であることを思い出されたい。このｋｓ値はプロトコルのセキュリティの中心であり、Ｕ０のみが知っており、全ての支払チャネルが作成されてＵ０の履行が完了するまで秘密にされる。
２. Ｕ０は、楕円曲線の基点Ｇをデフォルトのｓｖ値ｋｓに乗算することにより、そのデフォルトのｓｖ値ｋｓを暗号化する。Ｑｉがｓｖｉ値の暗号化されたバージョンである場合に、デフォルトのｓｖの暗号化されたバージョンはＱ０＝ｓｖ０Ｇ＝ｋｓＧである。
３. 作成された第１の支払チャネルＵ０→Ｕ１では、Ｕ１はその乱数ｋ１をＵ０に伝え、Ｕ０は「暗号化されたバージョンのシークレット鍵」Ｑ０をＵ１に伝える。
４. 作成された支払チャネルＵ０→Ｕ１のｓｖ値は、ｓｖ１＝ｓｖ０＋ｋ１であり、その暗号文は次のとおりである。
Ｑ１＝Ｑ０＋ｋ１Ｇ
ｏ新しいシークレット値（ｋｓ＋ｋ１）は、Ｑ１の計算に存在し、Ｑ１＝ｋｓＧ＋ｋ１Ｇ＝（ｋｓ＋ｋ１）Ｇを与えること、
ｏユーザＵ１はｋｓを知らず、タンデムで（in tandem）トランザクションのシークレット値を有すること、及び
ｏＵ１とＵ０との両方が、Ｑ１の他方の計算を計算及び検証することができることに留意されたい。
５. ステップ３及び４は、ＧＲＥＣＳ回路の他の全ての支払チャネルに一般化することができる。この一般化について以下に説明する。
・Ｕ（ｉ＋１） ｍｏｄ ｎは、乱数ｋ（ｉ＋１） ｍｏｄ ｎをＵｉに伝える。Ｕｉは、暗号化されたバージョンのシークレット鍵ＱｉをＵ（ｉ＋１） ｍｏｄ ｎに伝える。
・作成された支払チャネルのｓｖ値は、ｓｖ（ｉ＋１） ｍｏｄ ｎ＝ｓｖｉ＋ｋ（ｉ＋１） ｍｏｄ ｎになる。その暗号化された値は次のとおりである。
Ｑ（ｉ＋１） ｍｏｄ ｎ＝Ｑｉ＋ｋ（ｉ＋１） ｍｏｄ ｎＧ
・支払チャネルについて、
ｏ新しいシークレット値ｓｖ（ｉ＋１） ｍｏｄ ｎ＝ｋｓ＋ｋ１＋ｋ２＋…＋ｋｉ＋ ｋ（ｉ＋１） ｍｏｄ ｎは、以下で与えられるＱ（ｉ＋１） ｍｏｄ ｎの計算で確認することができること、
【数4】
・以前のプロセスは、最終的な支払チャネルＵｎ－１→Ｕ０にも適用されることに留意されたい。こうして、秘密の乱数ｋｓに加えて、Ｕ０は第２の乱数値ｋ０も作成する必要がある。ｋ０は、シークレット値に追加される最終的な値である。最終的なシークレット値には、ｓｖ０ではなくｓｖｆｉｎａｌというラベルが付けられていることに留意されたい。
６. 開始者Ｕ０のみが、自分に支払いを行う支払チャネルを、自分が支払いを行う支払チャネルの前に確立することを優先する必要はない。これは、Ｕ０が、全ての支払チャネルの全てのＴｐａｙトランザクションで必要とされるｋｓの値を知っている唯一の人物であるため、Ｕ０をだますことができないためである。従って、Ｕ０がプロセスを快適に開始するまで（最終的なシークレット値のリリースと一致するまで）、この構成のＧＲＥプロトコルのユーザは引出しを行うことができない。
ｓｖｆｉｎａｌ＝ｋｓ＋ｋ１＋ｋ２＋…＋ｋｎ－１＋ｋ０（ｋｓの値を含む）。
【0104】
最終的な支払チャネルＵｎ－１→Ｕ０は、時刻Ｓに又はその前に確定する。ユーザを接続する支払チャネルのセットは、図１６に示されるように円として視覚化できる。図１６は、この構成のプロトコルの全てのユーザの間に存在すＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎ支払チャネルの表現を示す。矢印は、支払チャネルとＴｐａｙ支払いの方向とを示す。矢印の外部に隣接する値は、ブロックチェーンによって受け入れられるトランザクションＴｐａｙ：Ｕｉ→Ｕ（ｉ＋１） ｍｏｄ ｎに必要なシークレット値を表す。矢印の内部に隣接する値は、ｓの期間値を表す。Ｑｉ値は、支払チャネルのシークレット値の暗号化された値を表す。
【0105】
円形の配置に照らして、｛Ｕｉ｜ｉ∈［０，ｎ－１］｝の順序がランダムであるという事実は、ユーザＵｉに支払いを行うユーザがランダムであり、Ｕｉが支払いを行うユーザがランダムであることを意味する。同様に、ユーザＵｉに支払いを行うユーザは、Ｕｉが支払いを行うユーザとは異なる。
【0106】
開始者Ｕ０は、既存の支払チャネルＵｎ－１→Ｕ０のトランザクションＴｐａｙを使って、ｓｖｆｉｎａｌ＝ｋｓ＋ｋ１＋ｋ２＋…＋ｋｎ－１＋ｋ０の値を明らかにする。上述したように、値ｋｓ及びｋ０を作成したのはＵ０であり、全てのユーザはｋｉ値をＵ０に送信する必要があった。
【0107】
Ｕ０はｓｖｆｉｎａｌのこの値をＵｎ－１に直接伝えることができる、又は、この値をブロックチェーンから取得することができる。
【0108】
Ｕｎ－１はここでｓｖｆｉｎａｌを知っているが、これは、Ｕｎ－１が支払チャネルＵｎ－２→Ｕｎ－１を介して支払いを受け取るために必要なシークレット値ではない。
ｓｖｆｉｎａｌ＝ｋｓ＋ｋ１＋ｋ２＋…＋ｋｎ－１＋ｋ０、であるが、
ｓｖｎ－１＝ｋｓ ＋ｋ１ ＋ｋ２ ＋…＋ｋｎ－１である。
ｓｖｆｉｎａｌ＝ｋｓ＋ｋ１＋ｋ２＋…＋ｋｎ－１＋ｋ０、であるが、
ｓｖｎ－１＝ｋｓ ＋ｋ１ ＋ｋ２ ＋…＋ｋｎ－１である。
【0109】
しかしながら、Ｕｎ－１はｓｖｆｉｎａｌからｋ０を引くことでｓｖｎ－１を容易に計算し、支払いのためにＴｐａｙトランザクションを送信することができる。Ｕｎ－１は、支払チャネルトランザクションの構築における以前のプロセスからｋ０を知っているだろう。
【0110】
同様に、各ユーザＵ（ｉ＋１） ｍｏｄ ｎは、値ｓｖ（ｉ＋１） ｍｏｄ ｎをその支払人Ｕｉに直接伝えることができる。Ｕ（ｉ＋１） ｍｏｄ ｎが取得できなない場合に、ユーザＵｉは、（少なくとも時間ｓ内に）ブロックチェーン台帳で値ｓｖ（ｉ＋１） ｍｏｄ ｎを取得することができる。
【0111】
ｓｖ（ｉ＋１） ｍｏｄ ｎから、ユーザＵｉは、ｓｖ（ｉ＋１） ｍｏｄ ｎからｋ（ｉ＋１） ｍｏｄ ｎを引くことによりｓｖｉを計算することができる。これにより、Ｔｐａｙ：Ｕｉ－１→Ｕｉを介してＵｉが支払いを受け取ることができる。
【0112】
ブロックチェーンがトランザクションを確認するのに平均１０分かかるため、ｓの値は、そのｓの値が表す期間が、ユーザＵｉが必要に応じてその期間内に、トランザクションがビットコイン・ネットワークに送信された後のトランザクションＴｐａｙ：Ｕｉ→Ｕ（ｉ＋１） ｍｏｄ ｎにおいてｓｖ（ｉ＋１）の値を見つけるのに十分であるように選択する必要がある。トランザクションを確認するための平均時間が変化する場合に、それに応じてｓを選択することができる。
【0113】
ｓの値には、一対のユーザの間の支払チャネルの構築にかかる推定時間も含める必要がある。従って、ｓはｓ＝ｓｓｖ＋εになり、ここで、ｓｓｖはｓｖ（ｉ＋１） ｍｏｄ ｎを見つけてＴｐａｙ：Ｕｉ→Ｕ（ｉ＋１） ｍｏｄ ｎを送信するための推定時間であり、εは支払チャネルを構築するための推定時間である。
【0114】
開始者Ｕ０が、Ｕｎ－１とＵ０との間の既存の支払チャネルのＴｐａｙトランザクションをネットワークに送信したため、ｓｖｆｉｎａｌの値をＵｎ－１に公開すると、次に、ｓｖｉの値を反時計回りの方法（Ｕｎ－１からＵ１へ）で他の全てのユーザＵｉに公開することができる（図１７を参照）。これは、各ユーザＵｉが、支払いを受け取ることができるトランザクション（Ｕｉ－１からＵｉへの支払チャネルのＴｐａｙ）を送信する際に権限が与えられるという前提に基づいている。
【0115】
上記トランザクションを送信するユーザＵｉは、ＵｉからＵ（ｉ＋１） ｍｏｄ ｎへの支払チャネルのＴｐａｙからｓｖ（ｉ＋１） ｍｏｄ ｎの値を取得する必要があり、その値からＵｉがｓｖｉを導出する。ＵｉがＵｉ－１からＵｉへの支払チャネルのそのトランザクションＴｐａｙを送信することにより、次に、ｓｖｉの値がユーザＵｉ－１に利用可能にされ、ユーザＵｉ－１はｓｖｉ－１を導出する。このプロセスは、ドミノがＵｎ－１からＵ１まで全て落ちるようにカスケードし、換金する各ユーザＵｉがｓｖｉ－１をユーザＵｉ－１に明らかにし、ユーザＵｉ－１も換金することができるようにする。
【0116】
より形式的には、支払チャネルの（実行／送信される）Ｔｐａｙトランザクションのシーケンスは次のようになる。
［Ｔｐａｙ：Ｕｎ－１→Ｕ０］，［Ｔｐａｙ：Ｕｎ－２→Ｕｎ－１］，…，［Ｔｐａｙ：Ｕ１→Ｕ２］，［Ｔｐａｙ：Ｕ０→Ｕ１］
［Ｔｐａｙ：Ｕｎ－１→Ｕ０］，［Ｔｐａｙ：Ｕｎ－２→Ｕｎ－１］，…，［Ｔｐａｙ：Ｕ１→Ｕ２］，［Ｔｐａｙ：Ｕ０→Ｕ１］
【0117】
Ｔｐａｙトランザクションのセットが完了すると、プロセスは首尾よく終了する。各ユーザはｘＢＴＣを支払い、各ユーザはｘＢＴＣを受け取る。
【0118】
この構成でのＴｐａｙ：Ｕｉ→Ｕ（ｉ＋１） ｍｏｄ ｎトランザクションを送信するプロセスについて図１８に示す。ここで、ｔは現在の時間であり、ＰＣは支払チャネルであり、Ｕｉ＋１＝Ｕ（ｉ＋１） ｍｏｄ ｎであり、ｂｃはブロックチェーンである。支払チャネルＵｎ－１→Ｕ０の場合に、ｓｖ値の名前はｓｖｆｉｎａｌである。
【0119】
全ての返金トランザクションＴｒ，０のブロックチェーンへの送信は、ｎＬｏｃｋＴｉｍｅ値によって制限される。ｎＬｏｃｋＴｉｍｅパラメーターのこの値は、Ｔｒ，０がその時間に又はそれ以降にブロックチェーンによってのみ受け入れられるような絶対時間値を表す。Ｕｉ→Ｕ（ｉ＋１） ｍｏｄ ｎのｎＬｏｃｋＴｉｍｅ値はＳ＋（ｎ－ｉ）ｓである。
【0120】
ユーザＵｉは、Ｕ（ｉ＋１） ｍｏｄ ｎが、署名し損ない、ｎＬｏｃｋＴｉｍｅ値の前にＱ（ｉ＋１） ｍｏｄ ｎのｓｖ（ｉ＋１） ｍｏｄ ｎを明らかにできない場合に、Ｔｒ，０：Ｕｉ→Ｕ（ｉ＋１） ｍｏｄ ｎを送信する。
【0121】
ＵｉがＴｒ，０：Ｕｉ→Ｕ（ｉ＋１） ｍｏｄ ｎを送信する場合に、これは、支払トランザクションＴｐａｙ：Ｕｉ→Ｕ（ｉ＋１） ｍｏｄ ｎが実行されておらず、これからも決して実行されないことを意味する。これは、ｓｖ（ｉ＋１） ｍｏｄ ｎが公開されないため、Ｕｉ－１がブロックチェーンから支払トランザクションＴｐａｙ：Ｕｉ－１→Ｕｉに必要なｓｖｉを計算することができないことを意味する。
【0122】
Ｕｉ－１は、自分の返金トランザクションＴｒ，０：Ｕｉ－１→Ｕｉを送信する前に、Ｕｉ－１→ＵｉのｎＬｏｃｋＴｉｍｅ値まで又はそれ以降まで待機する必要がある。
【0123】
これらの返金送信プロセスは、Ｔｒ，０：Ｕ０→Ｕ１を送信する開始者Ｕ０までの全てのユーザに対して、反時計回りに繰り返される。これらの各トランザクションは、特定の時点に又はそれ以降でのみ発生し得る。この返金トランザクションのシーケンスの例を図１９に示す。ここで、Ｕ４は署名に失敗し且つｔ＝Ｓ＋４ｓの前にＴｐａｙ：Ｕ３→Ｕ４のｓｖ４の生成に失敗する。返金トランザクションは、反時計回りを指す矢印で表される。支払又は実行トランザクションは、時計回りを指す矢印で表される。
【0124】
返金トランザクションを正確なｎＬｏｃｋＴｉｍｅ値で送信する必要がないことに留意することが重要である。返金トランザクションはその時点又はその後に適用することができる。これは、ＵｉがＵ（ｉ＋１） ｍｏｄ ｎに延長時間ｔｘを与えて、署名し、Ｔｐａｙ：Ｕｉ→Ｕ（ｉ＋１） ｍｏｄ ｎのｓｖ（ｉ＋１） ｍｏｄ ｎを生成することができることを意味する一方で、これは、その結果、Ｕｉが、Ｔｐａｙ：Ｕｉ－１→Ｕｉのｓｖｉを生成するための時間が短くなる（ＵｉがＵｉ－１によって延長時間を与えられていない場合）ことを意味する。図２０を参照されたい。ここでＵ０に延長時間ｔｘが与えられると、Ｕｎ－１がｓｖｎ－１を計算して、Ｔｐａｙ：Ｕｎ－１→Ｕ０のＵ０による遅くなった送信によってＴｐａｙ：Ｕｎ－２→Ｕｎ－１をブロックチェーンに送信する時間が短くなる。
【0125】
以下では、この構成のプロトコルの一対のユーザの間の支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎで利用されるビットコイン・トランザクションの構築について説明する。これらの支払チャネルは、３つの主要なトランザクションで構成される。
・２－ｏｆ－２マルチシグネチャ・トランザクションＴＣへの入金：このトランザクションは、支払チャネルのコミットメント・コンポーネントを表し、コミットメント・トランザクションと呼ばれる場合がある。ここで、トランザクションを通じて、ユーザＵｉは指定された数のビットコインｘＢＴＣを送信／コミットして、次のいずれかで管理する。
ｏ２－ｏｆ－２マルチシグネチャ（Ｕｉ，Ｕ（ｉ＋１） ｍｏｄ ｎ）、又は
ｏ値ｓｖ（ｉ＋１） ｍｏｄ ｎの知識及びＵ（ｉ＋１） ｍｏｄ ｎの署名。
・返金トランザクションＴｒ，０：このトランザクションは、指定された時間が経過した後に（コミットメント・トランザクションから）ユーザＵｉに返されるｘＢＴＣの返金を表し、ユーザＵｉはブロックチェーンへの送信の適格主体となる。このトランザクションを首尾よく実行するには、ユーザＵｉ及びＵ（ｉ＋１） ｍｏｄ ｎの署名が必要である。
・支払トランザクションＴｐａｙ：このトランザクションは、Ｕｉのコミット済み資金からユーザＵ（ｉ＋１） ｍｏｄ ｎへのｘＢＴＣの支払いである。このトランザクションを首尾よく実行するには、シークレット値ｓｖ（ｉ＋１） ｍｏｄ ｎの知識及びユーザＵ（ｉ＋１） ｍｏｄ ｎの署名が必要である。支払トランザクションは、実行トランザクションとも呼ばれる場合がある。
・２－ｏｆ－２マルチシグネチャ・トランザクションＴＣへの入金：このトランザクションは、支払チャネルのコミットメント・コンポーネントを表し、コミットメント・トランザクションと呼ばれる場合がある。ここで、トランザクションを通じて、ユーザＵｉは指定された数のビットコインｘＢＴＣを送信／コミットして、次のいずれかで管理する。
ｏ２－ｏｆ－２マルチシグネチャ（Ｕｉ，Ｕ（ｉ＋１） ｍｏｄ ｎ）、又は
ｏ値ｓｖ（ｉ＋１） ｍｏｄ ｎの知識及びＵ（ｉ＋１） ｍｏｄ ｎの署名。
・返金トランザクションＴｒ，０：このトランザクションは、指定された時間が経過した後に（コミットメント・トランザクションから）ユーザＵｉに返されるｘＢＴＣの返金を表し、ユーザＵｉはブロックチェーンへの送信の適格主体となる。このトランザクションを首尾よく実行するには、ユーザＵｉ及びＵ（ｉ＋１） ｍｏｄ ｎの署名が必要である。
・支払トランザクションＴｐａｙ：このトランザクションは、Ｕｉのコミット済み資金からユーザＵ（ｉ＋１） ｍｏｄ ｎへのｘＢＴＣの支払いである。このトランザクションを首尾よく実行するには、シークレット値ｓｖ（ｉ＋１） ｍｏｄ ｎの知識及びユーザＵ（ｉ＋１） ｍｏｄ ｎの署名が必要である。支払トランザクションは、実行トランザクションとも呼ばれる場合がある。
【0126】
図２１～図２４のトランザクションの詳細は、＜scriptSig＞、＜scriptPubkey＞、ｎＬｏｃｋＴｉｍｅ、及び様々なトランザクションの出力値に限定されるが、これらはこの構成に最も関連するトランザクション要素であることに留意されたい。
【0127】
トランザクションの詳細を図２１～２４に示す。以下に、楕円曲線オペコードの詳細を説明する。
【0128】
この構成では、楕円曲線暗号化を使用する。シークレット値ｋが与えられると、そのＥＣ暗号化された値はＱ＝ｋＧであり、ここで、Ｇは楕円曲線上の基点である。
【0129】
このＥＣ暗号化は、全ての支払チャネルで同じシークレット値を使用する構成のＧＲＥのハッシュ関数に相当する暗号化として機能する。ただし、ＥＣ加算の準同型の特性により、この構成の支払チャネルでｓｖ値の変更が可能になる一方、ｓｖの最終バージョンｓｖｆｉｎａｌの公開から始まるシークレット値のドミノカスケードが可能になる。
【0130】
各支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎについて、コミットメント・トランザクションＴＣには、返金とは別に、暗号化された値Ｑ（ｉ＋１） ｍｏｄ ｎを生成するシークレット値ｓｖ（ｉ＋１） ｍｏｄ ｎが提示された場合にのみ、コミット済み資金を使うことができることを規定する条件が含まれる。このコミット済み資金の非返金支出（non-refund spending）は、支払チャネルのＴｐａｙによって行われる。
Ｑ（ｉ＋１） ｍｏｄ ｎ＝ｓｖ（ｉ＋１） ｍｏｄ ｎＧ
ここで、ｓｖ（ｉ＋１） ｍｏｄ ｎ＝ｋｓ＋ｋ１＋ｋ２ ＋・・・＋ｋｉ＋ｋ（ｉ＋１） ｍｏｄ ｎである。
Ｑ（ｉ＋１） ｍｏｄ ｎ＝ｓｖ（ｉ＋１） ｍｏｄ ｎＧ
ここで、ｓｖ（ｉ＋１） ｍｏｄ ｎ＝ｋｓ＋ｋ１＋ｋ２ ＋・・・＋ｋｉ＋ｋ（ｉ＋１） ｍｏｄ ｎである。
【0131】
ｓｖ（ｉ＋１） ｍｏｄ ｎが正しいかどうかを判断するために、次のＥＣオペコードが使用され、乗算Ｑ＝ｋＧが提供される。このオペコードはＯＰ＿ＥＣＰＭＵＬＴと呼ばれる。ＯＰ＿ＥＣＰＭＵＬＴは、エンコードされた楕円曲線ポイント及び数値を受け取り、スカラーによる楕円曲線乗算を行う。ＯＰ＿ＥＣＰＭＵＬＴは、エンコードされた楕円曲線ポイントとして結果を出力する。
【0132】
支払チャネルＵｉ→Ｕ（ｉ＋１） ｍｏｄ ｎのトランザクションＴＣ、Ｔｒ，０、及びＴｐａｙのスクリプトを図２１～図２４に示す。特に、図２４は、コミットメント・トランザクションＴＣの＜scriptPubKey＞が、上記のオペコードＯＰ＿ＥＣＰＭＵＬＴを使用して、支払トランザクションＴｐａｙの＜scriptSig＞とどの様に結合され、コミット済みｘＢＴＣのロックを解除するかを示している。
【0133】
本発明の構成は、全ての支払チャネルに同じシークレット値又は全ての支払チャネルに異なるシークレット値のいずれかを使用するものとして上述したが、この記述より、シークレット値を変更すること及びシークレット値を変更しないことの組合せを使用するように構成を組み合わせるのは当業者の権限の範囲内である。
【0134】
さらに、電子メール、ファイル転送プロトコル、ピアツーピア共有等の他の通信チャネルを使用して、本発明の任意の構成のユーザが情報を通信することができ、この情報が、シークレット値又はそれに関連する情報、１つ又は複数のトランザクションの詳細、１つ又は複数のトランザクション自体の完全又は不完全なバージョンに関連することができ、且つブロックチェーン以外の通信チャネルが使用される範囲が、本発明の所与の一対のユーザの間に存在する信頼性のレベルに依存し得ることを理解されたい。
【0135】
上記の本発明の構成は、ユーザ同士の間のビットコインの転送のみに言及しているが、ユーザは、代わりに、情報、契約、トークン等のプロトコルを使用して他のリソースを交換できることを理解されたい。トークンは、トークンの制御が資産又はリソースの制御を与えるように、トークンに関連付けられたスマートコントラクトに従って資産又はリソースを表す。スマートコントラクト自体は、ブロックチェーン外に格納することも、１つ以上のトランザクション内に格納することもできる。
【0136】
本明細書において、用語「システム」は、上述したＧＲＥプロトコル、プロトコル自体、及びコンピュータハードウェアに保存されたプロトコルのうちの少なくとも１つの構成のステップを実行するように構成されたコンピュータハードウェア及び／又はソフトウェアのシステムを包含するために使用される。
【0137】
上述した実施形態は、本発明を限定するのではなく例示するものであり、当業者は、添付の特許請求の範囲によって規定される本発明の範囲から逸脱することなく多くの代替実施形態を設計できることに留意されたい。特許請求の範囲において、括弧内に置かれた参照符号は、特許請求の範囲を限定するものとして解釈すべきではない。「備える、有する、含む（comprising, comprises）」等の語は、請求項又は明細書全体に列挙されているもの以外の要素又はステップの存在を排除するものではない。本明細書において、「備える、有する、含む（comprises, comprising）」は「含む、有する（includes, including）」又は「から構成される（consists of, consisting of）」を意味する。要素の単数形の参照は、そのような要素の複数形の参照を除外するものではなく、その逆も同様である。本発明は、いくつかの別個の要素を含むハードウェアによって、及び適切にプログラムされたコンピュータによって実装され得る。いくつかの手段を列挙する装置クレームでは、これらの手段のいくつかは、ハードウェアの同一のアイテムによって具現化され得る。特定の手段が互いに異なる従属請求項に記載されているという単なる事実は、これらの手段の組み合わせが有利に使用できないことを示すものではない。
【0138】
以下に、出願当初の特許請求の範囲の内容を実施例として記載しておく。
［実施例１］
ブロックチェーン上の複数のユーザの間でトランザクション・ミキシングを行うためのシステムであって、当該システムは、
（ｉ）リソースの制御を第１のユーザの送信元アドレスから第２のユーザの受信アドレスに送信するように構成された第１のコミットメント・トランザクションを準備するステップと、
（ｉｉ）リソースの制御を前記第２のユーザの送信元アドレスから別のユーザの受信アドレスに送信するように構成された第２のコミットメント・トランザクションを準備するステップと、
（ｉｉｉ）リソースの制御を前記別のユーザの送信元アドレスから
（ａ）前記第１のユーザの受信アドレス、又は
（ｂ）さらに別のユーザの受信アドレス次のいずれかに送信するように構成された更なるコミットメント・トランザクションを準備するステップであって、トランザクション・チェーンを完了するためにオプション（ａ）が実行されるまでステップ（ｉｉｉ）を繰り返す、ステップと、
（ｉｖ）前記トランザクション・チェーンを実行するステップと、を実施するように構成されており、
前記ユーザのうちの少なくとも１人が前記複数のユーザからランダムに選択される、
システム。
［実施例２］
少なくとも１つのコミットメント・トランザクションが、少なくとも１つの前記コミットメント・トランザクションの実行条件を満たすことに応答して、それぞれのリソースの制御を送信するように構成される、実施例１に記載のシステム。
［実施例３］
それぞれの実行条件を満たすように構成された少なくとも１つの実行トランザクションを準備するステップを実行するようにさらに構成される、実施例２に記載のシステム。
［実施例４］
少なくとも１つの前記コミットメント・トランザクションの実行条件には、それぞれのシークレット値の供給が含まれる、実施例２又は３に記載のシステム。
［実施例５］
少なくとも１つのシークレット値が前記第１のユーザによって選択され、少なくとも１つの実行条件には前記選択されたシークレット値の供給が含まれる、実施例４に記載のシステム。
［実施例６］
少なくとも１つのシークレット値が、（ｉ）前記選択されたシークレット値の供給、及び（ｉｉ）少なくとも１つの他のシークレット値の供給の少なくとも１つに応答して計算可能である、実施例５に記載のシステム。
［実施例７］
少なくとも１つのコミットメント・トランザクションが、返還条件が満たされると、それぞれのリソースの制御をそれぞれのユーザに戻すように構成される、実施例１乃至６のいずれか一項に記載のシステム。
［実施例８］
ロック時間（LcokTime）を含む少なくとも１つの返還トランザクションを準備するステップを実行するようにさらに構成され、前記少なくとも１つの返還トランザクションは、前記ロック時間の満了時に少なくとも１つのそれぞれの返還条件を満たすように構成される、実施例７に記載のシステム。
［実施例９］
少なくとも１つの準備されたトランザクションをブロックチェーンに送信するようにさらに構成される、実施例１乃至８のいずれか一項に記載のシステム。
［実施例１０］
前記トランザクション・チェーンが準備された順序と逆の順序で前記トランザクション・チェーンを実行するようにさらに構成される、実施例１乃至９のいずれか一項に記載のシステム。
［実施例１１］
前記リソースが互いに同一である、実施例１乃至１０のいずれか一項に記載のシステム。
［実施例１］
ブロックチェーン上の複数のユーザの間でトランザクション・ミキシングを行うためのシステムであって、当該システムは、
（ｉ）リソースの制御を第１のユーザの送信元アドレスから第２のユーザの受信アドレスに送信するように構成された第１のコミットメント・トランザクションを準備するステップと、
（ｉｉ）リソースの制御を前記第２のユーザの送信元アドレスから別のユーザの受信アドレスに送信するように構成された第２のコミットメント・トランザクションを準備するステップと、
（ｉｉｉ）リソースの制御を前記別のユーザの送信元アドレスから
（ａ）前記第１のユーザの受信アドレス、又は
（ｂ）さらに別のユーザの受信アドレス次のいずれかに送信するように構成された更なるコミットメント・トランザクションを準備するステップであって、トランザクション・チェーンを完了するためにオプション（ａ）が実行されるまでステップ（ｉｉｉ）を繰り返す、ステップと、
（ｉｖ）前記トランザクション・チェーンを実行するステップと、を実施するように構成されており、
前記ユーザのうちの少なくとも１人が前記複数のユーザからランダムに選択される、
システム。
［実施例２］
少なくとも１つのコミットメント・トランザクションが、少なくとも１つの前記コミットメント・トランザクションの実行条件を満たすことに応答して、それぞれのリソースの制御を送信するように構成される、実施例１に記載のシステム。
［実施例３］
それぞれの実行条件を満たすように構成された少なくとも１つの実行トランザクションを準備するステップを実行するようにさらに構成される、実施例２に記載のシステム。
［実施例４］
少なくとも１つの前記コミットメント・トランザクションの実行条件には、それぞれのシークレット値の供給が含まれる、実施例２又は３に記載のシステム。
［実施例５］
少なくとも１つのシークレット値が前記第１のユーザによって選択され、少なくとも１つの実行条件には前記選択されたシークレット値の供給が含まれる、実施例４に記載のシステム。
［実施例６］
少なくとも１つのシークレット値が、（ｉ）前記選択されたシークレット値の供給、及び（ｉｉ）少なくとも１つの他のシークレット値の供給の少なくとも１つに応答して計算可能である、実施例５に記載のシステム。
［実施例７］
少なくとも１つのコミットメント・トランザクションが、返還条件が満たされると、それぞれのリソースの制御をそれぞれのユーザに戻すように構成される、実施例１乃至６のいずれか一項に記載のシステム。
［実施例８］
ロック時間（LcokTime）を含む少なくとも１つの返還トランザクションを準備するステップを実行するようにさらに構成され、前記少なくとも１つの返還トランザクションは、前記ロック時間の満了時に少なくとも１つのそれぞれの返還条件を満たすように構成される、実施例７に記載のシステム。
［実施例９］
少なくとも１つの準備されたトランザクションをブロックチェーンに送信するようにさらに構成される、実施例１乃至８のいずれか一項に記載のシステム。
［実施例１０］
前記トランザクション・チェーンが準備された順序と逆の順序で前記トランザクション・チェーンを実行するようにさらに構成される、実施例１乃至９のいずれか一項に記載のシステム。
［実施例１１］
前記リソースが互いに同一である、実施例１乃至１０のいずれか一項に記載のシステム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【外国語明細書】