OpenSSL doesn't have any interface for doing just the low level raw block hash part of SHA256.  SHA256 begins by wrapping your data in a specially formatted buffer.  Setting up the buffer takes an order of magnitude longer than the actual hashing if you're only hashing one or two blocks like we do.  It's intended that the time is amortised if you were hashing many KB or MB of data.  In BitcoinMiner, we format the buffer once and keep reusing it.

If you can find SHA256 code that's faster (with MinGW/GCC) than what we've got, that would be really great!  (although, keep licensing in mind)  The one we have is the only one I tried, so there's significant chance for improvement.

When I wrote it more than 2 years ago, there were screaming hot SHA1 implementations but minimal attention to SHA256.  That's a lot of time for them to come up with better stuff.  SHA256 was a lot slower than the fastest SHA1 at the time than I thought it should be.  Obviously SHA256 should be slower than SHA1 by a certain amount, but not by as much as I saw.

(hope you don't mind I renamed your thread, SHA-256 optimisation is something important that I keep forgetting about)

I uploaded to SVN my changes to add a password to JSON-RPC.  If you're set up to build, please test it.

The -server switch is replaced with -rpcpw=<password>, which is also used with bitcoind.
bitcoin -rpcpw=<password>    -- runs with JSON-RPC port open
bitcoind -rpcpw=<password>   -- daemon with password

If you have a better idea for the switch name, let me know, but keep in mind there will eventually be a password for encrypting the database too.  I'm not sure but I think they may want to use different passwords for the two.

It gives a warning if you don't set a password.

All commands now require the password as the first parameter.  It'll tell you that if you run "bitcoind help".

The central code:

  // Check password
  if (params.size() < 1 || params[0].type() != str_type)
      throw runtime_error("First parameter must be the password.");
  if (params[0].get_str() != strRPCPassword)
  {
      if (strRPCPassword.size() < 15)
          Sleep(50);
      begin = strRequest.end();
      printf("ThreadRPCServer incorrect password attempt\n");
      throw runtime_error("Incorrect password.");
  }

Any comments on these decisions?

1) if (strRPCPassword.size() < 15) Sleep(50);  -- this means if it's a short password, it'll wait 50ms after each attempt.  This might be used as a DoS attack, but I figured if it's a short password, it's more important to protect against brute force password scan.  This may tell outsiders whether the password is less than 15 characters, but less than 15 isn't all that noteworthy, most passwords are less than 15.  If you want to close the DoS possibility, just use a password 15 characters or longer.

2) begin = strRequest.end();  -- if it's a single request with multiple invocations, I throw away the rest if one has a bad password.  This is so you can't stuff it with millions of password attempts in one packet.  What do you think, is this the right thing to do?  (multiple invocation is probably almost never used anyway)

I also fixed the two duplicated commands listed in the help:

getaddressesbylabel <pw> <label>
getbalance <pw>
getblockcount <pw>
getblocknumber <pw>
getconnectioncount <pw>
getdifficulty <pw>
getgenerate <pw>
getinfo <pw>
getlabel <pw> <bitcoinaddress>
getnewaddress <pw> [label]
getreceivedbyaddress <pw> <bitcoinaddress> [minconf=1]
getreceivedbylabel <pw> <label> [minconf=1]
help <pw>
listreceivedbyaddress <pw> [minconf=1] [includeempty=false]
listreceivedbylabel <pw> [minconf=1] [includeempty=false]
sendtoaddress <pw> <bitcoinaddress> <amount> [comment] [comment-to]
setgenerate <pw> <generate> [genproclimit]
setlabel <pw> <bitcoinaddress> <label>
stop <pw>

The change list is basically encompassed by what's listed in the first message.  Everyone should upgrade to get the important security improvements.

Minimizing to tray had at least 3 different glitches and bugs on Linux, including a crash one, so I disabled it again.  You can still re-enable the option with "-minimizetotray" if you want to use it anyway.  The bugs/glitches are somewhere in wxWidgets or GTK or Gnome and I don't know how to fix them.  Sorry, I just don't know what else to do, it's just too glitchy and buggy to have as a mainline feature.

That's what I thought too.

Now I'm hearing a report that it IS possible for javascript to do a cross-domain POST request to 127.0.0.1.  Not other domains, but just specifically to that one.  Great...

If this is the case, then do not use the -server switch or bitcoind on a system where you do web browsing.

I'll get started on adding the password field.

They're only intended for intrepid programmers who read the sourcecode.

I didn't say impermeable, I said good-enough.  The loss in practice would be far lower than with credit cards.

No, the vending machine talks to a big service provider (aka payment processor) that provides this service to many merchants.  Think something like a credit card processor with a new job.  They would have many well connected network nodes.

In 0.3.0, the change to 8 only ended up in the Windows version, the other versions still had 15.

Please upgrade to 0.3.2, it's available now.

I didn't realize you were going to document all the intentionally undocumented commands.  They're unsupported and not intended to be used by users.

All the user-facing commands are listed in the -? help.

