JP2024500923A - トランザクション署名フラグ - Google Patents

Abstract

投票を行うためのブロックチェーンの投票トランザクションのインプットとアウトプットを生成するためのコンピュータプログラムであり、前記コンピュータプログラムは、１つ以上のプロセッサを、投票コーディネータから、１つ以上の公開鍵と投票オプションのセットとを含む投票指示を受信し、前記投票オプションを表示するユーザインタフェースをレンダリングし、前記投票オプションのうちの１つのユーザ選択を受信し、前記投票トランザクションに含めるインプット－アウトプットペアを生成する、よう構成させ、前記インプットの非署名部分は、ブロックチェーントランザクションの未使用トランザクションアウトプットを識別するアウトポイントを含み、前記インプットの署名部分は、signature singleフラグと、少なくとも前記インプット－アウトプットペアの前記非署名部分と前記インプット－アウトプットペアのアウトプットに署名するが前記投票トランザクションの他のアウトプットに署名しない関連署名と、を含み、前記インプット－アウトプットペアの前記アウトプットは、公開鍵の１つを含む、コンピュータプログラム。

Description

本開示は、ブロックチェーントランザクションで使用される署名フラグに関する。

ブロックチェーンとは、分散型ピアツーピア（P２P）ネットワーク（以下で「ブロックチェーンネットワーク」とも呼ばれる）内の複数のノードの各々において、ブロックチェーンの重複コピーが維持され広く公表される、分散データ構造の形態を指す。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックは１つ以上のトランザクションを含む。所謂「コインベーストランザクション」以外の各トランザクションは、シーケンス内の先行するトランザクションをポイントする。シーケンスは、１つ以上のコインベーストランザクションまで遡る１つ以上のブロックに跨がってよい。コインベーストランザクションは以下で更に議論される。ブロックチェーンネットワークに提出されるトランザクションは、新しいブロックに含まれる。新しいブロックは、「マイニング」として知られる処理により生成される。「マイニング」は、複数のノードの各々が「proof-of-work」を実行するために競争する、つまり、ブロックチェーンの新しいブロックに含まれることを待っている順序付き及び妥当性確認済みの保留中のトランザクションの定義されたセットの提示に基づき、暗号パズルを解くことを含む。留意すべきことに、ブロックチェーンは幾つかのノードにおいてプルーニング（pruned）されてよく、ブロックの公開はブロックヘッダのみの公開を通じて達成できる。

ブロックチェーン内のトランザクションは、以下の目的：デジタルアセット（つまり、多数のデジタルトークン）を運ぶこと、仮想台帳又はレジストリの中のエントリのセットを順序付けること、タイムスタンプエントリを受信し処理すること、及び／又はインデックスポインタを時系列にすること、のうちの１つ以上のために使用できる。ブロックチェーンの上に追加の機能をレイヤ化するために、ブロックチェーンを利用することもできる。例えば、ブロックチェーンプロトコルは、トランザクション内のデータに追加のユーザデータ又はインデックスを格納できるようにし得る。単一トランザクション内に格納できる最大データ容量に対する予め指定された限度は存在しない。従って、より複雑なデータを組み込むことができる。例えば、これは、ブロックチェーン内に電子文書（electronic document）、或いはオーディオ若しくはビデオデータを格納するために使用され得る。

ブロックチェーンネットワークのノード（「マイナー」と呼ばれることがある）は、以下に詳細に説明する分散型トランザクション登録及び検証処理を実行する。つまり、この処理の間、ノードは、トランザクションの妥当性確認を行い、それらをブロックテンプレイトに挿入し、それに対して有効なproof-of-work解を特定しようと試みる。有効な解が見付かると、新しいブロックはネットワークの他のノードへと伝播され、それにより、各ノードがブロックチェーンに新しいブロックを記録できるようになる。トランザクションをブロックチェーンに記録させるために、ユーザ（例えば、ブロックチェーンクライアントアプリケーション）は、伝播させるために、ネットワークのノードの１つにトランザクションを送信する。トランザクションを受信したノードは、proof-of-work解を見付けるために競争し、妥当性確認されたトランザクションを新しいブロックに組み込む。各ノードは、トランザクションが有効であるための１つ以上の条件を含む同じノードプロトコルを実施するよう構成される。無効なトランザクションは、伝播されず、ブロックに組み込まれることもない。トランザクションが妥当性確認され、それによってブロックチェーンに受け入れられたと仮定すると、（任意のユーザデータを含む）トランザクションは、従って、不変の公開レコードとしてブロックチェーンネットワークの各ノードに登録されインデックスされたままである。

最新のブロックを生成するためにproof-of-workパズルを解くことに成功したノードは、標準的に、デジタルアセットの新しい量、つまりトークンの数を生成する「コインベーストランザクション（coinbase transaction）」と呼ばれる新しいトランザクションにより報酬を受ける。無効なトランザクションの検出及び拒否は、ネットワークのエージェントとして動作し及び不法行為を報告及び阻止するよう奨励される競合ノードの動作により実施される。情報の広範な公開により、ユーザはノードの性能を継続的に監査できる。単なるブロックヘッダの公開により、参加者はブロックチェーンの現下の完全性を保証できる。

「アウトプットベースの」モデル（UTXOに基づくモデルと呼ばれることもある）では、所与のトランザクションのデータ構造は、１つ以上のインプット及び１つ以上のアウトプットを含む。任意の使用可能アウトプットは、先行するトランザクションシーケンスから導出可能なデジタルアセットの量を指定する要素を含む。使用可能アウトプットは、時にUTXO（unspent transaction output、未使用トランザクションアウトプット）と呼ばれる。アウトプットは、アウトプットの将来の償還（redemption）のための条件を指定するロックスクリプトを更に含んでよい。ロックスクリプトは、デジタルトークン又はアセットを妥当性確認し及び移転するために必要な条件を定義する述部（predicate）である。（コインベーストランザクション以外の）トランザクションの各インプットは、先行するトランザクション内のそのようなアウトプットへのポインタ（つまり参照）を含み、ポイントされたアウトプットのロックスクリプトをアンロックするためのアンロックスクリプトを更に含んでよい。従って、トランザクションのペアを考えるとき、それらを、第１トランザクション及び第２トランザクション（又は「ターゲット」トランザクション）と呼ぶ。第１トランザクションは、デジタルアセットの量を指定する、及びアウトプットをアンロックする１つ以上の条件を定義するロックスクリプトを含む、少なくとも１つのアウトプットを含む。第２ターゲットトランザクションは、第１トランザクションのアウトプットへのポインタと、第１トランザクションのアウトプットをアンロックするためのアンロックスクリプトとを含む、少なくとも１つのインプットを含む。

このようなモデルでは、第２ターゲットトランザクションがブロックチェーンで伝播され記録されるブロックチェーンネットワークに送られるとき、各ノードで適用される有効性の基準の１つは、アンロックスクリプトが第１トランザクションのロックスクリプトで定義された１つ以上の条件のすべてを満たすことである。もう１つは、第１トランザクションのアウトプットが、別の前の有効なトランザクションによって未だ償還されていないことである。これらの条件のうちのいずれかに従いターゲットトランザクションが無効であると分かった任意のノードは、該トランザクションを（有効なトランザクションとして）伝搬させず（しかし、無効なトランザクションを登録する場合がある）、ブロックチェーンに記録させるために新しいブロックに含めることもしない。

トランザクションモデルの代替のタイプは、アカウントに基づくモデルである。この場合、各トランザクションは、過去の一連のトランザクションにおいて、先行するトランザクションのUTXOに戻って参照することによって移転される量を定義するのではなく、絶対的な口座（アカウント）残高を参照することによって移転される。すべてのアカウントの現在の状態は、ブロックチェーンと分離してノードによって保管され、絶えず更新される。

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

特定のアウトプットベースのトランザクションモデルでは、通常、トランザクションに署名するときに、署名側パーティ（当事者、party）は、トランザクションで定義されたすべてのインプットとアウトプットに適用される署名を作成する。ただし、署名を作成するときに異なるタグ（sighashフラグと呼ばれる）を使用することで、トランザクションの特定の要素にのみ適用又は「承認」されるように、署名を特定のものにすることができる。

複数のパーティが１つのトランザクションで共同作業を行う状況では、従来のsighash ALL署名アプローチでは、署名を進める前に、パーティ間でトランザクションの詳細を確立するための初期通信が必要になる。これは非効率であり、多くの場合、パーティ間の関係を正確に反映しない相互依存関係を与える。対照的に、異なるsighashフラグを組み合わせることで、パーティはトランザクションの異なる部分に個別に署名する柔軟性を得ることができる。

このような柔軟性が役立つ機能の例としては、投票において、各投票者が自分の投票に関連するインプットとアウトプットのみに署名する機能がある。従って、投票は匿名のままにすることができる。署名前にすべてのインプットとアウトプットを知る必要があるため、標準のsighash ALL署名モデルを使用して投票を行うことはできず、投票結果に不満がある場合に署名の提供を拒否し、投票を無効にする機会を投票者に提供してしまう。

本明細書に開示される一態様によると、投票を行うためのブロックチェーンの投票トランザクションのインプットとアウトプットを生成するためのコンピュータプログラムであり、前記コンピュータプログラムは、非一時的媒体に格納され、１つ以上のコンピュータプロセッサによって実行されると、前記１つ以上のプロセッサを、
投票コーディネータから、前記投票コーディネータによって定義された１つ以上の公開鍵と投票オプションのセットとを含む投票指示を受信し、
ディスプレイを制御して、前記投票オプションのセットを表示するユーザインタフェースをレンダリングし、
前記ユーザインタフェースでユーザ入力によって定義された前記投票オプションのセットのうちの１つの投票オプションのユーザ選択を受信し、
投票トランザクションの異なるインデックスにある１つ以上の他のインプット－アウトプットペアを有する前記投票トランザクションに含めるインプット－アウトプットペアを生成する、
よう構成させ、
前記インプット－アウトプットペアのインプットの非署名部分は、ブロックチェーントランザクションの未使用トランザクションアウトプットを識別するアウトポイントを含み、前記インプットの署名部分は、signature singleフラグと、少なくとも前記インプット－アウトプットペアの前記非署名部分と前記インプット－アウトプットペアのアウトプットに署名するが前記投票トランザクションの他のアウトプットに署名しない関連署名と、を含み、前記インプット－アウトプットペアの前記アウトプットは、前記投票指示の１つ以上の公開鍵の１つを含む、コンピュータプログラムが提供される。

本明細書に開示される第２態様によると、ブロックチェーンの投票トランザクションを生成するためのコンピュータプログラムであって、前記コンピュータプログラムは、非一時的媒体に格納され、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサを、
複数のインプット－アウトプットペアを受信し、
投票トランザクションを生成し、
前記投票トランザクションは、
投票インデックスのセットの各投票インデックスの中に、受信したインプット－アウトプットペアの１つと、
認可インデックスの中に、投票コーディネータの署名が投票トランザクションのすべてのインプットとアウトプットに署名するように、all署名フラグを持つ投票コーディネータの署名で構成されるインプットと、
アウトプットと、
を含み、
前記投票トランザクションをブロックチェーンに送信する、
よう構成させる、コンピュータプログラムが提供される。

本明細書に開示される第３態様によると、コンピュータ可読媒体上に具現化されたブロックチェーントランザクションであって、
ブロックチェーントランザクションのインプット内で示される使用可能トランザクションアウトプットを有効に消費するためのインプット、
署名要件と必要な署名フラグを定義するロックスクリプトを含み、後続のブロックチェーントランザクションでアンロックスクリプトと連結されたときに、前記アンロックスクリプトの署名を妥当性確認し、前記アンロックスクリプトから使用された署名フラグを抽出し、前記使用された署名フラグと前記必要な署名フラグを比較し、前記使用された署名フラグが前記必要な署名フラグと一致しない及び／又は前記署名が無効である場合に、前記後続のブロックチェーントランザクションが無効になるようにする、少なくとも１つのアウトプットと、
を含むブロックチェーントランザクションが提供される。

本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、例としてのみ以下の添付の図面を参照する。
ブロックチェーンを実装するためのシステムの概略ブロック図である。 ブロックチェーンに記録されるトランザクションの幾つかの例を概略的に示す。 クライアントアプリケーションの概略ブロック図である。 図３Aのクライアントアプリケーションにより提示され得る例示的なユーザインタフェースの概略的模擬表示である。 トランザクションを処理するための特定のノードソフトウェアの概略ブロック図である。 例示的なトークン発行トランザクションである。 全ての有権者に投票を行うよう要求する投票のための例示的な投票トランザクションである。 定足数投票のための例示的な投票トランザクションである。 トークン発行トランザクションと投票トランザクションのインプットとアウトプットの関係の概略図である。 ブロックチェーンを用いて投票を提供する例示的な方法を示す。 例示的な投票方法を示す。

例示的なシステムの概要
図１は、ブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットのような広域インターネットワークであるパケット交換ネットワーク１０１を含んでよい。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア（P２P）ネットワーク１０６を形成するように配置され得る複数のブロックチェーンノード１０４を含む。図示されないが、ブロックチェーンノード１０４は、ほぼ完全なグラフとして配置されてよい。各ブロックチェーンノード１０４は、従って、他のブロックチェーンノード１０４と高度に結合される。

各ブロックチェーンノード１０４は、異なるピアに属するノード１０４のうちの異なるノード１０４を有す、ピアのコンピュータ装置を含む。各ブロックチェーンノード１０４は、１つ以上のプロセッサ、例えば、１つ以上の中央処理装置（CPU）、アクセラレータプロセッサ、特定用途向けプロセッサ、及び／又はフィールドプログラマブルゲートアレイ（FPGA）、及び特定用途向け集積回路（ASIC）のような他の機器を含む処理装置を含む。各ノードはまた、メモリ、すなわち、非一時的コンピュータ読み取り可能媒体又は媒体の形態のコンピュータ読み取り可能記憶装置を備える。メモリは、１つ以上のメモリ媒体、例えば、ハードディスクなどの磁気媒体、固体ドライブ（solid-state drive （SSD））、フラッシュメモリ又はEEPROMなどの電子媒体、及び／又は光ディスクドライブなどの光学媒体を使用する１つ以上のメモリユニットを含んでもよい。

ブロックチェーン１５０は、データのブロック１５１のチェーンを含み、ブロックチェーン１５０の各々のコピーは、分散型又はブロックチェーンネットワーク１０６内の複数のノード１０４の各々において維持される。上述のように、ブロックチェーン１５０のコピーを維持することは、必ずしも、ブロックチェーン１５０全体を格納することを意味しない。代わりに、各ブロックチェーンノード１５０が各ブロック１５１のブロックヘッダ（後述する）を格納する限り、ブロックチェーン１５０からデータを取り除くことができる。チェーン内の各ブロック１５１は、１つ以上のトランザクション１５２を含み、ここでは、この文脈におけるトランザクションは、一種のデータ構造を参照する。データ構造の性質は、トランザクションモデル又はスキームの一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、全体を通して、１つの特定のトランザクションプロトコルを使用する。１つの一般的なタイプのトランザクションプロトコルでは、各トランザクション１５２のデータ構造は、少なくとも１つのインプット及び少なくとも１つのアウトプットを含む。各アウトプットは、資産としてのデジタルアセットの量を表す量を指定する。この例では、アウトプットが暗号的にロックされているのはユーザ１０３である（ロックを解除し、それによって償還又は使用するために、そのユーザの署名又は他の解を必要とする）。各インプットは、先行するトランザクション１５２のアウトプットを指し示し、それによって、トランザクションをリンクする。

各ブロック１５１は、また、ブロック１５１への逐次的順序を定義するように、チェーン内の先に生成されたブロック１５１を遡ってポイントするブロックポインタ１５５を含む。（コインベーストランザクション以外の）各トランザクション１５２は、トランザクションのシーケンスに順序を定義するために、前のトランザクションへのポインタを含む（注：トランザクション１５２のシーケンスは、分岐することが許される）。ブロック１５１のチェーンは、チェーンの第１ブロックであったジェネシスブロック（genesis block （Gb））１５３にまで戻る。チェーン１５０の初期に１つ以上のオリジナルトランザクション１５２は、先行するトランザクションではなくジェネシスブロック１５３を指し示した。

ブロックチェーンノード１０４の各々はトランザクション１５２を他のブロックチェーンノード１０４へ転送し、それにより、ネットワーク１０６に渡りトランザクション１５２を伝播させるよう構成される。各ブロックチェーンノード１０４は、ブロック１５１を生成し、同じブロックチェーン１５０の各々のコピーを自身の各々のメモリに格納するよう構成される。各ブロックチェーンノード１０４はまた、ブロック１５１に組み込まれるのを待つトランザクション１５２の順序付きセット（又はプール）１５４を維持する。順序付きプール１５４は、時に「メモプール（mempool）」と呼ばれる。この用語は、本願明細書では、任意の特定のブロックチェーン、プロトコル、又はモデルに限定されない。それは、ノード１０４が有効であるとして受け付けた、及びノード１０４が同じアウトプットを使用しようと試みる他のトランザクションを受け付けないよう義務付けられたトランザクションの順序付きセットを表す。

