|
All the boost libs on my (Fedora 17) system seem to be 1.48
All other coins have all compiled fine.
Though actually, I almost never even try to compile the GUI since I usually run coins on headless servers.
So I suppose its theoretically possible there might by now be some other coins whose GUI wouldn't compile if I did try to compile it.
Presumably the daemon uses the same boost as the GUI, though?
Guess i should try to compile the daemon, see if that too is broken...
Oops, ouch, it doesn't even have the makefile.unix I usually modify to make my makefile.fedora17
Is this thing GUI only, no daemon?
The Makefile that is there talks about linking boost statically, why the heck would anyone want to do that? Isn't it a pointless waste of system resources?
Also it seems to be hard-coding USE_UPNP to 1 or 0 depending on whether you are compling the GUI or the daemon, won't that walk over the USE_UPNP= (empty) one uses on the commandline to make it compile at all (given that different coins use different versions of UPNP so half or more of them get syntax errors due to the different versions of UPNP having different numbers of args in certain calls, so basically unless you for some reason actually want UPNP enough to somehow install two different versions and differentiate among them at compile time its best to just always use UPNP= when making any of the coins)?
The daemon I have seems to work so I guess I will skip this "upgrade", maybe someday a fixed up version of it will come out.
Also if the goal is a useful client, then really useful would be warning you whether any of your domains are about to expire, and maybe even optionally automatically extending them or whatever one does to keep them from expiring. Since merely registering them easy won't be all that useful a year down the line when someone else steals them out from under you just as easy.
-MarkM-
|
|
|
|
At what point will discovery of bad chips be done?
Will only good chips be going onto K16 boards?
Or will we only find out if chips are bad once we get our K16 boards?
Part of why i am wondering this is if possible I would like to have K16s made from any full sets of 16 good chips I have, and K1s of any odd chips left over after bad chips are weeded out.
-MarkM-
Bad chips will be discovered during the testing phase of the boards. Any boards discovered to have a faulty chip will be repaired with the replacement chips. There are a few options we are exploring regarding board testing, and a procedure to do so will be finalized prior to chip arrival. K1's will not be available for Batch 1, as our focus is on ensuring the K16 are produced, tested, and shipped as quickly as possible. This may change in subsequent batches as the process is streamlined and more resources are made available. Ouch I need full assembly then. I think my first two orders maybe didn't even include saying what i wanted done with the things but the last order I sent the form did include saying, and I foolishly put full kit not realising that would mean the chips could be bad. Is there a procedure for updating that? As now i obviously am going to want full assembly at least, and if that doesn't include chi-checking then i guess I would need to full assembly plus testing. -MarkM- |
|
|
|
|
That seems kind of a waste of everyone's time and effort.
If a coin is going to bother to upgrade at all it might as well upgrade to the latest.
if it would just end up still old code it might as well stick with the old code it already has, though maybe I0Coin and GeistGeld might profit by rebasing themselves on some old merged coin that at least doesn't crash daily doing pointless DNS lookup and doesn't have memory leaks.
Also it might not be hard at all, I don't know as I didn't get to looking at those rejected chunks yet, had too many other things I need to do.
-MarkM-
|
|
|
|
Also, it sounds to me like that Ixian guy wasn't successful, given the past tense. So it sounds like that may not be a viable strategy  I really am sorry that this coin isn't what you think it should be. But hey, the source is on github Well Ixcoin itself is doing very well because it is merged mined on a few pools so its difficulty is not too insanely low. But the big problem thie Ixian guy has of course is third parties printing "his civilisation's coin". I expect the Fed would have similar problems if every mint in the world could print dollars, not just their own mint. Basically if you try to back the coins being dumped by all the people mining them and dumping them you are liable to go broke. Or another way of looking at the same problem is that blockchains are insanely expensive, even if you use merged mining. 100% of the coins, plus transaction fees, all go to miners. That really doesn't leave any reason for any nation to consider using a blockchain, they don't even get any of "their" coins, they are paying over 100% of all their money to the miners! So yeah obviously the guy was not able to effectively "back" the coins. The most he could do was continue to sell in game stuff for them and offer to buy in game stuff for them. most blockchain coin users do not bother with that kind of thing so IXCoin, GRouPcoin and DeVCoin continue to be the only blockchain-based coins that get used much in the game, GRouPcoins by most groups, DeVCoins because the game development itself favours their use, and IXCoins because of that one guy, who does not even seem to have put together any reasonable size clan or guild or nation or whatever of Ixian people yet let alone actually established an Ixian nation on the Freeciv scale of play. -MarkM- |
|
|
|
Where is yacminer.c being generated then? i tried the --with-scrypt arg to configure in case that might cause configure to create that file but there is still no such file.
There is no yacminer.c; check cgminer.c echo " CCLD " yacminer;gcc -g -O2 -lpthread -o yacminer cgminer-cgminer.o cgminer-util.o cgminer-sha2.o cgminer-api.o cgminer-logging.o cgminer-driver-opencl.o cgminer-ocl.o cgminer-findnonce.o cgminer-adl.o -lcurl -ljansson -lpthread -lm lib/libgnu.a ccan/libccan.a -lncurses -lpthread Well I guess the autoconf stuff (./configure) must be broken then, i tried to make sure it had all the right parts for my system by doing autoreconf and that found errors: autoreconf -i -f
Makefile.am:40: variable `cgminer_SOURCES' is defined but no program or
Makefile.am:40: library has `cgminer' as canonical name (possible typo)
Makefile.am:26: variable `cgminer_LDADD' is defined but no program or
Makefile.am:26: library has `cgminer' as canonical name (possible typo)
Makefile.am:25: variable `cgminer_LDFLAGS' is defined but no program or
Makefile.am:25: library has `cgminer' as canonical name (possible typo)
The Makefile is what is asking for yacminer.c, maybe that has something to do with the broken configure stuff. -MarkM- |
|
|
|
I might be wrong but a coin that uses a similar scheme to what Yacoin or Onecoin uses. A locked N factor of 12 might work well. With an N factor of 12 it should be very hostile to GPU/ FPGA/ ASICs. http://yacexplorer.tk/graphs.htm#techBoth are already mined on gpus since day 3 of launch iirc..... Also it looks like they are designed to give massive numbers of coins to the early GPU users initially then maybe eventually lock out competing GPUs leaving those early GPU people with massive haords in case someday the things do actually become valuable. As GPUs advance 12 might not continue to block them out so maybe it would be better to start at 14 or more especially if going with a fixed forever value? Still in the long run wouldn't they just end up as botnet coins? And because they are mined with general purpose equipment, very hard to secure since it is hard to have more general purpose equipment than the rest of the world has? Even with scrypt it might be too hard to have more hashing power than the rest of the world has if FPGAs and ASICs cannot really do a whole lot better than GPUs, so the classic merged-mined SHA256 coins (including bitcoin) look better to me every day. -MarkM- |
|
|
|
|
This is why I0Coin crashes daily.
Maybe it also is why they went to the trouble of adding a memory leak, which really is not necessary normally when making an altcoin, yet I0Coin managed somehow to accomplish it.
-MarkM-
|
|
|
|
|
At what point will discovery of bad chips be done?
Will only good chips be going onto K16 boards?
Or will we only find out if chips are bad once we get our K16 boards?
Part of why i am wondering this is if possible I would like to have K16s made from any full sets of 16 good chips I have, and K1s of any odd chips left over after bad chips are weeded out.
-MarkM-
|
|
|
|
|
Do none of the recent scamcoins have the time travel fix?
Did litecoin leave it out like bitcoin did, thinking their hash rate is so huge it would never happen to them, and all the scamcoins didn't bother to put it in because they were too stupid to even check what fixes litecoin had not yet implemented oro so crazy they thought they would have litecoin's level of hashing right from the start?
-MarkM-
|
|
|
|
It doesn't want to compile: In file included from ../src/util.cpp:6:0:
/usr/include/boost/program_options/detail/config_file.hpp: In instantiation of ‘bool boost::program_options::detail::basic_config_file_iterator<charT>::getline(std::string&) [with charT = char; std::string = std::basic_string<char>]’:
../src/util.cpp:1103:1: required from here
/usr/include/boost/program_options/detail/config_file.hpp:163:13: error: ‘to_internal’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
In file included from /usr/include/boost/program_options/detail/parsers.hpp:9:0,
from /usr/include/boost/program_options/parsers.hpp:265,
from ../src/util.cpp:7:
/usr/include/boost/program_options/detail/convert.hpp:75:34: note: ‘template<class T> std::vector<std::basic_string<char> > boost::program_options::to_internal(const std::vector<T>&)’ declared here, later in the translation unit
../src/util.cpp:972:41: warning: ignoring return value of ‘size_t fwrite(const void*, size_t, size_t, FILE*)’, declared with attribute warn_unused_result [-Wunused-result]
In file included from ../src/script.h:8:0,
from ../src/main.h:10,
from ../src/headers.h:100,
from ../src/util.cpp:4:
../src/keystore.h: In member function ‘virtual bool CKeyStore::HaveKey(const std::vector<unsigned char>&) const’:
../src/keystore.h:60:5: warning: control reaches end of non-void function [-Wreturn-type]
make: *** [build/util.o] Error 1
I tried putting the -mt on the end of the boost library names like the makefile-unix for the daemon does but still get the above error. The makefile was created using qmake-qt4 since coin qt clients all seem to be made with qt4. Is this one maybe using some other qt? -MarkM- |
|
|
|
|
So there isn't really even a clan or guild or whatever of players backing this coin in games, like that Ixian guy who was pushing the idea of Ixians as a nation or race or whatever in Galactic Milieu using Ixcoins as their national currency?
-MarkM-
|
|
|
|
it does not compile, one of the main source code files is missing:
I can compile it. wget http://sourceforge.net/projects/hnindev/files/yaminer-beta-src-2.zip
unzip yaminer-beta-src-2.zip
cd yaminer-beta-src/
chmod +x configure
./configure --enable-scrypt && make
cat ADL_SDK/readme.txt
Where is yacminer.c being generated then? i tried the --with-scrypt arg to configure in case that might cause configure to create that file but there is still no such file. -MarkM- |
|
|
|
it does not compile, one of the main source code files is missing: make[2]: Leaving directory `/usr/src/bitcoin/yaminer-beta-src/ccan'
make[2]: Entering directory `/usr/src/bitcoin/yaminer-beta-src'
make[2]: *** No rule to make target `yacminer.c', needed by `yacminer.o'. Stop.
make[2]: Leaving directory `/usr/src/bitcoin/yaminer-beta-src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/bitcoin/yaminer-beta-src'
make: *** [all] Error 2
[root@megabox yaminer-beta-src]# ls
01-cgminer.rules api-example.c bench_block.h compat.h config.sub driver-avalon.h elist.h hexdump.c m4 ocl.c scrypt.h util.c
aclocal.m4 api-example.php bitforce-firmware-flash.c compile configure driver-bflsc.c example.conf install-sh Makefile ocl.h SCRYPT-README util.h
adl.c API.java bitstreams config.guess configure.ac driver-bitforce.c findnonce.c lib Makefile.am phatk121016.cl sha2.c warn-on-use.h
adl_functions.h API-README ccan config.h COPYING driver-icarus.c findnonce.h libztex.c Makefile.in poclbm130302.cl sha2.h windows-build.txt
adl.h arg-nonnull.h c++defs.h config.h.in depcomp driver-modminer.c FPGA-README libztex.h miner.h README stamp-h1
ADL_SDK ASIC-README cgminer.c config.h.in~ diablo130302.cl driver-opencl.c fpgautils.c linux-usb-cgminer miner.php scrypt130511.cl usbutils.c
api.c AUTHORS ChangeLog config.log diakgcn121016.cl driver-opencl.h fpgautils.h logging.c missing scrypt.c usbutils.h
API.class autom4te.cache compat config.status driver-avalon.c driver-ztex.c GPU-README logging.h NEWS scrypt-chacha.cl uthash.h
-MarkM- |
|
|
|
this is minerd not cgminer! its for scrypt and sha256d
Oh Thanks! In that case I can probably update it just fine then. -MarkM- |
|
|
|
Also NMC is a currency that makes sense just for DNS if you forgot that.
Not just for DNS. it is also one of the methods you can use for a top level identity behind Open Transactions nyms, so you can change nyms, retire nyms and so on while still having a secure basis of identity behind them all showing they are all controlled by the same namecoin address. -MarkM- |
|
|
|
|
I tried git pull on the cgminer-git i am using and saw it was from ckolivas not from pooler.
It also said I am not on a branch abd need to choose a branch.
So now I have to wonder what if any relationship exists between what i was using and this one?
Is this one only for scrypt, maybe? Or does it include all the latest stuff for all the sha256 FPGAs and ASICs and such?
If it doesn't contain the latest stuff I was already using, will it walk over my existing binary or use a new name for its executable so I can continue to use my existing cgminer for what it is already doing and use this one for scrypt?
Or does this one basically obsolete the ckolivas one, containing all its stuff plus this new upgrade for scrypt?
come to that, does it also support the weird new variant scrypts or have the people pushing those not actually made pulls available yet to get their new variants into the mainline code?
(I have been unable to use any of their stuff yet because they seem to plan to walk all over my existing install instead of beign a new separate package.)
-MarkM-
|
|
|
|
|
Well yeah that is the whole problem with blockchains, they are insanely expensive to secure.
Even with merged mining it isn't easy, without merged mining the total hashing power available gets divided too thin (so they are all jokes) or the vast majority of scamcoins are just jokes, playthings for anyone to attack at will, because only one or maybe two have enough hashpower to temporarily resist attack (until some profitability site claims some other coin is more profitable so the miners leave it to be attacked while they follow the myth of higher profits, a myth that is probably already out of date by the time they see it on a website).
-MarkM-
|
|
|
|
|
There will be plenty of K1 USB mining sticks coming, hopefully cheaper than ASICminer's huge prices.
I just wonder how people figure they will *never* break even, since they might be able to earn more than the electricity to run them costs for many years.
-MarkM-
|
|
|
|
|
So still no local signing then and no rippled source code. So you basically need a throwaway ripple account for this that will never be used with anything real.
I take it that signing is a pretty hard thing to implement eh?
-MarkM-
|
|
|
|
|
Okay so again what is the problem? People speculated on litecoins, litecoins paid off, some won, some lost, so what?
I thought I got a great deal on a couple of dedicated servers, I loved the deal.
Yesterday I thought about buying another or a couple more and holy moly the new regular price is way the heck cheaper than the special cheap deal price I had paid a few months ago!
I will ask them about not charging me next year the same rate I paid on the special, instead getting the new rate.
But prices change, thats life.
One approach could be don't think about the price as in litecoins, think about it in acres or in cubes of raw game-materials or something.
They didn't have to think of what they spent on the land as litecoins, afterall they could have used fiat to buy litecoins to buy land. So the fact that litecoins went up would be irrelevant, the land cost them so many dollars, and if they can sell it for that many dollars or more they are in profit.
The fact that land didn't turn out to be as explosive an investment as litecoins is just tough, they should have bought and held litecoins instead of buying and holding land. Hopefully they held some of both, and can still profit from the land if they can sell it for more dollars, or more cubes of in game raw resources, or whatever, than they paid for it.
Bitcoins had similar problems, there have been very few things, at some point in time, that would give you more income by holding them than you would get by holding bitcoins.
-MarkM-
|
|
|
|
|
Show Posts
