To: bitcoin-dev@lists.linuxfoundation.org
References: <87h9cecad5.fsf@rustcorp.com.au>
	<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <577234A4.3030808@jonasschnelli.ch>
Date: Tue, 28 Jun 2016 10:26:12 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
	Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="5Mwj3D6vvqbmkODoP5NfJ31RdxhGowE6a"
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--5Mwj3D6vvqbmkODoP5NfJ31RdxhGowE6a
Content-Type: multipart/mixed; boundary="5qHNA5XS620cvTbWMSkP0dg5xLvFphD8H"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <577234A4.3030808@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] BIP 151
References: <87h9cecad5.fsf@rustcorp.com.au>
 <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
In-Reply-To: <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>

--5qHNA5XS620cvTbWMSkP0dg5xLvFphD8H
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Eric

> I haven't seen much discussion here on the rationale behind BIP 151. Ap=
ologies if I missed it. I'm trying to understand why libbitcoin (or any n=
ode) would want to support it.
>=20
> I understand the use, when coupled with a yet-to-be-devised identity sy=
stem, with Bloom filter features. Yet these features are client-server in=
 nature. Libbitcoin (for example) supports client-server features on an i=
ndependent port (and implements a variant of CurveCP for encryption and i=
dentity). My concern arises with application of identity to the P2P proto=
col (excluding Bloom filter features).
>=20
> It seems to me that the desire to secure against the weaknesses of BF i=
s being casually generalized to the P2P network. That generalization may =
actually weaken the security of the P2P protocol. One might consider the =
proper resolution 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 si=
gnificant problems associated with key distribution in any identity syste=
m. Given that the BIP relies on identity, these considerations should be =
fully vetted before heading down another blind alley.


In my opinion, the question should be "why would you _not_ encrypt".


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.

2) Peer censorship
MITM can remove or add entries from a "addr" message.

3) Fingerprinting
ISPs or any other MITM can intercept/inject fingerprinting relevant
messages like "mempool" to analyze the bitcoin network.

4) SPV
For obvious reasons regarding BF (see BIP or above).

5) Goundwork for a "client-server" model over the P2P channel
Fee estimation, bloom-filters, or any other message type that requires
authentication.

I would not reduce BIP151 to only solve the BF privacy/censorship problem=
=2E

If we agree that censorship-resistance is one of the main properties of
Bitcoin, then we should definitively use a form of end-to-end encryption
between nodes. Built into the network layer.

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.=

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.

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 agree that BIP151 _must_ be deployed together with an authentication
scheme (I'm working on that) to protect again MITM during encryption
initialization.

---
</jonas>


--5qHNA5XS620cvTbWMSkP0dg5xLvFphD8H--

--5Mwj3D6vvqbmkODoP5NfJ31RdxhGowE6a
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXcjSkAAoJECnUvLZBb1PsLvwP/0vgFiLeh8+YaUB9WY47Yogq
5yHfOJgCELZhrDsVLYm7b45K8MoJ+ASTw7PMBIfwyBdOqdKIO5JhC6oxwxX/fOTV
PynJossiRt+5aV5xPWcwM0H1PIuM3xRXQC429QG3DbyMLhZldS5oP3BQZ58Nl4rt
8C6G1o8BEJT1PXl8cWNo6M3a8IXCzsV3d5h7VS4ei7X5JEcrKZb1jHFLyizfa0qH
nEIQioyH3Qmx6mN1VWuwn/lIzVLB3bxb9FSfQnrLkjhHFT9r0BkewhYiPkbbzuhW
25O3hBn8ilAWph98RTl0Tgp8aZhso+1AfkPZlbtBSMnHtTePq5xiy1YX1RCF3KUx
1igDIonHAzOLyC9s8/NTLEYTKkFp7QKF2LqYLWpdWEAzuJ04hqCOii2OMasc1jll
GPgPb34UbyEbt9igwmp4c567MGl4wFx5H9Q7BiV279XIxkkmCFPanCH5vq0nWkvM
3BO6N1dx5OnOl+BIdkL6e0GBAX9Fm4pKJbjyMrR/a6YdQHf14we5B56e0BCTwJ+T
9UyURFs55oYns5BVV6zhjcu33nuHaPJasgb3yVIfb9GGvdkYY5h+CsJlIH79Pl+J
hniyL6cCYYUGbH4gRBfo/j+mWovi0+8ugn844mBbysPFeYuIN2iOh9C6bikFXaqZ
dYhvqjTYhJHsxTSLly5Q
=PAqa
-----END PGP SIGNATURE-----

--5Mwj3D6vvqbmkODoP5NfJ31RdxhGowE6a--