I wrote a BIP on discovery to go along with BIP 36, just never submitted it: https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Service_Discovery
Since I'm busy with other projects, if anyone wants to take up and/or finish either of these, please do!
Topic: Discovery of nodes that support custom services (Read 636 times)
It would be nice to have an "addr_v2" message, which supports a list of services. Or some non-propagated way of enumerating services, like a "list_services" P2P message. I've proposed such myself.
I don't see why it needs a new addr type. Other messages aren't set in stone. You can use the old form if you connect to an old node.
The extra info would only be forwarded by new nodes.
Quote
The main issues are thinking about how this gets propagated around the network properly, getting this info from various seeding mechanisms (if possible), and trying to avoid DoS issues.
What about using a bloom filter against the service name.
With a 256 bit auxServices field, 3 bits per service, a node with 5 services would write to 15 bits.
The odds of a false positive would be 1.3% for a 64 bit field, 0.16% for a 128 bit field and 0.02% for 256.
A node could prefix the number of bits, so that a small number of services could have reduced collision probability.
With 10 bits, the 256 bit field has a collision probability of 0.0000081%.
256 bits would mean a doubling of the addr entry size.
Quote
Also, we have nowhere near 64 services, so there are plenty of bits available for use right now, with zero protocol modifications.
However, that is a central solution. You need to get approval first.
It would be nice to have an "addr_v2" message, which supports a list of services. Or some non-propagated way of enumerating services, like a "list_services" P2P message. I've proposed such myself.
The main issues are thinking about how this gets propagated around the network properly, getting this info from various seeding mechanisms (if possible), and trying to avoid DoS issues.
Also, we have nowhere near 64 services, so there are plenty of bits available for use right now, with zero protocol modifications.
The main issues are thinking about how this gets propagated around the network properly, getting this info from various seeding mechanisms (if possible), and trying to avoid DoS issues.
Also, we have nowhere near 64 services, so there are plenty of bits available for use right now, with zero protocol modifications.
This BIP describes a way to support custom services.
It is only at the draft stage and hasn't been updated in nearly a year.
A potential problem with the system is finding nodes that support a given custom service.
The addr message only gives information about the standard services field.
The BIP could be improved by changing the addr message to include custom services.
The core of the addr message is the Network Address field.
int: last_seen (timestamp)
long: services
byte[16]: ip address (ip4 uses only 4 of these)
short: port
Extra info could be added to the end.
var_int: count
char[count][11]: custom services
int[count]: custom service version
Also, the new custom service field in the version message should have a "discovery" flag. This indicates that the service requires discovery.
Each service uses at most 11 characters, so they could be fixed 11 character fields.
If there are no extra services, this adds 1 byte to the network address type.
A maximum number of services would have to be set to prevent spam. However, if an address is received with to many services, the list could simply be truncated.
If a maximum of 10 custom services were supported, then that adds 111 bytes extra to the address (up from 30).
The rule for truncating the list would be that early services are more important than later ones.
Nodes would sort their custom services. Only services that actually need discovery would be included in that list included in the addr message and the most important ones would occur earlier.
It is only at the draft stage and hasn't been updated in nearly a year.
A potential problem with the system is finding nodes that support a given custom service.
The addr message only gives information about the standard services field.
The BIP could be improved by changing the addr message to include custom services.
The core of the addr message is the Network Address field.
int: last_seen (timestamp)
long: services
byte[16]: ip address (ip4 uses only 4 of these)
short: port
Extra info could be added to the end.
var_int: count
char[count][11]: custom services
int[count]: custom service version
Also, the new custom service field in the version message should have a "discovery" flag. This indicates that the service requires discovery.
Each service uses at most 11 characters, so they could be fixed 11 character fields.
If there are no extra services, this adds 1 byte to the network address type.
A maximum number of services would have to be set to prevent spam. However, if an address is received with to many services, the list could simply be truncated.
If a maximum of 10 custom services were supported, then that adds 111 bytes extra to the address (up from 30).
The rule for truncating the list would be that early services are more important than later ones.
Nodes would sort their custom services. Only services that actually need discovery would be included in that list included in the addr message and the most important ones would occur earlier.
Jump to: