{"type":"rich","version":"1.0","author_name":"npub1ncnj8arudstdxzfhxk7k4nwgkrw3hyw8sgt0wqqmm5hh2c4knmgs2lqt2n","author_url":"https://nostr.ae/npub1ncnj8arudstdxzfhxk7k4nwgkrw3hyw8sgt0wqqmm5hh2c4knmgs2lqt2n","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-12-11\n📝 Original message:I want to resurrect this thread from August/September because it seems like\na significant improvement for light clients at very little cost. From the\nmailing list, it seems like this got stalled in determining how many more\nbytes could be save in addition to the prev_block.\n\nThe ideas I've gathered from Greg Maxwell's forwarded email are:\n\n1. Omit nBits altogether and have the receiving node determine it from\nchain context.\n2. Include nBits only on headers with a height that is a multiple of 2016\nsince it does not change in between.\n3. Compress nTime to two bytes by using the bounds on allowed values from\nthe consensus rules.\n\nI propose just moving ahead with only the exclusion of the prev_block, as\nIMO the other savings are not worth the added complexity.\n\nFirstly, I don't like the idea of making the net header encoding dependent\non the specific header validation rules that Bitcoin uses (eg. the fact\nthat difficulty is only recalculated every 2016 blocks). This would be\ncoupling together the two layers, breaking net compatibility for some alts,\nand possibly making consensus rule changes even more difficult for a\nsavings with insufficient benefit. So if you buy that argument, I'm not in\nfavor of #2 or #3.\n\nOption 1 is still viable, though it has some downsides. The implementation\nleaks into the validation code, whereas calculating prev_block can occur\njust at the net layer (see implementation below). Also, nodes would now be\n*required* to sync the header chain from the genesis block, whereas they\nhad the option of starting from some checkpoint before.\n\nSo switching gears, I'd like to ask what the best way to actually implement\nthis change is. Solutions I can think of are:\n\n1. New headers command name like \"cmpctheaders\" or \"headersv2\".\n2. Change serialization of existing headers message in a new protocol\nversion.\n3. Change serialization of existing headers message with new service bit.\n\nI wrote up some proof-of-concept implementations in Core a) just omitting\nprev_block\n\u003chttps://github.com/bitcoin/bitcoin/compare/master...jimpo:compact-headers\u003e\nand b) omitting nBits as well\n\u003chttps://github.com/bitcoin/bitcoin/compare/master...jimpo:compact-headers-difficulty\u003e.\nIf people think a) is reasonable, I'll write up a BIP.\n\n\n\u003e Hi everyone, the Bitcoin headers are probably the most condensed and\n\u003e important piece of data in the world, their demand is expected to grow.\n\u003e When sending a stream of continuous block headers, a common case in IBD and\n\u003e in disconnected clients, I think there is a possible optimization of the\n\u003e transmitted data: The headers after the first could avoid transmitting the\n\u003e previous hash cause the receiver could compute it by double hashing the\n\u003e previous header (an operation he needs to do anyway to verify PoW). In a\n\u003e long stream, for example 2016 headers, the savings in bandwidth are about\n\u003e 32/80 ~= 40% without compressed headers 2016*80=161280 bytes with\n\u003e compressed headers 80+2015*48=96800 bytes What do you think? In\n\u003e OpenTimestamps calendars we are going to use this compression to give\n\u003e lite-client a reasonable secure proofs (a full node give higher security\n\u003e but isn't feasible in all situations, for example for in-browser\n\u003e verification) To speed up sync of a new client Electrum starts with the\n\u003e download of a file \u003chttps://headers.electrum.org/blockchain_headers\u003e\n\u003e ~36MB containing the first 477637 headers. For this kind of clients could\n\u003e be useful a common http API with fixed position chunks to leverage http\n\u003e caching. For example /headers/2016/0 returns the headers from the genesis\n\u003e to the 2015 header included while /headers/2016/1 gives the headers from\n\u003e the 2016th to the 4031. Other endpoints could have chunks of 20160 blocks\n\u003e or 201600 such that with about 10 http requests a client could fast sync\n\u003e the headers\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171211/86e7642f/attachment.html\u003e"}