JP7846693B2 - マルチ署名トランザクション - Google Patents

Description

本開示は、マルチ署名ロック解除要件を有する入力を伴うブロックチェーントランザクションに関する。

ブロックチェーンは、分散データ構造の形式を指し、ブロックチェーンの複製コピーが分散ピアツーピア(P2P)ネットワーク(以下では、「ブロックチェーンネットワーク」と呼ばれる)内の複数のノードの各々において維持され、広く宣伝される。ブロックチェーンはデータのブロックのチェーンを備え、各ブロックは1つまたは複数のトランザクションを備える。いわゆる「コインベーストランザクション」以外の各トランザクションは、1つまたは複数のコインベーストランザクションに戻る1つまたは複数のブロックにまたがり得るシーケンス内の先行するトランザクションを指す。コインベーストランザクションについては、以下でさらに説明する。ブロックチェーンネットワークに提出されるトランザクションは、新しいブロックに含まれる。新しいブロックは、多くの場合「マイニング(mining)」と呼ばれるプロセスによって作成され、このプロセスは、複数のノードの各々が「プルーフオブワーク(proof-of-work)」を実施するために競合すること、すなわち、ブロックチェーンの新しいブロックに含まれることを待っている、順序付けされ検証された保留中のトランザクションの定義されたセットの表現に基づいて暗号パズルを解くことを含む。ブロックチェーンはいくつかのノードにおいて取り除かれる可能性があり、ブロックの公開は単なるブロックヘッダの公開を通じて実現できる点に留意されたい。

ブロックチェーン内のトランザクションは、デジタル資産(すなわち、多数のデジタルトークン)を伝達するため、仮想化された台帳またはレジストリ内のエントリのセットを順序付けるため、タイムスタンプエントリを受信して処理するため、および/またはインデックスポインタを時間順にするための目的のうちの1つまたは複数のために使用され得る。ブロックチェーンはまた、ブロックチェーンの上に追加の機能を重ねるために利用することができる。たとえば、ブロックチェーンプロトコルは、追加のユーザデータまたはトランザクション内のデータのインデックスを記憶できる場合がある。単一のトランザクション内に記憶できる最大データ容量には事前に指定された制限がなく、したがって、ますます複雑なデータを組み込むことができる。たとえば、これは電子ドキュメントをブロックチェーンに記憶すること、あるいはオーディオデータまたはビデオデータを記憶することを行うために使用され得る。

ブロックチェーンネットワークのノード(「マイナ」と呼ばれることが多い)は、分散トランザクションの登録および検証プロセスを実施し、これについては後で詳しく説明する。要約すると、このプロセス中に、ノードはトランザクションを検証し、有効なプルーフオブワーク解を識別しようとするブロックテンプレートにトランザクションを挿入する。有効な解が見つかると、新しいブロックがネットワークの他のノードに伝搬され、したがって、各ノードが新しいブロックをブロックチェーンに記録できるようになる。トランザクションをブロックチェーンに記録するために、ユーザ(ブロックチェーンクライアントアプリケーションなど)が、伝搬させるためにトランザクションをネットワークのノードのうちの1つに送信する。トランザクションを受信するノードは、検証されたトランザクションを新しいブロックに組み込むプルーフオブワーク解を見つけるために競合する可能性がある。各ノードは、トランザクションを有効にするための1つまたは複数の条件を含む同じノードプロトコルを強制するように構成されている。無効なトランザクションは伝搬されず、ブロックに組み込まれない。トランザクションが検証され、それによってブロックチェーン上で受け入れられると仮定すると、トランザクション(ユーザデータを含む)は、不変の公開記録としてブロックチェーンネットワーク内のノードの各々において登録され、インデックス付けされたままになる。

最新のブロックを作成するためにプルーフオブワークパズルを解決したノードは通常、ある額のデジタル資産、すなわち多数のトークンを分散する「コインベーストランザクション」と呼ばれる新しいトランザクションで報酬を与えられる。無効なトランザクションの検出と拒否は、ネットワークのエージェントとして機能する競合ノードのアクションによって強制され、不正行為を報告してブロックするよう促される。情報が広範に公開されるため、ユーザはノードのパフォーマンスを継続的に監査できるようになる。単なるブロックヘッダを公開することにより、参加者はブロックチェーンの継続的な整合性を確保できるようになる。

「出力ベース」モデル(UTXOベースのモデルとも呼ばれる)では、所与のトランザクションのデータ構造は1つまたは複数の入力と1つまたは複数の出力を備える。使用可能な出力は、トランザクションの進行シーケンスから導き出されるデジタル資産の額を指定する要素を備える。使用可能出力は、UTXO(「未使用トランザクション出力(unspent transaction output)」)と呼ばれることもある。出力は、将来の出力の引換えのための条件を指定するロックスクリプトをさらに備え得る。ロックスクリプトは、デジタルトークンまたは資産を検証および転送するために必要な条件を定義する述語である。トランザクション(コインベーストランザクション以外)の各入力は、先行するトランザクションにおけるそのような出力へのポインタ(すなわち、参照)を備え、さらに、示された出力のロックスクリプトのロックを解除するためのロック解除スクリプトを備え得る。したがって、トランザクションのペアを考えると、それらを第1のトランザクションおよび第2のトランザクション(または「ターゲット」トランザクション)と呼ぶ。第1のトランザクションは、デジタル資産の額を指定する少なくとも1つの出力を備え、出力のロックを解除する1つまたは複数の条件を定義するロックスクリプトを備える。第2のターゲットトランザクションは、第1のトランザクションの出力へのポインタを備える少なくとも1つの入力と、第1のトランザクションの出力のロックを解除するためのロック解除スクリプトとを備える。

そのようなモデルでは、第2のターゲットトランザクションが、ブロックチェーンに伝搬および記録されるためにブロックチェーンネットワークに送信されるとき、各ノードに適用される有効性の基準のうちの1つは、ロック解除スクリプトが、第1のトランザクションのロックスクリプトにおいて定義された1つまたは複数の条件をすべて満たすことである。もう1つは、第1のトランザクションの出力が別の以前の有効なトランザクションによってまだ償還されていないことである。これらの条件のいずれかに従ってターゲットトランザクションが無効であると判断したノードは、そのトランザクションを(有効なトランザクションとして、ただし無効なトランザクションを登録するために)伝搬したり、ブロックチェーンに記録するために新しいブロックに含めたりすることはない。

「Transaction Signature Flags」と題する英国特許出願

別のタイプのトランザクションモデルは、アカウントベースのモデルである。この場合、各トランザクションは、過去のトランザクションのシーケンスにおける前のトランザクションのUTXOを参照することによってではなく、絶対的なアカウント残高を参照することによって送金される金額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別のノードによって記憶され、常に更新される。

ブロックチェーントランザクションでは、署名は、使用される資金の所有権または正当な管理の証拠を提供することと、支出を承認することと、トランザクション情報の完全性を保証することとの3つの目的を果たす。第3の機能は、署名を無効にすることなくトランザクションの特定の詳細を変更できないことを保証する。たとえば、出力に署名すると、ネットワークにブロードキャストされたトランザクションを傍受して、資金が割り当てられるアドレスを修正することが誰もできなくなることを保証する。

特定の出力ベースのトランザクションモデルでは、通常、トランザクションに署名する際、署名者は、トランザクションにおいて定義されたすべての入力および出力に適用される署名を作成する。しかしながら、署名を作成する際に別のタグ(sighashフラグとして知られている)を使用することによって、トランザクションの特定の要素にのみ適用される、または「承認(endorse)」されるように、署名を固有のものにすることができる。

複数の当事者が単一のトランザクションに対して共同作業する状況では、従来のsighash ALL署名手法は、署名が続行可能になる前に、トランザクションの詳細を確立するために当事者間の初期通信を必要とする。これは非効率的な場合があり、多くの場合、当事者間の関係を正確に反映しない相互依存関係が生じる。対照的に、異なるsighashフラグを組み合わせると、当事者にトランザクションの様々な部分に独立して署名できる柔軟性を提供することができる。

そのような柔軟性は、トランザクションが少なくとも1つのマルチ署名の支出要件を有する場合に必要になる場合がある。UTXOの複数の所有者は、前記UTXOの支出を承認する必要があり、使用済みのUTXOはそれらの所有者または他の当事者の間の個人に分配される。場合によっては、マルチ署名要件に署名を提供する必要がある人は、各当事者に送金される正確な金額を承認する必要もない。標準のsighash ALL署名モデルの使用は、このモデルでは、署名が提供される前にすべての入力と出力が知られている必要があるため、そのような階層的な支出構造には適していない。したがって、マルチ署名支出要件を備えたUTXOに関連付けられるポリシに基づいて、送金を承認する必要がない、または送金を承認することが承認されていない当事者でも、ブロックチェーンを介した送金を承認する必要がある。これにより、たとえば、ポリシに基づいて支払いを拒否できない当事者が、署名を提供しないことによって支払いを阻止する可能性がある。

本明細書に開示される一態様によれば、ブロックチェーンのマルチ署名トランザクションを生成するためのコンピュータ実装方法が提供され、本方法は、マルチ署名トランザクションの第1の入力-出力ペアの第1の出力、および第1の入力の非署名部分を受信するステップであって、第1の入力が、マルチ署名要件をエンコードする第1の使用可能トランザクション出力へのアウトポイントを備える、ステップと、マルチ署名要件の公開鍵に対応する秘密鍵を使用して、第1の入力-出力ペアの第1の出力、および第1の入力の非署名部分に電子署名するが、マルチ署名トランザクションの任意の他の出力には電子署名せず、それによって、(i)関連付けられるsighash単一フラグ、および(ii)マルチ署名要件に関して有効な少なくとも1つの他の署名が第1の入力の署名部分に含まれる場合に、マルチ署名要件を満たすための署名を生成するステップと、マルチ署名トランザクションの第2の入力-出力ペアの第2の出力、および第2の入力の非署名部分を受信するステップであって、第2の入力が、少なくとも1つの署名を必要とする署名要件をエンコードする第2の使用可能トランザクション出力へのアウトポイントを備える、ステップと、署名要件の公開鍵に対応する秘密鍵を使用して、マルチ署名トランザクションの第2の入力-出力ペアの第2の出力、および第2の入力の非署名部分には電子署名するが、マルチ署名トランザクションの任意の他の出力には電子署名せず、それによって、関連付けられるsighash単一フラグが第2の入力の署名部分に含まれる場合に、署名要件を少なくとも部分的に満たすための署名を生成するステップとを備える。

本開示の実施形態の理解を助け、そのような実施形態がどのように実施されるかを示すために、単なる例として添付の図面が参照される。

ブロックチェーンを実装するためのシステムの概略ブロック図である。 ブロックチェーンに記録され得るトランザクションのいくつかの例を概略的に示す図である。 クライアントアプリケーションの概略ブロック図である。 図3Aのクライアントアプリケーションによって提示され得る例示的なユーザインターフェースの概略的なモックアップを示す図である。 トランザクションを処理するためのいくつかのノードソフトウェアの概略ブロック図である。 2人の署名当事者を有する例示的なマルチ署名トランザクションを示す図である。 3人の署名当事者を有する例示的なマルチ署名トランザクションを示す図である。 マルチ署名トランザクションを生成する例示的な方法を示す図である。 マルチ署名トランザクションを生成する複数のユーザデバイスの概略図である。

例示的なシステムの概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を示している。システム100は、パケット交換ネットワーク101、通常はインターネットなどの広域インターネットワークを備え得る。パケット交換ネットワーク101は、パケット交換ネットワーク101内にピアツーピア(P2P)ネットワーク106を形成するように配置され得る複数のブロックチェーンノード104を備える。図示されていないが、ブロックチェーンノード104は、ほぼ完全なグラフとして配置され得る。したがって、各ブロックチェーンノード104は、他のブロックチェーンノード104と高度に接続されている。

各ブロックチェーンノード104は、ピアのコンピュータ機器を備え、ノード104のうちの異なるノードは異なるピアに属する。各ブロックチェーンノード104は、1つまたは複数のプロセッサ、たとえば、1つまたは複数の中央処理装置(CPU)、アクセラレータプロセッサ、特定用途向けプロセッサおよび/またはフィールドプログラマブルゲートアレイ(FPGA)と、特定用途向け集積回路(ASIC)などのその他の機器とを備える処理装置を備える。各ノードはまた、メモリ、すなわち非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を使用する1つまたは複数のメモリユニットを備え得る。

ブロックチェーン150は、データブロック151のチェーンを備え、ブロックチェーン150のそれぞれのコピーが、分散またはブロックチェーンネットワーク106内の複数のブロックチェーンノード104の各々に維持される。上述したように、ブロックチェーン150のコピーを維持することは、必ずしもブロックチェーン150を完全に記憶することを意味するわけではない。代わりに、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(後述)を記憶する限り、ブロックチェーン150からデータを取り除くことができる。チェーン内の各ブロック151は、1つまたは複数のトランザクション152を備え、この文脈におけるトランザクションは、ある種のデータ構造を指す。データ構造の性質は、トランザクションモデルまたは方式の一部として使用されるトランザクションプロトコルのタイプによって異なる。所与のブロックチェーンは、全体を通じて1つの特定のトランザクションプロトコルを使用する。1つの一般的なタイプのトランザクションプロトコルでは、各トランザクション152のデータ構造は、少なくとも1つの入力と少なくとも1つの出力を備える。各出力は、資産としてデジタル資産の数量を表す金額を指定し、その例としては、出力が暗号的にロックされているユーザ103がある(ロックを解除し、それによって償還または使用するためには、そのユーザの署名または他の解が必要である)。各入力は、先行するトランザクション152の出力を指し、それによってトランザクションがリンクされる。

各ブロック151は、ブロック151への連続的な順序を定義するために、チェーン内で以前に作成されたブロック151を指すブロックポインタ155も備える。各トランザクション152(コインベーストランザクション以外)は、トランザクションのシーケンスへの順序を定義するために、前のトランザクションへ戻るポインタを備える(注意:トランザクション152のシーケンスは分岐することができる)。ブロック151のチェーンは、チェーン内の第1のブロックであったジェネシスブロック(Gb)153まで遡る。チェーン150内の初期の1つまたは複数の元のトランザクション152は、先行するトランザクションではなくジェネシスブロック153を指していた。

ブロックチェーンノード104の各々は、トランザクション152を他のブロックチェーンノード104に転送し、それによってトランザクション152がネットワーク106全体に伝搬されるように構成されている。各ブロックチェーンノード104は、ブロック151を作成し、同じブロックチェーン150のそれぞれのコピーをそれぞれのメモリに記憶するように構成されている。各ブロックチェーンノード104もまた、ブロック151に組み込まれるのを待っているトランザクション152の順序付きセット(または「プール」)154を維持する。順序付きプール154は、「メモリプール(mempool)」と呼ばれることが多い。本明細書におけるこの用語は、任意の特定のブロックチェーン、プロトコル、またはモデルに限定することを意図したものではない。それは、ノード104が有効なものとして受け入れ、ノード104が同じ出力を使用しようとする任意の他のトランザクションを受け入れない義務があるトランザクションの順序付きセットを指す。

所与の現在のトランザクション152jにおいて、入力(または、各入力)は、トランザクションのシーケンスにおける先行するトランザクション152iの出力を参照するポインタを備え、この出力が、現在のトランザクション152jにおいて償還または「使用(spent)」されるべきであることを指定する。一般に、先行するトランザクションは、順序付きセット154内の任意のトランザクションまたは任意のブロック151である可能性がある。先行するトランザクション152iは、現在のトランザクションが有効となるために、存在し、検証される必要があるが、先行するトランザクション152iが現在のトランザクション152jが作成される時点、またはネットワーク106に送信される時点でさえも、必ずしも存在する必要はない。したがって、本明細書における「先行する(preceding)」は、ポインタによってリンクされた論理シーケンスにおける先行するもの(predecessor)を指し、必ずしも時系列における作成または送信の時間を指すものではなく、したがって、トランザクション152i、152jが順不同に作成または送信されることを必ずしも排除するものではない(オーファントランザクションに関する以下の説明を参照)。先行するトランザクション152iは、先のトランザクション(antecedent transaction)または先行したトランザクション(predecessor transaction)と同様に呼ぶことができる。

現在のトランザクション152jの入力はまた、入力権限、たとえば、先行するトランザクション152iの出力がロックされているユーザ103aの署名を備える。次に、現在のトランザクション152jの出力は、新しいユーザまたはエンティティ103bに暗号的にロックされ得る。したがって、現在のトランザクション152jは、先行するトランザクション152iの入力において定義された額を、現在のトランザクション152jの出力において定義されたように、新しいユーザまたはエンティティ103bに転送することができる。場合によっては、トランザクション152は、複数のユーザまたはエンティティ(残り(change)を与えるために、そのうちの1人が元のユーザまたはエンティティ103aであり得る)間で入力額を分割するための複数の出力を有し得る。場合によっては、トランザクションはまた、1つまたは複数の先行するトランザクションの複数の出力からの額をまとめ、現在のトランザクションの1つまたは複数の出力に再分配するために複数の入力を有することができる。

