Old P2SH debate thread

[rjk]

This pissing contest made me curious enough to try an understand the various code snippets and documentation (or lack thereof) of each proposal, something I have never been goaded into previously.

I believe that OP_CODEHASHCHECK is a dead end. Further, I believe that while OP_EVAL could be nice to have, /P2SH/ addresses concerns with it, and remains useful for the majority of users, if implemented properly.

I therefore cast my vote for /P2SH/.

[1714002906]

1714002906

[1714002906]

1714002906

[Steve]

I believe that OP_CODEHASHCHECK is a dead end.

Could you explain why you think it's a dead end?  BIP17 seems cleaner to me, but with an upgrade related security issue.  While BIP16 seems like a hack (and I don't like OP_EVAL if only for the fact that it makes static analysis more difficult and it doesn't really add much capability aside from running some code in a slightly different context (outside of the scriptSig execution context)).  There also seems to be a strong urge to not allow the full use of scripting facilities in scriptSig, which I can only attribute to a "cargo cult" that has formed based on past issues.  Both BIPs seem to be contortions that try to do things in a backward compatible way…and actually, I think "backward compatible" is the wrong way to look at it.  They aren't backward compatible at all…it's just that they are designed to exploit some permissiveness in the validation rules of old clients…but the old clients aren't actually doing what they need to do with respect to validating these new kinds of transactions.  I have a strong feeling that this is wrong headed.  It would be better for the old clients to reject these new transactions and for miners to upgrade and once there is general agreement that 70 or 80% of the mining power is ready to accept the new transactions, then set a date a month or two out when miners will start allowing them.  Any stragglers (miners or clients) will quickly switch over when they realize they are at risk of having un-marketable coins.

P.S.  It also occurs to me that as a "democratic money" that this process is exactly the way it should happen.  Trying to exploit the permissiveness of old clients feels like it's subverting what should be an, albeit painful, but consensus building exercise.

[rjk]

I believe that OP_CODEHASHCHECK is a dead end.

Could you explain why you think it's a dead end?  BIP17 seems cleaner to me, but with an upgrade related security issue.  While BIP16 seems like a hack (and I don't like OP_EVAL if only for the fact that it makes static analysis more difficult and it doesn't really add much capability aside from running some code in a slightly different context (outside of the scriptSig execution context)).  There also seems to be a strong urge to not allow the full use of scripting facilities in scriptSig, which I can only attribute to a "cargo cult" that has formed based on past issues.  Both BIPs seem to be contortions that try to do things in a backward compatible way…and actually, I think "backward compatible" is the wrong way to look at it.  They aren't backward compatible at all…it's just that they are designed to exploit some permissiveness in the validation rules of old clients…but the old clients aren't actually doing what they need to do with respect to validating these new kinds of transactions.  I have a strong feeling that this is wrong headed.  It would be better for the old clients to reject these new transactions and for miners to upgrade and once there is general agreement that 70 or 80% of the mining power is ready to accept the new transactions, then set a date a month or two out when miners will start allowing them.  Any stragglers (miners or clients) will quickly switch over when they realize they are at risk of having un-marketable coins.

I think that what it achieves is only a short-term solution, and will quickly need to be supplemented to be worth using in the long term - whereas /P2SH/ looks to me like a more complete option.

However, please do note that this isn't the kind of thing I mull over daily, and after such a cursory overview that is what jumped out at me. So take it for what it is worth.

[Steve]

I believe that OP_CODEHASHCHECK is a dead end.

Could you explain why you think it's a dead end?  BIP17 seems cleaner to me, but with an upgrade related security issue.  While BIP16 seems like a hack (and I don't like OP_EVAL if only for the fact that it makes static analysis more difficult and it doesn't really add much capability aside from running some code in a slightly different context (outside of the scriptSig execution context)).  There also seems to be a strong urge to not allow the full use of scripting facilities in scriptSig, which I can only attribute to a "cargo cult" that has formed based on past issues.  Both BIPs seem to be contortions that try to do things in a backward compatible way…and actually, I think "backward compatible" is the wrong way to look at it.  They aren't backward compatible at all…it's just that they are designed to exploit some permissiveness in the validation rules of old clients…but the old clients aren't actually doing what they need to do with respect to validating these new kinds of transactions.  I have a strong feeling that this is wrong headed.  It would be better for the old clients to reject these new transactions and for miners to upgrade and once there is general agreement that 70 or 80% of the mining power is ready to accept the new transactions, then set a date a month or two out when miners will start allowing them.  Any stragglers (miners or clients) will quickly switch over when they realize they are at risk of having un-marketable coins.

I think that what it achieves is only a short-term solution, and will quickly need to be supplemented to be worth using in the long term - whereas /P2SH/ looks to me like a more complete option.

However, please do note that this isn't the kind of thing I mull over daily, and after such a cursory overview that is what jumped out at me. So take it for what it is worth.

Ok.  I tried to wrap my head around it over the weekend.  What gives me pause with both OP_EVAL and BIP-16 is that they are pushing code onto the stack for later execution.  This undermines the deliberate desire to keep the scripting language non-turing complete.  An example of the things that I wonder about with OP_EVAL is could I nest an OP_EVAL in serialized code I push on the stack.  The "standard transactions" checks could trivially stop such a thing, but you've now created a situation where you're dependent on such "standard transactions" checks for the security of the system.  I would instead like to see a day where there is enough confidence in the implementation of the scripting system that such checks could be discarded.

I have a lot of experience in language and virtual machine design (bytecode interpreters, JIT VMs, and dynamic translation engines), so this topic is very interesting to me.

[Luke-Jr]

They aren't backward compatible at all…it's just that they are designed to exploit some permissiveness in the validation rules of old clients…but the old clients aren't actually doing what they need to do with respect to validating these new kinds of transactions.

They wouldn't be validating them in any case. This backward compatibility allows them to keep working with transactions they do recognize. The permissiveness being "exploited" (at least for BIP 12 and 17) was put there expressly for this purpose.

It would be better for the old clients to reject these new transactions and for miners to upgrade and once there is general agreement that 70 or 80% of the mining power is ready to accept the new transactions, then set a date a month or two out when miners will start allowing them.

The change you're describing requires 100% of not just mining power, but also all users (including merchants who may be unable to upgrade for various reasons). The backward compatibility in BIP 12,16,17 allows upgrading the network with only a super-majority among miners' consensus.

P.S.  It also occurs to me that as a "democratic money" that this process is exactly the way it should happen.  Trying to exploit the permissiveness of old clients feels like it's subverting what should be an, albeit painful, but consensus building exercise.

This change is actually fully in line with "democratic money"; what Bitcoin is, at the core protocol, is in fact "unanimous money".

I think that what it achieves is only a short-term solution, and will quickly need to be supplemented to be worth using in the long term - whereas /P2SH/ looks to me like a more complete option.

The only long-term benefit of BIP16 over BIP17 is that you can fit more multi-factor addresses into a block before the inevitable Bitcoin 2.0 upgrade is needed. If we do end up needing that much before Bitcoin 2.0, we can roll out something similar to BIP12/16 at that time, presumably after we've had many more months to consider the consequences.

[DiThi]

This is a stressful war because they set hard dates again and again, rushing to tell miners when most of them aren't even aware of this (and some didn't see BIP 17 that replaces the CHC idea), or just don't care.

Check out this soft schedule proposal.

[markm]

If scripting is mostly disabled anyway except for a few special cases, and using a special case is "the way to go" for this feature, then maybe in an ideal coin (think altcoins here if inability to change bitcoin itself this deeply this late in the game) should from the outset just have special cases and no actual scripting?

Do we know yet what scripting actually buys us? If so, maybe each use-case can be provided as a special case and scripting per se never even be contemplated let alone actually implemented or deployed?

