grarpamp: > Hi Jeremy. Hey grarpamp, Sorry for the delayed reply. > In regard your post 'Tor and Namecoin' here... > https://lists.torproject.org/pipermail/tor-dev/2016-July/011245.html > > In this thread prefixed 'Onioncat and Prop224' started and > spanning from here through now... > https://lists.torproject.org/pipermail/tor-dev/2016-April/010847.html Thanks for the pointer. For some reason I wasn't aware of that thread, even though those messages did hit my inbox. Probably because in April 2016 I was busy finishing semester projects and wasn't spending much time reading email. > Onioncat is interested in finding way to extend IPv6 addressing > past prop224 for use by IPv6 native user applications. > > There are some purely internal ideas for that. Yet to extent > an internal tor+onioncat solution may be difficult, > onioncat may need to develop or shell out to a non-native > mapping and lookup layer. Namecoin has been mentioned > among prebuilt potential solutions. Hmm, this is indeed an interesting use case. > Note clearly namecoin usage here *not* for human DNS style > naming such as myeasyname.onion. But as a mapping between > crypto key of onion (descriptor, hsdir, etc) and character string > of (in format of) IPv6 address for use in IP / tunnel addressing. Okay, so I've been pondering this for a little while. There are going to be some challenges in doing this properly, but I *think* that most or all of the challenges are solvable with some effort. Full disclosure: I will need to check with the other Namecoin devs to see if I might have missed anything, so I might need to issue corrections to these comments if I did miss anything important. Most of the challenges of dealing with this use case are going to be because Namecoin simultaneously aims to satisfy 2 goals: 1. Enforce that names are unique and only updatable by the owner. 2. Enforce that names are scarce, nonfungible, and resistant to squatting. Both of these goals are relevant for a DNS-like system that maps human-meaningful names to values. The first goal is relevant to Onioncat-like systems, but the second goal seems to be inapplicable, because (I presume) most end users don't care what IPv6 address Onioncat assigns them, and if a particular IPv6 address happens to be unavailable for registration, picking a different one isn't going to annoy anyone. (If, for some reason, there are Onioncat use cases that make this statement incorrect, please let me know.) Some of the challenges that are posed by the existence of goal 2 include: Creating a new IPv6 address would cost some money, conceptually similar to registering a domain name. This might incentivise unsafe user behavior such as reusing identities. There have been similar concerns raised in the past about other use cases of Namecoin (including some features of domain names) where name scarcity unintentionally incentivises insecure user behavior, so I'm guessing that we're open to the possibility of adjusting the system to solve this. Creating a new IPv6 address is subject to a 12-block (around 2 hours) waiting period (a salted commitment to the name is placed in the blockchain, and 2 hours later the name and salt are revealed), so that a newly created name cannot be sniped by someone relaying the transaction or during a small chain reorganization. I'm guessing that some Onioncat users may not want to have to wait 2 hours for their new IPv6 address to start working. This also might incentivise reuse of identities (see previous challenge). Okay, so here is a suggestion on how this might be fixable. Let's say that we create a new class of names in Namecoin. This might be a different set of name opcodes that have modified semantics. In this email I'll refer to this new class of names as MR (machine-readable) names, and the existing names as HR (human-readable) names. MR names have the following new properties: 1. MR names are not subject to name registration fees. (A fee is paid to the miner just as would be done for a currency transaction.) 2. MR name registrations are not subject to a 12-block waiting period. 3. MR name registrations must be signed by a public key whose hash is equal to the name being registered. 4. MR names are considered to be in a separate set from HR names for the purpose of name uniqueness checks, i.e. registering a domain name as an MR name is valid even if the domain name already exists, but software that looks up the domain name will receive the HR name unless it requests the MR name. I think MR names would solve both of the challenges I listed, without compromising goal 1. Sniping is prevented because a sniper would need to possess a private key whose public key hash is the name being sniped. In the case of Onioncat, the public key would be the .onion public key. Unfortunately, this construction introduces a new issue: there are a lot of public key systems and hash functions, and different applications will want different choices. If this is used to prevent sniping, then it would have to be part of blockchain validation, which makes supporting arbitrary pubkey systems and hash functions impossible. So, we can instead modify this construction a bit, as follows: 5. MR name uniqueness is not part of transaction/block validation. 6. The signatures used in property 3 are not used for transaction/block validation. 7. When an MR name is looked up, the Namecoin client returns all of the matching unspent transactions (meaning that since MR names are not unique, there may be multiple unspent transactions that match the name). 8. MR name lookups also return the signatures used in property 3, for each matching transaction. 9. MR name lookups also return the registration block height of each matching transaction. 10. The application layer that requests a name lookup (e.g. Onioncat) is responsible for choosing the earliest-registered name whose signature used in property 3 is valid according to whatever signature validation rules the application layer uses. The only attack I see here is that it's possible to spam invalid signatures into the blockchain and make everyone else carry them around. Transaction fees and block size limits should (I think) prevent this from being a problem, just as with Bitcoin. This kind of modification would, I think, be a softfork. It would be a fairly significant undertaking, but I think it would be useful for a lot of other use cases besides Onioncat. Again, I haven't discussed this outline with the other Namecoin devs, so maybe there are problems that I'm not seeing. > 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), but if I2P can expose a local TCP service as an I2P service, and if I2P allows such TCP services to be connected to by exposing a SOCKS interface, 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). 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? > It's also not ideal to be expending resources on mining > whereas other form of simpler distributed registry network > may suffice onioncat purpose. Might I ask what alternatives to mining would suit Onioncat's needs? I admit that I'm not incredibly familiar with Onioncat's needs and threat model, so if there's something simpler that works well, I'm unaware of what it would be. > Anyhow, fyi as to this thread and any ideas / collab :) Yes, thank you for bringing this up. Feel free to give feedback on the above, suggest alternative methods, etc. I'm not certain whether Namecoin is the best solution for Onioncat's needs (and it sounds like no one is certain at this point), but I'm happy to do what I can to flesh out the ideas so that we can figure out if it's the right solution, and if so, exactly what that solution would look like. Cheers, -Jeremy PS: I'm not subscribed to the other lists; if you are subscribed to them and think they'd like to see this reply, feel free to forward it to them.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev