From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 630F588A for ; Thu, 30 Jun 2016 12:21:05 +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 9C54DF0 for ; Thu, 30 Jun 2016 12:21:04 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id C38072E605DA; Thu, 30 Jun 2016 14:21:03 +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 69EF42E60018; Thu, 30 Jun 2016 14:21:02 +0200 (CEST) To: Eric Voskuil , Alfie John References: <87h9cecad5.fsf@rustcorp.com.au> <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org> <577234A4.3030808@jonasschnelli.ch> <360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org> <20160629111728.GO13338@dosf1.alfie.wtf> <2981A919-4550-4807-8ED9-F8C51B2DC061@voskuil.org> From: Jonas Schnelli Message-ID: <57750EAB.3020105@jonasschnelli.ch> Date: Thu, 30 Jun 2016 14:20:59 +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: <2981A919-4550-4807-8ED9-F8C51B2DC061@voskuil.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DR2EEdK3q1xfeDKeGSJAAEV9V2xNcQ24n" Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 12:21:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DR2EEdK3q1xfeDKeGSJAAEV9V2xNcQ24n Content-Type: multipart/mixed; boundary="lEoPt8M1HKDxM31sKvULuUr9vnFEusoMd" From: Jonas Schnelli To: Eric Voskuil , Alfie John Cc: Bitcoin Protocol Discussion Message-ID: <57750EAB.3020105@jonasschnelli.ch> Subject: Re: [bitcoin-dev] BIP 151 References: <87h9cecad5.fsf@rustcorp.com.au> <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org> <577234A4.3030808@jonasschnelli.ch> <360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org> <20160629111728.GO13338@dosf1.alfie.wtf> <2981A919-4550-4807-8ED9-F8C51B2DC061@voskuil.org> In-Reply-To: <2981A919-4550-4807-8ED9-F8C51B2DC061@voskuil.org> --lEoPt8M1HKDxM31sKvULuUr9vnFEusoMd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > Yes, this is exactly what I meant. The complexity of the proposed const= ruction is comparable to that of Bitcoin itself. This is not itself prohi= bitive, but it is clearly worthy of consideration. >=20 > A question we should ask is whether decentralized anonymous credentials= is applicable to the authentication problem posed by BIP151. I propose t= hat it is not. >=20 > The core problem posed by BIP151 is a MITM attack. The implied solution= (BIP151 + authentication) requires that a peer trusts that another is no= t an attacker.=20 BIP151 would increase the risks for MITM attackers. What are the benefits for Mallory of he can't be sure Alice and Bob may know that he is intercepting the channel? MITM is possible today, it would still be possible (though under higher costs) with BIP151. With BIP151 we would have the basic tool-set to effectively reduce the risks of being MITMled. IMO we should focus on the risks and benefits of BIP151 and not drag this discussion into the realm of authentication. This can and should be done once we have proposals for authentication (and I'm sure this will be a heated debate). The only valid risk I have on my list from you, Eric, is the false sense of security. My countermeasure for that would be... - deploy BIP151 together with the simplest form of authentication (know_hosts / authorized_keys file, no TOFU only editable "by hand") - make it more clear (in the BIP151 MOTIVATION text) that it won't solve the privacy/MITM problem without additional authentication. Or could you elaborate again =96 without stepping into the realm of authentication/MITM (which is not part of the BIP or possible already today) =96 why BIP151 would make things worse? --lEoPt8M1HKDxM31sKvULuUr9vnFEusoMd-- --DR2EEdK3q1xfeDKeGSJAAEV9V2xNcQ24n 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 iQIcBAEBCAAGBQJXdQ6rAAoJECnUvLZBb1PsOmQQAIsUmxoGwlEc03UsQdJ16KP3 vYfP3idXWb7hQOa5YzSOTF5N07jK9HZO3MCKRPIHQadH1nlPDYSb0GOESUpik2rE peTi1H+3RlE/V3DHlE7IWUvpGAnIl/q8iUJpuwuqOc60QFKRjk2NeM7SqXToREvu TMNTtlqpHvmRXAp+m3zt7BiUhx2XbXHvjUpZgZhvuqRbMa/NC3VWJOdTLGa3yYC0 9t8Estvba4pM6SoIVKh4wthJDaPYMpNvY6JH1AgTAnLPvkoOtKV3fC6I8N9O+OUs f0Wg3X9sA5uUgyV6SD1nQLXLXLRGi0dy5wXFGoegdJdghRZLeOoZSq4oMAqZ0/AZ iT/JAMHfv/dYKEiplUImhsa+PIQf69d3Jwzf0/l0tNGEeSymLkL2CaGgIkLbYnTl 6zW0z1/7cDkJS/dnnKGcI/OL1i8tF5AlNf3H3kSo6bBF4p9jd18PERVsQWDDpY7s ATt4ynKZWgoj46isekS65DuySWTsrbJ2hq5ZeZMwVjtZYvDzWPn7IOF0QwOM2zQf AofIKIdAAVUbhyP4NQ+BuTJN8DKBohlajErsinIlJ4fpx38GqEzmeOg9P8gkPn9w LSNHvPE/jxefKM0IwnIoKvHcBjwVy6KMUBXBHHM9ZcuSkDVAHktHggpRYiSQhS4g yFb6+gcXwJoiS7y7DCjN =S8AA -----END PGP SIGNATURE----- --DR2EEdK3q1xfeDKeGSJAAEV9V2xNcQ24n--