BIP 16 / 17 in layman's terms

[Costia]

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

[Luke-Jr]

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.

[MoreCowbell]

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

[Steve]

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.

All miners have a very strong incentive to do abide by the same rules that the majority abide by…otherwise, they risk their blocks being rejected and their coinbase coins invalid.  I think once it's clear the majority or super majority agree to enforce BIP16/17 transactions, there will be almost zero chance of falling back below 50% support (all miners will make sure they're fully validating p2sh transactions otherwise they could spend a lot of time mining a block that ends up rejected by the network).  

Also, you have to keep in mind that what these BIPs fundamentally do is restrict, not expand, the set of valid transactions.  Hence, even if neither Gavin and Luke-jr yield and they create their own separate forks of bitcoin, miners could simply chose to enforce both styles of P2SH transactions to be safe in knowing that whichever style becomes dominant that they'll never end up on a dead fork of the block chain.  I'm not advocating this mind you, I think it would be better to just pick one (and no matter which is chosen, make sure it's we'll tested before it's rolled out).  But, if it did happen, it wouldn't be the end of bitcoin.

[Costia]

in practice this would be hard if not impossible, the implementation of one bip might mess up something in the other. this will also make future development of bitcoin a lot more complicated
better none than both

[markm]

Bugs still showing up in BIP 16 sounds like the "deadline" was too rushed. Unless Luke's code is equally well tested and has not been turning out to be buggey we should probably push back the "deadline" to end of next month instead of end of this month?

-MarkM-

[Luke-Jr]

Bugs still showing up in BIP 16 sounds like the "deadline" was too rushed. Unless Luke's code is equally well tested and has not been turning out to be buggey we should probably push back the "deadline" to end of next month instead of end of this month?

BIP 17 doesn't change nearly as much as BIP 16, so it's much easier to audit and test.

[JusticeForYou]

Slow and steady wins the race (and usually results in it being done right the first time).

Normally, I would agree with this. However, BitCoin isn't dealing within a normal environment. If BTC takes hold, it will need to be as far along as possible because there will be great pressures brought to market. Major industries will either try to co-opt it or destroy it. If anyone has been on the receiving end of Multi-Billion dollar industries ire, they will understand 'all' that will be invoked.

Lets not forget, Gavin was already summoned to the CIA.

Transparency helps because of this.

Tycho, Gavin, Luke, etc... as developers are doing what they believe is correct for them, BitCoin, and possibly other reasons. This protocol change, while important, isn't the concern. The concern is the hold up in development. Since BitCoin is a beta and is already being relied on for Millions of dollars in transactions puts great pressure on correctness. It isn't the developers fault that the community put great faith in a beta, it is not their fault. It is ours for assuming it was a full version with all the bugs worked out.

We can't put the Milk back into the Glass. Development should be transparent and debated among the community. The reasons for this, I believe, are simple. Every major communication company has had to 'make deals' with Governments. AT&T, RIM, Google, etc... and this is just for communication. Now being that BitCoin can be used for 'Communication' and 'Money' transferring; I would not be so naive to believe the project wouldn't be put under great pressure, also.

As to stay on topic: BIP16/17, everyone put their heads together come up with all possible 'bad things' and 'good things', and apply Occam's Razor. And Then, PICK ONE.  Pick a weekend, get together, get drunk and happy(except Luke ), and pick one.

I'll shut up as to this matter as I believe my concerns have been conveyed.

Good Luck and Best Wishes.

[makomk]

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'm not really up to anything right now. Coiledcoin's dead (probably together with new altchains in general), and it's not really worth starting anything Bitcoin-based at this point in time.

[MoreCowbell]

Layman's question:

Will the proposed new long bitcoin addresses be mandated for everyone going forward, or will the long addresses only be used by people who chose multi-sig?  I definitely share the concern over difficulty in copy-paste, QR codes, eye-scanning etc. due to really long addresses.

What kind of address length are we looking at with each of the proposals?

[Costia]

https://en.bitcoin.it/wiki/BIP_0013 for both
 dont know what exactly the length is going to be

[Luke-Jr]

Will the proposed new long bitcoin addresses be mandated for everyone going forward, or will the long addresses only be used by people who chose multi-sig?  I definitely share the concern over difficulty in copy-paste, QR codes, eye-scanning etc. due to really long addresses.

What kind of address length are we looking at with each of the proposals?

BIP 13 (P2SH address format, used by all BIP 12, 16, and 17) addresses are (almost?) always 34 characters, similar to current addresses. The Address wiki page has been ahead of the game for a while now.

[interlagos]

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'm not really up to anything right now. Coiledcoin's dead (probably together with new altchains in general), and it's not really worth starting anything Bitcoin-based at this point in time.

I've suggested Coblee to consider BIP17 for Litecoin as an alternative to Bitcoin, let's see if we get anywhere with this.
He might need some help to port and maintain the changes though, if he decides to implement multisig at all.

[Andrew Vorobyov]

I thing the devs should take an opinion poll about changes, but ultimately they should set the deadline and have the final say. Anyone else can start their own fork and start their own volunteer network.

[Steve]

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'm not really up to anything right now. Coiledcoin's dead (probably together with new altchains in general), and it's not really worth starting anything Bitcoin-based at this point in time.

I've suggested Coblee to consider BIP17 for Litecoin as an alternative to Bitcoin, let's see if we get anywhere with this.
He might need some help to port and maintain the changes though, if he decides to implement multisig at all.

Why not go a step beyond and make a clean start for the script engine in litecoin?  Make all litecoin transactions be a p2sh style transaction.  And clean up the cruft in the bitcoin script engine.  Make it will tested, etc.

[interlagos]

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'm not really up to anything right now. Coiledcoin's dead (probably together with new altchains in general), and it's not really worth starting anything Bitcoin-based at this point in time.

I've suggested Coblee to consider BIP17 for Litecoin as an alternative to Bitcoin, let's see if we get anywhere with this.
He might need some help to port and maintain the changes though, if he decides to implement multisig at all.

Why not go a step beyond and make a clean start for the script engine in litecoin?  Make all litecoin transactions be a p2sh style transaction.  And clean up the cruft in the bitcoin script engine.  Make it will tested, etc.

Might be a good idea. I think you can talk to him about it. He said he would have more time soon to work on the client again.

[Andrew Vorobyov]

Developers must vote on this, not regular "miners" ( as long developers are trusted)...

I will split my bounty between all developers involved, does not matter of what BIP will be accepted.

[FreeMoney]

Developers must vote on this, not regular "miners" ( as long developers are trusted)...

I will split my bounty between all developers involved, does not matter of what BIP will be accepted.

If the miners refuse to switch it doesn't work. The devs can't force anything.

[Andrew Vorobyov]

If the miners refuse to switch it doesn't work. The devs can't force anything.

But this would pave light way to transition... If transition itself being questionable enough - miners can reject it... Only after this regular users will need to decide.


Small details what matters... People in order of importance

1st - developers
2nd - miners (poolops)
3rd - users

It will eliminate friction from the process...

[JusticeForYou]

Small details what matters... People in order of importance

1st - developers
2nd - miners (poolops)
3rd - users

Really?


Ok,

1st - Developers - lets say 10
2nd- miners - lets say 100
3rd- users - lets say 0


What was that order again?