From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 98E82B2E for ; Wed, 14 Dec 2016 11:11:38 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D6FA4A0 for ; Wed, 14 Dec 2016 11:11:37 +0000 (UTC) Received: from [172.21.35.100] (223.197.116.5 [223.197.116.5]) by mx.zohomail.com with SMTPS id 1481713892676531.0325125978444; Wed, 14 Dec 2016 03:11:32 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D91A8230-8DF0-4EC7-AD6F-DF12D9A4229B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Johnson Lau In-Reply-To: Date: Wed, 14 Dec 2016 19:11:29 +0800 Message-Id: <08ED1F61-BB96-43B8-9474-CD52913F6B34@xbt.hk> References: To: adiabat X-Mailer: Apple Mail (2.3124) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev Subject: Re: [bitcoin-dev] Forcenet: an experimental network with a new header format X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 11:11:38 -0000 --Apple-Mail=_D91A8230-8DF0-4EC7-AD6F-DF12D9A4229B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 Dec 2016, at 04:00, adiabat wrote: >=20 > Interesting stuff! I have some comments, mostly about the header. >=20 > The header of forcenet is mostly described in Luke=E2=80=99s BIP, but = I have made some amendments as I implemented it. The format is (size in = parentheses; little endian): >=20 > 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) >=20 > First, I'd really rather not have variable length fields in the = header. It's so much nicer to just have a fixed size. >=20 > 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. >=20 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.=20 > 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 >=20 > 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) Related discussion: = https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe1c2541ee= 7a17208 = >=20 > Also how about making timestamp 8 bytes? 2106 is coming up soon :) No need. See my other reply >=20 > 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. >=20 > Thanks and looking forward to trying out forcenet! >=20 > -Tadge --Apple-Mail=_D91A8230-8DF0-4EC7-AD6F-DF12D9A4229B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80=99s 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

= --Apple-Mail=_D91A8230-8DF0-4EC7-AD6F-DF12D9A4229B--