Bitcoin Forum
December 04, 2016, 06:15:14 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 4 »  All
  Print  
Author Topic: Deadlines and moving forward (BIP 16/17 support)  (Read 7209 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 30, 2012, 05:49:15 PM
 #1

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:

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.

How often do you get the chance to work on a potentially world-changing project?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480832114
Hero Member
*
Offline Offline

Posts: 1480832114

View Profile Personal Message (Offline)

Ignore
1480832114
Reply with quote  #2

1480832114
Report to moderator
1480832114
Hero Member
*
Offline Offline

Posts: 1480832114

View Profile Personal Message (Offline)

Ignore
1480832114
Reply with quote  #2

1480832114
Report to moderator
Explodicle
Hero Member
*****
Offline Offline

Activity: 947


View Profile
January 30, 2012, 06:21:19 PM
 #2

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
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 30, 2012, 06:41:23 PM
 #3

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
Legendary
*
Offline Offline

Activity: 1624


Director of Bitcoin100


View Profile
January 30, 2012, 06:52:14 PM
 #4

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 Cheesy

RaggedMonk
Sr. Member
****
Offline Offline

Activity: 308



View Profile
January 30, 2012, 07:44:19 PM
 #5

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
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
January 30, 2012, 08:07:16 PM
 #6

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

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
paraipan
Legendary
*
Offline Offline

Activity: 924


Firstbits: 1pirata


View Profile WWW
January 30, 2012, 08:37:55 PM
 #7

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

+1

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
January 30, 2012, 09:14:15 PM
 #8

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
elux
Legendary
*
Offline Offline

Activity: 1454



View Profile
January 30, 2012, 09:20:01 PM
 #9

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.

dooglus
Legendary
*
Offline Offline

Activity: 1988



View Profile
January 30, 2012, 09:29:20 PM
 #10

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
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
January 30, 2012, 09:36:16 PM
 #11

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
January 30, 2012, 10:02:30 PM
 #12

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

(gasteve on IRC) Does your website accept cash? https://bitpay.com
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
January 30, 2012, 10:20:32 PM
 #13

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
Full Member
***
Offline Offline

Activity: 204



View Profile
January 30, 2012, 10:22:43 PM
 #14

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
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 30, 2012, 10:29:13 PM
 #15

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
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
January 30, 2012, 11:33:54 PM
 #16

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.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
Jointops420
Full Member
***
Offline Offline

Activity: 132


View Profile
January 31, 2012, 12:06:48 AM
 #17

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
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
January 31, 2012, 12:54:51 AM
 #18

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
Legendary
*
Offline Offline

Activity: 1610


Affordable Physical Bitcoins - Denarium.com


View Profile WWW
January 31, 2012, 12:55:35 AM
 #19

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.

Denarium - Leading Physical Bitcoin Manufacturer - Special Xmas deals now live!
Technomage
Legendary
*
Offline Offline

Activity: 1610


Affordable Physical Bitcoins - Denarium.com


View Profile WWW
January 31, 2012, 12:58:45 AM
 #20

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.

Denarium - Leading Physical Bitcoin Manufacturer - Special Xmas deals now live!
Pages: [1] 2 3 4 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!