Bitcoin has powerful scripting capabilities I assume will just be expanded to include the new hashes for the security of actual bitcoins and transactions.

As for using SHA-256 as a proof of work, it doesn't really have to be collision-free, since the data that is hashed is pretty well pre-determined.  Since all that matters is that it's difficult to solve, I don't think the blockchain will need to be upgraded with a different hash.

All the transactions are public already, by Bitcoin's design.  As for the addresses used, it's true that publicly available addresses for any reason can be discovered, although it doesn't really matter, as you publicized it.  The privacy of Bitcoin comes from the concept that you can just create an address and send some btc to it, and now nobody knows who owns those coins.

What exactly is the difference between move and sendfrom?  Is it just shorthand for getting the account address and sending the coins to it?  How does a moved coin act in the block chain?

A bunch of the current debate about including BitDNS or BitX makes assumptions that miners will include transactions or not based on some rather fine-grained conditions, while none of the standard code includes any sort of implementation that allows non-programmers to make decisions like that.  How will I, the user, figure out what sort of fees have to go into a transaction?

The white paper allows for individual servers to drop transactions, so long as they maintain the hashes in the Merkle Tree.  So eventually, once the transaction server software is more advanced, the DNS servers could delete all the non-DNS server transactions, which would reduce it's storage requirements, and all the currency people can delete extraneous DNS transactions.

It is a tree, so it would be best if all transactions of each type were grouped so that you could delete one node, and reduce the Merkle Tree as much as possible.  Otherwise, all other transactions do is increase the number of transactions.

Also, as far as adding new data into transactions, maybe the best way to go about it is to introduce the data to the actual blockchain only when we also have the granular controls on mining and what people want included when they mine, and for what fees.  I think having a well thought out fee data distribution is going to end up crucial to bitcoin, so that way when bitcoin users go to make transactions, they can determine the likelihood of their data getting into a block.

Until we have this more effectively thought out, all the non-bitcoin stuff like BitDNS should go into the testchain.

What's the point of a scripting engine if you're only able to have "standard" transactions?  Not really good for scripting.

I did shrink the hashes, they're now fixed so they can be the 32 bytes they are. http://pastebin.com/zQEyKV0A

Could you please point me to where the transaction and block data is in the source code?  I thought I already had them encapsulated in the Tx and Block messages, but if there's more, having it all in one place can only help.

The current network serialization and implementation is really quite specialized, which is at cross-purposes to the goal of having several different clients that can all interact with the network.  I think that having our serialization and network data in a common format which already has several implementations in different languages would be very helpful to the long-term distribution of the bitcoin network.

In this view, I've created a quick and dirty Protocol Buffers version of the network protocol.  I doubt that it's particularly interoperable with the current code, but it does allow for all the information that goes over the network, according to the draft spec on the wiki.  I've uploaded the file at http://pastebin.com/SAgvHwa0