ビットコインのような出力ベースのトランザクションプロトコルによれば、個人ユーザまたは組織などの当事者103が、(手動で、または当事者が採用する自動プロセスによって)新しいトランザクション152jを制定したい場合、制定当事者は、そのコンピュータ端末102から受信者に新しいトランザクションを送信する。制定当事者または受信者は、最終的にこのトランザクションをネットワーク106の1つまたは複数のブロックチェーンノード104(今日では、典型的にはサーバまたはデータセンタであるが、原則として他のユーザ端末でもよい)に送信することになる。また、新しいトランザクション152jを制定する当事者103が、トランザクションをブロックチェーンノード104のうちの1つまたは複数に直接送信し、場合によっては受信者に送信しない可能性も排除されない。トランザクションを受信するブロックチェーンノード104は、ブロックチェーンノード104の各々において適用されるブロックチェーンノードプロトコルに従って、トランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、通常、新しいトランザクション152j内の暗号署名が、順序付けられたトランザクション152のシーケンス内で前のトランザクション152iに依存する、予想される署名と一致することをチェックすることをブロックチェーンノード104に要求する。そのような出力ベースのトランザクションプロトコルでは、これは、新しいトランザクション152jの入力に含まれる当事者103の暗号署名または他の許可が、新しいトランザクションが割り当てる先行するトランザクション152iの出力において定義された条件と一致することをチェックすることを備えてよく、この条件は通常、新しいトランザクション152jの入力における暗号署名または他の認可が、新しいトランザクションの入力がリンクされている前のトランザクション152iの出力のロックを解除することをチェックすることを少なくとも備える。条件は、先行するトランザクション152iの出力に含まれるスクリプトによって少なくとも部分的に定義され得る。あるいは、ブロックチェーンノードプロトコルだけによって単純に固定されてもよく、これらの組合せによるものであってもよい。いずれにしても、新しいトランザクション152jが有効である場合、ブロックチェーンノード104は、それをブロックチェーンネットワーク106内の1つまたは複数の他のブロックチェーンノード104に転送する。これらの他のブロックチェーンノード104は、同じブロックチェーンノードプロトコルに従って同じテストを適用し、したがって、新しいトランザクション152jを1つまたは複数のさらなるノード104に転送し、以下同様である。このようにして、新しいトランザクションはブロックチェーンノード104のネットワーク全体に伝搬される。

出力ベースのモデルでは、所与の出力(たとえば、UTXO)が割り当てられているか(たとえば、使用されているか)の定義は、ブロックチェーンノードプロトコルに従って、その出力が別の後続のトランザクション152jの入力によってまだ有効に償還されているかどうかである。トランザクションが有効であるための別の条件は、償還しようと試みる先行するトランザクション152iの出力が別のトランザクションによってまだ償還されていないことである。同様に、有効でない場合、トランザクション152jは(無効としてフラグが立てられ、警告のために伝搬されない限り)ブロックチェーン150に伝搬も記録もされない。これは、取引者が同じトランザクションの出力を複数回割り当てようとする二重支出を防止する。一方、アカウントベースのモデルは、アカウント残高を維持することによって二重支出を防止する。ここでも、トランザクション順序が定義されているため、アカウント残高は常に単一の定義された状態にある。

トランザクションの検証に加えて、ブロックチェーンノード104はまた、「プルーフオブワーク」によってサポートされる、一般にマイニングと呼ばれるプロセスにおいてトランザクションのブロックを最初に作成しようと競合する。ブロックチェーンノード104において、新しいトランザクションが、ブロックチェーン150上に記録されたブロック151にまだ現れていない有効なトランザクションの順序付きプール154に追加される。次いで、ブロックチェーンノードは、暗号パズルを解くことを試みることによって、順序付けられたトランザクションのセット154からトランザクション152の新しい有効なブロック151を組み立てようと競合する。通常、これは、ノンスが保留中のトランザクション154の順序付きプールの表現と連結されハッシュされたときに、ハッシュの出力があらかじめ定められた条件を満たすような「ノンス」値を検索することを備える。たとえば、あらかじめ定められた条件は、ハッシュの出力があらかじめ定義された数の先行ゼロを有することであってもよい。これは、プルーフオブワークパズルの特定のタイプの1つにすぎず、他のタイプが除外されるわけではない点に留意されたい。ハッシュ関数の特性は、その入力に対して予測不可能な出力を有することである。したがって、この検索は総当りしか実施することができず、したがって、パズルを解こうとしている各ブロックチェーンノード104においてかなりの量の処理リソースを消費する。

最初にパズルを解いたブロックチェーンノード104は、これをネットワーク106に公表し、その解を、ネットワーク内の他のブロックチェーンノード104によって容易にチェックできるプルーフとして提供する。(ハッシュに対する解が与えられると、それによってハッシュの出力が条件を満たすかどうかをチェックするのは簡単である)。第1のブロックチェーンノード104は、ブロックを受け入れてプロトコルルールを強制する他のノードのしきい値コンセンサスまでブロックを伝搬する。次いで、トランザクションの順序付きセット154は、ブロックチェーンノード104の各々によって、ブロックチェーン150内に新しいブロック151として記録されるようになる。ブロックポインタ155も、チェーン内で以前に作成されたブロック151n-1を指す新しいブロック151nに割り当てられる。プルーフオブワーク解を作成するために必要な、たとえばハッシュの形態のかなりの量の労力は、ブロックチェーンプロトコルの規則に従うという第1のノード104の意図を信号で伝える。そのようなルールは、以前に検証されたトランザクションと同じ出力が割り当てられている場合、トランザクションを有効なものとして受け入れないことを含み、これは二重支出とも呼ばれる。ブロック151は、一度作成されると、ブロックチェーンネットワーク106内のブロックチェーンノード104の各々において認識され維持されるため、修正することができない。また、ブロックポインタ155は、ブロック151に連続的な順序を課す。トランザクション152は、ネットワーク106内の各ブロックチェーンノード104の順序付けされたブロックに記録されるため、これは、トランザクションの不変の公開台帳を提供する。

パズルを解決するために常に競合している異なるブロックチェーンノード104は、それらがいつ解の検索を開始したか、またはトランザクションが受信された順序に応じて、常に未公開トランザクションのプール154の異なるスナップショットに基づいて実施している可能性がある点に留意されたい。誰がそれぞれのパズルを最初に解いても、どのトランザクション152が次の新しいブロック151nにどのような順序で含まれるかを最初に定義し、未公開トランザクションの現在のプール154が更新される。次いで、ブロックチェーンノード104は、新たに定義された未公開トランザクション154の順序付きプールからブロックを作成するために競合を続け、以下同様である。発生する可能性のある任意の「フォーク(fork)」を解決するためのプロトコルも存在し、フォークとは、2つのブロックチェーンノード104が互いに非常に短い時間内にパズルを解決し、ブロックチェーンの矛盾するビューがノード104間で伝搬されるようにするものである。つまり、最も長く成長するフォークの分岐が、最終的なブロックチェーン150になる。同じトランザクションが両方のフォークに現れるため、これはネットワークのユーザまたはエージェントに影響を与えないはずである点に留意されたい。

ビットコインブロックチェーン(および、他のほとんどのブロックチェーン)によると、(あるエージェントまたはユーザから別のエージェントまたはユーザにある額のデジタル資産を転送するエージェント間またはユーザ間のトランザクションとは対照的に)新しいブロック104の構築に成功したノードには、追加の規定額のデジタル資産を分散する新しい特別な種類のトランザクションにおいて、追加の受入れ額のデジタル資産を新たに割り当てる能力が与えられる。この特別なタイプのトランザクションは通常「コインベーストランザクション」と呼ばれるが、「開始トランザクション」または「生成トランザクション」と呼ばれることもある。これは通常、新しいブロック151nの第1のトランザクションを形成する。プルーフオブワークは、新しいブロックを構築するノードがプロトコルルールに従う意図を通知し、この特別なトランザクションを後で償還できるようにする。ブロックチェーンプロトコルのルールは、この特別なトランザクションが償還され得る前に、たとえば100ブロックなどの満期期間が必要とする場合がある。多くの場合、通常の(非生成)トランザクション152は、そのトランザクションが公開されたブロック151nを作成したブロックチェーンノード104にさらに報酬を与えるために、その出力の1つにおいて追加のトランザクション手数料も指定する。この手数料は通常「トランザクション手数料(transaction fee)」と呼ばれ、後で説明する。

トランザクションの検証および公開に関係するリソースに起因して、通常、ブロックチェーンノード104の少なくとも各々は、1つまたは複数の物理サーバユニットを備えるサーバの形態をとるか、またはデータセンタ全体の形態をとる。しかしながら、原則として、任意の所与のブロックチェーンノード104は、一緒にネットワーク化されたユーザ端末またはユーザ端末のグループの形態をとることができる。

各ブロックチェーンノード104のメモリは、ブロックチェーンノードプロトコルに従ってそれぞれの役割を実施し、トランザクション152を処理するために、ブロックチェーンノード104の処理装置上で実行するように構成されたソフトウェアを記憶する。本明細書においてブロックチェーンノード104に起因する任意のアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実施され得ることが理解されるであろう。ノードソフトウェアは、アプリケーション層、オペレーティングシステム層またはプロトコル層などの下位層、あるいはこれらの任意の組合せにおいて、1つまたは複数のアプリケーションに実装され得る。

ネットワーク101には、消費ユーザの役割を担う複数の当事者103の各々のコンピュータ機器102も接続されている。これらのユーザは、ブロックチェーンネットワーク106と対話し得るが、トランザクションの検証またはブロックの構築には参加しない。これらのユーザまたはエージェント103の一部は、トランザクションにおいて送信者および受信者として機能する場合がある。他のユーザは、必ずしも送信者または受信者として行動することなく、ブロックチェーン150と対話し得る。たとえば、一部の当事者は、ブロックチェーン150のコピーを記憶するストレージエンティティとして機能してもよい(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得した)。

当事者103の一部またはすべては、異なるネットワーク、たとえばブロックチェーンネットワーク106の上にオーバーレイされるネットワークの一部として接続されてもよい。ブロックチェーンネットワークのユーザ(しばしば「クライアント(clients)」と呼ばれる)は、ブロックチェーンネットワーク106を含むシステムの一部であると言われる場合があるが、これらのユーザは、ブロックチェーンノードに必要な役割を実施しないため、ブロックチェーンノード104ではない。代わりに、各当事者103は、ブロックチェーンネットワーク106と対話し、それによって、ブロックチェーンノード106に接続する(すなわち、通信する)ことによってブロックチェーン150を利用し得る。2人の当事者103およびそのそれぞれの機器102、すなわち第1の当事者103aおよびそのそれぞれのコンピュータ機器102a、ならびに第2の当事者103bおよびそのそれぞれのコンピュータ機器102bが、例示の目的で示されている。はるかに多くのそのような当事者103およびそれぞれのコンピュータ機器102が存在し、システム100に参加し得るが、便宜上、それらは図示されていないことが理解されるであろう。各当事者103は、個人であってもよく、組織であってもよい。純粋に例示として、本明細書では第1の当事者103aをアリスと呼び、第2の当事者103bをボブと呼ぶが、これに限定されるものではなく、本明細書におけるアリスまたはボブへのいかなる言及も、それぞれ「第1の当事者(first party)」および「第2の当事者(second party)」と置き換えられ得ることが理解されるであろう。

各当事者103のコンピュータ機器102は、1つまたは複数のプロセッサ、たとえばプロセッサ、たとえば、1つまたは複数のCPU、GPU、他のアクセラレータプロセッサ、特定用途向けプロセッサ、および/またはFPGAを備えるそれぞれの処理装置を備える。各当事者103のコンピュータ機器102は、メモリ、すなわち非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージをさらに備える。このメモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、SSD、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を使用する1つまたは複数のメモリユニットを備え得る。各当事者103のコンピュータ機器102上のメモリは、処理装置上で実行されるように構成された少なくとも1つのクライアントアプリケーション105のそれぞれのインスタンスを備えるソフトウェアを記憶する。本明細書において所与の当事者103に起因する任意のアクションは、それぞれのコンピュータ機器102の処理装置上で実行されるソフトウェアを使用して実施され得ることが理解されるであろう。各当事者103のコンピュータ機器102は、少なくとも1つのユーザ端末、たとえば、デスクトップまたはラップトップコンピュータ、タブレット、スマートフォン、あるいはスマートウォッチなどのウェアラブルデバイスを備える。所与の当事者103のコンピュータ機器102はまた、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの、1つまたは複数の他のネットワーク化されたリソースを備え得る。

クライアントアプリケーション105は、最初に、適切なコンピュータ可読記憶媒体上で任意の当事者103のコンピュータ機器102に提供されてよく、たとえば、サーバからダウンロードされるか、リムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスドライブ、磁気フロッピーディスクまたはテープ、CDまたはDVD ROMなどの光ディスク、あるいはリムーバブル光ドライブなどのリムーバブルストレージデバイスにおいて提供される。

クライアントアプリケーション105は、少なくとも「ウォレット(wallet)」機能を備える。これは2つの主な機能を有する。これらのうちの1つは、それぞれの当事者103が、トランザクション152を作成し、認可し(たとえば、署名し)、1つまたは複数のビットコインノード104に送信し、次いで、ブロックチェーンノード104のネットワーク全体に伝搬され、それによってブロックチェーン150に含まれるようにすることを可能にすることである。もう1つは、それぞれの当事者に、その当事者が現在所有しているデジタル資産の額を報告することである。出力ベースのシステムにおいて、この第2の機能は、当該当事者に属するブロックチェーン150全体に散在する様々なトランザクション152の出力において定義された額を照合することを備える。

注:様々なクライアント機能は、所与のクライアントアプリケーション105に統合されるものとして説明され得るが、これは必ずしも限定されるものではなく、代わりに、本明細書で説明される任意のクライアント機能は、代わりに、2つ以上の別個のアプリケーションのスイートにおいて実装されてもよく、たとえば、APIを介してインターフェイスするか、または一方が他方へのプラグインになる。より一般的には、クライアント機能は、アプリケーション層、もしくはオペレーティングシステムなどの下位層、またはこれらの任意の組合せにおいて実装することができる。以下はクライアントアプリケーション105に関して説明されるが、これに限定されないことが理解されるであろう。

各コンピュータ機器102上のクライアントアプリケーションまたはソフトウェア105のインスタンスは、ネットワーク106のブロックチェーンノード104のうちの少なくとも1つに動作可能に結合される。これにより、クライアント105のウォレット機能がトランザクション152をネットワーク106に送信できるようになる。クライアント105はまた、それぞれの当事者103が受信者であるトランザクションについてブロックチェーン150にクエリを行うために、ブロックチェーンノード104に連絡することができる(または、実施形態では、ブロックチェーン150は、部分的にその公開可視性を通じてトランザクションにおける信頼性を提供する公共施設であるため、実際にブロックチェーン150内の他の当事者のトランザクションを検査する)。各コンピュータ機器102上のウォレット機能は、トランザクションプロトコルに従ってトランザクション152を定式化し、送信するように構成されている。上で述べたように、各ブロックチェーンノード104は、ブロックチェーンノードプロトコルに従ってトランザクション152を検証するように構成されたソフトウェアを実行し、トランザクション152をブロックチェーンネットワーク106全体に伝搬させるためにそれを転送するように構成される。トランザクションプロトコルとノードプロトコルは互いに対応しており、所与のトランザクションプロトコルは所与のノードプロトコルとともに進行し、一緒に所与のトランザクションモデルを実装する。ブロックチェーン150内のすべてのトランザクション152に対して同じトランザクションプロトコルが使用される。同じノードプロトコルが、ネットワーク106内のすべてのノード104によって使用される。

所与の当事者103、たとえばアリスが、ブロックチェーン150に含まれるべき新しいトランザクション152jを送信したい場合、アリスは、関連するトランザクションプロトコルに従って(アリスのクライアントアプリケーション105のウォレット機能を使用して)新しいトランザクションを定式化する。次いで、アリスは、クライアントアプリケーション105から、アリスが接続されている1つまたは複数のブロックチェーンノード104にトランザクション152を送信する。たとえば、これは、アリスのコンピュータ102に最良に接続されているブロックチェーンノード104であり得る。任意の所与のブロックチェーンノード104が新しいトランザクション152jを受信すると、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従ってそれを処理する。これは、新しく受信されたトランザクション152jが「有効(valid)」であるための特定の条件を満たすかどうかを最初にチェックすることを含み、その例についてはすぐに詳しく説明する。一部のトランザクションプロトコルでは、検証のための条件は、トランザクション152に含まれるスクリプトによって、トランザクションごとに設定可能であり得る。あるいは、条件は単にノードプロトコルの組込み機能であってもよく、またはスクリプトとノードプロトコルの組合せによって定義されてもよい。

新たに受信されたトランザクション152jが有効であるとみなされるためのテストに合格することを条件として(すなわち、「検証される(validated)」ことを条件として)、トランザクション152jを受信する任意のブロックチェーンノード104は、そのブロックチェーンノード104において維持されるトランザクション154の順序付けられたセットに新しい検証されたトランザクション152を追加する。さらに、トランザクション152jを受信する任意のブロックチェーンノード104は、検証されたトランザクション152をネットワーク106内の1つまたは複数の他のブロックチェーンノード104に伝搬する。各ブロックチェーンノード104は同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、それがすぐにネットワーク106全体に伝搬されることを意味する。

所与のブロックチェーンノード104において維持される保留中のトランザクション154の順序付きプールへの参加が認められると、そのブロックチェーンノード104は、新しいトランザクション152を含むそれぞれのプール154の最新バージョンにおいてプルーフオブワークパズルを解こうと競合し始める。(他のブロックチェーンノード104は、異なるトランザクションプール154に基づいてパズルを解こうとしている可能性があるが、誰が最初に到達しても、最新のブロック151に含まれるトランザクションのセットを定義することになる可能性があることを思い出されたい。最終的には、ブロックチェーンノード104が、アリスのトランザクション152jを含む順序付けされたプール154の一部についてパズルを解くことになる)。新しいトランザクション152jを含むプール154に対してプルーフオブワークが行われると、それは不変的にブロックチェーン150内のブロック151の1つの一部となる。各トランザクション152は前のトランザクションへ戻るポインタを備えるため、トランザクションの順序も不変的に記録される。

異なるブロックチェーンノード104は、所与のトランザクションの異なるインスタンスを最初に受信し得、したがって、1つのインスタンスが新しいブロック151において公開される前に、どのインスタンスが「有効」であるかについて矛盾する見解を有し、その時点で、すべてのブロックチェーンノード104は、公開されたインスタンスが唯一の有効なインスタンスであることに同意する。ブロックチェーンノード104が1つのインスタンスを有効なものとして受け入れ、次いで、第2のインスタンスがブロックチェーン150に記録されていることを発見した場合、そのブロックチェーンノード104はこれを受け入れなければならず、最初に受け入れたインスタンス(すなわち、ブロック151において公開されていないもの)を破棄する(すなわち、無効なものとして扱う)ことになる。

