Lenor5.3090
Member
Offline
Activity: 161
Merit: 11
|
|
April 13, 2018, 10:17:37 AM |
|
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.
|
|
|
|
milkpeace67
Newbie
Offline
Activity: 84
Merit: 0
|
|
April 13, 2018, 10:20:43 AM |
|
Any road maps I can check on? Any websites I can find more information?
|
|
|
|
d5000
Legendary
Offline
Activity: 4032
Merit: 7232
Decentralization Maximalist
|
|
April 13, 2018, 08:20:45 PM |
|
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
|
|
April 14, 2018, 05:20:44 AM |
|
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
Legendary
Offline
Activity: 4032
Merit: 7232
Decentralization Maximalist
|
|
April 15, 2018, 01:34:13 AM |
|
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
|
|
April 15, 2018, 06:19:50 PM |
|
Is this a plan?
Looks very good for me. Done. https://github.com/B-DNS/Firefox/issues/5Now 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
|
|
April 15, 2018, 06:23:57 PM |
|
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?
|
|
|
|
|
BtcVolcano
|
|
April 15, 2018, 07:00:29 PM |
|
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
Legendary
Offline
Activity: 4032
Merit: 7232
Decentralization Maximalist
|
|
April 15, 2018, 08:53:02 PM |
|
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
|
|
April 17, 2018, 09:11:00 AM |
|
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
Copper Member
Newbie
Offline
Activity: 112
Merit: 0
You never knows until you try
|
|
April 17, 2018, 09:18:57 AM |
|
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
Legendary
Offline
Activity: 4032
Merit: 7232
Decentralization Maximalist
|
|
April 17, 2018, 02:08:06 PM |
|
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: 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: {"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
|
|
April 17, 2018, 02:24:03 PM |
|
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
|
|
April 17, 2018, 07:01:12 PM |
|
Hmm ... I get a similar error: {"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. 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
|
|
April 17, 2018, 07:07:52 PM |
|
Okay ... 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
|
|
April 17, 2018, 07:30:28 PM |
|
One last thing for today: See https://en.wikipedia.org/wiki/List_of_HTTP_status_codesfor 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
Legendary
Offline
Activity: 4032
Merit: 7232
Decentralization Maximalist
|
|
April 17, 2018, 08:32:38 PM |
|
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
|
|
April 20, 2018, 06:45:32 AM |
|
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
Legendary
Offline
Activity: 4032
Merit: 7232
Decentralization Maximalist
|
|
April 20, 2018, 10:04:07 AM |
|
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. 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: --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.
|
|
|
|
|