Develop with pleasure!

福岡でCloudとかBlockchainとか。

Tor v3 hidden service等128bitより大きなアドレスをサポートするための新しいaddrv2メッセージを定義したBIP-155

Bitcoinのノードは、接続しているリモートピアにgetaddrメッセージを送信すると、リモートピアが知っているノード情報をaddrメッセージで返してくれ、addrメッセージによって、ネットワーク上の分散ピアが発見できる。

このaddrメッセージでは、各ノードのネットワークアドレスを128 bitのIPアドレスとして表現している。ただ、最近Tor v3 hidden serviceなどのアドレスはこの範囲に収まらないアドレスも出てきており、I2Pなどより多様なネットワークの接続をサポートするため、128 bitよりも大きなアドレス表現をサポートできる新しいaddrメッセージとしてaddrv2メッセージがBIP-155として提案されている↓

https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki

以下、BIPの意訳↓

イントロダクション

概要

このドキュメントはP2Pネットワークにおいてより長いアドレスをゴシップするための新しいP2Pメッセージを提案する。これは、新世代のオニオンアドレスやI2Pおよび現在のaddrメッセージの128 bitに収まらないエンドポイントアドレスを持つ可能性がある他のネットワークをサポートするのに必要になる。

動機

TorのV3 Hidden Serviceバージョン0.3.2.9以降のTorの安定版リリースの一部だ。これは以前のHidden Serviceと比較してさまざまな利点を持っているが、その中でも暗号化とプライバシーの利点が大きい。ただ、これらは256 bitのアドレスを持っているため、OnionCatのIPv6アドレスにオニオンアドレスをカプセル化する現在のaddrメッセージには収まらない。

I2Pなどの他のトランスポート層プロトコルは、常により長いアドレスを使用してきた。このBIPの変更により、そのようなアドレスをP2Pネットワークでゴシップすることが可能になり、他のピアがそれらに接続できるようになる。

仕様

addrv2メッセージはpchCommand == "addrv2"のメッセージとして定義され、P2Pメッセージの標準エンコーディングシリアライズされる。フォーマットは現在のaddrメッセージと似ているが、16バイト固定のIPv6アドレスがネットワークIDと可変長アドレスに置き換えられ、timeservicesのフォーマットがVARINT形式に変更されている点が異なる。

これはメッセージに以下の構造のシリアライズされたstd::vectorが含まれること意味する。

タイプ 名前 定義
VARINT(unsigned) time このノードが最後にネットワークに接続していたと思われる時刻。最大64 bit幅のUNIXタイムスタンプ。
VARINT(unsigned) services 64bit幅のサービスビットフィールド
uint8_t networkID ネットワーク識別子。どのネットワークに対応するか示す8 bitの値。
std::vector<uint8_t> addr ネットワークアドレス。解釈はnetwork IDに依存する。
uint16_t port ネットワークポート。ネットワークに無関係の場合は0でなければならない。

1つのメッセージに最大1,000個のアドレスを含めることができる。クライアントはそれ以上のアドレスを含むメッセージは拒否すべきだ。

フィールドaddrは可変長で、最大32バイト(256 bit)。クライアントはそれより長いアドレスは拒否すべきだ。

予約済みのnetwork IDのリストは以下のとおり。

Network ID Enumeration アドレス長(バイト) 定義
0x01 IPV4 4 IPv4アドレス
0x02 IPV6 16 IPv6アドレス
0x03 TORV2 10 Tor v2 hidden serviceアドレス
0x04 TORV3 32 Tor v3 hidden serviceアドレス
0x05 I2P 32 I2Pオーバーレイネットワークアドレス
0x06 CJDNS 16 Cjdnsオーバーレイネットワークアドレス

将来の拡張を可能にするため、クライアントは知らないアドレスタイプを無視しなければならない。クライアントは知らないアドレスフォーマットを保存しゴシップするかもしれない。新しいnetwork IDの番号を追加する場合、新しいBIPドキュメントで予約されなければならない。

クライアントは特定のアドレスに対して、この表に記載されている長さと異なる長さのアドレスがあった場合、そのアドレスに意味がないので拒否すべきだ。

さまざなネットワークで使用されるアドレスエンコーディングについてはAppendix参照。

互換性

ピアが特定のプロトコルバージョン(もしくはそれ以降)である場合のみ、addrv2メッセージを送信する。

//! このバージョン以降、addrv2メッセージを使ったゴシップが可能
static const int GOSSIP_ADDRV2_VERSION = 70016;

旧ピアは新しく導入されたアドレスタイプを持つアドレスを無視し、従来のaddrメッセージを送り続ける。

参照実装

予定されているがまだ記載されていない。

Appendix A: Tor v2 アドレスエンコーディング

新しいメッセージはTORV2用の別のネットワークIDを導入する。

クライアントはアドレスフィールドに80 bitのhidden service IDを入れて、このネットワークIDを持つ、Tor hidden serviceアドレスを送信しなければならない。これは従来のaddrメッセージの表現と同じだが、OnionCatのラッピングの先頭6バイトが除かれている。

クライアントはもしIPV6ネットワークIDでこれらが送られてきた場合、受信時にOnionCat(fd87:d87e:eb43::/48)アドレスを無視する必要がある。

Appendix B: Tor v3アドレスエンコーディング

仕様によると、次世代の.onionアドレスは以下のようにエンコードされる。

onion_address = base32(公開鍵 | チェックサム | バージョン) + ".onion"
 CHECKSUM = H(".onion checksum" | 公開鍵 | バージョン)[:2]

 where:
   - 公開鍵はhidden serviceの32バイトのed25519マスター公開鍵
   - VERSIONは1バイトのバージョンフィールド(デフォルト値は'\x03')
   - ".onion checksum" は固定文字列
   - チェックサムはonion_addressに挿入される前に2バイトにトランケートされる

Tor v3アドレスはアドレスフィールドの32バイトの公開鍵と一緒にTORV3ネットワークIDと共に送信されなければならない。v3アドレスの場合バージョンは常に\x03になるので、これで十分オニオンアドレスを再構築できる。

Appendix C: I2Pアドレスエンコーディング

Torと同様、I2Pのネーミングはbase32エンコードされたアドレスフォーマットが使われる。

I2Pは52文字(256 bit)を使って完全なSHA-256を表現し、その後に.b32.i2pが続く。

I2Pアドレスは、アドレスフィールドとしてデコードされたSHA256ハッシュと一緒に、I2PネットワークIDと共に送信されなければならない。

Appendix D: Cjdnsアドレスエンコーディング

Cjdnsアドレスはfc00::/8範囲内のシンプルなIPv6アドレスで、CJDNSネットワークIDと共に送信されなければならない。