いくつかのブロックチェーンネットワークによって動作されるトランザクションプロトコルの代替タイプは、アカウントベースのトランザクションモデルの一部として、「アカウントベース(account-based)」プロトコルと呼ばれる場合がある。アカウントベースの場合、各トランザクションは、過去のトランザクションのシーケンスにおける先行するトランザクションのUTXOを参照することによってではなく、絶対的なアカウント残高を参照することによって転送されるべき額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別の、ネットワークのノードによって記憶され、絶えず更新される。そのようなシステムでは、トランザクションはアカウントの実行中のトランザクション集計(「ポジション」とも呼ばれる)を使用して順序付けられる。この値は、送信者によってその暗号化署名の一部として署名され、トランザクション参照計算の一部としてハッシュされる。さらに、トランザクションにおける任意のデータフィールドも署名され得る。たとえば、このデータフィールドは、前のトランザクションIDがデータフィールドに含まれている場合、前のトランザクションを指し得る。

UTXOベースのモデル
図2は、例示的なトランザクションプロトコルを示している。これは、UTXOベースのプロトコルの一例である。トランザクション152(「Tx」と略記される)は、ブロックチェーン150の基本的なデータ構造である(各ブロック151は1つまたは複数のトランザクション152を含む)。以下では、出力ベースまたは「UTXO」ベースのプロトコルを参照して説明される。しかしながら、これはすべての可能な実施形態に限定されない。UTXOベースの例示的なプロトコルはビットコインを参照して説明されているが、他の例示的なブロックチェーンネットワークにおいても同様に実装できる点に留意されたい。

UTXOベースのモデルでは、各トランザクション(「Tx」)152は、1つまたは複数の入力202および1つまたは複数の出力203を備えるデータ構造を備える。各出力203は、未使用のトランザクション出力(UTXO)を備え得、これは、(UTXOがまだ償還されていない場合)別の新しいトランザクションの入力202のソースとして使用され得る。UTXOは、デジタル資産の額を指定する値を含む。これは、分散台帳上のトークンの設定数を表す。UTXOはまた、他の情報の中でも特に、元となるトランザクションのトランザクションIDを含み得る。トランザクションデータ構造は、入力フィールド202および出力フィールド203のサイズを示すインジケータを備え得るヘッダ201も備え得る。ヘッダ201はまた、トランザクションのIDを含み得る。実施形態では、トランザクションIDは、(トランザクションID自体を除く)トランザクションデータのハッシュであり、ノード104に提出される生のトランザクション152のヘッダ201に記憶される。

アリス103aが、当該デジタル資産の額をボブ103bに転送するトランザクション152jを作成したいと仮定する。図2では、アリスの新しいトランザクション152jには「Tx₁」とラベル付けされている。これは、シーケンス内の先行するトランザクション152iの出力203においてアリスにロックされたデジタル資産の額を取り、これのうちの少なくとも一部をボブに転送する。先行するトランザクション152iは、図2では「Tx₀」とラベル付けされている。Tx₀とTx₁は単なる任意のラベルである。それらは、Tx₀がブロックチェーン151内の最初のトランザクションであることも、Tx₁がプール154内のすぐ次のトランザクションであることも必ずしも意味するものではない。Tx₁は、アリスにロックされた未使用の出力203を依然として有する先行する(すなわち、先の)トランザクションを指すことができる。

先行するトランザクションTx₀は、アリスが新しいトランザクションTx₁を作成した時点では、または少なくともアリスがそれをネットワーク106に送信する時点までには、すでに検証されており、ブロックチェーン150のブロック151に含まれている可能性がある。それは、その時点ですでにブロック151のうちの1つに含まれている可能性もあり、順序付きセット154内でまだ待機している可能性もあり、その場合、すぐに新しいブロック151に含まれることになる。あるいは、Tx₀とTx₁を作成して一緒にネットワーク106に送信することもでき、ノードプロトコルが「オーファン(Tx₀)」トランザクションのバッファリングを許可する場合には、Tx₀をTx₁の後に送信することさえもできる。本明細書でトランザクションのシーケンスの文脈において使用される「先行する(preceding)」および「後続の(subsequent)」という用語は、トランザクション内で指定されているトランザクションポインタ(どのトランザクションが他のどのトランザクションを指すかなど)によって定義されるシーケンス内のトランザクションの順序を指す。これらは、「先行するもの(predecessor)」と「後続するもの(successor)」、または「先の(antecedent)」と「後の(descendant)」、「親(parent)」と「子(child)」などに同等に置き換えることもできる。それは、それらが作成され、ネットワーク106に送信され、または任意の所与のブロックチェーンノード104に到着する順序を必ずしも含意するものではない。それにもかかわらず、先行するトランザクション(先のトランザクションまたは「親」)を指す後続のトランザクション(後のトランザクションまたは「子」)は、親トランザクションが検証されるまで、および検証されない限り検証されない。親よりも先にブロックチェーンノード104に到着する子は、オーファンとみなされる。ノードプロトコルおよび/またはノードの挙動に応じて、親を待つために特定の時間、破棄またはバッファリングされ得る。

先行するトランザクションTx₀の1つまたは複数の出力203のうちの1つは、本明細書ではUTXO₀とラベル付けされている特定のUTXOを備える。各UTXOは、UTXOによって表されるデジタル資産の額を指定する値と、ロックスクリプトとを備え、ロックスクリプトは、後続のトランザクションが検証され、したがって、UTXOが正常に償還されるために、後続のトランザクションの入力202内のロック解除スクリプトが満たさなければならない条件を定義する。典型的には、ロックスクリプトは、その額を特定の当事者(それが含まれるトランザクションの受益者)にロックする。すなわち、ロックスクリプトは、典型的には、後続のトランザクションの入力内のロック解除スクリプトに、先行するトランザクションがロックされる当事者の暗号署名が含まれるという条件を備えるロック解除条件を定義する。

ロックスクリプト(通称scriptPubKey)は、ノードプロトコルによって認識されるドメイン固有言語で記述されたコードの一部分である。そのような言語の特定の例は、ブロックチェーンネットワークによって使用される「スクリプト(Script)」(大文字S)と呼ばれる。ロックスクリプトは、トランザクション出力203を使用するためにどの情報が必要とされるか、たとえばアリスの署名の要件を指定する。ロック解除スクリプトはトランザクションの出力に現れる。ロック解除スクリプト(通称scriptSig)は、ロックスクリプト基準を満たすために必要な情報を提供するドメイン固有言語で記述されたコードの一部分である。たとえば、それはボブの署名を含み得る。ロック解除スクリプトは、トランザクションの入力202に現れる。

つまり、図示される例では、Tx₀の出力203内のUTXO₀は、UTXO₀が償還されるために(厳密には、UTXO₀を償還しようとする後続のトランザクションが有効となるために)アリスの署名Sig P_Aを必要とするロックスクリプト[Checksig P_A]を備える。[Checksig P_A]は、アリスの公開鍵-秘密鍵ペアからの公開鍵P_Aの表現(すなわち、ハッシュ)を含む。Tx₁の入力202は、(たとえば、実施形態ではトランザクションTx₀全体のハッシュであるそのトランザクションID、TxID₀によって)Tx₁を指し示すポインタを備える。Tx₁の入力202は、Tx₀の任意の他の可能な出力の中から、UTXO₀を識別するために、Tx₀内のUTXO₀を識別するインデックスを備える。Tx₁の入力202は、アリスが鍵ペアからのアリスの秘密鍵をデータのあらかじめ定義された部分(暗号では「メッセージ」と呼ばれることもある)に適用することによって作成された、アリスの暗号署名を備えるロック解除スクリプト<Sig P_A>をさらに備える。有効な署名を提供するためにアリスによって署名される必要があるデータ(または「メッセージ」)は、ロックスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義され得る。

新しいトランザクションTx₁がブロックチェーンノード104に到着すると、ノードはノードプロトコルを適用する。これは、ロックスクリプトおよびロック解除スクリプトを一緒に実行して、ロック解除スクリプトがロックスクリプトにおいて定義されている条件(この条件は1つまたは複数の基準を備え得る)を満たすかどうかをチェックすることを備える。実施形態では、これは2つのスクリプトを連結することを含む。
<Sig P_A> <P_A>||[Checksig P_A]
上式で、「||」は連結を表し、「<…>」はデータをスタックに置くことを意味し、「[…]」はロック解除スクリプト(この例ではスタックベースの言語)で構成される関数である。同等に、スクリプトは、スクリプトを連結するのではなく、共通スタックを用いて次々に実行され得る。いずれにしても、一緒に実行されるとき、スクリプトは、Tx₀の出力内のロックスクリプトに含まれるようなアリスの公開鍵P_Aを使用して、Tx₁の入力内のロック解除スクリプトが、データの予想される部分に署名したアリスの署名を含むことを認証する。データの予想される部分自体(「メッセージ」)はまた、この認証を実施するために含まれる必要がある。実施形態では、署名されたデータは、Tx₁の全体を備える(つまり、平文のデータの署名された部分を指定する別個の要素は、すでに本質的に存在するので、含まれる必要はない)。

メッセージmは、署名されているトランザクションの特定の詳細から派生する。このメッセージは署名から検証まで同一である必要があるため、このプロセスにより、署名を無効にすることなく、メッセージに含まれるトランザクションデータを修正できないことが保証される。

メッセージは、上に示したように、トランザクション情報の特定の要素を設定された順序で連結することによって生成される。署名の検証中、メッセージは明示的に送信されないが、代わりに、ブロードキャストトランザクション内のデータに基づいて検証者によって再作成され、トランザクション情報は、署名において使用されるのと同じプロセスを介して連結され、メッセージダイジェストeを生成するために二重ハッシュされる。メッセージを再作成するために使用されたトランザクションの一部が署名の作成後に変更されている場合、メッセージは同一ではなくなり、検証は失敗する。

署名メッセージにおいてトランザクションの詳細を使用するこのプロセスは、トランザクションのブロードキャストとブロックチェーンに公開される時点の間の遅延中に、重要なセキュリティ要素を提供する。しかしながら、「署名された」(すなわち、署名メッセージに含まれる)トランザクションの要素は署名を無効にしないと更新することができないため、一部のトランザクションフィールドは署名メッセージに含めることはできない。これらのフィールドは、生成された後に署名を含めるように更新する必要がある、入力ごとのロック解除スクリプトと、完全なトランザクション(ロック解除スクリプトにおける署名を含む)の二重ハッシュであるトランザクションID(TxID)である。両方のフィールドには署名が含まれている(または、署名から派生している)必要があるため、署名が生成されるまで固定することができない。

公開-秘密暗号法による認証の詳細は、当業者によく知られている。基本的に、アリスが自分の秘密鍵を使用してメッセージに署名した場合、アリスの公開鍵および平文のメッセージが与えられると、ノード104などの別のエンティティは、メッセージの暗号化バージョンがアリスによって署名されたものに違いないことを認証することができる。署名は、典型的には、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージにタグ付けすることを備え、これにより、公開鍵の任意の保持者が署名を認証することができる。したがって、特定のデータ部分またはトランザクションの一部への署名などへの本明細書での言及は、実施形態では、そのデータ部分またはトランザクションの一部のハッシュに署名することを意味することができる点に留意されたい。

Tx₁内のロック解除スクリプトが、Tx₀のロックスクリプト内で指定されている1つまたは複数の条件を満たす場合(つまり、図示される例では、アリスの署名がTx₁内で提供され、認証された場合)、ブロックチェーンノード104は、Tx₁が有効であるとみなす。これは、ブロックチェーンノード104が保留中のトランザクション154の順序付きプールにTx₁を追加することを意味する。ブロックチェーンノード104はまた、トランザクションTx₁をネットワーク106内の1つまたは複数の他のブロックチェーンノード104に転送し、その結果、トランザクションがネットワーク106全体に伝搬されるようにする。Tx₁が検証されてブロックチェーン150に含まれると、これは、Tx₀からのUTXO₀を使用済みと定義する。Tx₁は、未使用のトランザクション出力203を使用する場合にのみ有効であり得る点に留意されたい。別のトランザクション152によってすでに使用された出力を使用しようとする場合、Tx₁は、他のすべての条件が満たされたとしても無効になる。したがって、ブロックチェーンノード104はまた、先行するトランザクションTx₀内の参照されたUTXOがすでに使用済みであるかどうか(すなわち、別の有効なトランザクションへの有効な入力をすでに形成しているかどうか)をチェックする必要がある。これは、ブロックチェーン150がトランザクション152に定義された順序を課すことが重要である1つの理由である。実際には、所与のノード104は、どのトランザクション152内のどのUTXO203が使用されたかをマーキングする別個のデータベースを維持し得るが、最終的には、UTXOが使用されたかどうかを定義するものは、ブロックチェーン150内の別の有効なトランザクションへの有効な入力をすでに形成しているかどうかである。

所与のトランザクション152のすべての出力203において指定された合計金額が、そのすべての入力202によって指定された合計金額より大きい場合、これはほとんどのトランザクションモデルにおける無効のもう1つの根拠になる。したがって、そのようなトランザクションは伝搬されず、ブロック151にも含まれない。

UTXOベースのトランザクションモデルでは、所与のUTXOが全体として使用される必要がある点に留意されたい。UTXOにおいて使用済みとして定義された額の一部を「後に残す(leave behind)」ことはできず、別の一部が使用される。しかしながら、次のトランザクションの複数の出力間でUTXOからの額を分割することはできる。たとえば、Tx₀内のUTXO₀において定義された額は、Tx₁内の複数のUTXO間で分割され得る。したがって、アリスが、UTXO0において定義された額のすべてをボブに与えたくない場合、アリスは、リマインダを使用して、Tx₁の第2の出力において自分に残りを与えるか、または別の当事者に支払うことができる。

実際には、アリスは通常、自分のトランザクション104をブロック151に含めることに成功したビットコインノード104に対する手数料を含む必要もある。アリスがそのような手数料を含めない場合、Tx₀は、ブロックチェーンノード104によって拒否される可能性があり、したがって、技術的には有効であっても、伝搬されず、ブロックチェーン150に含められない可能性がある(ノードプロトコルは、ブロックチェーンノード104が望まない場合にトランザクション152を受け入れることを強制しない)。いくつかのプロトコルでは、トランザクション手数料は、それ自体の別個の出力203を必要としない(すなわち、別個のUTXOを必要としない)。代わりに、入力202によって指定された合計金額と、所与のトランザクション152の出力203において指定された合計金額との差は、トランザクションを公開するブロックチェーンノード104に自動的に与えられる。たとえば、UTXO₀へのポインタがTx₁への唯一の入力であり、Tx₁は唯一の出力UTXO₁を有するとする。UTXO₀において指定されているデジタル資産の額がUTXO₁において指定されている額より大きい場合、その差がUTXO₁を含むブロックを作成するためにプルーフオブワークレースに勝ったノード104によって割り当てられ得る。しかしながら、代替的にまたは追加的に、トランザクション手数料がトランザクション152のUTXO203のうちのそれ自体の1つにおいて明示的に指定され得ることは、必ずしも除外されるものではない。

アリスおよびボブのデジタル資産は、ブロックチェーン150内のどこにでもある任意のトランザクション152においてそれらにロックされたUTXOから構成される。したがって、典型的には、所与の当事者103の資産は、ブロックチェーン150全体にわたる様々なトランザクション152のUTXO全体に散在している。ブロックチェーン150内のどこにも、所与の当事者103の総残高を定義する数字は記憶されない。クライアントアプリケーション105におけるウォレット機能の役割は、それぞれの当事者にロックされ、別の前方のトランザクションにおいてまだ使用されていない様々なUTXOすべての値を一緒に照合することである。これは、ビットコインノード104のいずれかに記憶されたブロックチェーン150のコピーにクエリを行うことによって行うことができる。

スクリプトコードは、しばしば、概略的に表される(すなわち、正確な言語を使用していない)点に留意されたい。たとえば、特定の機能を表すためにオペレーションコード(オペコード)を使用し得る。「OP_...」は、スクリプト言語の特定のオペコードを指す。一例として、OP_RETURNは、ロックスクリプトの開始時にOP_FALSEが前に置かれると、トランザクション内にデータを記憶することができ、それによってデータをブロックチェーン150に不変的に記録することができる、トランザクションの使用不可能な出力を作成するスクリプト言語のオペコードである。たとえば、データは、ブロックチェーンに記憶することが望まれる文書を備え得る。

通常、トランザクションの入力は、公開鍵P_Aに対応するデジタル署名を含む。実施形態では、これは、楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は、特定のデータの一部分に署名する。いくつかの実施形態では、所与のトランザクションについて、署名は、トランザクション入力の一部、およびトランザクション出力の一部または全部に署名する。署名された出力の特定の部分は、SIGHASHフラグに依存する。SIGHASHフラグは、通常、どの出力が署名されるかを選択するために署名の最後に含まれる4バイトコードである(したがって、署名時に固定される)。

6つの異なるフラグタイプを使用すると、署名が選択的に承認でき、したがって、すべての入力と出力、または様々なサブセットの詳細を固定することができる。インデックス2における入力のロックを解除する署名に基づいて、様々なセットが以下に示されている。承認された入力と出力は太字で示されている。

各表の上部に示されるフラグ名は、メッセージに、ALL、NONE、またはSINGLEのどの出力が含まれるかを示している。各フラグには2つのバリアントがあり、これらはどの入力が署名メッセージに含まれるかを示しており、「標準(standard)」バリアント(ALL、NONE、SINGLE、図2の表の一番上の行)はすべての入力を含み、「誰でも支払うことができる(anyone can pay)」またはACPバリアント(ALL|ACP、NONE|ACP、SINGLE|ACP、一番下の行)は、署名によってロックが解除される入力のみを含む。単一フラグのバリアント(SINGLEまたはSINGLE|ACP)の場合、署名される単一の出力は常に、ロックが解除されている入力に一致するインデックス位置にある出力である点に留意されたい。一番上の行に示されているバリアント、つまりすべての入力に署名するバリアントはまた、本明細書ではそれぞれALL|ALL、NONE|ALL、およびSINGLE|ALLとも呼ばれる。ACPバリアントと同様に、第1の項は署名された出力を示し、第2の項は署名された入力を示している。

