path: root/b4/4049756739a1e8e5f37f19ca1c05a39c49ef06

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D2EFC308
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Jun 2016 16:46:02 +0000 (UTC)
Received: by mail-wm0-f48.google.com with SMTP id f126so148014935wma.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <eric@voskuil.org>
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 <dev@jonasschnelli.ch>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev@=
lists.linuxfoundation.org> 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

> ---
> </jonas>
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev