Protocol - getaddr - Network_address -> unknown format?

[georgem]

Hey guys,

I'm working on a multiwallet, so I spend a lot of time talking with nodes.

When I do a getaddr-command and receive all the addr-data,
though I can easily recognize the IPv4 and IPv6 format,
sometimes I keep seeing a format that I can't identify.

IPv4 addresses and IPv6 addresses are clearly defined here:
https://en.bitcoin.it/wiki/Protocol_documentation#Network_address

Code:

IPv6: 2001000041379e760c5b0558bcb8e3dd

Code:

IPv4: 00000000000000000000ffffb3b824c1

But in some rare cases I keep seeing this undocumented format:

Code:

Example1: 000000000000000070d1c52519793031
Example2: 00000000000000003d5a7e065c3ebc67

Anyone know what this represents?
Is this some kind of compact representation of IPv6?
Or does this have something to do with TOR/Onion?

Documentation has no info about this.

[Coding Enthusiast]

I am very interested in knowing more about this, since I have been learning more about this topic myself.

I have spent a couple of hours on this, in the morning and the only thing I could come up with is that maybe the node is reporting false information, the protocol is forgiving about these things!

You may want to read the RFC3493 on the standard for reporting IPV6 addresses.

The examples are these IP addresses:
::70d1:c525:1979:3031
::3d5a:7e06:5c3e:bc67
And the only time they start with 0 is the deprecated IPv4- compatible IPv6 address but again this format doesn't math that either!
   |                80 bits               | 16 |      32 bits        |
   +--------------------------------------+--------------------------+
   |0000..............................0000|0000|    IPv4 address     |
   +--------------------------------------+----+---------------------+

Is this some kind of compact representation of IPv6?

Compact representation of IPV6 removes the 0s and replaces them with ::
2001:0000:4137:9e76:0c5b:0558:bcb8:e3dd -> 2001:0:4137:9e76:c5b:558:bcb8:e3dd
0000:0000:0000:0000:0000:ffff:b3b8:24c1 -> ::ffff:b3b8:24c1

also some other methods of Encoding

[georgem]

maybe the node is reporting false information, the protocol is forgiving about these things!

I don't think that it is false information, I get the same format from many different nodes (even from different coins), and it always has that 8 byte structure.
And it's also always "unique" ... in the sense that it clearly serves as an identifier like IPv4 and IPv6.

Also, I don't see any other exotic formats.

Just these three: IPv4, IPv6 and this unknown 8-byte format, that I want to figure out what it stands for.

You may want to read the RFC3493 on the standard for reporting IPV6 addresses.

Compact representation of IPV6 removes the 0s and replaces them with ::
2001:0000:4137:9e76:0c5b:0558:bcb8:e3dd -> 2001:0:4137:9e76:c5b:558:bcb8:e3dd
0000:0000:0000:0000:0000:ffff:b3b8:24c1 -> ::ffff:b3b8:24c1

also some other methods of Encoding

Yes, this is how IPv6 is encoded in compact form, let's call it "human-readable"
(expressed in characters and colons, and made more compact by removing leading zeroes and reducing the amount of colos)
but when expressed in unencoded ByteFormat an IPv6 address always has 16 bytes.

I would almost bet that this unknown format has something to do with Tor, but I'm just guessing.

Let's find the location in bitcoin's source code where this is handled, so we don't need to guess.

[Coding Enthusiast]

I would almost bet that this unknown format has something to do with Tor, but I'm just guessing.

As per your initial comment I also thought about that too, but since I've never seen a Tor IP I looked it up and here are 3 different examples I could find:

171.25.193.20:80 orport=443 id=DD8BD7307017407FCC36F8D04A688F74A0774C02 weight=50600 ipv6=[2001:67c:289c::20]:443
128.6.224.107:9030 orport=9001 id=D67B28212377617448A2AC192E11372AD951FD13 weight=18000 ipv6=[2620:0:d60:401::2]:9001
78.47.134.6:3480 orport=3451 id=26220AEA188B8D0E47BB541E1A616EB3AD70295F weight=2360 ipv6=[2a01:4f8:d13:1602::2012]:3451

Let's find the location in bitcoin's source code where this is handled, so we don't need to guess.

Here is the "tests" core uses to determine if an IP is Tor: https://github.com/bitcoin/bitcoin/blob/master/src/test/netbase_tests.cpp#L42-L61
The example uses this IP: "FD87:D87E:EB43:edb1:8e4:3588:e546:35ca"

[georgem]

Here is the "tests" core uses to determine if an IP is Tor: https://github.com/bitcoin/bitcoin/blob/master/src/test/netbase_tests.cpp#L42-L61
The example uses this IP: "FD87:D87E:EB43:edb1:8e4:3588:e546:35ca"

Thank you very much. Very helpful.

But none of the tests listed there try to resolve an 8-byte structure.

If this unknown 8-byte format has anything to do with TOR, wouldn't it try to represent a *.onion address?

I will admit that I have never used TOR,
well I have used the TOR Browser a few times,
but I have no technical experience with TOR other than that (yet).

[georgem]

If you look at https://bitnodes.21.co/nodes/

it seems that onion-addresses always seem to have the same size/length



Here they talk a little bit about the onion-format:

http://security.stackexchange.com/questions/29772/how-do-you-get-a-specific-onion-address-for-your-hidden-service

Not sure if this helps our case.

[Coding Enthusiast]

But none of the tests listed there try to resolve an 8-byte structure.

Yeah, that is what confuses me too. I tried passing those hexes to my code trying to connect to those IPs but my Connect operation to the IP fails throwing a NotSupportedException, although this can also be because I am not behind Tor but the IPAddress.Parse also fails.

Some more examples, this time the list of Bitcoin Tor (Fallback) Nodes: https://en.bitcoin.it/wiki/Fallback_Nodes#IPv6_Nodes

If this unknown 8-byte format has anything to do with TOR, wouldn't it try to represent a *.onion address?

I don't think so because .onion is a top level domain suffix and is used because they are not actual DNS name. I may be wrong but you don't necessarily need that for connecting to an IP address (another node).

[georgem]

But none of the tests listed there try to resolve an 8-byte structure.

Yeah, that is what confuses me too. I tried passing those hexes to my code trying to connect to those IPs but my Connect operation to the IP fails throwing a NotSupportedException, although this can also be because I am not behind Tor but the IPAddress.Parse also fails.

Some more examples, this time the list of Bitcoin Tor (Fallback) Nodes: https://en.bitcoin.it/wiki/Fallback_Nodes#IPv6_Nodes

If this unknown 8-byte format has anything to do with TOR, wouldn't it try to represent a *.onion address?

I don't think so because .onion is a top level domain suffix and is used because they are not actual DNS name. I may be wrong but you don't necessarily need that for connecting to an IP address (another node).

That is true, but nonetheless, an onion address is required to connect to a node that uses TOR.
Bare in mind that this is what TOR tries to achieve: that people don't need to expose an IP address, but rather something else: onion.

[Coding Enthusiast]

That is true, but nonetheless, an onion address is required to connect to a node that uses TOR.
Bare in mind that this is what TOR tries to achieve: that people don't need to expose an IP address, but rather something else: onion.

In that case they have to pass the address which is a 16 bytes string inside the IP field.
For example from wiki:
mutqcuh7hwxmhx3k .onion
as hex: 6d757471637568376877786d6878336b

In case this is the way to do it, the result is not starting with 0s