From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YxSN2-0008Sx-EU for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 03:51:08 +0000 Received: from mail-wi0-f176.google.com ([209.85.212.176]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YxSN1-0001wn-0g for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 03:51:08 +0000 Received: by wifw1 with SMTP id w1so6148992wif.0 for ; Tue, 26 May 2015 20:51:00 -0700 (PDT) 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:cc:content-type; bh=MeRZas/8/l2++U5TG1YKeza379OpekX92rELk6Ur//w=; b=kaMI/9aDi4HQ3eoSG6Gb+FkrX2krchPuAm1FQ0EohKm+kdh1cc3ofdu6yWU8pF3AkS cTlJRr8kuozX4Jia4U8qeSJcQfPCC2pUPWj4U1/jxQUZm6ghBx209ZceH+/XXmph/q60 6D5Qf4G2Nf39Ei/yVJBvliiaW90WhE07lgS4S+mXIKF/QnL8l7AU5rq9AfgBzoCPBxsc 8LtldyNXzHryKSyIhxY5GBfCEPkcEhCUgEF5PgkOXxXnzjkig6UC1GcubR6CFP9KuzwS DyD/apEDM5zGAhqm+LzmaeOdQRMYWEADAJl4zj9tfWIMJGyC1yKWVBxK0XH0XQcyD/m4 miew== X-Gm-Message-State: ALoCoQlB4DYG5UcErgUfMeTIlL1o5xystYLse68jUbal8DrajzpJaPzNbg0ODALwh5FwcABUXB9g MIME-Version: 1.0 X-Received: by 10.180.188.4 with SMTP id fw4mr46135972wic.7.1432698660766; Tue, 26 May 2015 20:51:00 -0700 (PDT) Received: by 10.194.127.97 with HTTP; Tue, 26 May 2015 20:51:00 -0700 (PDT) Received: by 10.194.127.97 with HTTP; Tue, 26 May 2015 20:51:00 -0700 (PDT) In-Reply-To: <201505270346.17014.luke@dashjr.org> References: <201505270346.17014.luke@dashjr.org> Date: Wed, 27 May 2015 05:51:00 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Luke-Jr Content-Type: multipart/alternative; boundary=001a11c38216bedbcf0517082697 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1YxSN1-0001wn-0g Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Version bits proposal X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 03:51:08 -0000 --001a11c38216bedbcf0517082697 Content-Type: text/plain; charset=UTF-8 It would also help to see the actual code changes required, which I'm sure will be much shorter than the explanation itself. On May 27, 2015 5:47 AM, "Luke Dashjr" wrote: > On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote: > > Feel free to comment. As the gist does not support notifying participants > > of new comments, I would suggest using the mailing list instead. > > I suggest adding a section describing how this interacts with and changes > GBT. > > Currently, the client tells the server what the highest block version it > supports is, and the server indicates a block version to use in its > template, > as well as optional instructions for the client to forcefully use this > version > despite its own maximum version number. Making the version a bitfield > contradicts the increment-only assumption of this design, and since GBT > clients are not aware of overall network consensus state, reused bits can > easily become confused. I suggest, therefore, that GBT clients should > indicate > (instead of a maximum supported version number) a list of softforks by > identifier keyword, and the GBT server respond with a template indicating: > - An object of softfork keywords to bit values, that the server will > accept. > - The version number, as presently conveyed, indicating the preferred > softfork > flags. > > Does this sound reasonable, and/or am I missing anything else? > > Luke > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a11c38216bedbcf0517082697 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It would also help to see the actual code changes required, = which I'm sure will be much shorter than the explanation itself.

On May 27, 2015 5:47 AM, "Luke Dashjr"= <luke@dashjr.org> wrote:
On Wednesday, May 27, 20= 15 1:48:05 AM Pieter Wuille wrote:
> Feel free to comment. As the gist does not support notifying participa= nts
> of new comments, I would suggest using the mailing list instead.

I suggest adding a section describing how this interacts with and changes G= BT.

Currently, the client tells the server what the highest block version it supports is, and the server indicates a block version to use in its templat= e,
as well as optional instructions for the client to forcefully use this vers= ion
despite its own maximum version number. Making the version a bitfield
contradicts the increment-only assumption of this design, and since GBT
clients are not aware of overall network consensus state, reused bits can easily become confused. I suggest, therefore, that GBT clients should indic= ate
(instead of a maximum supported version number) a list of softforks by
identifier keyword, and the GBT server respond with a template indicating:<= br> - An object of softfork keywords to bit values, that the server will accept= .
- The version number, as presently conveyed, indicating the preferred softf= ork
flags.

Does this sound reasonable, and/or am I missing anything else?

Luke

---------------------------------------------------------------------------= ---
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
--001a11c38216bedbcf0517082697--