I tried building 4.3.5 on Centos 6.4 x86_64 (2.6.32-431.17.1.el6.x86_64) with Antminer S1 support.  The build stops in the bitmain driver:

  CC     cgminer-driver-bitmain.o
driver-bitmain.c: In function 'bitmain_read':
driver-bitmain.c:940: error: 'struct bitmain_info' has no member named 'device_fd'
driver-bitmain.c: In function 'bitmain_write':
driver-bitmain.c:971: error: 'struct bitmain_info' has no member named 'device_fd'
driver-bitmain.c: In function 'bitmain_parse_results':
driver-bitmain.c:1316: error: request for member 'min' in something not a structure or union
make[2]: *** [cgminer-driver-bitmain.o] Error 1

I ran the miner overnight. Here are the miner's stats as of this morning.

[2013-07-20 08:25:36] Pool: http://coinworld.us:8884/
[2013-07-20 08:25:36] SOLVED 16 BLOCKS!
[2013-07-20 08:25:36]  Share submissions: 34172
[2013-07-20 08:25:36]  Accepted shares: 21492
[2013-07-20 08:25:36]  Rejected shares: 12680
[2013-07-20 08:25:36]  Accepted difficulty shares: 202557
[2013-07-20 08:25:36]  Rejected difficulty shares: 120888
[2013-07-20 08:25:37]  Reject ratio: 37.1%
[2013-07-20 08:25:37]  Stale submissions discarded due to new blocks: 301
[2013-07-20 08:25:37]  Unable to get work from server occasions: 2
[2013-07-20 08:25:37]  Submitting work remotely delay occasions: 1

Even though the rejection rate is high, the results are good.

It was about 220 accepted and perhaps 230 rejected.  I set the miner back to just the coinworld pool.  We'll go watch a movie and see what the numbers are after that.   

I have a miner doing load balance mining between coinworld.us and nanotokens.miningpool.co.  Coinworld offers more lower difficulty blocks (1 and 2) and rejects about half of what the miner submits.  The second pool offered blocks at 32 difficulty and so far has not rejected any.  Less blocks are submitted with the higher difficulty (as expected.)

I see a 49.5% reject rate after ten minutes of mining.
On the positive side, I did solve three blocks (but at least one solved block was rejected.)
I'll run against another pool later to see what reject rate I get there.

I dropped off when the reject rate hit about 45% for me.  I'll take another look in a few minutes.

This has been educational.   
I ran a re-scan.  The scan found 518 blocks missing from my client's wallet.  The re-scan didn't add the blocks to the wallet, which is normal if the blocks aren't for an address found in the wallet.  However....
I backed up the wallet and created a new one, then imported the private keys from the older wallet into the new one.  I also downloaded the blockchain from scratch.  After that I did another re-scan.  That scan found "only" 167 blocks missing from the wallet just created.  The blockchain explorer is returning a 500 error at the moment, so looking up a few of them will be a chore for another day.  Here are a few of them from the end of the list found by the scan:

AddToWallet a7f2f06bb5
AddToWallet ce3fae5d6d
AddToWallet 5c6facb254

Here's a few from the beginning of the list:

AddToWallet 09230627f5
AddToWallet ac1c549ea2
AddToWallet 028c82e01b

I have some (a smaller number) of missing blocks from the Qt wallets of other coin clients based on bitcoin-qt, so this does not look like anything specific to the Nanotoken Qt or CLI clients.

I ran this earlier and saw some entries for today (2013.07.17). I re-visited that link a minute ago. The last payout is from three days ago. Somebody (something) changed their (its) mind. 

I don't have access to XP, but I modified the menu entry in the Windows program list of a Windows 7 client to include these options:

-rescan -checkblocks=0 -checklevel=4

The last two options don't take long to run against the Nanotoken blockchain at the size that it is now. They would take much time when it grows to the size of bitcoin's. If you trust the nodes in your peer list, you can leave them out.
In the Windows programs list, I select and right click on the Nanotoken client.  I go to the Shortcut tab, then edit the Target option so that it looks like this:

