public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: adiabat <rx@awsomnet•org>
To: Johnson Lau <jl2012@xbt•hk>,
	 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 15:00:00 -0500	[thread overview]
Message-ID: <CAKEeUhjYPL+kO6RCc8UDZWeAEmFuX1NRfkv22uqR4K+FiGosDA@mail.gmail.com> (raw)
In-Reply-To: <FB8593E6-3CD7-46D5-8FC8-A73A0EF1AE9A@xbt.hk>

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

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

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

  reply	other threads:[~2016-12-04 20:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-04 19:34 Johnson Lau
2016-12-04 20:00 ` adiabat [this message]
2016-12-04 20:37   ` Hampus Sjöberg
2016-12-05 11:58     ` Tom Zander
2016-12-14 11:01       ` Johnson Lau
2016-12-14 11:07         ` Luke Dashjr
2016-12-14 11:12           ` Johnson Lau
2016-12-14 11:11   ` Johnson Lau
2016-12-10 21:29 ` Tier Nolan
2016-12-10 21:41   ` Luke Dashjr
2016-12-11 16:40     ` Tier Nolan
2016-12-14 10:55       ` Johnson Lau
2016-12-14 12:52         ` Tier Nolan
2016-12-14 15:45           ` Johnson Lau
2016-12-14 16:26             ` Tier Nolan
2017-01-14 21:14 ` Johnson Lau
2017-01-28  2:32   ` Matt Corallo
2017-01-28  3:02     ` Matt Corallo
2017-01-28  7:28     ` Johnson Lau
2017-01-28 17:14       ` Matt Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKEeUhjYPL+kO6RCc8UDZWeAEmFuX1NRfkv22uqR4K+FiGosDA@mail.gmail.com \
    --to=rx@awsomnet$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=jl2012@xbt$(echo .)hk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox