diff options
| author | Jonas Schnelli <dev@jonasschnelli.ch> | 2017-02-14 21:58:54 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-02-14 20:59:16 +0000 |
| commit | 600b97c99b9e375acbb2fc10f67e9093b9e3fa4c (patch) | |
| tree | 659928c4d82fb0c3ebec6b09fe264773fa215129 | |
| parent | ad72ad50d2c9f24619bdb94fdade0679232a2f2e (diff) | |
| download | pi-bitcoindev-600b97c99b9e375acbb2fc10f67e9093b9e3fa4c.tar.gz pi-bitcoindev-600b97c99b9e375acbb2fc10f67e9093b9e3fa4c.zip | |
Re: [bitcoin-dev] BIP151 protocol incompatibility
| -rw-r--r-- | d4/fbf7a7ab0b5c5c610805b888b45e9963bdad22 | 285 |
1 files changed, 285 insertions, 0 deletions
diff --git a/d4/fbf7a7ab0b5c5c610805b888b45e9963bdad22 b/d4/fbf7a7ab0b5c5c610805b888b45e9963bdad22 new file mode 100644 index 000000000..cfb4abe7c --- /dev/null +++ b/d4/fbf7a7ab0b5c5c610805b888b45e9963bdad22 @@ -0,0 +1,285 @@ +Return-Path: <dev@jonasschnelli.ch> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 716B040C + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 14 Feb 2017 20:59:16 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from server3 (server3.include7.ch [144.76.194.38]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id 42BBEF4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 14 Feb 2017 20:59:15 +0000 (UTC) +Received: by server3 (Postfix, from userid 115) + id 402EC2E6010C; Tue, 14 Feb 2017 21:59:14 +0100 (CET) +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Spam-Level: +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1 + autolearn=ham version=3.3.1 +Received: from Jonass-MacBook-Pro.local (cable-static-140-182.teleport.ch + [87.102.140.182]) by server3 (Postfix) with ESMTPSA id BF2352D0022C; + Tue, 14 Feb 2017 21:59:10 +0100 (CET) +To: Eric Voskuil <eric@voskuil.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + libbitcoin@lists.dyne.org +References: <ba422d5e-8e96-3475-2a29-80d89fd67322@voskuil.org> + <CAPg+sBhDjVuN6=tdvUcSY5OCdJD7s3Jp90K1qx0iRX+2WppUQQ@mail.gmail.com> + <dde5349d-c430-ad57-30c7-77954ff1a94d@voskuil.org> + <ff7c24ba-7c70-efaf-a319-b1aebfd8a3bd@jonasschnelli.ch> + <638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org> + <e153823d-e38e-b4b6-01d5-b9d981381e01@jonasschnelli.ch> + <17f2f92c-68fc-7a7d-c015-9bad810365e3@voskuil.org> +From: Jonas Schnelli <dev@jonasschnelli.ch> +Message-ID: <2c059f3c-620e-4324-0726-4c56dfab0b43@jonasschnelli.ch> +Date: Tue, 14 Feb 2017 21:58:54 +0100 +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) + Gecko/20100101 Thunderbird/45.5.1 +MIME-Version: 1.0 +In-Reply-To: <17f2f92c-68fc-7a7d-c015-9bad810365e3@voskuil.org> +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; + boundary="C20EkEHwx3fuv7xSkACFUJGacxpsGlrSs" +Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility +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, 14 Feb 2017 20:59:16 -0000 + +This is an OpenPGP/MIME signed message (RFC 4880 and 3156) +--C20EkEHwx3fuv7xSkACFUJGacxpsGlrSs +Content-Type: multipart/mixed; boundary="GdxnCHx1xPlPL9QlNl1p9nIdW7w9wkx3s"; + protected-headers="v1" +From: Jonas Schnelli <dev@jonasschnelli.ch> +To: Eric Voskuil <eric@voskuil.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + libbitcoin@lists.dyne.org +Message-ID: <2c059f3c-620e-4324-0726-4c56dfab0b43@jonasschnelli.ch> +Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility +References: <ba422d5e-8e96-3475-2a29-80d89fd67322@voskuil.org> + <CAPg+sBhDjVuN6=tdvUcSY5OCdJD7s3Jp90K1qx0iRX+2WppUQQ@mail.gmail.com> + <dde5349d-c430-ad57-30c7-77954ff1a94d@voskuil.org> + <ff7c24ba-7c70-efaf-a319-b1aebfd8a3bd@jonasschnelli.ch> + <638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org> + <e153823d-e38e-b4b6-01d5-b9d981381e01@jonasschnelli.ch> + <17f2f92c-68fc-7a7d-c015-9bad810365e3@voskuil.org> +In-Reply-To: <17f2f92c-68fc-7a7d-c015-9bad810365e3@voskuil.org> + +--GdxnCHx1xPlPL9QlNl1p9nIdW7w9wkx3s +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable + + +>> This indeed is not ideal for compatibility checks, but increases secur= +ity. +> The issue I raised is that it is not backward compatible. It sounds lik= +e +> you agree but consider it a fair trade. My suggesting was that the BIP +> be updated to reflect the lack of compatibility. +It's still backward compatible. All (?) SPV clients and full node +implementation would still work if BIP151 has been implemented. +Isn't that backward compatibility? +>> I could not find a protocol specification that said communication must= + +>> be terminated when messages are transmitted before the version handsha= +ke +>> has been done. +> It doesn't need to be specified, most of Bitcoin is unspecified. The +> version handshake establishes the negotiated version. It is not possibl= +e +> to determine if a message is of the negotiated version before the +> version is negotiated. All messages apart from this one have followed +> that rule. +Yes. But encryption negotiation must be done before the version +handshake (security). +> +>> Also. BIP151 clearly says that the requesting peer needs to initiate t= +he +>> encryption (encinit). +> An incoming connection will be dropped due to invalid protocol and +> potentially banned depending on the implementation. +This is not true. If the connecting peer (assume the SPV client) will +not request encryption, the responding peer (the node) will not enforce +or ask for encryption. +This is clearly written in the BIP. +>> It could very likely be possible that the initial responding peer trie= +s +>> to initiate a encryption session which would mean that BIP151 was not +>> implemented correctly. +>> Correct me if I'm wrong please. +> I did consider the possibility, but there's this: +> +> "Encryption initialization must happen before sending any other message= +s +> to the responding peer (encinit message after a version message must be= + +> ignored)." +> +> https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#specific= +ation +> +> The BIP does not define "responding" and "requesting" peers, but: +> +> "A peer that supports encryption must accept encryption requests from +> all peers... The responding peer accepts the encryption request by +> sending a encack message." +> +> This implies the requesting peer is the peer that sends the message. Yo= +u +> seem to be saying that the requesting peer is the one that initiated +> the connection and the responding peer is the connection receiver. If +> this is the case it should be more clearly documented. But in the +> case I experienced the "requester" of an encrypted session was also +> the "receiver" of the connection. +I think the BIP makes this very clear. IMO you are trying to hide your +standpoint behind a wired interpretations of the BIP. + +=46rom the BIP: +=C2=ABTo request encrypted communication, the requesting peer generates a= +n EC +ephemeral-session-keypair and sends an encinit message to the responding +peer and waits for a encack message. The responding node must do the +same encinit/encack interaction for the opposite communication direction.= +=C2=BB + +This seems to be pretty clear to me. You can interpret the "requesting +peer" and "responding peer" per message interaction. But then the whole +BIP would make no sense. + +I'm happy if you can do a PR on the BIP that makes the wording better. +This would actually be a productive step. +> +>>>> Or do I make a mistake somewhere? +>>> Yes, the ordering of the messages. New messages can only be added aft= +er +>>> the handshake negotiates the higher version. Otherwise the handshake = +is +>>> both irrelevant (as Pieter is implying) and broken (for all existing +>>> protocol versions). +>> I could not find evidence of the protocol specification that would +>> forbid (=3Dterminate connection) such messages and I think allowing +>> unknown-messages before the version handshake makes the protocol flexi= +ble. +> Flexible is certainly one word for it. Another way to describe it is +> dirty. Allowing invalid messages in a protocol encourages protocol +> incompatibility. You end up with various implementations and eventually= + +> have no way of knowing how they are impacted by changes. There could be= + +> a range of peers inter-operating with the full network while running +> their own sub-protocols. Given the network is public and strong +> identification of peers is undesirable, the invalid messages would +> reasonably just get sent to everyone. So over time, what is the +> protocol? Due to certain "flexibility" it is already a hassle to +> properly implement. +Then you would have to go after all BIPs deployed this way. This +argument has nothing to do with BIP151 it questions the whole new +protocol features deployment. +Again, check this code part: + +https://github.com/bitcoin/bitcoin/blob/a06ede9a138d0fb86b0de17c42b936d9f= +e6e2158/src/net_processing.cpp#L2595 + + +> +>> Are there any reasons we should drop peers if they send us unknown, bu= +t +>> correctly formatted p2p packages (magic, checksum, etc.) before the +>> version handshake, ... but not drop them if we have received unknown +>> messages after the version handshake? +> There is no reason to treat invalid messages differently based on where= + +> they occur in the communication. After the handshake the agreed version= + +> is known to both peers. As a result there is never a reason for an +> invalid message to be sent. Therefore it is always proper to drop a pee= +r +> that sends an invalid message. +That's up to the implementation. But the current flexibility exists +because we not drop. +Again, see above. +>> I can't see that a such spec. would reduce the DOS attack vector? +> This was previously addressed (immediately below). +No. I'd like to hear from you why the DOS attack vector would be larger +if the encryption neg. would be after the version handshake. +> +>>>>> As for DOS, waste of bandwidth is not something to be ignored. If a= + peer +>>>>> is flooding a node with addr message the node can manage it because= + it +>>>>> understands the semantics of addr messages. If a node is required t= +o +>>>>> allow any message that it cannot understand it has no recourse. It +>>>>> cannot determine whether it is under attack or if the behavior is +>>>>> correct and for proper continued operation must be ignored. +>>>> How do you threat any other not known message types? +>>> You may be more familiar with non-validating peers. If a message type= + is +>>> not known it is an invalid message and the peer is immediately droppe= +d. +>>> We started seeing early drops in handshakes with bcoin nodes because = +of +>>> this issue. +> Yes, this is the purpose of version negotiation, which is why there are= + +> version and verack messages. And this is also why, in the satoshi +> client, two of the above messages are sent from the verack handler. The= + +> feefilter message is sent dynamically but only if the peer's version +> allows it. + +Again. Encryption =E2=80=93 for the sake of security =E2=80=93 must be th= +e first +interaction. +This is exceptional for BIP151 and I'd like to hear the real downsides +of doing that. +> +>> You can't link a (unimplemented) specification (improvement process) t= +o +>> a protocol version before deployment. Or can you? +> I'm not sure I follow your question. The BIP should presumably declare = +a +> version number if one is necessary. +What? You want to define protocol version number in draft improvement +specifications? +How should that be possible? +It's like defining a new HTML version number if you propose/draft a new +video streaming format. + + +</jonas> + + +--GdxnCHx1xPlPL9QlNl1p9nIdW7w9wkx3s-- + +--C20EkEHwx3fuv7xSkACFUJGacxpsGlrSs +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: OpenPGP digital signature +Content-Disposition: attachment; filename="signature.asc" + +-----BEGIN PGP SIGNATURE----- + +iQIzBAEBCAAdFiEEMu5cTD+hXMrbRqvlKdS8tkFvU+wFAlijb5oACgkQKdS8tkFv +U+xk3g/+M+S9G5XmYl1HzveOHDbtg3oGgHhBHnndIfDOfdcP1NRgCiHdiOFQfzSR +ewAl5uEcE1j0Vscd25N70L+rI/jbUWT+814+j5Rvy+j8afW6OHGsG712WkDt219H +/Z0tUNL1+gVDh8qwTCxv0QhHhsf/SS/gsDqJdS1QjIdKYm78mQWuQXyGv/OnoO7c +1mXEOnXGWpETH1AYV8is8eHN22XMJHT9G/Pt3GFJFGzjsfFRZpvcUVpqgSlfnoYN +EEBbyUORANcT1uGejCUoZ5hhqixeiW3DfXQrhJMgnfb/cP/08T2zXuoXV2gu4sf5 +yflY8EDMK4QYn6d2xcpsVi/gItUa7SBtMnXPbUTruHnc3xC3Qv58okKEI/p83PV0 +/MJ2W9MNynjbWRkDMRX60FJkIQv+eCTDFI+IVrcpvf42anxxLSCK3MW4Armrtyeu +UEL/rKkCKilsdxAETRqsJ29Ty+qXZUZ5g1woybK7292Ikdbek3xAfb9BZTU/I4bV +ttRt+B3wzpZLg7LX1kIESFHqGCkJuptHeOaB7tfzZ7Q6pxGb11qBixz9MvIH3RoN +btZ+hjYjs/Fb8SdJAv9z4K1c3cVwadA20TmlLZGx/ROholPx0dvIduFeWSJE6aGm +TA4ACZfHeVC4xuMt41kY6y4uqWhG6iZ2ah+Ozq+NM6BoL+vPaA4= +=bL43 +-----END PGP SIGNATURE----- + +--C20EkEHwx3fuv7xSkACFUJGacxpsGlrSs-- + |