You should use at least some priority in case a flood comes along before the next block.

As long as all dependencies have at least 1 conf, if the transaction doesn't have enough priority at first, the dependencies will age until it does.

Or managing how much priority you spend on a transaction.  The software would have to know your future plans to know whether to spend your priority now or save it for later.  I don't think we'll need to get into that much detail though.  There's a wide enough difference between normal users and flooders.

Priority doesn't have to do everything.  Once you know there's a flood, you can add -paytxfee=0.01.  Hopefully with priority, your transactions before that should be at worst slow, not stuck.

Version 0.3.15 is now available.

Changes:
- paytxfee switch is now per KB, so it adds the correct fee for large transactions
- sending avoids using coins with less than 6 confirmations if it can
- BitcoinMiner processes transactions in priority order based on age of dependencies
- make sure generation doesn't start before block 74000 downloaded
- bugfixes by Dean Gores
- testnet, keypoololdest and paytxfee added to getinfo

Thank you for limiting flood tests to the testnet.

Version 0.3.15 combines several features to help legitimate transactions jump the queue during a flood attack.  The key was Gavin's idea for prioritising transactions based on the age of their dependencies.  Every coin is entitled to turn over so often.  The longer waited, the more priority accumulates.  Priority is sum(valuein * age) / txsize.  Transaction fee still takes precedence over priority, and priority determines the order of processing within a fee strata.

In support of the priority feature, SelectCoins only uses your own 0 conf transactions only as a last resort if that's all you have left.  This helps keep you from turning your coins over rapidly unless you're forcing it by actually turning all your coins over rapidly.

I'm happy if someone with artistic skill wants to contribute alternatives.  The icon/logo was meant to be good as an icon at the 16x16 and 20x20 pixel sizes.  I think it's the best program icon, but there's room for improvement at larger sizes for a graphic for use on websites.

It'll be a lot simpler if authors could make their graphics public domain.

The only thing I can think of is to see if there are other versions of mingwm10.dll you can get.  mingwm10.dll is a tiny little DLL that came with the MinGW compiler that you need when you build for multi-thread.  I don't know exactly what it does, but it probably just says something like "yes Windows, see I'm in a DLL like you insisted."

The end of your debug.log file might show the last thing it was doing before it crashed.

Here's some pseudocode of how you would use the account based commands.  It sure makes website integration a lot easier.

print "send to " + getaccountaddress(username) + " to fund your account"
print "balance: " + getbalance(username, 0)
print "available balance: " + getbalance(username, 6)

// if you make a sale, move the money out of their account
move(username, "", amount, 6)

// withdrawal
sendfrom(username, bitcoinaddress, amount, 6)

I have the beginning of something like this.  It's mostly like what Gavin described.

Some more rpc interface:

move <fromaccount> <toaccount> <amount>
   Move from one internal account to another.  I think blank account name ("") will be your default account.  If you sell something to a user, you could do move "theiraccount" "" 123.45.
   Is "move" the best name for this?  I shied away from "transfer" because that sounds too close to sending a transaction.

I'm thinking a new function getaccountaddress instead of overloading getnewaddress:

getaccountaddress <account>
   Gives you an address allocated from getnewaddress <account>.  It'll keep giving the same address until something is received on the address, then it allocates a new address.  (It automatically does what the sample code I posted some time ago did)

Would these commands make it possible in simple cases to implement your website without needing a database of your own?

ECDSA can't encrypt messages, only sign signatures.

It would be unwise to have permanently recorded plaintext messages for everyone to see.  It would be an accident waiting to happen.

If there's going to be a message system, it should be a separate system parallel to the bitcoin network.  Messages should not be recorded in the block chain.  The messages could be signed with the bitcoin address keypairs to prove who they're from.

This is the important clue.  I believe it's saying it crashed in that.  Maybe there are other versions of it to try.  mingwm10.dll is just a simple placeholder thing that satisfies some callback requirement for multithreaded apps.

Is anyone else running OK on Windows 64-bit?

OK, if it really won't get past block 1698 on redownload, then we're in stranger territory.

Yes, possibly he has antivirus software or even a router or filewall that is pattern matching a sequence of bytes and censoring it.

