you might think twice about that one.
see: http://www.theatlantic.com/magazine/archive/1982/02/have-you-ever-tried-to-sell-a-diamond/4575/

Sure, you could even achieve the same thing using the official bitcoin client, by copy-pasting wallets and creating one with the amount of bitcoins you want and sending that. The problem is that it's not very user-friendly and requires that the user actually has good understanding on what goes on "under the hood". Requiring users to create and send wallet files will also lead to many disastrous mistakes.

So I'm not really arguing for a way to send bitcoins through other means than a regular transaction, but rather a standardized user-friendly way to do it. The same way we have standardized QR-codes and standardized bitcoin-URLs it would be neat with a standardized file-type that "cointains" bitcoins and is recognized by any client that wants to implement it.

The arguments against using regular wallets:
1. It's unintuitive. If I send you regular cash through regular mail, I won't send it in a wallet. We should avoid confusion and let wallets be wallets.
2. Wallets are made to store bitcoins, not send them, and thus there is no standard protocol for them. Since wallets differ between different clients, you need to make sure the recipient uses the right client first.
3. It's not very user-friendly, and could possibly lead to mistakes by sending the wrong wallet etc.

The arguments against using strings of private keys as suggested in this thread:
1. Again, not user friendly. Preferably, a user should not even need to know what a private key is.
2. Exporting a private key means you need to make sure it holds the correct amount of bitcoins first. Creating a new key, sending the correct amount of bitcoins to it and then exporting it creates a lot of unnecessary steps, and possibility for mistakes.
3. Risk that you give away a private key that will recieve a transaction meant for you some time in the future. That won't happen with a standardized procedure.

Arguments for using a standardized new file type for this purpose instead.
1. Simple. It could even be a one step procedure, just enter an arbitrary bitcoin amount and click "create btc container". Everything else (creating a new private key, embedding it in the file and sending the bitcoins to the corresponding adress + any extra requirements/features for the container) could happen under the hood. To retrieve bitcoins from a container you simply open the file.
2. A file is familiar. Everyone already know how to manage, copy and share files to others. So the risk for mistakes since you don't know what you are doing is minimized. Required knowledge of cryptokeys and bitcoin wallets is zero.
3. There will be a clear distinction between wallets (which intuitively are supposed to be personal) and bitcoins meant for sharing with others.

Multibit seem to be a step in the right direction, sure. But the way I'm imagining it could be so much more user-friendly, intuitive and feature-rich. For example, by using nlocktime you could create containers that are automatically retrieved to sender if they are not redeemd before a specified time. A bitcoin client could also be created to recognize e-mail adresses in the adress field, and automatically create a container if you choose to send to a e-mail adress rather than a bitcoin adress. The most important part though, is that we have a standard between all clients, so that you don't need to worry about what client the recipient is using. The meaning of a *.btc file should be as obvious as a *.torrent file.

And as I've said, this could be huge for promotion. With a feature like this, any site with a public e-mail adress automatically accepts bitcoins in an easy and intuitive way.

Hmm just in case you didn't realise (though I'm sure most people do by now with the number of times this has come up on the forum)
The block reward halves every 210,000 blocks (4 years)
So in 210,000-173,094 blocks (= 36,906 blocks = 256.3 days) it will drop to 25 BTC per block.
Then again 4 years later to 12.5 BTC etc ...
So that also means that Bitcoin is getting close to being 4 years old soon

As the block subsidy declines over time fees will play an important role in miner revenue. 
[..]
We aren't talking massive fees but every bitcent helps.

Are you seriously suggesting "blockreward is quickly and dramatically reducing, we have to act now to still get any reward on mining blocks!!1!"? Really?

I cant seem to be reaching this site. Is it permanently down?

The "current payout" graph only displays bitcoins going to the default address.

I can't get 0.6rc4 to work anymore. bitcoin-qt is simply "Not responding" all the time. Is there a better version of bitcoin out there?

Why my payout drop down so dramatically?

DeathAndTaxes: Yes, it only listens for block invs, but also polls getmemorypool occasionally, so it does update the txs.

Ente: The share count varying is normal. Peers only exchange blocks of 1000 shares, when you start P2Pool, it loads more shares than it needs, and last, other peers that are downloading the sharechain may rebroadcast old shares that your node remembers for a while.

2012-03-24 18:13:12.926276 P2Pool: 18121 shares in chain (17488 verified/18125 total) Peers: 10 (0 incoming)
[..]
2012-03-24 18:13:15.121819 New work for worker! Difficulty: 1.000000 Share difficulty: 1000.000177 Total block value: 50.029500 BTC including 19 transactions
2012-03-24 18:13:16.006935 P2Pool: 17851 shares in chain (17488 verified/17855 total) Peers: 10 (0 incoming)

