Hm, indeed.
doublec, I wonder why it compiles allright on my ubuntu when I go the autogen route... somewhat weird.
|
|
|
make make all-recursive make[1]: Entering directory `/Tenebrix-miner' Making all in compat make[2]: Entering directory `/Tenebrix-miner/compat' make[3]: Entering directory `/Tenebrix-miner/compat' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/Tenebrix-miner/compat' make[2]: Leaving directory `/Tenebrix-miner/compat' make[2]: Entering directory `/Tenebrix-miner' gcc -DHAVE_CONFIG_H -I. -pthread -fno-strict-aliasing -g -O2 -MT minerd-cpu-miner.o -MD -MP -MF .deps/minerd-cpu-miner.Tpo -c -o minerd-cpu-miner.o `test -f 'cpu-miner.c' || echo './'`cpu-miner.c cpu-miner.c: In function ‘parse_arg’: cpu-miner.c:786: warning: passing argument 2 of ‘json_load_file’ makes integer from pointer without a cast /usr/include/jansson.h:221: note: expected ‘size_t’ but argument is of type ‘struct json_error_t *’ cpu-miner.c:786: error: too few arguments to function ‘json_load_file’ make[2]: *** [minerd-cpu-miner.o] Error 1 make[2]: Leaving directory `/Tenebrix-miner' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/Tenebrix-miner' make: *** [all] Error 2 Any ideas whats wrong here? I vaguely suspect jansson is to blame. What's dependency versions and what are you building it on (and for) ? I've built it for windows from under Fedora 15 (Eh, I know) vm and under ubuntu for, well, ubuntu. in Gentoo for Gentoo dev-libs/jansson Installed versions: 2.0.1 and works fine with other *coin miners/apps Did you try going autogen.sh route as described in readme ( needs automake and autoconf)?
|
|
|
"tPKbCkqgio92KVJj4cQAXqs7Ng4dfbhFxR","-765.00" "tFCq32aZFqa13wrab6m55Nv3R53tk4zkL8","-765.00" "tVEFkyC8VkXyMfpCyeM78k2nBC6nYUHKS4","-765.00" "t9ArZXPEa4hiPY22WXDyLu8LW34b13zVMB","-765.00" "tUK2EQTMF6cN6vuNEfJtVf1BMqarvEZJBL","-765.00" Sent. Also, other people who posted their addresses before this message will recieve a sum too, a smaller one tho
|
|
|
No, plain English for Yet Another Useless Piece of Shit Currency...
Still trying to decide what's worse, if you and Artforz losing your time to do this or all this morons mining it lol
With all due respect to your opinion, I believe that in a world where i0coin is being actually sold (or perhaps it would be better to say actually bought ) it is most unfair to call a cryptocurrency with novel PoW that significantly changes adoption dynamics "Useless Piece of Shit" :-P OK I got it working with : ./minerd --user 1 --pass 1 --url http://127.0.0.1:8697But I'm not sure if I'm getting the right hash rate... ./minerd --user 1 --pass 1 --url http://127.0.0.1:8697[2011-09-26 18:30:19] Binding thread 0 to cpu 0 [2011-09-26 18:30:20] Binding thread 1 to cpu 1 [2011-09-26 18:30:21] Binding thread 2 to cpu 2 [2011-09-26 18:30:22] Binding thread 3 to cpu 3 [2011-09-26 18:30:23] 4 miner threads started, using SHA256 'scrypt' algorithm. [2011-09-26 18:31:00] thread 1: 65535 hashes, 1.66 khash/sec [2011-09-26 18:31:01] thread 2: 65535 hashes, 1.65 khash/sec [2011-09-26 18:31:02] thread 0: 65535 hashes, 1.53 khash/sec [2011-09-26 18:31:04] thread 1: 8191 hashes, 1.66 khash/sec [2011-09-26 18:31:06] thread 2: 8191 hashes, 1.66 khash/sec Looks a little slow although I must admit I don't usually CPU mine what are you guys getting? Typical hashrates for TBX. Do mind that most GPU implementations will be notably slower with modern GPUs.
|
|
|
Is anyone else getting a lot of false proof of works? around 80% of my proof of works turn out like the one below.
[2011-09-26 17:50:30] PROOF OF WORK RESULT: false (booooo)
Try setting -s in your miner to 5
|
|
|
make make all-recursive make[1]: Entering directory `/Tenebrix-miner' Making all in compat make[2]: Entering directory `/Tenebrix-miner/compat' make[3]: Entering directory `/Tenebrix-miner/compat' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/Tenebrix-miner/compat' make[2]: Leaving directory `/Tenebrix-miner/compat' make[2]: Entering directory `/Tenebrix-miner' gcc -DHAVE_CONFIG_H -I. -pthread -fno-strict-aliasing -g -O2 -MT minerd-cpu-miner.o -MD -MP -MF .deps/minerd-cpu-miner.Tpo -c -o minerd-cpu-miner.o `test -f 'cpu-miner.c' || echo './'`cpu-miner.c cpu-miner.c: In function ‘parse_arg’: cpu-miner.c:786: warning: passing argument 2 of ‘json_load_file’ makes integer from pointer without a cast /usr/include/jansson.h:221: note: expected ‘size_t’ but argument is of type ‘struct json_error_t *’ cpu-miner.c:786: error: too few arguments to function ‘json_load_file’ make[2]: *** [minerd-cpu-miner.o] Error 1 make[2]: Leaving directory `/Tenebrix-miner' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/Tenebrix-miner' make: *** [all] Error 2 Any ideas whats wrong here? I vaguely suspect jansson is to blame. What's dependency versions and what are you building it on (and for) ? I've built it for windows from under Fedora 15 (Eh, I know) vm and under ubuntu for, well, ubuntu. You need automake and autoconf before you can use the .sh script How do I build that modified miner of yours?
I tried git cloning it then tried:
./autogen.sh ./autogen.sh: 8: aclocal: not found
Do you have automake/autoconf ? The .sh is intended for use with them and kinda-sortish favors Fedora, but should work oke on ubuntu I just installed automake chris@galaxy:~/Tenebrix-miner$ automake configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal). compat/Makefile.am:2: WANT_JANSSON does not appear in AM_CONDITIONAL /usr/share/automake-1.11/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL /usr/share/automake-1.11/am/depend2.am: The usual way to define `am__fastdepCC' is to add `AC_PROG_CC' /usr/share/automake-1.11/am/depend2.am: to `configure.ac' and run `aclocal' and `autoconf' again. /usr/share/automake-1.11/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.11/am/depend2.am: The usual way to define `AMDEP' is to add one of the compiler tests /usr/share/automake-1.11/am/depend2.am: AC_PROG_CC, AC_PROG_CXX, AC_PROG_CXX, AC_PROG_OBJC, /usr/share/automake-1.11/am/depend2.am: AM_PROG_AS, AM_PROG_GCJ, AM_PROG_UPC /usr/share/automake-1.11/am/depend2.am: to `configure.ac' and run `aclocal' and `autoconf' again. Makefile.am:2: WANT_JANSSON does not appear in AM_CONDITIONAL Makefile.am:24: HAVE_x86_64 does not appear in AM_CONDITIONAL Makefile.am:25: HAS_YASM does not appear in AM_CONDITIONAL configure.ac:7: required file `cpuminer-config.h.in' not found Makefile.am:16: compiling `cpu-miner.c' with per-target flags requires `AM_PROG_CC_C_O' in `configure.ac'
If you have both automake and autoconf, start the autogen.sh, and follow the readme step-by-step from there (assuming autogen.sh doesn't blow up again) YAUPOSC French ?
|
|
|
Actually, it's doing quite fine, thanks for asking. A major update and an interesting development is on its way. Given that both are essentially community projects, and given that they have vastly different goals and niches, Tenebrix shall in no way subtract from Geist Geld. LOL ok. I look forward to some new constants you change and package as a new coin. How many premined coins are in Tenebrix btw? 10 million? Why, 2 bilionteen coinsez (warning - a joke ) But then again, Tenebrix doesn't expect miners to pay "protection" taxes, which affects budgetary policy a lot
|
|
|
How do I build that modified miner of yours?
I tried git cloning it then tried:
./autogen.sh ./autogen.sh: 8: aclocal: not found
Do you have automake/autoconf ? The .sh is intended for use with them and kinda-sortish favors Fedora, but should work oke on ubuntu
|
|
|
do mind that Linux users are advised to change daemon=1 to daemon=0, as d=1 makes some distros unhappy and kills the Tenebrix
|
|
|
[ Indeed, it's what I do, get things moving. A question about your previous coin geist geld, is that given up on now? I thought you just made a new website for it and all? What sort of support can we expect going forward for your new coin?
Actually, it's doing quite fine, thanks for asking. A major update and an interesting development is on its way. Given that both are essentially community projects, and given that they have vastly different goals and niches, Tenebrix shall in no way subtract from Geist Geld.
|
|
|
OK I got it compiled with qmake and make then I tried:
chris@galaxy:~/Tenebrix$ ./bitcoin-qt bitcoin-qt: src/main.cpp:1754: bool LoadBlockIndex(bool): Assertion `block.hashMerkleRoot == uint256("0x4e77ffdc1baa20ffffab9d901f418f7496b2a710e462ac4047accdb8b3b774f9")' failed. Aborted
Now I know you are misplacing the config Either put it into %home%/.tenebrix or put it anywhere you like and use -datadir Also, Linux users are advised to change daemon=1 to daemon=0, as d=1 makes it unhappy.
|
|
|
Ok, I have to ask, since you didn't say anyhting about it in the OP, can you give more detail about this currency?
Block size, block frequency, total number, simmilarities/differences to bitcoin, etc, etc, etc?
Boy oh boy I forgot, sorry. Will amend. 1 block per 5 minutes, retargets every week, accept window cut down to 1 hour (half bitcoin's value), Zeitgeist exploit patched. No upper limit on mining, not unlike Geist
|
|
|
Send some coins to '1DrPLgBFdrkSDCe7yx4S57SiRb9gPDQVmy' for test and I'll send 1/2 of it back to you.
Checking whether you can recover from "accidents" with pywallet or whether there is "accident protection" at all ?
|
|
|
I've gotten 10 stale blocks out of 11 so far. Is it possible that the blockrate is fairly fast and I am connected to some slow nodes?
Target blockrate is 1 in 5 minutes, so it's hardly "ZOMGFAST" like Geist. Current blockrate seems already quite above that tho. It is not entirely impossible that you are indeed connected to some slow nodes, try opening up incoming so that you get better connectivity. However, I think your miner might need some tweaks to better fit your hardware (default settings in the bat were established trial-and-error on an i7), minerd --help might help.
|
|
|
Um - I think you missed reality with your statement about bot nets trying to be covert. They CPU mine - and they take away LOTS of cycles from the machines they have infected. It's only in the rare case where the machine has an appropriate GPU that they even could be covert.
Well, natural selection will sort this one out. CPU mining too aggressively (or even GPU mining when the user is doing GPU-intensive stuff) is morel likely to get user's attention, and usually that's gameover because as soon as user finds he is infected (esp. with something that interferes with normal day-to-day use) he will eventually get rid of the bug. Give it some time. Someone who lucratively mines coins on other person's rig has obvious incentives 1) not to have the activity noticed (thus not to interfere with normal performance too much) and 2) not to get the box / it's owner into "hot water" (that would mean lost resource) unless doing so is vastly more lucrative. "Minerfections" have significant likelihood of naturally ameliorating as they become more sophisticated (much like real infections by the way)
|
|
|
GG update soon(ish). Stay tuned
|
|
|
Well, you're flattering me by calling it a Lolcust currency. It verily much a joint / community effort, even at the conceptual level (Geist is mostly my brainchild in terms of concept, this one evolved organically from all the "how do we design a GPU-hostile PoW" discussion flowing around )
|
|
|
GG update soon(ish). Stay tuned
|
|
|
Well, all I can say is that I hereby officially testify that CPU-friendly/GPU-hostile miner design is possible
|
|
|
|