Deadlines and moving forward (BIP 16/17 support)

[Gavin Andresen]

BIP 16 (or 17) will not meet their initial "go/no-go" deadlines.  You can see the state of support here: http://blockchain.info/P2SH

That's OK, that's why the deadlines were structured the way they are; in the past, Satoshi made changes like this by simply changing the code and then expecting everybody to upgrade. This is the first time we've used a more open, community-driven process.

So, since we'll miss the deadline, the question is:  what next?  To focus discussion, here are two straw-man proposals that y'all can agree or disagree with; I'll go along with whatever consensus arises over the next couple of days:

Support for BIP 16/17 will be evaluated weekly, beginning on February 1 (support measured as described in the BIP). Results shall be announced here in this thread, and when support exceeds 55% the switchover date shall be set two weeks from then (with announcements made here, to the bitcoin-development mailing list, and to the Mining and Mining Pool forums).  If support drops to less than 20%, then the proposal shall be withdrawn.

To give more time for testing and deployment, there will be a new go/no-go deadline for evaluating BIP 16/17 support. The new deadline for BIP 16 shall be March 1, 2012. If 55+% support the new feature (as described in the BIP), then March 15 shall be the switchover date.

On the subject of testing... I've created a wiki page to record QA (quality assurance) testing that has been done on BIP 16.  If you can help test, or have been testing/deploying, then please add to this page:  https://en.bitcoin.it/wiki/BIP_0016_QA

As always, (on-topic) discussion, feedback, etc. is very welcome. If we can, I'd like to move past the "we dont' need to do ANYTHING" arguments, there is clearly rough consensus (with notable exceptions) that a short-bitcoin-address solution is needed.

[1713926517]

1713926517

[1713926517]

1713926517

[1713926517]

1713926517

[Explodicle]

I think the first suggested plan (weekly assessment of approval) is preferable. It sets a simple precedent for future upgrades, and IMHO approval voting works very well. It has a means of rejection, which the March 1st plan lacks. It also relieves the developers from having to balance urgency with testing time, by giving that job to the community instead.

Edit: the posts below highlight why a rejection criterion isn't needed. Worst case scenario, a BIP could be tabled indefinitely instead.

[Luke-Jr]

Note the first BIP 17 deployment/vote is scheduled for the week leading up to Feb 8th, so right after BIP 16 fails to meet its initial goal. I propose the two BIPs alternate weeks (at most often) so as to not unnecessarily conflict. If they have to overlap for some reason, I can prepare "both BIPs" patches to use temporarily...

For the first proposal, I disagree with the arbitrary 20% rule. It seems set so that BIP 16 never dies provided it has Slush's support. Is there any problem with just keeping both BIPs open until one is decided on?

BIP 0017 QA is currently a work-in-progress, but I hope to have more main-net testing completed soon.

[Rassah]

I think the first suggested plan (weekly assessment of approval) is preferable. It sets a simple precedent for future upgrades, and IMHO approval voting works very well. It has a means of rejection, which the March 1st plan lacks. It also relieves the developers from having to balance urgency with testing time, by giving that job to the community instead.

+1
Also agree with Luke on the 20% thing. I think that both BIPs should be open until either one is accepted, or something else comes along and beats them both. Keep plugging those bugs in the mean time

[RaggedMonk]

I think the first suggested plan (weekly assessment of approval) is preferable. It sets a simple precedent for future upgrades, and IMHO approval voting works very well. It has a means of rejection, which the March 1st plan lacks. It also relieves the developers from having to balance urgency with testing time, by giving that job to the community instead.

Sounds good to me.

For the first proposal, I disagree with the arbitrary 20% rule.

What is the 20% rule?

[jtimon]

I think that both BIPs should be open until either one is accepted, or something else comes along and beats them both.

+1

[paraipan]

I think that both BIPs should be open until either one is accepted, or something else comes along and beats them both.

+1

+1

[theymos]

