Here's what I've gathered from this thread:
Tycho/Deepbit - concerned about rushing such a big change, concerned about wielding decision power over such a big change
Gavin - concerned about wallet security and allowing bitcoin to move to the next level
Luke - concerned about wallet security and allowing bitcoin to move to the next level
All parties care about having a stable and successful future for bitcoin, and we should not forget that. I think Tycho/Deepbit's refusal to get behind one of these proposals is quite possibly the wisest move in this whole ordeal and is under appreciated. What it does is put this incredibly hot bitcoin drama on ice and buys more time for the engineers to debate and the community to form some sort of consensus, which is crucial for something this big.
Slow and steady wins the race (and usually results in it being done right the first time).
Topic: BIP 16 / 17 in layman's terms - page 7. (Read 38982 times)
hm i liked gavins approach of changing things very conservatively. that on the other hand doesnt sound so conservative 
BIP 16 is not at all conservative. BIP 17, on the other hand, is.Let's do a brief comparison to disspell any FUD on the matter of even implementation simplicity (protocol simplicity should be obvious from reading the BIPs):
Code:
*** bitcoind v0.3.19 and v0.3.20
BIP 16: 5 files changed, 946 insertions(+), 435 deletions(-)
BIP 17: 5 files changed, 133 insertions(+), 14 deletions(-)
*** bitcoind v0.3.21
BIP 16: 5 files changed, 919 insertions(+), 429 deletions(-)
BIP 17: 5 files changed, 133 insertions(+), 14 deletions(-)
*** bitcoind v0.3.22 and v0.3.23
BIP 16: 5 files changed, 886 insertions(+), 409 deletions(-)
BIP 17: 5 files changed, 133 insertions(+), 14 deletions(-)
*** bitcoind v0.3.24
BIP 16: 5 files changed, 888 insertions(+), 398 deletions(-)
BIP 17: 5 files changed, 133 insertions(+), 14 deletions(-)
*** bitcoind v0.4
BIP 16: 5 files changed, 840 insertions(+), 386 deletions(-)
BIP 17: 4 files changed, 118 insertions(+), 15 deletions(-)
*** bitcoind v0.5
BIP 16: 5 files changed, 836 insertions(+), 388 deletions(-)
BIP 17: 5 files changed, 139 insertions(+), 34 deletions(-)
*** git master (this one including wallet integration, not just protocol changes)
Remove* BIP 16: 9 files changed, 48 insertions(+), 509 deletions(-)
... then add BIP 17: 8 files changed, 446 insertions(+), 49 deletions(-)
Overall replacement: 7 files changed, 126 insertions(+), 190 deletions(-)
As to the recent major bug in the BIP 16 implementation, it destroys any transaction fees in mined blocks. This is entirely unrelated to BIP 16, but affected because BIP 16 requires a major refactoring of the code. Because BIP 16 requires this refactor to implement in bitcoind, this bug affected all the backports too.
Quote
Also, some people are pointing that one/three pool operators can make important decisions/place a veto and this is very bad. But why no one thinks the same about the devs ? There aren't THAT many developers and Gavin can force almost any change he wants by applying some pressure on pool ops. Of course I'm not saying that he wants to destroy Bitcoin, but what if his PC/account/hostages are taken and someone is using his name to push changes ? 
Not this time, possibly, but that's just an answer to to such accusations.
I wouldnt worry about that, not many people update hourly from git source. He will be able to warn the mod's by then that it was hacked.Not this time, possibly, but that's just an answer to to such accusations.
But it still looks to me that there aren't enough active devs for a project of this scale...
Nobody wants to work for free
In last 2 days I already got 3 messages from Gavin about new bugs found in his implementation: one "minor bug" and one "major bug" ("one critical line was dropped in a merge and missed in my testing"). Also some coins were possibly destroyed in the process because a bug caused block fees to be lost.
hm i liked gavins approach of changing things very conservatively. that on the other hand doesnt sound so conservative
Also, some people are pointing that one/three pool operators can make important decisions/place a veto and this is very bad. But why no one thinks the same about the devs ? There aren't THAT many developers and Gavin can force almost any change he wants by applying some pressure on pool ops. Of course I'm not saying that he wants to destroy Bitcoin, but what if his PC/account/hostages are taken and someone is using his name to push changes ?
Not this time, possibly, but that's just an answer to to such accusations.
Not this time, possibly, but that's just an answer to to such accusations.
the devs mostly have power since they have much more knowledge about the proposals and the existing code. its hard to do anything about that without many people each spending a big amount of time aquiring that knowledge. the power of the big pools on the other hand is diminished with a few clicks from everybody.
I would like to add something about one of the reasons why I don't want to be the FIRST to adopt P2SH: I don't like doing beta tests in a production environment.
In last 2 days I already got 3 messages from Gavin about new bugs found in his implementation: one "minor bug" and one "major bug" ("one critical line was dropped in a merge and missed in my testing"). Also some coins were possibly destroyed in the process because a bug caused block fees to be lost.
Of course I understand that some bugs are always expected in big projects and Gavin isn't worse at programming than other developers, but that's what happens when such an important change is rushed into production.
Also, some people are pointing that one/three pool operators can make important decisions/place a veto and this is very bad. But why no one thinks the same about the devs ? There aren't THAT many developers and Gavin can force almost any change he wants by applying some pressure on pool ops. Of course I'm not saying that he wants to destroy Bitcoin, but what if his PC/account/hostages are taken and someone is using his name to push changes ? :)
Not this time, possibly, but that's just an answer to to such accusations.
In last 2 days I already got 3 messages from Gavin about new bugs found in his implementation: one "minor bug" and one "major bug" ("one critical line was dropped in a merge and missed in my testing"). Also some coins were possibly destroyed in the process because a bug caused block fees to be lost.
Of course I understand that some bugs are always expected in big projects and Gavin isn't worse at programming than other developers, but that's what happens when such an important change is rushed into production.
But I've said it before and I'll say it again: don't trust me. I make mistakes.
Doing exactly as he says.Also, some people are pointing that one/three pool operators can make important decisions/place a veto and this is very bad. But why no one thinks the same about the devs ? There aren't THAT many developers and Gavin can force almost any change he wants by applying some pressure on pool ops. Of course I'm not saying that he wants to destroy Bitcoin, but what if his PC/account/hostages are taken and someone is using his name to push changes ? :)
Not this time, possibly, but that's just an answer to to such accusations.
if you implement both - both will have to be supported forever. you wont be able to choose a "winner" in a later stage
implementing both just adds more security risks without any benefits
you would be better off flipping a coin to decide which to use than implementing both
implementing both just adds more security risks without any benefits
you would be better off flipping a coin to decide which to use than implementing both
Well if support for one BIP goes down below 50% those coins will become available to redeem for everyone,
at some point all of them will be redeemed rendering a particular BIP obsolete.
Of course the bad thing is that some of those coins will be redeemed by hackers and not by the owners,
but it might happen anyway only if just a single BIP is deployed and support for it goes away.
As I understood BIP16 is currently stronger protected for this kind of situation.
which doesn't really matters - if either of the BIPs go below 50% support the chainblock is basically doomed.
Also, replace "some" with "most" or "all".
Its a good thing i am not the one who needs to decide which BIP to use - too much responsibility if something goes wrong.
I have already suggested a fight to the death: gavin vs luke, to resolve the issue. There will be a lot of betting going on . good for the bitcoin economy.
and another thing: both BIP will be "invisible" to the user. As a user of bitcoin you wont be able to tell which BIP is used. They do the same thing.
if you implement both - both will have to be supported forever. you wont be able to choose a "winner" in a later stage
implementing both just adds more security risks without any benefits
you would be better off flipping a coin to decide which to use than implementing both
implementing both just adds more security risks without any benefits
you would be better off flipping a coin to decide which to use than implementing both
Well if support for one BIP goes down below 50% those coins will become available to redeem for everyone,
at some point all of them will be redeemed rendering a particular BIP obsolete.
Of course the bad thing is that some of those coins will be redeemed by hackers and not by the owners,
but it might happen anyway only if just a single BIP is deployed and support for it goes away.
As I understood BIP16 is currently stronger protected for this kind of situation.
if you implement both - both will have to be supported forever. you wont be able to choose a "winner" in a later stage
implementing both just adds more security risks without any benefits
you would be better off flipping a coin to decide which to use than implementing both
implementing both just adds more security risks without any benefits
you would be better off flipping a coin to decide which to use than implementing both
Quote
And that's the rub. I feel that his introduction of the additional BIP17 was intended solely to slow progress toward greater security. To what end, I don't know. But having more than one standard is guaranteed to cause a split among miners, which is the security problem you mentioned.
this wasn't my intention at all
BIP16 is just as bad as 17. (both suggestions have their strong and weak points. you will have to learn how the script works to understand)
nobody ever suggested implementing both. that would be beyond stupid
Quote
And that's the rub. I feel that his introduction of the additional BIP17 was intended solely to slow progress toward greater security. To what end, I don't know. But having more than one standard is guaranteed to cause a split among miners, which is the security problem you mentioned.
this wasn't my intention at all
BIP16 is just as bad as 17. (both suggestions have their strong and weak points. you will have to learn how the script works to understand)
nobody ever suggested implementing both. that would be beyond stupid
Where do you dig up this FUD?
It becomes inevitable wherever you are involved unfortunately. Your use of weasel words and language tricks give me cause for distrust.For example, if Gavin were to say (just as an example) "I have never DDoSed anyone in my life", I would take it at face value. However, if you say the same thing, I must spend time figuring out different meanings that the same phrase could have, because you likely mean "I personally have never DDoSed anyone in my life, but I have paid someone else to do it for me" instead.
Where do you dig up this FUD?
It becomes inevitable wherever you are involved unfortunately. Your use of weasel words and language tricks give me cause for distrust.For example, if Gavin were to say (just as an example) "I have never DDoSed anyone in my life", I would take it at face value. However, if you say the same thing, I must spend time figuring out different meanings that the same phrase could have, because you likely mean "I personally have never DDoSed anyone in my life, but I have paid someone else to do it for me" instead.
Why couldn't Gavin have just pushed the change through without making this hate topic, see if any of the mining pools rejected it?
He was trying to, but I brought it out to public light because of its problems.BIP17 is your attempt to push through code which has not been proven secure, presumably in order to compromise the integrity of the system.
Where do you dig up this FUD? BIP 17 is no less secure than BIP 16, and probably more secure in practice.I feel that his introduction of the additional BIP17 was intended solely to slow progress toward greater security. To what end, I don't know. But having more than one standard is guaranteed to cause a split among miners, which is the security problem you mentioned.
No, the slowdown you're thinking of is people continuing to push BIP16 even after a better replacement has been proposed. Testing is actually one of the reasons I don't like BIP 17; ....
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.
well, that only proves what i have written earlier. the actual implementation, testing and the number of devs who really have looked through the code is what actually counts. that's a prerequisite to being able to fix bugs and enhance it in the future. 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.
Why couldn't Gavin have just pushed the change through without making this hate topic, see if any of the mining pools rejected it?
He was trying to, but I brought it out to public light because of its problems.Why couldn't Gavin have just pushed the change through without making this hate topic, see if any of the mining pools rejected it?
He was trying to, but I brought it out to public light because of its problems.Why couldn't Gavin have just pushed the change through without making this hate topic, see if any of the mining pools rejected it?
He was trying to, but I brought it out to public light because of its problems.
Quote
I've actually studied incentives quite a bit but not from an economics standpoint. To read more on how incentives really work, based on real science, I can recommend this book
Technomage +1 I presume from Babylon 5
Without having read that book the approach seems logical. I have found 'incentives' are a factor of personality. There are 5 types of knowledge in the world. Individual Knowledge, Cultural Knowledge, Spiritual Knowledge, Philosophical Knowledge, and Scientific Knowledge.
Scientific knowledge doesn't/can't state any truism. It states observations from experiments (hopefully repeatable) that gets sent to others to apply Philosophical Knowledge.
But that not being the point, quantifying every individuals 'intentions' would need to asses every individual's application of those 5 types. And with that also being a dynamic not static application of those sets, one could only apply a probability of an individual's intentions.
In short, "Trying to predict human behavior"
I do not know what the intentions of operators are, I only know my own at this point in time. Others might be trying to change BitCoin solely based on Cultural needs, or (heaven forbid) on Spiritual needs.
I liked your response as it was rational and informative. Mine might not be.
Best Regards.
Why couldn't Gavin have just pushed the change through without making this hate topic, see if any of the mining pools rejected it?
He was trying to, but I brought it out to public light because of its problems. Quote
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
Satoshi?
Nothing against the first contributor(s), but it is your project now along with the other developers. Invoking a now 'mythical' persona, tends to cloud the issue. Understandable from a politicians point of view which I guess is a part time role you have been put in. This thread is, in my opinion, doing great good. You have stated your case and appealed to the voters which now include many rather than a few. But bringing up Satoshi's intent with him/them not being present is like bringing up George Washington's intent on how the country should be run.
I do not understand the full code, so I rely on your explanation and my interpretation of said explanation. BitCoin is a venture that I would like to succeed but not turn out to be just another fiat. My concerns were that power is being grouped into a relatively small group. This issue seems to have been a catalyst that brought it to the forefront.
With that being said, I think it is imperative that the proactive changes for future use of the client first runs through a filter of: "Does this increase or decrease decentralization?" Then run it through other filters as to the security, usefulness, etc...
In this case, there seems to be an impasse on the issue as on how good each protocol will be. I find analogies tend to express the idea of the problem better. Taking into consideration the code, developers, Pool Operators, etc... lets look at it like a Beta vs. VHS problem. Two ideas both valid but an impasse was reached on which one. Developers were held up, suppliers were held up, customers confused, etc... cause no one knew which one would win. It was solved by simple old competition. VHS won. (Shame cause I was for Beta).
Best Regards and good luck.
Jump to: