{"type":"rich","version":"1.0","author_name":"npub10uzud4rf4636awmfgvarmcfndcmdnv8rfd2y3rx2sqgckv9zur4qahln8t","author_url":"https://nostr.ae/npub10uzud4rf4636awmfgvarmcfndcmdnv8rfd2y3rx2sqgckv9zur4qahln8t","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-12-04\n📝 Original message:\u003e Also how about making timestamp 8 bytes?  2106 is coming up soon :)\n\nAFAICT this was fixed in this commit:\nhttps://github.com/jl2012/bitcoin/commit/fa80b48bb4237b110ceffe11edc14c8130672cd2#diff-499d7ee7998a27095063ed7b4dd7c119R200\n\n\n2016-12-04 21:00 GMT+01:00 adiabat via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\u003e Interesting stuff! I have some comments, mostly about the header.\n\u003e\n\u003e The header of forcenet is mostly described in Luke’s BIP, but I have made\n\u003e\u003e some amendments as I implemented it. The format is (size in parentheses;\n\u003e\u003e little endian):\n\u003e\u003e\n\u003e\u003e Height (4), BIP9 signalling field (4), hardfork signalling field (3),\n\u003e\u003e merge-mining hard fork signalling field (1), prev hash (32), timestamp (4),\n\u003e\u003e nonce1 (4), nonce2 (4), nonce3 (compactSize + variable), Hash TMR (32),\n\u003e\u003e Hash WMR (32), total tx size (8) , total tx weight (8), total sigops (8),\n\u003e\u003e number of tx (4), merkle branches leading to header C (compactSize + 32 bit\n\u003e\u003e hashes)\n\u003e\u003e\n\u003e\n\u003e First, I'd really rather not have variable length fields in the header.\n\u003e It's so much nicer to just have a fixed size.\n\u003e\n\u003e Is having both TMR and WMR really needed?  As segwit would be required\n\u003e with this header type, and the WMR covers a superset of the data that the\n\u003e TMR does, couldn't you get rid of the TMR?  The only disadvantage I can see\n\u003e is that light clients may want a merkle proof of a transaction without\n\u003e having to download the witnesses for that transaction.  This seems pretty\n\u003e minor, especially as once they're convinced of block inclusion they can\n\u003e discard the witness data, and also the tradeoff is that light clients will\n\u003e have to download and store and extra 32 bytes per block, likely offsetting\n\u003e any savings from omitting witness data.\n\u003e\n\u003e The other question is that there's a bit that's redundant: height is also\n\u003e committed to in the coinbase tx via bip 34 (speaking of which, if there's a\n\u003e hard-fork, how about reverting bip 34 and committing to the height with\n\u003e coinbase tx nlocktime instead?)\n\u003e\n\u003e Total size / weight / number of txs also feels pretty redundant.  Not a\n\u003e lot of space but it's hard to come up with a use for them.  Number of tx\n\u003e could be useful if you want to send all the leaves of a merkle tree, but\n\u003e you could also do that by committing to the depth of the merkle tree in the\n\u003e header, which is 1 byte.\n\u003e\n\u003e Also how about making timestamp 8 bytes?  2106 is coming up soon :)\n\u003e\n\u003e Maybe this is too nit-picky; maybe it's better to put lots of stuff in for\n\u003e testing the forcenet and then take out all the stuff that wasn't used or\n\u003e had issues as it progresses.\n\u003e\n\u003e Thanks and looking forward to trying out forcenet!\n\u003e\n\u003e -Tadge\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161204/77223c7c/attachment.html\u003e"}