what happens to the X11/X13 markets ? mining with my 8x7950 just make the electricity back in dollars  Is GPU mining rally dead ? unless you pay 0.1 or less per KW/H, it's been dead for a while now. |
|
|
|
New clean block chain is available at ftp://diamond.danbo.bg/dmdchain20140701.zip It is almost twice less in size than the previous one provided, which was bloated with more than one copy of the same block. As discussed earlier, it was created by connecting to a known good node (one running current software) ONLY, disabling IRC learning of peers, incoming connections and removing peers.dat. Anyone can create such a distilled blockchain -- we do this all the time to test the new client functions normally, this one is provided just for your convenience. Small note. The directory unpacks as a hidden folder on MAC. Yes... it unpacks as the .Diamond folder, which is the appropriate name under all UNIX (except OS X). It is hidden in OS X and Windows, because of the dot. Maybe, a better idea is to unpack as Diamond folder, which would work in both OS X and Windows. What do you think? The primary reason I did not do it that was is that on my development computers, Diamond is the directory where the git sources come. I could have inadvertently created a mess. But maybe good idea to change it, as for other OSes it's inconvenience. By the way, HTTP download links are here: Diamond Block chain http://diamond.danbo.bg/downloads/dmdchain20140701.zipDiamond Windows Wallet http://diamond.danbo.bg/downloads/diamond-qt-2.0.2.2.exeDiamond OS X Wallet http://diamond.danbo.bg/downloads/diamond-qt-2.0.2.2.dmgwell, actually it is hidden on unix/linux as well (if you don't specify "-a" to ls). I think the best way is to unpack to a directory named "dmd blockchain" which contains a README file which explains how to use it, depending on the OS you have. |
|
|
|
I occasionally experienced a similar problem: stratum is always working fine, but the web site times out. When that happens, wait some minutes and it's back. Looks like some kind of dns problem, danbi are you using some dynaminc dns service on the website? |
|
|
|
Code is already on github, but I forgot my portable build environment, so it will have to wait for the evening (EU time).
Can I already compile the headless wallet or should I wait? |
|
|
|
I have 3 "generate" transactions in my wallet, two negative and one positive, whose sum is exactly zero.
What does it means?
Got it. The pos reward is in the fees. They go into the default account. |
|
|
|
|
I have 3 "generate" transactions in my wallet, two negative and one positive, whose sum is exactly zero.
What does it means?
|
|
|
|
This is a known corruption of the block index database, for which we have not yet found a solution. The easiest way to fix it is to load the blocks from the block chain you already have, effectively rebuilding the index. You can do this by removing blkindex.dat first and then running
diamondd -loadblock=blk0001.dat
This will go like downloading the block chain from the network, only much faster and will result in clean block index.
For some reason, on my qnap, using this method is slower than redownloading the blockchain from scratch: after a night of indexing, it is still at block 95000. Now I'll restart with the blockchain from the OP and reconpile with the suggested flags, and report back. -fsanitize is not supported by the compiler. the other two flags are accepted but produce a binary which just segfaults when started. gcc -v: Target: arm-none-linux-gnueabi Configured with: ../gcc-4.2/configure --build=i386-pc-linux-gnu --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi --prefix=/opt --disable-nls --disable-static --with-as=/home/slug/optware/cs08q1armel/toolchain/arm-2008q1/bin/arm-none-linux-gnueabi-as --with-ld=/home/slug/optware/cs08q1armel/toolchain/arm-2008q1/bin/arm-none-linux-gnueabi-ld --enable-languages=c,c++ --disable-multilib --enable-threads --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --enable-shared --enable-symvers=gnu --enable-__cxa_atexit Thread model: posix gcc version 4.2.3 |
|
|
|
This is a known corruption of the block index database, for which we have not yet found a solution. The easiest way to fix it is to load the blocks from the block chain you already have, effectively rebuilding the index. You can do this by removing blkindex.dat first and then running
diamondd -loadblock=blk0001.dat
This will go like downloading the block chain from the network, only much faster and will result in clean block index.
For some reason, on my qnap, using this method is slower than redownloading the blockchain from scratch: after a night of indexing, it is still at block 95000. Now I'll restart with the blockchain from the OP and reconpile with the suggested flags, and report back. |
|
|
|
The full error message:
diamondd: kernel.cpp:412: unsigned int GetStakeModifierChecksum(const CBlockIndex*): Assertion `pindex->pprev || pindex->GetBlockHash() == (!fTestNet ? hashGenesisBlock : hashGenesisBlockTestNet)' failed.
Happened again today when I stopped and restarted the wallet daemon.
One idea how to fix it: since it happens more frequently with your installation (perhaps because it's slower to stop), could you please try adding this to CFLAGS: -fsanitize=thread -pie -fPIC This, after recreating blkindex.dat (and saving a copy of the whole dir just in case)  My theory here is that threads are destroyed asynchronously and the locking thread exits before the block index writer actually exists. A dirty fix, but might work. Note, might not work on older gcc versions. Hope, we will know more from this tool. I will try this tomorrow, thanks. "restart too early" can't be the cause in my case, because the wallet has been stopped for about one hour. Meanwhile it's slowly syncing, it will probably need at least the whole night. Developing on such a slow device can be painful :-) |
|
|
|
|
The full error message:
diamondd: kernel.cpp:412: unsigned int GetStakeModifierChecksum(const CBlockIndex*): Assertion `pindex->pprev || pindex->GetBlockHash() == (!fTestNet ? hashGenesisBlock : hashGenesisBlockTestNet)' failed.
Happened again today when I stopped and restarted the wallet daemon.
|
|
|
|
|
danbi, will the changes needed to compile on arm be included in the official git?
just wanted to know if they must be included in a "compile on arm" document (or "use the latest source with arm support" instead).
|
|
|
|
|
srcxxx, may I suggest you remove the thread concurrency (and lookup gap, and vectors...) from the filename, so the files are ok for everyone, regardless?
I did this myself in sph-sgminer in the past, it's much convenient. The only downside is it's not compatible with scrypt.
I can provide details if you wish.
|
|
|
|
About the need to re-download block chain, could you send me the complete error so that we investigate why it is happening. You should also verify that your wallet is functioning properly by downloading the complete block chain from scratch. This is the ultimate test.
Can you prepare two text documents for inclusion in the Diamond code? Such as how to build on ARM and how to build on QNAP. Add your copyright there, and make sure it's compatible with the general Diamond copyright.
About the blockchain problem: I built the 2.0.1 client before and downloaded the whole blockchain with it, then compiled the new client which failed on catching up (unfortunately I haven't kept the full error message, only the start, which is shown in the "guide"). This error might be only for those who had the old wallet (so myself only). Than I got the blockchain from the OP and it synced fine (even if I had to restart the wallet because it initially got stuck at around block 38000). If you think it's useful, I will redownload the whole blockchain with the latest client, only problem is that it takes more than a whole day, making the NAS very slow! About the two documents, I'll soon be on vacancy so it'll not be right now, but I'll do ASAP. And thanks to popshot for the donation, really appreciated! |
|
|
|
|
BUILDING THE HEADLESS WALLET ON A QNAP ARM NAS
----------------------------------------------
CHANGES TO THE WALLET SOURCES:
- mkdir src/obj
- makefile.unix sets -msse2 flag that obviously doesn't work for arm
- makefile.unix: missing scrypt-arm.S (I got it from hobonickels github: download and put into src/)
@@ -135,7 +135,8 @@ OBJS= \
obj/pbkdf2.o \
obj/scrypt_mine.o \
obj/scrypt-x86.o \
- obj/scrypt-x86_64.o
+ obj/scrypt-x86_64.o \
+ obj/scrypt-arm.o
all: diamondd
@@ -158,6 +159,9 @@ obj/scrypt-x86.o: scrypt-x86.S
obj/scrypt-x86_64.o: scrypt-x86_64.S
$(CXX) -c $(xCXXFLAGS) -MMD -o $@ $<
+obj/scrypt-arm.o: scrypt-arm.S
+ $(CXX) -c $(xCXXFLAGS) -MMD -o $@ $<
+
obj/%.o: %.cpp
$(CXX) -c $(xCXXFLAGS) -MMD -MF $(@:%.o=%.d) -o $@ $<
@cp $(@:%.o=%.d) $(@:%.o=%.P); \
- scrypt_mine.cpp: need to "else" instead of "elseif" or arm wouldn't get the declarations:
index afca59d..4fa1426 100644
--- a/src/scrypt_mine.cpp
+++ b/src/scrypt_mine.cpp
@@ -54,7 +54,8 @@ extern "C" void scrypt_core(uint32_t *X, uint32_t *V);
extern "C" void scrypt_core_2way(uint32_t *X, uint32_t *Y, uint32_t *V);
extern "C" void scrypt_core_3way(uint32_t *X, uint32_t *Y, uint32_t *Z, uint32_t *V);
-#elif defined(__i386__)
+#else
- main.cpp: ambiguous call to random(), need to specify it's the boost version:
index 1e40a7e..3a513e1 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -947,8 +947,8 @@ uint256 WantedByOrphan(const CBlock* pblockOrphan)
int generateMTRandom(unsigned int s, int range)
{
- random::mt19937 gen(s);
- random::uniform_int_distribution<> dist(1, range);
+ boost::random::mt19937 gen(s);
+ boost::random::uniform_int_distribution<> dist(1, range);
return dist(gen);
}
QNAP NAS specific:
- first of all install "ipkg" from the application center, open a terminal and install the build environment (TODO provide "ipkg install" command)
- don't compile into admin's home, it's too small: use another user or move to another directory
- for the same reason, don't do "make install", or do it but changing the prefix to /opt instead of /usr/local
- compile your own berkeleydb 4.8, boost library and, if you need it, miniupnpc too (see their documentation and read doc/build-unix.txt of any bitcoin-derived wallet)
- consider it may take a while: on my nas the boost library took a whole night to fully compile
- make with: CXXFLAGS='-DHAVE_CXX_STDHEADERS' BDB_INCLUDE_PATH='~/BerkeleyDB.4.8/include' BDB_LIB_PATH='~/BerkeleyDB.4.8/lib' \
BOOST_INCLUDE_PATH='~/boost_1_55_0' BOOST_LIB_PATH='~/boost_1_55_0/stage/lib' make -f makefile.unix
- remember to run ldconfig on the two new lib paths and/or add to /etc/ld.so.conf
- because of some locale issue, "export LC_ALL=C" is needed before running the wallet
- strip debug info from the executable in order to save ram (we have little on a NAS): "strip diamondd"
- if you get "diamondd: kernel.cpp:412: unsigned int GetStakeModifierChecksum..." try downloading blockchain from OP.
Donations (DMD): dVrz69vZFrxJRH9AnKyHim7Hd3PhY3w9NQ
|
|
|
|
Excellent! Solo mining with 21 MHs and happily finding blocks (about 10 per day) Does anyone have the Diamond.cl kernel, I am running groestl.cl currently and would like to try --algo diamond. there is no difference between the two opencl kernels (groestlcoin.cl and diamond.cl) |
|
|
|
|
where is child_arnold? I miss his positive posts! ;-)
|
|
|
|
|
I think you should list the pools in the OP in ascending hashrate order, so new miners will more likely come to the smaller ones, resulting in a better hashrate distribution.
|
|
|
|
|
you can make an fpga for every algo.
this doesn't mean it's available to the public nor power efficient.
|
|
|
|
I've succesfully compiled the headless wallet on my QNAP NAS (arm processor).
It wasn't trivial, the wallet code assumes x86 in some places.
Devs let me know if you are interested in which changes I made for arm compatibility.
i think its not only interesting for dev but anyone who try achieve that or a similar goal i suggest once new source is released and u repeat that u supply a "howto compile diamondDD on QNAP NAS" which we add to our github as a guide thx for your effort to explore new possible plattforms to run diamond onto I think the changes should be partly incorporated into the main source three: there are needed changes in the makefile, a couple cpp files and an additional asm file for scrypt arm (+ all the qnap specific things). when the new sources are available, I'll redo the same, but this time keeping track of all the changes ;-) |
|
|
|
|
I've succesfully compiled the headless wallet on my QNAP NAS (arm processor).
It wasn't trivial, the wallet code assumes x86 in some places.
Devs let me know if you are interested in which changes I made for arm compatibility.
|
|
|
|
|
Show Posts
