{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-12-11\n📝 Original message:On Mon, Dec 11, 2017 at 8:40 PM, Jim Posen via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Firstly, I don't like the idea of making the net header encoding dependent\n\u003e on the specific header validation rules that Bitcoin uses (eg. the fact that\n\u003e difficulty is only recalculated every 2016 blocks). This would be coupling\n\nIn the last proposal I recall writing up, there was a one byte flag on\neach header to indicate what was included.\n\nNbits _never_ needs to be sent even with other consensus rules because\nits more or less necessarily a strict function of the prior headers.\nThis still holds in every clone of Bitcoin I'm aware of; sending it\nwith the first header in a group probably makes sense so it can be\nchecked independently.\n\n\u003e with insufficient benefit.\n\nanother \u003e18% reduction in size beyond the removal of prev. is not\ninsubstantial by any means.  I don't think it should lightly be\nignored.\n\nPrev omission itself is not, sadly, magically compatible:  I am quite\nconfident that if there is a bitcoin hardfork it would recover the\nnbits/4-guarenteed always-zero bits of prev to use as extra nonce for\nminers. This has been proposed many times, implemented at least once,\nand the current requirement for mining infrastructure to reach inside\nthe coinbase txn to increment a nonce has been a reliable source of\nfailures.  So I think we'd want to have the encoding able to encode\nleading prev bits.\n\nMany altcoins also change the header structures. If the better thing\nis altcoin incompatible, we should still do it. Doing otherwise would\ncompetitively hobble Bitcoin especially considering the frequent\nrecklessly incompetent moves made by various altcoins and the near\ntotal lack of useful novel development we've seen come out of the\nclones.\n\nProbably the most important change in a new header message wouldn't be\nthe encoding, but it would be changing the fetching mechanism so that\nheader sets could be pulled in parallel, etc.\n\nI would rather not change the serialization of existing messages,\nnodes are going to have to support speaking both messages for a long\ntime, and I think we already want a different protocol flow for\nheaders fetching in any case."}