sighashフラグの選択によって影響を受けるメッセージ内のフィールドは、Hash(Outpoints)、Hash(nSeqs)、Hash(Outputs)、およびsigHashFlagフィールド自体である。ハッシュフィールドを計算する際、(sighashフラグに基づいて)含まれていない入力と出力は空になり、残りのデータが順番に連結されてハッシュされる。たとえば、sighash ALL|ACP署名の場合、インデックス0(Outpoint_i)とインデックス1(Outpoint_j)における入力の情報は削除されるが、すべての出力の詳細は保持され、次のハッシュフィールドが生成される。
Hash(Outpoints)= Hash([TxID_k][index_k])
Hash(nSeqs) = Hash([nSeq_k])
Hash(Outputs) = Hash([value_w][lockScriptLength_w][lockScript_w][value_x]...
[lockScriptLength_x][lockScript_x][value_y][lockScriptLength_y]...
[lockScript_y][value_z][lockScriptLength_z][lockScript_z])

sighash SINGLE署名の場合、すべての入力は保持されるが、出力は、署名の位置と一致するインデックス2にある1つだけが保持され、次のようになる。
Hash(Outpoints) = Hash([TxID_i][index_i][TxID_j][index_j][TxID_k][index_k])
Hash(nSeqs) = Hash([nSeq_i][nSeq_j][nSeq_k])
Hash(Outputs) = Hash([value_y][lockScriptLength_y][lockScript_y])

メッセージ文字列における他のフィールドは、sighashフラグによる影響を受けない。バージョンおよびロックタイムフィールド(署名メッセージに常に含まれる)は、署名がどの入力を許可するかに関係なく、同じトランザクションに基づくすべての署名にとって同一である。残りのフィールド(outpoint_k、lockScriptLength_k、lockScript_k、value_k、およびnSeq_k)は、署名される入力に直接関連するため、ロックを解除するために署名が作成される入力に応じて変化するが、ロックが解除されている入力は常に署名されている必要があるため、sighashフラグの選択によって影響されることはない。

署名メッセージは、署名(r,s)を生成するために、一致する秘密鍵とともにECDSA署名アルゴリズムに渡される。この署名をビットコイントランザクションに含めるために、それを許可する入力のロック解除スクリプトフィールドに配置される単一の文字列に変換する必要がある。この文字列は、署名の2つの要素であるrとsを連結し、DER標準を使用してバイト形式にエンコードすることによって作成される。

メッセージでは、sighashフラグが最終バイトとして追加され、シリアル化された署名を与えるために、以下の式に示されるように各sighashフラグが特定の値によって表される:sig(a,m)=[r][s][sigHashFlag]。Pay to Public Key Hash(P2PKH)ロックスクリプトを使用したアウトポイントの場合、署名は、ロック解除スクリプトフィールドに配置される前に、関連付けられる公開鍵とともにさらに追加される点に留意されたい。検証中、トランザクション内の署名ごとに、トランザクション情報とsighashフラグに基づいてメッセージが再作成され、そのメッセージに対する署名の有効性がチェックされる。

6つのsighashフラグは、1つの入力(NONE|ACP)からすべての入力と出力(ALL)まで、あらゆるものに(署名メッセージに含めることで)「署名(sign)」する柔軟性を提供することができる。sighash ALL以外のフラグの場合、これは、署名を無効にすることなく、署名メッセージから除外されるトランザクション情報を変更できることを意味する。これにより、sighash ALLを使用する標準的な手法よりも柔軟性が高まる。たとえば、誰でも支払うことができるフラグのバリアントでは、署名されているもの以外の入力の詳細に制限が設けられていないため、他の当事者はお互いの署名を無効にすることなくトランザクションに入力を追加する(すなわち、「支払う」)ことができる。

ロックスクリプトは、通常それぞれのトランザクションがロックされる当事者の公開鍵を備えるという事実を指して、「scriptPubKey」と呼ばれることがある。ロック解除スクリプトは、通常それが対応する署名を供給するという事実を指して「scriptSig」と呼ばれることがある。しかしながら、より一般的には、UTXOが償還されるための条件が署名を認証することを備えることは、ブロックチェーン150のすべてのアプリケーションにおいて必須ではない。より一般的には、任意の1つまたは複数の条件を定義するためにスクリプト言語を使用することができる。したがって、より一般的な用語「ロックスクリプト(locking script)」および「ロック解除スクリプト(unlocking script)」が好まれ得る。

サイドチャネル
図1に示されるように、アリスおよびボブの各々のコンピュータ機器102a、120b上のクライアントアプリケーションは、それぞれ、追加の通信機能を備え得る。この追加の機能は、(いずれかの当事者または第三者の指示で)アリス103aがボブ103bとの別個のサイドチャネル107を確立することを可能にする。サイドチャネル107は、ブロックチェーンネットワークとは別でのデータの交換を可能にする。そのような通信は、「オフチェーン(off-chain)」通信と呼ばれることがある。たとえば、これは、当事者の一方がトランザクションをネットワーク106にブロードキャストすることを選択するまで、トランザクションが(まだ)ブロックチェーンネットワーク106に登録されたり、チェーン150上に進んだりすることなく、アリスとボブとの間でトランザクション152を交換するために使用され得る。この方法でトランザクションを共有することは、「トランザクションテンプレート」の共有と呼ばれることもある。トランザクションテンプレートには、完全なトランザクションを形成するために必要な1つまたは複数の入力および/または出力が欠けている場合がある。代替的にまたは追加的に、サイドチャネル107は、鍵、交渉された額または条件、データコンテンツなどの任意の他のトランザクション関連データを交換するために使用され得る。

サイドチャネル107は、ブロックチェーンネットワーク106と同じパケット交換ネットワーク101を介して確立され得る。代替的にまたは追加的に、サイドチャネル301は、モバイルセルラーネットワークなどの異なるネットワーク、またはローカルワイヤレスネットワークなどのローカルエリアネットワーク、またはさらにはアリスのデバイス102aとボブのデバイス102bとの間の直接のワイヤードもしくはワイヤレスリンクを介して確立され得る。一般に、本明細書のどこかで参照されるサイドチャネル107は、「オフチェーン」、すなわちブロックチェーンネットワーク106とは別でデータを交換するための1つまたは複数のネットワーキング技術または通信媒体を介した任意の1つまたは複数のリンクを備え得る。2つ以上のリンクが使用される場合、全体としてのオフチェーンリンクの束または集合は、サイドチャネル107と呼ばれ得る。したがって、アリスおよびボブがサイドチャネル107を介して情報またはデータの特定の部分などを交換すると言われている場合、これは、これらのデータの部分のすべてが全く同じリンクまたは同じタイプのネットワーク上で送信されなければならないことを必ずしも含意するものではない点に留意されたい。

クライアントソフトウェア
図3Aは、現在開示されている方式の実施形態を実装するためのクライアントアプリケーション105の例示的な実装形態を示している。クライアントアプリケーション105は、トランザクションエンジン401とユーザインターフェース(UI)層402を備える。トランザクションエンジン401は、トランザクション152を定式化することと、サイドチャネル301を介してトランザクションおよび/または他のデータを受信および/または送信することと、ならびに/あるいは上記で説明し、すぐにさらに詳細に説明する方式に従って、ブロックチェーンネットワーク106を通じて伝搬されるべき1つまたは複数のノード104にトランザクションを送信することとを行うためなどに、クライアント105の基礎となるトランザクション関連機能を実装するように構成される。本明細書に開示される実施形態によれば、各クライアント105のトランザクションエンジン401は、マルチ署名トランザクションを生成および変更する関数403を備える。

関数403は、トランザクションの第1のインデックスにおいて、複数のロック解除署名を必要とする入力と出力を提供することによって、マルチ署名トランザクションを生成する。第1の署名は、第1のインデックスの出力のみを許可する入力に提供され、すなわち、第1の署名にはSINGLE|ALLまたはSINGLE|ACP sighashフラグが付けられる。第1のインデックスの入力のロックを解除するためにさらに多くの署名が必要となるこの段階におけるトランザクションは、部分マルチ署名トランザクションと呼ばれる。

クライアントアプリケーション105は、部分マルチ署名トランザクションを、第1のインデックスにおける入力のロックを解除すること、および/またはトランザクションに追加の入力および出力を追加することを許可されたユーザに関連付けられるクライアントアプリケーション105に送信する。

部分的なマルチ署名トランザクションを受信したユーザデバイスにおいて、第1のインデックスに別の署名を提供するために、関数403を使用することができる。この署名には、入力のロックを解除するためにさらに多くの署名が必要な場合はSINGLE|ALLまたはSINGLE|ACP sighashフラグが付けられ、署名がトランザクションのすべての出力を許可するように、署名が必要な最終署名である場合はALL sighashフラグが付けられる。関数403はまた、第1のインデックスにおいて使用されるsighashフラグに応じて、第2または次のインデックスにおいて出力または入力と出力を定義する。入力と出力が提供される場合、入力は単一のsighashフラグを備えた署名を備える。最終署名が第1のインデックスに提供される場合、署名が提供される前に追加の出力を提供する必要がある。

UI層402は、機器102のユーザ出力手段を介して各ユーザ103に情報を出力することと、機器102のユーザ入力手段を介して各ユーザ103から入力を受信することとを含む、各ユーザのコンピュータ機器102のユーザ入力/出力(I/O)手段を介して、ユーザインターフェースをレンダリングするように構成される。たとえば、ユーザ出力手段は、視覚出力を提供するための1つまたは複数のディスプレイスクリーン(タッチスクリーンまたは非タッチスクリーン)、オーディオ出力を提供するための1つまたは複数のスピーカ、および/または触覚出力を提供するための1つまたは複数の触覚出力デバイスなどを備えることができる。ユーザ入力手段は、たとえば、1つもしくは複数のタッチスクリーン(出力手段のために使用されるものと同じまたは異なるもの)の入力アレイ、マウス、トラックパッド、またはトラックボールなどの1つもしくは複数のカーソルベースのデバイス、スピーチもしくは音声入力を受信するための1つもしくは複数のマイクおよびスピーチもしくは音声認識アルゴリズム、手動もしくは身体的なジェスチャの形式で入力を受信するための1つもしくは複数のジェスチャベースの入力デバイス、あるいは1つもしくは複数の機械的なボタン、スイッチ、またはジョイスティックなどを備えることができる。

注:本明細書における様々な機能は、同じクライアントアプリケーション105に統合されるものとして説明される場合があるが、これは必ずしも限定されるものではなく、代わりに、それらは、2つ以上の別個のアプリケーションのスイートにおいて実装することができ、たとえば、1つはもう1つのプラグインであるか、API(アプリケーションプログラミングインターフェース)を介して接続されている。たとえば、トランザクションエンジン401の機能は、UI層402とは別個のアプリケーションで実装されてもよく、トランザクションエンジン401などの所与のモジュールの機能は、複数のアプリケーションに分割されてもよい。また、説明された機能の一部またはすべてが、たとえばオペレーティングシステム層において実装される可能性も排除されない。本明細書のどこかで単一のまたは所与のアプリケーション105などについて言及する場合、これは単なる例であり、より一般的には、説明される機能は任意の形式のソフトウェアで実装することができることが理解されるであろう。

図3Bは、アリスの機器102a上のクライアントアプリケーション105aのUI層402によってレンダリングされ得るユーザインターフェース(UI)300の一例のモックアップを示している。同様のUIが、ボブの機器102b上のクライアント105b、または他の当事者の機器によってレンダリングされ得ることが理解されるであろう。

例として、図3Bは、アリスの視点からのUI300を示している。UI300は、ユーザ出力手段を介して別個のUI要素としてレンダリングされる1つまたは複数のUI要素301、302、303を備え得る。

たとえば、UI要素は、異なるスクリーン上のボタン、またはメニュー内の異なるオプションなどであり得る、1つまたは複数のユーザ選択可能な要素301を備え得る。ユーザ入力手段は、ユーザ103(この場合、アリス103a)が、スクリーン上のUI要素をクリックまたはタッチすること、または所望のオプションの名前を話すことなどによって、オプションのうちの1つを選択または動作できるように構成される(注意:本明細書で使用する「手動(manual)」という用語は、自動との対比のみを意味しており、必ずしも片手または両手の使用に限定するものではない)。このオプションにより、ユーザ(アリス)は、たとえば、修正するトランザクションを選択すること、マルチ署名トランザクションに含めるアウトポイントまたは出力を選択すること、トランザクションを生成すること、あるいは署名を提供することを行うことができる。

代替的または追加的に、UI要素は、たとえば、ユーザがOP_RETURNに含まれるテキストを入力したり、秘密鍵またはパスワードを提供したりできる、1つまたは複数のデータ入力フィールド302を備え得る。これらのデータ入力フィールドは、ユーザ出力手段を介して、たとえばスクリーン上でレンダリングされ、データは、ユーザ入力手段、たとえばキーボードまたはタッチスクリーンを通じてフィールドに入力することができる。あるいは、データは、たとえばスピーチ認識に基づいて口頭で受信することもできる。

代替的にまたは追加的に、UI要素は、ユーザに情報を出力するために出力される1つまたは複数の情報要素303を備え得る。たとえば、これ/これらはスクリーン上に、または可聴式にレンダリングすることができる。

様々なUI要素をレンダリングし、オプションを選択し、データを入力する特定の手段は重要ではないことが理解されるであろう。これらのUI要素の機能についてはすぐに詳しく説明する。また、図3に示されるUI300は、模式化されたモックアップにすぎず、実際には、簡潔にするために図示されていない1つまたは複数のさらなるUI要素を備え得ることも理解されよう。

ノードソフトウェア
図4は、UTXOまたは出力ベースのモデルの例において、ネットワーク106の各ブロックチェーンノード104上で実行されるノードソフトウェア450の例を示している。別のエンティティは、ネットワーク106上でノード104として分類されずに、すなわち、ノード104に必要なアクションを実施せずに、ノードソフトウェア450を実行する可能性がある点に留意されたい。ノードソフトウェア450は、これらに限定されないが、プロトコルエンジン451と、スクリプトエンジン452と、スタック453と、アプリケーションレベル決定エンジン454と、1つまたは複数のブロックチェーン関連機能モジュール455のセットとを含み得る。各ノード104は、これらに限定されないが、コンセンサスモジュール455C(たとえば、プルーフオブワーク)、伝搬モジュール455P、および記憶モジュール455S(たとえば、データベース)の3つすべてを含む、ノードソフトウェアを実行し得る。プロトコルエンジン401は、通常、トランザクション152の異なるフィールドを認識し、ノードプロトコルに従ってそれらを処理するように構成される。別の先行するトランザクション152i(Tx_m-1)の出力(たとえば、UTXO)を指す入力を有するトランザクション152j(Tx_j)が受信されると、プロトコルエンジン451は、Tx_j内のロック解除スクリプトを識別し、それをスクリプトエンジン452に渡す。プロトコルエンジン451はまた、Tx_jの入力内のポインタに基づいて、Tx_iを識別し、取り出す。Tx_iはブロックチェーン150上で公開されてもよく、その場合、プロトコルエンジンは、ノード104に記憶されたブロックチェーン150のブロック151のコピーからTx_iを取り出し得る。あるいは、Tx_iはブロックチェーン150上でまだ公開されていない可能性がある。その場合、プロトコルエンジン451は、ノード104によって維持される未公開トランザクションの順序付きセット154からTx_iを取り出し得る。いずれにしても、スクリプトエンジン451は、Tx_iの参照された出力におけるロックスクリプトを識別し、これをスクリプトエンジン452に渡す。

したがって、スクリプトエンジン452は、Tx_iのロックスクリプトと、Tx_jの対応する入力からのロック解除スクリプトとを有する。たとえば、Tx₀およびTx₁とラベル付けされたトランザクションが図2に示されているが、同じことが、任意のペアのトランザクションにも当てはまる。スクリプトエンジン452は、前述したように2つのスクリプトを一緒に実行し、これは、使用されているスタックベースのスクリプト言語(たとえば、Script)に従って、スタック453上にデータを配置し、そこからデータを取り出すことを含む。

スクリプトを一緒に実行することによって、スクリプトエンジン452は、ロック解除スクリプトがロックスクリプトにおいて定義された1つまたは複数の基準を満たすか否か、すなわち、ロックスクリプトが含まれる出力を「ロック解除」するか否かを決定する。スクリプトエンジン452は、この決定の結果をプロトコルエンジン451に返す。スクリプトエンジン452は、ロック解除スクリプトが対応するロックスクリプトにおいて指定されている1つまたは複数の基準を満たすと決定した場合、結果「真(true)」を返す。そうでなければ、結果「偽(false)」を返す。

出力ベースのモデルでは、スクリプトエンジン452からの結果「真」は、トランザクションの有効性の条件のうちの1つである。典型的には、Tx_jの出力において指定されているデジタル資産の総額が、その入力によって示された総額を超えないこと、およびTx_iの示された出力が別の有効なトランザクションによってまだ使用されていないことなどの、同様に満たされなければならないプロトコルエンジン451によって評価される、1つまたは複数のさらなるプロトコルレベル条件も存在する。プロトコルエンジン451は、スクリプトエンジン452からの結果を1つまたは複数のプロトコルレベル条件とともに評価し、それらがすべて真である場合にのみ、トランザクションTx_jを検証する。プロトコルエンジン451は、トランザクションが有効であるかどうかの指示をアプリケーションレベル決定エンジン454に出力する。Tx_jが実際に検証されるという条件でのみ、決定エンジン454は、Tx_jに関してそれぞれのブロックチェーン関連機能を実施するために、コンセンサスモジュール455Cおよび伝搬モジュール455Pの両方を制御することを選択し得る。これは、コンセンサスモジュール455Cが、ブロック151に組み込むためにTx_jをノードのトランザクション154それぞれの順序付けられたセットに追加すること、および伝搬モジュール455PがTx_jをネットワーク106内の別のブロックチェーンノード104に転送することを備える。任意で、実施形態では、アプリケーションレベル決定エンジン454は、これらの機能の一方または両方をトリガする前に、1つまたは複数の追加の条件を適用し得る。たとえば、決定エンジンは、トランザクションが有効であり、かつ十分なトランザクション手数料を残しているという条件でのみトランザクションを公開することを選択し得る。

