It's a miniupnpc thing. You can run Monero without it.

Transactions were broadcast to both forks, so many transactions (all that I've checked) were mined on both sides. It is physically impossible that you lost the coins - either your friend received them or you'll get them back. If your friend hasn't received them, then delete your wallet.bin (or whatever you've called your wallet) - NOT the wallet.bin.keys file - and run simplewallet as normal. It will rebuild the wallet cache from scratch.

When we replace it with per-kb fees.

No - that's transactions in that bad black (202612) - we are adding an exception so that it doesn't scan that block.

When I have questions like this I find it useful to refer to this guide first: http://www.devtome.com/doku.php?id=a_massive_investigation_of_instamines_and_fastmines_for_the_top_alt_coins

It says, of Blackcoin -

"For those of us keeping track, Blackcoin was launched Februrary 24th at 6:00 (no indication is given what time zone this is)). Block 4100 commenced on February 27th at 6:15. In 3 days…Blackcoin produced some 40 million coins (or 50 million). Now they rest at around 75 million coins and only PoS occurs from here.

This is photographic evidence that supports our brief searching of the blackcoin blockchain. The majority of the first 10000 blocks were PoW, and since they were all producing 1,000 BC, the bulk of the coins were made within one week. Anyone should be highly skeptical of the start of this coin. Who would think that the creator of this coin is thinking about enriching your pockets and not theirs?

To this end, who cares about their PoS option? They dished out thousands of blocks at 1000 BC a pop for three days. You would have to hold 100,000+ BC to be able to mint that kind of Blackcoin, which at today's rate would cost you in the neighborhood of $15,000 to obtain 100,000 BC. Are you sure you want to lock in that coin for minting now?"

The author of that guide is vicious in his exposé, and only lists 14 altcoins as being "acceptably mined" (of which Monero is one). Nonetheless, most savvy investors agree wholeheartedly with him and can't fault the facts he demonstrates.

2014-Sep-08 14:26:29.917842 [P2P7][176.227.205.210:28080 OUT]Sync data returned unknown top block: 208402 -> 208793 [391 blocks (0 days) behind]

You're WAY WAY WAY past the fork. If it'll make you feel better you can run the previous binaries no problem. Any issues you're encountering have NOTHING to do with the fork patch, and are likely a result of something else we can't figure out.

Here is the previous version: http://monero.cc/downloads/monero.win.x64.20140824.zip

Feel free to use it, you have no reason or obligation to stay on the latest version right now.

Have you increased your tx fee to 0.1 XMR for payments?

Not really, we identified and patched it first: https://github.com/rfree2monero/bitmonero/commit/b417abfb7a297d09f1bbb6de29030f8de9952ac8

Thereafter the CN devs emailed a patch, but as there are edge-cases their patch doesn't cover (and we'd already almost finished a more robust patch) we decided not to implement their change.

Of course, if they (or any developer of any one of the CN coins) finds and patches a critical bug we will be eternally grateful for their efforts. Fixing exploitable code is all of our jobs, after all.

You said you were stuck on 202656? If you got up to 206081 you were on the right chain and you just needed to wait for it to sync?

If it's "brutally freezing" when exiting that sounds like it's writing the blockchain to disk and you don't have a lot of RAM so it's paging in and out of RAM...you need to be patient with it. We are working hard on the embedded database, as that will alleviate this sort of problem.

That's not true - adding exclusive nodes prevents it from connecting to other nodes. Adding priority nodes makes it try connect to those first and to maintain a connection to them. Both options are bad if you're trying to be part of a global consensus network - let your client connect to peers and *find* consensus rather than forcing it to connect to certain peers. Doing so breaks the very nature of a consensus network.

Why are you specifying nodes?!?!???

Just start bitmonerod.exe and let it run, don't specify any nodes unless you absolutely know what you're doing!!!

Then maybe you need to start paying more attention to the Monero core team, of which I am a member, rather than reading silly threads filled with FUD where I've already decimated OPs comments, demonstrating that BCN took code from Monero and merged it without attribution.

You'd do well, too, to look at some of our other projects: https://bitcointalk.org/index.php?topic=768499.0;all

Ah yes - sorry, the terminology used in the blockchain storage class is rollback -

https://github.com/monero-project/bitmonero/blob/master/src/cryptonote_core/blockchain_storage.cpp#L399

rollback_blockchain_switching() is used when a node disconnects from one chain, rolls back, and then switches to another chain that it determines is "best" (longest verifiable).

Uh, the fork patch doesn't touch the wallet code. You can use the old wallet binary with the current daemon binary if you'd like. Literally nothing has changed in the way the wallet works in the last two weeks.

I'm not understanding what you're trying to do. If the Monero command-line client is not something you'd like to use, then use one of the GUIs as linked in our OP.

From our OP -

Announcements

September 7 - Block 202612 attack patch released, please update immediately
September 4 - Block 202612 attack, technical update
September 4 - Block 202612 attack, update 1
August 25 - Blockchain Spam Attack post-mortem, part II
August 24 - Blockchain Spam Attack post-mortem, part I

With regards to dga's article, it's important to read it thoroughly to understand that there are no negative implications for Monero: https://bitcointalk.org/index.php?topic=583449.msg8578519#msg8578519

We've been reeling this week to weed out any effects of the attack, so hard to say. We'll regroup tomorrow and see where we're at with that, but it has/had been progressing quite nicely: https://github.com/mikezackles/bitmonero/tree/fees_wip

You're quoting out of context.

From: http://www.devtome.com/doku.php?id=a_massive_investigation_of_instamines_and_fastmines_for_the_top_alt_coins#bytecoin1

No malicious facts were discovered in blockchain. There was no premine but the coins were generated very fast. We could defintely call it a fastmine. 85% of the coin has been mined before it “appeared on the radar” of anyone in the crypto world. This does appear to be a hidden instamine, but it could have been intended to be that way.

There's no need to do this, just use the latest version. Once you sync up to blocks 202612 - 202614 it will checkpoint to make sure you're on the right chain, and then it will start to ignore those bad peers.

They have never been necessary for regular functioning - if you have a specific use-case for either you'll have to compile them from source:)