public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@exmulti.com>
To: Stefan Thomas <moon@justmoon.de>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP: Custom Services
Date: Mon, 13 Aug 2012 10:24:41 -0400	[thread overview]
Message-ID: <CA+8xBpfZzxBgqO6xT6+a_ACgYR=3cV9rmY_kmSovtT3dfjdhDg@mail.gmail.com> (raw)
In-Reply-To: <5028AFBE.8070104@justmoon.de>

On Mon, Aug 13, 2012 at 3:41 AM, Stefan Thomas <moon@justmoon.de> wrote:
> I was working on some custom protocol extensions for Bitcoin that I
> wanted to experiment with and I noticed that in order to enable nodes to
> announce these services the only mechanism the protocol currently
> provides is to use one of the 64 bits of the services field. This is
> obviously a resource that will run out quickly if we all just help
> ourselves, so I set out to come up with a standardized way to announce
> custom protocol extensions, without using up NODE_* flags.
>
> Please kindly review my solution:
>
> https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Services

heh, this is not a new idea.  I even implemented a pull request for
service discovery myself, which simply consisted of querying the list
of supported commands:
https://github.com/bitcoin/bitcoin/pull/1471

On IRC, I proposed several alternatives including modifying 'version'
(which you did) and a new "getcaps" (get capabilities) command to be
added in protocol_version X.

gmaxwell seems continually unenthused, and made a valid point about
service advertisement:  these capabilities are not advertised with
CAddress, so how does one usefully discover and make use of them?
What are real world use cases, that cannot be solved with nService
bits?

My only response is a weak one:  inevitability.  It seems likely that
-somebody- will implement their own P2P commands for their own client
subset, even if only a simple "use 'getstatus' with strSubVer matching
/FooClient/"

Therefore, if it is inevitable, we might as well make some basic rules
about how to extended your P2P command set.

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com



  parent reply	other threads:[~2012-08-13 14:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-13  7:41 [Bitcoin-development] BIP: Custom Services Stefan Thomas
2012-08-13 13:15 ` Mike Hearn
2012-08-13 20:00   ` Stefan Thomas
2012-08-13 14:24 ` Jeff Garzik [this message]
2012-08-13 15:07   ` Gregory Maxwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+8xBpfZzxBgqO6xT6+a_ACgYR=3cV9rmY_kmSovtT3dfjdhDg@mail.gmail.com' \
    --to=jgarzik@exmulti.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=moon@justmoon.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox