To: bitcoin-dev@lists.linuxfoundation.org
References: <87h9cecad5.fsf@rustcorp.com.au>
	<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <577269E7.6020008@jonasschnelli.ch>
Date: Tue, 28 Jun 2016 14:13:27 +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: <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="G0BmU2kctXdVI717EDrCaGBIHSwKfVXaR"
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--G0BmU2kctXdVI717EDrCaGBIHSwKfVXaR
Content-Type: multipart/mixed; boundary="lPTLK79lLbshXFovr8BolnGd482DNBTfr"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <577269E7.6020008@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] BIP 151
References: <87h9cecad5.fsf@rustcorp.com.au>
 <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
In-Reply-To: <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>

--lPTLK79lLbshXFovr8BolnGd482DNBTfr
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Eric

Sorry for not directly addressing your points.
I try to be more precise in this follow up email:

> I understand the use, when coupled with a yet-to-be-devised identity sy=
stem, with Bloom filter features. Yet these features are client-server in=
 nature. Libbitcoin (for example) supports client-server features on an i=
ndependent port (and implements a variant of CurveCP for encryption and i=
dentity). My concern arises with application of identity to the P2P proto=
col (excluding Bloom filter features).

I think the bloom filter SPV usecase is not "pure client-server". SPV
clients could request from/broadcast to multiple "trusted nodes".
Trusted nodes could be nodes where the operators have shared
identities/keys in advance over a different channel.

Further private p2p extensions (lets say a p2p form of the estimatefee
command) are something which needs to be discussed first and not
something that is encouraged or outlined in BIP151.

> It seems to me that the desire to secure against the weaknesses of BF i=
s being casually generalized to the P2P network. That generalization may =
actually weaken the security of the P2P protocol. One might consider the =
proper resolution is to move the BF features to a client-server protocol.=


I don't see reasons why BIP151 could weaken the security of the P2P
network. Can you point out some specific concerns?


> The BIP does not make a case for other scenarios, or contemplate the si=
gnificant problems associated with key distribution in any identity syste=
m. Given that the BIP relies on identity, these considerations should be =
fully vetted before heading down another blind alley.

BIP151 does not rely on identities. BIP151 does not use persisted keys
(only ephemeral keys). The authentication/identity system needs to be
described in a another BIP.
But correct, BIP151 without a form of authentication/identity management
is vulnerable to all sorts of MITM attacks and that's why I think BIP151
must be deployed together with an p2p authentication scheme.

Scope creeping and the risks of overspecifying is the main reason to
focus on the "pure encryption part" in BIP151.

Thanks
---
</jonas>


--lPTLK79lLbshXFovr8BolnGd482DNBTfr--

--G0BmU2kctXdVI717EDrCaGBIHSwKfVXaR
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

iQIcBAEBCAAGBQJXcmnnAAoJECnUvLZBb1PsEiUP/AliWXm56R/3p2+fQGSgMvPR
/CeP1bDcwUKpFz7p78xt2SYMbASiYvTa8s67mD3SRdp7tRmolaMM51TWTaqeKKel
Svu2uM1KG5PsoNK1Ctlhc2zImMz51Goph1qIb9mmlRtAUQjckICAvypoPAz4xSEB
CKHJuFU7HVQVZeBcE61Wj3jUFHaTu+NwPjMzjRCmbng/9UrDYbpKLwMYwM4mIBWB
rHoLwBw5lmmglyaxNQ1Jmhba+266ak4s9pjPeWG+L87WbDMvpO5cAcvG+NNMD26k
wmedUzFohhyT2KT3S2OTPKxeta2WiYMlvHqmJWtt+Kwzoxb7DPx7y3vXG76vOmm1
N1KdUSjOBrVLR0IQX+bFfNhZQTuKcaFmOl1gIGwmEKyYFD6otUvUZ/bAwpI3/qjM
vXl+WSqCy2fMGaEfKjjPjevXpH5e6F0+xo1uhA8uNGepeHZkCNyEH0rDsHxjHHum
KJttgq2eHpZsPNdK10dXG4gmslJffN3HJ+kYHOvpX8TT07e+4R4iRQsyeSfg6OYf
hEV0jtHAssIbL/+IiBBnw6HSQ2vbDOnjZ/va9M6r89AV24iapRm7lX2NypNR1PcZ
RV8mkbSTErrxiOVPSCQeCECzGGhKFWJsHwRG0S86Fd+vgN1kJcAuW+pjUF9VpRvt
7D5wDvJqabtDN6cn1u5x
=V2gG
-----END PGP SIGNATURE-----

--G0BmU2kctXdVI717EDrCaGBIHSwKfVXaR--