anoncuber
Newbie
Offline
Activity: 6
Merit: 0
|
|
September 28, 2013, 03:03:23 PM Last edit: September 28, 2013, 03:20:13 PM by 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
|
|
|
|
killdemon
|
|
September 28, 2013, 03:24:05 PM |
|
pool was down.
|
|
|
|
yugo23
|
|
September 28, 2013, 03:39:39 PM |
|
Any news when IFC will be back on Cryptsy?
|
|
|
|
tokyoghetto
Legendary
Offline
Activity: 1232
Merit: 1000
|
|
September 28, 2013, 04:13:22 PM |
|
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.
|
|
|
|
|
fisheater (OP)
|
|
September 28, 2013, 06:01:05 PM |
|
The IFC blockchain and mining is going on fine, no problem. I hope cryptsy will soon restore the trading of IFC.
|
|
|
|
zackclark70
Legendary
Offline
Activity: 868
Merit: 1000
ADT developer
|
|
September 28, 2013, 06:08:45 PM |
|
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
|
|
September 28, 2013, 06:21:26 PM |
|
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: 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 (OP)
|
|
September 28, 2013, 06:23:26 PM |
|
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 (OP)
|
|
September 28, 2013, 06:33:29 PM |
|
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: 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
|
|
September 28, 2013, 07:00:51 PM |
|
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
|
|
September 28, 2013, 07:16:58 PM |
|
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: 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 (OP)
|
|
September 28, 2013, 07:23:47 PM |
|
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
Legendary
Offline
Activity: 1232
Merit: 1000
|
|
September 28, 2013, 11:13:49 PM |
|
Happy Reward Halving Everyone!
|
|
|
|
RoadTrain
Legendary
Offline
Activity: 1386
Merit: 1009
|
|
September 29, 2013, 02:18:25 AM |
|
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 (OP)
|
|
September 29, 2013, 02:40:14 AM |
|
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
Legendary
Offline
Activity: 1386
Merit: 1009
|
|
September 29, 2013, 03:07:26 AM |
|
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 (OP)
|
|
September 29, 2013, 04:38:02 AM |
|
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
Sr. Member
Offline
Activity: 439
Merit: 250
mycoin.bitbank.com
|
|
September 29, 2013, 07:06:03 AM |
|
coins-e.com、 www.coinchoose.com still not upgrade their IFC client?
|
investment&deposit your BTC on bitbankmining BTC on
|
|
|
NaNaec
|
|
September 29, 2013, 10:22:46 AM |
|
devs, you know that every day the absence of trading, the coin is slowly dying?
|
|
|
|
|