BIP 16 / 17 in layman's terms

[Gavin Andresen]

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.

[Inaba]

Gavin,

Can you address what lasting changes this will have to the blockchain, both good and bad that are irreversible once BIP 16 or 17 is accepted and activated?

[Jan]

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.

Has it really come to this... bitcoin community having to beg one person to accept changes. I am in shock!

[ZodiacDragon84]

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.

Has it really come to this... bitcoin community having to beg one person to accept changes. I am in shock!

Indeed, we are coin whores parted out to the highest bidder. we need more small pools, and more adoption by the masses.

[Costia]

does it mean that with a 51% attack that reverses support for bip17 all multisig transactions will be redeemable by the attacker?

[ZodiacDragon84]

I'm with bitminter, and you'll hear no complaints from me about how Doc runs things.

[Technomage]

I think the number one most shocking thing about the whole issue is the power Tycho holds over this. It's ridiculous. If the potential of a 51% attack wasn't enough, but now this. I hope Deepbit users finally start to consider using a smaller pool or even p2pool.

I don't really understand the differences that these different solutions have so I can't really comment on this from a technical standpoint. One thing I can say is that I strongly agree with Gavin that this is a much needed feature that would make Bitcoin much better than it is now.

However it has been proven now that this is also the most difficult change Bitcoin has faced so far, it should be handled carefully. I think it's important that we don't just forget about this now and move on, even though it's very tiresome to developers such as Gavin, I believe this issue needs to be settled even if it takes another month.

Finally, I have to say that I appreciate the work Gavin is doing and the hardship he is enduring because of the difficulties in trying to get this feature into Bitcoin. Keep it up, you're doing very important work. The same goes to the other developers as well but I can see this being especially hard for Gavin because he is the main developer.

[ribuck]

There's no need for a rush decision. In time, and with further calm-headed discussion, support may gravitate towards BIP 16 or BIP 17, or perhaps a BIPxx will emerge that is superior to both.

It doesn't matter if this takes another six months to get this right.

[gnar1ta$]

I have one of my rigs on p2pool, I have no idea even how to vote (assuming I get a block). Where is the voting for dummies thread?

[oOoOo]

@ Gavin

Call me dumb, but I absolutely do not understand how you are supposed to create a whole address out of partial sigs?!? Wouldn't it be necessary for all sigs to come together at one point to create a single address hash to which you can then send the coins?
And if so, why don't you just take one private key, divide it into two or three or more parts (like this: 5JMhGPWc3pkdgPd9jqVZkRtEp3QB3Ze8ihv62TmmvzABmkNzBHw ) and then give each part to different people or devices.


Can you please explain in more detail?

[chrisrico]

@ Gavin

Call me dumb, but I absolutely do not understand how you are supposed to create a whole address out of partial sigs?!? Wouldn't it be necessary for all sigs to come together at one point to create a single address hash to which you can then send the coins?
And if so, why don't you just take one private key, divide it into two or three or more parts (like this: 5JMhGPWc3pkdgPd9jqVZkRtEp3QB3Ze8ihv62TmmvzABmkNzBHw ) and then give each part to different people or devices.


Can you please explain in more detail?

I think the code is saying "in order for this transaction to be spent, it must be signed by private key (X and Y) or Z". This allows more flexibility, because Z can be printed out and kept physically safe, in case X or Y (kept in separate locations) is lost. You can also say something like "...it must be signed by at least 51% of A through Z".

[Explodicle]

Thanks! Very helpful for us customers.

[Gavin Andresen]

Call me dumb, but I absolutely do not understand how you are supposed to create a whole address out of partial sigs?!? Wouldn't it be necessary for all sigs to come together at one point to create a single address hash to which you can then send the coins?

Bitcoin addresses today correspond to one public key in your wallet.

Signatures enter the picture when you spend the bitcoins sent to an address; your private key is used to generate the right digital signature, proving that you actually have that key.

BIP 16/17 will enable bitcoin addresses that are associated with more than one public key. Your wallet will know both public keys, but will only know ONE of the private keys needed to spend the bitcoins (your phone or a "wallet protection service" will keep the other private key safe).

So when sending coins, your wallet will provide one signature for the private key that it knows, the other required signature must come from whatever device is holding the other private key.

The public keys aren't just strung together in a row, but are combined using a secure hashing algorithm (the same algorithm that is used to associate public keys with the bitcoin addresses we're all using today).

[LightRider]

I would advocate for whichever option that makes things difficult now, but easier in the future to work with. For too long we, as a society, have implemented policies and technologies based on how convenient they are, as opposed to those which are better for the long term health and sustainability of our species. Can you tell us which would be better for the long term development of bitcoin, its continued function and the specific challenges we would face in the short term? I appreciate the fastener analogy, but that still is fairly vague.

[Shuai]

Seeing Gavins forum signature makes me want to cry... Bitcoin, nooooo! You used to be strong and follow noone's rules, now you're like a little slave begging your master for a bone.

It's time for a digital riot against our overlord. Who's up for funding an attack on deepbit?

[ZodiacDragon84]

Seeing Gavins forum signature makes me want to cry... Bitcoin, nooooo! You used to be strong and follow noone's rules, now you're like a little slave begging your master for a bone.

It's time for a digital riot against our overlord. Who's up for funding an attack on deepbit?

There is a time and place for this, and the bitcointalk.org forums are not it. Try l33thackers.com or blackhat.com for this kind of talk.

[oOoOo]

After a bit of reading it appears like p2sh allows the payer to place conditions upon which the payee can receive the payment. The question that now remains is what are the possible conditions. Can I do something like this:

"Here are your coins, but before you can receive them in your wallet, you will have to solve this: (5+5)
Or you will have to send me a pic of your... um... cat! Yeah that's it.." ?
.

[ineededausername]

It is apparent that Deepbit is now a community enemy.
That is, Deepbit wields too much power, handed to them by ignorant newbie miners who seem to love throwing away money, and uses that power against the democratic consensus of the developers and, perhaps, community as a whole.
There is no fucking reason that anybody should mine at Deepbit (variance is an excuse that anyone who has a working knowledge of statistics would ignore).  In fact, Deepbit should have been brought down months ago.  It has had close to 50% of the hash power of the network for far too long, and nobody listened.  This is what you get for not listening.
If Tycho believes that he has the right to block progress, then Deepbit must be forced from its position as the largest pool.  

I suggest that everyone pledge their hashing power, and when enough is collected in pledges, everyone should switch to p2pool at the same time (so that the transition is smooth).

edit: Everyone should copy my sig... we need Deepbit to fall.

[ZodiacDragon84]

I can understand the resentment for deepbit, but we as a community let this happen. We the sheeple have given our computing power not at the point of a sword, but at the promise of regular payouts.

[cunicula]

Would this make it easier to lose coins from human error? What happens if you lose your phone? Is it possible to allow very slow draining of a wallet with access to just one of the two private keys (e.g. max of 1 coin sent every 100 blocks)?

This way coins could be recovered even if one of the two factors is lost. It would also reduce user inconvenience for cases where security is not as essential. However, it would still be possible to steal very slowly.

Residing in a country where you need two factor authentication for everything. I suspect that this modification (while very useful) could impose serious inconveniences on users if poorly implemented.