{"type":"rich","version":"1.0","author_name":"npub1sax5yz8xgp684kl9c5f4kzljunm7u569vgfvuv66xtnl2aqs664s0y4xsu","author_url":"https://nostr.ae/npub1sax5yz8xgp684kl9c5f4kzljunm7u569vgfvuv66xtnl2aqs664s0y4xsu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-12-04\n📝 Original message:Interesting stuff! I have some comments, mostly about the header.\n\nThe header of forcenet is mostly described in Luke’s BIP, but I have made\n\u003e some amendments as I implemented it. The format is (size in parentheses;\n\u003e little endian):\n\u003e\n\u003e Height (4), BIP9 signalling field (4), hardfork signalling field (3),\n\u003e merge-mining hard fork signalling field (1), prev hash (32), timestamp (4),\n\u003e nonce1 (4), nonce2 (4), nonce3 (compactSize + variable), Hash TMR (32),\n\u003e Hash WMR (32), total tx size (8) , total tx weight (8), total sigops (8),\n\u003e number of tx (4), merkle branches leading to header C (compactSize + 32 bit\n\u003e hashes)\n\u003e\n\nFirst, I'd really rather not have variable length fields in the header.\nIt's so much nicer to just have a fixed size.\n\nIs having both TMR and WMR really needed?  As segwit would be required with\nthis header type, and the WMR covers a superset of the data that the TMR\ndoes, couldn't you get rid of the TMR?  The only disadvantage I can see is\nthat light clients may want a merkle proof of a transaction without having\nto download the witnesses for that transaction.  This seems pretty minor,\nespecially as once they're convinced of block inclusion they can discard\nthe witness data, and also the tradeoff is that light clients will have to\ndownload and store and extra 32 bytes per block, likely offsetting any\nsavings from omitting witness data.\n\nThe other question is that there's a bit that's redundant: height is also\ncommitted to in the coinbase tx via bip 34 (speaking of which, if there's a\nhard-fork, how about reverting bip 34 and committing to the height with\ncoinbase tx nlocktime instead?)\n\nTotal size / weight / number of txs also feels pretty redundant.  Not a lot\nof space but it's hard to come up with a use for them.  Number of tx could\nbe useful if you want to send all the leaves of a merkle tree, but you\ncould also do that by committing to the depth of the merkle tree in the\nheader, which is 1 byte.\n\nAlso how about making timestamp 8 bytes?  2106 is coming up soon :)\n\nMaybe this is too nit-picky; maybe it's better to put lots of stuff in for\ntesting the forcenet and then take out all the stuff that wasn't used or\nhad issues as it progresses.\n\nThanks and looking forward to trying out forcenet!\n\n-Tadge\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161204/43fe8311/attachment.html\u003e"}