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 D598C127B for ; Wed, 30 Dec 2015 19:00:45 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mcelrath.org (moya.mcelrath.org [50.31.3.130]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7256F184 for ; Wed, 30 Dec 2015 19:00:45 +0000 (UTC) Received: from mcelrath.org (localhost [127.0.0.1]) by mcelrath.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id tBUJ0ix0019062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Dec 2015 19:00:44 GMT Received: (from mcelrath@localhost) by mcelrath.org (8.14.3/8.14.3/Submit) id tBUJ0hkR019060; Wed, 30 Dec 2015 19:00:43 GMT X-Authentication-Warning: mcelrath.org: mcelrath set sender to bob_bitcoin@mcelrath.org using -f Date: Wed, 30 Dec 2015 19:00:43 +0000 From: Bob McElrath To: joe2015@openmailbox.org Message-ID: <20151230190043.GJ18200@mcelrath.org> References: <1bf64a5b514d57ca37744ae5f5238149@openmailbox.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 19:00:45 -0000 joe2015--- via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote: > That's the whole point. After a conventional hardfork everyone > needs to upgrade, but there is no way to force users to upgrade. A > user who is simply unaware of the fork, or disagrees with the fork, > uses the old client and the currency splits. > > Under this proposal old clients effectively enter "zombie" mode, > forcing users to upgrade. This is a very complex way to enter zombie mode. A simpler way is to track valid PoW chains by examining only the header, that are rejected for other reasons. Once a chain is seen to be 6 or more blocks ahead of my chain tip, we should enter "zombie mode" and refuse to mine or relay, and alert the operator, because we don't know what we're doing and we're out of date. This way doesn't require any modifications to block structure at all. -- Cheers, Bob McElrath "For every complex problem, there is a solution that is simple, neat, and wrong." -- H. L. Mencken