It's not implemented yet, but the network can support a transaction that requires two signatures.  It's described here:
http://bitcointalk.org/index.php?topic=750.0

It's absolutely safer than a straight payment without escrow, but not as good as a human arbitrated escrow, assuming you trust the human enough.

In this kind of escrow, a cheater can't win, but it's still possible for you to lose.  It at least takes away the profit motive for cheating you.  The seller is assured that the money is reserved for him, while the buyer retains the leverage that the seller hasn't been paid yet until completion.

I don't think it should cause any problems for version comparisons.  31300 > 312.

I would not encourage using the extra decimal places.  They're only intended for future use.

You are correct that above 0.01 can still have additional precision, but the recipient won't be able to see it.  The UI will show it rounded down.

Bitcoin would be convenient for people who don't have a credit card or don't want to use the cards they have, either don't want the spouse to see it on the bill or don't trust giving their number to "porn guys", or afraid of recurring billing.

I don't understand, are you under the impression that the program sets the system clock?  It doesn't.

We use an internal offset based on the median of other nodes' times, but for security reasons we don't let them offset us by more than an hour.  If they indicate we're off by more than an hour, then we resort to alerting the user to fix their clock.

In the next release (0.3.13), I'm going to change the format of the internal version number integer from 313 to 31300, for instance 31305 = 0.3.13.5.  The last number represents changes on the SVN between releases and ought to be properly represented in the version number.  Otherwise, it would be a pain if we had a mistake or something in one of the sub versions that needed to be worked around.

I implemented this change in SVN rev 157.

The reason I previously made it so high was to allow very large transactions without hitting the transaction fee.  The threshold was around 26,000 BTC for transactions made of 50 BTC generated coins.  Even though it was 100 times easier to generate back then, only a few people ever encountered the fee at that level.  The new threshold puts it at around 11,000 BTC for sending generated coins.  It would mostly only be reached with generated bitcoins.  If you bought your bitcoins, they'll be denominated in larger transactions and won't be anywhere near the fee limit, unless you bought them in several hundred separate transactions.  Even if you do reach the fee level, you only have to pay it once to bundle your little transactions together.

Theymos already said this...  ECDSA does not support encrypting messages.  Only digital signatures.

Probably best to disable receiving by IP unless you specifically intend to use it.  This is a lot of surface area that nobody uses that doesn't need to be open by default.

In storefront cases, you would typically only want customers to send payments through your automated system that only hands out bitcoin addresses associated with particular orders and accounts.  Random unidentified payments volunteered to the server's IP address would be unhelpful.

In general, sending by IP has limited useful cases.  If connecting directly without a proxy, the man-in-the-middle risk may be tolerable, but no privacy.  If you use a privacy proxy, man-in-the-middle risk is unacceptably high.  If we went to all the work of implementing SSL, only large storefronts usually go to the trouble of getting a CA cert, but most of those cases would still be better off to use bitcoin addresses.

I uploaded this change to SVN rev 156.  The switch to enable is "-allowreceivebyip".

Senders with this version will get the error "Recipient is not accepting transactions sent by IP address".  Older version senders will get "Transfer was not accepted".

I used a different name for the switch because "-allowiptransactions" sounds like it includes sending.  If there's a better name for the switch, we can change it again.

I don't know anything about any of the bug trackers.  If we were to have one, we would have to make a thoroughly researched choice.

We're managing pretty well just using the forum.  I'm more likely to see bugs posted in the forum, and I think other users are much more likely to help resolve and ask follow up questions here than if they were in a bug tracker.  A key step is other users helping resolve the simple stuff that's not really a bug but some misunderstanding or confusion.

I keep a list of all unresolved bugs I've seen on the forum.  In some cases, I'm still thinking about the best design for the fix.  This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them.

The lines it's tripping on:

So it's acting like nothing is defined, not even map and vector.

Yet, db.h is included by headers.h (and only there, nowhere else) which includes vector, map, util.h and everything before db.h.

Is VC trying to use precompiled headers and screwing it up?  Could there be some leftover precompiled header files in your directory from previously failed attempts that it's finding and using?

