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

hornetsnest

hero member

Activity: 1459

Merit: 973

Quote from: d5000 on April 29, 2018, 03:23:49 PM

Quote from: mt55 on April 28, 2018, 07:24:31 PM

True though that the technology also needs to advance as it also does for other coins with active development. Standing the test of time is one thing, active development the other.

There is active development. I've already mentioned the ConsensusJ light client.

The full client, namecoin-core follows Bitcoin development closely, the last update was 7 days ago.

The problem, for me, is still usability. It is still too difficult for the "general public" to use Namecoin. The Blockchain DNS project (browser extensions) I mentioned earlier is a big step forward as it works on two of the most popular browsers and works out-of-the-box. I think porting the Blockchain DNS extension to the remaining browsers (Safari and Edge/IE) and with a stable light client (ConsensusJ or Electrum) Namecoin can be a success.

The main reason namecoin is not heavily traded is because traders don't have a lite client to store their coins off exchanges.Same goes for regular Joe who has no interest in bit/dns and only wants a solid coin to use to buy his trash on the internet wherever a shop accepts namecoin.It all boils down to economics and the whole namecoin economy is wrong by only appealing to a niche audience.We are not all geeks but have a lot of respect for the developers of this legacy coin and many want to trade and use it for non geek stuff too.

trantute2

hero member

Activity: 784

Merit: 544

Quote from: d5000 on April 29, 2018, 03:23:49 PM

Quote from: mt55 on April 28, 2018, 07:24:31 PM

True though that the technology also needs to advance as it also does for other coins with active development. Standing the test of time is one thing, active development the other.

There is active development. I've already mentioned the ConsensusJ light client.

The full client, namecoin-core follows Bitcoin development closely, the last update was 7 days ago.

The problem, for me, is still usability. It is still too difficult for the "general public" to use Namecoin. The Blockchain DNS project (browser extensions) I mentioned earlier is a big step forward as it works on two of the most popular browsers and works out-of-the-box. I think porting the Blockchain DNS extension to the remaining browsers (Safari and Edge/IE) and with a stable light client (ConsensusJ or Electrum) Namecoin can be a success.

Since you mention that: I stumbled over the signatures (https://github.com/namecoin/gitian.sigs) of the current namecoin version (https://namecoin.org/download/) which obviously is 0.13.99.

There are also signatures for version 0.15.99! Does anyone know more?

As a finger exercise:

How to use those signatures? (Because it always works a little bit different for each project (here I stay with version 0.13.99). E.g. BitcoinUnlimited signs hash sums via Bitcoin's message signature system, which is only consequent: https://www.bitcoinunlimited.info/download. Some projects do not even provide signatures.)

Firstly download the software, e.g. via

Code:

wget https://namecoin.org/files/namecoin-core-0.13.99-name-tab-beta1-notreproduced/namecoin-0.13.99-i686-pc-linux-gnu.tar.gz

Then import the corresponding gpg-key:

Code:

gpg --keyserver keyserver.ubuntu.com --recv F8F7BF85

Which returns something similar to:

Code:

gpg: requesting key F8F7BF85 from hkp server keyserver.ubuntu.com
gpg: key F8F7BF85: public key "Jeremy Rand (Master Key) " imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)

You can find the key here:

https://keyserver.ubuntu.com/pks/lookup?op=vindex&search=JeremyRand&fingerprint=on

Via searching for "JeremyRand" at

https://keyserver.ubuntu.com/

Then, you must clone the signature repository of namecoin

Code:

git clone https://github.com/namecoin/gitian.sigs.git

And enter the corresponding directory

Code:

cd gitian.sigs/0.13.99-name-tab-beta1-linux/JeremyRand/

Check the signature

Code:

gpg --verify namecoin-linux-0.13-build.assert.sig

Which returns

Code:

gpg: assuming signed data in `namecoin-linux-0.13-build.assert'
gpg: Signature made Sa 15 Okt 2016 22:13:13 CEST using RSA key ID 786D6570
gpg: Good signature from "Jeremy Rand (Master Key) "
gpg: aka "Jeremy Rand "
gpg: aka "Jeremy Rand "
gpg: aka "Jeremy Rand "
gpg: aka "Jeremy Rand "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 5174 0B7C 732D 572A 3140 4010 6605 55E1 F8F7 BF85
Subkey fingerprint: 541D DF77 302B 6847 2806 D912 B3F2 D165 786D 6570

Or alternatively

Code:

gpg --verify namecoin-linux-0.13-build.assert.sig namecoin-linux-0.13-build.assert

Output is similar without the "assuming bla fasel". This shows that the information in the assert-file is signed by Jeremy Rand. The sig-file contains the signature and the assert-file contains sha256sums of the namecoin files.

Finally, find the sha256sum of the downloaded file in the assert-file

Code:

ef0fee861afe66cbf06de162ee5ee3cb88b43d281341d2f3f24ee9e9494ce5a1 namecoin-0.13.99-i686-pc-linux-gnu.tar.gz

And do something similar with the downloaded file like

Code:

sha256sum namecoin-0.13.99-i686-pc-linux-gnu.tar.gz | grep -o ef0fee861afe66cbf06de162ee5ee3cb88b43d281341d2f3f24ee9e9494ce5a1

If this returns

Code:

ef0fee861afe66cbf06de162ee5ee3cb88b43d281341d2f3f24ee9e9494ce5a1

Everythin seems fine.

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

Quote from: mt55 on April 28, 2018, 07:24:31 PM

True though that the technology also needs to advance as it also does for other coins with active development. Standing the test of time is one thing, active development the other.

There is active development. I've already mentioned the ConsensusJ light client.

The full client, namecoin-core follows Bitcoin development closely, the last update was 7 days ago.

The problem, for me, is still usability. It is still too difficult for the "general public" to use Namecoin. The Blockchain DNS project (browser extensions) I mentioned earlier is a big step forward as it works on two of the most popular browsers and works out-of-the-box. I think porting the Blockchain DNS extension to the remaining browsers (Safari and Edge/IE) and with a stable light client (ConsensusJ or Electrum) Namecoin can be a success.

versprichnix

sr. member

Activity: 876

Merit: 291

Quote from: rainypu on April 26, 2018, 11:55:44 AM

Hi guys. I have been interested in Namecoin for quite some time, but I'm not sure of exactly who are the relative representatives (assuming Coblee would be for Litecoin, Gavin would be for Bitcoin, etc).

It's decentralised, so there's no single "god" for namecoin. This increases the propability to survive attacks.

mt55

sr. member

Activity: 490

Merit: 250

Quote from: BtcVolcano on April 15, 2018, 02:00:29 PM

Quote from: mt55 on April 09, 2018, 11:50:11 PM

Quote from: sokol2504 on March 11, 2018, 06:49:13 AM

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.

True though that the technology also needs to advance as it also does for other coins with active development. Standing the test of time is one thing, active development the other.

rainypu

newbie

Activity: 95

Merit: 0

Hi guys. I have been interested in Namecoin for quite some time, but I'm not sure of exactly who are the relative representatives (assuming Coblee would be for Litecoin, Gavin would be for Bitcoin, etc).

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

Quote from: trantute2 on April 20, 2018, 01:05:21 PM

Cool. I will try it out tomorrow. Do you know some bit-domains or some site for browsing bit-domains so that I can play around with the name resolution? Thanks in advance.

Try http://nf.bit (Namecoin forum) and http://nx.bit (Blockchained.com). Both still work.

There is a (pretty old) list here.

I today earlier tried out the leveldbtxcache option and it didn't work (it threw a "Connection refused" error) but it's well possible that the blockchain part that is needed for name resolution wasn't fully downloaded.

trantute2

hero member

Activity: 784

Merit: 544

Quote from: d5000 on April 20, 2018, 05:04:07 AM

Quote from: trantute2 on April 20, 2018, 01:45:32 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.

Quote

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. Huh

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.

Cool. I will try it out tomorrow. Do you know some bit-domains or some site for browsing bit-domains so that I can play around with the name resolution? Thanks in advance.

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

Quote from: trantute2 on April 20, 2018, 01:45:32 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.

Quote

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. Huh

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.

trantute2

hero member

Activity: 784

Merit: 544

Quote from: d5000 on April 17, 2018, 03:32:38 PM

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?

Quote from: d5000 on April 17, 2018, 03:32:38 PM

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.

Quote from: d5000 on April 17, 2018, 03:32:38 PM

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. Huh

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

Quote from: trantute2 on April 17, 2018, 02:30:28 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.

Quote

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

hero member

Activity: 784

Merit: 544

One last thing for today: See

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

for the 500 error. It says:

Quote

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.

trantute2

hero member

Activity: 784

Merit: 544

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

hero member

Activity: 784

Merit: 544

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

hero member

Activity: 784

Merit: 544

Quote from: d5000 on April 17, 2018, 09:08:06 AM

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.

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

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).

Payportal

copper member

Activity: 112

Merit: 0

You never knows until you try

Quote from: wiked1 on April 17, 2018, 04: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.

agree, usually it takes few hours, even not few Wink

wiked1

sr. member

Activity: 427

Merit: 266

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.

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

Quote from: trantute2 on April 15, 2018, 01:23:57 PM

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

Quote

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 ...)

BtcVolcano

sr. member

Activity: 672

Merit: 250

Quote from: mt55 on April 09, 2018, 11:50:11 PM

Quote from: sokol2504 on March 11, 2018, 06:49:13 AM

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.

Topic: [announce] Namecoin - a distributed naming system based on Bitcoin - page 31. (Read 596107 times)