What is the exact use-case you are considering?

Lightweight, name-only resolvers for DNS.  I'm not sure if the "name only" part has the same ramifications for BitShares as Namecoin, but since purchasing a domain destroys the currency in both models I'm assuming that it means that a BitShares name resolver will not need to worry about double spends either.

Is it not sufficient to receive a signed statement from a quorum of delegates for the particular data that you are interested in?

I remember Bytemaster posting that every 101 blocks (1 per delegate, thats just over 15 minutes) acted like a snapshot.  Would this be similar to a 'meta-block' that you are talking about?  At ~15 minutes each it would be similar to Namecoin.

Like I said, I posted this because a few things didn't make sense.  When I asked around about the BitShares lightweight client I got the impression that it was a trusted server model ... which I didn't understand given that you could rely on a quorum.

While a lightweight client wouldn't want to have to tally the votes to figure out who a valid delegate is, I would assume that you could bootstrap new delegates by including a proof of some kind in each block.

Sorry for the basic questions.  I did some light googling, but I didn't see much on BitShares specific lightweight clients.  Is there a blog article I'm missing?

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.

I'm not a delegate, yet, and `wallet_delegate_update_signing_key` throws an error.  Is there some other way to update the account?  I would prefer to send only the signing keys to my sys admin.

Thank you for this, it should be part of the official delegate how-to.

We could set up a delegate hangout where we could record the community's questions as well...if you are interested.  Just pm me if you are

I don't know the process, I'm just following whatever Toast tells me to do.  But I would be happy to do a delegate hangout! 

This is great. Probably the best and most comprehensive delegate proposal our community has seen yet.

We should all thank toast for poaching indolering

You apparently didn't read the proposal very carefully  .

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.  It’s time we start working together to end online censorship and make the internet safe from corrupt governments.

I am, however, incredibly grateful to Toast for believing in me and helping me bring this to your community.  I hope we can do something important.

I updated the original post to include information about what .p2p is.

The other questions related to creating a new DAC.  Currently, we cannot boot up a new DAC because we need the existing infrastructure (delegates, exchange volume, etc). 

However, it might make sense to create a new DAC that is tailored to this task in the future.  For example, a trusted base doesn't need 10-second transaction times – this bloats the blockchain and increases the network activity required by the client.  Bitcoin's traditional 10 minute block intervals matches the existing DNS system rather well.

Again, however, if a DAC is created there will be a share drop on BTS.

Im wondering in the future which blockchain would you prefer be used for Tor domain lookup? Will it be BitShares, Namecoin or Ethereum?

It depends on the security, I haven't had the time to review how POS impacts the security model.

If its going to be BitShares, are you or someone here going to create a patch of the Tor Browser that looks up domain names on the BTS blockchain, and hope that the Tor project accepts the patch ?

The first step to build a compatible solution, then worry about integration with Tor.  We are actually anticipating that we will have to throw away whatever solution we end up using initially.  Fundamentally, the browsers need to modularize their system for checking the authenticity of certificates.  We can still build a secure interim solution but the options are all hacks.

I won't be doing that coding.  I'm a UX developer, I enjoy programing and I do have to understand the internals of these systems but I stay away from any security related code.

Im also wondering what you think of the anti squatter ideas that were part of the DNS plan? As I understand it an organisation like Wikileaks would have to compete in a DNS auction to get its Wikileaks.bit domain name.

I'm not familiar with them all, but I don't care for your auctioning of domain names.  I am something of an anti-squatting crusader but I think the problem is overblown.