Topic: BIP 22? - page 2. (Read 4409 times)

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

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.

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.

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.

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.

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

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?

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

Code first, please.

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.

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.

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

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.

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.

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.

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.

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