public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

From: Jonas Schnelli <dev@jonasschnelli•ch>
To: "David A. Harding" <dave@dtrt•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151)
Date: Sun, 24 Mar 2019 20:35:45 +0100	[thread overview]
Message-ID: <EDE2573D-ED27-4140-91BE-D405BC3D238D@jonasschnelli.ch> (raw)
In-Reply-To: <20190324132910.ss2fe4nzoneazti5@email>

[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]

Hi Dave

Thanks for the review...

>> ==== Short Command ID ====
>> 
>> To save valuable bandwidth, the v2 message format supports message command
>> short IDs for message types with high frequency. The ID/string mapping is a
>> peer to peer arrangement and MAY be negotiated between the initiating and
>> responding peer.
> 
> Why is this optional and only specified here for some message types
> rather than being required by v2 and specified for all message types?
> There's only 26 different types at present[1], so it seems better to
> simply make this a one-byte fixed-length field than it is to deal with
> variable size, mapping negotiation, per-peer mapping in general, and
> (once the network is fully v2) the dual-logic of being able to process
> messages either from a short ID or a full command name.

One thing I was trying to avoid is some sort of central planing.

Strings as message command identifier do usually bring some sort of collision resistance when competitive implementations work on different features.
An example are the service bits where we AFAIK had an (almost) collision.
This is the main reason why I think we should avoid setting the short IDs mandatory (naturally by not giving all commands a short ID).

Short IDs do probably make most sense for messages with high frequency.
By only giving frequent messages a short ID, we may avoid ID collisions in future.

Short IDs can be altered with the message protocol version (not the transport protocol, the message protocol like 70015, etc.) and new/different negation should be straight forward.

I just ran some random stats (non representative) and inv makes about 66% of all messages (pruned peer, not helping IBDing others) followed by tx and getdata.
Those three probably deserve a short ID.

I have no big objection against adding short IDs for other commands as long as we don’t make short IDs mandatory.
Though, there are little benefits for commands like VERSION, FILTERxx, SENDHEADERS, etc.,... and, we only(?!) have 244 short IDs.

/jonas


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

next prev parent reply	other threads:[~2019-03-24 19:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-22 21:04 Jonas Schnelli
2019-03-24 13:29 ` David A. Harding
2019-03-24 15:38   ` David A. Harding
2019-03-24 19:35   ` Jonas Schnelli [this message]
2019-03-25  6:32 ` Eric Voskuil

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=EDE2573D-ED27-4140-91BE-D405BC3D238D@jonasschnelli.ch \
    --to=dev@jonasschnelli$(echo .)ch \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=dave@dtrt$(echo .)org \
    /path/to/YOUR_REPLY

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox