Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C1A84A59 for ; Sun, 24 Mar 2019 15:40:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B1A30764 for ; Sun, 24 Mar 2019 15:40:32 +0000 (UTC) Received: from harding by newmail.dtrt.org with local (Exim 4.89) (envelope-from ) id 1h85Ed-0007p2-6c; Sun, 24 Mar 2019 11:40:31 -0400 Date: Sun, 24 Mar 2019 11:38:56 -0400 From: "David A. Harding" To: Bitcoin Protocol Discussion Message-ID: <20190324153856.5k4go3ws53hs4eit@email> References: <26A4BEC6-403C-4534-8A2D-57C71D1736FB@jonasschnelli.ch> <20190324132910.ss2fe4nzoneazti5@email> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nyprty5jgvc2bnpw" Content-Disposition: inline In-Reply-To: <20190324132910.ss2fe4nzoneazti5@email> User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 25 Mar 2019 06:42:16 +0000 Cc: Gregory Maxwell Subject: Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 15:40:33 -0000 --nyprty5jgvc2bnpw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Mar 24, 2019 at 09:29:10AM -0400, David A. Harding via bitcoin-dev wrote: > Why is this optional and only specified here for some message types > rather than being required by v2 and specified for all message types? Gregory Maxwell discussed this with me on IRC[1]. My summary of our conversation: Although the BIP can easily allocate short-ids to all existing messages, anyone who wants to add an additional protocol message later will need to coordinate their number allocation with all other developers working on protocol extensions. This includes experimental and private extensions. At best this would be annoying, and at worst it'd be another set of bikeshed problems we'd waste time arguing about. Allowing nodes to continue using arbitrary command names eliminates this coordination problem. Yet we can also gain the advantage of saving bandwidth by allowing mapping (with optional negotiation) of short-ids. Now that I understand the motivation, this part of the proposal makes sense to me. -Dave [1] http://www.erisian.com.au/bitcoin-core-dev/log-2019-03-24.html#l-159 --nyprty5jgvc2bnpw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAlyXpI8ACgkQ2dtBqWwi adMAZw//WCLKtiQPVqrMUwIklFaQRwUkMrTD61e7dCR0PpRPGnuP+l0kiKywSxqg KCX3B4Dh701J/GFbyBTk4NjUkc7ooVImvql6uW/MZa6ENDyy0elD7YqNgK84HHU0 8fSQhJQ1Z+DwcyCewbWF+J8pnKDIYxcfMldztPpCWShHFUz+Vv8c1W4nds4F3Jvl 3nMadu89SRyiyS2gIG4COKmLXElhryzVvDQODRabC3pb6Ci5H/GFGlQ5F8Dvz+gT lYJssSfH8ddctYwJtJtHcYMX5udlqboItI6JAR/SW+/mYuZuOkXYQEOI0JQVLzIn 1X3VdFvj8F4zleKEpC2iHhc/Gqj8TVphUCicX2K0zeg9HzbJLMzE5yQj/tSw4+hb rFOYu9bQIpsOAm65JrcgMWU/Oti7IfcGr7w46Tw9B6VmYtV8WZIAHst1w1qpGqC7 UXmxp96P4gNw8AQDTATA3rNEtuO/mAy/L3C87qcWa61+IZdWeoQHyKUR+c8Y4KWc zfzpvhwyqWy0EFFXjOdCB3P9RNUUEp6bAQ2qrpNNbJFGPnJsa8q3GdH/uQHhpvhp tNJMKQR0n/f+kUZ+H2yoT8RKR7WMQtwahr9LLYq3AEXHLPFtxUJtsu2G0cNxb5py 2UxEw30/42pUunHjXJhUfnSb7SZ7B0Bxibn7TF4O+wSDtnxJmvA= =cyI1 -----END PGP SIGNATURE----- --nyprty5jgvc2bnpw--