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 A48B3CEB for ; Fri, 30 Mar 2018 06:14:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 315F0163 for ; Fri, 30 Mar 2018 06:14:27 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1f1nIt-0006xd-MZ; Fri, 30 Mar 2018 16:14:25 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Fri, 30 Mar 2018 16:14:18 +1000 Date: Fri, 30 Mar 2018 16:14:18 +1000 From: Anthony Towns To: Jim Posen , Bitcoin Protocol Discussion Message-ID: <20180330061418.GA6017@erisian.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY 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] Optimized Header Sync 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, 30 Mar 2018 06:14:27 -0000 On Thu, Mar 29, 2018 at 05:50:30PM -0700, Jim Posen via bitcoin-dev wrote: > Taken a step further though, I'm really interested in treating the checkpoints > as commitments to chain work [...] In that case, shouldn't the checkpoints just be every 2016 blocks and include the corresponding bits value for that set of blocks? That way every node commits to (approximately) how much work their entire chain has by sending something like 10kB of data (currently), and you could verify the deltas in each node's chain's target by downloading the 2016 headers between those checkpoints (~80kB with the proposed compact encoding?) and checking the timestamps and proof of work match both the old target and the new target from adjacent checkpoints. (That probably still works fine even if there's a hardfork that allows difficulty to adjust more frequently: a bits value at block n*2016 will still enforce *some* lower limit on how much work blocks n*2016+{1..2016} will have to contribute; so will still allow you to estimate how much work will have been done, it may just be less precise than the estimate you could generate now) Cheers, aj