[bitcoin-dev] Services bit for xthin blocks
G. Andrew Stone
g.andrew.stone at gmail.com
Tue Mar 8 02:35:21 UTC 2016
Included at the bottom of this mail is a BIP concerning our impending use
of a particular services bit.
I am making a good-faith effort to notify the community of this use and
follow the BIP submission rules with a correctly formatted BIP sent to Luke
jr. He has informed me that such a BIP should be discussed on the mailing
list (which is this thread) and that the BIP should document the extreme
thin block protocol.
Not an unreasonable request, however while I personally respect the many
great accomplishments of individual engineers loosely affiliated with
"Core", Bitcoin Unlimited has our own process for documentation and
discussion on an uncensored forum located here:
would love to have any interested engineer join us there with ideas and
But since Bitcoin Unlimited already has a process, it would be redundant
and time consuming for us to adhere to your process. If a "Core" engineer
would like to spend the time to move this BIP through your process I would
be eternally grateful and be willing to use a different bit or make other
changes that make mutual sense. If not, then it is up to "Core" as a group
to decide whether they would like to preserve interoperability as the
protocol intended by avoiding use of bit 1<<4 (except to indicate the
presence of a compatible Xthin implementation), or whether they will force
clients to take the sub-version field into account when determining client
Developer, Bitcoin Unlimited
Title: Extreme thin block service bit
Author: Andrew Stone <g.andrew.stone at gmail.com>
Type: Standards Track
Nodes need to communicate to each other whether or not thin block
communication messages are supported.
# Ensure Satoshi client interoperability
Clients will use this functionality to choose peers, so a service bit is
the most appropriate location.
# Bit (1 << 4) of the nServices flags enum located in protocol.h shall
indicate the ability to handle thin block communication messages.
All older clients are compatible with this change. Users and merchants
should not be impacted.
/** nServices flags */
// NODE_XTHIN means the node is capable of and willing to handle Xthin
NODE_XTHIN = (1 << 4),
This document is Public Domain.
On Mon, Mar 7, 2016 at 4:10 PM, dagurval <dagurvj+btclist at gmail.com> wrote:
> > Does this functionality change peer selection?
> This bit will be used for selecting outgoing peers in Bitcoin XT.
> On Mon, Mar 7, 2016 at 9:51 PM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > The Bitcoin Unlimited client needs a services bit to indicate that the
>> > is capable of communicating thin blocks. We propose to use bit 4 as
>> > bit 3 is already earmarked for Segregated Witness.
>> Does this functionality change peer selection? If not, the preferred
>> signaling mechanism is probably the one in BIP 130.
>> Otherwise, I think the standard method for getting numbers has been to
>> write a BIP documenting the usage. I don't know if that is intentional
>> or just how things have previously happened; and I don't have much of
>> an opinion on it.
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev