Looks like I've been on the correct fork.  All I needed to do was generate a new deposit address.

In same boat.  Have three transactions to alcurex on old MRC network which have 10-1000 confirmations and no visibility on alcurex.  I have re-downloaded block-chain from earlier back-up between each case and used the list of alcurex.org nodes to seed.

It took some time, but also got MRC barely limping in pool form at nomp.myminingpool.info-- but a warning to all that the MRC client is soooo slow that payment is broken.  You won't get any payouts, but pointing one GPU there has been enough for me to occasionally mine blocks. 

However, like I said, nothing has shown up at alcurex.

I am wondering if it would be too much to ask for a private key entry in alcurex so that the exchange wallet server can just credit MRC from a private key?  It's not like it matters when the network will be dead soon. 

Caching hashes for the block index did not substantially improve block load time.  Will see about doing some real profiling.  I am at least familiar now with the start-up process.

I think I have a handle on why the loading is so slow.  Since microcoin is based (however loosely) on Bitcoin-Qt, it has a full blockchain and creates an index in memory during the "Loading Block Index" phase.  I imagine for security sake, the hashes of the blocks do not appear to be stored in the blkindex.dat, which maps location of blocks in the blknnnn.dat files.  Thusly, while loading the block index in memory, the hashes of all blocks are calculated.  For Scrypt-jane at high N-factor, this takes thousands of times longer than a SHA256d hash and is the reason why start-up time is slow.

My proposal is to go ahead and save the hashes in the blkindex.dat file alongside the index and simply load from the db.  This requires a few considerations/possibilities: 1) update-in-place an old blkindex.dat file 2) require blockchain be discarded and re-downloaded 3) offer a command line option to to hash validation 4) spawn a thread to check the hashes after loading from disk, and report any errors later.

For a full node, calculating the hashes is important because it validates the block chain has not been tampered with.  However, due to the complexity of Scrypt-jane with modified N-factor, we need to cache the hashes in order to be able to start quickly.

With that in mind, I do think I can put together a solution specific for this issue, without all of the coin control, multi-wallet and multi-sig changes I have been analyzing separately.  However, I promise no time frame because I have many other things on my plate and because summer vacation.

You are correct, I can confirm that after sweeping my MRC wallet, the start-up time remains the same.  Oh well, it will at least improve runtime performance.

Hi, that was me.  I didn't claim I could fix MRC start-up, only that I was working on a similar problem for another old alt-coin wallet (Lebowskis/LBW).  I have a branch of Lebowskis with many v0.8.x Bitcoin fixes applied.  It was a lot of work, and I do have everything compiling and linking.  There is new start-up code applied, and I am currently throwing an assert in there causing the application to quit immediately.  My hope was that once I was able to get these patches to work there I would also try to apply them to MRC.  This is unlikely to happen for a few weeks at best, namely because I'll be doing some summer vacation soon.

On a related note, for both LBW and MRC-- wallets with many transactions also experience additional slowness in the form of the wallet beginning to take 100% of single CPU.  This is due to wallet verifying new blocks/transactions vs thousands of private keys.  New wallets handle this more efficiently, but still ultimately also need to carry out the comparisons.  I had this LBW wallet with about ~14,000 transactions which besides being pegged at 100% CPU usage, first slowed down then stopped functioning (beyond expected timeouts).  I had not ever done this before, but I needed to "Sweep" all of my transactions from the wallet.  I did it all the coding myself, and that wallet took 7 or 8 full-block-sized transactions, but I was able to get it done and now the wallet is purring along at 10-20% CPU usage, which is reasonable for an active wallet.

So, for anyone having troubles with wallet with lots of transactions-- you need to sweep those transaction into one giant block, which will reduce the overhead of the wallet and marginally increase start-up time as well.  Here is what I used: https://github.com/CaptEmulation/bitcoin-rpc-sweep.  I have not tested on MRC, but it should work with any bitcoin RPC.  I'll test it with MRC later today.

Incredible.  Back-to-back blocks.  And my while I'm on the better side of my personal share variance.  Made my morning.

I added microcoin to my nomp pool at nomp.myminingpool.info.

