The Truth behind BIP 16 and 17 (important read)

[genjix]

http://bitcoinmedia.com/the-truth-behind-bip-16-and-17/

Now I am not usually posting (spamming) Bitcoin Media stories on the forum, but I feel this is an important read. All the posts I've seen thus far are by partisan supporters of either scheme with no objectivity. They've also been highly technical in their language whereas here I've put mucho effort to make it readable and understandable for non-bitcoin developers.

Other developers disagree with giving this information away and feel like you as users should trust their judgement. I strongly disagree. I'd rather people have a say in such fundamental matters such as this, even if it makes the developer's lives harder because they have to explain their decisions thoroughly.

My worry is bitcoin someday becomes corrupted. Developers: see this extra scrutiny as an opportunity to build a culture of openness. It is not at all bad.

EDIT:

http://bitcoinmedia.com/cathartic-progress/

Michael Marquardt (theymos) suggests compiling a list of everyone intimate with the bitcoin protocol to invite to a two-week email discussion. After those two-weeks a vote is taken. It will be the job of the champions of each idea (BIP 16, BIP 17 and no change) to win over the committee into supporting them. If an idea has necessary support, bitcoin clients will be programmed to apply the new rules for 3 months in the future.

[Phinnaeus Gage]

http://bitcoinmedia.com/the-truth-behind-bip-16-and-17/

Now I am not usually posting (spamming) Bitcoin Media stories on the forum, but I feel this is an important read. All the posts I've seen thus far are by partisan supporters of either scheme with no objectivity. They've also been highly technical in their language whereas here I've put mucho effort to make it readable and understandable for non-bitcoin developers.

Other developers disagree with giving this information away and feel like you as users should trust their judgement. I strongly disagree. I'd rather people have a say in such fundamental matters such as this, even if it makes the developer's lives harder because they have to explain their decisions thoroughly.

My worry is bitcoin someday becomes corrupted. Developers: see this extra scrutiny as an opportunity to build a culture of openness. It is not at all bad.

WoW! Good read, genjix, albeit I didn't understand half of it. But that's not important. What's important is that you've taken the time to present this in a different light. One which may open eyes as to what's at stack. I wish I was able to supply input into this important issue, but I can't. Not because of any side I like better than another, but because of my ignorance on this topic. Again, thank you, genjix, for taking the incentive in re-presenting this.

~Bruno~

[stcupp]

+1

[JusticeForYou]

+1

[cbeast]

I propose a voluntary shutdown of exchanges during the implementation of such a major patch until stabiity is fully tested. A bank holiday, so to speak.

[Ranvier]

+1 @Phinnaeus

[Maged]

A minor issue is that old clients will not propagate CHV payments. The old clients will accept blocks with CHV payments, but they will not pass them onto other nodes in the network. This is not a problem as transaction propagation speed is usually far quicker than confirmation speed (especially with 6 confirms or more).

Huh? Because hash power percentage is significantly different from the percentage of Bitcoin network nodes, this is a huge point. Until the relay nodes upgrade, it can take a well-connected node up to 24 hours to get a transaction to a miner that would accept it. At this point, BIP 16 has a huge advantage: although it will take that long to get the transaction to a BIP 16-based address, once it's there, it can be spent just as quickly as a normal address-based transaction. BIP-17 transactions have to wait on both ends. Hope you aren't buying anything with Bit-Pay... (they only wait 15 minutes for the transaction)

[paraipan]

+1 thanks for explaining this dude, now i feel i can make a more educated voting 


My view:

                         BIP        | 16 | 17 |
20-byte short address        |  x  |  x |
unexpected behavior         |  x  |  -  |
harder to manage             |  x  |  -  |
max. number of SIGOPS    |  x  |  -  |
uses an existing operation  |  -  |  x  |
(to define a subscript)
uses a new operation        |  -  |  x  |
(script’s actions)
need more than 55% sup.  |  x  |  x  |
backward compatible        |  x  |  x  |

[chsados]

somebody needs to explain this like im 5....

do normal non miners make an difference?

[[Tycho]]

http://bitcoinmedia.com/the-truth-behind-bip-16-and-17/

"There are four functional fundamental implementations of the bitcoin protocol" - looks like you forgot about the Ufasoft client.

[[Tycho]]

I wonder why rush to deploy such extremally dangereous changes
without months of torturing testing on the testnet ??

