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