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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 889864A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Mar 2019 03:23:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 235FB829
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Mar 2019 03:23:55 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))
id 1h3uUg-0005qw-G9; Wed, 13 Mar 2019 13:23:52 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Wed, 13 Mar 2019 13:23:46 +1000
Date: Wed, 13 Mar 2019 13:23:46 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20190313032346.ep472iuhayfzk5e5@erisian.com.au>
References: <CALJw2w5OiKHk1oj1p=rmQ-jvYOdieOD=xHcPt9D0A_-nLKvv7Q@mail.gmail.com>
<939C132D-8599-4258-8F14-62E992BA9F51@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <939C132D-8599-4258-8F14-62E992BA9F51@mattcorallo.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY
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: Wed, 13 Mar 2019 06:46:42 +0000
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: Wed, 13 Mar 2019 03:23:55 -0000
On Fri, Mar 08, 2019 at 03:20:49PM -0500, Matt Corallo via bitcoin-dev wrote:
> To make testing easier, it may make sense to keep the existing block header
> format (and PoW) and instead apply the signature rules to some field in the
> coinbase transaction.
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)
I think you could do that by adding a p2p service bit to say "send me
signatures if you have them / I can send you signatures", which changes
the p2p encoding of the header from (ver, prev, mrkl, time, bits, nonce)
to (ver, prev, mrkl, time, 0, nonce, bits, sig), and change header
processing to ignore headers from nodes that don't have the service
bit set?
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.
Cheers,
aj
|
