Topic: BIP 16 analysis from a miner's point of view (Read 3127 times)

Making an OP_P2SH really seems like the best option.  The objection that BIP16 creates a special case isn't confined to just Luke; plenty of other people also see that as a valid concern.  One name that stands out in my memory because I specifically asked him about it is Tycho.

Of course, Gavin also has objections to OP_P2SH, and while I don't think those objections are fatal (see my reply), I'm not the one doing the work so my opinion doesn't mean shit.

In particular, I think that we could define OP_P2SH in a way that has very strict limits today, but the ability to be used in a more flexible way tomorrow if we determine that it is safe to do so.

For example, we could require that it appear no more than once, and if present it must be the first (or last) opcode in a script and reject any transaction that includes it in any other position, or even reject any transaction where the script doesn't exactly match the existing BIP16 template.  This would be pretty simple to add to the existing BIP16 code.

But then down the road, we could gradually relax things as needed.

Say you want to make a transaction that can be redeemed by either of two different P2SH payloads.  You rewrite the first stage script to include two hashes and verify that the script matches at least one of them.  OP_P2SH still must be first, but now there are two possible templates.

Down the road, someone wants to write a conditional script that can be redeemed either with a key or a P2SH payload.  You allow OP_P2SH to be found elsewhere in the script, maybe even inside of a OP_IF block.

What I'm trying to get at is that OP_P2SH could be added today, which would ease some valid concerns, and for relatively low cost, and in a way that allows us room to change in the future.

And for what it's worth, I'm a strong supporter of P2SH, even without OP_P2SH.  My miners are currently set to only use pools that either support or intend to support P2SH very soon and my experimental p2pool deployment tool defaults to supporting it.  I trust Gavin's judgment on this, my only real disagreement is over how to sell it to the rest of the community.

BIP17 advocates (mostly Luke) argue that BIP17 is more conservative, because the change in behavior is conceptually more clean and less "special".  BIP16 advocates counter that the BIP16 change is more focused and narrow (And point out that old nodes still do at least superficial validation of BIP16, and other minor technical details) and that this makes it more conservative. BIP17 points out that its patches are somewhat smaller, BIP16 could counter that thats because BIP17 leaves some minor technical shortcomings open.  I don't think there is an objective way to settle that, they're all earnest perspectives.

During the discussion that was to become BIP16 I suggested that we satisify Luke by simply sticking a completely pointless OP_NOP at the end.. an OP_MAKEITSO, if you will:

09:35 < gmaxwell> sipa: okay, so lets end this argument and add a freeking op_code for this for luke.
[...]
09:36 < gavinandresen> I don't like adding an extra byte to make luke-jr feel better.

But doing this would perpetually bloat the blockchain a bit just so that Luke (and now a few others) would feel better about the cleanliness of the solution.  It's a real cost that will cost bitcoin users real money now and in the future and will contribute to the loss of decentralization as bitcoin grows.

I think Gavin is also rightly concerned about placating Luke for the sake of placating Luke. Luke's argument style is a bit like terrorism: He's a hard working contributor, and sometimes easy to compromise with, but sometimes when things don't go his way he just keeps turning up the rhetoric until everyone else burns out or folds.

Ignoring the bloat issue, it's good to avoid burning up NOPs:  We only have 10 of them, 9 really because the first one has been randomly used in toy transactions, when people really weren't thinking about what the NOPs were actually there for. Because they are our only method for adding explicit behavior in a backwards compatible way we must steward them carefully.

Luke's BIP17 avoids creating that bloat by making his new OPcode also do what two of our existing opcodes (HASH160, OP_EQUAL) do in addition to the MAKEITSO part.  The primary cost of this is that his transactions look like pay to anyone, rather than pay to hash-secret to old nodes.

In discussion Luke also indicated that he'd find BIP16 more acceptable if it was written so that BIP16 style transaction were expressed in the documentation just as a series of special bytes, not as a script and if old style transactions were deprecated (at least for new usage). His opinion there is that doing this would just make BIP16 the new way of doing things, not a special case (but rather the old outputs would be the special case).  I think Gavin made a political error by not just going along with that.   (Luke would point out that he's glad Gavin didn't because it caused him to propose BIP17 which he believes to be better than BIP16 with the "right" description).

The thing that bothered me most about BIP16 is that the execution of the script in scriptSig is triggered by recognition of a special pattern of opcodes in the scirptPubKey.  BIP17 seemed cleaner in that it adds a new opcode that essentially says "compute the hash of the code following the most recent OP_CODESEPARATOR and verify it."  Execution of this code happens because it's simply in the normal flow of opcodes.  From the perspective of what these BIPs enable, both of them are workable.  But Gavin's concern should give us all concern.  He's earned enough credibility that you shouldn't really disagree with his position unless you take the time to really study the current script engine as well as the history of how it evolved to where it is today.  And my superficial understanding is that BIP16 is less of a departure from the historic conventions in terms of how scripts get executed and what types of opcodes have been traditionally used in the scriptSig. 

BIP16 might be overly conservative, but at the same time its hard to argue against being overly conservative when the objections to BIP16 are largely just a matter of aesthetics.

Interesting. I don't understand completely but i'm making efforts

So the most secure and conservative way to implement the feature would be BIP16, a little more error prone too, given the amount of coding work that was needed, but nothing that can't be managed.

My understanding was that OP_NOP codes were left there exactly for these purposes that's why i thought you would be using them.

It's not possible to bypass the scripting system while remaining compatible with bitcoin.

BIP16 uses the script "OP_HASH160 [20-byte-hash-value] OP_EQUAL"

BIP17 uses the script " [20-byte-hash-value] OP_CHECKHASHVERIFY OP_DROP"  but OP_CHECKHASHVERIFY isn't something that existed already, it's something that Luke made up for the purpose of BIP17.  In order to make it compatible it's overlaid on top of OP_NOP2.

From the perspective of prior software nodes BIP16 transactions say "Check that the data the redeemer is providing hashes to this value from the address, if so then allow redemption" and BIP17 transactions say "allow redemption" (no condition).

From the perspective of new nodes both say "Check that the provided bitcoin script hashes to the value from the address, then execute it".   The execution is implicit in both cases, the BIP16 style uses an existing way of saying hash some data and check it (which is why old nodes are able to do that much validation) but gives it special meaning for this case, the BIP17 style introduces a completely novel way of checking hashes which is ignored by old nodes in order to make the implied execution special to just the new opcode it introduces.

You understand wrong.

BIP 16 recognizes a certain pattern of bytes, and says "If you see those bytes, then the script will be provided by the person who has the coins instead of the sender (the sender just provides a secure hash of that script)."

The script that is provided is then used EXACTLY as if it was a "normal" sender-provides-the-script transaction.

BIP16 is the most conservative possible solution to the problem we want to solve.

Thanks for being you the one to try give a "serious reply".

The way i understand it BIP16 changes completely the scripting system for the p2sh transactions. How ? bypassing it. Seen lot of code examples already. BIP17 uses an existent placeholder OP code to fit it's needs and another one that seems to have been put there by Satoshi himself.

Since no one has given you a serious reply—  No, this is completely unrelated.

At the level of similarity you're perceiving there the already existing bitcoin system also fits.   BIP16/BIP17 don't change the behavior of the scripting system except in changing _when_ the script requirements for the disposition of a transaction are provided. With P2SH you commit to your requirements when you pay (by giving a hash of them) but they're provided by the spending transaction.

It doesn't change the scripting language, make it more powerful or turing complete.  BIP12 did increase the expressive power some by adding limited recursion, but no one wants to go that way now.

Actually genjix himself assigned 0016 for that purpose.

My PM to genjix:

genjix's reply:
Just to settle the score.

+1    

meh this will clear out in the end and every one will know better it's place, developers write programs, miners make them work, so users can use them without hassle

Yeah, what's the CIA's agenda with Bitcoin? Let me guess: "no need to know".

I really don't like the discussion about some "Commitees" or letting some small group of ppl decide about this over here: https://bitcointalk.org/index.php?topic=61922.0;all.

I think major changes should be tested thoroughly and not rushed.
 

great, finally someone to tell the truth

The reason I closed it down was because Gavin works for the CIA, and I wanted to shut down all the dissenters. The BIP process is so that we can scheme together, make it BIP law then force everyone to comply.

Occam's razor.

i should put mine right away 

dunno, so all my post is mot ? the 2112's paper resembles actual bip 16 implementation, a script hash that always verifies, being backward compatible and the new clients actually running the scripts.

its a consipracy! where is my tin foil hat 

That stuff is totally unrelated to BIP 16. It was removed because 2112 was using that BIP number without having it assigned to him.

Hey guys just found something interesting on BIP 16, i opened another thread no to get off-topic this one https://bitcointalksearch.org/topic/bip-16-17-in-laymans-terms-61125
I should state that i'm not biased in any way pro/against this BIP the only thing is the way it was introduced to the community opened my appetite for researching it a bit more.

Going backwards on the updates (commits) of the bitcoin source code i found this reference

https://github.com/bitcoin/bitcoin/commit/922e8e2929a2e78270868385aa46f96002fbcff3

so thinking a bit, Gavin stated in some threads that he's been pushing this change for a few months now, but that could only be true with the scraped OP_EVAL because p2sh change is authored January 05, 2012. So when did bip 16 appeared first time ?
The BIP states 03-01-2012, https://en.bitcoin.it/wiki/BIP_0016, with a very small deadline to "vote" for it, Feb 1, 2012, and a two week time to implement, without thoroughly testing it, on Feb 15. That deadline was familiar... yes, you guessed it, it was the OP_EVAL's

https://en.bitcoin.it/wiki/BIP_0012
https://github.com/bitcoin/bitcoin/commit/a0871afb2b1d6d358c833fd08bca2f13c840fd4d

Meh, this doesn't sound quite right in a project like this. So i digg'ed more. Looking at BIP 16 page history on the wiki i saw that the original proposal was done by user "2112" on Dec 18, 2011 and scraped by Genjix then put in it's actual form by Gavin on Jan 4, 2012.

https://en.bitcoin.it/w/index.php?title=BIP_0016&action=history

Couldn't help myself to look at the original proposal and find a reason why it was changed in such a manner

https://en.bitcoin.it/w/index.php?title=BIP_0016&oldid=21016

Some citing:


Self explanatory


At first i didn't get it but then it hit me, remembered what some guys said about bypassing the present scripting system by putting only the hash of the script and doing the actual checking in memory (stack) by executing the script code there.


So someone would be able to do "amendments" on those scripts running on bitcoin clients.


Man, this doesn't sound right...


Now i felt shivers on my spine


Meh, so the script could be checking up it's code too

tl;dr


(1) Arbitrary code that uses as support p2sh transactions
(2) Network communication between those small scripts
(3) Self aware of it's code

woot, dunno what to say

edit: cut off the part about skynet