Topic: BIP 16 / 17 in layman's terms - page 8. (Read 38982 times)

This whole thing seems more of a personal attack by Gavin against Tycho than an actual announcement. Almost as though he's trying to manipulate the people away from the biggest pool using propaganda and exaggerations, trying to make Tycho into the scapegoat in case his slapdash change is rejected. Does Gavin feel marginalized or something?

Why couldn't Gavin have just pushed the change through without making this hate topic, see if any of the mining pools rejected it? Ferret out some actual villains instead of baselessly accusing people before the fact.

It's an awful risk I'm taking just asking this, since admins can just ban anyone and delete their posts in order to censor dissenters, but I must voice this lack of confidence in Gavin's leadership.

Oh yeah, no. That way of thinking lies ruin and pain, sir.  Having run the ShowEQ project for over a decade (though I haven't really been the active lead developer for years), I learned the hard way that adhering to the original creators intent is not the path to enlightenment.  Only by objectively observing reality and responding to that are you going to develop a better piece of software.  Once you let a piece of software into the wild, you can continue to shepherd it, if you so choose... but it belongs to everyone at that point.

That and I learned social contracts are worth shit when it comes to corporate interests.  

It's his project, just because he's not here doesn't mean his friends and coworkers are gonna undo conscious decisions that were made in development. Some of them were made to fix exploits. 

Because he is. http://bitprayer.com/ Praise Satoshi!

why is satoshi treated like some supreme being?
"satoshi did that , so he must be right"
"Maybe satoshi thought this so we shouldn't do that"
this is becoming religious

Alternatively, testers could just as well run BIP 17 on testnet with an activation date of 0; then they'll reject non-BIP17 blocks.

Just to clarify, BIP 17 does not in any way revert this change. scriptSig and scriptPubKey are still executed separately. There is just a new single value passed from scriptSig to scriptPubKey, just like the stack we already pass.

Testing is actually one of the reasons I don't like BIP 17; it is harder to test, because it is much easier to steal BIP-17 transactions if the network hasn't yet upgraded (Luke has had to test BIP 17 on the main network instead of testnet because I wrote a BIP-17-stealing robot and ran it on testnet).

I've spent the last couple of days running "transaction fuzzing" tests against both the new BIP 16 code and old clients; so far it has turned up no problems. "Fuzzing" means throwing lots and lots of random inputs at a program and making sure it deals with them properly; it is another good way of finding the "what do you know, we didn't think of that..." bugs.

The fuzzing tool is here:
  https://github.com/gavinandresen/bitcoin-git/tree/fuzzer

Also RE: ghastly exploits:

Satoshi himself made changes to the way the scripting language works after a series of 'ghastly exploits' were discovered back in 2010 after the first slashdotting. I'm so stubbornly against BIP 17 because it basically reverts one of the changes he made (separating execution of scriptSig and scriptPubKey-- take that discussion to another thread in Dev&Tech if you want to argue more about it, please).

I have added an edit to the bottom of my previous post... So the "this" referred to has been revised in part in effect...

-MarkM-

testing can reveal flaws in the protocol, not just the implementation

While practical testing is valuable, it should have no bearing on which BIP is accepted. These BIPs are protocol changes, and providing a stable implementation is the duty of the client, not the protocol. That being said, I'm confident that my bitcoind BIP 17 backports are more likely to hold up to testing, provided the signature check is sane (signing the relevant parts of the transaction), which would actually be a bug in the existing protocol if it weren't.

I'll see if makomk is up to this. His "coiledcoin" post implied he might be.

I'll have to remember this one for the next time I want to justify being an ass to someone I consider beneath me.


Back on topic...


I'm curious to know how thoroughly these proposals have been tested. That might go a long way toward swaying opinion. I would imagine having a public alt-coin for the sole purpose of implementing one proposal or the other and seeing how easy it is to break could be a great proving ground.

Fees are the incentive for running miners after the reward blocks diminish. Keeping the fees under control, while maintaining network security is the goal.

If you're as smart as you say you are, your thoughts, ideas, and logic should speak for itself. Your insults suggest you are either trying to cover up your own idiocy by loudly proclaiming eryone ELSE to be the idiot, or they make you seem like you are abusing the weaker guy who may simply not have as much education or experience as you yet. Either one only makes you sound like a loudmouthed douche who is to be ignored.

I am civil in conversation with men of quality. However, given the company one typically keeps in the forums, to not be nasty and abusive would reflect poorly on me.

Coming from cunicula... is this considered irony?

I think I might be with Luke on this insofar as BIP 16, but not sure yet about BIP 17.

I realise we are stuck with an already-existing blockchain.

But there seems to be a difference of opinion on whether in an ideal world an ideal blockchain would use scripts or simply an enumerated list of "special cases" aka "use cases".

I seem to recall Luke having implied somewhere that if we are going with a special case (which Gavin's approach seems to be), instead of with a generic scripting language (as Satoshi envisioned and implemented) we should do so for real, committing to moving to a future in which there will be no generic scripting, simply a list of special cases aka use cases. I seem to recall Luke also complaining that Gavin was refusing to make such a commitment, seeming to want to just hack a special case on top of the existing script language leaving us with a bastardised combination that is neither cleanly a scripting language nor cleanly an enumeration/list of special cases.

Evidently Satoshi was not scared that his scripting language would turn out to be full of ghastly exploits.

Was it?

Were the disabled scripting terms disabled due to actual exploits having been seen or simply because others were not as confident as Satoshi that the specific capabilities Satoshi intended were safe?

What does a general scripting language buy us, really? Flexibility, maybe? Couldn't simply adding yet another special case each time a use case is found that existing enumerated cases cannot handle equally well allow flexibility, while also providing assurance that only flexes shown to be safe can happen due to each case having to be explicitly included by the devs instead of brilliantly discovered as already possible by, potentially, an attacker?

Regardless of whether it is too late for bitcoin itself to make an informed and foresightful choice of using a scripting language versus using enumerated/special cases, I would like to know which would actually be better if only for cases such as "Yet Another AltCoin".

-MarkM-

EDIT: Apparently there *were* some ghastly exploits discovered in Satoshi's script language, so much so that he himself changed it to avoid them; furthermore apparently BIP 17 might actually be undoing one of those changes/fixes...

+1

There has to be some kind of compromise. As far as updating the system in the future, I am under the impression that BIP16 is more compatible with that. I don't remember which thread it was or who said it, but I remember something like that.

this is impossible for both proposed solutions.
dropping support for any of them in the future will make any transactions made in the past redeemable by others

Speaking as a poorly informed layman, it could be that the choice is not too important. In many cases, one expert will get become irate with another expert over a pretty trivial matter. Then the controversy will escalate, potentially developing into lifelong hatred. If the argument occurs within a team, the most important thing is preventing this kind of escalation.

One possible approach would be to admit that neither change is perfect, and to go with one of the two options as an explicitly temporary fix. In this case, the losing party would know that their views have been acknowledged, and that there is a plan to address their objections in a future revision.