I think everybody would like to merge bitcoin-qt as soon as the 0.4 release is shipped (see the bitcoin-dev mailing list for the current known bugs).

Closing the dozens of wxWidgets-related GUI bugs in the issues list will give me great pleasure...

Y'all probably want this:
  https://github.com/bitcoin/bitcoin/pull/491

However, I don't think you can fix all the problems that a fixed transaction fee cause; the real problem is that basic economics says that you need to let the price of a scare resource change, ideally in a market, to match the underlying real costs.

(bitcoin's fee structure isn't right either, and fixing it to create a market between miners and clients is high on the TODO list)

Good idea.

The developers listed on bitcoin.org are the people who have 'push' rights to the github source tree, but I like the git approach.

Who wants to volunteer to make it happen?

Optimizing the accounts code to add a berkeley db index table that indexed wallet transactions by account, and that cached account balances (and invalidated or updated the cache on receive/send) shouldn't be terribly hard for somebody who already knows c++ and berkeley db.

It is not on my short-term TODO list because there are too many other higher priority things on my TODO list, but a nice clean well-tested upward-compatible patch would be most welcome.

PS:  for ClearCoin, I used the "bitcoind keeps track of the bitcoins" architecture, and I never regretted it-- no problems with synchronization, less possibility for MtGox-like hacks that create mythical bitcoin balances out of thin air by adding an entry to a database.

+1

No hard limits, but the bitcoind "accounts" code hasn't been optimized for that.  For example, computing an account's balance loops through all transactions in the wallet, so will take an increasing amount of time the more transactions you have in the wallet.

I got a copy, too.  If you use gmail, use the 'Report phishing' function (in the Reply drop-down menu).

Those are "Proposal 1" -- enabling all the 'plain-old' OP_CHECKMULTISIG transactions.

groffer reports finding a bug in CHECKMULTISIG (pops too many items off the stack), which makes me wonder if it would be better to avoid it. For small n, using CHECKSIG multiple times is straightforward and doesn't make the transactions much larger.

The (a and b) OR c transaction with public keys instead of addresses isn't in the proposal, but for consistency's sake I agree it should be.

My worry is that we'll schedule a blockchain split 6 months from now, and between now and then somebody implements a secure, way-cool, everybody-decides-to-use, way to use your email address as a bitcoin address.

So my receiving address is 'gavinandresen@gmail.com' and suddenly all the arguing over length of the bitcoin addresses used behind the scenes was just a huge waste of time.

I'm as guilty of doing stuff like that as the next geek-- I can get so focused on one little bit of a problem I don't even realize solving a larger problem makes the whole issue go away.  Slap me upside the head if you see me going down that path...

Phew.  Ok, I feel better; consensus seems to be that enabling some or all of the proposed 'new standard' transactions is a good idea.

All the rest (new address format?  send to old addresses and immediately resend?  etc etc etc) can be argued to death later.

Because I want to enable these features reasonably soon, and modifying the way CHECKSIG works means a blockchain fork for clients that haven't upgraded.  Which means giving at least 6 months notice to give everybody time to upgrade their clients.

At some point that will make sense, but with what I'm proposing it is not necessary. When SHA3 is finalized or a weakness is found in ECDSA or SHA256 maybe it'll be time to do that...

I uploaded a PDF file of my slides here:
  http://skypaint.com/bitcoin/DevDirection.pdf

Clients could make c the base for a deterministic key; derive a series of keys from c, and use them in subsequent transactions.  (given full public key for c, you can derive a series of public keys without having the private key)

Same could be done for the 'wallet protection service' key b -- every time you use b, contact the protection service and ask for a b' derived deterministically from b.  Then b'', b''', etc...

The multi-device use-case I'm imagining:

