1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
Return-Path: <karljohan-alm@garage.co.jp>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BD8E6890
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Mar 2019 10:07:33 +0900 (JST)
X-Received: by mail-qt1-f198.google.com with SMTP id b40so3868780qte.1
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <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"
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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.
|