本明細書における「真」および「偽」という用語は、単一の2進数(ビット)のみの形態で表される結果を返すことに必ずしも限定されないが、それは確かに1つの可能な実装形態である点にも留意されたい。より一般的には、「真」は、成功または肯定的な成果を示す任意の状態を指すことができ、「偽」は、不成功または非肯定的な成果を示す任意の状態を指すことができる。たとえば、アカウントベースのモデルでは、「真」の結果は、署名の暗黙的な、プロトコルレベルの検証と、スマートコントラクトの追加の肯定的な出力との組合せによって示され得る(個々の成果の両方が真である場合、全体の結果が真を示すとみなされる)。

マルチ署名トランザクション
単一のトランザクションにおいて複数の署名が使用されるわかりやすい例の1つは、入力または出力にマルチ署名(マルチシグ)ロック解除要件を有する場合である。通常、これらは、複数の当事者がアカウントまたは資産の制御を共有できるようにするために使用され、支出を承認するためにm-of-nの署名を必要とし、m≦nである。

マルチシグロック解除要件を有するUTXOは、複数の当事者によって制御される資産を表し、当事者の各々が秘密署名鍵を保持する。通常、これらのマルチシグUTXOを入力として使用するトランザクションは、承認された署名当事者間で、非公開で草案が作成されて事前に合意され、次いで、各当事者が完全なトランザクションに基づいて署名を作成する。しかしながら、状況によっては、出力がグループの1人のメンバに特に関連しており、そのメンバが出力の割当てを独立して制御したい場合がある。

一例として、離婚時などに、2人の当事者間で共有されていた共同アカウントを解消して、2つの別個の単独で制御されるアカウントにすることが考えられる。アリスとボブの共同預金アカウントを表すUTXOは、アリスとボブがそれぞれ秘密署名鍵を保持する2-of-2マルチシグロック解除要件を有する場合がある。これらの資金を2つの単独で制御される出力に送金したい場合、次のようにトランザクションを作成して署名することができる。
1.アリスはマルチシグ入力をインデックス0に設定し、出力をインデックス0に定義し、SINGLEに署名する。マルチシグ入力とアリスの出力は同じインデックス位置にあるため、この署名は入力を承認し、アリスの出力を固定する。ボブはアリスの署名を無効にし、したがって、マルチシグ入力のロック解除スクリプトを無効にしないとアリスの出力を修正することができないため、たとえ2人の間の信頼が保証されていない場合でも、アリスはこれをボブに安全に送信することができる。同様に、入力を検証するために必要な第2の署名が存在しないため、トランザクションが傍受され、割り当てられていない資金が別のアドレスに転送される危険はない。

2.次に、ボブは出力をインデックス1に追加し、sighash ALLを使用してマルチシグ入力に署名し得る。これにより、入力を検証するために必要な第2の署名が提供され、出力が固定される。

異なるsighashフラグを使用したこの署名のシーケンスにより、アリスとボブは、sighash ALLで署名されたすべてのトランザクションに固有の相互依存関係を回避することができる。アリスもボブも、トランザクションを無効にすることなく相手の出力を編集する機会はない。同様に、どちらの当事者も、自分自身に必要以上の価値を割り当てることはできない。アリスが自分の出力値を高すぎる値に設定した場合、ボブはトランザクションを承認する署名をしないだろう。ボブが合意よりも高い出力値を設定した場合、出力の値が入力の値を超え、トランザクションは無効になる。

会社のアカウントを制御する株主グループなど、2人以上の関係者が関与するマルチシグの状況でも、同様のプロセスを実装することができる。たとえば、n-of-nのロック解除要件があるアカウントを指定すると、株主は次の方法で会社における株式を現金化することができる。手放そうとしている株主は、会社のマルチシグを入力として設定し、出力0で自分の個人アドレスに返されることが期待される資金を割り当てる必要がある。前の例において説明したように、SINGLEフラグを使用して署名する必要がある。残りのn-1人の株主は、マルチシグ入力を承認するために追加の署名を提供する必要がある。また、離脱する当事者を含まないマルチシグ支出要件(すなわち、n-1-of-n-1)で、残りの株式の価値を表す第2の出力を割り当てる必要がある。条件に同意する各株主は、sighash ALLフラグを使用して入力0においてマルチシグに署名する必要がある。これは、新しいマルチシグ出力を固定するために役立ち、元のマルチシグ入力を検証するために必要なn個の署名を提供する。以下では、たとえば会社が完全に解散する場合など、複数の株主が同時に現金化を希望する可能性がある状況を検討する。

本明細書で説明する方法で様々なsighashフラグを使用すると、署名プロセス内で一種の対話を可能にするため、署名前に当事者間でトランザクションの詳細を説明して合意する事前の話し合いの必要がなくなる。これらの定式化では、マルチシグUTXOの鍵を保持するすべての当事者の協力が依然として必要であるが、sighash ALLフラグを使用する際に必要なすべてのトランザクション情報を完全に事前に決定するよりも、より合理化された署名プロセスが提供される。

しかしながら、単一の入力では、3つ以上の出力に独立して署名することはできなかった。これを実現するためには、署名のプレースホルダを提供するために追加の入力を任意のインデックス位置に配置し、単一のフラグバリアントを使用して任意のインデックス位置における出力に署名できるようにする。これらの入力は、一致する出力を制御したい当事者によって制御される任意のUTXOを参照することができ、入力の価値は、当事者がマルチシグアカウントからの入力の予想シェアに比べて割り当てる出力の値を増やすことによって回収することができる。あるいは、入力は、これらのトランザクションにおいて入力として機能する目的で当事者に明示的に発行される(公称価値の)「トークン(token)」である可能性がある。この目的でトークンを明示的に発行する場合は、たとえば、トークン入力がSINGLEまたはSINLGE|ACP sighashフラグを使用して署名されることを保証するために、署名の生成時に特定のsighashフラグが使用されることを保証する追加の基準をロックスクリプトが含むようにトークンを作成することができる。トークンおよびそれらが使用されるトランザクションは、本出願と同じ日に本出願人によって提出された「Transaction Signature Flags」と題する英国特許出願にさらに詳細に使用および記載されており、これは参照により本明細書に組み込まれる。

本明細書で説明するようにプレースホルダとして使用される入力(公称値、またはペアの出力の値を増やすことによって回復される値を持つ必要がある)は、公称入力と呼ばれる。

同じトランザクションにおいて複数の入力が発生する場合に考慮する必要がある追加の要素は、入力を事前定義できるか否か、または入力を柔軟に保つ必要があるかどうかである。前者の場合、署名を開始する前に当事者間でいくつかの詳細を取り決める必要があるが、ACPフラグのバリアントを使用する必要がないため、展性に対する保護が提供される。対照的に、後者のオプションは、各当事者によって柔軟にトランザクションに署名され、更新されるが、展性を防ぐために追加の対策が必要になる可能性があることを意味する。

固定された入力セット
n-of-nマルチシグアカウントを有する企業株主グループの使用例は上で紹介された。1人の株主が株式を現金化し、残りの資金を残りの株主によって制御される(n-1)-of-(n-1)個のマルチシグアカウントに残すことができるシステムが提供されている。しかしながら、代わりに株主がマルチシグアカウントを完全に解消することを決定した場合、各当事者は独自の出力を個別に設定し、署名することを希望する可能性がある。これをサポートするために、マルチシグ入力に加えて公称入力を含めることができるため、後のインデックス位置における出力を単独で署名することができる。以下の例に示すように、最初と最後に署名する当事者は追加の公称入力を提供する必要はないが、他の各署名者には公称入力が含まれる必要がある。

たとえば、アリス、ボブ、およびチャーリーが、解消したい3-of-3のマルチシグアカウントの鍵を保持する株主であるとする。チェーンの中間で署名する当事者として、ボブは、署名する第1の当事者(アリス)に公称入力の詳細を提供する必要がある。署名プロセスは次のように進行する。
1.アリスは、事前に合意された入力を設定し、インデックス0で出力を定義し、SINGLEフラグを使用してSig Aに署名する。彼女の署名はマルチシグ入力を承認し、出力を固定するが、ボブとチャーリーによって他の出力が追加されることを許可する。

2.ボブは出力アドレスをインデックス1に設定する。彼は、1つはインデックス0のマルチシグ入力を承認するSig B_1と、インデックス1に配置され、ボブの出力を固定するSig B_2との2つの署名を生成する必要がある。チャーリーが後の段階で出力を追加できるように、両方の署名でsighash SINGLEフラグを使用する必要がある。

3.チャーリーは、出力アドレスをインデックス2に設定する。これですべての入力と出力が定義されたため、チャーリーはsighash ALLを使用して署名することができる。これは、ALLフラグが一致する入力を必要とせずに出力を固定することを意味するため、マルチシグ入力に対して1つの署名Sig Cを生成する必要があるだけであることを意味する。この段階では、すべての入力が必要な署名を受信しているため、トランザクションは有効である。

この方式は、第1の当事者と最終当事者がそれぞれアリスとチャーリーの手順に従い、他のすべての当事者がボブのステップに従うことで、より多くの参加者を含めるように容易に拡張することができる。各当事者は独自の出力の値を設定するが、誰もが合意したシェアを超えて受け取ることはできない。方式の最終段階の前に署名する参加者(すなわち、この例ではアリスとボブ)は、マルチシグ入力の支出を検証するために後続の署名を追加する必要があり、追加で割り当てた場合、後の当事者はトランザクションに署名することに同意しない。最終当事者はそれ以上の署名を必要としないが、この段階では値の適切なシェアだけが割り当てられておらず、出力をより高い値に設定すると、十分な入力がなくなるためトランザクションが無効になる。

この方式は、各当事者が出力を設定して署名するための独立した制御と、トランザクションが署名のために各参加者に1回だけ渡される合理化された署名プロセスを提供することができる。それにもかかわらず、トランザクションの最終バージョンを見ていない当事者でも、自分自身の出力を設定する責任は自分たちにあるため、プロセスが公正であることを確信することができる。

動的入力
状況によっては、署名を開始する前にすべての入力を事前定義することが望ましくない(または、可能ではない)場合がある。たとえば、前のセクションにおいて説明したn-of-nマルチシグとは対照的に、m-of-nマルチシグ(m<n)の場合、マルチシグロック解除要件を満たすことができる署名の多くの異なるサブセットが存在する。含まれる公称入力のセットは、設計上、マルチシグ入力に署名を適用する当事者を表す必要があるため、署名プロセスの前にこれらを定義すると、m個の署名の特定のセットのみが有効になることを意味する。これにより、m-of-nマルチシグが組み込むように設計されている柔軟性が制限される。したがって、利用可能な当事者、または署名の提供を選択した当事者に基づいて、署名中に入力を動的に設定できるように、ACP sighashフラグを使用することが望ましい場合がある。

しかしながら、この柔軟性を可能にするということは、署名の順序がより重要になることを意味する。会社の株式アカウントを解散する場合の上記の状況では、マルチシグアカウントに含まれる値全体がトランザクションによって割り当てられるように設定されていたため、チェーンの初期に署名した当事者は、適切な値が割り当てられていることを確認するだけで済んでいた。対照的に、入力と出力を動的に追加することができ、マルチシグアカウントが残りの資金を保持すると予想されるトランザクションの場合、当事者は、後の当事者によって追加された出力を拒否する権利を失うため、プロセスの早い段階で署名したくない可能性がある。

前の例におけるボブのように、チェーンの途中で署名する当事者は2つの別々の署名を提供する必要がある点にも留意されたい。これら(公称入力における)の1つは個人的な出力を固定するために使用され、もう1つはマルチシグ入力を承認する。チェーン内のボブの位置に基づいて、すべてのトランザクション入力が完了する前にこれらの署名が供給された場合、ボブはSINGLE|ACP sighashフラグを使用する必要がある。この場合、後の当事者(チャーリー)は、マルチシグアドレスに対するボブの署名をそのまま残したまま、ボブの単一署名入力-出力ペア(ボブのアカウントへの送金を表す)を削除することが可能になる。ボブの出力を削除した後、チャーリーは通常の共有に加えて、ボブに割り当てられるべき値をチャーリー自身の出力に追加することができる。チャーリーは最後に署名を提供するため、マルチシグ入力の支出を検証するために必要な最終署名を提供し、トランザクションを有効にすることができる。

したがって、チェーンの初期に署名した当事者は、署名後に追加された支出を承認することができず、また、その出力がチェーンにおいて後に当事者によって削除されやすい。この脆弱性を回避するための1つのオプションは、ボブのような中間チェーンの参加者が、最初の署名ラウンド中に1つの署名(入力と出力のペアの署名)のみを提供し、チェーンにおける最終当事者が署名した(すなわち、すべての入力と出力が定義され、sighash ALLが適用された)後、出力の詳細が編集または削除されていないことをチェックするために、トランザクションはすべての中間チェーン当事者に再循環され、編集または削除されている場合はマルチシグ入力の支出を検証するために必要な最終署名を提供する必要がある。

第2のオプションは、入力と出力の数、それらの値、使用される署名フラグなどを含む、各段階においてマルチシグトランザクションの予想されるフォーマットで事前にプログラムされた独立したシステム(たとえば、ソフトウェア)を作成することである。これは、署名の各段階後に次のようないくつかの基準をチェックするために使用することができる。
1.前回のトランザクションの反復からの情報が削除または編集されていないこと。これにより、SINGLE|ACPペアの削除などの攻撃が防止される。
2.署名が正しく適用されていること。これは、ECDSAなどの完全な署名検証、および/または署名プロセスの後続の段階が計画どおりに進むことができるように、特定のsighashフラグが使用されているかどうかのチェックを含むことができる。
3.事前に発行されたトークンが入力として使用される場合、そのトークンは現在のトランザクションにおける使用に有効である(たとえば、そのアウトポイント、その値、OP_RETURN内に埋め込まれた使い捨てコードなどに基づいて)。
4.出力の値が適切であること。これは、前のステップの間に追加された新しい入力によってもたらされる追加の値を考慮する必要がある。

いくつかの実施形態では、これらのチェックは、最終署名が提供された後で、ブロックチェーンに送信する前に実行される。

マルチ署名トランザクションを生成するいずれかの段階においてチェックされた基準のいずれかが満たされない場合、マルチ署名トランザクションはブロックチェーンに送信されない。

図5および図6は、生成可能なマルチ署名トランザクション500、600の例を示している。各トランザクション500、600は、一意のトランザクションIDを有する。「マルチ署名トランザクション(multisignature transaction)」という用語は、本明細書では、マルチ署名ロック解除要件を備えたUTXOを識別する少なくとも1つの入力を備えるブロックチェーントランザクションを指すために使用される。

図5のマルチ署名トランザクション500は、マルチ署名入力の支出を承認するために2人の当事者だけが必要とされるシナリオに適しているが、トランザクションは、たとえば、チームの若手メンバの経費など、第三者(third party)に関連付けられる入力を含む。

図5のマルチ署名トランザクション500は、3つの入力と4つの出力を備える。

インデックス0において、非署名部分と署名部分を備える第1の入力がある。非署名部分は、2-of-nマルチ署名ロック解除要件を有するUTXOを識別するアウトポイントを備える。署名部分において、SINGLE|ACP sighashフラグを有するアリス(A₀)によって提供された署名と、ALL sighashフラグを有するボブ(B)によって提供された署名との、2つの署名が提供されている。ボブの署名はトランザクション500のすべての入力と出力に署名するため、すべての入力と出力が定義された後にのみ提供することができる。

第1の出力はインデックス0において提供され、アリス、ボブ、または若手チームメンバに分配されなかった入力値の残りから必要なトランザクション手数料を差し引いた値に対応するUTXOを備える。このUTXOは、承認当事者のn個の秘密鍵にロックされており、これらの当事者のうち2人が支出を承認する必要があり、すなわち、UTXOはマルチシグ2-of-nロック解除要件を有する。この出力は、マルチシグ入力の値が使い果たされていない場合にのみ必要であることが理解されるであろう。このシナリオでは、たとえSINGLEフラグバリアントのみを使用したとしても、マルチシグ入力(インデックス0)の支出を承認するために署名するすべての当事者がマルチシグ出力にも署名するように、マルチシグ出力(変更がある場合)がインデックス0に配置されることが重要である。マルチシグアカウントが後のインデックス位置に配置された場合、プロセスの早い段階で署名した当事者はマルチシグ出力に署名しないため、適切な量の変更が割り当てられたかどうかを確認できず、後で署名する当事者は、追加の資金を自分たちに割り当てることができる。

トランザクション500のインデックス1には、アリスにすでに割り当てられているUTXOを識別するアウトポイントと、SINGLE|ACP sighashフラグを有するアリスの署名(A₁)を含むロック解除スクリプトとを備える入力がある。インデックス1には、アリスによって定義され、アリスの公開鍵にロックされたUTXOを備える出力もある。出力には、アリスの経費と入力のアウトポイントにおいて示されるUTXOをカバーするために十分な値が必要である。

トランザクション500のインデックス2には、ボブのチームの若手メンバにすでに割り当てられているUTXOを識別するアウトポイントと、SINGLE sighashフラグを有する若手チームメンバ(J_B)の署名を含むロック解除スクリプトを備える入力があるが、SINGLE|ACP sighashフラグを使用することもできる。インデックス2には、若手メンバに割り当てられるUTXOと、UTXOを若手メンバの公開鍵にロックするロックスクリプトを備える出力もある。UTXOは、若手メンバの経費と入力のアウトポイントに示されているUTXOをカバーするために十分である。

入力-出力ペアは、アリスがトランザクションを電子的に署名した後、ボブまたはボブのチームの若手メンバによって提供される。したがって、アリスは単一のsighashフラグのACPバリエーションを使用する必要がある。代わりに、アリスのみが入力-出力ペアを含めることができた場合、たとえば、アリスが若手メンバのすべての経費に対する権限を持っている場合、署名を求められる前にすべての入力が事前にアリスによって知られているため、インデックス0にSINGLE sighashフラグを付けて署名を提供することができる。

インデックス3には入力はないが、ボブの経費に対応するUTXOと、UTXOをボブの公開鍵にロックするロックスクリプトを備える第3の出力がある。ボブは、トランザクション500においてすべての入力と出力が提供された後でのみ、ALL sighashフラグを使用して署名を提供することができる。

