The Road to Universal .p2p Resolution

I came to BitShares with the express purpose of convincing them to reinvigorate their .p2p efforts.  Thankfully, I was pleasantly surprised to find that the .p2p initiative had fizzled not due to lack of interest but of bandwidth.  The core development team liked my overall plan and I would like to present my roadmap for making .p2p a reality for the BitShares community.

Note: this is primarily intended for the BitShares community and their investors.  The plan itself is very preliminary, please do not read too deeply into any one aspect, it will evolve. 

Introduction

I started contributing to Namecoin because I wanted to build an interoperability solution for .bit so that everyone could visit .bit sites without installing software or altering system settings.  I’ve spent the past couple of years working with my colleagues to systematically break down each one.  From legacy interop to inclusion with the major browsers to domain pricing to interoperating with registrars, I think we’ve architected a solution that will work.

My week at BitShares HQ was to give me time to grok BitShares’s security model, your team, and your community.  BitShares has solved some problems that Namecoin hasn’t, such as pegging assets to USD.  The BitShares’ community is also more open to my proposal for legacy interoperability.  Furthermore, I’m a convert to DPoS:, you can fuel a higher rate of innovation and the security model can accommodate my proposal for legacy interoperability.

However, I want to be upfront in my continued association with Namecoin.  I am a Namecoin contributor who also wants to become a BitShares contributor, but I am in no way being “poached” by BitShares.  Even if delegate pay could sustain me at a market competitive rate, I honestly wouldn’t be of much use without my continued collaboration with my colleagues in the Namecoin community.

Namecoin developers are all volunteers and we are eager to have others tackle this problem. Posts to our internal board regarding potential collaborations and my trip to BitShares HQ have been met with nothing but positive feedback.  The difference between Namecoin and BitShares is similar to that of Debian and RedHat or Firefox and Chrome.

My goal in collaborating with BitShares is to pool our resources and reduce duplication of effort.  Both projects need to work with the IETF, ICANN, certificate authorities DNS providers, and anonymity networks.  Having two parallel efforts tackling the same problem will increase our chances of success.  It’s time we start working together to end online censorship and make the internet safe from corrupt governments.

The Long Term Plan

Legacy Interoperability

Metcalf’s law ensures that .p2p sites must interoperate with the existing web, no website will link to a .p2p site unless all of their visitors can visit the site.  Asking users to install software or changing DNS settings is asking too much!

Initially, we will have to rely on a DNS suffix (i.e. p2p.tld) also known as a pseudo SLD.  However, we must make this solution as secure as traditional TLDs, which requires setting up threshold signing for DNSSEC and electing delegates to sign the zone file.  This task is non-trivial and there are several problems with BitShares original plans for the DNS suffix that I will cover later on.

This solution is not ideal in the long term, if a government shuts down our suffix it shuts down the entire TLD.  However, owning multiple backup .p2p TLDs will turn any attempt at shutting down the TLD into free marketing, the kind that pushes browser and operating system vendors to adopt lightclient resolution directly.

We will also publish signed zone files to Archive.org, so DNS providers can enable .p2p resolution and DNSSEC validating clients won’t have to rely on their DNS providers operational security.  In the medium term, I anticipate pushing .p2p resolution at third party DNS providers (like OpenDNS, Google’s DNS, etc.) as well as universities, major ISPs, and on corporate campuses.

There are several mechanisms (server side, client side, and on the browser level) for detecting support for direct .p2p resolution and forwarding clients from the suffix to the native .p2p domain. Thus, when clients support local resolution, existing DNS suffix links will resolve to the .p2p domain directly.

Local Lightclient Resolution

I interned at Mozilla and it is a crazy place to work.  The majority of the committers are unpaid and the majority of paid developers are remote, meaning that nearly every developer meeting is broadcast on the internet and that anyone can just drop in on the chat channel.  As a result, the noise floor is VERY high: there a lot of people demanding that Mozilla support various protocols and initiatives.

Take the Metalink project, a standard for listing multiple URLs and transports for a single download.  It has had patch sets for Firefox for years, pending RFCs at the IETF, it is used internally by YUM, supported by cURL, and offered as a distribution method for pretty much every major Linux distro.  It makes downloads faster and more resilient to failure … but Mozilla hasn’t adopted it.

That’s a very long-winded way of saying that we need an overwhelmingly strong case if we ever want adoption by the major browsers and operating systems.  Snowden and the US government’s domain name seizures have made our case much more compelling, but we need still need a few more tricks.

Zooko’s triangle is why I’m here: to make anonymous, censorship-resistant networks usable. Fulfilling this use case is what will enable us, in the long term, to be included in operating systems, browsers, and other network software directly.

Furthermore, China has essentially locked Google and every other Western company out of the world’s largest market.  Indeed, 55% of the worlds population lives in countries that engage in moderate to severe levels of censorship.  It is in these markets that users will be willing to install software add-ons to circumvent censorship and the profit motive to crack these walled gardens will be our vehicle to mass adoption.

The Plan for 2015

There are a number of problems with .p2p’s existing plans, mostly stemming from a lack of expertise in the relevant areas.  Collectively, it has taken the current Namecoin development team years to develop this expertise.  We also have connections to various communities  (DNS, certificate authorities, the security industry, and standards bodies) that the .p2p team lacks.  Hiring me as a delegate will give BitShares someone to head up this effort that has spent a lot of time reviewing the legal, technical, and usability issues at play.

With your official support, I will include explicit support for BitShares in all of my work and create parallel infrastructure for .p2p.  Let’s get down to what, exactly, that means.

Funding

I am requesting 2.5 delegates, one for myself, another for a security engineer and a third for operational expenses.  The operational expenses delegate will cover the cost of hiring a system admin to manage the delegates and additional expenses such as dedicated servers for the zone signers, .p2p domains, travel costs, and some code bounties for work I do not have time for myself.  I will regularly (probably annually) burn any additional funds that the operational expense delegate does not use.   All three delegates will be converted into zone signing delegates.

The proposal for 2015 is somewhat optimistic: delegate pay only covers me at ¼ of my industry pay rate (after self-employment taxes).  I am assuming that I will receive grant money to work on Namecoin ¾ time with delegate pay making up the other ¼ time and that the BitShares’ price will not fall dramatically.  If I do not receive grant funding or BitShares’ price falls dramatically, we will need to reevaluate my obligations and pay.

IETF, ICANN, & Domain Politics

I made a very stupid mistake in the first draft of this document: promising anything in regards to standards bodies.  I’m very new to both ICANN and the IETF but I do have contacts there and I am excited to start advocating on the behalf of .p2p.  However, if my time in politics taught me anything, it’s to be very humble in what you plan to accomplish.  I think I can provide value here, but do not hire me based on my expertise in this domain.

The operational expenses delegate will be used for any travel expenses to attend IETF and ICANN meetings ($3,000-$5,000).

Legacy Interop

DNS Suffix

We need several domains to try and prevent attackers from seizing our primary domain. Even with multiple fallbacks, we should try to use the domains most resistant to domain seizures.  I have a list of TLD’s that are cross referenced with the OpenNet Initiative as well as a FOIA request pending with ICE to help determine the safest alternative domains.  I will use this list to generate a list of potential TLDs and then negotiate the purchase of the domains.

Delegate pay will only cover my labor costs; the cost for the additional domains will need to come out from the operational expenses delegate ($1,000 per domain).

DNSSEC

We need to not only sign the DNS suffix but also publish signed zone files so that DNS providers (OpenDNS, Google’s DNS, universities, ISPs, corporate campuses, etc.) can enable .p2p resolution securely.  This is a very complex task.  The first engineering difficulty is that interoperability with DNSSEC means that we must implement a threshold signature scheme that can produce standard RSA public keys with signatures that can be verified by the standard verification routines.  The second is that since we are talking to standard DNSSEC equipment we can’t rely on the normal delegate consensus system.

Thankfully, an academic has published a paper outlining a scheme that produces standard RSA signatures.  There was apparently a Java implementation, but we have been unable to contact the author.  If we cannot get a hold of an existing implementation, we may need to hire a mathematician to help with the reimplementation.

Finally, we must create a system that parallels the traditional TLD zone signing scheme.  The proposed threshold signature scheme’s complexity scales linearly with the number of parties, so it is not feasible to use to scale to a full 101 delegates.  Furthermore, since we cannot easily replace delegates (revoking one delegate requires generating a new ZSK and signing it with the KSK) we need to select a smaller number of very reliable delegates.

The system will require the generation of a Key-Signing-Key (KSK) with 7 trusted parties that store their keys offline.  The KSK will sign a Zone-Signing-Key (ZSK) that is used by delegates to sign the zone files.  We can use a 2Kb ZSK, so there is no need to create and sign a new ZSK every 3 months (.com, .net, etc. use a 1Kb ZSK).  However, to protect against governmental adversaries, the zone signers will need to use dedicated servers and store their keys in hardware security modules.

Delegate pay cover the initial threshold implementation, creating a hardened Linux system, and setting up demonstration zone-signing delegates.  The threshold signature implementation and creating demonstration delegates (including a locked down image and sysop automation) will be covered by the security engineer’s 100% delegate for one year.  The operational delegate will increase its pay rate as needed to cover the demonstrations servers hardware costs (~$2,500).  Sometime in 2016, we will choose the final trusted KSK holders and the additional zone-signing delegates before officially launching .p2p.

Development

There is a lot of development work unrelated to the backwards interoperability proposal.  This includes work on domain record specification, middleware, and clients to manage domains.

Name records must be converted to a destination format.  For example, a domain might need to be converted for use by Plain-Old-DNS (PODNS), Tor, I2P, etc.  The names and their records must go through validation checks.  Finally, operating systems, browsers, and other applications also need the records served up via DNS; necessitating a standards compliant DNS server.  These tasks fall to a middleware layer that lives outside of the blockchain software.

Delegate pay will primarily fund making Namecoin’s middleware (NMControl) compatible with BitShares.  However, I would also like to convert NMControl to Python 3, replace the RPC library, add record validation, build client libraries in 5+ languages, and add full test coverage.  The resulting product will work with Namecoin’s browser and system level proxy solution and serve for other applications that wish to communicate directly.

I will also be working on important usability issues regarding domain name ownership.  For example, we need to refactor how TLS signing works.  Right now, sites can generate multiple TLS certificates and have them signed by a certificate authority.  We need to transition to a system in which site owners sign their site certificates with an master key pair that is stored offline.  Setting up a domain management client to handle these items automatically is going to take a significant amount of work.

I have little experience with Python, I am unfamiliar with the codebase, and I will work on this in parallel to my other responsibilities.  Given the level of unknowns, I am going to give myself a wide margin of error and estimate the time for completion of this task to be 6-12 months.

Given that delegate pay is only covering me at ¼ time, this estimate dependent on Namecoin providing additional funding for me through grants or from the community contributing to code bounties.  Delegate pay will enable me to survive until such funding comes through.

Internet Freedom Alliance Working Group

There is a need to harmonize standards between BitShares and Namecoin namespace specifications.  There is also potential for collaboration between other groups, such as Tor, I2P, and Freenet.  To facilitate these goals I will create and administer the Internet Freedom Alliance: a working group dedicated to harmonizing standards and increasing collaboration.

The group will largely consist of a mailing list and a Github organization with repositories for formal specifications, unit tests, and reference implementations.  A RFC process for proposing revisions and new standards will be created based on Bitcoin’s BIP workflow and existing standards will receive a formal write up.  The IFA-WG will register as a non-profit legal entity to receive funding from member projects as well as donations.

.p2p Prelaunch

I’ve worked out a general plan for name reservations, pricing, and other details during my week at BitShares HQ.  However, as the BitShares team can attest, the reasoning for each decision is complex and the full plan will be outlined at a later date.  However, we will create an experimental second-level-domain, x.p2p and progressively enhance it’s capabilities.  This will allow us to test software, such as the middleware and browser add-ons.

I will also work with DNS service providers to build an abstraction layer that will allow registrars to purchase domains using their existing infrastructure.

Beyond 2015

The majority of the work outlined above should be finished by the end of 2015.  I suspect that over the year, the core development team will be able to switch their focus to features like transaction anonymity, advanced light clients, and setting up the launch of .p2p in early or mid 2016.

It may, at some point, make sense to create a new DAC optimized as a trusted base. There is concern that BTS might not be perceived as “neutral” enough to be a trusted base for core internet infrastructure. It would also make sense to increase the time interval between blocks.  Finally, it may be easier to adopt ZeroCash and other future proposals using a different codebase.  However, in the near term, setting up 101 new delegates, getting adoption in the exchanges, and setting up a competing BitUSD market is just not feasible.

Should it end up being the case that we cannot use the BitShares blockchain, we can always share drop onto BTS for both the share allocation and the initial name ownership. As long as BTS holders benefit from selling the namespace in what eventually becomes a secure decentralized DNS solution, everyone should be satisfied.

It’s impossible to predict the future, and we should evaluate my contributions and potential future as a delegate when 2016 rolls around.  The entire crypto market could tank, or someone could exploit a design flaw so severe that we the couldn’t recover.  Hopefully, I will find external funding, I could be accepted into a Ph.D. program and comfortably work part time for BitShares, or BitShares could explode and I could support myself on delegate pay entirely.

Conclusion

I’ve laid out a comprehensive plan for both near-term and long-term adoption of .p2p.  I outlined cost estimates for the near-term future and options should the funding situation change.  In the future, it may make more sense to design a currency tailored specifically as a trusted base and share drop on BitShares.  With your support, I believe we can enable universal .p2p resolution thus ending the threat of domain name seizures and making anonymous networks usable.


Donation Addresses

  • BitShares ID: indolering
  • Bitcoin Donation: 1DKG4wMB4fQfgB5W5qFjrtMXHkZJKL37ua
  • Namecoin Donation: N3ramRzMjm791aGUyg5DQFSupFijVwCCEf

7 Responses to “The Road to Universal .p2p Resolution”

  1. anonymous January 18, 2015 at 12:49 pm #

    I’m curious if it is possible to replace the major centralized certificate authorities by the blockchain.
    It would be great if everybody were able to issue certifcates at much cheaper prices and with maximum trust via the blockchain. This could bring millions of USD to BitShares while also helping the world to be a better/secure place. I also believe the CA part could be easier to implement than the DNS part.
    however, you got my vote.

    • indolering January 18, 2015 at 1:43 pm #

      Right, so I’m advocating this as well. However, there is no reason to charge for certs, you just load the TLS fingerprints into the DNS record directly.

    • indolering February 17, 2015 at 1:03 pm #

      The CA cert system is fluke of history: it was created when they thought that a dozen sites might need encryption and that they would certify the domain as being owned by the organization it appears to represent. You can replace the CA system by stuffing hashes of the TLS public keys in the DNS record. If your DNS record is insecure, then they can point you to a different server and get rid of encryption anyway.

  2. Luckdragon69 January 26, 2015 at 10:02 pm #

    Is there a lighthouse project to help fund this agenda?

    • indolering January 27, 2015 at 11:45 am #

      Maybe in the future, Namecoin tried a crowdfunding campaign in the past and it only raised ~$2,000 despite heavy publicity. I don’t think a crowdfunding campaign will be successful until we start delivering end-user software. I think we are one or two years from being ready for one.

  3. ken Code March 20, 2015 at 10:33 am #

    You got my vote indolering.
    It’s been a few weeks since you appeared on btstalk, are you and toast workin this out now? Would love to chat if you have the time, I have a related project going.
    bts:kencode

    • indolering March 25, 2015 at 4:20 pm #

      Yes, I’m working with Toast on the details right now. I hope to get things sorted out in the next couple of weeks.

Leave a Reply