[bitcoin-dev] Services bit for xthin blocks

[G. Andrew Stone via bitcoin-dev]

The Bitcoin Unlimited client needs a services bit to indicate that the node
is capable of communicating thin blocks. We propose to use bit 4 as AFAIK
bit 3 is already earmarked for Segregated Witness.

Andrew

[Gregory Maxwell via bitcoin-dev]

On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev

Post by G. Andrew Stone via bitcoin-dev
The Bitcoin Unlimited client needs a services bit to indicate that the node
is capable of communicating thin blocks. We propose to use bit 4 as AFAIK
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.

[Gregory Maxwell via bitcoin-dev]

I think a BIP is a good idea, but rather than making such a specific
proposal as "Let's use bit 4 to indicate communication of thin blocks," how
about a more general one like "Let's use bit(s?) 4(-5?) as user-agent

Not communicated in address messages, so useless for discovery.

I think any feature which could do this could use the BIP130 approach instead.

[G. Andrew Stone via bitcoin-dev]

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:
https://bitco.in/forum/threads/buip010-passed-xtreme-thinblocks.774/. We
would love to have any interested engineer join us there with ideas and
criticisms.

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
capabilities.

Regards,
Andrew Stone
Developer, Bitcoin Unlimited


<pre>
BIP: XXX
Title: Extreme thin block service bit
Author: Andrew Stone <***@gmail.com>
Status:
Type: Standards Track
Created: 2016-03-07
</pre>

==Abstract==

Nodes need to communicate to each other whether or not thin block
communication messages are supported.

==Motivation==

# Ensure Satoshi client interoperability

==Rationale==

Clients will use this functionality to choose peers, so a service bit is
the most appropriate location.

==Specification==

# Bit (1 << 4) of the nServices flags enum located in protocol.h shall
indicate the ability to handle thin block communication messages.

==Backward compatibility==

All older clients are compatible with this change. Users and merchants
should not be impacted.

==Implementation==

/** nServices flags */
enum {
...
// NODE_XTHIN means the node is capable of and willing to handle Xthin
messages.
NODE_XTHIN = (1 << 4),
...
};

==Copyright==
This document is Public Domain.

Hi,

Post by Gregory Maxwell via bitcoin-dev
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 <

Post by Gregory Maxwell via bitcoin-dev
On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev

Post by G. Andrew Stone via bitcoin-dev
The Bitcoin Unlimited client needs a services bit to indicate that the

node

Post by G. Andrew Stone via bitcoin-dev
is capable of communicating thin blocks. We propose to use bit 4 as

AFAIK

Post by G. Andrew Stone via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Luke Dashjr via bitcoin-dev]

Post by G. Andrew Stone via bitcoin-dev
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
https://bitco.in/forum/threads/buip010-passed-xtreme-thinblocks.774/. We
would love to have any interested engineer join us there with ideas and
criticisms.

Bitcoin-dev and the BIP process are not affiliated with Core at all. In fact,
the BIP process was created by Amir Taaki, who was a libbitcoin developer
(libbitcoin is not Core).

I encourage Bitcoin Unlimited to use the BIP process for cross-implementation
standards like this, as do other implementations, so that you can benefit from
peer review from the wider Bitcoin development community, as well as have a
common repository for these standards.

Many BIPs are discussed on reddit in addition to this mailing list, and you
would certainly remain free to discuss your own proposals on any forum you
like - it isn't restricted to only this mailing list.

If this is of interest, I will be happy to try to go over and assign BIP
numbers to the current (15?) BUIPs assuming they meet the basic requirements
for such assignment (see BIP 1:
https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki). Is there an
easy way to get links to each of the BUIPs? I couldn't find BUIP 1 at all, for
example.

Thanks,

Luke

[G. Andrew Stone via bitcoin-dev]

Thanks for your offer Luke, but we are happy with our own process and,
regardless of historical provenance, see this mailing list and the BIP
process as very Core specific for reasons that are too numerous to describe
here but should be obvious to anyone who has been aware of the last year of
Bitcoin history.

Andrew

Post by Luke Dashjr via bitcoin-dev

Post by G. Andrew Stone via bitcoin-dev
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
https://bitco.in/forum/threads/buip010-passed-xtreme-thinblocks.774/. We
would love to have any interested engineer join us there with ideas and
criticisms.