図6のマルチ署名トランザクション600は、3人以上の当事者がマルチ署名入力の支出を承認する必要があるシナリオに適している。図示される例では、他の当事者はトランザクション600に寄与していない、すなわち入力を提供していないが、上記の経費の例のように追加の入力が提供され得ることが理解されるであろう。

図6のマルチ署名トランザクション600は、3つの入力と4つの出力を備える。

インデックス0において、署名と非署名部分を備える第1の入力がある。非署名部分は、3-of-nマルチ署名ロック解除要件を有するUTXOを識別するアウトポイントI₀を備える。SINGLE|ACP sighashフラグを有するアリス(A₀)によって提供される署名、SINGLEsighashフラグを有するボブ(B₀)によって提供される第1の署名、およびALL sighashフラグを有するチャーリー(C)によって提供される署名の署名部分において3つの署名が提供されている。チャーリーの署名はトランザクション600のすべての入力と出力に署名するため、すべての入力と出力が定義された後にのみ提供することができる。

第1の出力は、アリス、ボブ、およびチャーリーに分配されなかった、またはトランザクション手数料をカバーするために使用されなかった入力値の残りに対応するUTXOを備えるインデックス0において提供される。このUTXOは、承認当事者のn個の秘密鍵にロックされており、これらの当事者のうち3人が支出を承認する必要があり、すなわち、UTXOはマルチシグ3-of-nロック解除要件を有する。この出力は、マルチシグ入力の値が使い果たされていない場合にのみ必要であることが理解されるであろう。

トランザクション600のインデックス1に、アリスにすでに割り当てられているUTXOを識別するアウトポイントI₁とロック解除スクリプトとを備える第2の入力がある。ロックスクリプトは、SINGLE|ACP sighashフラグを使用して、第2の入力において示されたUTXOロックを解除する、Alice(A₁)の第2の署名を備える。インデックス1にはまた、アリスに割り当てられるUTXOと、UTXOをアリスの公開鍵にロックするロックスクリプトを備える第2の出力がある。UTXOは、アリスの経費と第2の入力のアウトポイントに示されているUTXOをカバーするために十分である。

トランザクション600のインデックス2には、ボブにすでに割り当てられているUTXOを識別するアウトポイントI₂とロック解除スクリプトとを備える第3の入力がある。ロックスクリプトは、ボブ(B₁)の第2の署名を備え、これは、第2の入力において示されたUTXOのロックをSINGLE sighashフラグを使用して解除する。インデックス1にはまた、ボブに割り当てられるUTXOと、UTXOをボブの公開鍵にロックするロックスクリプトで構成される第2の出力がある。UTXOは、ボブの経費と第2の入力のアウトポイントに示されているUTXOをカバーするために十分である。

この入力-出力ペアは、アリスがインデックス0において署名を提供した後、ボブによって提供される。したがって、アリスは単一のsighashフラグのACPバリエーションを使用する必要がある。あるいは、インデックス1のアウトポイントがトランザクション生成前にすでに知られている場合、アリスは署名を提供するよう要求される前にすべての入力を知っているため、アリスはSINGLE sighashフラグを使用してインデックス0に署名を提供することができる。

インデックス3において、入力はないが、チャーリーの経費に対応するUTXOと、UTXOをチャーリーの公開鍵にロックするロックスクリプトを備える第4の出力がある。チャーリーは、トランザクション600におけるすべての入力と出力が提供された後でのみ、ALL sighashフラグを使用してインデックス0に署名を提供することができる。

ここで、理論的には、チャーリーは自分の出力をインデックス3に追加する前に、アリスとボブの経費に対応するインデックス1と2における入力と出力のペアを削除できる点に留意することが重要である。チャーリーは、3セットすべての経費の支払いを受け取ることができるように、自分のアドレスに割り当てる出力の価値を増やすことができる。マルチシグアカウント(A₀とB₀)の使用を承認するためにインデックス0においてアリスとボブによって提供された署名はトランザクションに残るため、チャーリーが独自の署名を追加することによってマルチシグ入力署名要件を満たすことができる。

階層型マルチシグ
状況によっては、すべての当事者が1回のパスにおいて署名を追加するときに作成される自然な階層を使用することが有益な場合があり、この場合、初期の署名者には後の当事者の支出を拒否する機会がない。この非対称構造は、当事者がマルチシグアカウント内で同等の権限を有していない状況に適している可能性がある。

この一例として、通常の事業経費をカバーするために保有される会社の当座預金アカウントが挙げられる。アカウントは、m-of-nのマルチシグ支出要件を有し、各署名者が階層および署名手順において特定の位置を占めている場合がある。たとえば、アリス、ボブ、チャーリーが上級マネージャであり、それぞれの若手従業員のチームがあるとする。デリラは会社のCFOである。アリス、ボブ、チャーリー、およびデリラは全員、会社のマルチシグ当座預金アカウントの有効な鍵を保持している。これらの当事者は主な署名者であり、通常は毎月役割を果たすが、追加の4つの有効な鍵を上級財務チームの間で保持することができ、主な署名者が不在の場合には彼らが代わりに行動することができる。これにより、4-of-8のロック解除要件を有するマルチシグアカウントが得られる。経費を提出するには、最も若手のメンバから始まる正式な手順がある。
1.アリス、ボブ、およびチャーリーのチームの若手メンバは、以下に示される「若手」トランザクションフォーマットに基づいて、毎月の指定日までに個人経費請求を提出する必要がある。
〇経費は、公称入力を伴うSINGLE|ACP署名付き入力-出力ペアの形式をとる必要がある。
〇出力は、従業員の経費請求と(入力値と比較して)等しい値を持つ必要があり、従業員が所有するアドレスに割り当てられる必要がある。
〇経費の正確な詳細は、たとえば経費データのハッシュを含めることによって、出力のOP_RETURNにおいて参照することができる。

2.アリス、ボブ、およびチャーリーは、それぞれのチームから提出された経費を照合し、以下の「マネージャ」フォーマットに基づいてトランザクションを作成するために次の手順を実行し、トランザクションは、月内の第2の期限までにデリラに提出する必要がある。
〇マネージャが承認しない経費は、経費セットから削除される。
〇マネージャが自分自身の経費、またはチームを代表して発生した経費を提出したい場合、公称入力を使用して追加のSINGLE|ACP署名付き入力-出力ペアを作成することができる。
〇承認されたすべての経費は、インデックス1から始まるトランザクション内の一致する入力-出力位置に設定する必要がある。
〇マネージャは、会社のマルチシグアカウントを入力0に含める必要がある。異なるマルチシグ署名者によって個別に作成された署名間の競合を避けるために、インデックス0における出力を事前に決定する必要がある。
●たとえば、会社がHDウォレットを有している場合、鍵構造の特定の範囲および世代における次のインデックスとなるように、連続する月ごとに秘密鍵を定義することができる。
●出力0に割り当てられる値は、(事前に合意された)少量のみである必要がある。マネージャは、すべての経費を追加した後の最終的なアカウント残高がいくらになるかわからない。すべての経費が判明したら、デリラは第2の(より大きい)出力を新しいアドレスに割り当てる。
●マネージャは、チームがその月に経費を提出していない場合でも、マルチシグ入力(および、事前定義された出力)にSINGLE|ACP署名を提供する必要がある。

3.デリラは、アリス、ボブ、およびチャーリーから受け取ったマネージャのトランザクションを照合し、以下の会社テンプレートと一致する結合トランザクションを形成する。
〇デリラは、マルチシグ入力用に、アリス、ボブ、およびチャーリーからの署名を結合する必要がある。
〇マネージャとチームメンバからのすべての経費は、インデックス1から始まる、一致する入力-出力位置に配置される。
〇デリラは最後に署名するため、追加の公称入力を必要とせずに追加の出力を追加し得る。これらの出力は、彼女の個人的な経費、ならびに家賃および光熱費などの会社の他の支出を含み得る。
〇デリラは、マルチシグ入力からの残りの値を、最終出力において定義された事前に合意されたマルチシグ会社アカウントに割り当てる必要がある。
〇最後に、デリラは、マルチシグ入力を承認し、トランザクションを検証するために必要な最終署名を生成することができる。セキュリティのため、これはsighash ALLを使用して署名する必要がある。

この設定により、会社全体の経費を単一のトランザクション内で支払うことができ、全会社のアカウントが毎月ブロックチェーン上に表示され、簡潔で不変の監査証跡が提供される。この例では、SINGLE|ACPフラグをマルチシグ入力と組み合わせるときに固有の階層構造を利用する。ここでは、若手メンバがマネージャの経費請求を承認する必要がなく、マネージャが若手チームメンバの経費をチェックして承認できるようになる。同様に、CFOは相互チェックを必要とせずに、若手、マネージャ、およびチームの経費をチェックすることができる。

トランザクションが完了する前にマネージャが署名するという要件により、マネージャは他のマネージャまたはCFOからの支出を拒否することができなくなるが、マルチシグ要件にマネージャの署名を含めることには利点がある。毎月署名を提出するということは、チームの経費を提出するか、何もなかったことを確認する義務があることを意味し、これにより、一定の説明責任が生じ、経費の漏れがないことが保証される。すべてのマネージャが毎月マルチシグアカウントの署名を提出することを要求することによって、システムはCFOによって完全に制御される1-of-1アカウントとして効果的に動作することは注目に値する。しかしながら、たとえば、3人のマネージャ全員が署名し、CFOがトランザクションを完了して署名し、さらに5人の取締役会メンバからさらに2人の署名が必要になるように、マルチシグアカウントの要件を増やすのは簡単である。これは、CFOにチェックが課されることを意味するが、これは特定の状況では適切であり得る。別の方法としては、最終的な署名鍵がしきい値システムである場合、当事者のグループが秘密鍵の共有を保持し、有効な署名を作成するために一定数のグループメンバのサブセットが協力する必要がある。

本明細書で説明する署名プロセスは、合理化されたシステムも提供し、各当事者が独自に機能するトランザクションテンプレートを作成できるため、どの段階でもグループの共同作業は必要ない。各レベルの当事者が毎月それまでに行動する必要がある期限があることを除いて、署名の順序にはほとんど制限がない。すべての署名は単一のラウンドの署名内で収集され、後戻りする必要はない。すべての情報は一方の当事者から他方の当事者に直接通信され、通信は一方向になる可能性がある。これらの機能は、システム全体の勢いを制限することなく、個人が経費を提出する際に多くの自由を維持できることを意味する(たとえば、同僚間での署名に決まった順序はない)。さらに、最小限のコミュニケーション要件は、ディスカッションのスケジュール調整が難しい大規模なグループにとって特に有益である。

この署名手順は、高度な署名システムを実現するために複数のsighashフラグを組み合わせることができる方法の包括的な例を提供する。特に、本明細書で説明するシステムは、個人が独立性を失うことなく共同トランザクションにおいて協力する機会を提供する。また、部分的に形成され、部分的に署名されたトランザクションの交換が、sighash ALLに署名する際に必要な事前対話の代わりにコミュニケーションとしてどのように機能し、署名手順を大幅に合理化できるかについても概説している。

オフチェーンおよびオンチェーンのアクション
図7は、図6に示される形式のマルチ署名トランザクションを生成する例示的な方法を示しており、ここでは、入力は事前に知られておらず、すなわち、動的入力を伴うトランザクションである。左側に示されている方法ステップは、参加当事者のユーザデバイスによってオフチェーンで実装され、右側のステップはブロックチェーンノードによってオンチェーンで実装される。

ステップS702において、第1の入力のアウトポイントが定義され、これで示されるUTXOはマルチシグロック解除要件を有する。第1の出力も定義され、これは、第1の入力におけるUTXOと同じ署名要件を有する新しいマルチ署名アドレスである。出力の値は、第1の入力の値から他の出力の予想される値と適切なトランザクション手数料を引いたものと等しくなければならない。

ステップS704において、第1の入力のアウトポイントにおいて示されているUTXOのロックを解除するために必要な署名はすべて、第1の入力のUTXOの一部が送金される当事者に関連付けられているものを除いて、第1の入力において提供される。図7の例では、2つの追加の出力があるため、ステップS704においてm-2個の署名が提供される。後続の入力がまだ定義されていないため、これらの署名にはSINGLE|ACP sighashフラグが付いている。しかしながら、いずれかの当事者によって署名される前にすべての入力が定義されている場合、すべての入力がすでに提供されており、メッセージに含めることができるため、これらの署名にSINGLEフラグを付けることができる。第1のインデックスにおいて提供されるこれらの署名は、インデックス0の出力のみと、インデックス0における入力のみ(SINGLE|ACP sighashフラグの場合)、またはトランザクションのすべての入力(SINGLE sighashフラグの場合)に署名する。

第2の入力のアウトポイントはステップS706において定義される。このアウトポイントは、単一署名のロック解除要件を有し、独立して制御する出力を割り当てたい当事者によって制御されるUTXOを示している。たとえば、図6のアウトポイントI₁は、以前にアリスに割り当てられたUTXOに関連付けられており、ある量のデジタル資産が出力としてアリスに割り当てられる入力-出力ペアのアウトポイントである。

ステップS708において、第2の入力におけるアウトポイントによって示されるUTXOのロックを解除するための署名に単一のsighashフラグが提供される。すべての入力が知られているため、sighashフラグは、トランザクションのすべての入力が署名によって署名されるようにSINGLEにすることもでき、インデックス1における入力のみが署名されるようにSINGLE|ACPにすることもできる。どちらの場合も、インデックス1における出力のみが署名される。動的入力を伴うトランザクションにおいてSINGLE|ACPを使用すると、たとえ第1の入力に署名する最後から2番目の当事者によって入力-出力ペアが提供される場合でも、最終当事者が複数のアドレス間でシェアを分割するオプションに署名できるようにするため、より汎用性が高くなり、たとえば、最終当事者がチームメンバの経費を支払う必要がある場合などに当てはまり得る。また、SINGLE|ACPを使用することにより、入力-出力ペアを任意の時間的順序で提供できるようになるため、中央当事者が入力-出力ペアを収集してマルチ署名トランザクションをコンパイルする場合に有利である。

ステップS708において、第1の入力のアウトポイントにおいて示されたUTXOのロックを解除するためのm-1番目の署名が第1の入力において提供される。この署名は、ステップS706において入出力ペアを提供する当事者に関連付けられる。

ステップS710において、最終出力がインデックス2において定義される。この出力は対応する入力を有していない。最終出力の提供を担当する当事者は、これまでマルチ署名UTXOに署名するための署名を提供していなかったが、ステップS712において、トランザクションのすべての入力とすべての出力に署名するインデックス0の第1の入力においてALL sighashフラグを使用して最終署名を提供する。最終署名が提供された後は、トランザクションをさらに変更することはできない。

次いで、トランザクションはブロックチェーンノードに送信され、ブロックチェーンノードは、ステップS714において、上で説明したように、ロックスクリプトおよびロック解除スクリプトを実行することによってトランザクションを検証する。検証されると、ステップS716において、トランザクションはブロックチェーンに公開される。

図7に示される方法のステップは変更され得ることが理解されるであろう。たとえば、第2の入力を定義するステップ、ステップS706は、m-2個の署名のうちの少なくとも1つが第1の入力において提供される前、すなわち、第1の入力に出力署名を提供していない少なくとも1人の当事者の前に実施され得る。第1の入力において署名を提供するステップ、ステップS704は、各署名が個別のステップにおいて提供される複数のステップにおいて実施され得る。これらの署名の一部は、第2の入力を承認する当事者に応じて、第2の入力の前に提供され、一部はその後に提供され得る。第1の入力に対する署名を提供するためのステップ、ステップS708は、2つの別個のステップを備えてもよく、ステップS706およびS708と同様の追加の入力-出力ペアを提供するための追加のステップによって分離されてもよい。

図8は、マルチ署名トランザクション600を生成するための例示的なシステムを示している。

本システムは、トランザクション600に寄与する権限を与えられた当事者によってそれぞれ動作される3つのユーザデバイス802a、802b、802cと、ブロックチェーンノード(図示せず)とを備える。各ユーザデバイス802a、802b、802cは、コンピュータプログラムを記憶するためのメモリと、コンピュータプログラムが実行される少なくとも1つのプロセッサとを備える。コンピュータプログラムは、実行されると、当事者またはユーザが使用できるようにクライアントアプリケーション300をレンダリングするようにプロセッサを構成する。これらの当事者は、署名を提供することによってトランザクション600の入力および出力を承認するため、承認当事者と呼ばれ得る。

トランザクションの第1の出力、第1のアウトポイント、および第1の入力の第1の署名は、第1の当事者(アリス)によってクライアントアプリケーション300を介して第1のユーザデバイス802aにおいて定義され、インデックス0に含まれる。トランザクションの入力は署名前には知られていないため、第1の入力において提供される署名はSINGLE|ACPフラグを有する。第1の出力は、どの当事者にも割り当てられておらず、トランザクション手数料の支払いにも使用されず、複数の公開鍵にロックされているデジタル資産の残りの部分である。

アリスはまた、第1のユーザデバイス802aにおいて、インデックス1に含めるための入力-出力ペアを定義する。この入力-出力ペアは、アリスの公開鍵にロックされたUTXOを定義する第2の出力と、第2の入力とを備える。ここでも、すべての入力が知られているわけではないため、アリスはSINGLE|ACPフラグを使用して署名する。アリスが署名を提供する前にすべての入力が知られている場合、アリスはインデックス0とインデックス1の両方においてSINGLE sighashフラグを使用し得る。

次いで、第1のユーザデバイス802aは、部分的に完了したトランザクションを第2のユーザデバイス802bに送信する。

第2のユーザデバイス802bは、第2の当事者(ボブ)によって動作される。第2の当事者は、第2のユーザデバイス802b上で動作するクライアントアプリケーション300を介して、ユーザデバイス802bがトランザクション600のインデックス2に含める第3の入力および第3の出力を定義する。また、第2のユーザデバイス802bは、インデックス0において第1の入力に第2の当事者の署名を提供する。ボブは署名する最終当事者ではないため、ボブによって提供される各署名は、SINGLE|ACPフラグを有し、さらなる入力が提供され得る。しかしながら、トランザクションに署名する最終当事者がそれ以上の入力を提供しないことが知られている場合、または、前記当事者が、さらなる入力を提供することが承認されていない場合、ボブはSINGLEフラグを使用して署名することができる。次いで、部分的に完了したトランザクションは、第3のユーザデバイス802cに送信される。

