My apologies for being late to the discussion, I'm not much of a forum person and I didn't get an email from Ken until recently. I'll try to explain what I can about the delays in tomorrow's hangout, but things are in full swing and we are working towards a viable decentralized domain name system. However, I would love more smart people pitching in!
As far as what we need right now, the most important next step is a threshold signature scheme that can produce vanilla RSA signatures. This allows us to build a system in which delegates can sign zone exports using DNSSEC. This requires hiring a cryptographer/mathematician/programmer to implement
a scheme outlined in academia and it's what my delegate pay will be funding initially.
Browser add-ons and system level integration is another important step. Namecoin's middleware, NMControl, is designed for this task and it will act as the backend for the browser OS level integrations. NMControl is modular, the plan is to change the name and add BitShares support. We also need to switch to Python 3, create a MITM-proxy plug-in, and port over Unbound. If you are python programmer and interested in helping out, head over to
the Github repo.
In terms of lightweight clients, BitShares has a long way to go. Indeed, the primary reason for launching a DNS specific DAC is to improve the lightweight client situation. The only thing that should be stored in the blockchain are public key fingerprints and nameservers, waiting ten minutes just isn't a big deal and bloats storage requirements.
But since DPoS embraces delegation of trust, I'm not sure it would be that much better than just relying on DNSSEC signed zone exports (and thus keeping everything within the BitShares blockchain). The system works by having two keys, a Zone Signing Key (which signs zones) and a Key Signing Key (which signs the Zone Signing Key). Delegates will sign zone files using the Zone Signing Key (ZSK). If a certain threshold of delegates are proven to be producing incorrect zones, the KSK could sign a revocation of trust in the old ZSK and sign a new ZSK. Software trusting the KSK wouldn't need to be updated unless the blockchain chose a new KSK for some reason. Even if a new KSK is needed, the new KSK can be signed by the old KSK, ensuring interoperability until software is updated.
Note that this is all threshold crypto, a certain number of delegates are required to produce a valid signature. For the beta period, I think the KSK should be controlled by the developers and some mutually untrusted third parties in Iceland and other jurisdictions. This is actually more robust than the system we have for signing the client software. However, we could also setup a system for voting, similar to how delegates are voted in now.
So there you have it, I think that the important next steps are the RSA threshold scheme, upgrading NMControl, and a
lot of political engagement and public relations work.
If you want to help out, start by hacking on NMControl and voting in my sec.indolering delegate! After I get that one approved, I will pay the fee on the remaining delegates.
After my delegates get approved, I will post monthly updates and make an effort to visit the forum regularly. You can also shoot me an email at zachlym@indolering.com.
Topic: BTS: .P2P .DAC - Decentralized DNS using the BitShares blockchain! (Read 17420 times)
