特許 7532414 サイドチャネル上でのデータの部分のストリーミング

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-08-02

(45)【発行日】2024-08-13

(54)【発明の名称】サイドチャネル上でのデータの部分のストリーミング

(51)【国際特許分類】

   H04L 9/32 20060101AFI20240805BHJP

   G06F 21/10 20130101ALI20240805BHJP

   G06Q 20/38 20120101ALI20240805BHJP

【ＦＩ】

H04L9/32 200Z

G06F21/10

G06Q20/38 310

【請求項の数】 27

(21)【出願番号】P 2021568723

(86)(22)【出願日】2020-04-21

(65)【公表番号】

(43)【公表日】2022-07-22

(86)【国際出願番号】 IB2020053771

(87)【国際公開番号】W WO2020240292

(87)【国際公開日】2020-12-03

【審査請求日】2023-03-22

(31)【優先権主張番号】1907340.2

(32)【優先日】2019-05-24

(33)【優先権主張国・地域又は機関】GB

(73)【特許権者】

【識別番号】318001991

【氏名又は名称】エヌチェーン ライセンシング アーゲー

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ジャン，ウェイ

(72)【発明者】

【氏名】デーヴィス，ジャック

(72)【発明者】

【氏名】ライト，クレイグ

【審査官】中里 裕正

(56)【参考文献】

【文献】特表２０１９－５１１１４７（ＪＰ，Ａ）

【文献】特許第６４８７０９１（ＪＰ，Ｂ１）

【文献】米国特許出願公開第２０１９／００２８２７８（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１９／００５８９１０（ＵＳ，Ａ１）

【文献】国際公開第２０１８／０２０３８９（ＷＯ，Ａ２）

【文献】国際公開第２０１８／０９２４４３（ＷＯ，Ａ１）

【文献】SHI, F., QIN, Z. and MCCANN, J. A.，OPPay: Design and Implementation of A Payment System for Opportunistic Data Services，2017 IEEE 37th International Conference on Distributed Computing Systems，2017年06月，pp.1618-1628

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ９／３２

Ｇ０６Ｆ ２１／１０

Ｇ０６Ｑ ２０／３８

(57)【特許請求の範囲】

【請求項1】

ノードのネットワークの少なくとも一部の夫々で保持されているブロックチェーンのコピーにターゲットトランザクションを記録する方法であって、
第２パーティのコンピュータ機器によって、
第１パーティのコンピュータ機器と前記第２パーティのコンピュータ機器との間に、前記ネットワークとは別のサイドチャネルを形成することと、
連続したデータ部分のシーケンスを、該シーケンス内の最新のデータ部分まで、前記サイドチャネル上で前記第１パーティのコンピュータ機器へストリーミングすることと、
前記データ部分の各々のデータ部分に応答して、前記第１パーティのコンピュータ機器から第１トランザクションの異なった各々のインスタンスを前記サイドチャネル上で受信することであり、前記第１トランザクションは、デジタルアセットの量を指定する第１出力を有し、前記ターゲットトランザクションは、前記第１トランザクションの前記第１出力へのポインタを含む入力を有し、前記ターゲットトランザクションは、前記第１トランザクションの前記第１出力から前記第２パーティのコンピュータ機器へ転送すべき前記デジタルアセットの量を指定する出力を更に有し、前記第１トランザクションの前記第１出力で指定されている前記量は、前記第１トランザクションの連続するインスタンスごとに増大する、ことと、
前記第１トランザクションの最新のインスタンス及び前記ターゲットトランザクションの対応するバージョンが前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるようにすることであり、前記ターゲットトランザクションの前記対応するバージョンにおける前記ポインタは、前記シーケンスにおいて前記第１トランザクションの前記最新のインスタンスでの前記第１出力を指す、ことと
を有する方法。

【請求項2】

前記第１トランザクションの前記第１出力で指定されている前記量は、前記第１トランザクションの連続するインスタンスごとに線形に増大する、
請求項１に記載の方法。

【請求項3】

前記第１トランザクションの各インスタンスは、前記第１パーティのコンピュータ機器による前記各々のデータ部分の受信の肯定応答としての機能を果たし、
前記ストリーミングすることは、前記第１トランザクションの各インスタンスの受信に応答して前記シーケンスにおける次のデータ部分を送信することを有する、
請求項１又は２に記載の方法。

【請求項4】

前記第２パーティのコンピュータ機器で、
前記第１トランザクションのインスタンスのうちのいずれか１つのインスタンスと、そのインスタンスを指す前記ターゲットトランザクションの対応するバージョンとが、前記シーケンス内の任意の時点で、前記ネットワークにわたって伝播されて前記ブロックチェーンに記録されるようにすることを可能にするアプリケーション機能を提供することを有し、
当該方法は、代わりに前記機能を用いて、前記インスタンスのうちの先行するインスタンスのいずれかの代わりに、前記シーケンスにおける前記第１トランザクションの前記最新のインスタンス及び前記シーケンスにおける前記最新のインスタンスを指す前記ターゲットトランザクションの対応するバージョンの伝播及び記録を引き起こすことを有する、
請求項１乃至３のうちいずれか一項に記載の方法。

【請求項5】

前記データ部分の夫々は、メディアコンテンツ片の各々の部分を有する、
請求項１乃至４のうちいずれか一項に記載の方法。

【請求項6】

前記データ部分の夫々は、前記第１パーティのコンピュータ機器がサービスサプライヤからのサービスのユニットをアンロックすることを可能にする異なった各々のキーを有する、
請求項１乃至４のうちいずれか一項に記載の方法。

【請求項7】

前記サービスは、
電気、ガス、又は水道を含む公共事業の提供、あるいは、
不動産、車、又は他の物理オブジェクトの賃借
のうちの１つを有する、
請求項６に記載の方法。

【請求項8】

前記シーケンスは、有限なシーケンスであり、
前記最新のデータ部分は、前記シーケンス内の最後の部分である、
請求項１乃至７のうちいずれか一項に記載の方法。

【請求項9】

前記第１トランザクションの少なくとも最後のインスタンスの前記第１出力は、少なくとも第１条件及び第２条件を含む、前記第１トランザクションの前記第１出力をアンロックするための複数の代替条件を指定するロッキングスクリプトを有し、前記ターゲットトランザクションの前記入力は、アンロッキングスクリプトを有し、
前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるよう送信される前記ターゲットトランザクションの前記対応するバージョンにおいて、前記ロッキングスクリプトは、前記代替条件のうちの第１条件ではなく第２条件を満足することに基づいて前記第１トランザクションの前記第１出力をアンロックするよう構成される、
請求項８に記載の方法。

【請求項10】

前記第１トランザクションの各インスタンスの出力は、前記複数の代替条件を指定する前記ロッキングスクリプトを有し、
前記機能は、前記最後のインスタンスより前の前記第１トランザクションの現在受信されているインスタンスと、該現在のインスタンスを指す前記ターゲットトランザクションの第１バージョンとが前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるようにすることを可能にし、前記第１バージョンにおける前記ロッキングスクリプトは、前記第１条件を満足することに基づいて前記第１トランザクションの前記第１出力をアンロックするよう構成され、前記第２条件を満足する前記ロッキングスクリプトを含む前記ターゲットトランザクションの前記バージョンは、第２バージョンである、
請求項４に従属する請求項９に記載の方法。

【請求項11】

前記機能は、前記第１トランザクションの前記現在受信されているインスタンス及び前記ターゲットトランザクションの第１バージョンが前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるようにすることを手動で選択するためのオプションを前記シーケンス内の任意の時点で前記第２パーティのコンピュータ機器に提供し、かつ／あるいは、
前記機能は、前記第１パーティのコンピュータ機器が前記シーケンスを通じた前記第１トランザクションのインスタンスの送信を止める場合に、自動で前記第１トランザクションの前記現在のインスタンス及び前記ターゲットトランザクションの第１バージョンが前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるようにするよう構成される、
請求項１０に記載の方法。

【請求項12】

前記第２条件は、前記アンロッキングスクリプトが、該アンロッキングスクリプトを除く前記ターゲットトランザクションの部分に署名する前記第１パーティの暗号署名を有することを要求し、
伝播されて前記ブロックチェーンに記録されるよう送信される前記第２バージョンは、前記アンロッキングスクリプトにおいて前記第１パーティの前記署名を含む、
請求項１０又は１１に記載の方法。

【請求項13】

前記第１条件は、前記第１パーティの暗号署名を要求しない、
請求項１０乃至１２のうちいずれか一項に記載の方法。

【請求項14】

少なくとも前記第１条件は、前記アンロッキングスクリプトが、該アンロッキングスクリプトを除く前記ターゲットトランザクションの部分に署名する前記第２パーティの暗号署名を含むことを要求する、
請求項１０乃至１３のうちいずれか一項に記載の方法。

【請求項15】

前記第２条件は、前記アンロッキングスクリプトが、該アンロッキングスクリプトを除く前記ターゲットトランザクションの部分に署名する前記第２パーティの暗号署名を含むことを要求し、
伝播されて前記ブロックチェーンに記録されるよう送信される前記第２バージョンは、前記アンロッキングスクリプトにおいて前記第２パーティの前記署名を含む、
請求項１０乃至１４のうちいずれか一項に記載の方法。

【請求項16】

前記第２パーティの前記コンピュータ機器によって、
前記第１パーティの前記署名を加えることによって前記第１パーティのコンピュータ機器が前記ターゲットトランザクションの前記第２バージョンに統合するように前記第１バージョンを前記第１パーティのコンピュータ機器へ送ることを有する、
請求項１３又は１４に記載の方法。

【請求項17】

前記第１条件は、前記データ部分の夫々が前記アンロッキングスクリプトに含まれることを要求するが、前記第２条件は、前記データ部分のいずれも前記ターゲットトランザクションに含まれることを要求せず、
前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるよう送信される前記ターゲットトランザクションの前記第２バージョンは、前記ターゲットトランザクションにおいて前記データ部分のいずれも含まない、
請求項１０乃至１６のうちいずれか一項に記載の方法。

【請求項18】

前記第１条件は、前記アンロッキングスクリプトが前記データ部分の夫々と、前記アンロッキングスクリプトを除く前記ターゲットトランザクションの部分に署名する前記第２パーティの暗号署名とを有することを要求するが、前記第１パーティの暗号署名が前記ターゲットトランザクションに含まれることを要求せず、
前記第２条件は、前記アンロッキングスクリプトが前記第１パーティ及び前記第２パーティの両方の暗号署名を有することを要求するが、前記データ部分のいずれも前記ターゲットトランザクションに含まれることを要求せず、
伝播されて前記ブロックチェーンに記録されるよう送信される前記ターゲットトランザクションの前記第２バージョンは、該第２バージョンにおいて前記データ部分のいずれも含まないが、前記アンロッキングスクリプトにおいて前記第１パーティ及び前記第２パーティの前記署名を含む、
請求項１７に記載の方法。

【請求項19】

前記データ部分の夫々を含むという要件は、前記ロッキングスクリプトに含まれているハッシュチャレンジによって生成され、該ハッシュチャレンジは、データの各々の部分のハッシュと、前記アンロッキングスクリプトにおける各々のデータ部分のハッシュが前記ロッキングスクリプトに含まれているハッシュと一致することをチェックするハッシュ関数とを有し、
当該方法は、前記ネットワークとは別に、前記第１トランザクションのインスタンスの受信より前に、ハッシュセットを前記第１パーティのコンピュータ機器に利用可能にすることを有し、前記ハッシュセットは、前記第１パーティのコンピュータ機器が各々のデータ部分について前記ハッシュチャレンジを生成することを可能にするためのデータの部分ごとのハッシュ値を有する、
請求項１７又は１８に記載の方法。

【請求項20】

当該方法は、前記第２パーティのコンピュータ機器が前記サイドチャネル上で前記第１パーティのコンピュータ機器から前記第１トランザクションを受信することを有し、
前記第１トランザクションは、入力量を指定する１つ以上の第１入力を有し、前記第１トランザクションの前記第１出力は、第１ペイメントを指定し、前記第１トランザクションは、ペイメントの合計が前記入力量よりも多くなるように１つ以上の更なるペイメントを指定する１つ以上の更なる出力を更に有し、前記第１パーティのコンピュータ機器から前記第２パーティのコンピュータ機器によって受信される前記第１トランザクションは、差を補うための他の入力を有さず、前記ネットワークの前記ノードは、前記第１トランザクションが総入力量よりも多い総ペイメントを指定する場合には無効であるとして前記第１トランザクションを拒絶するよう構成され、
当該方法は、前記第２パーティのコンピュータ機器が、前記差を補うよう前記第１トランザクションの最新又は最後のインスタンスに第２入力を加え、該第２入力が加えられた前記第１トランザクションを、前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるよう送信することを有する、
請求項９乃至１９のうちいずれか一項に記載の方法。

【請求項21】

前記更なる出力は、前記入力量から前記第１ペイメントをマイナスしたものに等しい前記第１パーティへの第２ペイメントを指定する第２出力と、前記第２ペイメントに等しい前記第２パーティへの第３ペイメントを指定する第３出力とを有する、
請求項２０に記載の方法。

【請求項22】

前記ロッキングスクリプトは、前記代替条件のうちの第３条件を含み、該第３条件は、タイムアウト期間が経過していることと、前記第１パーティの暗号署名が前記アンロッキングスクリプトに含まれることとを要求して、前記タイムアウト期間内に前記第２パーティのコンピュータ機器によって精算されない場合に前記第１パーティのコンピュータ機器が前記第１トランザクションの前記第１出力におけるペイメントを精算することを可能にする、
請求項９乃至２１のうちいずれか一項に記載の方法。

【請求項23】

コンピュータ読み出し可能なストレージにおいて具現され、第２パーティのコンピュータ機器で実行される場合に、請求項１乃至２２のうちいずれか一項に記載の方法を実行するよう構成されるコンピュータプログラム。

【請求項24】

１つ以上のメモリユニットを有するメモリと、
１つ以上の処理ユニットを有する処理装置と
を有し、
前記メモリは、前記処理装置で実行されるよう配置されたコードを記憶し、該コードは、前記処理装置で実行される場合に、請求項１乃至２２のうちいずれか一項に記載の方法を実行するよう構成される、
コンピュータ機器。

【請求項25】

ノードのネットワークの少なくとも一部の夫々で保持されているブロックチェーンのコピーにターゲットトランザクションを記録することを第２パーティに可能にする方法であって、
第１パーティのコンピュータ機器によって、
前記ネットワークとは別のサイドチャネルを介して、前記第２パーティのコンピュータ機器から連続したデータ部分のシーケンスを受信することと、
前記データ部分の各々のデータ部分に応答して、前記第１パーティのコンピュータ機器から第１トランザクションの異なった各々のインスタンスを前記サイドチャネル上で返送することであり、前記第１トランザクションは、デジタルアセットの量を指定する第１出力を有し、前記ターゲットトランザクションは、前記第１トランザクションの前記第１出力へのポインタを含む入力を有し、前記ターゲットトランザクションは、前記第１トランザクションの前記第１出力から前記第２パーティのコンピュータ機器へ転送すべき前記デジタルアセットの量を指定する出力を更に有し、前記第１トランザクションの前記第１出力で指定されている前記量は、前記第１トランザクションの連続するインスタンスごとに増大する、ことと
を有し、
それによって、前記第２パーティのコンピュータ機器が、前記ターゲットトランザクションのインスタンスのいずれか１つを、前記ネットワークにわたって伝播されて前記ブロックチェーンに記録されるよう送信することを可能にする、
方法。

【請求項26】

コンピュータ読み出し可能なストレージにおいて具現され、第１パーティのコンピュータ機器で実行される場合に、請求項２５に記載の方法を実行するよう構成されるコンピュータプログラム。

【請求項27】

１つ以上のメモリユニットを有するメモリと、
１つ以上の処理ユニットを有する処理装置と
を有し、
前記メモリは、前記処理装置で実行されるよう配置されたコードを記憶し、該コードは、前記処理装置で実行される場合に、請求項２５に記載の方法を実行するよう構成される、
コンピュータ機器。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、ブロックチェーンベースのシステムとの関連において「オフチェーン」サイドチャネル上でのデータのストリーミング及び交換に関係がある。

【背景技術】

【0002】

ブロックチェーンは、分散型データ構造の形式を指し、ブロックチェーンの複製コピーが、ピア・ツー・ピア（Ｐ２Ｐ）ネットワーク内の複数のノードの夫々で保持される。ブロックチェーンは、データのブロックのチェーンを有し、各ブロックは１つ以上のトランザクションを有する。各トランザクションは、順番において前のトランザクションを指し示し得る。トランザクションは、「マイニング」として知られているプロセスによって新しいブロックに含まれるようネットワークにサブミットされ得る。マイニングは、複数のマイニングノードの夫々が「プルーフ・オブ・ワーク」を実行するよう競争すること、すなわち、ブロックに含まれるよう待機しているペンディング中のトランザクションのプールに基づき暗号パズルを解くことを伴う。

【0003】

従来、ブロックチェーン内のトランザクションは、デジタルアセット、すなわち、価値の蓄蔵として働くデータ、を運ぶために使用される。しかし、ブロックチェーンは、ブロックチェーンの上に追加の機能を積み重ねるためにも利用されることがある。例えば、ブロックチェーンプロトコルは、トランザクションの出力における追加のユーザデータの保存を可能にすることができる。最新のブロックチェーンは、より複雑なデータが組み込まれることを可能にしながら、単一のトランザクション内に保存され得る最大データ容量を増やしている。例えば、これは、ブロックチェーンに電子文書や、音声又は映像データさえも保存するために使用される可能性がある。

【0004】

ネットワーク内の各ノードは、３つの役割、転送、マイニング及び保存、のうちのいずれか１つ、２つ、又は全てを有することができる。転送ノードは、１つ以上の他のノードへ（有効な）トランザクションを夫々伝播し、よって、それらのノードの間でネットワークのノードにわたってトランザクションを伝播する。マイニングノードは、ブロック内へのトランザクションのマイニングを実行するよう夫々競争する。保存ノードは、ブロックチェーンのマイニングされたブロックのそれら自身のコピーを夫々記憶する。ブロックチェーンにトランザクションを記録するために、パーティは、ネットワークのノードの１つへトランザクションを送信して伝播する。トランザクションを受け取ったマイニングノードは、新しいブロック内にトランザクションをマイニングするために競争することができる。各ノードは、トランザクションが有効であるための１つ以上の条件を含む同じノードプロトコルを尊重するよう構成される。無効なトランザクションは、伝播されず、ブロック内にマイニングもされない。トランザクションが妥当性確認（validated）され、それによってブロックチェーン上に受け入れられると仮定すると、追加のユーザデータは、よって、不変のパブリックレコードとしてＰ２Ｐネットワーク内のノードの夫々で保存されたままである。

【0005】

プルーフ・オブ・ワークパズルを解いて最新のブロックを生成することに成功したマイナ（miner）は、通常は、新しい量のデジタルアセット生成する「ジェネレーショントランザクション」と呼ばれるトランザクションを見返りに与えられる。トランザクションは、任意に、成功したマイナに対する余分のマイニングフィーも指定してもよい。マイナは、ブロックをマイニングするために大量の計算リソースを必要とし、かつ、二重支払いの試みを含むブロックは、他のノードによって受け入れられない可能性があるので、プルーフ・オブ・ワークは、二重支払いトランザクションを彼らのブロックに含めることによってシステムをだまさないようにマイナに動機付けする。

【0006】

「出力ベース」のモデル（時々、ＵＴＸＯベースモデルと呼ばれる）では、所与のトランザクションのデータ構造は、１つ以上の入力及び１つ以上の出力を有する。如何なる使用可能な（spendable）出力も、時々ＵＴＸＯ（“Unspent Transaction Output”）と呼ばれる、デジタルアセットの量を指定する要素を有する。出力は、出力を精算（redeem）する条件を指定するロッキングスクリプトを更に有することがある。各入力は、前のトランザクションにおけるかような出力へのポインタを有し、更には、指し示された出力のロッキングスクリプトをアンロックするアンロッキングスクリプトを有することがある。故に、一対のトランザクションを考え、それらを第１トランザクション及び第２トランザクション（又は「ターゲット」トランザクション）と呼ぶ。第１トランザクションは、デジタルアセットの量を指定するとともに、出力をアンロックする１つ以上の条件を定義するロッキングスクリプトを有する少なくとも１つの出力を有する。第２の、ターゲットトランザクションは、第１トランザクションの出力へのポインタと、第１トランザクションの出力をアンロックするアンロッキングスクリプトとを有する少なくとも１つの入力を有する。

【0007】

かようなモデルにおいて、第２の、ターゲットトランザクションがＰ２Ｐネットワークへ送られて伝播されて、ブロックチェーンに記録される場合に、各ノードで適用される妥当性のための条件のうちの１つは、第１トランザクションのロッキングスクリプトで定義されている要件をアンロッキングスクリプトが満足することである。ターゲットトランザクションが有効であるための他の条件は、第１トランザクションの出力が他の有効なトランザクションによってまだ精算されていないことである。これらの条件のいずれかに従ってターゲットトランザクションを無効と判断した如何なるノードも、ブロックチェーンに記録するためにそれを伝搬することも、それをブロック内にマイニングするために含めることもない。

【0008】

例えば、ターゲットトランザクションは、ある量のデジタルアセットを第１パーティ（「アリス」）から第２パーティ（「ボブ」）へ運ぶことであるとする。先行する第１トランザクションのロッキングスクリプトで定義されている要件のうちの１つは、通常は、ターゲットトランザクションのアンロッキングスクリプトがアリスの暗号署名を含むことである。署名は、ターゲットトランザクションの一部にアリスが署名することによって生成されるべきである。

【0009】

トランザクションがブロックチェーンに記録されるようＰ２Ｐネットワークへブロードキャストされる前に、「オフチェーン」でパーティ間のトランザクションを交換するために、「ペイメントチャネル」と時々呼ばれるサイドチャネルを形成することも知られている。サイドチャネルは、Ｐ２Ｐオーバーレイネットワークとは別であり、従って、サイドチャネル上で送信される如何なるトランザクションも、パーティの１つがそれをネットワークに公開すると選択するまでは、ブロックチェーンでの記録のためにネットワークにわたって（まだ）伝播されない。典型的なペイメントチャネルは、「ファンディングトランザクション」（funding transaction）を必要とし、これによって、両方のパーティは、それらのファンドを一緒に有効にエスクローする。ファンディングトランザクションは、チャネルをセットアップするようブロードキャストされ、それから、問題となっているサービスが提供されると、決算（settlement）トランザクションが、チャネルを閉じるようブロードキャストされ、ファンディングトランザクションを使用する。

