BIP 17

[Costia]

you dont need computing power, you just send a competing transaction, and wichever gets first into a block will be accepted

BTW, why is the address of BIP17 longer than BIP16?

[1713587385]

1713587385

[Luke-Jr]

BTW, why is the address of BIP17 longer than BIP16?

BIP17 and BIP16 both use BIP13 addresses...

[Costia]

is there already an implementation of both BIPs?

[jojkaart]

...And even BIP16, which also evaluates code you push on the stack, seems wrong to me (and would make the implementation more complex and static analysis more difficult).

BIP 16 explicitly states:
"Validation fails if there are any operations other than "push data" operations in the scriptSig."

Let me try again for why I think it is a bad idea to put anything besides "push data" in the scriptSig:

Bitcoin version 0.1 evaluated transactions by doing this:

Code:

Evaluate(scriptSig + OP_CODESEPARATOR + scriptPubKey)

That turned out to be a bad idea, because one person controls what is in the scriptPubKey and another the scriptSig.

Part of the fix was to change evaluation to:

Code:

stack = Evaluate(scriptSig)
Evaluate(scriptPubKey, stack)

That gives a potential attacker much less ability to leverage some bug or flaw in the scripting system.

BIP 17 could gain the same robustness by the following (in python-like pseudocode):

Code:

MetaEvaluate(scriptSig + OP_CODESEPARATOR + scriptPubKey)

Where MetaEvaluate is a function that:

Code:

def MetaEvaluate(code):
    pieces = code_split(code, OP_CODESEPARATOR)
    stack = emptyStack
    foreach piece in pieces:
        stack = Evaluate(piece,stack)

I'm not going to write pseudocode for code_split but the first argument is the code to be split and the second is the instruction by which to separate it. I'm not sure if it makes sense to be able to split at any instruction but OP_CODESEPARATOR though. code_split does need to understand not to split in the middle of data though, so pure split won't work.

[Luke-Jr]

is there already an implementation of both BIPs?

Yes, BIP 16 is in mainline git master, and BIP 17 has implementations for 0.3.19 onward.

BIP 17 could gain the same robustness by the following (in python-like pseudocode):

Code:

MetaEvaluate(scriptSig + OP_CODESEPARATOR + scriptPubKey)

Where MetaEvaluate is a function that:

Code:

def MetaEvaluate(code):
    pieces = code_split(code, OP_CODESEPARATOR)
    stack = emptyStack
    foreach piece in pieces:
        stack = Evaluate(piece,stack)

I'm not going to write pseudocode for code_split but the first argument is the code to be split and the second is the instruction by which to separate it. I'm not sure if it makes sense to be able to split at any instruction but OP_CODESEPARATOR though. code_split does need to understand not to split in the middle of data though, so pure split won't work.

Interesting, but it seems more likely to break something subtle to me, at least in regard to backward compatibility. But perhaps this option should be explored more if we have the time.

[Maged]

But i do not feel that bip17 is mature enough since it introduces new security risks.
So i think something like bip17 should be implemented, but in a way that cannot be exploited/misenterpreted by older clients even if BIPXX has less than 50% support.

BIP 17 does not introduce any new security risks that aren't also risks with BIP 16.

it does. if you send a new transaction before 50% of the hash power is updated it will be redeemable by anyone
with bip16, you will at least need to know the script - its not much, but its not nothing either.

And to redeem it, you have to make the script known even before your redemption gets confirmed. So any rogue miner/relayer can easily swipe it the moment you try to spend.

On the contrary, you don't have to make the script known publicly to redeem it. You can mine it yourself, or get someone that you trust completely to mine it for you. Once it's in a block, the only danger is that the block could be orphaned, and since the script is now publicly released, other people could try redeeming it.

However, that is significantly better than BIP 17 where anyone can try redeeming it the second the BIP 17 transaction appears on the network.

[Luke-Jr]

However, that is significantly better than BIP 17 where anyone can try redeeming it the second the BIP 17 transaction appears on the network.

Not considering both BIPs require a supermajority hashpower of support to become active.

[theymos]

At the moment I slightly prefer BIP 16 over 17. BIP 16 seems a little more security-conservative because the scripting system isn't being modified and non-P2SH scripts will not be touched at all. There's no chance that anyone will actually want to use "OP_HASH160 [20-byte-hash-value] OP_EQUAL" as their entire scriptPubKey unless they're using P2SH, so I don't believe that BIP 16 undermines Script.

I find P2SH's use of special-case-scripts to be inelegant, though Script is already inconsistent and inelegant, so I don't care that much. Hopefully when the max block size is increased, Script will be totally revamped to fix all of the imperfections.

I'm amazed at how much argument there is over this tiny issue. BIP 16 and 17 have few real differences (and these differences are very technical), but it seems like everyone on this forum has some strongly-held opinion about it.

[ByteCoin]

I'm amazed at how much argument there is over this tiny issue.

The differences seem small and I'm confident that technical issues are not what is causing the controversy.
Of course, I would have liked OP_EVAL to succeed as I thought it led Bitcoin in a direction I thought would be healthy in the long run.

The current arguments bode ill for getting a vague consensus for more profound changes probably required in future. Imagine Satoshi trying to deploy IsStandard() if he had to deal with the current situation.

Part of the problem is that the pool operators are vital to the success of upgrades and they only really care about mining and the exchange rate!

ByteCoin

[finway]

http://blockchain.info/p2sh

I'm disapointed.

[Luke-Jr]

http://blockchain.info/p2sh

I'm disapointed.

Me too. Too many votes for BIP16

[Inaba]

The current arguments bode ill for getting a vague consensus for more profound changes probably required in future. Imagine Satoshi trying to deploy IsStandard() if he had to deal with the current situation.

Part of the problem is that the pool operators are vital to the success of upgrades and they only really care about mining and the exchange rate!

I don't think it bodes ill at all.  I think, in the future, if something like this is handled properly as a roll out, things will go very well.  This entire thing was botched from the beginning as far as the rollout goes and then quickly devolved into this mess. 

I also highly disagree that the pool operators only care about mining and the exchange rate.  Speaking personally, I care about what's best for the miners and the stability of the pool.  For my part, my objection over this is the fact that the timeframe was so short to make changes/deployment, after evaluating what, exactly, is being proposed.

[finway]

http://blockchain.info/p2sh

I'm disapointed.

Me too. Too many votes for BIP16

Oh, slush just started to support P2SH, it'll be more.

But surely P2SH will be delayed, again, because of you. Nice Work, Luke.

[Gavin Andresen]

I don't think it bodes ill at all.  I think, in the future, if something like this is handled properly as a roll out, things will go very well.  This entire thing was botched from the beginning as far as the rollout goes and then quickly devolved into this mess. 

We all learn from our mistakes.

Would you be willing to write an "informational BIP" describing how to do a rollout right in the future?

I'm terrible at that kind of "first we'll need to get buy-in from groups X, Y, and Z by doing A, B, and C, then each of those groups will elect representatives who will have three days to agree to a schedule, which will be announced blah blah blah blah"

[Inaba]

I'll have to review the BIP format and requirements, but I can probably put something together.  It's based on the Python development RFC format or something, yeah?

[Gavin Andresen]

I'll have to review the BIP format and requirements, but I can probably put something together.  It's based on the Python development RFC format or something, yeah?

Yes, BIPs are based on PIPs and BEPs (for Python and BitTorrent).  See BIP 0001 for the process.

[paraipan]

I'll have to review the BIP format and requirements, but I can probably put something together.  It's based on the Python development RFC format or something, yeah?

Yes, BIPs are based on PIPs and BEPs (for Python and BitTorrent).  See BIP 0001 for the process.

i think it would had a better success as BRFC (Bitcoin Request For Comments)

[Luke-Jr]

But surely P2SH will be delayed, again, because of you. Nice Work, Luke.

The only unnecessary delay at this point is from people trying to push BIP 16 through when we have a sane alternative. If everyone was focussed on BIP 17, we'd be there in no time.

[ByteCoin]

This entire thing was botched from the beginning as far as the rollout goes and then quickly devolved into this mess. 

My assessment is that the current state of disagreement is a rather freakish conspiracy of circumstances and would have been impossible to predict and/or avoid. Please outline how it was botched. Here's a little history as I see it:

In the beginning there was casascius' proposal which virtually nobody bothered to understand. This rapidly transformed into a proposal to "reinterpret" OP_CHECKSIG with some code to recognize legacy cases to ensure back compatibility. This was rejected because the special case interpretation was seen as a hack and destroyed the "purity" of the scripting language - rather ironic in light of the current hacky solutions. Gavin then gathered fairly broad support around my OP_EVAL proposal and everything was going smoothly for a few months until roconnor finds some bugs and some low-to-zero-practical-impact disadvantages. Gavin lobotomizes the scheme in an ugly fashion to allay these concerns, probably assuming that the adoption of the more cautious scheme will be uncontroversial. With reasonable justification but with little regard for propriety or the long-term consequences, Luke-Jr objects to Gavin's scheme's violation of the script and uses his considerable technical and social capital to engineer the scheme's failure. This brings us up-to-date.

To apportion the blame fairly, it should be mentioned that roconnor was threatening to spread FUD about the "dangers" of OP_EVAL if his demands were not met, regardless of the incidental damage to Bitcoin.

ByteCoin

[Red Emerald]

ByteCoin

So which BIP are you voting for?