was freeland listed on cryptopia?
if so novaexchange is offering free listings to coins previously listed on cryptopia.
unfortunately novaexchange is not useful to north americans, but the rest of the world is still a big place.

correctly spelled http://hash-to-coins.com

was bitcoinfast listed on cryptopia?
if so novaexchange is offering free listings to coins previously listed on cryptopia.
unfortunately novaexchange is not useful to north americans, but the rest of the world is still a big place.

novaexchange is offering free listings to coins previously listed on cryptopia.
unfortunately novaexchange is not useful to north americans, but the rest of the world is still a big place.

although, you probably still need to get a block explorer put into place

novaexchange is offering free listings to coins previously listed on cryptopia.
unfortunately novaexchange is not useful to north americans, but the rest of the world is still a big place.

novaexchange is offering free listings to coins previously listed on cryptopia.
unfortunately novaexchange is not useful to north americans, but the rest of the world is still a big place.

and novaexchange is offering free listings to coins previously listed on cryptopia.
unfortunately novaexchange is not useful to north americans, but the rest of the world is still a big place.

i'm trying to do a getinfo (or even getnetworkinfo, both fail) via network RPC (not the console or command-line)

using the curl command i get the following output

% /usr/bin/curl --max-time 8 --verbose --ignore-content-length --user user:pass --data-binary {"jsonrpc": "1.0", "id":"verscheck", "method": "getnetworkinfo", "params": [] } 192.168.0.199:44663/


