This has been lingering for months, and got bogged down in discussions of some nifty new mega-efficient binary protocol for stuff.  That hasn't happened.  So:  https://github.com/bitcoin/bitcoin/pull/198

This adds these new RPC commands:

monitortx/monitorblocks: POST JSON-RPC to a URL when new wallet transactions or blocks are received.
listmonitored: list URLS that will be POSTed to
getblock: get information about a block, given depth in main chain.

monitortx posts the same information you get from gettransaction.
monitorblock/getblock posts:

No, the send-from address is not available, for a couple of reasons:

1)  When people using a shared wallet service like MyBitcoin or MtGox send payments the "from address" could belong to any of the other users of the service (or could be a "change" address that doesn't belong to anybody).  It is a bad idea to think that "address == person".

2) If more complicated transaction types are ever "turned on" in bitcoin, there might be more than one "from address".   Satoshi designed-in support for complicated transactions like "this payment can only be spent if 2 of these 3 keys sign the transaction".   In that case, there would be two "from addresses".

If you need this to refund coins, you'll need to ask the customer for a refund address.

If you want each receiving address treated as its own account, you can:
setaccount <address> <address>
... and then use <address> as the name of the account.

And validateaddress will tell you what account is associated with an address.

+1

I'll brain-dump my second half-baked idea of the day:

github has a nice API for basically everything it does (issues getting closed,etc).

I've been working on an API for ClearCoin (creating escrow accounts, etc).

Marrying the two might work nicely.  Coders could publish their bitcoin addresses in their github profiles.

Bounties could be established for bugs (or, grumble, features) by creating a ClearCoin account, linking it to the issue (maybe by posting a machine-readable comment via the github api).

And when the issue was closed via a commit the bounty could be automagically paid to the coder(s) who contributed to the commit.  (somehow... via a yet-to-be-written way for ClearCoin to get a where-to-release-coins address that is not set in advance).

Reasons not to do it:  allegations of corruption/favoritism if people doing the pulling have to decide between two pull requests.  Maybe less cooperation to find/fix things if people are competing for bounties.

Half-baked thoughts:

Broadcasting policies makes me nervous-- it is too easy to lie, and there might be some advantage to lying.

Couldn't clients infer all the information they need to know about what transactions/fees are being accepted by miners by keeping track of transactions in the memory pool and looking at the last 10,000-or-so generated blocks?

Block 70136 has 0.03BTC in un-spendable transactions.

9050+
     0.03
---------
9050.03

TED is about "the vision thing"; somebody really good at public speaking and putting together compelling presentations should do it.

Somebody who actually enjoys travelling around and speaking about something they are passionate about.  I want to spend my time building stuff, not talking about stuff.

PS:  I think bitcoin needs another year of growth before it is TED-worthy.

The project needs more bug fixing and testing, so I would rather NOT see bounties for new features.

Bounties for fixing bugs would be ok.  And maybe a bug bounty, for finding significant bugs.

+1

So, team:  anybody interested?

I was actually thinking a return address would be a good use for the arbitrary-message-to-receiver OP_DROP transaction type.

Maybe make a convention that bytes be a JSON dictionary, so it could be:

{'return_address':'n2cGZYsiii1uAiDPM6ipPBqqXa4Z9bXh2t'} OP_DROP ...etc...

... which would be inefficient (58 bytes to encode the 20-byte return address) but wonderfully extensible.

And again:  I'd like to see experimentation on testnet.

The latest version of bitcoin does try to avoid "sub-cent change" by adding more inputs.

If it can't avoid it (e.g. you have 32.29 in your wallet and you send 32.28999999), then the sub-cent change becomes a sub-cent transaction fee.  It isn't lost, the miner that includes the transaction will get it.

bitcoind doesn't prompt before adding fees because it is meant to be used by websites and other services where there may not be a person available to push an "Ok, pay a fee" button.  There might not even be a place to put the button, either.

Your Transaction 2 paid a fee because it ran into the "small, low-priority transactions must pay" code that is new with version 0.3.21.  It was low priority because its outputs were small and its input was fairly new.

Bitcoin 0.3.21 puts a 'bestblock' entry in the wallet so it will automatically -rescan if you restore an old wallet (and it only rescans the blocks necessary to get up-to-date).

RE: agreed upon spot to place or distribute messages:

I think it is time to start experimenting with a <bytes> OP_DROP OP_DUP OP_HASH160 ...etc transaction type on the testnet.

And time to finish implementing headers-only-for-initial-download mode so new users don't have to wait so long to get their free Faucet bitcoins.

You're suggesting:
ECDSA_SIGN(SHA256(RIPEMD160(SHA256(public_key))+"fixed string"+message))
 is more secure than:
ECDSA_SIGN(SHA256("fixed string"+message))

It sure looks more secure!  But maybe some super-smart cryptographer will tease out a relationship between all the hashing and signing in the first version and it will turn out to be less secure; maybe she'll figure out a way to factor out the private key if the public key is involved in the salt.

I like the simpler version better.

Neat idea!

I don't like the economics of it, though.

First, it reinforces the "if you started mining early you are rich only because you were lucky enough to be early" idea.  And a lot of people already think that is unfair; give the early miners a current mining discount and you're just "helping the rich get richer."

Second, what stops an attacker from offering early miners $$$ for their (already spent) coinbase private keys?  If they have value because they give a mining discount, then there WILL be a market for them.  A wealthy attacker could just buy up as many as they can find and then take over the network with less hashing power...

All command-line options (except for -datadir and -conf) can be specified in the config file.

I launched a new version of the Bitcoin Faucet today, with a few changes:

1. Payout is now 0.02 bitcoins (down from 0.05), to reflect the rise in value of bitcoins versus other currencies.

2. Recent Sends page, showing scrambled email addresses and (not scrambled) IP addresses of the last 100 people to get coins from the Faucet.

3. Behind the scenes, faucet payouts are bundled up and sent in batches every N minutes, to minimize the fees that the Faucet pays.

I want to recruit some trusted volunteers to be "Faucet Police" -- if somebody notices a fishy pattern of either IP addresses or email addresses, I'll give the Faucet Police the ability to temporarily stop the flow of coins from the Faucet.

If you're willing to help out and you've got a good reputation/history here on the forums, email me (gavinandresen@gmail.com) your google account information along with what time zone you're usually in, and I'll try to pick a couple handfuls of people so no matter what time of day or night, somebody will be awake and ready to turn off the spigot.