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 D6E0CA73 for ; Tue, 28 Jun 2016 23:34:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EC6F81F8 for ; Tue, 28 Jun 2016 23:34:36 +0000 (UTC) Received: by mail-wm0-f54.google.com with SMTP id v199so158750555wmv.0 for ; Tue, 28 Jun 2016 16:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oyoynKeIIprCD1jlo7eR+tDhfz6nYpFFtHJPAeoquj4=; b=uI4PG0+OQB9pIMobadJuTL4b7/wIaZUSQc/LwC0B36G/KvPdr8cGw02Z2zqPrfLlmH oP+f6Q8KpJ/cccFZFbtRUcAK4WGzB/yvN35tln7d5bb+XBqIq9Nc37loJ6uyntamqgbe 2YsG+dzxHenqxyCynS4nyUBVCxf0E2zuKssF9AIyjOiaTrg3ziFobnIquEmniXpuDnoW 0nEvurk88rN8Qm04jhL03oWeJgW2yh7icCs/6q/xLELZtq6RsDZB2eiL6Jqhn2xHZffM ICkG3z3JnFgPksuEIKKk5msw+KWj7qmtjYoA6Y8hNrjBqNNIsYS73KogyPNmifl8MlG6 pQmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oyoynKeIIprCD1jlo7eR+tDhfz6nYpFFtHJPAeoquj4=; b=QixS9Pg0zjQFZL278bftt+uBIXtFUIsDWxmOGoUWEo4B/jsY4Jqq+9Dhfmd9o/v8wP mVGJWynKeGYO6XiwpbQsKVQNgvF8Wb5DVdWDCYBb5GcmomPdXdIfq34cESvtl3sul8Tl NT/4diJ7nrXwzTWaY2KM243H2sHGOfHBNerK+LiIQzqijTvaZTBj94kZT8tk2Y/Ke4L/ AtJAV7ePWzczB1I7+WRCv1xeNhQuvUaUtKzDZFfnHHcG1Y/Xs5gy5ngq/GawfS9s/QFM 4HLBP/az8SIY9AU+JDLK/80XZHLJ4pNmenpNF9We42PGAzwiJeKQEe6QT8N2jcUPNgbU zpog== X-Gm-Message-State: ALyK8tJ2lNQSrteDYQDKx2CppwgtEXPVsceVnajid21KcbOy6iF4pkuKgyMyBxVaiPH9Fg== X-Received: by 10.194.22.72 with SMTP id b8mr5344132wjf.74.1467156875630; Tue, 28 Jun 2016 16:34:35 -0700 (PDT) Received: from [10.114.7.71] ([41.33.219.246]) by smtp.gmail.com with ESMTPSA id r130sm1178472wmf.20.2016.06.28.16.34.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Jun 2016 16:34:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Wed, 29 Jun 2016 01:34:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87h9cecad5.fsf@rustcorp.com.au> <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org> <577234A4.3030808@jonasschnelli.ch> <360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org> <20160628182202.GA5519@fedora-21-dvm> <20160628201447.GA1148@fedora-21-dvm> <4DCF7DD2-6533-4F79-8CA1-871B67C01BDA@voskuil.org> <20160628203605.GA1328@fedora-21-dvm> <7F95A7F5-848C-4EA6-9503-C48F45AC1C34@voskuil.org> To: Gregory Maxwell X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, MIME_QP_LONG_LINE, 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: Tue, 28 Jun 2016 23:34:37 -0000 >> On Jun 29, 2016, at 12:22 AM, Gregory Maxwell wrote:= >>=20 >> On Tue, Jun 28, 2016 at 9:59 PM, Eric Voskuil wrote: >> Passing the session ID out of band is authentication. As this is explicit= ly not part of BIP151 it cannot be that BIP151 provides the tools to detect a= attack (the point at issue). >=20 > It provides the ID, the rest is meat. The rest is "authentication". > Users can compare session IDs > via whatever communications channels they already use after the fact > and discover if they were or are being MITMed. >=20 >>>> It requires a secure channel and is authentication. So BIP151 doesn't p= rovide the tools to detect an attack, that requires authentication. A genera= l requirement for authentication is the issue I have raised. >>>=20 >>> One might wonder how you ever use a Bitcoin address, or even why we migh= t guess these emails from "you" aren't actually coming from the NSA. >>=20 >> The sarcasm is counterproductive Greg. By the same token I could ask how y= ou ever use Bitcoin given that the P2P protocol is not encrypted or authenti= cated. >=20 > I think I was unclear. A bitcoin address needs to be sent over a secure ch= annel, which we do not provide. Yet sending funds to addresses instead of an= yone_can_spend is pretty useful. >=20 > Similarly, I can guess that messages claiming to you are probably from you= when many people can independently check, even if they don't usually. The f= act tampered messages might be detected is a big disincentive from trying. You were perfectly clear. Did I give some indication that I did not understa= nd what you meant? >> The blockchain and mempool are a cache of public data. Transmission of a p= ayment address to a payer is not a comparable scenario. >=20 > The precise timing and ordering of transactions being relayed is _not_ > public data. Posting txs to the network is a client-server scenario. The set of txs arriv= ing at an arbitrary node, including the order of arrival, is by definition p= ublic information. The only possible way it could be considered private is i= f the entire network was private. So where does the private timing become public? First hop, second, third? Encryption and authentication cannot prevent timing attacks against a person= posting txs to the network unless the entire network is "secured". That is n= ot possible without centralized access control. Encrypting the P2P network doesn't resolve this problem, nor does authentica= tion, nor does Tor. I would prefer we advance an actual solution to this sig= nificant problem than advance a false sense of security while creating both c= omplexity and the likely evolution of node identity. e=