Hi Anthony, On Wed, Mar 13, 2019 at 12:23 PM Anthony Towns <a...@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. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