Miners (as a group) should not be given any say over issues like this. They do not necessarily know what the best option is. The issue should be decided by people very familiar with the protocol and the proposals.

I suggest that we compile a list of everyone who knows a lot about the Bitcoin protocol, invite them to a two-week discussion via email, and have those who participate in the discussion vote on the issue at the end of the two weeks. If one proposal gets enough votes (two-thirds, say), then Bitcoin clients will be programmed to apply the new restrictions ~3 months in the future. Miners will have to upgrade by then or their blocks will not be recognized by most clients. If there aren't enough votes for any proposal to pass, the issue will be shelved for a while.

[elux]

Amended proposal:

Support for BIP 16/17 will be evaluated weekly, beginning on February 1 (support measured as described in the BIP). Results shall be announced here in this thread, and when support exceeds 55% the switchover date shall be set two weeks from then (with announcements made here, to the bitcoin-development mailing list, and to the Mining and Mining Pool forums).  If support drops to less than 20%, then the proposal shall be withdrawn.

[dooglus]

Miners (as a group) should not be given any say over issues like this.

Ultimately, miners are the ONLY people who have any say over issues like this.  They're the only one who decide which transactions get into blocks.

[theymos]

Ultimately, miners are the ONLY people who have any say over issues like this.  They're the only one who decide which transactions get into blocks.

Non-miners can reject blocks. If enough clients do this, the coins miners mine will become worthless.

[Steve]

Ultimately, miners are the ONLY people who have any say over issues like this.  They're the only one who decide which transactions get into blocks.

Non-miners can reject blocks. If enough clients do this, the coins miners mine will become worthless.

