Bitcoin Forum

Just to toss something on to the fire,

BIP 22 (https://en.bitcoin.it/wiki/BIP_0022) is something I proposed as a potential answer to all of the prior BIPs on the multisig subject.

It is one that I proposed way back when.

What this proposal does NOT come with, is an army of argument.  I am fully willing to take a back seat, I have NO desire to derail Gavin's efforts, and despite my proposal, I am still fully behind BIP 16.

I believe it is a completely viable proposal that addresses all the major concerns from Turing completeness, ugliness, stealing bots, and new unpredictable use cases.  But unless I see a swarm of people reading the proposal and saying "Hey, you're right, I agree" - the proposal should be seen as nothing more than entertainment.

I fully support Gavin and will not argue in favor of my proposal to the detriment of Gavin's current efforts.

I actually like BIP22.  If we are going to have to do something considered hackish, I think I like having a subset of script codes inside the main set the best.  I really don't like the serialization in BIP 16.  This is probably best talked about in another topic.

"Hey, you're right, I agree".

I like BIP 22 the best so far.  I don't have a deep enough knowledge of the protocol to see what if anything is wrong with it but it feels a lot cleaner than either 16 or 17.

I was confused by this part:


Don't you want OP_CHECKSIG to succeed not fail when one single signature and one single private key are provided, even when the new functionality is disabled?

dooglus: yep you are right. Meant the opposite. Will fix when not logged in via mobile phone

I edited it for you.  Replaced 'fail' with 'succeed'.

Can we have a review of BIP 22 from all the main devs?
So everyone can give his own opinion.

+1

edit: to the people treating this as a popularity contest please STFU

+1
It seems that old clients will be able to spend their coins in both old way and new way.
That's nice, coins should be always spendable!

I like this idea but I think this should be in a separate thread. This thread is not about BIP 22, in my opinion it isn't even about BIP16/17, this is a larger issue concerning the developer team of Bitcoin.

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.

This type of change would indeed be disastrous and should be avoided at all cost. All non-backwards-compatible changes were ruled out a long time ago as far as I know.

Yes, I think we should finally get over it. BIP16, so be it.
It's not the end of the world, and I trust Gavin to provide support for his solution if needed.

All other proposals are good candidates to play with on other blockchains.

I would be interested in someone demonstrating to me a basic case for how this hard fork would lead to hacks.  Privately even, since I have explicitly stated that my intent is to not derail the efforts behind BIP 16.  The "STOP IT" part was unexpected and not consistent with how I viewed the state of the relevant disagreement.  It was reasonably expected for someone producing FUD or arguing against BIP 16, quite honestly, my reaction is somewhat tongue in cheek silence if STOP IT means "stop producing new ideas that people might think are good on their merits".  Gavin, I won't be bothered if you decide to rename my Wiki page so it is just another Wiki page.  You have my full support behind your efforts, and will simply accept "No" as an answer.

Yes, a hard fork would be involved, but the way I saw it, the old leg of the fork containing only transactions accepted by old clients would still be compatible with recording all of the spends away from the common ancestor of both chains because spending from the common set of txouts looks identical in both worlds - coins spent in the new fork would simply become unrespendable in the old fork.  In other words, unlike in a typical chain fork, I don't believe I could ever spend bitcoin txout X in the new chain and elsewhere in the old chain because, despite there being a fork, the unconfirmed transaction spending txout X would still make sense to both, and both legs of chains would independently record that txout X got spent.  In the new chain, those coins could be respent and recirculate like they should be, but never to the old chain, which would view those coins as permanently unspendable, because nobody could provide a keypair with the right hash that met the old rules.  The old chain would simply accumulate unspendable transactions and the biggest symptom for old clients would be an inability to see incoming bitcoins that had ever participated in multisig anywhere in their history - something I viewed as good graceful failure mode as mentioned in my proposal.

If nothing else, I could not view what I was offering as any worse than Gavin and Luke both conceding to one another that they could each write "stealing bots" that stole coins from people who hadn't upgraded to their respective preferred proposals.

I am interested in hearing someone tell me how this won't work, but I reiterate my support for Gavin having the final decision.  I voluntarily concede to Gavin the right to say "No, this will not work for us", with no requirement of a reason why.  I have no objection to BIP 16 and believe it will accomplish the same goal if accepted.

I agree that Gavin's response was a bit over the top, Casascius is after all a supporter of BIP16. It doesn't hurt to explore other options and as a semi-technical person the explanation Casascius provided for the backwards compatability does make some sense. Hopefully someone more technical has something to say about this.

i think that the whole point was to avoid a fork
otherwise they could implement their "perfect" solution and a few other features/fixes.
https://en.bitcoin.it/wiki/Hardfork_Wishlist

persinally i am in favor of bip17, but it looks like bip16 has the majority of dev's support.
So implement it in 0.6 and be done with this mess already.
https://en.bitcoin.it/wiki/P2SH_Votes

I apologize for the shouting, it's been a hard couple of weeks.  And thanks for the support.

Very quickly, the problem with any chain split is double spends.  An attacker can spend his bitcoins twice, once using CHECKSIGEX and some script instead of a public key.  They can wait for the coins to confirm on the "new" chain, and then they can spend the coins again, using CHECKSIG, on the old chain.

The result would be massive confusion and chaos as those "old" users slowly upgraded and then found their wallets had NEGATIVE balances after the upgrade.

You sure about this?  OP_CHECKSIGEX is part of the redeeming, not the spending.  OP_CHECKSIGEX is solely for redeeming transactions on the new chain, it provides no novel ways to spend transactions on the common ancestor.  Someone cannot use OP_CHECKSIGEX to spend in a way the old chain can't understand, because the only possible OP_CHECKSIGEX they could provide on older transactions looks identical to a valid OP_CHECKSIG to old clients.  The old chain would properly recognize the coins were spent the moment any old node heard the unconfirmed transaction intended for the new chain.

Code first, please.

In script.cpp we have a big switch statement handling all the OP_xxxx cases.  This feature would be implemented by changing the behavior of the OP_CHECKSIG block, which is presently around line 900 in the code.

Presently, the OP_CHECKSIG handler does the following:

• Check for 2 items on the stack, fail if not present.
• Grab references the two top items on the stack: Sig and Pubkey
• Compute a hash of the script with the signature omitted.
• Call CheckSig() with these, pushing the result (true/false) on to the stack, Sig and Pubkey having been removed first

My proposal (in plain language pseudo-code) would be for an OP_CHECKSIG(EX) that does this (common items are in bold)

• Check for 2 items on the stack, fail if not present.
• Grab references the two top items on the stack: Sig and Pubkey (Sigs and PubKeyEx in this context)
• Compute a hash of the script with the signature omitted.
• Create a new empty stack with local scope.
• Create an inner loop that iterates over each byte in PubKeyEx:
  • Pass the byte into a switch statement that treats it as one of the opcodes enabled for eval processing.
  • If the operation is arithmetic or comparison, do it much the same way it's implemented (but disabled) now: pop operands (failing if invalid), do arithmetic, push result.  Of course, these are on the temporary local stack.
  • If the operation is a signature check, then swallow 64 bytes from PubKeyEx, grab one signature from Sigs (parsing as defined in proposal), assuming we didn't just grab a placeholder, pass it to CheckSig() with these, pushing the result (true/false) on to the (eval) stack, or if it was a placeholder, push 0 to the eval stack.  Fail completely if 64 bytes couldn't be taken from PubKeyEx or one sig/placeholder couldn't be grabbed from Sigs
  • If the operation pushes something to the local eval stack, then do it.  Undefined opcodes should cause failure.
• Upon termination of the loop, if the top element remaining on the eval stack is a 1, push a 1 on the real stack.  Otherwise push a 0.  The OP_CHECKSIGEX has completed - the temporary stack goes out of scope at this point and is abandoned.

To me, it is brazenly simple, my only hesitation in actually writing the code being an unfamiliarity with the C++ environment and style used in Bitcoin (something I can handle, but would just be uphill), and the legitimate possibility that Gavin will stick to saying "No, we have this covered, thanks".  That said, even if I pushed through this uphill, writing this as real functioning code is probably a day for the uninitiated, a hour or two for the intimately familiar.

This, and the only other thing would be to modify the definition of a standard transaction so that it allows bigger byte blobs to be pushed as the <sig> and <pubKey> parameters in redemptions, assuming this is even checked in the first place (I haven't checked, but can't imagine this isn't enforced).

No other code that I can foresee would be needed, here or anywhere else.

I don't get how this causes a worse split than the other BIPs since they all require the majority of miners to update.  Doesn't the BIP 17 stealing bot essentially means implementing that proposal requires everyone to update, too?

I've said before I support Gavin and BIP 16.  That being said, I'm curious if Gavin has any further comments on the technical merit of Mike's suggestion.

The split is different because with BIP16 only the miners are forced to upgrade. With BIP22 there is a hard split between new clients and old clients, it's not just about the miners. However Casascius is saying that it doesn't actually matter that there is a split, that it's safe for people to continue to use the old clients. That is the big issue right now.

I don't really get it though, I mean if user x and y are part of the "old chain" and user x sends user y some coins after the split, the old fashioned way of course, and then these users upgrade their clients, does the new chain include everything that's happening in the old chain but not the other way around? Is the newly received money still in user y's wallet after he upgrades? Probably stupid questions but I would like to understand this better.

I would expect the answer to be yes.  In this scenario, both the "old" and "new" clients are still communicating with one another, they just disagree on which blocks are valid.  But transactions and coins are completely compatible, except ones that have been involved in multisig transactions - from the view of the old clients, multisig coins are "lost" coins.  Old clients will always reject spends that are only recognized on the new fork.

If x sends money to y on an old client, it can only be with coins that came through a progeny of transactions that would have been acceptable to both forks (no multisig anywhere in history).  If multisig were anywhere in the history, x wouldn't see these coins to begin with (they're "lost" after all), and wouldn't ever be able to send them.

When client x sends coins to y, client x doesn't necessarily intend to send his transaction to the new fork he doesn't know about.  But since "sends" on both forks look identical, and old clients are still talking to new clients, the two forks essentially cross-contaminate each other (beneficially) with each other's unconfirmed transactions, which results in every unconfirmed transaction that would be considered valid by both clients making it into both forks independently.

No, bad idea, two chains cannot peacefully coexist for more than a few dozen blocks, they would eventually make a complete mess out of users' wallets.

As I understand it, it's a mess that would be completely remedied simply by having the newer version of the client rescan the wallet against the block chain once upon upgrade from the point of the fork (something I would expect it would do anyway by itself, since it would see what amounts to a normal chain reorg the moment once it suddenly becomes accepting of a tall chain of blocks it had rejected before).  The most critical entries in a wallet (keys, address book entries, settings) would be uninvolved in any mess, the rest I expect would be rebuilt without user interaction by the code already in the project.

I don't think I suggest that the chains peacefully coexist by design - the old chain is "old" and "dead" for a reason.  I suggest only that under what I proposed, the "old" chain would continue to function just well enough to reject spends of coins that had already been spent in the new chain.

What actually happens if user sends coins from old client into BIP16/17 multisig address?
Do they just disappear in a black hole? Or does the old client generates error message?

Some people with old clients might not be able to recognize new addresses and send coins by mistake.

This proposal is mutually exclusive of BIP 16/17.  If BIP 16 or BIP 17 is accepted, this proposal becomes unnecessary and will not be implemented.  Same vice versa.

However, if the question is, will old clients be able to send to new multisig addresses, the answer is YES, and the transaction will work correctly.  That's because a sender's client doesn't even know he is sending to a multisig address because it is still just a normal bitcoin address.  The transaction is identified as multisig much later when those coins are respent.  So, old clients can't see incoming transactions from multisig clients, but they can send coins to multisig clients (including their multisig addresses) just fine.

No coins are ever "lost" with this proposal.  When I say "lost", I simply mean that the old client sees multisig coins as "lost" only because it can't understand how they are being spent, and because it's impossible to respend them in a way that the old client will accept as an incoming transaction.  As soon as the user upgrades, the new client understands the new spending rules and they are no longer "lost".

cas, if you are proposing to do a chainsplit, then why not implement the 3 parts signature, why not implement the "perfect solution"?

Three-part and m-of-n signatures are completely supported in my proposal.  I have provided specific examples in my proposal.

I understand that it works fine with BIP22, my concern was that if we go with BIP16 only, what would happen then?
Edit: Ok I re-read the answer and now understand that sending coins from an old client should work with any of the BIPs.

so basically you are saying: forget about backward compatibility and implement the best solution without any constraints?

That decision is up to Gavin.

I don't think any of the solutions are backwards compatible - all of them require everyone to upgrade to continue using Bitcoin, even if they aren't interested in multisig.  The way I see it, the discussion of backward compatibility really only pertains to the question of what will happen to users that don't upgrade.  The goal is not to ensure they can continue to use their old client (which I understand is true of all multisig proposals including 16 and 17).  Rather, the goal is to ensure that they won't lose coins, and that they won't be victimized by double spends from clever attackers who spend their coins once with the new version and once again with the old clients who can't see the coins are already spent.

This plucked from another thread - to the extent this is true, I stand corrected on the point that someone could continue to use their old client.  (assuming of course that the person using a BIP 16 multisignature wallet is spending coins they actually own, since it would appear old client can't determine this for itself).

IMHO this seems the best way of doing it but make sure everyone can "convert" ( yeah I know oversimplified ) their BTC from the old type to the new type.

But at this rate of developing and "screw deadlines" attitude and petty fights between Gavin and Luke ( and deepshit refusing to accept any change ) we can say bye bye to multisig for now >:(

Yeah, even the old banking system and Benny printing his toilet paper is better than this chaos :-\

Where is Satoshi when we need him ? Why has he not thought of this ?

Wouldn't the old chain stop growing?  I mean, the large majority of miners and the pools will switch over very quickly.  Anyone using the old client should fairly abruptly stop getting confirmations, right?   If coordinated, this would be very abrupt.

Yes it looks like the old chain will just stall. It might be a good thing if we want people to upgrade their clients.
They will see that something is wrong, go to the official site and boom there is a new client with the message to upgrade.
Not this time maybe but in the future, when we really need to fork.

It took me a while to understand why this would be the case, but perhaps it's the following:

The 'old' chain will grow independently of the 'new' chain, generating 50 BTC per block which will spread to users of the old chain, and which they will believe is 'real' BTC.  Then when they upgrade to a BIP 22 client, they find that the coins generated on the old fork are no longer valid.

ie. the transactions look valid on both forks in terms of their format, but not in terms of their coinbases.

Then again doesn't it take something like 100 blocks before newly minted coins are spendable?  In which case I'm back to not understanding how BIP 22's chain split would "make a complete mess out of users' wallets" within "a few dozen blocks".

What you are saying sounds right to me.  None of the pools will be mining the old chains, it will only be at most some solo miners.  It will also take an awfully long time, if it ever happens, for the generations to mature without any mining power to support what will remain the original difficulty.

In the future, what you'd want to help manage a necessary chain split are nodes that will only accept transactions deemed valid in multiple chains.  Certainly, once a new set of validation rules are largely agreed upon, miners will switch over quickly (because if they stay on a dying chain they would be mining blocks with worthless coin base transactions).  A chain split may actually be easier to manage in the future than we can imagine today.  As thin client wallets proliferate and rely on a trusted point of presence on the bitcoin network, the full nodes that provide access to the bitcoin network can help ensure that only valid coins are ever accepted into wallets (possibly validating against multiple chains for short periods of time during a transition).  The reason you would want to validate against both the old and the new chain for a short period of time is that you want to make sure the transition actually occurs and you reach the critical mass to make the transition "stick."  If you only accept coins that are valid on both chains for that transition period, you can rest assured that no matter whether the transition is successful or not, all of the coins in your wallet will be spendable.

What if I don't publish the transaction in which I spend an old coin, but wait until I can mine a block containing the transaction for myself.  I'm an evil mining pool operator in this example, say, so that won't take too long.  I make sure there are some multi-sig transactions in the block too.

I publish the block, spending the coin on the new chain, but the old chain rejects the block, since it contains multi-sig transactions.  Then I can spend the same coin again on the old chain.

Your beneficial cross-contamination idea only works if everyone's playing fair...

I think this is a realistic enough attack that it makes BIP 22 unworkable.

I agree with your assessment.  You might win the award for the first serious argument against BIP 22 (at least from the set of those that I understand the ramifications of).

A mitigating factor is that this could be protected against by creating an optional patch to the new client that ensures that, upon receiving a block, the individual transactions are relayed to old clients (as determined by version number).  This patch would not need to be a part of the production code base, nor would it need to be run by everybody - as just a few individuals running it would be sufficient for such transactions from the new branch to get relayed to the old branch.  It would also not need to be permanent, being completely discardable and forgettable once consensus was that people actively expecting to receive bitcoins from the public via old clients was sufficiently small.  The relay patch is admittedly far less elegant than the simple piece of code I proposed for BIP 22 (the simplicity being a hallmark feature), the flipside being that its ugliness is temporary and not a permanent part of the protocol that must be implemented forever.

Other mitigating factors include the fact that any transaction on the old chain is unlikely to ever see six confirmations until long after receiving them.

Gavin's call still, of course.  I will be just as tickled to see BIP 16 move into place, ultimately I just want to see multisig happen but don't care how it gets done, and BIP 16 is more than good enough for me.

It was bugging me that Gavin had so quickly dismissed the idea without giving enough of an explanation for me to immediately understand what his objection to it was, and so I set about trying to find it.  I don't know if the attack I proposed is the same as Gavin had in mind, or he just knows "forks are bad" and left it at that.


I'm not sure that's enough.  Because now I modify my attack like this:

1) mine block on new fork spending old coin without broadcasting transaction
2) mine block on old fork spending same old coin
3) publish both blocks at the same time