It would be instructive to get knightmb's blk*.dat and see if that gets him past that point.

He was generating invalid blocks at difficulty 1.0.  He must have a corrupted entry in his blk0001.dat or blkindex.dat file.  He just needs to delete blk*.dat and let it redownload.

The safety lockdown detected the problem and was displaying "WARNING: Displayed transactions may not be correct!" because it saw a longer chain existed that it was unable to accept.  The safety lockdown cannot stop generation or it would create an attack possibility.

Good idea, I made a change to make sure it won't generate before checkpoint block 74000.

The order matters not to the program, but it matters to me maintaining it.  If it jumbles the order of the .po file then I can't diff for changes.  I have to update all 7 translation files when I change the English text in the program, and it's easier when they're all in the same order.

I can still put it back into normal order by making poedit rescan it.

It is normal that untranslated strings are shown on top.

I know, but not easily without complicating the sourcecode.

Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

Changes:
- Key pool feature for safer wallet backup
Gavin Andresen:
- TEST network mode with switch -testnet
- Option to use SSL for JSON-RPC connections on unix/osx
- validateaddress RPC command
eurekafag:
- Russian translation

SVN rev 163 (ver 0.3.13.3) has the key pool feature.  Pre-generated new keys are aged in a queue before use, so that backups of wallet.dat hold keys you'll use in the future.

For now I made the default pool size 100.  It can be configured with -keypool=.  Be aware, it takes a little time to increase the pool size, so don't go crazy with it.  Disk space is about 1K per key.

I have not addressed the recovery side of this yet.  If you actually did restore an old wallet.dat, I think you may have to delete blk*.dat to rediscover your own transactions during the redownload.

I've only tested this moderately.  You might not want to use this for a website server until it's had some more testing.

Repeating myself here, but there is open source software for that, so it would just be a matter of bolting on a Bitcoin payment mechanism.  One good one I found was Mihalism Multi Host.  It's designed as a free host, so it would just need a few tweaks to loosen up restrictions consistent with paid use.

Maybe you were just unlucky to have an exit node without reverse lookup.

The IRC server's response doesn't look like it was disconnecting you for that.  It's supposed to go IRC SENDING: NICK after that, and it doesn't so it gets timed out.

I see the problem.  The IRC code is looking for various phrases to see when the server is ready to receive your NICK, but it's not looking for that particular phrase.  I'll fix it.

I don't know if it's really required to wait for the server to finish looking up hostname before sending nick.

How long did it take to get connected with TOR the first time, having to use the seed nodes?

That's going to be more of a SelectCoins thing.

SVN rev 161 has a refinement to recursively determine if your own unconfirmed transactions can be spent.  This is needed because you should be able to spend your own change right away.

The new recursive determination is: 0/unconfirmed can be spent if it's yours and all its dependencies are either in a block or also yours.

Here's a Windows build:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

This version is an improvement if you already had a 0/unconfirmed transaction and might have already spent it.  If you were the original creator of a 0/unconfirmed transaction, you still need theymos' patch instead.

poedit reorganised the file for some reason.  I re-ran update from sources and it put it back in the original order so it's fine now.  Did you run it on a drive where files aren't sorted alphabetically, like a FAT drive or USB flash drive?

Strings aren't added or changed very often.  It's months before enough changes build up.

I uploaded the changes.

This Windows build has the Russian translation in it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

poedit does it.  Either get the src directory from a release, or download it with SVN.  Place your .po file 3 directories deep under the src directory.  Open it with poedit and do Catalog->Update from sources.

So for example, you have:
src
src\base58.h
src\bignum.h
...
src\util.cpp
src\util.h
src\xpm
src\locale\ru\LC_MESSAGES\bitcoin.po

Open bitcoin.po with poedit, do Catalog->Update from sources.  It looks for the sourcecode up 3 directories (..\..\..) from where bitcoin.po is.

This updates your existing .po file you already worked on and adds any news strings.  It may try to match close strings, so check things over and make sure it didn't make any bad guesses.

Make sure you use the .po file I uploaded to SVN or in a release, because I always fix up at least a few things.  I'm attaching your Russian one to this message.