Topic: Questions about BIP 16 / 17 in layman's terms (Read 3740 times)

I would agree with this were it not for the fact that 99% of all clients are running this script engine.  If there were say 10 different script engines in use, the impact of one of them having an exploitable bug would be much less severe.  In such a scenario, if a particular engine was flawed and allowed an invalid transaction into a block, you would have a chain split with the majority of the network rejecting that block.  It should be spotted quickly (people could run nodes that use multiple script engines to detect it right away) and the people using that script engine could be alerted.  They could switch out their script engine, or wait on a patch (the vast majority of transaction would still be valid on both forks of the chain and the affected people would only be on the bad fork for a short time until the rest of the network overtakes it).

BIP 17 can be easily tested by setting the activation time to 0 and running on testnet. Such clients will reject all non-compliant blocks, and should be sufficiently secure. The only problem your bot made was looking at them in Block Explorer.

That's half the problem. The BIPs are about protocol changes, and the specifics of any one particular implementation should be ignored. Also, the BIP 17 implementation in bitcoind changes significantly less code, and doesn't really execute any new code paths (all the "questionable" code paths mentioned are already enabled).

That's not actually a long time for a design decision with long-term consequences. Because of not rushing into this in 2011, it has been possible to improve on some of the earlier designs.


As it happens, I do maintain a large body of PHP code that is not well covered by unit tests. As a result, I almost always make only the most conservative changes.

But when something (a) is important, (b) has long-term consequences, and (c) has the potential for a cleaner but less-conservative change, I do my best to find the time to make the change that is cleaner in the long-term. When I can't manage that, I always feel a little bit ashamed of my code.

Although I contribute to the Bitcoin community in many ways, I've never contributed a line of code, nor am I currently mining, so I haven't earned any right to have a say in this. All I'm hoping to do is to clarify some of the issues so that everyone can feel comfortable with the decisions made by those who are entitled to make the decision. No-one should be left with the impression that any issues were overlooked or misunderstood by anyone making the decision, so I appreciate the clarifications here and elsewhere.

Well, exactly. The design of BIP 16 is safe. A bug-free implementation of BIP 16 is also safe. But in the presence of a bug, an additional facet of the system is exposed to a possible exploit. So BIP 17 has an advantage here.


Thanks for this explanation. The limit of 1000 can, of course, be eased in the future. If BIP 17 puts fewer bytes into the block chain, the potential for easing any future limits (not just this one) is greater, so BIP 17 surely has a slight advantage here.


Trying to break things can help to make them more robust


OK thanks for that unambiguous statement, which neutralises the rumors and makes this a total non-issue. I've edited my earlier post to reflect this.

You shouldn't, people have been thinking about these issues and coming up with solutions since at least August of 2011.

The principal concern that Gavin has is related to upgrade and executing well tread code paths in the implementation.  Despite having done much work on the core client, I did refactor the entire codebase once…so I can appreciate the desire to make only conservative changes.  If you've ever worked on a large body of code that isn't well covered by unit tests, you know what I mean.  As much as I think BIP-17 is a bit cleaner, I think I have to say BIP-16 is the more conservative approach.  And, it won't impair the ability to adopt a cleaner solution or even an entirely different scripting engine in the future.

Did you read BIP 16?


So there is no manipulation allowed AT ALL.


A maximum of 1,000 "naked" OP_CHECKMULTISIG operations are allowed in the scriptSigs and scriptPubKeys of transactions in any given block.

We had a block earlier this month with 1,8000 scriptSigs, so I think we are uncomfortably close to that limit.

BIP 16 "hides" the CHECKMULTISIGS in the serialized script, so more of them are allowed.


At the very least BIP 17 is harder to test-- Luke had to test on the main network because I was naughty and wrote and ran a BIP-17-transaction-stealing bot (sorry, I couldn't resist).


I have zero commercial interest; I am not being paid by anybody for anything right now.

What are the substantive issues? Here are how I see them:

1. It's prudent to avoid executing data from the stack. Why? Because you have a scripts that manipulate data on the stack. Obviously the system is designed so that scripts can't manipulate the data that is going to be executed. But if there is a bug, you have all the pieces in place for an exploit. The script doesn't have opcodes to manipulate off-stack data, so Luke's implementation seems safer.

2. Supporters of BIP 16 claim that it allows 5-10 times more headroom before block size limits are reached. Supporters of BIP 17 claim that it puts fewer bytes into the block. [Edit: Gavin has explained the headroom issue, but BIP 17 still seems more scalable to me because it puts fewer bytes into the block chain.]

3. It's clear that both BIP 16 and BIP 17 transactions can be spent by others if those transactions are broadcast before 50% of the mining power (plus a safety margin) supports them. It's also clear that the BIP 17 transactions are easier to spend in this situation. However I think this is a non-issue because (a) mining power will quickly rise above 50% once consensus is reached, and (b) who is going to broadcast these newfangled transactions before the mining power is there to support them?

3. Gavin needs to say whether it's commercially relevant to his current work project. [Edit: Gavin has made it absolutely clear that BIP 16 is not driven by any commercial pressure, so as far as I'm concerned this is a non-issue and the rumors can be ignored.]

4. BIP 17 "feels" like a more general approach to the problem, and BIP 16 "feels" a bit more like a special-cased design change.

5. BIP 17 "feels" like a less-developed solution, and BIP 16 "feels" like one that has already had a little more contemplation.

Of these 5 issues, I think only (1) and (2) are of any real consequence.