From: Karl-Johan Alm <karljohan-alm@garage•co.jp>
To: Anthony Towns <aj@erisian•com.au>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Signet
Date: Thu, 14 Mar 2019 10:07:20 +0900 [thread overview]
Message-ID: <CALJw2w62voqzyaf0b5ccX4vQvXdtVNXq1t4XKCTQFeyhHYcNwg@mail.gmail.com> (raw)
In-Reply-To: <20190313032346.ep472iuhayfzk5e5@erisian.com.au>
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.
next prev parent reply other threads:[~2019-03-14 1:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-08 5:54 Karl-Johan Alm
2019-03-08 20:20 ` Matt Corallo
2019-03-10 0:43 ` Karl-Johan Alm
2019-03-10 17:01 ` David A. Harding
2019-03-12 5:44 ` Karl-Johan Alm
2019-03-13 3:23 ` Anthony Towns
2019-03-14 1:07 ` Karl-Johan Alm [this message]
2019-03-09 19:52 ` Lautaro Dragan
2019-03-10 1:02 ` Karl-Johan Alm
2019-03-13 9:15 Varunram Ganesh
[not found] <CACJ+Xm+-+C43ev_Sk8T-wdm=1nsmHHR_wB4rk+wu9CJvMHS5jw@mail.gmail.com>
2019-03-14 1:17 ` Karl-Johan Alm
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=CALJw2w62voqzyaf0b5ccX4vQvXdtVNXq1t4XKCTQFeyhHYcNwg@mail.gmail.com \
--to=karljohan-alm@garage$(echo .)co.jp \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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