public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil•org>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Date: Wed, 29 Jun 2016 01:34:33 +0200	[thread overview]
Message-ID: <D317F7C9-C645-455F-8BA6-EB9F6D09F39F@voskuil.org> (raw)
In-Reply-To: <CAAS2fgQ0Ocs8hF+pf+fWfkKKhQwxNKpY=JHpb_bwua7neVO8tg@mail.gmail.com>



>> On Jun 29, 2016, at 12:22 AM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
>> 
>> On Tue, Jun 28, 2016 at 9:59 PM, Eric Voskuil <eric@voskuil•org> wrote:
>> Passing the session ID out of band is authentication. As this is explicitly not part of BIP151 it cannot be that BIP151 provides the tools to detect a attack (the point at issue).
> 
> It provides the ID, the rest is meat.

The rest is "authentication".

> Users can compare session IDs
> via whatever communications channels they already use after the fact
> and discover if they were or are being MITMed.
> 
>>>> It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
>>> 
>>> One might wonder how you ever use a Bitcoin address, or even why we might guess these emails from "you" aren't actually coming from the NSA.
>> 
>> The sarcasm is counterproductive Greg. By the same token I could ask how you ever use Bitcoin given that the P2P protocol is not encrypted or authenticated.
> 
> I think I was unclear. A bitcoin address needs to be sent over a secure channel, which we do not provide. Yet sending funds to addresses instead of anyone_can_spend is pretty useful.
> 
> Similarly, I can guess that messages claiming to you are probably from you when many people can independently check, even if they don't usually. The fact tampered messages might be detected is a big disincentive from trying.

You were perfectly clear. Did I give some indication that I did not understand what you meant?

>> The blockchain and mempool are a cache of public data. Transmission of a payment address to a payer is not a comparable scenario.
> 
> The precise timing and ordering of transactions being relayed is _not_
> public data.

Posting txs to the network is a client-server scenario. The set of txs arriving at an arbitrary node, including the order of arrival, is by definition public information. The only possible way it could be considered private is if the entire network was private.

So where does the private timing become public? First hop, second, third?

Encryption and authentication cannot prevent timing attacks against a person posting txs to the network unless the entire network is "secured". That is not possible without centralized access control.

Encrypting the P2P network doesn't resolve this problem, nor does authentication, nor does Tor. I would prefer we advance an actual solution to this significant problem than advance a false sense of security while creating both complexity and the likely evolution of node identity.

e

  parent reply	other threads:[~2016-06-28 23:34 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 [this message]
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
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=D317F7C9-C645-455F-8BA6-EB9F6D09F39F@voskuil.org \
    --to=eric@voskuil$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=gmaxwell@gmail$(echo .)com \
    /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