JP2022533753A - 知識証明 - Google Patents

知識証明 Download PDF

Info

Publication number
JP2022533753A
JP2022533753A JP2021569313A JP2021569313A JP2022533753A JP 2022533753 A JP2022533753 A JP 2022533753A JP 2021569313 A JP2021569313 A JP 2021569313A JP 2021569313 A JP2021569313 A JP 2021569313A JP 2022533753 A JP2022533753 A JP 2022533753A
Authority
JP
Japan
Prior art keywords
transaction
signature
challenge
key
participant
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2021569313A
Other languages
English (en)
Inventor
ジョセフ，ダニエル
ライト，クレイグ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nchain Holdings Ltd
Original Assignee
Nchain Holdings Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nchain Holdings Ltd filed Critical Nchain Holdings Ltd
Publication of JP2022533753A publication Critical patent/JP2022533753A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3252—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using DSA or related signature schemes, e.g. elliptic based signatures, ElGamal or Schnorr schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

ブロックチェーンに記録するための少なくとも１つの証明トランザクションは少なくとも、楕円曲線デジタル署名アルゴリズム（ECDSA）署名のs部分を含む。s部分は、署名コンポーネントのセットから計算され、各署名コンポーネントは、鍵シェア参加者のセットのうちの署名サブセットの参加者により提供される。鍵シェア参加者の各々は、未知の一時鍵の一時鍵シェアを保持し、署名コンポーネントの各々は、それらの一時鍵シェアに基づき署名サブセットの参加者により提供される。少なくとも１つの証明トランザクションは、少なくとも１つのチャレンジトランザクションのrチャレンジを示し、ブロックチェーンネットワークのノードは、署名検証を以下に適用する：（ｉ）少なくとも１つの証明トランザクションのs部分、及び（ｉｉ）以下のうちの１つ：（ｉｉａ）rチャレンジのr部分、（ｉｉｂ）少なくとも１つの証明トランザクションのr部分であって、その場合に、該r部分はrチャレンジを満たすことをチェックする。

Description

本開示は、ブロックチェーンに記録するためのトランザクションのセットにより実装される形式の知識証明に関連する。
ブロックチェーンとは、分散型データ構造の形式を指し、ブロックチェーンの複製のコピーは、ピアツーピア(peer-to-peer (P２P))ネットワーク内の複数のノードのそれぞれにおいて維持される。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックは１つ以上のトランザクションを含む。各トランザクションは、シーケンスの中の先行するトランザクションを指してよい。トランザクションは、新しいブロックに含まれるようネットワークへ提出され得る。新しいブロックは、「マイニング」として知られる処理により生成される。「マイニング」は、複数のマイニングノードの各々が「proof-of-work」を実行するために競争する、つまりブロックに含まれることを待っている保留中のトランザクションのプールに基づき、暗号パズルを解くことを含む。
従来、ブロックチェーン内のトランザクションは、デジタルアセット、すなわち、価値のストアとして機能するデータを伝達するために使用される。しかし、ブロックチェーンの上に追加の機能を積み重ねるために、ブロックチェーンを利用することもできる。例えば、ブロックチェーンプロトコルは、トランザクションのアウトプットに追加のユーザデータを格納することを可能にしてよい。現代のブロックチェーンは、単一トランザクション内に格納できる最大データ容量を増加させ、より複雑なデータを組み込むことを可能にしている。例えば、これは、ブロックチェーン内に電子ドキュメント（electronic document）、或いはオーディオ若しくはビデオデータを格納するために使用され得る。
ネットワーク内の各ノードは、転送、マイニング、及び記憶のうちの任意の１、２、又は３つ全部の役割を有することができる。転送ノードは、ネットワークのノードを通じてトランザクションを伝播させる。マイニングノードは、トランザクションのマイニングを実行してブロックにする。記憶ノードは、それぞれ、ブロックチェーンのマイニングされたブロックの彼ら自身のコピーを格納する。トランザクションをブロックチェーンに記録させるために、パーティは、該トランザクションを、伝播させるようにネットワークのノードのうちの１つへ送信する。トランザクションを受信したマイニングノードは、トランザクションをマイニングして新しいブロックにするよう競争してよい。各ノードは、トランザクションが有効であるための１つ以上の条件を含む同じノードプロトコルに関するよう構成される。無効なトランザクションは、伝播されず、マイニングされてブロックにされることもない。トランザクションが検証され、それによってブロックチェーンに受け入れられたと仮定すると、（任意のユーザデータを含む）トランザクションは、従って、不変の公開レコードとしてP２Pネットワークの各ノードに格納されたままである。
最新のブロックを生成するためにproof-of-workパズルを解くことに成功したマイナーは、標準的に、デジタルアセットの新しい額を生成する「生成トランザクション（generation transaction）」と呼ばれる新しいトランザクションにより報酬を受ける。proof-of-workは、ブロックをマイニングするために膨大な量の計算リソースを必要とするので、及び二重支払いの企てを含むブロックは他のノードにより受け入れられない可能性があるので、マイナーが、彼らのブロックに二重支払いトランザクションを含めることによりシステムを騙さないことを奨励する。
「アウトプットに基づく」モデル（UTXOに基づくモデルと呼ばれることもある）では、所与のトランザクションのデータ構造は、１つ以上のインプット及び１つ以上のアウトプットを含む。任意の使用可能アウトプットは、時にUTXO（「unspent transaction output（未使用トランザクションアウトプット）」）と呼ばれる、デジタルアセットの額を指定する要素を含む。アウトプットは、アウトプットを償還（redeem）するための条件を指定するロックスクリプトを更に含んでよい。各インプットは、先行するトランザクション内のそのようなアウトプットへのポインタを含み、ポイントされたアウトプットのロックスクリプトをアンロックするためのアンロックスクリプトを更に含んでよい。従って、トランザクションのペアを考えるとき、それらを、第１トランザクション及び第２トランザクションと呼ぶ。第１トランザクションは、デジタルアセットの額を指定する、及びアウトプットをアンロックする１つ以上の条件を定義するロックスクリプトを含む、少なくとも１つのアウトプットを含む。第２トランザクションは、第１トランザクションのアウトプットへのポインタと、第１トランザクションのアウトプットをアンロックするためのアンロックスクリプトと、を含む少なくとも１つのインプットを含む。
このようなモデルでは、第２トランザクションが伝播されてブロックチェーンに記録されるようP２Pネットワークへ送信されると、各ノードにおいて適用される有効性のための条件のうちの１つは、アンロックスクリプトが第１トランザクションのロックスクリプト内で定義された１つ以上の条件のうちの全部を満たすことである。もう１つは、第１トランザクションのアウトプットが、別の前の有効なトランザクションによって未だ償還されていないことである。これらの条件のうちのいずれかに従い第２トランザクションが無効であると分かった任意のノードは、該トランザクションを伝播させず、ブロックチェーンに記録させるためにマイニングしてブロックに含めることもしない。
トランザクションモデルの代替のタイプは、アカウントに基づくモデルである。この場合、各トランザクションは、過去の一連のトランザクションにおいて、先行するトランザクションのUTXOに戻って参照することによって移転される量を定義するのではなく、絶対的な口座（アカウント）残高を参照することによって移転される。全てのアカウントの現在の状態は、ブロックチェーンとは別個のマイナーによって格納され、絶えず更新される。アカウントに基づくモデルのトランザクションは、トランザクションを検証するのと同時に各ノードで実行するスマートコントラクトを含むこともできる。
いずれかのモデルのトランザクションは、知識証明を含むことができる。「知識証明（Knowledge proof）」又は「知識の証明（proof of knowledge）」は、パーティがデータの何らかのピース、例えばこれをdと呼ぶ、を知っていることをテストすることを表す従来の用語である。例として、アウトプットに基づくトランザクションモデルの場合には、１つのトランザクションTx１のアウトプット内のロックスクリプトはハッシュパズルを含むことができる。第２トランザクションTx２のインプットがTx１のこのアウトプットを指す場合、Tx２の該インプット内のアンロックスクリプトは、Tx１のアウトプットを償還することに成功するためには、ハッシュパズルを解かなければならない。ハッシュパズルは、dのハッシュであるハッシュ値hを含む。つまり、h=Hpuz(d)。パズルは、スクリプトのピースを含むこともできる。該スクリプトのピースは、ノードにおいてTx２のアンロックスクリプトと一緒に実行されると、Tx２のアンロックスクリプトからdであるとされているデータ値d'を取り入れ、それをハッシュ関数Hpuzによりハッシングし、Tx１のロックスクリプトに含まれるハッシュ値hと比較する。つまり、該スクリプトのピースは、h=Hpuz(d')であるかどうかをチェックし、比較の結果がyes（肯定）である（又は従来の用語で「真」である）場合にのみ、Tx１のアウトプットをアンロックする。従って、Tx２の受取人は、dの知識を証明するTx２のアンロックスクリプトにdが含まれる場合にのみ、Tx１のアウトプットをアンロックできる。
従来のハッシュパズルを単独で使用することに伴う問題は、不徳なマイナー又は他のノードがTx２のアンロックスクリプト内にdを観察し、従って、彼自身のバージョンTx２*を生成し及びマイニングする（又は発行する）ことができ、Tx２内の意図された受信者（例えばBob）の代わりにTx２*のアウトプット内で彼自身に支払うことができることである。これを回避するための既存の方法は、Tx１のロックスクリプトにP２PKH（pay-to-public key hash）要件を追加で含めることである。dについての知識証明に加えて、これは、Tx２のロックスクリプトに含まれることが意図される受取人の暗号署名を要求する。
ハッシュパズル及びP２PKHは、アウトプットに基づくモデルのロック及びアンロックスクリプト以外に、アカウントに基づくモデルではスマートコントラクトを用いて実装されることもできる。
当業者に馴染みのあるように、暗号書名は、秘密鍵Vに基づき生成され、秘密－公開鍵ペアの対応する公開鍵Pに基づき検証できる。秘密鍵Vをメッセージmに適用することにより生成される署名が与えられると、別のパーティが、Vを知らずに、Pを用いて、署名がVを用いて生成されたことを検証することが可能になる（従って、署名自体を検証することは、それ自体の能力において、知識証明の別の形式である）。
このためのアルゴリズムの１つの形式は、楕円曲線暗号（elliptic curve cryptography (ECC)）に基づき動作する楕円曲線デジタル署名 アルゴリズム（elliptic curve digital signature algorithm(ECDSA)）である。この場合、P及びVは以下により関連付けられる：
Figure 2022533753000002
 ここで、Pは２要素ベクトル（Px,Py）であり、Vはスカラーである、Gは、２次元楕円曲線上の所定の点（「生成元」（generator point））を表す２要素ベクトル（Gx,Gy）である。演算「・」は、スカラー楕円曲線乗算であり、楕円曲線上の１つの点を別の点に変換する演算の知られている形式である。
ECDSA署名は、それぞれr部分（r-part、(r)）及びs部分（s-part、(s)）として従来一般に知られている２個の要素で構成されるタプル(r,s)である。署名(r,s)は、メッセージmに秘密鍵Vを適用することにより生成される。ブロックチェーンに記録するためのトランザクションの場合、mはトランザクションの一部であり、署名は平文で該部分に加えてトランザクションにタグ付けされ、該トランザクションが検証されることを可能にする。例えば、アウトプットに基づくモデルでは、署名は、Tx２の部分に署名し、Tx１のアウトプットをアンロックするために、Tx２のロックスクリプトに含まれる。署名済み部分は、標準的に、トランザクションのアウトプットを含み、従って、これらは、署名及び従ってトランザクションを無効にすることなく変更することができない。
どんなトランザクションモデルが使用されても、署名(r,s)は以下のように計算される：
Figure 2022533753000003
 ここで、[R]xは、２要素ベクトルR=(Rx,Ry)のx軸を示す。kは一時鍵として知られている。これは、集合[１,n-１]から、標準的にはランダムに選択され、ここで、nは素数モジュラスであり、[１,n-１]は、両端を含む整数１からn-１までの実数の整数の集合である。Hsigは、ハッシュパズルで使用されるハッシュ関数Hpuzと比べて同じ又は異なる形式のハッシュ関数であり得るハッシュ関数である。
署名(r,s)、メッセージm、及び公開鍵Pの知識が与えられると、秘密鍵Vを知らない任意のパーティが、署名がメッセージmに対して秘密鍵を用いて生成されたことを検証することが可能になる。これは以下により行われる：
Figure 2022533753000004
 これが真の場合にのみ、署名が有効であり、その他の場合には有効ではない。これは、公開鍵Pに関連付けられたパーティが実際にメッセージの署名者であったことの検証として取り入れることができる。