所与の現在のトランザクション１５２jにおいて、インプット（又はその各々）は、トランザクションのシーケンスの中の先行トランザクション１５２iのアウトプットを参照するポインタを含み、このアウトプットが現在のトランザクション１５２jにおいて償還されるか又は「使用される（spent）」ことを指定する。一般に、先行するトランザクションは、順序付きセット１５４又は任意のブロック１５１内の任意のトランザクションであり得る。先行するトランザクション１５２iは、必ずしも、現在のトランザクション１５２jが生成された又はネットワーク１０６へ送信されたときに存在する必要はないが、先行するトランザクション１５２iは、現在のトランザクションが有効であるために存在し妥当性確認されている必要がある。従って、本願明細書で「先行する」は、ポインタによりリンクされた論理的シーケンスの中で先行するものを表し、必ずしも時系列の中での生成又は送信の時間を表さない。従って、それは、必ずしも、トランザクション１５２i,１５２jが順不同で生成され又は送信されることを排除しない（以下の親のない（orphan）トランザクションに関する議論を参照する）。先行するトランザクション１５２iは、等しく、祖先（antecedent）又は先行（predecessor）トランザクションと呼ばれ得る。

現在のトランザクション１５２jのインプットは、インプット認可、例えば先行するトランザクション１５２iのアウトプットがロックされているユーザ１０３aの署名も含む。次に、現在のトランザクション１５２jのアウトプットは、新しいユーザ又はエンティティ１０３bに暗号的にロックすることができる。従って、現在のトランザクション１５２jは、先行するトランザクション１５２iのインプットに定義された量を、現在のトランザクション１５２jのアウトプットに定義された新しいユーザ又はエンティティ１０３bに移転することができる。ある場合には、トランザクション１５２は、複数のユーザ又はエンティティ間でインプット量を分割するために複数のアウトプットを有してもよいエンティティ（そのうちの１つは、お釣りを与えるために、元のユーザ又はエンティティ１０３aであってもよい）。幾つかの場合には、トランザクションが複数のインプットを有し、１つ以上の先行するトランザクションの複数のアウトプットから量をまとめ、現在のトランザクションの１つ以上のアウトプットに再分配することもできる。

ビットコインのようなアウトプットに基づくトランザクションプロトコルによると、個人ユーザ又は組織のようなエンティティ１０３は、（手動で又はパーティにより利用されている自動処理によって）新しいトランザクション１５２jに作用したいとき、作用側エンティティは新しいトランザクションを自身のコンピュータ端末１０２から受信側へ送信する。作用側パーティ又は受信側は、結局、このトランザクションをネットワーク１０６のブロックチェーンノード１０４のうちの１つ以上（これらは、今日では、標準的にサーバ又はデータセンタであるが、原理的に他のユーザ端末も可能である）へと送信する。幾つかの例では、新しいトランザクション１５２jに作用するパーティ１０３が、トランザクションを、受信側ではなくブロックチェーンノード１０４のうちの１つ以上へと直接送信し得ることも排除されない。トランザクションを受信するブロックチェーンノード１０４は、各ブロックチェーンノード１０４に適用されるブロックチェーンノードプロトコルに従って、トランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、典型的には、ブロックチェーンノード１０４に、新しいトランザクション１５２j内の暗号署名が、トランザクション１５２の順序付きシーケンスの中の前のトランザクション１５２iに依存する、期待される署名と一致することをチェックすることを要求する。このようなアウトプットに基づくトランザクションプロトコルの場合、これは、新しいトランザクション１５２jのインプットに含まれるパーティ１０３の暗号署名又は他の認証が、新しいトランザクションが割り当てる先行するトランザクション１５２jのアウトプットに定義された条件と一致することをチェックすることを含んでよく、この条件は、典型的には、新しいトランザクション１５２jのインプット内の暗号署名又は他の認証が、新しいトランザクションのインプットがリンクされた前のトランザクション１５２iのアウトプットをアンロックすることを少なくともチェックすることを含む。条件は、先行するトランザクション１５２iのアウトプットに含まれるスクリプトにより少なくとも部分的に定義されてよい。あるいは、単にブロックチェーンノードプロトコルだけで固定することもできるし、あるいは、これらの組み合わせによることもある。いずれにせよ、新しいトランザクション１５２jが有効であれば、ブロックチェーンノード１０４は、新しいトランザクションをブロックチェーンネットワーク１０６内の１つ以上の他のブロックチェーンノード１０４に転送する。これらの他のブロックチェーンノード１０４は、同じノードプロトコルに従って同じテストを適用し、新しいトランザクション１５２jを１つ以上のさらなるノード１０４に転送し、以下で同様である。このようにして、新しいトランザクションは、ブロックチェーンノード１０４のネットワーク全体に伝播される。

アウトプットベースのモデルでは、与えられ割り当てアウトプット（例えば、UTXO）が割り当てられる（例えば使用される）かどうかの定義は、ブロックチェーンノードプロトコルに従って別の今後の（onward）トランザクション１５２jのインプットによって既に有効に償還されているかどうかである。トランザクションが有効であるための別の条件は、それが償還を試みる先行するトランザクション１５２iのアウトプットが、別のトランザクションによって未だ償還されていことである。ここでも、有効でない場合、トランザクション１５２jは、（無効であるとしてフラグが立てられ変更するために伝播されない限り）ブロックチェーン１５０に伝播又は記録されない。これは、取引者が同じトランザクションのアウトプットを複数回割り当てようとする二重支出を防ぐ。一方、アカウントベースモデルは、口座残高を維持することによって、二重支出を防ぐ。この場合も、トランザクションの順序が定義されているため、口座残高は、一度に単一の定義された状態を有する。

妥当性確認トランザクションに加えて、ブロックチェーンノード１０４は、また、「proof -of -work」により支えられているマイニングと呼ばれるプロセスで、トランザクションのブロックを最初に作成するために競合する。ブロックチェーンノード１０４では、ブロックチェーン１５０に記録されたブロック１５１にまだ現れていない有効なトランザクションの順序付きプール１５４に新しいトランザクションが追加される。ブロックチェーンノードは、次に、暗号パズルを解くことを試みることにより、トランザクションの順序付きセット１５４からトランザクション１５２の新しい有効なブロック１５１を組み立てるために競争する。これは、典型的には、ノンス（nonce）が保留トランザクションの順序付きプール１５４の表現と連結され、ハッシュされるときに、ハッシュのアウトプットが所定の条件を満たすような「ノンス」値を探すことを含む。例えば、所定の条件は、ハッシュのアウトプットが、所定の数の先頭ゼロを有することであってもよい。これは、単に１つの特定の種類のproof-of-workパズルであり、他の種類が排除されないことに留意する。ハッシュ関数の特性は、インプットに関して予測不可能なアウトプットを持つことである。従って、この探索は、ブルートフォースによってのみ実行することができ、従って、パズルを解決しようとしている各ブロックチェーンノード１０４において、相当量の処理リソースを消費する。

パズルを解いた第１ブロックチェーンノード１０４は、これをネットワーク１０６に通知し、その解を証明として提供する。この解は、ネットワーク内の他のブロックチェーンノード１０４によって簡単にチェックすることができる（ハッシュに対する解が与えられれば、ハッシュのアウトプットが条件を満たすことを確認することは簡単である）。第１ブロックチェーンノード１０４は、該ブロックを受け入れる閾値の他のノードの合意に、ブロックを伝播させ、従ってプロトコルルールを実施する。トランザクションの順序付きセット１５４は、次に、ブロックチェーンノード１０４の各々により、ブロックチェーン１５０内の新しいブロック１５１として記録されるようになる。また、新しいブロック１５１nにはブロックポインタ１５５が割り当てられ、チェーン内で前に作成されたブロック１５１n-１を指すようになっている。proof-of-work解を生成するために必要とされる例えばハッシュの形式の有意な量の労力が、ブロックチェーンプロトコルのルールに従うという第１ノード１０４の意図をシグナリングする。そのようなルールは、前に妥当性確認されたトランザクションと同じアウトプットを割り当てる場合に有効としてトランザクションを受け付けないこと、或いは二重支払いとして知られていることを含む。一旦生成されると、ブロック１５１は、ブロックチェーンネットワーク１０６内のブロックチェーンノード１０４の各々で認識され、維持されるので、修正することができない。また、ブロックポインタ１５５は、ブロック１５１に順序を課す。トランザクション１５２は、ネットワーク１０６内の各ブロックチェーンノード１０４において順序付きブロックに記録されるので、これは、トランザクションの不変の公開台帳を提供する。

パズルを解決するために常に競争している異なるブロックチェーンノード１０４は、いつ解を探し始めたか、又はトランザクションが受信された順序によって、いつでも未だ公開されていないトランザクションのプール１５４の異なるスナップショットに基づいてパズルを解いているかもしれないことに留意する。パズルを解く者は誰でも、最初に次の新しいブロック１５１nに含まれるトランザクション１５２を定義し、その順序で、未公開のトランザクションの現在のプール１５４が更新される。そして、ブロックチェーンノード１０４は、新たに定義された未公開トランザクションの順序付きプール１５４からブロックを作り出すために、競争を続ける。また、生じ得る「分岐（フォーク、fork）」を解決するためのプロトコルも存在する。これは、２つのブロックチェーンノード１０４が互いに非常に短い時間内にパズルを解き、ブロックチェーンの矛盾したビューがノード１０４の間で伝播する場合である。要するに、分岐の枝が伸びるときは常に、最長のものが最終的なブロックチェーン１５０になる。これは、同じトランザクションが両方の分岐に現れるので、ネットワークのユーザ又はエージェントに影響しないことに留意する。

ビットコインブロックチェーン（及び殆どの他のブロックチェーン）によると、新しいブロック１０４を構成するのに成功したノードは、デジタルアセットの追加の定義された量を分配する新しい特別な種類のトランザクションの中でデジタルアセットの追加の承認された量を新たに割り当てる能力を与えられる（１人のエージェント又はユーザから別のエージェント又はユーザへとデジタルアセットの量を移転するエージェント間又はユーザ間トランザクションと異なる）。この特別な種類のトランザクションは、通常、「コインベーストランザクション」と呼ばれるが、「開始（initiation）トランザクション」又は「生成（generation）トランザクション」とも呼ばれることがある。それは標準に新しいブロック１５１nの第１トランザクションを形成する。proof-of-workは、この特別なトランザクションが後に償還できるように、新しいブロックを構成したノードがプロトコルルールに従うことを意図していることをシグナリングする。ブロックチェーンプロトコルルールは、この特別なトランザクションが償還できる前に、満期、例えば１００ブロックを必要としてよい。通常の（非生成）トランザクション１５２は、そのアウトプットの１つに追加のトランザクション手数料を指定し、そのトランザクションが公開されたブロック１５１nを生成したブロックチェーンノード１０４にさらに報酬を与えることが多い。この手数料は、通常、「トランザクション手数料」と呼ばれ、後述する。

トランザクションの妥当性確認及び公開に関連するリソースのために、典型的には、少なくともブロックチェーンノード１０４の各々は、１つ以上の物理的サーバユニットを含むサーバ、又はデータセンタ全体の形態をとる。しかしながら、原理的に、任意の所与のブロックチェーンノード１０４は、ユーザ端末又は互いにネットワーク接続されたユーザ端末又はユーザ端末のグループの形態をとることができる。

各ブロックチェーンノード１０４のメモリは、各々の１つ以上の役割を実行し、ブロックチェーンノードプロトコルに従ってトランザクション１５２を処理するために、ブロックチェーンノード１０４の処理装置上で動作するように構成されたソフトウェアを記憶する。ブロックチェーンノード１０４に属するいずれの動作も、各々のコンピュータ装置の処理装置上で実行されるソフトウェアによって実行され得ることが理解されよう。ノードソフトウェアは、アプリケーションレイヤにおける１つ以上のアプリケーション、又はオペレーティングシステムレイヤ若しくはプロトコルレイヤのような下位レイヤ、又はこれらの任意の組合せの中に実装されてよい。

また、ネットワーク１０１には、消費者ユーザの役割を果たす複数のパーティ１０３の各々のコンピュータ装置１０２も接続されている。これらのユーザは、ブロックチェーンネットワークと相互作用できるが、トランザクションの妥当性確認及びブロックの構築には参加しない。これらのユーザ又はエージェントのうちの一部は、トランザクションにおいて送信側及び受信側として動作してよい。他のユーザは、必ずしも送信側又は受信側として動作することなく、ブロックチェーン１５０と相互作用してよい。例えば、幾つかのパーティは、ブロックチェーン１５０のコピーを格納する（例えば、ブロックチェーンノード１０４からブロックチェーンのコピーを取得した）記憶エンティティとして動作してよい。

パーティ１０３の一部又は全部は、異なるネットワーク、例えば、ブロックチェーンネットワーク１０６の上に重ねられたネットワークの部分として結合されてよい。ブロックチェーンネットワークのユーザ（「クライアント」と呼ばれることが多い）は、ブロックチェーンネットワーク１０６を含むシステムの部分であると言うことができる。しかしながら、これらのユーザは、ブロックチェーンノードの要求される役割を実行しないので、ブロックチェーンノード１０４ではない。代わりに、各パーティ１０３は、ブロックチェーンネットワーク１０６と相互作用し、それにより、ブロックチェーンノード１０６に結合する（つまり通信する）ことにより、ブロックチェーン１５０を利用してよい。２つのパーティ１０３及び各々の機器１０２は、説明のために示されており、第１パーティ１０３a及びその各々のコンピュータ機器１０２a、ならびに第２パーティ１０３b及びその各々のコンピュータ機器１０２bである。より多くのこのようなパーティ１０３及びそれらの各々のコンピュータ機器１０２がシステム１００に存在し、参加することができるが、便宜上、それらは図示されていないことが理解されよう。各パーティ１０３は、個人又は組織であってもよい。純粋に例示として、第１パーティ１０３ａは、本明細書においてAliceと称され、第２パーティ１０３ｂは、Bobと称されるが、これは限定的なものではなく、本明細書においてAlice又はBobという言及は、各々「第１パーティ」及び「第２パーティ」と置き換えることができることは理解されるであろう。

各パーティ１０３のコンピュータ機器１０２は、１つ以上のプロセッサ、例えば、１つ以上のCPU、GPU、他のアクセラレータプロセッサ、特定用途向けプロセッサ、及び／又はFPGAを備える各々の処理装置を備える。各パーティ１０３のコンピュータ機器１０２は、さらに、メモリ、すなわち、非一時的コンピュータ読み取り可能媒体又は媒体の形態のコンピュータ読み取り可能記憶装置を備える。このメモリは、１つ以上のメモリ媒体、例えば、ハードディスクのような磁気媒体、SSD、フラッシュメモリ又はEEPROMのような電子媒体、及び／又は光学ディスクドライブのような光学媒体を使用する１つ以上のメモリユニットを含むことができる。各パーティ１０３のコンピュータ機器１０２上のメモリは、処理装置上で動作するように配置された少なくとも１つのクライアントアプリケーション１０５の各々のインスタンスを含むソフトウェアを記憶する。本明細書で与えられたパーティ１０３に帰属するいずれのアクションも、各々のコンピュータ装置１０２の処理装置上で実行されるソフトウェアを使用して実行され得ることが理解されよう。各パーティ１０３のコンピュータ機器１０２は、少なくとも１つのユーザ端末、例えばデスクトップ又はラップトップコンピュータ、タブレット、スマートフォン、又はスマートウォッチのようなウェアラブルデバイスを備えている。所与のパーティ１０３のコンピュータ装置１０２は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースのような、１つ以上の他のネットワーク化されたリソースを含んでもよい。

クライアントアプリケーション１０５は、最初に、１つ以上の適切なコンピュータ読み取り可能な記憶媒体、例えばサーバからダウンロードされたもの、又はリムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスク又はテープ、光ディスク、例えばCD又はDVD ROM、又はリムーバブル光学ドライブなどのリムーバブル記憶装置上で、任意の所与のパーティ１０３のコンピュータ機器１０２に提供され得る。

クライアントアプリケーション１０５は、少なくとも「ウォレット」機能を備える。これには主に２つの機能を有する。これらのうちの１つは、各々のパーティ１０３が、ブロックチェーンノード１０４のネットワーク全体にわたって伝播され、それによってブロックチェーン１５０に含まれるべきトランザクション１５２を作成し、認可し（例えば署名し）、送信することを可能にすることである。もう１つは、現在所有しているデジタルアセットの量を各々のパーティに報告することである。アウトプットベースのシステムでは、この第２機能は、当該パーティに属するブロックチェーン１５０全体に散在する様々なトランザクション１５２のアウトプットの中で定義される量を照合することを含む。

注：種々のクライアント機能が所与のクライアントアプリケーション１０５に統合されるとして説明されることがあるが、これは、必ずしも限定的ではなく、代わりに、本願明細書に記載される任意のクライアント機能が２つ以上の異なるアプリケーションのスーツに実装されてよく、例えばAPIを介してインタフェースし、又は一方が他方へのプラグインである。より一般的には、クライアント機能は、アプリケーションレイヤ、又はオペレーティングシステムのような下位レイヤ、又はこれらの任意の組合せにおいて実装され得る。以下は、クライアントアプリケーション１０５の観点で説明されるが、これは限定的ではないことが理解される。

