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 C5A7E8D9 for ; Mon, 4 Sep 2017 18:42:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149082.authsmtp.co.uk (outmail149082.authsmtp.co.uk [62.13.149.82]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2C6CF12A for ; Mon, 4 Sep 2017 18:42:31 +0000 (UTC) Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v84IgT2D063579; Mon, 4 Sep 2017 19:42:29 +0100 (BST) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v84IgRlM025367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Sep 2017 19:42:28 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id C28D940297; Mon, 4 Sep 2017 18:42:25 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 0FDF122279; Mon, 4 Sep 2017 10:06:44 -0400 (EDT) Date: Mon, 4 Sep 2017 10:06:44 -0400 From: Peter Todd To: Gregory Maxwell , Bitcoin Protocol Discussion Message-ID: <20170904140644.GF1276@fedora-23-dvm> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Dzs2zDY0zgkG72+7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: cd5649f1-91a0-11e7-b1e8-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgYUC1AEAgsB AmEbWl1eVF97W2s7 bghPaBtcak9QXgdq T0pMXVMcUg1seEtj WmMeUBxxcQIIfnZy bQgxCnVdWE0sdFt0 Qx9UCGwHMGB9OmFK WF1YdwJRcQRMLU5E Y1gxNiYHcQ5VPz4z GA41ejw8IwAXBjtZ EElFZ3kVRF4REyUn ShxIVTUiFEEIXT57 NAA8J1cZdAAA X-Authentic-SMTP: 61633532353630.1038:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=0.4 required=5.0 tests=DATE_IN_PAST_03_06, RCVD_IN_DNSWL_LOW autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Fwd: "Compressed" headers stream 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: Mon, 04 Sep 2017 18:42:32 -0000 --Dzs2zDY0zgkG72+7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 28, 2017 at 05:12:15PM +0000, Gregory Maxwell via bitcoin-dev w= rote: > You are leaving a lot of bytes on the table. >=20 > The bits field can only change every 2016 blocks (4 bytes per header), > the timestamp can not be less than the median of the last 11 and is > usually only a small amount over the last one (saves 2 bytes per > header), the block version is usually one of the last few (save 3 > bytes per header). >=20 > But all these things improvements are just a constant factor. I think > you want the compact SPV proofs described in the appendix of the > sidechains whitepaper which creates log scaling proofs. Note that I'm already planning on OpenTimestamps having infrastructure for trusted validity attestations; log scaling proofs alone only prove total wo= rk, not validity. Timestamping has all kinds of very dubious security properties when done via proof-of-work, due to various ways that miners can get away w= ith inaccurate block times. In particular, setting a block time backwards is something that miners can do, particularly with majority hashing power, whi= ch is the exact thing we're trying to prevent in a timestamp proof. This all makes me dubious about risking further weakening of this already w= eak security with compact SPV proofs; we'd need a lot more analysis to understa= nd what we're risking. Also note that we can ship a known-good sum-merkle-tree tip hash with the software, which further reduces initial download bandwidth needed to get the block headers on top of this obviously safe eliding of redundant hashes. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --Dzs2zDY0zgkG72+7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZrV3xAAoJECSBQD2l8JH73QwIAJSCv3J1tyRj3LukwE6GVXSb KPKPT8JNtf/9YR7tvQbOiyXtRQzcYYPHhG43Lf3ZJ+gsDjSXjGx3xo5RM4tAIn/F smQNSMzOonGEVWARPTJVqHw2VwPFsw9ckQ7IsDr+N0IejhQv6cqdgcnnE+/BdI/L XfzBB5inxSvkmsvdfRiFn5sjCPFwfVYFXzp9LXJgv24G9FXAbqCD4I3HvMEeYMWO OoNt3R7rHgWeE2hPPSMik0hjGiRnUdzai9TgwoOgMhu8H7Ce74fzdwrUyfq5CejI pKPOuVvWhCCpRiPdVzsJA9PZ37AEGjRvW7PShJDlv9Kew9uhPbYr0eVdvF9flHY= =Poq8 -----END PGP SIGNATURE----- --Dzs2zDY0zgkG72+7--