【0010】

「マイクロペイメントチャネル」のための、つまり、小さいインストールメントで他のパーティ（「ボブ」）に支払うために１つのパーティ（「アリス」）からボブへトランザクションのシーケンスを送るための、いくつかの既存の提案も存在している。これは、ファンディングトランザクションを必要としない。少なくとも１つの既存の提案は、パケットで映画のデータをストリーミングするためにサイドチャネルを使用することである。ボブは、データのパケットのシーケンスをアリスに送り、各パケットに応答して、アリスは、各々のトランザクションを返す。それから、ボブは、それをネットワークにブロードキャストして、映画の各々のパケットに対する支払いを得る。

【発明の概要】

【0011】

しかし、マイクロペイメントチャネルに対する既存の提案に伴う問題は、各々の個別トランザクションが、ボブがアリスとへ送るデータの各々の個別部分（例えば、映画の各パケット）について、Ｐ２Ｐネットワークへブロードキャストされてブロックチェーンに記録されることを必要とする点である。これは、より多くのネットワークトラフィックを生じさせるとともに、多数の小さいトランザクションでブロックチェーンを膨張させることになる。ファンディングトランザクションの必要を回避しながら、多くの小さい個別トランザクションでネットワークをあふれさせチェーンを膨張させることを回避するメカニズムを提供することが望まれる。

【0012】

本開示は、部分単位でデータのストリーミング及びストリーミングされたデータの各部に対する支払いを可能にしながら、シーケンス内のデータ部分の数（例えば、シーケンス内の３つ以上から数百又は数千を超える部分までの任意の数）にかかわらず、一対のトランザクションしか実際にネットワークへ送信されてブロックチェーンに記録されることを必要としないメカニズムを提供する。第１の受信パーティ（「アリス」）は、第２の送信パーティ（「ボブ」）からデータをストリーミングすることをいつでも停止可能であり、ボブは、ただ一対のトランザクションのネットワークへの公開に基づいて、これまでストリーミングされたデータの部分に対する支払いを依然として取得することができる。逆に、ボブは、データの部分を送信することをいつでも停止可能であり、アリスは、これまで送信されたデータの部分に対する支払いを取得することボブに可能にするだけである。

【0013】

これを達成するために、本明細書で開示されている一態様に従って、ノードのネットワークの少なくとも一部の夫々で保持されているブロックチェーンのコピーにターゲットトランザクションを記録する方法であって、第２パーティのコンピュータ機器によって実行される次の動作を有する方法が提供される。方法は、第１パーティと前記第２パーティとの間に、前記ネットワークとは別のサイドチャネルを形成することと、連続したデータ部分のシーケンスを、該シーケンス内の最新のデータ部分まで、前記サイドチャネル上で前記第１パーティへストリーミングすることと、前記データ部分の各々のデータ部分に応答して、前記第１パーティから第１トランザクションの異なった各々のインスタンスを前記サイドチャネル上で受信することとを有する。ターゲットトランザクションは、前記第１トランザクションの第１出力へのポインタを含む入力を有し、前記ターゲットトランザクションは、前記第１トランザクションの前記第１出力から前記第２パーティへ転送すべき前記デジタルアセットの量を指定する出力を更に有し、前記量は、前記ターゲットトランザクションの連続するインスタンスごとに増大する。方法は、前記第１トランザクションの最新のインスタンス及び前記ターゲットトランザクションの対応するバージョンが前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるようにすることを更に有し、前記ターゲットトランザクションの前記対応するバージョンにおける前記ポインタは、順番において前記第１トランザクションの前記最新のインスタンスでの前記第１出力を指す。

【0014】

２つ（以上）のトランザクションは、両方が同じソーストランザクション（又は「０番目」のトランザクション）の同じ出力（例えば、ＵＴＸＯ）を参照する入力を含む場合には、（実質的に）同じトランザクションのインスタンスであると本明細書では言われることがある。それらは、同じアンロッキング条件を満足することに基づいてその入力を精算してもよい。それらは、しかし、異なる入力署名を含むことがある（例えば、どちらのインスタンス内の署名されたメッセージも非同一である）。異なるインスタンスは、実質的に同じ機能を提供し得るが、各々のデータ部分が異なっており、量が増大している。後述されるいくつかの実施形態はまた、ターゲットトランザクションの異なる可能なバージョンを可能にし得る。２つのトランザクションは、両方が（インスタンスにかかわらず）第１トランザクションの同じ出力（例えば、同じＵＴＸＯ）を参照する入力を含む場合には、（実質的に）同じトランザクションのバージョンであると言われることがある。異なるバージョンは、その出力の異なるアンロッキング条件を満足することによって、異なる機能を提供し得る。異なるバージョンはまた、両方が同じ入力署名を含んでもよい（すなわち、どちらのインスタンス内の署名されたメッセージも同一である）。

【0015】

ターゲットトランザクションを含む複数のトランザクションの夫々について、ネットワークの少なくともいくつかのノードは、トランザクションが有効であるという条件で各トランザクションを伝播するよう構成され、少なくともいくつかのノードは、トランザクションが有効であるという条件でそのノードでブロックチェーンのコピーに各トランザクションを記録するよう構成される。例えば、ターゲットトランザクションは、通常は、アンロッキングスクリプトが第１トランザクションの出力をアンロックすることを条件とする。しかし、ネットワーク内の各ノードはまた、インスタンスのうちの１つが任意の所与のノードで妥当性確認されると、それから、他のインスタンスが、そのノードによって無効と見なされるので、ノードによって伝播されることもブロックチェーンに記録されることもないように、構成される。また、ターゲットトランザクションの１バージョンが所与のノードで妥当性確認されると、それから、ターゲットトランザクションの如何なる他のバージョンもそのノードによって無効と見なされるので、ノードによって伝播されることもブロックチェーンに記録されることもない。

【0016】

第１トランザクションのインスタンス（例えば、それらをＴｘ_１、Ｔｘ_２、Ｔｘ_３、・・・と呼ぶ）は、ネットワークの各ノードによって、実質的に同じトランザクションのインスタンスと見なされる。これは、各インスタンスが、同じ先行ソーストランザクション（又は「０番目」のトランザクションであり、以下の例ではＴｘ_０と表記される）の同じ出力を指し示す入力を有しているからである。これは、第１トランザクションの１つのインスタンス（例えば、Ｔｘ_１、Ｔｘ_２、・・・のうちの１つ）がマイニングされると直ぐに、それから、ソーストランザクション（例えば、Ｔｘ_０）の出力が消費され、従って、如何なる他のインスタンスによっても消費され得ないことを意味する。従って、ただ１つのインスタンスしかブロックチェーンに記録され得ない。更に、第１トランザクションのインスタンスのうちの１つが、任意の所与のノードで、ターゲットトランザクションの任意のバージョン（例えば、Ｔｘ_ｐ又はＴｘ_ｐ’）によって有効に精算されることが検出されると、それから、第１トランザクションのいずれかのインスタンスを精算しようと試みる如何なる更なるターゲットトランザクションも、そのノードによって無効と見なされ、従って、そのノードによって伝播されることもブロックチェーンに記録されることもない。

【0017】

ターゲットトランザクションの任意のバージョン（例えば、Ｔｘ_ｐ又はＴｘ_ｐ’）がＰ２Ｐネットワーク上でブロードキャストされ、所与のノードで、第１トランザクションの特定のインスタンス（異なる量を定義する異なるインスタンス）の第１出力を有効に指し示すことが検出されると、これは、ただ１つのターゲットトランザクションしか出力を有効に精算することができないということで、その出力が如何なる更なるバージョンによっても再びに精算され得ないことを意味する。すなわち、第１トランザクションのインスタンス（Ｔｘ_１、Ｔｘ_２、Ｔｘ_３、・・・）のうちの１つが、所与のノードでターゲットトランザクション（例えば、Ｔｘ_ｐ又はＴｘ_ｐ’）によって有効に精算されることが検出されると、それから、第１トランザクションのいずれかのインスタンスを精算しようと試みる如何なる更なるターゲットトランザクションも、無効に見なされ、従って、そのノードによって伝播されることもブロックチェーンに記録されることもない。それでもなお、各インスタンスでのペイメントも、データの各部分と引き換えに増大するので、第２パーティ（「ボブ」）が行うべき全ては、第１トランザクションの最後又は最新のインスタンスＴｘ_ｎを精算するターゲットトランザクションのバージョン（例えば、Ｔｘ_ｐ’）を、伝播されてブロックチェーンに記録されるよう送信される。彼は、次いで、単一のトランザクション対に基づいてその時点までに送られたデータの全部分に対する完全なペイメントを受け取る。

【0018】

任意の時点で、アリスが、シーケンスの終了前に、第１トランザクションのインスタンス（Ｔｘ_１、Ｔｘ_２、Ｔｘ_３、・・・）を送ることを止めた場合に、ボブは、更なるデータ部分をアリスへ送ることを止めて、その時点より前に送られたデータの部分に対するペイメントを精算するためにターゲットトランザクションのバージョン（例えば、Ｔｘ_ｐ）をネットワークへ送信するという選択肢を依然として有している（従って、送信された最新のデータ部分のみを失う）。逆に、任意の時点で、ボブがデータ部分を送信することを止めた場合に、アリスは、第１トランザクションの更なるインスタンスＴｘ_ｉを送信することを止めるという選択肢を有しており、ボブは、それまでにアリスが受け取ったデータ部分に対するペイメントを精算する能力のみを受け取っていることになる。

【0019】

特定の任意の実施で、方法は、前記第２パーティが前記サイドチャネル上で前記第１パーティから前記第１トランザクションを受信することを有してもよく、前記第１トランザクションは、入力量を指定する１つ以上の第１入力を有してもよく、前記第１トランザクションの前記第１出力は、第１ペイメントを指定し、前記第１トランザクションは、ペイメントの合計が前記入力量よりも多くなるように１つ以上の更なるペイメントを指定する１つ以上の更なる出力を更に有し、前記第１パーティから前記第２パーティによって受信される前記第１トランザクションは、差を補うための他の入力を有さない。例えば、前記更なる出力は、前記入力量から前記第１ペイメントをマイナスしたものに等しい前記第１パーティへの第２ペイメントを指定する第２出力と、前記第２ペイメントに等しい前記第２パーティへの第３ペイメントを指定する第３出力とを有してもよい。前記ネットワークの前記ノードは、前記第１トランザクションが総入力量よりも多い総ペイメントを指定する場合には無効であるとして前記第１トランザクションを拒絶する。かような実施形態で、方法は、前記第２パーティが、前記差を補うよう前記第１トランザクションの最新又は最後のインスタンスに第２入力を加え、該第２入力が加えられた前記第１トランザクションを、前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるよう送信することを有する。

【0020】

これは、第１パーティ（「アリス」）が、彼女自身のターゲットトランザクションを送信して前のインスタンスのうちの１つを精算し、このようにして、ボブが後のインスタンスのうちの１つ（又は、実際には、インスタンスのうちのいずれか）を精算できないようにすることによって、システムをごまかすことを防ぐ。これは、そうするために、アリスが、彼女のデジタルアセットのより多くを負担することになる余分の入力を追加する必要があるからである。従って、アリスがシステムをごまかそうとする価値はない。

【0021】

更なる任意の実施形態で、前記第１トランザクションの少なくとも最後のインスタンスの前記第１出力は、少なくとも第１条件及び第２条件を含む、前記第１トランザクションの前記第１出力をアンロックするための複数の代替条件を指定するロッキングスクリプトを有してもよく、前記ターゲットトランザクションの前記入力は、アンロッキングスクリプトを有してもよい。かような実施形態で、前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるよう送信される前記ターゲットトランザクションの前記対応するバージョンにおいて、前記ロッキングスクリプトは、前記代替条件のうちの第１条件ではなく第２条件を満足することに基づいて前記第１トランザクションの前記第１出力をアンロックするよう構成される。

【0022】

前記第１トランザクションの各インスタンスの出力は、前記複数の代替条件を指定する前記ロッキングスクリプトを有してもよい。この場合に、方法は、最後のインスタンスより前の前記第１トランザクションの現在受信されているインスタンスと、該現在のインスタンスを指す前記ターゲットトランザクションの第１バージョンとが前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるようにすることを可能にする機能を提供することを有してもよく、前記第１バージョンにおける前記ロッキングスクリプトは、前記第１条件を満足することに基づいて前記第１トランザクションの前記第１出力をアンロックするよう構成される。

【0023】

例えば、前記機能は、前記第１トランザクションの前記現在受信されているインスタンス及び前記ターゲットトランザクションの第１バージョンが前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるようにすることを手動で選択するためのオプションを前記シーケンス内の任意の時点で前記第２パーティに提供してもよい。代替的に、又は追加的に、前記機能は、前記第１パーティが前記シーケンスを通じた前記第１トランザクションのインスタンスの送信を止める場合に、自動で前記第１トランザクションの前記現在のインスタンス及び前記ターゲットトランザクションの第１バージョンが前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるようにするよう構成されてもよい。

【0024】

ターゲットトランザクションの有効性は、上記の条件のうちのいずれか１つに従ってアンロッキングスクリプトが第１トランザクションの出力をアンロックすることを条件とする。しかし、バージョンのうちの１つが任意の所与のノードで妥当性確認されると、他のバージョンは、そのノードで無効と見なされることになるので、そのノードによって伝播されることも、そのノードでブロックチェーンに記録されることもない。

【0025】

従って、第２パーティ（「ボブ」）は、両方のバージョンが第１トランザクションを有効に精算することができないということで、両方のバージョンを、伝播されてブロックチェーンに記録されるよう送信しない。彼は、第２条件を満足することに基づいて、第２バージョンを、伝播されて記録されるように送信する。これは、彼の好みである。しかし、第１バージョンが存在したという事実により、第２バージョンに対する必要な条件が満たされない場合には、第１バージョンが記録されたというフォールバックが彼に与えられる。例えば、第１条件は、データペイロードがターゲットトランザクションのアンロッキングスクリプトに含まれることを求めてもよく、これはボブにペナルティを課すことになる（例えば、マイニングフィーがデータサイズに比例するため、及び／又はデータがボブに独自のものであって、それをブロックチェーンに置くことがそれを公にすることになるため）。他方で、第２条件は、アリスの署名を求めてもよく、従って、アリスの承認を必要とする。

【0026】

本明細書で開示されている更なる態様によれば、方法を実行するためのプログラム、及び／又は方法を実行するようプログラムされている第２パーティのコンピュータ機器が提供される。

【0027】

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

【図面の簡単な説明】

【0028】

【図1】ブロックチェーンを実装するシステムの略ブロック図である。

【図2】ブロックチェーンに記録され得るトランザクションのいくつかの例を概略的に表す。

【図3】ブロックチェーンを実装する他のシステムの略ブロック図である。

【図4】クライアントアプリケーションの略ブロック図である。

【図5】図４のクライアントアプリケーションによって提示され得るユーザインターフェースの例の略モックアップである。

【図6】トランザクションの組の模式図である。

【図7】データをストリーミングする方法を示すシグナリングチャートである。

【図8】図７の方法の実施例における第１トランザクションのインスタンスの入力及び出力の値を示すグラフである。

【図9】図７の方法における第１トランザクションのためのトランザクションフォーマットの例である。

【発明を実施するための形態】

【0029】

述べられたように、ペイメントチャネル及びマイクロペイメントチャネルのためのいくつかの既存の提案が存在している。しかし、それらは全て、個々のトランザクションが、ペイメントにおける個々のインクリメントごとに（すなわち、ストリーミングの場合には、送信された個々のデータ部分ごとに）、Ｐ２Ｐネットワーク上で公開されてブロックチェーンに記録されることを必要とする。これは、Ｐ２Ｐネットワーク上でのネットワーク輻輳を消費させ、また、小さいマイクロペイメントのための多くのトランザクションでブロックチェーンを膨張させる。

【0030】

本開示は、代わりに、ボブから受け取られたデータの各部分に応答して、アリスが、サイドチャネル上で、毎回ペイメントが増大する所与のトランザクションの異なるインスタンスをボブへ返送するメカニズムを提供する。ボブは、このトランザクションのインスタンスのうちの１つでのみペイメントを請求することができる。

【0031】

更に、既存のプロトコルのほとんどは、信頼を確立するためにファンディングトランザクションを必要とする。ペイメントチャネルの如何なる時期尚早の閉鎖も、ファンドが一定期間ロックされることを生じさせることになる。代替的に、それらは、コンセンサスルールの変更、つまり、プロトコルの安定性を損なう可能性がある新しいオペコードを導入すること、を必要とする。他のいくつかは、有効期限を有している。しかし、チャネルセットアッププロセスでのオーバーヘッドと相まって、有効期限は望ましくない特性になる。

【0032】

本明細書で開示されている実施形態は、ペイメントチャネルをセットアップするためのファンディングトランザクションを有さないという選択肢を提供する。代わりに、参加者は、彼らが望むようにチャネルに参加したり、チャネルから離れたりすることができる。開示されている技術はまた、既存のトランザクション及びノードプロトコルで実装され可能である。

【0033】

実施形態は、可鍛性（malleability）の概念を利用し得る。可鍛性は、トランザクションを全体として無効にせずに、トランザクションの少なくとも一部を変更する能力を指す。関連する形式の暗号署名（例えば、ＥＣＤＳＡ署名）によって署名されているトランザクション内の如何なる署名も、書き換え（malleation）の可能性を受けない。

【0034】

例えば、ターゲットトランザクションは、ある量のデジタルアセットを第１パーティ（「アリス」）から第２パーティ（「ボブ」）へ運ぶことであるとする。先行する第１トランザクションのロッキングスクリプトで定義されている条件の１つは、通常は、ターゲットトランザクションのアンロッキングスクリプトがアリスの暗号署名を含むことである。署名は、アリスがターゲットトランザクションの部分に署名することによって生成される必要がある。これがどの部分であるかは、ロッキングスクリプトによって柔軟に定義されてもよく、あるいは、使用されているプロトコルに応じて、ノードプロトコルの固有の特徴であってもよい。それでもなお、署名される部分は、通常は、ターゲットトランザクションのその他の部分、例えば、アンロッキングスクリプト自体の一部又は全部、を除く。

【0035】

これは、「可鍛性」の可能性をもたらす。すなわち、マイニング前に、署名されていないターゲットトランザクションの部分は、トランザクションを無効にせずに変更（“malleated”）され得る。可鍛性は、一般的に暗号化で知られている概念であり、それは、通常、メッセージが悪意を持って変更される可能性がありながら依然として本物として受け入れられるという安全上の懸念と見なされている。ブロックチェーンの概念では、可鍛性は、必ずしも問題ではなく、単に、トランザクションの特定の部分がそれを無効にせずに変更され得る興味をそそるアーチファクトとして知られている。可鍛性に関連した如何なる安全上の懸念も、代わりに、プロトコル自体ではなく不適切な実装によって引き起こされる。

【0036】

本明細書で開示されている実施形態は、高速で、安全で、信頼できるペイメントチャネルを容易にするための有用な特徴として可鍛性を任意に用いる。アイデアは、トランザクション内のどの１つ以上の部分が（例えば、ＥＣＤＳＡ署名によって）署名されていないかまたは署名されるべきではないかを識別することである。開示されているスキームは、トランザクションの各入力のアンロッキングスクリプト（例えば、「ｓｃｒｉｐｔＳｉｇ」フィールド）内の如何なるコンテンツも如何なる署名によっても署名されないという事実を利用する。実施形態はまた、トランザクションをそれを無効にせずに変更するための更なる柔軟性を可能にするためにＳＩＧＨＡＳＨフラグを利用してもよい。

【0037】

例は次の通りである。ブロックチェーン上でデータを交換する場合に、一般的な方法の１つは、ハッシュパズルを使用して、データの公開とペイメントの受け取りとが同時に行われるようにすることである。これを回避するために、トランザクションは、ペイメントが２つの条件：ｉ）「データ＋ボブの署名」を提供すること、又はｉｉ）「アリスの署名＋ボブの署名」を提供することのうちのどちらか一方で請求可能であるように、構成され得る。

【0038】

ボブは、データ及び彼の署名を提供することによってファンドを請求し、それをアリスへ送るようトランザクションを構成する。それから、アリスは、データを彼女の署名で置換し、トランザクションをネットワークへブロードキャストする。代替的に、ボブがアリスの署名を取得し、それによりデータを置換して、ネットワークへブロードキャストする。いずれにしても、データはボブの署名によって署名されたメッセージの部分ではないので、それをアリスの署名で置換することは、トランザクションを無効にしない。更に、トランザクションは、入力が条件ｉｉ）を満足するということで、依然として有効である。アリスがトランザクションをネットワークへブロードキャストしないか、あるいは、署名を提供しない場合には、ボブは、条件ｉ）に基づいて、ファンドを請求するよう元のトランザクションをブロードキャストするという選択肢を依然として有している（これは、ボブが、サイズが大きくかつ／あるいは独自仕様である可能性があるデータアップロードする必要があるので、それほど望ましくない）。アリスは、承認の要件や割引のインセンティブによって彼女の署名を提供するよう、あるいは、十分に実行されたサービスに対してボブに報酬を与えるよう、促され得る。

【0039】

［システム概要］
図１は、ブロックチェーン１５０を実装する、例となるシステム１００を示す。システム１００は、パケット交換ネットワーク１０１、通常は、インターネットなどのワイドエリアインターネットワーク、を有する。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内でピア・ツー・ピア（Ｐ２Ｐ）オーバーレイネットワーク１０６を形成するよう配置された複数のノード１０４を有する。各ノード１０４は、ピアのコンピュータ設備を有し、ノード１０４の異なる１つは異なるピアに属している。各ノード１０４は、１つ以上のプロセッサ、例えば、１つ以上の中央演算処理装置（ＣＰＵ）、アクセラレータプロセッサ、特定用途向けプロセッサ、及び／又はフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）を有する処理装置を有する。各ノード１０４はまた、メモリ、すなわち、１つ以上の非一時的なコンピュータ可読媒体の形を取るコンピュータ読み出し可能なストレージも有する。メモリは、１つ以上のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ソリッド・ステート・ドライブ（ＳＳＤ）、フラッシュメモリ、若しくはＥＥＰＲＯＭなどの電子媒体、及び／又は光ディスクドライブなどの光学媒体を用いる１つ以上のメモリユニットを有してもよい。