"C:\Program Files (x86)\nanotoken\nano-qt.exe" -server -checkblocks=0 -checklevel=4 -conf="$PATHNAME\nanotoken.conf" -rescan

$PATHNAME in my example is the full Windows directory path to where I store the configuration file.  I quote it because part of the path contains spaces.  I needed the -server option to accept connections from solo mining clients.

I agree.  When I've run the client behind a lot of network security with IRC disabled (because leaving it on gets the client quarantined for bot-like behavior by the loal PC's security), no blocks can be pulled down.  Does turning "dnsseeds" on, or "noirc" off, help?

What does "nanotokend getpeerinfo" show you/them?

We're the squeaky wheels. 
Thanks.

I re-scanned my client's wallet and did pick up some missed records.  I've been mining since Wednesday morning, but haven't seen any coinworld.us payouts yet.
MeKzQLrKbHt5DxvVCT47W5ZiaMJS5ZjyiU is the address I'm using to mine.

I had noirc enabled (noirc=1 in the configuration file.)  Until I turned that off (noirc=0) and re-started, the client was re-setting the max block every few minutes after each hijacker spewed into the block chain.

Done.
I'm running the alpha2 client.  I've seen the maximum block count go up, and synchronization is going slowly.  The client log shows the latest block is 10686, so there can't be 376,000+blocks left to go.
Screen shot:

https://i.imgur.com/MnLCA4c.png

I'm running on it for awhile, but I expected the pool fee to be more like 0.5% to 1%, at least at the beginning.

The logs show many orphan blocks showing up recently.  (Log excerpt in GMTime follows).

07/10/13 13:44:59 received block bb8de9716c21d63474da
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=adfede5ecbc220207348
07/10/13 13:44:59 received block 9350034b0ef4acbd3e1e
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=bb8de9716c21d63474da
07/10/13 13:44:59 received block db32f9bbe3603114d572
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=9350034b0ef4acbd3e1e
07/10/13 13:44:59 received block 15081ae1e33a41bbfa2c
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=db32f9bbe3603114d572
07/10/13 13:44:59 received block 0eb7258ad053301cba82
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=15081ae1e33a41bbfa2c
07/10/13 13:44:59 received block 77fa54894bd89aa84390
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=0eb7258ad053301cba82
07/10/13 13:44:59 received block f4f2c60f661b33206a49
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=77fa54894bd89aa84390
07/10/13 13:44:59 received block 398601a33baae11914e5
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=f4f2c60f661b33206a49
07/10/13 13:44:59 received block cdeddd3196901fe35faa
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=398601a33baae11914e5
07/10/13 13:44:59 received block 69dbefef0a90229b95cf
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=cdeddd3196901fe35faa
07/10/13 13:44:59 received block 5c0431388c2e5649ef9e
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=69dbefef0a90229b95cf
07/10/13 13:44:59 received block 07966a77107ff5aa749b
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=5c0431388c2e5649ef9e
07/10/13 13:44:59 received block 7eaddcdb95b11d60fc60
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=07966a77107ff5aa749b
07/10/13 13:44:59 received block f92ea85c0ef871992c30
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=7eaddcdb95b11d60fc60
07/10/13 13:44:59 received block 6ff362d710d1f8e6edb2
07/10/13 13:44:59 ProcessBlock: ORPHAN BLOCK, prev=f92ea85c0ef871992c30

Running the alpha 2 client.  I'll re-compile on the Linux and Mac zoo when I get time later this week.
We saw this reward overnight:

https://i.imgur.com/spNDqpK.png

A piece of the block 10,000 reward?  Lucky, anyway.

I don't see fresh stats older than 256 seconds, as of 06:17 forum time on 7/1/2013.

I cancelled an order for a 25Gh cube.  I still have a jalapeño order in, placed before the price increase.
People have waited longer than I did with larger orders in the queue.  I doff my hat to their patience.  I can risk a small amount on a hobby.  I wasn't willing to wait months or years for a major purchase.