可能なマイナー攻撃を回避するために、P２PKHと組み合わせて、知識証明としてハッシュパズルを使用することに伴う問題は、P２PKHは、先ず支払いが、dを知っているパーティに対してのみ行われることを保証するが、それは、Tx１のアウトプットが特定の所定の受信者又は受信者のセットに結びつけられていることも意味するということである（代替の受信者を含み得る代替の条件を指定することが可能である）。
ここで、特定のシークレット値を開示することを回避する方法で、該値の知識を証明できる任意の不特定パーティにより該償還可能なトランザクションを可能にすることが望ましい場合があることが認識される。例えば、Aliceは、彼女がシークレット鍵を与える者は誰でもアンロックできる第１トランザクションを設定したいが、彼女はそれらのパーティが誰であるか予め指定したくないとする。例えば、第１トランザクションは、Aliceの代わりに手紙又は小包のような何らかの品物の配達を受け取るために誰かに支払う、及び／又は品物を配達するために運送会社に支払ってよい。第１トランザクションは、シークレットの知識を証明する第２トランザクションにより償還できる。配達の注文の時点で、Aliceは、第１トランザクションを設定し、それを運送会社に提供するか、又はそれをブロックチェーンに発行してよい（又は、例えば、単に運送会社が第１トランザクションを生成することを可能にするために必要な詳細を提供する）。従って、運送会社は、配達が完了すると支払いが行われるという信頼を有する。しかしながら、Aliceは、この段階で、誰が彼女の代わりに配達を受け取るかを決定したくない。代わりに、彼女は、後に１つ以上の信頼パーティ（例えば、彼女の同居人Charlie及び／又はBobであり、彼らは配達の日に在宅であると確認されている）にシークレット値を提供するだけである。これは、彼らのいずれかが、Aliceのシークレット値の証明を実証する第２トランザクションを提供することにより、彼女の代わりに署名することを可能にする。
これはほんの１つの説明のための例であることが理解される。別の例として、トランザクションは、契約条件への合意を示すために使用され得る。Aliceは、１つ以上の信頼パーティのうちのサブセットに、彼女の代わりに署名する署名権限又は代理権を与えることを決定した後にのみ、合意したいと望み得る。例えば、合意する時点で、Aliceは、彼女自身が署名しようとしていたが、後になって、彼女は精神的能力を失っているか又は何らかの理由で署名することができないと分かり、従って、誰か他の者に代理権を割り当てる必要がある（例えば、この場合、Bob及びCharlieが彼女の家族又は仕事関係者であり得る）。
より一般的には、従来のハッシュパズルに代替案を提供することが望ましい場合がある。ここで、パズルの代替形式は、シークレット値をノードに開示することなく又はそれをブロックチェーンに発行することなく、そしてそれは特定のアイデンティティに結び付けられず、該シークレット値の知識の証明を可能にする。
本開示によると、本願明細書で「rパズル（r-puzzle）」又は同義的に「rチャレンジ（r-challenge）」と呼ばれる新しいタイプの知識証明が提供される。これは、チャレンジ（つまり、パズル）の基礎としてECDSA署名のr部分に対応する参照値に基づく。参照値は、第１トランザクションに（例えば、Tx１のロックスクリプトに）、第２トランザクションが第１トランザクションを償還するために（例えば、Tx２のアンロックスクリプト内に）指定されたr部分を含む署名を含むことを要求するチャレンジとして、含まれる。第２トランザクション内のｒパズルに対する解を提供することにより、これは、証明者が対応する一時鍵kを知っているに違いないことを証明するが、第２トランザクション内でkを開示する必要がない。従って、kは一時秘密鍵として使用でき、rは対応する一時公開鍵と同様に動作する。
ここで、rチャレンジを満たす署名は、「閾値署名方式（threshold signature scheme）」に基づき生成される。鍵シェア参加者のセットΠは、rチャレンジに対応する一時鍵kの一時鍵シェアを取する（参加者iの一時鍵シェアはkiと示される）。鍵シェア参加者Πの任意の「署名サブセット」πは、署名サブセットπの中の参加者の数が閾値を満たすならば、rチャレンジを満たす署名を生成するために協力でき、いずれの参加者も彼の／その鍵シェアkiを開示する必要がなく、参加者のうちのいずれも基礎にある一時鍵k自体の知識を有する必要がない。rパズルの枠組みの中で適用される閾値方式は、本願明細書で「rパズル閾値方式」と呼ばれてよい。
本開示の第１の態様は、コンピュータにより実施される方法であって、
ブロックチェーンネットワークにより維持されるブロックチェーンに記録するために、少なくとも１つの証明トランザクションを生成するステップであって、前記少なくとも１つの証明トランザクションは、楕円曲線デジタル署名アルゴリズム（ECDSA）署名の少なくともs部分を含み、前記s部分は署名コンポーネントのセットから計算され、前記署名コンポーネントの各々は、鍵シェア参加者のセットのうちの署名サブセットの参加者により提供される、ステップを含み、
前記鍵シェア参加者の各々は、未知の一時鍵の一時鍵シェアを保持し、前記署名コンポーネントの各々は、前記参加者により保持される前記一時鍵シェアに基づき前記署名サブセットの参加者により提供され、
前記少なくとも１つの証明トランザクションは、少なくとも１つのチャレンジトランザクションのrチャレンジを示して、前記ブロックチェーンネットワークのノードに、前記少なくとも１つの証明トランザクションを受信することに応答して、以下に署名検証を適用させる：
（ｉ）前記少なくとも１つの証明トランザクションの前記s部分、及び、
（ｉｉ）以下のうちの１つ：
（ｉｉａ）前記rチャレンジのr部分であって、それにより、前記rチャレンジの前記r部分が前記未知の一時鍵に対応しない場合に前記署名検証が失敗し、
（ｉｉｂ）前記少なくとも１つの証明トランザクションのr部分であって、その場合に、前記ノードに、更に、前記少なくとも１つの証明トランザクションの前記r部分が前記rチャレンジを満たすことをチェックさせ、それにより、前記少なくとも１つの証明トランザクションの前記r部分が前記未知の一時鍵に対応しない場合に前記署名検証が失敗し、前記少なくとも１つの証明トランザクションの前記r部分が前記rチャレンジを満たさない場合に前記チェックが失敗する、
方法を提供する。
これは、知識証明の一形態であり、有利なことに、r部分が、この知識証明の基礎として使用され、参加者に彼らの一時鍵シェアkiを提出することを要求することなく、基礎にある一時鍵k自体を参加者のうちのいずれにも開示することを要求しない。k及びシェアkiが開示されないので、悪意あるマイナー又は他のノードは、意図された受益者の代わりに彼／彼女自身に支払い得る有効な第２トランザクションTx２*を形成するために彼／彼女自身の署名を生成できない。更に、署名のr部分はそれ自体がシステム内の任意のアイデンティティにリンクされないので、これは、任意の署名サブセットが証明を満たすことができることを意味する。
本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、例としてのみ、以下の添付の図面を参照する。
ブロックチェーンを実装するためのシステムの概略ブロック図である。 ブロックチェーンに記録されるトランザクションの幾つかの例を概略的に示している。 ブロックチェーンを実装するための別のシステムの概略ブロック図である。 アウトプットに基づくモデルのノードプロトコルに従う、トランザクションを処理するノードソフトウェアのピースの概略ブロック図である。 トランザクションの例示的なセットの概略図である。 楕円曲線デジタル署名アルゴリズム（ECDSA）の背後にある原理の幾つかを概略的に示す。 楕円曲線デジタル署名アルゴリズム（ECDSA）の背後にある原理の幾つかを概略的に示す。 楕円曲線デジタル署名アルゴリズム（ECDSA）の背後にある原理の幾つかを概略的に示す。 楕円曲線デジタル署名アルゴリズム（ECDSA）の背後にある原理の幾つかを概略的に示す。 本願明細書でrパズル（又は同義的にrチャレンジ）と呼ばれるタイプの知識証明の１つの可能な実装の概略図である。 rパズルの別の可能な実装の概略図である。 rパズルの別の可能な実装の概略図である。 rパズルの更に別の可能な実装の概略図である。 アカウントに基づくモデルのノードプロトコルに従う、トランザクションを処理するノードソフトウェアのピースの概略ブロック図である。 ECDSA署名の例示的なフォーマットを概略的に示す。 rパズルの１つの形式のロック及びアンロックスクリプトの例示的な実装のステップ毎のスクリプト分析である。 rパズル閾値方式の特定の原理の高レベルな説明を示す。 rパズル閾値方式の文脈で、rパズルトランザクションを生成する方法を示す。 rパズル閾値方式の文脈で、証明トランザクションを検証する又は処理する方法を示す。 ディーラ不要のrパズル生成方法の原理を説明する。 ディーラに基づくrパズル生成方法の原理を説明する。 閾値rパズル方式で証明トランザクションを生成する第１の例示的な方法を示す。 閾値rパズル方式で証明トランザクションを生成する第２の例示的な方法を示す。 鍵シェアに基づき、ECDSA署名のs部分を計算する方法の処理フローを示す。 鍵シェアに基づき、ECDSA署名のr部分を計算する方法の処理フローを示す。 一時鍵、秘密鍵、及び署名シークレットに適用可能な、シークレットのシェアを取得する方法の処理フローを示す。 rパズルの枠組みを通常のECDSAの枠組みと比較する概略図である。
説明される実施形態は、「rパズル」の枠組みの中で実施される閾値署名方式の形式を提供する。実施形態は以下に説明される。先ず、それらの実施形態の幾つかの有用なコンテキストが提供され、これはrパズルの枠組みの説明を含む。
上述のように、本発明の主題の特定の実施形態は、「rパズル」の枠組みの中で知識チャレンジを策定する。１つのそのような例は、後述する図１４に示される。rパズルの枠組みの種々の利点は、以下に説明され、図１４の例では、それらの利点は、知識チャレンジの中で利用される。
他の実施形態は、rパズルの枠組みを利用しない。１つのそのような例は、これも後述する図１５に示される。
前述の実施形態を説明する前に、それらの実施形態の幾らかの有用な背景が提供される。これは、図１４の例及び他のそのような実施形態の状況のような、rパズルの枠組みの説明を含む。
幾つかの暗号方式では、検証者は、ある人（証明者又は被挑戦者又は被チャレンジャーと呼ばれる）が知識証明と呼ばれる情報の何らかのピースを有することを納得させる必要がある場合がある。単純に、これは、検証者に情報のピースを直接提供することにより行うことができる。代替として、証明者は、情報のピースに依存する計算を実行することを要求され得る。望ましくは、関連する計算は、検証者自身がチャレンジを設定するために情報のピースを知る必要がない、又は証明者が情報のピースを知っていることを検証するために情報のピースが検証者に開示される必要がないようなものである。計算方法について、検証計算は入力データに対して実行されなければならない。シークレット値の知識を証明する直接的な方法は、暗号ハッシュ関数の原像（preimage、プリイメージ）及び衝突耐性の特徴により、暗号ハッシュ関数の使用を通じるものである。このハッシュ方法は、ハッシュ関数が多くのブロックチェーンアプリケーションの秘密鍵－公開鍵暗号システムの基本部分を形成するので、多くのブロックチェーンアプリケーションに容易に統合できる。この種の知識証明は、標準的にハッシュパズルと呼ばれるブロックチェーンアプリケーションにおいて非常に多い。
UTXOに基づくブロックチェーンでは、ハッシュパズルに対する解（ハッシュ値の原像）は、使用条件として設定できる。従って、検証は、トランザクション検証の部分としてマイナーにより実行される。しかしながら、このアプローチでは、トランザクションは、特定の秘密鍵を用いる署名も要求しなければならない。そうでなければ、マイナーは、ブロックにトランザクションを含める前に、ハッシュパズル解を受け取るからである。これは、悪意あるマイナーに、マイナーに属するアドレスに向けられたアウトプットを有する支払いトランザクションを生成する機会を与え得る。
本開示では、知識証明は、検証がマイナー（又は転送ノード）により実行されることを可能にしたまま、この問題を回避する知識証明が提供される。これを行うために、知識証明は、楕円曲線デジタル署名アルゴリズム（elliptic curve digital signature algorithm (ECDSA)）署名に対応する一時鍵に接続される。このアルゴリズムで使用される暗号プリミティブは多くのブロックチェーンに固有のものであるので、現在のインフラストラクチャに直ちに統合できる。
＜例示的なシステムの概要＞
図１は、ブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットのような広域インターネットワークであるパケット交換ネットワーク１０１を含む。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア(P２P)オーバレイネットワーク１０６を形成するように配置された複数のノード１０４を含む。各ノード１０４は、異なるピアに属する異なるノード１０４を有するピアのコンピュータ装置を含む。各ノード１０４は、１つ以上のプロセッサ、例えば、１つ以上の中央処理装置（ＣＰＵ）、アクセラレータプロセッサ、特定用途向けプロセッサ、及び/又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む処理装置を含む。各ノードはまた、メモリ、すなわち、１つ以上の非一時的コンピュータ読取可能媒体の形態のコンピュータ読取可能記憶装置を備える。メモリは、１つ以上のメモリ媒体、例えば、ハードディスクなどの磁気媒体、固体ドライブ（solid-state drive (SSD)）、フラッシュメモリ又はEEPROMなどの電子媒体、及び/又は光ディスクドライブなどの光学的媒体を使用する１つ以上のメモリユニットを含んでもよい。
ブロックチェーン１５０は、データのブロック１５１のチェーンを指し、ブロックチェーン１５０のそれぞれのコピーは、ピアツーピア(peer-to-peer (P２P))ネットワーク１６０内の複数のノードのそれぞれにおいて維持される。チェーン内の各ブロック１５１は、１つ以上のトランザクション１５２を含み、この文脈ではトランザクションは、一種のデータ構造を参照する。データ構造の性質は、トランザクションモデル又はスキームの一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、典型的には、全体を通して、１つの特定のトランザクションプロトコルを使用する。１つの一般的なタイプのトランザクションプロトコルでは、各トランザクション１５２のデータ構造は、少なくとも１つのインプット及び少なくとも１つのアウトプットを含む。各アウトプットは、そのアウトプットが暗号的にロックされている(アンロックされ、それによって償還又は使用されるために、そのユーザ１０３の署名を必要とする)ユーザに属するデジタルアセットの数量を表す額（amount）を指定する。各インプットは、先行するトランザクション１５２のアウトプットを逆にポイントし、それによってトランザクションをリンクする。
ノード１０４の少なくとも幾つかは、トランザクション１５２を転送し、それによって伝播する転送ノード１０４Fの役割を引き受ける。ノード１０４の少なくともいくつかは、ブロック１５１をマイニングするマイナー１０４Mの役割を担う。ノード１０４の少なくとも幾つかは、記憶ノード１０４S（「フルコピー（full-copy）」ノードとも呼ばれる）の役割を引き受け、各ノードは、それぞれのメモリに同じブロックチェーン１５０のそれぞれのコピーを格納する。各マイナーノード１０４Mは、マイニングされてブロック１５１にされることを待ってるトランザクション１５２のプール１５４も維持する。所与のノード１０４は、転送ノード１０４、マイナー１０４M、記憶ノード１０４S、又はこれらの２つ若しくは全部の任意の組み合わせであり得る。
所与の現在のトランザクション１５２jにおいて、インプット（又はそのそれぞれ）は、トランザクションのシーケンスの中の先行トランザクション１５２iのアウトプットを参照するポインタを含み、このアウトプットが現在のトランザクション１５２jにおいて償還されるか又は「消費される（spent）」ことを指定する。一般に、先行するトランザクションは、プール１５４又は任意のブロック１５１内の任意のトランザクションであり得る。先行するトランザクション１５２iは、必ずしも、現在のトランザクション１５２jが生成された又はネットワーク１０６へ送信されたときに存在する必要はないが、先行するトランザクション１５２iは、現在のトランザクションが有効であるために存在し検証されている必要がある。従って、本願明細書で「先行する」は、ポインタによりリンクされた論理的シーケンスの中で先行するものを表し、必ずしも時系列の中での生成又は送信の時間を表さない。従って、それは、必ずしも、トランザクション１５２i,１５２jが順不同で生成され又は送信されることを排除しない（以下の親のない（orphan）トランザクションに関する議論を参照する）。先行するトランザクション１５２iは、等しく、祖先（antecedent）又は先行（predecessor）トランザクションと呼ばれ得る。
現在のトランザクション１５２jのインプットは、先行するトランザクション１５２iのアウトプットがロックされているユーザ１０３aの署名も含む。また、現在のトランザクション１５２jのアウトプットは、新しいユーザ１０３bに暗号的にロックできる。従って、現在のトランザクション１５２jは、先行するトランザクション１５２iのインプットで定義された量を、現在のトランザクション１５２jのアウトプットで定義された新しいユーザ１０３bに移転することができる。幾つかの場合には、トランザクション１５２が複数のアウトプットを有し、複数のユーザ間でインプット量を分割してよい(変更を行うために、そのうちの１人がオリジナルユーザとなる)。場合によっては、トランザクションが複数のインプットを有し、１つ以上の先行するトランザクションの複数のアウトプットから量をまとめ、現在のトランザクションの１つ以上のアウトプットに再分配することもできる。
上記は「アウトプットベースの」トランザクションプロトコルと呼ばれることがあり、時には「未使用のトランザクションアウトプット(unspent transaction output (UTXO))タイプのプロトコル」(アウトプットはUTXOと呼ばれる)とも呼ばれる。ユーザの合計残高は、ブロックチェーンに格納されている１つの数値で定義されるのではなく、代わりに、ユーザは、ブロックチェーン１５１内の多くの異なるトランザクション１５２に分散されている該ユーザの全てのUTXOの値を照合するために、特別な「ウォレット」アプリケーション１０５を必要とする。
アカウントベースのトランザクションモデルの一部として、別のタイプのトランザクションプロトコルを「アカウントベース」のプロトコルと呼ぶことがある。アカウントベースの場合、各トランザクションは、過去の一連のトランザクションにおいて、先行するトランザクションのUTXOに戻って参照することによって移転される量を定義するのではなく、絶対的な口座（アカウント）残高を参照することによって移転される。全てのアカウントの現在の状態は、ブロックチェーンとは別個のマイナーによって格納され、絶えず更新される。このようなシステムでは、トランザクションは、アカウントの連続したトランザクション記録(いわゆる「ポジション」)を用いて発注される。この値は、送信者により彼らの暗号署名の一部として署名され、トランザクション参照計算の一部としてハッシュされる。さらに、任意的なデータフィールドもトランザクションに署名することができる。このデータフィールドは、例えば、前のトランザクションIDがデータフィールドに含まれている場合、前のトランザクションを遡ってポイントしてよい。
どちらのタイプのトランザクションプロトコルでも、ユーザ１０３が新しいトランザクション１５２jを実行したい場合、ユーザは、自分のコンピュータ端末１０２からP２Pネットワーク１０６のノードの１つ１０４(現在は、通常、サーバ又はデータセンタであるが、原則として、他のユーザ端末でもよい)に新しいトランザクションを送信する。このノード１０４は、各ノード１０４に適用されるノードプロトコルに従って、トランザクションが有効であるかどうかをチェックする。ノードプロトコルの詳細は、問題のブロックチェーン１５０で使用されているトランザクションプロトコルのタイプに対応し、全体のトランザクションモデルを一緒に形成する。ノードプロトコルは、典型的には、ノード１０４に、新しいトランザクション１５２j内の暗号署名が、トランザクション１５２の順序付けされたシーケンスの中の前のトランザクション１５２iに依存する、期待される署名と一致することをチェックすることを要求する。アウトプットベースの場合、これは、新しいトランザクション１５２jのインプットに含まれるユーザの暗号署名が、新しいトランザクションが消費する先行するトランザクション１５２jのアウトプットに定義された条件と一致することをチェックすることを含んでよく、この条件は、典型的には、新しいトランザクション１５２jのインプット内の暗号署名が、新しいトランザクションのインプットがポイントする前のトランザクション１５２iのアウトプットをアンロックすることを少なくともチェックすることを含む。幾つかのトランザクションプロトコルでは、条件は、少なくとも部分的に、インプット及び/又はアウトプットに含まれるカスタムスクリプトによって定義されてもよい。或いは、単にノードプロトコルだけで固定することもできるし、或いは、これらの組み合わせによることもある。いずれにせよ、新しいトランザクション１５２jが有効であれば、現在のノードは新しいトランザクションをP２Pネットワーク１０６内のノード１０４の１つ以上の他のノードに転送する。これらのノード１０４の少なくともいくつかは、同じノードプロトコルに従って同じテストを適用し、新しいトランザクション１５２jを１つ以上のさらなるノード１０４に転送するなど、転送ノード１０４Fとしても機能する。このようにして、新しいトランザクションは、ノード１０４のネットワーク全体に伝播される。
アウトプットベースのモデルでは、与えられたアウトプット(例えば、UTXO)が消費されるかどうかの定義は、ノードプロトコルに従って別の今後の（onward）トランザクション１５２jのインプットによって既に有効に償還されているかどうかである。トランザクションが有効であるための別の条件は、それが消費又は償還を試みる先行するトランザクション１５２iのアウトプットが、別の有効なトランザクションによって未だ消費/償還されていないことである。ここでも、有効でない場合、トランザクション１５２jは、ブロックチェーンに伝播又は記録されない。これは、支払者が同じトランザクションのアウトプットを複数回消費しようとする二重支出を防ぐ。一方、アカウントベースのモデルは、口座残高を維持することによって、二重支出を防ぐ。この場合も、トランザクションの順序が定義されているため、口座残高は、一度に単一の定義された状態を有する。
検証に加えて、ノード１０４Mのうちの少なくともいくつかは、「proof of work」に支えられているマイニングと呼ばれるプロセスで、トランザクションのブロックを最初に作成するために競合する。マイニングノード１０４Mでは、まだブロックに現れていない有効なトランザクションのプールに新しいトランザクションが追加される。そして、マイナーは、暗号パズルを解決しようと試みることにより、トランザクションのプール１５４からトランザクション１５２の新しい有効なブロック１５１を組み立てるために競争する。これは、典型的には、ノンスがトランザクションのプール１５４と連結され、ハッシュされるときに、ハッシュのアウトプットが所定の条件を満たすような「ノンス」値を探すことを含む。例えば、所定の条件は、ハッシュのアウトプットが、所定の数の先行ゼロを有することであってもよい。ハッシュ関数の特性は、インプットに関して予測不可能なアウトプットを持つことである。従って、この探索は、ブルートフォースによってのみ実行することができ、従って、パズルを解決しようとしている各ノード１０４Mにおいて、相当量の処理リソースを消費する。
パズルを解く最初のマイナーノード１０４Mは、これをネットワーク１０６に通知し、その解を証明として提供する。この解は、ネットワーク内の他のノード１０４によって簡単にチェックすることができる(ハッシュが対する解が与えられれば、ハッシュのアウトプットが条件を満たすことを確認することは簡単である)。勝者がパズルを解いたトランザクションのプール１５４は、各ノードで勝者が発表した解をチェックしたことに基づいて、記憶ノード１０４Sとして機能するノード１０４のうちの少なくともいくつかによってブロックチェーン１５０の新しいブロック１５１として記録される。また、新しいブロック１５１nにはブロックポインタ１５５が割り当てられ、チェーン内で前に作成されたブロック１５１n-１を指すようになっている。proof-of-workは、新しいブロックを１５１作成するのに多大な労力を要し、二重の支出を含むブロックは他のノード１０４によって拒否される可能性が高く、従ってマイニングノード１０４Mが二重支払いを彼らのブロックに含まないようにする動機が働くので、二重の支出のリスクを減じるのを助ける。一旦生成されると、ブロック１５１は、同じプロトコルに従ってP２Pネットワーク１０６内の各格納ノード１０４Siで認識され、維持されるため、変更することはできない。また、ブロックポインタ１５５は、ブロック１５１に順序を課す。トランザクション１５２は、P２Pネットワーク１０６内の各記憶ノード１０４Sで順序付けられたブロックに記録されるので、これはトランザクションの不変の公開台帳を提供する。
パズルを解決するために常に競争している異なるマイナー１０４Mは、いつ解を探し始めたかによって、いつでもマイニングされていないトランザクションプール１５４の異なるスナップショットに基づいてパズルを解いているかもしれないことに留意する。パズルを解く者は誰でも、最初に次の新しいブロック１５１nに含まれるトランザクション１５２を定義し、現在のマイニングされていないトランザクションのプール１５４が更新される。そして、マイナー１０４Mは、新たに定義された未解決のプール１５４からブロックを作り出すために、競争を続ける。また、生じ得る「分岐（フォーク、fork）」を解決するためのプロトコルも存在する。これは、２人のマイナー１０４Mが互いに非常に短い時間内にパズルを解決し、ブロックチェーンの矛盾したビューが伝播する場合である。要するに、分岐の枝が伸びるときは常に、最長のものが最終的なブロックチェーン１５０になる。
ほとんどのブロックチェーンでは、勝ったマイナー１０４Mは、何も無いものから新しい量のデジタルアセットを生み出す特別な種類の新しいトランザクションによって自動的に報酬を受けている(通常のトランザクションでは、あるユーザから別のユーザにデジタルアセットの量を移転する)。したがって、勝ったノードは、ある量のデジタルアセットを「マイニング」したと言える。この特殊なタイプのトランザクションは「生成（generation）」トランザクションと呼ばれることもある。それは自動的に新しいブロック１５１nの一部を形成する。この報酬は、マイナー１０４Mがproof-of-work競争に参加する動機を与える。多くの場合、通常の（非生成）トランザクションは、そのトランザクションが含まれたブロック１５１nを生成した勝ったマイナー１０４Mにさらに報酬を与えるために、追加のトランザクション手数料をそのアウトプットの１つにおいて指定する。
マイニングに含まれる計算リソースのために、典型的には、少なくともマイナーノード１０４Mの各々は、１つ以上の物理的サーバユニットを含むサーバ、又はデータセンタ全体の形態をとる。各転送ノード１０４M及び/又は記憶ノード１０４Sは、サーバ又はデータセンタの形態をとることもできる。しかしながら、原則として、任意の所与のノード１０４は、ユーザ端末又は互いにネットワーク接続されたユーザ端末のグループを含むことができる。
各ノード１０４のメモリは、それぞれの１つ以上の役割を実行し、ノードプロトコルに従ってトランザクション１５２を処理するために、ノード１０４の処理装置上で動作するように構成されたソフトウェア４００を格納する。ノード１０４に属するいずれの動作も、それぞれのコンピュータ装置の処理装置上で実行されるソフトウェア４００によって実行され得ることが理解されよう。ノードソフトウェア４００は、アプリケーションレイヤにおける１つ以上のアプリケーション、又はオペレーティングシステムレイヤ若しくはプロトコルレイヤのような下位レイヤ、又はこれらの任意の組合せの中に実装されてよい。また、本明細書で使用される「ブロックチェーン」という用語は、一般的な技術の種類を指す一般的な用語であり、任意の特定の専有のブロックチェーン、プロトコル又はサービスに限定されない。
また、ネットワーク１０１には、消費者ユーザの役割を果たす複数のパーティ１０３の各々のコンピュータ装置１０２も接続されている。これらは、トランザクションにおける支払人及び被支払人の役割を果たすが、他のパーティの代わりにトランザクションをマイニングし又は伝播することに必ずしも参加しない。それらは必ずしもマイニングプロトコルを実行するわけではない。２つのパーティ１０３及びそれぞれの機器１０２が説明のために示されており、第１パーティ１０３ａ及びそのそれぞれのコンピュータ機器１０２a、幾つかの第２パーティ１０３ｂ及びそのそれぞれのコンピュータ機器１０２bである。より多くのこのようなパーティ１０３及びそれらのそれぞれのコンピュータ機器１０２がシステムに存在し、参加することができるが、便宜上、それらは図示されていないことが理解されよう。各パーティ１０３は、個人又は組織であってもよい。純粋に例示として、第１パーティ１０３ａは、本明細書においてAliceと称され、第２パーティ１０３ｂは、Bobと称されるが、これは限定的なものではなく、本明細書においてAlice又はBobという言及は、それぞれ「第１パーティ」及び「第２パーティ」と置き換えることができることは理解されるであろう。
各パーティ１０３のコンピュータ機器１０２は、１つ以上のプロセッサ、例えば１つ以上のCPU、GPU、他のアクセラレータプロセッサ、特定用途向けプロセッサ、及び/又はFPGAを備えるそれぞれの処理装置を備える。各パーティ１０３のコンピュータ機器１０２は、さらに、メモリ、すなわち、非一時的コンピュータ読取可能媒体又は媒体の形態のコンピュータ読取可能記憶装置を備える。このメモリは、例えば、ハードディスクなどの磁気媒体、ＳＳＤ、フラッシュメモリ又はEEPROMなどの電子媒体、及び/又は光ディスクドライブなどの光学的媒体を使用する１つ以上のメモリユニットを含んでもよい。各パーティ１０３のコンピュータ機器１０２上のメモリは、処理装置上で動作するように配置された少なくとも１つのクライアントアプリケーション１０５のそれぞれのインスタンスを含むソフトウェアを記憶する。所与のノード１０４に属するいずれの動作も、それぞれのコンピュータ機器１０２の処理装置上で実行されるソフトウェアを使用することにより実行され得ることが理解されよう。各パーティ１０３のコンピュータ機器１０２は、少なくとも１つのユーザ端末、例えばデスクトップ又はラップトップコンピュータ、タブレット、スマートフォン、又はスマートウォッチのようなウェアラブルデバイスを備えている。所与のパーティ１０３のコンピュータ装置１０２は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースのような、１つ以上の他のネットワーク接続されたリソースを含んでもよい。
クライアントアプリケーション１０５は、最初に、１つ以上の適切なコンピュータ読取可能な記憶媒体、例えばサーバからダウンロードされたもの、又はリムーバブルSSD、フラッシュ・メモリ・キー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピー・ディスク又はテープ、光ディスク、例えばCD又はDVD ROM、又はリムーバブル光学ドライブなどのリムーバブル記憶装置上で、任意の所与のパーティ１０３のコンピュータ機器１０２に提供され得る。
クライアントアプリケーション１０５は、少なくとも「ウォレット」機能を備える。これには主に２つの機能を有する。これらのうちの１つは、それぞれのユーザパーティ１０３が、ノード１０４のネットワーク全体にわたって伝播され、それによってブロックチェーン１５０に含まれるトランザクション１５２を作成し、署名し、送信することを可能にすることである。もう１つは、現在所有しているデジタルアセットの量をそれぞれのパーティに報告することである。アウトプットベースのシステムでは、この第２の機能は、当該パーティに属するブロックチェーン１５０全体に散在する様々なトランザクション１５２のアウトプットの中で定義される量を照合することを含む。
注：種々のクライアント機能が所与のクライアントアプリケーション１０５に統合されるとして説明されることがあるが、これは、必ずしも限定的ではなく、代わりに、本願明細書に記載される任意のクライアント機能が２つ以上の異なるアプリケーションのスーツに実装されてよく、例えばAPIを介してインタフェースし、又は一方が他方へのプラグインである。より一般的には、クライアント機能は、アプリケーションレイヤ、又はオペレーティングシステムのような下位レイヤ、又はこれらの任意の組合せにおいて実装され得る。以下は、クライアントアプリケーション１０５の観点で説明されるが、これは限定的ではないことが理解される。
各コンピュータ機器１０２上のクライアントアプリケーション又はソフトウェア１０５のインスタンスは、P２Pネットワーク１０６の転送ノード１０４Fの少なくとも１つに動作可能に結合される。これにより、クライアント１０５のウォレット機能は、トランザクション１５２をネットワーク１０６に送信することができる。クライアント１０５は、また、記憶ノード１０４のうちの１つ、一部、又は全部にコンタクトして、それぞれのパーティ１０３が受領者である任意のトランザクションについてブロックチェーン１５０に問い合わせることができる(又は、実施形態では、ブロックチェーン１５０は、部分的にその公開視認性を通じてトランザクションの信頼を提供する公開的設備であるため、実際には、ブロックチェーン１５０内の他のパーティのトランザクションを検査する)。各コンピュータ機器１０２上のウォレット機能は、トランザクションプロトコルに従ってトランザクション１５２を形成し、送信するように構成される。各ノード１０４は、ノードプロトコルに従ってトランザクション１５２を検証するように構成されたソフトウェア４００を実行し、転送ノード１０４Fの場合は、ネットワーク１０６全体にトランザクション１５２を伝播させるためにトランザクション１５２を転送する。トランザクションプロトコルとノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルと共に所与のトランザクションモデルを実装する。同じトランザクションプロトコルが、ブロックチェーン１５０内の全てのトランザクション１５２に使用される(ただし、トランザクションプロトコルは、トランザクションの異なるサブタイプを許可することができる)。同じノードプロトコルは、ネットワーク１０６内の全てのノード１０４によって使用される(ただし、多くのノードは、そのサブタイプに対して定義されたルールに従って異なるトランザクションのサブタイプを異なるように処理し、また、異なるノードは異なる役割を引き受け、従って、プロトコルの異なる対応する側面を実装することができる)。
上述のように、ブロックチェーン１５０は、ブロック１５１のチェーンを含み、各ブロック１５１は、前述のように、proof-of-workプロセスによって作成された１つ以上のトランザクション１５２のセットを含む。各ブロック１５１は、また、ブロック１５１への逐次的順序を定義するように、チェーン内の先に生成されたブロック１５１を遡ってポイントするブロックポインタ１５５を含む。ブロックチェーン１５０はまた、proof-of-workプロセスによって新しいブロックに含まれることを待つ有効なトランザクション１５４のプールを含む。各トランザクション１５２は、トランザクションのシーケンスに順序を定義するために、前のトランザクションへのポインタを含む(注：トランザクション１５２のシーケンスは、分岐することが許される)。ブロック１５１のチェーンは、チェーンの最初のブロックであったジェネシスブロック（genesis block (Gb)）１５３にまで戻る。チェーン１５０の初期に１つ以上のオリジナルトランザクション１５２は、先行するトランザクションではなくジェネシスブロック１５３を指し示した。
所与のパーティ１０３、例えばAliceがブロックチェーン１５０に含まれる新たなトランザクション１５２jを送信したいと望む場合、彼女は関連するトランザクションプロトコルに従って(彼女のクライアントアプリケーション１０５のウォレット機能を使用して)新たなトランザクションを定式化する（formulate）。次に、クライアントアプリケーション１０５からトランザクション１５２を、彼女が接続されている１つ以上の転送ノード１０４Fの１つに送信する。例えば、これは、Aliceのコンピュータ１０２に最も近いか又は最も良好に接続されている転送ノード１０４Fであってもよい。任意の所与のノード１０４が新しいトランザクション１５２jを受信すると、ノードプロトコル及びそのそれぞれの役割に従って、それを処理する。これは、最初に、新たに受信されたトランザクション１５２jが「有効」であるための特定の条件を満たしているかどうかをチェックすることを含み、その例については、簡単に詳述する。幾つかのトランザクションプロトコルでは、検証のための条件は、トランザクション１５２に含まれるスクリプトによってトランザクションごとに構成可能であってよい。或いは、条件は単にノードプロトコルの組み込み機能であってもよく、或いはスクリプトとノードプロトコルの組み合わせによって定義されてもよい。
新たに受信されたトランザクション１５２jが、有効であると見なされるテストに合格したという条件で(すなわち、「有効である」という条件で)、トランザクション１５２jを受信した任意の記憶ノード１０４Sは、そのノード１０４Sに維持されているブロックチェーン１５０のコピー内のプール１５４に、新たに有効とされたトランザクション１５２を追加する。さらに、トランザクション１５２jを受信する任意の転送ノード１０４Fは、検証済みトランザクション１５２をP２Pネットワーク１０６内の１つ以上の他のノード１０４に伝播する。各転送ノード１０４Fは同じプロトコルを適用するので、トランザクション１５２jが有効であると仮定すると、これは、P２Pネットワーク１０６全体に間もなく伝播されることを意味する。
ひとたび１つ以上の記憶ノード１０４で維持されるブロックチェーン１５０のコピー内のプール１５４に入ると、マイナーノード１０４Mは、新しいトランザクション１５２を含むプール１５４の最新バージョンのproof-of-workパズルを解決するために競争を開始する(他のマイナー１０４Mは、依然として、プール１５４の古いビューに基づいてパズルを解決しようとしているが、そこに到達した者は誰でも、最初に、次の新しいブロック１５１が終了し、新しいプール１５４が開始する場所を定義し、最終的には、誰かが、Aliceのトランザクション１５２jを含むプール１５４の一部のパズルを解決する)。一旦、新しいトランザクション１５２jを含むプール１５４についてproof-of-workが行われると、ブロックチェーン１５０内のブロック１５１の１つの一部となる。各トランザクション１５２は、以前のトランザクションへのポインタを含むので、トランザクションの順序もまた、不変的に記録される。
異なるノード１０４は、最初に所与のトランザクションの異なるインスタンスを受信する可能性があり、従って、１つのインスタンスがマイニングされてブロック１５０になる前に、どのインスタンスが「有効」であるかについて矛盾するビューを有することがあり、その時点で、全部のノード１０４は、マイニングされたインスタンスのみが有効なインスタンスであることに合意する。ノード１０４が１つのインスタンスを有効であるとして受け入れ、次に第２のインスタンスがブロックチェーン１５０に記録されていることを発見した場合、該ノード１０４は、これを受け入れなければならず、最初に受け入れた未だマイニングされていないインスタンスを破棄する（つまり、無効であるとして扱う）。
＜UTXOに基づくモデル＞
図２は、トランザクションプロトコルの例を示している。これは、UTXOベースのプロトコルの例である。トランザクション１５２(「Tx」と略す)は、ブロックチェーン１５０(各ブロック１５１は１つ以上のトランザクション１５２を含む)の基本的なデータ構造である。以下は、アウトプットベース又は「UTXO」ベースのプロトコルを参照して説明される。しかし、これは、全ての可能な実施形態に限定されるものではない。
UTXOベースのモデルでは、各トランザクション(「Tx」)１５２は、１つ以上のインプット２０２及び１つ以上のアウトプット２０３を含むデータ構造を含む。各アウトプット２０３は、未使用トランザクションアウトプット(UTXO)を含んでもよく、これは、別の新しいトランザクションのインプット２０２のソースとして使用することができる(UTXOが未だ償還されていない場合)。UTXOは、デジタルアセット（値のストア）の量を指定する。それは、情報の中でも特にその元となったトランザクションのトランザクションIDを含む。トランザクションデータ構造はまた、ヘッダ２０１も含んでよく、ヘッダ２０１は、インプットフィールド２０２及びアウトプットフィールド２０３のサイズの指示子を含んでもよいヘッダ２０１を含んでよい。ヘッダ２０１は、トランザクションのIDも含んでもよい。実施形態において、トランザクションIDは、トランザクションデータのハッシュ(トランザクションID自体を除く)であり、マイナー１０４Mに提出された未処理トランザクション１５２のヘッダ２０１に格納される。
例えば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，capital S)と呼ばれる。ロックスクリプトは、トランザクションアウトプット２０３を消費するために必要な情報、例えば、Aliceの署名の必要条件を指定する。トランザクションのアウトプットには、アンロックスクリプトが現れる。アンロックスクリプト(別名：scriptSig)は、ロックスクリプトの基準を満たすために必要な情報を提供するドメイン固有の言語で書かれたコードの一部である。例えば、Bobの署名を含んでもよい。アンロックスクリプトは、トランザクションのインプット２０２に現れる。
図示の例では、Tx０のアウトプット２０３のUTXO０は、ロックスクリプト[ChecksigPA]を含み、これは、UTXO０が償還されるために(厳密には、UTXO０を償還しようとする後続のトランザクションが有効であるために)、Aliceの署名SigPAを必要とする。[ChecksigPA]は、Aliceの公開－秘密鍵ペアからの公開鍵PAを含む。Tx１のインプット２０２は、Tx１を指すポインタ(例えば、そのトランザクションID、実施形態ではトランザクションTx０全体のハッシュであるTxID０による)を含む。Tx１のインプット２０２は、Tx０の任意の他の可能なアウトプットの中でそれを識別するために、Tx０内のUTXO０を識別するインデックスを含む。Tx１のインプット２０２は、さらに、Aliceが鍵ペアからのAliceの秘密鍵をデータの所定の部分(暗号において「メッセージ」と呼ばれることもある)に適用することによって作成された、Aliceの暗号署名を含むアンロックスクリプト<SigPA>を含む。有効な署名を提供するためにAliceが署名する必要があるデータ(又は「メッセージ」)は、ロックスクリプトにより、又はノードプロトコルにより、又はこれらの組み合わせによって定義され得る。
新しいトランザクションTx１がノード１０４に到着すると、ノードはノードプロトコルを適用する。これは、ロックスクリプトとアンロックスクリプトを一緒に実行して、アンロックスクリプトがロックスクリプトで定義されている条件(この条件は１つ以上の基準を含むことができる)を満たしているかどうかをチェックすることを含む。実施形態では、これは、２つのスクリプトの連結を含む。
Figure 2022533753000005
ここで、「||」は連結を表し、「<...>」はスタックにデータを配置することを意味し、「[...]」はアンロックスクリプトに含まれる機能である（本例では、スタックベースの言語）。同等に、スクリプトは。、スクリプトを連結するのではなく共通のスタックにより１つずつ実行されてよい。いずれの方法でも、一緒に実行する場合、スクリプトは、Tx０のアウトプット内のロックスクリプトに含まれるAliceの公開鍵PAを使用して、Tx１のインプット内のロックスクリプトが、データの期待部分に署名するAliceの署名を含むことを認証する。また、データの期待部分自体(「メッセージ」)も、この認証を実行するためにTx０に含まれる必要がある。実施形態において、署名されたデータは、Tx０の全体を含む(従って、別個の要素は、データの署名された部分がすでに本質的に存在するので、データの署名された部分の指定に明確に含まれる必要がある)。
公開－秘密暗号法による認証の詳細は、当業者には周知であろう。基本的に、Aliceが彼女の秘密鍵によりメッセージを暗号化することによってメッセージに署名した場合、Aliceの公開鍵とそのメッセージが明らか(暗号化されていないメッセージ)ならば、ノード１０４のような別のエンティティは、そのメッセージの暗号化されたバージョンがAliceによって署名されていなければならないことを認証することができる。署名は、典型的には、メッセージをハッシュし、ハッシュに署名し、署名としてメッセージのクリアなバージョンにこれをタグ付けすることによって、公開鍵の所有者が署名を認証することを可能にする。従って、実施形態では、特定のデータ片又はトランザクションの部分等に署名するという言及は、データ片又はトランザクションの部分のハッシュに署名することを意味し得る。
Tx１内のアンロックスクリプトが、Tx０のロックスクリプトで指定された１つ以上の条件を満たす場合(示される例では、Aliceの署名がTx１内で提供され、認証されている場合)、ノード１０４は、Tx１が有効であるとみなす。それが記憶ノード１０４Sである場合、これは、proof-of-workを待つトランザクションのプール１５４にそれを追加することを意味する。それが転送ノード１０４Fである場合、それはトランザクション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０はマイナーのノード１０４Mによって拒否される可能性が高く、したがって、技術的には有効であるが、それは依然として伝搬されず、ブロックチェーン１５０に含まれない（マイナーのプロトコルは、マイナーが望まない場合には、マイナー１０４Mにトランザクション１５２を受け入れるよう強制しない)。一部のプロトコルでは、マイニング料金は、独自の別個のアウトプット２０３を必要としない(すなわち、別個のUTXOを必要としない)。代わりに、インプット２０２によって指される総量と、所与のトランザクション１５２のアウトプット２０３の中で指定される総量との間の差は、勝ったマイナー１０４に自動的に与えられる。例えば、UTXO０へのポインタがTx１への唯一のインプットであり、Tx１は１つのアウトプットUTXO１しか持っていないとする。UTXO０で指定されたデジタルアセットの量がUTXO１で指定された量より多い場合、その差は自動的に勝ったマイナー１０４Mへ行く。しかし、代替的又は追加的に、必ずしも、トランザクション１５２のUTXO２０３のうちの独自のものにおいて、マイナー手数料を明示的に指定できることは除外されない。
Alice及びBobのデジタルアセットは、ブロックチェーン１５０内の任意のトランザクション１５２の中で彼らにロックされた未使用UTXOで構成されている。従って、典型的には、所与のパーティ１０３のアセットは、ブロックチェーン１５０を通して、様々なトランザクション１５２のUTXO全体に分散される。ブロックチェーン１５０内のどこにも、所与のパーティ１０３の総残高を定義する１つの数値は記憶されていない。各パーティへのロックされた、別の将来の（onward）トランザクションに未だ消費されていない全ての様々なUTXOの値をまとめることは、クライアントアプリケーション１０５におけるウォレット機能の役割である。これは、記憶ノード１０４Sのいずれかに記憶されたブロックチェーン１５０のコピーを、例えば、各パーティのコンピュータ機器０２に最も近いか、又は最も良好に接続されている記憶ノード１０４Sに問い合わせることによって行うことができる。
スクリプトコードは、概略的に表現されることが多い(すなわち、正確な言語ではない)ことに注意する。例えば、[Checksig PA]を以下を意味するように記述しできる：
Figure 2022533753000006
「OP_....」は、スクリプト言語の特定のオペコードを表す。OP_CHECKSIG(「Checksig」とも呼ばれる)は、２つのインプット(署名と公開鍵)を取り込み、楕円曲線デジタル署名アルゴリズム(Elliptic Curve Digital Signature Algorithm (ECDSA))を使用して署名の妥当性を検証するスクリプトオペコードである。ランタイムでは、署名(「sig」')の発生はスクリプトから削除されるが、ハッシュパズルなどの追加要件は、「sig」インプットによって検証されるトランザクションに残る。別の例として、OP_RETURNは、トランザクション内にメタデータを格納することができ、それによってメタデータをブロックチェーン１５０に不変に記録することができるトランザクションの使用不可能アウトプットを生成するためのスクリプト言語のオペコードである。例えば、メタデータは、ブロックチェーンに格納することが望ましいドキュメントを含むことができる。
注：表記<H(x)>は、「値hをスタックにプッシュする」を意味する。ここで、値h=H(x)は、アンロックスクリプト内で提供され、H又はxを提供しない。
署名PAは、デジタル署名である。実施形態において、これは楕円曲線secp２５６k１を使用するECDSAに基づく。デジタル署名は、特定のデータに署名する。実施形態では、所与のトランザクションについて、署名はトランザクションインプットの一部、及びトランザクションアウトプットの全部又は一部に署名する。署名するアウトプットの特定の部分はSIGHASHフラグに依存する。SIGHASHフラグは、署名の最後に含まれる４バイトのコードであり、どのアウトプットが署名されるかを選択する(従って、署名の時点で固定される)。
ロックスクリプトは、それぞれのトランザクションがロックされているパーティの公開鍵を含んでいることを表す「scriptPubKey」と呼ばれることがある。アンロックスクリプトは、対応する署名を提供することを表す「scriptSig」と呼ばれることがある。しかし、より一般的には、UTXOが償還される条件が署名を認証することを含むことは、ブロックチェーン１５０の全てのアプリケーションにおいて必須ではない。より一般的には、スクリプト言語は、１つ以上の条件を定義するために使用され得る。したがって、より一般的な用語「ロックスクリプト」及び「アンロックスクリプト」が好ましい。
＜任意的なサイドチャネル＞
図３は、ブロックチェーン１５０を実装するための更なるシステム１００を示す。システム１００は、追加の通信機能が含まれることを除いて、図１に関連して説明したものと実質的に同じである。Alice及びBobのコンピュータ機器１０２a、１０２bの各々に存在するクライアントアプリケーションは、それぞれ、追加通信機能を含む。つまり、それは、Alice１０３ａが、(いずれかのパーティ又は第三者の勧誘で)Bob１０３ｂとの別個のサイドチャネル３０１を確立することを可能にする。サイドチャネル３０１は、P２Pネットワークと別個にデータの交換を可能にする。このような通信は、時に「オフチェーン」と呼ばれる。例えば、これは、パーティのうちの一方がトランザクションをネットワーク１０６にブロードキャストすることを選択するまで、トランザクションがネットワークP２P１０６に（未だ）発行されることなく、又はチェーン１５０上でそのようにすることなく、AliceとBobとの間でトランザクション１５２を交換するために使用されてよい。代替又は追加で、サイドチャネル３０１は、任意の他のトランザクションに関連するデータ、例えば、鍵、交渉される量又は条項、データコンテンツ、等を交換するために使用されてよい。
サイドチャネル３０１は、P２Pオーバレイネットワーク１０６と同じパケット交換ネットワーク１０１を介して確立されてもよい。代替又は追加で、サイドチャネル３０１は、モバイルセルラネットワーク、又はローカル無線ネットワークのようなローカルエリアネットワーク、又はAliceとBobの装置１０２a、１０２bの間の直接有線若しくは無線リンクのような異なるネットワークを介して確立されてよい。一般に、本願明細書のどこかで言及されるサイドチャネル３０１は、「オフチェーン」で、つまりP２Pオーバレイネットワーク１０６と別個にデータを交換するための１つ以上のネットワーキング技術又は通信媒体を介する任意の１つ以上のリンクを含んでよい。１つより多くのリンクが使用されるとき、全体としてのオフチェーンリンクのバンドル又は集合がサイドチャネル３０１と呼ばれてよい。従って、Alice及びBobが特定の情報又はデータ片等をサイドチャネル３０１を介して交換すると言われる場合、これは、必ずしも全部のこれらのデータ片が正確に同じリンク又は同じ種類のネットワークを介して送信される必要があることを意味しないことに留意する。
＜ノードソフトウェア＞
図４は、UTXO又はアウトプットに基づくモデルの例における、P２Pネットワーク１０６の各ノード１０４で実行され得るノードソフトウェア４００の例を示す。ノードソフトウェア４００は、プロトコルエンジン４０１、スクリプトエンジン４０２、スタック４０３、アプリケーションレベルの決定エンジン４０４、及び１つ以上のブロックチェーン関連機能モジュールのセット４０５を含む。任意の所与のノード１０４で、これらは、（ノードの１つ以上の役割に依存して）マイニングモジュール４０５M、転送モジュール４０５F、及び格納モジュール４０５S、のうちの任意の１、２、又は３個全部を含んでよい。プロトコルエンジン４０１は、トランザクション１５２の異なるフィールドを認識し、それらをノードプロトコルに従い処理するよう構成される。トランザクション１５２m（Txm）が受信され、別の先行するトランザクション１５２m-１（Txm-１）のアウトプット（例えばUTXO）をポイントするインプットを有するとき、プロトコルエンジン４０１は、Txm内のアンロックスクリプトを識別し、それをスクリプトエンジン４０２に渡す。プロトコルエンジン４０１は、更に、Txmのインプットの中のポインタに基づき、Txm-１を識別し検索する。それは、Txm-１が未だブロックチェーン１５０上にない場合、それぞれのノード自身の保留中トランザクションのプール１５４から、又はTxm-１が既にブロックチェーン１５０上にある場合、それぞれのノード若しくは別のノード１０４に格納されたブロックチェーン１５０内のブロック１５１のコピーから、Txm-１を検索してよい。いずれの方法も、スクリプトエンジン４０１は、Txm-１のポイントされるアウトプットの中のロックスクリプトを識別し、これをスクリプトエンジン４０２に渡す。
スクリプトエンジン４０２は、従って、Txm-１のロックスクリプト、及びTxmの対応するインプットからのアンロックスクリプトを有する。例えば、Tx１及びTx２が図４に示されるが、Tx０及びTx１等のようなトランザクションの任意のペアについても同様である。スクリプトエンジン４０２は、前述のように２つのスクリプトを一緒に実行し、これらは、使用されているスタックに基づくスクリプト言語（例えばScript）に従い、スタック４０３にデータを置くことと、データを検索することとを含む。
スクリプトを一緒に実行することにより、スクリプトエンジン４０２は、アンロックスクリプトがロックスクリプトの中で定義された１つ以上の基準を満たすか否か、つまり、それがロックスクリプトが含まれるアウトプットを「アンロック」するか否かを決定する。スクリプトエンジン４０２は、この決定の結果をプロトコルエンジン４０１に返す。スクリプトエンジン４０２は、アンロックスクリプトは対応するロックスクリプトの中で指定された１つ以上の基準を満たすと決定した場合、結果「真」を返す。その他の場合、それは結果「偽」を返す。
アウトプットに基づくモデルでは、スクリプトエンジン４０２からの結果「真」は、トランザクションの有効性についての条件のうちの１つである。標準的に、同様に満たされなければならない、プロトコルエンジン４０１により評価される１つ以上の更なるプロトコルレベルの条件が更にあり、Txmのアウトプットの中で指定されたデジタルアセットの総量がそのインプットによりポイントされる総量を超えないこと、Txm-１のポイントされるアウトプットは別の有効なトランザクションにより未だ使用されていないこと、等である。プロトコルエンジン４０１は、１つ以上のプロトコルレベルの条件と一緒にスクリプトエンジン４０２からの結果を評価し、それら全部が真である場合、トランザクションTxmを検証する。プロトコルエンジン４０１は、トランザクションが有効であるかどうかの指示を、アプリケーションレベル決定エンジン４０４に出力する。Txmが実際に検証されたことのみを条件として、決定エンジン４０４は、マイニングモジュール４０５M及び転送モジュール４０５Fの一方又は両方を、それらのそれぞれのブロックチェーンに関連する機能をTxmに関して実行するよう制御することを選択してよい。これは、マイニングモジュール４０５Mがマイニングしてブロック１５１にするためにTxmをノードのそれぞれのプール１５４に追加すること、及び／又は、転送モジュール４０５FがTxmをP２Pネットワーク１０６内の別のノード１０４へ転送することを含んでよい。しかしながら、実施形態では、決定エンジン４０４は無効なトランザクションを転送し又はマイニングすることを選択しないが、逆に言えば、これは必ずしも、単に有効であるという理由で、有効なトランザクションのマイニング又は転送をトリガしなければならないことを意味するものではないことに留意する。任意的に、実施形態では、決定エンジン４０４は、これらの機能のうちのいずれか又は両方をトリガする前に、１つ以上の追加条件を適用してよい。例えば、ノードがマイニングノード１０４Mである場合、決定エンジンは、トランザクションが有効であること、及び十分なマイニング手数料が残されることの両方を条件としてのみ、トランザクションをマイニングすることを選択してよい。
用語「真（true）」及び「偽（false）」は、本願明細書では、必ずしも単一の２進数字（ビット）のみの形式で表現される結果を返すことに限定しないが、それは勿論１つの可能な実装であることに留意する。より一般的には、「真」は、成功又は肯定的な結果を示す任意の状態を表すことができ、「偽」は、不成功又は非肯定的な結果を示す任意の状態を表すことができる。例えば、アカウントに基づくモデルでは（図４に示されない）、「真」の結果は、ノード１０４による署名の暗示的なプロトコルレベルの検証と、スマートコントラクトの追加の肯定的なアウトプットとの組合せにより示され得る（全体の結果は、両方の個々の結果が真である場合に、真を伝達すると考えられる）。
＜例示的なトランザクションセット＞
図５は、本願明細書に開示される実施形態に従い使用するためのトランザクション１５２のセットを示す。セットは、第０トランザクションTx０、第１トランザクションTx１、及び第２トランザクションTx２.を含む。「第０」、「第１」、及び「第２」は、単なる便宜上のラベルであることに留意する。それらは、必ずしも、これらのトランザクションが直ちに１つずつブロック１５１又はブロックチェーン１５０内に置かれること、又は第０トランザクションがブロック１５１又はブロックチェーン１５０内の最初のトランザクションであることを意味しない。また、これらのラベルは、それらのトランザクションがネットワーク１０６へ送信される順序に関して何も示唆しない。それらは、単に、１つのトランザクションのアウトプットが次のトランザクションのインプットによりポイントされる論理的シリーズを表す。幾つかのシステムでは、親をその子の後にネットワーク１０６へ送信することが可能であることを思い出してほしい（この場合、「親のない」子がある期間の間、１つ以上のノード１０４においてバッファされ、その間、親が到着するのを待っている）。
第０トランザクションTx０は、本発明の目的のためにソーストランザクションと呼ばれてもよく、Alice１０３aへのロックされたデジタルアセットの量のソースとして機能する。第１トランザクションTx１は、本発明の目的のためにチャレンジトランザクション又はパズルトランザクションと呼ばれてもよい。それは、第２トランザクションTx２がrパズルに対する解を提供することに依存して、ソーストランザクションTx０からデジタルアセットの量を条件付きで移転するための仲介として機能する。第２トランザクションTx２は、証明トランザクション又は支払いトランザクションと呼ばれてもよく、第１トランザクションTx１内に設定されたrパズルに対する解を提供し、結果として生じる証明者（又は場合によっては、証明者が代表を務める受益者）への支払いをロックするトランザクションである。実施形態は、証明者（第２パーティ）がBobになるが、後の議論に基づき認められ、実際にrパズルが、任意の第２パーティがrパズルを解く有効な署名を提供する限り、アイデンティティに関係なく、彼らが証明者になることを許容する例を用いて説明され得る。
図５に示すように、ソーストランザクションTx０は、デジタルアセットの量を指定する少なくとも１つのアウトプット２０３０（例えば、Tx０のアウトプット０）、及びAlice１０３aへのこのアウトプットをロックするロックスクリプトを更に含む。これは、ソーストランザクションTx０のロックスクリプトが、少なくとも１つの条件が満たされることを要求することを意味する。この条件は、アウトプットをアンロックしようとする（従って、デジタルアセットの量を償還する）任意のトランザクションのインプットが、そのアンロックスクリプト内にAliceの暗号署名（つまり、Aliceの公開鍵を使用する）を含まなければならないことである。この意味で、Tx０のアウトプット内で定義される量は、Aliceにより所有されると言える。アウトプットは、 UTXOと呼ばれてよい。どの先行するトランザクションのアウトプットがTx０のインプットをポイントするかは（それらが、Tx０の合計アウトプットをカバーするのに十分である限り）、本発明の目的のために特に重要ではない。
本発明の場合には、ソーストランザクションTx０のアウトプットをアンロックするトランザクションは、第１トランザクションTx１（チャレンジトランザクション）である。従って、Tx１は、Tx０の関連するアウトプット（図示の例ではTx０のアウトプット０）へのポインタを含み及び該アウトプットのロックスクリプト内で定義された条件に従いTx０のポイントされたアウトプットをアンロックするよう構成される、少なくともAliceの署名を要求するアンロックスクリプトを更に含む、少なくとも１つのインプット２０２１（例えばTx１のインプット０）を有する。Tx０のロックスクリプトにより要求されるAliceからの署名は、Tx１の特定の部分に署名することが要求される。幾つかのプロトコルでは、署名される必要のあるTx１の部分は、Tx１のアンロックスクリプト内で定義された設定であり得る。例えば、これは、署名に付加される１バイトであるSIGHASHフラグにより設定されてよい。従って、データの観点では、アンロックスクリプトは次の通りである：<Sig PA><sighashflag><PA>代替として、署名される必要のある部分は、単にTx１.の固定又はデフォルト部分であってよい。いずれの方法も、署名されるべき部分は、標準的に、アンロックスクリプト自体を除き、及びTx１のインプットの一部又は全部を除いてよい。しかしながら、Tx１の署名済み部分は、少なくとも、rパズルを含むアウトプット２０３１を含む（以下を参照、本例ではTx１のアウトプット０）。
第１トランザクションTx１は、少なくとも１つのアウトプット２０３１（例えば、ここでもアウトプットがUTXOと呼ばれてよいTx１のアウトプット０）を有する。第１トランザクションTx１のアウトプットは、任意の１つのパーティにロックされない。Tx０と同様に、それは、転送されるべきデジタルアセットの量を指定する少なくとも１つのアウトプット（例えば、Tx１のアウトプット０）を有する。該アウトプットは、該アウトプットをアンロックする、従って該量を償還するために何が必要かを定義するロックスクリプトを更に含む。しかしながら、このロックスクリプトは、rパズルの解を提供する任意のパーティによりアンロックされることが可能である。
第２トランザクション（支払いトランザクション）Tx２は、少なくとも１つのインプット２０２２（例えば、Tx２のインプット０）を有し、該インプットは、Tx１の上述のアウトプット（図示の例ではTx１のアウトプット０）へのポインタを含み、Tx１のロックスクリプトの中で定義されたアンロックスクリプトの１つ以上の要件を満たすことに基づきTx１の該アウトプットをアンロックするよう構成されるアンロックスクリプトも更に含む。本願明細書に開示される実施形態によると、アンロック条件は、少なくとも、対応するアンロックスクリプトがrパズルに対する解を含むという要件を含む。rパズルは、楕円曲線暗号（elliptical curve cryptography (ECC)）署名のr部分に基づきTx１のロックスクリプト内で定義されるチャレンジを含む。これは、Tx２のアンロックスクリプトに彼らの署名（又は少なくともそのs部分）を含む任意のパーティ（この場合にはたまたまBobである）により満たされることができる。Tx０のロックスクリプトと異なり、任意のパーティの署名は、それがrチャレンジ（つまり、rパズル）を満たす有効な署名である限り、Tx１のロック条件をアンロックするために使用できる。これの例は、間もなく更に詳細に議論される。Bobは、単に、証明者又は第２パーティの例としてここで選択されたが、rパズルは、実際には、任意の第２パーティ、例えば、Charlie、Dora、Ezekiel、等が証明者になることを許容する。幾つかの実施形態では、Tx）１内のアンロック条件は、１つ以上の更なる条件を条件としても生成され得る。例えば、Aliceの署名がTx２のアンロックスクリプトにも含まれることを要求する。
第２トランザクションTx２は、少なくとも１つのアウトプット２０２２（例えば、Tx２のアウトプット０）を有し、該アウトプットは、Bobへ移転すべきデジタルアセットの量、及びこれをBobに対してロックするロックスクリプトを指定する（つまり、これは、更なる、今後のトランザクションが、使用するためにアンロックスクリプトの中にBobの署名を含むことが要求される）。この意味で、ターゲットトランザクションTx２のアウトプットは、Bobにより所有されると言える。このアウトプットは、ここでもUTXOと呼ばれてよい。
証明者の署名（例えば、Bobの場合にはSig PB）により署名されたTx２の部分は、少なくとも、このアウトプット２０３２、つまり証明者への支払いをロックするアウトプット（本例では、Tx２）のアウトプット０）を含む。
実施形態では、Tx１内のアウトプット２０３１内のロックスクリプトがアウトプットをアンロックするための複数の代替条件、例えば複数の代替のｒパズルを定義することが可能である。この場合、Ｔｘ２のインプット２０２２内のアンロックスクリプトは、それが代替アンロック条件のうちのいずれか１つを満たす場合、Tx１のアウトプットをアンロックする。
第０（つまり、ソース）トランザクションTx０は、Alice、証明者（例えば、Bob）、又は第三者により生成されてよい。それは、標準的に、AliceがTx０のインプット内に定義された量を取得した先行するパーティの署名を要求する。それは、Alice、Bob、先行するパーティ、又は別の第三者によりネットワーク１０６へ送信されてよい。
第１トランザクション（つまり、チャレンジトランザクション）Tx１は、Alice、証明者（例えば、Bob）、又は第三者により生成されてもよい。実施形態では、それはAliceの署名を要求するので、それはAliceにより生成されてよい。代替として、それは、Bob又は第三者によりテンプレートとして生成され、次に署名のためにAliceへ送信されてよく、例えばサイドチャネル３０１を介して送信される。Aliceは、次に、署名付きトランザクションをネットワーク１０６へ彼女自身で送信し、又はそれをBob若しくは第三者へ送信してそれらをネットワーク１０６へ転送し、又は単に彼女の署名をBob若しくは第三者へ送信して、署名付きTx１に構成してネットワーク１０６へ転送できる。Tx１をネットワーク１０６へ送信する前の任意のオフチェーン交換は、サイドチャネル３０１を介して実行されてよい。
第２トランザクション（つまり、証明又は支払いトランザクション）Tx２は、Alice、証明者（例えば、Bob）、又は第三者により生成されてよい。第１バージョンは証明者の署名及び／又はデータを要求するので、Bobにより生成されてよい。代替として、それは、Alice又は第三者によりテンプレートとして生成され、次に、署名するためにBobへ送信されてよく、例えば、サイドチャネル３０１を介してBobへ送信される。Bobは、次に、署名付きトランザクションをネットワーク１０６へ彼自身で送信し、又はそれをAlice若しくは第三者へ送信してそれらをネットワーク１０６へ転送し、又は単に彼の署名をAlice若しくは第三者へ送信して、署名付きTx２に構成してネットワークへ転送できる。
トランザクションの異なる要素が生成され構成され得る種々の位置があり、それが直接に又は間接的にP２Pネットワーク１０６の最終的な宛先へと送信される種々の方法があることが理解される。開示の技術の実装の範囲は、これらのいずれに関しても限定されない。
「Aliceにより」、「Bobにより」、及び「第三者により」のような語句は、本願明細書では、それぞれ「Aliceのコンピュータ機器１０２aにより」、「Bobのコンピュータ機器１０２bにより」、及び「第三者のコンピュータ機器１０２により」の短縮表現として使用されることがある。また、所与のパーティの機器は、該パーティにより使用される１つ以上のユーザ装置、又は該パーティにより利用されるクラウドリソースのような幾つかのサーバリソース、又はそれらの任意の組合せを含み得ることに留意する。それは、必ずしも動作が単一のユーザ装置上で実行されることに限定しない。
＜楕円曲線デジタル署名アルゴリズム（ELIPTICAL CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)）＞
公開鍵暗号法は、多数の異なるブロックチェーンアーキテクチャにおいてトランザクションをセキュアにするための基礎として使用される。公開鍵暗号法の使用は、公開鍵暗号化及びデジタル署名方式を含む。公開鍵暗号法は、特定の関数が、計算するのは容易だが、何からの特定の知識が無くては逆算（reverse）することが困難であるという原理に基づいている。そのような関数は、落とし戸関数（trapdoor function）と呼ばれ、それを逆算するために必要な特定の知識は該関数の落とし戸（トラップドア）と呼ばれる。計算するのが容易であることは、所与の入力（又は入力のセット）について妥当な時間枠内で落とし戸関数を計算することが計算上実現可能であることを意味し、逆算が困難であることは、落とし戸の知識を有しないで結果から該入力（又は複数の該入力）を推定することが計算上不可能であることを意味する。
公開鍵暗号法の文脈では、鍵ペアは、公開鍵（これは誰にでも自由に入手可能にできる）及び対応する秘密鍵（これは、特定のエンティティ又はグループにのみ知られているという意味で、秘密であると想定される）を意味する。公開鍵は落とし戸関数を定義し、対応する秘密鍵は該関数を逆算するために必要な落とし戸である。
公開鍵暗号の文脈では、暗号化は、落とし戸関数に基づき（つまり、暗号化は「順方向」に実行され）、一方で、復号は、落とし戸が分かっているときにのみ実現可能である落とし戸関数の逆算に基づく（つまり、復号は、「逆方向」に実行される）。
デジタル署名の文脈では、署名検証は、公開鍵を用いて順方向に実行され、署名生成は、逆方向に実行され、秘密鍵を用いてのみ実行可能である。
ブロックチェーンの文脈では、公開鍵暗号法に基づくデジタル署名は、トランザクションに暗号法で署名するため及びトランザクション署名を検証するための基礎として使用される。
ECCは、楕円曲線の数学的特性を利用する形式の公開鍵暗号法であり、DSA（Digital Secure Algorithm）のような他の暗号方式に対して種々の利点を有する。
「楕円曲線デジタル署名アルゴリズム（Elliptic Curve Digital Signature Algorithm (ECDSA)）」は、デジタル署名生成及び検証のための基礎としてECCを使用するクラスのデジタル署名方式を表す。ECDSAの特定の原理は以下に概説される。
数学的用語では、ECCは、素数位数の有限体上の楕円曲線の代数的構造を利用する。有限体は、要素の有限の集合、並びに、集合内の要素に適用されるとき通常の算術規則（結合法則、可換性、等）を満たす乗算、加算、減算、及び除算の関連する演算のセットを意味する。つまり、「通常」の意味で、加算、乗算、等を必要としないが、本質的に同じように振る舞う、演算である。
楕円曲線演算：
ECCの文脈では、加算、減算、及び乗算演算は、それぞれ、本願明細書で「+」で示される楕円曲線点加算、本願明細書で「-」で示される楕円曲線点減算、及び本願明細書で「・」で示される楕円曲線点乗算である。加算及び減算演算は、それぞれ、楕円曲線上の２個の点に適用され、楕円曲線上の第３の点を返す。しかしながら、乗算演算は、スカラー及び楕円曲線上の単一の点に適用され、楕円曲線上の第２の点を返す。これに対して、除算は、スカラー上で定義される。
説明を目的として、図６Aは、全ての実数値の２次元座標の集合：
Figure 2022533753000007
 における楕円曲線εを示し、