I sign up with Acme Bitcoin Security Solutions, Inc.  They give me a WalletProtection public key (or bitcoin address, doesn't matter) and a unique-for-me URL.  I put the address/pubkey into my bitcoin client as "Second factor off-device Send Authentication." Or something.
(ABBS also sends me the private key in the mail and tells me to keep it safe in case they go out of business)

Now I want all coins sent to me to require signatures from keys in my wallet AND the ABBS key to spend.

What bitcoin address do I give to people so that all coins going into my wallet have that property?

If it is raw CHECKMULTISIG, then I need to give out addresses containing 2 full public keys.  Which would be 186 characters in base58 and look something like this:
LeFKX5Uhue9B4bVNqFouRdH9xyJ4uVksV16Gc3v5Kov6SEtyUmKmF3j582VHcmhKGEfBXvrft6SHAq4 SQPw5kbGryZj4aGqZKGFSPsotRJvrmQXCT8qZ2LZd3KyxFLDt1rsBx2uisukHPvBnyCpbyVdgNhyQYn z3Cf4oakK9Rm6oxFHwjHxHnnbdW3

Using 20-byte hashes and the more complicated 2-of-2 transaction i'm proposing, the address is a more reasonable 61 chars:
2SEe6qhJ11baZfpk9qXt3gfz3qAgFj4BMc2FXh9ojoBoLU4GAhft1hJAb5TAK

You're right, I think even without blockexplorer Satoshi would've added the IsStandard() check.  There were a series of "oops, didn't think of that" moments that pushed him to disable a bunch, tighten up some requirements on existing opcodes, and add IsStandard().

In general, I believe in "whitelisting" instead of "blacklisting" to try to prevent harm. Enable functionality that you can prove (or convince yourself beyond a reasonable doubt) will not cause problems. I'm strongly influenced from watching web content systems that fail repeatedly trying to detect malicious HTML or CSS.

RE: allow non-standard transactions but give them a very low priority so they take a very long time to confirm:  I like that idea.  I'll have to think a little more about possible unintended consequences (will they tend to fill up transaction memory pools and crowd out low-priority standard transactions?  Do they need their own memory-limited pool?  etc)

The intent was always to relax the rules when SPV/headers-only mode was implemented and non-mining clients didn't need to download the entire block chain.  However, nobody tackled that work (it is on my TODO list, right after I tackle some testing framework work).

Sunday at the bitcoin conference I led a little brainstorming session on extending the set of 'standard' transaction types, and I've been picking people's brains via email and IRC chat (and pull request comments) to work through the details.

My motivation for wanting to do this NOW is because it will allow features like:

+ Multi-device confirmation of spends, so if your computer is infected by a trojan it cannot spend all of your coins.

+ Master-key emergency backup, so if you lose your wallet (and all of its backups) you can get the master key from your safe deposit box and recover all of your coins

It will also enable third-party escrow and some other nifty features that aren't as important to me.  The first step in doing all of these things is to work out the lowest-level transaction format and to allow those transactions to be relayed and included in blocks.  That is ALL I am proposing right now (actually implementing something like multi-device spend confirmation will require a little protocol for the devices to communicate, a new kind of bitcoin address that people will send into, etc etc etc).

Working out a common way of doing (for example) 1-of-2-keys-required transactions will make it much easier for sites like blockexplorer to display them intelligently, and will generally make life happier for anybody writing tools that look at the blockchain.

I'd rather not have this turn into a "lets get rid of the IsStandard() check" or "lets re-enable a bunch of currently disabled opcodes", so if you want to talk about that start a new thread.

Current draft proposal is here:
  https://gist.github.com/39158239e36f6af69d6f

I've been working on a proposal to enable {1,2}-of-{1,2,3} signatures-required as standard transaction types.

I'll start another thread with more information...

I enjoyed the conference, and I usually hate conferences.

Apologies to everybody who I met and whose name I've already forgotten.  My secret super-power is forgetting names.

And congratulations and a big Thank You to Bruce and company for organizing and making it happen!

If you need a stable testing environment, the self-contained testnet-in-a-box works very nicely:
  https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/

You do have to remember to run -noirc or keep your testnet listen port closed, because if a 'real' testnet node connects to you you'll get the 'real' testnet block-chain.

Why couldn't the-collective-we only revoke the double-spends (and subsequent txns that depended on them) ?

A hard-coded list of invalid txids wouldn't be hard to insert into the is-valid-transaction checks, and that along with a blockchain checkpoint would work just fine.  Valid transactions on the bad chain would move to the new chain (actually, they'd already be on the non-attacker chain, since the miners on both sides of the block split would have included them).