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 A9429A47 for ; 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 ; Wed, 29 Jun 2016 01:01:52 +0000 (UTC) Received: by mail-vk0-f53.google.com with SMTP id u68so3193592vkf.2 for ; 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: References: <87h9cecad5.fsf@rustcorp.com.au> <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org> <577234A4.3030808@jonasschnelli.ch> From: Gregory Maxwell Date: Wed, 29 Jun 2016 01:01:50 +0000 X-Google-Sender-Auth: 5IlkOjrq-wof7b_pauvHXeQq2x0 Message-ID: To: Eric Voskuil 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 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: Wed, 29 Jun 2016 01:01:52 -0000 On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil 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.