Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of
	midnightdesign.ws designates 50.87.144.70 as permitted sender)
	client-ip=50.87.144.70; envelope-from=boydb@midnightdesign.ws;
	helo=gator3054.hostgator.com; 
MIME-Version: 1.0
In-Reply-To: <5747D5DF-879B-4A60-8BD6-18251E7D5F47@plan99.net>
References: <5747D5DF-879B-4A60-8BD6-18251E7D5F47@plan99.net>
Date: Wed, 15 Jan 2014 17:07:07 -0600
Message-ID: <CANg-TZBCSvVeDTNKQSPV-Fw+uZ8np04WoE=o0J+8wULBHrsgKQ@mail.gmail.com>
From: Brooks Boyd <boydb@midnightdesign.ws>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=047d7bd6b9ac39ae7a04f00a5e2a
Subject: Re: [Bitcoin-development] Tor / SPV
Precedence: list

--047d7bd6b9ac39ae7a04f00a5e2a
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

>
> 2) Secondly, we bump the protocol version, add a service flag and
> introduce a new P2P protocol command =93tor?=94. If a client sends a tor?
> message to a node that has the new service flag set, it will respond with=
 a
> new =93tor=94 message that contains a regular addr packet, with a single
> address, the IPv6-ified version of its hidden service name.
>


Rather than a separate message type that implies binding a clearnet IP to a
hidden service ID, why not add the service flag that the peer would like
Tor addresses, and the remote peer can then add IPv6-ified hidden service
addresses to "addr" messages? May need to modify the network address format
to include the ability to differentiate IPv6 clearnet vs. Tor addresses,
but then you remove the implication that a node has to give both public and
private IPs to a peer. If it's part of a batch of "addr"s, it could be my
own hidden service ID, but it could also be one that I learned from someone
else and is now propagating, for anyone to bootstrap with Tor hidden
service peers if they'd like.

Brooks

--047d7bd6b9ac39ae7a04f00a5e2a
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div style=
=3D"color:rgb(34,34,34);font-family:arial;font-size:small">
2) Secondly, we bump the protocol version, add a service flag and introduce=
 a new P2P protocol command =93tor?=94. If a client sends a tor? message to=
 a node that has the new service flag set, it will respond with a new =93to=
r=94 message that contains a regular addr packet, with a single address, th=
e IPv6-ified version of its hidden service name.</div>
</div></blockquote></div><br></div><div class=3D"gmail_extra"><br></div><di=
v class=3D"gmail_extra">Rather than a separate message type that implies bi=
nding a clearnet IP to a hidden service ID, why not add the service flag th=
at the peer would like Tor addresses, and the remote peer can then add IPv6=
-ified hidden service addresses to &quot;addr&quot; messages? May need to m=
odify the network address format to include the ability to differentiate IP=
v6 clearnet vs. Tor addresses, but then you remove the implication that a n=
ode has to give both public and private IPs to a peer. If it&#39;s part of =
a batch of &quot;addr&quot;s, it could be my own hidden service ID, but it =
could also be one that I learned from someone else and is now propagating, =
for anyone to bootstrap with Tor hidden service peers if they&#39;d like.</=
div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Brooks</div=
></div>

--047d7bd6b9ac39ae7a04f00a5e2a--