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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3FEF8267
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Dec 2015 05:13:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f179.google.com (mail-io0-f179.google.com
[209.85.223.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EA97D121
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Dec 2015 05:13:15 +0000 (UTC)
Received: by iofh3 with SMTP id h3so153367086iof.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 05 Dec 2015 21:13:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=bM3aEzn80R2T+6m+GOyDvInb4J2FY2gNJW9jMdOHBJA=;
b=ZEBhvOTi5Yp/z4hzgs3036sQu6wf+YXJohSyEUlm6y5cMXyxtvXnVXbUyazz0mY8e8
2ySuVYR+AUYxmnNWsO/lNpYIn3K+fh/gWaUeer62r87wEOtASytmE8Be3L2F+bMmSHI7
TVBLeAOdiYTi4GTIXDYCTO11TvW0UhhvDjL22+Bl2403vmpXlKEj7NxRfUij70w5Fbgo
TZZeSsB9Rv3Gfn3TbQ2GN8+QxoN+3gP48ZlVzbDAxofVfZS/RcVCEnXht6zsbEyERrDX
d0E6ZuIyTcM0IcpPuNm9csarwJBVQTibjMh13A249UwcgBKXaKM9XVcCdpuWbiP13ar4
QY/g==
MIME-Version: 1.0
X-Received: by 10.107.34.199 with SMTP id i190mr21379261ioi.150.1449378795343;
Sat, 05 Dec 2015 21:13:15 -0800 (PST)
Sender: gmaxwell@gmail.com
Received: by 10.107.192.70 with HTTP; Sat, 5 Dec 2015 21:13:15 -0800 (PST)
In-Reply-To: <871tb16diz.fsf@rustcorp.com.au>
References: <CAAS2fgRwfQNYxCmDPAnVudyAti9v8PPXQjxe9M13pmrFxKcSCQ@mail.gmail.com>
<CABsx9T1vBRMYm6rLuqzvOxD0eABE4saF44JzZjMF3iUU==Nz0Q@mail.gmail.com>
<871tb16diz.fsf@rustcorp.com.au>
Date: Sun, 6 Dec 2015 05:13:15 +0000
X-Google-Sender-Auth: vcSLhSmHbeZxUOQhHDNk0S9v02c
Message-ID: <CAAS2fgRMi3KKKUW_7eunG9cprOLtz8yrEtA+8ChiCgninjMMZw@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, 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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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: Sun, 06 Dec 2015 05:13:17 -0000
On Fri, Dec 4, 2015 at 10:43 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>> I agree with Jannes Faber, behavior with respect to SPV clients should be
>> to only tell them about fully validated headers.
>
> A delicate balance. If we penalize these blocks too much, it's
> disincentive to set the bit. Fortunately it's easy for SPV clients to
> decide for themselves, I think?
I think this is orthogonal: You should only tell SPV clients* about
blocks you've fully validated yourself. The bit in the header doesn't
matter with respect to that. (Effectively, the wallet risk model gets
as input the fact that they got given the block in the first place as
well as the flag where the miner said they were validating things or
not.)
Whatever the ideal behavior is for network nodes towards lite clients;
it's insanely cheap to just spin up a lot of 'nodes' that have
arbitrary behavior; so it shouldn't be relied on too much; but
absolutely they should be filtering to things they've verified
themselves... unlike the mining case, there is no reason not to.
[Specific attacks to consider: You get a broken miner to include both
your payment, and some invalid transaction. Other miners extend it
without verifying. To avoid the fact that nodes sensibly filter
invalid blocks from their lite clients, you simply just run a lot of
'nodes' so that virtually every lite client has a connection to you]
(More specifically, peers should be able to specify that they want to
know about pre-validated blocks and you should be able to fetch blocks
from them which haven't been validated... but no one should get fed
unverified blocks by surprise.)
|