One might argue that scripting allows future use-cases we have not yet thought of, but special cases could too, the new thing could simply be added to the list of special cases. Our 'opcodes" could simply be enumerators, enumerating the "special cases" aka "use cases"?

Bastardising our scripting language by hacking "special cases" over it or subverting our list of allowed cases aka use cases aka special cases by having a "scripting language" both sound bad, shouldn't we either go with a script language or go with an enumerated list of special aka use cases, one or the other, instead of a hack job that is neither cleanly but instead has possibly the downsides of both?

-MarkM-

[runeks]

One might arge that scripting allows future use-cases we have not yet thought of, but special cases could too, the new thing could simply be added to the list of special cases. Our 'opcodes" could simply be enumerators, enumerating the "special cases" aka "use cases"?

In my opinion, a scripting language makes sense, even if it's disabled. In any case, enabling a disabled scripting language seems much easier than implementing a scripting language in a currency that didn't support it to begin with. I suspect this is the reason that Bitcoin has a scripting language.

I agree with the developers that Bitcoin is at a stage where it is too early to fully unleash the power of the scripting language. I think Bitcoin needs time to mature, and attract attention, developers and capital, in order to enable us to create a secure implementation of the scripting language.

It seems to me that the developers acknowledge that a powerful scripting language is a double-edged sword. It adds tremendous power and an almost unlimited number of use cases to the currency, while at the same time greatly increases the number of routes through which an attacker can subvert Bitcoin. I think it's sensible that Bitcoin was born with a scripting language that is currently de facto disabled.

My point is that special cases cannot ever provide the functionality of a scripting language. But a restricted scripting language can provide the functionality of special cases. Currently, I think it's sensible to restrict Bitcoin in this way, while still retaining the option of enabling scripting entirely when we feel that we have a secure implementation of the scripting language.

[os2sam]

I'm pushing this hard because I'm tired of hearing that users lost their bitcoins to trojans and viruses

And how many of those losses are not fault to the person who lost them?  Making a change to the network because of bad or irresponsible behavior is NOT a good idea?

So what is the current deficiency in the Bitcoin technology/network which has NOTHING to do with human behavior that requires this change?
Sam

[kjj]

I'm pushing this hard because I'm tired of hearing that users lost their bitcoins to trojans and viruses

And how many of those losses are not fault to the person who lost them?  Making a change to the network because of bad or irresponsible behavior is NOT a good idea?

So what is the current deficiency in the Bitcoin technology/network which has NOTHING to do with human behavior that requires this change?
Sam

You've never heard of safety engineering have you?

One guy crashes a plane into a mountain, pilot error.  Several people crash the same type of plane into mountains, design problem.

Lots of bitcoin users have crashed into mountains.  Each one of them made a mistake.  Gavin is trying to change the design so that the system is much more tolerant of these mistakes.

[os2sam]

I'm pushing this hard because I'm tired of hearing that users lost their bitcoins to trojans and viruses

And how many of those losses are not fault to the person who lost them?  Making a change to the network because of bad or irresponsible behavior is NOT a good idea?

So what is the current deficiency in the Bitcoin technology/network which has NOTHING to do with human behavior that requires this change?
Sam

You've never heard of safety engineering have you?

One guy crashes a plane into a mountain, pilot error.  Several people crash the same type of plane into mountains, design problem.

Lots of bitcoin users have crashed into mountains.  Each one of them made a mistake.  Gavin is trying to change the design so that the system is much more tolerant of these mistakes.

The problem is still behavioral and has already been solved with encrypted wallets.

If we make changes to the Bitcoin protocol to ameliorate every possible human error we will end up with an unusable system.
Sam

[rjk]

The problem is still behavioral and has already been solved with encrypted wallets.

If we make changes to the Bitcoin protocol to ameliorate every possible human error we will end up with an unusable system.
Sam

Do you know what a keylogger is? It is something that renders an encrypted wallet essentially useless. Requiring more than one diverse device to confirm a transaction is another solution to this issue.

