Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9CEEC88A for ; Tue, 28 Jun 2016 19:55:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 38BC8249 for ; Tue, 28 Jun 2016 19:55:40 +0000 (UTC) Received: by mail-vk0-f42.google.com with SMTP id j2so37175176vkg.2 for ; Tue, 28 Jun 2016 12:55:40 -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; bh=oXJam+/7RxVy4umZ/++ZX9QuX8zhCMRx43dhFt8mrbE=; b=DkHijeICgX3jzPCG1mu3sAA1yyKXpwtfOBVV13Dr+mGibGumPWJIOQabcTgmAQPIm5 cCFZpvpuogZMYJBYKXGamhQ2MGWK5BVyGFrU2g0wkzbM0jW5zHnteMZu/iJGjohEkM4r NU/GD+LFAZ/sn17hyOZSvKFdTLrp/FJg3PBSXuEjN7Q0sjk3iMdzb6FsX+Uub2iGDwev j8vYHUnCJLItQf36q7KZlSGd2YCDf/jBiNirGDSk3HA8PNmaBKUnB+0/OD7Pdj+rLOqV ihaRqMA1ihFPXd6Z9w8A5ZhdfdJqURxXhXk7GTT8t2Mhx4xzY90InZi+1Vj8nOdGJ85o 775g== 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; bh=oXJam+/7RxVy4umZ/++ZX9QuX8zhCMRx43dhFt8mrbE=; b=H4bFZptTeAg41qudFG+v605uWbDEYcwAXdtRBK8QN5I+pZY9mFE7hpayOAJL1MuPOX IVXOV0BQek9BeS9+TgNrRuijEeWmT0nEpVgFlCPMNZK34B+c2K3WWldTSR0BKSPASELX 5oEfXFKXnxJio2zUrgd8PxI13R9R0bAjqMNYW06C16vVFEHwVi5Tufz1VggSjPtS5fUh P7NtFCJPVVJHzi0N+W9xdf6EAQQEMnVNN4uJv2adK6GIowPEtEFwX+y8VefubDElvLj7 Jm3SjEmDZgnsYEv3AiQWpeYEKafabzgVaztt8sOqXP/jwR/cFwoeJFMic2YC1aKxzzjr ty+A== X-Gm-Message-State: ALyK8tITQ2d1CJESdF5slxNnRowDO+oV39ULDL4NQnQoD4oxCKUkQP8bZ88JxKeh5+vbe3SHeusoDieZKvyrKQ== X-Received: by 10.31.210.133 with SMTP id j127mr1634282vkg.143.1467143739290; Tue, 28 Jun 2016 12:55:39 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.94.67 with HTTP; Tue, 28 Jun 2016 12:55:37 -0700 (PDT) In-Reply-To: <577234A4.3030808@jonasschnelli.ch> References: <87h9cecad5.fsf@rustcorp.com.au> <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org> <577234A4.3030808@jonasschnelli.ch> From: Gregory Maxwell Date: Tue, 28 Jun 2016 19:55:37 +0000 X-Google-Sender-Auth: WL92ODOcvfJHqNO175L_vRINa-4 Message-ID: To: Jonas Schnelli , Bitcoin Protocol Discussion 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 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: Tue, 28 Jun 2016 19:55:40 -0000 > I understand the use, when coupled with a yet-to-be-devised identity system, with Bloom filter features. Yet these features This is a bit of a strawman, you've selected a single narrow usecase which isn't proposed by the BIP and then argue it is worthless. I agree that example doesn't have much value (and I believe that eventually the BIP37 bloom filters should be removed from the protocol). Without something like BIP151 network participants cannot have privacy for the transactions they originate within the protocol against network observers. Even if, through some extraordinary effort, their own first hop is encrypted, unencrypted later hops would rapidly expose significant information about transaction origins in the network. 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. Along the way BIP151 appears that it will actually make the protocol faster. > Given that the BIP relies on identity This is untrue. The proposal is an ephemerally keyed opportunistic encryption system. The privacy against a network observer does not depend on authentication, much less "identity". And when used with authentication at all it makes interception strongly detectable after the fact. > The BIP does not [...] contemplate the significant problems associated with key distribution in any identity system Because it does not propose any "identity system" or authorization (also, I object to your apparent characterization of authentication as as an 'identity system'-- do you also call Bitcoin addresses an identity system?). That said, manually maintaining adds nodes to your own and somewhat trusted nodes is a recommend best practice for miners and other high value systems which is rendered much less effective due to a lack of authentication, there is no significant key distribution problem in that case, and I expect the future auth BIP (Jonas had one before, but it was put aside for now to first focus on the link layer encryption) to address that case quite well.