* [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes)
@ 2012-05-16 18:18 Jeff Garzik
2012-05-16 18:29 ` Luke-Jr
0 siblings, 1 reply; 4+ messages in thread
From: Jeff Garzik @ 2012-05-16 18:18 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
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.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes)
2012-05-16 18:18 [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes) Jeff Garzik
@ 2012-05-16 18:29 ` Luke-Jr
2012-05-16 18:38 ` Jeff Garzik
0 siblings, 1 reply; 4+ messages in thread
From: Luke-Jr @ 2012-05-16 18:29 UTC (permalink / raw)
To: bitcoin-development
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).
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes)
2012-05-16 18:29 ` Luke-Jr
@ 2012-05-16 18:38 ` Jeff Garzik
2012-05-16 18:46 ` Luke-Jr
0 siblings, 1 reply; 4+ messages in thread
From: Jeff Garzik @ 2012-05-16 18:38 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
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....
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes)
2012-05-16 18:38 ` Jeff Garzik
@ 2012-05-16 18:46 ` Luke-Jr
0 siblings, 0 replies; 4+ messages in thread
From: Luke-Jr @ 2012-05-16 18:46 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-development
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-05-16 18:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-16 18:18 [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes) Jeff Garzik
2012-05-16 18:29 ` Luke-Jr
2012-05-16 18:38 ` Jeff Garzik
2012-05-16 18:46 ` Luke-Jr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox