Namecoin was a good idea, but it suffers from many flaws due to its DNS-based architecture, it's single block chain, and of course, the fact that it is based on the bitcoin block chain, limiting it's flexibility somewhat.
A few issues typical of the todays DNS systems (*but not Namecoin) are as follows:
"Parked" domains and hoarding
Man-in-the-middle attacks*
Government-based censorship*
Commercial DNS redirection*
Tracking and traffic analysis*
Limited to specific domains
As you may know, Namecoin is one solution to
Zooko's Triangle, that is, addresses are secure, memorable, and global as well. The traditional DNS system is close, but not quite global due to consensus issues and censorship.
Namecoin is also easily susceptible to hoarders and "parked" websites caused by the way it is modelled on ordinary dns servers. It is also, by nature, impermanent due to the irreversible loss of coins upon creation of an address.
It is fairly simple to build a system that circumvents these issues and builds upon the decentralized and flexible nature of the Ethereum blockchain. Please let me know if you have any ideas for the following potential project.
If the implementation is based on Namecoin, we would have a single "name contract" and Ethereum would be spent in creating new addresses within the contract, the memory of which could quickly balloon and become costly in terms of processing power. On the Ethereum blockchain, a single name contract would be inefficient, due to these increasing costs.
Ie, the first address added would cost x ether to add to memory (including checks on whether it already exists, which grow as the number of addresses increase) , the nth address could therefore cost significantly more than the first. This may be a good thing, in that it prevents a exceedingly large number of addresses to be claimed for no content, but disproportionately benefits early users and domain trolling, which are both significant problems with Namecoin and the DNS system.
In an alternative situation, there are many "name contracts" with relatively small memories, and trust relationships between them.
Ie,
A contract, [internally] named "hello" acts as a root server to a hypothetical user.
The contents of the memory of a contract can be used to either point to resources on or off the blockchain.
In the case of the "hello" contract,
(0,"hello", "[own contract address]")
(1,"jam10o", "[other name-contract address ]")
(2,"world", ("ethereum.org")
(3,"...", "... ")
etc..
Users can select their own root contract, and gain access to all contracts and addresses it links to. Name contracts can either
a) accept "submitted" addresses with address deletion controlled by a "moderator" or muiltiple moderators, using a scheme similar to the DAC example in the wiki,
Or
b) be completely under the control of a single owner (such as, hypothetically me, owning the Jam10o name contract example above).
In the case of the above contract, the URL hello:world points to the Ethereum homepage. These relationships could be used to create a chain to any resource defined in any compatible contract, given the network is sufficiently linked. Potentially, it could also introduce annoying recursive urls, such as hello:jam10o:hello:jam10o:... ...:hello:world or, if contracts do not "return" links, an issue of "non-reversible" urls may come into play (hello:jam10o is valid, whereas jam10o:hello is not).
Using these contracts, anyone who needs to can own their own vanity url that is both memorable, secure, and globally accessible (with certain caveats) due to the need to have contracts link to each other. An unsavoury character may "park" muiltiple contracts on the blockchain, but without any users finding utility in them, their contracts will be "orphaned" from the web, which may act as a web of trust. A trusted user who provides utility to the community however, will certainly be linked by muiltiple contracts, increasing their visibility and traffic. Content may be self-censored in this manner, however due to the fact that the "censored" contract is still on the blockchain, it can still be easily accessed.
Therefore you have an un-censorable, but still moderatable and safe, dynamic naming system. Name resolution would need to be handled by an external client, which is why I put this in the "Projects" section of the forum:
A successful implementation of this system relies on a few elements:
A standard structure for participating contracts
An external DNS server linked to the Ethereum blockchain, capable of parsing the links between contracts
[and at some point in the future, a protocol that allows users to connect to one another without interception. Cjdns integration anyone?]
I'd love to hear what anyone has to say about this idea, feel free to implement it on the blockchain on release if it seems doable for you, (as the code will undoubtedly be reused by others). Discussion on possible contract standards, dns servers, and criticism of any flaws in the concept is welcome.
Comments
I see what you are saying though, I see it like a torrent tracker, once there is no more need for it, it disappears. So the person is obliged to make it "interesting" if not it disappears.
Let me see if I understand you correctly: let's say I create a contract "sneur" that is compatible (format/protocol-wise) with your contract "hello" above. The first address I register in sneur is "lax", of course, which links to my private webpage. Now, you don't explicitly mirror all the data in my contract, but you come to value our hypothetical future friendship and so deign to register an address that forwards to my contract. Thus, your users can type hello:sneur:lax and access my webpage just fine?
I don't know if you've thought of this (or if it's what you meant,) but a useful addition that I would add to my own brand of name resolution contract would be a feature to trust other such contracts; that is, as in the previous example, if I chose to trust your hello contract (based on the utility you provide,) then my contract would first search its own internal memory for an address but, failing that, would route it on to its trusted fellow name-resolution contracts. For example: I link hello in sneur as a "trusted" name-resolution list. Thereafter, users can simply input sneur:world to access "ethereum.org", even if sneur never explicitly refers to world.
I hope I haven't been obtuse.
The actual resolution of the contracts would be best left to an off-chain client, and different policies for resolution could be easily implemented as features of this application as opposed to the contracts themselves, which will ideally just be data storage with edit controls. That would be great, but as in any trust based system, it could have repercussions ie, bob trusts hello, which has a trusted path to jerry who has a different friend called bob. Unless of course, bob only accepts addresses directly in hello, in which case he all trust in hello must be ignored. This could cause confusion between different policies, and what good is a url if you can't share it?
What say we start hashing out a format so that we can maintain some sort of compatibility like you mentioned? Nothing has to be binding, of course, but I'd rather be compatible with someone else than a hermit.
Jam: I think that at least four keys are needed: an index (obviously,) label, address, and contact address. Now, the contact address can be optional, but I think it should be available and encouraged (so label owners can be contacted, but don't have to include to information if they don't want to.)
so ( 0, 'hello', '[own contact address]', '[email]' )
Your last post is pretty mind boggling even though my non dev mind cannot decipher how something like that would work on a technical side. If I understand it correctly it means that there would be no need to specificity the full address as it would auto select.
That my new found forum friend blew my mind.
This could then be applied to other aspects like VOIP/SIP as a protocol, as you mentioned there is still and issue with latency. The more I think about your comments, I could even see a decentralized TV as I had been reading recently about Bittorrents bitstream project.
Thanks for sharing your thoughts, helps non developers get a bit deeper with the ideas.
sneurlax: I didn’t think about adding contact addresses, but it does seem reasonable. That and specifying protocols.
How about this? A rough draft of the first link in "hello" (In pseudo-RLP)
[0x84, 0x00, 0x45, 'h', 'e', 'l', 'l', 'o', 0x82, "protocol", "address", 0x82, "protocol", "address"]
Or to make it less convoluted
The entire item is a list of four items, the first is the index, followed by label, followed by a two-item list containing protocol(s maybe? As a list within this list?) and address, followed by contact details in the same format. This should give enough flexibility, and can easily be extended with new features in the future by adding more keys or nesting lists.
I don't know if key => entry arrays are possible in ECLL, but if http => blurb.com isn't possible then we can just code in that i is the address and i+1 is the protocol, etc. etc. -- same situation is ECLL doesn't allow for subarrays, it just makes things less elegant (imo.)
So, address-first ([ "blurb.com", "http"; ]) or protocol-first ([ "http", "blurb.com" ])?
giannidalerta: a quick google search fails to return any joy on Chris Oden open transactions library. Mind sharing a link?
I based this off of the DAO example in the whitepaper, but in doing so, I noticed that the "exit" (on the ECLL wiki page) is "stop" in the whitepaper. Not really an issue. Would like some clarification though...
Contract accepts transactions only above 300 times the base fee (very rough overestimate of how much it actually needs..) FORTUNATELY it includes a feature to "withdraw" funds back to the owner. No "duplicate label" checks (yet).
Transaction data sent to the contract (from anyone granted permission) is in the format of [command, index, data] an owner can grant permission to any other person by setting their "index" to the address of the new editor, and "data" to "1". Available commands are adding to memory (1) removing from memory (0) and withdrawing ether (2)
"data" would normally be the structure described earlier, minus the index presumably, since it's in the transaction data?
This contract also acts as a "shared" storage of arbitrary data and units of ether.
This is a very rough draft, and if I've made any obvious errors in syntax or anything, please correct me.
Here we go //comments. [why the hell am I doing this on my phone... sorry about the space/tabs... ]
if tx.value < tx.basefee * 300:
//arbitrary value limit
stop
else:
//check if you have permission to edit
if contract.storage[tx.sender] == 0:
stop
else:
//delete command
if tx.data[0] == 0:
contract.storage[tx.data[1]] = 0
stop
//save command
else if tx.data[0] == 1:
contract.storage[tx.data[1]] = tx.data[2]
stop
//withdraw contract contents
else if tx.data[0] == 2:
mktx(tx.sender, (contract.balance - tx.basefee * 100))
stop
//using same magic number as vbuterin to check if this is the first run.
//first owner is hard coded. contract can be returned if magic number is restored to 0.
//(or deleted in order to gain the refund fee). your contract will come back to you... Someday.
if contract.storage[2^255+1] == 0:
contract.storage[2^255+1] = 1
contract.storage[*insert owner address here*] = 1
stop
Ethereum script for above contract as follows:
TXVALUE PUSH 0 MLOAD PUSH 300 MUL LT NOT PUSH 128 JMPI STOP PUSH 128 JMP PUSH 1 MLOAD NOT PUSH 128 JMPI PUSH 2 PUSH 255 EXP PUSH 1 SUB SLOAD PUSH 0 EQ NOT PUSH 47 JMPI PUSH 1 PUSH 2 MLOAD SSTORE PUSH 1 PUSH 2 MLOAD SSTORE TXSENDER SLOAD PUSH 0 EQ NOT PUSH 128 JMPI STOP PUSH 128 JMP PUSH 3 PUSH 0 ADD MLOAD PUSH 0 EQ NOT PUSH 128 JMPI PUSH 0 PUSH 2 MLOAD SSTORE STOP PUSH 128 JMP PUSH 3 PUSH 0 ADD MLOAD PUSH 1 EQ NOT PUSH 128 JMPI PUSH 3 PUSH 2 ADD MLOAD PUSH 2 MLOAD SSTORE STOP PUSH 128 JMP PUSH 3 PUSH 0 ADD MLOAD PUSH 2 EQ NOT PUSH 128 JMPI PUSH 4 MLOAD PUSH 4 MLOAD PUSH 4 MLOAD TXSENDER MKTX STOP
Now I have to figure out how to get this on the blockchain once I'm sure the blockchain is accepting contracts.
Jam10o wrote:
"the first address added would cost x ether to add to memory (including checks on whether it already exists, which grow as the number of addresses increase) , the nth address could therefore cost significantly more than the first."
I don't think that is necessarily true. You could simply do a hash of the address and store the corresponding name at the contract storage slot corresponding to the hash. The cost of the verification is always O(1), basically using the permanent storage as a hash table. (possibly with an offset to avoid overwriting contract code).
With this, a single contract is sufficient to store your entire name registry. It doesn't have the same properties of your proposition though, as it is unmoderatable. But it might be a useful construct for other registries.
Few questions: So the functions are 0 => delete, 1 => save, 2 => withdraw?
Why not just have 0 => edit, where to delete the entry you just set it to 0?
Why not just have it automatically refund the excess ether to the last sender?
Any word of how to / if we can store arrays?
One thing I thought of over the weekend is how we'll link contracts. How about using a function similar to a symbolic link (symlink?) We can add the contract address and perhaps use "contract" or "symlink" as the protocol. Or should linked contracts be in their own array instead of interspersing them throughout the name/address values?
Should we add some "date-registered" value? This would allow, for example, a functionality that could resolve address conflicts between linked contracts by returning the earliest-registered address.
About refunds - this happens in a root contract I'm working on now, doesn't happen in this contract because it's intended to only have a single user.
About dates - we don't have access to time, but we can add a simple counter (increases by one every transaction)
About links - as in the "protocol" space? Yep, we'd have to denote the protocol, and it would be simpler to use the same name/address notation.
Check out the github repo I threw together (todo ones exist, but aren't quite there yet)
https://github.com/jam10o/contracts
exit and stop are synonyms for now; but the ECLL and ES are still being worked on so that might change.
> I don't know if key => entry arrays are possible in ECLL
Just use
arr[sha256(key)] = val
and you got it (although there isn't a way to loop through/enumerate keys); it's ugly but it works since the probability of a collision is essentially zero.Name-contracts (done! By quite a few people already!)
Parsing Name-contracts (already implemented by Gavin Wood in Alethzero with his name registration contract)
"Mapping" contracts (I'm working on this! Stay tuned for something that works with the current client in the next few weeks. I have no idea what I'm doing but I'll get it done.)
Initial DNS/Namecoin support (shortly after the above gets done.)
Initial meshnet support(shortly after above, again.)
Update for whatever the canonical format will be for writing plugins to the client (whenever this is announced, hopefully before the mainnet is released.)
Quick security audit, and bug-squashing and initial "realease" of the full software (prior to mainnet release, ie Q3/Q4 this year.)
If anything, I'll be using this because I find it cool and it'll let me build a small VPN (if not a fully blown meshnet) with my own machines.
Please PM or comment if you feel like speeding this timeline up
Some pretty pictures incoming once I get to my work machine
Merkle trees might also be an approach to avoid hoarding on all the existing domain names; put a Merkle root of the name in. However, this leaves us with the awkward problem of trying to figure out if some dude claiming that he has the domain name actually does have it.. Perhaps we can use the public key if a site uses SSL, much doubt that being fool proof!(but at least the thought behind it is potentially trustless)
Zaki Manian makes a good point in Ethercasts.
In discussions on skype some have been worries about the of Ethereum creating the top NameReg. Only now i realize that this post might be what other others were talking about.
Main issue with your approach is that, the point of naming systems like namecoin is that human readable names relate to the same things for different people. Having people choose different name registries isnt conducive to that. I dont think we can afford to have chaos regarding who creates the top namereg. Besides, the top NameReg can be trustless anyway, though there is the problem with hoarding, and i dont really have a good trustless solution to that..
Edit: i suppose you could leave that and say that each page has a list of domain-givers, and those can contain sublists. Not sure what the consequences of that are.
I accept the point that in any practical implementation, having people choose different "top" servers will cause confusion from the perspective of an internet user. I couldn't reliably or safely, say, give the url to a website to a friend who has chosen a different top server than me. But knowing this, given the (potentially pseudonymous) identity of a friend, I can find the exact resource the friend is referencing; it isn't an issue of "choosing" a NameReg, it is one of entirely controlling your own.
There will certainly be multiple implementations of name registration on ethereum, in different data structures, with varying levels of trust or security. Trustless implementations will always be vulnerable to gaming and hoarding; whereas trusting someone else with your DNS will be hard for those conscious of security or censorship. The concept here is to let anyone be their own registrar (and ideally, create a system that is more flexible, or at least interesting, than the current web). Chaos is a feature here
Just because it is not trustless doesnt mean it is untrustworthy, or that you need 'very focussed' trust. You can 'trustlessly' have a democracy of some kind, but you still need to trust the members not to vote for awful things. This could also apply for lists the top registries might use to try avoid hoarding with respect to existing domain names.
I think the word 'established' sounds more final than the NameReg code is... It was put onto the testnet, and made central for the client. That doesnt have that much finality to it! It certainly isnt the same code that will be uploaded on the live net.