On Mon, Aug 28, 2017 at 05:12:15PM +0000, Gregory Maxwell via bitcoin-dev wrote:
> You are leaving a lot of bytes on the table.
> 
> 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).
> 
> 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 work,
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 with
inaccurate block times. In particular, setting a block time backwards is
something that miners can do, particularly with majority hashing power, which
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 weak
security with compact SPV proofs; we'd need a lot more analysis to understand
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.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org