The bitcoin developers certainly have NOT been adding features willy-nilly left right and center. To say otherwise is simply delusional.

[os2sam]

The problem is still behavioral and has already been solved with encrypted wallets.

If we make changes to the Bitcoin protocol to ameliorate every possible human error we will end up with an unusable system.
Sam

Do you know what a keylogger is? It is something that renders an encrypted wallet essentially useless. Requiring more than one diverse device to confirm a transaction is another solution to this issue.

And how does one go about getting a keylogger on their system?  Largely by bad behavior.

The bitcoin developers certainly have NOT been adding features willy-nilly left right and center. To say otherwise is simply delusional.

I agree completely, so far.

But implementing this change to offset an persons behavior would be setting the precedent that it's the Bitcoin technologies responsibility,  and require future changes, which could lead to "willy-nilly left right and center" changes.
Sam

[eldentyrell]

In my opinion, a scripting language makes sense, even if it's disabled. In any case, enabling a disabled scripting language seems much easier than implementing a scripting language in a currency that didn't support it to begin with.

Sadly this isn't true!  It has do to with the way in which the opcodes in the existing scripting system were disabled -- or perhaps more accurately "never enabled".

Existing clients treat any script containing a disabled opcode as invalid.  As a result, enabling a disabled opcode requires upgrading all clients (miners, exchanges, end-users, etc).

OP_EVAL/P2SH/CHV work because they transfer validity-checking responsibility from the end-user to the miners, resulting in a much smaller set of clients to upgrade.

[os2sam]

Also, there ARE other solutions to the P2SH need/problem.

Is there a problem? or do you have yet another solution in need of a problem to solve?

[Luke-Jr]

Also, there ARE other solutions to the P2SH need/problem.

Is there a problem? or do you have yet another solution in need of a problem to solve?

Yes, the problem with BIP 16 is obvious and I and others have discussed it enough. Read the BIP, or at least genjix's summary.

[Gavin Andresen]

Yes, the problem with BIP 16 is obvious and I and others have discussed it enough. Read the BIP, or at least genjix's summary.

In my humble opinion, this kind of trash talk against BIP 16 is bad for Bitcoin.

The poll in this thread says the community prefers BIP 16.

The chart on the bitcoin wiki says the core developers prefer BIP 16.

And the actions of the big mining pools and independent miners says that they overwhelmingly prefer BIP 16.

Luke, I'd be delighted to add Eligius to the list of pools that are supporting BIP 16 in my signature.

[os2sam]

Yes, the problem with BIP 16 is obvious and I and others have discussed it enough. Read the BIP, or at least genjix's summary.

In my humble opinion, this kind of trash talk against BIP 16 is bad for Bitcoin.

The poll in this thread says the community prefers BIP 16.

The chart on the bitcoin wiki says the core developers prefer BIP 16.

And the actions of the big mining pools and independent miners says that they overwhelmingly prefer BIP 16.

Luke, I'd be delighted to add Eligius to the list of pools that are supporting BIP 16 in my signature.

The poll in this thread is worthless as it doesn't ask the real question.

Please give a real reason for this change.  Is there a flaw in the Bitcoin technology that requires this?  Or are you all trying to ameliorate a flaw in human nature with software?
Sam

[os2sam]

Please give a real reason for this change.  Is there a flaw in the Bitcoin technology that requires this?  Or are you all trying to ameliorate a flaw in human nature with software?
Sam

Bitcoin is money that is stored on computers and spent via the internet. Because I have to access the internet to spend my coins, there is potential risk. Adding features that make it more difficult for someone to steal coins is a worthwhile goal. There doesn't need to be a flaw in order to improve the system.

Automobiles work perfectly without airbags. People can travel from point A to point B without them. But airbags might save lives if there is an automobile accident. Would you argue that we shouldn't add airbags to cars because there is no flaw in the technology that prevents us from traveling from point A to point B?