Username:              your microcoin wallet address
Password:               anything
Algorithm:              scrypt-jane
URL (difficulty 8 ):   stratum+tcp://nomp.myminingpool.info:5008
URL (vardiff):          stratum+tcp://nomp.myminingpool.info:5032
Fees:                     2%
Payouts:                 To address after generation maturity (regular transaction)

Dirty little secret, I've never been able to get my gfx cards to mine microcoin.  Always causes a lock-up-- so I have not even tested scrypt-jane on nomp.  However this pool as worked fine for me on SHA256d and Scrypt coins.  NOMP's graph and statistics feature is limited as it does not track payout, but you will see hashrate and blocks found including pending and paid.  Payments and fees are all public on-chain.

I offer limited support through bitcointalk.  Please PM me if you have any problems.

I already have some UI improvements (new kilo-MRC and mega-MRC display units and locale currency formatting) already pushed into github.  I also fixed the merge errors in the original repo, so I don't think https://github.com/microcoinsource/microCoin_V2 is required anymore.  All should be able to use master of https://github.com/microcoinsource/microcoin.

I have mac build available at https://s3.amazonaws.com/captemulation/dmg/microCoin-Qt.dmg which I did over a month ago and tried to let alcurex dev forum, MRC and halibit know about-- but I see that there is still no Mac wallet posted at http://microcoin.alcurex.info/wallets-and-tools/ .   Would be nice to get that fixed.  I would also recommend a new Windows wallet, the UI is much easier to read especially for large MRC amounts.

I have been looking into the differences between bottlecaps and lebowskis wallets.  Lebowskis wallet forked from bottlecaps and has the exceptionally long start-up time problem.  Bottlecaps (latest wallet) appears to not have that problem.  There are a variety of changes, but am currently trying to update the lebowskis wallet to see if I can fix it's start-up problems.

Where was microcoin forked from?

We all knew attacks would come.  I don't think anyone is surprised about defects in quality of third party sub-contracted work.

I asked and have to date received no response.

As it turns out Lebowskid does not like multi-address generated coins which is how NOMP assigns fees.  So fees for LBW are now 0% at http://nomp.myminingpool.info/

Here's some IPv4 addresses to get people syncing again:

Anyone who is synced, can you please post the output of 'getpeerinfo' for the betterment of other FOOD participants.

I was synced fine to block 7971 but now have 0 peers and can't find an open connection.

Do not use rpcallowip=*.  You are opening up your wallet for remote RPC which can be used to steal all of your coins.  Use rpcallowip=127.0.0.1 if you want local daemon access or better yet, do as others have suggested and just use the basics.

Stirling engines are powered from a heat differential.  If you put the whole machine in the fire, so to speak, nothing happens.  But if you can heat one end of the machine while keeping "cooler" the other side, then you can generate power.

Stirling engines are sealed.  Heat is applied externally.  Natural gas, when burned, makes great heat source.

More details: http://en.wikipedia.org/wiki/Stirling_engine

Mac Wallet: https://s3.amazonaws.com/captemulation/dmg/Plankton-Qt.dmg

Mavericks (10.9) 64-bit

Here is a Mac build: https://s3.amazonaws.com/captemulation/dmg/RepublicCoin-Qt.dmg

Mavericks (10.9) only, because that is how I roll.

Donations: 1KEQpTBUNsqBDZoshDG7kyroBZpgdeHrWz

Put the code on github please.  +100 points if you properly fork.  Can do a build for Mac OS X but want to be able to create a PR for changes.

I am trying to understand how to use NOMP to multi-mine using a Base58Check compatible pubkey and a custom profit switcher algo.  In my case, I am working from a simple implementation of being able to manually switch the auto-switch pool from a web service.  I've looked at the bitcoin code and wiki so understand the mechanics of key creation-- now I am wondering if someone can point me towards a handy utility to help generate WIF keys from a common key to import into an arbitrary wallet.  So I don't have to write one.  Not wanting to reinvent the wheel ( I was doing that already before I found NOMP <3 ) and I figure I'm overlooking a key piece of information to do this easily.

Thanks.

I created a pool to point some spare USB Dualminer sticks at http://nomp.myminingpool.info/

Connection Details:
Username: your lebowskis wallet address
Password: anything
Algorithm: scrypt
URL (difficulty 32/Vardiff): stratum+tcp://nomp.myminingpool.info:4032

Payments are made after coins have fully generated and matured.  1% fee.  Running NOMP.