BIP 17

[Luke-Jr]

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.

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

[1714176427]

1714176427

[1714176427]

1714176427

[1714176427]

1714176427

[1714176427]

1714176427

[1714176427]

1714176427

[Inaba]

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:

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.

[Gavin Andresen]

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

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.

[Luke-Jr]

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.

This was about OP_EVAL (BIP 12). All communications about BIP 16, if any, were kept secret until I brought it into public light... I don't recall getting any myself, despite running one of the top 10 pools.

[Costia]

gavin, do you have any commercial interest in implementing P2SH?

[RaggedMonk]

gavin, do you have any commercial interest in implementing P2SH?

[Costia]

somebody suggested that he had contacted a commercial company for making HW keys for bitcoin wallets - similar to what mtgox has.
to use such a device with bitcoin P2SH might be very helpful - 1 key on the PC , 1 key on the device

[Red Emerald]

somebody suggested that he had contacted a commercial company for making HW keys for bitcoin wallets - similar to what mtgox has.
to use such a device with bitcoin P2SH might be very helpful - 1 key on the PC , 1 key on the device

Even if Gavin does have a monetary incentive to implement P2SH, that doesn't mean he will only support BIP 16. It just means that he will want the code written quickly.  If he wants a company behind it, that is just more incentive to make sure that P2SH works properly.

The WTF image was posted because your question has little relevance, not because of some misunderstanding.

[Costia]

one of the reasons bip17 is not well accepted is because it will take more time to implement and test - delaying the introduction of P2SH.
I just want to make sure the reasons to opposing BIP17 are not commercial (aka a set release date for a commercial product).

Any bip16/17 thread gets off topic quite fast :\
if anyone wanted to know the details - they are posted in the wiki
I cant see any chance of an objective and/or productive discussion of this topic on the forums...

[Luke-Jr]

one of the reasons bip17 is not well accepted is because it will take more time to implement and test - delaying the introduction of P2SH.

BIP 17 is already implemented, and easily tested. The delays at this point are because people won't let BIP 16 go.

[cunicula]

one of the reasons bip17 is not well accepted is because it will take more time to implement and test - delaying the introduction of P2SH.

BIP 17 is already implemented, and easily tested. The delays at this point are because people won't let BIP 16 go.

It does seem like giving in to a guy with such one-sided interpretations of events is like giving into a terrorist. Since he is quite willing to approach controversies from an extremist and catastrophic point of view, there is no way to establish bargaining power with him unless you hold your ground.

quid pro quo won't work

[jtimon]

I don't have an opinion this, but I have some related questions.

1) Where is MAX_SIGOPS validated? In isStandard(), right?

I think it should be there. I'm ok with having that function for sanity, but I think the door should be open to stop using it in the future, to leave it out of the protocol (although maybe each implementation runs its own version of the function, depending on its performance variables). Not sure how each proposal affects that part I just read something about it somewhere in these discussions.

2) Probably there's a good reason but...Why a scripting language is needed in the first place?
Why don't just a set of validations that must be all true, operators with parameters and references to other elements in the script?

Standard Transaction to Bitcoin address

Code:

scriptPubKey: OP_HASH_EQUAL(<pubKeyHash>), OP_CHECKSIG(scriptSig[0])
scriptSig: <pubKey>, <sig> 

Multi-signature

Code:

scriptPubKey: OP_HASH_EQUAL(<pubKeyHash1>) OR OP_HASH_EQUAL(<pubKeyHash2>) OR OP_HASH_EQUAL(<pubKeyHash3>), 
       scriptPubKey[0], scriptSig[0] != scriptSig[1], OP_CHECKSIG(scriptSig[0]),  OP_CHECKSIG(scriptSig[1])
scriptSig: <pubKey1>, <pubKey3>, <sig1>, <sig3>

another valid scriptSig

Code:

scriptSig: <pubKey2>, <pubKey1>, <sig2>, <sig1>

Wouldn't something like this be more secure and achieve the same things?
Of course, this would not be feasible for compatibility issues, I just want to know the reasons behind the stack language.

EDIT
Sorry, I just found this thread:
https://bitcointalk.org/index.php?topic=61248.0

[Costia]

why not just add another field into a transaction at the output and implement the "ideal" 3 parts solution gavin sugested?
Is there a way to make old clients ignore an unknown field?
 

[jtimon]

EDIT
Sorry, I just found this thread:
https://bitcointalk.org/index.php?topic=61248.0

We could add a hashScriptPubKey field and let scriptPubKey be presented at redemption. My question remains.
Why do we need a stack based language?

3) Also, the scriptPubKey it's going to end up in the chain anyway. Why the moment matters so much?

why not just add another field into a transaction at the output and implement the "ideal" 3 parts solution gavin sugested?

As Gavin explains, it's not possible for backwards compatibility.
I'm not making a proposal, just trying to understand bitcoin better.
I'm not directly involved in the bitcoin development and I don't think my voice counts much in this purely technical controversy.
I mean, if both proposals end up being equally secure, for the end user, both do the same thing.

[[Tycho]]

3) Also, the scriptPubKey it's going to end up in the chain anyway. Why the moment matters so much?

If you are asking about the public key, then usually it appears in the blockchain only when it doesn't matters anymore (for one-time addresses).
So if someone can "break" the signature using only pubkey, he won't be dangerous because if pubkey is used for redeeming then that address is empty already.

[jtimon]

I found better answers for the third question:

-You would have to pay to long addresses.

