Date: Mon, 4 Sep 2017 10:06:44 -0400
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <greg@xiph.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20170904140644.GF1276@fedora-23-dvm>
References: <CADabwBBrrPM2f9h_sgxY12tg=FUvKKCcnCC8ixnct93YL9uEFQ@mail.gmail.com>
	<CAAS2fgS3uG=4vgFuObPKA_5MstoGm4AabO=60fhV3EU_0dvejg@mail.gmail.com>
	<CAAS2fgRvSZm-NVLU++0WmWoaYbpX1R0Fqmv_Jf7a_RsqzXfOog@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="Dzs2zDY0zgkG72+7"
Content-Disposition: inline
In-Reply-To: <CAAS2fgRvSZm-NVLU++0WmWoaYbpX1R0Fqmv_Jf7a_RsqzXfOog@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [bitcoin-dev] Fwd:  "Compressed" headers stream
Precedence: list


--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--