BIP 16 / 17 in layman's terms

[Costia]

why are you concerned about giving a lot of power to pool managers but not about giving a lot of power to miners in general?
Isn't it the same thing on a different scale. Most Bitcoin users aren't miners ( same as most miners aren't pool managers), yet the miners can set the transaction prices to whatever they want, they can force a protocol change or shutdown the network altogether. they have the incentive to make the "right" decision, but so do the pool managers.

[cunicula]

In layman's terms:

They want to happily charge you more fees.

Nice. Thanks for bringing us back to the real world.

[markm]

Wow did that ever go off course, WTF was I going to respond to after all that?

Yes, blaming the children for what some priests sometimes for some time get away with is not quite right.

But does it mean the Pope is a pederast? I'm not sure that follows.

Lets go back to basics. Decentralisation. If I want to decentralise, should I listen to the chap who hangs out with the C.I.A. or the raving religious nutbar who actually and possibly unfortunately can be amazingly on point when its not a question of how many angels can dance on the head of a pin or some other theological debate?

I think maybe I need to hear/read again Luke's argument(s) against BIP16 as it seems to me that if Gavin's arguments against BIP 17 were as cogent as he seems to think, Luke would have recognised that fact by now. It is not, afterall, a religious matter. (Is it?)

Presumably Luke has heard all Gavin's arguments, yet they have not convinced him. That worries me, as I have not yet found Luke to be a nutbar in such fields and dismissing people's expert opinions on account of their extra-curricular nutbarism is not something we nutbars particularly approve of.

-MarkM-

[cunicula]

Wow did that ever go off course, WTF was I going to respond to after all that?

Yes, blaming the children for what some priests sometimes for some time get away with is not quite right.

But does it mean the Pope is a pederast? I'm not sure that follows.

Lets go back to basics. Decentralisation. If I want to decentralise, should I listen to the chap who hangs out with the C.I.A. or the raving religious nutbar who actually and possibly unfortunately can be amazingly on point when its not a question of how many angels can dance on the head of a pin or some other theological debate?

I think maybe I need to hear/read again Luke's argument(s) against BIP16 as it seems to me that if Gavin's arguments against BIP 17 were as cogent as he seems to think, Luke would have recognised that fact by now. It is not, afterall, a religious matter. (Is it?)

Presumably Luke has heard all Gavin's arguments, yet they have not convinced him. That worries me, as I have not yet found Luke to be a nutbar in such fields and dismissing people's expert opinions on account of their extra-curricular nutbarism is not something we nutbars particularly approve of.

-MarkM-

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.

 

[Costia]

go with one of the two options as an explicitly temporary fix

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

[Technomage]

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.

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

[markm]

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

[Rassah]

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.

Coming from cunicula... is this considered irony?

[cunicula]

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.

Coming from cunicula... is this considered irony?

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.

[Rassah]

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.

Coming from cunicula... is this considered irony?

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.

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.

[cbeast]

In layman's terms:

They want to happily charge you more fees.

Nice. Thanks for bringing us back to the real world.

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

[westkybitcoins]

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.

Coming from cunicula... is this considered irony?

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.

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.

[Luke-Jr]

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.

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.

[Costia]

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

[phelix]

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 moveing 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 committment, seeming to want to just hack a special case on top of the existing script language leavign 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 existign 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-

this

[markm]

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-

[Gavin Andresen]

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.

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

[Luke-Jr]

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

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

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

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.

[Costia]

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

[rjk]

why is satoshi treated like some supreme being?

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