Figure 2022533753000008
 は
Figure 2022533753000009
 の要素を示す。楕円曲線εは、次式を満たす点の集合である：
Figure 2022533753000010
加算：εの数学的特性は、楕円曲線ε上の任意の２個の点A、Bが与えられると、A及びBと交差する直線はεとCと示される１個の追加の点でのみ再び交差し；A及びBの楕円曲線加算、つまりA+Bは、Cの「反射（reflection）」として定義され、Cと交差する水平線を取ると、Cの反射は、該直線が交差する楕円曲線上の他方の点である。この定義は、∞と示される無限遠点を楕円曲線上の点として及びそこで任意の垂直線が楕円曲線と交差すると定義することにより（例えば、D及びEとラベル付けされた点が垂直方向及び水平方向に揃えられ、従ってD+E=∞である）、２個の点と交差する線が垂直である場合に当てはまる。この定義は、∞と示される無限遠点を楕円曲線上の点として及びそこで任意の垂直線が楕円曲線と交差すると定義することにより（例えば、D及びEとラベル付けされた点が垂直方向及び水平方向に揃えられ、従ってD+E=∞である）、２個の点と交差する線が垂直である場合に当てはまる。
減算／加算反数（Subtraction/additive inverse）：上述の反射の定義は、任意の点に適用され、楕円曲線点減算の定義を提供する。A-Bは、AとBの反射との和である。Bの反射は、より正式にはBの「加算反数」と呼ばれ、-Bと示される。この表記を用いて、楕円曲線減算は、数学的表記で定義できる：
Figure 2022533753000011
ここで、図６Bにおいて、C=-(A+B)及び(A+B)=-C。この定義の下で、D=-Eであり、代数構造の一般的規則を反映すること、つまり、楕円曲線上の任意の点とその加算反数との楕円点加算が無限遠点であることにも留意する。つまり、
Figure 2022533753000012
無限遠点∞は、より正式には、「単位元」と呼ばれる（通常の算術計算の平行と偏差の両方に留意する：通常の算術計算では、任意の数aとその加算反数-aとの和は０であり、０は通常の算術計算の単位元である）。単位元、通常の算術計算をミラーリングする∞の別の特性は、∞自体を含むε上の任意の点Aについて、A+∞=Aであることである（任意の実数aについて、ステートメントa+０=０と同様である）。
乗算：楕円曲線点加算の定義から、楕円曲線スカラー乗算の定義は以下の通りである。楕円曲線点Aの整数vとの乗算は次式のように定義される：
Figure 2022533753000013
つまり、Aのそれ自体とのv回の楕円曲線点加算としてである。
注：楕円曲線スカラー乗算は、従来、楕円曲線点乗算とも呼ばれている。これらの２つの用語は、本開示において同じ意味を有する。
除算／乗算反数（Division/multiplicative Inverse）：除算の延安は、スカラーに関して定義される。スカラーvが与えられると、「乗算反数」はスカラーv-１として定義され、その結果、以下の通りである：
Figure 2022533753000014
図６Aは、上述の演算の直感的視覚化を提供する。ここで、εは、全部の実数：
Figure 2022533753000015
 を含む無限体に渡り定義される。
