 Show Posts
|
|
Pages: [1] 2 »
|
I would like to know more details about the scam accusations and what'll be the defense, but it seems dev and the original accusers didn't want to get into this further. Too bad, I've made my popcorn.
Anyway, with the benefit of the doubt, why would green energy resource(s) need to be crypto-ed? It still works completely fine with conventional paper money, isn't it?
Yeah, so the function that I showed above will only allow blocks with coinbase transactions with destination addresses belonging to a predetermined set of 22 addresses. This means that all of the coins mined from now to eternity will belong to the owners of those 22 addresses and anybody mining will be at the mercy of the owners of the addresses. No private pools, no competing pools. This project is running a rate limited pool, which bans miners with too high of a hashrate. These combined factors make it extremely easy for the project to mine a whole bunch of coins whenever they want by either lowing the rate limit on the miners of their pool, setting up their own private pool without the rate limit, shutting off the pool all together and adding some blocks, or just throwing a 50% fee onto the pool. This code does prevents outside 51% attack, but I think there are better ways to do that. I think this code leaves too many loopholes for the project to be able to utilize if it's a scam. |
|
|
|
|
I see the source code was added.
From Main.cpp line 899 to 907
// A coinbase transaction vouts
if (tx.IsCoinBase()) {
BOOST_FOREACH(const CTxOut& out, tx.vout) {
CTxDestination out_dest;
if (nHeight >= Params().GetConsensus().GetFirstEnforcedMinerLicenseBlockHeight() && ExtractDestination(out.scriptPubKey,out_dest) && !Params().IsLicensedMiner(EncodeDestination(out_dest)))
return state.DoS(100, error("CheckTransaction(): coinbase unlicensed miner"),
REJECT_INVALID, "bad-cb-miner");
}
}
Looks like you are only allowing specific addresses to add blocks to the chain.
From chainparams.cpp lines 184 to 207
vLicensedMiners = {
"V1gUNHs9Ae2t6hCA7MkVqghe2GWsJvB8exM",
"V1oUJSYnwUoeowB2CykMBMg9RKRt6uUPoj2",
"V1brKJBb8Q3HxPk3by7o6aNFjTtDhMWtEmX",
"V1iQ8LDi8QS7PJjpDWnyPyaCA93sC1NZL5f",
"V1TgZrkism6Zj7RPh4NoZbbXEdEWLpa6SMp",
"V1fSF2pbMdDCE6tgG1waCG7e71NWSpKcYiX",
"V1e7vjV8esvkdvokVqdwR7Bui3bD9YLZFWT",
"V1RVmTC7mCHFM9iGQ5yZKYEDMynhw3bDFJ2",
"V1gsR99Sd2azGwM5wNarCEFF4SvESL7yxjf",
"V1SXJJn6mhD6CE7W8jXdS4rxc3B9dMkYghK",
"V1R7AFHw6U5btTrxkVkeq2ZMS5KN7HrNj5A",
"V1j957XzHXDRdz9ainnnjrnRqfSf3XBGvL4",
"V1b7wFTbsuQBhGgAF5f5Dt8paPazSsrFTg4",
"V1fgNT2qyA9G8VnEHCtMV1SFsJhWVgAEgoc",
"V1YxmmRWxTKBNSB6Pv235o16ffgWRk9ZqrY",
"V1YuCVe2ufQHUu3NS67bcbixUY9TbfmpNaW",
"V1Y5g3Pm2Wn7QTzytrzFxiydKwdLVV9GXip",
"V1hNZdZVjyUcfXYfu71R2RBjmyN8kZoRE7r",
"V1at7HqpMbffzkxCeGRZk4nrK9rsWtGdo4M",
"V1h7Fc3XxgCYS8CW26oDf5idQiNgCQMcMqm",
"V1bwTWLiwe23K1avvYQzGt7Ffxr1p4KeAih",
"V1Zrkrrh3BDWqnuBfS8Y5tBAse7xM3F1wAS"
};
Beware, this code gives the team behind this complete control over the chain. They can easy shut off their "authorized pool" and continue to add blocks without competition. They can put up a private non-rate limited pool and mine as much as they want. They don't need a premine cause they can mine as much as they want whenever they want.
I'm out, I prefer my decentralized networks to be decentralized.
|
|
|
|
|
Why no source code for the flash blockchain? It obviously a zcash clone, since it's got overwinter and sapling. Also since you're running 192/7 it probably a clone of one of the I think 3 zcash clones that run that algo. However since I see your swing wallet is from the Zero project (I can see it their's right in the source code) I suspect it a clone of their blockchain code as well. So why the secrecy? You could have all kinds of stuff hidden in there. How do we validate the coin supply, halving schedule, founders/dev fees, etc..?
|
|
|
|
What do you mean? You get errors? I'm installing a dedicated web-wallet meanwhile, unfortunatly I've never compiled wallets for Windows platform, only old bitcoin qt sources back in the days. Hopefully someone will come up with a compiled version soon  Another new node: yes i got errors about params.... please it would be helpful for the web wallet thanks based on a review of the code it looks like the Zero nodes prior to 1.0.14-2 will work on zeroclassic because the magicnumbers and default ports have not been changed. The version strings weren't even changed. This means that you can run zero 1.0.14-1 and all of zero's wallets for zeroclassic. As far as i can tell it look like a find replace all kind of port with no changes to actually separate the network. |
|
|
|
|
What are your plans for development?
Is this coin listed on an exchange, if not what are your plans for an exchange?
Is there a development team?
|
|
|
|
this coin is GARBAGE. There are literally DOZENS of better projects than this heap. Guys, the "lead developer" is a cat and they other "devs" are made up. You should never invest in a project with an anonymous team. Who the hell is DIMITRIS MARSELOS anyways? Well, if anyone did even a modicum of research they would know he has a background as a Manager, Passenger Services for a shipping company. How does someone go from that position (which he currently still does) to anything to do with crypto?? The answer is, they don't. This is a SCAM. I tried to warn you before, and am warning you again. It's not too late to get out now!
Cool story bro... If you don't like the coin nobody is forcing you to invest. Feel free to go invest in those dozens of better projects. |
|
|
|
Here is an example from log files
We thought a block was found but it was rejected by the daemon, share data: {"job":"d3a2","ip":"::ffff:x.x.x.x","port":2053,"worker":"t1xxxxxxxxxeL","height":236147,"difficulty":0.2,"shareDiff":"4596.03419805","blockDiff":1351.176112912,"blockDiffActual":1351.176112912,"blockHash":"0000007212f19755fb017650d29e3823cf44a2b5aca1cf90baa36f3152951c0f","error":{"unknown":"check coin daemon logs"}}
ERROR: CheckEquihashSolution(): invalid solution
ERROR: CheckBlockHeader(): Equihash solution invalid
Have you considered that the user might just have used the wrong hash algorithm param when connecting to the pool? If the protocol is different it goes right away as an error on the first submit. I have tested all the pools listed on the first page. They all report shares mined with a wrong algorithm as correct back to the miner: $ ./optiminer-equihash -a equihash200_9 -s zer-eu.forgetop.com:2053 -u <...> -p x
[2018-01-17 01:42:59.055] [default] [info] Optiminer/Equihash 2.1.2 (C) Optiminer 2017
[2018-01-17 01:42:59.055] [default] [info] Connecting to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.149] [default] [info] Using 2 verifier threads.
[2018-01-17 01:42:59.149] [default] [info] Using highly optimized kernel code for Fiji devices.
[2018-01-17 01:42:59.149] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Fiji.bin
[2018-01-17 01:42:59.150] [default] [info] Autodetected '--intensity 5' for device 0.
[2018-01-17 01:42:59.192] [default] [info] Extranonce is '60000043'.
[2018-01-17 01:42:59.233] [default] [info] Mining target is 0050000000000000000000000000000000000000000000000000000000000000
[2018-01-17 01:42:59.234] [default] [info] Got new work.
[2018-01-17 01:42:59.260] [default] [info] [GPU0] Device info: {"id": "0/0" "name": "Fiji" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.314] [default] [info] Connected to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.464] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.464] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.465] [default] [info] Autodetected '--intensity 5' for device 1.
[2018-01-17 01:42:59.570] [default] [info] [GPU1] Device info: {"id": "0/1" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.773] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.773] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.773] [default] [info] Autodetected '--intensity 5' for device 2.
[2018-01-17 01:42:59.879] [default] [info] [GPU2] Device info: {"id": "0/2" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:43:01.015] [default] [info] [GPU2] Share accepted! (1 / 1)
[2018-01-17 01:43:02.549] [default] [info] [GPU0] Share accepted! (2 / 2)
[2018-01-17 01:43:03.061] [default] [info] [GPU2] Share accepted! (3 / 3)
It seems the pools internally filter those incorrect shares which is good. But they should be reported back to the miner as invalid. The pool always get warnings when zcash solution is submited: Share rejected: {"job":"ccd0","ip":"::ffff:x.x.x.x","worker":"xxxxx.xxx","difficulty":0.01,"error":"incorrect size of solution"} And also there is no hashrate. Unfortunately this is not the case with the problem. Not a single warning is presented in the log files. Those ppl have good steady hasrate, everything is OK, just when it comes to finding block it got rejected from zcashd. Just checked, the solution verification has stayed the same in optiminer since version 2.0. You are chasing a red herring here. The problem also does not seem to be new: https://github.com/zerocurrency/zero/issues/6My best guess would be that there is NOMP and zerod validate the block difficulty. OPTI - genuine curiosity has got the better of me, hope you can straighten me out. Monitored all 1.1 traffic over the course of 90 minutes (on a crap - 1sol - GPU). A little confused by the traffic patterns! Miner fires up and connects to Devfee server (88.99.30.25 / Proxy.optiminer.pl / static.25.30.99.88.clients.your-server.de) blah blah blah - expected. But over the course of 90 minutes: Sent packets to forgetop pool = 136 (132978 bytes) Sent packets to you = 5 (1052 bytes) Received packets from forgetop pool = 221 (29891) Received packets from you = 89 (23264) Seems like a fairly large payload for a heartbeat - it is a heartbeat yes? Odd direction considering the client shuts down on port block. No, it is not is it? Firewall shows client sending out heartbeat at a reasonable size of 60, and you respond with a payload of 250-300. Those packets are work – and they account for 35-40%. I can watch the miner state 'Got New Work' and BOOOOOOM - in real time - a tic in received packet count. Sometimes from you, sometimes from Forge. Best be time to lawyer up! So according to your 90 minute, low share test run, the optimizer getwork from dev server is consuming 28% of the download bandwidth (89/(221+ 89)), but only 3.5% (5/ (136+5)) of the upload bandwidth. Wouldn't this suggest that the dev fee is close to what is advertised, since only 3.5% of the data submitted (as in shares) was going to the dev sever? Especially considering your very low sample size. Maybe you should explain it again, I don't see a problem here. Valid points although I think sample size is irrelevant - the client is consistent in its ping to the devfee server, that server is consistent in its reply. And each reply can be visually correlated with a Got New Work line item in the client. Without having access to the underlying src, it is more than plausible to assume that close to 1/3rd of hashing power is being diverted. What is more telling since I blocked all comm with devfee - my chart has flattened out a bit while my avg HR has remained near consistent. This is what needs a bigger sample size - I'll report back in 24. All rigs doing ZER work btw... I I don't see how it is plausible to assume that network download bandwidth correlates to diverted hashrate without corresponding upload bandwidth. All it really shows is that optiminer is downloading the data needed to do POW calculations, not that its actually doing them. If however you can prove that the program is uploading shares at a higher than expected rate then you have some evidence. When you blocked comm traffic with the dev server did your hashrate change at all, increase by 33%? |
|
|
|
Here is an example from log files
We thought a block was found but it was rejected by the daemon, share data: {"job":"d3a2","ip":"::ffff:x.x.x.x","port":2053,"worker":"t1xxxxxxxxxeL","height":236147,"difficulty":0.2,"shareDiff":"4596.03419805","blockDiff":1351.176112912,"blockDiffActual":1351.176112912,"blockHash":"0000007212f19755fb017650d29e3823cf44a2b5aca1cf90baa36f3152951c0f","error":{"unknown":"check coin daemon logs"}}
ERROR: CheckEquihashSolution(): invalid solution
ERROR: CheckBlockHeader(): Equihash solution invalid
Have you considered that the user might just have used the wrong hash algorithm param when connecting to the pool? If the protocol is different it goes right away as an error on the first submit. I have tested all the pools listed on the first page. They all report shares mined with a wrong algorithm as correct back to the miner: $ ./optiminer-equihash -a equihash200_9 -s zer-eu.forgetop.com:2053 -u <...> -p x
[2018-01-17 01:42:59.055] [default] [info] Optiminer/Equihash 2.1.2 (C) Optiminer 2017
[2018-01-17 01:42:59.055] [default] [info] Connecting to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.149] [default] [info] Using 2 verifier threads.
[2018-01-17 01:42:59.149] [default] [info] Using highly optimized kernel code for Fiji devices.
[2018-01-17 01:42:59.149] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Fiji.bin
[2018-01-17 01:42:59.150] [default] [info] Autodetected '--intensity 5' for device 0.
[2018-01-17 01:42:59.192] [default] [info] Extranonce is '60000043'.
[2018-01-17 01:42:59.233] [default] [info] Mining target is 0050000000000000000000000000000000000000000000000000000000000000
[2018-01-17 01:42:59.234] [default] [info] Got new work.
[2018-01-17 01:42:59.260] [default] [info] [GPU0] Device info: {"id": "0/0" "name": "Fiji" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.314] [default] [info] Connected to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.464] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.464] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.465] [default] [info] Autodetected '--intensity 5' for device 1.
[2018-01-17 01:42:59.570] [default] [info] [GPU1] Device info: {"id": "0/1" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.773] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.773] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.773] [default] [info] Autodetected '--intensity 5' for device 2.
[2018-01-17 01:42:59.879] [default] [info] [GPU2] Device info: {"id": "0/2" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:43:01.015] [default] [info] [GPU2] Share accepted! (1 / 1)
[2018-01-17 01:43:02.549] [default] [info] [GPU0] Share accepted! (2 / 2)
[2018-01-17 01:43:03.061] [default] [info] [GPU2] Share accepted! (3 / 3)
It seems the pools internally filter those incorrect shares which is good. But they should be reported back to the miner as invalid. The pool always get warnings when zcash solution is submited: Share rejected: {"job":"ccd0","ip":"::ffff:x.x.x.x","worker":"xxxxx.xxx","difficulty":0.01,"error":"incorrect size of solution"} And also there is no hashrate. Unfortunately this is not the case with the problem. Not a single warning is presented in the log files. Those ppl have good steady hasrate, everything is OK, just when it comes to finding block it got rejected from zcashd. Just checked, the solution verification has stayed the same in optiminer since version 2.0. You are chasing a red herring here. The problem also does not seem to be new: https://github.com/zerocurrency/zero/issues/6My best guess would be that there is NOMP and zerod validate the block difficulty. OPTI - genuine curiosity has got the better of me, hope you can straighten me out. Monitored all 1.1 traffic over the course of 90 minutes (on a crap - 1sol - GPU). A little confused by the traffic patterns! Miner fires up and connects to Devfee server (88.99.30.25 / Proxy.optiminer.pl / static.25.30.99.88.clients.your-server.de) blah blah blah - expected. But over the course of 90 minutes: Sent packets to forgetop pool = 136 (132978 bytes) Sent packets to you = 5 (1052 bytes) Received packets from forgetop pool = 221 (29891) Received packets from you = 89 (23264) Seems like a fairly large payload for a heartbeat - it is a heartbeat yes? Odd direction considering the client shuts down on port block. No, it is not is it? Firewall shows client sending out heartbeat at a reasonable size of 60, and you respond with a payload of 250-300. Those packets are work – and they account for 35-40%. I can watch the miner state 'Got New Work' and BOOOOOOM - in real time - a tic in received packet count. Sometimes from you, sometimes from Forge. Best be time to lawyer up! So according to your 90 minute, low share test run, the optimizer getwork from dev server is consuming 28% of the download bandwidth (89/(221+ 89)), but only 3.5% (5/ (136+5)) of the upload bandwidth. Wouldn't this suggest that the dev fee is close to what is advertised, since only 3.5% of the data submitted (as in shares) was going to the dev sever? Especially considering your very low sample size. Maybe you should explain it again, I don't see a problem here. |
|
|
|
Can I ask you something? I would like you to tell me what you honestly think, since you have quite some experience. Users mining on suprnova report that they get rewarded according to whattomine predictions. So, according to whattomine right now, a 100S/s hashrate rewards a miner with 10.5 coins per day. This means that a 65,000 hashrate would give 3505 coins per day. 65,000 S/s is suprnova's total hashrate. 3505 coins equal 350 blocks. Suprnova (as yourself also noticed) mined 620 blocks in 24h. This is a difference of 270 blocks in 24h. Question: If WTM is correct and miners report they get whatever WTM predicts, then where do these 270 blocks=2700 zer per day go? If WTM is incorrect and suprnova indeed mines 620 blocks, how can miners report that they get what WTM predicts? Am I wrong somewhere? I could. I am asking everybody to verify my calculations and to give feedback. I think your math has an error. If 100 Sols/s = 10.5 zer/day then 65,000 Sols/s would be 6,825 zer/day or 682.5 blocks. 62.5 more than suprnova mined, but only 9% off from the prediction. This math assumes that the nethash is 75,600 Sols/s. I've noticed the nethash vary bewteen 71Ksols/s to 109Ksol/s which is over 50% swing so a 9% variance in predictive income isn't all that bad in my opinion. On the matter of other pools, I think it is unhealthy for the network as a whole to be so heavy into one pool but even our second largest pool seems to have reliability issues that suprnova does not. I mined to suprnova for months and in all the time i've mined to it, it was only down once for a few hours. I started mining to forgetop when it came online, but I've lost count how many times it has gone down and have decided to go back to suprnova for a while. Hopefully when the community pool comes online it will prove more reliable. |
|
|
|
Can I ask you something? I would like you to tell me what you honestly think, since you have quite some experience. Users mining on suprnova report that they get rewarded according to whattomine predictions. So, according to whattomine right now, a 100S/s hashrate rewards a miner with 10.5 coins per day. This means that a 65,000 hashrate would give 3505 coins per day. 65,000 S/s is suprnova's total hashrate. 3505 coins equal 350 blocks. Suprnova (as yourself also noticed) mined 620 blocks in 24h. This is a difference of 270 blocks in 24h. Question: If WTM is correct and miners report they get whatever WTM predicts, then where do these 270 blocks=2700 zer per day go? If WTM is incorrect and suprnova indeed mines 620 blocks, how can miners report that they get what WTM predicts? Am I wrong somewhere? I could. I am asking everybody to verify my calculations and to give feedback. I think your math has an error. If 100 Sols/s = 10.5 zer/day then 65,000 Sols/s would be 6,825 zer/day or 682.5 blocks. 62.5 more than suprnova mined, but only 9% off from the prediction. |
|
|
|
I used the chain file with GITHUB. Installed new wallet HEXX. When indexing chain stops on the block 114399. Repeated restarts of the wallet does not help. Tried on three different computers. 2018-01-15 19:11:32 Hexxcoin version v3.0.1.1PATCH1.0 (Jan 11 2018, 03:30:17)
2018-01-15 19:11:32 Using OpenSSL version OpenSSL 1.0.2k 26 Jan 2017
2018-01-15 19:11:32 Default data directory C:\Users\VIP\AppData\Roaming\hexx
2018-01-15 19:11:32 Using data directory C:\Users\VIP\AppData\Roaming\hexx
2018-01-15 19:11:32 Using at most 125 connections (2048 file descriptors available)
2018-01-15 19:11:32 Using 4 threads for script verification
2018-01-15 19:11:32 init message: Verifying wallet...
2018-01-15 19:11:32 dbenv.open LogDir=C:\Users\VIP\AppData\Roaming\hexx\database ErrorFile=C:\Users\VIP\AppData\Roaming\hexx\db.log
2018-01-15 19:11:32 Bound to [::]:29100
2018-01-15 19:11:32 Bound to 0.0.0.0:29100
2018-01-15 19:11:32 init message: Loading block index...
2018-01-15 19:11:32 Opening LevelDB in C:\Users\VIP\AppData\Roaming\hexx\blocks\index
2018-01-15 19:11:32 Opened LevelDB successfully
2018-01-15 19:11:32 Opening LevelDB in C:\Users\VIP\AppData\Roaming\hexx\chainstate
2018-01-15 19:11:32 Opened LevelDB successfully
2018-01-15 19:11:34 LoadBlockIndexDB(): last block file = 0
2018-01-15 19:11:34 LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=121290, size=52253502, heights=0...114399, time=2017-01-30...2017-08-24)
2018-01-15 19:11:34 LoadBlockIndexDB(): transaction index disabled
2018-01-15 19:11:34 LoadBlockIndexDB(): hashBestChain=7b37432e6593671c99bed622a9a651ce25e18c1722249be5206e009dd981d71f height=114399 date=2017-08-24 16:03:02
2018-01-15 19:11:34 init message: Verifying blocks...
2018-01-15 19:11:34 Verifying last 288 blocks at level 3
2018-01-15 19:11:44 No coin database inconsistencies in last 289 blocks (313 transactions)
2018-01-15 19:11:44 block index 11530ms
2018-01-15 19:11:44 init message: Loading wallet...
2018-01-15 19:11:44 PROCESS BLOCK = 114399
2018-01-15 19:11:44 nFileVersion = 3000101
2018-01-15 19:11:44 wallet 271ms
2018-01-15 19:11:44 init message: Loading addresses...
2018-01-15 19:11:44 Loaded 1 addresses from peers.dat 0ms
2018-01-15 19:11:45 mapBlockIndex.size() = 121290
2018-01-15 19:11:45 nBestHeight = 114399
2018-01-15 19:11:45 setKeyPool.size() = 100
2018-01-15 19:11:45 mapWallet.size() = 0
2018-01-15 19:11:45 mapAddressBook.size() = 1
2018-01-15 19:11:45 dnsseed thread start
2018-01-15 19:11:45 upnp thread start
2018-01-15 19:11:45 opencon thread start
2018-01-15 19:11:45 addcon thread start
2018-01-15 19:11:45 dumpaddr thread start
2018-01-15 19:11:45 net thread start
2018-01-15 19:11:45 Loading addresses from DNS seeds (could take a while)
2018-01-15 19:11:45 init message: Done loading
2018-01-15 19:11:45 msghand thread start
2018-01-15 19:11:45 1 addresses found from DNS seeds
2018-01-15 19:11:45 dnsseed thread exit
2018-01-15 19:11:45 refreshWallet
2018-01-15 19:11:49 GetMyExternalIP() received [***.***.0.228] ***.***.0.228:0
2018-01-15 19:11:49 GetMyExternalIP() returned ***.***.0.228
2018-01-15 19:11:49 AddLocal(***.***.0.228:29100,4)
2018-01-15 19:11:53 No valid UPnP IGDs found
2018-01-15 19:11:53 upnp thread exit
2018-01-15 19:14:50 keypool added key 102, size=101
2018-01-15 19:14:50 keypool reserve 2
2018-01-15 19:14:50 keypool return 2
2018-01-15 19:14:52 Flushing wallet.dat
2018-01-15 19:14:52 Flushed wallet.dat 13ms Are you connected to the network? Try adding these nodes. I had no problem downloading the bloackchain, the whole thing, thru the wallet. addnode=109.174.125.199 addnode=109.251.151.248 addnode=161.53.40.94 addnode=178.47.141.198 addnode=179.222.104.159 addnode=185.230.125.44 addnode=188.238.7.190 addnode=195.151.244.217 addnode=195.9.243.122 addnode=42.115.19.91 addnode=47.148.175.217 addnode=78.137.5.155 addnode=79.246.245.94 addnode=82.151.123.134 addnode=91.83.142.84 I got them from here. https://chainz.cryptoid.info/hxx/#!network |
|
|
|
Do someone know how to mine this with i7 CPU ? i am looking for a miner if already configured for this coin or send me command how to run it ?
Thanks in advance.
Zero mining is possible ONLY with GPU, sorry. Technically there is an open source CPU miner available, but the hashrate is basically zero. I tried is once back when the nethash was hovering between 5 and 7 Ksols/s with an i7 3770K and 32 GB of memory. |
|
|
|
May we have a full and professional explanation clarifying the story of those huge fluctuations about circulating supply in marketcap, in blockexplorer and between both?
I'm new to this thread and I don't know any of you. I read miners care about hashing power and I read team members care about promoting. I respect them. Respect me too.
If this coin is transparent as it says, with nothing to hide since inception, you should take it serious to properly answer the question, because this is beginning to smell as scam, or as terrible bug or as an intentional misleading information.
This was a currency project, takover by the community only 1 month ago. The team has already explained that the explorer is correct right now but Coinsmarketcap hasn´t updated the information, despite of the team has written CMC twice to fix the problem. The math to double check is pretty simple. ZERO makes 7200 coins a day. The launch date was 2/19/2017 so its been 326 days as of the end of today. 7200 * 326 = 2,347,200. The block explorer said 2,342,200 when I checked a few seconds ago. If you would like more information please read pages 22 to 28 where the issue was being discussed. It's been discussed more in later pages as well. |
|
|
|
our contest continuing....win free btcz by guessing how many 1 day 1 post new accs gonna post bs
feel free to laugh or cry!
That's 3, I'm gonna go with 15, by that I mean 1 account 15 posts. |
|
|
|
so the number is off by a couple of millions, lol. who cares. cmc has a link to the explorer right on their page people can verify the correct info.
It's not ONLY off by a couple million, it's increasing not frozen. And that matters big time. *** ZERO ACTUAL CIRCULATION SUPPLY NOW AT : 2,334,710 (with 7,200 added daily)*** Coinmarketcap showing 446,303 is NOT correct and the dev knows that http://zeroexplorer.forgetop.com/Dude, if people do their research investing then they would have done minimal reading and know the market cap is wrong. The people on twitter who give advice on what to buy and dont take the time to research just past tweets or just read the last 10 pages here would have easily spotted this. It took me about 2 pages in and is discussed 100's of times. The moral of this story is dont buy off recommendations from twitter without doing your own research and it also shows you just how "smart" some of the so called crypto experts are on twitter to not catch this. Please leave if you are gonna continue arguing about a known problem. I am not part of the team but im on here looking for real information and u keep spamming this channel. Giving info most people don't know is not spam. People can do as they wish, but they need to know the true numbers. It's called righteousness and fairness and the dev is not looking out for his customers by his not clearly posting that info for all to see. *** ZERO ACTUAL CIRCULATION SUPPLY NOW AT : 2,334,600 (with 7,200 added daily)*** Coinmarketcap showing 446,303 is NOT correct and the dev knows that http://zeroexplorer.forgetop.com/CONGRATULATIONS! You are SO RIGHTEOUS! Why don't you give yourself a pat on the back? Then you can go celebrate your own righteousness! We all love you and thank you so much for your positively titillating discussion topic! You are up to twelve whole posts now! They are all about the exact same thing! You have said nothing new since the first post! We are so happy to have people like you around! CONGRATULATIONS! You have just righted all of the wrongs of the world and you are the protector of those investors who may just by a nano-chance may have been "misled" . I am sure it was all deliberate manipulation of the market to pump the price! WRONG!!! I will tell you why the price is going up, it's not the "wrong" number. It is the fact that people are just now discovering zero. There are more miners showing up and increased hash rate. This typically results in increased prices because investors feel stronger about a stronger network. And all the miners show up and now it's more difficult, resulting in a higher price. Your attempts at RIGHTEOUSNESS do nothing to change the market value of the coin. Would you like to re-iterate once again the same thing you just said? Then you can be up to 13 posts with your brand new account, and they are all about ZERO. We feel so special to have you in our discussion group. THANK YOU SO MUCH YOU RIGHTEOUS BEING !!! You just care about making money. I care about truth. "A man without his word is a cockroach" - Scarface *** ZERO ACTUAL CIRCULATION SUPPLY NOW AT : 2,334,600 (with 7,200 added daily)*** Coinmarketcap showing 446,303 is NOT correct and the dev knows that http://zeroexplorer.forgetop.com/If your going to spam the channel can you at least use the right number? 2,334,820 |
|
|
|
Very easy to look at "recent posts from user" and see that the only content is attempts to discredit or no content at all... It is sad people waste their time like this. So insecure.
Relax, the only thing he did was to pump the volume of our coin. With amounts this high it is pretty much sure exchanges will fight to bring us in  Yes yes, I am relaxed despite a bit too much caffeine. Yet it I cannot help stating the obvious when an account is created just to post about Zero. I only feel bad for those who get panic and sold... A lot of money changed their owners this evening. So sad. I really don't think anyone is panicking, other than Zero's competitors. I am sure they bought up plenty of Zero's when they were cheap, waiting for this moment to dump them and troll our thread. It's no coincidental timing.. However, they waited too long because we are "over the hump" so to speak and the volume is high their little holdings get ate up and changed hands to real investors who will hold them. This is all good news. You're still guessing wrong. I own no Zero, want no Zero and don't want anyone being misled when they buy something. And if no one else is going to make it clear to people what the real numbers are, then i will. Crypto is about truth and freedom, not lies and deception. *** ZERO ACTUAL CIRCULATION SUPPLY NOW AT : 2,334,520 (with 7,200 added daily)*** Coinmarketcap showing 446,303 is NOT correct and the dev knows that http://zeroexplorer.forgetop.com/If you have ZERO interest in this project, I give ZERO fucks about your opinion. |
|
|
|
If it's over 3 million supply then the current price is incorrect. It's very simple math that even you can do. The current price times the circulation supply gives you the market cap. If instead of 446 thousand the supply is over 3 million, the current price would be over 6 times lower than it now to match the current cap. It's laughable you don't see the problem with the incorrect numbers. It is so adorable when brand new profiles come and try to convince people that this coin is no good:) Just go... hack your self The numbers are a lie. And i'm not going to sit by while people profit by deceiving their customers. Not in this life, baby! ****ZERO CIRCULATION SUPPLY = OVER 2 MILLION**** yes it is Thanks, but anybody reading this thread already knows that the coin supply is 2,333,920.00 as of right now and the market cap on that is about 29 million. If you don't then you're not paying attention. |
|
|
|
how can i mine this i the miner is working but where will it put my coins???
Windows wallet or linux wallet, found on page 1. Otherwise, store them in Cryptopia. ok so I installed the wallet and I get all that, I made a user name and password in the zero config file in the wallet folder, the read me says it will work even if I left it alone, my question is what does this file do? and why doesnt my password matter? so I can leave it as is, and just click the miner now and it will deposit coins into my wallet? it's not that the password doesn't matter. it does. however, you won't be needing it. it's a password to issue rpc (remote procedure call) commands to the daemon which is not relevant to your situation. it is however, relevant if you put a very easy password and enable rpc and somebody were to try to "hack" your wallet.. then they could issue commands to send the funds from your wallet. while it seems very unlikely anybody would do such a thing (or find your wallet out of all of the wallets should they try) it is still a good plan to not put something simple there. I believe that if it is totally disabled everything will work fine. you don't need RPC commands since you aren't running a site or remote wallet. if you disable the username and password it will result in "impenetrability" , rpc commands will be disabled except for local cookie authorization (which is a whole different thing) .. you don't really need to worry about any of that unless you put a very easy password to guess, still would be very unlikely .. securing your wallet by disabling the password or if left enabled putting something extremely complex (unguessable) would be the best course. hmmm so myoptermizer miner command looks like this optiminer -s zero.suprnova.cc:6568 -u moobar.worker -p x -m 8080 is this correct? Did I do it the right way? How can I see how much I have mined if it is working? I can tell its working because my gpu is at 100% and running hit I hope that you replaced moobar.worker with your own worker name, otherwise you are mining for somebody else. |
|
|
|
@Demarsac "Ethical Philosophy", only this should have a great value .. but not in the midst of speculators, not in this society.
I disagree. Ethics is exactly what is needed in this society. I agree. Ethics creates trust, and trust creates value. Thanks guys Let me just add... Regardless of what someone has studied or not Your safest bet is to judge a person by his actions DM I agree. Ethics are only good if they are adhered to, which can only be judged by ones action. That said, I think you have earned a lot of trust by doing what you say you are going to do. |
|
|
|
@Demarsac "Ethical Philosophy", only this should have a great value .. but not in the midst of speculators, not in this society.
I disagree. Ethics is exactly what is needed in this society. I agree. Ethics creates trust, and trust creates value. |
|
|
|
|
