path: root/26/18c18c608f1ef2bf8fb92ba8d93c4a6dac8275

Return-Path: <g.andrew.stone@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 75D63CC7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  8 Mar 2016 02:35:22 +0000 (UTC)
Received: by mail-qk0-f175.google.com with SMTP id x1so851415qkc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CALcNmJwY=pQuRpnb-MJ1QiME3mPUSe2KmHD7XykhX08yku9mhQ@mail.gmail.com>
References: <CAHUwRvuR9qtYc+rVh1yPbQoESxm4m0r6a+Fd6VF=FuT0vom_HQ@mail.gmail.com>
	<CAAS2fgQi1X4v9WxT1pnd_XSyE2b8hUZUv0z5A8cOEvw5RztOKw@mail.gmail.com>
	<CALcNmJwY=pQuRpnb-MJ1QiME3mPUSe2KmHD7XykhX08yku9mhQ@mail.gmail.com>
Date: Mon, 7 Mar 2016 21:35:21 -0500
Message-ID: <CAHUwRvv_UMoRhcwy7u2XLz19q3aKNfHXyTNbfaSUsEapFnH2kg@mail.gmail.com>
From: "G. Andrew Stone" <g.andrew.stone@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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


<pre>
  BIP: XXX
  Title: Extreme thin block service bit
  Author: Andrew Stone <g.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.

On Mon, Mar 7, 2016 at 4:10 PM, dagurval <dagurvj+btclist@gmail.com> 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
>> <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.  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

<div dir=3D"ltr"><div>Included at the bottom of this mail is a BIP concerni=
ng our impending use of a particular services bit.=C2=A0 <br><br></div><div=
>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 <br><br>Not an unreasonable request, however w=
hile I personally respect the many great accomplishments of individual engi=
neers loosely affiliated with &quot;Core&quot;, Bitcoin Unlimited has our o=
wn process for documentation and discussion on an uncensored forum located =
here: <a href=3D"https://bitco.in/forum/threads/buip010-passed-xtreme-thinb=
locks.774/" target=3D"_blank">https://bitco.in/forum/threads/buip010-passed=
-xtreme-thinblocks.774/</a>.=C2=A0 We would love to have any interested eng=
ineer join us there with ideas and criticisms.<br><br></div><div>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 &quot;Core&quot; 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 &quot;Core=
&quot; as a group to decide whether they would like to preserve interoperab=
ility as the protocol intended by avoiding use of bit 1&lt;&lt;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.<br><br></div><div>Regards,<br></div><div>=
Andrew Stone<br></div><div>Developer, Bitcoin Unlimited<br> </div><div><br>=
<br>&lt;pre&gt;<br>=C2=A0 BIP: XXX<br>=C2=A0 Title: Extreme thin block serv=
ice bit<br>=C2=A0 Author: Andrew Stone &lt;<a href=3D"mailto:g.andrew.stone=
@gmail.com" target=3D"_blank">g.andrew.stone@gmail.com</a>&gt;<br>=C2=A0 St=
atus: <br>=C2=A0 Type: Standards Track<br>=C2=A0 Created: 2016-03-07<br>&lt=
;/pre&gt;<br><br>=3D=3DAbstract=3D=3D<br><br>Nodes need to communicate to e=
ach other whether or not thin block communication messages are supported.<b=
r><br>=3D=3DMotivation=3D=3D<br><br># Ensure Satoshi client interoperabilit=
y <br><br>=3D=3DRationale=3D=3D<br><br>Clients will use this functionality =
to choose peers, so a service bit is the most appropriate location.<br><br>=
=3D=3DSpecification=3D=3D<br><br>#
 Bit (1 &lt;&lt; 4) of the nServices flags enum located in protocol.h=20
shall indicate the ability to handle thin block communication messages.<br>=
<br>=3D=3DBackward compatibility=3D=3D<br><br>All older clients are compati=
ble with this change. Users and merchants should not be impacted.<br><br>=
=3D=3DImplementation=3D=3D<br><br>/** nServices flags */<br>enum {<br>=C2=
=A0 ...<br>=C2=A0=C2=A0=C2=A0 // NODE_XTHIN means the node is capable of an=
d willing to handle Xthin messages.<br>=C2=A0=C2=A0=C2=A0 NODE_XTHIN =3D (1=
 &lt;&lt; 4),<br>=C2=A0 ...=C2=A0 <br>};<br><br>=3D=3DCopyright=3D=3D<br>Th=
is document is Public Domain.<br></div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Mon, Mar 7, 2016 at 4:10 PM, dagurval <span dir=3D=
"ltr">&lt;<a href=3D"mailto:dagurvj+btclist@gmail.com" target=3D"_blank">da=
gurvj+btclist@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div style=3D"font-size:12.8px">Hi,<br></div><span><s=
pan style=3D"font-size:12.8px"><div><br></div><div>&gt;=C2=A0<span style=3D=
"font-size:12.8px">Does this functionality change peer selection?=C2=A0</sp=
an></div><div><br></div></span></span><span><div style=3D"font-size:12.8px"=
>This bit will be used for selecting outgoing peers in Bitcoin XT.</div></s=
pan></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span>O=
n Mon, Mar 7, 2016 at 9:51 PM, Gregory Maxwell via bitcoin-dev <span dir=3D=
"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br>=
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div><div><span>On Mon, Mar 7, 2016 a=
t 8:06 PM, G. Andrew Stone via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; The Bitcoin Unlimited client needs a services bit to indicate that the=
 node<br>
&gt; is capable of communicating thin blocks.=C2=A0 We propose to use bit 4=
 as AFAIK<br>
&gt; bit 3 is already earmarked for Segregated Witness.<br>
<br>
</span>Does this functionality change peer selection?=C2=A0 If not, the pre=
ferred<br>
signaling mechanism is probably the one in BIP 130.<br>
<br>
Otherwise, I think the standard method for getting numbers has been to<br>
write a BIP documenting the usage. I don&#39;t know if that is intentional<=
br>
or just how things have previously happened; and I don&#39;t have much of<b=
r>
an opinion on it.<br></div></div><span>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</span></blockquote></div><br></div>
</blockquote></div><br></div></div>

--001a114ab048cafdc0052d806ec6--