I mean BOTH proposals (16 and 17).

Gavin created a bot that makes BIP17 testing impossible on the testnet.

[joulesbeef]

I'm concerned about lukejr continuing to work on bitcoin after he proved his is an untrustworthy individual. He abused the people using his pool. And they want to continue to let him change the bitcoin code? I tell you what as a business owner, I would say fuck that shit. ANd really I am going to make sure as many business owners as possible who are considering bitcoin know who helps program it. And let them decide with full information that they have to trust something produced by a person who proved that they could not be trusted.

[vuce]

I wonder why rush to deploy such extremally dangereous changes
without months of torturing testing on the testnet ??

I mean BOTH proposals (16 and 17).

Gavin created a bot that makes BIP17 testing impossible on the testnet.

Is this true?

[genjix]

I'm concerned about lukejr continuing to work on bitcoin after he proved his is an untrustworthy individual. He abused the people using his pool. And they want to continue to let him change the bitcoin code? I tell you what as a business owner, I would say fuck that shit. ANd really I am going to make sure as many business owners as possible who are considering bitcoin know who helps program it. And let them decide with full information that they have to trust something produced by a person who proved that they could not be trusted.

This is the wrong attitude that I am campaigning against. Ideas should be selected based on technical merit, not the people behind them. And Luke's idea is technically sound.

Bitcoin is not a business either, it is a system and a community. Having authorities start banning individuals is fascist.

[wachtwoord]

Thanks a lot for that post. I have a background in computer science (MSc title and work experience) and have had no time as of yet to form a good opinion. If the facts in that article are correct I am in favor of NEITHER.

Both (especially BIP16, sorry Gavin) sound like complete hacks. Furthermore I don't see a lot of value in the advantage of this, reducing the address lengths of complex operations. I suggest we wait until the 20k limit becomes an issue and solve it by forking the block chain.

This was a fairly high level article though and a lot of people have much more in depth knowledge of the system and the benefits so I could very well be wrong here. Either way I thought I'd voice my opinion (and mention on what information it is based).

[Steve]

Both (especially BIP16, sorry Gavin) sound like complete hacks.

They are both hacks to a degree, everyone knows that (there are many other warts in the scripting system too btw).  The questions/concerns are of a more pedestrian nature.  How to make the transition with the least amount of disruption.

I've come to the conclusion that there's very little risk in the transactions themselves.  The risk is just about bugs that might be introduced as a result of the code changes being made in the scripting system.  

A different way to arrive at a consensus is for Gavin and Luke-Jr to put their forks of the bitcoin script engine out there and start lobbying for miner support now (assuming they've already done a prudent amount of testing with tesnet).  For miners, there's little risk in validating these new style transactions if they do it right.  They won't be creating a fork if they have these new transactions in their blocks.  All they're basically doing it some additional validation that might reject some transactions that other miners would include.  If they validate BIP16/17 without rejecting blocks that others mine that don't satisfy the full validation of BIP16/17, then they won't go off on their own fork.  You simply need to caution people against actually creating these new transactions until the majority of the network is fully validating them (i.e. don't provide any UI that uses them until some time after a super majority of miners are validating them).

The first BIP to achieve a majority of support will then quickly achieve super majority support and that BIP can be declared the winner.  After that point, miners can simply never include transactions of the other kind in their blocks (so they don't need to carry forward the validation code of the losing BIP).

[[Tycho]]

I wonder why rush to deploy such extremally dangereous changes
without months of torturing testing on the testnet ??

I mean BOTH proposals (16 and 17).

Gavin created a bot that makes BIP17 testing impossible on the testnet.

You are kidding, right ?

No, I'm not:

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

* Disclaimer: I don't think that BIP17 is better than BIP16. Both are ugly hacks. I will support one only if most other miners will.

[hazek]

The risk is loosing the entire bitcoin market. The return is a better blockchain.

Just based on this I'll tell you right now, that if the bitcoin systems's integrity is compromised even for a second, I'm out and will never be back. It's whole value to me depends on it and I know I'm in the majority who think like this.

[wachtwoord]

 How to make the transition with the least amount of disruption.

Imo that would be doing neither.

[hazek]

 How to make the transition with the least amount of disruption.

Imo that would be doing neither.

Exactly. There's no urgency, so I really don't understand why the urgency to ram through a proposal with any risk attached with the excuse that nothing will get done otherwise? Gavin?