So you might have rumblings about changes to the network:  OP_EVAL and BIP 16 and BIP 17 and multisig and P2SH, and you wonder what the heck is going on.

Here's my view; I'll try not to get too technical.

First, the feature:

I want more secure wallets. There's unanimous agreement among developers that the easiest, fastest way to get there is with "multi-signature transactions" -- bitcoins that require approval from more than one person or device to spend.

For example, a future version of Bitcoin-Qt might know how to talk to an app running on your mobile phone. When you send bitcoins, it would provide one signature, but it would have to ask your phone for approval and the other signature.  That way even if your computer gets compromised by malware your bitcoins absolutely positively cannot be stolen, since the best the malware could do would be to ask your phone to approve the "Send the bad guys bitcoins" transaction.

The bitcoin network protocol already mostly support multi-signature transactions, although they're considered "non-standard" right now.  Part of what is going in is making them standard.  That's not controversial.

What is causing all the discussion is how to support sending coins into one of these new, spiffy, secure wallets.  There is rough consensus that the best way to do that right now is with a new type of bitcoin address; I say "rough consensus" because in a perfect world some people think that there wouldn't be bitcoin addresses visible to users at all.  And I say "right now" because we don't live in a perfect world, and there are no proposals for how, exactly, to replace bitcoin addresses with something better.

Part of the controversy is whether really long bitcoin addresses would work-- would it be OK if the new bitcoin addresses were really long and looked something like this:
  57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr
(or possibly even longer)

I've argued no: past 70 or so characters it becomes a lot harder to copy and paste, a lot harder to scan an address with your eyes to see if you're paying who you think you're paying, harder to create a readable QR code, harder to upgrade website or database code that deals with bitcoin addresses, etc. There is rough consensus that very-long addresses are not workable.

So: there are three proposals on how to support short multisignature addresses-- BIP 12, 16, and 17.

I withdrew BIP 12 (also known as "OP_EVAL") because I try to be extremely conservative when it comes to changes to core Bitcoin, and I think BIP 16 is a safer way to go.

Luke Dashjr liked OP_EVAL, really doesn't like BIP 16, and came up with BIP 17, which solves the same problem in a different way. I still like BIP 16 best, because I think it is the most conservative, safest solution. The number of people who understand the guts of Bitcoin well enough to have an informed opinion about which is better is pretty darn small, but I think the controversy is really about how conservative we aught to be.

All of the BIP 12/16/17 stuff is mostly engineers arguing over whether it is better to use a nail, a screw, or glue to put two pieces of wood together. Any of the solutions would work, and ordinary users wouldn't notice any difference; you'll still (eventually) get spiffy, more secure wallets.

(don't take the analogy too far, in this case using a nail AND a screw AND some glue to be extra safe isn't an option).

How dangerous is all this?  Is the bitcoin network in danger of falling apart one of these BIPs is adopted?

The worst-case scenario for all of this stuff (including the non-controversial support of multisignature transactions as "standard") is that some bug will slip by, and an attacker will figure out a way of getting all the nodes running the new software to crash or misbehave. I'm working hard to prevent that from happening-- I've been writing "unit tests" and "fuzzing tools" and have been getting other developers to look really hard at the code.  I strongly believe that the new feature is worth the (small) risk, and that even in the worst-case scenario the consequences are not catastrophic (we'd just fix the bug and come out with a new release; everybody still running old code would continue to confirm transactions and create blocks while the early adopters were busy downloading and installing the fixed software).

The bitcoin network is NOT in danger of falling apart if any of these are adopted; they are all backwards-compatible, so old software will continue to work exactly as before.

Some footnotes (and sorry for making this so long):

I concentrated on multisignature transactions for secure wallets, but they're useful for several other things, including escrow transactions and "emergency offline backup keys" for wallet backups.

I've set an arbitrary deadline of February 1'st for deciding whether or not to "turn on" the new short-multisignature-bitcoin-address-support feature, mostly because deadlines are the only way I know to actually get people to pay attention. If you read the BIPs, those deadlines are designed to be flexible, so if there is NOT a majority of support or "we" think that not enough time has gone by or enough testing has been done they can (and will) be slipped.

Right now, it looks like one person/pool (Tycho/deepbit) has enough hashing power to veto any change. I believe Tycho liked, and planned to support, the original OP_EVAL proposal, but doesn't like/support either BIP 16 or BIP 17 (he does like/support BIP 11, the multisignature-as-standard-transactions part of all this), so unless he changes his mind or there is a mass exodus from his pool short, multisignature bitcoin addresses will have to wait.

Decentralized systems often settle into some kind of "power law distribution."

For example, there's no central authority determining how large cities all over the world should be, and yet if you plot the size of cities you'll see that there are a few REALLY big ones, a bunch of medium sized ones, and a gazillion small ones.

Plot the size of the bitcoin mining pools and I think you'll see the same thing.

If there were no mining pools, then plot the hashing power of individual miners and I bet you'd see the same thing... (ArtForz used to be a significant fraction of mining power all by himself, for example)

I worry a lot more about incentives than I do size; if the "naturally big" players have the right incentives, then they're not bad for the network. So far, I think the incentives are working nicely. For example, people HAVE tried to knock out the big mining pools and exchanges using denial-of-service attacks, and the big mining pools and exchanges have (as far as I can tell) worked to fix that problem themselves.

PS: p2pool built into a bitcoin client is something I'd fully support, I think a lot of people would like a one-button "get a trickle of bit-pennies" option.

Please explain to me how ANY of the proposals (the original OP_EVAL, BIP 16, and BIP 17) are any different in the "what if we change our minds and want to remove support" case?

Removing support for BIP 17 would be harder than removing support for BIP 16, because if the network doesn't support it all BIP 17 transactions can be stolen as soon as they're broadcast.

Imagine there are a bunch of un-redeemed BIP 17 transactions in the block chain and support for BIP 17 goes away.  Every single one of them could be immediately redeemed by anybody.

The situation is better with BIP 16, because of the "half validation" done by old nodes.  Admittedly not a lot better, but it is the "belt and suspenders" nature of BIP 16 that makes me prefer it.

I've been very clear about my top development priorities:

1. Network stability: DoS threats, scaling-up issues, etc.
2. Wallet security/backup.

I see everything else as lower priority; I want users to be confident that their bitcoins can't get stolen even if they slip up and open an attachment in Outlook that the aughtn't have opened before I want a downloads-the-entire-blockchain-in-10-seconds client with all sorts of other bells and whistles.

Huh?  GIT HEAD bitcoind supports import private key functionality:

Whether or not that's ever supported by the GUI is a different issue, and there I think we SHOULD be more concerned about people using the GUI shooting themselves in their feet.

No, it really isn't.

Here's a possible future implementation of IsStandard():


I like the idea of a future IsStandard() that allows more transaction types, but only if they're under some (sane) resource limits.

That's non-trivial to implement; it seems to me that a conscious decision by the miners/pools to support or not support is less work and safer.

Luke proposed something similar earlier, though; I'm surprised his patches don't implement it.

I like whoever proposed that the string in the coinbase refer to the BIP, in the future that's the way it should be done.


RE: schedules:

Deadlines, as we've just seen, have a way of focusing attention.  OP_EVAL got, essentially, zero review/testing (aside from my own) until a month before the deadline.

It seems to me one-to-two months is about the right amount of time to get thorough review and testing of this type of backwards-compatible change. Longer deadlines just mean people get busy working on other things and ignore the issue.

So I'm trying to figure out why I'm so annoyed at I'm-sure-you-can-guess-who.

And I think I've figured it out-- I think it is because I feel like I bend over backwards to be completely honest and open about potential flaws or problems with my ideas, and I'm completely honest and open about the fact that I'm human and I make mistakes.

And it seems like that's being leveraged to create fear, uncertainty and doubt. I say something like "there is a small risk that...", but I NEVER EVER hear even a hint that the "other side's" proposal might be anything but perfect.

Maybe I'm just too naive, and aught to get with the program and say that everything I do comes perfect, straight from God. People do tend to suffer from The Wise Leader Fallacy; maybe I should stop fighting against human nature and be more of a politician.

Ok, enough venting.

Yes.

I'd love so see a bitcoin client with p2pool-technology built in; bring back the "generate coins" option!

But... that will take a while. If I was a pool operator, though, I'd be thinking about other bitcoin-related businesses where I could use my expertise (the pool operators deserve a lot of credit, they've had to deal with DOS attacks, keeping their wallets safe, servicing hundreds or thousands of customers banging on their servers constantly, etc).

