From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 75D63CC7 for ; Tue, 8 Mar 2016 02:35:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 32212102 for ; Tue, 8 Mar 2016 02:35:22 +0000 (UTC) Received: by mail-qk0-f175.google.com with SMTP id x1so851415qkc.1 for ; Mon, 07 Mar 2016 18:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=DkdjZ1dX5Hz8xaL1rouggc7sQv9/Ge7S/NXT0tDVWeY=; b=H+6apswVYhW9he3QLBxvY8rXc5jpu9FCQI87vbQ1COY/mZy9qADA1f7qtTtnNYASMu m5XfqeU48Cg0b11a+BPuSFmegOO9F5y3Ti2w9wMQi+o/y2k/bqjBF/bnMaerwElqexW7 y7C7KBG27F1LnxBbLt0N95uyTsaC4zmLB14biQUcvj4Lm2XiEEOz1S3hwRnbJxWypym6 AaJIO7FKIY+SKB2NWj/xWNM/oJnqW5c0O5mKIUItWxdHT7PoXseHY2KRAdtRqiQWezn8 g+JY4elNSTArmgTpWjzBolVeHhKQbmLqeaZTNekvUxdTBFdmOu7EDZTHkGTrNqJi8Yqu kswA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=DkdjZ1dX5Hz8xaL1rouggc7sQv9/Ge7S/NXT0tDVWeY=; b=SwCDL4GuJ7y1uJav51bvqsu+hR3GY/I4KkG+/qFflBsdYuApRdQ/+vuldmFhHMnTwC WG5fb5Q6DwBQx1fbovymBTYM+5WePEKcww+sR46JwI96YT33djicetVBhTMlHuO0el9S 7znKzmOXO/B28TkFc0UX4WXrAPKM/iQ9e8ZZ0EzKZR7r7nmQ+2rZimq59K/62sKvGLwH 1o8oXO0ZVV6zYOh33oWQ6JAWXay/hJnpA+Pndgcoh7rWp6h6BLwQdgV6R5mLz6faNaEm ExBI7/Xz0fyY9p1imr/d9X1t1IiqsPPlgm9n8uvwO+gPDmVMZgby6qKAsM+vlhWHe4Ls cVjw== X-Gm-Message-State: AD7BkJIhhd+D9bpSv2RhfrtFbToqmMrR6r0kPq/5QACiNHrJGOBv1e5H6QSO4w5QB35hTAVZOODT7d8idT9XCQ== MIME-Version: 1.0 X-Received: by 10.55.75.77 with SMTP id y74mr32201501qka.19.1457404521410; Mon, 07 Mar 2016 18:35:21 -0800 (PST) Received: by 10.55.9.13 with HTTP; Mon, 7 Mar 2016 18:35:21 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Mar 2016 21:35:21 -0500 Message-ID: From: "G. Andrew Stone" To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a114ab048cafdc0052d806ec6 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 08 Mar 2016 06:58:05 +0000 Subject: Re: [bitcoin-dev] Services bit for xthin blocks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 02:35:23 -0000 X-List-Received-Date: Tue, 08 Mar 2016 02:35:23 -0000 --001a114ab048cafdc0052d806ec6 Content-Type: text/plain; charset=UTF-8 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 
  BIP: XXX
  Title: Extreme thin block service bit
  Author: Andrew Stone 
  Status:
  Type: Standards Track
  Created: 2016-03-07
==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. On Mon, Mar 7, 2016 at 4:10 PM, dagurval wrote: > Hi, > > > 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@lists.linuxfoundation.org> wrote: > >> On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev >> wrote: >> > 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. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > --001a114ab048cafdc0052d806ec6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Included at the bottom of this mail is a BIP concerni= ng our impending use of a particular services bit.=C2=A0

I am making a good-faith effort to notify the community of this use and fo= llow the BIP submission rules with a correctly formatted BIP sent to Luke j= r.=C2=A0 He has informed me that such a BIP should be discussed on the mail= ing list (which is this thread) and that the BIP should document the extrem= e thin block protocol.=C2=A0

Not an unreasonable request, however w= hile I personally respect the many great accomplishments of individual engi= neers loosely affiliated with "Core", Bitcoin Unlimited has our o= wn process for documentation and discussion on an uncensored forum located = here: https://bitco.in/forum/threads/buip010-passed= -xtreme-thinblocks.774/.=C2=A0 We would love to have any interested eng= ineer join us there with ideas and criticisms.

But since = Bitcoin Unlimited already has a process, it would be redundant and time con= suming for us to adhere to your process.=C2=A0 If a "Core" engine= er would like to spend the time to move this BIP through your process I wou= ld be eternally grateful and be willing to use a different bit or make othe= r changes that make mutual sense.=C2=A0 If not, then it is up to "Core= " as a group to decide whether they would like to preserve interoperab= ility as the protocol intended by avoiding use of bit 1<<4=C2=A0 (exc= ept to indicate the presence of a compatible Xthin implementation), or whet= her they will force clients to take the sub-version field into account when= determining client capabilities.

Regards,
= Andrew Stone
Developer, Bitcoin Unlimited

=
<pre>
=C2=A0 BIP: XXX
=C2=A0 Title: Extreme thin block serv= ice bit
=C2=A0 Author: Andrew Stone <g.andrew.stone@gmail.com>
=C2=A0 St= atus:
=C2=A0 Type: Standards Track
=C2=A0 Created: 2016-03-07
<= ;/pre>

=3D=3DAbstract=3D=3D

Nodes need to communicate to e= ach other whether or not thin block communication messages are supported.
=3D=3DMotivation=3D=3D

# Ensure Satoshi client interoperabilit= y

=3D=3DRationale=3D=3D

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

= =3D=3DSpecification=3D=3D

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

All older clients are compati= ble with this change. Users and merchants should not be impacted.

= =3D=3DImplementation=3D=3D

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

=3D=3DCopyright=3D=3D
Th= is document is Public Domain.

On Mon, Mar 7, 2016 at 4:10 PM, dagurval <da= gurvj+btclist@gmail.com> wrote:
Hi,

>=C2=A0Does this functionality change peer selection?=C2=A0

This bit will be used for selecting outgoing peers in Bitcoin XT.

O= n Mon, Mar 7, 2016 at 9:51 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=
On Mon, Mar 7, 2016 a= t 8:06 PM, G. Andrew Stone via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> The Bitcoin Unlimited client needs a services bit to indicate that the= node
> is capable of communicating thin blocks.=C2=A0 We propose to use bit 4= as AFAIK
> bit 3 is already earmarked for Segregated Witness.

Does this functionality change peer selection?=C2=A0 If not, the pre= ferred
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<= br> or just how things have previously happened; and I don't have much of an opinion on it.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a114ab048cafdc0052d806ec6--