path: root/be/3bde8ab82d9bbad60597436630b4aa53f57627

Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5B1A971F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Apr 2017 10:14:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 556D714F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Apr 2017 10:14:14 +0000 (UTC)
Received: from [10.10.140.216] (c187-247.i02-7.onvol.net [213.165.187.247])
	by mail.bluematt.me (Postfix) with ESMTPSA id ADEFA133C80;
	Fri,  7 Apr 2017 10:14:11 +0000 (UTC)
Date: Fri, 07 Apr 2017 10:14:07 +0000
In-Reply-To: <CB65A263-FFD5-4F9A-B14E-31F44EEC05B9@xbt.hk>
References: <CB65A263-FFD5-4F9A-B14E-31F44EEC05B9@xbt.hk>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: Johnson Lau <jl2012@xbt.hk>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Johnson Lau via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <A6D5BF88-F5C0-41FC-BD41-CA5493FD5180@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] A different approach to define and
	understand	softforks and hardforks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Apr 2017 10:14:15 -0000

Random misreadings of your post aside (maybe it's time to moderate this lis=
t a bit more again), I think this is a reasonable model, and certainly more=
 terminology/understanding is useful, given I and many others have been mak=
ing arguments based on these differences=2E

One thing you may wish to further include may be that many soft forks do n=
ot require any miner upgrade at all due to standardness rules=2E Eg OP_CSV =
and SegWit both only require miners upgrade if they wish to receive the add=
itional fees from new transactions using these features=2E

Matt

On April 5, 2017 12:28:07 PM GMT+02:00, Johnson Lau via bitcoin-dev <bitco=
in-dev@lists=2Elinuxfoundation=2Eorg> wrote:
>Softforks and hardforks are usually defined in terms of block validity
>(BIP99): making valid blocks invalid is a softfork, making invalid
>blocks valid is a hardfork, and SFs are usually considered as less
>disruptive as it is considered to be =E2=80=9Copt-in=E2=80=9D=2E However,=
 as shown below
>this technical definition could be very misleading=2E Here I=E2=80=99m tr=
ying to
>redefine the terminology in terms of software upgrade necessity and
>difficulty=2E
>
>Softforks are defined as consensus rule changes that non-upgraded
>software will be able to function exactly as usual, as if the rule
>changes have never happened
>
>Hardforks are defined as consensus rule changes that non-upgraded
>software will cease to function or be severely handicapped
>
>SFs and HFs under this definitions is a continuum, which I call it
>=E2=80=9Chardfork-ness=E2=80=9D=2E A pure softfork has no hardfork-ness=
=2E
>
>*Mining node
>
>Under this definitions, for miners, any trivial consensus rule changes
>is somewhat a hardfork, as miners can=E2=80=99t reliably use non-upgraded
>software to create blocks=2E However, there is still 3 levels of
>=E2=80=9Chardfork-ness=E2=80=9D, for example:
>
>1=2E Those with lower hardfork-ness would be the SFs that miners do not
>need to upgrade their software at all=2E Instead, the minimum requirement
>is to setup a boarder node with latest rules to make sure they won=E2=80=
=99t
>mine on top of an invalid block=2E Examples include CSV and Segwit
>
>2=2E Some SFs have higher hardfork-ness, for example BIP65 and BIP66=2E T=
he
>minimum actions needed include setting up a boarder node and change the
>block version=2E BIP34 has even higher hardfork-ness as more actions are
>needed to follow the new consensus=2E
>
>3=2E Anything else, ranging from simple HFs like BIP102 to complete HFs
>like spoonnet, or soft-hardfork like forcenet, have the highest
>hardfork-ness=2E In these cases, boarder nodes are completely useless=2E
>Miners have to upgrade their servers in order to stay with the
>consensus=2E
>
>*Non-mining full node
>
>Similarly, in terms of non-mining full node, as the main function is to
>fully-validate all applicable rules on the network, any consensus
>change is a hardfork for this particular function=2E However, a technical
>SF would have much lower hardfork-ness than a HF, as a border node is
>everything needed in a SF=2E Just consider a company has some
>difficult-to-upgrade software that depends on Bitcoin Core 0=2E8=2E Using=
 a