図６Bは、次式により定義される楕円曲線εnを示すので、上述の演算が、ECCの文脈で実際にどのように適用されるかをより厳密に表す：
Figure 2022533753000016
ここで、pは素数（素数モジュラス）であり、modはモジュロ演算を示す。上式を満たす点の集合は有限であり、それらの点のうちの１つを除き全部が白丸として図６Bに示され、残りの点は単位元∞である。
素数pは、楕円曲線の定義の部分を形成し、自由に選択できる。楕円曲線が良好な暗号特性を有するためには、pは十分に大きくなければならない。例えば、２６５ビットのpが特定のブロックチェーンモデルにおいて指定される。
添え字「n」は、本願明細書では、以上に定義された点加算の下で楕円曲線点により形成されるグループの次数を表す（簡単に言うと、これは、楕円曲線εnの次数と呼ばれてよい）。以下を参照する。
言い換えると、nはグループの次数であり、pはフィールドの次数である。全部でn個の楕円曲線点がある。楕円曲線上の各点は、２個の数／座標（x,y）により表され、ここで、x及びyは、全部、範囲－(p-１),…０,…,(p-１)の中にある。
図６Bのεnは図６Aのεnと同様に水平対称性であることが分かる。これは、素数ファイル（prime file）に対する楕円曲線の一般的特性であり、従って、εn上の点の加算反数の定義が依然として当てはまる。幾つかの点は水平方向に揃えられた対称点を有しない（例えば、（０,０））。そのような点は、それら自体の加算反数である。
εn上の２点A及びBと交差する「直線」lA,Bは、有限点集合になり、小さな黒丸により示され、同様の幾何学的要件を満たし、楕円曲線スカラー乗算の定義が依然として当てはまる。図６Aと同様に、図６Bは、点C=-(A+B)の加算反数である点A+B=-Cを示し、ここで直線lA,Bがεnと再び交差する。
εn上の２点の楕円曲線加算A+B=-Cは、次式により代数的に定義できる：
Figure 2022533753000017
上述の目的のために、整数vの乗算反数v-１の定義は、以下のように変更される：
Figure 2022533753000018
つまり、整数vの乗算反数は、v mod pのモジュラ反数である。
B=-Aの場合は特別であり、単位元∞の導入により解決され、上述のように、この場合、A+B=A+(-A)=∞である。B=∞の場合も特別であり、上述のようにA+∞=Aと表記して解決される。
楕円曲線スカラー乗算の定義は、楕円曲線加算のこの定義を採用し、その他の場合には同じままである。
他の文脈では、関連するスカラーvの乗算反数v-１の定義は：
Figure 2022533753000019
 乗算反数がmod n又はmod pに関して定義されるかは、文脈上明らかである。
実際に、数がmod n又はmod pとして扱われるべきかを識別するために、以下のチェックが適用されてよい：
（１）EC点の座標を表す数であるか？
a）Yesの場合、mod p
（２）EC点を乗算するために使用される数であるか？
a）Yesの場合、mod n
両方のチェックが肯定的結果を与えたる場合があることに留意する。この場合、その数はmod p且つmod nでなければならない。
＜楕円曲線暗号法（Elliptic Curve Cryptography (ECC)）＞
楕円曲線演算は、シークレット値を不明瞭にするユニークな能力を提供し、多くの現代の暗号システムの基礎を形成する。特に、有限体に渡る楕円曲線点のスカラー乗算を逆算することは、至難問題である（実行することが計算上不可能である）。
秘密鍵Vは整数の形式をとり、対応する公開鍵Pは、楕円曲線εn上の点である「生成元（generator point）」Gから導出される、楕円曲線εn上の点Pであり、次式の通りである：
Figure 2022533753000020
ここで、「・」は、a、b、及びn（楕円曲線パラメータ）により定められる、楕円曲線εn上の楕円曲線スカラー乗算を示す。
十分に大きなVについて、Pを導出するために実際にV回の楕円曲線加算を実行することは困難である、つまり計算上不可能である。しかしながら、Vが知られている場合、Pは、楕円曲線演算の代数特性を利用することにより、遙かに効率的に計算できる。Pを計算するために使用できる効率的なアルゴリズムの例は、「Double and Add」アルゴリズムである。重大なことに、これはVが知られている場合にのみ実施できる。
反対に、Vが分からない場合、G及びPの両方が分かっていたとしても、Vを導出する（つまり、スカラー乗算を逆算する）計算上実行可能な方法は存在しない（これは、所謂「離散対数問題」である）。攻撃者は、Gから開始して、Pを得るまで楕円曲線点加算を繰り返し実行することにより、「力ずくで」Pを破ろうとし得る。この点において、攻撃者は、Vが、彼が実行すべき楕円曲線点加算の数であることを知っているが、それは計算上不可能であることが分かる。従って、Vは、上述の意味において落とし戸の要件を満たす。
ECCでは、公開鍵P、生成鍵G、及び楕円曲線εnは、公開されており、知られていると想定されるが、秘密鍵Vは秘密である。
＜楕円曲線デジタル署名検証アルゴリズム（ECDSA)）＞
ブロックチェーンシステムでは、ユーザ又は他のエンティティは、標準的に、彼らのアイデンティティを証明するために使用される秘密鍵Vを保持し、対応する公開鍵Pは次式により計算され得る：
Figure 2022533753000021
秘密鍵Vは、ECDSAを用いてデータのピースm（「メッセージ」）に署名するために使用できる。
ECDSAの更なる詳細は、参照によりその全体が本願明細書に組み込まれる次の文献で与えられる："RFC６９７９-Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", Tools.ietf.org, ２０１９。
図６Cは、公開鍵－秘密鍵ペア（V,P）についてECDSA署名（r,s）を生成する署名生成機能（署名生成器６００）の概略機能ブロック図を示す。EDSA署名は、本願明細書ではそれぞれr部分（r-par (r)）及びs部分（s-part (s)）と呼ばれる値のペアである。
署名生成は、公開鍵Pを導出するために使用された同じ楕円曲線εn及び生成元Gに基づく。従って、楕円曲線パラメータa、b、及びn、並びに生成元Gは、署名生成器６００への入力として示される。
署名生成器６００の一時鍵生成器６０２は、「一時」鍵k∈[１,n-１]を、つまり両端を含む１～n-１の範囲で生成する。
r部分生成器６０４は、kから対応する一時鍵を以下のように計算する。
Figure 2022533753000022
そして次に、計算される点のx座標を取り入れる（楕円曲線点のx座標を取り入れる処理を示す[]xによる）：
Figure 2022533753000023
上式は署名のr部分である。
s部分生成器６０６は、k mod nのモジュラ反数k-１を用いて署名のs部分を計算し（つまり、次式であり、先の説明を参照する）：
Figure 2022533753000024
 H(m)と示される（必要な場合にはトランケートされる）、メッセージmのハッシュは以下の通りである：
