BitcoinTalk

Version 0.3.18

BitcoinTalk
#1
From:
satoshi
Subject:
Version 0.3.18
Date:
Changes:
- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
- IsStandard() check to only include known transaction types in blocks
- Jgarzik's optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at http://bitcointalk.org/index.php?topic=1886.0).  
- getaccountaddress
- sendfrom
- move
- getbalance
- listtransactions

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/
BitcoinTalk
#37
From:
satoshi
Subject:
Re: Version 0.3.18
Date:
New transaction templates can be added as needed.  Within a few days, there will be plenty of GPU power that accepts and works on it.  Network support will be thorough long before there'll be enough clients who understand how to receive and interpret the new transaction.

Timestamp hashes are still already possible:

txin: 0.01
txout: 0.00  <appid, hash> OP_CHECKSIG
fee: 0.01

If there's an actual application like BitDNS getting ready to actually start inserting hashes, we can always add a specific transaction template for timestamps.

I like Hal Finney's idea for user-friendly timestamping.  Convert the hash of a file to a bitcoin address and send 0.01 to it:

I thought of a simple way to implement the timestamp concept I mentioned above. Run sha1sum on the file you want to timestamp. Convert the result to a Bitcoin address, such as via http://blockexplorer.com/q/hashtoaddress . Then send a small payment to that address.

The money will be lost forever, as there is no way to spend it further, but the timestamp Bitcoin address will remain in the block chain as a record of the file's existence.

I understand that this is arguably not a good use of the Bitcoin distributed database, but nothing stops people from doing this so we should be aware that it may be done.
BitcoinTalk
#39
From:
satoshi
Subject:
Re: Version 0.3.18
Date:
I came to agree with Gavin about whitelisting when I realized how quickly new transaction types can be added.

why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?
That's already possible.  <pubkey> OP_CHECKSIG.  <pubkey> can be 33 to 120 bytes.

I also support a third transaction type for timestamp hash sized arbitrary data.  There's no point not having one since you can already do it anyway.  It would tell nodes they don't need to bother to index it.