Topic: BIP 22? (Read 4347 times)

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

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

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 

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

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.

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.

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.

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.

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

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

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.

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.

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 ?

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

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.

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

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.

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

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