【0040】

ブロックチェーン１５０は、データのブロック１５１のチェーンを有し、ブロックチェーン１５０の各々のコピーは、Ｐ２Ｐネットワーク１０６内の複数のノードの夫々で保持される。チェーン内の各ブロック１５１は、１つ以上のトランザクション１５２を有し、この文脈中のトランザクションは、一種のデータ構造を指す。データ構造の性質は、トランザクションモデル又はスキームの部分として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、通常は、全体を通して１つの特定のトランザクションプロトコルを使用する。１つの一般的なタイプのトランザクションプロトコルでは、各トランザクション１５２のデータ構造は、少なくとも１つの入力及び少なくとも１つの出力を有する。各出力は、出力が暗号でロックされているユーザ１０３に属するデジタルアセットの分量を表す量を指定する（アンロックされて精算又は使用されるためにそのユーザの署名を必要とする）。各入力は、前のトランザクション１５２の出力を指し示して、トランザクションをリンクする。

【0041】

ノード１０４のうちの少なくともいくつかは、トランザクション１５２を転送し、それによって伝播する転送ノード１０４Ｆの役割を果たす。ノード１０４のうちの少なくともいくつかは、ブロック１５１をマイニングするマイナ１０４Ｍの役割を果たす。ノード１０４のうちの少なくともいくつかは、保存ノード１０４Ｓ（「完全コピー」ノードとも時々呼ばれる）の役割を果たし、それらの夫々は、各々のメモリに同じブロックチェーン１５０の各々のコピーを記憶する。各マイナノード１０４Ｍはまた、ブロック１５１内にマイニングされるのを待っているトランザクション１５２のプール１５４を保持する。所与のノード１０４は、転送ノード１０４Ｆ、マイナ１０４Ｍ、保存ノード１０４Ｓ、又はそれらのうちの２つ又は全ての任意の組み合わせであってよい。

【0042】

所与の、目下のトランザクション１５２ｊで、（各）入力は、トランザクションのシーケンスにおいて前のトランザクション１５２ｉの出力を参照し、この出力が目下のトランザクション１５２ｊで精算又は“使用”（spent）されるべきであることを指定するポインタを有する。一般に、前のトランザクションは、プール１５４又は任意のブロック１５１内の任意のトランザクションであってよい。前のトランザクション１５２ｉは、必ずしも、目下のトランザクション１５２ｊが生成されるか、又はネットワーク１０６へ送信される時点に存在している必要はないが、前のトランザクション１５２ｉは、目下のトランザクション１５２ｊが有効であるために存在し妥当性確認される必要がある。従って、本願での「前の」（preceding）は、ポインタによってリンクされた論理順序において前にあるもの（predecessor）を指し、必ずしも時間順序における生成又は送信の時点ではなく、従って、それは、トランザクション１５２ｉ、１５２ｊが順不同で生成又は送信されることを必ずしも排除するわけではない（孤立トランザクションに関する以下の説明を参照）。前のトランザクション１５２ｉは、先行（antecedent又はpredecessor）トランザクションと同様に呼ばれることがある。

【0043】

目下のトランザクション１５２ｊの入力はまた、前のトランザクション１５２ｉの出力がロックされるユーザ１０３ａの署名も有する。つまり、目下のトランザクション１５２ｊの出力は、新しいユーザ１０３ｂに暗号でロックされ得る。目下のトランザクション１５２ｊは、このようにして、目下のトランザクション１５２ｊの出力で定義されている新しいユーザ１０３ｂへ、前のトランザクション１５２ｉの入力で定義されている量を転送し得る。いくつかの場合に、トランザクション１５２は、複数のユーザ（そのうちの１ユーザが、チェンジ（change）を与えるために元のユーザ１０３ａであってよい）の間で入力量を分割するために複数の出力を有してもよい。いくつかの場合に、トランザクションはまた、１つ以上の前のトランザクションの複数の出力からの両方をひとまとめにして、現在のトランザクションの１つ以上の出力に再分配するために複数の入力を有することができる。

【0044】

上記は、未使用トランザクション出力（ＵＴＸＯ）タイププロトコル（出力がＵＴＸＯと呼ばれる）とも時々呼ばれる「出力ベース」のトランザクションプロトコルと呼ばれることがある。ユーザの総合収支（total balance）は、ブロックチェーンに保存されているいずれか１つの番号では定義されず、代わりに、ユーザは、ブロックチェーン１５０内の多種多様なトランザクション１５２にわたって散らばっているそのユーザの全てのＵＴＸＯの値を照合するよう特別の“ウォレット”１０５を必要とする。

【0045】

トランザクションプロトコルの代替のタイプは、アカウントベースのトランザクションモデルの部分として、「アカウントベース」のプロトコルと呼ばれることがある。アカウントベースの場合に、各トランザクションは、過去のトランザクションのシーケンスにおいて前のトランザクションのＵＴＸＯを参照することによって、転送されるべき量を定義するのではなく、むしろ、絶対的なアカウント残高を参照することによって定義する。全てのアカウントの現在の状態は、ブロックチェーンとは別のマイナによって保存され、常に更新される。本開示は、アカウントベースではなく、出力ベースのモデルに関係がある。

【0046】

いずれのタイプのトランザクションプロトコルによっても、ユーザ１０３が新しいトランザクションを成立させたい場合に、彼／彼女は、その新しいトランザクションを彼／彼女のコンピュータ端末１０２からＰ２Ｐネットワーク１０６のノード１０４（今日、通常は、サーバ又はデータセンタであるが、原理上、他のユーザ端末であってもよい）の１つへ送る。このノード１０４は、トランザクションが有効であるかどうかを、ノード１０４の夫々で適用されるノードプロトコルに従ってチェックする。ノードプロトコルの詳細は、問題となっているブロックチェーン１５０で使用されているトランザクションプロトコルのタイプに対応し、一緒にトランザクションモデル全体を形成する。ノードプロトコルは、通常は、新しいトランザクション１５２ｊ内の暗号署名が、トランザクション１５２の順序づけられたシーケンスにおける前のトランザクション１５２ｉに依存する期待される署名と一致することをチェックするように、ノード１０４に求める。出力ベースの場合に、これは、新しいトランザクション１５２ｊの入力に含まれているユーザの暗号署名が、新しいトランザクションが使用する前のトランザクション１５２ｉの出力で定義されている条件と一致することをチェックすることを有してもよい。この条件は、通常は、新しいトランザクション１５２ｊの入力における暗号署名が、新しいトランザクションの入力が指し示す前のトランザクション１５２ｉの出力をアンロックすることを少なくともチェックすることを含む。いくつかのトランザクションプロトコルで、条件は、入力及び／又は出力に含まれているカスタムスクリプトによって少なくとも部分的に定義されてもよい。代替的に、それは、単に、ノードプロトコルのみによって確定されても、あるいは、これらの組み合わせによってもよい。いずれにしても、新しいトランザクション１５２ｊが有効である場合には、現在のノードはそれをＰ２Ｐネットワーク１０６内のノード１０４のうちの１つ以上の他のノードへ転送する。これらのノード１０４のうちの少なくともいくつかは、同じノードプロトコルに従って同じテストを適用しながら、転送ノード１０４Ｆとしても働くので、新しいトランザクション１５２ｊを１つ以上の更なるノード１０４へ転送し、以降同様である。このようにして、新しいトランザクションは、ノード１０４のネットワークにわたって伝播される。

【0047】

出力ベースのモデルでは、所与の出力（例えば、ＵＴＸＯ）が使用されるかどうかの定義は、それがノードプロトコルに従って他の以降のトランザクション１５２ｊの入力によってまだ有効に精算されているかどうかである。トランザクションが有効であるための他の条件は、使用又は精算しようと試みている前のトランザクション１５２ｉの出力が他の有効なトランザクションによってまだ使用／精算されていないことである。先と同じく、有効でない場合には、トランザクション１５２ｊは、ブロックチェーンにおいて伝搬又は記録されない。これは、使用者（spender）が同じトランザクションの出力を１回よりも多く使用しようとする二重支払いを防ぐ。

【0048】

妥当性確認に加えて、ノード１０４Ｍの少なくともいくつかはまた、マイニングとして知られているプロセスでトランザクションのブロックを生成する最初のものであるよう競争する。これは「プルーフ・オブ・ワーク」によって裏打ちされる。マイニングノード１０４Ｍで、新しいトランザクションは、まだブロックに現れていない有効なトランザクションのプールに加えられる。マイナは、次いで、暗号パズルを解こうと試みることによって、トランザクションのプール１５４からトランザクション１５２の新しい有効なブロックを組み立てるよう競争する。通常、これは、ノンスがトランザクションのプール１５４と連結されてハッシュ化される場合に、ハッシュの出力が所定の条件を満足するように、「ノンス」（nonce）値を探すことを有する。例えば、所定の条件は、ハッシュの出力が特定の予め定義された数の先行ゼロ（leading zeros）を有していることであってよい。ハッシュ関数の特性は、それがその入力に関して予測不能な出力を有していることである。従って、この探索は、ブルート・フォース（brute force）によってのみ実行可能であるから、パズルを解こうとしている各ノード１０４Ｍでかなりの量の処理リソースを消費する。

【0049】

パズルを解く最初のマイナノード１０４Ｍは、このことをネットワーク１０６にアナウンスし、解をプルーフとして供給する。解は、次いで、ネットワーク内の他のノード１０４によって容易にチェックされ得る（ハッシュに対する解を与えられると、それがハッシュの出力に条件を満足させることをチェックすることは簡単である）。勝者がパズルを解いたトランザクションのプール１５４は、次いで、保存ノード１０４Ｓとして動作するノード１０４のうちの少なくともいくつかによって、各そのようなノードで勝者のアナウンスした解をチェックしたことに基づいて、ブロックチェーン１５０で新しいブロック１５１として記録されることになる。ブロックポインタ１５５も新しいブロック１５１ｎに割り当てられ、チェーン内の前に生成されたブロック１５１ｎ－１を指し示す。プルーフ・オブ・ワークは、新しいブロック１５１を生成するのに多大な労力を要するので、二重支払いのリスクを減らすのに役立ち、そして、二重支払いを含む如何なるブロックも他のノード１０４によって拒絶される可能性が高いと言うことで、マイニングノード１０４Ｍは、二重支払いが彼らのブロックに含まれることを許さないよう動機付けられる。生成されると、ブロック１５１は、同じプロトコルに従ってＰ２Ｐネットワーク１０６内の保存ノード１０４Ｓの夫々で認識されて保持されるので、変更され得ない。ブロックポインタ１５５も、ブロック１５１に順次的な順序を課す。トランザクション１５２は、Ｐ２Ｐネットワーク１０６内の各保存ノード１０４Ｓで順序づけられたブロックに記録されるので、これは、従って、トランザクションの不変のパブリック台帳を提供する。

【0050】

如何なる所与の時点でもパズルを解くよう競争する異なるマイナ１０４Ｍは、いつそれらが解を探し始めたかに応じて、如何なる所与の時点でのマイニングされていないトランザクションプール１５４の異なるスナップショットに基づいてそうしている可能性がある点に留意されたい。各々のパズルを解く者は誰でも、どのトランザクションが次の新しいブロック１５１ｎに含まれるかを最初に定義し、マイニングされていないトランザクションの現在のプール１５４は更新される。マイナ１０４Ｍは次いで、新たに定義された未処理のプール１５４からブロックを生成するよう競争を続け、以降同様である。プロトコルはまた、発生する可能性がある如何なる「フォーク」（fork）も解決するためにも存在する。フォークは、２つのマイナ１０４Ｍが互いに非常に短時間にパズルを解き、それにより、ブロックチェーンの競合する見解が伝播されることになる場合である。要するに、フォークのどちらの先が最も長いとしても、確定的なブロックチェーン１５０になる。

【0051】

ほとんどのブロックチェーンで、勝者マイナ１０４Ｍは、（１ユーザから他のユーザへある量のデジタルアセットを転送する通常のトランザクションとは対照的に）どこからともなく、新しいデジタルアセットを生成する特別な種類の新しいトランザクションを自動的に見返りに与えられる。従って、勝者ノードは、ある量のデジタルアセットを「マイニングした」と言われる。この特別なタイプのトランザクションは、時々「ジェネレーション」トランザクションと呼ばれる。それは、自動的に、新しいブロック１５１ｎの部分を形成する。この見返りは、マイナ１０４Ｍがプルーフ・オブ・ワーク競争に参加する動機を与える。しばしば、通常の（非ジェネレーション）トランザクション１５２も、その出力の１つで追加トランザクションフィーを指定して、そのトランザクションが含まれたブロック１５１ｎを生成した勝者マイナ１０４Ｍに更に見返りを与える。

【0052】

マイニングに関与する計算リソースにより、通常、マイナノード１０４Ｍの少なくとも夫々は、１つ以上の物理サーバユニットを含むサーバ、又はデータセンタ全体の形を取る。各転送ノード１０４Ｆ及び／又は保存ノード１０４Ｓも、サーバ又はデータセンタの形を取る。しかし、原則として、如何なる所与のノード１０４も、ユーザ端末又は一緒にネットワーク化されたユーザ端末のグループの形をとってもよい。

【0053】

各ノード１０４のメモリは、その各々の１つ以上の役割を実行しかつノードプロトコルに従ってトランザクション１５２を処理するためにノード１０４の処理装置で実行されるよう構成されたソフトウェアを記憶している。本明細書でノード１０４に起因する如何なる動作も、各々のコンピュータ設備の処理装置でソフトウェアが実行されることによって実行されてよいことが理解される。また、本明細書で使用されている「ブロックチェーン」と言う用語は、その種類の技術全般を指す一般名称であり、如何なる特定の独自仕様のブロックチェーン、プロトコル、又はサービスにも限定されない。

【0054】

ネットワーク１０１には、消費ユーザの役割を担う複数のパーティ１０３の夫々のコンピュータ機器１０２も接続されている。これらは、トランザクションにおけるプレイヤー及び受取人として働くが、必ずしも、他のパーティに成り代わってトランザクションをマイニング又は伝播することに参加するわけではない。それらは、必ずしも、マイニングプロトコルを実行するわけではない。２つのパーティ１０３及びそれらの各々の機器１０２は、実例の目的で示されている。すなわち、第１パーティ１０３ａ及び彼／彼女の各々のコンピュータ機器１０２ａ、並びに第２パーティ１０３及び彼／彼女の各々のコンピュータ機器１０２ｂである。多数のより多くのそのようなパーティ１０３及びそれらの各々のコンピュータ機器１０２が存在してシステムに参加してもよいが、便宜上それらは表されていないことが理解されるだろう。各パーティ１０３は、個人又は組織であってよい。純粋に実例として、第１パーティ１０３ａは、本明細書ではアリス（Alice）と呼ばれ、第２パーティ１０３ｂは、ボブ（Bob）と呼ばれるが、これは限定ではなく、本明細書でのアリス又はボブへの如何なる言及も、「第１パーティ」及び「第２パーティ」で夫々置換されてもよいことが理解されるだろう。

【0055】

各パーティ１０３のコンピュータ機器１０２は、１つ以上のプロセッサ、例えば、１つ以上のＣＰＵ、ＧＰＵ、他のアクセラレータプロセッサ、特定用途向けプロセッサ、及び／又はＦＰＧＡ、を有する各々の処理装置を有する。各パーティ１０３のコンピュータ機器１０２は、メモリ、すなわち、１つ以上の非一時的なコンピュータ可読媒体の形を取るコンピュータ読み出し可能なストレージ、を更に有する。このメモリは、１つ以上のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ＳＳＤ、フラッシュメモリ、若しくはＥＥＰＲＯＭなどの電子媒体、及び／又は光ディスクドライブなどの光学媒体、を用いる１つ以上のメモリユニットを有してもよい。各パーティ１０３のコンピュータ機器１０２におけるメモリは、処理装置で実行されるよう配置された少なくとも１つのクライアントアプリケーション１０５の各々のインスタンスを有するソフトウェアを記憶している。本明細書で所与のパーティ１０３に起因する如何なる動作も、各々のコンピュータ機器１０２の処理装置で実行されるソフトウェアを用いて実行されてもよいことが理解されるだろう。各パーティ１０３のコンピュータ機器１０２は、少なくとも１つのユーザ端末、例えば、デスクトップ若しくはラップトップコンピュータ、タブレット、スマートフォン、又はスマートウォッチなどのウェラブルデバイス、を有する。所与のパーティ１０３のコンピュータ機器１０２は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの、１つ以上の他のネットワーク化されたリソースを有してもよい。

【0056】

クライアントアプリケーション又はソフトウェア１０５は、最初に、１つ以上の適切なコンピュータ可読記憶媒体でいずれかの所与のパーティ１０３のコンピュータ機器１０２へ供給されてよく、例えば、サーバからダウンロードされるか、あるいは、リムーバブルＳＳＤ、フラッシュメモリキー、リムーバブルＥＥＰＲＯＭ、リムーバブル磁気ディスクドライブ、磁気フロッピー（登録商標）ディスク若しくはテープ、ＣＤ若しくはＤＶＤ ＲＯＭなどの光ディスク、又はリムーバブル光学ドライブ、などのリムーバブル記憶デバイスで供給される。

【0057】

クライアントアプリケーション１０５は、少なくとも「ウォレット」機能を有する。これは、２つの主な機能性を有している。それらのうちの１つは、各々のユーザパーティ１０３が、ノード１０４のネットワークにわたって伝播され、それによってブロックチェーン１５０に含まれるようトランザクション１５２を生成、署名し、送信することを可能にすることである。他は、彼又は彼女が現在所有しているデジタルアセットの量を各々のパーティに折り返し報告することである。出力ベースのシステムでは、この第２の機能性は、問題となっているパーティに属するブロックチェーン１５０にわたって散らばった様々なトランザクション１５２の出力で定義されている量を照合することを有する。

【0058】

各コンピュータ機器１０２でのクライアントアプリケーション１０５のインスタンスは、Ｐ２Ｐネットワーク１０６の転送ノード１０４Ｆのうちの少なくとも１つに動作可能に結合される。これは、クライアント１０５のウォレット機能がトランザクションをネットワーク１０６へ送ることを可能にする。クライアント１０５は、各々のパーティ１０３が受け手である如何なるトランザクションについてもブロックチェーン１５０にクエリする（あるいは、実施形態において、ブロックチェーン１５０は、その公共の可視性を通じて部分的に取引への信頼を提供する公共施設であるため、実際に、ブロックチェーン１５０内の他のパーティのトランザクションを検査する）ために、保存ノード１０４Ｓのうちの１つ、いくつか、又は全てに連絡することもできる。各コンピュータ機器１０２でのウォレット機能は、トランザクションプロトコルに従ってトランザクションプロトコル１５２を定式化して送信するよう構成される。各ノード１０４は、ノードプロトコルに従って、トランザクション１５２をネットワーク１０６にわたって伝播するためにそれらを転送する転送ノード１０４Ｆの場合に、トランザクション１５２を妥当性確認するよう構成されたソフトウェアを実行する。トランザクションプロトコル及びノードプロトコルは、互いに対応しており、所与のトランザクションプロトコルは所与のノードプロトコルと同調して、一緒に所与のトランザクションモデルを実装する。同じトランザクションプロトコルが、ブロックチェーン１５０における全てのトランザクション１５２に対して使用される（なお、トランザクションプロトコルは、その中で異なったサブタイプのトランザクションを許し得る）。同じノードプロトコルが、ネットワーク１０６内の全てのノード１０４によって使用される（なお、それは、異なったサブタイプのトランザクションを、そのサブタイプに対して定義された規則に従って異なるように扱ってもよく、また、異なるノードは、異なる役割を果たし、従って、プロトコルの異なった対応する態様を実装し得る）。

【0059】

述べられているように、ブロックチェーン１５０は、ブロック１５１のチェーンを有し、各ブロック１５１は、上述されたようにプルーフ・オブ・ワークプロセスによって生成された１つ以上のトランザクション１５２の組を有する。各ブロック１５１はまた、ブロック１５１に順次的な順序を定義するために、チェーン内の前に生成されたブロック１５１を指し示すブロックポインタ１５５も有する。ブロックチェーン１５０はまた、プルーフ・オブ・ワークプロセスによって新しいブロックに含まれるのを待っている有効なトランザクションのプール１５４も有する。各トランザクション１５２は、トランザクションのシーケンスに順序を定義するために、前のトランザクションに対するポインタを有する（トランザクション１５２のシーケンスは枝分かれすることを許されている点に留意されたい）。ブロック１５１のチェーンは、チェーン内の最初のブロックであったジェネシスブロック（Ｇｂ）１５３にまでずっとさかのぼる。チェーン１５０内の初期にある１つ以上のオリジナルのトランザクション１５２は、先行するトランザクションよりむしろ、ジェネシスブロック１５３を指し示していた。

【0060】

所与のパーティ１０３、例えば、アリスが、新しいトランザクション１５２ｊをブロックチェーン１５０に含まれるよう送信したいと望む場合に、彼女は、関連するトランザクションプロトコルに従って（例えば、彼女のクライアントアプリケーション１０５におけるウォレット機能を用いて）新しいトランザクションを定式化する。次いで、彼女は、トランザクション１５２をクライアントアプリケーション１０５から、彼女が接続されている１つ以上の転送ノード１０４Ｆへ送る。例えば、これは、アリスのコンピュータ１０２へ最も近く又は最も良く接続されている転送ノード１０４Ｆであってもよい。いずれかの所与のノード１０４が新しいトランザクション１５２ｊを受け取る場合に、それは、その新しいトランザクション１５２ｊをノードプロトコル及びその各々の役割に従って処理する。これは、最初に、新たに受け取られたトランザクション１５２ｊが、「有効である」ための特定の条件を満足するかどうかをチェックすることを有する。この例は、後で更に詳細に説明される。いくつかのトランザクションプロトコルで、有効性の条件は、トランザクション１５２に含まれているスクリプトによってトランザクションごとに設定可能であってよい。代替的に、条件は、単に、ノードプロトコルのビルトイン機構であっても、あるいは、スクリプトとノードプロトコルとの組み合わせによって定義されてもよい。

【0061】

