Topic: The Truth behind BIP 16 and 17 (important read) - page 4. (Read 8549 times)

I think it's important.  An address doesn't have to be a hash of anything…an address could be the entire script that you want someone to send coins to.  However, that would be rather unwieldy and there has been considerable investment in the notion of a bitcoin address being a relatively short thing.  Both investment in terms of software and investment in terms of people learning and understanding bitcoin.  To start passed around very long addresses would be rather confusing I think.  It also has the drawback of revealing more about the destination script than is necessary.

P2SH is the way that bitcoin should have been designed from the beginning IMO.  Outputs of transactions (scriptPubKey) should have always been just a hash and the validation always been that a script hashes to that value and executes successfully.  Using long addresses would be moving in the wrong direction in my opinion.

It is completely artificial urgency, so a decision is reached and implemented in a reasonable amount of time.

When I set the deadline, I had no idea Luke would:
  a) Decide that a bugfix 0.5.2 release was a good idea. I thought the minor bugfixes weren't worth taking the time to make a release but arguing with Luke is like arguing with a brick wall, so I went "meh, whatever."
  b) Propose BIP 17 and go on a war against BIP 16.

Both of those distracted from implementation and testing of BIP 16.

But what's past is past, the question is what do do from here; I'm planning on starting that discussion in the Dev&Tech forum tomorrow.

PS: RE: risk:  the risks of either proposal to the overall health of the bitcoin network are small.

bip 17 sounds more elegant, straightforward and less complex. i think it deserves some time for proper testing.

that being said i am not sure if i can fully assess the downsides of implementing neither bip. longer addresses, bigger blockchain (is there an estimation how much bigger?). any security problems?

edit: btw: its stated as an advantage of bip 16 that you can put more multisig transactions in a block. doesnt that make miners favor multisig transactions? (higher fees and you can still include many in a block)
if so, wouldnt the fees of normal transactions converge to the fees of multisig transactions once the blocks get fuller and there is actual competetion about which transactions go into the first possible block?

What is the added value beyond shorter addresses for complex transactions? Because I don't see that as very important.

I think this is wrong.  There is urgency.  It's clear the p2sh makes for a better bitcoin in many respects.  If bitcoin cannot make the transition, then another coin most certainly will (maybe litecoin, or something else).  That coin will be superior to bitcoin and will start to attract investment.

Hmm, perhaps the best and right solution in this sad situation is
to invent some other method of construction of multysig transactions.
Not BIP 16/17.

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?

Imo that would be doing neither.

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.

No, I'm not:


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

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

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

You are kidding, right ?

Even if that's true , BIP16 can be tested till death.

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.

Is this true?

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.

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

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

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

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

do normal non miners make an difference?