From: Gregory Maxwell <greg@xiph•org>
To: Eric Voskuil <eric@voskuil•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Date: Wed, 29 Jun 2016 01:01:50 +0000 [thread overview]
Message-ID: <CAAS2fgT4V72vj17qTLu7pz5EQ60bqnggeDnTP5ASdwYxpuNpWw@mail.gmail.com> (raw)
In-Reply-To: <AB9C1C8F-7369-42CC-8551-7E03B16D5229@voskuil.org>
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
>> 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.
> 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)
>> 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.
>> 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
itercepting all your connections out.
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.
> 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.
> 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.
> Anyone with a node and the ability to monitor traffic should remain very effective.
Not via passive observation.
> Defining an auth implementation is not a hard problem, nor is it the concern I have raised.
Glad you agree.
We seem to be looping now. Feel free to not implement this proposal,
no one suggests making it mandatory.
next prev parent reply other threads:[~2016-06-29 1:01 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 [this message]
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=CAAS2fgT4V72vj17qTLu7pz5EQ60bqnggeDnTP5ASdwYxpuNpWw@mail.gmail.com \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@voskuil$(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