This is the second time I've seen this "Live Protection" problem reported.

It must be blocking the program's network communication.  It sounds like it's allowing connections to be made, hence the 10 connections shown, but not allowing any data to be sent or received on them.

We need to understand this problem better.

Can someone write some instructions on the wiki explaining how to turn off or add an exclusion to Live Protection or whatever its full proper name is.

Laszlo corrected this, but unfortunately it was too late to make it into 0.3.0.  There will probably be a 0.3.1 soon though.

The problem is I used PRIO_MIN, I should have used PRIO_MAX for the lowest priority.  The OS isn't supposed to let you increase priority, so the PRIO_MIN ought to leave it at priority 0.

It doesn't work with wxWidgets 2.8, it needs wxWidgets 2.9.  Unfortunately, there isn't a Debian package of wxWidgets 2.9 yet.

Thanks for making that calculator.

The difficulty doubled a day or two ago, plus it's just random and you can have surprisingly long dry spells.

In Windows, you select the process in the task manager, right click, Set Priority.  Set it to BelowNormal or Low.  That shouldn't make a difference though.

If you turn off Generate Coins, does the CPU usage go flat?  That would confirm that all the CPU time it's taking is generate, which is idle priority already.

It could be it's slow just because you have too many things running at once and you're out of memory.  When you switch from one thing to another, it has to page it in from disk.

So that was responsible for keeping blocks from downloading?

The link: "Win32 CPU Cycles vs 'Live Protection' Engines"

For BitcoinFX, Live Protection was keeping it from getting CPU for generating coins.  You said your friend was getting 1400-1600 khash/s, so it was getting CPU.  I guess Live Protection must have been blocking some other part of the program then?

True, if it happened suddenly.  If it happens gradually, we can still transition to something stronger.  When you run the upgraded software for the first time, it would re-sign all your money with the new stronger signature algorithm.  (by creating a transaction sending the money to yourself with the stronger sig)

I'll start thinking about how to do this.

At the moment, you can kind of use -connect.  You can use -connect to make it connect to local computers on your LAN, like -connect=192.168.0.100.  If you start it out blank and don't let it connect to the main network, the difficulty is still at the original low difficulty.  If you've port-forwarded though, then outside nodes might still connect inward to you.

With -connect it still uses IRC, do you think it shouldn't get on IRC when you're telling it to only connect to specific nodes with -connect?  The main scenario for -connect is where you have a server farm, with two connected to the network and the rest connected to the first two.  In that case, you wouldn't want the -connect computers on IRC.

