{"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:On Mon, Dec 11, 2017 at 1:04 PM, Gregory Maxwell \u003cgreg at xiph.org\u003e wrote:\n\n\u003e On Mon, Dec 11, 2017 at 8:40 PM, Jim Posen via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e Firstly, I don't like the idea of making the net header encoding\n\u003e dependent\n\u003e \u003e on the specific header validation rules that Bitcoin uses (eg. the fact\n\u003e that\n\u003e \u003e difficulty is only recalculated every 2016 blocks). This would be\n\u003e coupling\n\u003e\n\u003e In the last proposal I recall writing up, there was a one byte flag on\n\u003e each header to indicate what was included.\n\u003e\n\u003e\nIs there a link somewhere to that proposal? The only thing I could find was\nyour forwarded email\n\u003chttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014904.html\u003e\non\nthis thread.\n\n\n\u003e Nbits _never_ needs to be sent even with other consensus rules because\n\u003e its more or less necessarily a strict function of the prior headers.\n\u003e This still holds in every clone of Bitcoin I'm aware of; sending it\n\u003e with the first header in a group probably makes sense so it can be\n\u003e checked independently.\n\u003e\n\u003e \u003e with insufficient benefit.\n\u003e\n\u003e another \u003e18% reduction in size beyond the removal of prev. is not\n\u003e insubstantial by any means.  I don't think it should lightly be\n\u003e ignored.\n\u003e\n\u003e\nOmitting nBits entirely seems reasonable, I wrote up a possible\nimplementation here\n\u003chttps://github.com/bitcoin/bitcoin/compare/master...jimpo:compact-headers-difficulty\u003e.\nThe downside is that it is more complex because it leaks into the\nvalidation code. The extra 4 byte savings is certainly nice though.\n\n\n\u003e Prev omission itself is not, sadly, magically compatible:  I am quite\n\u003e confident that if there is a bitcoin hardfork it would recover the\n\u003e nbits/4-guarenteed always-zero bits of prev to use as extra nonce for\n\u003e miners. This has been proposed many times, implemented at least once,\n\u003e and the current requirement for mining infrastructure to reach inside\n\u003e the coinbase txn to increment a nonce has been a reliable source of\n\u003e failures.  So I think we'd want to have the encoding able to encode\n\u003e leading prev bits.\n\u003e\n\u003e Many altcoins also change the header structures. If the better thing\n\u003e is altcoin incompatible, we should still do it. Doing otherwise would\n\u003e competitively hobble Bitcoin especially considering the frequent\n\u003e recklessly incompetent moves made by various altcoins and the near\n\u003e total lack of useful novel development we've seen come out of the\n\u003e clones.\n\u003e\n\u003e Probably the most important change in a new header message wouldn't be\n\u003e the encoding, but it would be changing the fetching mechanism so that\n\u003e header sets could be pulled in parallel, etc.\n\u003e\n\u003e I would rather not change the serialization of existing messages,\n\u003e nodes are going to have to support speaking both messages for a long\n\u003e time, and I think we already want a different protocol flow for\n\u003e headers fetching in any case.\n\u003e\n\nCan you elaborate on how parallel header fetching might work? getheaders\nrequests could probably already be pipelined, where the node requests the\nnext 2,000 headers before processing the current batch (though would make\nsense to check that they are all above min difficulty first).\n\nI'm open to more ideas on how to optimize the header download or design the\nserialization format to be more flexible, but I'm concerned that we forgo a\n40-45% bandwidth savings on the current protocol for a long time because\nsomething better might be possible later on or there might be a hard fork\nthat at some point requires another upgrade. I do recognize that supporting\nmultiple serialization formats simultaneously adds code complexity, but in\nthis case the change seems simple enough to me that the tradeoff is worth\nit.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171211/995788a9/attachment-0001.html\u003e"}