第3のユーザデバイス802cは、第三者(チャーリー)によって動作される。第三者は、第3のユーザデバイス802c上で動作するクライアントアプリケーション300を介して、ユーザデバイス802cがトランザクション600のインデックス3に含める第4の出力を定義する。また、第3のユーザデバイス802cは、トランザクション600のすべての入力および出力を承認するために、インデックス0の第1の入力に第三者の最終署名を提供する。

最終署名が入力に含まれると、トランザクションは有効になる。第3のユーザデバイス802cは、現在完了しているトランザクション600を検証のためにブロックチェーンノードに送信する。

本システムは、トランザクション600に寄与するために追加の当事者によって動作される追加のユーザデバイスを含み得る。これらの当事者は、マルチ署名入力(第1の入力)に署名することを承認されてもよく、トランザクションのための入力-出力ペアを提供することのみを承認されてもよく、これは、マルチ署名入力に署名することを承認された当事者によって削除され得る。

第1の入力および第1の出力の非署名部分は、第1の入力のアウトポイントに署名する権限を有する任意の当事者によって提供され得る。この当事者は、一定量のデジタル資産を自分自身に送金するための入力-出力ペアを提供する必要もない。上記の例では、アリスは第1の出力を定義し、インデックス0において彼女の署名を提供することができるが、彼女自身がデジタル資産を必要としない場合、たとえば支払われる経費がない場合、彼女はインデックス1において入力-出力を提供しない。この時点で、部分的に完了したトランザクションは第2のユーザデバイス802bに送信され、そこでボブの入力-出力ペアがインデックス1に提供される。

いくつかの実施形態では、上述したマルチシグアカウントを解消する場合のように、第1の入力において参照されるUTXO全体が個々の当事者に送金されることになる。そのような実施形態では、アリスによってインデックス0において提供される出力は、アリスの公開鍵にロックされるデジタル資産の量を備える。アリスが第1の入力と第1の出力を定義した後、部分的に完了したトランザクションが第2のユーザデバイスに送信され、そこでボブが入力-出力のペアを定義し、これをインデックス1に含める。

トランザクションに寄与する権限を与えられた当事者に、その当事者が寄与する権限を持っていることを証明するトークンを提供すると有利な場合がある。トークンは、トークン発行トランザクションにおいて発行された承認された当事者の公開鍵にロックされたUTXOである。上記の例ではCFOのデリラであり得る、トランザクションを調整する当事者が、トークン発行トランザクションを生成する。

トークントランザクションの各出力は、マルチ署名トランザクションにおいてトークンに署名する際、または入力-出力のペアを提供する際に当事者によって提供される必要があるsighashフラグを定義する署名条件を備え得る。トークンの使用を承認する際に使用されるsighashフラグが、署名要件において定義されたsighashフラグと一致しない場合、トランザクションは有効として返されない。

トークンの価値は小さいため、トークンが後で使用されなかった場合にトークン発行者によって失われるデジタル資産の量は無視できる。

当事者がマルチ署名入力以外のトークンを備えない入力を定義した場合、対応する入力-出力ペアはCFOによって削除されてもよく、マネージャがトランザクションに経費を含めることを拒否することもできる。同様に、現在のトランザクションにおいて使用できないトークンは削除することができる。トランザクションに最終署名を含むCFOのコンピュータデバイスは、最終署名を提供する前に入力が有効なトークンであることをチェックし得る。

上で説明した例では、マルチ署名入力はm-of-nロック解除要件を有し、すなわち、使用のためにUTXOのロックを解除するために、UTXOがロックされているn個の署名のうちmが提供される必要がある。しかしながら、上記のトランザクションは、n-of-nのロック解除要件を伴う入力を有し得、UTXOがロックされているn個の署名すべてを使用する必要があることが理解されるであろう。

第2の、または後続のインデックスにおいて提供されるUTXOは、上記の例のような単一の署名ロック解除要件ではなく、マルチ署名ロック解除要件を有し得る。この場合、入力の非署名部分はUTXOを識別するアウトポイントを備え、署名部分はマルチ署名要件を満たすための単一のsighashフラグを有する2つ以上の署名を備える。

上記のトランザクションは経費の提出に関連して説明されているが、マルチ署名トランザクションは、少なくとも1つの入力がマルチ署名ロック解除要件を有し、当事者が独自の出力を定義できる他のシナリオにおいても使用できることが理解されよう。

トランザクション手数料
上で説明したように、トランザクション手数料はトランザクションのペアである必要がある。この料金は様々な方法で提供することができる。

トランザクション手数料はマルチ署名入力によって全額カバーすることができる。すなわち、第1のインデックスの出力におけるデジタル資産の量は、マルチ署名入力量から、他の当事者に割り当てられたトランザクションの他のすべての出力およびトランザクション手数料を差し引いたものに等しくなる。

任意の所与のトランザクションのトランザクション手数料の額は、トランザクションのサイズ、すなわち入力と出力の数に基づいて計算される。したがって、入力と出力の数が変化する可能性があるトランザクションの場合、第1の出力を提供する時点ではトランザクション手数料は知られておらず、したがって、トランザクション手数料として準備された金額が手数料を全額カバーする場合もあれば、カバーしない場合もある。この場合、第1の出力を提供する時点では、料金の見積もりのみがわかる。

トランザクション手数料を確実にカバーするために、見積もりよりも大きい金額がトランザクション手数料として準備される可能性がある。しかしながら、これにより不必要に多額のトランザクション手数料が支払われる可能性がある。

代わりに、トランザクション手数料を少なくとも部分的にカバーするために、1つまたは複数の他の入力が使用され得る。複数の入力を使用してトランザクション手数料をカバーする方法の例としては、次のようなものがある。
●見積もりを使用してマルチ署名入力の一部をトランザクション手数料に準備し、すべての入力-出力ペアと最終出力が提供された後、必要な金額のトランザクション手数料入力を提供する。この入力は、NONEまたはALL sighashフラグを使用して署名することができる。
●見積もりを使用してマルチ署名入力の一部をトランザクション手数料に準備し、すべての入力-出力ペアと最終出力が提供された後、トランザクション手数料入力-出力ペアが提供され、入力は必要な金額よりも大きく、トランザクション手数料が支払われた後の出力は入力の残りと等しくなる。出力は、トランザクション入力に署名した当事者に返される。この入力は、SINGLE、SINGLE|ACP、およびALL sighashフラグのいずれかを使用して署名することができる。
●トランザクション手数料にマルチ署名入力を使用せず、トランザクション手数料全体をカバーするためにトランザクション手数料入力またはトランザクション手数料入力-出力ペアを使用する。前述のように、これらは他のすべての入力と出力が提供された後に提供される必要がある。
●マルチ署名入力は、マルチ署名入力と最終出力を備える第1のインデックスのみのトランザクション手数料の一部をカバーするために使用される。すなわち、マルチ署名入力は、1つの入力と2つの出力に関連付けられるトランザクション手数料をカバーする。後続の入力の各々は、入力-出力ペアに関連付けられるトランザクション手数料をカバーするために使用され、そのため、入力-出力ペアごとの出力におけるデジタル資産の量は、入力と、前記入力に署名する当事者に割り当てられたマルチ署名入力の量から、入力-出力ペアのトランザクション手数料を差し引いたものに等しくなる。

トランザクション手数料は、マルチ署名トランザクションの入力の他の組合せを使用して支払われ得ることが理解されるであろう。

結論
開示された技法の他の変形または使用事例は、本明細書の開示が与えられれば、当業者には明らかになり得る。本開示の範囲は、記載された実施形態によって限定されるものではなく、添付の特許請求の範囲によってのみ限定される。

たとえば、上記のいくつかの実施形態は、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104に関して説明されている。しかしながら、ビットコインブロックチェーンはブロックチェーン150の特定の一例であり、上記の説明は一般に任意のブロックチェーンに適用し得ることが理解されるであろう。すなわち、本発明は決してビットコインブロックチェーンに限定されるものではない。より一般的には、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104に対する上記の言及は、それぞれ、ブロックチェーンネットワーク106、ブロックチェーン150、およびブロックチェーンノード104の言及と置き換えられ得る。ブロックチェーン、ブロックチェーンネットワーク、および/またはブロックチェーンノードは、上述のように、ビットコインブロックチェーン150、ビットコインネットワーク106、およびビットコインノード104の記載された特性のうちのいくつか、またはすべてを共有し得る。

本発明の好ましい実施形態では、ブロックチェーンネットワーク106はビットコインネットワークであり、ビットコインノード104は、ブロックチェーン150のブロック151を作成、公開、伝搬、および記憶する上述の機能の少なくともすべてを実施する。これらの機能のすべてではなく、1つまたは一部のみを実施する他のネットワークエンティティ(または、ネットワーク要素)が存在する可能性も排除されない。すなわち、ネットワークエンティティは、ブロックを作成および公開することなく、ブロックを伝搬および/または記憶する機能を実施し得る(これらのエンティティは、好ましいビットコインネットワーク106のノードとはみなされないことを思い出されたい)。

本発明の他の実施形態では、ブロックチェーンネットワーク106はビットコインネットワークでなくてもよい。これらの実施形態では、ノードが、ブロックチェーン150のブロック151を作成、公開、伝搬、および記憶する機能のすべてではないが、少なくとも1つまたはいくつかを実施し得ることを排除するものではない。たとえば、それらの他のブロックチェーンネットワークでは、「ノード」は、ブロック151を作成および公開するが、それらのブロック151を記憶および/または他のノードに伝搬しないように構成されたネットワークエンティティを指すために使用され得る。

さらにより一般的には、上記の「ビットコインノード」104という用語への言及は、「ネットワークエンティティ」または「ネットワーク要素」という用語に置き換えられてよく、そのようなエンティティ/要素は、ブロックの作成、公開、伝搬、および記憶の役割のいくつか、またはすべてを実施するように構成されている。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード104を参照して上で説明したのと同じ方法で、ハードウェアに実装され得る。

上記の実施形態は、単なる例として説明されたものであることが理解されよう。より一般的には、以下のステートメントのいずれか1つまたは複数に従って、方法、装置、またはプログラムが提供され得る。

ステートメント1.ブロックチェーンのマルチ署名トランザクションを生成するためのコンピュータ実装方法であって、本方法は、マルチ署名トランザクションの第1の入力-出力ペアの第1の出力、および第1の入力の非署名部分を受信するステップであって、第1の入力が、マルチ署名要件をエンコードする第1の使用可能トランザクション出力へのアウトポイントを備える、ステップと、マルチ署名要件の公開鍵に対応する秘密鍵を使用して、第1の入力-出力ペアの第1の出力、および第1の入力の非署名部分には電子署名するが、マルチ署名トランザクションの任意の他の出力には電子署名せず、それによって、(i)関連付けられるsighash単一フラグ、および(ii)マルチ署名要件に関して有効な少なくとも1つの他の署名が第1の入力の署名部分に含まれる場合に、マルチ署名要件を満たすための署名を生成するステップと、マルチ署名トランザクションの第2の入力-出力ペアの第2の出力、および第2の入力の非署名部分を受信するステップであって、第2の入力が、少なくとも1つの署名を必要とする署名要件をエンコードする第2の使用可能トランザクション出力へのアウトポイントを備える、ステップと、署名要件の公開鍵に対応する秘密鍵を使用して、マルチ署名トランザクションの第2の入力-出力ペアの第2の出力、および第2の入力の非署名部分には電子署名するが、マルチ署名トランザクションの任意の他の出力には電子署名せず、それによって、関連付けられるsighash単一フラグが第2の入力の署名部分に含まれる場合に、署名要件を少なくとも部分的に満たすための署名を生成するステップとを備える、コンピュータ実装方法。

ステートメント2.マルチ署名トランザクションの第2の入力-出力ペアの第2の出力、および第2の入力の非署名部分が受信された後、関連付けられる入力がないマルチ署名トランザクションの最終出力を受信するステップと、マルチ署名要件の最終公開鍵に対応する最終秘密鍵を使用して、マルチ署名トランザクションのすべての出力、およびすべての入力の非署名部分に電子署名し、それによって、(i)関連付けられるsighash allフラグ、および(ii)マルチ署名要件を満たすための少なくとも署名が第1の入力の署名部分に含まれる場合に、マルチ署名条件を満たすための最終署名を生成するステップとをさらに備える、ステートメント1に記載のコンピュータ実装方法。

ステートメント3.本方法が、最終署名が生成された後、マルチ署名トランザクションをブロックチェーンノードに送信するステップをさらに備える、ステートメント2に記載のコンピュータ実装方法。

ステートメント4.署名要件が複数の署名を必要とする場合、署名要件の別の公開鍵に対応する別の秘密鍵を使用して、マルチ署名トランザクションの第2の入力-出力ペアの第2の出力、および第2の入力の非署名部分には電子署名するが、マルチ署名トランザクションの任意の他の出力には電子署名せず、それによって、関連付けられるsighash単一フラグおよび署名条件を少なくとも部分的に満たすための署名を第2の入力の署名部分に含める場合に、署名条件を部分的に満たすための別の署名を生成するステップをさらに備える、ステートメント1から3のいずれか1つに記載のコンピュータ実装方法。

ステートメント5.マルチ署名要件を満たす少なくとも1つの他の署名のうちの少なくとも1つが、sighash single-anyone can payフラグを有する第1の入力の署名部分において受信された後に、第2の入力の非署名部分が受信され、それによって、マルチ署名トランザクションの第1の出力のみと、第1の入力の非署名部分のみに署名する、ステートメント1から4のいずれか1つに記載のコンピュータ実装方法。

ステートメント6.署名要件を少なくとも部分的に満たすための署名の後に、追加の入力が提供され、署名要件を少なくとも部分的に満たすための署名が、single-anyone can payフラグに関連付けられており、それによって、マルチ署名トランザクションの第2の出力、および第2の入力の非署名要件のみに署名する、ステートメント1から5のいずれか1つに記載の方法。

ステートメント7.第1の使用可能な出力の一部が、第2の入力の非署名部分に署名する当事者に割り当てられる、ステートメント1から6のいずれか1つに記載の方法。

ステートメント8.マルチ署名トランザクションの第2の入力が、第2の使用可能トランザクション出力の残りのデジタル資産を、第2の入力の非署名部分に署名した当事者に返す、ステートメント1から7のいずれか1つに記載の方法。

ステートメント9.第2の使用可能トランザクション出力において定義されるデジタル資産の量が、ブロックチェーンを維持するブロックチェーンネットワークの現在のトランザクション手数料に基づいて設定される、ステートメント1から8のいずれか1つに記載の方法。

ステートメント10.すべての出力、および入力のすべての非署名部分が提供された後、ブロックチェーンを維持するブロックチェーンネットワークの現在のトランザクション手数料を少なくとも部分的に支払うためのトランザクション手数料入力の非署名部分を提供するステップをさらに備え、トランザクション手数料入力が、第3の使用可能トランザクション出力へのアウトポイントを備え、第3の使用可能トランザクション出力において定義されるデジタル資産の量が、現在のトランザクション手数料に基づいて設定される、ステートメント1から9のいずれか1つに記載の方法。

ステートメント11.第3の使用可能トランザクション出力において定義されるデジタル資産の量が、トランザクション手数料入力によって支払われるトランザクション手数料の一部よりも大きく、本方法が、第3の使用可能トランザクション出力の残りを、トランザクション手数料入力の非署名部分に署名する当事者に再割当てするためのトランザクション手数料出力を提供するステップをさらに備える、ステートメント10に記載の方法。

ステートメント12.第3の使用可能トランザクション出力において定義されるデジタル資産の量が、トランザクション手数料入力によって支払われるトランザクション手数料の一部に等しく、トランザクション手数料入力が出力に関連付けられない、ステートメント10に記載の方法。

ステートメント13.第2の使用可能トランザクション出力が、当事者がマルチ署名トランザクションに参加することを承認するために、第2の入力の非署名部分に署名する当事者に割り当てられるトークンである、ステートメント1から12のいずれか1つに記載の方法。

ステートメント14.トークンのロックスクリプトが、トークンを有効に使用するために使用する必要があるsighashフラグを定義する、ステートメント13に記載の方法。

ステートメント15.トランザクション基準が満たされていることをチェックするステップをさらに備え、基準が満たされた場合にのみマルチ署名トランザクションがブロックチェーンに送信され、基準が、マルチ署名トランザクションの以前の反復からの情報が削除および/または変更されていない、提供された署名が検証される、正しいsighashフラグが署名に関連付けられており、正しい署名により、方法の後続の段階が必要に応じて実施されることが可能になる、有効なトークンが使用されている、マルチ署名トランザクションの出力の値が適切である、のうちの少なくとも1つを備える、ステートメント3またはそれに依存する任意のステートメントに記載の方法。

ステートメント16.ブロックチェーンのマルチ署名トランザクションを生成するためのコンピュータシステムであって、1つまたは複数のプロセッサを備え、プロセッサが、マルチ署名トランザクションの第1の入力-出力ペアの第1の出力、および第1の入力の非署名部分を受信することであって、第1の入力が、マルチ署名要件をエンコードするブロックチェーントランザクションの使用可能な出力へのアウトポイントを備える、受信することと、マルチ署名要件の公開鍵に対応する秘密鍵を使用して、第1の入力-出力ペアの第1の出力、および第1の非署名入力には電子署名するが、マルチ署名トランザクションの任意の他の出力には電子署名せず、それによって、(i)関連付けられるsighash単一フラグ、および(ii)マルチ署名要件を満たす少なくとも1つの他の署名が第1の入力の署名部分に含まれる場合に、マルチ署名要件を満たすための署名を生成することと、マルチ署名トランザクションの第2の入力-出力ペアの第2の出力、および第2の入力の非署名部分を受信することであって、第2の入力が、少なくとも1つの署名を必要とする署名要件をエンコードするブロックチェーントランザクションの使用可能な出力へのアウトポイントを備える、受信することと、署名要件の公開鍵に対応する秘密鍵を使用して、マルチ署名トランザクションの第2の入力-出力ペアの第2の出力、および第2の入力の非署名部分には電子署名するが、マルチ署名トランザクションの任意の他の出力には電子署名せず、それによって、関連付けられるsighash単一フラグを第2の入力の署名部分に含める場合に、署名条件を少なくとも部分的に満たすための署名を生成することとを行うように構成される、コンピュータシステム。

