-Wallet no longer supports in-wallet Mining
-Wallet no longer supports "Stratum" mining
deal breaker. the only two ways i mine. especially in-wallet cpu mining because any ASIC will overwhelm the current network size. and dont give me that "avoiding false-postiives from antivirus software" bullpucky. altcoins have been surving that issue for years now. THAT problems likes with the antivirus vendors and people should not raise their asses up to accomodate AV lazy heuristics. |
|
|
|
Thanks for the links, i've plenty of memory on my system. The wallet is syncing really slow, I'm currently 4y 242d 17h 57m, it could take 5 mins or more just to move a few blocks.
I'v added the addnodes from the link you posted, however when trying to download the bootstrap it comes with a 'Network Error' or 'File corrupted'
do you have any suggestions on why that would keep happening?
Thanks
wallet v2.0.1.0 ? (previous were really slow syncing) the current wallet is a giant memory hog and takes a long time to start up, but actually synching, once started up, seems about the same as any other coin. on my own system, i get much slowness when i have multiple wallets beating on the same hard-drive. hard-drive is a real bottleneck when more than one program is doing it at the same time. likewise with network bandwidth, if several coins are attempting to download at the same time (while you are web browsing and streaming music) you will find things are very slow too. set the hobonickels task priority to high should help a bit too. |
|
|
|
cryptopia is definitely gone to shits. for the 5th time in a row in the last couple months deposits i send for CAP fail to show up. support eventually after a week or two will credit me, but that sure destroys any concept of market timeliness  |
|
|
|
i have an iquidus block explorer for Chicago's newnet here: http://coins.dognose.net:3010/i'm still running old code (with my own client patch) on the standard port at coins.dognose.net and running Chicago's newnet code for the last couple days on a non-standard port. i would've thought peer discovery would have more connections to that by now, still only have the one specifically configured chicago node... |
|
|
|
is whoever running the following aware of the conversation here to hardfork to a new network number (pch) ??
ndl@carpdiem:~$ bin/rc.ndl cmd getpeerinfo|grep addr|grep pools
"addr" : "188.99.44.158:60623", (dslb-188-099-044-158.188.099.pools.vodafone-ip.de)
"addr" : "188.99.44.158:49572", (dslb-188-099-044-158.188.099.pools.vodafone-ip.de)
"addr" : "188.99.44.158:50469", (dslb-188-099-044-158.188.099.pools.vodafone-ip.de)
"addr" : "188.99.44.158:56194", (dslb-188-099-044-158.188.099.pools.vodafone-ip.de)
|
|
|
|
0.14.4 fails on startup with a dialog box saying "unable to start http server" or something similar.
Can you please provide your machine type, operating system details, etc. In the meantime, you might also try rebooting your machine. windows 7/64bit, amd quad core i reboot every evening after i get home from work, when i have time on the weekend i'll give 0.14.4 another attempt. i doubt reboots will solve it however, since the older code works fine. |
|
|
|
i'll try again next weekend with a fresh download.
Hi dnp, Sounds good, let me know if there is anything I can help with to make things easier. Eventually, when nodes are seeded on the new peer swarm, I'll add some updates into src/net.cpp and we can discuss who wants to run the DNS Seeder code. Once src/net.cpp has a few hard-coded addresses in the pnSeed array and after there is a working DNS Seed, then the chain should march on until there is some future upgrade. Best Regards, -Chicago i just recompiled the un-modded source i downloaded oct.16 and get the same error at the same line number. it had the new pch value so i assumed i found the correct source. so, what source location should i download? also, could -txindex be a potential issue? its needed to support iquidus block explorer. or maybe i somehow corrupted my block files, although a -reindex didnt fix it. oh well, next weekend it is. 60 hour work weeks suck. |
|
|
|
Notably, the src/main.cpp line cited in your assertion error does not match up here. Your code suggests SetBestChain is defined starting in line 1802 while in the code I've shared it is declared in line 1784.
i do mod the source before compiling, however i do not put mods into main.cpp i probably fumbled something although it did run fine as compiled for a couple days. i'll try again next weekend with a fresh download. |
|
|
|
so, playing with Chicago's modified ndl when i (re)start the daemon today i get testcoins@carpdiem:~$ rc.ndl2 start
nice --adjustment=2 /usr/local/bin/noodly2d-0862 -port=24021 -rpcport=12022 -txindex
testcoins@carpdiem:~$ Noodlyappendagecoin server starting
noodly2d-0862: main.cpp:1802: bool SetBestChain(CValidationState&, CBlockIndex*): Assertion `pfork != NULL' failed.
2018-10-20 17:49:08 Noodlyappendagecoin version v0.8.6.21-unk-dnp (Oct 20 2018, 13:17:03)
2018-10-20 17:49:08 Using OpenSSL version OpenSSL 1.0.2p 14 Aug 2018
2018-10-20 17:49:08 Default data directory /home/testcoins/.noodlyappendagecoin
2018-10-20 17:49:08 Using data directory /home/testcoins/.noodlyappendagecoin
2018-10-20 17:49:08 Using at most 20 connections (1024 file descriptors available)
2018-10-20 17:49:08 Using 8 threads for script verification
2018-10-20 17:49:08 init message: Verifying wallet...
2018-10-20 17:49:08 dbenv.open LogDir=/home/testcoins/.noodlyappendagecoin/database ErrorFile=/home/testcoins/.noodlyappendagecoin/db.log
2018-10-20 17:49:08 Bound to [::]:24021
2018-10-20 17:49:08 Bound to 0.0.0.0:24021
2018-10-20 17:49:08 init message: Loading block index...
2018-10-20 17:49:08 Opening LevelDB in /home/testcoins/.noodlyappendagecoin/blocks/index
2018-10-20 17:49:09 Opened LevelDB successfully
2018-10-20 17:49:09 Opening LevelDB in /home/testcoins/.noodlyappendagecoin/chainstate
2018-10-20 17:49:09 Opened LevelDB successfully
2018-10-20 17:49:21 LoadBlockIndexDB(): last block file = 2
2018-10-20 17:49:21 LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=375533, size=84622739, heights=939774...1315306, time=2017-05-26...2018-10-20)
2018-10-20 17:49:21 LoadBlockIndexDB(): transaction index enabled
2018-10-20 17:49:21 LoadBlockIndexDB(): hashBestChain=4f108d0f34539f50645e193d211a5e63f2fd5ce3eee88f3fee926fd22678c528 height=1315306 date=2018-10-20 17:45:15
2018-10-20 17:49:21 init message: Verifying blocks...
2018-10-20 17:49:21 Verifying last 288 blocks at level 3
2018-10-20 17:49:21 No coin database inconsistencies in last 289 blocks (289 transactions)
2018-10-20 17:49:21 block index 12854ms
2018-10-20 17:49:21 init message: Loading wallet...
2018-10-20 17:49:21 nFileVersion = 80621
2018-10-20 17:49:22 wallet 230ms
it's a fresh wallet.dat too, it ran okay earlier in the day and was all caught up with the one node at that time. i'm also a bit unclear, it this simply a 'test' network or a serious attempt at hardforking everyone over to the new pch value? |
|
|
|
Goldcoin Core v0.14.4 has been released which includes a very important security fix for a DoS vulnerability! If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows). Download links: https://www.goldcoin.org/downloads.htmlAll users are advised to upgrade as soon as possible. Submit any issues you encounter here and one of the Goldcoin developers will assist you. 0.14.4 fails on startup with a dialog box saying "unable to start http server" or something similar.
2018-10-20 01:00:40 Goldcoin version v0.14.4.0-8eb798e
2018-10-20 01:00:40 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2018-10-20 01:00:41 GUI: libpng warning: iCCP: known incorrect sRGB profile
2018-10-20 01:00:41 Validating signatures for all blocks.
2018-10-20 01:00:41 GUI: "registerShutdownBlockReason: Successfully registered: GoldCoin Core didn't yet exit safely..."
2018-10-20 01:00:41 Default data directory C:\Users\ken\AppData\Roaming\GoldCoin (GLD)
2018-10-20 01:00:41 Using data directory C:\Users\ken\AppData\Roaming\GoldCoin_GLD_
2018-10-20 01:00:41 Using config file C:\Users\ken\AppData\Roaming\GoldCoin_GLD_\goldcoin.conf
2018-10-20 01:00:41 Using at most 15 automatic connections (2048 file descriptors available)
2018-10-20 01:00:41 Using 32 MiB out of 32 requested for signature cache, able to store 1048576 elements
2018-10-20 01:00:41 Using 4 threads for script verification
2018-10-20 01:00:41 scheduler thread start
2018-10-20 01:00:43 libevent: getaddrinfo: no address associated with nodename
2018-10-20 01:00:43 Binding RPC on address :: port 8122 failed.
2018-10-20 01:00:43 Binding RPC on address 0.0.0.0 port 8122 failed.
2018-10-20 01:00:43 Unable to bind any endpoint for RPC server
2018-10-20 01:00:52 scheduler thread interrupt
2018-10-20 01:00:52 Shutdown: In progress...
2018-10-20 01:00:52 Shutdown: done
2018-10-20 01:02:12
reverting back to 0.14.3 works fine.
2018-10-20 01:04:29 Goldcoin version v0.14.3.0-7a76ae6
2018-10-20 01:04:29 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2018-10-20 01:04:29 GUI: libpng warning: iCCP: known incorrect sRGB profile
2018-10-20 01:04:29 Validating signatures for all blocks.
2018-10-20 01:04:29 GUI: "registerShutdownBlockReason: Successfully registered: GoldCoin Core didn't yet exit safely..."
2018-10-20 01:04:29 Default data directory C:\Users\ken\AppData\Roaming\GoldCoin (GLD)
2018-10-20 01:04:29 Using data directory C:\Users\ken\AppData\Roaming\GoldCoin_GLD_
2018-10-20 01:04:29 Using config file C:\Users\ken\AppData\Roaming\GoldCoin_GLD_\goldcoin.conf
2018-10-20 01:04:29 Using at most 15 automatic connections (2048 file descriptors available)
2018-10-20 01:04:29 Using 32 MiB out of 32 requested for signature cache, able to store 1048576 elements
2018-10-20 01:04:29 Using 4 threads for script verification
2018-10-20 01:04:29 scheduler thread start
2018-10-20 01:04:32 libevent: getaddrinfo: no address associated with nodename
2018-10-20 01:04:32 Binding RPC on address :: port 8122 failed.
2018-10-20 01:04:32 HTTP: creating work queue of depth 16
2018-10-20 01:04:32 Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcuser for rpcauth auth generation.
2018-10-20 01:04:32 HTTP: starting 4 worker threads
2018-10-20 01:04:32 Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
2018-10-20 01:04:32 Using wallet wallet.dat
2018-10-20 01:04:32 init message: Verifying wallet...
2018-10-20 01:04:32 CDBEnv::Open: LogDir=C:\Users\ken\AppData\Roaming\GoldCoin_GLD_\database ErrorFile=C:\Users\ken\AppData\Roaming\GoldCoin_GLD_\db.log
2018-10-20 01:04:32 Bound to [::]:8121
2018-10-20 01:04:32 Bound to 0.0.0.0:8121
2018-10-20 01:04:32 Cache configuration:
2018-10-20 01:04:32 * Using 2.0MiB for block index database
2018-10-20 01:04:32 * Using 8.0MiB for chain state database
2018-10-20 01:04:32 * Using 440.0MiB for in-memory UTXO set (plus up to 4.8MiB of unused mempool space)
2018-10-20 01:04:32 init message: Loading block index...
|
|
|
|
omg, and I thought ... not to mention.  We are not stable, as we are writing. ... I am sure this has to be solved. the day weed becomes legal in this country the internet goes to pot |
|
|
|
TekSavvy Assistance
@TekSavvyCSR
Many customers on the Cable network around Ontario may be experiencing a issue with the service.
This is impacting all customers that are using Third Party Internet Access providers on
the Rogers infrastructure. We will update all customers when we know more information. -BP
-Dave it's a very good inside view of Rogers Cable network support |
|
|
|
dnp's coins.dognose.net server is down.
I hope nothing bad happened.
n.
TekSavvy Assistance
@TekSavvyCSR
Many customers on the Cable network around Ontario may be experiencing a issue with the service.
This is impacting all customers that are using Third Party Internet Access providers on
the Rogers infrastructure. We will update all customers when we know more information. -BP
thankfully i also have lightweight DSL with my fibre television service  i can go out, but nobody gets in. |
|
|
|
Many of your presented adjustments may help with the network but the real way its supposed to be done is through the pchMessage.
btw, whatever future/new value of pch you have chosen, how have you determined it's not already taken by some other altcoin? anyhow, i'd find it amusing if the hex ascii equivalent of NDLY was used  even more amusing if the EBCDIC values of NDLY were used |
|
|
|
looks like litecoin looks for 'bad' subvers, while the code i posted a couple days ago looks for 'good' subvers. pretty much the same idea but from opposite directions the problem with looking for bad ones, is you have to know who they are in advance. those 'seeder' nodes (which i noticed connecting to dognose as well) may be a big clue as to the root source of the plague however. |
|
|
|
I don't think changing the Network ID is a good idea yet.
We don't know who runs the dognose nodes and if they don't upgrade then everything falls apart without a seed.
i be dognose. i wont have real free time until december. maybe possibly late november. i'm too busy to figure what fork i may have wandered down, but this is my current state of the daemon. i do not have any of those nasty altcoin connections since i'm running that code i posted a couple days ago. {
"version" : "v0.8.6.50-unk-dnp",
"protocolversion" : 70002,
"walletversion" : 60000,
"client" : "/Noodly-dnp:0.8.6.50/",
"berkeleydb_version" : "Berkeley DB 4.8.30: (April 9, 2010)",
"openssl_version" : "OpenSSL 1.0.2p 14 Aug 2018",
"boost_version" : "1_59",
"compiler_version" : "5.5.0 (5.5.0)",
"build_date" : "2018-10-13 22:49:01 -0400",
"balance" : 1205499.87000000,
"al_dente" : 0.00000000,
"immature" : 30000.00000000,
"blocks" : 1313963,
"lastblock_time" : 1539574422, (Oct 14 23:33:42 2018 -0400)
"timeoffset" : -1,
"connections" : 6,
"proxy" : "",
"ip_address" : "23.233.2.252",
"port" : 40021,
"rpc_port" : 40022,
"difficulty" : 0.00054808,
"next_block" : {
"height_next" : 1313964,
"difficulty_next" : 0.00054808
},
"testnet" : false,
"keypoololdest" : 1539525759, (Oct 14 10:02:39 2018 -0400)
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"mininput" : 0.00001000,
"generate" : true,
"threads/cores" : 2,
"errors" : "URGENT: Alert key compromised, upgrade required"
}
[
{
"addr" : "74.113.33.65:40021",
"services" : "00000003",
"lastsend" : 1539574585, (Oct 14 23:36:25 2018 -0400)
"lastrecv" : 1539574492, (Oct 14 23:34:52 2018 -0400)
"bytessent" : 992049,
"bytesrecv" : 672331,
"blocksrequested" : 682,
"conntime" : 1539485439, (Oct 13 22:50:39 2018 -0400)
"version" : 70002,
"subver" : "/Satoshi:0.8.6.1/",
"inbound" : false,
"startingheight" : 1312487,
"banscore" : 0,
"syncnode" : true
},
{
"addr" : "188.99.44.158:54782", (dslb-188-099-044-158.188.099.pools.vodafone-ip.de)
"services" : "00000003",
"lastsend" : 1539574514, (Oct 14 23:35:14 2018 -0400)
"lastrecv" : 1539574400, (Oct 14 23:33:20 2018 -0400)
"bytessent" : 817679,
"bytesrecv" : 496281,
"blocksrequested" : 1145,
"conntime" : 1539489038, (Oct 13 23:50:38 2018 -0400)
"version" : 70002,
"subver" : "/Satoshi:0.8.6.1/",
"inbound" : true,
"startingheight" : 1312486,
"banscore" : 0
},
{
"addr" : "188.99.44.158:58773", (dslb-188-099-044-158.188.099.pools.vodafone-ip.de)
"services" : "00000003",
"lastsend" : 1539574493, (Oct 14 23:34:53 2018 -0400)
"lastrecv" : 1539574513, (Oct 14 23:35:13 2018 -0400)
"bytessent" : 1103190,
"bytesrecv" : 243716,
"blocksrequested" : 1697,
"conntime" : 1539502578, (Oct 14 03:36:18 2018 -0400)
"version" : 70002,
"subver" : "/Satoshi:0.8.6.1/",
"inbound" : true,
"startingheight" : 1312265,
"banscore" : 0
},
{
"addr" : "188.99.44.158:52593", (dslb-188-099-044-158.188.099.pools.vodafone-ip.de)
"services" : "00000003",
"lastsend" : 1539574399, (Oct 14 23:33:19 2018 -0400)
"lastrecv" : 1539574585, (Oct 14 23:36:25 2018 -0400)
"bytessent" : 731746,
"bytesrecv" : 339180,
"blocksrequested" : 584,
"conntime" : 1539503274, (Oct 14 03:47:54 2018 -0400)
"version" : 70002,
"subver" : "/Satoshi:0.8.6.1/",
"inbound" : true,
"startingheight" : 1312789,
"banscore" : 0
},
{
"addr" : "188.99.44.158:55015", (dslb-188-099-044-158.188.099.pools.vodafone-ip.de)
"services" : "00000003",
"lastsend" : 1539574586, (Oct 14 23:36:26 2018 -0400)
"lastrecv" : 1539574399, (Oct 14 23:33:19 2018 -0400)
"bytessent" : 261746,
"bytesrecv" : 199291,
"blocksrequested" : 513,
"conntime" : 1539525882, (Oct 14 10:04:42 2018 -0400)
"version" : 70002,
"subver" : "/Satoshi:0.8.6.1/",
"inbound" : true,
"startingheight" : 1313157,
"banscore" : 0
},
{
"addr" : "76.16.12.81:43892", (c-76-16-12-81.hsd1.in.comcast.net)
"services" : "00000003",
"lastsend" : 1539574601, (Oct 14 23:36:41 2018 -0400)
"lastrecv" : 1539574602, (Oct 14 23:36:42 2018 -0400)
"bytessent" : 147416906,
"bytesrecv" : 39445802,
"blocksrequested" : 353502,
"conntime" : 1539570369, (Oct 14 22:26:09 2018 -0400)
"version" : 70002,
"subver" : "/Satoshi:0.8.6.1/",
"inbound" : true,
"startingheight" : 0,
"banscore" : 0
}
]
5 inbound 1 outbound = 6 total connections
|
|
|
|
UPDATE:
I seem to have made a new working version of the wallet! I need to dot a few "i"'s and cross a few "t"'s and then I'll upload and release it in the next few days. It seems to have no problem with old wallet.dat files, though it doesn't import current paper wallets of NDL for some reason. May have to update the paperwallet code. This new version will distinguish us on the network and not even bother with nodes that don't conform to the new pchMessage code I've implemented. So it will mean everyone will have to update to the new wallet. Plus it'll include an upgrade to all the BIPs we need to be traded and, I think, even be setup for SegWit to go live in a couple of weeks.
this is called a hard fork, perhaps first a release without the pchVersion change to test everything else in your wallet first? also, when done, the hardfork/pchVersion change should occur at some future block number or date to give time for people to install the new wallet. hardforks should have a bit of community consensus... have you established a testnet? |
|
|
|
All the same height likely means that its all litecoin wallets. Or maybe someone made their own wallet and didn't know what they were doing and named it differently, but its still a litecoin wallet.
I've got a new idea I'm going to try to apply this weekend to the new version of the wallet I'm trying to make. If I'm successful I would really like to give it a new pchMessage setting so as to immediately reject all those other nodes.
besides LitecoinCore versions, i've seen multiple instances (different ip#) of bitcore:1.1.0
btcseeder:0.0001
litecoinseeder:0.01
unitedbitcoinseeder:1.01
crawler.gamecredits.com:0.1
BitNodes.net:4.0.2
Satoshi:0.13.2
litetroll.net:1.0
CypherfunkCore:0.15.2
DigitalcoinV3.0:3.0.1
FeathercoinCore:0.16.3
FlashcoinCore:0.13.3
FlashcoinCore:0.15.1
I2CcoinCore:0.14.2
Satoshi:0.13.2UASFSegWithBIP148
DevCoinCore:1.0.0
ViaBTC:bitpeer.0.3.0
WorldcoinFoundation:0.8.6.2
all with the same starting height once is happenstance, twice is coincidence, three times is enemy action to quote a bond movie even valid nodes with same wallet generally dont have the same starting height, that's why they connect -- to catch up. |
|
|
|
This is actually a worry of mine. One day the node that the explorer talks to is going to walk away on another chain and not come back.
-Dave
Naw, the other alt coins aren't on the same blockchain. They merely act as a distraction; our wallets see them and consider them, but ultimately our wallets reject them because they don't conform to fundamental NDL chain why are these other alts connecting at all? someone mispublish a port number somewhere? willful attack? i'm thinking willful attack, i just notice that even though they identify as various differnent altcoins they all seem to have the same startingheight All it takes is one person's wallet to connect to one of these other coins, then those wallets tell our wallets about its other wallets etc. The current wallet is programmed to connect to all wallets with the proper pchMessage code. Since, when Noodlyappendagecoin was created, it was programmed with the same pchMessage code as Litecoin (and other alt-coins that weren't modified properly), our wallets see these as valid nodes until they realize that they aren't on the same blockchain (which can take a while). Our wallets may give each node several hours to try to provide proper blockchain info, but during that time our wallets will incorporate all that other wallets' nodes to our list of nodes. In other words, its a mess. still seems like a willful attack using this vulneratbility. it's very odd (suspicious) that all the 'different' altcoins have the same blockchain height (total number of blocks.) |
|
|
|
hmmm ... If all that contributes comes together 1 BTC.
0.1 BTC I could give from my side. What do you think ?
Or should the roadmap be worked through first and then look for a stock exchange ?
never submit to blackmail. cryptopia deserves to choke. |
|
|
|
|
Show Posts