各コンピュータ機器１０２上のクライアントアプリケーション又はソフトウェア１０５のインスタンスは、ネットワーク１０６のブロックチェーンノード１０４の少なくとも１つに動作可能に結合される。これにより、クライアント１０５のウォレット機能は、トランザクション１５２をネットワーク１０６に送信することができる。クライアント１０５は、また、ブロックチェーンノード１０４にコンタクトして、各々のパーティ１０３が受信側である任意のトランザクションについてブロックチェーン１５０に問い合わせることができる（又は、実施形態では、ブロックチェーン１５０は、部分的にその公開視認性を通じてトランザクションの信頼を提供する公開的設備であるため、実際には、ブロックチェーン１５０内の他のパーティのトランザクションを検査する）。各コンピュータ機器１０２上のウォレット機能は、トランザクションプロトコルに従ってトランザクション１５２を形成し、送信するように構成される。上述のように、各ブロックチェーンノード１０４は、ブロックチェーンノードプロトコルに従いトランザクション１５２を妥当性確認し、トランザクション１５２をブロックチェーンネットワーク１０６全体に渡り伝播させるために、トランザクション１５２を転送するよう構成されるソフトウェアを実行する。トランザクションプロトコルとノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルと共に所与のトランザクションモデルを実装する。同じトランザクションプロトコルは、ブロックチェーン１５０内の全部のトランザクション１５２について使用される。同じノードプロトコルは、ネットワーク１０６内の全部のノード１０４について使用される。

所与のパーティ１０３、例えばAliceがブロックチェーン１５０に含まれる新たなトランザクション１５２jを送信したいと望む場合、彼女は関連するトランザクションプロトコルに従って（彼女のクライアントアプリケーション１０５のウォレット機能を使用して）新たなトランザクションを作成する（formulate）。彼女は、次に、クライアントアプリケーション１０５からトランザクション１５２を、彼女が接続されている１つ以上のブロックチェーンノード１０４に送信する。例えば、これは、Aliceのコンピュータ１０２に最も良好に接続されているブロックチェーンノード１０４であってもよい。任意の所与のブロックチェーンノード１０４が新しいトランザクション１５２jを受信すると、ブロックチェーンノードプロトコル及びその各々の役割に従って、それを処理する。これは、最初に、新たに受信されたトランザクション１５２jが「有効」であるための特定の条件を満たしているかどうかをチェックすることを含み、その例については、簡単に詳述する。幾つかのトランザクションプロトコルでは、妥当性確認のための条件は、トランザクション１５２に含まれるスクリプトによってトランザクションごとに構成可能であってよい。或いは、条件は単にノードプロトコルの組み込み機能であってもよく、或いはスクリプトとノードプロトコルの組み合わせによって定義されてもよい。

新たに受信されたトランザクション１５２jが、有効であると見なされるテストに合格したという条件で（すなわち、「妥当性確認された」という条件で）、トランザクション１５２jを受信した任意のブロックチェーンノード１０４は、そのブロックチェーンノード１０４に維持されているブロックチェーンの順序付きセット１５４に、新たな妥当性確認済みトランザクション１５２を追加する。さらに、トランザクション１５２jを受信する任意のブロックチェーンノード１０４は、妥当性確認済みトランザクション１５２をネットワーク１０６内の１つ以上の他のブロックチェーンノード１０４に伝播する。各ブロックチェーンノード１０４は同じプロトコルを適用するので、トランザクション１５２jが有効であると仮定すると、これは、ネットワーク１０６全体に間もなく伝播されることを意味する。

所与のブロックチェーンノード１０４において維持される保留中トランザクションの順序付きプール１５４に入れられると、該ブロックチェーンノード１０４は、新しいトランザクション１５２を含む、彼ら各々のトランザクションのプールの最新バージョンについて、proof-of-workパズルを解く競争を開始する（他のブロックチェーンノード１０４は、トランザクションの異なるプール１５４に基づきパズルを解こうとしているが、誰であっても１番の者が、最新のブロック１５１に含まれるトランザクションのセットを定義することに留意する。）。最終的に、ブロックチェーンノード１０４は、Aliceのトランザクション１５２jを含む順序付きプール１５４の一部についてパズルを解くだろう。）。一旦、新しいトランザクション１５２jを含むプール１５４についてproof-of-workが行われると、それはブロックチェーン１５０内のブロック１５１のうちの１つの一部となる。各トランザクション１５２は、以前のトランザクションへのポインタから構成されるので、トランザクションの順序もまた、不変的に記録される。

異なるブロックチェーンノード１０４は、最初に所与のトランザクションの異なるインスタンスを受信する可能性があり、従って、１つのインスタンスが公開（Publishing）されて新しいブロック１５１になる前に、どのインスタンスが「有効」であるかについて矛盾するビューを有することがあり、その時点で、全部のブロックチェーンノード１０４は公開されたインスタンスのみが有効なインスタンスであることに合意する。ブロックチェーンノード１０４が１つのインスタンスを有効であるとして受け入れ、次に第２インスタンスがブロックチェーン１５０に記録されていることを発見した場合、該ブロックチェーンノード１０４は、これを受け入れなければならず、最初に受け入れたインスタンス（つまり未だブロック１５１の中で公開されていないもの）を破棄する（つまり、無効であるとして扱う）。

アカウントベースのトランザクションモデルの一部として、幾つかのブロックチェーンネットワークにより運用される別のタイプのトランザクションプロトコルを「アカウントベース」のプロトコルと呼ぶことがある。アカウントベースの場合、各トランザクションは、過去の一連のトランザクションにおいて、先行するトランザクションのUTXOに戻って参照することによって移転される量を定義するのではなく、絶対的な口座（アカウント）残高を参照することによって移転される。すべてのアカウントの現在の状態は、ブロックチェーンと分離して、ネットワークのノードにより格納され、絶えず更新される。このようなシステムでは、トランザクションは、アカウントの連続したトランザクション記録（いわゆる「ポジション」）を用いて発注される。この値は、送信者により彼らの暗号署名の一部として署名され、トランザクション参照計算の一部としてハッシュされる。さらに、任意的なデータフィールドもトランザクションに署名することができる。このデータフィールドは、例えば、前のトランザクションIDがデータフィールドに含まれている場合、前のトランザクションを遡ってポイントしてよい。

＜UTXOベースのモデル＞
図２は、トランザクションプロトコルの例を示している。これは、UTXOベースのプロトコルの例である。トランザクション１５２（「Tx」と略す）は、ブロックチェーン１５０（各ブロック１５１は１つ以上のトランザクション１５２を含む）の基本的なデータ構造である。以下は、アウトプットベース又は「UTXO」ベースのプロトコルを参照して説明される。しかし、これは、全ての可能な実施形態に限定されるものではない。例示的なUTXOベースのプロトコルは、ビットコインを参照して説明されるが、他の例示的なブロックチェーンネットワーク上でも等しく実施できることに留意する。

UTXOベースのモデルでは、各トランザクション（「Tx」）１５２は、１つ以上のインプット２０２及び１つ以上のアウトプット２０３を含むデータ構造を含む。各アウトプット２０３は、未使用トランザクションアウトプット（UTXO）を含んでもよく、これは、別の新しいトランザクションのインプット２０２のソースとして使用することができる（UTXOが未だ償還されていない場合）。UTXOは、デジタルアセットの量を指定する値を含む。これは、分散型台帳上のトークンの設定数を表す。また、他の情報の中でも、UTXOは、それが由来するトランザクションのトランザクションIDも含んでよい。トランザクションデータ構造はまた、ヘッダ２０１も含んでよく、ヘッダ２０１は、インプットフィールド２０２及びアウトプットフィールド２０３のサイズの指示子を含んでもよい。ヘッダ２０１は、トランザクションのIDも含んでもよい。実施形態において、トランザクションIDは、トランザクションデータ（トランザクションID自体を除く）のハッシュであり、ノード１０４に提出された未処理トランザクション１５２のヘッダ２０１に格納される。

例えばAlice１０３aは、問題のデジタルアセットの量をBob１０３bに移転するトランザクション１５２jを作成したいと考えているとする。図２において、Aliceの新しいトランザクション１５２jは「Tx_１」とラベル付けされている。これは、Aliceにロックされているデジタルアセットの量を、シーケンス内の先行するトランザクション１５２iのアウトプット２０３に取り入れ、その少なくとも一部をBobに移転する。先行するトランザクション１５２iは、図２において「Tx_０」とラベル付けされている。Tx_０とTx_１は、単なる任意のラベルである。これらは、必ずしも、Tx_０がブロックチェーン１５１の第１トランザクションであること、又は、Tx_１がプール１５４の直ぐ次のトランザクションであることを意味しない。Tx_１は、まだAliceにロックされた未使用アウトプット２０３を有する任意の先行する（つまり祖先）トランザクションを指し示すことができる。

先行するトランザクションTx_０は、Aliceが彼女の新しいトランザクションTx_１を作成するとき、又は少なくとも彼女がそれをネットワーク１０６に送信するときに、既に妥当性確認され、ブロックチェーン１５０のブロック１５１に含まれていてもよい。それは、その時点で既にブロック１５１のうちの１つに含まれていてもよく、あるいは、順序付きセット１５４内でまだ待機していてもよく、その場合、新しいブロック１５１にすぐに含まれることになる。あるいは、Tx_０及びTx_１が生成されネットワーク１０６に送信されることができ、あるいは、ノードプロトコルが「孤児（orphan）」トランザクションのバッファリングを許容する場合にはTx_１の後にTx_０が送信されることもできる。ここでトランザクションのシーケンスの文脈で使用される「先行する」及び「後の」という用語は、トランザクション内で指定されたトランザクションポインタ（どのトランザクションがどの他のトランザクションを指すかなど）によって定義されるシーケンス内のトランザクションの順序を指す。それらは、「先行する」及び「相続する」又は「祖先」及び「子孫」、「親」及び「子」、等により、等しく置き換えられ得る。これは、必ずしも、それらが作成され、ネットワーク１０６に送られ、又は任意の所与のブロックチェーンノード１０４に到達する順序を意味しない。それにもかかわらず、先行するトランザクション（祖先トランザクション又は「親」）を指す後続のトランザクション（子孫トランザクション又は「子」）は、親トランザクションが妥当性確認されない限り、妥当性確認されない。親の前にブロックチェーンノード１０４に到着した子は孤児とみなされる。それは、ノードプロトコル及び／又はノードの行動に応じて、親を待つために特定の時間、破棄又はバッファリングされることがある。

先行するトランザクションTx_０の１つ以上のアウトプット２０３のうちの１つは、本明細書でUTXO_０とラベル付けされた特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタルアセットの量を指定する値と、後続のトランザクションが検証されるために、従ってUTXOが正常に償還されるために、後続のトランザクションのインプット２０２の中のアンロックスクリプトによって満たされなければならない条件を定義するロックスクリプトとを含む。典型的には、ロックスクリプトは、特定のパーティ（それが含まれているトランザクションの受益者）に量をロックする。すなわち、ロックスクリプトは、標準的に以下のようなアンロック条件を定義する：後続のトランザクションのインプット内のアンロックスクリプトは、先行するトランザクションがロックされたパーティの暗号署名を含む。

ロックスクリプト（別名scriptPubKey）は、ノードプロトコルによって認識されるドメイン固有の言語で書かれたコードの一部である。そのような言語の特定の例は、ブロックチェーンネットワークにより使用される「スクリプト」（Script，大文字S）と呼ばれる。ロックスクリプトは、トランザクションアウトプット２０３を消費するために必要な情報、例えば、Aliceの署名の必要条件を指定する。トランザクションのアウトプットには、アンロックスクリプトが現れる。アンロックスクリプト（別名：scriptSig）は、ロックスクリプトの基準を満たすために必要な情報を提供するドメイン固有の言語で書かれたコードの一部である。例えば、Bobの署名を含んでもよい。アンロックスクリプトは、トランザクションのインプット２０２に現れる。

図示の例では、Tx_０のアウトプット２０３のUTXO_０は、ロックスクリプト[ChecksigP_A]を含み、これは、UTXO_０が償還されるために（厳密には、UTXO_０を償還しようとする後続のトランザクションが有効であるために）、Aliceの署名SigP_Aを必要とする。[Checksig P_A]は、Aliceの公開－秘密鍵ペアからの公開鍵P_Aの表現（つまりハッシュ）を含む。Tx_１のインプット２０２は、Tx_１を指すポインタ（例えば、そのトランザクションID、実施形態ではトランザクションTx_０全体のハッシュであるTxID_０による）を含む。Tx_１のインプット２０２は、Tx_０の任意の他の可能なアウトプットの中でそれを識別するために、Tx_０内のUTXO_０を識別するインデックスを含む。Tx_１のインプット２０２は、さらに、Aliceが鍵ペアからのAliceの秘密鍵をデータの所定の部分（暗号において「メッセージ」と呼ばれることもある）に適用することによって作成された、Aliceの暗号署名を含むアンロックスクリプト<SigP_A>を含む。有効な署名を提供するためにAliceが署名する必要があるデータ（又は「メッセージ」）は、ロックスクリプトにより、又はノードプロトコルにより、又はこれらの組み合わせによって定義され得る。

新しいトランザクションTx_１がブロックチェーンノード１０４に到着すると、ノードはノードプロトコルを適用する。これは、ロックスクリプトとアンロックスクリプトを一緒に実行して、アンロックスクリプトがロックスクリプトで定義されている条件（この条件は１つ以上の基準を含むことができる）を満たしているかどうかをチェックすることを含む。実施形態では、これは、２つのスクリプトの連結を含む。

ここで、「||」は連結を表し、「<...>」はスタックにデータを配置することを意味し、「[...]」はロックスクリプトに含まれる機能である（本例では、スタックベースの言語）。同等に、スクリプトは。、スクリプトを連結するのではなく共通のスタックにより１つずつ実行されてよい。いずれの方法でも、一緒に実行する場合、スクリプトは、Tx_０のアウトプット内のロックスクリプトに含まれるAliceの公開鍵P_Aを使用して、Tx_１のインプット内のアンロックスクリプトが、データの期待部分に署名するAliceの署名を含むことを認証する。また、データの期待部分（「メッセージ」）も、この認証を実行するために含まれる必要がある。実施形態において、署名されたデータは、Tx_１の全体を含む（従って、データの署名された部分がすでに本質的に存在するので、データの署名された部分を平文で指定する別個の要素が含まれる必要はない）。

メッセージmは、署名されているトランザクションの特定の詳細から導出される。このメッセージは署名から妥当性確認まで同一である必要があるため、この処理により、署名を無効にせずにメッセージに含まれるトランザクションデータを変更できないようにする。

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

署名メッセージ内のトランザクションの詳細を使用するこのプロセスは、トランザクションのブロードキャストからブロックチェーンに公開される時点までの遅延の間のセキュリティの重要な要素を提供する。ただし、署名される（すなわち署名メッセージに含まれる）トランザクションの任意の要素は、署名を無効にしないと更新できないため、一部のトランザクションフィールドは署名メッセージに含めることができない。これらのフィールドは、生成後に署名を含めるように更新する必要がある各インプットのアンロックスクリプトと、完全なトランザクション（アンロックスクリプト内の署名を含む）のダブルハッシュであるトランザクションID（TxID）である。両方のフィールドは、署名を含む（又はそれから導出される）必要があるため、署名が生成されるまで確定できない。

公開－秘密暗号法による認証の詳細は、当業者には周知であろう。基本的に、Aliceが彼女の秘密鍵を用いてメッセージに署名した場合、Aliceの公開鍵とそのメッセージが平文ならば、ノード１０４のような別のエンティティは、そのメッセージがAliceによって署名されていなければならないことを認証することができる。署名は、典型的には、メッセージをハッシュし、ハッシュに署名し、署名としてメッセージにこれをタグ付けすることによって、公開鍵の所有者が署名を認証することを可能にする。従って、実施形態では、特定のデータ片又はトランザクションの部分等に署名するという言及は、データ片又はトランザクションの部分のハッシュに署名することを意味し得る。

Tx_１内のアンロックスクリプトが、Tx_０のロックスクリプトで指定された１つ以上の条件を満たす場合（示される例では、Aliceの署名がTx_１内で提供され、認証されている場合）、ブロックチェーンノード１０４は、Tx_１が有効であるとみなす。これは、ブロックチェーンノード１０４がTx_１を保留トランザクションの順序付きプール１５４に追加することを意味する。ブロックチェーンノード１０４は、トランザクションTx_１をネットワーク１０６内の１つ以上の他のブロックチェーンノード１０４に転送し、それによって、それがネットワーク１０６全体に伝播されることになる。一旦、Tx_１が妥当性確認され、ブロックチェーン１５０に含まれると、これは、Tx_０からのUTXO_０を消費したものとして定義する。Tx_１は、未使用トランザクションアウトプット２０３を使用する場合にのみ有効であることに留意されたい。別のトランザクション１５２によって既に消費されたアウトプットを消費しようとする場合、Tx_１は、たとえ他のすべての条件が満たされていても無効となる。従って、ブロックチェーンノード１０４は、先行するトランザクションTx_０において参照されたUTXOが既に消費されているかどうか（既に別の有効なトランザクションへの有効なインプットを形成しているかどうか）もチェックする必要がある。これが、ブロックチェーン１５０がトランザクション１５２に定義された順序を課すことが重要である理由の１つである。実際には、所与のブロックチェーンノード１０４は、トランザクション１５２が消費されたUTXO２０３をマークする別個のデータベースを維持することができるが、最終的には、UTXOが消費されたかどうかを定義するのは、ブロックチェーン１５０内の別の有効なトランザクションへの有効なインプットを既に形成しているかどうかである。

