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
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
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 A9429A47
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Jun 2016 01:01:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com
[209.85.213.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1077D1CF
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Jun 2016 01:01:52 +0000 (UTC)
Received: by mail-vk0-f53.google.com with SMTP id u68so3193592vkf.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 18:01:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc:content-transfer-encoding;
bh=zUvVC3+SMFWp8NuvvGcxrQv0/EpBj88VqInKEBiAxJs=;
b=stf7pFj88PjA8DPZHlYm4iQNuVyja/Nk0S5nJim7A0k8JaQ9yXxLdMYtg/rIse0JNU
jQ9f/xYW7M+owQYs+xEnx4BhBl5F09DOELwOLJQY4THC+xie8V2nRHpf+Pv9aiZSm/LQ
2fbEOiiUv8SP1qMCRDItz9a0rS8rlaPtduZv3cRXRHOb0itbbI2mHkihE4/S5LMKluc5
pOb2pQ6B1lZ081A4PXckPygX0TAXZTWTCcM2hVpQb1yxTEu5q8rJhQUspqAI0+UG+fM9
k0zXnUuFVlS0SeLMLh07JidMrIgL6FHtZTf37jS6mU2MguE5jUijbqLIBFBuH0rGbx5T
qOTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc:content-transfer-encoding;
bh=zUvVC3+SMFWp8NuvvGcxrQv0/EpBj88VqInKEBiAxJs=;
b=LE4ICaBcvF8H2CHdlu/uJH+KrOd0mDJME1qgnN34Ee4Tgo+lDjNket7+0YiznyfSTW
2YaKYzpGOILlZO//TzqfVrNaYXlYGDdM+cJLuszUKUklFTA9X836hAnAErfXIyr/V+se
92TT3ppuZIGUeTnEUWa0tnWhehs33LxdrZ7h7+r12HX2wBWAoPsmia4xEotp1dIL8R0t
isvBMLZdSLmSl8iHRJK+goEacORqMnLFs1Mu5I+kqB4UA/2RIXvoj6HwH3JnTDH3CGRn
Qi3nyGfak45DmwUFlsaKVgAaDYoIv/xENn/ZEFeK/rTZVGrlp1Q/UBKCfTCiW36nMcJQ
fQlg==
X-Gm-Message-State: ALyK8tKMfzCpVAHVh5parH7gQxTfJF+afbGokY+1ZzE23UB3gfMHpli53hevP0jViv7JmDmDwB0aWqHowiGvYA==
X-Received: by 10.31.84.131 with SMTP id i125mr2345201vkb.29.1467162111112;
Tue, 28 Jun 2016 18:01:51 -0700 (PDT)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.94.67 with HTTP; Tue, 28 Jun 2016 18:01:50 -0700 (PDT)
In-Reply-To: <AB9C1C8F-7369-42CC-8551-7E03B16D5229@voskuil.org>
References: <87h9cecad5.fsf@rustcorp.com.au>
<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
<577234A4.3030808@jonasschnelli.ch>
<CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com>
<AB9C1C8F-7369-42CC-8551-7E03B16D5229@voskuil.org>
From: Gregory Maxwell <greg@xiph.org>
Date: Wed, 29 Jun 2016 01:01:50 +0000
X-Google-Sender-Auth: 5IlkOjrq-wof7b_pauvHXeQq2x0
Message-ID: <CAAS2fgT4V72vj17qTLu7pz5EQ60bqnggeDnTP5ASdwYxpuNpWw@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
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, 29 Jun 2016 01:01:52 -0000
On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil <eric@voskuil.org> wrote:
> I don't follow this comment. The BIP aims quite clearly at "SPV" wallets =
as its justifying scenario.
It cites SPV as an example, doesn't mention bloom filters.. and sure--
sounds like the bip text should make the
>> Without something like BIP151 network participants cannot have privacy f=
or the transactions they originate within the protocol against network obse=
rvers.
>
> And they won't get it with BIP151 either. Being a peer is easier than obs=
erving the network.
Not passively, undetectable, and against thousands of users at once at low =
cost.
> If one can observe the encrypted traffic one can certainly use a timing a=
ttack to determine what the node has sent.
Not against Bitcoin Core, transactions are batched and relayed in
sorted order. (obviously there are limits at what this provides;
ironically, the lack of link encryption has been used to argue against
privacy preserving relay behavior)
>> Even if, through some extraordinary effort, their own first hop is encry=
pted, unencrypted later hops would rapidly
>> expose significant information about transaction origins in the network.
>
> As will remain the case until all connections are encrypted and authentic=
ated, and all participants are known to be good guys. Starting to sound lik=
e PKI?
Huh? The first and subsequent hops obscures the origin and timing.
>> Without something like BIP151 authenticated links are not possible, so
>> manually curated links (addnode/connect) cannot be counted on to provide=
protection against partitioning sybils.
>
> If we trust the manual links we don't need/want the other links. In fact =
retaining the other links enables the attack you described above. Of course=
there is no need to worry about Sybil attacks when all of your peers are a=
uthenticated. But again, let us not ignore the problems of requiring all pe=
ers on the network be authenticated.
Don't need and want them for what? For _partitioning_ resistance,
you are not partitioned if you have one honest connection to the
functional network. Additional peers purely reduce your partition
vulnerability-- so long as an active network attacker isn't
itercepting all your connections out.
For privacy, you have improve transaction privacy so long as your
transaction isn't initially relayed to a malicious peer-- but
malicious peers can lie further out because transit nodes obscure the
order of message creation. Bitcoin Core currently relays transactions
first and more frequently to outbound and whitelisted peers.
> Maybe I was insufficiently explicit. By "relies on identity" I meant that=
the BIP is not effective without it. I did not mean to imply that the BIP =
itself implements an identity scheme. I thought this was clear from the con=
text.
I understood that, but my point was that Bitcoin cannot be used at
all_unless users have secure communication channels to share
addresses.
> then there is no reason to expect any effective improvement, since nodes =
will necessarily have to connect with anonymous peers.
They're not required to _only_ connect with anonymous peers. And
partition resistance requires that you have any one good link.
> Anyone with a node and the ability to monitor traffic should remain very =
effective.
Not via passive observation.
> Defining an auth implementation is not a hard problem, nor is it the conc=
ern I have raised.
Glad you agree.
We seem to be looping now. Feel free to not implement this proposal,
no one suggests making it mandatory.
|
