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
signature.asc
Description: Digital signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
