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 90447C6D for ; Tue, 8 Mar 2016 05:14:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8B374109 for ; Tue, 8 Mar 2016 05:14:16 +0000 (UTC) Received: by mail-oi0-f48.google.com with SMTP id m82so3324165oif.1 for ; Mon, 07 Mar 2016 21:14:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=ia3hwN03ESEc/LxuAPdDqBeo745gXDh544ZhEb081vI=; b=EMoqT/+tuPtxYOu4GXy7Avlfl9iPwC24zzVcZaWiXNcRXaBpvmIoVGuJphp+oyQqnc DkFmtF/Bngk3gk+En7Vo1Ze9pDIsiPkdwuifTgSvKDAf+vcBmP1BRhJZqJTPjVB14KmT qCE2No9pg3+yKn3lpoI70r16410vm2SztvJJ6NGyG6aysCttHAnAh5kH8jU0cfpt468W wiL+iTgNrXGXVCUqEtuGAAmJOMfoWSH0Ets1gQPM6ELiBZtXZB+G2XLG63VL8SA6IZYg 0luiBoFtPNlJnS0yc4328bas1gXHEXFnuQiPu4toZ8xc8Ts01UTUxqVlyyp5zreZEhac hiXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ia3hwN03ESEc/LxuAPdDqBeo745gXDh544ZhEb081vI=; b=kNJNL0h/nfoyquOvSgyWSsN8/J7BT9nz39MiTSaA6zlRjq/bMusM+Pounluj2DsRr7 80cI9H928XHv88nSrsj5A6p6zzSUVwVA2MqwXhJ+tEzrlvsV3ypRxYNJq9YrommolP/V UbR8wtdF1JGkne8P4uo1AzmVlF2taIvIrJegSU3P781rqKqJcITI1aMQixudEFMmeT5z WPeV/26xQomQQjqFVwBklnFplCyS6vLXhWHjx513t8rlIgj5Uk26VpL+yYejPZLGtPqO 7pKbuxzd5oXC6PiCMikttTDg3kQBdBgEKY53XkMxTXx2IxOqpePj71Xj0JbECQdwIpCq J9ig== X-Gm-Message-State: AD7BkJJ50vcb2Fq+d6cczWG5Prs6jTJEgVEyTA3soBXGwzlHoftAcbE6HvjjfdC8wzqtjrGtM8KyLpD+NFct7Q== MIME-Version: 1.0 X-Received: by 10.202.221.87 with SMTP id u84mr7270688oig.93.1457414055942; Mon, 07 Mar 2016 21:14:15 -0800 (PST) Sender: dscotese@gmail.com Received: by 10.60.55.71 with HTTP; Mon, 7 Mar 2016 21:14:15 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Mar 2016 21:14:15 -0800 X-Google-Sender-Auth: fUlCV_0I-bUQFS7UG9_98x5R_Sw Message-ID: From: Dave Scotese To: Gregory Maxwell Content-Type: multipart/alternative; boundary=001a113d526c18618d052d82a7dd X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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:59:09 +0000 Cc: Bitcoin Dev 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 05:14:17 -0000 X-List-Received-Date: Tue, 08 Mar 2016 05:14:17 -0000 --001a113d526c18618d052d82a7dd Content-Type: text/plain; charset=UTF-8 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 specific service bits so that if you customize your user-agent string, you can use them for whatever you want"? That way, other clients can choose to follow suit by saying so, or simply recognize the meaning (or lack thereof) of those bits based on the user-agent setting. This relieves future development from the burden of agreeing on where to put what, and allows time and utility to show when such a user-agent-specific service bit should be moved into the protocol section of service bits. PS I am not well versed in the creation of standards, but the reservation of digital real estate for self-identified customization (bits, bytes, or whatever that will never be used by the standard) such as what I'm proposing seems like something that probably has a standard name. "Public provisioning" or something like that? On Mon, Mar 7, 2016 at 12: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 > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy and Meme Racing (in alpha). I'm the webmaster for The Voluntaryist which now accepts Bitcoin. I also code for The Dollar Vigilante . "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto --001a113d526c18618d052d82a7dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think a BIP is a good idea, but rather than making = such a specific=20 proposal as "Let's use bit 4 to indicate communication of thin blo= cks,"=20 how about a more general one like "Let's use bit(s?) 4(-5?) as use= r-agent specific service bits so that if you customize your user-agent stri= ng, you can use them for whatever you want"? That way, other clients c= an choose to follow suit by saying so, or simply recognize the meaning (or = lack thereof) of those bits based on the user-agent setting.=C2=A0 This rel= ieves future development from the burden of agreeing on where to put what, = and allows time and utility to show when such a user-agent-specific service= bit should be moved into the protocol section of service bits.

PS I am not well versed in the creation of standards, but the reserv= ation of digital real estate for self-identified customization (bits, bytes= , or whatever that will never be used by the standard) such as what I'm= proposing seems like something that probably has a standard name.=C2=A0 &q= uot;Public provisioning" or something like that?

On Mon, Mar 7, 2016 at = 12: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 vi= a bitcoin-dev
<bitcoin-dev@li= sts.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



--
I like to provide some work at no charge to prove = my value. Do you need a techie?=C2=A0
I own Litmocracy and Meme Racing (in alpha).
I'm the we= bmaster for The V= oluntaryist which now accepts Bitcoin.
I also code for The Dollar Vigilante.
&= quot;He ought to find it more profitable to play by the rules" - Satos= hi Nakamoto
--001a113d526c18618d052d82a7dd--