path: root/bb/2e72cc93dc1277884e4ef9ebc64aa506d743b0

Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C93BA98D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jun 2016 13:37:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com
	[209.85.220.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CB704107
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jun 2016 13:36:59 +0000 (UTC)
Received: by mail-qk0-f181.google.com with SMTP id t127so144770031qkf.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jun 2016 06:36:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=gsCAP6vzD5SgUPJOI5x54bDB+4mLbs7RN+M8VXsEmxI=;
	b=fnYgIddiTU5w4fzFKRa34y+cM7n7EOe+eFA2fjX79ZZQaR6s5dhi589OfcgKTU1Jaj
	x8fcSVb6gIsRQ/571PddqF2uXpp+UvnZwxAb3cYvJdprWGN0xx7i6d2OpZhe4Zj9BeEB
	o+R6Kj1V9dgtd4hgmnZJcLs8aItPVdP93090FuITYqCIjkgUJPoIPwxYzzd3u29qrLYx
	il1rCYu5JvtRC4v6Hrcg1KJfl0470jlDpaMbPwbL/KS342/pQ5Bu0awryPSBTr+9/WuR
	apA9Ca8AHO/faAr9ZkddVgeFQ9WX8jz2ygP/ExRJzYZHk5E8vPbtoPoCnindIPypB1fz
	lzJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=gsCAP6vzD5SgUPJOI5x54bDB+4mLbs7RN+M8VXsEmxI=;
	b=Z19s2ANqLkqLr26K5sUU9Y0Ch/ZrP1oqH8DTO4ekiXyHQHw638gXE7CNf1DUZHKsIG
	5djkw0b+WlwDrgMV/ccHIafGdotY2d8/AdzhiPifm4QZQe4olKGSN/EI5GEvnmzyc9xM
	e7DPES2QEXPKvdBJCpUxk7DAHHy5BMREw47W4vxPy2pibV7u5N0OGdTfyZEJVT0C1XeR
	rZSGDkxqWDuN+OWn4LB771nDtTSgF2yxCDbkfT6p/eT3y5djWBz35RHi3O0iX9twVh2P
	HDmh1c/q+RT9MadYjHQj/2VEfq0tStSRSC7Iubd1ixUcjodQeUbv8mHFSY9zuLbgISiF
	qCUA==
X-Gm-Message-State: ALyK8tKT4L5P5B+tEdeDjXTjhWiUF5TYeiJLYP1Zu+DPYqhUnrso2PkqDRhBTlYVaWTcIOU/QSNo/rMkersYRg==
X-Received: by 10.13.227.196 with SMTP id m187mr6698528ywe.18.1467293818873;
	Thu, 30 Jun 2016 06:36:58 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.37.72.68 with HTTP; Thu, 30 Jun 2016 06:36:57 -0700 (PDT)
In-Reply-To: <CB6D8DF2-3EB7-4A12-8861-494D1DBC3D93@voskuil.org>
References: <87h9cecad5.fsf@rustcorp.com.au>
	<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
	<577234A4.3030808@jonasschnelli.ch>
	<CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com>
	<AB9C1C8F-7369-42CC-8551-7E03B16D5229@voskuil.org>
	<CAAS2fgT4V72vj17qTLu7pz5EQ60bqnggeDnTP5ASdwYxpuNpWw@mail.gmail.com>
	<CB6D8DF2-3EB7-4A12-8861-494D1DBC3D93@voskuil.org>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 30 Jun 2016 09:36:57 -0400
X-Google-Sender-Auth: 4AYgoH-dbBkkvCLCchcAdDWS-Ws
Message-ID: <CAJowKg+tOoEEeVh2sh3oZbnJ3dO_h4n9eBaUeZ+ys2RPD+s2vQ@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c07cfc8daeeb405367ef6c6
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP 151
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2016 13:37:03 -0000

--94eb2c07cfc8daeeb405367ef6c6
Content-Type: text/plain; charset=UTF-8

I agree.

Encrypting links in a network without identity doesn't really seem to help
enough for the costs to be justified.

I would like to see a PGP-like "web of trust" proposal for both the
security of the bitcoin network itself /and/ (eventually) of things like
transmission of bitcoin addresses.

Something where nodes of any kind (full, spv, mobile wallets) can
/optionally/ accumulate trust over time and are capable of verifying the
identity of other nodes in that web.

*Then* you can slap an encryption layer on top of it.   Once you have
identity & P2P verified pub keys for nodes, encryption becomes easy.


On Thu, Jun 30, 2016 at 5:57 AM, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--94eb2c07cfc8daeeb405367ef6c6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>I agree.=C2=A0=C2=A0 <br><br>Encrypting links in=
 a network without identity doesn&#39;t really seem to help enough for the =
costs to be justified.=C2=A0=C2=A0 <br><br>I would like to see a PGP-like &=
quot;web of trust&quot; proposal for both the security of the bitcoin netwo=
rk itself /and/ (eventually) of things like transmission of bitcoin address=
es.=C2=A0=C2=A0 <br><br>Something where nodes of any kind (full, spv, mobil=
e wallets) can /optionally/ accumulate trust over time and are capable of v=
erifying the identity of other nodes in that web.<br><br></div>*Then* you c=
an slap an encryption layer on top of it.=C2=A0=C2=A0 Once you have identit=
y &amp; P2P verified pub keys for nodes, encryption becomes easy.<br></div>=
<div><div><br></div></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Thu, Jun 30, 2016 at 5:57 AM, Eric Voskuil via bitcoin-=
dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Jun 29, 20=
16, at 3:01 AM, Gregory Maxwell &lt;<a href=3D"mailto:greg@xiph.org">greg@x=
iph.org</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil &lt;<a href=3D"mail=
to:eric@voskuil.org">eric@voskuil.org</a>&gt; wrote:<br>
&gt;&gt; I don&#39;t follow this comment. The BIP aims quite clearly at &qu=
ot;SPV&quot; wallets as its justifying scenario.<br>
&gt;<br>
&gt; It cites SPV as an example, doesn&#39;t mention bloom filters.. and su=
re-- sounds like the bip text should make the<br>
<br>
</span>&quot;MOTIVATION:<br>
The Bitcoin network does not encrypt communication between peers today. Thi=
s opens up security issues (eg: traffic manipulation by others) and allows =
for mass surveillance / analysis of bitcoin users. Mostly this is negligibl=
e because of the nature of Bitcoins trust model, however for SPV nodes this=
 can have significant privacy impacts [1] and could reduce the censorship-r=
esistance of a peer.&quot;<br>
<br>
This is not an example, this is the exception that is described as &quot;si=
gnificant&quot; in comparison to the other issues, which are described as &=
quot;negligible&quot;.<br>
<br>
The Bloom filters messages are of course the unique aspects of the protocol=
 as it pertains to &quot;SPV&quot;.<br>
<br>
The RISKS section declares that the BIP cannot prevent MITM attacks and tha=
t &quot;identity authentication&quot; will=C2=A0 be defined in a forthcomin=
g BIP.<br>
<br>
The obvious implication (accepted by the author) is that authentication is =
required to prevent a MITM attack, and furthermore establishment of identit=
y will be required to ensure that the authenticated party is not a bad acto=
r.<br>
<span class=3D""><br>
&gt;&gt;&gt; Without something like BIP151 network participants cannot have=
 privacy for the transactions they originate within the protocol against ne=
twork observers.<br>
&gt;&gt;<br>
&gt;&gt; And they won&#39;t get it with BIP151 either. Being a peer is easi=
er than observing the network.<br>
&gt;<br>
&gt; Not passively, undetectable, and against thousands of users at once at=
 low cost.<br>
<br>
</span>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 us=
ers.<br>
<br>
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 a=
ttack may be a larger security problem than a complex passive attack. Attac=
ks against privacy under this BIP (and with authentication) can be carried =
out by passively monitoring traffic and operating one or more nodes. Operat=
ing a node may be considered &quot;active&quot; because the node communicat=
es, but technically it is not. In either case the activeness itself hardly =
raises the difficulty, especially for a global (thousands of users) passive=
 attacker.<br>
<br>
Depending on the attacker, cost may not be an issue at all, so raising it c=
an have zero effect. Certainly we are not talking about prohibitive (crypto=
graphically hard) cost. Raising the cost *any* amount is not likely a reaso=
nable cost-benefit tradeoff.<br>
<br>
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 &quot;good&qu=
ot; 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.<br>
<span class=3D""><br>
&gt;&gt; If one can observe the encrypted traffic one can certainly use a t=
iming attack to determine what the node has sent.<br>
&gt;<br>
&gt; Not against Bitcoin Core, transactions are batched and relayed in<br>
&gt; sorted order.=C2=A0 (obviously there are limits at what this provides;=
<br>
&gt; ironically, the lack of link encryption has been used to argue against=
<br>
&gt; privacy preserving relay behavior)<br>
<br>
</span>It cannot be both impossible (&quot;not against Bitcoin Core&quot;) =
and limited in effectiveness (&quot;obviously there are limits&quot;).<br>
<br>
We should be clear at this point that the transaction-posting security prov=
ided against a privacy attack, based on the assumption of &quot;good&quot; =
(identified) peers in the first few hops, derives entirely from the ability=
 of the good peers to break the timing attack, which is itself &quot;limite=
d&quot;.<br>
<br>
This is a compound pair of weak assumptions, that to be made stronger will =
require widespread use of identity (not just authentication).<br>
<br>
The proliferation of node identity is my primary concern - this relates to =
privacy and the security of the network. Secondarily I am concerned about u=
sers operating under a false assumption about the strength of privacy. Thir=
dly I am concerned about the risk of vulnerability introduced by the integr=
ation into the P2P network layer of an totally new network security scheme.=
 Fourthly I&#39;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 cen=
tralization.<br>
<span class=3D""><br>
&gt;&gt;&gt; Even if, through some extraordinary effort, their own first ho=
p is encrypted, unencrypted later hops would rapidly<br>
&gt;&gt;&gt; expose significant information about transaction origins in th=
e network.<br>
&gt;&gt;<br>
&gt;&gt; As will remain the case until all connections are encrypted and au=
thenticated, and all participants are known to be good guys. Starting to so=
und like PKI?<br>
&gt;<br>
&gt; Huh? The first and subsequent hops obscures the origin and timing.<br>
<br>
</span>Described as &quot;limited&quot; in effectiveness, and clearly usefu=
l only if these hops are not attacker nodes.<br>
<br>
So back to my comment on how we maintain a pool of &quot;good&quot; nodes f=
or 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 exis=
t in the context of the BIP).<br>
<span class=3D""><br>
&gt;&gt;&gt; Without something like BIP151 authenticated links are not poss=
ible, so<br>
&gt;&gt;&gt; manually curated links (addnode/connect) cannot be counted on =
to provide protection against partitioning sybils.<br>
&gt;&gt;<br>
&gt;&gt; If we trust the manual links we don&#39;t need/want the other link=
s. 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 requi=
ring all peers on the network be authenticated.<br>
&gt;<br>
&gt; Don&#39;t need and want them for what?=C2=A0 For _partitioning_ resist=
ance,<br>
&gt; you are not partitioned if you have one honest connection to the<br>
&gt; functional network. Additional peers purely reduce your partition vuln=
erability-- so long as an active network attacker isn&#39;t<br>
</span>&gt; intercepting all your connections out.<br>
<br>
Don&#39;t want them as peers for the purpose of tx relay. As I said this, &=
quot;enables the attack you described above.&quot;<br>
<span class=3D""><br>
&gt; For privacy, you have improve transaction privacy so long as your<br>
&gt; transaction isn&#39;t initially relayed to a malicious peer-- but<br>
&gt; malicious peers can lie further out because transit nodes obscure the<=
br>
&gt; order of message creation.=C2=A0 Bitcoin Core currently relays transac=
tions<br>
&gt; first and more frequently to outbound and whitelisted peers.<br>
<br>
</span>This whitelisting is simply a stand-in for a more formal identity sy=
stem. One doesn&#39;t whitelist anonymous peers, one whitelists peers contr=
olled by trusted parties. Preferring trusted peers is another aspect of try=
ing to break the timing attack. So I would lump this under the same analysi=
s as above (batching).<br>
<span class=3D""><br>
&gt;&gt; Maybe I was insufficiently explicit. By &quot;relies on identity&q=
uot; I meant that the BIP is not effective without it. I did not mean to im=
ply that the BIP itself implements an identity scheme. I thought this was c=
lear from the context.<br>
&gt;<br>
&gt; I understood that, but my point was that Bitcoin cannot be used at all=
_unless users have secure communication channels to share addresses.<br>
<br>
</span>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 &quot;good&quot=
; node, nor does my ability to PGP email a payment address or to send a ste=
alth address in the clear.<br>
<br>
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 author=
ities - despite the fact the the BIP did not require this. Some people cons=
ider this extremely dangerous for Bitcoin, enough so that Peter Todd recent=
ly proposed scrapping the BIP.<br>
<br>
It&#39;s not clear to me how the Bitcoin community intends to establish wha=
t nodes are good nodes. But one thing is certain, any anonymous node may be=
 an undetectable attacker.<br>
<span class=3D""><br>
&gt;&gt; then there is no reason to expect any effective improvement, since=
 nodes will necessarily have to connect with anonymous peers.<br>
&gt;<br>
&gt; They&#39;re not required to _only_ connect with anonymous peers. And p=
artition resistance requires that you have any one good link.<br>
<br>
</span>As a minimum requirement, it implies that only need only to connect =
to one or more &quot;good&quot; peers. Anonymous peers are gravy for partit=
ion 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 prob=
lem.<br>
<span class=3D""><br>
&gt;&gt; Anyone with a node and the ability to monitor traffic should remai=
n very effective.<br>
&gt;<br>
&gt; Not via passive observation.<br>
<br>
</span>See above commentary on the irrelevance of this distinction.<br>
<span class=3D""><br>
&gt;&gt; Defining an auth implementation is not a hard problem, nor is it t=
he concern I have raised.<br>
&gt;<br>
&gt; Glad you agree.<br>
<br>
</span>I don&#39;t get your point here. It seems like you are just trying t=
o antagonize.<br>
<span class=3D""><br>
&gt; We seem to be looping now. Feel free to not implement this proposal,<b=
r>
<br>
</span>At this point I think it&#39;s fair for me to say that nobody needs =
your permission.<br>
<span class=3D""><br>
&gt; no one suggests making it mandatory.<br>
<br>
</span>Have you ever debated an optional feature proposal?<br>
<br>
e<br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>

--94eb2c07cfc8daeeb405367ef6c6--