*   Trying 192.168.0.199...
* TCP_NODELAY set
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to 192.168.0.199 (192.168.0.199) port 44663 (#0)
* Server auth using Basic with user 'user'
> POST / HTTP/1.1
> Host: 192.168.0.199:44663
> Authorization: Basic Q2hlZXNlOk1vbmV5NE5vdGhpbmd4
> User-Agent: curl/7.61.1
> Accept: */*
> Content-Length: 79
> Content-Type: application/x-www-form-urlencoded
> 
} [79 bytes data]
* upload completely sent off: 79 out of 79 bytes
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Thu, 28 Mar 2019 08:00:06 GMT
< Content-Length: zu
* no chunk, no close, no size. Assume close to signal end
< 
{ [559 bytes data]
100   638    0   559  100    79     90     12  0:00:06  0:00:06 --:--:--   102* Operation timed out after 8000 milliseconds with 559 bytes received
100   638    0   559  100    79     69      9  0:00:08  0:00:08 --:--:--    79
* Closing connection 0
curl: (28) Operation timed out after 8000 milliseconds with 559 bytes received
{"result":{"version":130900,"subversion":"/Mooncoin:0.13.9/","protocolversion":70016,"localservices":"000000000000000d","localrelay":true,"timeoffset":2,"connections":8,"networks":[{"name":"ipv4","limited":false,"reachable":true,"proxy":"","proxy_randomize_credentials":false},{"name":"ipv6","limited":false,"reachable":true,"proxy":"","proxy_randomize_credentials":false},{"name":"onion","limited":true,"reachable":false,"proxy":"","proxy_randomize_credentials":false}],"relayfee":0.00100000,"localaddresses":[],"warnings":""},"error":null,"id":"verscheck"}

the Content-length is a garbage non-numeric value (ie: 'zu'), which curl trips over if i dont use the --ignore-content-length option

makes me think whatever library function is used to write the Http length header is being given a NULL rather than a real string.

the getnetworkinfo does seem to be returned, but i'd rather not use the --ignore-content-length option and wait for timeouts.

seems needlessly obtuse to have two layers of different versioning.

oh well, getinfo should report the subversion or better still getnetworkinfo should be implemented.

what (and where) is the correct current wallet?
i've been running 42-v0.0.9-bdb-mingw for a while, but notice all my peer connections
are version 0.7.6.9 or 0.7.7.1
and i have no peers at all for 0.0.9

are the download links at netcoin.io going to be updated?

the new theme looks like fingerpainting and takes up too much screen real estate. is it really necessary
not to allow the window to be resized any smaller or use such giant fonts when there is no obvious way to
user-control the font size.

well the crypto-bridge setup app under windows7/64 fails, and doing a google search for the word 'digital crypto exchange" yields all kinds of abundant results, none of them appearing to call themselves 'Digital'

if been visible on an incoming accessible default port for nearly 3 years 24/7. and yes i've restarted the linux daemon. and no i dont expect/demand people to do the addnode, i was merely suggesting if the network was getting frail in any way they are welcome to do so. i still have a couple connections so its not like the daemon has failed in some odd way.
and of course why dont i have more outgoing connections too? why dont other people open up their ports for a change?

eeesh, such agresive response to a simple observation/request. perhaps i'll dump my trivial holdings and move on. the wallet demands too much cpu anyway. hopefully i can get $10 for 360k coins.

i match the explorer at cap.altcoinwarz.com

it says a lot about how unusable crypto coin tech is if the first assumption for a problem is the wallet going off chain.
this will never endear itself to the greater public.

but i'm down from 18 to 1 connection lately.
where is everybody?
please addnode=coins.dognose.net

compare a fresh complete checkout of your own github with your saved VM.
looking at the 3 files i changed probably wont find all the differences.

presumably the saved VM was 'working' code base
make your github match exactly what you sucessfully build.

[putting on grumpy old man retired compiler developer hat]

okay, i'll try to explain the source code situation (that deserves one or more litecoin developers to be slapped.)

first, a lesson on C/C++ coding and the language sourcefile preprocessor.

you can have included/header files of various definitions, they are referenced in source
by one of two syntaxes:
  #include <filename>
or
  #include "filename"

they basically do the same thing. but don't. they find the referenced filename by a set of "search rules"
on which system and local project folders to look for them and in what order.
some locations are built into the preprocessor command as defaults for the language standard include
files. other locations may be supplied on the compile time invocation of C/C++ (and buried in a maze
of bulky text in the Makefile structure for these larger projects.)

the thing is, the defaults for order of search folders is slightly different between the <f> and "f" syntax.

for general sanity, one should use the <f> syntax for external packages and system/compiler supplied stuff, and the "f" syntax for the current project's code.

lesson over, now what happened:

some litecoin 'coder' foolishly decided it was okay to have multiple files in the same code project have the same filename. they just were in slightly different subfolders.
a couple of these files were the include files referenced by #include directives.

the source files needing them found them by using the <f> syntax of #include -- which is not so much wrong and just avoided by people who know the potential pain.
the local project should be using the "f" syntax for referencing its own local header files.

now it appears that number435398 'fixed' these OCD aggravating #include references to use double quotes instead of the angle brackets.
but that resulted in the *other* (wrong) version of the same file name being found and used -- which led to compile time syntax errors.

specifically, file rpc/util.h and wallet/init.h clashed with files of the same name in the higher level source folder.

just to make things work, i edited the #include directives to say "../util.h" instead of "util.h" and likewise for init.h

the correct solution would be to rename the following files
  rpc/util.cpp  --> rpc/rpcutil.cpp
  rpc/util.h     --> rpc/rpcutil.h
  wallet/init.cpp --> wallet/walletinit.cpp
  wallet/init.h  --> wallet/walletinit.h

and of course edit any references to them along with cleaning up any #include <f> directives which really should be #include "f" format.

curiously, only files near/needing these two same named header files seem to have used the offputting version of the #include syntax -- almost as if the litecoin developer felt forced to do so to "make the stuff work." obviously someone not quite understanding how #include search rules work -- and the coding traditions that exist to avoid such issues.

the referencing files that would fail to build were rpc/server.cpp , rpc/protocol.cpp, and wallet/rpcwallet.cpp

other files may erroneously have references to util.h and init.h but dont actually need/use the data they contain and so did not create build/compile time errors. i havent taken the time to go hunting for them.

i'm inclined to suspect the coder who originated this mess simply lacked experience (and possibly not doing much more than a copy/paste from some other codebase such as bitcoin.)
i am more worried about the sod who accepted the code into the official git repository for litecoin. either they didnt know better (bad), or just too lazy to actually look at what was being checked-in (very bad.)
perhaps they had faith in the coder who supplied the changes.
this to me has long term security implications. faith and/or laziness will eventually lead to disaster in financial software.

oh, and because those files could not build is why i do not believe the published noodly github source matches the published binaries (kinda trust breaking.)

i strongly suspect the source on github is not *precisely* the source use to build the binaries.
i had to make a minor edit to #include directives in three source files to get a clean build.

i'm also thinking there are brain-dead litecoin developers who set up a source boobytrap.

but i have it built and it appears to be functioning.

the configure step is suppose to catch missing dependencies.

i built the current dogecoin (based on recent litecoin) in the fall without problem, so i suspect dependencies arent really the problem.
unless an obscure one has been introduced into the code base.

oh, and no apt-get on Slackware linux it has its own package manager...