Topic: Old P2SH debate thread - page 2. (Read 19705 times)

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.

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.

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

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.

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


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

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.

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

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.

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

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.

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-

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.

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.

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.

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

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.

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.

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.

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.

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

I try not to respond to trolls, but....

Quit spreading FUD. If you think BIP 16 is terrible, please give a rational reason, beyond "It is a special case," which I have repeatedly responded to.

BIP 17 is implemented.

No, it really hasn't been going on very long.

BIP 16 is terrible, and de facto protocol breakage. BIP 17 can get us there tomorrow if we really need to rush. It doesn't require longer addresses, nor bloat the blockchain (in fact, it saves more space than BIP 16 does!), nor is it remotely turing complete (it doesn't even require an eval-like function at all!).

I can't see any better implementation yet.  This has already been discussed for a long time.  BIP 16 is a good solution, and the only way to get there in the near future.  Neither longer addresses and blockchain bloat, nor turing completeness in the scripting language seems like better solutions to me.  BIP 16 has the greatest support by a large margin, so please let us just get BIP 16 out there.