MIME-Version: 1.0
Sender: dagurvj@gmail.com
In-Reply-To: <CAAS2fgQi1X4v9WxT1pnd_XSyE2b8hUZUv0z5A8cOEvw5RztOKw@mail.gmail.com>
References: <CAHUwRvuR9qtYc+rVh1yPbQoESxm4m0r6a+Fd6VF=FuT0vom_HQ@mail.gmail.com>
	<CAAS2fgQi1X4v9WxT1pnd_XSyE2b8hUZUv0z5A8cOEvw5RztOKw@mail.gmail.com>
From: dagurval <dagurvj+btclist@gmail.com>
Date: Mon, 7 Mar 2016 22:10:33 +0100
Message-ID: <CALcNmJwY=pQuRpnb-MJ1QiME3mPUSe2KmHD7XykhX08yku9mhQ@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary=001a114111065f0348052d7be660
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Services bit for xthin blocks
Precedence: list

--001a114111065f0348052d7be660
Content-Type: text/plain; charset=UTF-8

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
>

--001a114111065f0348052d7be660
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style=3D"font-size:12.8px">Hi,<br></div><span class=
=3D"im" style=3D"font-size:12.8px"><div><br></div><div>&gt;=C2=A0<span styl=
e=3D"font-size:12.8px">Does this functionality change peer selection?=C2=A0=
</span></div><div><br></div></span><div style=3D"font-size:12.8px">This bit=
 will be used for selecting outgoing peers in Bitcoin XT.</div></div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Mar 7, 2016 at =
9:51 PM, Gregory Maxwell via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><span class=3D"">On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via=
 bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.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>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>
</blockquote></div><br></div>

--001a114111065f0348052d7be660--