From: Eric Voskuil <eric@voskuil•org>
To: Gregory Maxwell <greg@xiph•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Date: Wed, 29 Jun 2016 01:33:53 +0200 [thread overview]
Message-ID: <AB9C1C8F-7369-42CC-8551-7E03B16D5229@voskuil.org> (raw)
In-Reply-To: <CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com>
On Jun 28, 2016, at 9:55 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> I understand the use, when coupled with a yet-to-be-devised identity system, with Bloom filter features. Yet these features
>
> This is a bit of a strawman, you've selected a single narrow usecase which isn't proposed by the BIP and then argue it is worthless. I agree that example doesn't have much value (and I believe that
> eventually the BIP37 bloom filters should be removed from the protocol).
I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as its justifying scenario.
> 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. If one can observe the encrypted traffic one can certainly use a timing attack to determine what the node has sent.
> 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?
> 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.
> Along the way BIP151 appears that it will actually make the protocol faster.
>
>> Given that the BIP relies on identity
>
> This is untrue. The proposal is an ephemerally keyed opportunistic
> encryption system. The privacy against a network observer does not depend on authentication, much less "identity". And when used with authentication at all it makes interception strongly detectable after the fact.
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.
>> The BIP does not [...] contemplate the significant problems associated with key distribution in any identity system
>
> Because it does not propose any "identity system" or authorization (also, I object to your apparent characterization of authentication as as an 'identity system'-- do you also call Bitcoin addresses an identity system?).
Please read more carefully what I wrote. I did not characterize authentication as an identity system. I proposed that key distribution has significant problems, and used identity systems as an example of systems with such problems. I could just have easily written "authentication systems", (and probably should have).
> That said, manually maintaining adds nodes to your own and somewhat trusted nodes is a recommend best practice for miners and other high value systems which is rendered much less effective due to a lack of
> authentication, there is no significant key distribution problem in that case
This is the only legitimate scenario that I am aware of. Doing this by IP address (as we do) is weak if there is no VPN.
Yet this scenario is very different than general authentication. This scenario is a set of nodes that is essentially a single logical node from the perspective of the Bitcoin security model. One entity controls the validation rules, or is collaborating with another entity to do so.
My concern is that a general authentication requirement expands this single logical node and gives control over if to the entity that controls key distribution - the hard problem that hasn't been addressed.
If there is no such entity restricting access to the network (which hopefully we can assume) then there is no reason to expect any effective improvement, since nodes will necessarily have to connect with anonymous peers. Anyone with a node and the ability to monitor traffic should remain very effective.
> and I expect the future auth BIP (Jonas had one before, but it was put aside for now to first focus on the link layer encryption)
> to address that case quite well.
Defining an auth implementation is not a hard problem, nor is it the concern I have raised.
e
next prev parent reply other threads:[~2016-06-28 23:33 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 [this message]
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
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=AB9C1C8F-7369-42CC-8551-7E03B16D5229@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