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
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
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 system
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, 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
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. They
6 matches
Mail list logo
