[ANN] Infinitecoin - IFC | V1.8 Released! *Mandatory Upgrade, upgrade ASAP*

[anoncuber]

Block chain and wallet are synchronized very well. I have currently 17 connections. New diff. algo is working great also.
Majority of the miners are at http://coin-base.net/infinitecoin and one coin jumping pool is jumping whenever diff get lover.
You can continue to mine and support this coin, i know i will .

You can trade your IFC at bter, deposit and withdraw is working. Trading at Cryptsy is still on hold, someone should wake up BigVern!

Fantastic .. another bit of strip-mining in progress I think! The pool has now not found a single block in over 2 hours and the hashrate has jumped to nearly 300MH (now 416MH just a few mins later!) from a peaceful 40 odd  

[1713986501]

1713986501

[1713986501]

1713986501

[1713986501]

1713986501

[killdemon]

pool was down.

[yugo23]

Any news when IFC will be back on Cryptsy?

[tokyoghetto]

seems like http://coin-base.net/infinitecoin/index.php is still down. I think this is the only pool running 1.7 client. I wish ifc.scryptmining.com and other IFC pools would update their clients.

[killdemon]

you can mine at  http://treasurequarry.com:9844 also updated with v1.7

[fisheater]

The IFC blockchain and mining is going on fine, no problem. I hope cryptsy will soon restore the trading of IFC.

[zackclark70]

The IFC blockchain and mining is going on fine, no problem. I hope cryptsy will soon restore the trading of IFC.

they paused it due to your request just tell them you are happy its all working now and they can un pause it

[Petr1fied]

The IFC blockchain and mining is going on fine, no problem. I hope cryptsy will soon restore the trading of IFC.

I've attempted syncing from nothing with v1.7 at least 5 times now and I cannot get past block 248,093 no matter how many times I try:

Code:

received block 6e79edc0751588e349dd
  nActualTimespan = 3049  before bounds
GetNextWorkRequired RETARGET
nTargetTimespan = 3600    nActualTimespan = 3049
Before: 1e0fffff  00000fffff000000000000000000000000000000000000000000000000000000
After:  1e0d8d14  00000d8d14c55555555555555555555555555555555555555555555555555555
ERROR: AcceptBlock() : incorrect proof of work
ERROR: ProcessBlock() : AcceptBlock FAILED
disconnecting node 86.150.227.43:9321
Disconnected 86.150.227.43:9321 for misbehavior (score=100)

It looks to me like there may be an issue in the blockchain you've all manually downloaded and being building upon.

[fisheater]

The IFC blockchain and mining is going on fine, no problem. I hope cryptsy will soon restore the trading of IFC.

they paused it due to your request just tell them you are happy its all working now and they can un pause it

I just sent them another email stating that everything is running smooth and the previous issues have been resolved. I asked them to restore the trading for IFC.

[fisheater]

The IFC blockchain and mining is going on fine, no problem. I hope cryptsy will soon restore the trading of IFC.

I've attempted syncing from nothing with v1.7 at least 5 times now and I cannot get past block 248,093 no matter how many times I try:

Code:

received block 6e79edc0751588e349dd
  nActualTimespan = 3049  before bounds
GetNextWorkRequired RETARGET
nTargetTimespan = 3600    nActualTimespan = 3049
Before: 1e0fffff  00000fffff000000000000000000000000000000000000000000000000000000
After:  1e0d8d14  00000d8d14c55555555555555555555555555555555555555555555555555555
ERROR: AcceptBlock() : incorrect proof of work
ERROR: ProcessBlock() : AcceptBlock FAILED
disconnecting node 86.150.227.43:9321
Disconnected 86.150.227.43:9321 for misbehavior (score=100)

It looks to me like there may be an issue in the blockchain you've all manually downloaded and being building upon.

Block 248093 is not where it has problem, the problem was long ago (246953). You already passed that point. Please try to sync with these nodes using addnode (from my peers):

    {
        "addr" : "68.42.103.11:9321",
        "services" : "00000001",
        "lastsend" : 1380393168,
        "lastrecv" : 1380393168,
        "conntime" : 1380392845,
        "version" : 60001,
        "subver" : "/Satoshi:1.7.0/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 259331,
        "banscore" : 0
    },
    {
        "addr" : "86.150.227.43:9321",
        "services" : "00000001",
        "lastsend" : 1380393168,
        "lastrecv" : 1380393168,
        "conntime" : 1380392850,
        "version" : 60001,
        "subver" : "/Satoshi:1.7.0/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 259331,
        "banscore" : 0
    },
    {
        "addr" : "71.218.181.245:9321",
        "services" : "00000001",
        "lastsend" : 1380393156,
        "lastrecv" : 1380393168,
        "conntime" : 1380392851,
        "version" : 60001,
        "subver" : "/Satoshi:1.7.0/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 259331,
        "banscore" : 0
    },
    {
        "addr" : "76.110.255.33:9321",
        "services" : "00000001",
        "lastsend" : 1380393162,
        "lastrecv" : 1380393168,
        "conntime" : 1380392941,
        "version" : 60001,
        "subver" : "/Satoshi:1.7.0/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 259337,
        "banscore" : 0
    },

[ortchi]

Sorry crontab had hung himself.
Mining continued without problems.
The crontab is restarted and all the blocks were calculated retrospectively!
NO COINS ARE LOST!
Now everything is ok!

http://coin-base.net/infinitecoin/

[Petr1fied]

The IFC blockchain and mining is going on fine, no problem. I hope cryptsy will soon restore the trading of IFC.

I've attempted syncing from nothing with v1.7 at least 5 times now and I cannot get past block 248,093 no matter how many times I try:

Code:

received block 6e79edc0751588e349dd
  nActualTimespan = 3049  before bounds
GetNextWorkRequired RETARGET
nTargetTimespan = 3600    nActualTimespan = 3049
Before: 1e0fffff  00000fffff000000000000000000000000000000000000000000000000000000
After:  1e0d8d14  00000d8d14c55555555555555555555555555555555555555555555555555555
ERROR: AcceptBlock() : incorrect proof of work
ERROR: ProcessBlock() : AcceptBlock FAILED
disconnecting node 86.150.227.43:9321
Disconnected 86.150.227.43:9321 for misbehavior (score=100)

It looks to me like there may be an issue in the blockchain you've all manually downloaded and being building upon.

Block 248093 is not where it has problem, the problem was long ago (246953). You already passed that point. Please try to sync with these nodes using addnode (from my peers):

    {
        "addr" : "68.42.103.11:9321",
        "services" : "00000001",
        "lastsend" : 1380393168,
        "lastrecv" : 1380393168,
        "conntime" : 1380392845,
        "version" : 60001,
        "subver" : "/Satoshi:1.7.0/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 259331,
        "banscore" : 0
    },
    {
        "addr" : "86.150.227.43:9321",
        "services" : "00000001",
        "lastsend" : 1380393168,
        "lastrecv" : 1380393168,
        "conntime" : 1380392850,
        "version" : 60001,
        "subver" : "/Satoshi:1.7.0/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 259331,
        "banscore" : 0
    },
    {
        "addr" : "71.218.181.245:9321",
        "services" : "00000001",
        "lastsend" : 1380393156,
        "lastrecv" : 1380393168,
        "conntime" : 1380392851,
        "version" : 60001,
        "subver" : "/Satoshi:1.7.0/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 259331,
        "banscore" : 0
    },
    {
        "addr" : "76.110.255.33:9321",
        "services" : "00000001",
        "lastsend" : 1380393162,
        "lastrecv" : 1380393168,
        "conntime" : 1380392941,
        "version" : 60001,
        "subver" : "/Satoshi:1.7.0/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 259337,
        "banscore" : 0
    },

For now I'll just wait, I've wasted enough time trying to sync. If you note from my quote the peer that was banned is on your list. It's currently disabled on Crypto Blackjack until such times as I can actually sync.

[fisheater]

Hey fisheater. I think It would be good to raise the IFC miners fee to 1 to 2 IFC for a transaction fee (Like DVC) to maintain Network Hashrate and to prevent pool Jumping
BTC

Thanks. Will consider it in the next upgrade. I agree it is a good idea to have minimum transaction fee set to 1-2 IFCs. Earlier proposal with 10 IFCs got some oppositions.

[tokyoghetto]

Happy Reward Halving Everyone!

[RoadTrain]

BTW fisheater, in your code you compute nActualTimespan as a timespan between the last 120 blocks. While the PPC algorithm only uses timespan between the last 2 blocks.
In this way your implementation is half-working, it adjusts fast but the same oscillations may apply ,though in a softer form. Only the last 2 blocks matter.

Petr1fied, you are certainly using an older build, because these log messages were commented out in the latest codebase.

[fisheater]

BTW fisheater, in your code you compute nActualTimespan as a timespan between the last 120 blocks. While the PPC algorithm only uses timespan between the last 2 blocks.
In this way your implementation is half-working, it adjusts fast but the same oscillations may apply ,though in a softer form. Only the last 2 blocks matter.

Petr1fied, you are certainly using an older build, because these log messages were commented out in the latest codebase.

RoadTrain, it is not the algorithm uses timespan between the last 2 blocks. Basically you want the actual timespan be as close as the target timespan, so if they are different you want to move the diff so that the next one will make it closer to the target (in 120-block zone). But you can't just set the diff which will achieve it in one shot (as it will cause strong oscillations), you need to put certain "weight" to it so it moves to the right direction. What you see the formula does exactly this. The 2 actual timespans are the weights applied to the new diff. By the way, this is directly from PPCoin algorithm.

I have some improvements that I will put in the future upgrades, to make less diff oscillations. But it is not important at this time. IFC diff retarget is working fine, and despite people swing in and out due to some mining pools hop in and out of different coins, the retraget algorithm is very stable and has no problems.

[RoadTrain]

BTW fisheater, in your code you compute nActualTimespan as a timespan between the last 120 blocks. While the PPC algorithm only uses timespan between the last 2 blocks.
In this way your implementation is half-working, it adjusts fast but the same oscillations may apply ,though in a softer form. Only the last 2 blocks matter.

Petr1fied, you are certainly using an older build, because these log messages were commented out in the latest codebase.

RoadTrain, it is not the algorithm uses timespan between the last 2 blocks. Basically you want the actual timespan be as close as the target timespan, so if they are different you want to move the diff so that the next one will make it closer to the target (in 120-block zone). But you can't just set the diff which will achieve it in one shot (as it will cause strong oscillations), you need to put certain "weight" to it so it moves to the right direction. What you see the formula does exactly this. The 2 actual timespans are the weights applied to the new diff. By the way, this is directly from PPCoin algorithm.

I have some improvements that I will put in the future upgrades, to make less diff oscillations. But it is not important at this time. IFC diff retarget is working fine, and despite people swing in and out due to some mining pools hop in and out of different coins, the retraget algorithm is very stable and has no problems.

I understand how it works. I just pointed out that you use the timespan across 120 blocks as opposed to ppcoin's 2 blocks. And then apply it to the target timespan across last 30 blocks. It's plain wrong, the formula used assumes that nActualTimespan is the distance between last 2 blocks and nothing more.
In fact PPC's algo is based on Spacing, not Timespan.
Looking at blockexplorer I can see the same oscillations, though more smooth. When the blocks are slow, the diff is still climbing, while in PPC it would start decreasing immediately. With ppcoin's algo there can't be any oscillations at all, because the diff is adjusted only based on last 2 blocks, this is how it achieves the equillibrium.

[fisheater]

RoadTrain, using last 2 blocks you can't guarantee the average block time meets your target time. Yes I agree with you that using 120 blocks causing some oscillations, altho it is a smooth one. With the current algo the average block time is met perfectly. It is not the exact PPCoin formula, as it is applied to the 120 block time.

There will be some improvements to decrease the oscillations. But the algo for its purpose meet its target, so it is a correct one, although there will be some improvements to it.

The 30 is not the last 30 blocks, think it more a damping factory towards the target.

[myweblife]

coins-e.com、www.coinchoose.com still not upgrade their  IFC  client?

[NaNaec]

devs, you know that every day the absence of trading, the coin is slowly dying?