|
Ok, alerts is fixed. Use last master commit.
|
|
|
|
|
I'm working on it.
I've pushed another alert, just to turn off blue messages until i fix problem.
build 14 is not exists yet.
|
|
|
|
Daemon output 2014-Jun-11 01:37:06.828478 [P2P2][URGENT]:This software is is up to date, please update.
2014-Jun-11 01:37:17.829092 [P2P8][URGENT]:This software is is up to date, please update.
On what version you are ? (don't care about wrong text) |
|
|
|
Please update daemon to version v0.1.1.15(5e193f8)
1. daemon miner hot fix!!! (solo miners)
2. pool rpc hot fix!!! (pools)
. |
|
|
|
Is this update only for pool/solo daemons ?
Solo. Pools is not affected. But for pools i have another fix that's comming soon. |
|
|
|
Please all pool owners and solo miners, check your daemon logs now, we stuck again.
It seems that some bug in miner.
Might be coincidence - I restarted my mining daemon to be able to print_block and see what was going on, and found the next block very shortly thereafter. I'm *sure* that the latter part was luck - it's a very fast machine but not *that* fast - but I wonder if there was something about the restart that triggered some updates. I agree with you. I guess in some situations on_block_chain_update() is not called for miner and scratchpad becomes invalid, that's why we have seen wrong PoW hashes. It's just guess, it's hard to reproduce it. I've pushed hotfix with regular scratchpad update, once 30 sec, for first time it's ok, but it will become expensive when scratchpad will be more than 10-20 MB, hope we gonna find bug by then. The only things I notice about the blocks: The "extra" field in 16755 is larger than any of the previous several blocks; 16756 included two tx hashes, which none of the previous blocks did. 16756 "timestamp": 1402428976,
16755 "timestamp": 1402425579, <- last block found before the gap
16754 "timestamp": 1402425570,
...
And extra fields: 16756 "timestamp": 1402428976,
"tx_hashes": [ "9d0367bd319b128856c4b5c0039d81d77da14594753f849a4b2cff25642e43b2", "5f52cc1f3922edaaccac6a226b0c1db4981952c2ead97550c80ba27d8a4bf031"
"extra": [ 1, 12, 170, 236, 106, 246, 128, 1, 64, 237, 160, 188, 139, 26, 60, 183, 2, 138, 33, 11, 78, 91, 223, 3, 160, 14, 147, 223, 31, 190, 15, 162, 14, 2, 22, 48, 46, 49, 46, 49, 46, 57, 40, 48, 46, 49, 45, 103, 101, 54, 50, 50, 99, 97, 48, 41, 124
16755 "timestamp": 1402425579,
"extra": [ 1, 254, 90, 32, 214, 169, 66, 142, 107, 82, 112, 69, 141, 195, 9, 6, 153, 36, 236, 134, 174, 29, 214, 163, 233, 119, 179, 189, 81, 22, 225, 246, 0, 2, 32, 48, 46, 49, 46, 49, 46, 49, 49, 40, 51, 48, 49, 55, 52, 102, 50, 45, 100, 105, 114, 116, 121, 41, 0, 0, 0, 0, 7, 89, 162, 98, 0
16754 "timestamp": 1402425570,
"extra": [ 1, 28, 48, 231, 241, 73, 242, 252, 185, 15, 227, 86, 12, 140, 79, 7, 171, 166, 109, 180, 100, 186, 97, 81, 74, 6, 20, 191, 82, 131, 53, 136, 111, 2, 22, 48, 46, 49, 46, 49, 46, 57, 40, 48, 46, 49, 45, 103, 101, 54, 50, 50, 99, 97, 48, 41, 124
The second of those two tx hashes was a pretty large transaction. I thought about some combinations of transaction that broke create_block_template(), but since there are no errors in log about this i guess transactions is not related. Not sure about this. |
|
|
|
|
Please all pool owners and solo miners, check your daemon logs now, we stuck again.
It seems that some bug in miner.
|
|
|
|
With last updated simpleminer I get strange picture.
Sometimes simpleminer can't get new job for a long time. Until the network found new block
Pool runs on server with 24 threads and has enough resources.
Thank you - this might be a bug I hadn't spotted. I'm not entirely sure if it's the same thing, I've submitted a pull request for a fix, but if you want to rebuild for yourself, this is the patch: --- a/src/miner/simpleminer.cpp
+++ b/src/miner/simpleminer.cpp
@@ -235,6 +235,9 @@ namespace mining
threads.push_back(boost::thread(&simpleminer::worker_thread, this, start_nonce, nonce_offset, &results[i]
nonce_offset += attempts_per_loop;
}
+ (*reinterpret_cast<uint64_t*>(&m_job.blob[1])) = (start_nonce + nonce_offset);
+
+
BOOST_FOREACH(boost::thread& th, threads)
{
th.join();
@@ -281,6 +284,8 @@ namespace mining
}
LOG_PRINT_GREEN("Share submitted successfully!", LOG_LEVEL_0);
new_job_needed = true;
+ (*reinterpret_cast<uint64_t*>(&m_job.blob[1])) = (start_nonce + nonce_offset);
+
break;
}
}
Merged, thank you. |
|
|
|
I have a few of these:
2014-Jun-10 07:18:20.634615 [P2P6]Blockchain stored OK.
2014-Jun-10 08:11:32.679787 [miner 7]Found block for difficulty: 79798370751
2014-Jun-10 08:11:32.683788 [miner 7]Block with id: <9e634e9cc3677301977e7fc114f2353bb1b9f341d72b214612b031b16cf40d48>
have not enough proof of work: <b4aa8012fb75a1d48646d64278afc3a0f7c7c83bc4e4e179479ff9c5a85063b7>
nexpected difficulty: 79798370751
2014-Jun-10 08:11:32.698789 [miner 7]ERROR ..\..\src\currency_core\currency_core.cpp:384[currency::core::handle_block_found]mined block failed verification
Not enough proof? Anything I can do to prevent this in the future?
I think there's a bug - I've been seeing this during some of the big "no block for an hour" things as well. My hypothesis is that it's related to the block timestamp getting thrown off by a miner with a bad clock, but I'll try to investigate more in the morning if nobody else figures it out before then. I guess timestamp is not related, since expected difficulty is seems right. Probably miner have a bug in reorganize when alternative chain is loaded. I'll do hot fix today that reloads scratchpad from blockchain in case of such errors with mined blocks. |
|
|
|
I have a few of these:
2014-Jun-10 07:18:20.634615 [P2P6]Blockchain stored OK.
2014-Jun-10 08:11:32.679787 [miner 7]Found block for difficulty: 79798370751
2014-Jun-10 08:11:32.683788 [miner 7]Block with id: <9e634e9cc3677301977e7fc114f2353bb1b9f341d72b214612b031b16cf40d48>
have not enough proof of work: <b4aa8012fb75a1d48646d64278afc3a0f7c7c83bc4e4e179479ff9c5a85063b7>
nexpected difficulty: 79798370751
2014-Jun-10 08:11:32.698789 [miner 7]ERROR ..\..\src\currency_core\currency_core.cpp:384[currency::core::handle_block_found]mined block failed verification
Not enough proof? Anything I can do to prevent this in the future?
Can you send full log file, or at least about last 100 screens. I'll try to figure out what happend. btw: at the moment when blocks stopped to appear you can also see connections count decreased. http://boolberry.com/munin/localdomain/localhost.localdomain/incoming_connections_count.html |
|
|
|
I've added preliminary multithreading support to simpleminer. It's annoying launching all of those processes manually. I've just now sent it as a pull request to crypto_zoidberg, but if anyone wants to test it, this is my test repository:
https://github.com/dave-andersen/boolberry
(For the paranoid, the only files that are changed are simpleminer.h and simpleminer.cpp, so you can copy those into your own checkout from the official release).
Note: That repository is going to go away if and when the changes are merged.
This is now merged into the main boolberry source, please update. As a warning, it's still suboptimal. It spends too much time waiting for jobs from the servers. The starting diff for the pools will need to be adjusted for multithreaded clients, at minimum. Better would, of course, be adding stratum support and a better miner architecture, but this is a start in the right direction. a) If you use it, be sure to connect to the highest starting difficulty port available on your pool. b) Latency is important. Make sure you find a pool that responds fast to your job requests! Look at the log output and see the time between "Getting next job" and the report of starting work (either job didn't change or applying scratchpad diff). c) The new arg is --mining-threads # Testing comments appreciated. This is alpha-quality -- I've run it on my own machine but that's it. from bbr.extremehash.com: Last Share Submitted: less than a minute ago Hash Rate: 256.71 KH/sec Total Hashes Submitted: 182280000 that's running 8 threads on an i7-4770. It's still slower than solo mining, but it's getting better.  dga, thank you for this update! New simpleminer uploaded to web: http://boolberry.com/downloads.htmlGood "luck"! |
|
|
|
I don't know how yo all are doin' , Difficulty: 66640425354, Block Found: Never  pretty funny Which pool do you mean? |
|
|
|
crypto_zoidberg is a dev powerhouse. I'm very confident about the future of BBR.  kudos to crypto_zoidberg  |
|
|
|
Hello friends. I want to share some intermediate results of work on GUI, just to let everyone know in what direction we are moving. A lot of work on integrating currency core and daemon stuff into qt is done. Now we can go much quicker. Daemon now is able to show the state information in GUI, so it's the first part of work, obviously not really usable without wallet functions, but was very important from technical point of view. Want to notice one more time: wallet functions is not enabled yet, i'm publishing this just to show concept. I've uploaded binary for windows and put link to our downloads page: http://boolberry.com/downloads.html (notice: this is not windows-only GUI, it's desgining as completely cross-platform qt-based GUI). Static build is not setup yet, so there is just a bunch of dll's, that should be enough to run binary. Few words about conception: for UI rendering i use WebKit(web browser engine, http://en.wikipedia.org/wiki/WebKit), that is provided by qt as qtWebKit library. You could see folder "html" in qt-daemon archive, so UI is represented as a full-featured html page, that is actually interacts with C++ code by using qt "signals" and "slots". This approach will help us to improve interface with nice appearance and fast implementation. You may do some experiments with GUI by changing html, and if you have any ideas how to improve it - you could share your html versions with screenshots - it could be easily included into Boolberry, since currend design is just a draft. Little trick, if you pass this parametr to GUI, you'll get both and GUI and console: qt-daemon.exe --alloc-win-clonsole For those who is lazy to download binary i've attached screenshots:   GUI branch om github: https://github.com/cryptozoidberg/boolberry/tree/GUI |
|
|
|
When was the last update for the client ?
Could we have on the first post the link to the client with the last date update ?
New build: v0.1.1.11(d6bd447) http://boolberry.com/downloads.htmlNew: few minor fixes, including fix in wallet (one more fix for big transactions) Thx. How do I redownload the blockchain in case it got corrupted ? Remove blockchain.bin from app directory (C:\Users\user\AppData\Roaming\boolb on windows) |
|
|
|
When was the last update for the client ?
Could we have on the first post the link to the client with the last date update ?
New build: v0.1.1.11(d6bd447) http://boolberry.com/downloads.htmlNew: few minor fixes, including fix in wallet (one more fix for big transactions) |
|
|
|
we must improve Gravity Well
when the hashrate slow down,and the diff down,someone prize the hashrate and diff quickly
when the diff going so high,they leave us,I think there is a bug in it
Well, i see as a main problem now is that we don't have pools. Since we have a different PoW it's not so easy to be add BBR to existing pools. I'm working now on simple built-in pool, to allow everyone to run his own daemon-based pool withot any development, just plug-and-pool. But if this won't help - i'll hardfork BBR with new difficulty adjustment. Can I use daemon-based pool now ? When I'm mining solo my hashrate is ~ 560 610 kb/s each one from four servers. Total is ~ 2 Mh/s . With pools ~ 780 860 kb/s from 4 servers. When was announced that pools are up i've freezed daemon-based pool branch, and got back to developing GUI. Hope Lukas gonna fix bugs. Mike will announce bounty for simpleminer optimization today, hope we make it multithreaded in the next few days. Total is ~ 2 Mh/s . With pools ~ 780 860 kb/s from 4 servers. - did you start simpleminer instance per each core on your servers ? |
|
|
|
|
Hi guys.
Pools have not yet found any blocks.
Does anyone from devs tried it on testnet and found there some blocks?
|
|
|
|
Added 500BBR transfer 0 1GY8357A9rGdzYKFojwY7jeyvTwZD4MpEMPsAPZwW2guY7s1xLZtKQFeud7XmTtHaPWZ2Qc8dJPtBLcAmq7aEDcj2VssTY3 500
Money successfully sent, transaction <1b016475d48bb15c3a49041b66a8ded06ca97e7aac0d50f6a9313d7d7e1341c4>, 613 bytes |
|
|
|
|
Show Posts
