P2P feature discovery (was Re: BIP 33 - Stratized Nodes)

On Wed, May 16, 2012 at 12:34 PM, Amir Taaki <zgenjix@yahoo•com> wrote:

> Please check out my proposal,
>
> https://en.bitcoin.it/wiki/BIP_0033
>
> I want to use the existing Bitcoin protocol to provide this functionality in order to maintain compatibility. This proposal does not affect current Bitcoin clients, but allows the parallel system to operate alongside and sometimes intersect with the main Bitcoin network in a positive way.

I do not object to the concept, but the discovery process should be improved. Even venerable SMTP has a better, more flexible capabilities discovery process.

Instead of further overloading service bits in the version message, or altering the version message, let us instead make feature discovery an easy, flexible, extensible process.

We can add new commands without impacting older nodes, so let's create a new command "get-features" (or pick your name) that returns a list of key/value pairs. The key is a string, the value type is determined by the key.

Standard behavior of clients would be to send "get-features" after seeing remote version info, as part of the initial connection handshake.

In any case, the basic point is to move FAR away from fighting over a limited, inflexible resource (service bits in "version" msg) to something string-based and easily extensible.

I can create this as BIP 34, if people wish.

On Wednesday, May 16, 2012 6:18:27 PM Jeff Garzik wrote:

> Instead of further overloading service bits in the version message, or
> altering the version message, let us instead make feature discovery an
> easy, flexible, extensible process.
>
> We can add new commands without impacting older nodes, so let's create
> a new command "get-features" (or pick your name) that returns a list
> of key/value pairs.  The key is a string, the value type is determined
> by the key.

That assumes you already have a connection to the peer in question. As I understand it, the service bits are propagated as part of the address, so you can see at a glance which nodes you want to connect to for some special service. Passing a huge list along might be unwieldy (though it makes sense for protocol changes that don't add new services).

On Wed, May 16, 2012 at 2:29 PM, Luke-Jr <luke@dashjr•org> wrote:

> That assumes you already have a connection to the peer in question.
> As I understand it, the service bits are propagated as part of the address,
> so you can see at a glance which nodes you want to connect to for some
> special service. Passing a huge list along might be unwieldy (though it
> makes sense for protocol changes that don't add new services).

If the peer list becomes too, um, stratified maybe that's a Big Hint that said clients should be using another network entirely, and not overloading bitcoin's P2P network for wholly unrelated tasks. The bitcoin P2P network is not a general message transit network.

Another argument against the proposal, IOW, if you ask me....

On Wednesday, May 16, 2012 6:38:28 PM Jeff Garzik wrote:

> On Wed, May 16, 2012 at 2:29 PM, Luke-Jr <luke@dashjr•org> wrote:
> > That assumes you already have a connection to the peer in question.
> > As I understand it, the service bits are propagated as part of the
> > address, so you can see at a glance which nodes you want to connect to
> > for some special service. Passing a huge list along might be unwieldy
> > (though it makes sense for protocol changes that don't add new
> > services).
>
> If the peer list becomes too, um, stratified maybe that's a Big Hint
> that said clients should be using another network entirely, and not
> overloading bitcoin's P2P network for wholly unrelated tasks.  The
> bitcoin P2P network is not a general message transit network.
>
> Another argument against the proposal, IOW, if you ask me....

No, I meant the inverse. If only a small minority of nodes are stratified, the clients need some way to figure out which ones, without connecting to every node.