所与のトランザクション１５２の全部のアウトプット２０３の中で指定された総量が全部のそのインプット２０２により指される総量より大きい場合、これは、殆どのトランザクションモデルにおいて無効の別の基礎である。従って、このようなトランザクションは、伝播されず、ブロック１５１に含まれることもない。

UTXOベースのトランザクションモデルでは、所定のUTXOを全体として使用する必要があることに注意する。UTXOで定義されている量のうち、別の分量が消費されている一方で、ある分量を「残しておく」ことはできない。ただし、UTXOからの量は、次のトランザクションの複数のアウトプットに分割できる。例えば、Tx_０のUTXO_０で定義された量は、Tx_１の複数のUTXOに分割できる。従って、AliceがBobにUTXO_０で定義された量の全てを与えることを望まない場合、彼女は残りの量を使って、Tx_１の第２アウトプットの中で自分自身にお釣りを与えるか、又は別のパーティに支払うことができる。

特に、Aliceは、通常、彼女のトランザクション１０４をブロック１５１に含めることに成功したビットコインノード１０４のための手数料も含める必要がある。Aliceがそのような手数料を含まない場合、Tx_０はブロックチェーンノード１０４によって拒否される可能性が高く、したがって、技術的には有効であるが、それは伝播されず、ブロックチェーン１５０に含まれない（ノードプロトコルは、彼らが望まない場合には、ブロックチェーンノード１０４にトランザクション１５２を受け入れることを強制しない）。一部のプロトコルでは、トランザクション手数料は、独自の別個のアウトプット２０３を必要としない（すなわち、別個のUTXOを必要としない）。代わりに、インプット２０２によって示される総量と、所与のトランザクション１５２のアウトプット２０３で指定される総量との間の差は、トランザクションを公開するブロックチェーンノード１０４に自動的に与えられる。例えば、UTXO_０へのポインタがTx_１への唯一のインプットであり、Tx_１は１つのアウトプットUTXO_１しか持っていないとする。UTXO_０で指定されたデジタルアセットの量がUTXO_１で指定された量より多い場合、その差は、UTXO_１を含むブロックを生成するproof-of-work競争の勝者であるノード１０４により割り当てられてよい。しかし、代替的又は追加的に、必ずしも、トランザクション１５２のUTXO２０３のうちの独自のものにおいて、トランザクション手数料を明示的に指定できることは除外されない。

Alice及びBobのデジタルアセットは、ブロックチェーン１５０内の任意のトランザクション１５２の中で彼らにロックされたUTXOで構成されている。従って、典型的には、所与のパーティ１０３のアセットは、ブロックチェーン１５０を通して、様々なトランザクション１５２のUTXO全体に分散される。ブロックチェーン１５０内のどこにも、所与のパーティ１０３の総残高を定義する１つの数値は記憶されていない。各パーティへのロックされた、別の将来の（onward）トランザクションに未だ使用されていない全ての様々なUTXOの値をまとめることは、クライアントアプリケーション１０５におけるウォレット機能の役割である。ビットコインノード１０４のいずれかに格納されたブロックチェーン１５０のコピーをクエリすることにより、これを行うことができる。

スクリプトコードは、概略的に表現されることが多い（すなわち、正確な言語を用いない）ことに注意する。例えば、特定の機能を表現するオペレーションコード（opcode、オペコード）を使用してよい。「OP_....」は、スクリプト言語の特定のオペコードを表す。例として、OP_RETURNは、ロックスクリプトの始めにあるOP_FALSEが先行するとき、トランザクション内にデータを格納することができ、それによってデータをブロックチェーン１５０に不変に記録することができるトランザクションの使用不可能アウトプットを生成するためのスクリプト言語のオペコードである。例えば、データは、ブロックチェーンに格納することが望ましい文書を含むことができる。

通常、トランザクションのインプットは、公開鍵P_Aに対応するデジタル署名を含む。実施形態において、これは楕円曲線secp２５６k１を使用するECDSAに基づく。デジタル署名は、特定のデータに署名する。幾つかの実施形態では、所与のトランザクションについて、署名はトランザクションインプットの一部、及びトランザクションアウトプットの全部又は一部に署名する。署名するアウトプットの特定の部分はSIGHASHフラグに依存する。SIGHASHフラグは、通常、署名の最後に含まれる４バイトのコードであり、どのアウトプットが署名されるかを選択する（従って、署名の時点で固定される）。

６つの異なるフラグタイプを使用すると、署名は選択的に承認できるため、すべてのインプットとアウトプット、又は様々なサブセットのいずれかの詳細を確定できる。インデックス２内のインプットをアンロックする署名に基づいて、異なるセットを以下に示す。保証されたインプットとアウトプットは太字で示されている。

各表の上部に表示されるフラグ名は、メッセージに含まれるアウトプット（ALL、NONE、又はSINGLE）を示す。各フラグには２つの変形があり、どのインプットが署名メッセージに含まれるかを示すシグナリングする。「standard」変形（図２の表の一番上の行：ALL、NONE、SINGLE）にはすべてのインプットが含まれ、一方、「anyone can pay」又はACP変形（一番下の行：ALL|ACP、NONE|ACP、SINGLE|ACP）には、署名がアンロックするインプットのみが含まれる。単一（single）フラグ変形（SINGLE又はSINGLE|ACP）の場合、署名される単一のアウトプットは、アンロックされるインプットに一致するインデックス位置にあるものであることに注意する。

sighashフラグの選択によって影響を受けるメッセージ内のフィールドは、Hash（Outpoints）、Hash（nSeqs）、Hash（Outputs）、及びsigHashFlagフィールド自体である。ハッシュフィールドを計算する場合、含まれていないインプットとアウトプット（sighashフラグに基づく）は空になり、残りのデータは順に連結されてハッシュされる。例えば、sighash ALL|ACP署名の場合、インデックス０（Outpoint_i）とインデックス１（Outpoint_j）のインプットの情報は削除されるが、すべてのアウトプットの詳細は保持され、以下のハッシュフィールドが生成される：

sighash SINGLE署名の場合、すべてのインプットが保持される一方で、１つのアウトプット（署名の位置に一致するインデックス２のアウトプット）だけが保持され、次のようになる：

メッセージ文字列内の他のフィールドは、sighashフラグの影響を受けない。バージョン（version）フィールドとロックタイム（locktime）フィールド（これらは署名メッセージに常に含まれる）は、署名がどのインプットを許可するかに関係なく、同じトランザクションに基づくすべての署名で同じである。残りのフィールド（outpoint_k、lockScriptLength_k、lockScript_k、value_k、及びnSeq_k）は、署名されているインプットに直接関連しているため、どのインプットをアンロックするために署名が作成されたかに応じて変更されるが、アンロックするインプットは常に署名されている必要があるため、sighashフラグの選択の影響を受けない。

署名メッセージは、一致する秘密鍵とともにECDSA署名アルゴリズムに渡され、署名（r,s）が生成される。この署名をブロックチェーントランザクションに含めるには、承認するインプットのアンロックスクリプトフィールドに配置される単一の文字列に変換する必要がある。文字列は、署名の２つの要素rとsを連結し、DER標準を使用してバイト形式に符号化することによって作成される。

メッセージでは、sighashフラグが最後のバイトとして追加され、各sighashフラグは、以下の表に示すように特定の値で表され、以下のシリアル化された署名を示す：

P２PKH（pay to public key hash）ロックスクリプトを使用するアウトポイントの場合、署名は、アンロックスクリプトフィールドに配置される前に、関連付けられた公開鍵を更に追加されることに注意する。検証中に、トランザクション内の各署名について、トランザクション情報とsighashフラグに基づいてメッセージが再作成され、そのメッセージで署名の有効性がチェックされる。

６つのsighashフラグは、１つのインプット（NONE|ACP）からすべてのインプットとアウトプット（ALL）まで、あらゆるものに（署名メッセージに含めることで）「署名」する柔軟性を提供する。sighash ALL以外のフラグの場合、これは、署名メッセージから除外されるトランザクション情報を、署名を無効にすることなく変更できることを意味する。これにより、sighashALLを使用する標準的な方法よりも柔軟性が高まる。例えば、anyone can payフラグ変形は、署名されているもの以外のインプットの詳細に制限を加えず、他のパーティが各々の他の署名を無効にすることなく、トランザクションにインプット（すなわち「pay」）を追加できる。

ロックスクリプトは、通常、各々のトランザクションがロックされているパーティの公開鍵を含んでいることを表す「scriptPubKey」と呼ばれることがある。アンロックスクリプトは、通常、対応する署名を提供することを表す「scriptSig」と呼ばれることがある。しかし、より一般的には、UTXOが償還される条件が署名を認証することを含むことは、ブロックチェーン１５０の全てのアプリケーションにおいて必須ではない。より一般的には、スクリプト言語は、任意の１つ以上の条件を定義するために使用され得る。したがって、より一般的な用語「ロックスクリプト」及び「アンロックスクリプト」が好ましい。

＜サイドチャネル＞
図１に示されるようにAlice及びBobのコンピュータ装置１０２a、１２０bの各々にあるクライアントアプリケーションは、付加的な通信機能を備えてよい。この追加機能は、Alice１０３aが、（いずれかのパーティ又は第３者の勧誘で）Bob１０３bと別個のサイドチャネル１０７を確立することを可能にする。サイドチャネル１０７は、ブロックチェーンネットワークと別個にデータの交換を可能にする。このような通信は、時に「オフチェーン」通信と呼ばれる。例えば、これは、パーティの一方がネットワーク１０６にトランザクション１５２をブロードキャストすることを選択するまで、ブロックチェーンネットワーク１０６上に登録されることなく、又はチェーン１５０上に進むことなく、AliceとBobとの間でトランザクション１５２を交換するために使用され得る。このようにトランザクションを共有することは、時に、「トランザクションテンプレイト」の共有と呼ばれる。トランザクションテンプレイトは、完全なトランザクションを形成するために必要な１つ以上のインプット及び／又はアウトプットが欠けていてよい。代替又は追加で、サイドチャネル１０７は、任意の他のトランザクションに関連するデータ、例えば、鍵、交渉される量又は条項、データコンテンツ、等を交換するために使用されてよい。

サイドチャネル１０７は、ブロックチェーンネットワーク１０６と同じパケット交換ネットワーク１０１を介して確立されてもよい。代替又は追加で、サイドチャネル１０７は、モバイルセルラネットワーク、又はローカル無線ネットワークのようなローカルエリアネットワーク、又はAliceとBobの装置１０２a、１０２bの間の直接有線若しくは無線リンクのような異なるネットワークを介して確立されてよい。一般に、本願明細書のどこかで言及されるサイドチャネル１０７は、「オフチェーン」で、つまりブロックチェーンネットワーク１０６と別個にデータを交換するための１つ以上のネットワーキング技術又は通信媒体を介する任意の１つ以上のリンクを含んでよい。１つより多くのリンクが使用されるとき、全体としてのオフチェーンリンクのバンドル又は集合がサイドチャネル１０７と呼ばれてよい。従って、Alice及びBobが特定の情報又はデータ片等をサイドチャネル１０７を介して交換すると言われる場合、これは、必ずしも全部のこれらのデータ片が正確に同じリンク又は同じ種類のネットワークを介して送信される必要があることを意味しないことに留意する。

クライアントソフトウェア
図３Aは、本開示の方式の実施形態を実装するためのクライアントアプリケーション１０５の例示的な実装を示す。クライアントアプリケーション１０５は、トランザクションエンジン４０１と、ユーザインタフェース（UI）レイヤ４０２と、を含む。トランザクションエンジン４０１は、クライアント１０５の基礎トランザクション関連機能、例えば、トランザクション１５２を形成し、トランザクション及び／又はサイドチャネル３０１を介して他のデータを受信及び／又は送信し、及び／又はブロックチェーンネットワーク１０６を介して伝播されるように１つ以上のノード１０４にトランザクションを送信するように、上述したスキームに従って、さらに詳細に説明するように、構成される。ここに開示された実施形態に従って、各クライアント１０５のトランザクションエンジン４０１は、以下のうちの１つ以上を実行するよう構成される機能４０３を含む：
－トークン発行トランザクションを生成することによりトークンを生成する、
－投票オプションを定義すること、投票へ公開鍵を割り当てること、投票オプションと公開鍵を投票者へ送信すること、により投票を開始する、
－投票者の１人の投票に対応するインプット－アウトプットペアを生成し、そのインプット－アウトプットペアを投票コーディネータに送信する、
－受信したインプット－アウトプットペアを含む投票トランザクションを生成する、
－投票条件が満たされたかどうかを決定する。

UIレイヤ４０２は、各々のユーザコンピュータ機器１０２のユーザ入力／出力（I/O）手段を介して、機器１０２のユーザ出力手段により各々のユーザ１０３へ情報を出力すること及び機器１０２のユーザ入力手段により各々のユーザ１０３から入力を受信することを含む、ユーザインタフェースをレンダリングするよう構成される。例えば、ユーザ出力手段は、視覚的出力を提供する１つ以上のディスプレイスクリーン（タッチ又は非タッチスクリーン）、オーディオ出力を提供する１つ以上のスピーカ、及び／又は触覚出力を提供する１つ以上の触覚出力装置、等を含み得る。ユーザ入力手段は、例えば、１つ又は複数のタッチスクリーンの入力アレイ（出力手段に使用されるものと同じか又は異なる）、マウス、トラックパッド又はトラックボールなどの１つ又は複数のカーソルベースの装置、音声又は声の入力を受け取るための１つ又は複数のマイクロフォン及び音声認識アルゴリズム、手動又は身体のジェスチャの形態で入力を受け取るための１つ又は複数のジェスチャベースの入力装置、又は１つ又は複数の機械的ボタン、スイッチ又はジョイスティックなどを含むことができる。

注：本願明細書において種々の機能が同じクライアントアプリケーション１０５に統合されるとして説明されることがあるが、これは、必ずしも限定的ではなく、代わりに、それらは２つ以上の異なるアプリケーションのスーツに実装されてよく、例えば一方が他方へのプラグインであるか、又はAPI（application programming interface）を介してインタフェースする。例えば、トランザクションエンジン４０１の機能は、UIレイヤ４０２と別個のアプリケーション、又は所与のモジュールの機能に実装されてよく、トランザクションエンジン４０１が１つより多くのアプリケーションの間で分割されてよい。また、記載の機能の一部又は全部が、例えばオペレーティングシステムレイヤに実装されることを除外しない。本願明細書のどこかで、単一の又は所与のアプリケーション１０５等を参照する場合、これが単に例としてであること、より一般的には、記載の機能が任意の形式のソフトウェアで実装され得ることが理解される。

図３Bは、Aliceの機器１０２a上のクライアントアプリケーション１０５aのUI層４０２によりレンダリングされてよいユーザインタフェース（UI）３００の例の模擬表示を与える。同様のUIが、任意の他のパーティのクライアント１０５b Bobの機器１０２b、又は任意の他のパーティの機器によりレンダリングされてよいことが理解される。

例示として、図３Bは、Aliceの観点からUI３００を示す。UI３００は、ユーザ出力手段を介して別個のUI要素として描画される１つ以上のUI要素３０１、３０２、３０３を含んでもよい。

例えば、UI要素は、例えば、画面上の異なるボタン、又はメニュー内の異なるオプション等の１つ以上のユーザ選択可能要素３０１を含むことができる。ユーザ入力手段は、スクリーン上のUI要素をクリック若しくはタッチすることにより、又は所望のオプションの名称を発話することにより、ユーザ１０３（この場合にはAlice１０３a）がオプションのうちの１つを選択又は操作できるよう構成される（注：ここで使用される「手動（manual）」は単に自動の反対を意味し、必ずしも手の使用に限定されない）。オプションを使用すると、ユーザ（Alice）は、投票を行うための投票指示で提供されている投票オプションの事前に定義されたセットのうちの１つを選択したり、投票オプションを定義するときに１つ以上の推奨される投票オプションを選択したり、受信したインプット－アウトプットペアを選択して完全な投票トランザクションに含めたり、ユーザディレクトリからトークンを生成するユーザグループを選択したりすることができる。

代替的又は追加的に、UI要素は、１つ以上のデータエントリフィールド３０２を含むことができ、ユーザは、OP_RETURNに含まれるべきデータ又は投票指示に含まれるべき投票オプションを定義するテキストを入力することができる。これらのデータエントリフィールドは、ユーザ出力手段、例えば、オンスクリーンを介してレンダリングされ、データは、ユーザ入力手段、例えば、キーボード又はタッチスクリーンを介してフィールドに入力することができる。あるいは、データは、例えば、音声認識に基づいて口頭で受信され得る。

代替的又は追加的に、UI要素は、ユーザに情報を出力するために出力される１つ以上の情報要素３０３を含んでもよい。例えば、これ／これらは、スクリーン上に描画されるか、又は可聴でレンダリングされることがある。

例えば、この／これらは、スクリーン上に描画されるか、又は可聴で描画されることがある。これらのUI要素の機能は、間もなく更に詳細に議論される。また、図３に示されたUI３００は、単に概略的なモックアップであり、実際には、１つ以上のさらなるUIエレメントを含んでもよく、これは、簡潔さのために示されていないことが理解される。

