Re: [bitcoin-dev] Fwd: "Compressed" headers stream
On Mon, Aug 28, 2017 at 05:12:15PM +, 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
Re: [bitcoin-dev] Fwd: "Compressed" headers stream
2017-08-28 19:12 GMT+02:00 Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > > 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). > ... and I guess the nonce can be arbitrarily truncated as well, just brute force the missing bits :-P. > 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. > I think that my blog post on compact spv proofs can be helpful also. It tries to make the pretty compact formulations in the sidechains paper a bit more graspable by normal people. http://popeller.io/index.php/2016/09/15/compact-spv-proofs/ Kalle ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Fwd: "Compressed" headers stream
On Mon, Aug 28, 2017 at 3:50 PM, Riccardo Casatta via bitcoin-dev wrote: > Hi everyone, > > the Bitcoin headers are probably the most condensed and important piece of > data in the world, their demand is expected to grow. > > When sending a stream of continuous block headers, a common case in IBD and > in disconnected clients, I think there is a possible optimization of the > transmitted data: > The headers after the first could avoid transmitting the previous hash cause > the receiver could compute it by double hashing the previous header (an > operation he needs to do anyway to verify PoW). > In a long stream, for example 2016 headers, the savings in bandwidth are > about 32/80 ~= 40% > without compressed headers 2016*80=161280 bytes > with compressed headers 80+2015*48=96800 bytes > > What do you think? 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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
