tanx sp ...
ill let you know when i get it ...
I have already sendt it yesterday. You are on the mailing list. it was last night that the email was fixed - i was on the fone for an hour to get it running again with the isp ... they had 'fixed' it prior - but i still had issues ... should be all good now ... so i probably didnt get it ... could you send again please? ... is this both vanilla and decred - or just decred? ... the last i got was #5 on the 25032016 at 2027 ... #crysx |
|
|
|
#9??? ...
sp - why are you not sending ANYTHING my way now? ...
I am sending to the crysx email adress adress. tanx sp ... ill let you know when i get it ... ill be off to bed soon - as ive had a HUGE day today ... but if you are sending it now - i should get it soon after you send ... im getting very upset with bct and their lack of care for the people in my situation and profile lockouts and forum bans ... i got hit with both - and STILL nothing from them ... pathetic really ... #crysx |
|
|
|
Offtopic: For the 980TI I actually get better throughput using -i 31 than -i 31.9 (as reported poolside). The typical job time is about .8 seconds vs 1.1-1.2 for the higher intensity. These numbers I can see when I have a run of jobs for which it did not find a solution (don't use -q). I am a bit more likely to find a solution meeting the difficulty requirement of the job at the higher intensity but the slower processing time lowers throughput. This made me scratch my head more than a little bit...why the higher solve rate at the higher intensity? But I've watched the numbers stream past for hours. Tried -i 31.5 and it yields same results as 31.9 for throughput.
The intensity control how many hashes you compute in the gpu before work is restarted.. In version #9 only one solution is kept and sendt to the pool. In version #7 and #8 2 solutions are sendt if found.¨ I=25 2^25= 33554432 Up to 262 144 Hashes are computed on the gpu before work is restarted. i=31 2^26= 2147483648 Up to 16 777 216 Hashes are computed on the gpu before the work is restarted. On low difficulty the probability of finding 2 solutions is high (since we are checking up to 16 MHASH in one go), but ccminer #9 is only sending one solution to the pool. On low difficulties and high intensity version #9 will only send 50% of the solutions found. On high difficulty and high intensity version #9 will send up to 100% of the solutions found, but If the gpu is too fast, the miner might be faster than the pool, and work will be lost. I use default intensity of 29 for compute 5.0 and 30 for compute 5.2 and up #9??? ... sp - why are you not sending ANYTHING my way now? ... the emails have been fixed - and you can send to the email you have on your list ... just because i have a newbie account doesnt mean crap - especially when bct have done NOTHING in helping me with getting the chrysophylax account back ... if you dont trust newbie accounts - fine ... send the updates to the email address you have always sent it to - and i will get it ... im NOT a fake bullshit account that is here to play ... what gives mate? ... #crysx |
|
|
|
I'm surprised they released tesla first, I would expect them to beta test with the consumer line. Maybe they are confident enough in the quality. same ... though nvidia do thngs in the most unorthodox ways ... cant wait to see how cuda 8 performs with it ... #crysx If I understood properly: they will hit the market NEXT YEAR?? now that tesla pascal is out - it will be in production for the corporates ... so chance are - nvidia already has the commercial consumer line already produced and is waiting on the influx of cashflow from the corporate range before they release the consumer line ... this MAY mean that they are only a few months down the track - if that long at all ... the consumer line will most definitely be the most expensive cards on the market when that happens ... so for me - it will be a good 6months before i buy any pascal in bulk for thefarm - though a single card for testing maybe on the books ... #crysx |
|
|
|
Big holders of this coin should help. I used to be a big holder, but not anymore. I sold A LOT.
Somebody has bought A LOT. The new big holders should be able to get DEV team for this coin.
I have tried to get soopy over, but he is always missing. I am still around, but not a big holder anymore.
Throwing money at a coin will not solve things completely. If a dev or team is driven, it only takes one dev (or persons on a team) with 1 OC each to make that 1 OC dream worth a million $. We need a dev and team to be whole-heartedly committed, to achieve new boundaries of code and see what the blockchain can really do. We have parts of that team already. Well said. Well said, Halo. -Raven agreed ... totally ... hence the word TEAM being 'unounciated' in the post ... but you cannot expect a TEAM to have 1oc and make it worth $1million if the major holders of the 'team' is but the few that are the richest ... that will not work - no matter which way you look at it ... a shared expense and wealth is the ONLY way you will do this - unless you get contracters to come in - do the job - and leave - getting PAID ( not invested in oc ) in btc for the 'job' ... if my team and i came in and did this - with no oc in our pockets - how fair would that be? ... as a team - shared wealth AND shared responsibility would be the priority ... but having said that - it all goes to hell if you dont have a team LEAD to have the ultimate say after the voting is done ... sounds too corporate for you? ... it probably is ... but it works and can make a coin pull itself from obscurity - to the the forefront ... there are some MAJOR holders of oc - that should share some of that wealth if they want to realize the coins potential ... its the only way to attract the attention and focus of devs willing to put time and effort in ... thats my 1oc worth ( which is more oc than i actually own ) ... #crysx |
|
|
|
I'm surprised they released tesla first, I would expect them to beta test with the consumer line. Maybe they are confident enough in the quality. same ... though nvidia do thngs in the most unorthodox ways ... cant wait to see how cuda 8 performs with it ... #crysx |
|
|
|
its like saying that feul efficiency IS the factor in high octane drag races ... its not - its the time it takes to get from one point to another - and the fastest wins ... period ... they dont care how much feul or noise or rubber is used or destroyed in the process ...
that's because they have a wide margin. everybody must take expenses into account. if you made more money by lowering your TDP, wouldn't you do it? do the math and you'll see. agreed ... expense IS a factor IF the result takes it into account ... if all you want is more hashrate at the expense of power - then great ... i will concede though that in a larger farm environment - this view would be the deciding factor for the farm and its design and setup - as the smallest decrease in power would save a huge amount ... but in this case pallas - i honestly dont think the power reduction is that great that it would be anything to worry about - especially if thehasrate is increased by a larger margin ... not a very small one ... as for money - im not fussed on that end ... it comes good in the end when it comes to money ... im more concerned with the coins themselves ... more hash - more coin ... hence the reason why i have always said - that my view of 'profitability' is VERY different form what most people accept it to be ... #crysx WE ARE NOT IN A HIGH OCTANE DRAG RACE-- There has to be a standard for measurement, even in a drag race. The amount of sassy banter that goes on in this thread is extra-ordinary, and it is all about who has the best code. Even drag races have rules, it is not always just the fastest time. Some races are about the closest time to a point, etc. There has to be a standard way of comparison. I like my beer, I am not an idiot, and I want to keep my beer free of the yellow-tinted spray wash that is wizzed around so frequently in this happy thread. Don't pollute my sudz, please. --scryptr hahaha ... and as usual - you manage to put a smile on my face scryptr ... you are completely wrong - it IS a drag race here fro the highest hashrate - but nonetheless a very funny read ... i dont drink alcohol - nor smoke - nor do drugs ... i do drink a LOT of water though ( about 5 litres a day ) - so go figure with the yellow spray ...  ... if there was a standard of measure that could be verified by a reliable source that had standards to abide by - then i would totally agree ... but this is a drag race that has no rules - so the end result is who hash the 'bigger' hashrate and stable miner - no matter how much power is involved ... power is expensive here in australia - and so i need a LOT of coin to cater for it if i were to trade in all the coin i own ... luckily for me i have other businesses to make sure there is other income flows ... or maybe not luckily - just smart enough to make sure it doesnt kill everything i do ... im old enough and ugly enough to know the difference ... either way - hashrate is king in here ... whether we like to conserve power or not ... i guarantee you - that if a miner comes out that is twice the hashrate we are getting now - but uses three or four or five times time the current power usage - miners worldwide would jump on it like a sexy hollywood actress turned hooker giving away her services for free ... #crysx |
|
|
|
sp ... what version are your kernels sitting at currently - and where am i at with receiving any of the miners? ... the email is back online again - and you can send emails again to that address ... just so you know its me - chrysophylax  ... #crysx |
|
|
|
its like saying that feul efficiency IS the factor in high octane drag races ... its not - its the time it takes to get from one point to another - and the fastest wins ... period ... they dont care how much feul or noise or rubber is used or destroyed in the process ...
that's because they have a wide margin. everybody must take expenses into account. if you made more money by lowering your TDP, wouldn't you do it? do the math and you'll see. agreed ... expense IS a factor IF the result takes it into account ... if all you want is more hashrate at the expense of power - then great ... i will concede though that in a larger farm environment - this view would be the deciding factor for the farm and its design and setup - as the smallest decrease in power would save a huge amount ... but in this case pallas - i honestly dont think the power reduction is that great that it would be anything to worry about - especially if thehasrate is increased by a larger margin ... not a very small one ... as for money - im not fussed on that end ... it comes good in the end when it comes to money ... im more concerned with the coins themselves ... more hash - more coin ... hence the reason why i have always said - that my view of 'profitability' is VERY different form what most people accept it to be ... #crysx |
|
|
|
the only fair conditions to compare miners is at the same power usage.
at the end of the story, it's efficiency that counts, not "maximum speed".
so just set a low tdp and see which one is faster.
I'LL BACK THAT-- It is based on the economy of mining. Variations in code may require different command-line tweaksfor best hashrate, but this proposed standard is based on the bottom line. --scryptr i cannot agree with that ... in MY mining - i disregard the power argument altogether ... as i dont tweak or manipulate ANY of the power settings ... ever ... i dont oc either ... speed of the hashrate and its stability and its share acceptibility and correctness with the pools is all im after ... the way to maximize coin income - is through hashrate optimization and accepted shares ... if power efficiency was a factor in the speed calculations and results - then we would never be able to have fully optimized algos ... yes - algos CAN be power efficient and have 'higher' hashrates than 'standard' released algos - but not at maximum optimization ... and IF algos can get the same hasrates at a lower power usage - then why not ... but thats not what teh whole issue is here ... its raw hasrates - regardless of power ... its like saying that feul efficiency IS the factor in high octane drag races ... its not - its the time it takes to get from one point to another - and the fastest wins ... period ... they dont care how much feul or noise or rubber is used or destroyed in the process ... same here ... to hell with efficiency - i want max hashrates ( and we are talking stable and accepted shares ) to maximize the coinage ... #crysx |
|
|
|
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. its from the main git pallas ... go to the git and see ... ive changed nothing from the clone i did before it - which did compile ... git pull showed there were updates - so i cloned again and compiled and had these errors ... #crysx read my post just over yours. git compiles fine, I even fixed it. in the current git now? ... if so - ill clone again now and recompile ... #crysx |
|
|
|
yeah its good to go. starting to work on the getdifficulty rpc command for each algo. not finished, but the commits that are new do work. try git pull and make clean. our README page on the source code, includes a build pass/fail tag. it is built automatically after each commit/pull request to make sure it doesn't break. this link will let you know if our current build in the master branch works or not, as the build process is logged from start to finish, and available to see =] https://travis-ci.org/vergecurrency/VERGEill be speaking with pool admins over the next day or two to see how mining is going on their end, see if they have anything they'd like to see tweaked etc, and setting up an x17/blake2s pool, with 2% fee that goes to development ;p ps: cryptsy is not in control of their funds anymore, they tried to send coins to bittrex and they were halted and sent to a management company, so i dont think we need to worry about a massive dump from cryptsy, plus ALOT of our users (and other users) got xvg out of there before they closed. i dont think they had very many when they closed. this is where im getting the clone from and still the same output after compile - https://github.com/vergecurrency/VERGE ... ill have another go at it - but im getting weary of it :| ... #crysx |
|
|
|
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. its from the main git pallas ... go to the git and see ... ive changed nothing from the clone i did before it - which did compile ... git pull showed there were updates - so i cloned again and compiled and had these errors ... #crysx |
|
|
|
Hi.
I'm trying to start mine again and it's been at least year since last time.
I got gtx 970 and water block on the way and the question is: what should i consider to mine and where i can find best cudaminer to do the job.
Thanks.
ps. i know it might not be profitable...
and sorry if this is the wrong thread to ask such things.
this is the right place, this versio can mine everything, it just missed something in the documentation, like lyra2v2, 1 970 is good if pointed at ethereum right now, try dwarf pool it sounds like you are saying that the ccminer-tpruvot can mine eth ... it cant ... depending on your setup and os and what it is you want to mine - that should determine what miner you require ... ccminer-tpruvot ( this miner ) has the widest range of algorithms that can be used with some of the algos optimized by alexis78 ( amongst others ) which is great to mine ( like blake2s ) ... ccminer-spmod ( the 'other' miner ) has some of the most optimized algorithms compared to this miner ... some algos are better optimized in that miner - some better here - some better in ccminer-alexis78 ( until epsylon3 merges the kernels into his miner - if he does it at all ) ... ccminer-alexis78 has some of the algos highly optimized for THOSE specific algos ( decred / blake2s / lyra2rev2 ) ... so you need to make a choice as to what you would like to mine - and which miner you would mine with for the algo you wish to mine with ... eth is a completely different story altogether - and NONE of these miners mine ethereum ... you need a specialized miner for that ... you also need to decide whether you are going to compile yourself - or use the compiled miners ... hope this helps some more - and doesnt confuse you ... #crysx yes ethminer is different, but that version is running only eth and its clone, i'm curious about allexis version, i can't find it in this section where it is? fpr the sp version i'm a bit sceptical about the optimization, the improvements aren't as good as he claim it to be ethminer gave me a MAJOR headache trying to compile - so i gave up after three attempts with issues on fedroa 23 x64 ... i havent mined one eth ... decred was my thing - and now im back to different algos ( currently with one gb 750ti oc lp card that in my opwn system under fedora 23 x64 and lower intensity than i normally mine ... dont want to lock up my workstation ) ... alexis78 - the miner is in his git with his optimizations here - https://github.com/alexis78/ccminer/ ... its the earlier fork of tpruvots version with alexis78 optimizations - so its reasonably easy to compile ... all you have to do is clone and compile and run ... test between the versions ... sp hasnt sent me the latest of his miner yet - so i cannot test that against anything - which is the main reason i cant give any figures or results of MY tests ... but as with any of these sorts of tests - they will always conflict with results as different people use different miners with different settings with different operating systems ... i have tested both alexis and sp miners ( though only against the earlier versions of the sp miner - decred only as i havent tested vanilla at all ... yet ) and the results vary between versions also ... so i cant really comment much more until i get the latest sp miner and do a thorough test ... apart from that - i need to get my test miner running - and my friend is loaning me his beast that i built him for a few weeks - so that will show where we are at with the 980ti g1 and extreme cards on my environment ... when i get my miners back up and running - ill be able to do better testing ... although i will be selling off the majority if the gb 750ti oc lp cards - so testing for that will become obsolete for me in the next few weeks ... ill only have the gb 980ti extreme cards left ... #crysx |
|
|
|
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 |
|
|
|
Hi.
I'm trying to start mine again and it's been at least year since last time.
I got gtx 970 and water block on the way and the question is: what should i consider to mine and where i can find best cudaminer to do the job.
Thanks.
ps. i know it might not be profitable...
and sorry if this is the wrong thread to ask such things.
this is the right place, this versio can mine everything, it just missed something in the documentation, like lyra2v2, 1 970 is good if pointed at ethereum right now, try dwarf pool it sounds like you are saying that the ccminer-tpruvot can mine eth ... it cant ... depending on your setup and os and what it is you want to mine - that should determine what miner you require ... ccminer-tpruvot ( this miner ) has the widest range of algorithms that can be used with some of the algos optimized by alexis78 ( amongst others ) which is great to mine ( like blake2s ) ... ccminer-spmod ( the 'other' miner ) has some of the most optimized algorithms compared to this miner ... some algos are better optimized in that miner - some better here - some better in ccminer-alexis78 ( until epsylon3 merges the kernels into his miner - if he does it at all ) ... ccminer-alexis78 has some of the algos highly optimized for THOSE specific algos ( decred / blake2s / lyra2rev2 ) ... so you need to make a choice as to what you would like to mine - and which miner you would mine with for the algo you wish to mine with ... eth is a completely different story altogether - and NONE of these miners mine ethereum ... you need a specialized miner for that ... you also need to decide whether you are going to compile yourself - or use the compiled miners ... hope this helps some more - and doesnt confuse you ... #crysx |
|
|
|
If it is possible to update all the wallets, in my humble opinion, I would suggest a 10,000 block session in the future, where block reward is temporarily increased from 1 TX to 10 TX.
We could get the thread busy, with Developers coming back, if we are allowed to vote for this temporary phase in the future.
This bonus 10k block period will force members to stake, sell and buy Transfer coin. It will also create awareness and attract more members.
Of course, we have to allow the community to vote on this, and we need to give members at least 2 weeks advance notice before the BONUS BLOCKS begin.
Actually I like that idea.. high stake period would be awesome.. TX is an exceptionally under valued coin considering it's superior tech I sent out a tweet to get some feedback, as I usually have a good response rate. https://twitter.com/wigitgetit/status/719685224565592064Also If you use twitter help me spread the word. Below is a ling to the term #transfercoin that will bring up everything I have been tweeting lately. https://twitter.com/search?f=tweets&vertical=default&q=%23transfercoin&src=typdI have also hired some help on spreading the word on different forums and social media platforms. I appreciate any assistance I can get.  Thank You wigitgetit Lol a Trump fan our politcal circus in Australia is bizzare but thankfully not as bad as the US, your elections seem to run for years. Keeps everyone distracted I suppose. If a bonus block period was to come in people would need heaps of notice. like a good month or so run in to it. TX takes a long while to mature. and I was staking 60-70 times a day and the with new wallet decided to resend it to myself to get all coins in one block, That was 3 days ago and still now only getting 5 stakes a day.. The longer the run in time the more we could get out and spruke it as well. I would happily troll Yobit for a month If it is to hard to do with hard forking and so on required I am sure there are other ways to bring attention to the coin, I dont mind a quite time for next few months, I'm still 25k off my target, These prices are good to buy a few more every week Wbb got away on me 8k short of my target. still bites me... its all a matter of timing thoth ... if there is going to be any major changes to anything in the code - there doesnt need to be a huge amount of noise made about it ... the noise just needs to be made about the results of those changes ... as for wbb - well you saw that ages ago - and even introduced me to it ... so patience and a little luck ... ... #crysx |
|
|
|
Btw guys please stake your wallets , the observed that the network is on a standstill , I m testing a new client and waiting to see the network stabalize.
Warm Regards,
~SoopY~
How's the network looking? My network is good, but I don't know about others. Well hopefully we will get more to chime in. Cheers! -Raven is the op uptodate? ... or do i need to look elsewhere to find the git / wallets / current code? ... tanx ... #crysx Crysx, As far as I am concerned the OPs are current. 2.0.3 version with checkpoints. Also bootstrap available. Cheers! -Raven tanx mate ... i will start looking into it tomorrow ... very late now - and sleepy ... #crysx Things are OK on my end, network-wise. OP is up to date. kool ... ill have a go with the compile of oc in its current state - and will see if i can get it all running well under fedora 23 x64 ... got to get a few other things out the way first ... #crysx I don't know how much help I can be, never used fedora. I wish you smooth compiling, crysx. all good ... compiled and running mate ... though it has a christmas santa hat on for the logo - im guessing its still the latest wallet as it seems to be syncing without any real issue ... as for the speaking up bit ... i wouldnt work on a coin that i could NOT control the outcome of ... especially a coin that i could not have a nice stake in also ... a premined coin that has most of the coins sitting in the major stakeholders wallets is of no use - especially if the future development of the coin means only a small portion of those wallets is used for development ( ie - getting paid for the work ) ... the work that soopy ( core dev ) and i ( infrastructure and backend and some coding ) set aside and finalized on droidz ( always with the advice and guidance of greedyjohn ) was more of a 'damage control' situation than it was a development one - simply due to the multiple fingers that were in the 'droidz pie' that had ultimate control over what went on ... which also led to the hell that broke loose when those in control took ( ie - stole ) from the community coffers ( NOT greedyjohn soopy or i ) more than a million of those coins to dump for a few btc ... this is what happens when devs that are not 'known' and 'others' that are not reliable take control over a coin - which has a community that is desparate to get the network and coin back on its feet ... i for one ( and i dare you greedyjohn to deny this ) was ALWAYS against the lack of communication that happened in the background ... which eventually led to this pitiful grab at a few btc by those involved ... i asked soopy to help in that situation and soopy came in - had a look - and we both went to work on fixing the issues ... now droidz is stable and is situated for future plans ... but still with the ironic stigma that 3 threads later and three devs later - that it cant seem to shake off ... as greedyjohn knows - as well as soopy - i prefer to work with conviction and full focus on the goal - and that cannot happen when too many fingers are and project ... unless there is structure and management of time and processes and people is in order - there canot be stability within the coalition of the TEAM ... there needs to be a lead - and the dev is not always the person to lead ... soopy has disappeared once again - he was slated to work with me on granite ( and subsequently the sister coin - ozc ozziecoin ) as these projects have been on hold for more than 6MONTHS now due to the droidz fiasco and the othe issues that have risen ... why am i mentioning all this to you? ... easy answer ... there is a simple reason why crypto in general have only a very few select coins / projects that are successful in any way shape or form ... they have structure - development TEAM - and leadership ... apart from a future vision ( as most projects should have ) - these three things are a REQUIREMENT for the success of any project ... so community involvement is important - but the crucial part is the structured TEAM ( notice this word ) that will bring forth the development ... TEAM - the word that a lot of communities and devs and investors DO NOT seem to understand ... i may be on a newbie profile currently - and that is a whole other story altogether as i cant post from my chrysophylax account any longer ( and still have had no response from the people at bct for weeks now ) - but i am far from being a newbie in the crypto field or the business / enterprise field ( in real life ) ... the points i have made above WILL be the seeds that make the success of the projects ... the rest is the hard and dedicated work that will follow by the TEAM that works on the project ... #crysx |
|
|
|
If it is possible to update all the wallets, in my humble opinion, I would suggest a 10,000 block session in the future, where block reward is temporarily increased from 1 TX to 10 TX.
We could get the thread busy, with Developers coming back, if we are allowed to vote for this temporary phase in the future.
This bonus 10k block period will force members to stake, sell and buy Transfer coin. It will also create awareness and attract more members.
Of course, we have to allow the community to vote on this, and we need to give members at least 2 weeks advance notice before the BONUS BLOCKS begin.
Actually I like that idea.. high stake period would be awesome.. TX is an exceptionally under valued coin considering it's superior tech bonus bloacks huh? ... sounds quite familiar ... o yes - granite has 10 of those bonus blocks built in from the start ... thats right ... ... hence the great idea - i suppose ... though you may find that a hardfork will be required for it ... @greedyjohn - heard from soopy lately? ... or has he done the disappearing act again? ... #crysx |
|
|
|
|
Show Posts