＜ノードソフトウェア＞
図４は、UTXO又はアウトプットに基づくモデルの例における、ネットワーク１０６の各ブロックチェーンノード１０４で実行され得るノードソフトウェア４５０の例を示す。別のエンティティが、ネットワーク１０６上でノード１０４として分類されずに、つまり、ノード１０４に必要なアクションを実行せずに、ノードソフトウェア４５０を実行できることに注意する。ノードソフトウェア４５０は、プロトコルエンジン４５１、スクリプトエンジン４５２、スタック４５３、アプリケーションレベルの決定エンジン４５４、及び１つ以上のブロックチェーン関連機能モジュールのセット４５５を含んでよいが、それらに限定されない。各ノード１０４は、合意モジュール４５５C（例えば、proof-of-work）、伝播モジュール４５５P、及びストレージモジュール４５５S（例えば、データベース）の３つすべてを含むが、これらに限定されないノードソフトウェアを実行できる。プロトコルエンジン４０１は、標準的に、トランザクション１５２の異なるフィールドを認識し、それらをノードプロトコルに従い処理するよう構成される。トランザクション１５２j（Tx_j）が受信され、別の先行するトランザクション１５２i（Tx_m-１）のアウトプット（例えばUTXO）をポイントするインプットを有するとき、プロトコルエンジン４５１は、Tx_j内のアンロックスクリプトを識別し、それをスクリプトエンジン４５２に渡す。プロトコルエンジン４５１は、更に、Tx_jのインプットの中のポインタに基づき、Tx_iを識別し検索する。Tx_iはブロックチェーン１５０上で公開されてよい。この場合、プロトコルエンジンは、ノード１０４に格納されているブロックチェーン１５０のブロック１５１のコピーからTxiを取得できる。又は、Tx_iは、まだブロックチェーン１５０上で公開されていない可能性がある。その場合、プロトコルエンジン４５１は、ノード１５４によって保持されている未公開トランザクションの順序付きセット１５４からTx_iを取得することができる。いずれの方法も、スクリプトエンジン４５１は、Txiの参照されるアウトプットの中のロックスクリプトを識別し、これをスクリプトエンジン４５２に渡す。

スクリプトエンジン４５２は、従って、Tx_iのロックスクリプト、及びTx_j対応するインプットからのアンロックスクリプトを有する。例えば、Tx_０及びTx_１が図２に示されるが、同じことがトランザクションの任意のペアに適用され得る。スクリプトエンジン４５２は、前述のように２つのスクリプトを一緒に実行し、これらは、使用されているスタックに基づくスクリプト言語（例えばScript）に従い、スタック４５３にデータを置くことと、データを検索することとを含む。

スクリプトを一緒に実行することにより、スクリプトエンジン４５２は、アンロックスクリプトがロックスクリプトの中で定義された１つ以上の基準を満たすか否か、つまり、それがロックスクリプトが含まれるアウトプットを「アンロック」するか否かを決定する。スクリプトエンジン４５２は、この決定の結果をプロトコルエンジン４５１に返す。スクリプトエンジン４５２は、アンロックスクリプトは対応するロックスクリプトの中で指定された１つ以上の基準を満たすと決定した場合、結果「真」を返す。その他の場合、それは結果「偽」を返す。

アウトプットに基づくモデルでは、スクリプトエンジン４５２からの結果「真」は、トランザクションの有効性についての条件のうちの１つである。標準的に、同様に満たされなければならない、プロトコルエンジン４５１により評価される１つ以上の更なるプロトコルレベルの条件が更にあり、Tx_jのアウトプットの中で指定されたデジタルアセットの総量がそのインプットによりポイントされる総量を超えないこと、Tx_iのポイントされるアウトプットは別の有効なトランザクションにより未だ使用されていないこと、等である。プロトコルエンジン４５１は、１つ以上のプロトコルレベルの条件と一緒にスクリプトエンジン４５２からの結果を評価し、それら全部が真である場合、トランザクションTx_jを妥当性確認する。プロトコルエンジン４５１は、トランザクションが有効であるかどうかの指示を、アプリケーションレベル決定エンジン４５４に出力する。Tx_jが実際に妥当性確認されたことのみを条件として、決定エンジン４５４は、合意モジュール４５５C及び伝播モジュール４５５Pの一方又は両方を、それらの各々のブロックチェーンに関連する機能をTx_jに関して実行するよう制御することを選択してよい。これは、ブロック１５１に組み込むためにノードの各々の順序付きトランザクションセット１５４にTx_jを追加する合意モジュール４５５Cと、ネットワーク１０６内の別のブロックチェーンノード１０４にTx_jを転送する伝播モジュール４５５Pを含む。任意的に、実施形態では、アプリケーションレベル決定エンジン４５４は、これらの機能のうちのいずれか又は両方をトリガする前に、１つ以上の追加条件を適用してよい。例えば、決定エンジンは、トランザクションがだとうせされたこと、及び十分なトランザクション手数料が残されることの両方を条件としてのみ、トランザクションを公開することを選択してよい。

用語「真（true）」及び「偽（false）」は、本願明細書では、必ずしも単一の２進数字（ビット）のみの形式で表現される結果を返すことに限定しないが、それは勿論１つの可能な実装であることに留意する。より一般的には、「真」は、成功又は肯定的な結果を示す任意の状態を表すことができ、「偽」は、不成功又は非肯定的な結果を示す任意の状態を表すことができる。例えば、アカウントに基づくモデルでは、「真」の結果は、署名の暗示的なプロトコルレベルの検証と、スマートコントラクトの追加の肯定的なアウトプットとの組合せにより示され得る（全体の結果は、両方の個々の結果が真である場合に、真を伝達すると考えられる）。

トークン
一部のトランザクションは、次に説明する投票トランザクションなど、異なるユーザに関連付けられたインプットを含む。トランザクションに貢献できるユーザを制限するために、許可された貢献者にトークンが発行され、許可された貢献者がトランザクション内でインプットとアウトプットを提供できるようになる。

トークンは、投票での使用を参照して説明される。

トークン発行トランザクションの例を以下及び図５に示す。トランザクションは、トークンを使用して生成されるトランザクションに責任のあるパーティの装置によって生成される。投票の場合、パーティは投票コーディネータである。

トークン発行トランザクション５００は、未使用トランザクションアウトプットのトランザクションIDとインデックスを識別するアウトポイント５０４と、トークン発行トランザクション５００のすべてのインプットとアウトプットが投票コーディネータの署名によって署名されるように、sighash ALLフラグを持つ投票コーディネータの署名を含むアンロックスクリプト５０６と、を含む単一のインプットを持つ。

トークン発行トランザクション５００は複数のアウトプットを持つ。有権者ごとに１つずつのトークンのセット５１０、及びコーディネータに関連付けられたアウトプットがある。投票コーディネータに関連付けられたアウトプットは、未使用トランザクションアウトプットと、UTXOをコーディネータの公開鍵にロックするロックスクリプトと、を含む。

図５には３つのトークンがあり、各々に対応するロックスクリプト５０８があり、トークンがロックされている適格な投票者を識別する。トークンは、ダストUTXOと見なされる可能性があるように、低い値又は公称値を持つ未使用トランザクションアウトプットである。これは、投票者が投票しない場合、投票コーディネータによって失われるデジタルアセットはわずかであり、投票者が投票しないインセンティブはほとんどないことを意味する。ロックスクリプトは、投票者がトークンを使用して投票するときに使用する必要があるsighashフラグを定義する署名条件も含んでいる。投票者の一部のみが投票する必要があり、そのため投票の前にインプットを知ることができない定足数投票の場合、署名条件は、SINGLE|ACP sighashフラグを使用する必要があることを定義する。一方、すべての投票者が投票の前にすべてのインプットを知る必要がある場合、署名条件はいずれかのsingle sighashフラグを定義できる。つまり、SINGLE|ACP又はSINGLEが、署名条件の中で定義される。

トークンを使用すると、署名条件は、署名に使用されるsighashフラグを示す署名の最後のバイトが、定義された署名条件に関連付けられた特定の値と等しいかどうかを確認する。例えば、sighash SINGLE|ACP（バイト値０x８３）が使用されていることを確認するには、ロックスクリプトの先頭に次の一連のOPコードを含めることができる：

このコードの説明は付録Aにある。与えられたコードはSCRIPTコードの一例にすぎず、当業者は同じ結果を達成するために使用できる他のSCRIPTコードを知っていることが理解される。

その後、資格のある投票者は、トークン発行トランザクションと投票者にロックされたUTXOを識別するアウトポイント、トークンがロックされた投票者の署名、及びトークンのロックスクリプト内で示されたsighashフラグを提供することによって、投票トランザクション内の自分のトークンを使用できる。

上記のトークンは、複数のパーティが同じトランザクションに貢献する他のトランザクションに使用できる。トークンは、トランザクションに貢献できるパーティを制限する方法を提供し、権限のないパーティからの貢献を簡単に識別する方法を提供する。

投票方法
投票では、複数のパーティが１つのトランザクションに貢献する。

sighash ALLを使用して署名を適用する場合、ALLフラグを有する署名が適用されると、インプット又はアウトプットをそれ以上編集することができないため、署名を開始する前に、すべてのインプットとアウトプットの詳細を含むトランザクション全体を定義する必要がある。これは、すべてのパーティが最初に共同でトランザクションを定義し、次に２回目に署名する必要があることを意味する。これと対照的に、異なるsighashフラグを使用すると、すべてのトランザクションの詳細を事前に定義する必要なく、パーティが個別に異なるアウトプットを設定して署名を適用できるため、パーティ間に一定の自律性を提供できる。

関係者は異なる時間に投票を行い、各パーティが選択した投票オプションは匿名のままにしておくことが望ましいため、パーティは、パーティが提供したアウトプットのみが署名メッセージに含まれるように、single sighashフラグでインプットに署名する。他の投票者が知らない間に、投票者が別の投票者の投票をトランザクションから削除しないようにするために、トランザクションは投票コーディネータによって生成される。投票コーディネータは、投票トランザクションをコンパイルし、すべての投票が受信されて含まれた後にALL sighashフラグで投票トランザクションを承認する。

ACPフラグ変形は、インプットを独立して定義できるため、複数のインプットが存在する状況での使用に適している。同様に、SINGLEフラグの変形では、他のアウトプットを修正せずに特定のアウトプットに署名することができる。これらの２つの機能は、SINGLE|ACPフラグを使用して、他のインプット及びアウトプットの詳細や数に制限を設けることなく、一致するインデックス位置に存在するインプット－アウトプットペアに署名できることを意味する。これにより、ペアを１つのトランザクションに結合するためのかなりの自由度が得られる。すべてのインプット及びアウトプットが署名されているため、完全なトランザクションが有効であるための唯一の要件は、インプットの結合値が、割り当てられたすべてのアウトプットと適切なトランザクション手数料をカバーするのに十分であることである。例えば、４つの独立して署名されたペアのセットから形成される、以下に示すトランザクションTx及びTx'は、インプット値がアウトプット値を超える場合に両方とも有効になる。

しかし、sighash SINGLE|ACPは非常に柔軟性がある一方で、柔軟性の可能性も残している。SINGLE|ACPを使用して署名された任意のインプット－アウトプットペアは、元の署名を無効にすることなくコピーして競合するトランザクションに含めることができる。傍受者（interceptor）が変更されたトランザクションをネットワークにブロードキャストする場合、ネットワーク上の一部のノードが元のトランザクションよりも前に変更されたバージョンを受信する可能性があるため、トランザクションのどのバージョンがブロックチェーンに公開されるかは定かではない。これは、署名されたペアのインプットの値がアウトプットよりも大きい場合に特に問題となる。つまり、変更されたトランザクションでは、余分な値を傍受者のアドレスに割り当てることができる。従って、干渉を抑制するために、SINGLE|ACP署名済みペアは、インプット値を割り当てずに残しておくべきではない。

投票の定義
投票コーディネータは、投票を定義する。

投票には事前に定義されたオプションのセットがあり、投票者は事前に定義されたオプションの１つを選択する必要がある。この例としては、選挙に立候補している候補者の１人を投票者が選択する選挙投票がある。投票には「その他」オプションを含めることができ、ユーザが独自の回答を入力できる場合がある。

投票コーディネータは、候補者リストなどのオプションのセットを定義する。投票コーディネータは、各々のオプションに異なる公開鍵を割り当てることができる。これらの割り当てはデータベースに格納される。公開鍵を使用してアドレスを生成できる。投票者が定義済みの投票オプションの１つを選択すると、未使用トランザクションのアウトプットは選択したオプションに関連付けられた公開鍵にロックされる。

投票者は、他のユーザ定義の入力を提供できる場合がある。例えば、投票者は投票オプションを選択し、データエントリフィールドにコメントを入力することによって、投票結果に含めるためのさらなるコメントを提供できる。

投票コーディネータは、投票者がテキストを入力することを許可すると定義する。投票者が投票に参加すると、投票の未使用トランザクションアウトプットは選択された投票オプションの公開鍵にロックされ、テキストはトランザクションのOP_RETURN内にレンダリングされる。

完全なグループ投票
グループのすべてのメンバーが投票しなければならない秘密投票を制定したいグループを考える。投票オプションは、上記のように投票コーディネータによって事前に定義されている必要があり、投票者はすべての投票が行われるまで互いの選択を見ることができないようにする必要がある。個々の投票は、単一の投票パーティによって独立してアウトプットを設定及び署名できる場合には、単一のアウトプットの詳細によってトランザクション内で表すことができる（例えば、すべての投票選択を特定のアウトプットアドレスに関連付けることによって）。これを可能にするには、投票トランザクションに各投票者からのインプットと、単一のsighashフラグを使用して署名された一致するアウトプットを含める必要がある。インプットは、投票に先立ってグループの各メンバーに発行される名目値の投票トークンにすることができる。

例えば、３人の投票者（Alice、Bob、Charlie）とコーディネータ（Delilah）のグループの場合、次のように投票を行うことができる。

１．Delilahは、投票トークンとして機能する３つのダストUTXOを作成するトランザクションを作成し、Alice、Bob、Charlieに各々１つずつ割り当てる。

２．Delilahは、トランザクション手数料をカバーするのに十分な資金を含む彼女が制御する追加のインプットと一緒に、これらのトークンUTXOを投票トランザクションテンプレイトのインプットとして追加する。彼女は、投票の各選択肢に対応するアウトプットアドレスのリストとともに、このテンプレイトをAlice、Bob、Charlieに送信する。

３．Alice、Bob、Charlieは各々、自分の投票選択を反映するように指名されたアウトプット詳細を設定し、sighash SINGLEを使用して署名を作成し、インプットのアンロックスクリプトに配置する。Signing SINGLEは、他のインデックスに設定されたアウトプットに制限を設けないため、有効な署名を作成するために他のパーティの投票選択を知る必要はない。すべての投票者は、部分署名されたトランザクション（彼らの投票を表す）をDelilahに返す必要がある。例えば、Bobの投票は次のような形式になる：

４．Delilahはすべての投票を受信すると、それらを１つの投票トランザクションに結合し、sighash ALLを使用して彼女のインプットの使用を妥当性確認する署名を作成し、トランザクションをブロードキャストして、投票の不変のレコードを提供する。

Delilahは、投票テンプレイトを設定し、投票を照合する必要があるが、結果に干渉する機会はない。パーティの署名の前にインプットを事前に定義することで、グループは、有効なトランザクションを作成するためにすべてのパーティが投票を提供しなければならないことを保証する。同様に、インプットは事前に指定された鍵を保持するパーティによってのみ妥当性確認できるため、他の政党（Delilahを含む）によって投票が改竄されることはない。

図６は、完全なグループ投票の投票トランザクション６００の例であり、図５のトークン発行トランザクションを使用して投票トークンが発行される。投票トランザクション６００は、４つのインプットと４つのアウトプットを含む。

０番目のインデックスには、第１投票者によって提供される第１インプット－アウトプットペアがある。インプットは、非署名部分と署名部分を含む。非署名部分は、図５のトークン発行トランザクションのインデックス０にあるトークンを示すアウトポイントを含み、署名部分は、トークンがロックされている公開鍵を持つ第１投票者の署名と、SINGLE sighashフラグを含む。アウトプットは、トークンの値と等しいデジタルアセット値と、ユーザが選択した投票オプション－投票オプション１のアドレスを含むロックスクリプトと、を含む。署名は、投票トランザクション６００のすべてのインプットと、投票トランザクション６００の０番目のインデックスのアウトプットに署名するが、投票トランザクション６００の他のアウトプットには署名しない。つまり、署名メッセージには、４つのインプットと０番目のインデックスのアウトプットのみが含まれる。

同様のインプット－アウトプットペアは、１番目と２番目のインデックスに各々提供され、１番目のインデックスのインプット－アウトプットペアは、２番目の投票者の署名とSINGLE sighashフラグを有するトークン発行トランザクションのインデックス１のトークン、トークンのアウトプット値と等しい未使用トランザクションアウトプット値、及び２番目の投票者によって選択された投票オプション３のアドレスを示し、２番目のインデックスのインプット－アウトプットペアは、３番目の投票者の署名とSINGLE sighashフラグを有するトークン発行トランザクションのインデックス２のトークン、トークンのアウトプット値と等しい未使用トランザクションアウトプット値、及び３番目の投票者によって選択された投票オプション１のアドレスを示す。

