BIP 22?

[casascius]

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.

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.

[1714651635]

1714651635

[1714651635]

1714651635

[1714651635]

1714651635

[1714651635]

1714651635

[dooglus]

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

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.

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

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.

[casascius]

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.

[Gavin Andresen]

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.

I used my Phone-a-Friend and Ask the Audience, and I'm locking in BIP 16 as my Final Answer (follow the link if you don't get the stale pop culture reference).

[fornit]

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 

[casascius]

I used my Phone-a-Friend and Ask the Audience, and I'm locking in BIP 16 as my Final Answer (follow the link if you don't get the stale pop culture reference).

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

[bc]

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.

I used my Phone-a-Friend and Ask the Audience, and I'm locking in BIP 16 as my Final Answer (follow the link if you don't get the stale pop culture reference).

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