And I'm holding onto my soon to be rare NFD coins. 

And the fact that 1.7 has reached end of life, everyone should be updating to 1.8 any ways unless you have a specific reason not to.

The announcement (with the deadline):
https://bitcointalk.org/index.php?topic=603932.msg10635985#msg10635985

And the how to:
https://bitcointalk.org/index.php?topic=603932.msg10643792#msg10643792

Thanks. 

I tried to generate a deposit address for HZxDASH a little over 6 days ago.  Today, the site still shows "waiting for address".

You might want to look into that.

Awesome!  Thanks.

Edit:  I don't have or use facebook (or similar social media sites).  Is there another way to login?

Your pool appears to be broken.

This is probably because HZ server(s) you've specified in the config file is offline, unreachable, etc...  I actually just setup my own forging pool and was about to post it here.  I ran into the same issue while setting it up.

Your stats of 450k HZ should have forged a block within 2 days.  My node has been up for about 6 days now, forged 5 blocks, 2 of which had a transaction fee with about 210k HZ forging.  It does have the default 1% fee.  (But if your node is offline that might by why it's not forging....)

You can see it here:  http://forgingpools.funkymonkey.org:8810/ - NHZ-EV6Z-CUQN-ST7T-G989A


(Note:  I am making an assumption in this post that the forging pool in the quote is yours.)

You know, if you're going to go through the trouble of clearing out the address at the top of the image, you might want to make sure your mouse isn't hovering over a link showing the address at the bottom of the image as well. 

BTER's node appears to have returned.  Hopefully this is a good sign. 

Why do you think that the network isn't strong enough to continue updating NAS?  Anyone who's running a node is either not watching this thread and still forked from the attack and going no where, or are watching this thread and will know that a new version will be coming out and will update.

If Bter hasn't fixed their node, it might be easier (less work) for them to just download the new client and download the chain cleanly from the network again.  Otherwise they'll be wiping the client, downloading the data, bringing their node offline when the new version comes out, possibly download the chain again, etc.

There are some major bugs that are fixed with newer versions of the NXT client.  I don't think that stopping the NAS patching at 1.1.6 leaving the rest of the bugs in place due to the fear of nodes not updating is a wise decision.

Will there be a NFD 1.3.7 with the Asset Exchange patches or has NFD updates completely stopped at this point?

Kozan, we can't get you your NAS back if it is stuck between exchanges.  Only the administrators of those exchanges can help.

The current plan for NAS is to get it patched with all of the security fixes NXT has applied.  Since the updates would probably require a hard fork in the block chain, we'd need to schedule it ahead of time when it's ready and start a new thread on the forums here since we can't update the first post of this thread with new client information.

What happens after the security fixes is going to depend on how much time we have.  We all have busy lives so I can't say what and when things will happen at this time.

Thanks MaWo! 

Well, we stopped the planet from spinning, then reversed the spinning direction to go back in time... wait, that was a Superman movie...

We found that the forked nodes agreed on all of the blocks up to a certain block height which was 277934.
We shut down a node once it deleted the forked blocks back to 277934.
We shut down a second node and deleted the block chain db.

The first node was brought up on an isolated network in a way that peers couldn't connect to it and it wouldn't attempt to connect out to anyone.
The second node was started up with a similar configuration but altered so that it would connect to the first isolated node.
Once the second node had downloaded the block chain from the first node (to verify it would be accepted by a new node) the two nodes started forging on their own disconnected from network under attack.
Transactions that were sent on the network under attack were not confirmed because of the attack.
Those transactions were copied and re-broadcasted on the isolated network and confirmed.  (The ones that were noticed at least with 1440 minute deadlines.)
After a few days, the other NAS forgers (that joined the XMPP chat room posted earlier) compared block chains from the different forked nodes and the isolated node.
After some testing with the different forks, seeing what worked and didn't, checking account balances, transactions sent during the attack, etc. it was decided that the fork running on the isolated network was the best NAS fork to resume working with.
The other forgers modified their clients to join the isolated network hidden from the public network and nodes under attack and ran various tests (forging, transactions, etc.) to verify everything worked.
Once we determined that the isolated network was at a point safe enough to re-introduce to the rest of the public and safe from the attack, we shutdown the nodes together, reconfigured them and started them up together for the rest of the world to access.

That brings us to today.
The NAS forks that were created from the attack will report that forging stopped a few days ago.  This is because the account which caused the problems was doing so with a balance lease that ended at a certain block height.  None of the forging accounts are forging on that chain due to transactions not being confirmed, possible sync issues for new NAS nodes, etc.

Anyone who finds their node stuck at a point where it is not forging or accepting new blocks is on a fork which will not be resolved by the client automatically.  If you are on one of these forks you can either restore a copy of your block chain from a backup taken before height 277934 (Apr. 5th ~14:00 GMT) or delete your node's database file and start over clean.

There is a public node "funkyvps3.funkymonkey.org" which can be added to the "wellKnownPeers" configuration option to get started.  This node is on block chain fork that the other NAS forgers agreed on.  This node also has the GUI interface open to the public at http://funkyvps3.funkymonkey.org:7873 for anyone who wants to login and check things.  This would be a good way to see if your local NAS nodes are on the same fork as the fork the rest of us agreed on.

Hopefully this sort of "attack" won't happen again.  We have learned a few things from this experience.

At the moment, the network is under an attack by lcharles123.

Any public node will get you up to block 277934.  After that block you'll see the blocks appear and disappear as the network fights with lcharles123.

There is a plan to fix things but it will take some time.

The actual client is still in the first post of this thread - 1.1.3N1.

You'll need to modify the config to add the public nodes.  There's a post about that a few pages back.

Since Patapato has Pidgin installed to chat, we're going to discuss things in a chat room, (faster than message boards).

This is an open invitation to everyone who wants to join, the XMPP (Jabber) chat room (MUC) is:  nas-dev@conference.funkymonkey.org

Not sure when we'll be discussing yet.. but join and sit idle for now... hopefully everyone with a NAS stake will join.  We need to make a decision to fix this issue soon.

Well, he's on the forums now so I'll let him defend himself...

If we blacklist his IP, what do you expect will happen?  My nodes seem to disagree with the blocks your node has.  Chances are, your node will disagree with what my nodes have.  User1234567890 reset a node and ended up where my nodes sit today.  Does that make my nodes the correct chain even though they're stuck at a block lower than your nodes?

I don't know for sure, it's an assumption.  This node became available the same day bter fixed their NAS withdrawals for me to get a few NAS from the exchange.  This IP is also visible on the NFD network which bter also supports.

I could be completely wrong calling 106.187.... bter's node but that's what I call it.  

Blacklisting lcharles node might be a bit extreme.  If it was done by lcharles setting his node then it probably wasn't intentional.  I don't think it's lcharles' blockchain reset because the blocks between 277021 and 278461 would have been forged with his account.  The last 100 blocks or so that I can see on both clients were forged by NAS-5HZF-TPQ5-GSHF-7GV33 (User123456789?).  Even if lcharles forged one fork, reset and forged the new fork, the blocks would still have his account on them from either fork.  I'd almost think lcharles was on a fork before the lease was set, started forging on his own and the rest of us didn't agree and accepted forged blocks from the 2nd highest forger.  That doesn't explain how I got stuck before the rest of you though...

To speed things up in getting this fixed quicker, I'd suggest we find a chat room for everyone with a node, compare chains, find a solution (hopefully without resetting bter) and going with it.  My access to IRC networks is limited most of the time being at work but I can join XMPP chat rooms any time.  If everyone agrees, let's set a time and discuss...

So your client is stuck where my nodes are.  That means that the blocks creating the longer chain contain something bad that those nodes accepted for some unknown reason.

If a new node is stuck at the same spot as my nodes then chances are we won't be fixing my nodes to reach patapato's block height.  We could try re-syncing again with my nodes shut down to see what happens but that might make things worse for the network.