From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YxXjz-00066g-2S for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 09:35:11 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.181 as permitted sender) client-ip=209.85.220.181; envelope-from=tier.nolan@gmail.com; helo=mail-qk0-f181.google.com; Received: from mail-qk0-f181.google.com ([209.85.220.181]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YxXjw-0003VZ-UL for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 09:35:11 +0000 Received: by qkx62 with SMTP id 62so2041257qkx.3 for ; Wed, 27 May 2015 02:35:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.33.6 with SMTP id h6mr62609843qkh.99.1432719303566; Wed, 27 May 2015 02:35:03 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Wed, 27 May 2015 02:35:03 -0700 (PDT) In-Reply-To: References: <201505270346.17014.luke@dashjr.org> Date: Wed, 27 May 2015 10:35:03 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1144bc4226ea1c05170cf5e5 X-Spam-Score: 3.3 (+++) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (tier.nolan[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 2.7 MALFORMED_FREEMAIL Bad headers on message from free email service X-Headers-End: 1YxXjw-0003VZ-UL 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 09:35:11 -0000 --001a1144bc4226ea1c05170cf5e5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think it would be better to have the deadlines set as block counts. That eliminates the need to use the median time mechanism. The deadline could be matched to a "start-line". The definition would then be something like BIP 105 Start block: 325000 End block: 350000 Activation: 750 of 1000 Implication: 950 of 1000 Bit: 9 This would allow creation of a simple table of known BIPs. It also keeps multiple users of the bit as strictly separate. The alternative to the start time is that it is set equal to the deadline or implication time of the previous user of the bit. Was the intention to change the 95% rule. You need 750 of the last 1000 to activate and then must wait at least 1000 for implication? On Wed, May 27, 2015 at 4:51 AM, Jorge Tim=C3=B3n wrote: > It would also help to see the actual code changes required, which I'm sur= e > 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 change= s >> 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 ca= n >> 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 indicatin= g: >> - 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 >> > > > -------------------------------------------------------------------------= ----- > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --001a1144bc4226ea1c05170cf5e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it would be bet= ter to have the deadlines set as block counts.=C2=A0 That eliminates the ne= ed to use the median time mechanism.

The deadline c= ould be matched to a "start-line".=C2=A0 The definition would the= n be something like

BIP 105
Start block: 325000
End block: 350000
Activation: 750 of 1000
Implication: 950 = of 1000
Bit: 9

This would allow creation of a simple table = of known BIPs.=C2=A0 It also keeps multiple users of the bit as strictly se= parate.

The alternative to the start time is that it is set eq= ual to the deadline or implication time of the previous user of the bit.

Was the intention to change the 95% rule.=C2= =A0 You need 750 of the last 1000 to activate and then must wait at least 1= 000 for implication?


On Wed, May 27, 2015 at 4:5= 1 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:

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

On May 27, 2015 5:47 AM, "Luke Dashjr"= <luke@dashjr.org> wrote:
On Wed= nesday, May 27, 2015 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-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

-----------------------------------------------------------= -------------------

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


--001a1144bc4226ea1c05170cf5e5--