That's going to be harder than the original attack, but should be possible for any reasonable sized mining pool to achieve given a day's notice.

That one strikes me as less plausible.  First, mining on the old fork is expensive - you are mining coins you cannot use for much at a very high difficulty, also putting your credibility on the line as a big pool.  Second, your set of potential victims - those who haven't upgraded but who are actively awaiting to deliver goods and services upon seeing an incoming transaction from the public - I would guess are already pretty small. Keeping in mind that a change like this would not suddenly be deployed all at once, but rather, put in a new version and left dormant on mainnet for a long time.

Two other "soft" considerations don't get much attention. One is that a new client with sufficient compelling features from a usability standpoint (e.g. Not so damn long to dl blocks etc.) would entice a lot of upgrades, mitigating lots of problems.  Second, i believe Gavin has a key that can sign a message that cripples or shows alerts on old clients, which may not be true, or which may be reserved for more careful use.

I used my Phone-a-Friend and Ask the Audience, and I'm locking in BIP 16 as my Final Answer (http://en.wikipedia.org/wiki/Who_Wants_to_Be_a_Millionaire%3F) (follow the link if you don't get the stale pop culture reference).

its a little stale indeed. on the other hand i was quite amused by the thought that the whole trouble was caused by a 50:50 in the first place  ;)

In deference, I have updated the Wiki article to reflect BIP 22 as rejected/abandoned.

Stale? Already?

:( Time flies.

Casascius, this thread was educational, if nothing else.

Gavin, thank you for sticking with this all. Most humans would have really lost their cool - to the detriment of what may one day benefit billions of people. Even if bitcoin doesn't become THE one currency to rule them all, it's got a great shot at pointing the way - and THAT could benefit plenty of people. Teacher says "Every time someone proposes a new BIP to compete with 16, Gavin gets his wings."