新たに受け取られたトランザクション１５２ｊが、有効であると見なされるためのテストを通過する、という条件で（すなわち、それが「妥当性確認」される、という条件で）、トランザクション１５２ｊを受け取る如何なる保存ノード１０４Ｓも、新しい妥当性確認されたトランザクション１５２を、そのノード１０４Ｓで保持されているブロックチェーン１５０のコピーで、プール１５４に加える。更に、トランザクション１５２ｊを受け取った如何なる転送ノード１０４Ｆも、妥当性確認されたトランザクション１５２を、Ｐ２Ｐネットワーク１０６内の１つ以上の他のノード１０４へと前方に伝播する。各転送ノード１０４Ｆは同じプロトコルを適用するので、トランザクション１５２ｊが有効であると仮定し、これは、トランザクション１５２ｊがＰ２Ｐネットワーク１０６の全体にわたって直ぐに伝播されることになることを意味する。

【0062】

１つ以上の保存ノード１０４Ｓで保持されているブロックチェーン１５０のコピーでプール１５４に入れられると、次いで、マイナノード１０４Ｍは、新しいトランザクション１５２を含むプール１５４の最新バージョンに関してプルーフ・オブ・ワークパズルを解くよう競争し始める（他のマイナ１０４Ｍは、依然として、プール１５４の古いビューに基づいてパズルを解こうとしている可能性があるが、最初にそこに着いた者は、どこで次の新しいブロック１５１が終了し、新しいプールが開始するかを定義し、最終的に、誰かが、アリスのトランザクション１５２ｊを含むプール１５４の一部についてパズルを解く）。プルーフ・オブ・ワークが、新しいトランザクション１５２ｊを含むプール１５４について行われると、それは不変に、ブロックチェーン１５０内のブロック１５１のうちの１つの部分となる。各トランザクション１５２は、先のトランザクションへのポインタを有するので、トランザクションの順も不変に記録される。

【0063】

図２は、例となるトランザクションプロトコルを表す。これは、ＵＴＸＯベースのプロトコルの例である。トランザクション１５２（「Ｔｘ」と略される）は、ブロックチェーン１５０の基本データ構造である（各ブロック１５１は１つ以上のトランザクション１５２を含む）。以下は、出力ベース又は“ＵＴＸＯベース”のプロトコルを参照することによって記載される。しかし、これは、全ての可能な実施形態に対する限定ではない。

【0064】

ＵＴＸＯベースのモデルでは、各トランザクション（「Ｔｘ」）１５２は、１つ以上の入力２０２及び１つ以上の出力２０３を含むデータ構造を有する。各出力２０３は、未使用のトランザクション出力（ＵＴＸＯ）を有してもよく、ＵＴＸＯは、（ＵＴＸＯがまだ精算されていない場合に）他の新しいトランザクションの入力２０２のためのソースとして使用可能である。ＵＴＸＯは、デジタルアセット（価値の蓄蔵）の量を指定する。それはまた、数ある情報の中でもとりわけ、それが伝来したトランザクションのトランザクションＩＤを含んでもよい。トランザクションデータ構造はまた、ヘッダ２０１を有してもよく、ヘッダ２０１は、入力フィールド２０２及び出力フィールド２０３のサイズのインジケータを有してもよい。ヘッダ２０１はまた、トランザクションのＩＤを含んでもよい。実施形態において、トランザクションＩＤは、トランザクションデータ（トランザクションＩＤ自体を除く）のハッシュであり、マイナ１０４Ｍにサブミットされた生の（raw）トランザクション１５２のヘッダ２０１に格納される。

【0065】

例えば、アリス１０３ａは、問題となっているデジタルアセットのある量をボブ１０３ｂに転送するトランザクション１５２ｊを生成したいと望む。図２で、アリスの新しいトランザクション１５２ｊは、「Ｔｘ_１」とラベル付けされている。それは、順番において前のトランザクション１５２ｉの出力２０３でアリスにロックされているデジタルアセットの量を取り、これの少なくともいくらかをボブへ転送する。前のトランザクション１５ｉは、図２では「ＴＸ_０」とラベル付けされている。Ｔｘ_０及びＴｘ_１は、単に任意のラベルである。それらは必ずしも、Ｔｘ_０がブロックチェーン１５０内の最初のトランザクションであることも、Ｔｘ_１がプール１５４内の直ぐ次のトランザクションであることも意味しない。Ｔｘ_１は、アリスにロックされている未使用出力２０３を依然として有しているいずれかの前の（すなわち、先行する）トランザクションを指し示し得る。

【0066】

前のトランザクションＴｘ_０は、既に妥当性確認をされて、アリスが新しいトランザクションＴｘ_１を生成する時点には、あるいは、少なくとも、彼女がそれをネットワーク１０６へ送る時点までには、ブロックチェーン１５０に含まれていることができる。それは既に、その時点でブロック１５１のうちの１つに含まれていてもよく、あるいは、それは依然としてプール１５４で待機していてもよく、その場合に、それは、新しいブロック１５１に間もなく含まれることになる。代替的に、Ｔｘ_０及びＴｘ_１は生成されて、一緒にネットワーク１０６へ送信されてもよく、あるいは、ノードプロトコルが「孤立」（orphan）トランザクションをバッファすることを有する場合には、Ｔｘ_０はＴｘ_１の後に送信されてもよい。トランザクションのシーケンスに関連して本明細書で使用されている「前の」（preceding）及び「後の」（subsequent）という用語は、トランザクションで指定されたトランザクションポインタによって定義されているシーケンス内のトランザクションの順序を指す（どのトランザクションは、どの他のトランザクションを指し示すか、以降同様）。それらは、同様に、「先行」（predecessor）及び「後続」（successor）、又は「先祖」（antecedent）及び「子孫」（descendant）、「親」（parent）及び「子」（child）、等で置換され得る。それは必ずしも、それらが生成され、ネットワーク１０６へ送信され、あるいは、いずれかの所与のノード１０４に到着する順序を暗示するわけではない。それでもなお、前のトランザクション（先行するトランザクション又は「親」）を指し示す後続のトランザクション（続くトランザクション又は「子」）は、親トランザクションが妥当性確認されない限りは、妥当性確認されない。その親より前にノード１０４に到着する子は、孤立と見なされる。それは、ノードプロトコル及び／又はマイナ挙動に応じて、捨てられるか、あるいは、親を待つ一定の時間の間バッファされ得る。

【0067】

前のトランザクションＴｘ_０の１つ以上の出力２０３のうちの１つは、ここではＵＴＸＯ_０とラベル付けされている特定のＵＴＸＯを有する。各ＵＴＸＯは、そのＵＴＸＯによって表されるデジタルアセットの量を指定する値と、後続のトランザクションが妥当性確認されるために、従って、ＵＴＸＯが成功裏に精算されるためにその後続のトランザクションの入力２０２内のアンロッキングスクリプトによって満足されるべき条件を定義するロッキングスクリプトとを有する。通常、ロッキングスクリプトは、その量を特定のパーティ（それが含まれるトランザクションの受取人）にロックする。すなわち、ロッキングスクリプトは、アンロッキング条件を定義し、通常は、後続のトランザクションの入力内のアンロッキングスクリプトが、前のトランザクションがロックされているパーティの暗号署名を含む、という条件を有する。

【0068】

ロッキングスクリプト（別名、ｓｃｒｉｐｔＰｕｂＫｅｙ）は、ノードプロトコルによって認識されるドメイン固有言語で記述されたコード片である。そのような言語の特定の例は、「スクリプト」（Script）（大文字Ｓ）と呼ばれる。ロッキングスクリプトは、どのような情報がトランザクション出力２０３を使用するために必要とされるか、例えば、アリスの署名の要件、を指定する。アンロッキングスクリプトは、トランザクションの出力に現れる。アンロッキングスクリプト（別名、ｓｃｒｉｐｔＳｉｇ）は、ロッキングスクリプト基準を満足するために必要な情報を供給するドメイン固有言語で記述されたコード片である。例えば、それは、ボブの署名を含んでもよい。アンロッキングスクリプトは、トランザクションの入力２０２に現れる。

【0069】

故に、表されている例では、Ｔｘ_０の出力内のＵＴＸＯ_０は、ＵＴＸＯ_０が精算されるために（厳密には、ＵＴＸＯ_０を精算しようと試みる後続のトランザクションが有効であるために）、アリスの署名Ｓｉｇ Ｐ_Ａを必要とするロッキングスクリプト［Ｃｈｅｃｋｓｉｇ Ｐ_Ａ］を有する。［Ｃｈｅｃｋｓｉｇ Ｐ_Ａ］は、アリスのパブリック－プライベートキーペアからのパブリックキーＰ_Ａを含む。Ｔｘ_１の入力２０２は、（例えば、実施形態において、トランザクションＴｘ_０の全体のハッシュであるそのトランザクションＩＤ ＴｘＩＤ_０を用いて）Ｔｘ_１を指し示すポインタを含む。Ｔｘ_１の入力２０２は、ＴＸ_０内のＵＴＸＯ_０を識別するインデックスを、Ｔｘ_０の如何なる他の起こり得る出力の中からもそれを識別するために有する。Ｔｘ_１の入力２０２は、アリスがキーペアからの彼女のプライベートキーをデータ（時々、暗号法で「メッセージ」と呼ばれる）の予め定義された部分に適用することによって生成されたアリスの暗号署名を含むアンロッキングスクリプト＜Ｓｉｇ Ｐ_Ａ＞を更に有する。どのようなデータ（又は「メッセージ」）が有効な署名をもたらすようアリスによって署名される必要があるかは、ロッキングスクリプトによって、又はノードプロトコルによって、又はそれらの組み合わせによって定義されてよい。

【0070】

新しいトランザクションＴｘ_１がノード１０４に到着する場合に、ノードはノードプロトコルを適用する。これは、アンロッキングスクリプトが、ロッキングスクリプトで定義されている条件（この条件は１つ以上の基準を含んでもよい）を満足するかどうかをチェックするために、ロッキングスクリプト及びアンロッキングスクリプトを一緒に実行することを含む。実施形態において、これは、２つのスクリプトを連結することを含む：

＜Ｓｉｇ Ｐ_Ａ＞＜Ｐ_Ａ＞｜｜［Ｃｈｅｃｋｓｉｇ Ｐ_Ａ］

ここで、「｜｜」は、連結を表し、「＜・・・＞」は、スタックにデータを置くことを意味し、「［・・・］」は、アンロッキングスクリプトによって構成された関数（本例では、スタックベースの言語）である。同等に、スクリプトは、スクリプトを連結するのではく、共通のスタックにより、順々に実行されてもよい。いずれの場合にも、一緒に実行される場合に、スクリプトは、Ｔｘ_１の入力内のロッキングスクリプトが、データの期待された部分に署名するアリスの署名を含むことを認証するために、Ｔｘ_０の出力内のロッキングスクリプトに含まれているアリスのパブリックキーＰ_Ａを使用する。データ自体（「メッセージ」）の期待された部分はまた、この認証を実行するためにＴｘ_０にも含まれる必要がある。実施形態において、署名されたデータは、Ｔｘ_０の全体を含む（故に、データの署名された部分を平文で指定する別個の要素は、それが既に本質的に存在するということで、含まれる必要がある）。

【0071】

パブリック－プライベート暗号法による認証の詳細は、当業者によく知られている。基本的に、アリスが、彼女のプライベートキーによりメッセージを暗号化することによってメッセージに署名している場合に、アリスのパブリックキー及び平文のメッセージ（暗号化されていないメッセージ）を考えると、ノード１０４などの他のエンティティは、メッセージの暗号化されたバージョンがアリスによって署名されているべきであることを認証することができる。署名することは、通常は、メッセージをハッシュ化し、ハッシュに署名し、これを署名としてメッセージの平文バージョンにタグ付けすることを有するので、パブリックキーのいずれのホルダも署名を認証することが可能となる。従って、特定のデータ片又はトランザクションの部分に署名すること等への本明細書中の如何なる言及も、実施形態において、そのデータ片又はトランザクションの部分のハッシュに署名することを意味し得る点に留意されたい。

【0072】

Ｔｘ_１におけるアンロッキングスクリプトが、Ｔｘ_０のロッキングスクリプトで指定されている１つ以上の条件を満足する場合に（故に、示されている例では、アリスの署名がＴｘ_１で与えられて、認証される場合に）、ノード１０４は、Ｔｘ_１を有効であると見なす。それが保存ノード１０４Ｓである場合には、これは、保存ノード１０４Ｓが、Ｔｘ_１を、プルーフ・オブ・ワークを待っているトランザクションのプール１５４に加えることを意味する。それが転送ノード１０４Ｆである場合に、転送ノード１０４Ｆは、トランザクションＴｘ_１をネットワーク１０６内の１つ以上のノード１０４へ転送して、それがネットワークにわたって伝播されるようにする。Ｔｘ_１が妥当性確認されて、ブロックチェーン１５０に含まれると、これにより、Ｔｘ_０からのＵＴＸＯ_０は使用済みとして定義される。Ｔｘ_１は、それが未使用トランザクション出力２０３として使用される場合にのみ有効であることができる点に留意されたい。他のトランザクション１５２によって既に使用されている出力を使用しようと試みる場合には、Ｔｘ_１は、他の全ての条件が満足される場合でさえ無効となる。従って、ノード１０４はまた、前のトランザクションＴｘ_０における参照されたＵＴＸＯが既に使用されているか（他の有効なトランザクションへ有効な入力を既に形成しているか）どうかもチェックする必要がある。これは、ブロックチェーン１５０が予め定義された順序をトランザクション１５２に課すことが重要である１つの理由である。特に、所与のノード１０４は、どのトランザクション１５２内のどのＵＴＸＯ２０３が使用されているかをマークする別個のデータベースを保持することができるが、最終的に、ＵＴＸＯが使用されているかどうかを定義するものは、それがブロックチェーン１５０内の他の有効なトランザクションへの有効な入力を既に形成しているかどうかである。

【0073】

ＵＴＸＯベースのトランザクションモデルでは、所与のＵＴＸＯは、全体として使用される必要がある点に留意されたい。それは、ＵＴＸＯで定義されている量の一部分を、他の部分が使用されている間に使用されるものとして「残しておく」ことはできない。しかし、ＵＴＸＯからの量は、次のトランザクションの複数の出力間で分割可能である。例えば、Ｔｘ_０内のＵＴＸＯ_０で定義されている量は、Ｔｘ_１内の複数のＵＴＸＯの間で分割され得る。従って、アリスが、ＵＴＸＯ_０で定義されている量の全てをボブに与えたくない場合には、彼女は、残りを使用してＴｘ_１の第２出力で彼女自身にチェンジ（change）を与えるか、あるいは、別のパーティに支払うことができる。

【0074】

実際に、アリスは、通常、勝者マイナのためのフィーを含めることも必要になる。これは、今日、ジェネレーショントランザクションの見返りが、通常、マイニングを動機付けるのに十分でないからである。アリスがマイナのためのフィーを含めない場合には、Ｔｘ_０は、マイナノード１０４Ｍによって拒絶される可能性があり、従って、技術的に有効だとしても、それは依然として伝播されず、ブロックチェーン１５０に含まれないことになる（マイナプロトコルは、マイナ１０４Ｍが望まない場合にトランザクション１５２を受け入れるようマイナ１０４Ｍに強制しない）。いくつかのプロトコルで、マイニングフィーは、それ自体の別個の出力２０３を必要としない（すなわち、別個のＵＴＸＯは不要である）。代わりに、入力２０２によって指し示されている総量と、所与のトランザクション１５２の出力２０３で指定されている総量との間の如何なる差も、勝者マイナ１０４Ｍに自動的に与えられる。例えば、ＵＴＸＯ_０へのポインタは、Ｔｘ_１への唯一の入力であり、Ｔｘ_１は、ただ１つの出力ＵＴＸＯ_１しか有していない。ＵＴＸＯ_０で指定されているデジタルアセットの量が、ＵＴＸＯ_１で指定されている量よりも多い場合には、差は勝者マイナ１０４Ｍに自動的に行く。代替的に、又は追加的に、しかしながら、マイナフィーがトランザクション１５２のＵＴＸＯ２０３のうちのそれ自身の１つで明示的に指定され得ることは必ずしも除外されない。

【0075】

所与のトランザクション１５２の全ての出力２０３で指定されている総量が、その全ての入力２０２によって指し示されている総量よりも多い場合には、これは、ほとんどのトランザクションモデルでの無効性のもう１つの基準である。従って、そのようなトランザクションは、伝播も、ブロック１５１内にマイニングもされない。

【0076】

アリス及びボブのデジタルアセットは、ブロックチェーン１５０内のどこでも、どのトランザクション１５２でも彼らにロックされている未使用ＵＴＸＯから成る。従って、通常、所与のパーティ１０３のアセットは、ブロックチェーン１５０にわたって様々なトランザクション１５２のＵＴＸＯにわたって散らばっている。所与のパーティ１０３の合計残高を定義する１つの番号は、ブロックチェーン１５０のどこにも保存されていない。クライアントアプリケーション１０５におけるウォレット機能の役割は、各々のパーティにロックされており、他の以降のトランザクションでまだ使用されていない全ての様々なＵＴＸＯの値を一緒に照合することである。それは、保存ノード１０４Ｓのいずれか、例えば、各々のパーティのコンピュータ機器１０２へ最も近く又は最も良く接続されている保存ノード１０４Ｓ、で保存されているブロックチェーン１５０のコピーをクエリすることによって、これを行うことができる。

【0077】

スクリプトコードは、しばしば、概略的に（すなわち、厳密な言語でなく）表現される点に留意されたい。例えば、［Ｃｈｅｃｋｓｉｇ Ｐ_Ａ］＝ＯＰ＿ＤＵＰ ＯＰ＿ＨＡＳＨ１６０＜Ｈ（Ｐ_Ａ）＞ＯＰ＿ＥＱＵＡＬＶＥＲＩＦＹ ＯＰ＿ＣＨＥＣＫＳＩＧを意味するよう［Ｃｈｅｃｋｓｉｇ Ｐ_Ａ］が記述され得る。「ＯＰ＿・・・」は、スクリプト言語の特定のオペコードを指す。ＯＰ＿ＣＨＥＣＫＳＩＧ（「Ｃｈｅｃｋｓｉｇ」とも呼ばれる）は、２つの入力（署名及びパブリックキー）を取り、楕円曲線デジタル署名アルゴリズム（Elliptic Curve Digital Signature Algorithm，ＥＣＤＳＡ）を用いて署名の有効性を検証するスクリプトオペコードである。ランタイム時に、署名（‘ｓｉｇ’）の如何なる発生も、スクリプトから除かれるが、ハッシュパズルなどの追加の要件は、‘ｓｉｇ’入力によって検証されたトランザクションにとどまる。他の例として、ＯＰ＿ＲＥＴＵＲＮは、トランザクション内のメタデータを保存し、それによって、ブロックチェーン１５０に不変にメタデータを記録することができるトランザクションの使用不可能な出力を生成するためのスクリプト言語のオペコードである。例えば、メタデータは、ブロックチェーンに保存することが望まれる文書を有してもよい。

【0078】

署名Ｐ_Ａはデジタル署名である。実施形態において、これは、楕円曲線ｓｅｃｐ２５６ｋ１を用いたＥＣＤＳＡに基づく。デジタル署名は、特定のデータ片に署名する。実施形態において、所与のトランザクションについては、署名は、トランザクション入力の部分と、トランザクション出力の全て又は部分とに署名することになる。それが署名する出力の特定の部分は、ＳＩＧＨＡＳＨフラグに依存する。ＳＩＧＨＡＳＨフラグは、どの出力が署名されるかを選択するよう署名の最後に含まれ（て、署名する時点で修正され）る４バイトコードである。

【0079】

ロッキングスクリプトは、各々のトランザクションがロックされるパーティのパブリックキーをそれが有するという事実を参照して、時々「ｓｃｒｉｐｔＰｕｂＫｅｙ」と呼ばれる。アンロッキングスクリプトは、それが対応する署名を供給するという事実を参照して、時々「ｓｃｒｉｐｔＳｉｇ」と呼ばれる。しかし、より一般的に、ＵＴＸＯが精算されるための条件が、署名を認証することを有することは、ブロックチェーン１５０の全てのアプリケーションにおいて必須ではない。より一般的に、スクリプト言語は、いずれかの１つ以上の条件を定義するために使用され得る。従って、より一般的な用語「ロッキングスクリプト」及び「アンロッキングスクリプト」が好まれ得る。

【0080】

図３は、ブロックチェーン１５０を実装するシステム１００を示す。システム１００は、追加の通信機能性が含まれることを除いて、図１に関して記載されているものと略同じである。アリス及びボブのコンピュータ機器１０２ａ、１０２ｂの夫々でのクライアントアプリケーションは、追加の通信機能性を夫々有している。すなわち、それは、アリス１０３ａが（どちらかのパーティ又はサードパーティの扇動で）ボブ１０３ｂと別個のサイドチャネル３０１を確立することを可能にする。サイドチャネル３０１は、Ｐ２Ｐネットワークとは別にデータの交換を可能にする。かような通信は、「オフチェーン」と時々呼ばれる。例えば、これは、パーティの１つがトランザクション１５２をネットワーク１０６へブロードキャストすることを選択するまで、トランザクションが（まだ）Ｐ２Ｐネットワーク１０６に公開されないか又はチェーン１５０にたどり着かない状態で、アリスとボブとの間でトランザクション１５２を交換するために使用され得る。そのようなサイドチャネル３０１は、例えば、「ペイメントチャネル」として時々使用される。

【0081】

サイドチャネル３０１は、Ｐ２Ｐオーバーレイネットワーク１０６と同じパケット交換ネットワーク１０１を介して確立され得る。代替的に、又は追加的に、サイドチャネル３０１は、モバイルセルラーネットワーク、又はローカルワイヤレスネットワークなどのローカルエリアネットワーク、又はアリス及びボブのデバイス１０２ａ、１０２ｂの間の直接的な有線若しくは無線リンクなどの異なるネットワークを介して確立されてもよい。一般に、本明細書中のどこかで言及されているサイドチャネル３０１は、「オフチェーン」で、すなわち、Ｐ２Ｐオーバーレイネットワーク１０６とは別個に、データを交換する１つ以上のネットワーキング技術又は通信媒体を介したいずれかの１つ以上のリンクを有してもよい。１よりも多いリンクが使用される場合に、オフチェーンリンクのバンドル又は集合は全体として、サイドチャネル３０１と呼ばれ得る。従って、アリス及びボブがサイドチャネル３０１を介して特定の情報又はデータ片などを交換すると言われる場合に、これは必ずしも、これら全てのデータ片が、厳密に同じリンク又は同じタイプのネットワークを介して送られる必要があることを意味しているわけではないことに留意されたい。

【0082】

