MIME-Version: 1.0
In-Reply-To: <CAKEeUhjYPL+kO6RCc8UDZWeAEmFuX1NRfkv22uqR4K+FiGosDA@mail.gmail.com>
References: <FB8593E6-3CD7-46D5-8FC8-A73A0EF1AE9A@xbt.hk>
	<CAKEeUhjYPL+kO6RCc8UDZWeAEmFuX1NRfkv22uqR4K+FiGosDA@mail.gmail.com>
From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Sun, 4 Dec 2016 21:37:39 +0100
Message-ID: <CAFMkqK-4jATqTsbFmS5GDPHhXW8X+6m+dBvc3nqknmea-fz_YA@mail.gmail.com>
To: adiabat <rx@awsomnet.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=047d7b6251a06cc6910542db24f8
Subject: Re: [bitcoin-dev] Forcenet: an experimental network with a new
	header format
Precedence: list

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

<div dir=3D"ltr">&gt; Also how about making timestamp 8 bytes? =C2=A02106 i=
s coming up soon :)<br><div><br></div><div>AFAICT this was fixed in this co=
mmit: <a href=3D"https://github.com/jl2012/bitcoin/commit/fa80b48bb4237b110=
ceffe11edc14c8130672cd2#diff-499d7ee7998a27095063ed7b4dd7c119R200">https://=
github.com/jl2012/bitcoin/commit/fa80b48bb4237b110ceffe11edc14c8130672cd2#d=
iff-499d7ee7998a27095063ed7b4dd7c119R200</a><br></div><div><br></div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-12-04 21:00 =
GMT+01:00 adiabat via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.l=
inuxfoundation.org</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">Interesting stuff! I have some comments, mostly about the header=
.<div><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span=
 class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
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):<br>
<br>
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)=
<br></blockquote><div><br></div></span><div>First, I&#39;d really rather no=
t have variable length fields in the header.=C2=A0 It&#39;s so much nicer t=
o just have a fixed size.</div><div><br></div><div>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&#39;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&#39;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.</div><div><br></div><div>The other question is t=
hat there&#39;s a bit that&#39;s redundant: height is also committed to in =
the coinbase tx via bip 34 (speaking of which, if there&#39;s a hard-fork, =
how about reverting bip 34 and committing to the height with coinbase tx nl=
ocktime instead?)</div><div><br></div><div>Total size / weight / number of =
txs also feels pretty redundant.=C2=A0 Not a lot of space but it&#39;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.=
</div><div><br></div><div>Also how about making timestamp 8 bytes? =C2=A021=
06 is coming up soon :)</div><div><br></div><div>Maybe this is too nit-pick=
y; maybe it&#39;s better to put lots of stuff in for testing the forcenet a=
nd then take out all the stuff that wasn&#39;t used or had issues as it pro=
gresses.</div><div><br>Thanks and looking forward to trying out forcenet!</=
div><div><br></div><div>-Tadge</div></div></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--047d7b6251a06cc6910542db24f8--