Yes correct, using hidden services just as a kind of more complicated, out
of process/sandboxable SSL.
> would the overall transactions/second the Bitcoin network could handle go
> down?
>
If all nodes talked to each other all the time over Tor, probably yes
because Bitcoin is quite sensitive to
quote:
> > 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 bootstr
On Wed, 2014-01-15 at 20:29 -0800, Miron wrote:
> On Wed, 2014-01-15 at 23:51 +0100, Mike Hearn wrote:
> ...
> > 3) SPV wallets that want to get a good mix of nodes for measuring
> > pending transactions identify nodes on the clearnet via their addr
> > announcements+service flag, in the normal way
On Wed, 2014-01-15 at 23:51 +0100, Mike Hearn wrote:
...
> 3) SPV wallets that want to get a good mix of nodes for measuring
> pending transactions identify nodes on the clearnet via their addr
> announcements+service flag, in the normal way. They select some of
> these nodes using the standard cle
On Wed, 2014-01-15 at 20:26 -0600, Brooks Boyd wrote:
> My goal here is not necessarily to hide P2P nodes - we still
> need lots of clearnet P2P nodes for the forseeable future no
> matter what. Rather we're just using hidden services as a way
> to get authenticatio
>
> My goal here is not necessarily to hide P2P nodes - we still need lots of
> clearnet P2P nodes for the forseeable future no matter what. Rather we're
> just using hidden services as a way to get authentication and encryption.
> Actually the 6-hop hidden service circuits are overkill for this
>
On Wed, 15 Jan 2014 23:51:21 +0100, Mike Hearn wrote:
> The goal of all that is that we get to keep our existing IPv4 based
> anti-sybil heuristics, so we can’t possibly make anything worse,
> only better. Plus, we’ve now set things up so in future if/when we
> come up with a better anti-sybil syst
>
> May need to modify the network address format to include the ability to
> differentiate IPv6 clearnet vs. Tor addresses
>
sipa already implemented some clever hack where the 80-bit Tor keys are
mapped to a subregion of reserved IPv6 space, giving magical IPv6 hidden
service addresses. So addr
>
> 2) Secondly, we bump the protocol version, add a service flag and
> introduce a new P2P protocol command “tor?”. If a client sends a tor?
> message to a node that has the new service flag set, it will respond with a
> new “tor” message that contains a regular addr packet, with a single
> addres
intro text starts here, protocol upgrade proposal starts further down
Recently on IRC we have discussed what it'd take to use SSL on P2P connections,
the goal being encryption and authentication of traffic to help avoid passive
wiretapping and sybil attacks.
Gregory pointed out - very reasonabl
10 matches
Mail list logo
