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
|
Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7FA7371
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Aug 2016 10:02:12 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from server3 (server3.include7.ch [144.76.194.38])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id BADBC117
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Aug 2016 10:02:11 +0000 (UTC)
Received: by server3 (Postfix, from userid 115)
id A8A3C2E60573; Tue, 9 Aug 2016 12:02:10 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Spam-Level:
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1
autolearn=ham version=3.3.1
Received: from Jonass-MacBook-Pro-2.local (cable-static-140-182.teleport.ch
[87.102.140.182]) by server3 (Postfix) with ESMTPSA id 12AA72D004C9
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Aug 2016 12:02:10 +0200 (CEST)
To: bitcoin-dev@lists.linuxfoundation.org
References: <57A89EA3.4020101@jonasschnelli.ch>
<57A8BCD9.7050402@AndySchroder.com>
<CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
<57A8C76D.1080405@AndySchroder.com>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <57A9AA1E.9050302@jonasschnelli.ch>
Date: Tue, 9 Aug 2016 12:02:06 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <57A8C76D.1080405@AndySchroder.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="jQiNR1tg3Pjs7KHH5dpC1fsTulQxuTeEP"
Subject: Re: [bitcoin-dev] Authentication BIP
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: Tue, 09 Aug 2016 10:02:12 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--jQiNR1tg3Pjs7KHH5dpC1fsTulQxuTeEP
Content-Type: multipart/mixed; boundary="64r3FRdLDM1XdUudXDjFWIUahlQiCs2c1"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <57A9AA1E.9050302@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] Authentication BIP
References: <57A89EA3.4020101@jonasschnelli.ch>
<57A8BCD9.7050402@AndySchroder.com>
<CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
<57A8C76D.1080405@AndySchroder.com>
In-Reply-To: <57A8C76D.1080405@AndySchroder.com>
--64r3FRdLDM1XdUudXDjFWIUahlQiCs2c1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Hi Andy
>>
>>> Does openssh have this same problem?
>> No. OpenSSH doesn't make an effort to protect the privacy of its users=
=2E
>>
>>> I'm assuming this could be parallelized very easily, so it is not a h=
uge
>>> problem?
>> It's not a issue because we're not aware of any usecase where a node
>> would have a large list of authenticated peers.
>>
>>> Each peer can configure one identity-key (ECC, 32 bytes) per listenin=
g
>> network interface (IPv4, IPv6, tor).
>>
>> I'm not aware of any reason for this limitation to exist. A node
>> should be able to have as many listening identities as it wants, with
>> a similar cost to having a large authorized keys list.
>>
>=20
> So you are saying that you agree with me that the original text needs t=
o
> be revised slightly or I am just misinterpreting the original text?
Yes. I think this limitation could be removed.
A responding node can have =96 in theory =96 multiple identity-keys per
network interface (network interfaces is also confusing, because you
could run multiple bitcoind instances on the same interface with
different ports).
The BIP should just make clear, that it is probably wise, to use
different identity-keys for each network interface (ipv4, v6, tor).
I'll try to overhaul that part.
</jonas>
--64r3FRdLDM1XdUudXDjFWIUahlQiCs2c1--
--jQiNR1tg3Pjs7KHH5dpC1fsTulQxuTeEP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJXqaoeAAoJECnUvLZBb1PsGZ8P/ikfH/toEWFLPThtSwQoQ4rD
QVhaoSURoO893AMRSLXTNNcmifah7m4/2N46ybVy27ChrmE/31/Kz09DfeTGyCk1
iMAtJMSiX4zfGEEb3AvjuZ5Gw0OaCEBSoIIGnSkvewQsw7NnL2vUK2WgCb9Itued
iNUTTEMs6IR6xsuRqCkZ4//bjn9jozHnn098Xnt0x2mzRFWJGkR4OoaS5/JPBIic
vrqp9S7VQy8PNSqAgRBX+obT4fiMWYO4jBZ1LvC4E7db65G6hZGue9wwjfrj4oze
LvcnPU43QS0yYeDwKUO5jUVI+Q338xpGw7pwDhF8bb3Fy/wQEOgwBHuCHDtCkcBc
VBcPddEUjOp5IQTZjwd5orAkXHErGsxZAejbMau2vqmeOruFloF4vU3vwk3Nf1P3
U3Ilv1SR8fybp174kW8x1zlDT7Q756jEGkVDwYmPjKjA3aPpOSW+MTky5/Bs0Q/d
+/LY0G9HRHsUAz0Wig+tB+t0QZwKJpfKYhkqSoGT9GZ9kXdk0I80eN2tIBQobP0M
pYSerdrWvpnYvhRVNBxxt/TZ9jMwy5kBjXRWdiY4/du34BPS99JvHfwULxOjfd0H
Lhs6MQt84NVoCOF4cHWvY+vOonRMTNX38dLRxf8NMjgz8R+t21ZZEFhg6/4glbjr
lpoQ7tYmBmWPBzwYemw9
=ET9b
-----END PGP SIGNATURE-----
--jQiNR1tg3Pjs7KHH5dpC1fsTulQxuTeEP--
|
