[tor-dev] Onioncat and Prop224

[str4d]

On 08/08/16 01:22, Jeremy Rand wrote:
>> And most certainly any external layer must be capable of having
>> nodes binding natively in the Tor / I2P / etc networks, and
>> preferably being strictly private entirely within them (like how
>> private Tor / I2P / Bitcoin nets can be deployed by generating
>> new authorities, keys, genesis, etc). Outproxy is not an option.
> 
> Bitcoin and Namecoin nodes can be exposed as Tor hidden services (I
> believe there's even code in there now for automatically configuring
> such a hidden service via the Tor control port).  I don't think there's
> any built-in support for I2P (unless something was added since I last
> looked),

Not yet, but there's an open issue for adding I2P support (alongside
support for Tor's HS2.0) [0]. See also an old Bitcoin fork with I2P
support [1], and other relevant links in Zcash's I2P issue [2]. Any
native I2P support would automatically set up the I2P Destinations,
because that's how the SAM API operates [3].

> but if I2P can expose a local TCP service as an I2P service,

Yes.

> and if I2P allows such TCP services to be connected to by exposing a
> SOCKS interface,

Yes.

> I'm guessing that it should mostly work (famous last
> words).  The only thing that would break that way is peer exchange:
> Bitcoin and Namecoin nodes normally share peer addresses, and although
> this works just fine with Tor hidden services, I don't think it would
> work out of the box with I2P (unless someone's added that since I last
> looked).

The issue here is that I2P addresses (even B32s) are longer than the
internal message fields for sharing addresses. Tor's HS2.0 will suffer
from the same issue, because their proposed addresses are just as long
as I2P's B32s.

> 
> Although it is possible to deploy private Bitcoin and Namecoin networks
> (I did it at a workshop I gave at DWS so that I could mine blocks on
> demand), usually people do this for testing or demonstration purposes,
> not for real-world applications.  The reason is that blockchains'
> security assumptions include the assumption that they have a reasonably
> high hashrate from a reasonably diverse set of miners.  An
> Onioncat-specific Namecoin network would probably have a very low
> hashrate compared to the main Namecoin network, which means that it
> would be much easier to perform a 51% attack.  Merged mining could,
> hypothetically, raise the hashrate, except that to do merged mining, the
> miners would have to be connected to the public Bitcoin network.  In
> addition, it's usually very unprofitable to mine Bitcoin or Namecoin
> over Tor or I2P, because the additional latency causes much higher
> orphan rates.  (Most Bitcoin and Namecoin miners spend considerable
> effort obtaining low-latency connections for relaying blocks to and from
> other miners.)
> 
> Might I ask what the motivation is for having a completely separate
> Namecoin network inside Tor/I2P, that can't be satisfied by binding
> participants' nodes to Tor/I2P hidden services while allowing some users
> who don't want or need anonymity to relay transactions and blocks
> between clearnet and Tor/I2P?

One potential issue is that if the user's endpoint isn't configured
correctly, Namecoin names that resolve to clearnet addresses could
deanonymise the user (checks at the browser or app level wouldn't help
here because all it would see is an IPv6-style address IIUC). It's not
unavoidable, but a point to be wary of when considering the overall
integration strategy.

Using the global Namecoin blockchain also puts the bridging nodes into a
position of importance and trust, that can only be lessened by greatly
increasing the number of bridging nodes. This is more of a concern for
I2P than Tor, as I2P-only peers can only reach the bridging nodes,
whereas Tor-only peers can connect to clearnet Namecoin nodes too
(although as with Bitcoin there is the issue of exit node traffic
manipulation).

str4d

[0] https://github.com/bitcoin/bitcoin/issues/2091
[1] https://github.com/VirtualDestructor/bitcoin-qt-i2p
[2] https://github.com/zcash/zcash/issues/1111
[3] https://geti2p.net/en/docs/api/samv3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160808/5e55cd83/attachment.sig>