［定義例］
以下は、いくつかの実施で採用され得るいくつかの定義の例である。これらは全てが、全ての可能な実施に対する限定であるわけではなく、特定の可能な実施の理解を助けるためにのみ与えられており、例えば、後述される使用ケースの例のいくつかの可能な実施で用いられ得ることに留意されたい。

【0083】

定義１：トランザクション。トランザクションは、入力及び出力を含むメッセージである。それはまた、プロトコルバージョン番号及び／又はロックタイムを有してもよい。プロトコルバージョンは、トランザクションプロトコルのバージョンを示す。ロックタイムは、後に別途説明される。

【0084】

定義２：入力。トランザクションの入力は、順序付きリストを形成する。リスト内の各エントリは、アウトポイント（未使用トランザクション出力に対する識別子）及びｓｃｒｉｐｔＳｉｇ（アンロッキングスクリプト）を有する。それはまた、シーケンス番号を有してもよい。

【0085】

定義３：出力。トランザクションの出力は、順序付きリストを形成する。リスト内の各エントリは、値（その基本単位でのデジタルアセットの量）及びｓｃｒｉｐｔＰｕｂＫｅｙ（ロッキングスクリプト）を有する。

【0086】

定義４：アウトポイント。アウトポイントは、トランザクション識別子ＴｘＩＤ及びインデックス番号ｉによって一意に定義される。それは、未使用トランザクション出力（ＵＴＸＯ）の一意の位置を与える、トランザクションＴｘＩＤの出力におけるｉ番目のエントリを参照する。ここで「未使用」（unspent）という用語は、アウトポイントが如何なる有効な後続トランザクションでも決して現れていないことを意味する。

【0087】

定義５：ｓｃｒｉｐｔＳｉｇ。これは、所与のアウトポイントに対応するＵＴＸＯをアンロック又は使用するために必要とされる情報である。標準トランザクションでは、この情報は、通常は、ＥＣＤＳＡ署名である。従って、スクリプトは「ｓｃｒｉｐｔＳｉｇ」と呼ばれる。しかし、アウトポイントをアンロックするための必要な情報は、ＵＴＸＯのロッキング条件を満足する如何なるデータであることもできる。

【0088】

定義６：ｓｃｒｉｐｔＰｕｂＫｅｙ。これは、特定のＵＴＸＯに関連したファンドをロックするスクリプトである。ｓｃｒｉｐｔＳｉｇがｓｃｒｉｐｔＰｕｂＫｅｙに付け加えられて、結合されたスクリプトの実行がＴＲＵＥを与える場合かつその場合に限り、ファンドはアンロックされて使用され得る。これが当てはまらない場合には、トランザクションは無効であり拒絶されることになる。それは、一般的に、標準トランザクションのためのＥＣＤＳＡパブリックキーのハッシュ値を含むので、「ｓｃｒｉｐｔＰｕｂＫｅｙ」と呼ばれる。

【0089】

次の定義では、１つ以上の入力に署名することが参照される場合に、これは、ｓｃｒｉｐｔＳｉｇ部分を除く１つ以上の入力に署名することを意味する（定義２を参照）。

【0090】

定義７：ＳＩＧＨＡＳＨフラグ。ＥＣＤＳＡ署名を与える場合に、次のＳＩＧＨＡＳＨフラグのうちの１つを付け加えることも必要である。

【表1】

【0091】

特徴として可鍛性（malleability）について話題にする場合に、ＥＣＤＳＡ署名によって署名されていないトランザクション内の情報が期待される。署名されるべきメッセージから除かれ得る入力及び出力は別として、ｓｃｒｉｐｔＳｉｇの内容は常に除かれる。これは、ｓｃｒｉｐｔＳｉｇが署名のプレースホルダーであるよう設計されているからである。

【0092】

定義８：ブロックチェーンタイムロック。一般に、トランザクションで使用可能なタイムロックには、絶対タイムロック及び相対タイムロックの２タイプがある。絶対タイムロックは、特定の時点を指定し、その時点の後で何かが「有効」と見なされ得る。一方、相対タイムロックは、何かが有効と見なされ得る前に経過しなければならない期間を指定する。いずれかの場合にも、ブロックチェーンタイムロックを使用する場合に、時間のプロキシとして、ブロック高さ（マイニングされるブロックの数）又は経過時間（例えば、ＵＮＩＸ（登録商標）時間）のどちらかを使用することができる。

【0093】

ブロックチェーンタイムロックのもう１つの特性は、それらがどこで現れるか、及びそれらがトランザクションのどの側面に適用されるか、である。この意味でタイムロックにはやはり２つの分類がある。トランザクション全体をロックするトランザクションレベル、及び特定の出力をロックするスクリプトレベルである。それらのタイムロックレベルのどちらも、絶対又は相対タイムロックのどちらかを実装するために使用され得る。以下の表は、これらの特性に基づき生成され得るタイムロックを実装するための４つの可能なメカニズムをまとめたものである。

【表2】

【0094】

定義９：ｎＬｏｃｋｔｉｍｅ：ロックタム（ｎＬｏｃｋｔｉｍｅ）は、ブロックの高さ又はＵｎｉｘ時間での特定の時間を表す非負整数である。それは、指定されたブロック又は指定された時間の後にのみトランザクションが加えられ得るという意味で、トランザクションレベルのタイムロックである。ｎＬｏｃｋｔｉｍｅが５００，０００，０００未満であるようセットされる場合には、それはブロック高さと見なされる。それが５００，０００，０００以上であるようセットされる場合には、それはＵｎｉｘ時間の表示と見なされる。それは、１９７０年１月１日の００：００：００より後の秒数である。

【0095】

例えば、現在の最も高いブロックが３，０００，０００の高さであり、ロックタイムが４，０００，０００であるようセットされる場合には、トランザクションは、４百万番目のブロックがマイニングされるまでマイナによって考慮されない。

【0096】

定義１０：ｎＳｅｑｕｅｎｃｅ。シーケンス番号（ｎＳｅｑｕｅｎｃｅ）は、メッセージとしてトランザクションのバージョンを示す。トランザクションが変更されると、シーケンス番号は大きくなる。ｎＳｅｑｕｅｎｃｅの最大値は２^３２－１であり、一般に、シーケンス番号は、トランザクションが終了していることを示すようデフォルトでこの最大値にセットされる。ｎＳｅｑｕｅｎｃｅ値は、トランザクションの入力ごとに定義され、入力によって参照されたＵＴＸＯが、それが有効な入力として使用され得る前にブロックに含まれた後の期間を指定する。マイナが同じ入力を有する２つのトランザクションを確認する場合に、マイナは、より大きいシーケンス番号を有しているトランザクションを選択する。しかし、この特徴は、一般的には無効にされている。

【0097】

定義１１：ＣｈｅｃｋＬｏｃｋＴｉｍｅＶｅｒｉｆｙ（ＯＰ＿ＣＬＴＶ）。オペコードＯＰ＿ＣＨＥＣＫＬＯＣＫＴＩＭＥＶＥＲＩＦＹ（ＯＰ＿ＣＬＴＶ）は、トランザクションの特定のブロックを将来のある特定の時間又はブロック高さにロックするために使用され得る絶対的なスクリプトレベルのタイムロックである。ＵＴＸＯがトランザクションで参照されている現在のＵｎｉｘ時間又はブロック高さが、ＵＴＸＯが生成されたＵｎｉｘ時間又はブロック高さに、ＯＰ＿ＣＬＴＶオペコードの前に指定されているパラメータをプラスしたものによって越えられる場合には、使用中のトランザクションのスクリプト実行は失敗する。

【0098】

定義１２：ＣｈｅｃｋＳｅｑｕｅｎｃｅＶｅｒｉｆｙ（ＯＰ＿ＣＳＶ）。オペコードＯＰ＿ＣＨＥＣＫＳＥＱＵＥＮＣＥＶＥＲＩＦＹ（ＯＰ＿ＣＳＶ）は、将来の特定の期間又はブロック数の間にトランザクションの特定の出力をロックするために使用される相対的なスクリプトレベルのタイムロックである。これは、ＯＰ＿ＣＬＴＶと同様に動作するが、ＯＰ＿ＣＳＶに与えられるパラメータが相対時間を表す点で相違する。ＵＴＸＯがトランザクションで参照されている現在のＵｎｉｘ時間又はブロック高さが、ＯＰ＿ＣＳＶオペコードの前に指定されているパラメータによって越えられる場合に、使用中のトランザクションのスクリプト実行は失敗する。

【0099】

定義１３：可鍛性（malleability）：一般に、ブロックチェーントランザクションで可能な可鍛性には２つの広いタイプがある。それらのどちらも、入力で与えられている署名を無効にせずにトランザクションの内容が変更されることを可能にする。

【0100】

両方の場合を説明するために、１つの入力と、その入力にある１つの署名と、１つの出力とを有する最初のトランザクションＴｘを考える。

【0101】

タイプ１：スクリプトレベルの可鍛性。このタイプの可鍛性は、スクリプトオペコードＯＰ＿ＣＨＥＣＫＳＩＧでチェックされるべき署名がトランザクション内のいずれの入力のスクリプトフィールドにも署名しないという事実を利用する。この事実は、我々がトランザクションＴｘに対して署名を生成し、トランザクションＴｘ’がＴｘと非同一であるように入力スクリプトを変更し、ブロックチェーンコンセンサスルールの下で同じ署名によって署名された有効なトランザクションメッセージと見なされるＴｘ及びＴｘ’の両方を依然として有することを可能にする。

【0102】

タイプ２：入力及び出力レベルの可鍛性。このタイプの可鍛性は、トランザクションで用いられているＳＩＧＨＡＳＨ ＡＬＬ以外のＳＩＧＨＡＳＨフラグの使用に依存する。トランザクションＴｘが、５つの他のＳＩＧＨＡＳＨフラグの組み合わせのいずれかを使用する入力署名を有している場合に、入力又は出力のどちらかは、署名を変更する必要なしに、両方のトランザクションが、コンセンサスに従って、有効なトランザクションメッセージと見なされるように、非同一のトランザクションＴｘ’を生成するよう加えられ得る。

【0103】

［特徴としての可鍛性］
図４は、現在開示されているスキームの実施形態を実装するクライアントアプリケーション１０５の実施例を表す。クライアントアプリケーション１０５は、トランザクションエンジン４０１及びユーザインターフェース（ＵＩ）レイヤ４０２を有する。トランザクションエンジン４０１は、上述されて更に詳細に簡潔に説明されるスキームに従って、トランザクション１５２を定式化し、トランザクション及び／又は他のデータをサイドチャネル３０１上で受信及び／又は送信し、かつ／あるいは、Ｐ２Ｐネットワーク１０６を通じて伝播されるようトランザクションを送信するために、クライアント１０５の基本的なトランザクション関連機能を実装するよう構成される。いくつかの実施形態で、少なくともボブのクライアント１０５ｂのトランザクションエンジン４０１は、任意に、選択機能の形でアプリケーション機能４０３を有してもよい。選択機能は、２つ以上の異なったバージョンのターゲットトランザクション（「Ｔｘ_ｐ」及び「Ｔｘ_ｐ’」）のどちらが、妥当性のためにＰ２Ｐネットワーク１０６を通じて伝播でされて、ブロックチェーン１５０に記録されるよう、ボブの各々のコンピュータ機器１０２から送信されるべきであるかに関して選択を可能にする（伝播及び記録それら自体は上記のメカニズムによる）。この送信は、ボブのコンピュータ機器１０２ｂからネットワーク１０６の転送ノード１０４Ｆへ直接にターゲットトランザクションを送信することを、又はネットワーク１０６のノード１－４Ｆのうちの１つへ転送されるようアリスの機器１０２ａ若しくはサードパーティの機器へターゲットトランザクションを送信することを有してもよいことにやはり留意されたい。

【0104】

ＵＩレイヤ４０２は、情報を機器１０２のユーザ出力手段を介して各々のユーザ１０３へ出力することと、各々のユーザ１０３から機器１０２のユーザ入力手段を介して入力を受け取ることとを含め、各々のユーザのコンピュータ機器１０２のユーザ入力／出力（Ｉ／Ｏ）手段を介してユーザインターフェースをレンダリングするよう構成される。例えば、ユーザ出力手段は、視覚出力を供給する１つ以上の表示スクリーン（タッチ若しくは非タッチスクリーン）、オーディオ出力を供給する１つ以上のスピーカ、及び／又は触覚出力を供給する１つ以上の触覚出力デバイス、等を有してもよい。ユーザ入力手段は、例えば、１つ以上のタッチスクリーン（出力手段のために使用されるものと同じ又は異なる）の入力アレイ、マウス、トラックパッド若しくはトラックボールのような１つ以上のカーソルベースデバイス、スピーチ若しくは音声入力を受け取る１つ以上のマイクロホン及びは発話音声認識アルゴリズム、手若しくは身体ジェスチャの形で入力を受け取る１つ以上のジェスチャベース入力デバイス、又は１つ以上の機械ボタン、スイッチ、若しくはジョイスティック、等を有してもよい。

【0105】

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

【0106】

図５は、ボブの機器１０２ｂでクライアントアプリケーション１０５ｂのＵＩレイヤ４０２によってレンダリングされ得るユーザインターフェース（ＵＩ）５００
の例のモックアップを与える。実施形態で、ユーザインターフェース５００は、任意に、２つのオンスクリーンボタン又はメニュー内の２つの異なるオプションのような、ユーザ出力手段を介して２つの相異なったＵＩ要素としてレンダリングされ得る少なくとも２つのユーザ選択的なオプション５０１、５０２を有してもよい。ユーザ入力手段は、ユーザ１０３ｂ（この場合に、ボブ）が、例えば、スクリーン上でＵＩ要素をクリック若しくはタッチすること、又は所望のオプションの名称を発声することによって、オプションから１つを選択することを可能にするよう配置される（本明細書で使用される「手動」との用語は、自動と対照をなすことのみを意味し、１つ以上の手の使用に限定しないことに留意されたい）。オプションをレンダリングし選択する特定手段は物質でないことが理解されるだろう。

【0107】

どのような手段を使用する場合でも、オプションの夫々は、第１及び第２のターゲットトランザクションＴｘ_ｐ及びＴｘ_ｐ’に対応する。選択機能４０３は、以下を可能にするためにＵＩレイヤ４０２とインターフェースするように構成される。すなわち、ボブ１０３ｂが第１オプション５０１を選択する場合、これは、トランザクションエンジン４０３に、第１バージョンのターゲットトランザクションＴｘ_ｐを、ネットワーク１０６を通じて伝播してブロックチェーン１５０に登録されるよう送信させる。しかし、ボブ１０３ｂが第２オプション５０２を選択した場合、これは、トランザクションエンジン４０３に、第２バージョンのターゲットトランザクションＴｘ_ｐ’を、ネットワーク１０６を通じて伝播してブロックチェーン１５０に登録されるよう送信させる。図５に示されるＵＩ５００は、図式化されたモックアップにすぎず、実際には、１つ以上の更なるＵＩ要素を有してもよい、簡潔にするために図示されていないことが理解されるだろう。

【0108】

ＵＩオプション５０１、５０２に代わるものとして、又はそれらに加えて、選択機能４０３は、ブロックチェーン１５０での記録のためにターゲットトランザクションの第１及び第２バージョンＴｘ_ｐ及びＴｘ_ｐ’の送信の自動選択を実行するよう構成されてもよい。これは、所定のイベントに応じて又は所定のタイムアウトの後で自動的にトリガされてもよい。例えば、イベントＹがタイムアウト前に起こる場合には、機能４０３は、第２バージョンＴｘ_ｐ’を、ネットワーク１０６を通じて伝播されるよう自動送信する。しかし、イベントＹが起こる前にタイムアウトが経過する場合には、機能４０３は代わりに、第１バージョンＴｘ_ｐを自動送信する。あるいは、イベントＸが起こる場合には、機能４０２は、第１バージョンＴｘ_ｐを、ネットワーク１０６を通じて伝播されるよう自動送信するが、イベントＹが起こる場合には、機能４０３は代わりに、第２バージョンＴｘ_ｐ’を自動送信する。実際に、第１及び第２バージョンをネットワーク１０６へ自動的に送信するための状況は、システム設計者によって事実上どうにでも構成され得る。

【0109】

図６は、本明細書で開示されている実施形態に従う仕様のためのトランザクション１５２の組を表す。組は、０番目のトランザクションＴｘ_０と、第１トランザクションＴｘ_ｉ（その複数のインスタンスｉ＝１，２，３，・・・が存在する）と、第２トランザクション（その１つ以上のバージョンＴｘ_ｐ又はＴｘ_ｐ’が存在する）とを有する。「０番目」、「第１」、及び「第２」は、単に便宜上のラベルであることに留意されたい。それらは必ずしも、それらのトランザクションがブロック１５１又はブロックチェーン１５０で次々に直ぐに配置されることも、０番目のトランザクションがブロック１５１又はブロックチェーン１５０で最初のトランザクションであることも示しているわけではない。また、それらのラベルは、それらのトランザクションがネットワーク１０６へ送信される順序に関して必ずしも何かを示しているわけでもない。それらは、１つのトランザクションの出力が次のトランザクションの入力によって指し示されるという点で、論理的な連続を単に指す。いくつかのシステムでは、親をその子の後にネットワーク１０６へ送ることが可能であることに留意されたい（この場合に、「孤立した」子は、親が到着するのを待つ間、１つ以上のノード１０４で一定期間バッファリングされる）。

【0110】

０番目のトランザクションＴｘ_０は、アリス１０３ａにロックされているデジタルアセットの量のソースとして働く点で、現在の目的のためにソーストランザクションとも呼ばれ得る。第１トランザクションＴｘ_ｉは、ソーストランザクションＴｘ_０からのデジタルアセットの量を条件付きで転送する仲介人として働く点で、現在の目的のために仲介トランザクション又は条件付きトランザクションとも呼ばれる。第２トランザクションは、条件の１つをアンロックしてボブ（あるいは、場合により、ボブが代理を務める受益者）のためのペイメントを運ぶトランザクションであるということで、ターゲットトランザクション又はペイメントトランザクション（従って、添え字「ｐ」）とも呼ばれ得る。実施形態で、ターゲットトランザクションは、少なくとも２つの可能なバージョン、第１バージョンＴｘ_ｐ及び第２バージョンＴｘ_ｐ’を有する。これらのトランザクションは夫々、少なくともある時点で存在することができ、アリス（第１パーティ）のコンピュータ機器１０２ａ、若しくはボブ（第２パーティ）のコンピュータ機器１０２ｂ、若しくは、サードパーティの機器（図示せず）、又はそれらの任意の組み合わせのどれかで現れる。２つのバージョンＴｘ_ｐ及びＴｘ_ｐ’は、同時に一緒に、又は次々に、又は時間において部分的に重なって、一定期間存在することができる。

【0111】

図６に示されるように、ソーストランザクションＴｘ_０は、デジタルアセットの量を指定する少なくとも１つの出力２０３_０（例えば、Ｔｘ_０の出力０）を有し、出力は、更に、個の出力をアリスと１０３ａにロックするロッキングスクリプトを有する。これは、ソーストランザクションＴｘ_０のロッキングスクリプトが、少なくとも１つの条件が満足されることを求めていることを意味する。条件は、出力をアンロックしようとしている（従って、デジタルアセットのその量を精算しようとしている）如何なるトランザクションの入力もそのアンロッキングスクリプトでアリスとの暗号署名（すなわち、アリスのパブリックキーを使用する）を含まなければならない、ことである。この意味で、Ｔｘ_０の出力で定義されている量は、アリスによって所有されていると言われることがある。どの先行トランザクションのどの出力をＴｘ_０の入力が指し示しているかは、（それらがＴｘ_０の合計出力をカバーするのに十分である限りは）特に重要ではない。

【0112】

この場合に、ソーストランザクションＴｘ_０の出力をアンロックするトランザクションは、第１の、すなわち、仲介トランザクションＴｘ_ｉのインスタンスである。従って、Ｔｘ_ｉは、Ｔｘ_０の関連出力（表されている例では、Ｔｘ_０の出力０）へのポインタを有する少なくとも１つの入力２０２_１（例えば、Ｔｘ_ｉの入力０）を有している。入力は更に、アリスの少なくとも署名を必要とする、その出力のロッキングスクリプトで定義されている条件に従って、Ｔｘ_０の指し示されている出力をアンロックするよう構成されたアンロッキングスクリプトを有する。Ｔｘ_０のロッキングスクリプトによってアリスに要求された署名は、Ｔｘ_ｉのある部分に署名するために必要とされる。いくつかのプロトコルで、署名される必要があるＴｘ_ｉの部分は、Ｔｘ_ｉのアンロッキングスクリプトで定義されている設定であることができる。例えば、これは、署名に付け加えられている１バイトであるＳＩＧＨＡＳＨフラグによってセットされてもよく、故に、データに関して、アンロッキングスクリプトは、＜Ｓｉｇ Ｐ_Ａ＞＜ｓｉｇｈａｓｈｆｌａｇ＞＜Ｐ_Ａ＞と現れる。代替的に、署名される必要がある部分は、単純に、Ｔｘ_ｉの固定部分であることができる。いずれにしても、署名される部分は、通常は、アンロッキングスクリプト自体を除き、そして、Ｔｘ_ｉの入力の一部又は全てを除いてもよい。これは、Ｔｘｉの入力が可鍛性であることを意味する。

【0113】

第１の又は仲介トランザクションＴｘ_ｉは、少なくとも１つの出力２０３１（例えば、Ｔｘ_ｉの出力０であり、やはり出力はＵＴＸＯと呼ばれ得る）を有する。仲介トランザクションＴｘ_ｉの出力は、どのパーティにも無条件にはロックされない。Ｔｘ_０のように、それは、前方へ転送されるべきデジタルアセットの量を指定する少なくとも１つの出力（例えば、Ｔｘ_ｉの出力０）を有し、出力は更に、その出力をアンロックし、従ってこの量を精算するために必要とされるものを定義するロッキングスクリプトを有する。しかし、実施形態において、このロッキングスクリプトは、その出力が、少なくともｉ）第１条件（「条件１」）及びｉｉ）第２条件（「条件２」）を含む複数の異なった可能な条件おうちのいずれか１つに基づきアンロックされることを可能にし得る。

【0114】

