Yes, the next step is to get miners and clients to recognize a new 'standard' transaction type that does multisig.  BIP 11 describes them, they're already supported in git HEAD and by the p2sh code, and old miners and clients will recognize and validate blocks that contain OP_CHECKMULTISIG transactions.

I did some work today that should be useful to stress-test transaction handling for alternative bitcoin implementations:
  https://github.com/gavinandresen/bitcoin-git/tree/fuzzer

From its README.md:

Hacked version of Bitcoin that adds a "relayfuzzed" command. Note: this only works on the testnet.

USING THIS CODE

First, create one or more transactions using the send* RPC commands, and remember their transaction IDs. This version of bitcoin is modified so 'original' wallet transactions are not announced to the network.

Then, you can generate as many "fuzzed" variations as you like using the relayfuzzed command, which takes a transaction ID and an integer to seed a random number generator.

Example usage from a bash prompt:

The result should be a long list of fuzzed transaction ids, almost all of which are actually bad, invalid transactions. And a lot of "ConnectInputs failed" in testnet-box/2/testnet/debug.log

THINGS TO BE AWARE OF

You will trigger the denial-of-service-prevention code using this. If you are running a "testnet-in-a-box" setup (see https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/) then you don't have to worry, nodes running on localhost don't disconnect each other for bad behavior. Otherwise, you can run bitcoind with -banscore=999999 to avoid being disconnected.

Running the code being tested under Valgrind or Purify or another memory-corruption detection tool is a good idea.

Types of "high-level" fuzzing done:

Insert random opcodes at the front of the transactions's scriptSig(s)

Types of "low-level" fuzzing done:

Change bit in one of the transaction's bytes
Delete one or more bytes
Insert one or more random bytes

TODO:

Generate mostly-random scriptSig/scriptPubkey pairs that validate, and generate pairs/chains of valid transactions that spend them.

So what happens if I put two OP_P2SH's in a scriptPubKey?  What happens if I put one in a scriptSig? What if I put it inside an OP_IF ... OP_ENDIF ?

I think you're really just suggesting that the "magic" scriptPubKey be 24 bytes big instead of 23, and start with one of the NOP opcodes-- yes? In which case there is going to be a special case code path anyway.

Yes, of course. I did most of my testing on 'testnet-in-a-box' nodes, but spent a day producing P2SH blocks and transactions on testnet; see, for example this transaction that spends a P2SH transaction:
  http://blockexplorer.com/testnet/tx/cff697a07fa21780b2553c6e86bf956cb42838b0e9b226da2c6b3cd7754da736

Today I created a smart 'transaction fuzzer', and tomorrow I'll be creating and running stress-tests for the new p2sh and multisignature code to try to catch anything code review and unit tests might have missed.

notme is exactly right; the change is backwards-compatible, pool users don't have to do anything.

Pools and solo miners should upgrade, or they run a (very small) risk that they'll waste time hashing a block that can't be valid.

The risk is very small because it requires that somebody mine a block containing a /P2SH/ transaction that is valid-under-the-old-rules, invalid-under-the-new. That won't happen by accident, somebody malicious will have to create such a transaction and then find a miner who is willing to put that non-standard transaction in their block (and is willing to create a block they know the network will reject).

They would spend a lot of time (and therefore money) on an attack that would do nothing but slow down transaction confirmations a tiny bit and maybe trip up some random, unlucky mining pool or solo miner who didn't bother upgrading.



Gory details if you're not already bored:

Old miners and clients will ignore all /P2SH/ transactions; they won't relay them to other nodes and won't put them in blocks they mine, because they're non-standard.  So an attacker can't broadcast an invalid /P2SH/ transaction and hope it gets included in a block; they'll have to mine a block themself, or partner with a big solo miner or pool who is willing to produce bad blocks.

If an attacker DID manage to create a block with a timestamp after the switchover date and a bad /P2SH/ transaction in it, then some percentage of the network will try to build on that bad block.  Lets say 70% of hashing power supports /P2SH/.  That would mean only 70% of the network was working on a good block-chain, and the result would be transactions taking, on average, about 14 minutes to confirm instead of the usual 10 minutes.

In other words: they'd give up a $300 block reward and manage to just give the network a tiny little hiccup.

Is this open source?

The code is written and committed to the master branch, backports are available for every bitcoin release since 0.3.19, and I'm as confident as I can be there are no major bugs or "gotchas" hiding in the pay-to-script-hash code. Several of the big mining pools have been testing it and will start deploying it on the main network.

"This stuff" IS programmed in a way so it is only activated on the main network after an agreed-upon time.

There are still two weeks until we look and see how much support it has, and almost a month before /P2SH/ transactions are fully validated on the main network. You want to wait 30,000 more blocks?  More than 7 months? That's a darn good way to get everybody to ignore the issue for 6 months and then restart this debate from square one with 1 month to go and a whole fresh set of people who think they're being helpful suggesting using OP_ADD to combine private keys because they don't realize we thought about and discarded that idea 4 months ago.

No, that's not a realistic attack.

For an attacker to feed you a malicious block chain, they would have to be able to produce malicious blocks that have CORRECT proof-of-work. I don't think it is realistic to think that any attacker would throw lots of hash power onto a malicious block chain just so they can feed a bad block chain to somebody who connects to them.

Especially since that somebody would discover that their version of the block chain was incorrect within about 10 minutes, as soon as they got a new block message.

The bugfix was a "belt and suspenders" change to limit the potential damage from somebody who already had more than 50% of hashing power.

All righty, I mostly stepped away from the keyboard for a couple of days and I'm less frustrated and angry.

So first, I want to apologize to Luke for calling his CODEHASHCHECK code "a joke." I was frustrated that after weeks of discussion and gathering consensus around /P2SH/ he and piuk (and a couple others) decide it would be a good idea to propose slightly-different-but-not-obviously-better alternatives.

I still think Luke went about this the wrong way; for example, I think I would have been happy to accept a patch that made supporting /P2SH/ optional if he had presented it rationally instead of posting "ALERT! GAVIN IS HIJACKING BITCOIN! ACTION NEEDED!" I'd still be happy to accept a patch turning on/off the "put /P2SH/ in the coinbase" (assuming the general consensus is that is a good idea), but that's a discussion that should happen in the Dev/Tech forum.

In fact, most of the discussion in this thread on the merits of various proposals belongs in the Dev/Tech forum, and most of the concerns expressed here in this thread have already been discussed over the last several months.

piuk:  please read BIP 0001, it describes the process for getting BIP numbers assigned.

RE: Why OP_CODEHASHVERIFY is bad:

First, it requires that you concatenate the scriptSig and the scriptPubKey and execute them as on Script.

Bitcoin used to validate scripts that way, but ArtForz discovered a bug in July of 2010 (the OP_RETURN bug) that allowed anybody to spend anybody else's bitcoins.  It by far Bitcoin's biggest bug and Satoshi's biggest brain-fart.

Part of the fix was to make executing the scriptSig completely independent of executing the scriptPubKey (see commit 7f7f07 in the tree if you're really interested).

Is there some other subtle bug involving the interaction of OP_CODESEPARATOR, OP_CHECKSIG, OP_IF and the proposed OP_CODEHASHVERIFY lurking? I don't know, and I'm not about to risk all of Bitcoin to find out.

Second, Luke obviously isn't very familiar with all the details of transaction validation, or he would know that a scriptPubKey needs to leave a true value on the stack or validation fails.  So either OP_CODEHASHVERIFY both verifies AND leaves a true value on the stack (in which case it is inconsistent with the other VERIFY opcodes that consumer their operands) or it should be OP_CODEHASHEQUAL.

Third, the whole reason OP_EVAL caused controversy and was withdrawn is because adding a new opcode is more risky than adding a little extra validation logic.  OP_CODEHASHVERIFY is almost as risky as OP_EVAL.

Fourth, the code Luke posted is a joke. He doesn't modify VerifyScript to combine the scriptSig and scriptPubKey, so there is no way for the code hash to get communicated between the scriptSig and the scriptPubKey.  I think he is just trying to do whatever he can to cause trouble and confusion.

strikethrough added:  I read through his code again and his code is a joke for a different reason than I thought at first glance (I missed the vchLastScript nonsense).

Here's my motivation for /P2SH/ or something like it:

I want to stop playing whack-a-mole with wallet stealing viruses and trojans, and I think requiring more than one private key to sign away your bitcoins is the critical feature needed to do that. Keep one set of keys on your computer, another set of keys on your cell phone, teach each to talk to the other before sending out bitcoins and you're safe (as long as a virus or trojan doesn't infect BOTH your cell phone and your computer at the same time).

The bitcoin protocol already supports that, but the bitcoin network, the bitcoin software, and the bitcoin addresses that we're all using now don't support multisignature transactions.

OP_EVAL and /P2SH/ and Luke's OP_CODEHASHCHECK are all slightly different ways of implementing multisignature transactions that are as short as the bitcoin addresses we're using today.


RE: the timeframe:

I'm pushing this hard because I'm tired of hearing that users lost their bitcoins to trojans and viruses, and getting there is a multi-step process that will take a lot longer than I'd like:

1. First a majority of miners have to validate, accept and mine the new transaction types. (that's the Feb 15 date)
2. Second we have to convince enough people to upgrade so that they are relayed around the network and not dropped
3. Finally, we can release software with wallets that use the new feature.

I'm losing patience because this process started in October, over three months ago, and certain people seem determined to do whatever they can to derail it-- if I was more conspiracy-theory-minded I would think somebody was purposely trying to keep bitcoin less secure than it can be. roconnor brought up legitimate complaints with OP_EVAL that were discussed and addressed with /P2SH/, but I can't respond to every half-baked scheme that is supposedly "better" or I will spend all of my time explaining why something like CODEHASHCHECK is a bad idea and have no time left over to making Bitcoin better.

Luke, you try my patience.

I'm going to step away from the code for a few days to calm down before I do something stupid because my patience is wearing thin.

I just pulled p2sh into master, replacing the OP_EVAL code that I pulled last month before the controversy erupted.

If you think it is a bad idea, then don't use it.  Hopefully it will inspire you to prove that I'm an idiot and completely wrong about people continuing to use 30-something-character "bitcoin addresses" for the next year or three.

I don't think they make the two-person-escrow case you describe any simpler; use a plain CHECKMULTISIG for that case.

I think they might make third-party escrow easier; the escrow agent would get public keys from all the participants and then give the buyer a short script hash to send the funds into escrow, instead of giving them three separate public keys. If all the key gathering negotiation happens automatically (as it should) then it doesn't really matter, but I suspect that it will take a while to get a secure, convenient, well-supported multiparty transaction negotiation protocol defined and implemented. So I bet pay-to-script-hashes for escrow transactions will get copied and pasted (or put into emailed or SMS-ed URLs) for at least a year or two.

But the use case I REALLY care about is the secure, multiple-signatures-required-to-spend wallet. Script hashes are the same length as existing bitcoin addresses, so it should be much easier for services that can already send to bitcoin addresses to be modified to send to multisignature script hashes (if they use bitcoind to validate addresses then they will just need to update bitcoind; otherwise it is a trivial change to their bitcoin-address-validation routine to recognize the new pay-to-script-hash format).

What percentage support by February 15'th would make you comfortable?  As I said, if it is 55% from Feb 1 to Feb 15'th (or, worse, if it varies a lot in that time) then I think we'll need to re-assess. I expect to get well over 70% support starting Feb 1.

I'd rather use some common sense rather than spend days arguing about exactly what percentage aught to be specified in the BIP, or how many standard deviations of variance are acceptable between Feb 1 and 15.

No, not "something else", it is "if you see this very-specific sequence of bytes in the scriptPubKey then do this ADDITIONAL validation."

As for saying something in BIP 16 about obsoleting scriptPubKey :  no.  Although I think in the future we'll move towards all transactions being pay-to-script-hash, I think it is dumb to put anything like "we think this is what is going to happen in the future" into standards documents.

Can we keep the big picture in mind?  The reason I'm pushing so hard for "send bitcoins to a multisignature-protected-address" functionality is so users stop losing their bitcoins to malware infecting their computers and smartphones and to scammers.

We can spend more months arguing over trivia, but I would much rather we spent the time thinking hard about, and building, great wallet and escrow solutions that solve Bitcoin's biggest technical problems.

Right........


Also, the worst case scenario isn't very scary-- worst case is the less-than-50%-of-miners who did the switch find themselves on the short end of a blockchain split, so they lose revenue (and transactions take longer to confirm because the network is working on two different chains).

That would motivate them to either quickly recruit more hashing power or quickly switch back to the old rules.

If we manage to get 55% or better on Feb 1, then for the next two week's I'll be sending out the message "Upgrade or you might be on the short end of a blockchain split come Feb 15" -- and I expect the result to be a large majority of miners supporting P2SH by the Feb 15'th switchover date. If we're still at 55% on Feb 7'th then I'll be worried, too, and might advise miners to push the hard switchover date a couple of weeks (if they're using the patches I'm creating then it is a command-line argument to bitcoind).

The real danger is for the 45% -- after Feb 15 (assuming the switchover happens) all it takes is for one old miner who is including non-standard transactions in their blocks to create a block containing a transaction that is invalid under the new rules.  They announce the block, and any miners who haven't upgraded would happily build on it, only to waste some hashing power because the 55% majority will sooner or later reject their chain.

However, I don't think anybody will accidentally mine a block spending an 'invalid under the new rules transaction' in it (the number of people mining non-standard transactions seems to be very small), and it seems unlikely an attacker would waste time solving one or more blocks that they knew were going to be rejected by a majority of the network.

Are you communicating via JSON-RPC or by command-line (bitcoind sendmany ....) ?

There shouldn't be any limits if you're talking directly via JSON-RPC, but if you're calling it via the command-line then sh and bash and whatever Windows uses to launch processes all have length limits.