hi all ...
after compiling from the git ( yesterday ) - the wallet STILL says 'warning: this version is obsolete, upgrade required' ...
just ignore? ... or is there a later version that has not been updated to git? ...
#crysx
if you are compiling from git, you can do a git pull and that will go away. it was fixed about an hour ago. the next wallet releases will be updated in a few days.. an hour ago? ... no worries ... recompiling again ... new wallet? ... is this not the new wallet? ... with multialgo? ... #crysx btw - the latest git does not compile ... bombs out with errors ... /usr/bin/ar -rs libleveldb.a db/builder.o db/c.o db/dbformat.o db/db_impl.o db/db_iter.o db/filename.o db/log_reader.o db/log_writer.o db/memtable.o db/repair.o db/table_cache.o db/version_edit.o db/version_set.o db/write_batch.o table/block_builder.o table/block.o table/filter_block.o table/format.o table/iterator.o table/merger.o table/table_builder.o table/table.o table/two_level_iterator.o util/arena.o util/bloom.o util/cache.o util/coding.o util/comparator.o util/crc32c.o util/env.o util/env_posix.o util/env_win.o util/filter_policy.o util/hash.o util/histogram.o util/logging.o util/options.o util/status.o port/port_posix.o /usr/bin/ar: creating libleveldb.a make[2]: Leaving directory '/mnt/horustor/compile/coins/vergecurrency/VERGE/src/leveldb' CXXLD VERGEd libbitcoin_server.a(libbitcoin_server_a-rpcmining.o): In function `getmininginfo(std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > const&, bool)': /mnt/horustor/compile/coins/vergecurrency/VERGE/src/rpcmining.cpp:75: undefined reference to `GetDifficulty(CBlockIndex const*)' libbitcoin_wallet.a(libbitcoin_wallet_a-rpcwallet.o): In function `getinfo(std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > const&, bool)': /mnt/horustor/compile/coins/vergecurrency/VERGE/src/rpcwallet.cpp:86: undefined reference to `GetDifficulty(CBlockIndex const*)' collect2: error: ld returned 1 exit status Makefile:1619: recipe for target 'VERGEd' failed make[1]: *** [VERGEd] Error 1 make[1]: Leaving directory '/mnt/horustor/compile/coins/vergecurrency/VERGE/src' Makefile:523: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1
obviously this shows VERGEd not being compiled here - but the bombout is with VERGE-qt also ... #crysx it looks like you don't have a correct git tree. try re-cloning from scratch.
|
|
|
It's possible, but not without changing the code. Which code exactly? SGMiner itself or the darkcoin-mod.cl? the miner itself
|
|
|
i'd like to see an x17 and blake pool open up. if i dont see one in a few hours, ill create one that has both.
ok but how come the wallet "internal" miner can't mine any of the two algos? well it uses the cpu for one, so im sure theres no way anyone is going to yolo mine blocks right now i havent even tried to solo mine with a cpu in wallet. but i will look at it. it might make sense to just remove the miner from the wallet tbh.. but if an x17 pool or blake pool opened and we could point gpus.. that would be a diff story.. this is not too little hashpower: ERROR: VERGEMiner : proof-of-work not meeting target this really looks like a bug :-)
|
|
|
evergreen coin gone away?
|
|
|
i'd like to see an x17 and blake pool open up. if i dont see one in a few hours, ill create one that has both.
ok but how come the wallet "internal" miner can't mine any of the two algos?
|
|
|
somethings wrong I think we've forked the chain. ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) Should we stop mining? hes talking about his pool. i dont think he was on the correct update. all is well on the rest of the pools. blocks being found on suprnova, and idcray so far myrgroestl, lyra2rev2, and scrypt have blocks found. all is looking good. Lyra2RE or Lyra2REV2?? From readme: Algorithms: scrypt, x17, Lyra2re, myr-groestl, & blake2s thus it should be V1...
|
|
|
blake2s mining is broken. can't mine with an external miner nor wallet itself:
ERROR: VERGEMiner : proof-of-work not meeting target
looking into this.. so far i can confirm myr-groestl is working. thanks. question: I see that the algo diff changes even though blocks are mined on a different algo. that looks to be a problem for "slower" algos like x17. how do the algo diffs relate to each other? They don't. They difficulties are independent but they can retarget on a block found with any algo. If one algo gets stuck on high difficulty, the other algos can help it retarget instead of waiting for the next same algo block. It must be wrongly reported, then: "pow_algo" : "x17", "difficulty" : 255.71905437, Because no blocks have been found on x17 so far (it's way too high). Same with blake2s. EDIT: I think there is indeed a problem with diff. I'm mining on an algo (which didn't generate any block on the chain yet) for half an hour... doesn't make sense. Only groestl and lyra2 working so far.
|
|
|
blake2s mining is broken. can't mine with an external miner nor wallet itself:
ERROR: VERGEMiner : proof-of-work not meeting target
looking into this.. so far i can confirm myr-groestl is working. thanks. question: I see that the algo diff changes even though blocks are mined on a different algo. that looks to be a problem for "slower" algos like x17. how do the algo diffs relate to each other?
|
|
|
blake2s mining is broken. can't mine with an external miner nor wallet itself:
ERROR: VERGEMiner : proof-of-work not meeting target
|
|
|
someone with groestl did the rush! :-) I couldn't get any block while the diff was low.... :-(
|
|
|
stuck again at 338198 for many hours. stopping and restarting doesn't help. version is correct, compiled myself, ubuntu. I've reset the blockchain countless times, don't make me do it again!
|
|
|
I got angry because 2 people reported back. And they said that it's not faster. Yet you claimed 30->15->8% faster
Pallas claimed +10% and he was wrong on the 750ti. But he was also right on the gtx 970 and Linux. I didn't sell it :-D BTW the problem with windows wasn't in my kernel.
|
|
|
I'm having a hard time syncing the wallet. Compiled the latest git, cleared the blockchain, it hangs and only gets orphans or continuously reorganises the chain. Stopping and restarting may help, still I can't reach the last block. Any snapshot?
^^^^ | | | | Look a few messages up ("blockchain") doesn't work: ERROR: CTxDB::LoadBlockIndex() : Failed stake modifier checkpoint height=0, modifier=0x0000000000000000 VERGE: Error loading blkindex.dat . didnt u delete the blockchain? Yes I used the files in the zip archive. I will try importing, instead of overwriting. Your wording is a bit... off ... this isnt the wallet stuff that was in the zip download... this is the block index files. in your /roaming/appdata/verge folder. you need to delete THAT. (and make a copy of your wallet.dat) ofc... Sir I've been compiling and contributing to coin wallets for long enough to know how to use a blockchain snapshot :-)
|
|
|
I'm having a hard time syncing the wallet. Compiled the latest git, cleared the blockchain, it hangs and only gets orphans or continuously reorganises the chain. Stopping and restarting may help, still I can't reach the last block. Any snapshot?
^^^^ | | | | Look a few messages up ("blockchain") doesn't work: ERROR: CTxDB::LoadBlockIndex() : Failed stake modifier checkpoint height=0, modifier=0x0000000000000000 VERGE: Error loading blkindex.dat . didnt u delete the blockchain? Yes I used the files in the zip archive. I will try importing, instead of overwriting.
|
|
|
I'm having a hard time syncing the wallet. Compiled the latest git, cleared the blockchain, it hangs and only gets orphans or continuously reorganises the chain. Stopping and restarting may help, still I can't reach the last block. Any snapshot?
^^^^ | | | | Look a few messages up ("blockchain") doesn't work: ERROR: CTxDB::LoadBlockIndex() : Failed stake modifier checkpoint height=0, modifier=0x0000000000000000 VERGE: Error loading blkindex.dat
|
|
|
I'm having a hard time syncing the wallet. Compiled the latest git, cleared the blockchain, it hangs and only gets orphans or continuously reorganises the chain. Stopping and restarting may help, still I can't reach the last block. Any snapshot?
|
|
|
I never mined bitcoin, I came later :-)
|
|
|
Deos Decred mining use a lot memory or the memory frequency is irrelevant? If so, I will use 2GB cards.
No memory usage. Fast algo.
|
|
|
Hi decred, I have a 1.5% fee ccminer which is performing +6% than the latest decred commit on my 970 http://s000.tinyupload.com/index.php?file_id=07209038321464518069The miner will work on all compute capabilities > 2.0 It's your responsibility to set the intensity ( I'm mining with -i 31) I will opensource it once there is a publicly available version which outperforms it or just makes the fees obsolete If you like to see my work on other algos, here is my github https://github.com/alexis78/ccminer (currently untested on windows) I'd also be glad if you could post or pm me your hashrates on different types of GPUS since i have just a single 970, thank you in advance why not making a thread about your ccminer fork?
|
|
|
I didnt know of that. Anyway, no bad feelings. I'm very curious to know what led you do this thing ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) Since you saw my kernel, what do you think about the way i divide the scanning ranges of threads? Isn't it a more accurate way to experiment with parameters since you can use non powers (or even multiples) of 2 in intensity, blocks, nonces_per_thread and actually dont hash nonces > maxNonce while maintaing 100% threads of the block for the kernel's life span? (except on the last iterations) I didn't notice that and I'll have a look ASAP. Surely it's something the standard ccminer can improve: the old versions even had bugs, in that they might hash the same nonce range two times (not the current tpruvot's, AFAIK). It may be useful for fast algos like blake, so you can use the nonce range better ;-)
|
|
|
|