Here's how I currently secure my Bitcoins. I create new wallets on a sterile offline computer and then send coins to them. This makes spending those coins troublesome, especially if I want to retain that level of security. I don't feel secure enough to allow myself easy access to spending my coins because I realize a simple key logger can defeat encrypted wallets.

Being able to choose how many different physical machines are required to spend my Bitcoins would make me feel much more comfortable when accessing my offline storage.

I try to practice safe computing habits as much as possible (keep OS and browers up to date, hardware and software firewall, avoid "sketchy" websites, etc.), but the threat of a compromised computer is unlike most threats because I probably won't see it coming until it's too late. With Bitcoins, once they are gone, there is no getting them back.

And this doesn't even speak of the other uses that multi-sig will enable. For example, shared addresses that require two (or more) parties' agreement to spend the coins. This kind of utility will allow Bitcoin to be adopted by more people in more places. Businesses with several owners can hold accounts that no one person can drain.

I don't know which multi-sig is the best, but normal users having access to the feature is something that should have been available from the start. As slow as it's going though, I'm planning on using Armory's offline transaction feature as my go-to security method in the future. I probably won't need multi-sig for uses other than security, but I certainly don't think that is the case for everyone.

But your talking about modifying the block chain which will be permanent.  There may be unforeseen consequences that I have seen no evidence that they have been thought through.  Also the security environment with our PC's and the internet are not static.  The way Bitcoin is currently implemented is not be the way it will implemented in the future.

Making changes which break backward compatibility should be avoided unless absolutely necessary.  The case has not been made that this is absolutely necessary, at least to my satisfaction.  Additional security can be implemented in the Bitcoin Client, third party services or new hardware devices that haven't been developed yet all which would require no change to the protocol and block chain.

By the way don't get me started on the car air bag fiasco.
Sam

[os2sam]

But your talking about modifying the block chain which will be permanent.  There may be unforeseen consequences that I have seen no evidence that they have been thought through.  Also the security environment with our PC's and the internet are not static.  The way Bitcoin is currently implemented is not be the way it will implemented in the future.

Making changes which break backward compatibility should be avoided unless absolutely necessary.  The case has not been made that this is absolutely necessary, at least to my satisfaction.  Additional security can be implemented in the Bitcoin Client, third party services or new hardware devices that haven't been developed yet all which would require no change to the protocol and block chain.

By the way don't get me started on the car air bag fiasco.
Sam

I agree. We should be prudent when making changes that involve the block chain. That doesn't mean we should avoid them at all costs.

What's more concerning is that one pool can effectively stop such changes. While that may or may not be a good thing today, who knows what the future holds? Before you suggest that the miners are there because they support the pool op's position, consider what would happen if the pool op decided to support BIP16 today? Would there be a mass exodus? I highly doubt it. I doubt much would change at all. Would you make the effort to switch to a pool that aligns with your vote?

I do think changes should be avoided at all cost's, UNLESS ABSOLUTELY NECESSARY!  I understand there was a change the HAD to be made because of an actual flaw, that is/was appropriate.  This issue can be ameliorated in so many other ways, and is, that folks should question it a little more than they are.

I am not concerned about one pool effectively preventing the change by not voting for it and that is why I am mining there full time right now.  And if Tycho did start supporting BIP16 and the implementation was NOT a done deal I would mine elsewhere until it was implemented or defeated, granted at that point it wouldn't really make a difference except clear my conscience if things did go awry because of one of these multi-sig schemes.

I am much more concerned with the Bitcoin community trying to strong arm and badger a pool op into doing what they want and effectively take away my voice of dissension in the process.  That is very troubling to me.

Would there be a mass exodus from Deepbit if they decided to support multi-sigs?  I don't know.  But Deepbits hash rate is up significantly recently, whereas BTCGuild is about level where it has always been but Ozco is significantly higher for that pool in support of it.

So I don't think the personality of Tycho by him/her self will defeat what the rest of the community wants but if it is defeated it will be by the voice of miners Deepbit represents.
Sam