On 5 Dec 2016, at 04:00, adiabat <rx@awsomnet.org> wrote:

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.

I foresee there will be 2 types of headers under this system: the 80 bytes short header and the variable length full header. Short headers are enough to link everything up. SPV needs the full header only if they are interested in any tx in a block.

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?)

you could omit the transmission of nHeight, as it is implied (saving 4bytes). Storing nHeight of headers is what every full and SPV nodes would do anyway

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.

Yes, I agree with you that these are not particularly useful. Sum tree is more useful but it has other problems (see my other reply)

Also how about making timestamp 8 bytes? 2106 is coming up soon :)

No need. See my other reply

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