[announce] Namecoin - a distributed naming system based on Bitcoin

[Lenor5.3090]

A long coin is developed. Because of this, it is hard for the project to remain active and hope that the project side will remain passionate.

[1713994478]

1713994478

[1713994478]

1713994478

[milkpeace67]

Any road maps I can check on? Any websites I can find more information?

[d5000]

Hmm ... I think some "centralized" server is always necessary, otherwise people must download and maintain their own copy of the namecoin blockchain.

Yes, but the IP of the server with the Namecoin daemon being configurable would be better. I haven't still looked into the details, but in the Blockchain DNS Chrome extension there seems no easy way to choose a custom server to do the resolution (e.g. without changing the code). In theory you could configure that "alternative DNS server" address in the browser settings without any extension, but that's already too difficult for most users (otherwise, there would be much more OpenNIC users, for example).

So an extension based on Blockchain DNS with a default server and an easy-to-use interface (e.g. with infographics and explanations, these details are important for usability and mass adoption, I think) to change the server would be the best way to go, for me. The extension could contain a (regularly updated) list of available servers.

This restricts usability too much. Or is there something like a light client for namecoin which only keeps track of the domain names?

There seems to be an Electrum client for Namecoin, but I never tried it and so I don't know if it is sufficient to keep track of the domain names.

[trantute2]

Yes, but the IP of the server with the Namecoin daemon being configurable would be better.

I see.

I haven't still looked into the details, [...]

Me neither. And I feel bad about that. However, it is also important to figure out a reasonable roadmap.

[...] but in the Blockchain DNS Chrome extension there seems no easy way to choose a custom server to do the resolution (e.g. without changing the code). In theory you could configure that "alternative DNS server" address in the browser settings without any extension, but that's already too difficult for most users (otherwise, there would be much more OpenNIC users, for example).

So an extension based on Blockchain DNS with a default server and an easy-to-use interface (e.g. with infographics and explanations, these details are important for usability and mass adoption, I think) to change the server would be the best way to go, for me. The extension could contain a (regularly updated) list of available servers.

Okay. Then let's conclude: We do not need to develop an addon from scratch. We can use blockchain-dns as a starting point. Convincing the developer(s) of this addon to do the work for us would be most efficient. Alternatively, I could fork the github-repository and we introduce the corresponding changes. Which is clearly more work, but I think the hardest part is to get used to new concepts.

But firstly, we should contact the developer(s). The project looks alive. I can do this via github. I am traveling this weekend and could contact them Sunday evening.

Is this a plan?

[d5000]

Is this a plan?

Looks very good for me.

The second part could be to investigate if the Electrum client is capable to resolve NMC addresses for "a little bit more advanced" users. I think however that this wouldn't be a very easy task, as I just looked into Electrum-NMC's github repo, and it seems to be 1) a bit old (its codebase is older than the "big vulnerability fix" earlier this year) and 2) is not marked as "ready for the end user".

So likely it needs the attention of skilled developers.

PS: Just saw that there is an actively developed light client called ConsensusJ. It seems to be still experimental, but I'll look at it.

[trantute2]

Is this a plan?

Looks very good for me.

Done.

https://github.com/B-DNS/Firefox/issues/5

Now we have to wait. I am not sure anymore, whether the project is alive or not. Last code changes were done 5 months ago.

I would recommend, that we wait for a week or two and then fork the project.

[trantute2]

PS: Just saw that there is an actively developed light client called ConsensusJ. It seems to be still experimental, but I'll look at it.

A light client would be perfect. But what about this:

It synchronizes faster and uses less storage than Namecoin Core, but trusts Namecoin miners more than Namecoin Core does.

Does a light client not fully depend on the set of full nodes?

 

[vsrocks]

Namecoin (NMC) all-in-one info now added here:

https://chatoncrypto.com/Crypto/C/31-NMC-Namecoin


Thanks.

[BtcVolcano]

Namecoin has many useful functions, therefore it is impossible to consider it simply as an ordinary coin. It is an innovation that will show itself to the world. I read information about the Safinus project as an investment platform. I also see a lot of revolutionary innovations there

Namecoin also has an incredible history in the crypto space. I hope it can go back up again as it is one of the oldest coins out there!

I agree in many respects with you and your opinion. Now probably have to still look and technology that will be in demand in the future. But this coin test of time and I think it is still manifest themselves in the future.

[d5000]

A light client would be perfect. But what about this:

It synchronizes faster and uses less storage than Namecoin Core, but trusts Namecoin miners more than Namecoin Core does.

Does a light client not fully depend on the set of full nodes?

You're right. I think this is the general problem light clients have (see Thin Client Security, I think you may know it already). As ConsensusJ seems to be based on BitcoinJ, it seems to feature a different security model than Electrum (it selects a set of full nodes and compares their data, instead of selecting one single "trustworthy" node).

In the case of Namecoin name registrations, there is less potential for attacks to occur for the average user (although there may be so when the project becomes really popular). Additionally, the light client, as far as I understand this documentation website  does only support name lookups but not registrations of new names. (I'm starting with that and still haven't installed it, so I may be wrong with this; the installation procedure seems to be still no "one-click-procedure", that is other usability challenge to improve ...)

[wiked1]

The only reason I never bought namecoin is because there is no electrum.Not too many peeps want to spend all day downloading a whole blockchain and less want to leave coins sitting on an exchange either.

[Payportal]

The only reason I never bought namecoin is because there is no electrum.Not too many peeps want to spend all day downloading a whole blockchain and less want to leave coins sitting on an exchange either.

agree, usually it takes few hours, even not few

[d5000]

I installed the ConsensusJ light client now, and it runs (instructions are here). But I run into a problem.

When I try to access the RPC server via curl, I get an HTTP error 500 ("Internal Server Error"). I used the example in the documentation:

Code:

curl --user user:pass --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"name_show","params":["d/domob"]}' -H 'content-type:text/plain;' http://127.0.0.1:8080

and the error I got was:

Code:

{"jsonrpc":"1.0","id":"curltext","error":{"code":0,"message":"Server returned HTTP response code: 500 for URL: https://namecoin.webbtc.com/name/d/nf.json?history&with_height&with_rawtx&with_mrkl_branch&with_tx_idx&raw","data":{"exceptionTypeName":"java.io.IOException","message":"Server returned HTTP response code: 500 for URL: https://namecoin.webbtc.com/name/d/nf.json?history&with_height&with_rawtx&with_mrkl_branch&with_tx_idx&raw"}}}

It's strange that it connects to a "webbtc.com" domain (a block explorer), and when I enter the URL mentioned in the error in a browser, I also get the Internal Server Error. So I think there's some configuration step I missed ... it should use my own client and not a block explorer to lookup a name, or not?

I don't know also how to set up the RPC user and password. Normally there should be a "$coin.conf" file to setup these things, but simply placing a "namecoin.conf" in the directory doesn't change anything (I also didn't really expect that to work, haha).

[trantute2]

I installed the ConsensusJ light client now, and it runs (instructions are here). But I run into a problem.

I will also try it in the evening and will come back to you.  

[trantute2]

Hmm ... I get a similar error:

Code:

{"jsonrpc":"1.0","id":"curltext","error":{"code":0,"message":"Server returned HTTP response code: 500 for URL: https://namecoin.webbtc.com/name/d/domob.json?history&with_height&with_rawtx&with_mrkl_branch&with_tx_idx&raw","data":{"exceptionTypeName":"java.io.IOException","message":"Server returned HTTP response code: 500 for URL: https://namecoin.webbtc.com/name/d/domob.json?history&with_height&with_rawtx&with_mrkl_branch&with_tx_idx&raw"}}}

Check the terminal, where namecoinj is running while the curl command is executed. There might be an exception, including "HTTP response code: 500" (see below), which in my case correlates with the curl command. I think, there lies the dog buried.

Code:

java.lang.reflect.InvocationTargetException: null
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_162]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_162]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_162]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_162]
	at com.googlecode.jsonrpc4j.JsonRpcServer.invoke(JsonRpcServer.java:513) [jsonrpc4j-1.1.jar!/:na]
	at com.googlecode.jsonrpc4j.JsonRpcServer.handleObject(JsonRpcServer.java:384) [jsonrpc4j-1.1.jar!/:na]
	at com.googlecode.jsonrpc4j.JsonRpcServer.handleNode(JsonRpcServer.java:293) [jsonrpc4j-1.1.jar!/:na]
	at com.googlecode.jsonrpc4j.JsonRpcServer.handle(JsonRpcServer.java:230) [jsonrpc4j-1.1.jar!/:na]
	at com.googlecode.jsonrpc4j.JsonRpcServer.handle(JsonRpcServer.java:207) [jsonrpc4j-1.1.jar!/:na]
	at com.googlecode.jsonrpc4j.spring.JsonServiceExporter.handleRequest(JsonServiceExporter.java:40) [jsonrpc4j-1.1.jar!/:na]
	at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle(HttpRequestHandlerAdapter.java:51) [spring-webmvc-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:967) [spring-webmvc-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:901) [spring-webmvc-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970) [spring-webmvc-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:872) [spring-webmvc-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:661) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846) [spring-webmvc-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) [tomcat-embed-websocket-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99) [spring-web-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:105) [spring-web-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:81) [spring-web-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:197) [spring-web-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:861) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_162]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_162]
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-8.5.15.jar!/:8.5.15]
	at java.lang.Thread.run(Thread.java:748) [na:1.8.0_162]
Caused by: java.io.IOException: Server returned HTTP response code: 500 for URL: https://namecoin.webbtc.com/name/d/domob.json?history&with_height&with_rawtx&with_mrkl_branch&with_tx_idx&raw
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1894) ~[na:1.8.0_162]
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492) ~[na:1.8.0_162]
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263) ~[na:1.8.0_162]
	at java.net.URL.openStream(URL.java:1045) ~[na:1.8.0_162]
	at com.fasterxml.jackson.core.JsonFactory._optimizedStreamFromURL(JsonFactory.java:1547) ~[jackson-core-2.8.8.jar!/:2.8.8]
	at com.fasterxml.jackson.core.JsonFactory.createParser(JsonFactory.java:783) ~[jackson-core-2.8.8.jar!/:2.8.8]
	at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2797) ~[jackson-databind-2.8.8.jar!/:2.8.8]
	at org.libdohj.names.NameLookupLatestRestMerkleApi.getUntrustedNameHistory(NameLookupLatestRestMerkleApi.java:130) ~[libdohj-namecoin-0.14-SNAPSHOT.jar!/:na]
	at org.libdohj.names.NameLookupLatestRestMerkleApi.getLatestUntrustedNameData(NameLookupLatestRestMerkleApi.java:103) ~[libdohj-namecoin-0.14-SNAPSHOT.jar!/:na]
	at org.libdohj.names.NameLookupLatestRestMerkleApi.getNameTransaction(NameLookupLatestRestMerkleApi.java:63) ~[libdohj-namecoin-0.14-SNAPSHOT.jar!/:na]
	at org.namecoin.bitcoinj.spring.service.NameLookupService.name_show(NameLookupService.java:157) ~[bitcoinj-server-0.2.7-SNAPSHOT.jar!/:na]
	... 55 common frames omitted

I did not set the environment variable as recommended in the instructions. And I used OpendJDK.

[trantute2]

Okay ...

Code:

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64

... makes no difference.

I will stop here for today since I have to get up early in the morning tomorrow. And two beers are waiting ...

Maybe we should also try Oracle's java?

[trantute2]

One last thing for today: See

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

for the 500 error. It says:

500 Internal Server Error
    A generic error message, given when an unexpected condition was encountered and no more specific message is suitable.

(also compare it with https://de.wikipedia.org/wiki/HTTP-Statuscode)

Maybe it is not our fault. Maybe the server, the curl command is aiming for, is down or similar. But this is only one hypothesis.

And I have to admit, that I do not understand the curl command yet.

[d5000]

Maybe it is not our fault. Maybe the server, the curl command is aiming for, is down or similar. But this is only one hypothesis.

That is also my hypothesis, as I checked the link to the webbtc block explorer in the error message and I get the same HTTP 500 error in a browser.

But ... if all what the "light client" does is to connect to a single, centralized block explorer to show the status of a name, what is its purpose? I could use curl, wget or another tool connecting directly to the block explorer and would need no light client. And the light client does download a part of the blockchain.

So I guess that there is some additional configuration step I didn't see, to ensure the light client checks several nodes for the required information (and not only the webbtc node). However, in the documentation, the URL of the webbtc block explorer is also mentioned several times.

And I have to admit, that I do not understand the curl command yet.

The curl command basically does what the "name_show" command of the namecoin-cli program would do (it basically shows who registered a domain/name, see here), only that you send it in JSON format directly to the "server" (in this case, your light client acts as a server).

By the way: Just read this reddit message - it seems that electrum-nmc isn't dead and is intended to be used in the future for name registrations. Maybe it's - once ready - a better choice for end users than the difficult-to-use consensusj client, but it should at least upgraded to v3.0.5 because of the vulnerability.

[trantute2]

But ... if all what the "light client" does is to connect to a single, centralized block explorer to show the status of a name, what is its purpose? I could use curl, wget or another tool connecting directly to the block explorer and would need no light client. And the light client does download a part of the blockchain.

True. Do you know where the blockchain is stored on the HD?

So I guess that there is some additional configuration step I didn't see, to ensure the light client checks several nodes for the required information (and not only the webbtc node). However, in the documentation, the URL of the webbtc block explorer is also mentioned several times.

Yes. And I still do not understand, what the tool is good for.

The curl command basically does what the "name_show" command of the namecoin-cli program would do (it basically shows who registered a domain/name, see here), only that you send it in JSON format directly to the "server" (in this case, your light client acts as a server).

In the description, it sounds like you can use namecoinj (for simplicity i will call it namecoinj) together with namecoin-cli. What is the benefit of that? Could it be, that namecoinj does not download the domain data? I played around with bitcoinj a few years ago to build my own wallet. It's quite easy to use. As far as I know, a light client only downloads the block headers, right (https://en.bitcoin.it/wiki/Thin_Client_Security )? And maybe, the domain data is not stored in the headers. That is, namecoinj is simply a namecoin wallet. For domain resolution, it needs a namecoin block explorer. 

[d5000]

True. Do you know where the blockchain is stored on the HD?

In my case the client created a sub-directory called LibdohjNameLookupDaemon.spvchain (in the same directory where the JAR file is located) and it seems to contain the (partial) blockchain.

Could it be, that namecoinj does not download the domain data? [...] That is, namecoinj is simply a namecoin wallet. For domain resolution, it needs a namecoin block explorer.  

Seems so. But finally, I think I found the solution: If one doesn't want to rely on a block explorer one must use the following command line argument:

Code:

--namelookup.latest.algo=leveldbtxcache

This creates a name database on the HD based of the informations in full blocks (not just headers), it will sync a bit longer.

Here is a forum thread about the light client, that gave me the right clue.

BTW: the webbtc url continues to throw "Internal Server Error" for me. So it seems it isn't a temporary failure.