BIP 22?

[btc_artist]

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.

[1714006545]

1714006545

[Technomage]

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?

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.

[casascius]

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.

[Gavin Andresen]

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.

[casascius]

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

[interlagos]

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.

[casascius]

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

[Costia]

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

[casascius]

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.

[interlagos]

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

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.

[Costia]

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

[casascius]

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.

[casascius]

You should be able to use your present wallet but would probably be required to upgrade your client.

No, you don't have to upgrade your client to receive coins from somebody using a BIP 16 multisignature wallet.

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

[bulanula]

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

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 ?

[dayfall]

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.

[interlagos]

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.

[dooglus]

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.

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

[casascius]

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.

[Steve]

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.

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.

[dooglus]

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.

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.