According to the wiki API reference, you should be able to do authentication stuff over the WebSocket interface.

Authenticated commands
These commands require an API key and secret pair to sign requests. Any of the HTTP API version 1 methods can be called.

I used this: https://bitcointalk.org/index.php?topic=49789.msg592388#msg592388, it works.

def get_nonce():
    return int(time.time()*100000)

def encoder(raw):
  dec = json.dumps(raw)
  return dec

def sign_data(secret, data):
    return base64.b64encode(str(HMAC(secret, data, sha512).digest()))


call = "1/info.php"
params = "testparams"
item = "BTC"
currency = "BTC"
id = "1234567890"

query1 = {'call':call, 'params':params, 'item':item, 'currency':currency, 'id':id, 'nonce':get_nonce()}

{'nonce': 133259594451109, 'item': 'BTC', 'currency': 'BTC', 'params': 'testparams', 'call': '1/info.php', 'id': '1234567890'}

query2 = encoder(query1)

{"nonce": 133259594451109, "item": "BTC", "currency": "BTC", "params": "testparams", "call": "1/info.php", "id": "1234567890"}

sign = sign_data(secret, query2)

xjAc1rbh0T4xFVJT/eZo/nxI4vXxiVmaZxbyM6a5RQtHqld2RW1y9HYdE9z/TlM5e9++P+MMWEd9YFdf6Nenqg==

query3 = sign, query2

('xjAc1rbh0T4xFVJT/eZo/nxI4vXxiVmaZxbyM6a5RQtHqld2RW1y9HYdE9z/TlM5e9++P+MMWEd9YFdf6Nenqg==', '{"nonce": 133259594451109, "item": "BTC", "currency": "BTC", "params": "testparams", "call": "1/info.php", "id": "1234567890"}')

call = {'op':'call', 'call':base64.b64encode(str(query3)), 'id':id, 'context':'mtgox.com'}

{'call': 'KCd4akFjMXJiaDBUNHhGVkpUL2Vaby9ueEk0dlh4aVZtYVp4YnlNNmE1UlF0SHFsZDJSVzF5OUhZZEU 5ei9UbE01ZTkrK1ArTU1XRWQ5WUZkZjZOZW5xZz09JywgJ3sibm9uY2UiOiAxMzMyNTk1OTQ0NTExMD ksICJpdGVtIjogIkJUQyIsICJjdXJyZW5jeSI6ICJCVEMiLCAicGFyYW1zIjogInRlc3RwYXJhbXMiL CAiY2FsbCI6ICIxL2luZm8ucGhwIiwgImlkIjogIjEyMzQ1Njc4OTAifScp', 'id': '1234567890', 'context': 'mtgox.com', 'op': 'call'}

socket.send("4:::{'call': 'KCd4akFjMXJiaDBUNHhGVkpUL2Vaby9ueEk0dlh4aVZtYVp4YnlNNmE1UlF0SHFsZDJSVzF5OUhZZEU5ei9UbE01ZTkrK1ArTU1XRWQ5WUZkZjZOZW5xZz09JywgJ3sibm9uY2UiOiAxMzMyNTk1OTQ0NTExMDksICJpdGVtIjogIkJUQyIsICJjdXJyZW5jeSI6ICJCVEMiLCAicGFyYW1zIjogInRlc3RwYXJhbXMiLCAiY2FsbCI6ICIxL2luZm8ucGhwIiwgImlkIjogIjEyMzQ1Njc4OTAifScp', 'id': '1234567890', 'context': 'mtgox.com', 'op': 'call'}")

{u'debug': {u'data': False, u'uuid': u'249bcb53-ccb0-43f1-bac6-e5ae0748e2e1', u'op': u'client'}, u'message': u'Unknown command', u'success': False, u'op': u'remark'}

P2Pool release 0.10.3 signed tag: 0.10.3 UPGRADE REQUIRED before April 1st (BIP 16 date), March 27th for Litecoin

* New graph implementation (works on Windows!) with per-miner graphs. Go to http://127.0.0.1:9332/static/graphs.html once installed to view.

RELEASE NOTES: You have to go to http://127.0.0.1:9332/static/graphs.html , not http://127.0.0.1:9332/static to see graphs.

Remember avg can be deceptive.  1/6th to 6x the average isn't that rare.  So shooting for goal of 1 share per hour means you will have some hours with 6 shares and sometimes go 6 hours (oops missed an entire block = payout) without a single share.  That can be frustrating for some miners.

Im down with this, what would your recomended settings be for 1.7GS/s. Also I wouldnt mind a detailed howto on the setup, I browsed ~5 pages backwards in this thread and cant seem to find one.