Prohashing seems to assume that the coinbase is the same as the miners' reward, which it is not the case for SmileyCoin. The word "Block reward" is used on your page, and shown as 10 thousand SMLY. But the miners' reward is only 10% of the coinbase. It may not be as profitable as your calculator implies (apparently still very profitable, just not this much). I looked into this and it was decided to discontinue the coin due to low-quality daemon software. The scrypt blocks are returning an error about an "EIASAddress," but searching the Internet for the term didn't reveal any documentation as to what that is or how to create transactions to resolve it. More concerning, however, is that the daemon will return this error when scrypt blocks are submitted, but not when blocks for any other algorithm are submitted. It silently succeeds for those algorithms, still submits the block to the network, the other nodes reject it, and the daemon wasted over $100. This lack of testing on the part of the developers is unacceptable. Real people's livelihoods are at stake here, and that was someone's salary for the day.
|
|
|
BGrd3xq1jtott3AU8hzzya7BpDfroCpc9g BYND
what does that mean? AFAIK there is no SMLY mining pool. What pool are you using? Have you tried to read the postings above which tell you how to mine SMLY -- with no pool? Prohashing ( https://prohashing.com) recently added Smileycoin for mining and payouts.
|
|
|
I wanted to report that Prohashing ( https://prohashing.com/) now offers Nekonium for mining. Nekonium can also be earned by mining other ethash coins, or by using ASICs for other algorithms to take payouts in Nekonium.
|
|
|
We're pleased to announce the a Strayacoin block explorer is now available at https://prohashing.com/explorer/Strayacoin! You can also mine Strayacoins at Prohashing, or mine a different algorithm and receive Strayacoins for payouts!
|
|
|
I'm pleased to announce the addition of five new payout coins: - Crypto.com Chain (CRO)
- Chainlink (LINK)
- iExec RLC (RLC)
- Veruscoin (VRSC)
- Multi-collateral DAI (DAI)
All of these coins are available immediately for payout. Additionally, the synchronization issues we were having with TRON have been resolved, thanks to help from TRON's lead developers. The daemon is now fully synchronized and has remained that way for several hours, and all TRON payouts have been corrected.
|
|
|
Dear Chris and the Prohashing team, I have been using Prohashing now for a few months and love the service, I find it simple and beneficial to a lazy miner such as I am! I hoped to reach out to you to find out the processes of adding coins to the list of payout coins please? I have been involved in the crypto-community since December 2009 and am currently lead marketing guru for a blockchain use-case project called Qbase. Infos: Website: www.qbase.meBlock Explorer: http://explorer.qbase.me/BictoinTalk ANN: https://bitcointalk.org/index.php?topic=5047764.0Discord: https://discord.gg/QehcvfVTelegram: https://t.me/QBase_OfficialExchanges: https://altmarkets.cc/market/BTC-QBS and https://latinex.la/market/BTC-QBSWe would very much appreciate some feedback and info on how we can have Qbase added to your list of payout coins please. As mentioned I am such a lazy miner and although my ASICs remain on Prohashing, I’d love to be able to point my GPU rigs with you, and auto-convert to Qbase, if this is at all possible? I look forwards to your responses at your convenience. You can request a coin to be added by creating a support ticket at https://support.prohashing.com/. The only requirement is that it be listed at at least one exchange that has a private API and which accepts US customers. You can see the list of exchanges that we already have in the "Live coin status" page on the site. While we try to keep an eye on other forums, new tickets are sent to us immediately and can be assigned to the person most qualified to resolve the issue.
|
|
|
I would like to move from NiceHash to Prohasing (Lyra2REv2) . Does it make sense?
We have performed tests on SHA-256 and scrypt and have determined in all test cases that Prohashing yielded higher profitability than the comparable pool. For example, SHA-256 profitability was about 104% of what Antpool was paying, even after fees from both pools. Unfortunately, I don't have a Lyra2REv2 ASIC to test. At Nicehash, we found that scrypt mining was paying 98.2% of Prohashing's earnings.
|
|
|
It appears that even though miners could pull more out of the blockchain by using multipliers, enough miners tend to be content enough to get less reward by accepting the 50 BTCV payout. This is actually good in that it strengthens the blockchain by finding blocks faster which makes a 51% attack harder. As I observe the Variable Block Rewards in action, it seems that the majority will form pools either going for x1 or x2 block rewards. There will always those trying to grab a large reward SOLO mining. It is the additional variation of pools and SOLO mining that actually makes BitcoinV a more decentralized version of Bitcoin.
We are Prohashing are mining at x1 because that is the only multiplier compatible with our mining software without code changes, and I suspect that's the reason most other pools are using x1 as well. We would love to mine at a higher multiplier, but the client has what we consider a bug - it returns the same difficulty target in getblocktemplate regardless of the multiplier; the difficulty should increase by the multiplier. Therefore, if we use another multiplier, we pay too much to customers. For example, with an x16 multiplier, the block reward increases by 16 but the difficulty doesn't increase, and we end up incorrectly paying 16x per share to miners. If the client just increased the reported the difficulty by the multiplier, then it would be compatible with all existing pool software, including ours, and we could easily increase our multiplier. Otherwise, we would have to modify our pool software to support BitcoinV and deal with all the potential bugs that may introduce. I think the community of miners could be greatly expanded if that single change was made to the client. We have contacted the developer requesting this change, and he has said that what we consider a bug is actually a feature and that will not be changing this behavior. We disagree.
|
|
|
I downloaded the go client, but I am not finding any peers. Can someone post a known good peer so that I can get connected? Thanks!
My node is enode://a3e4a082acab5efd104593e6e949f5873cc904e7de41ae872ece063b00e32cca052fb475e34d99bbf7a0a838948bf2b119468616917b7718ff4bdf156e9d38fd@50.225.198.67:6491
|
|
|
Are there any remaining nodes hosting this coin? The client has no connections by default.
|
|
|
I'm trying to debug our pool by mining testnet blocks, but I can't find any testnet nodes to get the bitcoingold client working. Does anyone know of any working testnet nodes that I can connect to?
|
|
|
Same chain, to my knowledge. Perhaps that pool went on a fork?
Share the TXID's in question and maybe we can assist.
Here's a small subset of the transactions I don't see on the chain. The client just returns "Invalid or non-wallet transaction id" Date (EDT) Destination address Amount Txid 1-May-17 2:34:19 AM RN3EcJ8PB6Ci9qjPnTUM1yPELd8AodPdnP 106925.4563 9dabdff91b362317bce149642f2a7988d4e1b650e4af12b51a71f756127def08 1-May-17 2:34:20 AM RYLyovgbxorkmVRzFNXWzt8PKLN9N4fURP 131172.6599 2280e1ff0de1dfea388618c1afcebffc22a9c9ff85c876b8e449205db3db1924 1-May-17 2:34:21 AM RBP4LUpAj39xb7T5JEK2ML4hMRfnLJ7uw3 252226 967a2dc8594f78d16a6adcf7068554744df24a11cb7b70d0a3974c22da2f3648 1-May-17 2:34:22 AM RDtBg3WmPzqcjjGiT3AoCmicfpPE4qgcFu 447397.3222 72476fbc6e623a1aa214926d5b356996ddc0b75d15a3e294d2fe56946bf725d1 1-May-17 2:34:23 AM RLpxahx4hUNd1xVgARNwuUn6DWYVGatQ2w 781039.3804 8e9d66b4d4299fd1f5c24e5767a6ed8b45c7662cb832768c8270b5c974651d40 I appreciate any insight you can provide All these appear to be sent around the same time, second apart. Was this automated? I suspect a fork occurred around that time and orphaned these txs. Do you have control of the sending wallet? Move the input address private key to a clean wallet and -rescan. Such a small amount compared to the balance on those addresses ... Hats off to the early adopter. Congrats to you sir. NYC wallets also have the config option to spend unconfirmed change. If that was enabled and these tx really were sent 1 second apart .... any failure of a single tx would cause problems for the next that included the unconfirmed change. And the next, and the next. The option is in the options under the wallet tab. Thanks for the reply. I picked those just because they were recent, but our database has an additional 934 transactions that I can't find in the explorer. I don't want to post them all publicly but I can send you more examples via PM. We were mining blocks and selling them at Bleutrade at the time, so I know we were on the correct chain. Those 939 transactions were all sent to different people but not Bleutrade. I find it unlikely that all those transactions were invalid for over two years. I feel like I would have noticed that sooner (or someone would have complained that they never received the money we sent them). I will note that we have replaced our wallets multiple times over the years, so those transactions did not originate from our current wallet, but that shouldn't affect whether they are valid. When calling gettransaction, would the client return "not found" for transactions that did not originate from the current wallet? We do have txindex=1.
|
|
|
Same chain, to my knowledge. Perhaps that pool went on a fork?
Share the TXID's in question and maybe we can assist.
Here's a small subset of the transactions I don't see on the chain. The client just returns "Invalid or non-wallet transaction id" Date (EDT) Destination address Amount Txid 1-May-17 2:34:19 AM RN3EcJ8PB6Ci9qjPnTUM1yPELd8AodPdnP 106925.4563 9dabdff91b362317bce149642f2a7988d4e1b650e4af12b51a71f756127def08 1-May-17 2:34:20 AM RYLyovgbxorkmVRzFNXWzt8PKLN9N4fURP 131172.6599 2280e1ff0de1dfea388618c1afcebffc22a9c9ff85c876b8e449205db3db1924 1-May-17 2:34:21 AM RBP4LUpAj39xb7T5JEK2ML4hMRfnLJ7uw3 252226 967a2dc8594f78d16a6adcf7068554744df24a11cb7b70d0a3974c22da2f3648 1-May-17 2:34:22 AM RDtBg3WmPzqcjjGiT3AoCmicfpPE4qgcFu 447397.3222 72476fbc6e623a1aa214926d5b356996ddc0b75d15a3e294d2fe56946bf725d1 1-May-17 2:34:23 AM RLpxahx4hUNd1xVgARNwuUn6DWYVGatQ2w 781039.3804 8e9d66b4d4299fd1f5c24e5767a6ed8b45c7662cb832768c8270b5c974651d40 I appreciate any insight you can provide
|
|
|
I'm having an issue with old NYC transactions. I've been looking back in our pool's transaction history, and none of our transactions before October 2017 are found in the client. I'm sure they were valid at the time, but now when I call 'gettransaction' in the client, only the transactions since October 2017 return as valid; the older ones are not found. I've tried in the block explorer have the same results. Why would old transactions not show up? Is this a different chain than the one that was on Bleutrade least year?
|
|
|
You can't compile this coin from source because there is no main.cpp or main.h. Unless I'm looking at the wrong repository. Can someone confirm?
|
|
|
*** FORK UPDATE - RESOLUTION - INSTRUCTIONS - ACTION IMMEDIATELY***Linux users - Compile the new wallet from source https://github.com/novaexchange/SOCC and ensure you delete your blockchain, before using the 'connect' command in your conf as detailed below. Windows users 1) Delete your blockchain files in AppData\Roaming\Socialcoin To get to this directory, as I'm sure you all know, use %appdata% in the run box, and open up the 'Socialcoin' directory. DO NOT DELETE THE wallet.dat FILE DO NOT DELETE THE socialcoin.conf file All other files and folders should be deleted. 2) In socialcoin.conf file, add the following line AND DELETE PREVIOUS. This is critical, and without this addition and removing the blockchain, the fix will not work: connect=217.175.119.126:18645So your conf file should now look like this: rpcuser=<your local wallet address> rpcpassword=x rpcallowip=127.0.0.1 rpcport=18646 port=18645 listen=1 server=1 connect=217.175.119.126:18645 MAKE SURE YOU DELETE ANY EXISTING ADDNODE LINES. Once we issue recompiled wallets, the old nodes can be added once again. Note that the above is a temporary solution whilst we also work on issuing recompiled Windows wallets (I am away from home currently will get to this ASAP). This will be done ASAP but for now, removing the blockchain and mining with the above settings should work successfully. To aid mining, connecting to GCPOOL is the suggested solution as part of the resolution to this issue is mining the blockchain until the height exceeds the height of the hacked chain. Indeed, to secure the network properly we need people to start mining on this pool please. Any questions, post them here. Massive thanks to Linus on the Nova Exchange for his dev assistance in this. And to Glen on GCPOOL for clearing his hangover incredibly quickly and recompiling his pool  Cheers, Mark. Is this node still online? I set up our client to use only that node, and we can't connect to it (0 peers).
|
|
|
I've been trying to sync the goldblock daemon (compiled from source on Debian 8 ), but after it finishes downloading a few thousand blocks, calling any command on the daemon results in the following error: error: {"code":-1,"message":"CDB : Error -30973, can't open database "} Can I get suggestions on how to fix it? Thanks in advance.
|
|
|
The wallet from the first post doesn't sync. I need latest wallet or working nodes. Please, help.
Yeah, I have the same problem. Even after adding C-CEX's nodes, it won't get past 999 blocks.
|
|
|
I want to start mining BCC, but pool list on OP don't show enough Hasrate compare the whole Network like 500 Ghs right now, where I can find that pool with such big Hashrate? where the biggest Pool of BCC?
At Prohashing, we have between 60-160 GH/s on BCC depending on the time of day. I don't think we're the biggest BCC pool, but we're somewhere near the top.
|
|
|
|