Thanks!  Let me know when the block explorer is up and running.  Note that IMAC is a n-script coin with a large enough n that most generic code needs tweaks to work (mostly just changing stack memory allocations to heap allocations)

I've been syncing a number of new machines, would not expect you to have any problems.

How large of a bounty would you want?  Perhaps PM me and we can negotiate <smile>.

GoArchit (www.goarchit.online) is at 50% complete, next step will take it to 60% expected in the next couple of weeks.

A new windows wallet was published today.  It has the latest checkpoint information and new artwork (some may recognize the heavy influence of my defunct coin, YACCoin).

You can grab it off the link at http://www.imacredit.com. 

PLEASE keep a copy of your original executable.  Testing here at my remote site showed no problems, but previous efforts at another site generated an executable that wasn't compatible with the old wallet (for totally unclear reasons).  If you get a "non-recoverable wallet" type error seconds after launching, just revert to your old code, and PLEASE post here.  In fact, if you don't have any issues, PLEASE post that here as well!  I'll be testing this executable when I visit my other site next week.

Slightly tweaked http://ww.imacredit.com as well, and snuck in the name of the new project that is using IMAC...

Spent the last few evenings recreating a build environment for the Windows version of the coin, finding capable packages, etc.  Did upgrade to 64-bit.

Having one problem with the new code and wondering if this rings a familiar bell with anyone:

The new executable claims the old wallet is corrupt.  It works fine is allowed to create a new wallet, and the old wallet works fine with the old executable.  Tried 32 & 64 bit versions.  Tried db5.3 as well as the original db4.8 - no difference.

Not really interested in moving all my private keys, would rather figure out whats wrong.

I DO NOT have this problem with the Linux version, the code was completely compatible there.

This isn't hyper critical, but would be nice to get fixed.  Other than going to 64-bit mode, the only other change is additional checkpoint records and a bump in the protocol (which I used to track adoption of wallet packages).

Time is NOT an issue.  This project is being measured in months, not days.

Just a quick update:  Progress on the new project is continuing.  The next step is a big one - validation of their key algorithm.  Most of the basic window dressing is complete.  The next few weeks will be interesting.

Regarding  IMACredit, I could use a hand with a couple of things:

1)  Need a blockexplorer
2)  Would like to revamp the website and possibly move it off of Weebly (mostly since Weebly wants an arm and a leg and part of my other arm to provide https support, which is kind of basic these days now that letsencrypt.org is available).  Since the project is written in GoLang, I thought Hugo would be cute.  I can provide the VM, certificates, etc. but could really use some help.
3)  Going to spend some time and work on being able to rebuild the Windows GUI.  Most of the original packages have updates, and alas they didn't all play together well on my previous attempt - so will try again.

Last but not least, may end up resetting mpos.imacredit.org.  I appear to be the only user, and this might lighten the load for the maintainer of that site.  Its currently suffering from a mysql database issue (duplicate payment of a block type thing).  I'm open to using newer pool software if anyone has a suggestion for something that is currently ACTIVELY supported.

Good news is the coin blockchain appears to be nicely stable.

Cheers!

ps.  If you happen to want to work on the main project, and are comfortable coding in Go, please let me know.  The project is all volunteer based and not currently paying anything, but still, could be fun.  I'm doing what I can...

Thanks.  Unfortunately none that I'm aware of - those tend to appear in sync with exchanges.

Just a little bit of news:  I know the developers have successfully interfaced their code with the wallet, which isn't quite as easy as it sounds, since every well baked coin has their own "magic number" and similar changes.  For instance, its pretty trivial to figure out what the current block number is, that is just an RPC call, but doing transactions or validating addresses is just a bit harder.

Lots of room for improvement on how they are doing it, although their current approach isn't bad.  I MIGHT have to refresh the code to enable a more efficient interface, but that should become obvious over the next couple of months.  If so, it will be transparent and not require any forking.

I have a little desktop "appliance" class box that is doing pretty well.  Its a $250 quad-core celeron with 4gb of memory running linux and its mined over 800 coins since I cranked it up when this new project started.  That is competing with a 56 core Xeon I'm using to keep blocks flowing.  Point being, everyday home machine have a reasonable chance at finding blocks - just measure success in coins/week, not coins/minute.

If you (or anyone else) does host a block explorer, please let me know.  I'll update the official webpage to point at it.  That would be a great help, since most exchanges require one to be functional.

The original dev?  Me?  Yep.  Last year.  Posted why back then.

Cautiously optomistic with the new development.  Suspect it will be 3-6 months before any code is made public, but I've been made part of the development team.

If in that time frame, significant progress is made, I'll likely refresh IMACredit off the current Vertcoin stream, retro fitting the significant changes that made IMACredit unique, while preserving the current blockchain.  That will bring the code base up to snuff with features like WebSockets, which will industrialize the coin a bit.

