Topic: [ANN][SIC] Sifcoin - inflation fork - page 7. (Read 46491 times)

7iN9tZvkgPmrKD4ddTQrtpr8DaYB8wt6ch

any one fancy sending a miner with 0 coins their first??

many thanks

Any easy way to reduce the diff or to re-scale how it increases?

My luck has been better the last two days though.  Not bad for a cpu-only coin!

Cheers!

Update 2013-7-4:
The diff is down some and my coin gen rate is up.  

The is a lot of activity on the Russian version of this thread. It would be great if someone could post some of the highlights and announcements from there to here (I'm impressed with how many on that thread are fluently multilingual!)

Any news from developers/big miners/exchanges?

Detailed Windows build instructions, using MinGW (64-bit):
   Install MinGW and the MSYS Developer Tool Kit (http://www.mingw.org/)
      * Choose C, C++ and MSys on install and select to have it update its libraries
      * Install into C:\MinGW
      * Add C:\MinGW\bin and c:\MinGW\msys\1.0 to your path
   Download MinGW64 from http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/
      * Choose mingw-w64-bin_i686-mingw_20111220.zip
      * Extract ZIP to C:\MinGW64
      * Add C:\MinGW64\bin to your path before C:\MinGW\bin
   Install libcurl devel (http://curl.haxx.se/download.html)
      * download curl-7.30.0.tar.gz from http://curl.haxx.se/download.html and put it in C:\deps\
      * launch an MSYS shell and enter the following commands (the configure step will take a long time!)
         cd /c/deps
         tar -xvzf curl-7.30.0.tar.gz
         cd curl-7.30.0
         ./configure --host=x86_64-w64-mingw32 –-prefix=/c/mingw64
         make
         make install
         cp /c/deps/curl-7.30.0/docs/libcurl/libcurl.m4 /c/mingw/share/aclocal/libcurl.m4
   Install pthreads
      * download pthreads-20100604.zip from http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/pthreads/ and put it in C:\deps\
      * unzip the file to c:\deps\
      * In the mingw64 subdirectory is pthreads-w64.zip - extract the contents to C:\MinGW64
   In the MSYS shell, navigate to the CPUminer source code direcctory
      * You will likely get higher hashrates by forcing the compiler to build the executable for your
        specific CPU architecture.  This is done by adding "-march=" into the CFLAGS.  Those
        values can be found at http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html
           common choices for intel are : core2, corei7, corei7-avx
           common choices for AMD are : athlon-fx
      * Execute the following (replacing the value of -march with the value for your CPU type)
         ./autogen.sh
         ./configure --host=x86_64-w64-mingw32 CFLAGS="-O3 -march=core2 -DCPU_X86_FORCE_INTRINSICS"
         make
   Strip minerd.exe
      * In a command prompt, in the compilation directory, execute the following
         x86_64-w64-mingw32-strip minerd.exe
   Combine the executables with the dependencies
      * copy minerd.exe, C:\MinGW64\bin\libcurl-4.dll, and C:\MinGW64\bin\pthreadGC2-w64.dll to the same directory

1. This is my logical mistake. Turning on the total correction blocks found in comparison with the calculated from the start of the system. So the current difficulty is too high - 2100 blocks is the estimated week+, and was a little less than four days.

2. 64-bit should be faster. At least one hash function skein, designed for 64-bit systems. Need a check, but the problem is that mingw32 - a compiler 32-bit exe.

Very minor differences from the base version.
lightweight rpc-call getwork2, and checkpoint on the 2000 block number (protection against alternative chain starting from scratch from an attacker).
minerd - modification cpu-miner by Jeff Garzik the modified hash functions and getwork2. The algorithm calculating hashes, really the same as in the qt-client used (C-library) sphlib v3.0

Once again my pyccкий is not very good   How does sic_new differ from what is posted on sourceforge (besides being much smaller)?  I noticed some small differences in the gui, but the version info is the same.  Not a complaint, just an observation.  I assume that minerd is included in the sourceforge version, just hidden behind the scenes since coin gets generated with just it running.

I REALLY like the idea behind this coin, and I understand that it takes some time to iron out the wrinkles when you don't just copy and paste to make a 'me-too' coin.  I just wish my pyccкий was better so I could get more from the original link!

Cheers!

i only compile source ))
Sources have been posted by creator of this coin
https://bitcointalksearch.org/topic/m.2588510, he speak, version of cpu miner is not beta is a deep alpha..)) and you can use miner for your own risk))

great work  may I suggest you make an official announcement in the forums so people dont miss it

source cpu miner http://sourceforge.net/projects/sifcoin/files/cpuminer-1.0.2.zip/download
and modificated wallet http://sourceforge.net/projects/sifcoin/files/sifcoin-code.zip/download

i compiled miner and wallet, but not sure is optimized for x64
minerd http://rghost.ru/47044682
wallet new http://rghost.ru/47044633

sifcoin.conf

It has - I mined about 6 coin in the first 24 -30 hours, but the next 24 hours I only mined 1 on the same machine/config.  Diff shot up and luck was down  

Now it makes me wish I had sprung for the faster cpu

BTW: does the windows .exe use all available processing extensions available in today's cpus (like SSE3)?  That's more a function of the compiler settings than the source code.  Would a 64-bit version buy much in terms of performance?  If the operations are mostly 32-bit int then probably not (I suppose I could look at the source to get a clue on that)...

we need more support for this coin it is really overlooked for some reason. Probably the inability to pump and dump.

Number of 1990 blocks reached! Seems like total hashrate slowed down, so generating speed is near to 250 coins per day, maybe a little bit more.

Thanks for the feedback!  

Now that the client has been running a bit longer, I noticed an interesting pattern.  

I should first point out that I'm testing this at work (sshhhh!), so most of the nodes are getting blocked by the firewall leaving me with usually just one connection.  (before you point out that IT will hang my ass for this, a) you are probably right but b) there are over 700 people just in this building so my threads are a drop in the bucket and I won't be leaving this running .  

This means it's taking a very long time to sync the transaction history. However, I've noticed that each time the client reports a new mined transaction, I find that another block is processed in the network transaction history (ie, "Processed N of 1943 (estimated) blocks in the transaction history" when I hover over the updating icon in the bottom corner of the client (N = also equals the number of coins it says I've mined).

I think this is more than a coincidence!  I will shut this down here for now and try it on one of my machines at home to get a more 'realistic' behavior, but I wanted to throw this out there in case it was useful to the dev...

Cheers!

UPDATE: Running the client at home was much more successful - it behaved as most clients do.  And it has generated a coin! (after it was fully sync'd)...

UPDATE2: (6/28) I had a corrupted data file - when I copied the directory to another machine, it was still misbehaving (even though I had a working instance (saved off of course) on that machine).  So the problem was on my end...  The original distro was ok.

Current blocksize has no connection with block reward. It's just block size in kB.

current block is 1938 so there must be something wrong

I'm not developer of the coin, but:
2. It's unreal number. I was getting ~2 SIC per hour with 100+ cores last day, so you can just restart your wallet to check
3. It's normal - developer didn't add this functionality yet
5. 5-7 is good, 0-1 is bad - maybe it is cause of your "1 coin per minute"

This is an intriguing coin, but my русский is not very good, so I have a few questions:

1. Do we need to set "generate=1" in the .conf to mine? (I seem to be mining ok, but I had it 'on' just to be safe)
2. Current blocksize is 1000, but I seem to be getting 1 SIC every minute or so (on a mobile sandy bridge i7 using 3 cores) - is this the expected behavior?
3. getmininginfo reports 'hashespersec' : 0, yet I appear to be mining coin (see #2) - is this the expected behavior?
4. How many confirms to confirm a transaction?
5. How stable is the nodelist?  I get 1 or 2, then sometimes 0 connections using the long nodelist in an earlier post.
6. Anymore info you can provide on the unique machanics of this coin would be a great help!

Cheers!

any word on getting on an exchange yet? I really think this is the best cpu only coin we have had.

Looking briefly at the code, it looks like it doesn't chain together the hash functions, but instead does keccak, then twice does either blake, groest, jh, or skein, depending on the hash of the previous block. I'm looking at the Hash5() function.

Why doesn't it just chain one after the other?