ステートメント17.1つまたは複数のプロセッサが、マルチ署名トランザクションの第2の入力-出力ペアの第2の出力、および第2の入力の非署名部分が受信された後、関連付けられる入力がないマルチ署名トランザクションの最終出力を受信することと、マルチ署名要件の最終公開鍵に対応する最終秘密鍵を使用して、マルチ署名トランザクションのすべての出力、およびすべての入力の非署名部分に電子署名し、それによって、(i)関連付けられるsighash allフラグ、および(ii)マルチ署名要件を満たすための少なくとも署名が第1の入力の署名部分に含まれる場合に、マルチ署名条件を満たすための最終署名を生成することとを行うようにさらに構成される、ステートメント16に記載のコンピュータシステム。

ステートメント18.コンピュータシステムが、ブロックチェーントランザクションを検証するためのブロックチェーンノードをさらに備え、1つまたは複数のプロセッサが、最終署名が生成された後にマルチ署名トランザクションをブロックチェーンノードに送信するように構成される、ステートメント17に記載のコンピュータシステム。

ステートメント19.署名要件に複数の署名が必要な場合、システムが、署名要件の別の公開鍵に対応する別の秘密鍵を使用して、マルチ署名トランザクションの第2の入力-出力ペアの第2の出力、および第2の入力の非署名部分には電子署名するが、マルチ署名トランザクションの任意の他の出力には電子署名せず、それによって、関連付けられるsighash単一フラグおよび署名条件を少なくとも部分的に満たすための署名を第2の入力の署名部分に含める場合に、署名条件を部分的に満たすための別の署名を生成するようにさらに構成される、ステートメント16から18のいずれか1つに記載のコンピュータシステム。

ステートメント20.1つまたは複数のプロセッサが単一のコンピュータデバイスに備えられる、ステートメント16から19のいずれか1つに記載のコンピュータシステム。

ステートメント21.コンピュータシステムは第1のユーザデバイスである、ステートメント16に記載のコンピュータシステム。

ステートメント22.コンピュータシステムが、ステートメント2またはステートメント3に記載の方法を実施するように構成された第2のユーザデバイスを備える、ステートメント21に記載のコンピュータシステム。

ステートメント23.コンピュータシステムは、第2の入力の非署名部分が受信される前に、sighash single-anyone can payフラグを有する第1の入力の署名部分に含めるためのマルチ署名要件を満たす少なくとも1つの他の署名のうちの少なくとも1つを生成するように構成された第3のユーザデバイスを備え、それによって、マルチ署名トランザクションの第1の出力のみと、第1の入力の非署名部分のみに署名する、ステートメント21またはステートメント22に記載のコンピュータシステム。

ステートメント24.コンピュータ可読ストレージ上に具体化され、1つまたは複数のプロセッサ上で実行されると、ステートメント1から15のいずれか1つに記載の方法のいずれかを実施するように構成される、コンピュータプログラム。

ステートメント25.コンピュータ可読媒体に埋め込まれたブロックチェーンのマルチ署名トランザクションであって、マルチ署名トランザクションの第1の入力-出力ペアの第1の出力、および第1の入力の非署名部分であって、第1の入力が、マルチ署名要件をエンコードする第1の使用可能トランザクション出力へのアウトポイントを備える、第1の出力、および第1の入力の非署名部分と、(i)関連付けられるsighash単一フラグ、および(ii)マルチ署名要件に関して有効な少なくとも1つの他の署名が第1の入力の署名部分に含まれる場合に、マルチ署名要件を満たすための署名であって、マルチ署名要件を満たすための署名が、マルチ署名要件の公開鍵に対応する秘密鍵を使用して、第1の入力-出力ペアの第1の出力、および第1の入力の非署名部分には電子署名するが、マルチ署名トランザクションの任意の他の出力には電子署名しないことによって生成される、署名と、マルチ署名トランザクションの第2の入力-出力ペアの第2の出力、および第2の入力の非署名部分であって、第2の入力が、少なくとも1つの署名を必要とする署名要件をエンコードする第2の使用可能トランザクション出力へのアウトポイントを備える、第2の出力、および第2の入力の非署名部分と、関連付けられるsighash単一フラグが第2の入力の署名部分に含まれる場合に、署名要件を少なくとも部分的に満たすための署名であって、署名要件の公開鍵に対応する秘密鍵を使用して、マルチ署名トランザクションの第2の入力-出力ペアの第2の出力、および第2の入力の非署名部分には電子署名するが、マルチ署名トランザクションの任意の他の出力には電子署名しないことによって生成される、署名とを備える、マルチ署名トランザクション。

100 システム
101 パケット交換ネットワーク
102 コンピュータ機器
102a コンピュータ機器
102b コンピュータ機器
103 当事者
103a ユーザ
103a アリス
103a 第1の当事者
103b 第2の当事者
103b ボブ
104 ビットコインノード
104 ブロックチェーンノード
105 クライアント
105 クライアントアプリケーション
106 ピアツーピア(P2P)ネットワーク
106 ブロックチェーンネットワーク
107 サイドチャネル
150 ブロックチェーン
151 データブロック
151 新しいブロック
151n-1 ブロック
152 トランザクション
152i 先行するトランザクション
152j 現在のトランザクション
153 ジェネシスブロック(Gb)
154 順序付きセット(または「プール」)
155 ブロックポインタ
201 ヘッダ
202 入力
202 入力フィールド
203 出力
203 出力フィールド
300 ユーザインターフェース(UI)
301 UI要素
301 ユーザ選択可能な要素
302 UI要素
302 データ入力フィールド
303 UI要素
303 情報要素
401 トランザクションエンジン
402 ユーザインターフェース(UI)層
403 関数
450 ノードソフトウェア
451 プロトコルエンジン
452 ノードのスクリプトエンジン
453 スタック
454 アプリケーションレベル決定エンジン
455 ブロックチェーン関連機能モジュール
455C コンセンサスモジュール
455P 伝搬モジュール
455S 記憶モジュール
500 マルチ署名トランザクション
600 マルチ署名トランザクション

Claims (24)

1. ブロックチェーンのマルチ署名トランザクションを生成するためのコンピュータ実装方法であって、
   前記マルチ署名トランザクションの第1の入力-出力ペアの第1の出力、および第1の入力の非署名部分を受信するステップであって、前記第1の入力が、マルチ署名要件をエンコードする第1の使用可能トランザクション出力へのアウトポイントを備える、ステップと、
   前記マルチ署名要件の公開鍵に対応する秘密鍵を使用して、前記第1の入力-出力ペアの前記第1の入力の前記非署名部分と前記第1の入力-出力ペアの前記第1の出力のみに電子署名し、前記マルチ署名トランザクションの他の出力には電子署名せず、それによって、(i)関連付けられるsighash単一フラグ、および(ii)前記マルチ署名要件に関して有効な少なくとも1つの他の署名が前記第1の入力の署名部分に含まれる場合に、前記マルチ署名要件を満たすための署名を生成するステップと、
   前記マルチ署名トランザクションの第2の入力-出力ペアの第2の出力、および第2の入力の非署名部分とを受信するステップであって、前記第2の入力が、少なくとも1つの署名を必要とする署名要件をエンコードする第2の使用可能トランザクション出力へのアウトポイントを備える、ステップと、
   前記署名要件の公開鍵に対応する秘密鍵を使用して、前記マルチ署名トランザクションの前記第2の入力-出力ペアの前記第2の入力の前記非署名部分と、前記第2の入力-出力ペアの前記第2の出力のみに電子署名し、前記マルチ署名トランザクションの他の出力には電子署名せず、それによって、関連付けられるsighash単一フラグが前記第2の入力の署名部分に含まれる場合に、前記署名要件を少なくとも部分的に満たすための署名を生成するステップと
   を備える、コンピュータ実装方法。
2. 前記マルチ署名トランザクションの前記第2の入力-出力ペアの前記第2の出力、および前記第2の入力の前記非署名部分が受信された後、
   関連付けられる入力がない前記マルチ署名トランザクションの最終出力を受信するステップと、
   前記マルチ署名要件の最終公開鍵に対応する最終秘密鍵を使用して、前記マルチ署名トランザクションのすべての出力、およびすべての入力の前記非署名部分に電子署名し、それによって、(i)関連付けられるsighash allフラグ、および(ii)前記マルチ署名要件を満たすための少なくとも前記署名が前記第1の入力の前記署名部分に含まれる場合に、前記マルチ署名要件を満たすための最終署名を生成するステップと
   をさらに備える、請求項1に記載のコンピュータ実装方法。
3. 前記最終署名が生成された後、前記マルチ署名トランザクションをブロックチェーンノードに送信するステップをさらに備える、請求項2に記載のコンピュータ実装方法。
4. 前記署名要件が複数の署名を必要とする場合、
   前記署名要件の別の公開鍵に対応する別の秘密鍵を使用して、前記マルチ署名トランザクションの前記第2の入力-出力ペアの前記第2の入力の前記非署名部分と前記第2の入力-出力ペアの前記第2の出力のみに電子署名し、前記マルチ署名トランザクションの他の出力には電子署名せず、それによって、関連付けられるsighash単一フラグおよび前記署名要件を少なくとも部分的に満たすための前記署名を前記第2の入力の署名部分に含める場合に、前記署名要件を部分的に満たすための別の署名を生成するステップをさらに備える、請求項1から3のいずれか一項に記載のコンピュータ実装方法。
5. 前記マルチ署名要件を満たす前記少なくとも1つの他の署名のうちの少なくとも1つが、sighash single-anyone can payフラグを有する前記第1の入力の前記署名部分において受信された後に、前記第2の入力の前記非署名部分が受信され、それによって、前記マルチ署名トランザクションの前記第1の出力のみと、前記第1の入力の前記非署名部分のみに署名する、請求項1から4のいずれか一項に記載のコンピュータ実装方法。
6. 前記署名要件を少なくとも部分的に満たすための前記署名の後に、追加の入力が提供され、前記署名要件を少なくとも部分的に満たすための前記署名が、single-anyone can payフラグに関連付けられており、それによって、前記マルチ署名トランザクションの前記第2の出力、および前記第2の入力の前記非署名部分のみに署名する、請求項1から5のいずれか一項に記載の方法。
7. 前記第1の使用可能トランザクション出力の一部が、前記第2の入力の前記非署名部分に署名する当事者に割り当てられる、請求項1から6のいずれか一項に記載の方法。
8. 前記マルチ署名トランザクションの前記第2の入力が、前記第2の使用可能トランザクション出力の残りのデジタル資産を、前記第2の入力の前記非署名部分に署名した当事者に返す、請求項1から7のいずれか一項に記載の方法。
9. 前記第2の使用可能トランザクション出力において定義されるデジタル資産の量が、前記ブロックチェーンを維持するブロックチェーンネットワークの現在のトランザクション手数料に基づいて設定される、請求項1から8のいずれか一項に記載の方法。
10. すべての出力、および前記入力のすべての非署名部分が提供された後、前記ブロックチェーンを維持するブロックチェーンネットワークの現在のトランザクション手数料を少なくとも部分的に支払うためのトランザクション手数料入力の非署名部分を提供するステップをさらに備え、前記トランザクション手数料入力が、第3の使用可能トランザクション出力へのアウトポイントを備え、前記第3の使用可能トランザクション出力において定義されるデジタル資産の量が、前記現在のトランザクション手数料に基づいて設定される、請求項1から9のいずれか一項に記載の方法。
11. 前記第3の使用可能トランザクション出力において定義されるデジタル資産の前記量が、前記トランザクション手数料入力によって支払われる前記トランザクション手数料の一部よりも大きく、前記方法が、前記第3の使用可能トランザクション出力の残りを、前記トランザクション手数料入力の前記非署名部分に署名する当事者に再割当てするためのトランザクション手数料出力を提供するステップをさらに備える、請求項10に記載の方法。
12. 前記第3の使用可能トランザクション出力において定義されるデジタル資産の前記量が、前記トランザクション手数料入力によって支払われる前記トランザクション手数料の一部に等しく、前記トランザクション手数料入力が出力に関連付けられない、請求項10に記載の方法。
13. 前記第2の使用可能トランザクション出力が、当事者が前記マルチ署名トランザクションに参加することを承認するために、前記第2の入力の前記非署名部分に署名する前記当事者に割り当てられるトークンである、請求項1から12のいずれか一項に記載の方法。
14. 前記トークンのロックスクリプトが、前記トークンを有効に使用するために使用する必要があるsighashフラグを定義する、請求項13に記載の方法。
15. トランザクション基準が満たされていることをチェックするステップをさらに備え、前記基準が満たされた場合にのみ前記マルチ署名トランザクションが前記ブロックチェーンに送信され、前記基準が、
    前記マルチ署名トランザクションの以前の反復からの情報が削除および/または変更されていない、
    提供された前記署名が検証される、
    正しいsighashフラグが前記署名に関連付けられており、前記正しい署名により、前記方法の後続の段階が必要に応じて実施されることが可能になる、
    有効なトークンが使用されている、
    前記マルチ署名トランザクションの前記出力の値が適切である
    のうちの少なくとも1つを備える、請求項3に記載の方法。
16. ブロックチェーンのマルチ署名トランザクションを生成するためのコンピュータシステムであって、1つまたは複数のプロセッサを備え、前記プロセッサが、
    前記マルチ署名トランザクションの第1の入力-出力ペアの第1の出力、および第1の入力の非署名部分を受信することであって、前記第1の入力が、マルチ署名要件をエンコードするブロックチェーントランザクションの使用可能な出力へのアウトポイントを備える、受信することと、
    前記マルチ署名要件の公開鍵に対応する秘密鍵を使用して、前記第1の入力-出力ペアの前記第1の入力の非署名部分と前記第1の入力-出力ペアの前記第1の出力のみに電子署名し、前記マルチ署名トランザクションの他の出力には電子署名せず、それによって、(i)関連付けられるsighash単一フラグ、および(ii)前記マルチ署名要件を満たす少なくとも1つの他の署名が前記第1の入力の署名部分に含まれる場合に、前記マルチ署名要件を満たすための署名を生成するステップと、
    前記マルチ署名トランザクションの第2の入力-出力ペアの第2の出力、および第2の入力の非署名部分を受信することであって、前記第2の入力が、少なくとも1つの署名を必要とする署名要件をエンコードするブロックチェーントランザクションの使用可能な出力へのアウトポイントを備える、受信することと、
    前記署名要件の公開鍵に対応する秘密鍵を使用して、前記マルチ署名トランザクションの前記第2の入力-出力ペアの前記第2の入力の前記非署名部分と、前記第2の入力-出力ペアの前記第2の出力のみに電子署名し、前記マルチ署名トランザクションの他の出力には電子署名せず、それによって、関連付けられるsighash単一フラグを前記第2の入力の署名部分に含める場合に、前記署名要件を少なくとも部分的に満たすための署名を生成することと
    を行うように構成される、コンピュータシステム。
17. 前記1つまたは複数のプロセッサが、前記マルチ署名トランザクションの前記第2の入力-出力ペアの前記第2の出力、および前記第2の入力の前記非署名部分が受信された後、
    関連付けられる入力がない前記マルチ署名トランザクションの最終出力を受信することと、
    前記マルチ署名要件の最終公開鍵に対応する最終秘密鍵を使用して、前記マルチ署名トランザクションのすべての出力、およびすべての入力の前記非署名部分に電子署名し、それによって、(i)関連付けられるsighash allフラグ、および(ii)前記マルチ署名要件を満たすための少なくとも前記署名が前記第1の入力の署名部分に含まれる場合に、前記マルチ署名要件を満たすための最終署名を生成することと
    を行うようにさらに構成される、請求項16に記載のコンピュータシステム。
18. 前記コンピュータシステムが、ブロックチェーントランザクションを検証するためのブロックチェーンノードをさらに備え、前記1つまたは複数のプロセッサが、前記最終署名が生成された後に前記マルチ署名トランザクションを前記ブロックチェーンノードに送信するように構成される、請求項17に記載のコンピュータシステム。
19. 前記署名要件に複数の署名が必要な場合、前記コンピュータシステムが、
    前記署名要件の別の公開鍵に対応する別の秘密鍵を使用して、前記マルチ署名トランザクションの前記第2の入力-出力ペアの前記第2の入力の前記非署名部分と、前記第2の入力-出力ペアの前記第2の出力のみに電子署名し、前記マルチ署名トランザクションの他の出力には電子署名せず、それによって、関連付けられるsighash単一フラグおよび前記署名要件を少なくとも部分的に満たすための前記署名を前記第2の入力の署名部分に含める場合に、前記署名要件を部分的に満たすための別の署名を生成するようにさらに構成される、請求項16から18のいずれか一項に記載のコンピュータシステム。
20. 前記1つまたは複数のプロセッサが単一のコンピュータデバイスに備えられる、請求項16から19のいずれか一項に記載のコンピュータシステム。
21. 前記コンピュータシステムが第1のユーザデバイスである、請求項16に記載のコンピュータシステム。
22. 前記コンピュータシステムが、請求項2または請求項3に記載の方法を実施するように構成された第2のユーザデバイスを備える、請求項21に記載のコンピュータシステム。
23. 前記コンピュータシステムが、前記第2の入力の前記非署名部分が受信される前に、sighash single-anyone can payフラグを有する前記第1の入力の前記署名部分に含めるための前記マルチ署名要件を満たす前記少なくとも1つの他の署名のうちの少なくとも1つを生成するように構成された第3のユーザデバイスを備え、それによって、前記マルチ署名トランザクションの前記第1の出力のみと、前記第1の入力の前記非署名部分のみに署名する、請求項21または22に記載のコンピュータシステム。
24. コンピュータ可読ストレージ上に具体化され、1つまたは複数のプロセッサ上で実行されると、請求項1から15のいずれか一項に記載の方法のいずれかを実施するように構成されたコンピュータプログラム。