From: <jl2012@xbt.hk>
To: "'Gavin Andresen'" <gavinandresen@gmail.com>,
	"'Gregory Maxwell'" <greg@xiph.org>
References: <f225318eddd0aadc71861f988f2f4674@xbt.hk>	<CAAS2fgT_f858GFVY9RAN1skd8_9Q_T1ZFoUXCQiC3o3B+z4oXw@mail.gmail.com>
	<CABsx9T1AdWPAtGHkhMAGtnWtthE+oienUBm0iXEfUG05S6ko-Q@mail.gmail.com>
In-Reply-To: <CABsx9T1AdWPAtGHkhMAGtnWtthE+oienUBm0iXEfUG05S6ko-Q@mail.gmail.com>
Date: Mon, 8 Feb 2016 03:27:48 +0800
Message-ID: <232901d161dd$a35f8d30$ea1ea790$@xbt.hk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHbMrTCecyH04NftjxoC3dSKJ6yWAIfgCv5AT+pZiae8lanIA==
Content-Language: en-hk
Cc: 'Bitcoin Dev' <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork bit BIP
Precedence: list

From: Gavin Andresen [mailto:gavinandresen@gmail.com]=20
Sent: Friday, 5 February, 2016 06:16
To: Gregory Maxwell <greg@xiph.org>
Cc: jl2012 <jl2012@xbt.hk>; Bitcoin Dev =
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork bit BIP

>It is always possible I'm being dense, but I still don't understand how =
this proposal makes a chain-forking situation better for anybody.

>If there are SPV clients that don't pay attention to versions in block =
headers, then setting the block version negative doesn't directly help =
them, they will ignore it in any case.

It is unfortunate SPV clients are not following that. However, they =
SHOULD follow that. It becomes a self fulfilling prophecy if we decide =
not to do that if SPV are not following that.

>If the worry is full nodes that are not upgraded, then a block with a =
negative version number will, indeed, fork them off the the chain, in =
exactly the same way a block with new hard-forking consensus rules =
would. And with the same consequences (if there is any hashpower not =
paying attention, then a worthless minority chain might continue on with =
the old rules).

It will distinguish between a planned hardfork and an accidental =
hardfork, and full nodes may react differently. Particularly, a planned =
unknown hardfork is a strong indication that the original chain has =
become economic minority and the non-upgraded full node should stop =
accepting incoming tx immediately.

>If the worry is not-upgraded SPV clients connecting to the old, =
not-upgraded full nodes, I don't see how this proposed BIP helps.

Same for not-upgraded full nodes following not-upgraded full nodes. =
Anyway, the header with enough PoW should still be propagated.

>I think a much better idea than this proposed BIP would be a BIP that =
recommends that SPV clients to pay attention to block version numbers in =
the headers that they download, and warn if there is a soft OR hard fork =
that they don't know about.

Normal version number only suggests softforks, which is usually not a =
concern for SPV clients. An unknown hardfork is a completely different =
story as the values of the forks are completely unknown.

>It is also a very good idea for SPV clients to pay attention to =
timestamps in the block headers that the receive, and to warn if blocks =
were generated either much slower or faster than statistically likely. =
Doing that (as Bitcoin Core already does) will mitigate Sybil attacks in =
general.

Yes, they should.

--=20
--
Gavin Andresen