User:Justmoon/BIP Draft: Custom Service Discovery - Revision history

Justmoon: Update reference with actual BIP number.

2012-08-19T06:07:55Z

Update reference with actual BIP number.

← Older revision		Revision as of 06:07, 19 August 2012
Line 12:		Line 12:
	== Abstract ==		== Abstract ==

	This BIP augments BIP XX to provide a recommendation how nodes using a specific custom services might handle discovery of peers supporting the same service. This BIP introduces no changes to the Bitcoin protocol and is purely informational.		This BIP augments [[BIP 0036\|BIP 36]] to provide a recommendation how nodes using a specific custom services might handle discovery of peers supporting the same service. This BIP introduces no changes to the Bitcoin protocol and is purely informational.

	== Motivation ==		== Motivation ==

Justmoon: Added standard BIP structure.

2012-08-10T19:41:18Z

Added standard BIP structure.

@@ Line 1: / Line 1: @@
-===Optional: Announcing known nodes===
+<pre>
 Bitcoin includes the <code>services</code> field for each node in the <code>addr</code> message. This is very useful for discovering other nodes that support a specific service. For example a lightweight client may be interested in finding all the nodes capable of serving it.
@@ Line 33: / Line 51: @@
 If a node knows about many different services, the recommendation is to store a bitmask of all the recognized services for each node, order by that field and then use <code>X:addr</code> messages using TYPE_RLE.

Justmoon: Section split off from original BIP.

2012-08-10T18:20:21Z

Section split off from original BIP.

New page

===Optional: Announcing known nodes===

Bitcoin includes the <code>services</code> field for each node in the <code>addr</code> message. This is very useful for discovering other nodes that support a specific service. For example a lightweight client may be interested in finding all the nodes capable of serving it.

However, some services may not need this functionality whereas other services may need to communicate extra information per node. So rather than modifying the <code>addr</code> message, we instead send a service-specific message ahead of it. This message SHOULD use the addr subcommand, so for the <code>MySampleSvc</code> service it would be called <code>MySampleSvc:addr</code>. We'll refer to it here generically as the <code>*:addr</code> message.

The <code>*:addr</code> of a service specifies which nodes in the next following <code>addr</code> list support that service. It uses the following format:

* If <code>*:addr</code> is empty or starts with TYPE_ALL (0x00), then all addresses in the next <code>addr</code> message support the service.
* If <code>*:addr</code> starts with TYPE_BITS (0x01), then the rest of the data is a bit array marking which nodes in the next addr message support the service. Any nodes not covered by the bitarray don't support the service.
* If <code>*:addr</code> starts with TYPE_RLE (0x02), then the next byte determines whether the first address supports the service and the remaining data is a series of [[Protocol_specification#Variable_length_integer|var_ints]] determining the lengths of runs of nodes that support or don't support the service, not counting the first node in the run. Any nodes not covered by the RLE have the opposite value of the last node covered.
* If there was no <code>*:addr</code> message since the last <code>addr</code> message or the beginning of the connection, then none of the nodes in the next <code>addr</code> message support the service.

Examples:

00 - TYPE_ALL - all nodes in the next addr message support the service

01 - TYPE_BITS
FC - 11111100 - First six nodes support the service, next two don't
1F - 00011111 - Next three don't, next five do
- Remaining nodes don't

02 - TYPE_RLE
01 - First set of nodes are nodes that support the service
05 - First six nodes support the service
FD 42 03 - Next 835 nodes don't
00 - Next node does
08 - Next nine nodes don't
- Remaining nodes do

Multiple <code>X:addr</code> messages for different services MUST all be applied to the next <code>addr</code> message. If there are multiple <code>X:addr</code> messages for the same service, only the most recent one is used.

If a node knows about many different services, the recommendation is to store a bitmask of all the recognized services for each node, order by that field and then use <code>X:addr</code> messages using TYPE_RLE.