Topic: BIP 17 - page 2. (Read 9151 times)

Just FYI: I contacted the top ten mining pools (as listed in the stickied threads in the Mining Pools subforum) directly via email way back in October, copied the email to them in the Mining Pools forum, and kept them 'in the loop' on all of this.

I probably should have posted all of my followup emails to them in the Mining Pools forum, also; as I said, I'm terrible at that kind of "keep track of who you've told what and make sure you've got 'buy-in' from X Y and Z" thing.

I think my only really major blunder was being too stubborn about inserting some wording into BIP 16 that Luke wanted inserted; I let my emotions cloud my judgement.

I left out the outline you already gave, as I have no objective assessment as to it's accuracy (or inaccuracy) - the part I would add, that I would consider the important botched part:

BIP 16 proposed on 3 Jan 12, deadline for changes to bitcoind for miners (realistically, the big pools) to be 1 Feb 12.  Giving less than 4 weeks to implement changes, test, deploy and mine.  No direct contact of the major players making up 55%+ of the mined blocks, with the possible exception of Slush(?) and/or Tycho (?) in "secret." 

The time frame is too short, and the lack of communication as to the ramifications/reasons to the people who mine the majority of the blocks is the problem.  If either of those two situations had been handled, the other one probably would have sorted itself out, but since neither issues was handled properly, the entire operation was botched.

You forgot to mention "engineering its failure" includes "engineering a better, sane proposal"... BIP 17

So which BIP are you voting for? 

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

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.

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

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

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?

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"

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

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

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.

Me too. Too many votes for BIP16

http://blockchain.info/p2sh

I'm disapointed.

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

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.

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

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.

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

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.

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

Where MetaEvaluate is a function that:

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.