第２の、ターゲットトランザクションＴｘ_ｐ／Ｔｘ_ｐ’は、Ｔｘ_ｉの上記の出力（示される例では、Ｔｘ_ｉの出力０）へのポインタを有し、更には、Ｔｘ_ｉのその出力を、Ｔｘ_ｉのロッキングスクリプトで定義されている１つ以上の条件のうちの１つを満足することに基づいてアンロックするよう構成されたアンロッキングスクリプトを有する少なくとも１つの入力２０２ｐ（例えば、Ｔｘ_ｐ／Ｔｘ_ｐ’の入力０）を有する。例えば、ターゲットトランザクションの第１バージョンＴｘ_ｐで、アンロッキングスクリプトは、第１条件、条件１を満足するよう構成される。ある時点で、ターゲットトランザクションの第２バージョンは、それから、例えば、書き換え（malleation）によって、Ｔｘｐから生成されることがある。第２バージョンで、アンロッキングスクリプトは、第２条件、条件２を満足するよう構成される。

【0115】

第２の、ターゲットトランザクションＴｘ_ｐ／Ｔｘ_ｐ’は、いずれのバージョンでも、ボブに転送すべきデジタルアセットの量と、これをボブにロックするロッキングスクリプトとを有する少なくとも１つの出力２０２_ｐ（例えば、Ｔｘ_ｐ／Ｔｘ_ｐ’の出力０）を有する（すなわち、それは、アンロッキングスクリプトでボブの署名を含む更に先のトランザクションを実行する必要がある）。この意味で、ターゲットトランザクションＴｘ_ｐ／Ｔｘ_ｐ’の出力は、ボブによって所有されていると言われる。この出力はやはりＵＴＸＯと呼ばれ得る。

【0116】

実施形態で、第１条件は、Ｔｘ_ｉをアンロックしようとしているどのトランザクション（実施形態では、ターゲットトランザクションの第１バージョンＴｘ_ｐ）のアンロッキングスクリプトも、そのアンロッキングスクリプトにおいてボブの暗号署名、及び／又はボブが供給するか若しくは含める必要があるボブのデータであることができるデータペイロードを含む、ことを求める。データペイロードを含むという要件は、Ｔｘ_ｉのロッキングスクリプトに含まれているハッシュチャレンジによって課され得る。チャレンジは、（アンロッキングスクリプトとともにノード１０４で実行される場合に）対応するアンロッキングスクリプトで与えられているデータのハッシュがロッキングスクリプトで与えられているハッシュ値に等しいかどうかをテストするように構成されているスクリプト片とともに、データのハッシュ（データ自体ではない）を有する。署名に対する要件は、例えば、上述されたＣｈｅｃｋＳｉｇによって、課され得る。実施形態で、第１条件は、アリスの署名がＴｘ_ｐのアンロッキングスクリプトに含まれることを求めない。ボブによって署名される必要があるＴｘ_ｐの部分は、Ｔｘ_ｐのアンロッキングスクリプトの設定であってよく（例えば、ＳＩＧＨＡＳＨフラグによって指定される）、あるいは、固定であってもよい。いずれにしても、それは、少なくともアンロッキングスクリプトを除く。従って、Ｔｘ_ｐのアンロッキングスクリプトは可鍛性である。

【0117】

実施形態で、第２条件は、Ｔｘ_ｉをアンロックしようとしているどのトランザクション（実施形態では、ターゲットトランザクションの第２バージョンＴｘ_ｐ’）のアンロッキングスクリプトも、そのアンロッキングスクリプトにおいてボブの暗号署名及びアリスの暗号署名を含む、ことを求める。やはり、これは、例えば、ＣｈｅｃｋＳｉｇによって課され得る。実施形態で、第２条件は、データペイロードがＴｘ_ｐ’のアンロッキングスクリプトに含まれることを求めない。アリス及びボブによって署名される必要があるＴｘ_ｐ’の部分は、Ｔｘ_ｉのアンロッキングスクリプトの設定であってよく（例えば、ＳＩＧＨＡＳＨフラグによって指定される）、あるいは、固定であってもよい。

【0118】

０番目の（すなわち、ソース）トランザクションＴｘ_０は、アリス、ボブ、又はサードパーティによって生成され得る。それは、通常は、Ｔｘ_０の入力で定義されている量をアリスが取得した前のパーティの署名を必要とする。それは、アリス、ボブ、前のパーティ、又は他のサードパーティによってネットワーク１０６へ送信され得る。

【0119】

第１の（すなわち、仲介、条件付き）トランザクションＴｘ_ｉも、アリス、ボブ、又はサードパーティによって生成され得る。実施形態で、それはアリスの署名を必要とするので、アリスによって生成されてもよい。代替的に、それは、テンプレートとしてボブ又はサードパーティによって生成されて、署名すべきアリスへ送信されてもよい（例えば、サイドチャネル３０１上で送信される）。アリスは、次いで、署名されたトランザクションをネットワーク１０６へ彼女自身が送信することも、あるいは、それをボブ又はサードパーティへ、彼らがネットワーク１０６へ転送するために送信することも、あるいは、単に彼女の署名を、ボブ又はサードパーティが署名されたＴｘ_ｉに組み込んでネットワーク１０６へ転送するために送信することもできる。やはり、Ｔｘ_ｉをネットワーク１０６へ送る前のオフチェーンでの如何なるやりとりも、サイドチャネル３０１上で実行されてよい。

【0120】

第２の（すなわち、ターゲット又はペイメント）トランザクションのどちらのバージョンＴｘ_ｐ／Ｔｘ_ｐ’も、アリス、ボブ、又はサードパーティによって生成され得る。第１バージョンはボブの署名及び／又はデータを必要とするということで、それはボブによって生成されてもよい。代替的に、それは、テンプレートとしてアリス又はサードパーティによって生成され、それからボブへ、署名してデータを加えるために送信されてもよい（例えば、サイドチャネル３０１上でボブへ送信される）。ボブは、次いで、署名されたトランザクションをネットワーク１０６へ彼自身が送信することも、あるいは、それをアリス又はサードパーティへ、彼らがネットワーク１０６へ転送するために送信することも、あるいは、単に彼の署名及びデータを、アリス又はサードパーティが署名されたＴｘ_ｐに組み込んでネットワークへ転送するために送信することもできる。実施形態で、第２バージョンはボブ及びアリスの両方の署名を必要とする。従って、それは、テンプレートとしてアリス又はボブによって生成され、他方へ、彼らの署名を加えるために、例えば、やはりサイドチャネル３０１上で、テンプレートとして送られてもよい。代替的に、それは、テンプレートとしてサードパーティによって生成され、それからアリスへ送信されてもよく、アリスは、彼女の署名を加え、ボブへ、彼の署名を加えるために転送する。ボブは、次いで、署名されたトランザクションをネットワーク１０６へ転送するか、あるいは、アリス又はサードパーティへ、彼らがネットワーク１０６へ転送するために返送する。あるいは、Ｔｘ_ｐ’は、サードパーティによってテンプレートとして生成され、それからボブへ送信されてもよく、ボブは、彼の署名を加え、アリスへ、彼女の署名を加えるために転送する。アリスは、次いで、署名されたトランザクションをネットワーク１０６へ転送するか、あるいは、ボブ又はサードパーティへ、彼らがネットワーク１０６へ転送するために返送する。更なる変形例では、アリス及び／又はボスは、受け取ったトランザクションテンプレートに署名し、単に彼らの署名を他方のパーティの１つへ、そのパーティがＴｘ_ｐ’に組み込んでネットワーク１０６へ転送するために、返す。やはり、Ｔｘ_ｐ及び／又はＴｘ_ｐ’をネットワーク１０６へ送る前のオフチェーンでの如何なるやりとりも、サイドチャネル３０１上で実行されてもよい。

【0121】

トランザクションの異なる要素が生成されて組み込まれ得る様々な場所、及びそれが直接に又は身代わりでＰ２Ｐネットワーク１０６の最終的な送り先へ送信される様々な方法があることが理解されるだろう。開示されている技術の実施の範囲は、これらの点のいずれにおいても限定されない。

【0122】

また、「アリスによって」、「ボブによって」及び「サードパーティによって」等の本明細書中の表現は、夫々、「アリス１０３ａのコンピュータ機器１０２ａによって」、「ボブ１０３ｂのコンピュータ機器１０２ｂによって」及び「サードパーティのコンピュータ機器によって」に対する短縮として使用され得ることも理解されるだろう。また、所与のパーティの機器は、そのパーティによって使用される１つ以上のユーザデバイス、又はそのパーティによって用いられるクラウドリソース等のサーバリソース、又はそれらの任意の組み合わせを有してもよい。それは、必ずしも、動作を、単一のユーザデバイスで実行されることに限定するものではない。

【0123】

ターゲットトランザクションＴｘ_ｐのアンロッキングスクリプトは可鍛性であるから、実施形態で、ターゲットトランザクションの第２バージョンＴｘ_ｐ’は、第１バージョンを書き換えること（malleating）、すなわち、Ｔｘ_ｐの既存データを取り、それを、第２バージョンＴｘ_ｐ’を形成するよう変更することによって、この場合には、ロッキングスクリプトを書き換えることによって、生成され得る。これは、スクリプトレベルの可鍛性の例である。同等の変形例では、しかしながら、Ｔｘ_ｐ’は、アンロッキングスクリプトが異なることを除いて同じ構造を有しているターゲットトランザクションの新しいバージョンを作ることによって生成されてもよい。「アップデート」が、既存の構造を書き換えること又は新しい置換バージョンを作ることのどちらかの可能性について記載するための一般的な用語として本明細書では使用されることがある。書き換え（Malleation）は、例として本明細書では様々な実施形態に関連して言及されることがあるが、これは、スクラッチからのターゲットトランザクションの新しいバージョンの生成によって置換されてもよいことが理解されるだろう。いずれの場合にも、書き換え又は新しいバージョンの生成は、アリス及び／又はボブ、かつ／あるいはアリス及び／又はボブの署名を与えられたサードパーティによって、実行されてよい。

【0124】

述べられているように、実施形態で、Ｔｘ_ｉにおいて、第１条件ｉ）は、ボブの署名及びデータペイロードがＴｘ_ｐのアンロッキングスクリプトに含まれることを必要とするが、アリスの署名は不要であり、第２条件ｉｉ）は、アリス及びボブの両者の署名を必要とするが、データペイロードがＴｘ_ｐ’に含まれることは要しない。

【0125】

ターゲットトランザクションＴｘ_ｐは、よって、アリスの署名を必要とせずに、しかし、ボブがアンロッキングスクリプトにデータペイロードを含める場合にのみ、ボブ（又はボブの代理）によって一方的に精算可能である。これは、マイニングするのにより費用がかかることになる。マイナ１０４Ｍは、マイニングのためにトランザクションにアクセスするためにマイニングフィーを必要とする、フィーが不十分である場合には、彼らは、例えばトランザクションが有効であるとしても、ブロック１５１にマイニングするためにトランザクションを受け入れない（有効性及び受任可能性は別の概念である）。マイニングフィーは、データの量（バイト又はキロバイトの数）に関連してトランザクションのサイズと通常は比例する。更に、データペイロードは、ブロックチェーン１５０自体で公に利用可能にしたくないボブの独自のデータであることがある。従って、ボブは、アリスを幸せなままとし、彼女に、彼女の署名を含むターゲットトランザクションの第２の更新されたバージョンＴｘ_ｐ’を提供してもらうことを望む（あるいは、少なくとも彼女の署名を送ってもらい、ボブ又はサードパーティがターゲットトランザクションＴｘｐ’を組み立てる）。これは、ボブが、ターゲットトランザクションＴｘ_ｐ’にデータペイロードを含める必要なしにＴｘ_ｉの出力を精算することを可能にする。しかし、アリスが約束を破る場合には、ボブは、データペイロードがターゲットトランザクションＴｘ_ｐに含まれることを求める、より好ましくない第１条件に基づいて、Ｔｘ_ｉの出力を精算するフォールバックを依然として有している。

【0126】

第１トランザクションＴｘ_ｉは、実際にはソーストランザクションも、ブロックチェーン１５０での記録のためにネットワーク１０６へブロードキャストされる必要がある。これは、それらが全てある段階で最終的に妥当性確認される限りは、如何なるパーティによってもいつでも行われ得る。

【0127】

Ｔｘ_ｉのロッキングスクリプトにおける第１条件の要件は、データペイロード自体がＴｘ_ｉのロッキングスクリプトに含まれることも、Ｔｘ_ｉがアリスによって定式化される場合でさえ、アリスによって知られていることも求めないことに留意されたい。むしろ、それは、データペイロードのハッシュが（ノード１０４でハッシュ化される場合に、アンロッキングスクリプト内のハッシュ値と一致するデータを提供するよう、Ｔｘ_ｐのアンロッキングスクリプトに調整するスクリプトとともに）Ｔｘ_ｉのロッキングスクリプトに含まれることをしか求めない。従って、たとえアリスと又はサードパーティがＴｘ_ｉを定式化するとしても、ボブは、彼のデータのハッシュを彼らに与えさえすればよく、データ自体を与える必要はない。データを自体を与えるのは、彼がデータを公開する必要があるチェーンに彼がターゲットトランザクションＴｘ_ｐの第１バージョンを公開する必要がある場合のみである。

【0128】

いくつかの実施形態で、Ｔｘｉのロッキングスクリプトは、第１及び第２の両方の条件に対する代案として、第３のアンロッキング条件を含んでもよい。第３条件は、ロックタイムが経過しており、かつ、アリスの署名がターゲットトランザクションの第３バージョンＴｘ_ｐ”のアンロッキングスクリプトに含まれていることを求めてもよい。これは、ボブが第１及び第２条件のどちらかに基づいてペイメントを請求していない場合に（例えば、ボブが、時間制限内にそうすることできないか又は処理に全く関わっていないため）、アリスがＴｘ_ｉの出力から彼女のペイメントを取り戻すことを可能にする。ロックタイムは、絶対的な時点、又は経過すべき時間（例えば、秒で又はマイニングされたブロックの数で測定される）として定義され得る。

【0129】

本開示のために、第１トランザクション及び異なるバージョンのターゲットトランザクションにおける異なる代替条件の使用は、任意の付加的なセキュリティ手段であることが理解されるだろう、それらは、ストリーミング及びマイクロペイメントメカニズムを実装するのに有利であるが必須ではない。これらの実施形態について、これより、更に詳細に説明する。

【0130】

［ストリーミング及びマイクロペイメントチャネル］
図７を参照すると、例えば、アリスは、ボブからあるデータをストリーミングするために支払いたい。データは、ボブからアリスへ「チャンク・バイ・チャンク」で、つまり、部分Ｄ_０、Ｄ_１、Ｄ_２等のシーケンスで転送される。これらは、例えば、アリスがボブからストリーミングしているメデイアコンテンツのアイテムの部分であってよく、例えば、映画等のビデオトラック、及び／又は楽曲などのオーディオトラックを有する。ビデオは、任意の時間変化する画像又はグラフィクス、例えば、映画、テレビ番組、スライドショー又は他のそのようなシーケンス若しくは静止画、アニメーション化されたベクターグラフィクス、及び／又はゲームコンテンツを有してもよい。オーディオは、スピーチ、音楽、ノイズ及び／又は効果、あるいはそのようなものを含む、サンプリングされたオーディオ及び／又は合成されたオーディオを有してもよい。他の例では、次の技術が使用されてもよく、アリスがサービス、例えば、ガス、電気若しくは水道などの公共事業の供給、又は車両、不動産、若しくは他の物理オブジェクトの賃貸に対して「使った分だけ支払う」（pay as she goes）ことを可能にする。サービスに支払う場合に、その場合には、所望のコンテンツ自体の部分であるデータの代わりに、各データ部分Ｄ_０、Ｄ_１、Ｄ_２等は、サービスのユニットをアンロックするために必要な異なった各々のキーを有する。例えば、アリスのガス、電気又は水道供給は、彼女のコンピュータ機器１０２ａへ接続されたスマートメーターによって管理されている。受け取られた各キーにより、彼女は、これを彼女のコンピュータ機器１０２ａから彼女のメーターへ供給し、メーターは、各々のキーを検証することに応答して、公共事業の他のユニットをアンロックする。

【0131】

ボブのペイメントがこれまで受け取られたデータ部分の数に比例するようにデータの部分をストリーミングすることが望ましい。これを行うために、アリスは、各データ部分Ｄ_０、Ｄ_１、Ｄ_２等がボブから受け取られたことに応答して、サイドチャネル３０１上でボブへ各々の署名されたトランザクションＴｘ_１、Ｔｘ_２、Ｔｘ_３等を返すことができる。つまり、ボブがデータの送信を止める場合に、アリスは単純にペイメントの送信を止めることができ、アリスがペイメントの送信を止める場合に、ボブは単純にデータの送信を止めることができ、アリスが支払っていないデータＤの部分はこれ以上与えない。

【0132】

しかし、ストリーミングされるデータの各個別的な部分Ｄ_０、Ｄ_１、Ｄ_２等について個々のトランザクションがネットワーク１０６へブロードキャストされてブロックチェーン１５０に記録される必要がないようにこれを実装することも望ましい。これによりネットワーク輻輳は増大し、ブロックチェーン１５０は膨張するからである。

【0133】

これに対処するために、アリスがボブから受け取る各データ部分Ｄ_０、Ｄ_１、Ｄ_２等に夫々応答してアリスがボブへ返送する各トランザクションＴｘ_１、Ｔｘ_２、Ｔｘ_３等は、同じソーストランザクションＴｘ_０の同じ出力（例えば、同じＵＴＸＯ）を指し示す第１トランザクションの異なるインスタンスである。第１トランザクションの量は毎回増大するので、ボブは単に、ある定義されたシーケンスの終わりに、例えば、オーディオ又はビデオトラックの終わり（例えば、映画の終わり）に、あるいは、指定された期間のサービス（例えば、１時間、１日、１週間、又は１ヶ月に１つ）の終わりに、最後の１つの出力を請求する。これは、更に図７を参照して後で更に詳細に説明される。

【0134】

第１に、ボブが、データを送信しないにもかかわらずアリスからペイメントを得ることによって不正を働くことができないように、第２に、アリスが、データを受け取りながらボブの支払わないことによって不正を働くことができないように、部分をストリーミングすることも望ましい。

【0135】

実施形態において、第１トランザクションの各インスタンスは、その入力によって指し示されているよりも多い量のデジタルアセットに合計でなる複数の出力を有する。つまり、トランザクションは、誰か、実際にはボブが、彼自身の他の入力を加えて差を補うまでは有効でない（入力レベルの可鍛性の例）。これにより、アリスはシーケンスにおいて初期のトランザクションを公開するのを止め、ボブが後のトランザクションを公開するのをブロックする。従って、これは、映画全体などのためのデポジットとして機能する初期ファンディングトランザクションなしでストリーミングを可能にする。これは、図８を参照して後で更に詳細に説明される。

【0136】

ストリーミング方法を実装するために、アリス及びボブは、彼らの間にオフチェーンサイドチャネル３０１を形成する。すなわち、このチャネルを介して送信されるトランザクションは、ブロックチェーン１５０での記録のためにＰ２Ｐネットワークへ（まだ）公開されない。これは、本明細書で「マイクロペイメントチャネル」とも呼ばれる、ペイメントチャネルの変更された形式として使用される。更に、ボブは、シーケンスにおけるデータ部分Ｄ_０、Ｄ_１、Ｄ_２等のためのハッシュセットをアリスに利用可能にする。例えば、ボブは、ペイメントチャネル３０１を介してハッシュセットをアリスに送ってもよく、あるいは、インターネット１０１等でサーバからアクセスするようそれを公に利用可能にしてもよい。ハッシュセットは、アリスが、実際の生（raw）データ自体を前もって知らなくても、データのハッシュチャレンジを作成することを可能にするハッシュの組を有する。例えば、ハッシュセットは、マークル木（Merkle tree）としても知られているハッシュ木を有してもよい（マークル木という用語は、あらゆるハッシュ木を意味するためにその最も広い意味で本明細書では使用され、必ずしも、例えば、２項枝分かれに限定されるわけではないことに留意されたい）。代替的に、ハッシュセットは、ハッシュチェーン又はハッシュリストを有してもよい。

【0137】

ボブは、ペイメントチャネル３０１を介して第１データ部分Ｄ_０をアリスに送ることによって、開始する。この第１部分は、無料で又はつけで送られる。アリスが支払わない場合には、ボブは、第１部分に相当するデータしか失わない。アリスが継続したと望むならば、Ｄ_０を受け取ったことに応答して、彼女は、ペイメントチャネル３０１を介して第１トランザクションの第１インスタンスＴｘ_１をボブに送る。これに応答して、ボブは、シーケンスにおける次のデータ部分Ｄ_１をアリスに送る、次いで、これに応答して、アリスは、第１トランザクションＴｘ_２の第２インスタンスをボブに送り、次いで、ボブはＤ_２をアリスに送り、アリスはＴｘ_３をボブに送り、以降同様に続くが、全てペイメントチャネル３０１を介する。第１トランザクションの各インスタンスＴｘ_１、Ｔｘ_２、Ｔｘ_３等は、ボブへの増大するペイメント（例えば、これまで受け取ったデータ部分Ｄの数とともに線形に増大する）を指定する。しかし、第１トランザクションの各インスタンスＴｘ_１、Ｔｘ_２、Ｔｘ_３等は、アリスの同じＵＴＸＯを指し示す。従って、ボブは、それらのうちの１つにペイメントを請求する第２のターゲットトランザクションの有効なインスタンスＴｘ_ｐ／Ｔｘ_ｐ’しか構成することができない（同じＵＴＸＯを２回精算しようとする如何なる試みも、無効としてネットワーク１０６によって拒絶されることになる）。全てが上手くいくと、ボブは、従って、順番において第１トランザクションの最後のインスタンスにペイメントを請求するターゲットトランザクションのバージョンを作成することになる。

【0138】

