After much fruitful discussion and evolution, this proposal is now a series of "Bitcoin Improvement Proposals" -- see BIP 11, 12 and 13: https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals
Sincere thanks to everybody who contributed improvements, ideas and code.
Thanks for the feedback. I'm pushing this hard because I want much better wallet security and backup sooner rather than later.
There is no groffer proposal to pull (I think gmaxwell might take a shot at implementing the 2-of-3 case), and I don't see how to implement wallet security and backup on top of the fully-generic transactions (I'm probably just being dense).
Also, again: this isn't "either-or".
Please consider including the 2-of-3 case. This would enable simple escrow - buyer, seller, arbiter.
Oh, I just saw your comment just now after submitting my own. Great!
Btw, @gavinandresen, I forgot to say thanks for all your hard work :)
EDIT: for some reason the reply I sent by my phone (prior to your last comment) didn't post to github. Here it is:
Like most things, this could have been avoided with better communication. The following would have done nicely:
"Support for this minimum feature set is needed for 0.5's improved security features. The security of the whole network is improved by adding these transactions immediately. Support for generalized m-of-n transactions will be added as soon as a consensus is reached, but we deemed it necessary to split the process into two stages so as to get these new security features out the door ASAP."
FYI, for the future.
I can update my pull to implement the latest version of the generalized proposal within two weeks. I have not been motivated to do so because of the issues that @maaku raises. If such a pull will be seriously considered I can go ahead.
I don't see the problem with wallet security/backup on top of the generalized case. To get the a AND b OR c case, just use 2-of-2 OR 1-of-1.
Two weeks will be too late for the 0.5 release, and you'll need to split your PULL into two parts (just the IsStandard() changes and then another pull that adds RPC commands to generate the transactions; the IsStandard part has to be released first so users don't start generating might-take-days-to-confirm transactions).
I'm surprised you feel like all of this isn't being "seriously considered" given the amount of discussion and back-and-forth.
@gavinandresen - I feel that there is a reluctance to accept substantial contributions from the community. As @maaku I am also concerned about community trust and I think the success of bitcoin project depends on that and good communication. A decision was made even though the balance of arguments seemed in favor of the generalized solution.
As to code complexity, the IsStandard part of pull #319 is very simple - https://github.com/bitcoin/bitcoin/pull/319/files - wallet.cpp line 1125 to 1179. The only other part is a refactoring of Solver in script.cpp that is generally useful. Extending this to multiple OR clauses will be only a few more lines of code.
@gavinandresen: I meant simpler in terms for future maintenance, support, and extensions, since that will be an on-going, continuous effort whereas the implementation need only be written once.
Regardless, the real issue is one of community trust. You opened with a proposal for new m-of-n transactions types. A significant segment of the community responded that this is actually a special case of a more general need. Besides @groffer's work on an alternative proposal, there has been significant discussion on the forums about what kinds of things generalized m-of-n transactions would allow, and the discussion was not confined to the usual group of commentators. However without reaching consensus for or against, you go ahead and implement your own proposal and pull it into 0.5. The downside? Now I, @groffer, or anyone else who supported his proposal really don't feel motivated to put effort into any of your proposals in the future (not that I contributed much to this one, but I was still new to bitcoin-dev).
That's now how a community project is or should be run, and one need only look to successful community projects like Python or Django to see the difference.