(1) They are highly vulnerable to invisible substitution.  E.g. I can
 trivially take a P2S address, change one or two characters and get a
 script which is redeemable by anyone.  With P2SH you have to do
 computation which is exponential in the number of unchanged digits to
 get a look alike address.

 (2) The sender is fully responsible for fees related to the enlarged
 transactions. Even if _you're_ willing to take the txn-processing time
 and fee burden of a 30 person joint trust address,  random e-commerce
 sites will not be and will randomly reject your addresses.

 (3) They create another input vector for non-trivial data which must
 be inspected and validated, potentially presenting an attack surface.

 (4) They leave the complicated (long) release rules in the transaction
 outputs.  When a transaction is mined we can't be sure if it will ever
 be redeemed. The outputs are unprunable.   In a future world where
 many nodes prune output space is far more important than input space
 and it would make sense to require more fees for it because we're
 never sure how long it would need to be stored (making it an
 attractive target for someone who wants to make Bitcoin unusable by
 spamming it with worthless data).  P2SH reduces output sizes to the
 absolute minimum without inflating the total data size.

The other questions are still open.

[Qoheleth]

As someone who only understands the Bitcoin algorithm on a high level, I want to get a better understanding of what multi-sig is for.

My impression is that the feature involves the creation of an address with two private keys, each generated by a party who doesn't have to know the other one. In other words, an address where both key-generators would have to be compromised for the coins at that address to be compromised.

My impression was also that ECDSA already has that feature, based on some kind of magic where you multiply Party 1's private key and Party 2's public key (and vice versa). I remember Mike Caldwell (the Casascius guy) talking about this method with whoever runs Printbills as a possible means of adding confidence in the security of the Bitcoins backing a piece of physical currency.

Was one of these impressions incorrect? Does that magic of multiplying ECDSA keys not work really, or is there something else that these BIPs do that justifies a change in the protocol?

[Steve]

We could add a hashScriptPubKey field and let scriptPubKey be presented at redemption. My question remains.
Why do we need a stack based language?

As opposed to what?  A register based language?  Note that what bitcoin implements is just a bytecode interpreter, not a language.  You could chose to implement a more user friendly language that compiles to bitcoin bytecode if you chose to, but the benefits would be marginal at best given that the scripts are very small.  It's not like you have to wade through pages and pages of the stuff when talking about your typical script.  People have already invented a defacto language when talking about bitcoin scripts (using "OP_CHECKSIG" instead of its bytecode…or {} to denote stuff pushed on the stack).

[jtimon]

As opposed to what?  A register based language?  Note that what bitcoin implements is just a bytecode interpreter, not a language.  You could chose to implement a more user friendly language that compiles to bitcoin bytecode if you chose to, but the benefits would be marginal at best given that the scripts are very small.  It's not like you have to wade through pages and pages of the stuff when talking about your typical script.  People have already invented a defacto language when talking about bitcoin scripts (using "OP_CHECKSIG" instead of its bytecode…or {} to denote stuff pushed on the stack).

That bytecode is also a formal language. I'm not talking about performance improvements, so it doesn't matter much if the interpreter interprets bytecodes or strings containing operators names such as "OP_CHECKSIG". Both would be equivalent in what they can do (but the second notably worse for storage).
My point is, why have such a potent language?
Why not just a list of bytecodes that express conditions to be validated?
Separating from the beginning the operator scripts from the data?
You have a list of data and a stack of operators that can refer to that data as variables or use constants for the parameters of the operators.
You wouldn't have flow control or stack words, for example.
I guess the reason is to allow use cases that aren't thought of yet, but new words can be added later, as is the case for p2sh.
Well, kind of answered myself now: a more potent language needs to be extended less times and extending the language is really an issue with a blockchain to agree.

[Steve]

As opposed to what?  A register based language?  Note that what bitcoin implements is just a bytecode interpreter, not a language.  You could chose to implement a more user friendly language that compiles to bitcoin bytecode if you chose to, but the benefits would be marginal at best given that the scripts are very small.  It's not like you have to wade through pages and pages of the stuff when talking about your typical script.  People have already invented a defacto language when talking about bitcoin scripts (using "OP_CHECKSIG" instead of its bytecode…or {} to denote stuff pushed on the stack).

That bytecode is also a formal language. I'm not talking about performance improvements, so it doesn't matter much if the interpreter interprets bytecodes or strings containing operators names such as "OP_CHECKSIG". Both would be equivalent in what they can do (but the second notably worse for storage).
My point is, why have such a potent language?
Why not just a list of bytecodes that express conditions to be validated?
Separating from the beginning the operator scripts from the data?
You have a list of data and a stack of operators that can refer to that data as variables or use constants for the parameters of the operators.
You wouldn't have flow control or stack words, for example.
I guess the reason is to allow use cases that aren't thought of yet, but new words can be added later, as is the case for p2sh.
Well, kind of answered myself now: a more potent language needs to be extended less times and extending the language is really an issue with a blockchain to agree.

Right…and with p2sh, the impetus is really on the receiver of coins to ensure whatever script they come up with is free from any defects that might allow unauthorized people to spend their coins.  Which is how it should be.  Someone could create a script that allowed anyone to spend the coins, but that's an issue for the script author, not bitcoin itself.  If anything, scripts should be allowed to access even more data related to a transaction or the block chain.  For instance, your script might check whether the input transaction has at least N confirmations.  Or it might want to check that a certain percentage of the input amount goes to certain output addresses (you can imagine this might be useful for a payment processor like bit-pay that doesn't want to ever have control over the full amount of a transaction, but instead just redirect a percentage of the value of the transaction).