インデックス３のインプットは、投票コーディネータのUTXOを示すアウトポイントと、ALL sighashフラグによる投票コーディネータの署名と、を含む。インデックス３のアウトプットは、インプット内に示されたUTXOからトランザクション手数料を引いたもの（各トークンの完全な値は投票オプションの公開鍵にロックされるため）に等しい値を有するUTXOと、投票コーディネータの公開鍵を含むロックスクリプトと、を含む。インデックス０から２の投票のアウトプットのUTXO値がインプット内に示された値よりも小さく、各投票がトランザクション手数料に貢献する場合、インデックス３のインプットで参照されるUTXOとインデックス３のアウトプットのUTXOの差は、個々の投票でカバーされていないトランザクション手数料の額と等しいだけでよい。

投票者によって提供されるインプット－アウトプットペアにあるインデックスは、投票インデックスと呼ばれることがある。図６の例では、これらはインデックス０、１、及び２である。投票コーディネータが署名を提供するインデックスでは、ここではインデックス３は、投票コーディネータがすべてのインプットとアウトプットに署名するため、承認インデックスと呼ばれることがある。すべての投票インデックスが提供された後に、投票コーディネータがインプットとアウトプットに署名するだけであれば、トランザクション６００の任意のインデックスで投票インデックスと承認インデックスを提供することができることが分かる。

投票トランザクション６００はトランザクションIDも含み、インカウント４とアウトカウント４を含む。

図８は、投票トランザクション６００とトークン発行トランザクション５００の関係を示している。投票（インデックス０から２）に対応する投票トランザクション６００の各インプットは、前述のようにトークン発行トランザクション５００のアウトプットを示す。投票トランザクション６００がブロックチェーンノードによって検証されると、同じUTXOに関連付けられたロックスクリプトとアンロックスクリプトが一緒に実行され、アンロックスクリプトがロックスクリプトの要件を満たしていることが確認される。これは、トークンのロックスクリプトにこのような署名条件が含まれている場合に、sighashフラグ値の確認も含む。

トークン発行トランザクション５００のインプットは、UTXOを投票コーディネータの公開鍵にロックする前のブロックチェーントランザクション８００のアウトプットを指すように示されている。前のトランザクションは、前の投票に使用されたデジタルアセットが再利用されるように、前の投票に関連付けられたUTXO（示されない）を使用するためのインプットを含む場合がある。

フルグループ投票では、SINGLE又はSINGLE|ACP sighashフラグのいずれかを使用できる。トークンが使用されている場合、上記及び図６に示すように、インプットは投票トランザクションの生成前に投票コーディネータに知られるため、投票者はSINGLE sighashフラグを使用できる。ユーザは、他の投票者の投票能力に影響を与えることなく、このシナリオではSINGLE|ACP sighashフラグを使用することもできる。

代替として、トークンは発行されず、その結果、上記のステップ１が除外され、投票者は前に投票者に割り当てられている事前に定義された値の未使用トランザクションアウトプットを消費することにより投票する。つまり、投票の「コスト」は投票コーディネータによって投票者に提供されておらず、投票者は投票するために支払う必要がある。この場合の投票のコストは、投票を促進するために名目上のものである場合がある。投票を行う際に投票者によって提供されるアウトポイントは、投票前に投票コーディネータに知られていないため、SINGLE|ACP sighashフラグが投票者によって使用される。

上記のトークンは、小さな値である「ダスト（dust）」UTXO値を有する。このような小さな値は、例えば、トランザクションからの変更として非常にわずかな量が残っている場合に作成されることがある。これらのダストUTXOには、トランザクション手数料をカバーするのに十分な値が含まれていない可能性があり、単独では機能しない。トークンが使用されない場合、投票コーディネータはわずかな金額を失うだけである。

定足数投票
場合によっては、すべてのパーティが回答を返す必要はなく、代わりに、グループ内の閾値（定足数）のメンバーが参加している限り、投票が有効であることに同意する場合がある。この場合、正確なインプットを事前に定義することはできないため（どの投票者が投票を返すかは不明であるため）、投票トークンはSINGLE|ACPフラグを使用して署名する必要がある。

１．コーディネータは、すべての有権者に投票トークンを発行する必要がある。これらには、SINGLE|ACPフラグを使用して署名する必要があるように、追加の支出要件（ロックスクリプトで定義されている）が必要である。

この署名条件は、署名の最後のバイト（署名に使用されるsighashフラグを示す）が特定の値と等しいかどうかをチェックするロックスクリプトの追加条件である。例えば、sighash SINGLE|ACP（バイト値０x８３）が使用されたことを確認するには、ロックスクリプトの先頭に次の一連のOPコードを含めることができる：

このスクリプトの説明は付録Aにある。

２．投票を選択した有資格投票者は、投票期限までに署名された投票トークンをコーディネータに返却する必要がある。必要に応じて、投票者はロックタイムを設定して、投票の期限前に投票が有効にならないようにすることができる。

３．投票期限が過ぎると、コーディネータは提出されたすべての投票を１つのトランザクションに収集する。使用されたすべてのトークンがこの投票に対して有効であること、及び必要な定足数に達していることを確認する必要がある。これは手動又はスマートコントラクトを介して行うことができる。例えば、すべての投票インプットがTx０を参照していること、及びトークンインプットの合計値が必要な値（n_Q×BSV、ここで、n_Qは定足数に必要な投票数）を超えていることを確認するものである。これらの条件が満たされた場合、コーディネータは、トランザクション手数料をカバーする最終的なインプット及びアウトプットを追加し、sighash ALLを使用して署名し、最終的な投票トランザクションをブロードキャストする。

コーディネータがミスをして、適格な投票を含まなかった場合は、コーディネータは単に失われた投票を含む第２トランザクションを作成できる。同様に、何らかの理由でSINGLE|ACPの投票が別のトランザクションに含まれ、メインの投票トランザクションの前にマイニングされた場合、コーディネータは、最終アウトプットのOP_RETURNに投票が含まれていたTxIDへの参照を追加できる。

図７は、図５で発行されたトークンを使用した定足数投票の投票トランザクション７００の例を示している。投票トランザクション７００は、完全な投票の投票トランザクション６００と類似しているが、投票したのは２人の投票者だけである。第２投票者は投票していないため、第１投票者と第３投票者のインプット－アウトプットペアのみが、インデックス０と１で投票トランザクション７００に含まれるが、投票は任意の順序と任意のインデックスで提供できる。図６の投票トランザクション６００の３番目のインデックスのように、投票コーディネータに関連付けられたインプットとアウトプットを含むインデックス２。従って、投票トランザクション７００のインカウントとアウトカウントは両方とも３である。

完全なグループ投票と同様に、幾つかの実施例ではトークンが発行されない場合がある。代わりに、投票者は、投票のコストをカバーするために事前に定義された値を持つ未使用トランザクションアウトプットを示すアウトポイントを提供する。場合によっては、このコストは投票を促進するために最小限に抑えられることがある。他の例では、投票にほとんど関心のない投票者が参加すること、又は投票結果を歪めるために複数回投票したりすることを抑止するために、コストは決して小さくないかもしれない。

定足数投票の具体的な例は、世論調査である。この例では、投票するパーティを事前に定義することはできないため、インプットにはSINGLE|ACPフラグを使用して署名する必要がある。世論調査の設定は次のように動作する可能性がある。

１．世論調査の発信者であるAliceは、２つ以上の世論調査の選択肢の詳細を公に投稿する。各投票の選択肢は、Aliceがアンロックできるアドレスに関連付けられる必要がある。

２．世論調査に投票を登録したい人は、次のプロパティを持つSINGLE|ACP署名されたインプット－アウトプットペアを作成できる：
－アウトプットは、Aliceによって定義された世論調査選択アドレスのいずれかである必要がある。
－インプットにはスパム投票を阻止するための最小値を設定する必要がある。
－アウトプットの値はインプットと一致する必要がある。
－ロックタイムは、世論調査の期限と一致するように設定する必要がある。

３．各「投票」ペアはAliceに直接送信され、Aliceはそれらを１つのトランザクションに結合する。彼女は、必要に応じてトランザクション手数料に資金を提供するための最終的なインプットを追加し、sighash ALLを署名する。

４．トランザクションがブロックチェーンノードによって妥当性確認され、ブロックチェーンに公開されると、世論調査の結果の記録が提供される。Aliceは、どの世論調査オプションが選択されたかに関係なく、各回答者がインプットを通じて貢献した値から利益を得る。

SINGLE|ACPフラグの柔軟性は、SINGLEフラグとは対照的に、Aliceが最終トランザクションをブロードキャストするときに、誰かがネットワークに到達する前にそれを傍受し、まだ有効である適格な投票のサブセットに基づいて代替トランザクションを作成することが可能であることを意味する。ただし、アウトプットアドレスは固定されており、値はインプット値と一致するため、潜在的な影響は世論調査の結果を変更することだけであるため、傍受者は世論調査の応答者によって提供された値をリダイレクトすることはできない。この状況でも、Aliceが除外された世論調査応答を含む第２トランザクションを作成して、それらのインプットによって提供された値を収集できるようにすることは可能である。それにもかかわらず、この柔軟性から保護する代わりに、各世論調査の値のある割合を取得するサービスプロバイダを導入する価値がある場合がある。例えば、ブロックプロデューサ（又はサービス独自のブロック制作機能）との契約を介して、世論調査トランザクションをより広いブロードキャストを必要とせずに直接コアネットワークに送信できるようにする。

図９は、ブロックチェーンを用いて投票を提供する例示的な方法を示す。左側のアクションはブロックチェーンの外部で実行されるアクションであり、右側のアクションはブロックチェーンノードによってブロックチェーン上で実行されるアクションである。

ステップS９０２で、投票コーディネータは投票オプションを定義し、投票に少なくとも１つの公開鍵を割り当てる１つの公開鍵が割り当てられている場合、投票者によって選択された投票オプションはトランザクションのOP_RETURNで返され、投票のすべてのUTXOが投票の１つの公開鍵にロックされる。複数の公開鍵の場合、投票のUTXOが選択された投票オプションの公開鍵にロックされるように、１つの公開鍵が各投票オプションに関連付けられる。投票オプションと公開鍵の関連付けが格納される。投票コーディネータは、投票を受信する必要がある時間を設定する。投票コーディネータは、図３A及び３Bに示すようなユーザインタフェースをレンダリングするコンピュータプログラムを実行しているユーザ装置を介して投票オプションを定義する。

ステップS９０４で、投票コーディネータは、投票者と署名要件も定義する。投票コーディネータは、誰が投票資格があるか、必要な投票者の数、つまり、完全なグループ投票か定足数投票かを定義する。署名要件は、投票が完全なグループ投票かどうかに少なくとも部分的に依存する。投票コーディネータは、このステップで、投票の重みや拒否権などの他の特別な投票特権も定義する。

ステップS９０６で、投票コーディネータは、ステップS９０４で定義された投票者要件に基づいてトークン発行トランザクション５００を生成する。ステップS９０８で、トークン発行トランザクション５００はブロックチェーンノードによって受信され、ブロックチェーンノードは、ステップS９１０でトランザクションを検証し、ステップS９１２でトランザクションをブロックチェーンに発行する。

検証され、発行されると、トークンは投票者の公開鍵にロックされる。投票者は、ステップS９１４でトークンを受信すると言われる。

ステップS９１６で、投票コーディネータは投票オプションと定義された公開鍵を投票者に配布する。投票コスト、投票期限、トークン発行トランザクション５００のトランザクションIDなどのその他の情報が、配布された投票情報に含まれる場合がある。

投票に参加することを希望する各投票者は、自分が選択した投票オプションを示し、必要なsighashフラグと共に投票トークンを使用するための署名を提供する、インプット－アウトプットペアを定義する。これらは、ステップS９１８でインプット－アウトプットペアを受信する投票コーディネータの装置に送信される。

投票を行うための期限が過ぎたか、すべての投票が受信されると、投票コーディネータは、必要な数の参加者がインプット－アウトプットペアを送信したこと、及びインプットが投票のために発行されたトークンを識別するアウトポイントを含むことを確認する。これらの投票条件が満たされた場合、投票コーディネータは、ステップS９２０で、受信したすべてのインプット－アウトプットペアを含む投票トランザクション６００、７００を生成する。無効なインプット－アウトプットペアが受信された場合、例えば、投票資格のないパーティから受信された場合や、トークンを使用して投票しなかった場合は、無効なインプット－アウトプットペアを無視して破棄できる。

ステップS９２２で、投票トランザクション６００、７００はブロックチェーンノードによって受信され、ブロックチェーンノードは、ステップS９２４でトランザクションを検証し、ステップS９２６でトランザクションをブロックチェーンに発行する。

発行されると、投票コーディネータは、ステップS９２８で投票データにアクセスできる。各投票オプションが異なる公開鍵に関連付けられている場合、投票データ又は結果は、公開鍵に関連付けられている異なるアドレスにアクセスすることによって決定できる。各アドレスでのUTXOの量、又は投票トランザクション６００、７００の結果としてそのアドレスで受け取った量は、投票の重みを含めて、各投票オプションで受け取った投票の数に比例する。これにより、効率的かつ正確な***方法が提供される。

代替として、ブロックチェーンに保存された投票トランザクション６００、７００自体にアクセスして、投票データにアクセスすることもできる。これにより、OP_RETURN内のデータを閲覧する方法が提供される。OP_RETURNを使用して行われた投票は、投票コーディネータ又はそのコンピュータ装置によってカウントされる。

その後、投票コーディネータは、ステップS９３０で投票結果を投票者に配布できる。

上記のようにブロックチェーンに投票を公開することで、投票結果と投票参加者の追跡が容易になる。また、投票は不変であるため、手動でカウントされた投票よりも結果の信頼性が高くなる。

「投票コーディネータ」という用語は、上記では、ユーザ装置を制御するユーザと、コンピュータ装置上で方法のステップを実装するように構成されたユーザ装置上で実行されるコンピュータプログラムの両方を指すために使用されている。

図９の方法のステップの幾つかは、異なる順序で、又は同時に実装される場合があることが理解される。例えば、投票者を定義するステップS９０４が第１ステップである場合もあれば、ステップS９０２と同時に実行される場合もある。投票オプションを定義するステップS９０２は、トークンが投票者によって受信された後、ステップS９１４まで実行されない場合もある。方法ステップの他の代替の順序は、当業者には明らかであろう。

図１０は、投票者による例示的な投票方法を示す。この方法は、投票するパーティのユーザ装置上で、装置のプロセッサでコンピュータプログラムを実行することによって実装される。投票者はクライアントアプリケーション３００を使用してインプットを提供する。

ステップS１００２で、投票コーディネータから投票指示を受信する。投票指示は、投票コーディネータによって定義された投票オプションと、投票オプションに関連付けられた公開鍵を含む。投票オプションは、ステップS１００４で、ユーザ選択項目３０１としてユーザ装置のディスプレイ上でレンダリングされる。

ユーザは、選択した投票オプションを選択するか、又は入力する。ステップS１００６で、この選択はUI３００において検出される。

ステップS１００８で、選択された投票オプションに関連付けられた公開鍵は、受信した投票指示を使用して決定される。

ステップS１０１０で、投票者の投票のインプット－アウトプットペアが生成される。インプットはアウトポイントとsingle sighashフラグを持つパーティの署名を含み、アウトプットはユーザが選択した投票オプションに関連付けられた公開鍵と必要なデジタルアセット量を含む。

その後、ユーザ装置はステップS１０１２として、インプット－アウトプットペアを投票トランザクションに含めるために投票コーディネータに送信する。

投票コーディネータが投票トークンも生成する場合、投票指示にはトークンに関する情報、例えばトークンを識別するアウトポイントと投票の値（投票者がトークンを分割して複数の投票を行うことができる場合）が含まれる。ステップS１０１０でユーザ装置によって生成されたインプットは、トークンを識別するアウトポイントを含み、アウトプットは、パーティが選択された投票オプションに割り当てたい投票数に比例する値を含む。

ただし、トークンが発行されない場合、投票指示には投票のコストが含まれ、インプットはコストと等しい値を持つUTXOを識別するアウトポイントを含む。

１つの公開鍵のみが投票に関連付けられている場合、公開鍵を決定するステップS１００８は、方法から削除され、アウトプットは投票に関連付けられた１つの公開鍵を含む。

前述のように、投票者は、UI３００のデータエントリフィールド３０２を介して、投票者が提供するテキストの形式で、ユーザ定義のコメント又は投票オプションをインプットできる場合がある。投票者が提供したテキストは、投票トランザクションのOP_RETURNに含めるために、アウトプットに含まれる。

変形
匿名性：ここで説明する設定では、投票者は各投票トークンに関連付けられたIDを知っているため、最終的なトランザクションがブロードキャストされると、パーティの投票選択を識別できる。ただし、コーディネータが各投票者にどのトークンが発行されたかを公に識別する必要はなく、トークンが投票者に未だ公にリンクされていないアドレスに発行される場合は、秘密投票を行うことができる。

