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 D2EFC308 for ; Tue, 28 Jun 2016 16:46:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C6B8F19D for ; Tue, 28 Jun 2016 16:46:02 +0000 (UTC) Received: by mail-wm0-f48.google.com with SMTP id f126so148014935wma.1 for ; Tue, 28 Jun 2016 09:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :references:in-reply-to:to; bh=+vsWA2WV+J6FSP3L2mLeSJzQTXYDUmMd0bJ6A+10FTs=; b=08kGHRazmzVd48AEoW9yKACSARR7pr8YOUdGoePkkCnSPRCFxiEXn2pdys5p0Up/03 UKo+YC+eav6ojaISrhOWpb51P3pPu4ZP7iStZpX9uyLzXyyDS3paYlde3FoYEQVidGUw Uxa39SCbr5lvPjH/k5P4QQtXAXqqtzfZDH3ABHLj5w06R4QuaBVS4cvg4A3EB/aU2hzl BU5pzf8fLMNq8O+OW/Ln0MZk9zxu7zViSPGRrob8iKdX4Oq/EVHJedezIsmisY4C0zDU W2rQB2gb8X4drzlFbT3EE/IB7GVrwQxHzpawe9JsKOO8VWS2NRwK/tOG7WHHszizEkmL qQ3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:references:in-reply-to:to; bh=+vsWA2WV+J6FSP3L2mLeSJzQTXYDUmMd0bJ6A+10FTs=; b=VWzp5FOIEG0K+J1WzQJnfMo5mVfm+9yN4/TUBF7g5UF6kT2tttmLF+QfvLtHN4skox /Xv2JG5UQ/nrFdSU2Nqz9L2iJuuDVKU5ndWaKvLrIphy+BDHVSB8TWUzdVlLvBJ2YUyx Mh8g0XU6F+4UtWdq1PptOMnLgTISJFeVoqV+ClCnapu5iPvD07fmIYKN0dcHcUeCsUGL u8zUFcODCkBVSkOcmMCflxyO2lfPVp4y+RynOxVOnu15watahyOnpjXuOribe0+gpSeC 9D5ELQ6EmkOdaXh+wzUxFiHXry+f5R4A/TvHTESQtQikqsg+aSpnFHQlVAKjlE9cp6RI EwUg== X-Gm-Message-State: ALyK8tLp9EexvyHvKLiVyReHKo2gIphiF52bCL+FK6+CyAOLhW1N0xuduLM+gEVJdNxfQQ== X-Received: by 10.194.55.136 with SMTP id s8mr3952081wjp.134.1467132361111; Tue, 28 Jun 2016 09:46:01 -0700 (PDT) Received: from [10.114.7.71] ([41.33.219.254]) by smtp.gmail.com with ESMTPSA id bb4sm5206606wjb.32.2016.06.28.09.45.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Jun 2016 09:46:00 -0700 (PDT) From: Eric Voskuil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org> Date: Tue, 28 Jun 2016 18:45:58 +0200 References: <87h9cecad5.fsf@rustcorp.com.au> <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org> <577234A4.3030808@jonasschnelli.ch> In-Reply-To: <577234A4.3030808@jonasschnelli.ch> To: Jonas Schnelli , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (13F69) 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 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 16:46:03 -0000 Hi Jonas, I'll follow up in your second reply as well. Responses inline: > On Jun 28, 2016, at 10:26 AM, Jonas Schnelli via bitcoin-dev wrote: >=20 > Hi Eric >=20 >> I haven't seen much discussion here on the rationale behind BIP 151. Apol= ogies if I missed it. I'm trying to understand why libbitcoin (or any node) w= ould want to support it. >>=20 >> I understand the use, when coupled with a yet-to-be-devised identity syst= em, with Bloom filter features. Yet these features are client-server in natu= re. Libbitcoin (for example) supports client-server features on an independe= nt port (and implements a variant of CurveCP for encryption and identity). M= y concern arises with application of identity to the P2P protocol (excluding= Bloom filter features). >>=20 >> It seems to me that the desire to secure against the weaknesses of BF is b= eing casually generalized to the P2P network. That generalization may actual= ly weaken the security of the P2P protocol. One might consider the proper re= solution is to move the BF features to a client-server protocol. >>=20 >> The BIP does not make a case for other scenarios, or contemplate the sign= ificant problems associated with key distribution in any identity system. Gi= ven that the BIP relies on identity, these considerations should be fully ve= tted before heading down another blind alley. > In my opinion, the question should be "why would you _not_ encrypt". 1) creation of a false sense of security 2) as a tradeoff against anonymity 3) benefit does not justify cost > 1) Transaction censorship > ISPs, WIFI provider or any other MITM, can holdback/censor unconfirmed > transactions. Regardless if you are a miner or a validation/wallet node. >=20 > 2) Peer censorship > MITM can remove or add entries from a "addr" message. >=20 > 3) Fingerprinting > ISPs or any other MITM can intercept/inject fingerprinting relevant > messages like "mempool" to analyze the bitcoin network. Encryption alone cannot protect against a MITM attack in an anonymous and pe= rmissionless network. This is accepted in the BIP (and your follow-up reply)= . > 4) SPV > For obvious reasons regarding BF (see BIP or above). >=20 > 5) Goundwork for a "client-server" model over the P2P channel > Fee estimation, bloom-filters, or any other message type that requires > authentication. I do not challenge the usefulness and appropriateness of encryption with aut= hentication in a client-server blockchain protocol. > I would not reduce BIP151 to only solve the BF privacy/censorship problem.= >=20 > If we agree that censorship-resistance is one of the main properties of Bi= tcoin, We do. > then we should definitively use a form of end-to-end encryption between no= des. Built into the network layer. This is the assumption that I'm questioning. > There are plenty of other options to solve this problem. stunnel, > Bernsteins CurveCP, VPN, etc. which are available since years. > But the reality has shown that most bitcoin traffic is still unencrypted. The question arises from concern over the security of the network in the cas= e where encryption (and therefore authentication) is pervasive. As you point out, anyone can set up a private network of nodes today. These n= odes must also connect to the permissionless network to maintain the chain. T= hese nodes constitute a trust zone within Bitcoin. This zone of exclusion op= erates as a single logical node from the perspective of the Bitcoin security= model (one entity controls the validation rules for all nodes). Widespread application of this model is potentially problematic. It is a non= -trivial problem to design a distributed system that requires authentication= but without identity and without central control. In fact this may be more c= hallenging than Bitcoin itself. Trust on first use (TOFU) does not solve thi= s problem. In my opinion this question has not received sufficient consideration to war= rant proceeding with a network encryption scheme (which concerns me as well,= but as I consider it premature I won't comment). > Example: IIRC non of the available SPV wallets can "speak" on of the > possible encryption techniques. Encrypting traffic below the application > layer is extremely hard to set up for non-experienced users. Bloom filters can (and IMO should) be isolated from the P2P protocol. Also, i= f the proposal creates an insecurity its ease of deployment is moot. > On top of that, encryption allows us to drop the SHA256 checksum per p2p > message which should result in a better performance on the network layer > once BIP151 is deployed. I would not consider this a performance enhancing proposal. Simply dropping t= he checksum seems like a better option. But again, it is moot if it creates a= n insecurity. > I agree that BIP151 _must_ be deployed together with an authentication > scheme (I'm working on that) to protect again MITM during encryption > initialization. At a minimum I would propose that you modify BIP151 to declare a dependency o= n a future BIP, making BIP151 incomplete without it. I think we can agree th= at it would be unadvisable to deploy (and therefore to implement) encryption= alone. I'll respond to the question of authentication in your follow-up post. e > --- > >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev