I can't say I've entirely understood how BIP16 or BIP17 work (but I'm not completely ignorant of them); however:

• BIP16 feels "hackish"; that is not to say BIP17 is therefore "the one", and it might be that an as yet unwritten BIP18 is the answer.  That being said, there is an awful lot of "hackish" already in the scripting part of bitcoin... OP_CODESEPARATOR makes me uncomfortable anyway.
• The inertia needed to be overcome for a change, suggests that changes should be made very judiciously.
• Deadlines are for closed source software.  The most uncomfortable part about this for me was the sudden announcement of a deadline.

In general: I think if there is controversy, then the answer is not to rush it is to delay.  But  then again... I'm not the project lead am I? 

I don't actually think that this proposal can break something, but rather expect some better solution for this problem.
Well, I also believed that Gavin's OP_EVAL patch is good too because he is Gavin, and Deepbit was the first pool to support and vote for OP_EVAL. Until it turned out to be exploitable, buggy and not the thing Gavin really wanted. Luckily no harm was done, but lesson learned.

1 Objection: there are clearly no consensus between devs or miners about the exact method of implementing pay-to-script thing. That's the reason I would prefer dividing it into two separate stages - 1) implement plain multisig and long-address multisig support, 2) decide about pay-to-script method and move 1 into it.
This would give us both time for deciding on stage 2 and allow 2-factor authentication and escrow-services support with a small downside of using pubkeys instead of pubkeyhashes and a bit longer output scripts.

2 Objection: (less important) this proposal makes strange use of scripts: it's like having a compiler that can only allow the source to contain just one line #include "source2.c", which contains the actual script. Somewhat hackish. I would prefer either normal scripts or no scripts at all in TX's output.
Also I don't like the script to be in serialized form, but this is not a real downside at all.

3 Objection: I don't want to become the single entity to decide on this. That's exactly the opposite of what Gavin says. With current 2% ofP2SH/ support Deepbit would be the force to pushP2SH/ into existence, not the other way around.

Actually AFAIR, the "voting" ENDS 1 Feb.

Well, this just proves my point that the whole situation is a mess. The 2 percent support still doesn't tell us what the real opinions are, for example Slush has stated that he supports P2SH and his pool is much more than 2 percent. I'm not quite sure which BIP he prefers, however.

No. Luke-jr initiated a rumor that Gavin is hired by some company going to produce hardware/software solution for 2-factor authentication and this is the reason he is pushing so hard.

Disclaimer: I don't think that this is true.

No, the whole point is in having private keys on separate devices.

I think the deadlines are right now the biggest problem and many seem to agree with that. This has a very low chance of working out with these deadlines I believe, but there can always be a new vote.

This is a good point. I'm not against you personally, I just believe it's unhealthy for a few individuals (including you) to hold too much power over the development of Bitcoin.

The same thing is true with Bitcoin that is true in politics, people who do not have power do not care and thus remain ignorant of the issues. Studies of the Swiss direct democracy system have proven that when people feel they have more power, they study the issues at hand much more carefully.

This is why it's in all of our best interest if miners in general become a bit more aware of their voting possibilities.

I hope people don't get turned off or frustrated by this process…that's exactly what this is, a process.  I think some people have allowed what should be an objective debate on technical merits to turn a little personal and have said things that they probably regret.  And people shouldn't allow themselves to get their identity wrapped up in a solution that they've proposed.  A rejection of a technical proposal is not a rejection of you as a person.  I have no reason to believe that anyone here is acting in anything but the best interests of bitcoin.


I want to voice my opinion against long-address multisig.  In my opinion, that's the last thing that should be implemented (actually, it's not the last thing that should be implemented…it should *never* be implemented…it's even more hacky than BIP-16).  P2SH is the proper way to handle multi-sig (and many other types of transactions).  And as I've said earlier in this thread, all transactions should eventually be P2SH.  P2PK (pay to public key…the current style transactions) is a just special case of P2SH.

Lastly, everyone should be in favor of implementing P2SH in some form.  The kind of transactions it enables will add great value to bitcoin.  In fact, if bitcoin doesn't do this, it will create an opportunity for a competing coin that does provide this innovation…this is the kind of fundamental improvement that could allow an alt-coin to overtake bitcoin.  So, everyone that has invested their time and/or money into bitcoin should be in favor to getting this implemented.

As I've been asking in other threads, but have yet to get an answer, I will ask here again.  Why is this such a rush?  Why the secretive "upgrade?"  What is wrong with this proposal that it requires it to be force pushed through at such a rapid pace?

This needs to be weighed and measured and the potential consequences thought out.  Why is this not being done?