diff options
Diffstat (limited to 'bip-0155.mediawiki')
-rw-r--r-- | bip-0155.mediawiki | 21 |
1 files changed, 10 insertions, 11 deletions
diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki index 1364a3f..71fe3cc 100644 --- a/bip-0155.mediawiki +++ b/bip-0155.mediawiki @@ -46,7 +46,7 @@ The <code>addrv2</code> message is defined as a message where <code>pchCommand = It is serialized in the standard encoding for P2P messages. Its format is similar to the current <code>addr</code> message format <ref>[https://bitcoin.org/en/developer-reference#addr Bitcoin Developer Reference: addr message]</ref>, with the difference that the -fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the time and services format has been changed to VARINT. +fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize]. This means that the message contains a serialized <code>std::vector</code> of the following structure: @@ -55,13 +55,13 @@ This means that the message contains a serialized <code>std::vector</code> of th !Name !Description |- -| <code>VARINT</code> (unsigned) +| <code>uint32_t</code> | <code>time</code> -| Time that this node was last seen as connected to the network. A time in Unix epoch time format, up to 64 bits wide. +| Time that this node was last seen as connected to the network. A time in Unix epoch time format. |- -| <code>VARINT</code> (unsigned) +| <code>CompactSize</code> | <code>services</code> -| Service bits. A 64-wide bit field. +| Service bits. A bit field that is 64 bits wide, encoded in [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize]. |- | <code>uint8_t</code> | <code>networkID</code> @@ -144,15 +144,13 @@ The reference implementation is available at (to be done) ==Acknowledgements== -- Jonas Schnelli: change <code>services</code> field to VARINT, to make the message more compact in the likely case instead of always using 8 bytes. - -- Luke-Jr: change <code>time</code> field to VARINT, for post-2038 compatibility. +- Jonas Schnelli: change <code>services</code> field to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize], to make the message more compact in the likely case instead of always using 8 bytes. - Gregory Maxwell: various suggestions regarding extensibility ==Appendix A: Tor v2 address encoding== -The new message introduces a separate network ID for <code>TORV2</code>. +The new message introduces a separate network ID for <code>TORV2</code>. Clients MUST send Tor hidden service addresses with this network ID, with the 80-bit hidden service ID in the address field. This is the same as the representation in the legacy <code>addr</code> message, minus the 6 byte prefix of the OnionCat wrapping. @@ -166,10 +164,11 @@ onion_address = base32(PUBKEY | CHECKSUM | VERSION) + ".onion" CHECKSUM = H(".onion checksum" | PUBKEY | VERSION)[:2] where: - - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service. - - VERSION is an one byte version field (default value '\x03') + - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service + - VERSION is a one byte version field (default value '\x03') - ".onion checksum" is a constant string - CHECKSUM is truncated to two bytes before inserting it in onion_address + - H() is the SHA3-256 cryptographic hash function </pre> Tor v3 addresses MUST be sent with the <code>TORV3</code> network ID, with the 32-byte PUBKEY part in the address field. As VERSION will always be '\x03' in the case of v3 addresses, this is enough to reconstruct the onion address. |