In-Reply-To: <CAFp6fsFgkGV93PrdJPXnS880weNX=bXd17H1u5V7VBucTtW=7A@mail.gmail.com>
References: <CAFp6fsHBbyVo21DnQKGBVJ7P=8NqOGJ-jv0-MH9WaBD6vauudA@mail.gmail.com>
	<CAE-z3OUKTKh5-SHkiawr4R58Fdg9N6_1PLjW19YsF-K9OOjQow@mail.gmail.com>
	<CAFp6fsEq0So3nUtRrn1G3Q-sEFUpK7myxfvT9-p9LNkxPGYoTw@mail.gmail.com>
	<10E4880B-1B3F-40AF-88DD-65D152533DFC@petertodd.org>
	<CAFp6fsFgkGV93PrdJPXnS880weNX=bXd17H1u5V7VBucTtW=7A@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
From: Peter Todd <pete@petertodd.org>
Date: Thu, 24 Sep 2015 19:27:57 +0000
To: Suhas Daftuar <sdaftuar@gmail.com>
Message-ID: <7E19FA2C-70E5-4D8A-B533-50463FA92918@petertodd.org>
Cc: Suhas Daftuar via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] New "sendheaders" p2p message
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


On 24 September 2015 14:56:23 GMT-04:00, Suhas Daftuar <sdaftuar@gmail.com> wrote:
>I considered that as well, but it seemed to me that other software on
>the
>network (say, different wallet implementations) might prefer the option
>of
>being able to bump up their protocol version in the future to pick up
>some
>other change, without having to also opt-in to receiving
>headers-announcements for blocks.
>
>In particular, inv-based block announcements aren't going away (even in
>my
>implementation of headers announcements, there are some edge cases
>where
>the code would need to fall back to an inv announcement), so forcing
>all
>software on the network to upgrade to supporting headers announcements,
>whether now or in the future, seems too drastic -- I could imagine some
>software not being very concerned about optimizing block relay in this
>particular way.

Block headers are so small - 80 bytes - that it may be reasonable to just stop using the inv mechanism for them in favor of always sending headers. IIRC a inv is 32 bytes of digest and another four bytes or something of the inv string itself - that's already nearly half of the header.

Meanwhile reducing the amount of state in the protocol does have some value, and decreasing overall latency for headers to get around the network certainely isnt a bad thing.
-----BEGIN PGP SIGNATURE-----

iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWBE60
AAoJEMCF8hzn9Lncz4MH/jybITh0VWtf+2MotWZOdMIiQtmWZ6Ly2yiDXwi3atu+
MEA6yx9vPFV8P1ZKIZzVtr/4Iu3gBHBdDxAzQW0SjreTLdzZ1+d28/A2kYD4+es7
MFD8rDV/kPtnu8ajMkS9bfmrU0WfkgSSB2fUheT+kqgH/ejIJBISo8BpQZbz7f4B
M+D+hoNadcqWcZZKBHT+o5o7v3jJwxh8qpJgMMZrtN/QfFJK5UVdU4I/hEd89XP9
XD/y29ykWAFQPDdBKMGIUj1csUGlyS5kFXp6ZLVtAZWHIgfZ1R/qOhIUcRwRxZjc
JXZEWrMGTIXr2zkX9mtLzfjAzDc6ZULoEAHCV3sVa0M=
=SLUT
-----END PGP SIGNATURE-----