I went about 200 blocks back.  The block chain was a clean straight line without branches, and there was only one known version of the locked block.

Sorry, not yet, but I do want to make the initial block download faster.

Right, they'll re-appear when it's finished downloading all the blocks.

I believe it'll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less.

The network nodes only accept the first version of a transaction they receive to incorporate into the block they're trying to generate.  When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it's a race to propagate to the most nodes first.  If one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes.

A rough back-of-the-envelope example:
1         0
4         1
16        4
64        16
80%      20%

So if a double-spend has to wait even a second, it has a huge disadvantage.

The payment processor has connections with many nodes.  When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends.  If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad.  A double-spent transaction wouldn't get very far without one of the listeners hearing it.  The double-spender would have to wait until the listening phase is over, but by then, the payment processor's broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.

Download links available now on bitcoin.org.  Everyone should upgrade to this version.

- Added a simple security safeguard that locks-in the block chain up to this point.
- Reduced addr messages to save bandwidth now that there are plenty of nodes to connect to.
- Spanish translation by milkiway.
- French translation by aidos.

The security safeguard makes it so even if someone does have more than 50% of the network's CPU power, they can't try to go back and redo the block chain before yesterday.  (if you have this update)

I'll probably put a checkpoint in each version from now on.  Once the software has settled what the widely accepted block chain is, there's no point in leaving open the unwanted non-zero possibility of revision months later.

0.3.2 has some security safeguards to lock in the block chain up to this point and limit the damage a little if someone gets 50%.

But if someone has 50%+ of the CPU power and malicious intent, they can prove what it already says in the design document.

We should queue up a supply of pre-made addresses in the wallet to use when a new address is needed.  They aren't very big, so it wouldn't hurt to have a lot of them.  This would more generally cover the case also where someone backs up, then requests a new address and receives a big payment with it.  Maybe there should be separate queues so one type of demand on addresses doesn't deplete it for the others.

The addresses would be created and stored in the normal place, but also listed on a separate list of created-but-never-used addresses.  When an address is requested, the address at the front of the never-used queue is handed out, and a new address is created and added to the back.

There's some kind of rescan in the block loading code that was made to repair the case where someone copied their wallet.dat.  I would need to check that the rescan handles the case of rediscovering received payments in blocks that were already received, but are forgotten because the wallet was restored.

It must be a rounding error when getinfo converts to floating point to return the JSON-RPC result.  The only place where it uses floating point to represent money is returning a value in JSON-RPC.

1.139999999999 is longer than bitcoin can internally represent.

internally, it could only be:
1.13999999 or
1.14000000

1.139999999999 is much much closer to 1.14000000 than 1.13999999, so it must be 1.14000000.

The code is this:
(double)GetBalance() / (double)COIN.

(I can't think of an easy way to fix it at the moment)

0.3.1 fixes that, sets the generate threads to the lowest priority.  Download links are on the homepage now.

I uploaded windows 0.3.1 rc1 and linux 0.3.1 rc2 to SourceForge and updated the links on the homepage.

You don't need to update to 0.3.1 unless you had one of the problems listed in the first post.  If you've got it working already, stay with 0.3.0.

We need someone to write sample code, preferably Python or Java, showing the recommended way to use the JSON-RPC interface to create an account system.  Most sites that sell things will need something like this.  Someone who's kept up on the JSON-RPC threads here should have some idea how it should work.

When a user is logged in to their account, you show the bitcoin address they can send to to add funds.  Before showing it, you check if it's been used, if it has then you replace it with a new one (getnewaddress <username>).  You only need to keep the latest bitcoin address for the account in your database.  (I posted a sample code fragment for this in an earlier thread somewhere, search on getnewaddress)

You use getreceivedbylabel <username> with the username as the label to get the "credit" amount of the account.  You need to keep a "debit" amount in your database.  The current balance of the account is (credit - debit).  When the user spends money, you increase debit.

If you're requiring more than 0 confirmations, it's nice if you show the current balance (0 confirmations) and the available balance (1 or more confirmations), so they can immediately see that their payment is acknowledged.  Not all sites need to wait for confirmations, so the dual current & available should be optional.  Most sites selling digital goods are fine to accept 0 confirmations.

A nice sample app for this would be a simple bank site, which would have the above, plus the option to send a payment to a bitcoin address.  The sample code should be the simplest possible with the minimum extra stuff to make it a working site.

vekja.net is an example of a site like this.

Right, the difficulty adjustment is trying to keep it so the network as a whole generates an average of 6 blocks per hour.  The time for your block to mature will always be around 20 hours.

The recent adjustment put us back to close to 6 blocks per hour again.

There's a site where you can see the time between blocks, and since block 68545, it's been more like 10 minutes per block:
http://nullvoid.org/bitcoin/statistix.php

I've been trying to encourage someone to write and release some sample Python code showing the recommended way to do the typical accounting stuff, but to no avail.  It would be nice if you didn't have to re-invent the wheel like you're doing here.  Search on getnewaddress and you should find a thread where I gave a small fragment of sample pseudocode.