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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev