From: Eric Voskuil <eric@voskuil•org>
To: Gregory Maxwell <greg@xiph•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Date: Thu, 30 Jun 2016 11:57:02 +0200 [thread overview]
Message-ID: <CB6D8DF2-3EB7-4A12-8861-494D1DBC3D93@voskuil.org> (raw)
In-Reply-To: <CAAS2fgT4V72vj17qTLu7pz5EQ60bqnggeDnTP5ASdwYxpuNpWw@mail.gmail.com>
On Jun 29, 2016, at 3:01 AM, Gregory Maxwell <greg@xiph•org> wrote:
>
>> On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil <eric@voskuil•org> wrote:
>> I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as its justifying scenario.
>
> It cites SPV as an example, doesn't mention bloom filters.. and sure-- sounds like the bip text should make the
"MOTIVATION:
The Bitcoin network does not encrypt communication between peers today. This opens up security issues (eg: traffic manipulation by others) and allows for mass surveillance / analysis of bitcoin users. Mostly this is negligible because of the nature of Bitcoins trust model, however for SPV nodes this can have significant privacy impacts [1] and could reduce the censorship-resistance of a peer."
This is not an example, this is the exception that is described as "significant" in comparison to the other issues, which are described as "negligible".
The Bloom filters messages are of course the unique aspects of the protocol as it pertains to "SPV".
The RISKS section declares that the BIP cannot prevent MITM attacks and that "identity authentication" will be defined in a forthcoming BIP.
The obvious implication (accepted by the author) is that authentication is required to prevent a MITM attack, and furthermore establishment of identity will be required to ensure that the authenticated party is not a bad actor.
>>> Without something like BIP151 network participants cannot have privacy for the transactions they originate within the protocol against network observers.
>>
>> And they won't get it with BIP151 either. Being a peer is easier than observing the network.
>
> Not passively, undetectable, and against thousands of users at once at low cost.
This is a straw man, as the BIP does not state that its objective is to moderately raise the cost of passive attack against large numbers of users.
It is also a red herring, as passivity is not itself a benefit. It implies that the attack is easier and therefore less costly. But a trivial active attack may be a larger security problem than a complex passive attack. Attacks against privacy under this BIP (and with authentication) can be carried out by passively monitoring traffic and operating one or more nodes. Operating a node may be considered "active" because the node communicates, but technically it is not. In either case the activeness itself hardly raises the difficulty, especially for a global (thousands of users) passive attacker.
Depending on the attacker, cost may not be an issue at all, so raising it can have zero effect. Certainly we are not talking about prohibitive (cryptographically hard) cost. Raising the cost *any* amount is not likely a reasonable cost-benefit tradeoff.
Privacy attacks would remain entirely undetectable under this proposal, and under any additional proposal that required authentication in the absence of identity. Only with all users of the network identified as "good" would such proposals be effective. Until that point any bad actors can become an integral part of the network. I will investigate the question of identity in a follow-up to an independent post.
>> If one can observe the encrypted traffic one can certainly use a timing attack to determine what the node has sent.
>
> Not against Bitcoin Core, transactions are batched and relayed in
> sorted order. (obviously there are limits at what this provides;
> ironically, the lack of link encryption has been used to argue against
> privacy preserving relay behavior)
It cannot be both impossible ("not against Bitcoin Core") and limited in effectiveness ("obviously there are limits").
We should be clear at this point that the transaction-posting security provided against a privacy attack, based on the assumption of "good" (identified) peers in the first few hops, derives entirely from the ability of the good peers to break the timing attack, which is itself "limited".
This is a compound pair of weak assumptions, that to be made stronger will require widespread use of identity (not just authentication).
The proliferation of node identity is my primary concern - this relates to privacy and the security of the network. Secondarily I am concerned about users operating under a false assumption about the strength of privacy. Thirdly I am concerned about the risk of vulnerability introduced by the integration into the P2P network layer of an totally new network security scheme. Fourthly I'm concerned about the cost of the above based on the belief that the benefit may not be material and that it may lead to increased centralization.
>>> Even if, through some extraordinary effort, their own first hop is encrypted, unencrypted later hops would rapidly
>>> expose significant information about transaction origins in the network.
>>
>> As will remain the case until all connections are encrypted and authenticated, and all participants are known to be good guys. Starting to sound like PKI?
>
> Huh? The first and subsequent hops obscures the origin and timing.
Described as "limited" in effectiveness, and clearly useful only if these hops are not attacker nodes.
So back to my comment on how we maintain a pool of "good" nodes for people to connect to, and raising the question of how effective is this strategy (which is itself unspecified and so cannot be assumed to even exist in the context of the BIP).
>>> Without something like BIP151 authenticated links are not possible, so
>>> manually curated links (addnode/connect) cannot be counted on to provide protection against partitioning sybils.
>>
>> If we trust the manual links we don't need/want the other links. In fact retaining the other links enables the attack you described above. Of course there is no need to worry about Sybil attacks when all of your peers are authenticated. But again, let us not ignore the problems of requiring all peers on the network be authenticated.
>
> Don't need and want them for what? For _partitioning_ resistance,
> you are not partitioned if you have one honest connection to the
> functional network. Additional peers purely reduce your partition vulnerability-- so long as an active network attacker isn't
> intercepting all your connections out.
Don't want them as peers for the purpose of tx relay. As I said this, "enables the attack you described above."
> For privacy, you have improve transaction privacy so long as your
> transaction isn't initially relayed to a malicious peer-- but
> malicious peers can lie further out because transit nodes obscure the
> order of message creation. Bitcoin Core currently relays transactions
> first and more frequently to outbound and whitelisted peers.
This whitelisting is simply a stand-in for a more formal identity system. One doesn't whitelist anonymous peers, one whitelists peers controlled by trusted parties. Preferring trusted peers is another aspect of trying to break the timing attack. So I would lump this under the same analysis as above (batching).
>> Maybe I was insufficiently explicit. By "relies on identity" I meant that the BIP is not effective without it. I did not mean to imply that the BIP itself implements an identity scheme. I thought this was clear from the context.
>
> I understood that, but my point was that Bitcoin cannot be used at all_unless users have secure communication channels to share addresses.
This is true but not relevant. The parties with whom we transact are not in the same space as the nodes with which we connect. The fact that I am face-to-face with a counterparty does not help me find a "good" node, nor does my ability to PGP email a payment address or to send a stealth address in the clear.
But the fact that you raise this point is itself instructive. The solution that was devised to resolve the problem of verifying that a counterparty is who one thinks it is ended up being based on the use of certificate authorities - despite the fact the the BIP did not require this. Some people consider this extremely dangerous for Bitcoin, enough so that Peter Todd recently proposed scrapping the BIP.
It's not clear to me how the Bitcoin community intends to establish what nodes are good nodes. But one thing is certain, any anonymous node may be an undetectable attacker.
>> then there is no reason to expect any effective improvement, since nodes will necessarily have to connect with anonymous peers.
>
> They're not required to _only_ connect with anonymous peers. And partition resistance requires that you have any one good link.
As a minimum requirement, it implies that only need only to connect to one or more "good" peers. Anonymous peers are gravy for partition resistance, yet they are potential attackers for tx tainting. In other words the logical topology is to only connect to good peers. That is a problem.
>> Anyone with a node and the ability to monitor traffic should remain very effective.
>
> Not via passive observation.
See above commentary on the irrelevance of this distinction.
>> Defining an auth implementation is not a hard problem, nor is it the concern I have raised.
>
> Glad you agree.
I don't get your point here. It seems like you are just trying to antagonize.
> We seem to be looping now. Feel free to not implement this proposal,
At this point I think it's fair for me to say that nobody needs your permission.
> no one suggests making it mandatory.
Have you ever debated an optional feature proposal?
e
next prev parent reply other threads:[~2016-06-30 9:57 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 [this message]
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
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=CB6D8DF2-3EB7-4A12-8861-494D1DBC3D93@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=greg@xiph$(echo .)org \
/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