From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5B1A971F for ; 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 ; 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: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Johnson Lau , Bitcoin Protocol Discussion , Johnson Lau via bitcoin-dev , bitcoin-dev From: Matt Corallo Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > >), 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 > ) 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 > )= =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