public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <greg@xiph.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:55:37 +0000	[thread overview]
Message-ID: <CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com> (raw)
In-Reply-To: <577234A4.3030808@jonasschnelli.ch>

> 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).

Without something like BIP151 network participants cannot have privacy
for the transactions they originate within the protocol against
network observers. 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.

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.

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.

> 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?).

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, 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.


  parent reply	other threads:[~2016-06-28 19:55 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 [this message]
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
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=CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com \
    --to=greg@xiph.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dev@jonasschnelli.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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