I've refocused a number of my systems to mine IMACredit with blocks coming out close to the expected time.  Suspect we are only a few big machines, or a few dozen small ones, from have a steady flow of blocks at the target interval.

As always, the best thing to do is to solo-mine the coin, but http://mpos.imacredit.org has been up and running steadly since this new initiative started.

Not pumping the coin, especially since there is no exchange handling it, but trying to be as public as I can about whats happening.

Your pretty much screwed.  Poloniex announced the delisted at least a week ago.

Not uinless some new group of develops want to adopt it.  I'm out of the game on this coin now, and have been for some time (see post #177).

I believe this coin suffered a major set back after post #177.  AFter that, all previous posts, sites, etc. were pretty moot.

Maybe, just maybe, might have a project that will use IMACredit as its base.  Should know more in the next week or two.  Until then, I'm working on making sure all the seed nodes are stable and current, and doing a bit of mining.  ps.  mpos.imacredit.org is back online if anyone insist on pool mining.  Recommend tpruvot's miner for those that don't want to solo mine:

nice -n 19 ./cpuminer --algo=scrypt:131072 --url=stratum+tcp://10.184.155.39:10052 --userpass=Cassey.rackserv:pass --quiet

If this take off, it won't be anything quick and not likely public for some time.

Basically the new project developers are looking for an ASIC resistant coin with a bit of history and an established blockchain that they can partner with.  Could be great news, likely will become nothing.  Still, thought I'd mention it, even though the coin currently has no exchange that I'm aware of.

You win No-Ice-Please.

Since I have NO CLUE how to prevent this for 1CRedit, or for any of the hundreds of other coins based on KGW, guess I'll be shutting down my support for 1CRredit and YACCoin today.

I think someone orchistrated the long outage:  threw a ton of asic at it to boost the difficulty, then went private for a month or so, then rejoined the network.  I noticed the block count jumped ~6000 blocks within a day of the long block being found.  I would have anticipated a quick 1024, since that is the depth of the KGW, but not the extra 5000.  Of course, once they joined, their own breaker block would register on the chain as valid and they could flood all the private blocks they wanted.  The ~6000 is about right for the period we were offline.

I have NO idea how to block against this abuse of power.  Very VERY depressed by it - enough to want to say "Enough" and shut things down.

Play with what you think looks nice.  Check out YACC for what I did.  Get other peoples opinion, I'll go along with what the crowd wants, within reason.

Ooh... pretty!  I'd be happy to incorporate that.  Need it about 12 differnet ways from Sunday (various sizes, formats, regular and testnet versions, etc.), but I like it.  What does everyone else think?

(See the https://github.com/1credit/1credit and look in:

/src/qt/res/icons and
/src/qt/res/images

to see the various files required.)

Nah, we would likely just go back one block - so at most, 1 coin, if you found that previous block.

Thanks for looking, and posting the correction.  You had us scratching our heads for a bit.

Our pool shows a pretty consistant difficultly around that number.

For sake of conversation:  if the difficulty has jumped from 97.5 to the previously reported 344,503, the only cure is a hard fork after some code work.

I should note that the current difficulty adjustment algo is based on the Kimoto Gravity Well with the Time Warp fix, and uses the last 1024 blocks in its computation.

Per my logs:

2016-08-09 23:28:05 received block 37c2825a528f103cdc5e3fac26ce77a3588f4d572a69ad3a387f3305bee0e2ff
2016-08-09 23:28:05 Difficulty Retarget - Kimoto Gravity Well TW
2016-08-09 23:28:05 PastRateAdjustmentRatio = 1.0484
2016-08-09 23:28:05 Before: 1c02a67a 0000000002a67a00000000000000000000000000000000000000000000000000
2016-08-09 23:28:05 After: 1c02a014 0000000002a014dbc3c543fadb829c672b0f9209df55da10db29383c0f4cf699
2016-08-09 23:28:06 Committing 1 changed transactions to coin database...
2016-08-09 23:28:06 SetBestChain: new best=37c2825a528f103cdc5e3fac26ce77a3588f4d572a69ad3a387f3305bee0e2ff  height=50895  log2_work=51.204357  tx=61080  date=2016-08-09 13:07:37 progress=0.998413
2016-08-09 23:28:06 ProcessBlock: ACCEPTED

So in theory, the next block should only be about 5% harder to find than the current block, which had a difficulty of 97.5, so the current block difficulty should be around 102.2.  Of course, that was based on a net hashrate of 845MH/s and the devs only have about 26MH/s of ASICs to throw at it.  Given that, I would have expected to find a block "On Average" in about 5 hours, not 30+ days.

Is there an exploit to KGW w/TW that yielded the previously mentioned difficulty of 344,503?  

We have been running with KGW w/TW using 1024 blocks since block 16175...  (check the source on github to verify)

Basically need suggestions and curious what the appetite for doing a hard fork is.   Please, constructive replies only...