void ThreadIRCSeed(void* parg)
{
    if (mapArgs.count("-connect"))
        return;

I tested this with a non-lower-ASCII account name on XP and confirmed the bug, then tested that the new GetDefaultDataDir fixed it.  This change is revision 102 of the SVN.

What the OP described is called "cornering the market".  When someone tries to buy all the world's supply of a scarce asset, the more they buy the higher the price goes.  At some point, it gets too expensive for them to buy any more.  It's great for the people who owned it beforehand because they get to sell it to the corner at crazy high prices.  As the price keeps going up and up, some people keep holding out for yet higher prices and refuse to sell.

The Hunt brothers famously bankrupted themselves trying to corner the silver market in 1979:
"Brothers Nelson Bunker Hunt and Herbert Hunt attempted to corner the world silver markets in the late 1970s and early 1980s, at one stage holding the rights to more than half of the world's deliverable silver.[1] During Hunt's accumulation of the precious metal silver prices rose from $11 an ounce in September 1979 to nearly $50 an ounce in January 1980.[2] Silver prices ultimately collapsed to below $11 an ounce two months later,[2] much of the fall on a single day now known as Silver Thursday, due to changes made to exchange rules regarding the purchase of commodities on margin.[3]"

http://en.wikipedia.org/wiki/Cornering_the_market

I think I see where the problem is.  Coincidentally, I recently coded a replacement for the function in question which should fix it.  It's not enabled yet, but in the SVN version it prints a debug message in debug.log showing the new directory value and old value for comparison.

It's hard to imagine the Internet getting segmented airtight.  It would have to be a country deliberately and totally cutting itself off from the rest of the world.

Any node with access to both sides would automatically flow the block chain over, such as someone getting around the blockade with a dial-up modem or sat-phone.  It would only take one node to do it.  Anyone who wants to keep doing business would be motivated.

If the network is segmented and then recombines, any transactions in the shorter fork that were not also in the longer fork are released into the transaction pool again and are eligible to get into future blocks.  Their number of confirmations would start over.

If anyone took advantage of the segmentation to double-spend, such that there are different spends of the same money on each side, then the double-spends in the shorter fork lose out and go to 0/unconfirmed and stay that way.

It wouldn't be easy to take advantage of the segmentation to double-spend.  If it's impossible to communicate from one side to the other, how are you going to put a spend on each side?  If there is a way, then probably someone else is also using it to flow the block chain over.

You would usually know whether you're in the smaller segment.  For example, if your country cuts itself off from the rest of the world, the rest of the world is the larger segment.  If you're in the smaller segment, you should assume nothing is confirmed.

Thanks for finding that.  We switched from ANSI in 0.2 to UTF-8 in version 0.3, so it must be related to that.

Just to confirm, if you log in with the non-latin character username, not having an appdata/Bitcoin directory yet, and run Bitcoin and let it create the database from scratch, does it work or not?

Everybody needs to connect to the same IRC server and channel so they can find each other.

It might not be good if we suddenly rushed freenode with a ton of users all at once.

The fallback is our own seed system.

irc.lfnet.org is pretty old and has impressive uptime.  I think it's going to be fine.

We could take IRC out at some point if we want, but I'd rather ease into it and just test our own seed system as a backup for now, and I really like the complementary redundant attributes of the two different systems.

0.3 released
http://bitcointalk.org/index.php?topic=238.msg2004#msg2004

Announcing version 0.3 of Bitcoin, the P2P cryptocurrency!  Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server.  Escape the arbitrary inflation risk of centrally managed currencies!  Bitcoin's total circulation is limited to 21 million coins.  The coins are gradually released to the network's nodes based on the CPU power they contribute, so you can get a share of them by contributing your idle CPU time.

What's new:
- Command line and JSON-RPC control
- Includes a daemon version without GUI
- Transaction filter tabs
- 20% faster hashing
- Hashmeter performance display
- Mac OS X version (thanks to Laszlo)
- German, Dutch and Italian translations (thanks to DataWraith, Xunie and Joozero)

Get it at http://www.bitcoin.org or read the forum to find out more.

BTW, I did come to my senses after that brief bout with 1.3, this release is still going to be 0.3 beta not 1.0.

I really appreciate the effort, but there are a lot of problems.

We don't want to lead with "anonymous".  (I've been meaning to edit the homepage)

"The developers expect that this will result in a stable-with-respect-to-energy currency outside the reach of any government." -- I am definitely not making an such taunt or assertion.

It's not stable-with-respect-to-energy.  There was a discussion on this.  It's not tied to the cost of energy.  NLS's estimate based on energy was a good estimated starting point, but market forces will increasingly dominate.

Sorry to be a wet blanket.  Writing a description for this thing for general audiences is bloody hard.  There's nothing to relate it to.

Laszlo's build is going to be our first Mac release so please test it!

I reduced max outbound connections from 15 to 8 in RC4.

15 was way more than we needed for redundancy.  8 is still plenty of redundancy.

As the nodes upgrade to this version, this will cut in half the number of connections that inbound accepting nodes get.

If anyone wants more than 8 connections, they can open port 8333 on their firewall.

OK, back to 0.3 then.

Please download RC4 and check it over as soon as possible.  I'd like to release it soon.

http://bitcointalk.org/index.php?topic=199.msg1927#msg1927

Other than the version number change, which included changes in readme.txt and setup.nsi, I reduced the maximum number of outbound connections from 15 to 8 so nodes that accept inbound don't get too many connections.  15 was a lot more than needed.  8 is still plenty for redundancy.