From: "David A. Harding" <dave@dtrt•org>
To: Jonas Schnelli <dev@jonasschnelli•ch>,
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 09:29:10 -0400 [thread overview]
Message-ID: <20190324132910.ss2fe4nzoneazti5@email> (raw)
In-Reply-To: <26A4BEC6-403C-4534-8A2D-57C71D1736FB@jonasschnelli.ch>
[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]
On Fri, Mar 22, 2019 at 10:04:46PM +0100, Jonas Schnelli via bitcoin-dev wrote:
> === v2 Messages Structure ===
>
> {|class="wikitable"
> ! Field Size !! Description !! Data type !! Comments
> [...]
> | 1-13 || encrypted command || variable || ASCII command (or one byte short command ID)
> [...]
> The command field MUST start with a byte that defines the length of the ASCII
> command string up to 12 chars (1 to 12) or a short command ID (see below).
> [...]
> ==== 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.
Thanks,
-Dave
[1] src/protocol.cpp:
const static std::string allNetMessageTypes[] = {
NetMsgType::VERSION,
NetMsgType::VERACK,
NetMsgType::ADDR,
NetMsgType::INV,
NetMsgType::GETDATA,
NetMsgType::MERKLEBLOCK,
NetMsgType::GETBLOCKS,
NetMsgType::GETHEADERS,
NetMsgType::TX,
NetMsgType::HEADERS,
NetMsgType::BLOCK,
NetMsgType::GETADDR,
NetMsgType::MEMPOOL,
NetMsgType::PING,
NetMsgType::PONG,
NetMsgType::NOTFOUND,
NetMsgType::FILTERLOAD,
NetMsgType::FILTERADD,
NetMsgType::FILTERCLEAR,
NetMsgType::REJECT,
NetMsgType::SENDHEADERS,
NetMsgType::FEEFILTER,
NetMsgType::SENDCMPCT,
NetMsgType::CMPCTBLOCK,
NetMsgType::GETBLOCKTXN,
NetMsgType::BLOCKTXN,
};
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-03-24 13:30 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 [this message]
2019-03-24 15:38 ` David A. Harding
2019-03-24 19:35 ` Jonas Schnelli
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=20190324132910.ss2fe4nzoneazti5@email \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dev@jonasschnelli$(echo .)ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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