[ANN][SIC] Sifcoin - inflation fork

[fendlestick]

The best thing we can do is get this on an exchange sooner rather then later. Atleast there was no premine and quick diff adjust means no one can dump a large amount of coins.

You can request coins-e at https://bitcointalk.org/index.php?topic=240717.0 they will probably take you, if not straight away possibly quite quickly if you show you are keen.

[1714857855]

1714857855

[1714857855]

1714857855

[1714857855]

1714857855

[mill0601]

skipping this one, too many coins already which are better (atleast in announcing & releasing)

This is relatively innovative coin with 6 crypto-algoritms (Blake, BMW, Groestl, JH, Keccak, Skein) + block reward depending on difficulty.
CPU-only at this time.
No premine.
That is actually what a lot of people waited for.

why, what was the point if 6 algorithms, why not 7 or 5.  What is your purpose other than adding complexity to a solution that is already exists (scrypt)?

Because everyone knows that using six 512-bit hashing algorithms consecutively and then truncating the last 256-bits means that your coins can't be GPU mined, duh!  It's not like you can just reduce the search space to what the difficulty is and only check random hashes against the last hashing algorithm, either.

Someone is GPU mining this right now.

With how few coins that have been generated I highly doubt anyone is gpu mining

[tacotime]

With how few coins that have been generated I highly doubt anyone is gpu mining

Well, all the hash functions are included in the source as .c files, if someone isn't GPU mining without a few hours I don't know when they will be.  It should be like Bitcoin in that GPUs will be expected to hash at rates of around 50-100 fold that of CPUs.  Most of the algorithms selected are high throughput and benefit strongly from parallelization.

[hl5460]

Based on code Bitcoin 0.8.2

Start: 2013-06-23, 00:00 GMT

Coin: infinity in time

Block target: 5 minutes

Dif retarget: every block, +-1% of mean last hour

1 Coin = 100'000 Satoshi

Block reward = 1Coin + bonus
bonus = sqrt(Diff * block#) Satoshi (eq 0 in start, hundreds in far future)

Hash-mining: chain in sha-3 candidate-finalis-win function Blake=>BMW=>Groestl=>JH=>Keccak=>Skein. While only cpu-mining (built-in qt miner)


Download links: http://sourceforge.net/projects/sifcoin/ (win32-exe and source code for another)

original (rus) post here: https://bitcointalk.org/index.php?topic=240884.0


known node

addnode=206.248.191.155
addnode=206.248.191.155

I thought satoshi is just for BTC?

[Storan]

why, what was the point if 6 algorithms, why not 7 or 5.  What is your purpose other than adding complexity to a solution that is already exists (scrypt)?

just like that 
long chain complicates gpu optimization thousands of times, there is a function not so accelerated, and it will slow down the entire chain functions.
Unfortunately, i no have knowledge of mathe, pre-select in this regard "good" algorithms.

I thought satoshi is just for BTC?

Why not? good, the traditional name for the atomic unit cryptocurrency.

[maxsolnc]

Does the client have possibility to look on generation speed? Both per machine and whole network

[ig0tik3d]

i will pay 75 SIC for first pool and 75 SIC for miner on cpu..

[mill0601]

i will pay 75 SIC for first pool and 75 SIC for miner on cpu..

I will add 10 sic to each of those

[tacotime]

why, what was the point if 6 algorithms, why not 7 or 5.  What is your purpose other than adding complexity to a solution that is already exists (scrypt)?

just like that 
long chain complicates gpu optimization thousands of times, there is a function not so accelerated, and it will slow down the entire chain functions.
Unfortunately, i no have knowledge of mathe, pre-select in this regard "good" algorithms.

no

[Balthazar]

Just a dirty example in pseudo-code:

Code:

PoWHash(Data):
    laFunctions = [Skein, scrypt_pbkdf2_salsa, scrypt_keccak_chacha, Groestl, Keccak, SHA512, Blake]
    liFuncIndex = 3
    lsHash = Data

    lI = 0

    while lI < 5:
        if liFuncIndex < 0 or liFuncIndex > len(laFunctions):
            liFuncIndex = 3

        lsHash = laFunctions [liFuncIndex](lsHash)

        if (lsHash[64]&(1<<0))!=0:
            liFuncIndex = liFuncIndex - 1
        else:
            liFuncIndex = liFuncIndex + 1
        lI = lI + 1

    return lsHash 

 

But it's potentially vulnerable to lsHash[64]&(1<<0) brute-forcing. This could be resolved by adding more conditions to make it stronger.

[h2odysee]

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?

[mill0601]

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

[SpaceCadet]

This is an intriguing coin, but my pyccкий 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!

[maxsolnc]

This is an intriguing coin, but my pyccкий 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!

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"

[mill0601]

This is an intriguing coin, but my pyccкий 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!

current block is 1938 so there must be something wrong

[Balthazar]

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

[SpaceCadet]

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.

[maxsolnc]

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.

[mill0601]

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.

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

[SpaceCadet]

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.

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)...