Hi all, to help new users with ( sync 1/1), I uploaded current blockchain in zip file ( hcn_blockchain_92682.zip) Try to extract under %appdata% / humanitarycoin folder C:\Users\UserX\AppData\Roaming\humanitarycoin Thank you, that worked!
|
|
|
Registered for the airdrop. Thank you again for this great opportunity!
|
|
|
Hash Rate: 28.03 MH/sec, Difficulty: 6727437161... This is not funny anymore . It's getting harder and harder for smaller pools to keep miners attracted as it is just too hard to find new blocks. No new blocks = no rewards and big miners leave.
|
|
|
sumo.pandapool.nl now featured with minimal payout settings and support for workers!
|
|
|
2017-Dec-24 15:18:28.330731 [P2P2] ********************************************************************** Last scheduled hard fork time shows a daemon update is needed now. **********************************************************************
2017-Dec-24 17:11:13.153423 [P2P0]----- BLOCK ADDED AS ALTERNATIVE ON HEIGHT 83786 id: <9e749b1e64b2a3f7abda76116bc497fd2ffba4e97eb947d89b6c409aabc20ca1> PoW: <aae31a24fa1f5f56b5adf339bce40e5714cd817957f5cb9dfdf8505a01000000> difficulty: 2110357819 2017-Dec-24 17:18:29.425331 [P2P2] ********************************************************************** Last scheduled hard fork time shows a daemon update is needed now. **********************************************************************
2017-Dec-24 19:18:30.963754 [P2P6] ********************************************************************** Last scheduled hard fork time shows a daemon update is needed now. Haha, did you even searched for this error in this thread? I posted this last week and @sumogr answered it: https://bitcointalk.org/index.php?topic=1905086.msg26546439#msg26546439
|
|
|
-snip-
I see that you use fixed difficulty. For instance, if you start on diff 500, you constantly stay at 500. Other pools have a more dynamic approach. Is there a way I can increase diff manually? My GPU on diff 10000 sends your pool hashes every 6.4 seconds, my CPU on diff 5000 sends every 14.5 seconds... on official pool, my CPU stabilizes around dif 30000 and my GPU around 150000. You can set your diff fixed at the clientside. At least with my pool @ sumo.pandapool.nl (which also suffers bad luck as I mentioned earlier in this thread). Just put the diff behind your wallet address, like: "Sumooxxxxxxxx .100000". This will set your diff to 100K. Thanks for the tip. I used this on fairpool a while ago, but ms-pool's faq didn't mention they supported this feature. It's true that with higher network diff, smaller pools are experiencing huge luck issues. Yep, it's hard. The current Hash Rate of 15+ MH/sec and Difficulty of 3.5G+ are not in favour of small pools.
|
|
|
-snip-
I see that you use fixed difficulty. For instance, if you start on diff 500, you constantly stay at 500. Other pools have a more dynamic approach. Is there a way I can increase diff manually? My GPU on diff 10000 sends your pool hashes every 6.4 seconds, my CPU on diff 5000 sends every 14.5 seconds... on official pool, my CPU stabilizes around dif 30000 and my GPU around 150000. You can set your diff fixed at the clientside. At least with my pool @ sumo.pandapool.nl (which also suffers bad luck as I mentioned earlier in this thread). Just put the diff behind your wallet address, like: "Sumooxxxxxxxx .100000". This will set your diff to 100K.
|
|
|
I try to transfer some Sumo with the sumo-wallet-cli (Sumokoin 'Sapporo' (v0.2.0.0-release)), but every time it crashes with 'Segmentation fault (core dumped)'. I am using the command transfer Sumoo-address-receiver amount.
There is a message that the default mixin 12 is being used and I have to confirm that I don't want to use a payment id. After that it crashes. My wallet has enough unlocked balance, the blockchain is fully synced, so what is going wrong?
Did you compile the wallet on the same machine where you get the segfaults? Has it ever worked before? I don't run Sapporo yet, since I don't need subaddresses but the previous version needs following libraries: ldd sumo-wallet-cli linux-vdso.so.1 (0x00007fff7d3f2000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f3068de4000) libm.so.6 => /lib64/libm.so.6 (0x00007f3068ae3000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f30688c6000) libc.so.6 => /lib64/libc.so.6 (0x00007f306851e000) /lib64/ld-linux-x86-64.so.2 (0x00007f3068fe8000) run ldd on your Linux and check if no lib is missing. No, I didn't compile the wallet on my machine, I downloaded and extracted it. The libs are all there and 'automatic' transfers from my pool are fine, but transferring with cli gives me this error. Update: I put some extra SUMO in my sending wallet and now the transfer is processed succesfully. Maybe somehow there wasn't enough SUMO in it before, but I would have expected a nice error about this instead of a crash.
|
|
|
I try to transfer some Sumo with the sumo-wallet-cli (Sumokoin 'Sapporo' (v0.2.0.0-release)), but every time it crashes with 'Segmentation fault (core dumped)'. I am using the command transfer Sumoo-address-receiver amount.
There is a message that the default mixin 12 is being used and I have to confirm that I don't want to use a payment id. After that it crashes. My wallet has enough unlocked balance, the blockchain is fully synced, so what is going wrong?
|
|
|
Look like hashing rate is catching up now. Starting getting harder and harder to mine.
Yep, it's just no fun anymore to mine with my small pool. Last block found a week ago!
|
|
|
Today is a great 'DeepOnion' day, because: - Airdrop day! And I have received my new Onions. - Trading has started @ Kucoin. That was sooner then I expected. - In about two hours the 2nd Q&A with TheMonkii!
|
|
|
Why is the luck of the network itself so low? Look at the luck of the blocks on different pools. Low luck above 200% is considered normal. But I looked at the luck of the blocks on other coins, there is not such a low luck, a maximum of 150, and this is a rarity.
I thought it was just something because of some kind of problem with my pool. The estimated time for finding a block doesn't come near to the actual time to find a block. But you say it's happening on more pools?
|
|
|
The current pump of the Sumo price attracted a lot of miners. The current global hashrate increased to 6.42 MH/sec! It is not a sad news it is happy news. More people mining, more hard to get sumos which bring more value per token. Also bigger awareness. Yeah, I know that it's only improving the value of the coin. But it's not great if you try to mine yourself and are already having bad luck with finding blocks. This means it will only get harder to find a block.
|
|
|
The current pump of the Sumo price attracted a lot of miners. The current global hashrate increased to 6.42 MH/sec!
|
|
|
The sumokoin project has a well maintained cryptonote pool fork here: https://github.com/SadBatman/cryptonote-sumokoin-pool/Changes we added to this fork are, amongst others: - Email notifications
- Miner controlled minimum payout rates
- Health monitoring in the web UI (e.g. see when the pool's wallet is down)
- Improved proxy support
We also have a Telegram group where we discuss new development projects and can assist if you have problems running our fork. https://t.me/joinchat/Hkpz6hIFOy4qGqMHTDzn1AIf you are a pool admin; come and have a look at our fork! Is it possible to update the existing cryptonote pool or is it necessary to start from scratch?
|
|
|
Onion seems to be stable around 4$, thats great news guys! Cant wait for it to hit Kucoin, gonna be interesting to see. Dont miss the livestream on friday! Keep it real! Cheers
Adding DeepOnion to another exchange will definitively get more people attracted! I can't wait untill next week when it hits Kucoin!
|
|
|
Can someone explain why I see this event in my pool?
"Last scheduled hard fork time shows a daemon update is needed now."
I am running the latest "Sumokoin 'Sapporo' (v0.2.0.0-release)" daemon already.
Safely ignore it. It is coming from Monero's hardfork update mechanism, it is an unimportant leftover piece of code. It will be cleaned on the next update Thxs @sumogr. I searched for the error on the internet and all the results where about Monero, so that explains it. Glad that I can ignore the error, if only I could change the red color of the error, it's triggering alarmbells all over .
|
|
|
Can someone explain why I see this event in my pool?
"Last scheduled hard fork time shows a daemon update is needed now."
I am running the latest "Sumokoin 'Sapporo' (v0.2.0.0-release)" daemon already.
|
|
|
Hi, where can I find the file with the wallet? I'm using Windows GUI-Wallet.
C:\ProgramData\SumokoinGUIWallet\wallets
|
|
|
Can someone help me out? I found out that my pool was not updating the charts for a while (3 weeks ). I can't remember but maybe that was the time I switched from running the pool with "node init.js" to running it with four seperate modules in tmux: node init.js -module=api node init.js -module=pool node init.js -module=unlocker node init.js -module=payments The README.md is not mentioning that there is a fifth module "chartsDataCollector" so I don't know if it was running as part of one of the other four modules. However, I have restarted the complete pool with "node init.js" and in the console I only see two out of five charts ("workers" & "hashrate"): 2017-12-12 22:08:13 [charts] workers chart collected value 2. Total sets count 9 2017-12-12 22:09:13 [charts] hashrate chart collected value 3311. Total sets count 9 So in my frontend I am missing the three charts for "difficulty", "price" & "profit". I didn't touch this section in the config_example.json so it's running with default settings, all charts are enabled. What can I do to get the missing three charts back? Update: As always, right after this post (without doing anything) the other three charts appeared out of nowhere...
|
|
|
|