再利用可能／移転可能な投票：アウトプットのアドレスを介して投票を示す代わりに、アウトプットのOP_RETURNデータで投票の選択肢を表すこともできる。これにより、トークンを（アウトプットアドレスを独自のものとして設定することで）同じユーザに割り当てることができ、その後の投票でトークンを再利用できるようになる。これにより、コーディネータが投票ごとにトークンを発行する必要がなくなるため、パーティの同じセットが定期的に投票することが予想される状況でのプロセスが合理化される。これにより、各メンバーの投票履歴も提供される（これは、必要に応じて、上記のように投票者のIDから抽象化することができる）。このシステムでは、投票を移転可能にすることができる。投票者が投票の代理人を指名する場合は、自分の代わりに代理人のアドレスにトークンを転送できる。

重み付け：投票は、投票者間で均等に配分される必要はない。トークンは、例えば年功序列や投資に基づいた階層を実装するために、重み付けされた方法で発行することができる。重み付けは、各ユーザに発行されたトークンの数を介して、又は各投票者に変数値の単一のトークンを発行することによって実装できる。トークンが変動する量で発行される場合、投票者はトークンを分割して複数のオプションに投票することができ、１つの投票は事前に定義された値を持つ場合がある。従って、より大きな権限を持つ投票者は、複数のオプションに投票するか、大きな重みを持つ１つのオプションに投票するか、又はその２つの組み合わせに投票するかを決定できる。

詳細な（Granular）投票：投票者ごとに複数のトークンが発行された場合（これがメンバー間で重みづけされているか等しいかに拘わらず）、これにより投票者は投票を分割して好みを示す機会を与えられる。例えば、１０個のトークンのうち、投票者はオプションAに８個、オプションBに０個、オプションCに２個を割り当てることを選択できる。

特別なトークン：特別な条件が付加されたトークンを発行できる。例えば、グループの上級メンバーに拒否権トークンを発行できる。これは、通常のトークンの代わりに（又は追加で）送信でき、例えば、投票全体又は選択した投票オプションを無効にする効果がある場合がある。特別なトークンは、UTXOに基づいて投票コーディネータ又はスマートコントラクトによって識別でき、トークンの作成時に使用条件をOP_RETURNに記述できる。

追加情報の埋め込み：各アウトプットのOP_RETURNにデータを含めることで、事前に定義された選択肢のセットの間で直接的に選択するよりも、応答のニュアンスを高めることができる。このスペースは、投票選択に対するオプションのコメントを許可するために使用することも、より形式的に各投票者からのフィードバックを要求するために使用することもできる。例えば、学術研究では、多くの学術誌が論文の出版を承認する前に、複数の独立した専門家による査読を要求している。これは、ここで説明されているように投票によって実装することができ、アウトプットアドレスは全体的な推奨事項（却下、修正、再提出、受理など）を反映し、OP_RETURNは完全なコメントのためのスペースを提供する。原稿の決定を表すトランザクションは、すべてのレビュー担当者が投票とコメントを返すまで有効ではなく、これは決定プロセスの不変の記録を提供する。また、例えばフィードバックが要求される場合は、投票コーディネータが投票オプションを提供せず、投票者がOP_RETURNで投票オプションを提供するように投票を定義することもできる。この場合、投票に対して定義する必要があるのは１つのアドレスのみであり、すべての投票の値は１つのアドレスに送られる。

多目的投票トークントランザクション：トークン発行トランザクションは、トランザクションのOP_RETURNで提供される各トークンに関連付けられたロックスクリプトに追加情報を含めることができる。この追加情報は投票指示にすることができる。トークン発行トランザクションが発行され、ユーザがトークンが発行されたことを通知すると、投票者の装置上のプログラムはOP_RETURNで提供された投票指示にアクセスし、適切な情報をユーザにレンダリングする。これにより、トークンが発行されたときに投票指示を不変に保存することができる。

トークン／投票者チェックソフトウェア：投票者又は投票コーディネータの装置上のクライアントアプリケーション１０５などのソフトウェアは、投票者が投票資格があるかどうか、及び／又は正しいsighashフラグが使用されたかどうかをチェックする役割を担う場合がある。投票者の適格性をチェックするために、ソフトウェアは、インプット－アウトプットペアの署名が適格な投票者と関連付けられていることをチェックできる。例えば、適格な投票者のリストと比較したり、トークンが発行されている場合に有効なトークンが使用されていることをチェックしたりできる。ソフトウェアは、プログラムなどに格納されている事前に定義されたsighashルールに対して使用されているsighashフラグをチェックしたり、トークン発行トランザクションで定義されているsighashフラグ条件に対して使用されているsighashフラグをチェックしたりできる。このシナリオでは、使用されているsighashフラグを要件に対してチェックするときにソフトウェアによってアクセスされる、トークン発行トランザクションのOP_RETURNでsighashフラグ条件を定義できる。その後、インプット－アウトプットペアは投票コーディネータにのみ送信されるか、又は基準が満たされた場合に投票トランザクションに含まれるため、インプット－アウトプットペアがないと投票トランザクションが無効になる。

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

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

例えば、上述の幾つかの実施形態は、ビットコインネットワーク１０６、ビットコインブロックチェーン１５０、及びビットコインノード１０４の観点で説明された。しかしながら、ビットコインブロックチェーンは、ブロックチェーン１５０の１つの特定の例であり、上述の説明は任意のブロックチェーンに一般的に適用されてよいことが理解される。つまり、本発明は、ビットコインブロックチェーンに何ら限定されない。より一般的には、上述のビットコインネットワーク１０６、ビットコインブロックチェーン１５０、及びビットコインノード１０４への言及は、ブロックチェーンネットワーク１０６、ブロックチェーン１５０、及びブロックチェーンノード１０４により各々置き換えられてよい。ブロックチェーン、ブロックチェーンネットワーク、及び／又はブロックチェーンノードは、ビットコインブロックチェーン１５０、ビットコインネットワーク１０６、及びビットコインノード１０４の上述の特性の一部又は全部を共有してよい。

本発明の好適な実施形態では、ブロックチェーンネットワーク１０６は、ビットコインネットワークであり、ビットコインノード１０４はブロックチェーン１５０のブロック１５１を生成し、公開し、伝播し、及び格納する上述の機能の少なくとも全部を実行する。これらの機能の全部ではなく１つ又は一部のみを実行する他のネットワークエンティティ（又はネットワーク要素）が存在することが除外されない。つまり、ネットワークエンティティは、ブロックを伝播し及び／又は格納する機能を実行してよいが、ブロックを生成し公開しなくてよい（これらのエンティティが好適なビットコインネットワーク１０６のノードと見なされないことを思い出してほしい）。

本発明の他の実施形態では、ブロックチェーンネットワーク１０６はビットコインネットワークでなくてもよい。これらの実施形態では、ノードが、ブロックチェーン１５０のブロック１５１を生成し、公開し、伝播し、及び格納する機能の全部ではなく少なくとも１つ又は一部を実行してよいことが除外されない。例えば、これらの他のブロックチェーンネットワークでは、「ノード」は、ブロック１５１を生成し公開するよう構成されるが該ブロック１５１を格納し及び／又は他のノードに伝播しないネットワークエンティティを表すために使用されてよい。

更に一般的には、上述の用語「ビットコインノード」１０４の言及は、用語「ネットワークエンティティ」又は「ネットワーク要素」と置き換えられてよい。このようなエンティティ／要素は、ブロックを生成し、公開し、伝播し、及び格納する役割のうちの一部又は全部を実行するよう構成される。そのようなネットワークエンティティ／要素の機能は、ハードウェアで、ブロックチェーンノード１０４を参照して上述したのと同じ方法で実装されてよい。

上記の実施形態は、単なる例示として説明したものであることが理解されるであろう。より一般的には、以下の記述のうちの任意の１つ以上に従った方法、装置又はプログラムが提供され得る。

（ステートメント１）投票を行うためのブロックチェーンの投票トランザクションのインプットとアウトプットを生成するためのコンピュータプログラムであり、前記コンピュータプログラムは、非一時的媒体に格納され、１つ以上のコンピュータプロセッサによって実行されると、前記１つ以上のプロセッサを、
投票コーディネータから、前記投票コーディネータによって定義された１つ以上の公開鍵と投票オプションのセットとを含む投票指示を受信し、
ディスプレイを制御して、前記投票オプションのセットを表示するユーザインタフェースをレンダリングし、
前記ユーザインタフェースでユーザ入力によって定義された前記投票オプションのセットのうちの１つの投票オプションのユーザ選択を受信し、
投票トランザクションの異なるインデックスにある１つ以上の他のインプット－アウトプットペアを有する前記投票トランザクションに含めるインプット－アウトプットペアを生成する、
よう構成させ、
前記インプット－アウトプットペアのインプットの非署名部分は、ブロックチェーントランザクションの未使用トランザクションアウトプットを識別するアウトポイントを含み、前記インプットの署名部分は、signature singleフラグと、少なくとも前記インプット－アウトプットペアの前記非署名部分と前記インプット－アウトプットペアのアウトプットに署名するが前記投票トランザクションの他のアウトプットに署名しない関連署名と、を含み、前記インプット－アウトプットペアの前記アウトプットは、前記投票指示の１つ以上の公開鍵の１つを含む、コンピュータプログラム。

（ステートメント２）前記１つ以上のプロセッサが、前記投票トランザクションを生成するために、前記インプット－アウトプットペアを前記投票コーディネータに送信するようにさらに構成される、ステートメント１に記載のコンピュータシステム。

（ステートメント３）前記投票オプションのセットの各投票オプションが異なる公開鍵に関連付けられ、前記１つ以上のプロセッサが、選択された投票オプションに関連付けられた公開鍵を決定するようにさらに構成され、前記アウトプットは決定された公開鍵を含む、ステートメント１又は２に記載のコンピュータプログラム。

（ステートメント４）前記投票指示は、未使用トランザクションアウトプットを識別する投票トークンをさらに含み、前記インプット－アウトプットペアのインプットのアウトポイントが前記投票トークンを識別する、ステートメント１～３のいずれかに記載のコンピュータシステム。

（ステートメント５）前記インプット－アウトプットペアは、事前に定義された投票者のセットの１人の投票者に関連付けられ、前記事前に定義された投票者のセットのサブセットは、各々のインプット－アウトプットペアを生成することが要求され、前記single署名フラグは、前記署名がインプット－アウトプットペアのインプットとアウトプットのみに署名し、前記投票トランザクションの他のインプット又はアウトプットに署名しないような、single－anyone can pay署名フラグである、ステートメント１～４のいずれかに記載のコンピュータプログラム。

（ステートメント６）前記１つ以上のプロセッサが、OP_RETURNに含めるための情報を含むユーザ定義のインプットを受信するように更に構成されており、インプット－アウトプットペアのアウトプットが更に前記情報を含む、ステートメント１～５のいずれかに記載のコンピュータプログラム。

（ステートメント７）ブロックチェーンの投票トランザクションを生成するためのコンピュータプログラムであって、前記コンピュータプログラムは、非一時的媒体に格納され、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサを、
ステートメント１～６のいずれかに記載の複数のインプット－アウトプットペアを受信し、
投票トランザクションを生成し、
前記投票トランザクションは、
投票インデックスのセットの各投票インデックスの中に、受信したインプット－アウトプットペアの１つと、
認可インデックスの中に、投票コーディネータの署名が投票トランザクションのすべてのインプットとアウトプットに署名するように、all署名フラグを持つ投票コーディネータの署名で構成されるインプットと、
アウトプットと、
を含み、
前記投票トランザクションをブロックチェーンに送信する、
よう構成させる、コンピュータプログラム。

（ステートメント８）前記１つ以上のプロセッサが、事前に定義された数のインプット－アウトプットペアを受信したかどうかを決定するようにさらに構成されている、ステートメント７に記載のコンピュータプログラム。

（ステートメント９）前記１つ以上のプロセッサが、
投票指示を生成し、
投票者のセットのうちの各投票者のユーザ装置からアクセス可能に前記投票指示をレンダリングする、
よう構成され、前記投票指示を生成する処理は、
投票を開始するユーザ入力を検出することと、
少なくとも１つの公開鍵を前記投票に関連付けることと、
を含む、ステートメント７又は８に記載のコンピュータプログラム。

（ステートメント１０）前記１つ以上のプロセッサがトークンのセットを生成するように構成されており、前記トークンのセットのうちの各トークンは、前記投票者のセットのうちの投票者の１人に関連付けられた未使用トランザクションアウトプットである、ステートメント９に記載のコンピュータプログラム。

（ステートメント１１）前記投票指示は、前記投票指示がアクセス可能にレンダリングされるコンピュータ装置の受信側投票者に関連付けられたトークンを含む、ステートメント１０に記載のコンピュータプログラム。

（ステートメント１２）前記１つ以上のプロセッサが、更に、前記少なくとも１つの公開鍵の各々のアドレスにアクセスするように構成されている、ステートメント７～１１に記載のコンピュータプログラム。

（ステートメント１３）前記１つ以上のプロセッサが、更に、投票トランザクションが前記ブロックチェーンノードによって妥当性確認された後に、前記投票トランザクションにアクセスするように構成されている、ステートメント７～１２に記載のコンピュータプログラム。

（ステートメント１４）前記１つ以上のプロセッサが、受信したインプット－アウトプットペアのアウトポイントによって示される未使用トランザクションアウトプットが、トランザクション手数料をカバーするのに十分であるかどうかを決定するように、更に構成され、
前記未使用トランザクションアウトプットが、前記トランザクション手数料をカバーするのに十分でない場合、認可インデックスのインプットは、前記インプット－アウトプットペアによってカバーされない前記トランザクション手数料の金額をカバーするのに十分な未使用トランザクションアウトプットを示すアウトポイントを含む、ステートメント７から１３のいずれかに記載のコンピュータプログラム。

（ステートメント１５）前記インプット－アウトプットペアのインプットのアウトポイントによって識別される未使用トランザクションアウトプットは、投票数に比例する値を持ち、１つの投票は事前に定義された値を持つ、ステートメント１～１４のいずれかに記載のコンピュータプログラム。

（ステートメント１６）前記トークンは、前記トークンを含むインプットの非署名部分に署名するときに使用しなければならない署名フラグを定義するロックスクリプトに関連付けられている。ステートメント４又は１１、ステートメント４に従属するステートメント５～６のいずれか、又はステートメント１１に従属するステートメント１２～１５のいずれかに従ったコンピュータプログラム。

（ステートメント１７）コンピュータ可読媒体上に具現化されたブロックチェーントランザクションであって、
ブロックチェーントランザクションのインプット内で示される使用可能トランザクションアウトプットを有効に消費するためのインプット、
署名要件と必要な署名フラグを定義するロックスクリプトを含み、後続のブロックチェーントランザクションでアンロックスクリプトと連結されたときに、前記アンロックスクリプトの署名を妥当性確認し、前記アンロックスクリプトから使用された署名フラグを抽出し、前記使用された署名フラグと前記必要な署名フラグを比較し、前記使用された署名フラグが前記必要な署名フラグと一致しない及び／又は前記署名が無効である場合に、前記後続のブロックチェーントランザクションが無効になるようにする、少なくとも１つのアウトプットと、
を含むブロックチェーントランザクション。

（ステートメント１８）前記署名フラグが前記署名の最後のバイトによって示され、前記使用された署名フラグを前記必要な署名フラグと比較するステップは、前記署名の前記最後のバイトを前記ロックスクリプトで定義された前記必要な署名フラグを示す値と比較することを含み、前記署名の前記最後のバイトが前記必要な署名フラグを示す値と等しい場合、前記使用された署名フラグと前記必要な署名フラグが一致する、ステートメント１７に記載のブロックチェーントランザクション。

（ステートメント１９）前記トークンは投票トランザクションでの使用のためのものであり、前記使用可能アウトプットが投票数に比例する値を持つ、ステートメント１７又は１８に記載のブロックチェーントランザクション。

（ステートメント２０）前記ブロックチェーントランザクションは、承認されたパーティのセットのうちの各パーティに関連付けられたアウトプットを含み、前記承認されたパーティは、後続のブロックチェーントランザクションのインプットとアウトプットを提供する権限を与えられている、ステートメント１７～１９のいずれかに記載のブロックチェーントランザクション。

（ステートメント２１）前記承認されたパーティのセットのうちのサブセットは、前記後続のブロックチェーントランザクションのインプットとアウトプットを提供する必要があり、前記必要な署名フラグは、前記後続のブロックチェーントランザクション内の同じインデックスで提供されるインプットとアウトプットのみを承認するためのsingle－anyone can pay署名フラグである、ステートメント２０に記載のブロックチェーントランザクション。

（ステートメント２２）前記承認されたパーティのセットのうちのすべてのパーティは、前記後続のブロックチェーントランザクションのインプットとアウトプットを提供する必要があり、前記必要な署名フラグは、前記後続のトランザクションのすべてのインプットと、提供されたアンロックスクリプトと同じインデックスでのアウトプットのみを承認するためのsingle－all署名フラグである、ステートメント２０に記載のブロックチェーントランザクション。

（ステートメント２３）前記ブロックチェーントランザクションがトークン発行トランザクションであり、前記トークン発行トランザクションのアウトプットは、前記ブロックチェーントランザクションをブロックチェーンに記録するためだけに十分なデジタルアセットの名目量を定義する、ステートメント１７～２２のいずれかに記載のブロックチェーントランザクション。

