From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1T0vZc-0002Eq-Vj for bitcoin-development@lists.sourceforge.net; Mon, 13 Aug 2012 14:24:52 +0000 X-ACL-Warn: Received: from mail-qc0-f175.google.com ([209.85.216.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1T0vZX-0007RH-C3 for bitcoin-development@lists.sourceforge.net; Mon, 13 Aug 2012 14:24:52 +0000 Received: by qcad10 with SMTP id d10so2316128qca.34 for ; Mon, 13 Aug 2012 07:24:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=fpWftmJyXv4EBhcp+QEwRWh1CO5gulgp1AXzrwfkaSM=; b=fLTFzj4sqc2ULuMewes+fdJKY77GpsA5V7XGSZoGUEHwvI5JosEodqxJXr4K3up3Jq amKRivAUmHIGj+vzHyRFfbPXNcX0pQFr1jVU+LkO2iXMCK/gpu9Yx7P4L0gUlwn4Qia/ vK/nNXDL/Q8av5SVsQJZEBbBEmfE5ycG5gjCfKvdayHhNsQHgMdselyu4VCx/zIRsdN9 wUgis9e9VR6SthYGxpBS9lw8RxQYw7T50x+rojHevReaZ8BnzAEpkrRTWtT22KvVzh3w 8t4jr0jT3knMajvPifjCHyaS6Orqr1k05PeDUnazyl3ghjzKWTwrk1mn/F/XZUi73xNe ZMZA== MIME-Version: 1.0 Received: by 10.224.0.202 with SMTP id 10mr25489773qac.5.1344867881836; Mon, 13 Aug 2012 07:24:41 -0700 (PDT) Received: by 10.49.35.195 with HTTP; Mon, 13 Aug 2012 07:24:41 -0700 (PDT) X-Originating-IP: [2001:4830:1603:2:21c:c0ff:fe79:c8c2] In-Reply-To: <5028AFBE.8070104@justmoon.de> References: <5028AFBE.8070104@justmoon.de> Date: Mon, 13 Aug 2012 10:24:41 -0400 Message-ID: From: Jeff Garzik To: Stefan Thomas Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkopwyOO4cBkFsvYEncr1jQroqmOYvGsbT+OgwQy8Bg4IolvIpTV1SvCZusT802aE0aIFNW X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1T0vZX-0007RH-C3 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] BIP: Custom Services X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 14:24:53 -0000 On Mon, Aug 13, 2012 at 3:41 AM, Stefan Thomas 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