From: Eric Voskuil <eric@voskuil•org>
To: Jonas Schnelli <dev@jonasschnelli•ch>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Date: Tue, 28 Jun 2016 19:39:41 +0200 [thread overview]
Message-ID: <2E638F35-D212-43B7-A9AB-7D7C33CFF781@voskuil.org> (raw)
In-Reply-To: <577269E7.6020008@jonasschnelli.ch>
continued from previous post...
> On Jun 28, 2016, at 2:13 PM, Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hi Eric
>
> Sorry for not directly addressing your points.
No problem. Thanks for the detailed replies.
> I try to be more precise in this follow up email:
>
>> I understand the use, when coupled with a yet-to-be-devised identity system, with Bloom filter features. Yet these features are client-server in nature. Libbitcoin (for example) supports client-server features on an independent port (and implements a variant of CurveCP for encryption and identity). My concern arises with application of identity to the P2P protocol (excluding Bloom filter features).
>
> I think the bloom filter SPV usecase is not "pure client-server". SPV
> clients could request from/broadcast to multiple "trusted nodes".
I have referred to the Bloom filters messages. These are clearly asymmetric in nature. Despite being possible it is not a valid use case for a full node to make BF requests to another node.
One client to multiple servers is still client-server for the sake of this discussion. The nature of the P2P protocol is synchronization of content between all nodes/peers. If the protocol is asymmetric the semantics, and therefore use cases, are different.
FWIW posting a transaction to the network can be done using the P2P protocol, connecting for a short period of time. But this is also a client-server scenario and is a hack when done (full disclosure, bx provides both P2P and client-server commands for tx posting). Broadcasting is naturally the behavior of a full node.
> Trusted nodes could be nodes where the operators have shared identities/keys in advance over a different channel.
Yes, this is necessarily the case in order to prevent a MITM attack. This is the basis of my concern.
> Further private p2p extensions (lets say a p2p form of the estimatefee
> command) are something which needs to be discussed first and not
> something that is encouraged or outlined in BIP151.
Sure, but then let us not make assumptions about it in the context of this discussion. Libbitcoin provides fee estimation by monitoring broadcast penetration using a client-server protocol with an optional subscription mechanism.
>> It seems to me that the desire to secure against the weaknesses of BF is 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.
>
> I don't see reasons why BIP151 could weaken the security of the P2P network. Can you point out some specific concerns?
TOFU cannot prevent MITM attacks (the goal of the encryption). Authentication requires a secure (trusted) side channel by which to distribute public keys. This presents what I consider a significant problem. If widespread, control over this distribution network would constitute control over who can use Bitcoin.
The effort to prevent censorship could actually enable it. I don't think it would get that far. Someone would point this out in the process of vetting the authentication BIP, and the result would be the scrapping of BIP151.
>> The BIP does not make a case for other scenarios, or contemplate the significant problems associated with key distribution in any identity system. Given that the BIP relies on identity, these considerations should be fully vetted before heading down another blind alley.
>
> BIP151 does not rely on identities. BIP151 does not use persisted keys
> (only ephemeral keys).
BIP 151 is incomplete without authentication.
> The authentication/identity system needs to be described in a another BIP.
> But correct, BIP151 without a form of authentication/identity management
> is vulnerable to all sorts of MITM attacks and that's why I think BIP151
> must be deployed together with an p2p authentication scheme.
Agree, but my problem is that I do not believe we can assume this is a solvable problem.
> Scope creeping and the risks of overspecifying is the main reason to
> focus on the "pure encryption part" in BIP151.
Understood, yet this is the basis of my blind alley comment.
e
> Thanks
> ---
> </jonas>
next prev parent reply other threads:[~2016-06-28 17:39 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-28 2:31 [bitcoin-dev] BIP 151 use of HMAC_SHA512 Rusty Russell
2016-06-28 7:17 ` [bitcoin-dev] BIP 151 Eric Voskuil
2016-06-28 8:26 ` Jonas Schnelli
2016-06-28 16:45 ` Eric Voskuil
2016-06-28 18:22 ` Peter Todd
2016-06-28 18:35 ` Eric Voskuil
2016-06-28 20:14 ` Peter Todd
2016-06-28 20:29 ` Eric Voskuil
2016-06-28 20:36 ` Peter Todd
2016-06-28 21:22 ` Eric Voskuil
2016-06-28 21:36 ` Gregory Maxwell
2016-06-28 21:40 ` Cameron Garnham
2016-06-28 22:07 ` Eric Voskuil
2016-06-28 22:33 ` Cameron Garnham
2016-06-28 23:29 ` Eric Voskuil
2016-06-29 0:06 ` Nick ODell
2016-06-28 21:59 ` Eric Voskuil
[not found] ` <CAAS2fgQ0Ocs8hF+pf+fWfkKKhQwxNKpY=JHpb_bwua7neVO8tg@mail.gmail.com>
2016-06-28 23:34 ` Eric Voskuil
2016-06-28 20:06 ` Jonas Schnelli
2016-06-28 23:31 ` Eric Voskuil
2016-06-29 11:17 ` Alfie John
2016-06-30 11:56 ` Eric Voskuil
2016-06-30 12:20 ` Jonas Schnelli
2016-06-30 12:27 ` Eric Voskuil
2016-06-30 12:43 ` Jonas Schnelli
2016-06-30 15:22 ` Eric Voskuil
2016-06-30 16:52 ` Peter Todd
2016-06-30 18:25 ` Eric Voskuil
2016-06-30 19:06 ` Peter Todd
2016-06-30 20:26 ` Eric Voskuil
2016-06-28 19:55 ` Gregory Maxwell
2016-06-28 23:33 ` Eric Voskuil
2016-06-29 1:01 ` Gregory Maxwell
2016-06-30 9:57 ` Eric Voskuil
2016-06-30 13:03 ` Pieter Wuille
2016-06-30 15:10 ` Eric Voskuil
2016-08-31 14:29 ` Pieter Wuille
2016-06-30 13:36 ` Erik Aronesty
2016-06-30 14:47 ` Alfie John
2016-07-02 9:44 ` Chris Priest
2016-06-28 12:13 ` Jonas Schnelli
2016-06-28 17:39 ` Eric Voskuil [this message]
2016-06-28 7:19 ` [bitcoin-dev] BIP 151 use of HMAC_SHA512 Jonas Schnelli
2016-06-28 8:31 ` Arthur Chen
2016-06-29 18:34 ` Jonas Schnelli
2016-06-29 20:13 ` Peter Todd
2016-06-29 20:31 ` Jonas Schnelli
2016-06-29 1:00 ` Rusty Russell
2016-06-29 1:38 ` Arthur Chen
2016-06-29 1:56 ` Ethan Heilman
2016-06-29 6:58 ` Pieter Wuille
2016-06-29 14:38 ` Ethan Heilman
2016-06-29 18:46 ` Jonas Schnelli
2016-07-01 3:25 ` Rusty Russell
2016-07-01 22:42 ` Zooko Wilcox
2016-07-04 1:23 ` Arthur Chen
2016-07-04 1:44 ` Arthur Chen
2016-07-04 6:47 ` Jonas Schnelli
2016-07-04 6:37 ` Jonas Schnelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2E638F35-D212-43B7-A9AB-7D7C33CFF781@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dev@jonasschnelli$(echo .)ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox