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.
Topic: Deadlines and moving forward (BIP 16/17 support) - page 4. (Read 8870 times)
Non-miners can reject blocks. If enough clients do this, the coins miners mine will become worthless.
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.
Amended proposal:
Quote
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.
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 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 think that both BIPs should be open until either one is accepted, or something else comes along and beats them both.
+1+1
I think that both BIPs should be open until either one is accepted, or something else comes along and beats them both.
+1 
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?
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
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.
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.
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.
Edit: the posts below highlight why a rejection criterion isn't needed. Worst case scenario, a BIP could be tabled indefinitely instead.
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:
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.
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:
Quote
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.
Quote
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.
Jump to: