[tor-dev] Tor and Namecoin

[Jeremy Rand]

George Kadianakis:
> 
> Hello Jeremy,

Hi George, thanks for the reply.

> I'm a big noob when it comes to blockchains, namecoin, SPV clients and such, so
> I'm mainly going to focus on how to integrate this with Tor.

I know this isn't necessarily needed given that this would start out as
an optional thing, but I'm curious: does Tor have people these days who
are familiar with blockchain stuff?  I know it's not particularly
relevant to the core of what Tor does, so I'd be unsurprised if the
answer is "not really", but I figure asking can't hurt.

> It seems to me that a plausible way to kickstart this big project would be to
> make an unofficial add-on for TBB that can do the namecoin dance. People can
> then install it and experiment with it. If it fits the Tor use case well, then
> a community might be formed that will push this project forward even more.

Yes, this sounds good to me.

> If it's an optional add-on, we also don't have to worry that much about the
> 400MB blockchain size, since it's gonna be optional and only people who want it
> will have to download it. This way we can learn how much of a problem the
> download size is anyway (it seems to me like a total blocker for people in
> non-western fast-internet countries).

FWIW, the 400 MB that I listed is the size of a LevelDB database after
synchronizing a name database against the most recent year of blocks.
This may not be representative of the data downloaded, for a few reasons:

1. If a name is updated more often than the expiration period, the
download size will be higher.
2. LevelDB has storage overhead due to indexing, which will make the
download size be lower.
3. If an API server is used for lookups, then only the block headers
need to be downloaded, which makes the download size a lot lower.
(Hence why it takes 5 minutes to sync rather than 10 minutes.)
4. There are a number of optimizations that can be made to decrease the
download size, some of which are easier than others.  Some of the
optimizations that come to mind include checkpoints, UTXO commitments,
UNO commitments, SegVal, and DMMS improvements.

That said -- I definitely agree with you that real-world experimentation
is a useful way to learn how much of an issue this really is.  If it
turns out to be totally usable in its current form, then we can
deprioritize further optimizations, whereas if there are major issues in
this department, then we would probably want to bump up the priority of
optimizations.  In particular, checkpoints are low-hanging fruit.

> That's why I would suggest experimenting with the first two approaches you
> mentioned that don't require a modification to Tor's protocol.

Agreed.

> Specifically, if you can build a PoC with Yawning's or-ctl-filter that's what I
> would go for, since I'm not actually sure what's the current state of the
> OnioNS code, and how easy it will be to plug namecoin in there. 

That's very good to hear that you suggest this, because the Namecoin
devs who would be likely to work on this (including me) prefer Go over
C++, and we already have Go libraries that are likely to be reasonably
straightforward to integrate into or-ctl-filter.

> What would be
> the procedure for third-party people with TBB to install namecoin + or-ctl-filter?
> Would it be a painful UX?

To be honest, while I've examined the code for or-ctl-filter, I've never
gone through the process of installing it, so I'm unsure of how the UX
would be there.  On Namecoin's end, it would basically consist of
running a Java program; the Go library that we would hook into
or-ctl-filter will simply return a resolution error for Namecoin lookups
until the Java SPV client has finished syncing the blockchain; after the
syncup finishes, Namecoin lookups automatically start working.  So, the
UX is unlikely to be much worse than a vanilla or-ctl-filter
installation, unless there's something I haven't thought of.

> FWIW, I'm also not sure what's the state of Jeff Burdges' name resolution idea,
> whether there are any plans on moving forward, and whether it would fit the
> Namecoin API.

Yes, I was under the impression that not much has happened on that front
lately.  Looks like we don't need to worry about it short-term.

Thanks again for the feedback -- much appreciated.

Cheers,
-Jeremy

-------------- 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/20160801/d9c48e4e/attachment.sig>