Yes. Old solo mining clients will produce perfectly valid blocks, unless they've been hacked to mine "non-standard" transactions.

There is a small risk that somebody ELSE will produce an invalid block, old solo mining clients will think it is valid, and will try to mine on top of it.  But that's a small risk because we'll wait until a super-majority of the network supports p2sh before starting to reject any p2sh transactions.

So worst case scenario would be:

+ Somebody with a hacked bitcoind mines a block containing a valid-under-old-rules, invalid-under-new p2sh transaction.
+ Old miners try to build on it, but the majority of the network rejects it (there's a short block-chain split).

If an attacker could target just the p2sh-supporting nodes and denial-of-service enough of them to get p2sh support below 50%, then there could be a longer block-chain split. If you do the math, that's not as easy as it sounds (if p2sh support is at 80%, you'd have to knock out 60% of the supporting nodes-- 20% of the original network would support, 20% wouldn't...).


Don't do that, please. "Voting" with your coinbase should mean you actually do the extra validation required by p2sh, otherwise you're saying you support a feature when you really don't.

I try not to respond to trolls, but....

Quit spreading FUD. If you think BIP 16 is terrible, please give a rational reason, beyond "It is a special case," which I have repeatedly responded to.

BIP 16 explicitly states:
"Validation fails if there are any operations other than "push data" operations in the scriptSig."

Let me try again for why I think it is a bad idea to put anything besides "push data" in the scriptSig:

Bitcoin version 0.1 evaluated transactions by doing this:


That turned out to be a bad idea, because one person controls what is in the scriptPubKey and another the scriptSig.

Part of the fix was to change evaluation to:


That gives a potential attacker much less ability to leverage some bug or flaw in the scripting system.

Little known fact of bitcoin as it exists right now: you can insert extra "push data" opcodes at the beginning of the scriptsigs of transactions that don't belong to you, relay them, and the modified transaction (with a different transaction id!) may be mined.


Are you volunteering to make that happen? After working really hard for over four months now to get a backwards-compatible change done I'm not about to suggest an "entire network must upgrade" change...

By the way... if there is no fully-functional reference implementation yet, you really shouldn't be putting "CHV" in your coinbases yet. The string in the coinbase really aught to mean "this code is all ready to support this feature,"  because full support from a majority of hashing power is what we want to measure.


Imagine you're an early adopter.  You ask people to send you money into your spiffy new ultra-secure wallet.

With BIP 16, transactions TO you will take longer to get into a block because not everybody is supporting the new feature.

But transactions FROM you will look like regular transactions, so the people you are paying won't have to wait.

That is not a big difference, but it is an advantage of the BIP 16 approach.


No, they are not evaluated in the same way.  The bit of code in bitcoin transaction validation that makes me nervous is:
... in SignatureHash(), which is called from the CHECKSIG opcodes.  scriptCode is the scriptPubKey from the previous (funding) transaction, txTmp is the transaction being funded.

This is the "Copy the scriptPubKey into the scriptSig before computing the hash that is signed" part of what OP_CHECKSIG does.

I like BIP 16 better than OP_EVAL/BIP 17 because BIP 16 does two complete validations, once with the scriptPubKey set to HASH160 <hash> OP_EQUAL and then once again with the scriptPubKey set to (for example) <pubkey> OP_CHECKSIG.

BIP 16 essentially says "If we see a P2SH transaction, validate it, then treat it is a normal, standard transaction and validate it again."

BIP 17 will run OP_CHECKSIGs when it is executing the scriptSig part of the transaction, which is a completely different context from where they are executed for the standard transactions we have now.

Again, I can't see a way to exploit that but it makes me very nervous.

If you don't want to change you can just ignore the new feature(s). There is zero risk with the proposed changes for anybody running old, un-hacked versions of bitcoin.

(if you are solo mining and hacked your version of bitcoin to accept 'non-standard' transactions then you could shoot yourself in your foot, but even that is unlikely).

Nobody has written a Korean translation.  If/when somebody does (join https://www.transifex.net/projects/p/bitcoin/ if you want to help) you'd get the Korean translation.

An option to change the language in the GUI is a great idea.  Somebody should do that....

We need more Windows developers, by the way; if you know a lot about developing in C++ on Windows and want to (for example) create a Visual Studio project or resurrect makefile.vc or fix the build instructions if they're not right that'd be spiffy.

I haven't seen discussion of BIP 17 anywhere besides IRC, so I thought I'd start one.

I'll start by saying that I'm trying hard to put aside my biases and dispassionately evaluating the proposal on its merits (I'll just say that I'm not happy with the way BIP 17 came to be, but it is what it is).

Quick executive summary of BIP 17:

A new opcode is proposed, OP_CODEHASHVERIFY, that replaces OP_NOP2.

It is used in a new "standard" scriptPubKey that looks like:


... which is redeemed using a scriptSig like (for example, a 2-of-2 CHECKMULTISIG):



OP_CODEHASHVERIFY is defined to take the hash of everything in the scriptSig from the last OP_CODESEPARATOR and compare it to the top item on the stack. If the hashes match, then it is a no-op, otherwise script validation fails. (see the spec for all the details for what happens if there is no CODESEPARATOR or a CODEHASHVERIFY is put in the scriptSig)


BIP 17 is an alternative to BIP 16, which has a scriptPubKey:


... which is redeemed with:



I see the appeal of BIP 17 -- the redeeming opcodes aren't "hidden" as serialized bytes, they're right there in the scriptSig. That feels less like a hack.

However, there are a couple of practical reasons I like BIP 16 better:

• Old clients and miners count each OP_CHECKMULTISIG in a scriptSig or scriptPubKey as 20 "signature operations (sigops)."  And there is a maximum of 20,000 sigops per block.  That means a maximum of 1,000 BIP-17-style multisig inputs per block.  BIP 16 "hides" the CHECKMULTISIGs from old clients, and (for example) counts a 2-of-2 CHECKMULTISIG as 2 sigops instead of 20. Increasing the MAX_SIGOPS limit would require a 'hard' blockchain split; BIP 16 gives 5-10 times more room for transaction growth than BIP 17 before bumping into block limits.
• With BIP 17, both transaction outputs and inputs fail the old IsStandard() check, so old clients and miners will refuse to relay or mine both transactions that send coins into a multisignature transaction and transactions that spend multisignature transactions.  BIP 16 scriptSigs look like standard scriptSigs to old clients and miners. The practical effect is as long as less than 100% of the network is upgraded it will take longer for BIP 17 transactions to get confirmed compared to BIP 16 transactions.
• Old clients and miners will immediately accept ANY scriptSig for BIP 17 transactions as valid. That makes me nervous; if anybody messes up and sends coins into a BIP 17 transaction before 50% of hashing power supports it anybody can claim that output. An advantage of BIP 16 is the "half-validation" of transactions; old clients and miners will check the hash in the scriptPubKey.

I also have some theoretical, "just makes me feel uncomfortable" reasons for disliking BIP 17:

• OP_CHECKSIG feels like it was originally designed to be in the scriptPubKey-- "scriptSig is for signatures." Although I can't see any way to exploit an OP_CHECKSIG that appears in the scriptSig instead of the scriptPubKey, I'm much less confident that I might have missed something.  I'm much more confident that BIP 16 will do exactly what I think it will (because it is much more constrained, and executes the CHECKSIG exactly as if it appeared directly in the scriptPubKey).
• Changing from the scriptSig being just "push data onto the stack" to "do the bulk of verification" also makes me nervous, especially since nodes that relay transactions can add whatever they like to the beginning of the scriptSig before relaying the transaction. Again, I can't think of any way of leveraging that into an exploit, but the added complexity of code in the scriptSig and requiring OP_CODESEPARATORs in the right place makes me nervous.
• I've never liked OP_CODESEPARATOR-- it is not like the other opcodes, the way it isn't affected at all by OP_IF and the way it 'steps out' and causes the raw bytes of the transaction to be hashed.  Nobody has been able to figure out how to use it, and the best guess is it is like your appendix:  maybe useful in the past, but not useful now.  Safer to get rid of it entirely, in my opinion.

Once transactions are validated and buried "deep enough" in the blockchain you can forget their inputs, because the inputs are only needed for validation.

... although SOMEBODY on the network should remember them, in case I-don't-trust-anybody nodes want to validate the entire blockchain.

Good idea. Somebody should do that.

Just the bitcoind node.