Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

From: "Hampus Sjöberg" <hampus.sjoberg@gmail.com>
To: adiabat <rx@awsomnet.org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Forcenet: an experimental network with a new header format
Date: Sun, 4 Dec 2016 21:37:39 +0100	[thread overview]
Message-ID: <CAFMkqK-4jATqTsbFmS5GDPHhXW8X+6m+dBvc3nqknmea-fz_YA@mail.gmail.com> (raw)
In-Reply-To: <CAKEeUhjYPL+kO6RCc8UDZWeAEmFuX1NRfkv22uqR4K+FiGosDA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]

> 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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3937 bytes --]