There's an installer package now that makes it really easy to install MinGW.  Don't use the latest version 4.5.0, use a few versions back like 4.4.1 (1.908.0) or 1.812.0.  A setup program completely installs everything, it's not hard like it used to be.  I think the only thing I had to do was rename make*.exe something to make.exe.
http://tdm-gcc.tdragon.net/

Off topic, but: It would be nice if someone would hack on getting tcatm's 4-way 128-bit SSE2 code working on Windows.  There's something with MinGW's optimisation, I'm not sure but maybe a problem with 16-byte alignment on the stack, that makes it segfault.  With some fiddling, I was able to get his code to work in a test program, but not in Bitcoin itself for some reason.

Bouncing between 0 and 2 connections could be if it's connecting to itself.  Are you using the "-connect" switch?

Did you compile it or is this a release build, and what version?

I'm not sure how the 200Kb/sec, since it waits at least a half second between connection attempts.  How fast is it flickering between 0 and 2 connections?  Faster than twice a second?

The wait function on linux is:

inline void Sleep(int64 n)
{
    boost::thread::sleep(boost::get_system_time() + boost::posix_time::milliseconds(n));
}

If that doesn't work right, then it would be possible for it to spin through the loop as fast as it can.

If the only library is closed source, then there's a project to make an open source one.

If the only library is GPL, then there's a project to make a non-GPL one.

If the best library is MIT, Boost, new-BSD or public domain, then we can stop re-writing it.

I don't question that GPL is a good license for operating systems, especially since non-GPL code is allowed to interface with the OS.  For smaller projects, I think the fear of a closed-source takeover is overdone.

Trying it without the DB_PRIVATE flag in rev 153.  We need to keep an eye on what's different.

On Windows at least, it creates six __db.001 - __db.006 files with sizes from 24K to 4MB.  It doesn't delete them on exit, it just leaves them behind.

The docs say it uses memory mapped files.  I assume they have the same file permissions as the database files, so the same user access restrictions apply.

Tests on Windows private LAN download of 78500 blocks:
with DB_PRIVATE     20 minutes 51 seconds
without DB_PRIVATE   20 minutes 51 seconds

I wasn't expecting them to come out exactly the same.

Is there a way to open BerkeleyDB exclusive?

DB_PRIVATE is the worst of both worlds.  DB_PRIVATE is not exclusive, but it does make it get screwed up if another process tries to access it at the same time.

I've dropped the DB_PRIVATE flag in rev 153.

Added in SVN rev 152

The fix is in SVN rev 151.

You will be able to send your stuck 0.01 (actually 0.01000010) when you next upgrade.

I think I know what happened.  Doubleclick on the generated transaction.  It probably has a sub-0.01 transaction fee in it.

Someone has been paying a 0.00000010 transaction fee.  I don't think you can even set that with -paytxfee, I think you'd have to modify the code to do it.  Your generated block is worth 50.00000010, so when you try to send the whole thing you have 0.00000010 left over for the change, which triggers the dust spam 0.01 fee.

It would normally be harmless except in this corner case.  I should add a special case to CreateTransaction to handle this.

What version is the one where this happened?  Release build, or built it yourself?  Which operating system? 

Were you sending by IP or by Bitcoin Address?

When you sent 49.99, did it prompt you to pay a 0.01 fee?

There was a change in GetMinFee, but I can't see how it would cause this.  It only starts to apply when a block gets huge.

The reason for the difference in block number is the number displayed was reduced by 1 in 0.3.11 because it made more sense that way.

SVN rev 150 has some code to try to auto-detect whether to use 4-way SSE2.  We need this because it's only faster on certain newer CPUs that have 128-bit SSE2 and not ones with 64-bit SSE2.

It uses the CPUID instruction to get the CPU brand, family, model number and stepping.  That's the easy part.  Knowing what to do with the model number is the hard part.  I was not able to find any table of family, model and stepping numbers for CPUs.  I had to go by various random reports I saw.

Here's what I ended up with:

I saw some sporadic inconsistent model numbers for AMD CPUs, so I'm not sure if this will catch all capable AMDs.

If it's wrong, you can still override it with -4way or -4way=0.

It prints what it finds in debug.log.  Search on CPUID.

This is only enabled if built with GCC.