Protocol documentation

提供: tezos-wiki
Merkle treeから転送)
移動先: 案内検索

このページでは、参照クライアントの動作を説明しています。 Bitcoinプロトコルは、このページではなく、参照クライアントの動作によって指定されます。 特に、このページではネットワークプロトコルの説明が完全に完了していますが、ブロックまたはトランザクションの妥当性のためのすべてのルールをリストアップしようとはしません。

このドキュメントで使用されているタイプ名は、C99規格のものです。

マイニングで使用されるプロトコルについては、getblocktemplateを参照してください。

共通の標準[編集]

ハッシュ[編集]

通常、ビットコイン内でハッシュが計算されると、ハッシュは2回計算されます。ほとんどのSHA-256ハッシュが使用されていますが、RIPEMD-160も使用されていますより短いハッシュが望ましい場合(例えば、ビットコインアドレスを生成する場合)。

文字列 "hello"の二重SHA-256エンコーディングの例

 こんにちは  2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824(sha-256の第1ラウンド)  9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50(sha-256の第2ラウンド)

ビットコインアドレス(RIPEMD-160)の場合、次のようになります。

 こんにちは  2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824(1回目はsha-256)  b6a9c8c230722b7c748331a8b450f05566dc7d0f(ripemd-160付き)

メルクの木[編集]

メルクルツリーはハッシュのバイナリツリーです。ビットコルクのMerkleツリーは、何かのSHA-256ハッシュのSHA-256ハッシュ「 'SHA-256を使用します。

ツリーのルート(ツリーのルート以外)を作成するときに奇数の要素がある場合は、最後のダブルハッシュを複製して、その行に偶数のハッシュがあることを確認します。

最初に、ブロック内のトランザクションのバイトストリームの順序付けられたダブルSHA-256ハッシュを使用して、ツリーの最下行を形成します。

その上の行はハッシュ数の半分で構成されています。各エントリは、ツリーの下の対応する2つのハッシュの64バイト連結の倍長SHA-256です。

このプロシージャは、単一のダブルハッシュからなる行に達するまで再帰的に繰り返されます。これは、木の "Merkle root"です。

たとえば、3つのトランザクション 'a' '、' 'b' '、' 'c' 'を持つブロックを想像してみてください。 Merkleツリーは次のとおりです。

 d1 = dhash(a)  d2 = dhash(b)  d3 = dhash(c)  d4 = dhash(c)#a、b、cは3です。これは奇数なので、cを2度取る    d5 = dhash(d1 concat d2)  d6 = dhash(d3 concat d4)    d7 = dhash(d5 concat d6)

どこで    dhash(a)= sha256(sha256(a))

d7 はこのブロック内の3つのトランザクションのMerkleルートです。

注:ブロックエクスプローラに表示されるMerkle Treeのハッシュはリトルエンディアン表記です。いくつかの実装と[1]の場合、バイトはハッシュされる前に元に戻す必要があります。

署名[編集]

Bitcoinは[2] [3][4] / Elliptic_Curve_DSA ECDSA])を使用してトランザクションに署名します。

ECDSAには、http://www.secg.org/sec2-v2.pdfのsecp256k1カーブが使用されています。

公開鍵(スクリプト内)は、04 <x> <y>として与えられます。ここで、 'x'と 'y'は、曲線上の点の座標を表す32バイトのビッグエンディアンの整数です。 <sign> <x> "y"が偶数の場合は<sign>が0x02、 "y"が奇数の場合は0x03です。

