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.

You know how I say "I make mistakes, don't trust me" ...

A bug in my code is dropping transaction fees from the block reward. Simple to fix, and obvious in hindsight; I will be personally reimbursing everybody who got bit by this bug by finding the blocks affected by this, figuring out what transaction fees the creators SHOULD have received, and sending that number of bitcoins to the block-award address.

Backports and the main git HEAD tree have been patched with the fix.

---

On a higher level:

There is obviously not going to be 50+% blockchain support for BIP 16 on Tuesday; I'm going to start conversations on how to move forward.

And there has obviously not been enough testing of the BIP 16 code. Getting people to thoroughly test things BEFORE code makes it into the main tree has been a chronic problem, I'd appreciate ideas on how to avoid this kind of annoying, time-wasting "it's ready"/"oops, found a bug"/"it's fixed"/"wait, no, somebody found another bug" thing in the future. I've been unsuccessful finding the kind of QA (quality assurance) person who can both do the QA and do the fundraising necessary so they get paid.

Yes, you will confuse the GUI if you send coins to 'change' addresses.

My advice would be "don't do that."

Thanks very much for helping to test, though, it is very appreciated!

Just FYI: I contacted the top ten mining pools (as listed in the stickied threads in the Mining Pools subforum) directly via email way back in October, copied the email to them in the Mining Pools forum, and kept them 'in the loop' on all of this.

I probably should have posted all of my followup emails to them in the Mining Pools forum, also; as I said, I'm terrible at that kind of "keep track of who you've told what and make sure you've got 'buy-in' from X Y and Z" thing.

I think my only really major blunder was being too stubborn about inserting some wording into BIP 16 that Luke wanted inserted; I let my emotions cloud my judgement.