 Show Posts
|
|
Pages: [1] 2 »
|
Umm...why does the website ( https://cryptopay.org.za/) claim the price of CPA is some 30 times higher than it is, in USD? There have been a couple of trades at 1 sat. 1 sat is about $0.000065 USD last I checked From the website: 1 CPA = 0.00190000 USD
1 CPA = 0.00000001 BTCIts pulling the current sell price from the exchange. Go look on primex under usd-tether tab CryptoPayAfrica(CPA) Usd-Cpa 0.00190000 USD 0.00000000 Regards Dev I see. In a liquid market the prices so derived shouldn't deviate by too much, but here, there's a huge distortion. It's also not clear why there is even a CPA-USD price listed as there's been no volume for that pair according to the exchange. Likewise with DOGE. It looks like it's just taking the ask price of the top sell order and posting that. |
|
|
|
Umm...why does the website ( https://cryptopay.org.za/) claim the price of CPA is some 30 times higher than it is, in USD? There have been a couple of trades at 1 sat. 1 sat is about $0.000065 USD last I checked From the website: 1 CPA = 0.00190000 USD
1 CPA = 0.00000001 BTC |
|
|
|
The fact that the project has managed to attract a few tens of miners (31, at current count) with not that much exposure is encouraging. Some more effort on bringing in new miners and establishing the use case for the coin, developing features linked to the use cases etc will pay rich dividends at a later stage once listed. It looks however like the listing is going to occur soon on a new exchange, and the end result is likely to be a sharp slowdown in progress as the price established may (my guess is, will) deter additional miners from coming on board.
Some wise words. Our thinking was that a new exchange has to grow as well and they will have to market thus also pushing the coin growth. I have close contact with the owner and he will make sure we get the necessary exposure on their new exchange. We will have to do some research as to how and when we going to a second exchange and how it would affect what we trying to achieve. Yes definitely more mining pools. I was hoping some community members would take up the challenge. If I own all the mining pools it will also seems that we want to control everything. That is not the case we want everyone to contribute. Like I said its been 3 weeks we also learning the ropes. I am in two minds about discord so early in the project. I have seen many projects go up in flames because of FUD spread on those type of channels. "The fact that the project has managed to attract a few tens of miners (31, at current count)" Remember that doesn't count the webminer and daemon miners stats shows we have over 90 Miners connected today. We have a public holiday tomorrow in South Africa. Its a bit of family time. I will have a meeting with my team as soon as everyone is available. We have 29 Nodes active already http://51.15.99.72:8085/Keep up the good work. Even if I am not keen on a listing, I am curious to learn more about the exchange itself. Have a good holiday! |
|
|
|
|
The fact that the project has managed to attract a few tens of miners (31, at current count) with not that much exposure is encouraging. Some more effort on bringing in new miners and establishing the use case for the coin, developing features linked to the use cases etc will pay rich dividends at a later stage once listed. It looks however like the listing is going to occur soon on a new exchange, and the end result is likely to be a sharp slowdown in progress as the price established may (my guess is, will) deter additional miners from coming on board.
|
|
|
|
|
I don't understand why everyone is always clamoring for exchanges. Listing too soon runs the risk of stunting a project's growth as everyone becomes obsessed with price. For a coin with 1 mining pool (unless I am mistaken there are still no others) the real focus should be on development, opening of other pools, developing use cases etc, growing the network hashrate, etc. Buyers won't magically materialize just because there is an exchange.
|
|
|
|
|
Thanks to the devs being very active and responsive on the discord and looking into the Win7 remixd issue, that turned out to be a non-issue really. Used n2.remixcoin.io nodes to sync. n1.remixcoin.io is also out there.
|
|
|
|
|
Is there a discord or a telegram chat as yet? Much better for back and forth than BCT
|
|
|
|
Is the project site and pool having a DNS issue? I can't reach cryptopay.org.za nor pool.cryptopay.org.za
I have a miner still on the pool, but two others are unable to reconnect, after having been on there for some time (all are on the same network...the two that cannot reconnect were rebooted at some point, and then lost the ability to find the pool).
All systems are good now. Yesterday we had a DDOS attack on one of the servers from South Korea! Issue was dealt with. Are you running your miners on the same IP? PM me if you still have the issue. Send me your public IP and I can check if you did not get blocked on the network. All good now. Added a new DNS server in my own config and CPA servers are reachable now. Not sure why they fell off the radar of my previous DNS server. |
|
|
|
|
Is the project site and pool having a DNS issue? I can't reach cryptopay.org.za nor pool.cryptopay.org.za
I have a miner still on the pool, but two others are unable to reconnect, after having been on there for some time (all are on the same network...the two that cannot reconnect were rebooted at some point, and then lost the ability to find the pool).
|
|
|
|
Something is screwy with running the cli wallet on Windows7. Maybe it's just my Win7, I don't know. I've been mining to a wallet address that I generated using the cli wallet on Win7. The node wasn't running, as documented in my earlier post about the invalid hash for blocks 0-255. Anyway, my attempt to use the key files generated on the Win7 box on the properly running Win10 node+cli wallet produced a weird result - the wallet opened, but showed a zero balance, and no transactions. Very strange. I had verified a mining tx using the block explorer when I first started mining, so I didn't think there was a problem at the pool end. Anyway, I recovered the wallet from the mnemonic seed on the Win10 box and that worked fine.
I don't know what the origin of these issues is, but it seems there's a real problem with running the tools on Win7 (or at least my Win7 - but I run other nodes and cli wallets on Win7 just fine).
Updated to v0.1.0.3 and was able to sync node |
|
|
|
|
Something is screwy with running the cli wallet on Windows7. Maybe it's just my Win7, I don't know. I've been mining to a wallet address that I generated using the cli wallet on Win7. The node wasn't running, as documented in my earlier post about the invalid hash for blocks 0-255. Anyway, my attempt to use the key files generated on the Win7 box on the properly running Win10 node+cli wallet produced a weird result - the wallet opened, but showed a zero balance, and no transactions. Very strange. I had verified a mining tx using the block explorer when I first started mining, so I didn't think there was a problem at the pool end. Anyway, I recovered the wallet from the mnemonic seed on the Win10 box and that worked fine.
I don't know what the origin of these issues is, but it seems there's a real problem with running the tools on Win7 (or at least my Win7 - but I run other nodes and cli wallets on Win7 just fine).
|
|
|
|
|
new info - remixd is syncing successfully on a Windows 10 box. The error I described previously was on a Windows 7 box. Not sure why I cannot get it going on the Win7 system. Not an urgent issue, but if the devs know what this might be related to, let us know.
|
|
|
|
|
Hi - I am unable to get the blockchain synced on my machine. Windows. I get a message about invalid hashes for blocks 0-255, shown below when I run remixd:
[REMIX] [info] The network detected a new top block: 1 -> 8274 [8273 blocks behind]
[REMIX] [info] SYNCHRONIZATION started
2018-09-08 17:15:00.064 [P2P7] WARN blockchain src/cryptonote_core/blockchain.cpp:3849 invalid hash for blocks 0 - 255
Has anybody been able to run the daemon and download the chain successfully? Any ideas re: the above error?
|
|
|
|
Payments have gotten screwy again - they are moving, but in insufficient amounts to prevent accumulation of pending balances.
We will be increasing the payment frequency in about an hour. We are in the process of building a second pool. We welcome anyone that wants to run their own mining pool. Get in touch with me. Regards Dev Team Is there a reason why the payment issue has been cropping up? It would be good if it could be conclusively sorted out, so that folks feel confident in leaving their rigs on the pool without having to worry about payments getting jammed up. Cheers. |
|
|
|
|
Payments have gotten screwy again - they are moving, but in insufficient amounts to prevent accumulation of pending balances.
|
|
|
|
A few strange sized payments just came through, but with 0 (zero) mixins. I think you want to keep mixins, yeah, to keep the transactions private!
Mixins size set back. Guys we welcome anyone that wants to run a mining pool. Please PM me if you want to run and support the project. Great - thank you. The project reflects a lot of passion...I wish you guys well. Find a way to differentiate your coin and make it stick! You are likely already doing this, but please don't let your project fall victim to the same missteps that some other small CN projects have fallen prey to in the recent past. Github has excellent documentation on some of the issues, including a wallet attack uncovered by Arqma, and difficulty adjustment issues revealed by GRAFT. I am sure there are many others out there, not all of which may apply. Cheers. |
|
|
|
|
A few strange sized payments just came through, but with 0 (zero) mixins. I think you want to keep mixins, yeah, to keep the transactions private!
|
|
|
|
|
Same issue here - payments on mining not coming through. I guess no payments from the pool overall for the past ~7 hours or so. Also - are there other pools running out there?
|
|
|
|
|
Kudos on your project. It looks like the diff adjustment algo is quite slow to respond to changes in hashrate however. Hopefully you are not using the diff adjustment from XMR verbatim. A minor comment - the link on your webpage for the source files points to bitbucket instead of github.
|
|
|
|
Yeah... so I got a little too excited too soon. Definitely have my overclocks well within previous working ranges, and yet after mining for a while cards will randomly start hashing ~100-200 H/s. Very strange... I can exit the miner without it hanging and having to restart, but still, can't be around to monitor the machines.
Will probably pull out the old JJHashRateMonitor modified for CAST and see if that can take care of it, since --ratewatchdog can't fix this problem. We're getting close though!
I had a similar experience. 2 RX Vega 64s on 18.3.4 driver, PCIE set to GEN1, power play tables etc. Rates are good (maybe about 2% better than with cast 0.9.0) and temps are maybe 1 deg C lower. After a few hours though both cards dropped down to ~ 400-500 H/s. I saw there were kernel resets in the miner, but they were unable to restore the full speed (~3900 H/s). Was able to exit gracefully and restart. Now running without the --ratewatchdog option. My suspicion is that the kernel resets are themselves responsible for the strange rates - these are hashrates (~400-500 H/s per card) I've never had in the past. It could be in the past the miner would hang/system would crash prompted by whatever prompted the initial fall and kernel resets however. More to be learned. Regardless, the implementation of (an eventually working native) option like ratewatchdog is sorely needed, so this initial development is applauded! Hope it continues... |
|
|
|
|