実施形態において、第１トランザクションの各インスタンスＴｘ_１、Ｔｘ_２、Ｔｘ_３等又は最後のインスタンスＴｘ_ｎは、（例えば、図５を参照して）上述されたように、そのトランザクションの出力でアリスからのペイメントを精算するための複数の代替条件を定義する。この場合に、シーケンス内の最後のデータ部分Ｄ_ｎのアリスの確認応答Ｔｘ_ｎとともに、彼女は、ターゲットトランザクションの第２バージョンＴｘ_ｐ’も供給し、あるいは、少なくとも、ボブがＴｘ_ｐ’を組み立てることを可能にする彼女の署名を供給する。これにより、ボブは、ボブに不利益をもたらす第１条件ではなく、好ましい第２条件に基づいて、完全なシーケンス（例えば、映画全体）に対するペイメントを請求することが可能にある。ボブが部分Ｄをストリーミングすることを止め、アリスが不満を抱く場合には、彼女は、第２条件を満足するために必要な彼女の署名を提供しなくてもよく、従って、ボブは、第１の、より好ましくない条件に基づいてしかペイメントを請求することができない。他方で、アリスが、途中でそれ以上の部分を要求することを止めたが不満足でない（例えば、彼女が、映画を観るのを止めることを単に選択する）場合には、これまでの第１トランザクションのインスタンスの夫々Ｔｘ_１、Ｔｘ_２、Ｔｘ_３等に複数の代替条件が含まれているとすれば、アリスは、好ましい第２条件に基づいてこれまでのシーケンスに対するペイメントを請求することをボブに可能にするように、Ｔｘ_ｐ’又は彼女の署名を提供し得る。

【0139】

第１トランザクションのインスタンスＴｘ_ｉ（ｉ＝１，２，３，・・・）は、共通のＵＴＸＯを使用するが、異なるメッセージで署名を使用する。従って、これに関連して、インスタンスは、トランザクションのインスタンスとして、アリスからのデータに対する各々の「要求」を参照する（後述される）。これは、値及び要求されたデータを変更することが、署名されたメッセージを変更するからである。

【0140】

第２トランザクションのバージョンＴｘ_ｐ／Ｔｘ_ｐ’は、共通のＵＴＸＯを使用するが、同じメッセージで署名を使用する。従って、これに関連して、バージョンは、トランザクションの各々のバージョンとして、トランザクションの「書き換えられていない」形式及び「書き換えられた」形式を参照する。これは、スクリプトレベルの書き換えが、署名されたメッセージを変更しないからである。

【0141】

注釈：どのパーティが第１トランザクションＴｘ_１・・・並びにターゲットトランザクションの第１及び第２バージョンＴｘ_ｐ／Ｔｘ_ｐ’を生成及び／又はブロードキャストするかに関して上述された変形例のいずれもが、ここで適用されてもよい。例えば、サードパーティは、アリス又はボブの代わりにそれらの一部又は全てを生成及び／又はブロードキャストしてもよく、あるいは、ボブは、Ｔｘ_ｐ／Ｔｘ_ｐ’をネットワークへ彼自身が送っても、又は彼の署名をアリスへ、アリスがターゲットトランザクションＴｘ_ｐ／Ｔｘ_ｐ’等を組み立てるために送ってもよい。便宜上、これらの様々な選択肢は、ここでは完全に再びは繰り返されない。

【0142】

例として、映画産業を考える。スクリプトサイズ制限は、書き込みの時点で１０キロバイトである。従って、映画ごとに、それは多数の８キロバイト部分に分割され得る。部分のサイズは、他の制約が存在する場合には、より一層小さくてもよく、あるいは、スクリプトサイズ制限が増やされる場合には、より大きくてもよい。部分が定義されると、マークル木が次いで構成され得、ルートハッシュが映画タイトルとともに公にリスト化される。

【0143】

簡単のために、説明は、マイニングフィーが暗黙的に適用されると仮定する。明示的な入力が明示的な出力に暗黙的なトランザクションフィーをプラスしたものをカバーすることができない場合には、他の暗黙的な入力があるとする。

【0144】

アリスは、ボブから映画を買おうとしている。映画は、ｎ＋１個のデータパケットＤ_０、・・・、Ｄ_ｎと、ルートハッシュＨ_ｒｏｏｔを有するそれらのマークル木Ｔとによって定義される。方法は、アリスからボブへの一連のトランザクションＴＸ_１、ＴＸ_２、・・・、ＴＸ_ｎを構成する。各トランザクションＴＸ_ｉは、Ｄ_ｉに対する要求と、Ｄ_ｉ－１を受け取ったことの確認応答とに対応する。理想的に、ペイメントチャネル３０１が適切に選択される場合には、ただ２つのトランザクションＴＸ_ｎ’及びＴＸ_ｐ’のみが、アリスからボブへのペイメントを完了するよう公開される。このシナリオは図７に表されている。図７は、アリスとボブとの間のペイメントチャネル３０１のシーケンス図である。ボブからアリスへの１つの初期メッセージが存在し、その後に、各データパケットのためのｎ個のメッセージ対と、チャネルを選択するための２つの最終メッセージとが続くことに留意されたい。

【0145】

第１ラウンド－アリスのターン：最初に、ボブは、アリスに、Ｄ_０と、期待されるデータパケットを含む完全なマークル木とを送る。アリスは、ルートハッシュが彼女の選択する映画タイトルに属することをチェックし、Ｄ_０のマークルパスを検証する。アリスが受け取ったデータに満足すると、彼女は、彼女がＤ_０を受け取ったことを承認するようＴＸ_１を構成し、Ｄ_１を要求したいと思う。このトランザクションは、次の形を取ることができる：

ＴＸ_１
ロックタイム：０
入力０：
●アリスの未使用アウトポイント（ＴｘＩＤ_０，ｖｏｕｔ＝０）
●アリスの署名及びＳＩＧＨＡＳＨ＿ＡＬＬ｜ＡＮＹＯＮＥＣＡＮＰＡＹ
出力０：
●ロッキング条件
（ｉ）ボブがＤ_１及び彼の署名を提供する場合に、彼は出力を請求することができる。
（ｉｉ）他に、アリス及びボブが彼らの署名を提供する場合に、ボブは出力を請求することができる。
（ｉｉｉ）さもなければ、７２０個のブロックの後（このトランザクションがマイニングされてから後）に、アリスは出力を請求することができる。
●値：デジタルアセットの５００ユニット
出力１：
●アリスのチェンジ
出力２：
●出力１と同量をボブに支払う

【0146】

この例となるインスタンス化は、図９に示されている、単一のトランザクション設計は、３つの意図された機能を備える。余分の意味合いをトランザクションのいくつかのフィールドに割り当てることによって、データトレードシナリオで必要とされる複数のメッセージをただ１つの単一トランザクションテンプレートで置換することが可能である。Ｓｉｇ（Ｐ_Ａ，Ｔｘ_１）は、前のデータパックが受け取られて満足していることを認める署名である。ＰＰ＿ＤＵＰ ＯＰ＿ＳＨＡ２５６＜Ｈ（Ｄ_１）＞ＯＰ＿ＥＱＵＡＬは、データの次のパックを求める要求である。５００個のユニットは、データの次のパックに対するペイメントである。

【0147】

ＴＸ_１の入力は、少なくとも入力０を有する。これは、その量がＴＸ_１の出力０よりも多い（以下を参照）、アリスにロックされている前のトランザクションＴＸ_０のＵＴＸＯへのポインタを有する。ＴＸ_１の入力０はまた、入力のアンロッキングスクリプトでのアリスの署名と、他のパーティが入力を加えることを可能にするフラグ（「ＡＮＹＯＮＥＣＡＮＰＡＹ」）とを有する。

【0148】

ＴＸ_１の出力は、少なくとも出力０を有する。これは、ＴＸ_１の入力０よりも小さい（最初に）小さい量のデジタルアセット（例えば、５００個のユニット）を指定する。任意の実施形態では、ＴＸ_１の出力はまた、条件：
ｉ）後続のトランザクションＴＸ_ｐの入力でのアンロッキングスクリプトがＤ_１及びボブの署名を含む；
ｉｉ）後続のトランザクションＴＸ_ｐ’の入力でのアンロッキングスクリプトがアリスの署名及びボブの署名を含む；又は
ｉｉｉ）タイムアウト制限が経過しており、後続のトランザクションの入力でのアンロッキングスクリプトがアリスの署名を含む；
のうちのいずれかの下でこれがアンロックされることを可能にするロッキングスクリプトを有する。

【0149】

条件ｉ）に関して、アリスは、ボブがハッシュ木と呼ばれるマークル木を彼女に送っているので、どのデータ部分を期待すべきかを知っている。これにより、彼女は、彼女がこの条件をハッシュチャレンジによって含めるのに十分であるＤ_１のハッシュを決定することができる。（ＴＸ_１のロッキングスクリプトは、ＴＸ_ｐの入力のアンロッキングスクリプトで与えられている値が、ハッシュ化される場合に、ロッキングスクリプト内の値に一致することをチェックする何らかのコードをプラスしたＤ_１のハッシュを含む）。この条件は、ボブがアリスの署名なしで今すぐペイメントを請求したい場合に、彼がＤ_１をブロックチェーン１５０にアップロードしなければならなくなることを意味する。Ｄ_１は、ボブの独自のデータであり、また、Ｄ_１のサイズは高いマイニングフィーを負うために、ボブは、そうしたくないことがある。この技術はまた、後続のデータ部分Ｄ_２、Ｄ_３等に対しても使用され得る。

【0150】

条件ｉｉ）は、ボブが代わりにアリスに彼の署名を与える場合に、ボブがデータをアップロードせずにペイメントを請求することを可能にする。しかし、彼はまだそうしたくないと仮定する。

【0151】

条件ｉｉｉ）は任意である。これにより、特定の指定されたタイムアウト期間後にボブが何らかの理由で請求しなかった場合（例えば、ボブは決してプロセスに関与しない場合）に、アリスはＴＸ_１の出力０内の量を取り戻すことができる。７２０個のブロックの特定のタイムアウト値は単なる例であることが理解されよう。より一般的には、タイムアウト期間は、ブロック数又は秒などの人間の時間で定義でき、任意の値に設定可能である。これは、絶対的な時点又は経過時間で期限切れになると定義可能である。

【0152】

ＴＸ_１はまた、任意に、１つ以上の更なる出力を有してもよい。実施形態で、これらは、出力１及び出力２を有する。出力１は、入力量に等しいデジタルアセットの量を定義し、これをアリスにロックする（「アリスのチェンジ」）スクリプトを有する。例えば、これは２０００－５００個のユニット＝１５００個のユニットである。

【0153】

出力２は、出力１に等しいデジタルアセットの量を定義し、これをボブにロックする（「出力１でのアリスのチェンジと同量をボブに支払う」）スクリプトを有する。この効果は、他に誰か（実際には、ボブだけである）が自身の他の入力１をＴＸ_１に加えて差を補わない限りは、合計出力（例では、５００＋１５００＋１５００個のユニット＝３５００個のユニット）が常に入力よりも大きいことである。

【0154】

出力２は、ボブの肯定応答なしでアリスがトランザクションを公開しないよう設計されたトリックである。支払人として、アリスは、最初に、ＴＸ_１をブロードキャストするよう動機付けられていない。しかし、数ラウンドの後、アリスがボブにより多く支払う他のトランザクションが存在する場合には、アリスは、ボブが彼のペイメントを請求するよう後のインスタンスを使用する前に、ＴＸ_１をネットワーク１０６にブロードキャストすることによって、他のトランザクションを無効にするためにＴＸ_１を使用する可能性がある。出力２を含めることによって、ＴＸ_１は、ボブが出力と入力との間の不足をカバーするために自身の入力（入力１）をＴＸ_１に加えるまで、有効でない。ボブは、アリスがＳＩＧＨＡＳＨフラグ「ＡＬＬ｜ＡＮＹＯＮＥＣＡＮＰＡＹ」を使用するので、余分の入力を加えることができる。結果として、ＴＸ_１は、ボブによってのみブロードキャストされる可能性が高くなる。アリスは、ＴＸ_ｉを有効にするために必要な余分の入力を追加したくはない。これは、彼女がシステムをだまさなかった場合よりもコストがかかるためである。

【0155】

アリスのチェンジは、アリスの入力（入力０）の値からボブのペイメント（出力０）の値をマイナスしたものであるよう定義される。図８のグラフが示すとおり、ボブの保険（出力２）は、最後のデータ部分が送られる前に、合計出力（破線）が常に入力よりも大きいことを確かにする。

【0156】

より一般的に、ＴＸ_１の合計出力値が合計入力値よりも大きい状況が生じるように出力の他の組み合わせが使用されてもよく、よって、ボブにＴＸ_１の出力を請求するために彼自身の入力を加えるよう求めるとともに、アリスにＴＸ_１をブロードキャストすることを思いとどまらせる。

【0157】

スクリプト言語において出力０に３つの条件ｉ）、ｉｉ）及びｉｉｉ）を実装する例として、ハッシュパズル及び条件付きオペコードを使用することができる。例えば、次の通りである。

【数1】

【0158】

第１ラウンド－ボブのターン：ボブがトランザクションＴＸ_１を受け取るとき、彼は単純にＤ_１をアリスへ送る。ボブは、次のことを行うことによって、アリスからの如何なる助けもなしで彼がＴＸ_１でペイメントを請求することができるということで、これを安全に行うことに留意されたい。最初に、ボブは、ＴＸ_１で出力２の値をカバーするよう、アウトポイント（ＴｘＩＤ_Ｂ，ｖｏｕｔ＝０）を用いて、自身の入力を加えることによって、ＴＸ_１’を生成する。第２に、ボブは、ペイメントを請求するよう他のトランザクションＴＸ_ｐを生成する：

ＴＸ_ｐ
ロックタイム：０
入力０：
●ＴＸ_１’の出力０からのアウトポイント
●アンロッキングデータ
○Ｄ_１
○ボブの署名
出力０：
●ボブに支払う
●値：５００個のユニット

【0159】

ボブは、次いで、両方のトランザクションをネットワーク１０６へブロードキャストする。しかし、ボブにとって、これは、理想的な状況ではない。これは、彼がトランザクションでＤ_１をさらさなければならないからである。これは、チャネルの早期閉鎖（premature closure）と見なされる。しかし、アリスが、ペイメントチャネルを閉じるよう適切な手順に従う場合には（後述される）、ボブはこれを行う必要がない。

【0160】

第２ラウンド－アリスのターン：アリスがＤ_１を受け取り、内容に満足する場合に、彼女は、データの次のパックのための続くトランザクションを構成する。このトランザクションも、Ｄ_１を受け取ったことの確認応答と見なされる：

ＴＸ_２
ロックタイム：０
入力０：
●アリスの未使用アウトポイント（ＴＸ_１と同じアウトポイントであるとする）
●アリスの署名及びＳＩＧＨＡＳＨ＿ＡＬＬ｜ＡＮＹＯＮＥＣＡＮＰＡＹ
出力０：
●ロッキング条件
（ｉ）ボブがＤ_２及び彼の署名を提供する場合に、彼は出力を請求することができる。
（ｉｉ）他に、アリス及びボブが彼らの署名を提供する場合に、ボブは出力を請求することができる。
（ｉｉｉ）さもなければ、７２０個のブロックの後に、アリスは出力を請求することができる。
●値：１０００ユニット
出力１：
●アリスのチェンジ
出力２：
●出力１と同量をボブに支払う

【0161】

ＴＸ_１とＴＸ_２とを比較すると、Ｄ_１がＤ_２に変更されており、出力０の値がデジタルアセットの５００ユニットから１０００ユニットに増加していることに気付く。これら２つの変更の結果として、（アリスが同じ未使用アウトポイントを使用していると仮定して）他の出力は異なる値を有することになる。更に、これらの変更はトランザクションの可鍛部分に行われていないので、アリスはＴＸ_２に対して新しい署名を生成しなければならない。

【0162】

第２ラウンド－ボブのターン：ボブがトランザクションＴＸ_２を受け取るとき、彼は単純にＤ_２をアリスへ送る。前と同様に、ボブは、第１ラウンドと同じように、アリスからの如何なる助けもなしで彼がＴＸ_１でペイメントを請求することができるということで、これを安全に行う。ボブは、ＴＸ_２で出力２をカバーするよう、やはり（ＴｘＩＤ_Ｂ，ｖｏｕｔ＝０）から、自身の入力を加えて、ＴＸ_２’を生成する。また、ボブは、ペイメントを請求するよう他のトランザクションＴＸ_ｐを生成する：

ＴＸ_ｐ
ロックタイム：０
入力０：
●ＴＸ_２’の出力０からのアウトポイント
●アンロッキングデータ
○Ｄ_２
○ボブの署名
出力０：
●ボブに支払う
●値：１０００個のユニット

【0163】

ボブは、次いで、両方のトランザクションをネットワークへブロードキャストする。

【0164】

アリス及びボブがチャネルを閉じるよう協働する場合に、ボブは、第１ラウンドで述べられたように、これを行うことを回避することができる。

【0165】

最終ラウンド－アリスのターン：数ラウンドの後、アリスは、データの最後のパックＤ_ｎを要求するようＴｘ_ｎを構成する：

ＴＸ_ｎ
ロックタイム：０
入力０：
●アリスの未使用アウトポイント（ＴＸ_１と同じアウトポイントであるとする）
●アリスの署名及びＳＩＧＨＡＳＨ＿ＡＬＬ｜ＡＮＹＯＮＥＣＡＮＰＡＹ
出力０：
●ロッキング条件
（ｉ）ボブがＤ_ｎ及び彼の署名を提供する場合に、彼は出力を請求することができる。
（ｉｉ）他に、アリス及びボブが彼らの署名を提供する場合に、ボブは出力を請求することができる。
（ｉｉｉ）さもなければ、７２０個のブロックの後に、アリスは出力を請求することができる。
●値：５００ｎユニット
出力１：
●アリスのチェンジ
出力２：
●出力１と同量をボブに支払う

【0166】

最終ラウンド－ボブのターン：ボブは、最後のデータパックＤ_ｎで応答する。

【0167】

チャネルの閉鎖：ペイメントチャネルを閉じるために、アリスとボブとの間には数回のインタラクションが存在する。アリス又はボブのどちらかが、チャネル３０１を閉じる意志を他方に伝えることができる。一般性を失わずに、ボブからアリスへ送られたデータの最後のパックはＤ_ｎであるとする。ボブは、Ｄ_ｎを要求するトランザクションであるＴＸ_ｎを見つけ、自身の入力を加えて出力２をカバーしてＴＸ_ｎ’を生成する。ボブは、次のようにＴＸ_ｐを生成する：

ＴＸ_ｐ
ロックタイム：０
入力０：
●ＴＸ_ｎ’の出力０からのアウトポイント
●アンロッキングデータ
○Ｄ_ｎ
○ボブの署名
出力０：
●ボブに支払う
●値：５００ｎ個のユニット

【0168】

ボブは、両方のトランザクションＴＸ_ｎ’及びＴＸ_ｐを直接にアリスへペイメントチャネル３０１を介して送信する。アリスは、Ｔｘ_ｎ’及びＴｘ_ｐの入力が、彼女が期待するように実際に関係していることをチェックする。アリスは、ＴＸ_ｐに署名し、Ｄ_ｎを彼女の署名で置換して、Ｔｘ_ｐ’を生成する。

ＴＸ_ｐ’
ロックタイム：０
入力０：
●ＴＸ_ｎ’の出力０からのアウトポイント
●アンロッキングデータ
○アリスの署名
○ボブの署名
出力０：
●ボブに支払う
●値：５００ｎ個のユニット

【0169】

アリスは、ＴＸ_ｐ’をボブへ送る。ボブはＴＸ_ｎ’及びＴＸ_ｐ’をネットワーク１０６へブロードキャストする。代替的に、アリスは、ＴＸ_ｎ’及び／又はＴＸ_ｐ’をブロードキャストしてもよく、あるいは、それらの一方又は両方をサードパーティへおくって、アリス及びボブの代わりにブロードキャストしてもらってもよい。アリスは、いつでもチャネルを閉じることを選択することができることに留意されたい。

【0170】

図７では、（Ａ）チャネルがボブによって一対のトランザクションをブロードキャストすることによって一方的に閉じられ得る方法と、（Ｂ）対を形成する２つのトランザクションが両方ともチャネルの閉鎖時にブロードキャストされる方法とを両方に言及しており、チャネルがネットワーク１０６と通信しない有効に「開かされた」オフチェーンであることを示す。

【0171】

シーケンスをリキャップするために、ＴＸ_１に応答して、ボブはＤ_２をアリスへ送る。アリスは承認するためにボブにＴＸ_２を送り、次いで、ボブはＤ_３を送り、以降同様に続く。ＴＸ_２は、ＴＸ_１と同じであるが、Ｄ_１がＤ_２で置換されており、出力０の量が増えている。ＴＸ_３では、Ｄ_２がＤ_３で置換されており、出力０の量がやはり増えている。実施形態において、出力０での量は、ｉとともに、つまり、確認応答で送られたチャンク及びＴＸごとに、線形に増大する。代替的に、他の増大関係が使用されること、例えば、シーケンスを完了することを更に奨励するようシーケンスの終わりに向かってより高い重み付けを与えること、は除かれない。

【0172】

ボブは、基準ｉｉ）に基づきＴｘ_１、・・・Ｔｘ_ｉのうちのいずれか１つを一方的に請求することができる。これ行うために、ボブは、それを書き換えてＴｘ_ｉ’を生成する。書き換えは、Ｔｘ_ｉを使用するために、差を補うようボブのデジタルアセットの一部の入力を加え、それから、その入力でＤ_ｉを含む他のトランザクションを生成することを有する。Ｔｘ_ｐは無条件にボブにロックされた出力を有する。ボブは、彼の入力を加え、前のトランザクションＴｘ１又はＴｘ２等の１つを使用できたが、それだけの価値はない。彼は、映画を送信し続けて、最後に全量を手に入れたいと思っている。また、ボブは、彼がブロックチェーンで彼の映画のチャンクのうちの１つを公開する必要があるために、基準ｉｉ）にのみ依存したくはない。

【0173】

夫々のＴｘ_１、Ｔｘ_２、Ｔｘ_３、・・・の入力は、Ｔｘ_０の同じＵＴＸＯを指定することに留意されたい。従って、それらのうちのいずれか１つがネットワークへブロードキャストされ、いずれかの所与のノードで妥当性確認される場合に、インスタンスのうちのその他はもはや、そのノードによって有効と見なされなくなる（有効性の条件は、Ｔｘが、他のトランザクションに既に有効に使用されているＵＴＸＯを使用しようと試みていないことである）。異なるノード１０４は、最初の異なるインスタンスを受け取るので、１つのインスタンスがマイニングされる前にどのインスンタンスが「有効」であるかについて矛盾する見解を有しており、その時点で、全てのノード１０４は、マイニングされたインスタンスが唯一の有効なインスタンスであることに同意する。ノード１０４が１つのインスタンスを有効として受け入れ、それから、第２インスタンスがブロックチェーン１５０に記録されていることを発見する場合に、そのノード１０４は、これを受け入れ（るべきであり）、最初に受け入れたマイニングされていないインスタンスを捨てる（すなわち、無効として扱う）。