Signatureは、['r' 'と' 's' ']コンポーネントを1バイトストリームにパックするためにDER encodingを使用します(これはデフォルトでOpenSSLが生成します)。

取引の確認[編集]

トランザクションはBitcoinsの所有権を新しいアドレスに再割り当てする暗号署名されたレコードです。取引には、他の以前の取引からの資金を参照するレコードと、転送されたBitcoinsの新しい所有者を決定するレコードと、将来の取引の入力としてそれらの資金が参照されるレコードがあります。侮辱する。

それぞれの「入力」には、前回の取引から資金を解錠する暗号デジタル署名が必要です。適切な[秘密鍵]を所持している人のみが満足のいく署名を作成することができます。これにより、実際に資金が所有者によってのみ費やされることが保証されます。

それぞれの「出力」は、どのBitcoinアドレス(またはScriptを参照)が資金の受領者であるかを決定します。

トランザクションでは、すべての入力の合計がすべての出力の合計以上でなければなりません。入力が出力を超えた場合、差額は取引手数料とみなされ、最初に取引をブロックチェーンに含める者によって償還されます。

coinbase transactionと呼ばれる特殊なトランザクションは、入力がありません。これはminersによって作成され、ブロックごとに1つのコインベーストランザクションがあります。各ブロックには新たに作成されたBitcoins(最初の210,000ブロックの場合は50BTC)の報酬が付いているため、ブロックの最初のトランザクションは例外で、コインを受信者(鉱夫)に許可するトランザクションです。新しく作成されたBitcoinsに加えて、コインベース取引は、同じブロックに含まれる他の取引内で支払われた取引手数料の受領者を割り当てるためにも使用されます。コインベース取引は、他の取引と同様に、報酬全体を単一のBitcoinアドレスに割り当てることも、複数のアドレスに分けて分割することもできます。コインベース取引には、ブロック報酬と、同じブロック内の他の取引から収集されたすべての取引手数料の合計額を合計した出力が常に含まれます。

ブロック0のcoinbase transactionは使えません。これは、一部のノードが支出を受け入れ、他のノードが支出を受けた場合、ブロックチェーンフォークの潜在的可能性を開くリファレンスクライアントの実装が奇抜であるためです。.msg1288552#msg1288552ブロック0ネットワークフォーク </ ref>。

ほとんどのBitcoin出力は、新しく転送されたコインを単一のECDSA秘密鍵で拘束します。入力と出力で保存された実際のレコードは必ずしもキーではなく、 "スクリプト"です。 Bitcoinは、2つのECDSA署名または2つの3署名方式が必要な出力など、より複雑な操作が可能な出力の条件が満たされているかどうかを解釈するスクリプトシステムを使用します。単一のBitcoinアドレスを参照する出力は「典型的な」出力です。出力には実際には単一のECDSA署名を必要とするスクリプトの形でこの情報が含まれています([[OP_CHECKSIG]参照)。出力スクリプトは、後で資金のロックを解除するために何を提供する必要があるのか​​を指定し、将来、トランザクションを別の入力に費やす時間がある場合、その入力は元の出力で定義された要件スクリプト。

アドレス[編集]

ビットコインアドレスは、実際にはECDSA公開鍵のハッシュであり、このように計算されます。

 バージョン= 1バイトの0(ゼロ)。テストネットワーク上では、これは1バイトの111  Key hash = RIPEMD-160と連結されたバージョン(SHA-256(公開鍵))  チェックサム=最初の4バイトのSHA-256(SHA-256(キーハッシュ))  Bitcoin Address = Base58Encode(Checksumと連結されたキーハッシュ)

使用されるBase58エンコーディングは自家製であり、いくつかの違いがあります。特に、先行ゼロは、変換が行われるときには単一のゼロとして保持されます。

一般的な構造[編集]

ほぼすべての整数はリトルエンディアンでエンコードされます。 IPまたはポート番号のみエンコードされたビッグエンディアンです。

メッセージ構造[編集]

フィールドサイズ 説明 データ・タイプ コメント
4 魔法 uint32_t メッセージ発信元ネットワークを示すマジック値。ストリーム状態が不明なときに次のメッセージを探すために使用される
12 コマンド char [12] パケット内容を識別するASCII文字列、NULL埋め込み(NULLでない埋め込みの結果パケットが拒否される)
4 長さ uint32_t ペイロードの長さ(バイト数)
4 チェックサム uint32_t sha256の最初の4バイト(sha256(ペイロード))
ペイロード uchar [] 実際のデータ


既知の魔法の値:

ネットワーク 魔法の価値 電線で
メイン 0xD9B4BEF9 F9 BE B4 D9
テストネット 0xDAB5BFFA FA BF B5 DA
testnet3 0x0709110B 0B 11 09 07
ナマコイン 0xFEB4BEF9 F9 BE B4 FE

可変長整数[編集]

空間を節約するために、表現された値に応じて整数を符号化することができます。 可変長整数は、常に長さが変化する可能性があるデータ型の配列/ベクトルに先行します。 長い数字はリトルエンディアンでエンコードされます。

価値 保管長 フォーマット
<0xFD 1 uint8_t
<= 0xFFFF 3 0xFDの後に長さがuint16_t
<= 0xFFFF FFFF 5 0xFEの後に長さがuint32_t

Satoshiクライアントコード(BitcoinQT)を読んでいる場合は、このエンコーディングを「CompactSize」と呼びます。現代のBitcoinQTには、CVarIntクラスもあります。このクラスは、ローカル記憶域の目的でさらにコンパクトな整数を実装しています(ここで説明する「CompactSize」と互換性がありません)。 CVarIntはプロトコルの一部ではありません。

可変長文字列[編集]

可変長文字列は可変長整数の後に文字列自体を格納して格納することができます。

フィールドサイズ 説明 データ・タイプ コメント
長さ var_int 文字列の長さ
文字列 char [] 文字列自体(空の場合もあります)

ネットワークアドレス[編集]

どこかにネットワークアドレスが必要な場合は、この構造が使用されます。ネットワークアドレスには、バージョンメッセージのタイムスタンプが前置されていません。

フィールドサイズ 説明 データ・タイプ コメント
4 時間 uint32 時間(バージョン> = 31402)。 'バージョンメッセージには存在しません。'
8 サービス uint64_t versionに記載されているサービスと同じサービス
16 IPv6 / 4 char [16] IPv6アドレス。ネットワークバイトオーダー。元のクライアントはIPv4のみをサポートし、最後の4バイトを読み込んでIPv4アドレスを取得しました。しかし、IPv4アドレスは16バイトIPv4マップされたIPv6アドレスとしてメッセージに書き込まれます。

(12バイトの'00 00 00 00 00 00 00 00 00 00 FF FF の後にIPv4アドレスの4バイトが続きます)。

2 ポート uint16_t ポート番号、ネットワークバイトオーダー

ネットワークアドレス構造のHexdumpの例

0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........

ネットワークアドレス:
 01 00 00 00 00 00 00 00 - 1(NODE_NETWORK:バージョンコマンドの下にリストされているサービスを参照)
 00:00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6::: ffff:a00:1またはIPv4:10.0.0.1
 20 8D - ポート8333
</ pre>

在庫ベクトル[編集]

在庫ベクトルは、所有しているオブジェクトまたは要求されているデータについて他のノードに通知するために使用されます。

在庫ベクトルは、次のデータ形式で構成されます。

フィールドサイズ 説明 データ・タイプ コメント
4 タイプ uint32_t このインベントリにリンクされているオブジェクトの種類を識別します。
32 ハッシュ char [32] オブジェクトのハッシュ


オブジェクトタイプは現在、次のいずれかの可能性として定義されています。

価値 名前 説明
0 エラー この番号を持つデータはすべて無視することができます
1 MSG_TX ハッシュはトランザクションに関連しています
2 MSG_BLOCK ハッシュはデータブロックに関連しています
3 MSG_FILTERED_BLOCK ブロックヘッダのハッシュ。 MSG_BLOCKと同じです。 getdataメッセージでのみ使用されます。応答がブロックメッセージではなくメルクブロックメッセージでなければならないことを示します。これは、ブルームフィルタが設定されている場合にのみ機能します。
4 MSG_CMPCT_BLOCK ブロックヘッダのハッシュ。 MSG_BLOCKと同じです。 getdataメッセージでのみ使用されます。返信がcmpctblockメッセージであることを示します。詳細はBIP 152を参照してください。

その他のデータ型の値は、将来の実装のために予約されていると見なされます。

ブロックヘッダ[編集]

ブロックヘッダーは、getheadersメッセージに応答してヘッダーパケットで送信されます。

フィールドサイズ 説明 データ・タイプ コメント
4 バージョン int32_t バージョン情報をブロックする(注:これは署名されている)
32 prev_block char [32] この特定のブロックが参照する前のブロックのハッシュ値
32 merkle_root char [32] このブロックに関連するすべてのトランザクションのハッシュであるMerkleツリーコレクションへの参照
4 タイムスタンプ uint32_t このブロックが作成されたときのタイムスタンプの記録(2106年にオーバーフローします<ref> https://en.wikipedia.org/wiki/Unix_time#Notable_events_in_Unix_time </ ref>)
4 ビット uint32_t このブロックに使用されている計算された難易度ターゲット
4 nonce uint32_t The nonce used to generate this block… to allow variations of the header and compute different hashes
1 txn_count var_int トランザクションエントリの数。この値は常に0です。

cf. ブロックハッシュアルゴリズム

差分エンコーディング[編集]

以下のCompactSizeのいくつかの使用法は、「差別的にコード化された」ものです。これらのために、未処理の索引を使用する代わりに、現行の索引と前の索引の差から1を差し引いた数が符号化されます。たとえば、0の最初のインデックスは0の実インデックスを意味し、0の2番目のインデックスはその後1の実インデックスを参照します。

PrefilledTransaction[編集]

PrefilledTransaction構造体は、いくつかのトランザクションのリストを明示的に提供するためにHeaderAndShortIDsで使用されます。

フィールド名 タイプ サイズ エンコーディング 目的
インデックス CompactSize 1,3バイト コンパクトサイズ。リスト内の最後のPrefilledTransactionから差別的にコード化されています。このトランザクションがあるブロックのインデックス
トランザクション 変数 tx messages インデックスインデックスにあるブロック内のトランザクション。

詳細については、BIP 152を参照してください。

HeaderAndShortIDs[編集]

HeaderAndShortIDs構造体は、ブロックヘッダー、既に使用可能なトランザクションの照合に使用される短いトランザクションID、およびピアが失われていると予想される少数の選択されたトランザクションを中継するために使用されます。

フィールド名 タイプ サイズ エンコーディング 目的
ヘッダー ブロックヘッダー 80バイト 「ブロック」メッセージによって使用される符号化によって定義されるブロックの最初の80バイト 提供されているブロックのヘッダー
ノンス uint64_t 8バイト リトルエンディアン 短いトランザクションIDの計算に使用するノンス
shortids_length CompactSize 1または3バイト 配列の長さを他の場所でエンコードするのに使用されるように ショートカット内のショート・トランザクションIDの数(ブロックtx count - prefilledtxn_length)
短期 6バイト整数のリスト 6 * shortids_lengthバイト リトルエンディアン プレフィルドで明示的に提供されなかったトランザクションから計算された短いトランザクションID
prefilledtxn_length CompactSize 1または3バイト 配列の長さを他の場所でエンコードするのに使用されるように prefilledtxn(すなわちブロックtxカウント - shortids_length)での事前充填されたトランザクションの数は、
予め充填された PrefilledTransactionsのリスト 可変サイズ* prefilledtxn_length PrefilledTransaction定義で定義されているように、上記の コインベース取引を提供するために使用されています。

詳細については、BIP 152を参照してください。

BlockTransactionsRequest[編集]

BlockTransactionsRequest構造体は、要求されているブロック内のトランザクションインデックスをリストするために使用されます。

フィールド名 タイプ サイズ エンコーディング 目的
ブロックハッシュ バイナリブロブ 32バイト ブロックヘッダーのdouble-SHA256からの出力。他の場所で使用されています。要求されたトランザクションが入っているブロックのブロックハッシュ
indexes_length CompactSize 1または3バイト 配列の長さを他の場所でエンコードするのに使用されるように 要求されたトランザクションの数
インデックス CompactSizesの一覧 1または3バイト* indexes_length 差異符号化された ブロック内で要求されているトランザクションのインデックス

詳細については、BIP 152を参照してください。

BlockTransactions[編集]

BlockTransactions構造体を使用して、ブロック内のトランザクションの一部を要求どおりに提供します。

フィールド名 タイプ サイズ エンコーディング 目的
ブロックハッシュ バイナリブロブ 32バイト ブロックヘッダーのdouble-SHA256からの出力。他の場所で使用されています。提供されているトランザクションが入っているブロックのブロックハッシュ
transactions_length CompactSize 1または3バイト 配列の長さを他の場所でエンコードするのに使用されるように 提供されたトランザクションの数
取引 トランザクション一覧 変数 tx messages 提供された取引

詳細については、BIP 152を参照してください。

短いトランザクションID[編集]

短いトランザクションIDは、完全な256ビットハッシュを送信せずにトランザクションを表すために使用されます。それらは次のように計算されます。

#single-SHA256はノンスを付加したブロックヘッダをハッシュします(リトルエンディアンで) #入力がトランザクションIDで、キー(k0 / k1)が上記のハッシュから最初の2つのリトルエンディアンの64ビット整数にそれぞれ設定されているSipHash-2-4を実行しています。 #SipHashの出力から2つの最上位バイトを落として6バイトにする。

詳細については、BIP 152を参照してください。

メッセージタイプ[編集]

バージョン[編集]

ノードが発信接続を作成すると、すぐにアドバタイズします。リモートノードはそのバージョンで応答します。両方のピアがバージョンを交換するまで、それ以上の通信はできません。


getblocks[編集]

ブロックロケータオブジェクト内の最後の既知のハッシュの直後から開始するブロックのリストを含む「 'inv' '」パケットをhash_stopまたは500ブロックのうちのどちらか早い方から返す。

ロケータハッシュは、メッセージに表示される順序でノードによって処理されます。ノードのメインチェーンにブロックハッシュが見つかった場合、その子のリストは "'inv' 'メッセージで返され、残りのロケータは要求された制限に達しても無視されます。

次のブロックハッシュを受け取るには、新しいブロックロケータオブジェクトでgetblockを再度発行する必要があります。ブロックロケータオブジェクトに無効なブランチのハッシュが含まれていると、一部のクライアントが無効なブロックを提供することがあります。 ペイロード:

ブロックロケータハッシュを作成するには、起点ブロックに戻るまでハッシュを押し続けます。 10個のハッシュを押した後、ステップはループごとに2倍になります。


知られているハッシュ数を少なくして、最低でも1つのハッシュまで送信することができます。しかし、ブロックロケータオブジェクトの目的は、呼び出し元のメインチェーン内の間違った分岐を検出することです。ピアが主チェーンから離れていることを検出すると、最後に知られているブロックよりも前のブロックハッシュが送信されます。だから、あなたが最後に知られているハッシュを送るだけで、それがメインチェーンから外れているならば、ピアはブロック#1でやり直します。

ゲットヘッダー[編集]

ブロックロケータオブジェクト内の最後の既知のハッシュの直後から始まるブロックのヘッダを含む「ヘッダ」パケットを、hash_stopまたは2000ブロックまでのいずれか早い方の時刻に返す。次のブロックヘッダーを受け取るには、新しいブロックロケーターオブジェクトを使用してgetheadersを再度発行する必要があります。 getheaders コマンドは、シンクライアントがトランザクションの内容が無関係であるブロックチェーンをすぐにダウンロードするために使用されます(これは私たちのものではないためです)。ブロックロケータオブジェクトに無効なブランチのハッシュが含まれていると、無効なブロックのヘッダーを提供するクライアントがあることに注意してください。


TxInは、次のフィールドで構成されています。

フィールドサイズ 説明 データ・タイプ コメント
36 前の出力 アウト点 OutPoint構造としての以前の出力トランザクション参照
1+ スクリプトの長さ var_int 署名スクリプトの長さ
署名スクリプト uchar [] トランザクション認証を確認するための計算スクリプト
4 [5] uint32_t 送信者によって定義されたトランザクションバージョン。ブロックに含める前に情報が更新されたときのトランザクションの「置き換え」を意図しています。

OutPoint構造体は、次のフィールドで構成されます。

フィールドサイズ 説明 データ・タイプ コメント
32 ハッシュ char [32] 参照されるトランザクションのハッシュ。
4 インデックス uint32_t トランザクション内の特定の出力のインデックス。最初の出力は0です。

スクリプト構造は、トランザクションの値に関連する一連の情報および操作で構成されています。

(今後拡張される構造...詳しくは、script.hとscript.cpp、Scriptを参照してください)

TxOut構造体は、次のフィールドで構成されています。

フィールドサイズ 説明 データ・タイプ コメント
8 int64_t 取引価値
1+ pk_scriptの長さ var_int pk_scriptの長さ
pk_script uchar [] 通常、この出力を要求する条件を設定するBitcoinスクリプトとして公開鍵を含みます。

TxWitness構造体は、証人データコンポーネントの var_intカウントと、それに続く(各証人データコンポーネントごとに)コンポーネントの[Protocol_documentation#Variable_length_integer | var_int]長さと生のコンポーネントデータ自体。


ブロック[編集]

'ブロック' メッセージは、ブロックハッシュからトランザクション情報を要求するgetdataメッセージに応答して送信されます。

フィールドサイズ 説明 データ・タイプ コメント
4 バージョン int32_t バージョン情報をブロックする(注:これは署名されている)
32 prev_block char [32] この特定のブロックが参照する前のブロックのハッシュ値
32 merkle_root char [32] このブロックに関連するすべてのトランザクションのハッシュであるMerkleツリーコレクションへの参照
4 タイムスタンプ uint32_t このブロックが作成されたときのUnixタイムスタンプ記録(現在は2106年以前の日付に限定されています)
4 ビット uint32_t 計算された難易度ターゲットがこのブロックに使用されています
4 ノンス uint32_t このブロックを生成するために使用されたノンス...ヘッダーの変形を許し、異なるハッシュを計算する
txn_count var_int トランザクションエントリの数
txns tx [] "tx"コマンドの形式でトランザクションをブロックする

この構造体の最初の6つのフィールド(version、prev_block、merkle_root、timestamp、bits、nonce、および標準SHA256パディング)から、各ブロックを識別するSHA256ハッシュが計算され(0ビットの実行が必要)すべてのバイトチャンク)と完全なブロックからの ではないハッシュを計算するには、SHA256アルゴリズムで2つのチャンクのみを処理する必要があります。 nonce フィールドは2番目のチャンクにあるので、最初のチャンクはマイニング中は一定のままなので、2番目のチャンクだけを処理する必要があります。ただし、Bitcoinハッシュはハッシュのハッシュなので、各マイニングの繰り返しに2つのSHA256ラウンドが必要です。 詳細と例は、ハッシュアルゴリズムのブロックを参照してください。

ヘッダー[編集]

headers パケットは、「getheaders」パケットに応答してブロックヘッダを返します。

ペイロード:

フィールドサイズ 説明 データ・タイプ コメント
カウント var_int ブロックヘッダの数
81x? ヘッダー block_header [] ブロックヘッダー

このパケットのブロックヘッダーには、鉱夫によってハッシュされるブロックヘッダーとは対照的に、トランザクションカウント(var_int、ヘッダーあたり81バイトを超えることがあります)が含まれています。

getaddr[編集]

getaddrメッセージは、既知のアクティブなピアに関する情報を要求する要求をノードに送信し、ネットワーク内の潜在的なノードを見つけるのを助ける。このメッセージの受信に対する応答は、既知のアクティブなピアのデータベースから、1つまたは複数のピアを有する1つまたは複数のアドレスメッセージを送信することである。典型的な仮定は、ノードが過去3時間以内にメッセージを送信している場合、ノードがアクティブである可能性が高いということです。

このメッセージでは、追加のデータは送信されません。

mempool[編集]

mempoolメッセージは、確認済みのトランザクションについての情報を要求する要求をノードに送信しますが、まだ確認されていません。このメッセージの受信に対する応答は、ノードのmempool内のすべてのトランザクションのトランザクションハッシュを含むinvメッセージです。

ping[編集]

「ping」メッセージは、主にTCP / IP接続が有効であることを確認するために送信されます。送信のエラーは閉じた接続であると推定され、アドレスは現在のピアとして削除されます。


Tデータフィールドは、サイズが520バイト(一致する可能性のあるオブジェクトの最大サイズ)以下でなければなりません。

指定されたデータ要素がBloomフィルタに追加されます。フィルタは、 filterload </ code>を使用して以前に提供されている必要があります。このコマンドは、ネットワークへの接続が開いている間に新しい鍵またはスクリプトがクライアントWalletに追加された場合、再計算してすべてのピアにまったく新しいフィルタを送信する必要はありません(ただし、通常そうすることをお勧めします)。匿名性を維持する)。

<code> filterclear </ code>コマンドには引数が全くありません。

フィルタが設定された後、ノードは不一致トランザクションの通知を止めるだけでなく、フィルタリングされたブロックを提供することもできます。フィルタリングされたブロックは、<code> merkblock </ code>メッセージで定義され、次のように定義されます。

フィールドサイズ 説明 データ・タイプ コメント
4 バージョン int32_t このブロックを作成するソフトウェアのバージョンに基づいてバージョン情報をブロックします(注:これは署名されています)
32 prev_block char [32] この特定のブロックが参照する前のブロックのハッシュ値
32 merkle_root char [32] このブロックに関連するすべてのトランザクションのハッシュであるMerkleツリーコレクションへの参照
4 タイムスタンプ uint32_t このブロックが作成されたときのタイムスタンプ記録(2106に限定)!
4 ビット uint32_t このブロックに使用されている計算された難易度ターゲット
4 ノンス uint32_t このブロックを生成するために使用されたノンス...ヘッダーの変形を許し、異なるハッシュを計算する
4 total_transactions uint32_t ブロック内のトランザクション数(不一致を含む)
ハッシュ uint256 [] 深さ優先のハッシュ(標準のバント・サイズ・プレフィックスを含む)
フラグ バイト[] バイト単位で8ビットごとにパックされたフラグビット、最下位ビットから最初に(標準バージンサイズプレフィックスを含む)

アラート[編集]

2016年3月にbitcoinコアから警告メッセージのサポートが削除されました。もっと読む[6]


ノード間で[Alert system | alert ]]が送信され、ネットワーク全体に一般的な通知メッセージが送信されます。シグネチャがBitcoinソフトウェアのコア開発グループから来たものとしてアラートを確認できる場合、メッセージはエンドユーザー向けに表示されるように提案されます。トランザクションを実行しようとする試み、特にクライアントを介した自動化されたトランザクションは停止することが推奨される。メッセージ文字列内のテキストは、ログファイルと任意のユーザーインターフェイスに中継する必要があります。

アラート形式:

フィールドサイズ 説明 データ・タイプ コメント
ペイロード uchar [] シリアライズされたアラートペイロード
署名 uchar [] メッセージのECDSA署名

Satoshiのクライアントの開発者は、この公開鍵を使用してアラートに署名します。  04fc9702847840aa195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284  (ハッシュ)1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

ペイロードはuchar []にシリアル化され、互換性のないアラート形式を使用しているバージョンが引き続きアラートを相互に中継できることが保証されています。現在のアラートペイロード形式は次のとおりです。

フィールドサイズ 説明 データ・タイプ コメント
4 バージョン int32_t アラート形式のバージョン
8 RelayUntil int64_t ノードがこのアラートの中継を停止するタイムスタンプ
8 有効期限 int64_t このアラートがそれ以上有効ではなく、無視されるべきタイムスタンプ
4 ID int32_t このアラートの一意のID番号
4 キャンセル int32_t この番号以下のID番号を持つすべてのアラートはキャンセルする必要があります:削除され、今後受け入れられません
setCancel set <int32_t> このセットに含まれるすべてのアラートIDは、上記のようにキャンセルする必要があります
4 MinVer int32_t このアラートは、このバージョン以上のバージョンにのみ適用されます。他のバージョンではまだそれを中継する必要があります。
4 MaxVer int32_t このアラートは、このバージョン以下のバージョンにのみ適用されます。他のバージョンではまだそれを中継する必要があります。
setSubVer セット<文字列> このセットに要素が含まれている場合、このセットに含まれるサブベクトルを持つノードのみがアラートの影響を受けます。他のバージョンではまだそれを中継する必要があります。
4 優先度 int32_t 他のアラートと比較した優先順位
コメント 文字列 表示されていないアラートに関するコメント
ステータスバー 文字列 ユーザーに表示される警告メッセージ
予約済み 文字列 予約済み

注:上記の表の 'set' 'type' '>' は、可変長整数の後ろに、与えられた型のフィールドの数が続きます(int32_tまたは可変長文字列


feefilter[編集]

ペイロードは常に8バイト長で、 'feerate' の64ビット整数値(LSB /リトルエンディアン)をエンコードします。 この値は最小限の料金を表し、1000バイトあたりのサトシで表されます。

「feefilter」メッセージを受信すると、ノードは、キロバイトあたりsatoshisとして解釈されるフェイファーターメッセージで提供されたフェートよりも下にあるトランザクションについて、トランザクションinvをフィルタすることを許可されるが、必須ではない。

料金フィルタはトランザクションのブルームフィルタと相補的です。したがって、SPVクライアントがブルームフィルタをロードしてフェイフッターメッセージを送信する場合、トランザクションは両方のフィルタを通過した場合にのみ中継されます。

mempoolメッセージから生成されたInvは、それが存在すれば料金フィルタの対象となります。

フィーチャディスカバリは、プロトコルバージョン> = 70013をチェックすることで有効になります

詳細については、BIP 133を参照してください。

sendcmpct[編集]

#sendcmpctメッセージは、1バイト整数とそれに続く8バイト整数を含むメッセージとして定義され、pchCommand == "sendcmpct"となります。 #最初の整数はブール値として解釈されなければなりません(そして、値は1か0のいずれかでなければなりません) #2番目の整数は、リトルエンディアンのバージョン番号として解釈されます。 sendcmpctメッセージを送信するノードは、現在この値を1に設定しなければならない(MUST)。 #第1および第2の整数が1にセットされた "sendcmpct"メッセージを受信すると、ノードはcmpctblockメッセージを送信して新しいブロックを通知すべきである(SHOULD)。 #最初の整数が0に設定された "sendcmpct"メッセージを受信すると、ノードはcmpctblockメッセージを送信して新しいブロックを通知してはならない(SHOULD NOT)が、BIP130で定義されているようにinvsまたはヘッダを送信して新しいブロックを通知するべきである。 #2以外の値に設定された第2の整数を持つ "sendcmpct"メッセージを受信すると、ノードは、ピアがメッセージを受信して​​いないかのようにピアを扱わなければならない(ピアが予期しないエンコーディングを #cmpctblock、および/またはその他のメッセージ)。これにより、将来のバージョンのバージョンハンドシェイクの一部として異なるバージョンのsendcmpctメッセージを重複して送信することが可能になります。 #ノードは、sendcmpctメッセージを送信する前に、> 70014のプロトコルバージョンをチェックすべきである(SHOULD)。 #ノードは、そのピアからsendcmpctメッセージを受信する前に、ピアにMSG_CMPCT_BLOCKオブジェクトの要求を送信してはならない(MUST NOT)。

このメッセージはプロトコルバージョン> = 70014でのみサポートされています

詳細については、BIP 152を参照してください。

cmpctblock[編集]

#cmpctblockメッセージは、シリアル化された HeaderAndShortIDsメッセージとpchCommand == "cmpctblock"メッセージを含むメッセージとして定義されています。 #sendcmpctメッセージを送信した後、cmpctblockメッセージを受信すると、ノードは、利用可能な未確認のトランザクション(すなわちmempool内)ごとに short transaction IDを計算し、 cmpctblockメッセージ #利用可能なトランザクションを見つけた後、フルブロックを再構築するために利用可能なすべてのトランザクションを持たないノードは、getblocktxnメッセージを使用して不足しているトランザクションを要求するべきです(SHOULD)。 #ブロック内のすべてのトランザクションを要求するgetblocktxnメッセージに応答できない限り、ノードはcmpctblockメッセージを送信してはならない(MUST NOT)。 #ノードはブロック内の各トランザクションに正しくヘッダがコミットされていることを検証せずにcmpctblockメッセージを送信してはならない(MUST NOT)。また、有効な実証証明書とともに既存のチェーンの上に適切に構築する。ノードは、ブロック内の各トランザクションが既存のUTXOセットエントリを有効に使用していることを検証する前に、cmpctblockを送信してもよい(MAY)。

このメッセージはプロトコルバージョン> = 70014でのみサポートされています

詳細については、BIP 152を参照してください。

getblocktxn[編集]

#getblocktxnメッセージは、シリアル化された BlockTransactionsRequestメッセージとpchCommand == "getblocktxn"メッセージを含むメッセージとして定義されています。 #適切な形式のgetblocktxnmessageを受信すると、このメッセージの送信者に最近提供されたノードは、このメッセージで識別されたブロックハッシュのcmpctblockを適切な blocktxnメッセージで応答しなければならない。このようなblocktxnメッセージは、要求された順序で、getblocktxnインデックスリストで指定されたインデックスの適切なブロックに存在する各トランザクションだけを正確に含む必要があります。

このメッセージはプロトコルバージョン> = 70014でのみサポートされています

詳細については、BIP 152を参照してください。

blocktxn[編集]

#blocktxnメッセージは、シリアル化された BlockTransactionsメッセージとpchCommand == "blocktxn"を含むメッセージとして定義されています。 #適切にフォーマットされた要求されたblocktxnメッセージを受信すると、ノードは以下の方法で完全なブロックを再構築しようとするべきである(SHOULD)。 #プリフィットされたトランザクションを元の cmpctblockから取り出し、マークされた位置に配置します。 #オリジナルの cmpctblockからの短いトランザクションIDごとに、blocktxnメッセージまたは他のソースから対応するトランザクションを見つけ、ブロックの最初の利用可能な位置に配置します。 #ブロックが再構築されると、短いトランザクションIDが時折衝突することが予想され、そのような衝突が発生した場合にはそのノードにペナルティを課されてはならないことを覚えておいて、正常に処理されるものとします。

このメッセージはプロトコルバージョン> = 70014でのみサポートされています

詳細については、BIP 152を参照してください。

スクリプティング[編集]

scriptを参照してください。

関連項目[編集]

WiresharkのBitcoin解読器:https://github.com/lbotsch/wireshark-bitcoin https://github.com/op-sig/bitcoin-wireshark-dissector

参考文献[編集]

<リファレンス/>

zh-cn:协议说明 Category:技術 Category:開発者