Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of
	bitcoinarmory.com designates 157.56.111.115 as permitted
	sender) client-ip=157.56.111.115;
	envelope-from=doug@bitcoinarmory.com;
	helo=na01-bn1-obe.outbound.protection.outlook.com; 
Message-ID: <55652C79.4080305@bitcoinarmory.com>
Date: Tue, 26 May 2015 22:31:21 -0400
From: Douglas Roark <doug@bitcoinarmory.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
References: <CAPg+sBg5TqQ=zjyZ7dp-d1oBGp31Krnix3zyt9suP4-AGbxW=Q@mail.gmail.com>
In-Reply-To: <CAPg+sBg5TqQ=zjyZ7dp-d1oBGp31Krnix3zyt9suP4-AGbxW=Q@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Received-SPF: None (protection.outlook.com: bitcoinarmory.com does not
	designate permitted sender hosts)
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2015 02:31:29.0371 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0601MB1459
X-Spam-Score: -1.5 (-)
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [157.56.111.115 listed in list.dnswl.org]
	-0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1YxRe4-00039o-GI
Subject: Re: [Bitcoin-development] Version bits proposal
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2015 03:04:42 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015/5/26 21:48, Pieter Wuille wrote:
> here is a proposal for how to coordinate future soft-forking
> consensus changes:
> https://gist.github.com/sipa/bf69659f43e763540550
>=20
> It supports multiple parallel changes, as well as changes that get=20
> permanently rejected without obstructing the rollout of others.
>=20
> Feel free to comment. As the gist does not support notifying=20
> participants of new comments, I would suggest using the mailing
> list instead.

Hi Pieter. Thanks for posting the proposal. I think the concept itself
is pretty solid. I know some people have been proposing alternate
methods too. I hope they'll share here, assuming they haven't already.
As is, my comments concern typos and general copy editing.

- - Just speaking in general, I found the BIP to be a bit hard to read.
AFAIK, the basic facts are accurate. I just found myself having to
re-read certain passages two or three times. A little polish wouldn't
hurt. For example, using the "it" pronoun can be confusing, such as
multiple uses in the abstract. Specifying what "it" is (e.g., "The
proposed change relies on...") would really help. In addition, the way
the "W" value is handled seems like it could be improved a bit. I know
the wording is accurate. Seeing 1000 change to 1001 is still a little
weird.
- - In "Multi-stage soft forks," I presume the second sentence should
end as follows: "[...] with additional validation rules that get
enabled one by _one_." Depending on semantics, I'd consider changing
"one by one" to "incremental steps," but that's your call.
- - I found the "High bits" section to be confusing at first. It looks
like you chose to show everything as little endian data, matching
what's actually in the block. My personal preference would be to
represent the data, for readability purposes, as big endian. I doubt
I'm the only one who finds big endian to be much easier to process
mentally.
- - Some sort of legend showing A, I, W, etc. would really help, as
opposed to just running into them as one goes along. Otherwise, the
alphabet soup can be a bit confusing.

Thanks again.

- --=20
- ---
Douglas Roark
Senior Developer
Armory Technologies, Inc.
doug@bitcoinarmory.com
PGP key ID: 92ADC0D7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVZSx5AAoJEGybVGGSrcDXrYEQAOIrsggoZv0LdJHZjPGpEkeb
7ULhO4krZtQmKXjWDP0KnHAsFiyo5EOh1fYFRZz11OCqO4QmteTLPbodZFz47tKp
tIYv5uc0qYhjfo5uLkzxuUky08VE4dUoELfqdbNciC45xHras7Wh/+KXc1a20Fib
TaisWx9aL6VfPf7urM8b6mQ9XMba4YB3e2syAY8AA+qAEEP4DK2V6tuOQJD3kxP2
tbHtJnDvkDoXEY6tnL7fePo9X/IrlXLi8vNWGqPIf/hoiHmdvU+ORwHta7z9YeIO
zi4LRs8n8sYmifY4nt6Wkkc1aoPsmpoXmI3tKgFM2h5bfdg0n3fN3K0nTMWtnR6z
HUq8JhrQkZUP8uunN/23bt94FZolvnHTdL9YuWoyrlJ0gQri5YxV1BAN4hM9oCZy
1SqlSmFRplIFWu45q8/I5duDSphmA4NP2qc59QRjftcGYpNxmzaeSViiCDWzAjI9
qTLZgLTa/nf3TFN8oU8RwquGpwD82/fFo9V+uKdNGj79kdV8WOv4sa9q63OTVimJ
w+r4l1gDZYyToe0heKtV2kL9Tt4HTn23bj7EvU+98uaKEpfWSP8a3BN9mPR7ork/
lNRGEGQ0tvkeDUzKy9IHuAjXo2XkKctbBRJwZJCGc5WW2sN0HdSu/GFPXrOOLf0J
JXqeKpfaS0UriFXkxVHO
=3D8uNL
-----END PGP SIGNATURE-----