And clients might end up with worthless coins themselves in the process (not much good having a coin you can't transfer).

Anyway, this sounds like a fun road to travel down. Clients and miners fighting over the network rules. 

And that would lead to people checking with their favorite merchants and exchanges regarding whether they consider a given transaction valid.  If everyone did that, there would be no need for a block chain.  Everyone could just keep their own transaction histories and check with others to see if they think a transaction is valid.  But then you've created a situation where the power to determine what is considered a valid transaction consolidates around a handful of entities.

[ShadowOfHarbringer]

I suggest that we compile a list of everyone who knows a lot about the Bitcoin protocol, invite them to a two-week discussion via email

That is OK, as long as the discussion will be completely public. Openess is the fundament of any Open Source project.
Perhaps we should create a mainling list read-write for developers and read-only for all others  ?

Or it could be done on the forums, so it is even more public.

[Killdozer]

Outsourcing the vote solely to the miners seems especially questionable when the mining is so centralized.
In this particular issue there will not be any actual difference for the miners, not more so than the difference for all the users. So why give them more power than to the average user? Then again, even giving the decision to the general vote of the users seems vulnerable to the fact that most of them will not have enough knowledge to make a good decision.

Make the devs take the ultimate decision.
Keep the network voting online to monitor what the miners are saying, and take that into account when you are making the decision. Say, if 99percent of miners support one choice, it would be inappropriate of course to take another choise just because you are developers and you can.

[Luke-Jr]

Outsourcing the vote solely to the miners seems especially questionable when the mining is so centralized.

It's not outsourced. Miners by nature have to make this decision. Now if the miners agree to take the decision of a panel of developers or something, that would be outsourcing it (possibly in a good way).

Why this debate continues to go on, I'm not really sure. Gavin is worried about some potential for an already-existing-but-unknown bug being made mainstream by BIP 17, but by every tangible measure it's clearly the better solution now that the maybe-a-problem-in-the-far-future sigop-limit issue is resolved.

[FreeMoney]

Outsourcing the vote solely to the miners seems especially questionable when the mining is so centralized.

It's not outsourced. Miners by nature have to make this decision. Now if the miners agree to take the decision of a panel of developers or something, that would be outsourcing it (possibly in a good way).

Why this debate continues to go on, I'm not really sure. Gavin is worried about some potential for an already-existing-but-unknown bug being made mainstream by BIP 17, but by every tangible measure it's clearly the better solution now that the maybe-a-problem-in-the-far-future sigop-limit issue is resolved.

Yes, this vote isn't like political events where some people decide that if a person gets X people/delegates to say so then they are the president or some other title. This vote is for finding out what will happen, what the actual state of things is.

This is the real life it's not just fantasy.

[Jointops420]

As much as I would like a vote on things that would change bitcoin. I am not qualified in anyway to be sure I am voting for the best thing. I think this should be for those with a clearly demonstrated knowledge of the code to decide. Also how this has panned out so far is a good opportunity to put some form of protocol together so possible future changes can go through or not a bit smoother.
I appreciate all the work the developers have put into bitcoin.

[genjix]

Miners (as a group) should not be given any say over issues like this. They do not necessarily know what the best option is. The issue should be decided by people very familiar with the protocol and the proposals.

I suggest that we compile a list of everyone who knows a lot about the Bitcoin protocol, invite them to a two-week discussion via email, and have those who participate in the discussion vote on the issue at the end of the two weeks. If one proposal gets enough votes (two-thirds, say), then Bitcoin clients will be programmed to apply the new restrictions ~3 months in the future. Miners will have to upgrade by then or their blocks will not be recognized by most clients. If there aren't enough votes for any proposal to pass, the issue will be shelved for a while.

I strongly agree and support theymos' proposal:

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

I propose theymos as the organiser. The organiser will be entrusted with running the system to take the votes. They will organise the platforms and structure the discussions to promote neutrality.

theymos is a trusted long-term member of the community. His running of blockexplorer qualifies him technically; he is intimate with the code and issues. He has demonstrated a neutral objective character as the moderator of the bitcointalk forums. I think he's a good choice here.

[Technomage]

I think the situation is still very confusing. Gavin is talking about BIP16/17 with clear intent to attempt BIP16 approval, Luke is talking about BIP17 "clearly being the best solution". Are there any other developers or are they just mute? This issue was never supposed to be a community driven decision. It is and it will always be a developer driven decision. Almost everyone agree that P2SH should be implemented, with some exceptions, but there is still very clear confusion on which implementation to enable.

My solution to this is a vote between all core developers after which there is an intense testing period focused only on the BIP that got the majority vote. The losing BIP needs to be thrown to the trash bin and only taken out if the winning BIP shows serious bugs in testing. Mining pools will support it after this decision is reached. It's ridiculous that mining pools owners and more accurately, miners, need to be asked opinions on matters that they do not have an educated opinion on. At least most don't.

The situation would be different if it was just a question of whether to enable P2SH or not, that is not purely a technical issue. But the implementation is a purely technical issue and should be handled solely by technical people. This whole issue proves that the developer team and more specifically their decision making process needs a major overhaul or we will continue to have serious issues.

[Technomage]

Miners (as a group) should not be given any say over issues like this. They do not necessarily know what the best option is. The issue should be decided by people very familiar with the protocol and the proposals.

I suggest that we compile a list of everyone who knows a lot about the Bitcoin protocol, invite them to a two-week discussion via email, and have those who participate in the discussion vote on the issue at the end of the two weeks. If one proposal gets enough votes (two-thirds, say), then Bitcoin clients will be programmed to apply the new restrictions ~3 months in the future. Miners will have to upgrade by then or their blocks will not be recognized by most clients. If there aren't enough votes for any proposal to pass, the issue will be shelved for a while.

I strongly agree and support theymos' proposal:

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

I propose theymos as the organiser. The organiser will be entrusted with running the system to take the votes. They will organise the platforms and structure the discussions to promote neutrality.

theymos is a trusted long-term member of the community. Michael’s running of blockexplorer qualifies him technically; he is intimate with the code and issues. He has demonstrated a neutral objective character as the moderator of the bitcointalk forums. I think he's a good choice here.

+1000

This is exactly how this issue should be handled. Without these kinds of procedures, many will lose faith in the whole development of Bitcoin.