OK, it has been a couple of days and the general consensus seems to be a 'rolling' two-week window, with no "below 20%" rule.

I don't think there is any need for a two-week email discussion period among those familiar with the guts of Bitcoin, we've already spent months discussing the options and the consensus for BIP 16 is clear (see the tally here).

It is time to call it settled and move on to bigger and better things, like what protocol to use when a client needs to gather signatures (REST? JSON? http? https? something else?).

STOP IT.  JUST STOP IT.

BIP 16 has overwhelming support, it will be the solution.

Casascius:  please read BIP 0001 for the process to get assigned a BIP number.  The process is not "create a page on the wiki."

As for the proposal itself:  No.

You are proposing a non-backwards-compatible change, which would mean a "hard" blockchain split. Everybody agrees that is a bad idea. The confusion and potential for hacks if a significant fraction of bitcoin users were on a separate chain is massive; you gloss over all of that in your proposal.

I moved Casascius' proposal ("BIP 22") to the Dev&Tech forum, I will respond there.

FYI: I pulled:
  https://github.com/bitcoin/bitcoin/pull/686

... which will likely result in a testnet blockchain split on February 15'th. I hadn't pulled before because I was busy with other things. The testnet faucet bitcoind will be updated in the next day or two.

See this thread for the design discussion.

Yes, exactly. At some point you have to say "enough is enough, I'm not going to let this person derail the project any more going forward."

I'm saying that point is right now; see the unproductive, one-sided argument about BIP 20 versus BIP 21 on the bitcoin-development mailing list that is re-hashing a wiki editing war that "the rest of us" just gave up on a year ago for the latest example.

You understand wrong.

BIP 16 recognizes a certain pattern of bytes, and says "If you see those bytes, then the script will be provided by the person who has the coins instead of the sender (the sender just provides a secure hash of that script)."

The script that is provided is then used EXACTLY as if it was a "normal" sender-provides-the-script transaction.

BIP16 is the most conservative possible solution to the problem we want to solve.

RE: debating ideas rather than people:  I've tried very hard to do that.

I said last year when I reluctantly agreed to function as the lead core bitcoin developer that I have zero experience leading open source projects.  But I try to do my due-diligence and learn from the experience of other successful projects.

The "aha" moment for me yesterday is the point in the video that I linked to, where the advice is to evaluate whether or not somebody causing issues for a project (whether intentional or not) is a net positive or negative to the project, and if they're "more trouble than they're worth" get them out of the project.

This isn't about BIP 16 versus BIP 17, this is about one person draining the rest of the development team with nagging, idealogical rigidity, and holy wars against "impure" ideas.

I try very hard to consider that maybe I'm wrong, but I think the evidence is clear.

You might also argue that the subversion people take the wrong approach, in which case please send me a link to some other open source project that has dealt with the issue in a different/better way.

I thought carefully about where to start this, and decided I might as well start it in the most public bitcoin discussion forum, because I think if I started it anywhere else it would eventually just appear here as "There's a Secret Conspiracy Started By Gavin To Oust A Valued Developer!"

bittenbob:

You replied 3 minutes after I posted.  You obviously didn't watch the video link I posted.

At that link, two experienced subversion (another successful open source project) developers talk about what to do if somebody in your open source community makes it impossible to have unity and agreement.

You say "we need to get back to unity" -- I agree.  That is why Luke must go.

Thanks to midnightmagic who directed me to this very helpful video about identifying and then dealing with "poisonous people" in open source software projects:
  http://youtu.be/ZSFDm3UYkeE

Advice on disinfecting:
  http://youtu.be/ZSFDm3UYkeE?t=34m22s

Watch the whole thing for examples of "poisonous person" behavior, like repeatedly flooding mailing lists/forums with their opinion or comments, not listening to the opinion of others, or making sweeping "the world will end if..." statements about the project.

I'll be blunt:  I think Luke Dashjr fits the definition of a poisonous person, and I think Bitcoin would be better without him. At the very least, we wouldn't be creating two BIPs for every technical issue, one for Luke and one for the rest of us (see BIP 16/17, and now we have BIP 20/21, too).

For context: makomk is the creator of CoiledCoin, a bitcoin alternative:
  https://bitcointalk.org/index.php?topic=56675

And RE: creating bots:  I created a BIP-17-stealing bot because it was really easy (took about 10 minutes of hacking).  A BIP-16-stealing bot would be a lot harder (because it would have to 'lie in wait' until the sender was redeeming the coins, and then race to relay/mine a 'stealing' version of the transaction before the rest of the network mined the original).

Transaction sent: 2d3006cf1e16cb9f4097894fdaa0739c66d38eb9e0356be3fd8daf63810cf375

I wrote some code that found all blocks with "/P2SH/" in their coinbase that did not include transaction fees in the block reward. I extracted the block reward payment address (or addresses, if it was a p2pool block) and reimbursed those addresses.

If the amount would be less than 0.0011 bitcoins, then I rounded the amount awarded up to 0.0011.  Just because eleven is my favorite number (well, and because I like the idea of rewarding p2pool users, I think p2pool is neat).

I've started a discussion on BIP 16/17 support moving forward (including trying to improve the testing process) here:
  https://bitcointalk.org/index.php?topic=61922.0

(please reply there so the discussion stays mostly in one place)

I've started a discussion on BIP 16/17 support moving forward (including trying to improve the testing process) here:
  https://bitcointalk.org/index.php?topic=61922.0

RE: rushing:

I'm starting a discussion on how not to rush here:
  https://bitcointalk.org/index.php?topic=61922.0

BIP 16 (or 17) will not meet their initial "go/no-go" deadlines.  You can see the state of support here: http://blockchain.info/P2SH

That's OK, that's why the deadlines were structured the way they are; in the past, Satoshi made changes like this by simply changing the code and then expecting everybody to upgrade. This is the first time we've used a more open, community-driven process.

So, since we'll miss the deadline, the question is:  what next?  To focus discussion, here are two straw-man proposals that y'all can agree or disagree with; I'll go along with whatever consensus arises over the next couple of days:

---

On the subject of testing... I've created a wiki page to record QA (quality assurance) testing that has been done on BIP 16.  If you can help test, or have been testing/deploying, then please add to this page:  https://en.bitcoin.it/wiki/BIP_0016_QA

As always, (on-topic) discussion, feedback, etc. is very welcome. If we can, I'd like to move past the "we dont' need to do ANYTHING" arguments, there is clearly rough consensus (with notable exceptions) that a short-bitcoin-address solution is needed.

Yes, that's the use-case I care most about -- you have control over all of your keys, you just put them in multiple places so if you lose control of (say) your computer you don't lose your bitcoins.

But there are other use-cases, like you agreeing to let the government control half the keys, so the government can "guarantee" the transactions, etc.  I can imagine the PR campaign: "It is just like Federal Deposit Insurance (FDIC), only for Bitcoin!"

I don't think that will ever happen, though. I know I wouldn't trust the government to keep the keys to my money safe and secure, I don't think most people would, either. More likely is most people will trust banks to hold half the keys, and the governments will then regulate the banks like they do today to get information about who is paying who for what....

So far, I think the pace of technological change has outrun governments' ability to figure out how to use it to exert control.

Maybe governments will get more nimble, but I'm going to continue betting that entrepreneurs and individuals will continue to widen the gap between the new freedoms that technology enables and what the law allows.

RE: multisignature transaction dangers:  I'm completely convinced the (large, practical) benefits far outweigh the (small, theoretical) risks that it'll be abused by some repressive government(s).

So the SolidCoin folks have been creating 1-post locked threads announcing stuff.

Putting aside how you feel about SolidCoin, I wonder what other people think about that practice in general.  It seems to me to go against the purpose of "Forums" -- seems to me the whole point is discussion.  If you don't want discussion, then buy an ad or publish information on your website.

Seems to me locking threads should be a last resort instead of "I'll just lock every thread I make to keep out the trolls."

I'm going to lock this thread now because I think some people will disagree with me.
(KIDDING, JUST KIDDING)

It is completely artificial urgency, so a decision is reached and implemented in a reasonable amount of time.

When I set the deadline, I had no idea Luke would:
  a) Decide that a bugfix 0.5.2 release was a good idea. I thought the minor bugfixes weren't worth taking the time to make a release but arguing with Luke is like arguing with a brick wall, so I went "meh, whatever."
  b) Propose BIP 17 and go on a war against BIP 16.

Both of those distracted from implementation and testing of BIP 16.

But what's past is past, the question is what do do from here; I'm planning on starting that discussion in the Dev&Tech forum tomorrow.

PS: RE: risk:  the risks of either proposal to the overall health of the bitcoin network are small.

The fees were 0 all the time, that was the bug.