>0=2E13=2E1+ boarder node will make sure they will always follow the lates=
t
>rules=2E In case of a HF, they have no choice but to upgrade the backend
>system=2E
>
>So we may use the costs of running a boarder node to further define the
>hardfork-ness of SFs, and it comes to the additional resources needed:
>
>1=2E Things like BIP34, 65, 66, and CSV involves trivial resources use so
>they have lowest hardfork-ness=2E
>
>2=2E Segwit is higher because of increased block size=2E
>
>3=2E Extension block has very high hardfork-ness as people may not have
>enough resources to run a boarder node=2E
>
>* Fully validating wallets
>
>In terms of the wallet function in full node, without considering the
>issues of validation, the hardfork-ness could be ranked as below:
>
>1=2E BIP34, 65, 66, CSV, segwit all have no hardfork-ness for wallets=2E
>Non-upgraded wallets will work exactly in the same way as before=2E Users
>won=E2=80=99t notice any change at all=2E (In some cases they may not see=
 a new
>tx until it has 1 confirmation, but this is a mild issue and 0-conf is
>unsafe anyway)
>
>2=2E Extension block, as presented in my January post (
>https://lists=2Elinuxfoundation=2Eorg/pipermail/bitcoin-dev/2017-January/=
013490=2Ehtml
><https://lists=2Elinuxfoundation=2Eorg/pipermail/bitcoin-dev/2017-January=
/013490=2Ehtml>
>), has higher hardfork-ness, as users of legacy wallets may find it
>difficult to receive payments from upgraded wallet=2E However, once they
>got paid, the user experience is same as before
>
>3=2E Another extension block proposal (
>https://github=2Ecom/tothemoon-org/extension-blocks
><https://github=2Ecom/tothemoon-org/extension-blocks> ) has very high
>hardfork-ness for wallets, as legacy wallets will frequently and
>suddenly find that incoming and outgoing txs becoming invalid, and need
>to sign the invalidated txs again, even no one is trying to double
>spend=2E
>
>4=2E Hardfork rule changes have highest hardfork-ness for full node
>wallets
>
>I=E2=80=99ll explain the issues with extension block in a separate post i=
n
>details
>
>* Real SPV wallet
>
>The SPV wallets as proposed by Satoshi should have the ability to fully
>validate the rules when needed, so they could be somehow seen as fully
>validating wallets=2E So far, real SPV wallet is just vapourware=2E
>
>* Fake SPV wallet, aka light wallet
>
>All the so-called SPV wallets we have today are fake SPV according to
>whitepaper definition=2E Since they validate nothing, the hardfork-ness
>profile is very different:
>
>1=2E BIP34, 65, 66, CSV, segwit has no hardfork-ness for light wallets=2E
>Block size HF proposals (BIP10x) and Bitcoin Unlimited also have no
>hardfork-ness (superficially, but not philosophically)=2E Along the same
>line, even an inflation hardfork has no hardfork-ness for light
>wallets=2E
>
>2=2E Extension block has the same kind of hardfork-ness issue as I
>mentioned=2E
>
>3=2E HFs that deliberately breaks light wallets, such as spoonnet, is a
>complete hardfork=2E
>
>While some people try to leverage weakness of light wallets, the
>inability to validate any important rules like block size, double
>spending, and inflation is a serious vulnerability=2E
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>Before I finish, I=E2=80=99d also like to analyse some other interesting =
cases=2E
>
>1=2E Soft-hardfork: which requires miners to mine empty blocks with 0
>reward, and put the tx merkle tree in the legacy coinbase (e=2Eg=2E
>https://github=2Ecom/luke-jr/bips/blob/bip-mmhf/bip-mmhf=2Emediawiki
><https://github=2Ecom/luke-jr/bips/blob/bip-mmhf/bip-mmhf=2Emediawiki> )=
=2E
>This allows most hardfork-ing changes including block size and
>inflation=2E In terms of block validity this is a softfork=2E But with th=
e
>definition I presented, soft-hardforks are clearly hardforks for every
>practical purposes=2E
>
>2=2E On-chain KYC, blacklist, account freezing: technically softforks,
>but all are very disruptive hardforks in terms of user experience=2E
>
>3=2E Lightning network and side chains are not consensus rule changes,
>and they could provide new features without any hardfork-ness=2E