Date: Wed, 13 Mar 2019 13:23:46 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20190313032346.ep472iuhayfzk5e5@erisian.com.au>
References: <CALJw2w5OiKHk1oj1p=rmQ-jvYOdieOD=xHcPt9D0A_-nLKvv7Q@mail.gmail.com>
	<939C132D-8599-4258-8F14-62E992BA9F51@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <939C132D-8599-4258-8F14-62E992BA9F51@mattcorallo.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: [bitcoin-dev] Signet
Precedence: list

On Fri, Mar 08, 2019 at 03:20:49PM -0500, Matt Corallo via bitcoin-dev wrote:
> To make testing easier, it may make sense to keep the existing block header
> format (and PoW) and instead apply the signature rules to some field in the
> coinbase transaction.

Maybe make the signature be an optional addition to the header, so
that you can have a "light node" that doesn't download/verify sigs
and a full node that does? (So signatures just sign the traditional
80-byte header, and aren't included in the block's tx merkle root, and
the prevHash reflects the hash of the previous block's 80-byte header,
without the signature)

I think you could do that by adding a p2p service bit to say "send me
signatures if you have them / I can send you signatures", which changes
the p2p encoding of the header from (ver, prev, mrkl, time, bits, nonce)
to (ver, prev, mrkl, time, 0, nonce, bits, sig), and change header
processing to ignore headers from nodes that don't have the service
bit set?

If you did this, it might be a good idea to enforce including the previous
block's header signature in the current block's coinbase.

Cheers,
aj