Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 75BE340A for ; Sun, 4 Dec 2016 20:37:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wj0-f175.google.com (mail-wj0-f175.google.com [209.85.210.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5EF47137 for ; Sun, 4 Dec 2016 20:37:41 +0000 (UTC) Received: by mail-wj0-f175.google.com with SMTP id qp4so274363051wjc.3 for ; Sun, 04 Dec 2016 12:37:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=4IfEH0vO/bMoNztE1v/WnAV05smvCuDU4ao9KKtMMXU=; b=qlSthnS3z23wlJzTtd0kXzj5JUj/Nz5jvToA2k2YNKmXWtZF4/n5aWp7cedOYbh64A bmxaAKWtrV+wCm1HKnt9xgOiZJWS7U5TIR6ssJBmoCaKzQp50XjdBur/PyL6pPkFLEqE U5Qi53I251gpprH1IqRYz6HVoZaIYvM8sbX4FCfos5YvlW7izy6o6YUkdgdZD6jvKOuN cd3iHbKE5/vrPvXk4oAPhlnLpgFIGYgF1RRSY+CnBz0+/2bQcf4BxR1jAHoJzSZEphPU 9rWqXYeo4uCKg0VgTZqzZ0QmO0ZPYInvzjQQdjGh4hj56vUiEfAeBsn/wizJcswYg5KX FOHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=4IfEH0vO/bMoNztE1v/WnAV05smvCuDU4ao9KKtMMXU=; b=dwKLZMhnHwHLg5VFZyqW3pnvx+JT8ig8e+KoG02niKcl8Le3Q9oAF/eBAXiiHdyQd6 9OWhoaz+tnMjLLoS+t0IUNNqztxRUPvpchjMV4EiYjbRKF8SbytAjNS/eINVJiOIVbxG m4niJecsU8Q484al6gw+JKXJSS8+DRfagAjX9boPZ+cPjyeP31ldOA36R4yWcjY5aO9K 2yyUM0eOZ+RVymPQHvtzKuNFsQ4g6fNNtrk9iXMESEqU7FyijXonAJzMlvkvZZW/qbCU iVAYt4Csp3968hKvx9vP2txG5ZdBw4SO6pPFbHvHec/ZSyjmWUXHPS5bMZkzF0rqDADq qM+Q== X-Gm-Message-State: AKaTC00NFpC7YYImG0+jpuXNGHzIBs+vhEjC9xirnQROwwgO05zJWFmyKIFU8fhP+y+ILUPw/qBlcwOLlWlprg== X-Received: by 10.194.39.7 with SMTP id l7mr46656156wjk.182.1480883859931; Sun, 04 Dec 2016 12:37:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.63.66 with HTTP; Sun, 4 Dec 2016 12:37:39 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= Date: Sun, 4 Dec 2016 21:37:39 +0100 Message-ID: To: adiabat , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=047d7b6251a06cc6910542db24f8 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 X-Mailman-Approved-At: Sun, 04 Dec 2016 20:42:57 +0000 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: Sun, 04 Dec 2016 20:37:42 -0000 --047d7b6251a06cc6910542db24f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > 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/fa80b48bb4237b110ceffe11edc14c8130= 672cd2#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=E2=80=99s BIP, but I h= ave 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 s= ee > 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 wil= l > have to download and store and extra 32 bytes per block, likely offsettin= g > 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 t= he > 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 fo= r > 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 > > --047d7b6251a06cc6910542db24f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> Also how about making timestamp 8 bytes? =C2=A02106 i= s coming up soon :)


=

2016-12-04 21:00 = GMT+01:00 adiabat via bitcoin-dev <bitcoin-dev@lists.l= inuxfoundation.org>:
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 hav= e made some amendments as I implemented it. The format is (size in parenthe= ses; little endian):

Height (4), BIP9 signalling field (4), hardfork signalling field (3), merge= -mining hard fork signalling field (1), prev hash (32), timestamp (4), nonc= e1 (4), nonce2 (4), nonce3 (compactSize + variable), Hash TMR (32), Hash WM= R (32), total tx size (8) , total tx weight (8), total sigops (8), number o= f tx (4), merkle branches leading to header C (compactSize + 32 bit hashes)=

First, I'd really rather no= t have variable length fields in the header.=C2=A0 It's so much nicer t= o just have a fixed size.

Is having both TMR and W= MR really needed?=C2=A0 As segwit would be required with this header type, = and the WMR covers a superset of the data that the TMR does, couldn't y= ou get rid of the TMR?=C2=A0 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.=C2=A0 This seems pretty minor, especia= lly as once they're convinced of block inclusion they can discard the w= itness data, and also the tradeoff is that light clients will have to downl= oad and store and extra 32 bytes per block, likely offsetting any savings f= rom omitting witness data.

The other question is t= hat 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 nl= ocktime instead?)

Total size / weight / number of = txs also feels pretty redundant.=C2=A0 Not a lot of space but it's hard= to come up with a use for them.=C2=A0 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? =C2=A021= 06 is coming up soon :)

Maybe this is too nit-pick= y; maybe it's better to put lots of stuff in for testing the forcenet a= nd then take out all the stuff that wasn't used or had issues as it pro= gresses.

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


--047d7b6251a06cc6910542db24f8--