【0174】

ボブが早期にキャッシュインを行って、映画を送るのを止める場合に、アリスは、彼女が受け取っているよりも１つ多いチャンクについて支払っただけであるから、５００しか失わない。アリスは、いつでも手を引くことができたが、彼女がそうしない場合には、ボブは、アリスが支払わなかった映画の１よりも多いチャンク（例えば、５００ユニットの価値）を決して彼女に送っていない。

【0175】

量が、最初は小さくて映画の終わりまでに増大しながら、毎回増大し、そして、全てのトランザクションがＴｘ_０で同じＵＴＸＯを使用しようと試みるので、メカニズムは機能する。故に、いずれか１つをキャッシュインすると、その他が無効になる。また、実施形態で、出力合計は、ボブが自身の入力を加えるまで、入力よりも本質的に大きい。これは、入力レベルの可鍛性の例である。

【0176】

ボブ及びアリスの両方が映画の終わりまで待つ場合には、ボブは、アリスが署名するためにＴｘ_ｎ’をアリスへ送る。それにより、Ｄ_ｎのハッシュはアリスの署名で置換される。これは、ボブが、データの如何なるチャンクＤも公開せずに完全なペイメントを請求することを可能にする。これは、スクリプトレベルの可鍛性の例である。

【0177】

ブロックチェーンでのデータ輻輳を回避するために、プロセスは、何らかのデータパケット又はデータ受信者の署名のどちらかを使用してアンロックされ得るロッキングスクリプトを使用する。トランザクションの可鍛性を使用することによって、データ受信者は、アンロッキングスクリプト内のデータを彼又は彼女の署名で置換することができる。この動作は、データが受け取られたことを承認したり又はペイメントチャネルの閉鎖を確認したりするのみならず、空間を節約するようトランザクションからデータをプルーニングする。

【0178】

ボブが、トランザクションの値の漸進的な増大を考慮して、彼がアリスから受け取る最後のトランザクション以外の如何なるトランザクションも公開する動機はない。アリスが時期尚早にチャネルから去る場合に、ボブは単純に、彼がアリスから受け取る最後のトランザクションを、ペイメントを請求するトランザクションとともに公開する。彼がアリスの書き換えられたトランザクションを受け取らなかった場合には、彼は、ペイメントを請求するために、関連するデータパックをさらさなければならない。実施形態で、データ機密性に関する強い要件が存在する場合には、ボブはアリスへ送られるデータを暗号化し、トランザクションで暗号解読キーを明らかにすることができる（以下を参照）。

【0179】

アリスについては、しかしながら、彼女が十分なデータパックを受け取る場合に、最初のトランザクションを公開する動機が存在する可能性がある。最初のトランザクション及び最新のトランザクションの両方が有効である場合に、彼女が最新の通信されたトランザクションを無事に無効にすることは定かでない。このシナリオを完全に回避するために、実施啓太は、誰かが出力と入力との間の不足をカバーしない限りは、トランザクション自体を無効にする余分の出力を含む。アリスがトランザクションを有効にするために、彼女は余分の入力を供給する必要があり、それは、トランザクションをブロードキャストするという彼女の目的を無にする。

【0180】

ボブがオフラインになる場合に、アリスは、映画を観続けることができなくなる。しかし、彼女は、彼女が見たものにこれ以上支払うことはない。彼女は、ボブが戻るのを待つか、あるいは、他のサービスプロバイダに移動して、彼女が停止した場所から開始することができる。

【0181】

この形式のペイメントチャネルに必要なファンディングトランザクションはないことに留意されたい。更に、それは、アリスがいつでもストリーミングサービスを再開するよう再接続することができるほどに柔軟である。つまり、ペイメントチャネルを形成するためのオーバーヘッドはない。

【0182】

実施形態は、ペイメントチャネル内の全てのリスクに対処する。アリスはペイメントチャネル外で彼女のＵＴＸＯを二重に支払う可能性が依然としてあり得る。実施形態は、これを防ぐために３つの選択肢のうちの１つ以上を阻止することができる。１つは、アリスがＵＴＸＯを二重支払いしようとしたときに、デポジットアカウントの秘密鍵を明らかにするように強制する手法を採用することである。この場合、ボブは全てのデポジットを請求可能である。第２の選択肢は、アリスの確認応答を法的拘束力のあるものにすることである。つまり、ボブのペイメント請求トランザクションに対するアリスの署名は、彼女の身元の拘束力のある証拠と見なされ得る。アリスからの如何なる不正行為も、法執行の対象となる。第３の選択肢は、ボブがペイメントを随時、例えば、５分ごとに完了及び再開することである。頻度は、ボブによって、リスクに関する彼自身の評価に従って調整可能である。ファンディングトランザクションは不要であるから、ペイメントチャネルを再開することによるオーバーヘッドがないことに留意されたい。

【0183】

データ暗号化：データ機密性は、データがパブリックネットワーク上で交換される場合に、しばしば必要条件である。前のセクションでは、データ受信者は、何が受け取られると期待されるかを正確に知っている、と仮定した。しかし、データが暗号化される場合に、暗号文が何であるか、又はどのようなハッシュ値を期待すべきかを、如何なる通信もなしで前もって知ることは困難である。これにより、ロッキングスクリプトでハッシュパズルを構成する必要が生じる。これを軽減するために、実施形態では、データの売り手は、暗号文のハッシュ値を、その暗号文をそうしんする前にデータの受け手へ伝えることができる。データの受け手は、与えられたハッシュ値を用いて、ペイメントトランザクションを構成する。暗号化されたデータを受け取る場合に、データの受け手は、データを暗号解読し、データが期待されているかどうかを検証することができる。そうである場合には、全てが大丈夫である。そうでない場合には、最悪のケースは、受け手がお金を失うことである。しかし、受け手が失う可能性がある量は、データパックあたりの価格によって制限される。映画の場合に、それはおそらく約５００ユニットである。例えば、映画を合計すると約５ドルになる。経済的価値の規模が小さく、評判への影響がはるかに大きいことを考えると、データの売り手には不正を行う動機がない。

【0184】

いくつかの実施形態は、データの売り手とデータの各買い手との間で対称暗号法により共通の秘密キーを形成するメカニズムを実装してもよい。従って、伝送における全てのデータは、暗号化され得る。

【0185】

［結論］
上記の実施形態は、単に例として記載されていることが理解されるだろう。

【0186】

より一般的には、本明細書で開示されている一態様に従って、ノードのネットワークの少なくとも一部の夫々で保持されているブロックチェーンのコピーにターゲットトランザクションを記録する方法であって、
第２パーティのコンピュータ機器によって、
第１パーティと前記第２パーティとの間に、前記ネットワークとは別のサイドチャネルを形成することと、
連続したデータ部分のシーケンスを、該シーケンス内の最新のデータ部分まで、前記サイドチャネル上で前記第１パーティへストリーミングすることと、
前記データ部分の各々のデータ部分に応答して、前記第１パーティから第１トランザクションの異なった各々のインスタンスを前記サイドチャネル上で受信することであり、前記第１トランザクションは、デジタルアセットの量を指定する出力を有し、前記ターゲットトランザクションは、前記第１トランザクションの前記第１出力へのポインタを含む入力を有し、前記ターゲットトランザクションは、前記第１トランザクションの前記第１出力から前記第２パーティへ転送すべき前記デジタルアセットの量を指定する出力を更に有し、前記第１トランザクションの前記第１出力で指定されている前記量は、前記第１トランザクションの連続するインスタンスごとに増大する、ことと、
前記第１トランザクションの最新のインスタンス及び前記ターゲットトランザクションの対応するバージョンが前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるようにすることであり、前記ターゲットトランザクションの前記対応するバージョンにおける前記ポインタは、前記シーケンスにおいて前記第１トランザクションの前記最新のインスタンスでの前記第１出力を指す、ことと
を有する方法が提供される。

【0187】

前記第１トランザクションの最新のインスタンス及び前記ターゲットトランザクションの対応するバージョンが前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるようにすることは、第２パーティ自体が（第２パーティのコンピュータ機器によって）第１トランザクションの最新のインスタンス及び／又は対応するターゲットトランザクションを、ネットワークを通じて伝播されてブロックチェーンに記録されるよう送信することを有してもよい（当該送信することは、直接であっても、あるいは、第１又は第３パーティを介してもよい）。代替的に、前記第１トランザクションの最新のインスタンス及び前記ターゲットトランザクションの対応するバージョンが前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるようにすることは、第２パーティが第１トランザクションの最新のインスタンス及び／又は対応するターゲットトランザクションの一方又は両方を、ネットワークを通じて伝播されてブロックチェーンに記録されるように送信することを、第１パーティ又は第３パーティに要求又はトリガすることを有してもよい。例えば、第２パーティは、第１及び／又は第２トランザクションの一方又は両方を第１パーティへ部分的な形式で（例えば、第２パーティの署名を含むが第１パーティの署名は含まない）、第１パーティが完成させてネットワークへ（直接に又は第３パーティを介して）転送するために、送信してもよい。他の例として、第１パーティにトランザクションの１つを送信させることは、第２パーティがトランザクションのコンポーネント（例えば、第２パーティの署名）を第１パーティへ、第１パーティがトランザクションを形成して送信するために、送信することを有してもよい。

【0188】

実施形態において、前記第１トランザクションの前記第１出力で指定されている前記量は、前記第１トランザクションの連続するインスタンスごとに線形に増大してもよい。

【0189】

実施形態において、前記第１トランザクションの各インスタンスは、前記第１パーティによる前記各々のデータ部分の受信の肯定応答としての機能を果たしてもよく、その場合に、前記ストリーミングすることは、前記第１トランザクションの各インスタンスの受信に応答して前記シーケンスにおける次のデータ部分を送信することを有する。

【0190】

実施形態において、方法は、前記第２パーティのコンピュータ機器で、前記第１トランザクションのインスタンスのうちのいずれか１つのインスタンスと、そのインスタンスを指す前記ターゲットトランザクションの対応するバージョンとが、前記シーケンス内の任意の時点で、前記ネットワークにわたって伝播されて前記ブロックチェーンに記録されるようにすることを可能にするアプリケーション機能を提供することを有してもよい。この場合に、方法は、このために前記機能を使用する代わりに、前記機能を用いて、前記インスタンスのうちの先行するインスタンスのいずれかの代わりに、前記シーケンスにおける前記第１トランザクションの前記最新のインスタンス及び前記シーケンスにおける前記最新のインスタンスを指す前記ターゲットトランザクションの対応するバージョンの伝播及び記録を引き起こすことを有する。

【0191】

実施形態において。前記データ部分の夫々は、メディアコンテンツ片（例えば、ビデオ及び／又はオーディオコンテンツ）の各々の部分を有してもよい。

【0192】

代替的に、前記データ部分の夫々は、前記第１パーティがサービスサプライヤからのサービスのユニットをアンロックすることを可能にする異なった各々のキーを有してもよい。例えば、前記サービスは、電気、ガス、又は水道を含む公共事業の提供、あるいは、不動産、車、又は他の物理オブジェクトの賃借、のうちの１つを有してよい。

【0193】

実施形態において、前記シーケンスは、有限なシーケンスであってよく、前記最新のデータ部分は、前記シーケンス内の最後の部分であってよい。

【0194】

実施形態において、前記第１トランザクションの少なくとも最後のインスタンスの前記第１出力は、少なくとも第１条件及び第２条件を含む、前記第１トランザクションの前記第１出力をアンロックするための複数の代替条件を指定するロッキングスクリプトを有してもよく、前記ターゲットトランザクションの前記入力は、アンロッキングスクリプトを有してもよい。前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるよう送信される前記ターゲットトランザクションの前記対応するバージョンにおいて、前記ロッキングスクリプトは、前記代替条件のうちの第１条件ではなく第２条件を満足することに基づいて前記第１トランザクションの前記第１出力をアンロックするよう構成されてもよい。

【0195】

実施形態において、前記第１トランザクションの各インスタンスの出力は、前記複数の代替条件を指定する前記ロッキングスクリプトを有してもよい。前記機能は、前記最後のインスタンスより前の前記第１トランザクションの現在受信されているインスタンスと、該現在のインスタンスを指す前記ターゲットトランザクションの第１バージョンとが前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるようにすることを可能にすることができ、前記第１バージョンにおける前記ロッキングスクリプトは、前記第１条件を満足することに基づいて前記第１トランザクションの前記第１出力をアンロックするよう構成される。

【0196】

例えば、前記機能は、前記第１トランザクションの前記現在受信されているインスタンス及び前記ターゲットトランザクションの第１バージョンが前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるようにすることを手動で選択するためのオプションを前記シーケンス内の任意の時点で前記第２パーティに提供してもよい。代替的に、又は追加的に、前記機能は、前記第１パーティが前記シーケンスを通じた前記第１トランザクションのインスタンスの送信を止める場合に、自動で前記第１トランザクションの前記現在のインスタンス及び前記ターゲットトランザクションの第１バージョンが前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるようにするよう構成されてもよい。

【0197】

実施形態において、前記第２条件は、前記アンロッキングスクリプトが、該アンロッキングスクリプトを除く前記ターゲットトランザクションの部分に署名する前記第１パーティの暗号署名を有することを要求してもよく、伝播されて前記ブロックチェーンに記録されるよう送信される第２バージョンは、前記アンロッキングスクリプトにおいて前記第１パーティの前記署名を含んでもよい。

【0198】

実施形態において、前記第１条件は、前記第１パーティの暗号署名を要求しなくてもよい。

【0199】

実施形態において、少なくとも前記第１条件は、前記アンロッキングスクリプトが、該アンロッキングスクリプトを除く前記ターゲットトランザクションの部分に署名する前記第２パーティの暗号署名を含むことを要求する。

【0200】

実施形態において、前記第２条件は、前記アンロッキングスクリプトが、該アンロッキングスクリプトを除く前記ターゲットトランザクションの部分に署名する前記第２パーティの暗号署名を含むことを要求してもよい。この場合に、伝播されて前記ブロックチェーンに記録されるよう送信される第２バージョンは、前記アンロッキングスクリプトにおいて前記第２パーティの前記署名を含むことになる。

【0201】

実施形態において、方法は、前記第２パーティの前記コンピュータ機器によって、前記第１パーティの前記署名を加えることによって前記第１パーティが前記ターゲットトランザクションに統合するように前記第１バージョンを前記第１パーティへ送ることを有してもよい。

【0202】

実施形態において、前記第１条件は、前記データ部分の夫々が前記アンロッキングスクリプトに含まれることを要求するが、前記第２条件は、前記データ部分のいずれも前記ターゲットトランザクションに含まれることを要求しない。この場合に、前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるよう送信される前記ターゲットトランザクションの第２バージョンは、前記ターゲットトランザクションにおいて前記データ部分のいずれも含む必要がない。

【0203】

実施形態において、前記第１条件は、前記アンロッキングスクリプトが前記データ部分の夫々と、前記アンロッキングスクリプトを除く前記ターゲットトランザクションの部分に署名する前記第２パーティの暗号署名とを有することを要求するが、前記第１パーティの暗号署名が前記ターゲットトランザクションに含まれることを要求せず、前記第２条件は、前記アンロッキングスクリプトが前記第１パーティ及び前記第２パーティの両方の暗号署名を有することを要求するが、前記データ部分のいずれも前記ターゲットトランザクションに含まれることを要求しない。この場合に、伝播されて前記ブロックチェーンに記録されるよう送信される前記ターゲットトランザクションの前記第２バージョンは、該第２バージョンにおいて前記データ部分のいずれも含む必要がないが、前記アンロッキングスクリプトにおいて前記第１パーティ及び前記第２パーティの前記署名を含む。

【0204】

実施形態において、前記データ部分の夫々を含むという要件は、前記ロッキングスクリプトに含まれているハッシュチャレンジによって生成されてもよく、該ハッシュチャレンジは、データの各々の部分のハッシュと、前記アンロッキングスクリプトにおける各々のデータ部分のハッシュが前記ロッキングスクリプトに含まれているハッシュと一致することをチェックするハッシュ関数とを有する。この場合に、方法は、前記ネットワークとは別に、前記第１トランザクションのインスタンスの受信より前に、ハッシュセットを前記第１パーティに利用可能にすることを有し、前記ハッシュセットは、前記第１パーティが各々のデータ部分について前記ハッシュチャレンジを生成することを可能にするためのデータの部分ごとのハッシュ値を有する。

【0205】

実施形態において、方法は、前記第２パーティが前記サイドチャネル上で前記第１パーティから前記第１トランザクションを受信することを有してもよい。前記第１トランザクションは、入力量を指定する１つ以上の第１入力を有してもよく、前記第１トランザクションの前記第１出力は、第１ペイメントを指定し、前記第１トランザクションは、ペイメントの合計が前記入力量よりも多くなるように１つ以上の更なるペイメントを指定する１つ以上の更なる出力を更に有し、前記第１パーティから前記第２パーティによって受信される前記第１トランザクションは、差を補うための他の入力を有さない。前記ネットワークの前記ノードは、前記第１トランザクションが総入力量よりも多い総ペイメントを指定する場合には無効であるとして前記第１トランザクションを拒絶するよう構成される。可能な実施形態で、方法は、前記第２パーティが、前記差を補うよう前記第１トランザクションの最新又は最後のインスタンスに第２入力を加え、該第２入力が加えられた前記第１トランザクションを、前記ネットワークを通じて伝播されて前記ブロックチェーンに記録されるよう送信することを有する。

【0206】

上記の実施例として、前記更なる出力は、前記入力量から前記第１ペイメントをマイナスしたものに等しい前記第１パーティへの第２ペイメントを指定する第２出力を有してもよく、第３出力は、前記第２ペイメントに等しい前記第２パーティへの第３ペイメントを指定してもよい。

【0207】

実施形態において、前記ロッキングスクリプトは、前記代替条件のうちの第３条件を含んでもよく、該第３条件は、タイムアウト期間が経過していることと、前記第１パーティの暗号署名が前記アンロッキングスクリプトに含まれることとを要求して、前記タイムアウト期間内に前記第２パーティによって精算されない場合に前記第１パーティが前記第１トランザクションの前記第１出力におけるペイメントを精算することを可能にする。

【0208】

本明細書で開示されている他の態様に従って、コンピュータ読み出し可能なストレージにおいて具現され、第２パーティのコンピュータ機器で実行される場合に、第２パーティの方法を実行するよう構成されるコンピュータプログラムが提供される。

【0209】

本明細書で開示されている他の態様に従って、１つ以上のメモリユニットを有するメモリと、１つ以上の処理ユニットを有する処理装置とを有し、前記メモリは、前記処理装置で実行されるよう配置されたコードを記憶し、該コードは、前記処理装置で実行される場合に、第２パーティの方法を実行するよう構成される、コンピュータ機器が提供される。

【0210】

実施形態において、プログラム又はコードは、本明細書で開示されている第２パーティのステップのいずれかを実行するよう更に構成されてもよい。

【0211】

本明細書で開示されている他の態様に従って、ノードのネットワークの少なくとも一部の夫々で保持されているブロックチェーンのコピーにターゲットトランザクションを記録することを第２パーティに可能にする方法であって、
第１パーティのコンピュータ機器によって、
前記ネットワークとは別のサイドチャネルを介して、前記第２パーティから連続したデータ部分のシーケンスを受信することと、
前記データ部分の各々のデータ部分に応答して、前記第１パーティから第１トランザクションの異なった各々のインスタンスを前記サイドチャネル上で返送することであり、前記第１トランザクションは、デジタルアセットの量を指定する第１出力を有し、前記ターゲットトランザクションは、前記第１トランザクションの前記第１出力へのポインタを含む入力を有し、前記ターゲットトランザクションは、前記第１トランザクションの前記第１出力から前記第２パーティへ転送すべき前記デジタルアセットの量を指定する出力を更に有し、前記第１トランザクションの前記第１出力で指定されている前記量は、前記第１トランザクションの連続するインスタンスごとに増大する、ことと
を有し、
それによって、前記第２パーティが、前記ターゲットトランザクションのインスタンスのいずれか１つを、前記ネットワークにわたって伝播されて前記ブロックチェーンに記録されるよう送信することを可能にする、
方法が提供される。

【0212】

実施形態において、方法は、本明細書で開示されている第２パーティのステップのいずれかに相補的に対応する第１パーティのステップを更に有してもよい。

【0213】

本明細書で開示されている他の態様に従って、コンピュータ読み出し可能なストレージにおいて具現され、第１パーティのコンピュータ機器で実行される場合に、第１パーティの方法を実行するよう構成されるコンピュータプログラムが提供される。

【0214】

本明細書で開示されている他の態様に従って、１つ以上のメモリユニットを有するメモリと、１つ以上の処理ユニットを有する処理装置とを有し、前記メモリは、前記処理装置で実行されるよう配置されたコードを記憶し、該コードは、前記処理装置で実行される場合に、第１パーティの方法を実行するよう構成される、コンピュータ機器が提供される。

【0215】

実施形態において、プログラム又はコードは、本明細書で開示されている第１パーティのステップのいずれかを実行するよう更に構成されてもよい。

【0216】

本明細書で開示されている他の態様に従って、ブロックチェーンでの記録のためのトランザクションの組であって、当該組は、１以上のコンピュータ可読データ媒体で具現されて、
第１トランザクションのインスタンスのシーケンスを最新のインスタンスまで有し、各インスタンスが、同じソーストランザクションの同じ出力を指す入力を有し、前記ソーストランザクションの前記出力が、第１パーティのデジタルアセットの量を指定し、前記第１トランザクションの各インスタンスが、前記デジタルアセットの量を指定する第１出力を更に有し、
前記第１トランザクションのインスタンスのうちの１つの前記第１出力へのポインタを含む入力を有するターゲットトランザクションを有し、該ターゲットトランザクションが、前記第１トランザクションの前記第１出力から第２パーティへ転送すべき前記デジタルアセットの量を指定する出力を更に有し、
前記第１トランザクションの前記第１出力で指定されている前記量は、前記第１トランザクションの連続するインスタンスごとに増大し、前記ターゲットトランザクションの対応するバージョンにおけるポインタは、前記シーケンスにおいて前記第１トランザクションの最新のインスタンスでの前記第１出力を指す、
前記トランザクションの組が提供される。

【0217】

開示されている教示の他の変形又は使用ケースは、本明細書での開示を鑑みて当業者に明らかになる。本開示の範囲は、記載されている実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】