Figure 2022533753000025
本例では、メッセージmは、トランザクション６０８に含まれるべき日を含む（本例では１つ以上のトランザクションアウトプット）。これは、メッセージmに署名する処理と呼ばれてよく、メッセージmは、トランザクションの署名済み部分と呼ばれてよい。
メッセージm及び署名（r,s）は、また、トランザクション６０８の部分を形成する。本例では、署名（r,s）は、アンロックスクリプトの部分としてトランザクション６０８のインプットに含まれる。
図６Dは、トランザクション６０８を検証する署名検証機能（署名検証器）６２０の概略機能ブロック図を示す。署名検証器６２０により実行される計算は、留意すべきことに公開されている同じ楕円曲線εn及び生成元Gに基づく。
署名は秘密鍵Vをインプットとして要求するが、つまり有効な署名を生成するためにその知識を要求するが、署名（r,s）を検証するためには、署名ペア（r,s）、メッセージm、及び公開鍵Pしか必要ない。署名を検証するために、署名検証器６２０は、トランザクションmの署名済み部分をハッシングする（署名（r,s）を生成するために使用されたのと同じハッシュ関数Hを適用する）。検証処理は、次に、以下の計算を用いて実行される。
Figure 2022533753000026
[R’]x=rの場合及びその場合にのみ、署名は有効である（つまり、署名検証器が成功する）。その他の場合、無効である（つまり署名検証が失敗する）。本例では、rは、トランザクション６０８に含まれる署名のr部分を示す。
署名検証器処理で使用される公開鍵Pは、例えば、先行するトランザクションのロックスクリプト内で指定される。署名検証は、この場合には、先行するトランザクションのロックスクリプト内で指定された公開鍵、（後の）トランザクション６０８の署名された部分m及び署名（r,s）を用いて実行され、署名（r,s）が先行するトランザクション内で指定された公開鍵Pに対応する秘密鍵V及びのりのトランザクション６０８の署名された部分mに基づき生成されたものでない限り、失敗する。従って、秘密鍵Vを肘する人物のみが、（標準的には、彼ら自身の公開鍵を後のトランザクション６０８のアウトプットに含めることにより）先行するトランザクションのアウトプットを請求でき、後のトランザクション６０８の署名された部分mは署名（R,S）を無効にすることなく変更できない。
Rパズル
以下は、ECDSAに基づく知識証明の新しい形式を記載する。説明により、チャレンジャーは、彼女自身でTx１を生成しP２Pブロックチェーンネットワークに発行することにより、又はTx１を構成し発行するための必要な詳細を第三者に提供することにより、第１トランザクションTx１内でrパズルを設定する第１パーティAliceである。検証者（実際に証明を実行するパーティ）は、ネットワークのノード１０４のオペレータ、例えばマイナーである。ｒパズルの回は、ネットワーク１０６にTx２を発行することにより、提供される。ｒパズルがアイデンティティに本質的に結び付けられないので、証明者は任意の第２パーティであり得る。しかし、例として、以下は、証明者がたまたまBobであるシナリオの観点で記載されることがある。証明者は、彼自身でTx２を生成し発行するか、又は必要な詳細を第三者に提供してそれらをTx２に構成し発行するようにしてよい。
暗号ハッシュ関数は、インプットの小さな変更がアウトプットの予測できない変更をもたらす場合に、インプットを決定論的に不明確にする手段を提供する。従来のハッシュ関数は、MD５、RIPEMD-１６０、SHA-１、及びSHA-２５６[５]を含む。これらはそれぞれ、衝突耐性（同じアウトプットを生成する２つのインプットを見付ける確率が極めて小さい）、及びプリイメージ耐性（ハッシュ値h=H(d)が与えられた場合に、インプットdを見付けることが極めて困難である）。
従来のハッシュパズルは以下のように設定できる。考え方は、第１トランザクションTx１を設定することである。第１トランザクションTx１は、第２トランザクションTx２がそのインプットに何らかの特定のデータのピースを含むことを条件として、自身のアウトプットが第２トランザクションTx２により償還されることを可能にする。
ブロックチェーントランザクションでは、単純に、以下のように、ロックスクリプト内でハッシュ値ｈを用いて、第１パーティ（Alice）は、非標準トランザクションTx１を生成し得る：
Figure 2022533753000027
ここで、h=Hpuz(d)であり、Hpuzは、パズルの中で使用されるハッシュ関数である（上述の例では、ロックスクリプトによると、このハッシュ関数はHASH１６０でなければならないが、他の実装では他の形式のハッシュ関数が使用され得る）。このロックスクリプトが含まれるUTXOを償還することは、後のトランザクションのアンロックスクリプト内にあるハッシュパズル解を要求する。従って、アドレスAddr_Bobを有する第２パーティのための支払いトランザクションTx２は、dを含むだけでよいアンロックスクリプトにより構成され得る。
Figure 2022533753000028
ここで、TxIDiはTxiのトランザクションIDである。ロックスクリプトは以下を記述する：Tx２のインプット内のアンロックスクリプトからデータ値dを取り込み、それをハッシングし、それがTx１のアウトプット内のロックスクリプトに含まれるハッシュ値ｈと等しいかどうかをチェックする。従って、アウトプットは、Tx２のアンロックスクリプト内のdを提供することにより、アンロックされる。
この素朴な例では、Tx２内のハッシュパズル解を有するユーザのトランザクションが分かった後に、このトランザクションを最初に受信したマイナーは、悪意をもってトランザクションを拒否し、ハッシュパズルに対する同じ解を有するが、彼ら自身のアドレスAdd_Minerにアウトプットを変更している、新しい柔軟な（malleated）バージョンTx２*を生成することができる。悪意あるマイナーは、次に、彼／彼女自身でTx２*をマイニングしてブロック１５１にすることができる。Tx２がマイニングされる前に、彼らがTx２*をマイニングすることに成功すれば、悪意あるマイナーはBobの代わりに支払いを受け取るだろう。
Figure 2022533753000029
デジタル署名は、所有権を証明し未使用トランザクションアウトプット（unspent transaction output (UTXO)）を償還するために、ブロックチェーントランザクションの中で一般的に使用されている。これは、Tx１のようなトランザクションのアウトプットが、特定のパーティにロックされることを可能にする。最も一般的な例は、トランザクションのアウトプットが公開鍵の特定のハッシュ（これは、そのパーティのアドレスとしても機能する）にロックされるP２PKH（pay-to-public-key-hash）トランザクションである。公開鍵Pのロックスクリプトは：
Figure 2022533753000030
ここで、hＰ=Hsig(Ｐ)であり、Hsigは、署名の中で使用されるハッシュ関数である（上述の例では、ロックスクリプトによると、このハッシュ関数はHASH１６０でなければならないが、他の実装では他の形式のハッシュ関数が使用され得る）。このUTXOを別のトランザクションへのインプットとして使用可能にするためには、Pを用いて有効なECDSA署名を有するアンロックスクリプトを提供する必要がある：
Figure 2022533753000031
文字列全体（アンロック＋ロックスクリプト）は、マイナーにより評価される。マイナーは、正しい公開鍵が提供されるか、及び署名が有効でありPに対応するか、をチェックする。ロックスクリプトは、基本的に以下を記述する：Tx２のインプット内のアンロックスクリプトから公開鍵Pを取り入れ、それをハッシングし、それがTx１のアウトプット内のロックスクリプトに含まれるハッシュ値hPと等しいかどうかをチェックし、更に、Tx２の署名済み部分の知識が与えられた場合に、Tx２のアンロックスクリプトから公開鍵Pを用いて、ECDSA検証関数に基づき署名sigを検証する。ECDSA検証関数はOP_CHECKSIGオペコードにより呼び出される。
従って、アウトプットは、Tx２のアンロックスクリプト内で、Pに対応する秘密鍵Vに基づき署名された有効な署名sigを提供することによってのみ、アンロックできる。
これをハッシュパズルと一緒にすると、上述の脆弱性は、ハッシュパズル解と一緒に、意図された受信者からのデジタル署名を要求することにより、修正できる。ロックスクリプトは以下のように構成され得る：
Figure 2022533753000032
対応するアンロックスクリプトは次のようになる：
Figure 2022533753000033
しかしながら、これは、それを償還できる人を、公開鍵Pの所有者に制限する。ここで、これは幾つかの適用では、例えば、Aliceがパズルを設定した後にのみ署名権限を選定する能力を保持したい場合、望ましくないことがあることが分かる。
ここで、ハッシュパズル機能は、一時的なランダム値であってよいECDSA署名の中のr部分を利用することにより、エミュレートできることが分かる。ECDSA署名は、２つの部分r及びsで構成される。以上から分かるように、r=[k・G]xである。従来のハッシュパズルh=H(d)の代わりに、楕円曲線加算の逆算の困難さは、本願明細書でrパズルと呼ばれる類似のパズルを形成できる。パズルを解くためには、解の値kを取得する必要があり、ここで、kは、rに対応する一時鍵である。
従来のハッシュパズルでは、パズルを解くときに、ブロックチェーン上にｄを開示するリスクがある。しかしながら、rパズルでは、kは決して開示されない。その代わり、rが開示され、署名と共にrから、kの知識が証明できる。
kは固定サイズでなければならないが、ハッシュパズルのプリイメージデータは任意の長さにできるので（そして、ハッシュ関数の１つの特徴は、インプットデータの長さに拘わらず、固定長の値を出力することである）、ハッシュパズル機能をエミュレートするために、rパズルの生成者は、先ず、何らかの多のプリイメージデータをハッシングして値kを取得してよい。例えば、２５６ビット長の秘密／一時鍵を使用する場合、kを得るために、rパズルに対するプリイメージデータはハッシングされなければならない。代替として、しかしながら、何らかの適切な長さ値のkは、単に選択され、それ自体の能力で直接シークレット値として使用され得る（つまり、何らかの他の選考するプリイメージからそれを導出する必要がない）。
この方法は、支払い（spending）のためにECDSA署名を使用する任意のブロックチェーンシステムと共に使用できる。説明のために、以下は、UTXOに基づくモデルにおける例示的な実装を説明する。スクリプト言語では、OP_CHECKSIGオペコードは、スタック上で署名及び公開鍵を要求する（スタックの一番上には公開鍵があり、その直下に署名がある）。rパズルについて、スクリプトは、提供された署名の中のr値がrパズルチャレンジのっために使用されたものと同じであるかをチェックするよう構成される。言い換えると、スクリプトは、（OP_CHECKSIGを通じて）署名が公開鍵に基づき有効であることをチェックするだけでなく、署名が、ブロックチェーン上で事前に発行されているｒパズルのr値を用いて生成されたことも確かめる。
rパズルの幾つかの例示的な実装は、図７～１０を参照して以下に議論される。それぞれの場合に、証明者、例えばBobは、Tx２の部分に署名することにより、署名（r,s）を生成している。この形式の署名は、時に、「sig」と呼ばれることもある。暗号書名の文脈では、署名済み部分は「メッセージ」（m）とも呼ばれる。署名済み部分（メッセージ）mは、少なくとも、結果として生じるBobへの支払いをロックする、Tx２のアウトプットを含む。１つより多くのアウトプットが存在する場合、mは、アウトプットのうちの一部又は全部を含んでよい。mは、使用される場合には、ロックタイム（locktime）のような他の部分も含んでよい。しかしながら、それは、アンロックスクリプト自体を除く（及び、勿論、少なくとも、署名自体を除く）。メッセージmとして署名されるべきTx２の部分は、Sighashにより設定され、又はデフォルトであり、マラはプロトコルの固定的特徴であることもできる。
おそらく、rパズルの最も簡単な実装は図７に示される。Tx１内のロックスクリプトは、ここではr'とラベル付けされる、参照インスタンス又はr部分を含む。この方法では、Tx２内のアンロックスクリプトは、少なくとも、Bobの署名のs部分（s）のみを含めばよい。それは、Bobがmに署名するために使用した秘密鍵Vに対応する公開鍵Pも含んでよい。Tx１のロックスクリプトは、ノード１０４でスクリプトエンジン４０２により実行されると、s及びPをTx２のアンロックスクリプトから取り入れ、以下の演算を実行するように構成される。
Figure 2022533753000034
ここで、r'は、Tx１のロックスクリプトから取り入れられ、s及びmは、Tx２のアンロックスクリプトから取り入れられる。Bobの公開鍵Pも、Tx２のアンロックスクリプトから取り入れられてよく、又は他の手段により知られていてよい。Hsigは、第１ECDSA署名を生成する際にmをハッシングするために使用されたハッシュ関数である。それは、任意の形式のハッシュ関数であってよい。それがどんな形式であっても、このハッシュ関数の形式（タイプ）は、所定の両者に知られているものであると考えられてよい。Gは固定の公衆に知られたベクトル値である。
ロックスクリプトは、前記のチェックが真であることを条件に「真」の結果を返し、その他の場合に「偽」の結果を返すよう構成される。UTXOの場合には、アンロックスクリプトと一緒にロックを実行した真（つまり、成功）の結果は、トランザクションの有効性の要件である。従って、Tx２の有効性は、rパズルの結果のプロキシとして使用できる。或いは、別の方法では、Tx２の有効性は、rパズルに対する解を提供することを条件とする。つまり、Bobがrパズルに合格しない場合、彼のトランザクションTx２は、ネットワーク１０６に渡り伝播されず、ブロックチェーン１５０に記録もされない（Tx１のアウトプット内に定義されたいかなる支払いも償還されない）。
図７の例は数学的意味において最も単純であるが、これは、必ずしも、任意の所与のノードプロトコル又はスクリプト言語と統合することが最も単純であることを意味しない。支払者（spender）が、<r,s>及び<P>ではなく、アンロックスクリプトの中で<s>及び<P>しか提供しない場合、スクリプトはこれに対応しなければならない。演算I)～ＩＩ）は、標準的なChecksigタイプのオペコードの演算ではない。OP_CHECKSIGオペコードは、署名がDERフォーマットであることを期待しているので、<s>値のみがアンロックスクリプト内で提供された場合、有効な署名をDERフォーマットで生成するために、ロックスクリプト内に幾つかの追加のオペコード（連結するためにOP_CAT等）が存在する必要がある。図８は、数学的に言うと追加ステップを含むが、実際には、両方ともTx２のインプットから取り入れられるr及びsに基づくECDSA署名検証を呼び出すための専用オペコードを既に有するScriptのようなスクリプト言語と統合しているより簡単な代替の例を簡単に記載し示す。
全部の可能な実施形態においてTx２にPを含むことは本質的ではないことにも留意する。実際に、メッセージm及び（r,s）又はこの場合には（r’,s）の知識から、公開鍵の２つの可能な値P及び-P（しかしどちらがどちらかは分からない）を計算することが可能である。２つの検証は、次に、どちらが正しい方かを識別するために使用できる。又は代替として、２つの可能な解のうちのどちらを使用すべきかをシグナリングするための１ビットフラグがTx２に含まれることが可能である。この後者のアプローチは、幾つかのアカウントに基づくプロトコルで現在使用されている。しかしながら、それは、スクリプト言語（例えば、Script）がP及び-Pを（r,s）及びmから計算する演算のためのオペコードを有しない現在のUTXOに基づくプロトコルでは使用されない傾向にある。しかしながら、演算がロックスクリプト内に明示的にコーディングされること、又は導入される可能性を排除すべきではない。別の可能性は、Aliceが既に知っている、或いはPへのアクセスを有するか又はそれをサイドチャネル３０１を介して受信することである。しかしながら、それは、PをTx２にマッピングするために別のルックアップを必要とする。
別の例示的な実装は図８に示される。ここで、rパズルは、Tx２のアンロックスクリプトがr部分の提出されたインスタンスrを明示的に含むことを要求する。Tx１のロックスクリプトは、r部分についてのテストを含み、該テストは、r部分の参照インスタンスr'が提出されたインスタンスrに対して比較されることを含む。この方法では、Tx２内のアンロックスクリプトは、少なくとも、Bobの署名のr部分（r）及びs部分（s）を含まなければならない。それは、Bobがmに署名するために使用した秘密鍵Vに対応する公開鍵Pも含んでよい。Tx１のロックスクリプトは、ノード１０４でスクリプトエンジン４０２により実行されると、r、s及びPをTx２のアンロックスクリプトから取り入れ、以下の演算を実行するように構成される。
Figure 2022533753000035
ここで、r'は、Tx１のロックスクリプトから取り入れられ、s、r、及びmは、Tx２のアンロックスクリプトから取り入れられる。Bobの公開鍵Pも、Tx２のアンロックスクリプトから取り入れられてよく、又は他の手段により知られていてよく、例えば（r,s）及びmから導出され、又は前述のような（r,s）及びmであってよい。
ロックスクリプトは、ステップＩ）及びＩＩ）の両方のチェックが真であることを条件に「真」の結果を返し、その他の場合に「偽」の結果を返すよう構成される。UTXOに基づく場合にも、これは、トランザクションの有効性がrパズル知識証明の結果に依存して決定されることを可能にする。番号I～ＩＩＩは、必ずしも順序を意味しないことに留意する。ＩＩＩ）はＩＩ）の後に実行される必要があるが、チェックＩ）はII）～ＩＩＩ）の前又は後に実行できる。
図８の方法では、ステップＩＩ）及びＩＩＩ）は、単独で、ECDSA検証関数により実行される従来の演算である。大部分のプロトコルでは、それらは、従って、Scriptにおける既存のChecksigオペコード(OP_CHECKSIG)のような専用オペコードにより呼び出される。ステップＩ）は、汎用オペコードを用いてロックスクリプトに別個にコーディングできる（例は後述する）。ステップＩＩ）及びＩＩＩ）がChecksigのような専用オペコードを用いる代わりに、汎用オペコードを用いて明示的に符号化されることも原理的に除外されない。
１つの例示的なトランザクションプロトコルでは、図１１Aに示すように、トランザクションECDSA署名は、ASN.１(Abstract Syntax Notation One)DER(Distinguished Encoding Rules)符号化フォーマットを使用する。第１バイトフィールドは、ASN.１シーケンス番号を示すフラグ０x３０を含む。次のバイトフィールドは、シーケンスの長さを１６進数で含む。第３バイトフィールドは、ASN.１整数（integer.を示すフラグ０x０２を含む。その後に、ECDSA署名のr値が、次の３２又は３３バイトに含まれる。フィールドは３２バイトであるべきだが、rの第１バイトが０x７fより大きい場合（第１ビットは１である）、０の追加バイトがr値の前に追加され、３３バイトの長さにする。これは、整数の第１ビットを署名として解釈するDERフォーマット符号化の結果として行われる。０の追加バイトは値の始めに追加され、その結果、負の値として解釈されない。同じことが、ECDSA署名のs値に行われる。最終的に、１バイトフィールド、ハッシュタイプ（ht）が、DER符号化に追加され、これはトランザクション内のビットコイン署名のタイプ（SIGHASH_ALL、SIGHASH_NONE、等）に対応する。
Alice（A）が、パズルの解を取得した者が誰でも使用できるrパズルトランザクションを生成したい場合を検討する。これを達成するために、彼女は、以下に一例を示すような新しいトランザクションTx１を生成する。インプット部分は、使用されている前のトランザクションTx０のアンロックスクリプトを含む。簡単のため、それは、Aliceの署名及び公開鍵を用いて使用される標準的なP２PKHであると仮定する。アウトプット部分は、ロックスクリプト（スクリプト公開鍵）、又は言い換えるとrパズルチャレンジを含む。図１１Aに示すように、署名は、幾つかのプロトコルではDER符号化フォーマットを使用してよい。従って、スクリプトは、符号化署名からrの値を抽出し、次に、それが<r>に等しいかをチェックしなければならない。その後、スクリプトは、署名が公開鍵に基づき有効であることをチェックしなければならない。スクリプトがどのように動作するかの更に詳細な説明は図５に示される。太字のオペコードは、基本的に、署名からrを抽出する方法である。
Figure 2022533753000036
対応するアンロックスクリプトは、以下に示される。ここで、署名sigrはrを使用し、支払者Bob（B）は任意の秘密／公開鍵ペアを用いて署名を計算できる。sigrは(r,s)であることに留意する。
Figure 2022533753000037
図１１Bは、ステップ毎のスクリプト分析を示す。
一時鍵kは、Aliceにより生成され、Bob（及び任意的に１人以上の他の可能な証明者）に与えられてよい。代替として、kは、Bobにより生成され、Bob（又はkを共有するためにBobが選択した誰か）だけが解くことができるrパズルを設定するためにAliceに与えられてよい。いずれの場合にも、証明者Bobは、送信者Aliceはrパズルの解（k）を知っているので、彼女がトランザクションを彼女自身で使用しないことを信じなければならない。これを防ぐために、証明者Bobは、パズルを生成し、Aliceがｒパズルトランザクションを生成するときに使用するために、Aliceにr値を送信し得る。その後、Bobは、彼がrパズルの解であり鍵の一形態として見られる値kを保持している限り、任意の秘密／公開鍵ペアを用いて後日、アウトプットを償還できる。他方で、幾つかの場合には、Aliceがkを知っているという事実は、有利な特徴になり得る。例えば、これは、秘密鍵パズルを生成するために、それを通じて一般化されたアトミックスワップ（atomic swap）を生成するために使用できる。
図９は、rパズルの別の例を示す。これは、P２PKH（pay to public key hash）と同様に、本願明細書で「P２RPH（pay to r-puzzle hash）」と命名される。追加されるセキュリティ及びプライバシのために、r値は、（ネットワーク１０６のノード１０４を通じて伝播されブロックチェーン１５０上に置かれる）Tx１内に置かれる前に、ハッシングされ得る。P２PKHと同様に、公開鍵自体ではなく、公開鍵のハッシュのみがブロックチェーン上にある場合、rパズルにより同じことが行われる。
ここでも、rパズルは、Tx２のアンロックスクリプトがr部分の提出されたインスタンスrを含むことを要求する。Tx１のロックスクリプトは、ここでも、r部分についてのテストを含むが、今回は、r'のハッシュの形式のr部分の圧縮されたインスタンスの形式である。つまり、h=H(r’)。これは、提出されたインスタンスrに対して比較される。この方法では、Tx２内のアンロックスクリプトは、ここでも、少なくとも、Bobの署名のr部分（r）及びs部分（s）を含まなければならない。それは、Bobがmに署名するために使用した秘密鍵Vに対応する公開鍵Pも含んでよい。Tx１のロックスクリプトは、ノード１０４でスクリプトエンジン４０２により実行されると、r、s及びPをTx２のアンロックスクリプトから取り入れ、以下の演算を実行するように構成される。
Figure 2022533753000038
ここで、hは、Tx１のロックスクリプトから取り入れられ、s、r、及びmは、Tx２のアンロックスクリプトから取り入れられる。ハッシュ値h=Hpuz(r)であり、ここで、Hpuzはrパズルのハッシュ（hash-of-r puzzle）で使用されるハッシュ関数である。それは、任意の形式のハッシュ関数であってよい。それは、Hsigと同じ又は異なる形式のハッシュ関数であってよい。それがどんな形式であっても、Hpuzの形式は、所定の両者に知られているものであると考えられてよい。Bobの公開鍵Pも、Tx２のアンロックスクリプトから取り入れられてよく、又は他の手段により知られていてよく、例えば（r,s）及びmから導出され、又は前述のような（r,s）及びmであってよい。
ロックスクリプトは、ステップＩ）及びＩＩ）の両方のチェックが真であることを条件に「真」の結果を返し、その他の場合に「偽」の結果を返すよう構成される。ＩＩＩ）はＩＩ）の後に実行される必要があるが、チェックＩ）はII）～ＩＩＩ）の前又は後に実行できる。
ここでも、図８の場合のように、ステップＩＩ）及びＩＩＩ）は、単独で、ECDSA検証関数により実行される従来の演算である。大部分のプロトコルでは、それらは、従って、Scriptにおける既存のChecksigオペコード(OP_CHECKSIG)のような専用オペコードにより呼び出される。ステップＩ）は、汎用オペコードを用いてロックスクリプトに別個にコーディングできる。
トランザクションチャレンジTx１内のロックスクリプトの例は以下に示される。
Figure 2022533753000039
送信者及び受信者の両方のパーティの間で一貫している任意のタイプのハッシュ関数が使用され得る。しかしながら、P２PKH標準と調和していながら、私たちは、OP_HASH１６０、SHA-２５６のダブルハッシュ、及びRIPEMD-１６０を使用する。
対応するアンロックスクリプトは、以下に示される（前の章と同じである）。ここで、署名sigrはrを使用し、支払者Bob（B）は任意の秘密／公開鍵ペアを用いて署名を計算できる。
Figure 2022533753000040
従って、図９の例は、rの未変換インスタンスの代わりに、r部分のハッシュをrチャレンジの基礎として使用することを除き、図８と同様である。
これらの場合のいずれでも、Tx１のアンロックスクリプトが「真」の結果について追加基準を課すことに留意する。例えば、例は、ロックタイムまたは追加署名に対する要件であり得る。
上述の技術のいずれかの例示的な使用例は、汎用知識チャレンジとしてである。何らかの解kを有する任意のチャレンジ、又はハッシングされてkになる何らかの解を検討する。Aliceは、パズルに結合されるrパズルを生成する。つまり、彼女は、r=[k・G]xを定義できる。
例として、Aliceは数学の教授である。彼女は、rパズルトランザクションTx１を構成できる。ここで、基礎にあるk値は、学生が解くように促される数学の問題に対する解である。解を考え出すことができた者は誰でも、署名（r,s）を生成するためにそれを使用でき、従って報酬を請求できる。ここで、rはロックスクリプト内の値と一致する。署名は、真正さを提供するだけでなく、解を誰か他の者に開示することなく、解の知識証明としても機能する。従って、rパズルは、何からの解の知識又は情報を、それを公開するリスクを伴わずに一般的に証明するためのセキュアなメカニズムを提供する。それは、アンロックスクリプト内で要求される署名をエレガントに再利用し、任意の公開鍵Pが使用できるので、解を見付けた者が誰でもプライバシと共に報酬を請求できるようにする。
この方式は、トークン又はデジタルチケットの形式として使用されることもできる。例えば、イベント主催者は、デジタルチケットとしてkの異なる値を、出席者に発行できる。出席者がイベントに出席したいとき、彼らは、rパズルの使用を通じてシークレットトークンの知識を証明できる。
別の例示的な使用例として、rパズルは、あるパーティが別のパーティに署名する権利を委任できる署名権限付与方式として使用できる。ロックスクリプトに一致するr値を有する署名が提供された場合にのみアンロックできるrパズルトランザクションTx１を検討する。これは、値k、ここで[k・G]x=r、を知っている人物だけがそのような署名を生成できることを意味する。しかしながら、人物がkの知識を誰か他の者に渡した場合、これは、事実上、彼又は彼女の代わりに署名する権利を他の人物に与える。
例えば、Aliceは配達を受け取りたいとする。彼女は彼女が配達を受け取るためにそこに居ないかもしれないことを心配している。彼女は、Bob及びCharlieの両者にkのコピーを与え、彼らは彼女の代わりに配達を受け取ることができる。Daveが小包を配達している場合、彼女は、Bobに小包を解放するために、期待されるr値を有する署名を得なければならない。
このようなシナリオでは、kは一時秘密鍵として、rは一時公開鍵として、k及びrが特定のアイデンティティにリンクされないことを除き、それぞれV及びPと同様に、動作すると考えることができる。
＜共同値（JOINT-VALUE）rパズル＞
図９のハッシングされたrパズル（P２PKH）への拡張として、（h=Hpuz(r||d)を得るために）ハッシングの前にrと連結される追加の値dを含むことが可能である。その場合、証明者（例えば、Bob）は、rパズルを解くだけでなく、dも知っていなければならない。この例は図１０に示される。
Tx１のロックスクリプトは、ノード１０４でスクリプトエンジン４０２により実行されると、r、s、P及びdをTx２のアンロックスクリプトから取り入れ、以下の演算を実行するように構成される。
Figure 2022533753000041
r||dは、いずれかの順序で（rが最初、又はdが最初）、r及びdの連結を表す。チャレンジトランザクションTx１内のロックスクリプトの例は以下に示される。
Figure 2022533753000042
対応するアンロックスクリプトは、以下に示される（dが含まれることを除き、前の章と同じである）。署名sigrPBはrを使用し、証明者Bob（B）は任意の秘密／公開鍵ペアを用いて署名を計算できる。
Figure 2022533753000043
追加の署名sig'は、セキュリティのために追加された特徴である（後述する任意的なセキュリティ特徴についての章を参照する）。しかし、これは、全ての可能な実施形態で必要とされるものではない。
例示的な使用例は、CLTVにリンクされたｒパズル（CLTV Linked R-Puzzle）であってよい。この場合、データ値dは、CLTV（Check Lock Time Verify）トランザクションアウトプットにリンクされた時間値tであり得る。この背後にある動機は時間tを隠すことであり、この時間tの前には、P２RPHハッシュの中でアウトプットは使用できず、rパズルにリンクする。その場合、証明者（例えば、Bob）は、rパズルを解くだけでなく、tも知っていなければならず、それを使用するためには特定の時間まで待機しなければならない。トランザクション内のロックスクリプトの例は以下に示される。
Figure 2022533753000044
対応するアンロックスクリプトは、以下に示される。ここで、署名sigrPBはrを使用し、支払者Bob（B）は任意の秘密／公開鍵ペアを用いて署名を計算できる。
Figure 2022533753000045
追加の署名sig'は、セキュリティのために追加された特徴である（後述する任意的なセキュリティ特徴についての章を参照する）。しかし、これは、全ての可能な実施形態で必要とされるものではない。
以上は、連結の観点で説明された。しかしながら、これを特定の関数f(r,d)へと一般化することも可能である。例えば、fはr及びdの加算であってよく、例えば<r><d>OP_ADDとして実装できる。
＜複数のr値のステートメント＞
別の可能性は、rの複数の所定の値、例えば、異なるステートメントに関連付けられそれらをアンロックするr１、r２、及びr３を有することである。ステートメントSiをそれぞれのriに割り当てた場合、私たちは、署名の中で対応するriを用いることにより、特定のステートメントに肯定応答できる。例えば、これは、合意した１又は複数の代替の可能な項目を承諾することを示すよう、署名するために使用されてよい。
どのr値がアンロックスクリプト内で使用されるかをチェックするロックスクリプトを構成することが可能であり、rの値に解釈を割り当てることができる。上述の思想を実装するロックスクリプトは以下のようであってよい。
Figure 2022533753000046
全ての<statement i>は、対応するrパズルを解いた後にのみアクセスできる異なるロック条件により置き換えられるべきである。アンロックスクリプトが以下に示され、ここで、riは、設定されたステートメントにアクセスするために必要な異なるr値である。
Figure 2022533753000047
追加の署名sig'は、ここでも、セキュリティのための、任意的に追加された特徴である（以下を参照する）。しかし、これは、全ての可能な実施形態で必要とされるものではない。
＜任意的なセキュリティ特徴＃１＞
kに基づく署名が公開された場合、kの値を知っている者は誰でも、署名を生成するために使用されたシークレット鍵Vの値を導出できる。これは、以下の署名式の中のVについて解くことにより行うことができる。
Figure 2022533753000048
多くの場合にトランザクションの受信者はkを知っている者だけなので、これは有意なリスクを引き起こさない。他の場合には、支払者は、rパズルの解に署名するために使用された秘密鍵Vを決して再利用しないよう注意しなければならない。良好なセキュリティの慣習は、ユーザが公開／秘密鍵ペア（P,V）を決して再利用しないことが望ましく、むしろ、新しい金銭を受け取るとき、常に新鮮な新しい公開／秘密鍵ペアを使用する。
原則的に、公開－秘密鍵ペア（P,V）は「永久的」である。つまり、それは、何回も使用できる。ランダム一時鍵kの使用はこれを保証するべきである。しかしながら、乱数生成器の実装が不十分である場合には、問題が起こる。
同じ一時鍵k及び同じ秘密鍵を用いて２つの異なるメッセージに署名した場合、２つの署名から秘密鍵Vを導出できる。つまり、所与の（r,s）及びｋが与えられると、Vを算出できる。ここで、r=[k・G]xであり、Vは署名で使用された公開鍵Pに対する秘密鍵である。乱数生成器が署名処理中に障害になった場合、最後に同じ乱数を生成することがあり、従って、秘密鍵が公衆に漏洩する。この問題を解決するために、人々は、乱数生成器を固定する代わりに、公開鍵を再利用することを避け始めた。
本例では、Aliceがkを知っているが、彼女が、Bobの公開鍵に対する秘密鍵であるVを知らない場合。AliceがBobにkを渡すとき。Bobは、彼の秘密鍵を用いて（r,s）を提供することにより、rパズルを解くことができる。Aliceは署名を見ると、彼女はkを知っているので、彼女はVを導出できる。これは、Bobにとって望ましくない場合がある。従って、Bobは、望ましくは（P,V）の再利用を回避すべきである。
しかしながら、これに伴う問題は、Bobの公開鍵PがBobを識別する持続的な手段として使用できないことである。
これを解決するために、本願明細書に開示される実施形態によると、Bobは、対応する公開鍵P２を有する別個の秘密鍵V２を用いて、Tx２にBobの追加署名sig２を含めてよい。彼は、追加署名と一緒にP２も含める。従って、２種類の公開－秘密鍵ペアがある。第１種類は、１回限りの使用のためにオンザフライで生成されるものである。他の種類は、何らかの追加プロトコル、例えばHDウォレットに従い生成されるものである。Bobは、rパズル署名のために第１種類の鍵ペアを使用し、第２署名のために第２種類を使用できる。
Aliceは、公開鍵とアイデンティティとの間のマッピングに基づき、Bobのアイデンティティ、例えばBobの正式名、ユーザ名、又はネットワークアドレスを検索するために、第２公開鍵を使用できる。マッピングは、例えば、公開鍵をアイデンティティにマッピングする公開データベースの中で利用可能にされ得る。或いは、マッピングは、単にAliceとBobとの間で予め合意され得る（例えば、Aliceのコンピュータ機器１０２aにプライベートに格納される）。
ここで再び、署名権限の使用例を検討する。例えば、Aliceは、配達を受け取りたいが、彼女自身で配達を受け付けることが可能ではないかも知れない。彼女は、Bob及びCharlieの両者にkのコピーを与え、彼らは彼女の代わりに配達を受け取ることができる。Daveは、小包を配達している。彼は、期待されるr値を有する署名を得なければならない。ここで、彼の記録又は規則対応では、Daveは受取人のアイデンティティを検証する必要もあることを考える。
Bobは配達を受け付けるためにそこに居るとする。Bobが彼の公開鍵及び署名をkに基づき生成した場合、Alice及びCharlieの両者は、Bobの秘密鍵Vを算出できる。これは、公開鍵が１回限りの使用のために指定された場合には、問題ではない。しかしながら、Bobがこの公開鍵を将来に彼のアイデンティティを証明するために必要とする場合には、理想的ではない。
この問題を解決するために、実施形態は、Tx２に、Bobを識別するために使用できるBobからのrパズルと独立した１つ以上の署名を含めてよい。例えば、追加署名及び対応する公開鍵P２を、Daveが受け付けるのと同じトランザクション内のOP_RETURNアウトプット（未使用アウトプット）に追加できる。代替案は、rパズルトランザクションのロックスクリプト内に追加OP_CHECKSIGを含めることである。トランザクション及び追加署名のために使用された公開鍵を閲覧することにより、Aliceは、誰が彼女の代わりに署名したかを教えることができる。
幾つかの他の場合には、値kが使用する前に漏洩する可能性があるという心配があり得る。これを解決するために、AliceはrパズルトランザクションにP２PKHを追加して、それをよりセキュアにすることができる。Aliceは彼女の署名権限をBobに委任したいとする。AliceがBobから１回限り公開鍵P２を取得し、r値を指定するだけでなく追加公開鍵P２も指定するrパズルトランザクションを生成する。
Alice自身も署名できるようにするために、任意的に、Aliceは１-out-of-２ MultiSigを生成できる。ロックスクリプトの一例は以下に与えられる。
Figure 2022533753000049
Aliceはｒパズルの解、つまり署名権をBobに渡すべきときを選択できるので、rパズルが一層の柔軟性を提供することに留意する。彼女は、トランザクションがマイニングされた後でも、渡すか渡さないかを決定できる。
kが漏洩した場合、人々は、漏洩したkにより署名に署名するために使用される秘密鍵を発見できる。しかしながら、別の秘密鍵V２、つまりBobを識別するために使用できる公開鍵にリンクされる秘密鍵がある。アウトプットを損傷させるために、攻撃者は、２つの独立したシークレットを取得しなければならない。これは、それらのうちの１つのみを損傷させることより遙かに可能性が低い。
上述の例では、Tx２のロックスクリプトは、従来のP２PKHを用いて、Bobの追加公開鍵P２にロックされる（rパズルで使用されたものではなく、追加署名によりアンロックされる）。rパズル技術は、ユーザにとって追加の選択肢を可能にする。幾つかの適用では、証明者がアイデンティティに関係なくチャレンジを満たすことができるように、rパズルを使用することが望ましい場合がある。他方で、幾つかの他の適用では、ハッシュパズルとP２PKHの組合せが、依然として望ましい場合があり、rパズルはそれに関連して任意的に使用できる。これは、間もなく更に詳細に議論される。
しかしながら、P２に対応する追加署名がアイデンティティ検索及び／又はセキュリティのために必要であるが、P２PKHにおけるようにTx１のロックスクリプトが特定の証明者のアイデンティティに予め結び付けられることがない場合、上述のロックスクリプトが相応して採用できる。つまり、対応する公開鍵P２にOP_EQUALVERIFYではなく、追加署名にChecksigを単に含めることができる。
＜任意的なセキュリティ特徴＃２＞
上述の方法における別の可能なセキュリティ脆弱性は、署名の鍛造性（forgeability）である。これは、（ハッシュパズルと同様に）資金を請求しようとするマイナーにより利用されることがある。トランザクションを（支払者から）受信したマイナーは、支払者が元のトランザクションで使用したものと同じ署名を使用しながら、トランザクションを変更して、自分自身に資金を送ることができる。これは以下のように行われる。
P=V・Gを、mにより示される元のトランザクションに署名して、以下のように署名（r,s）を得るために使用された公開／秘密鍵ペアとする。
Figure 2022533753000050
そのトランザクションを使用するために、支払者は、以下のアンロックスクリプトを使用する。
Figure 2022533753000051
このトランザクションを受信したマイナーは、トランザクションを、以下の新しいアンロックスクリプトを使用して自分自身に資金を送信する、m'により示される新しいものに変更できる。
Figure 2022533753000052
マイナーは（Vを知らないので）V'を知る必要がないことに留意する。検証処理は、次に、以下の計算を用いて実行される。
Figure 2022533753000053
署名は、(R')x=rの場合及びその場合にのみ有効であり、その他の場合に無効である。
新しいトランザクションm’及び新しいアンロックスクリプトにより、検証処理は以下の通りである。
Figure 2022533753000054
この潜在的な脆弱性を解決するために、実施形態では、マイナーがシークレット鍵Vを知らない限り提供することができない別のメッセージmsighashに対するアンロックスクリプト内に別の追加署名sig'を含めてよい。その場合、アンロックスクリプトは、以下の通りであってよい。
Figure 2022533753000055
sig'は、同じメッセ維持m又は異なるメッセージmsighashに対する署名であってよい。異なるメッセージに署名するために、元のものと異なるsighashフラグを使用することができる（例えば、デフォルトフラグであるSIGHASH_ALLの代わりにSIGHASH_NONE）。しかしながら、両方の署名が同じメッセージ上に存在できるので、これは任意である。また、sig'は異なる値のrを使用しなければならない。その結果、それは秘密鍵を漏洩しない（何故なら、秘密鍵は、同じ一時鍵を使用する２つの署名から導出できるからである）。最後に、トランザクションは、以下に示すように末尾に別のOP_CHECKSIGを含む必要がある。
Figure 2022533753000056
これは、同じ公開鍵Pをrパズルとして使用しなければならない。その結果、公開鍵Pに対する秘密鍵Vを知っている者だけが別の署名を生成でき、上述の攻撃は不可能である。
攻撃者は、公開鍵を、攻撃者が秘密鍵の知識を有しない別の公開鍵で置き換えようとする。この攻撃を防ぐために、チャレンジは、秘密鍵の知識についても尋ねる。この場合、１つの署名は十分ではない。従って、２つの署名が要求される。両方の署名は、同じ秘密鍵の知識の証明として考えられる。チャレンジはそれらが異なる一時鍵を有することを要求するので、これはセキュアである。
＜rパズル閾値署名方式＞
敷地委暗号システムは、整数のペア(t;m)により特徴付けられる。ここで、mはパーティ（鍵シェア参加者、又は等価的に「プレイヤ」）の総数であり、t+１は、シークレットを再構成するために必要なパーティの最小数である。
シークレット共有方式は、閾値暗号システムの例であり、それにより、シークレットは、m人のプレイヤの間で分割（共有）され、少なくともｔ＋１人の参加者がシークレットを再構成するために協力する必要がある。シークレットの任意のt個の鍵シェアの知識は、シークレットを未定のままにする。
以下の例では、シークレット共有は、rパズルを設定するための、及びrパズルを満たす署名を導出するための、両方の基礎として使用されてよい。
図１２は、本願明細書でシークレット共有に基づく「rパズル閾値方式」と呼ばれる高レベルな概要を提供する。チャレンジトランザクション１２０２及び証明トランザクション１２０４が示される。
チャレンジトランザクション（rパズルトランザクション）１２０２は、一時鍵kに対応するrチャレンジ（rパズル）１２０３を含むように示される。上述の説明により、rチャレンジ１２０３は、証明トランザクション１２０４の中で、同じ一時鍵kに対応する有効なECDSA署名(r,s)（又は少なくともそのs部分s）を提供することによってのみ、満たさすことができる。
図１２及び後続の図では、rチャレンジ１２０３は、rパズルトランザクション１２０２のロックスクリプトに含まれる発行r部分r'として示される。しかしながら、上述のように、rチャレンジ１２０３は、r'のハッシュ（例えばH(r')）（又は他の変換）のように等しく実施でき、以下の説明は任意の形式のrパズル１２０３に適用される。
本願明細書では、シークレットは、通常、σと示され、参加者iにより保持される該シークレットのシェアはσi.と示される。記載される実施形態は、３個のそのようなシークレットを利用する。つまり、
（１）一時鍵k。ここで、kiは、参加者iにより保持される一時鍵シェアである。
（２）秘密鍵V。ここで、Viは、参加者iにより保持される秘密鍵シェアである。
（３）「署名シークレット」c。ここで、ciは、参加者iにより保持される署名シークレットのシェアである。
一時鍵シェアki及び秘密鍵シェアViは、「フルセット」と呼ばれΠ（大文字のパイ）で示される、m人の鍵シェア参加者のセットのうちの各参加者に割り当てられる。
署名シークレットは、フルセットのうちの２t+１人の参加者で構成される「署名サブセット」の各参加者に割り当てられる。ここで、２t+１≦mである。署名サブセットは、π⊂Πと示される（πは小文字のパイであり、大文字のパイの部分集合である）。署名サブセットπは、証明トランザクション１２０４に含めるために、rチャレンジを満たすECDSA署名のs部分を生成するために協力できる。
記載される実施形態の幾つかは、以下も考慮する：
・「チャレンジサブセット」π’⊂Π。チャレンジトランザクション１２０２のrパズル１２０３を設定するために（つまり、rパズルの基礎を形成するr'を導出するために）協力できる者；及び／又は、
・「r導出サブセット」π''⊂Π。ECDSA署名のr部分(r)を導出するために協力できる者。これはまた、署名サブセットπにより証明トランザクション１２０４のs部分（s）を導出するために使用されてよい。
π’及びπ''の両方が、フルセットΠのうちの任意のt+１人の参加者で構成されることができ、チャレンジサブセットπ'は、r導出サブセットπ''と等しくてよく又はそうでなくてよい。
フルセットΠを参照するとき、参加者は、任意のそのような参加者が署名等を導出するために必要な数の他の参加者と共同する可能性を有するという事実を反映して、「見込み参加者」と呼ばれてよい。
記載される閾値rパズル方式の特徴は、一時鍵kが未知であることである（つまり、鍵シェア参加者の少なくとも一部に未知である）。むしろ、各参加者iは、彼の一時鍵シェアkiを知っているだけである。
記載される閾値rパズル方式の別の特徴は、任意の署名サブセットπが、つまり、フルセットΠのうちの任意の２t+１人の参加者が、一時鍵kを開示することなく、署名サブセットπの各参加者iの一時鍵シェアkiに基づき、rチャレンジ１２０３を満たすECDSA署名を生成することが可能であることである。
後述数r実施形態では、署名は、各々のそのような参加者の一時鍵シェアkiを、該参加者の秘密鍵シェアVi及び署名シークレットシェアciと一緒に使用して生成され、秘密鍵V又は署名シークレットc（これらの両方も、参加者の少なくとも一部に未知である）のいずれも開示しない。
図１２Aは、rパズルトランザクション１２０２を生成する文脈で組み立てられた、閾値rパズルの例を概略的に示す。rチャレンジ１２０３は、未知の一時鍵kに対応するよう導出されるよう概略的に示され、その一時鍵シェア（k１,…,km）はそれぞれm人の参加者により保持される。証明トランザクション１２０４は、図７～１０を参照して上述した条件の下でのみ、rパズルトランザクション１２０２を満たす。しかしながら、rパズル１２０３が実施され、結局、これは証明トランザクションのs部分がrチャレンジ１２０３と同じ未知の一時鍵kに対応することを要求する。
図１２Bは、閾値rパズルの例を概略的に示すが、rパズルトランザクション１２０４を検証する文脈での時間フレームである。証明トランザクションのs部分sは、未知の一時鍵kに対応し署名サブセットπの参加者により保持される一時鍵シェアki,…k２t+１のセットに基づき導出されるように、概略的に示される。署名コンポーネントs１,…,s２t+１のセットが導出され、署名コンポーネントsiは、参加者iにより、彼の一時鍵シェアkiに基づき導出される。証明トランザクション１２０４は、従って、同じ未知の一時鍵kに対応するrチャレンジ１２０３を有するrパズルトランザクション１２０２を満たすことができる。
＜シークレット共有＞
そのようなシークレットシェアは、シャミアのシークレット共有（Shamir’s Secret Sharing (SSS)）に基づき導出される。SSSは、多項式補間に基づき、（一般性を失うことなく）以下である：
Figure 2022533753000057
後述するように、「ディーラ不要の」及び「ディーラに基づく」取引所の両方が適用されてよい。
一般的な表記φは、鍵シェア参加者のセットを示すために使用される。これは、フルセット（φ＝Π）又はそのサブセット（例えば、φ＝π、π'、又はπ''）であり得る。
シャミアのソリューションでは、任意のランダムシークレットσは、ｔ次多項式ｆ（ｘ）の中のｆ（０）として格納され、参加者ｉのみが自身のシェアｆ（ｘｉ）を計算できる。つまり、
Figure 2022533753000058
 ｎ人のうちのｔ＋１人の参加者が協力する場合、彼らは、ラグランジュ多項式補間を用いて、f(x１),f(x２),…,f(xn)に対応する（シークレットσの）彼らのシェアσ１,σ２,…,σMによりｆ（ｘ）上の任意の点を再構成できる。
ラグランジュ多項式補間を用いると、次数ｔを有する関数ｆ（ｘ）は、ｔ＋１個の点により再構成できる：
Figure 2022533753000059
 再構成は、次に、以下に従い実行される：
Figure 2022533753000060
 式（１）の特定の例では、φはt+１人の参加者のセットを示す：
Figure 2022533753000061
 しかしながら、上述のように、表記φは、本開示の別の場所で更に一般的に使用される。
閾数のユーザが式（１）のように問題のシークレット（例えば、k、V、又はc）を復元することは、理論的に可能であるが、これは、t+１人のユーザに、問題のシークレットの彼らのシェアを開示することを要求する。以下の例では、一時鍵k、秘密鍵V、又は共有シークレットcのいずれも（「基礎にあるシークレット」）再構成されず、いずれの参加者も彼の鍵シェアki,Vi,ciのいずれも開示することを要求されない。むしろ、開示の例は、SSSの特定の原理を適用して、rパズルの生成（図１３A）及びrパズルを満たす署名の生成（図１４A及び図１４B）の両方を実現し、基礎にあるシークレットを開示する要求を伴わない（全ての参加者のシークレットシェアki,Vi,ciは、該参加者に秘密のままにできる）。式（１）、は、それらの原理に特定の理論的コンテキストを提供するためにのみ提供され、記載される方法のいずれかの部分として適用されない。
項b(i,φ)(x)は、以下のように定義される：
Figure 2022533753000062
 以下に留意する：
Figure 2022533753000063
また、式（１）では、φはt+１人の参加者のセットを特に示したが、式（２）の定義は、参加者の任意のセットφ（φ＝Π、φ＝π、φ＝π'、φ＝π''を含む）に適用されることに留意する。つまり、疑義を避けるために、第１のインデックスiはφの中の参加者を示し、第２のインデックスφは、補間係数が定義される参加者のサブセットを示す。そのような補間係数は、後述するように、参加者の異なるセットについて式（２）に従い計算され、種々の目的のために使用される。
値b(i,φ)(０)、つまり、x=０で評価された式（２）は、「補間係数」と呼ばれ、本願明細書では以下の簡易表記が採用される。
Figure 2022533753000064
参加者φのセットの間でシークレットのシェア{σi｜i∈φ}を分配させるための２つの基本的方法がある。つまり、「ディーラに基づく鍵シェア分配（Dealer Based Keyshare Distribution）」及び「ディーラ不要の鍵シェア分配（Dealerless Based Keyshare Distribution）」である。
＜ディーラに基づく鍵シェア分配＞
ディーラが存在する場合、ディーラは、単に以下のシークレットを選択し：
Figure 2022533753000065
 以下をランダムに選び：
Figure 2022533753000066
 これは、以下の多項式の係数を表す：
Figure 2022533753000067
 ディーラは、次に、多項式に属する以下のM個の点を計算し：
Figure 2022533753000068
 それらを、φの中のM人の参加者に分配する。つまり、参加者iは点(xi,f(xi))を受信する。
ディーラは、Πの中の参加者又は別のパーティ（第三者ディーラ）であり得る。
＜ディーラ不要の鍵シェア分配＞
図１７は、参加者セットφの中の各参加者がシークレットσのシェアを取得する、ディーラ不要の取引所の概略図を示す。参加者iにより取得されたシェアはφiと示され、ディーラ不要の取引所は、シークレットσをφの中のいずれの参加者にも開示することなく実施される。
簡単のために、i及びjと示される２人の参加者のみが示されるが、以下の説明は任意の参加者数Mのセットφに関連することが理解される。
ディーラ不要の取引所は以下のように進行する。
各参加者i∈φは、φの中の全ての参加者により知られているx座標xiを割り当てられる。各ｘｉはユニークでなければならない。図１７は、参加者i、jにそれぞれ割り当てられたx座標xi,xjを示す。
各参加者i∈φは、次数ｔのランダム多項式ｆｉ（ｘ）を生成する（１７０２）。これは、参加者iにより保持される「多項式シェア」と呼ばれる。
各参加者i∈φは、全ての他の参加者j∈φに、多項式上のそれぞれの点fi(xj) mod nを秘密裏に送信する（１７０４）。つまり、参加者iの多項式シェアfiを、参加者jの知られているx座標xjに適用することにより取得された点である。
各参加者i∈φは、全部の彼らの受信したf１(xi),f２(xi),…fp(xi)及び彼ら自身の（all mod n）を加算して、次式を形成する：
Figure 2022533753000069
 これは、未知の多項式f(x) mod nのシェアである。
ここで、未知の多項式f(x)は、次のように定義され：
Figure 2022533753000070
 これは、ディーラに基づく取引所ではディーラにのみ知られている多項式に対応し、特にシークレットσ（該シークレットのシェアσiを各参加者が受信する）はσ=f(０)により与えられる。しかしながら、ディーラに基づく取引所と対照的に、多項式fが実際に導出されることはない（シークレットσではない）。むしろ、各参加者は、多項式上の１つの点の知識、つまり(xi,f(xi))、つまり自身のx座標における多項式の値のみを有する。
ここで、nは、楕円曲線上の生成元（generator point）Gにより生成されたグループの次数である。これは、署名検証チェックで使用されるのと同じnである。
示されたように、rパズルの文脈では、閾値署名方式が使用され、参加者のサブセットπがデジタル署名、特にECDSA署名を生成することを可能にする。実装では、以下のようなデジタル署名(r,s)のs部分：
Figure 2022533753000071
 を計算するために利用される秘密鍵V及び一時鍵kは、
ディーラ不要の分配の場合には、特定の個人に知られていない（ディーラに基づく鍵分配の場合にはディーラにのみ知られている）。代わりに、Πの中の各見込み参加者は、ECDSA署名を生成するとき、秘密鍵シェアVi及び一時鍵シェアki（決して開示されない）を与えられる。
これは、「閾値署名方式（threshold signature scheme (TSS)）」と呼ばれる。
TSSによりこのECDSA署名を生成する処理は、[JF Edit]で入手できる。その署名方式から、サブプロセスであるSecret Share Joining and Secure Inverseに注意を向ける。
＜rパズル閾値署名方式＞
rパズルの鍵特性は、それが、支払い受取人の「知識要件」を、秘密鍵xのものから一時鍵kのものへと移転することである。rパズルでは、秘密鍵kは、任意の秘密鍵xが正当なECDSA署名を生成するために使用できるという点で、該正当なECDSA署名を生成できるか否かに影響しない。従って、（rパズルについての）焦点は、一時鍵kに向けられる。
この原理は、図１８に概略的に示され、「通常の」ECDSAによるrパズルの基礎と対照的である。
ECDSA署名に対する閾値署名方式（TSS）の価値は、それが、「少なくとも何人の」関係者が署名を生成するために参加しなければならないかを決定できることである。この制約は、rパズルの保護するトランザクションアウトプットについても同様に要求されてよい。
基本的に、これは、rパズルの保護するUTXOを成功裏に使用することに参加することを、閾数の参加者に同様に要求してよい。rパズルの保護するアウトプットを保護する際に利用可能な（ディーラ不要の分配）閾値署名方式の説明が与えられる。
＜ディーラ不要のrパズル導出＞
閾値署名計算の重要な要素は、R=k×Gの決定である。ここで、kはシークレット鍵であり、Gは楕円曲線上の点である。
記号「×」及び「・」は、本願明細書で、楕円曲線スカラー乗算を示すために同義的に使用される。更に、それらの記号は、意味を変更することなく、つまり任意のスカラーb及び任意の楕円曲線点Bが与えられると、一緒に省略されてもよい。
Figure 2022533753000072
r部分は、rパズルトランザクション１２０２を生成するため、及び証明トランザクションの署名を生成するため、の両方で必要である。前者は、先ず、図１３Aを参照して検討される。
図１３Aは、rパズルがディーラ不要の取引所に基づき生成され得る処理（１２０３）の概略図を示す。
ディーラ不要の取引所１３０２は、参加者のフルセットΠにより実施され、各参加者i∈Πが一時鍵シェアkiを取得することを可能にする。
ディーラ不要の一時鍵シェア取引所１３０２は、図１７に示すように実施され、φ＝Φ（つまり、全参加者集合）、及びσ＝kである。
各参加者iが一時鍵シェアkiを取得することにより、t+１人の参加者のうちの任意のチャレンジサブセットπ'が、rパズル１２０３を設定するために協力してよい。これを行うために、彼らは、参照符号１６００により示される分散型r部分導出処理に従事する。
分散型r部分導出処理１６００は、図１６に概略的に示され、以下に説明される。
f(x)がt次多項式である場合、一時的なkは次式により補間され得る：
Figure 2022533753000073
 ここで、π'はサイズｔ＋１のシェアka,kb,…,kt,kt+１のサブセットであり、bi,π'は上述の式（３）により定義される補間係数である（kはt次多項式におけるx=０の点のy値であることに留意する、つまりk=f(０)）。しかしながら、それは、参加者に彼らの鍵シェアを開示することを要求し得る。
kを開示することを回避するために、代わりに、π’サブセットのプレイヤは、以下のように、彼らのシェアを開示することなく、k×Gを計算するために協力する。
各参加者i∈π'は、上述の式（３）のように補間係数bi,π'を計算する。図１３Aに、これは、参加者i及びjについて、それぞれステップ１６０２-i及び１６０２-jとして示される。
各参加者i∈π'は、次式のように公開一時鍵コンポーネントを計算する：
Figure 2022533753000074
 これは、参加者i及びjについて、それぞれステップ１６０４-i及び１６０４-jとして示される。
各参加者は、彼の公開一時鍵コンポーネントRi'を安全に開示でき、楕円曲線スカラー乗算の非逆算性（non-reversibility）により、kiはそれから復元できない。
これは、また、R'=k×Gを以下のように計算することを可能にする。
Figure 2022533753000075
 ここで、「Σ」は楕円曲線点加算を示す。つまり、公開一時鍵部分Ri’の楕円曲線点加算に基づく。
これは、ステップ１６０６として示される。このステップは、参加者のうちの任意のもの、又は任意の他のパーティにより、チャレンジサブセットπ'により公開された楕円曲線一時鍵コンポーネントRi’に基づき実行できることに留意する。rパズルは、また、以下のように設定できる（又は以下に基づくことができる）：
Figure 2022533753000076
 R'=kGを計算するこの処理は、本願明細書で使用される用語に従い、「Secret Share Joining」の形式と呼ばれる。
＜ディーラに基づくrパズル決定＞
図１３Bは、チャレンジトランザクション１２０２のためのrパズル１２０３を導出するための代替処理を示す。
この場合、ディーラ１３００（これは、参加者のうちの１人又は第三者であり得る）は、一時鍵kの知識を有するが、これは（他の）参加者には知られていない。
ディーラ１３００は、上述の方法で、Πの各参加者にkの鍵シェアkiを割り当て、kを使用してrパズルを設定する。
r'がディーラ不要の方式で又はディーラにより導出されるかに関係なく、r値は、プレイヤ（ディーラ、参加者、又は任意の他のパーティであってよい）に通信される。UTXOの文脈で、プレイヤは、rパズル１２０３によりロックされたアウトプットを有しr'を受信するとそうするようにされる支払いトランザクション１２０２の生成者である。rパズルによりロックされたUTXOを有するｒパズルトランザクション１２０２は、プレイヤにより生成される（つまり、「プレイヤ」は、ｒパズル１２０３によりロックされたアウトプットを有する支払いトランザクションであるチャレンジトランザクション１２０３の生成者である）。
＜署名生成＞
TSSにより明トランザクション１２０４のために署名(r,s)を生成するために、以下のステップが行われる。
これらのステップは、特定のステップの意味的説明を提供する図１４Aを参照して説明される。
上述のように、チャレンジサブセットπ'は、ｔ＋１人の参加者のグループである。本例では、π'は、２t+１人の参加者のうちの署名サブセットπのサブセットである。ここで、k-１におけるシェアの多項式はt次である。
UTXOの文脈で、「参加者」は、rパズル１２０３により保護されたUTXOを使用するECDSA署名を生成することに参加し得るエンティティのセットであると定義される。tが、シークレットkの依拠する多項式の次数であることを思い出してほしい。
参加者のセットは、一時鍵kの彼らの鍵シェアkiを決定する。これは、ディーラ不要の鍵シェア分配（図１３A）又はディーラに基づく分配（図１３B）を利用してよい。
ステップ１６００Aで、π'’=t+１人の参加者のr導出サブセットは、Secret Share JoiningによりkGを計算する。これを行うために、図１６の分散型r部分導出処理１６００が適用される。しかしながら、それらのステップは、証明トランザクション１２０２のr部分rを導出するために適用されていることに留意する（一方で、上述の例では、それらのステップは、rパズルトランザクション１２０４内のrチャレンジ１２０３の基礎を形成するr部分r'を生成するために適用される）。ステップは同じであるが、ステップ１６０６における出力は、r'ではなくrである（勿論、証明トランザクション１２０４が成功するためには、r=r'であるが、２つの表記の間で区別することは必ずしも有用ではない）。
署名生成の目的でrを導出するr導出サブセットπ''は、図１３Aの例でrパズルを生成する参加者のサブセットπ'（チャレンジサブセット）と同じであってよく又はそうでなくてよい（しかし、両者は、同じ数の参加者を有する、つまりt+１）。
証明トランザクション１２０４のための署名のr部分r（これは、rチャレンジ１２０３を満たすためにr'に等しくなければならない）は、以下のように計算される：
Figure 2022533753000077
 ここで、R''は、処理１６００でr導出サブセットπ''の参加者により公開された公開一時鍵コンポーネントに基づき導出される。参加者i∈π''により公開された公開一時鍵コンポーネントは、Ri'’と示され、ｒパズル１２０３の生成と区別される（しかし、その他の場合、上述した図１６に示されるコンポーネントRi’及びRj’に対応する）。Ri''は、式（３）に従い決定された補間係数bi,π''に基づき計算される。
参加者のセットは、ディーラ不要の鍵シェア分配を利用して、秘密鍵xの彼らの鍵シェアxiを決定する。
ECDSA署名を生成することは、次式となるように乗算反数（multiplicative inverse）k－１ mod nの使用を必要とする：
Figure 2022533753000078
 一時鍵kの値を保護しながら、反数を協働で組み込むために、以下のステップが行われる。これらは、参照符号１５００により示される、分散型s部分導出処理のステップである。
図１５は、分散型s部分導出処理１５００のステップの概略図を提供する。これらのステップは、図１５を参照して以下に説明される。
所望の署名を生成することに合意している２t+１人の参加者のうちの署名サブセットπは、ディーラ不要の鍵シェア分配を使用して、特定のシークレットc（署名シークレット）のシェアを計算する。cは、t次多項式上のシークレットであり、ciはシークレットsの参加者ｉのシェアである。
シークレットsは、参加者のフルセットに対して図１７のステップを適用することにより導出される。つまり、Φ＝Πであり、sはσの役割を満たす。
代替として、ディーラ１３００（又は別のディーラ）は、各参加者iにciを割り当ててよい。
各参加者iは、以下の部分を計算する：
Figure 2022533753000079
 （乗算反数コンポーネント）図１５では、これは、参加者i,jについてそれぞれ参照符号１５０２-i及び１５０２-jにより示される。
Ciは、mod nの適用により、kiciを開示することなく、安全に公開できる。
ステップ１５０４で、πの中の参加者からのコンポーネントCiは、一緒に加算され、以下を得る：
Figure 2022533753000080
 この値kc mod nは、グループπの全員に分配される。これは、また、以下のように乗算反数を計算するために使用される：
Figure 2022533753000081
 例えば、これは、グループ内の各参加者により又は他の場所で、公開されたコンポーネントCiに基づき計算され、各参加者へ通信されることができる。
各参加者iは、また、以下のように第２部分を計算する：
Figure 2022533753000082
 これは、また、参加者iの署名コンポーネントを計算するために以下のように使用できる：
Figure 2022533753000083
 これは、参加者i,jについてそれぞれ参照符号１５０８-i及び１５０２８jにより示される。
ここで、Viは、参加者iにより取得された秘密鍵シェアである。これは、φ＝Πで（つまり、参加者のフルセットに対して）又はφ＝πで（つまり、例えば１回限りの使用の秘密鍵シェアViのセットを生成するために、署名サブセットに対してのみ）図１７のステップを適用することにより、ディーラ不要の取引所において取得できる。代替として、ディーラ（ディーラ１３００又は別のディーラ）は、秘密鍵シェアを割り当ててよい。
ここで、rは、署名サブセットπの全ての参加者に共通のr部分であり、msは、これもそれらの参加者の全てに共通の署名済みメッセージデータを示す（上述の例では、ms=Hsig(m)）。
補間係数bi,πは、式（３）に従い計算される。
ステップ１５１０で、s部部分sは以下のように計算される。適用可能な場合には、グループπの各参加者iは、彼らの署名コンポーネントsiを計算のために提供する。
Figure 2022533753000084
署名は、シークレットcも、一時鍵k又はその鍵シェアのいずれも（適用可能な鍵シェアを保持する参加者iへのものを除く）、秘密鍵V又はその鍵シェアのいずれも（適用可能な鍵シェアを保持する参加者iへのものを除く）開示することなく生成されることに留意する。
図１４Bは、図１４Bの方法の変形を示す。本例では、チャレンジトランザクション１２０２の基礎を形成する値r'は、「平文で（intheclear）」含まれる。つまり、ｒ’は、チャレンジトランザクション１２０２自体から直接取り入れることができる（r'の一方向ハッシュまたは他の一方向変換とは対照的である）。この場合、証明トランザクション１２０４のための署名を導出する目的で、ステップ１６００Aは省略でき、チャレンジトランザクション１２０２内のr'の値は、署名のs部分を生成するために、他の必要な要素と関連して使用できる。図１５００のステップは、変更されないが、この場合には、ステップ１５０８-i、１５０８-jで使用されるr部分は、チャレンジトランザクション１２０４から取り入れられたr’値である。
注：「署名鍛造性（signature forgeability）」（以上を参照）を保護するs任意的な第２署名に関し、その署名は同じ秘密鍵シェアVi（しかし異なる一時鍵）に基づき生成されてよい。
＜アカウントに基づくモデルにおける代替の実装＞
以上は、大まかに、アウトプットに基づくモデル（例えば、UTXOに基づくモデル）における実装の観点で説明された。しかしながら、これは限定的ではないことが理解される。図１１は、アカウントに基づくモデルを使用する可能な代替の実装を示す。
要するに、アカウントに基づくモデルでは、rパズル機能は、ユーザにより呼び出されるスマートコントラクト関数に含まれ得る。あるパーティは、スマートコントラクト内にrパズル値（又はハッシングされたrパズル値）を設定できる。次に、他のパーティは、その後にスマートコントラクトに署名を提供し得る。
UTXOブロックチェーンアーキテクチャでは、第１トランザクションのアンロックスクリプト内に埋め込まれた要件は、第２トランザクションが有効であるとして受け入れられブロックチェーンに記録されるためには、第２トランザクションのロックスクリプトにより満たされなければならない。この状況で、トランザクション検証処理の部分としてマイナーにより既に行われた作業を利用するので、これは有利である。この状況における具体例として、トランザクションがブロックチェーンに追加されたという事実は、ブロックチェーンネットワーク全体に渡るノードにより検証されたことを意味し、また、そのロックスクリプトが特定の有用な要件を満たすことを意味する。関心のあるパーティは、彼ら自身のために、それらの要件が満たされるかどうかをチェックする必要がなく、トランザクションがブロックチェーンに記録されることに成功しているという事実により、彼らは、単に、それらの要件が満たされていると想定できる。これは、トランザクションが有効であるためには、スクリプトが完了すると「真」の結果を返さなければならないという事実に起因し（トランザクションが有効であるための他の要件が存在してもよい）、スクリプトが「偽」の結果を返した場合には（これは、本願明細書で使用される用語によると、例えばOP_VERIFYオペコードがスクリプトを終了したために、スクリプトが失敗した場合を含む）、トランザクションは無効である。
しかしながら、他のブロックチェーンモデル（例えば、特定のアカウントに基づくアーキテクチャ）では、トランザクション有効性と実行トランザクションコードの結果との間の相互依存性は必ずしもミラーリングされない。例えば、特定のスマートコントラクトブロックチェーンでは、トランザクションは、それらがブロックチェーンプロトコルにより課される「基本的」有効性要件のセットを満たすならば、有効であり、従って、ブロックチェーンに記録するために受け入れられてよい。従って、第２トランザクションは、第１トランザクションのコードに埋め込まれた特定の要件を満たさない場合でも、依然として有効であるとして受け入れられ、ブロックチェーンに記録されてよい。第１トランザクションのコードは、例えば、スマートコントラクトコードであってよい。
第２トランザクションが、第１トランザクションにより生成されたスマートコントラクトアカウントにアドレスされているとすると、それは次に、該トランザクションにどのように応答するかを決定するためにスマートコントラクトコードへと落とされる。例えば、何らかの要件が乱されない場合にそれを無視し（又は偽の結果を返し）、一方で、要件が正しい場合には、スマートコントラクトアカウントの残額から減額されクレジットされたデジタルアセットの額で、証明者に報酬を与える（又は真の値を返す）。ある意味、これは、ノードにより「暗示的に」実行される「プロトコルレベル」の処理、つまりブロックチェーンネットワークが動作するブロックチェーンプロトコルにより課される有効性の要件を満たすかどうかを決定するトランザクションに対して実行される処理から、スマートコントラクト（エージェント）による、つまりスマートコントラクトコード内に明示的にコーディングされた、「エージェントレベル」の処理を抽象化する。従って、そのようなブロックチェーンアーキテクチャでは、トランザクションそれぞれのプロトコルレベルにおけるノードによる「有効／無効」の決定は、スマートコントラクトによりエージェントレベルで該トランザクションに関して返される「真／偽」の結果から分離されてよい。ここで、トランザクションは、プロトコルレベルで有効であると決定されてよいが、エージェントレベルでは偽の結果を返してよい。
これは、トランザクションが有効であるために「スクリプトが真」の結果を返すことが必要であるUTXOアーキテクチャと対照的に、トランザクションは、スクリプトが終了した又はスタック上に真以外のものを残して完了した場合に、無効である。
トランザクション有効性のための基本的要件のうちの１つは、トランザクションが有効な署名を含むことであってよい。従って、上述のUTXIの例では、署名はチャレンジトランザクション自体のコードにより（例えば、署名を検証し署名検証について真／偽を返すOP_CHECKSIGオペコード、又は同じ方法で署名をチェックし、更に結果が真であることを検証し、否である場合にスクリプトが終了するOP_CHECKSIGVERIFYオペコードを用いて）検証されたが、代替のブロックチェーンアーキテクチャでは、署名は、上述の意味では暗示的に処理ノードにより検証されてよく、これは、トランザクションコード自体に署名チェックをコーディングする必要を回避できる。
本願の文脈では、具体的な例として、トランザクションは、例えば有効な署名を含むので、プロトコルレベルで有効であると考えられる。しかし、例えば、何らかの他の要件が満たされないので、アプリケーションレベルでは依然として偽の結果を返してよい。
図１１は、アカウントに基づくモデルによる、トランザクションを処理するノードソフトウェア４００の代替案を示す。ノードソフトウェアはここでは４００accとラベル付けされる。このノードソフトウェア４００accのインスタンスは、ネットワーク１０６のアカウントに基づくバージョンのノード１０４の各々に実装されてよい。アカウントに基づくノードソフトウェア４００accは、アカウントに基づくプロトコルエンジン４０１acc、コントラクトエンジン４０２acc(スクリプトエンジン４０２と同様のもの）、アプリケーションレベルの決定エンジン４０４、及び１つ以上のブロックチェーン関連機能モジュールのセット４０５を含む。任意の所与のノード１０４で、これらは、（ノードの１つ以上の役割に依存して）マイニングモジュール４０５M、転送モジュール４０５F、及び格納モジュール４０５S、のうちの任意の１、２、又は３個全部を含んでよい。プロトコルエンジン４０１accは、トランザクションの異なるフィールドを認識し、それらをノードプロトコルに従い処理するよう構成される。ノードソフトウェア４００accは、それぞれのノード１０４のメモリに、複数のアカウントの各々のアカウント状態４０６も維持している。これらは、例えば、Alice、証明者（例えば、Bob）、及び／又はAliceと証明者との間で制定されるコントラクトに依存して借り方又は貸し方である別のパーティのアカウントを含み得る。コントラクトエンジン４０２accは、トランザクション内で受信したスマートコントラクトの結果に依存して、アカウント状態を変更するよう構成される。スマートコントラクトは、「エージェント」とも呼ばれる。
図１１は、図７～１０に関して上述したものと同じ又は同様のrパズル機能を実装し得るトランザクションTx１ acc及びTx２ accのペアも示す。それぞれは、（ソースアドレスフィールド内の）ソースアカウントアドレス１１０２、及び（宛先アドレスフィールド内の）宛先アカウントアドレス１１０３を含む。第１トランザクションTx１ accは、ソースアカウントアドレス１１０２a及び宛先アカウントアドレス１１０３aを含む。第２トランザクションTx２ accは、ソースアカウントアドレス１１０２b及び宛先アカウントアドレス１１０３bを含む。第１トランザクションTx１ accは、スマートコントラクト１１０１も含む。スマートコントラクト１１０１は、Aliceによるチャレンジ（パズル）を含んでよい。それは、Aliceにより、又はAliceにより提供された詳細を用いてAliceに代わる第三者により生成されてよい。第２トランザクションTx２ accは、任意的に、ユーザの指定したペイロードデータを運ぶ１つ以上の手数料データフィールド１１０４を含んでよい。これ／これらは、証明者、例えばBobにより提供されたパズルに対する解の少なくとも部分を含んでよい。トランザクションTx１ acc及びTx２ accは、更にAlice及び証明者によりそれぞれ署名される。各トランザクションは、それぞれのパーティの署名１１０５a、１１０５bも含む。
トランザクションは、ネットワーク１０６に渡りブロードキャストされる。プロトコルエンジン４０１accは、各トランザクションを受信すると、署名１１０５が有効か否かを自動的に検証する。つまり、これは、プロトコルエンジン４０１accの固有の機能であり、スマートコントラクト１１０１内で指定される必要がない。プロトコルエンジン４０１accは、従って、少なくともそれぞれの署名が有効であることを条件に、転送及び／又はマイニングのために各トランザクションを検証する。それは、満たされるべき、有効性のための１つ以上の追加条件を要求してもよい。有効ならば、アプリケーションレベル決定エンジン４０４は、それぞれトランザクションをマイニング及び／又は転送するよう、マイニングモジュール４０５M及び／又は転送モジュール４０５Fを制御するかを選択できる。
そのようなアカウントに基づくモデルでは、Alice、Bob、及びスマートコントラクト自体は、異なるアカウントアドレスを有する別個のアカウントを割り当てられる。トランザクションは、そのソースアドレスフィールド内のアドレス「から」、その宛先アドレスフィールド内のアドレス「へ」、送信されると言える。スマートコントラクト用にアカウントを生成するために、スマートコントラクトのバイトコードを含むトランザクションが、トランザクションの中でブロックチェーンにアップロードされる。そのようなアカウント生成トランザクションでは、宛先フィールド内の宛先アドレス１１０３は、ブロックチェーンにおいて以前に使用されたことがないアドレスでなければならない。一旦、トランザクションが受け付けると、そのアドレスは、新たに生成されたスマートコントラクトアカウントのアドレスになる。その後、更なるトランザクションは、スマートコントラクトを「呼び出す」ためにそのアドレスへ送信されることができ、つまり、更なるトランザクションに依存して、スマートコントラクトのバイトコードを実行させる。「宛先」アドレス１１０３は、コントラクトを制定するために中間アドレスとして動作する。Aliceは、１つ以上の要件を指定するスマートコントラクトを生成するために、TX１ accをそのアドレスへ送信する。Bobは、スマートコントラクトを呼び出すために、TX２ accをその同じアドレスへ送信する。また、スマートコントラクトに、TX２ accがそれらの指定された要件を満たすか否かを検証させる。「ソース」アドレス１１０２は、コントラクトに対するパーティであるユーザのアカウントを指定する。スマートコントラクトがTX２ accは指定された要件を満たすと決定した場合、スマートコントラクトは、自身の口座（アカウント）残高からデジタルアセットの額を控除し、TX２ acc内のソースアドレス１１０２bを有するアカウント（つまり、Bobのアカウント）の残高をその額だけクレジットさせる（credit、貸し方に記入する）（直感的には、TX２ accを送信することにより、Bobは、事実上、（ソースアドレスフィールド内で識別される）彼のアカウントをクレジットするよう（宛先アドレスフィールド内で識別される）スマートコントラクトに依頼する）。
プロトコルエンジン４０１accは、TX２ accを受信すると、それが有効であることを条件に、TX２ acc内の宛先アドレス１１０３bと一致するアカウントを探す。Tx１ accが処理され、有効であるとすると、そのアカウントは、TX１ accのお陰で存在し、TX１内で提供されたスマートコントラクトコードに関連付けられる。応答して、プロトコルエンジン４０１accは、Tx１ accからのスマートコントラクト１１０１を実行するよう、コントラクトエンジン４０２accを制御し、コントラクト内にどんな基準が定義されているかに依存して、スマートコントラクトの１つ以上のフィールドからのデータをオペランドデータとして取り入れる。オペランドデータは、例えば、自由データフィールド１１０４の１つ以上からのデータ、及び／又は署名フィールド１１０５bからの署名を含んでよい。Tx２ accからのオペランドデータがTx１ accのスマートコントラクト１１０１内に定義された１つ以上の基準を満たすことを条件として、コントラクトエンジン４０２accは、スマートコントラクト１１０１内に定義された変更に従い、１つ以上のパーティ（Alice、証明者、及び／又は１人以上の第三者）のアカウント状態４０６を変更する。その他の場合、アカウント状態４０６に対するこの変更は行われない。しかしながら、幾つかのアカウントに基づくシステムでは、スマートコントラクトの結果は、トランザクションの有効性のための条件ではない。従って、Tx２ accがTx１ accのスマートコントラクト１１０１内に設定された基準を満たさない場合、Tx２ accは、失敗したトランザクションのレコードとして、依然として伝播されブロックへとマイニングされる。それは、依然としてマイニング手数料ももたらし得る（従って、プロトコルエンジン４０１は、依然として、パーティのうちの１つ及び勝者であるマイナーのアカウント状態４０６を変更してよい）。
rパズルを実装するために、rパズル機能の少なくとも一部は、Tx１ accのスマートコントラクト１１０１内にコーディングされることができ、解は、Tx２ accのデータフィールド１１０４の１つ以上の中で提示できる。例えば、これは、図７の変形を実装するために使用され得る。任意的に、プロトコルエンジン４０１accの暗示的署名検証機能の一部は、例えば、図８～１０の変形のうちの１つを実装するために、利用され得る。図８～１０の場合には、ステップＩＩ）及びＩＩＩ）は、Tx２ accの署名を検証するとき、プロトコルエンジン４０１accの陰関数であってよい（署名検証自体はプロトコルエンジン４０１accにより実装されるノードプロトコルの固有機能であることを思い出してほしい）。従って、Tx１ accのスマートコントラクト１１０１では、これの上にステップＩ）を積み重ねるだけでよい。スマートコントラクトは、Ｉ）の結果が真であるかどうか、及びプロトコルエンジン４０１accがTx２ accは有効であると示すかどうか、をチェックする。両方がYesである場合、それは、検証について「真」の全体の結果を宣言する。つまり、Bobは、rパズルにより設定されたチャレンジを満たすことに成功する。図８～１０の実装のうち、図９及び１０の場合にデータ値dのみが、自由データフィールド１１０４に含まれる必要があるだけであることに留意する。署名情報は、署名フィールド１１０５bに含まれる。
スマートコントラクトアカウントは、アカウントに関連付けられた（論理的）データ記憶要素である「データレジスタ」（図示しない）ともインデックスを付される。以上に概説したUTXOモデルでは、値は、ロックスクリプト自体に埋め込まれ、同じことがスマートコントラクトコード１１０１の特定のピースについても言える。しかしながら、スマートコントラクトのスマートコントラクトバイトコードは、代替として又は追加で、そのアカウントレジスタのうちの１つ以上に格納されたデータで実行されてよい。更に、通常、スマートコントラクトアカウントが生成された後に、スマートコントラクトアカウントレジスタに値を格納することが可能である。従って、例えば、スマートコントラクトアカウントは、スマートコントラクトバイトコードを含むチャレンジトランザクションTx１,α accにより生成されてよい。別個の「中間」トランザクションTx１,β accは、次に、（今や存在する）スマートコントラクトアカウントへ送信されてよく、スマートコントラクトアカウントのレジスタ＄Rに特定の値vを格納する効果を有する。スマートコントラクトは、（例えば）指定されたソースアカウントアドレス、例えば第１の場所（Alice）でスマートコントラクトを生成した同じパーティからのそのようなデータのみを受け付けるよう構成されてよい。Tx２ accが受信されると、コントラクトエンジン４０２accにより実行される演算（例えば、「レジスタ＄Rにアクセスし、値をTx２ accのデータフィールド内の値＄Dと比較する」）は、チャレンジトランザクションTx１,α acc内で提供されるスマートコントラクトバイトコードにより定義される。しかし、$Rに格納された値は、中間トランザクションTx１,β accにより設定されている。本願明細書で使用される用語によると、Tx１,α accは、依然として、１つ以上の要件を設定するチャレンジトランザクションと言える。今や、それらの要件のみが、１つ以上の中間トランザクション（例えば、Tx１,β acc）内で提供されるデータを参照して定義されてよい。
従って、幾つかの実装では、チャレンジトランザクションTx１,α accは、ｒパズルの演算（例えば、証明トランザクションTx２ accの署名のr部分をレジスタ$R内の値と比較し、それらが一致するかを調べる、等）を定義してよい。しかし、証明トランザクションTx２ accのr部分と比較される$R内の値は、中間トランザクションTx１,βaccにより送信されてよい。
幾つかのアカウントに基づくモデルは、署名１１０５と一緒に公開鍵Pが含まれることを必要としないことにも留意する。代わりに、単に１ビットフラグflgを含む。上述のように、（r,s）及びメッセージから２つの可能な鍵P及び-Pを導出することが可能である。フラグflgは、これらの２つの可能な解のうちのどちらが、実際に、Tx２ accにおいてメッセージに署名するために証明者により使用された秘密鍵Vに対応する公開鍵であるかをシグナリングするために使用される。プロトコルエンジン４０１accは、この（r,s）及びflgを使用して、Tx２ accの中で明示的に受信する代わりに、署名者の公開鍵Pを導出する。この技術は、アウトプットに基づくモデルでも可能であり、アカウントに基づくモデル専用ではない。しかし、多くの現在のアウトプットに基づくモデルで使用されるスクリプト言語では、r及びsからPを導出するための専用オペコードが存在しない。従って、この機能を、スタックに基づく言語の既存の汎用オペコードを用いてアンロックスクリプト内に明示的にコーディングすることは複雑になるだろう。更に、特定のアカウントに基づくモデルは、トランザクションに署名するために使用された公開鍵から該トランザクションのソースアドレスを導出することに留意する。従って、ソースアドレスは、必ずしも、トランザクション内で別個に符号化されず、公開鍵が署名から導出される場合には、これは、ソースアドレスも署名から間接的に導出され得ることを意味する。
上記の実施形態は、単なる例示として説明したものであることが理解されるであろう。
より一般的には、本願明細書に開示された第１の態様によると、（「例１」）コンピュータにより実施される方法であって、
ブロックチェーンネットワークにより維持されるブロックチェーンに記録するために、少なくとも１つの証明トランザクションを生成するステップであって、前記少なくとも１つの証明トランザクションは、楕円曲線デジタル署名アルゴリズム（ECDSA）署名の少なくともs部分を含み、前記s部分は署名コンポーネントのセットから計算され、前記署名コンポーネントの各々は、鍵シェア参加者のセットのうちの署名サブセットの参加者により提供される、ステップを含み、
前記鍵シェア参加者の各々は、未知の一時鍵の一時鍵シェアを保持し、前記署名コンポーネントの各々は、前記参加者により保持される前記一時鍵シェアに基づき前記署名サブセットの参加者により提供され、
前記少なくとも１つの証明トランザクションは、少なくとも１つのチャレンジトランザクションのrチャレンジを示して、前記ブロックチェーンネットワークのノードに、前記少なくとも１つの証明トランザクションを受信することに応答して、以下に署名検証を適用させる：
（ｉ）前記少なくとも１つの証明トランザクションの前記s部分、及び、
（ｉｉ）以下のうちの１つ：
（ｉｉａ）前記rチャレンジのr部分であって、それにより、前記rチャレンジの前記r部分が前記未知の一時鍵に対応しない場合に前記署名検証が失敗し、
（ｉｉｂ）前記少なくとも１つの証明トランザクションのr部分であって、その場合に、前記ノードに、更に、前記少なくとも１つの証明トランザクションの前記r部分が前記rチャレンジを満たすことをチェックさせ、それにより、前記少なくとも１つの証明トランザクションの前記r部分が前記未知の一時鍵に対応しない場合に前記署名検証が失敗す、前記少なくとも１つの証明トランザクションの前記r部分が前記rチャレンジを満たさない場合に前記チェックが失敗する、
方法が提供される。
第１の態様の例示的な実施形態は、更なる列挙される例として以下に記載される。
例２。前記一時鍵シェアは、前記一時鍵が前記参加者のうちのいずれにも知られることなく、ディーラ不要の取引所において前記鍵シェア参加者のセットにより決定される、例１に記載の方法の実施形態。
例３。各参加者は、ディーラに基づく取引所において、ディーラにより前記一時鍵シェアを割り当てられる、例１に記載の方法の実施形態。
例４。前記少なくとも１つのチャレンジトランザクションは、前記ディーラにより生成されるか又は生成させられる、例３に記載の方法の実施形態。
例５。前記鍵シェア参加者のセットΠの各参加者により保持される前記一時鍵シェアkiは次式により導出され、
Figure 2022533753000085
 ここで、nは素数整数であり、fは多項式であり、xiは参加者iに割り当てられたx座標である、例１～４のいずれかに記載の方法の実施形態。
例６。前記ディーラ不要の取引所において、前記鍵シェア参加者のセットΠの各参加者は、互いに、鍵シェア参加者のセットΠの参加者jに、該参加者iへの多項式シェアfiシークレットを、他の参加者jに割り当てられた前記x座標xjに適用することにより導出されたy座標fi(xj)を提供し、
各参加者iへの前記一時鍵シェアkiシークレットは、次式により導出される：
Figure 2022533753000086
 例２に従属する例５に記載の方法の実施形態。
例７。前記署名コンポーネントのセットを提供するために、前記署名サブセットπの各参加者iは、以下の逆算コンポーネントを提供し：
Figure 2022533753000087
 ここで、ciは署名シークレットのシェアであり、bi,πは次式により与えられる補間係数であり：
Figure 2022533753000088
 前記逆算コンポーネントは、以下のように乗算反数を計算するために結合され：
Figure 2022533753000089
 前記署名サブセットπの各参加者は、前記乗算反数k-１c-１ mod nを使用して、以下のように該参加者iのための前記署名コンポーネントを提供し：
Figure 2022533753000090
 ここで、Viは該参加者iの秘密鍵シェアであり、msは前記少なくとも１つの証明トランザクションの署名済みメッセージデータであり、rは各署名コンポーネントsiのために使用される共通のr部分であり、
前記s部分は、次式のように公開された署名コンポーネントから計算される：
Figure 2022533753000091
 例５又は６に記載の方法の実施形態。
例８。前記共通のr部分は、各署名コンポーネントsiを計算するために前記少なくとも１つのチャレンジトランザクションの前記rチャレンジから取り入れられる、例７に記載の方法の実施形態。
例９。前記共通のr部分は、各署名コンポーネントsiを計算するために、複数の公開一時鍵コンポーネントから導出され、各公開一時鍵コンポーネントは、前記鍵シェア参加者のセットのうちのr導出サブセットπ''の参加者により、該参加者により保持されるシークレット一時鍵に基づき提供される、例７に記載の方法の実施形態。
例１０。前記公開一時鍵コンポーネントRi''の各々は、それを提供した、前記r導出サブセットπ''の参加者iにより次式のように決定され：
Figure 2022533753000092
 ここで、bi,π''は、次式のように決定される補間係数であり：
Figure 2022533753000093
 各署名コンポーネントsiを生成するために使用される前記共通のr部分は、次式のように導出される：
Figure 2022533753000094
 例９に記載の方法の実施形態。
例１１。各参加者iは、ディーラ不要の取引所において、前記秘密鍵シェアViを割り当てられる、例７～１０のいずれかに記載の方法の実施形態。
例１２。鍵シェア参加者iは、前記署名シークレットcをいずれの参加者に開示することなく、ディーラ不要の取引所において前記署名シークレットcのシェアciを割り当てられる、例７～１１のいずれかに記載の方法の実施形態。
第２の態様は、コンピュータにより実施される方法であって、
ブロックチェーンネットワークにより維持されるブロックチェーンに記録するために少なくとも１つのチャレンジトランザクションを生成するステップであって、前記少なくとも１つのチャレンジトランザクションは、未知の一時鍵に対応するrチャレンジを含み、鍵シェア参加者のセットのうちの各参加者は、前記未知の一時鍵の一時鍵シェアを保持する、ステップを含み、
前記少なくとも１つのチャレンジトランザクションは、前記ブロックチェーンネットワークのノードに、前記少なくとも１つのチャレンジトランザクションの前記rチャレンジを示す少なくとも１つの証明トランザクションを受信することに応答して、楕円曲線デジタル署名アルゴリズム（ECDSA）の署名検証関数を、以下に適用させる：
（ｉ）前記少なくとも１つの証明トランザクションのs部分、及び
（ｉｉ）以下のうちの１つ：
（ｉｉａ）前記rチャレンジのr部分であって、その場合には、前記少なくとも１つの証明トランザクションの前記s部分が前記未知の一時鍵に対応しない場合に、署名検証は失敗し、又は、
（ｉｉｂ）前記少なくとも１つの証明トランザクションのr部分であって、その場合には、前記ノードに、更に、前記少なくとも１つの証明トランザクションの前記r部分が前記rチャレンジを満たすことをチェックさせ、それにより、前記少なくとも１つの証明トランザクションの前記r部分が前記rチャレンジを満たさず、従って前記未知の一時鍵に対応しない場合に、前記チェックが失敗する、方法を提供する。
第２の態様の例示的な実施形態は、更なる列挙される例として以下に記載される。
例１４。前記rチャレンジは、複数の公開一時鍵コンポーネントから導出され、各公開一時鍵コンポーネントは、前記鍵シェア参加者のセットのうちのチャレンジサブセットの参加者により、該参加者により保持される前記一時鍵に基づき提供される、例１３に記載の方法の実施形態。
例１５。の実施形態を前記公開一時鍵コンポーネントの各々は、それを提供した、前記チャレンジサブセットπ'の参加者iにより次式のように決定され：
Figure 2022533753000095
 ここで、kiは、該参加者iにより保持される前記一時鍵シェアであり、bi,π'は、次式のように決定される補間係数であり：
Figure 2022533753000096
 前記rチャレンジは、次式のように導出される公開一時鍵のデータを含む：
Figure 2022533753000097
 例１４に記載の方法の実施形態。
例１６。前記一時鍵シェアは、前記一時鍵が前記参加者のうちのいずれにも知られることなく、ディーラ不要の取引所において前記鍵シェア参加者のセットにより決定される、例１３～１５のいずれかに記載の方法の実施形態。
例１７。各参加者は、ディーラに基づく取引所において、ディーラにより前記一時鍵シェアを割り当てられ、前記rチャレンジは、前記ディーラにより生成されるか又は生成させられる、例１３～１５のいずれかに記載の方法の実施形態。
例１８a。前記鍵シェア参加者のセットΠの各参加者により保持される前記一時鍵シェアkiは次式により導出され、
Figure 2022533753000098
 ここで、nは素数整数であり、fは多項式であり、xiは参加者iに割り当てられたx座標である、例１３～１７のいずれかに記載の方法の実施形態。
例１８b。前記一時鍵シェアは、例６に記載の方法で、ディーラ不要の取引所において取得される、例１８aに記載の方法の実施形態。
例１８c。前記一時鍵シェアはディーラにより割り当てられる、例１８aに記載の方法の実施形態。
例１９。前記少なくとも１つの証明トランザクションは、第２トランザクション署名を含み、前記s部分及び前記第２トランザクション署名は、共通秘密鍵又は秘密鍵シェアの共通セットを用いて生成され、異なる一時鍵又は一時鍵シェアの異なるセットに基づき生成される、請求項１３～１８cのいずれかに記載の方法の実施形態。
例２０。前記ノードは、前記少なくとも１つの証明トランザクションの第２トランザクション署名を検証させられ、前記s部分及び前記第２トランザクション署名は、共通の公開鍵に基づき検証されるが、前記第２トランザクション署名は異なるr部分に基づき検証される、例１～１２のいずれかに記載の方法の実施形態。
例２１。前記rチャレンジはr部分ハッシュを含み、前記ノードに、
前記署名検証関数を前記少なくとも１つの証明トランザクションの前記r部分及び前記s部分に適用させ、
前記少なくとも１つの証明トランザクションの前記r部分に基づき、トランザクションr部分ハッシュを計算させ、
前記トランザクションr部分ハッシュが前記rチャレンジの前記r部分ハッシュに一致するかどうかをチェックさせ、それにより前記rチャレンジが満たされるかどうかをチェックする、
例１～２０（第１又は第２の態様又はそのいずれかの実施形態）のいずれかに記載の方法の実施形態。
例２２。別の態様は、少なくとも１つの証明トランザクションを生成するコンピュータシステムであって、アクセス可能なコンピュータメモリに保持された署名コンポーネントのセットに基づき、少なくとも１つの証明トランザクションのs部分を生成するために、例１～１２のいずれかに記載の方法を実施するようプログラムされた１つ以上のコンピュータを含む、システムを提供する。
例２３。別の態様は、少なくとも１つのチャレンジトランザクションを生成するコンピュータシステムであって、アクセス可能なコンピュータメモリに保持された複数の公開一時鍵コンポーネントから、少なくとも１つのチャレンジトランザクションのrチャレンジを導出するために、例１４～１５のいずれかに記載の方法を実施するようプログラムされた１つ以上のコンピュータを含む、システムを提供する。
例２４。別の態様は、前記方法を実施するために例２２又は２３の前記１つ以上のコンピュータをプログラミングするための実行可能コンピュータ命令を含むコンピュータプログラムを提供する。
例２５。第３の態様は、システムであって、
鍵シェア参加者の参加者装置のセットであって、各参加者装置は前記鍵シェア参加者のうちの１人の一時鍵シェアへのアクセスを有し、前記一時鍵シェアは未知の一時鍵に対応する、参加者装置のセットと、
ブロックチェーンを維持するよう構成されるブロックチェーンネットワークと、
を含み、
前記ブロックチェーンネットワークの少なくとも１つのノードは、rパズルを含む少なくとも１つのチャレンジトランザクションを格納するよう構成されるコンピュータメモリを含み、
前記少なくとも１つのチャレンジトランザクションは、前記ノードに、前記少なくとも１つのチャレンジトランザクションの前記rパズルを示す少なくとも１つの証明トランザクションを受信することに応答して、署名検証を以下に適用させる：
（ｉ）前記少なくとも１つの証明トランザクションのs部分、
（ｉｉ）以下のうちの１つ：
（ｉｉａ）前記rチャレンジのr部分であって、前記rチャレンジの前記r部分が前記未知の一時鍵に対応しない場合に前記署名検証は失敗し、
（ｉｉｂ）前記少なくとも１つの証明トランザクションのr部分であって、その場合に、前記ノードに、更に、前記少なくとも１つの証明トランザクションの前記r部分が前記rチャレンジを満たすことをチェックさせ、前記少なくとも１つの証明トランザクションの前記r部分が前記未知の一時鍵に対応しない場合に、前記署名検証は失敗し、前記少なくとも１つの証明トランザクションの前記r部分が前記rチャレンジを満たさない場合に前記チェックは失敗する、システムを提供する。
実施形態では、上述のトランザクションのうちの何れかは、ノードにより証明トランザクショントランザクションを検証するために、ノードにより処理されてよく、前記証明トランザクションが有効であると決定された場合、前記ノードは、前記証明トランザクションに有効化され、前記ノード前記は証明トランザクションをブロックチェーンネットワークにより維持されているブロックチェーンに記録させる。
例えば、そのような検証は、UTXOモデルにおいて適用されてよい。
代替又は追加で、上述のトランザクションのうちの何れかがノードにより処理されてよく、ノードは、真の結果、及び偽の結果のうちの１つを返す（そして、真の結果は、トランザクションが有効である場合に要求されてよく又はされなくてよい）。
しかしながら、例えば、アカウントに基づくモデルでは、有効なトランザクションは、偽の結果を返してよい。
任意のrパズルの文脈で、少なくとも１つの証明トランザクションのECDSA署名を検証するために使用される公開鍵は、少なくとも１つの証明トランザクション内で示されるが、少なくとも１つのチャレンジトランザクションによっては（或いはその他の場合にはブロックチェーン上で又はその他で）指定されないことがあり得る。従って、任意の秘密鍵は、ECDSA署名を生成するために使用されてよい（従って、署名は、それを生成するために誰の秘密鍵が使用されるかに関係なく、有効であってよい）。
公開鍵は、少なくとも１つの証明トランザクション内の文字列（string）として符号化され、それにより、少なくとも１つの証明トランザクション内で示され、マラは少なくとも１つの証明トランザクションのECDSA署名から導出されてよく、それにより、公開鍵はECDSA署名自体により示される。
少なくとも１つの証明トランザクションは、チャレンジトランザクションのトランザクション識別子を含み、それにより、チャレンジトランザクション（又はその適用可能な、rパズル、コード、等のようなコンポーネント）を示してよい。
代替として、少なくとも１つのチャレンジトランザクションは、rパズル、コード、又は他のコンポーネントを、アカウントアドレスに関連付けてよく、少なくとも１つの証明トランザクションは、一致するアカウントアドレスを含み、それにより、チャレンジトランザクションの該コンポーネントを示してよい。
本明細書に開示される別の態様によれば、第１パーティ（チャレンジャー）、第２パーティ（証明者）、関連し得る任意の第３者、及びノードのネットワーク（ブロックチェーンネットワーク）を備える方法を提供することができる。
本明細書に開示される別の態様によれば、第１パーティのコンピュータ機器、第２パーティのコンピュータ機器、任意の第３者のコンピュータ機器、及びノードのネットワークを備えるシステムを提供することができる。
開示された技術の他の変形例又は使用事例は、本明細書で開示されると、当業者に明らかになり得る。本開示の範囲は、記載された実施形態によって限定されるものではなく、添付の特許請求の範囲によってのみ限定される。

Claims (25)

  1. コンピュータにより実施される方法であって、
    ブロックチェーンネットワークにより維持されるブロックチェーンに記録するために、少なくとも１つの証明トランザクションを生成するステップであって、前記少なくとも１つの証明トランザクションは、楕円曲線デジタル署名アルゴリズム（ECDSA）署名の少なくともs部分を含み、前記s部分は署名コンポーネントのセットから計算され、前記署名コンポーネントの各々は、鍵シェア参加者のセットのうちの署名サブセットの参加者により提供される、ステップを含み、
    前記鍵シェア参加者の各々は、未知の一時鍵の一時鍵シェアを保持し、前記署名コンポーネントの各々は、前記参加者により保持される前記一時鍵シェアに基づき前記署名サブセットの参加者により提供され、
    前記少なくとも１つの証明トランザクションは、少なくとも１つのチャレンジトランザクションのrチャレンジを示して、前記ブロックチェーンネットワークのノードに、前記少なくとも１つの証明トランザクションを受信することに応答して、以下に署名検証を適用させる：
    （ｉ）前記少なくとも１つの証明トランザクションの前記s部分、及び、
    （ｉｉ）以下のうちの１つ：
    （ｉｉａ）前記rチャレンジのr部分であって、それにより、前記rチャレンジの前記r部分が前記未知の一時鍵に対応しない場合に前記署名検証が失敗し、
    （ｉｉｂ）前記少なくとも１つの証明トランザクションのr部分であって、その場合に、前記ノードに、更に、前記少なくとも１つの証明トランザクションの前記r部分が前記rチャレンジを満たすことをチェックさせ、それにより、前記少なくとも１つの証明トランザクションの前記r部分が前記未知の一時鍵に対応しない場合に前記署名検証が失敗し、前記少なくとも１つの証明トランザクションの前記r部分が前記rチャレンジを満たさない場合に前記チェックが失敗する、
    方法。
  2. 前記一時鍵シェアは、前記一時鍵が前記参加者のうちのいずれにも知られることなく、ディーラ不要の取引所において前記鍵シェア参加者のセットにより決定される、請求項１に記載の方法。
  3. 各参加者は、ディーラに基づく取引所において、ディーラにより前記一時鍵シェアを割り当てられる、請求項１に記載の方法。
  4. 前記少なくとも１つのチャレンジトランザクションは、前記ディーラにより生成されるか又は生成させられる、請求項３に記載の方法。
  5. 前記鍵シェア参加者のセットΠの各参加者iにより保持される前記一時鍵シェアkiは次式により導出され、
    Figure 2022533753000099
     ここで、nは素数整数であり、fは多項式であり、xiは該参加者iに割り当てられたx座標である、請求項１～４のいずれかに記載の方法。
  6. 前記ディーラ不要の取引所において、前記鍵シェア参加者のセットΠの各参加者iは、互いに、鍵シェア参加者のセットΠの参加者jに、該参加者iへの多項式シェアfiシークレットを、他の参加者jに割り当てられた前記x座標xjに適用することにより導出されたy座標fi(xj)を提供し、
    各参加者iへの前記一時鍵シェアkiシークレットは、次式により導出される：
    Figure 2022533753000100
     請求項２に従属する請求項５に記載の方法。
  7. 前記署名コンポーネントのセットを提供するために、前記署名サブセットπの各参加者iは、以下の逆算コンポーネントを提供し：
    Figure 2022533753000101
     ここで、ciは署名シークレットのシェアであり、bi,πは次式により与えられる補間係数であり：
    Figure 2022533753000102
     前記逆算コンポーネントは、以下のように乗算反数を計算するために結合され：
    Figure 2022533753000103
     前記署名サブセットπの各参加者は、前記乗算反数k-１c-１ mod nを使用して、以下のように該参加者iのための前記署名コンポーネントを提供し：
    Figure 2022533753000104
     ここで、Viは該参加者iの秘密鍵シェアであり、msは前記少なくとも１つの証明トランザクションの署名済みメッセージデータであり、rは各署名コンポーネントsiのために使用される共通のr部分であり、
    前記s部分は、次式のように公開された署名コンポーネントから計算される：
    Figure 2022533753000105
     請求項５又は６に記載の方法。
  8. 前記共通のr部分は、各署名コンポーネントsiを計算するために前記少なくとも１つのチャレンジトランザクションの前記rチャレンジから取り入れられる、請求項７に記載の方法。
  9. 前記共通のr部分は、各署名コンポーネントsiを計算するために、複数の公開一時鍵コンポーネントから導出され、各公開一時鍵コンポーネントは、前記鍵シェア参加者のセットのうちのr導出サブセットπ''の参加者により、該参加者により保持されるシークレット一時鍵に基づき提供される、請求項７に記載の方法。
  10. 前記公開一時鍵コンポーネントRi''の各々は、それを提供した、前記r導出サブセットπ''の参加者iにより次式のように決定され：
    Figure 2022533753000106
     ここで、bi,π''は、次式のように決定される補間係数であり：
    Figure 2022533753000107
     各署名コンポーネントsiを生成するために使用される前記共通のr部分は、次式のように導出される：
    Figure 2022533753000108
     請求項９に記載の方法。
  11. 各参加者iは、ディーラ不要の取引所において、前記秘密鍵シェアViを割り当てられる、請求項７～１０のいずれかに記載の方法。
  12. 鍵シェア参加者iは、前記署名シークレットcをいずれの参加者に開示することなく、ディーラ不要の取引所において前記署名シークレットcのシェアciを割り当てられる、請求項７～１１のいずれかに記載の方法。
  13. コンピュータにより実施される方法であって、
    ブロックチェーンネットワークにより維持されるブロックチェーンに記録するために少なくとも１つのチャレンジトランザクションを生成するステップであって、前記少なくとも１つのチャレンジトランザクションは、未知の一時鍵に対応するrチャレンジを含み、鍵シェア参加者のセットのうちの各参加者は、前記未知の一時鍵の一時鍵シェアを保持する、ステップを含み、
    前記少なくとも１つのチャレンジトランザクションは、前記ブロックチェーンネットワークのノードに、前記少なくとも１つのチャレンジトランザクションの前記rチャレンジを示す少なくとも１つの証明トランザクションを受信することに応答して、楕円曲線デジタル署名アルゴリズム（ECDSA）の署名検証関数を、以下に適用させる：
    （ｉ）前記少なくとも１つの証明トランザクションのs部分、及び
    （ｉｉ）以下のうちの１つ：
    （ｉｉａ）前記rチャレンジのr部分であって、その場合には、前記少なくとも１つの証明トランザクションの前記s部分が前記未知の一時鍵に対応しない場合に、署名検証は失敗し、又は、
    （ｉｉｂ）前記少なくとも１つの証明トランザクションのr部分であって、その場合には、前記ノードに、更に、前記少なくとも１つの証明トランザクションの前記r部分が前記rチャレンジを満たすことをチェックさせ、それにより、前記少なくとも１つの証明トランザクションの前記r部分が前記rチャレンジを満たさず、従って前記未知の一時鍵に対応しない場合に、前記チェックが失敗する、方法。
  14. 前記rチャレンジは、複数の公開一時鍵コンポーネントから導出され、各公開一時鍵コンポーネントは、前記鍵シェア参加者のセットのうちのチャレンジサブセットの参加者により、該参加者により保持される前記一時鍵に基づき提供される、請求項１３に記載の方法。
  15. 前記公開一時鍵コンポーネントの各々は、それを提供した、前記チャレンジサブセットπ'の参加者iにより次式のように決定され：
    Figure 2022533753000109
     ここで、kiは、該参加者iにより保持される前記一時鍵シェアであり、bi,π'は、次式のように決定される補間係数であり：
    Figure 2022533753000110
     前記rチャレンジは、次式のように導出される公開一時鍵のデータを含む：
    Figure 2022533753000111
     請求項１４に記載の方法。
  16. 前記一時鍵シェアは、前記一時鍵が前記参加者のうちのいずれにも知られることなく、ディーラ不要の取引所において前記鍵シェア参加者のセットにより決定される、請求項１３～１５のいずれかに記載の方法。
  17. 各参加者は、ディーラに基づく取引所において、ディーラにより前記一時鍵シェアを割り当てられ、前記rチャレンジは、前記ディーラにより生成されるか又は生成させられる、請求項１３～１５のいずれかに記載の方法。
  18. 前記鍵シェア参加者のセットΠの各参加者により保持される前記一時鍵シェアkiは次式により導出され、
    Figure 2022533753000112
     ここで、nは素数整数であり、fは多項式であり、xiは参加者iに割り当てられたx座標である、請求項１３～１７のいずれかに記載の方法。
  19. 前記少なくとも１つの証明トランザクションは、第２トランザクション署名を含み、前記s部分及び前記第２トランザクション署名は、共通秘密鍵又は秘密鍵シェアの共通セットを用いて生成され、異なる一時鍵又は一時鍵シェアの異なるセットに基づき生成される、請求項１３～１８のいずれかに記載の方法。
  20. 前記ノードは、前記少なくとも１つの証明トランザクションの第２トランザクション署名を検証させられ、前記s部分及び前記第２トランザクション署名は、共通の公開鍵に基づき検証されるが、前記第２トランザクション署名は異なるr部分に基づき検証される、請求項１～１２のいずれかに記載の方法。
  21. 前記rチャレンジはr部分ハッシュを含み、前記ノードに、
    署名検証関数を前記少なくとも１つの証明トランザクションの前記r部分及び前記s部分に適用させ、
    前記少なくとも１つの証明トランザクションの前記r部分に基づき、トランザクションr部分ハッシュを計算させ、
    前記トランザクションr部分ハッシュが前記rチャレンジの前記r部分ハッシュに一致するかどうかをチェックさせ、それにより前記rチャレンジが満たされるかどうかをチェックする、
    請求項１～２０のいずれかに記載の方法。
  22. 少なくとも１つの証明トランザクションを生成するコンピュータシステムであって、アクセス可能なコンピュータメモリに保持された署名コンポーネントのセットに基づき、少なくとも１つの証明トランザクションのs部分を生成するために、請求項１～１２のいずれかに記載の方法を実施するようプログラムされた１つ以上のコンピュータを含む、システム。
  23. 少なくとも１つのチャレンジトランザクションを生成するコンピュータシステムであって、アクセス可能なコンピュータメモリに保持された複数の公開一時鍵コンポーネントから、少なくとも１つのチャレンジトランザクションのrチャレンジを導出するために、請求項１４～１５のいずれかに記載の方法を実施するようプログラムされた１つ以上のコンピュータを含む、システム。
  24. 前記方法を実施するために請求項２２又は２３の前記１つ以上のコンピュータをプログラミングするための実行可能コンピュータ命令を含むコンピュータプログラム。
  25. システムであって、
    鍵シェア参加者の参加者装置のセットであって、各参加者装置は前記鍵シェア参加者のうちの１人の一時鍵シェアへのアクセスを有し、前記一時鍵シェアは未知の一時鍵に対応する、参加者装置のセットと、
    ブロックチェーンを維持するよう構成されるブロックチェーンネットワークと、
    を含み、
    前記ブロックチェーンネットワークの少なくとも１つのノードは、rパズルを含む少なくとも１つのチャレンジトランザクションを格納するよう構成されるコンピュータメモリを含み、
    前記少なくとも１つのチャレンジトランザクションは、前記ノードに、前記少なくとも１つのチャレンジトランザクションの前記rパズルを示す少なくとも１つの証明トランザクションを受信することに応答して、楕円曲線デジタル署名アルゴリズム（ECDSA）の署名検証関数を以下に適用させる：
    （ｉ）前記少なくとも１つの証明トランザクションのs部分、
    （ｉｉ）以下のうちの１つ：
    （ｉｉａ）rチャレンジのr部分であって、前記rチャレンジの前記r部分が前記未知の一時鍵に対応しない場合に署名検証は失敗し、
    （ｉｉｂ）前記少なくとも１つの証明トランザクションのr部分であって、その場合に、前記ノードに、更に、前記少なくとも１つの証明トランザクションの前記r部分が前記rチャレンジを満たすことをチェックさせ、前記少なくとも１つの証明トランザクションの前記r部分が前記未知の一時鍵に対応しない場合に、前記署名検証は失敗し、前記少なくとも１つの証明トランザクションの前記r部分が前記rチャレンジを満たさない場合に前記チェックは失敗する、システム。
JP2021569313A 2019-05-24 2020-05-13 知識証明 Pending JP2022533753A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB1907393.1 2019-05-24
GB1907393.1A GB2584154A (en) 2019-05-24 2019-05-24 Knowledge proof
PCT/IB2020/054514 WO2020240319A1 (en) 2019-05-24 2020-05-13 Knowledge proof

Publications (1)

Publication Number Publication Date
JP2022533753A true JP2022533753A (ja) 2022-07-25

Family

ID=67385486

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021569313A Pending JP2022533753A (ja) 2019-05-24 2020-05-13 知識証明

Country Status (6)

Country Link
US (1) US11968304B2 (ja)
EP (2) EP4333358A3 (ja)
JP (1) JP2022533753A (ja)
CN (1) CN113875186A (ja)
GB (1) GB2584154A (ja)
WO (1) WO2020240319A1 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3099017B1 (fr) * 2019-07-16 2021-08-06 Idemia Identity & Security France Procédé de vérification d’une transaction dans une base de données de type chaîne de blocs
GB2606526A (en) * 2021-05-10 2022-11-16 Nchain Licensing Ag Multi-party blockchain address scheme
GB202113092D0 (en) * 2021-09-14 2021-10-27 Nchain Licensing Ag Generating blockchain transactions
GB2614077A (en) * 2021-12-21 2023-06-28 Nchain Licensing Ag Signature-based atomic swap
GB2615081A (en) * 2022-01-26 2023-08-02 Nchain Licensing Ag Elliptic curve arithmetic in script
GB202200993D0 (en) * 2022-01-26 2022-03-09 Nchain Licensing Ag Elliptic curve arithmetic in script
GB2618093A (en) * 2022-04-26 2023-11-01 Nchain Licensing Ag Non-native blockchain signatures
GB2622833A (en) * 2022-09-29 2024-04-03 Nchain Licensing Ag Blockchain based read receipt

Family Cites Families (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3833412B2 (ja) * 1999-04-09 2006-10-11 富士通株式会社 有限体演算における表現データ生成装置および方法
US20040174570A1 (en) 2002-12-02 2004-09-09 Plunkett Richard Thomas Variable size dither matrix usage
JP4034743B2 (ja) * 2004-01-23 2008-01-16 株式会社東芝 多重署名方法、装置、プログラム及びシステム
US7574600B2 (en) * 2004-03-24 2009-08-11 Intel Corporation System and method for combining user and platform authentication in negotiated channel security protocols
US7936869B2 (en) 2005-01-07 2011-05-03 First Data Corporation Verifying digital signature based on shared knowledge
JP5214474B2 (ja) * 2007-02-16 2013-06-19 パナソニック株式会社 分散情報配布装置、保持装置、認証局装置及びシステム
US10231077B2 (en) * 2007-07-03 2019-03-12 Eingot Llc Records access and management
US20110055585A1 (en) 2008-07-25 2011-03-03 Kok-Wah Lee Methods and Systems to Create Big Memorizable Secrets and Their Applications in Information Engineering
WO2010124390A1 (en) * 2009-04-30 2010-11-04 Certicom Corp. System and method for authenticating rfid tags
US8949989B2 (en) 2009-08-17 2015-02-03 Qualcomm Incorporated Auditing a device
US10515567B2 (en) * 2010-06-01 2019-12-24 Ternarylogic Llc Cryptographic machines with N-state lab-transformed switching devices
US20140006781A1 (en) * 2012-06-23 2014-01-02 Pomian & Corella, Llc Encapsulating the complexity of cryptographic authentication in black-boxes
US9887989B2 (en) * 2012-06-23 2018-02-06 Pomian & Corella, Llc Protecting passwords and biometrics against back-end security breaches
US20160085955A1 (en) * 2013-06-10 2016-03-24 Doosra, Inc. Secure Storing and Offline Transferring of Digitally Transferable Assets
FR3027177B1 (fr) * 2014-10-13 2016-11-04 Morpho Procede d'authentification d'un dispositif client aupres d'un serveur a l'aide d'un element secret
GB2551954A (en) * 2016-04-29 2018-01-10 Univ Newcastle End-to-end verifiable E-voting system without tallying authorities
US20190149337A1 (en) * 2016-04-29 2019-05-16 nChain Holdings Limited Implementing logic gate functionality using a blockchain
US10567377B2 (en) * 2016-05-23 2020-02-18 Pemian & Corella, LLC Multifactor privacy-enhanced remote identification using a rich credential
US20170345011A1 (en) 2016-05-26 2017-11-30 Hitfin, Inc. System and method executed on a blockchain network
US11514448B1 (en) * 2016-07-11 2022-11-29 Chicago Mercantile Exchange Inc. Hierarchical consensus protocol framework for implementing electronic transaction processing systems
FR3054905B1 (fr) * 2016-08-04 2019-10-18 Safran Identity & Security Procede de generation de cle et procede de controle d'acces
US10880089B2 (en) * 2017-03-15 2020-12-29 NuID, Inc. Methods and systems for universal storage and access to user-owned credentials for trans-institutional digital authentication
EP3385894B1 (en) 2017-04-03 2021-07-21 PLC Group AG Method for producing a cryptographically signed transaction
GB201705621D0 (en) * 2017-04-07 2017-05-24 Nchain Holdings Ltd Computer-implemented system and method
US11107048B2 (en) 2017-04-17 2021-08-31 International Business Machines Corporation Providing out-of-band verification for blockchain transactions
SG10202112667UA (en) 2017-05-22 2021-12-30 Nchain Holdings Ltd Duplicating smart contracts with termination condition
US10530585B2 (en) * 2017-06-07 2020-01-07 Bar-Ilan University Digital signing by utilizing multiple distinct signing keys, distributed between two parties
US10761877B2 (en) * 2017-07-21 2020-09-01 Intel Corporation Apparatuses, methods, and systems for blockchain transaction acceleration
CN110914852A (zh) 2017-08-05 2020-03-24 普罗克鲁斯科技有限公司 使用交易证明使得区块链安全化的方法和系统
US11381389B2 (en) * 2017-08-15 2022-07-05 Nchain Holdings Ltd. Computer-implemented method of generating a threshold vault
US11671255B2 (en) 2017-08-15 2023-06-06 Nchain Licensing Ag Threshold digital signature method and system
WO2019046021A1 (en) * 2017-08-30 2019-03-07 Raytheon Company AUTHENTICATION OF MESH NETWORK PAIR TO MOBILE PAIR WITH AUTO-ORGANIZATION
GB201720753D0 (en) * 2017-12-13 2018-01-24 Nchain Holdings Ltd Computer-implemented system and method
EP3502941B1 (en) 2017-12-19 2021-01-20 Riddle & Code GmbH Dongles and method for providing a digital signature
GB201800818D0 (en) * 2018-01-18 2018-03-07 Nchain Holdings Ltd Computer-implemented system and method
US10373158B1 (en) * 2018-02-12 2019-08-06 Winklevoss Ip, Llc System, method and program product for modifying a supply of stable value digital asset tokens
US11139955B1 (en) * 2018-02-12 2021-10-05 Winklevoss Ip, Llc Systems, methods, and program products for loaning digital assets and for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
US11522700B1 (en) * 2018-02-12 2022-12-06 Gemini Ip, Llc Systems, methods, and program products for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
US11310060B1 (en) 2018-02-15 2022-04-19 Blockstream Corporation Atomic cross-chain swaps using equivalent secret values
GB201805633D0 (en) * 2018-04-05 2018-05-23 Nchain Holdings Ltd Computer implemented method and system
US20190313246A1 (en) * 2018-04-06 2019-10-10 Iot And M2M Technologies, Llc Device default wifi credentials for simplified and secure configuration of networked transducers
US20190327086A1 (en) * 2018-04-24 2019-10-24 Bartosz Slowik Reciprocal data mirror system and method of data security
SG11202010960YA (en) 2018-05-08 2020-12-30 Visa Int Service Ass Password based threshold token generation
US11184157B1 (en) 2018-06-13 2021-11-23 Amazon Technologies, Inc. Cryptographic key generation and deployment
KR102209178B1 (ko) 2018-07-17 2021-01-29 이윤경 유전체 및 유전체 정보의 보존 및 활용을 위한 방법
US11444779B2 (en) * 2018-08-02 2022-09-13 Paypal, Inc. Techniques for securing application programming interface requests using multi-party digital signatures
US11112132B2 (en) 2018-08-22 2021-09-07 Bao Tran Systems and methods for monitoring water in a building
GB201815816D0 (en) 2018-09-28 2018-11-14 Nchain Holdings Ltd Computer-implemented system and method
US11151558B2 (en) 2018-12-12 2021-10-19 American Express Travel Related Services Company, Inc Zero-knowledge proof payments using blockchain
CN109728910A (zh) 2018-12-27 2019-05-07 北京永恒纪元科技有限公司 一种高效的门限分布式椭圆曲线密钥生成及签名方法和系统
CN110612547A (zh) 2018-12-29 2019-12-24 阿里巴巴集团控股有限公司 一种用于信息保护的系统和方法

Also Published As

Publication number Publication date
EP4333358A3 (en) 2024-05-22
EP3966991B1 (en) 2024-02-28
US11968304B2 (en) 2024-04-23
EP4333358A2 (en) 2024-03-06
US20220263658A1 (en) 2022-08-18
CN113875186A (zh) 2021-12-31
EP3966991A1 (en) 2022-03-16
WO2020240319A1 (en) 2020-12-03
GB201907393D0 (en) 2019-07-10
GB2584154A (en) 2020-11-25

Similar Documents

Publication Publication Date Title
EP3966991B1 (en) Knowledge proof
EP3966998B1 (en) Hash function attacks
EP3977673B1 (en) Blockchain transaction comprising runnable code for hash-based verification
US20220239501A1 (en) Knowledge proof
US20220263664A1 (en) Blockchain transaction comprising runnable code for hash-based verification
US20230316272A1 (en) Divisible tokens
CN114747172A (zh) 加密链接身份
EP3973661B1 (en) Knowledge proof

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230417

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20240430

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240528