（ステートメント２４）投票を行うためのブロックチェーンの投票トランザクションのインプットとアウトプットを生成する方法であり、前記方法は、
投票コーディネータから、前記投票コーディネータによって定義された１つ以上の公開鍵と投票オプションのセットとを含む投票指示を受信するステップと、
前記投票オプションのセットを表示するユーザインタフェースをレンダリングするステップと、
前記ユーザインタフェースでユーザ入力によって定義された前記投票オプションのセットのうちの１つの投票オプションのユーザ選択を受信するステップと、
投票トランザクションの異なるインデックスにある１つ以上の他のインプット－アウトプットペアを有する前記投票トランザクションに含めるインプット－アウトプットペアを生成するステップと、
を含み、
前記インプット－アウトプットペアのインプットの非署名部分は、ブロックチェーントランザクションの未使用トランザクションアウトプットを識別するアウトポイントを含み、前記インプットの署名部分は、signature singleフラグと、少なくとも前記インプット－アウトプットペアの前記非署名部分と前記インプット－アウトプットペアのアウトプットに署名するが前記投票トランザクションの他のアウトプットに署名しない関連署名と、を含み、前記インプット－アウトプットペアの前記アウトプットは、前記投票指示の１つ以上の公開鍵の１つを含む、方法。

（ステートメント２５）ブロックチェーンの投票トランザクションを生成する方法であって、前記方法は、
上述のステートメントのいずれかに従い複数のインプット－アウトプットペアを受信するステップと、
投票トランザクションを生成するステップであって、前記投票トランザクションは、
投票インデックスのセットの各投票インデックスの中に、受信したインプット－アウトプットペアの１つ、及び、
認可インデックスの中に、投票コーディネータの署名が投票トランザクションのすべてのインプットとアウトプットに署名するように、all署名フラグを持つ投票コーディネータの署名を含むインプットと、アウトプットと、
を含む、ステップと、
前記投票トランザクションをブロックチェーンに送信するステップと、
を含む方法。

（ステートメント２６）コンピュータシステムであって、
ステートメント１～６、又はステートメント４に従属するステートメント１６のいずれかに記載のコンピュータプログラムを実行するように構成された少なくとも１つのコンピューティング装置と、
ステートメント７～１５、又はステートメント７に従属するステートメント１６記載のコンピュータプログラムを実行するように構成された少なくとも１つのコンピューティング装置と、
を含むコンピュータシステム。

（ステートメント２７）ブロックチェーントランザクションを生成するコンピュータプログラムであって、前記コンピュータプログラムは非一時的媒体に格納され、１つ以上のプロセッサにより実行されると、前記１つ以上のプロセッサを、前記ブロックチェーントランザクションを生成するよう構成させ、前記ブロックチェーントランザクションは、
前記ブロックチェーントランザクションのインプット内で示される使用可能トランザクションアウトプットを有効に消費するためのインプットと、
署名要件と必要な署名フラグを定義するロックスクリプトを含む少なくとも１つのアウトプットであって、後続のブロックチェーントランザクション内のアンロックスクリプトと連結されたときに、前記アンロックスクリプトの署名を妥当性確認し、前記アンロックスクリプトから使用された署名フラグを抽出し、前記使用された署名フラグと前記必要な署名フラグを比較し、前記使用された署名フラグが前記必要な署名フラグと一致しない及び／又は前記署名が無効である場合に、前記後続のブロックチェーントランザクションが無効になるようにする、少なくとも１つのアウトプットと、
を含む、コンピュータプログラム。

付録A：
このセクションでは、UTXOが使用されたときに特定のsighashフラグを使用して署名されているかの追加チェックを作成するために、標準のP２PKHロックスクリプトの前に追加できるSCRIPTコードについて説明する。

ECDSAを使用して作成され、ビットコイントランザクション用に符号化されたデジタル署名は、署名シーケンスの長さを示すバイトで始まり、sighashフラグを示すバイトで終わる。例えば、SINGLE|ACPフラグで署名された合計４７バイトの署名は、０x４７<sig>８３の形式になる。署名時に特定のsighashフラグが使用されたかどうかを確認するには、署名の最終バイトが特定の値と等しいことを確認する。

この例では、sighashチェックコードに続くロックスクリプトがP２PKHスクリプトであると仮定する。従って、アンロックスクリプトは<sig><P>の形式をとり、ロックスクリプトが実行される前に両方の項目がスタックにプッシュされる。

次の行は、スタック上の項目を下（左）から上（右）の順に表し、各項目は［］で囲まれている。インデントされた青色のテキストは、次のOPコードを示す。各OPコードが最初に使用されたときに、その機能の簡単な説明が続く。

アンロックスクリプトは、署名と関連する公開鍵をスタックにプッシュした：

最終状態は、標準のP２PKHスクリプトが妥当性確認するために必要であるため、署名と公開鍵をスタックに残す。

Claims (27)

1. 投票を行うためのブロックチェーンの投票トランザクションのインプットとアウトプットを生成するためのコンピュータプログラムであり、前記コンピュータプログラムは、非一時的媒体に格納され、１つ以上のコンピュータプロセッサによって実行されると、前記１つ以上のプロセッサを、
   投票コーディネータから、前記投票コーディネータによって定義された１つ以上の公開鍵と投票オプションのセットとを含む投票指示を受信し、
   ディスプレイを制御して、前記投票オプションのセットを表示するユーザインタフェースをレンダリングし、
   前記ユーザインタフェースでユーザ入力によって定義された前記投票オプションのセットのうちの１つの投票オプションのユーザ選択を受信し、
   前記投票トランザクションの異なるインデックスにある１つ以上の他のインプット－アウトプットペアを有する投票トランザクションに含めるインプット－アウトプットペアを生成する、
   よう構成させ、
   前記インプット－アウトプットペアのインプットの非署名部分は、ブロックチェーントランザクションの未使用トランザクションアウトプットを識別するアウトポイントを含み、前記インプットの署名部分は、signature singleフラグと、少なくとも前記インプット－アウトプットペアの前記非署名部分と前記インプット－アウトプットペアのアウトプットに署名するが前記投票トランザクションの他のアウトプットに署名しない関連署名と、を含み、前記インプット－アウトプットペアの前記アウトプットは、前記投票指示の１つ以上の公開鍵の１つを含む、コンピュータプログラム。
2. 前記１つ以上のプロセッサが、前記投票トランザクションを生成するために、前記インプット－アウトプットペアを前記投票コーディネータに送信するようにさらに構成される、請求項１に記載のコンピュータプログラム。
3. 前記投票オプションのセットの各投票オプションが異なる公開鍵に関連付けられ、前記１つ以上のプロセッサが、選択された投票オプションに関連付けられた公開鍵を決定するようにさらに構成され、前記アウトプットは決定された公開鍵を含む、請求項１又は２に記載のコンピュータプログラム。
4. 前記投票指示は、未使用トランザクションアウトプットを識別する投票トークンをさらに含み、前記インプット－アウトプットペアのインプットのアウトポイントが前記投票トークンを識別する、請求項１～３のいずれかに記載のコンピュータプログラム。
5. 前記インプット－アウトプットペアは、事前に定義された投票者のセットのうちの１人の投票者に関連付けられ、前記事前に定義された投票者のセットのサブセットは、各々のインプット－アウトプットペアを生成することが要求され、前記single署名フラグは、前記署名がインプット－アウトプットペアのインプットとアウトプットのみに署名し、前記投票トランザクションの他のインプット又はアウトプットに署名しないような、single－anyone can pay署名フラグである、請求項１～４のいずれかに記載のコンピュータプログラム。
6. 前記１つ以上のプロセッサが、ユーザ定義の入力を受信するようにさらに構成され、前記インプット－アウトプットペアのアウトプットが、前記ユーザ定義の入力の情報と、前記アウトプットを無効にするオペコードをさらに含む、請求項１～５のいずれかに記載のコンピュータプログラム。
7. ブロックチェーンの投票トランザクションを生成するためのコンピュータプログラムであって、前記コンピュータプログラムは、非一時的媒体に格納され、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサを、
   請求項１～６のいずれかに従って複数のインプット－アウトプットペアを受信し、
   投票トランザクションを生成し、
   前記投票トランザクションは、
   投票インデックスのセットの各投票インデックスの中に、受信したインプット－アウトプットペアの１つと、
   認可インデックスの中に、投票コーディネータの署名が投票トランザクションのすべてのインプットとアウトプットに署名するように、all署名フラグを持つ投票コーディネータの署名を含むインプット、及びアウトプットと、
   を含み、
   前記投票トランザクションをブロックチェーンに送信する、
   よう構成させる、コンピュータプログラム。
8. 前記１つ以上のプロセッサが、事前に定義された数のインプット－アウトプットペアを受信したかどうかを決定するようにさらに構成されている、請求項７に記載のコンピュータプログラム。
9. 前記１つ以上のプロセッサが、
   投票指示を生成し、
   投票者のセットのうちの各投票者のユーザ装置から前記投票指示をレンダリングする、
   よう構成され、
   前記投票指示を生成する処理は、
   投票を開始するユーザ入力を検出することと、
   少なくとも１つの公開鍵を前記投票に関連付けることと、
   を含む、請求項７又は８に記載のコンピュータプログラム。
10. 前記１つ以上のプロセッサがトークンのセットを生成するように構成されており、前記トークンのセットのうちの各トークンは、前記投票者のセットのうちの投票者の１人に関連付けられた未使用トランザクションアウトプットである、請求項９に記載のコンピュータプログラム。
11. 前記投票指示は、前記投票指示がアクセス可能にレンダリングされるコンピュータ装置の受信側投票者に関連付けられたトークンを含む、請求項１０に記載のコンピュータプログラム。
12. 前記１つ以上のプロセッサが、更に、前記少なくとも１つの公開鍵の各々のアドレスにアクセスするように構成されている、請求項７～１１のいずれかに記載のコンピュータプログラム。
13. 前記１つ以上のプロセッサが、更に、投票トランザクションがブロックチェーンノードによって妥当性確認された後に、前記投票トランザクションにアクセスするように構成されている、請求項７～１２のいずれかに記載のコンピュータプログラム。
14. 前記１つ以上のプロセッサが、受信したインプット－アウトプットペアのアウトポイントによって示される未使用トランザクションアウトプットが、トランザクション手数料をカバーするのに十分であるかどうかを決定するように、更に構成され、
    前記未使用トランザクションアウトプットが、前記トランザクション手数料をカバーするのに十分でない場合、認可インデックスのインプットは、前記インプット－アウトプットペアによってカバーされない前記トランザクション手数料の金額をカバーするのに十分な未使用トランザクションアウトプットを示すアウトポイントを含む、請求項７から１３のいずれかに記載のコンピュータプログラム。
15. 前記インプット－アウトプットペアのインプットのアウトポイントによって識別される未使用トランザクションアウトプットは、投票数に比例する値を持ち、１つの投票は事前に定義された値を持つ、請求項１～１４のいずれかに記載のコンピュータプログラム。
16. 前記トークンは、前記トークンを含むインプットの非署名部分に署名するときに使用しなければならない署名フラグを定義するロックスクリプトに関連付けられている。請求項４又は１１、請求項４又は１１に従属する請求項５～６、１２～１５のいずれかに記載のコンピュータプログラム。
17. コンピュータ可読媒体上に具現化されたブロックチェーントランザクションであって、
    ブロックチェーントランザクションのインプット内で示される使用可能トランザクションアウトプットを有効に消費するためのインプット、
    署名要件と必要な署名フラグを定義するロックスクリプトを含み、後続のブロックチェーントランザクションでアンロックスクリプトと連結されたときに、前記アンロックスクリプトの署名を妥当性確認し、前記アンロックスクリプトから使用された署名フラグを抽出し、前記使用された署名フラグと前記必要な署名フラグを比較し、前記使用された署名フラグが前記必要な署名フラグと一致しない及び／又は前記署名が無効である場合に、前記後続のブロックチェーントランザクションが無効になるようにする、少なくとも１つのアウトプットと、
    を含むブロックチェーントランザクション。
18. 前記署名フラグが前記署名の最後のバイトによって示され、前記使用された署名フラグを前記必要な署名フラグと比較するステップは、前記署名の前記最後のバイトを前記ロックスクリプトで定義された前記必要な署名フラグを示す値と比較することを含み、前記署名の前記最後のバイトが前記必要な署名フラグを示す値と等しい場合、前記使用された署名フラグと前記必要な署名フラグが一致する、請求項１７に記載のブロックチェーントランザクション。
19. トークンが投票トランザクションで使用され、使用可能アウトプットが投票数に比例する値を持つ、請求項１７又は１８に記載のブロックチェーントランザクション。
20. 前記ブロックチェーントランザクションは、承認されたパーティのセットのうちの各パーティに関連付けられたアウトプットを含み、前記承認されたパーティは、後続のブロックチェーントランザクションのインプットとアウトプットを提供する権限を与えられている、請求項１７～１９のいずれかに記載のブロックチェーントランザクション。
21. 前記承認されたパーティのセットのうちのサブセットは、前記後続のブロックチェーントランザクションのインプットとアウトプットを提供する必要があり、前記必要な署名フラグは、前記後続のブロックチェーントランザクション内の同じインデックスで提供されるインプットとアウトプットのみを承認するためのsingle－anyone can pay署名フラグである、請求項２０に記載のブロックチェーントランザクション。
22. 前記承認されたパーティのセットのうちのすべてのパーティは、前記後続のブロックチェーントランザクションのインプットとアウトプットを提供する必要があり、前記必要な署名フラグは、前記後続のトランザクションのすべてのインプットと、提供されたアンロックスクリプトと同じインデックスでのアウトプットのみを承認するためのsingle－all署名フラグである、請求項２０に記載のブロックチェーントランザクション。
23. 前記ブロックチェーントランザクションがトークン発行トランザクションであり、前記トークン発行トランザクションのアウトプットは、前記ブロックチェーントランザクションをブロックチェーンに記録するためだけに十分なデジタルアセットの名目量を定義する、請求項１７～２２のいずれかに記載のブロックチェーントランザクション。
24. 投票を行うためのブロックチェーンの投票トランザクションのインプットとアウトプットを生成する方法であり、前記方法は、
    投票コーディネータから、前記投票コーディネータによって定義された１つ以上の公開鍵と投票オプションのセットとを含む投票指示を受信するステップと、
    前記投票オプションのセットを表示するユーザインタフェースをレンダリングするステップと、
    前記ユーザインタフェースでユーザ入力によって定義された前記投票オプションのセットのうちの１つの投票オプションのユーザ選択を受信するステップと、
    投票トランザクションの異なるインデックスにある１つ以上の他のインプット－アウトプットペアを有する前記投票トランザクションに含めるインプット－アウトプットペアを生成するステップと、
    を含み、
    前記インプット－アウトプットペアのインプットの非署名部分は、ブロックチェーントランザクションの未使用トランザクションアウトプットを識別するアウトポイントを含み、前記インプットの署名部分は、signature singleフラグと、少なくとも前記インプット－アウトプットペアの前記非署名部分と前記インプット－アウトプットペアのアウトプットに署名するが前記投票トランザクションの他のアウトプットに署名しない関連署名と、を含み、前記インプット－アウトプットペアの前記アウトプットは、前記投票指示の１つ以上の公開鍵の１つを含む、方法。
25. ブロックチェーンの投票トランザクションを生成する方法であって、前記方法は、
    請求項１～１６のいずれかに従い複数のインプット－アウトプットペアを受信するステップと、
    投票トランザクションを生成するステップであって、前記投票トランザクションは、
    投票インデックスのセットの各投票インデックスの中に、受信したインプット－アウトプットペアの１つ、及び、
    認可インデックスの中に、投票コーディネータの署名が投票トランザクションのすべてのインプットとアウトプットに署名するように、all署名フラグを持つ投票コーディネータの署名を含むインプットと、アウトプットと、
    を含む、ステップと、
    前記投票トランザクションをブロックチェーンに送信するステップと、
    を含む方法。
26. コンピュータシステムであって、
    請求項１～６、又は請求項４に従属する請求項１６のいずれかに記載のコンピュータプログラムを実行するように構成された少なくとも１つのコンピューティング装置と、
    請求項７～１５、又は請求項７に従属する請求項１６記載のコンピュータプログラムを実行するように構成された少なくとも１つのコンピューティング装置と、
    を含むコンピュータシステム。
27. ブロックチェーントランザクションを生成するコンピュータプログラムであって、前記コンピュータプログラムは非一時的媒体に格納され、１つ以上のプロセッサにより実行されると、前記１つ以上のプロセッサを、前記ブロックチェーントランザクションを生成するよう構成させ、前記ブロックチェーントランザクションは、
    前記ブロックチェーントランザクションのインプット内で示される使用可能トランザクションアウトプットを有効に消費するためのインプットと、
    署名要件と必要な署名フラグを定義するロックスクリプトを含む少なくとも１つのアウトプットであって、後続のブロックチェーントランザクション内のアンロックスクリプトと連結されたときに、前記アンロックスクリプトの署名を妥当性確認し、前記アンロックスクリプトから使用された署名フラグを抽出し、前記使用された署名フラグと前記必要な署名フラグを比較し、前記使用された署名フラグが前記必要な署名フラグと一致しない及び／又は前記署名が無効である場合に、前記後続のブロックチェーントランザクションが無効になるようにする、少なくとも１つのアウトプットと、
    を含む、コンピュータプログラム。

Images