Bitcoin-dev and the BIP process are not affiliated with Core at all. In fact,
the BIP process was created by Amir Taaki, who was a libbitcoin developer
(libbitcoin is not Core).
I encourage Bitcoin Unlimited to use the BIP process for
cross-implementation
standards like this, as do other implementations, so that you can benefit from
peer review from the wider Bitcoin development community, as well as have a
common repository for these standards.
Many BIPs are discussed on reddit in addition to this mailing list, and you
would certainly remain free to discuss your own proposals on any forum you
like - it isn't restricted to only this mailing list.
If this is of interest, I will be happy to try to go over and assign BIP
numbers to the current (15?) BUIPs assuming they meet the basic requirements
https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki). Is there an
easy way to get links to each of the BUIPs? I couldn't find BUIP 1 at all, for
example.
Thanks,
Luke

[Tier Nolan via bitcoin-dev]

On Wed, Mar 9, 2016 at 6:11 PM, G. Andrew Stone via bitcoin-dev <

Post by G. Andrew Stone via bitcoin-dev
Thanks for your offer Luke, but we are happy with our own process and,
regardless of historical provenance, see this mailing list and the BIP
process as very Core specific for reasons that are too numerous to describe
here but should be obvious to anyone who has been aware of the last year of
Bitcoin history.

One of the advantages with the BIP process is that it means that there are
hashlocked descriptions of the specs available for people to implement
against.

The BIP process is not the same as getting a PR accepted into core. It is
not a veto based process. If you write the BIP and it doesn't have any
serious technical problems, then it will be accepted into the BIP repo.

Getting it marked as "final" is harder but I don't think that matters
much. I don't think that core would actually use a service bit that was
claimed in a BIP, even if the BIP wasn't final. Maybe in 20 years if thin
blocks aren't being used, they might recycle it. It would be pretty
obviously an aggressive act otherwise.

The NODE_GETUTXO bit is a perfect example of that. They don't think it is
a good idea, but they still accepted the claim on the bit, because there
are nodes actually using it.

On the other hand, the BIP git repository is hosted on the /bitcoin github
site, so in that context it can be seen as linked with core. I wouldn't be
surprised if that specific objection was raised when it was moved from the
wiki to github. Luke may be willing to change that if you think that would
be worth changing?

With regards to the proposal, the description on the forum link isn't
sufficient for an alternative client to implement it. I had a look at the
thread and I think that this is the implementation?

https://github.com/ptschip/bitcoinxt/commit/7ea5854a3599851beffb1323544173f03d45373b

Is the intention here to simply reserve the bit for thin blocks usage or to
define the specification for inter-operation with other clients?

Perhaps there could be a process for claiming service bits as it can be
useful to claim a bit in advance of actually finalizing the feature.

- Claim bit with a reasonable justification (good faith intent to implement
and the bit is useful for the feature)
- Within 3 months have a finalized description of the feature that lets
other clients implement it
- Within 6 months have working software that deploys the feature
- After 6 months of it actually being in active use, the bit is "locked"
and stays assigned to that feature

There could be an expiry process if it ends up not being used after all.
Requiring a public description of the feature seems like a reasonable
requirement in exchange for the community assigning the service bit, but we
don't want to go to far. There is no point in having lots of free bits
that end up never being used. Worst case, the addr message could be
updated to add more bits.

[Tier Nolan via bitcoin-dev]

These are the relevant info BIPs.

NODE_GETUTXO
https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki

NODE_BLOOM:
https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki

The relevant code is here:
https://github.com/bitcoin/bitcoin/blob/master/src/protocol.h#L228

The NODE_GETUTXO bit was included even though it is not supported by core.
(It is one of XT's features).

I think you need to be able to reasonably claim that the bit is useful and
will have actual users, before you can claim a bit.

You can also claim one of the free for all bits 24 - 31, but that is
supposed to be only temporary.

Giving a link to "thin blocks" would help promote discussion about its
merits.

On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev <

Post by G. Andrew Stone via bitcoin-dev
The Bitcoin Unlimited client needs a services bit to indicate that the
node is capable of communicating thin blocks. We propose to use bit 4 as
AFAIK bit 3 is already earmarked for Segregated Witness.
Andrew
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev