Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BD8E6890 for ; Thu, 14 Mar 2019 01:07:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mo.garage.hdemail.jp (mo.garage.hdemail.jp [46.51.242.127]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 09493D3 for ; Thu, 14 Mar 2019 01:07:34 +0000 (UTC) Received: from ip-10-217-1-36.ap-northeast-1.compute.internal (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-mf-postfix) with SMTP id 8B73514C0E7 for ; Thu, 14 Mar 2019 10:07:33 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Received: from unknown (HELO mo.garage.hdemail.jp) (127.0.0.1) by 0 with SMTP; 14 Mar 2019 10:07:33 +0900 X-Received: from mo.garage.hdemail.jp (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-ma-postfix) with ESMTP id 802684C06D for ; Thu, 14 Mar 2019 10:07:33 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) Received: from gw26.oz.hdemail.jp (ip-10-185-1-211.ap-northeast-1.compute.internal [10.185.1.211]) by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id 7423B14C0C5 for ; Thu, 14 Mar 2019 10:07:33 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Received: from mail-qt1-f198.google.com (lb06.oz.hdemail.jp [54.238.50.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw26.oz.hdemail.jp (Postfix) with ESMTP id 1B62B148C115 for ; Thu, 14 Mar 2019 10:07:33 +0900 (JST) X-Received: by mail-qt1-f198.google.com with SMTP id b40so3868780qte.1 for ; Wed, 13 Mar 2019 18:07:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fbNBKraPRiItD3vY3Yn/jAVxiAMCwTplQbVnGb7W4dg=; b=gUXumSdrc6j4GRGbsymTC+SsbLjQAkt0qZBt4I27rlZxQROoumAxt4dD1FmZaOjXZY KIN0gS0ZYP7O9MzLwXpMDcZi+apF7k1cmBOr2iqEJCQPEWaiNYv/PIz4N49gtspeyDUT P2f3oX4AjMng1DgcyG47dwGyhSY5Mke0hFvRkBVy0WvtCNHbOFpQxmJuPPrnLr0uzsls yN6LQ3S1lVzaSGrxurVWdcfD1ZVY+rAhnCLbW5RvMVtOOMU8FSR+f8x7JfrsPNAbiUEx 8fmR+/tE6nLftdQ1Wc7IVMNqephLv+OEzoU2JmmXAcPnTP/Wu1PxJHEOVLTb8SFYIITg BEtg== X-Gm-Message-State: APjAAAU9tRTJ/v1bQoSXg09tcFApyELEHPP4+eH1FOlIc39ol1oj4ZaQ 3eDs5xjVjpeDhj9n/zXFn17wld72ifihlbA8fIs3NwjvSLl1+UmDG1Ax0V/yOJTHvkUgBymK3K+ EqwZXC4khVSwufHCHH7KQwtqmbPLdoeKt28H8SaYgTMIiGil31NiC5bwrwmIDkoz895LJXTjSuW v1miXMpAQXX9dC+yRLDT/ub1C5S0tTjGoO3d5P8vFHR4/uqGHL64lGLQSZ8AVfmypPwr40/W0z4 oZxu8hEenJjAXfGu8t/9O6pjRalJa333JE8ZK5Cd9A1rCY/i+VQWA/JHxXoW7uEAn4/fWivK7hO U2XSABNC6319VEz7AkdWI0pglPI= X-Received: by 2002:ac8:25d9:: with SMTP id f25mr37524449qtf.156.1552525651677; Wed, 13 Mar 2019 18:07:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqyIMRhGqAHfMOOLWA90IBsHVrbe6o880wQUU495eG5CuGTaF2egEDDANztDQFA7c10N+JUxBMEw/Id1HkpTIvU= X-Received: by 2002:ac8:25d9:: with SMTP id f25mr37524434qtf.156.1552525651415; Wed, 13 Mar 2019 18:07:31 -0700 (PDT) MIME-Version: 1.0 References: <939C132D-8599-4258-8F14-62E992BA9F51@mattcorallo.com> <20190313032346.ep472iuhayfzk5e5@erisian.com.au> In-Reply-To: <20190313032346.ep472iuhayfzk5e5@erisian.com.au> From: Karl-Johan Alm Date: Thu, 14 Mar 2019 10:07:20 +0900 Message-ID: To: Anthony Towns Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 14 Mar 2019 02:53:19 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Signet X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 01:07:35 -0000 Hi Anthony, On Wed, Mar 13, 2019 at 12:23 PM Anthony Towns 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.