Pages:
Author

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

newbie
Activity: 24
Merit: 0
January 28, 2012, 03:28:54 PM
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).

legendary
Activity: 2576
Merit: 1186
January 28, 2012, 01:51:33 PM
hm i liked gavins approach of changing things very conservatively. that on the other hand doesnt sound so conservative  Undecided
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.
newbie
Activity: 28
Merit: 0
January 28, 2012, 01:41:17 PM
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 ? Smiley
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.
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 Smiley

hero member
Activity: 991
Merit: 1008
January 28, 2012, 01:27:15 PM
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  Undecided

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 ? Smiley
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.
hero member
Activity: 742
Merit: 500
January 28, 2012, 01:05:49 PM
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.

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.
newbie
Activity: 28
Merit: 0
January 28, 2012, 11:41:56 AM
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

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.
bip16 will require more effort. but not too much.
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.
hero member
Activity: 496
Merit: 500
January 28, 2012, 11:32:32 AM
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

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.
newbie
Activity: 28
Merit: 0
January 27, 2012, 06:26:41 PM
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
hero member
Activity: 868
Merit: 1007
January 27, 2012, 05:33:19 PM
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
And, at the same time, there's nothing stopping anyone from implementing both.  It's conceivable someone could create a client that did the validation for both BIP-16 and BIP-17.  Miners could also validate both style transactions.  Since they are both designed to be backward compatible, they will all be recognized as legitimate transactions by the whole network if they get into a block (even if not all clients relay them).  The downside of course is that if you create either a BIP-16 or BIP-17 style transaction and the majority of mining power isn't doing the full validation, you run the risk of losing your coins to theft.
newbie
Activity: 28
Merit: 0
January 27, 2012, 05:17:42 PM
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
legendary
Activity: 2576
Merit: 1186
January 27, 2012, 05:15:14 PM
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.
Sounds like a personal problem.
rjk
sr. member
Activity: 448
Merit: 250
1ngldh
January 27, 2012, 05:01:07 PM
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.
legendary
Activity: 2576
Merit: 1186
January 27, 2012, 04:50:45 PM
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.
What problems?
Being entirely inconsistent with the Bitcoin design, and breaking it with magical special cases.

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.
hero member
Activity: 763
Merit: 500
January 27, 2012, 04:32:57 PM
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.
rjk
sr. member
Activity: 448
Merit: 250
1ngldh
January 27, 2012, 04:28:00 PM
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.
What 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. Which government or large banking institution do you work for?
both BIPS are about as secure as a paper safe if not supported properly by the miners
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.
newbie
Activity: 28
Merit: 0
January 27, 2012, 04:21:01 PM
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.
What 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. Which government or large banking institution do you work for?
both BIPS are about as secure as a paper safe if not supported properly by the miners
rjk
sr. member
Activity: 448
Merit: 250
1ngldh
January 27, 2012, 04:17:08 PM
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.
What 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. Which government or large banking institution do you work for?
vip
Activity: 490
Merit: 271
January 27, 2012, 04:16:26 PM
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.
legendary
Activity: 2576
Merit: 1186
January 27, 2012, 04:11:48 PM
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.
vip
Activity: 490
Merit: 271
January 27, 2012, 03:53:02 PM
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.
Pages:
Jump to: