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
|
Return-Path: <thomas.kerin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8A7B889C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Dec 2015 16:47:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com
[209.85.220.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 234C914D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Dec 2015 16:47:00 +0000 (UTC)
Received: by qkda6 with SMTP id a6so46035288qkd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 04 Dec 2015 08:46:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-type:content-transfer-encoding;
bh=wt5ThvnB8aarRF0b8Vsc4uIy3vj5joUcIixmDiogePQ=;
b=lqm/GYOMEK/QYigEDskNTTty5mmKedgjv1DK0ih5Qo2pC92Gzf+tx4Ppo+ybT6PV60
RwCb1MAX3BDYU0TTpAp5BgZqqr+WSIB9ctpgWN7fMdQdBLpBomg+Fpr9wJNqHjFajUsy
GhuX4rVi7MPBJAlPq2QbAvA6d1ZoL8yDyf4iZ/dl2FxJSWs+Fmn9kcDMO0f9l02RxwWq
wXJ/O7E+xHirKBzfcABhmuDuhfQK7QgGm1cvu9S1daRAJZ8i2KK0J+WOJL0RHTA2H4ll
3em9sLzo9KMYd7Y+DOWwZv3GZP+d5Zmhuv1elQHQuTTxsxPUwU5Wo8TQKhLczzhFxJ7p
pidg==
X-Received: by 10.55.77.202 with SMTP id a193mr19387632qkb.48.1449247619201;
Fri, 04 Dec 2015 08:46:59 -0800 (PST)
Received: from [192.168.0.3] ([82.223.30.165])
by smtp.gmail.com with ESMTPSA id
e184sm5825110qkb.40.2015.12.04.08.46.57
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 04 Dec 2015 08:46:58 -0800 (PST)
To: bitcoin-dev@lists.linuxfoundation.org
References: <CAAS2fgRwfQNYxCmDPAnVudyAti9v8PPXQjxe9M13pmrFxKcSCQ@mail.gmail.com>
<CABeL=0gWD8Nvp=j7OWKMVeVYH5NA-TBox1UTbyWxmVBf2nSJfQ@mail.gmail.com>
From: Thomas Kerin <thomas.kerin@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <5661C36A.9090509@gmail.com>
Date: Fri, 4 Dec 2015 16:46:34 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CABeL=0gWD8Nvp=j7OWKMVeVYH5NA-TBox1UTbyWxmVBf2nSJfQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW 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: Fri, 04 Dec 2015 17:35:23 +0000
Subject: Re: [bitcoin-dev] Blockchain verification flag (BIP draft)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Fri, 04 Dec 2015 16:47:00 -0000
1. Not relaying can cause problems. Gossip networks operate by
propagating new information (like a single new header), and refuse to
relay information if it's obviously invalid.
From the POV of a full node, which will normally hear about the header
first, there's no point to not telling peers about this information.
It's likely in the interest of SPV wallets to hear about EVERY
contending chain, so they can go about their business deciding which is
correct.
2. The only difference between a block and it's header is the list of
transactions. There isn't anywhere else to put the flag but the header's
version. Which is good, because clients usually receive headers first.
3. "Signal would need to include some sort of proof" That's not the
point of this BIP. You can't prove the miner has or hasn't verified the
chain. What purpose would it even serve? If clients accepted this
'proof', they might ignore blocks they should pay attention to.
The BIP doesn't involve proof at all, it's just an indicator you can
chose to use or ignore.
On 04/12/15 12:44, Jannes Faber via bitcoin-dev wrote:
> nodes side by side, one of them doesn't validate in order to reduce latency
|
