BIP 22?

[casascius]

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.

[1714022503]

1714022503

[1714022503]

1714022503

[1714022503]

1714022503

[1714022503]

1714022503

[Red Emerald]

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.

[dooglus]

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.

"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:

A suggested implementation is to program the client such that the functionality is enabled only on Testnet, and on the main Bitcoin network once a certain level of voting consensus has been established into the block chain. So long as the functionality is disabled, OP_CHECKSIG shall fail so long as the expected parameters of one single signature and one single private key are provided.

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?

[casascius]

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

[dooglus]

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'.

[HostFat]

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

[paraipan]

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

[interlagos]

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

+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!

[Technomage]

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

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.

[Gavin Andresen]

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.

[Technomage]

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.

[interlagos]

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.

[casascius]

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.

[Technomage]

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.

[Costia]

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

[Gavin Andresen]

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.

[casascius]

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.

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.

[finway]

Code first, please.

[casascius]

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.

[Red Emerald]

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?