MIME-Version: 1.0
References: <CALJw2w5OiKHk1oj1p=rmQ-jvYOdieOD=xHcPt9D0A_-nLKvv7Q@mail.gmail.com>
	<939C132D-8599-4258-8F14-62E992BA9F51@mattcorallo.com>
	<20190313032346.ep472iuhayfzk5e5@erisian.com.au>
In-Reply-To: <20190313032346.ep472iuhayfzk5e5@erisian.com.au>
From: Karl-Johan Alm <karljohan-alm@garage.co.jp>
Date: Thu, 14 Mar 2019 10:07:20 +0900
Message-ID: <CALJw2w62voqzyaf0b5ccX4vQvXdtVNXq1t4XKCTQFeyhHYcNwg@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: text/plain; charset="UTF-8"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Signet
Precedence: list

Hi Anthony,

On Wed, Mar 13, 2019 at 12:23 PM Anthony Towns <aj@erisian.com.au> wrote:
>
> 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)

This seems to be what everyone around me thinks is the best approach.
I.e. signet is a "p2p level agreement" that an additional signature is
required for a block to be considered fully valid.

It has the added complexity that a signature-aware signet node talking
to a non-signature-aware signet node should reject/discard headers
sent from the peer, or you will run into situations where a node
doesn't know if the headers are valid or not and has to hold onto them
indefinitely, which is a situation that currently does not occur in
"regular" nets.

If you detach the signature from the header, you also end up with
cases where a malicious user could send garbage data as the signature
for a valid header, forcing peers to mark that header as invalid, even
though it isn't. That is regardless of whether a fix is in place for
the above, too.

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

Yeah that is one of the ideas we had early on, and I think it's a good
one to do. It doesn't mean someone cannot spam a bunch of invalid
headers at block height current_tip+1, but at least you can get all
but the latest signature now. So as long as you are able to fetch the
latest signature, you should theoretically be able to verify the
entire chain just from the blocks + that one sig.

-Kalle.