Pages:
Author

Topic: Deadlines and moving forward (BIP 16/17 support) - page 3. (Read 8961 times)

hero member
Activity: 868
Merit: 1008
The Bitcoin system is _NOT_ up for a majority election. Not a majority of hashpower, not a majority of people, not a majority of money.

For example, What happens if a super-majority— even 100%— of the current miners decide that the subsidy should be 50 BTC forever?  NOTHING, miners who change that rule in their software simply stop existing from the perspective of the bitcoin network.  What happens if a super-majority— even 100%— of the current miners decide that they're going to mine a transaction that takes all of your Bitcoin and gives it to them?  NOTHING,  miners who violate the protocol rules stop existing from the perspective of the bitcoin network. What happens if a super-majority— even 100%— of the current miners decide that they're going to lie about the current time in order to mine 20 million BTC this year instead of over the next decades? NOTHING(* ignoring the timewarp bug),  miners who produce objectively incorrect blocks are ignored by the Bitcoin software run by everyone else.
Excellent point.  Much of the debate happening on the forums probably leaves a lot of people with the impression that a majority of miners could simply change the rules of bitcoin.  They could change the rules they enforce, but they would no longer be creating bitcoin blocks and their block rewards would no longer be usable anywhere that bitcoin is accepted.  It's important to remember that the proposed changes actually reduce the set of transactions that would be considered valid.
hero member
Activity: 755
Merit: 515
The next point which is irritating me is the false controversy being made here.  There is some minor disagreement, centered primarily from one person, over technical minutia which was small enough that Genjix didn't bother to explain and which is boring enough that you probably don't want to hear this again.
The reason OP_EVAL was withdrawn was much more minor technical minutia than the problems with BIP 16.
Let me take this opportunity to go ahead and point out that its pretty much Luke freaking out over technical minutia throwing fud everywhere without making any useful technical arguments holding this whole thing up.  Claiming that BIP 16 has more problems than OP_EVAL is so stupid its just ridiculous, please for the love of god, stop throwing fud everywhere, make technical arguments and try to convince people without turning this whole thing into a political fud-throwing competition where everyone loses.
hero member
Activity: 755
Merit: 515
Pool owners have the biggest incentives to keep the network running smoothly.
Thats so far from the truth its not even funny.  Even so, most of the largest poolops either say BIP 16 is their current leaning or they are just gonna wait until a consensus forms (slush already uses BIP 16, BTC-Guild is planning on adding it barring more controversy, and deepbit will add whatever gets a 50% majority in non-deepbit blocks).
legendary
Activity: 2576
Merit: 1186
In the case of P2SH, the development team could easily deploy this functionality against the will of the miners: They simply issue a new client that enforces the BIP16 rule and send an alert which would pop up a message for every bitcoin user telling them to update.  Miners that fail to update would eventually extend a chain containing a contradictory transaction and from that moment they would no longer be miners from the perspective of the majority of Bitcoin users,  no matter how many yottahashe/s they had.  Done.
And miners can simply refuse to mine P2SH transactions (like most of them do right now) to be immune to the (subset) "development team"'s changes. And if the "developers" lock out all the miners, guess what happens? Easy 50% attacks, the network is left unsecured!

Also, the ability for Gavin + tcatm (who controls bitcoin.org more or less) to effectively trick 90% of the users into switching to a new network is a flaw we should be trying to overcome, not a weapon to be wielded against objections. I'm pretty sure both Gavin and tcatm will agree with this, so please don't misinterpret it as an accusation that they would abuse this power.

The next point which is irritating me is the false controversy being made here.  There is some minor disagreement, centered primarily from one person, over technical minutia which was small enough that Genjix didn't bother to explain and which is boring enough that you probably don't want to hear this again.
The reason OP_EVAL was withdrawn was much more minor technical minutia than the problems with BIP 16.

Please don't leave out that BIP 17 has also had the same testing.
legendary
Activity: 1834
Merit: 1020
So, what happens if the developers make up their minds and choose one option over the other and 500,000 Bitcoin users who aren't even aware of the change fail to upgrade their clients?

That could only be a problem in the event that <50% of the mining power upgrades. This is nearly impossible because miners know that they will eventually lose when fighting against the development group. The percentage of clients ignoring the disagreeing miners' blocks will grow forever because everyone downloads the client from bitcoin.org. The development group could also send out alerts and get like 95% of users to upgrade in days, though this will probably not be necessary.

I can only see "turbulence" happening if the largest pool ops totally disregard their profitability in order to fight against the new rules. Hopefully no proposal bad enough to elicit this response would make it through the process.

I had no idea about the alert system.  Thanks!
hero member
Activity: 755
Merit: 515
The next point which is irritating me is the false controversy being made here.  There is some minor disagreement, centered primarily from one person, over technical minutia which was small enough that Genjix didn't bother to explain and which is boring enough that you probably don't want to hear this again.

Among competent and involved parties there is pretty much consensus over the direction, a little less about the timing.
So true, this is being blown out of proportion entirely because some parties insist on blowing it out of proportion for various reasons.  
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
This is clearly getting out hand. Bureaucracy is not the solution and i think more agree on this. The thing is we will not get anything better than what we already have regarding the "voting" system. The present one is quite perfect and natural so please take a little of your precious time and think before saying or doing things just to leave a mark of your passing through the community.

Pool owners have the biggest incentives to keep the network running smoothly. Why every one of them got to represent a bunch of miners ? Because we need to adapt slowly from centralized to de-centralized so the people, by natural means, pooled their resources together with a constant coin revenue in mind. Pool owners have a great responsibility in the process and some of them really understood this, some of them didn't. So miners will try informing themselves and migrate to the pool that represent best their interests.

Before bashing pool owners or miners you should try putting yourself in their place, spending precious time, money and brain cells keeping the system in place. Try spending more time in the miner threads and less in the speculation ones. I'm happy with the system we have and how it protects itself naturally. This keeps us protected even from inside in case some respected community member loses contact with reality.

I really think we should move usability of the main client, implementing "bells and whistles", before securing the hell out of the protocol. If bitcoin protocol wasn't secure it wouldn't have resisted for more than 3 years. We could have implemented the multiple key transaction at the cryptography level, like some other have already stated, multiplying ECDSA keys.

Sorry for the rant ppl but when someone pushes big changes with only security in mind it raises all my alarms. The ones that handle bitcoins will get reeducated or not use them. Point. It's a powerful tool and i saw lots of bad things happen if you have stupid people handle them.
staff
Activity: 4284
Merit: 8808
Still, I think it's not a bad idea.  The miners could vote in proportion to their mining power to elect a committee to study and then make a recommendation.  The recommendation would also be made by a vote.

Grrrrr.  This is rubbish.  I'm quite irritated with Genjix promoting this horrible misunderstanding of the Bitcoin system as being based on some kind of majority election in his post by taking "one cpu, one vote" out of context and applying it to parts of the system where it does not apply.

(FWIW, I'm the anonymously quoted person in his latest essay.)

Please go (re-)read this post:  http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source

Quote
The root problem with conventional currency is all the trust that's required to make it work.
[...]
Before strong encryption, users had to rely on password protection to secure their files, placing trust in the system administrator to keep their information private. Privacy could always be overridden by the admin based on his judgment call weighing the principle of privacy against other concerns, or at the behest of his superiors. Then strong encryption became available to the masses, and trust was no longer required. Data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.

It's time we had the same thing for money.

The Bitcoin system is _NOT_ up for a majority election. Not a majority of hashpower, not a majority of people, not a majority of money.

For example, what happens if a super-majority—even 100%—of the current miners decide that the subsidy should be 50 BTC forever?  NOTHING. Miners who change that rule in their software simply stop existing from the perspective of the bitcoin network.  What happens if a super-majority—even 100%—of the current miners decide that they're going to mine a transaction that takes all of your Bitcoin and gives it to them?  NOTHING.  Miners who violate the protocol rules stop existing from the perspective of the bitcoin network. What happens if a super-majority—even 100%—of the current miners decide that they're going to lie about the current time in order to mine 20 million BTC this year instead of over the next decades? NOTHING(* ignoring the timewarp bug).  Miners who produce objectively incorrect blocks are ignored by the Bitcoin software run by everyone else.

Your bitcoin is secured in a way that is physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter a majority of miners, no matter what.

Now—it would have been Satoshi's dream to make the entire system work completely like this but sadly Einstein came along and screwed everything up: relativity says that the temporal ordering of events is different for every observer and depends on your mutual locations in spacetime.  A decentralized system does not exist in just one place and thus there can be no single constant decentralized view of the flow of time and ordering of events.

(Bitcoin needs to reach a consensus about order so that it can decide which of multiple attempts to spend the same coin is the single valid one, in the rare case that someone would attempt to fraudulently spend the same coin more than once)

To solve this, Satoshi introduced a very limited form of a specialized kind of voting: miners express their view of the ordering of events in a way which is fully decentralized, attack resistant, and inevitably convergent.  This voting is very limited—miners can decide the order of transactions (including orders which place transactions infinitely far in the future). But that is it. They do not get to do anything else. This is powerful, yes, but it's also still very limited. As absolutely limited as possible.

The vision of Bitcoin is not a vision of democracy, where the wolves can vote to have the sheep for supper, it's a vision of independence and autonomy.  We use a "vote" where we have no choice, but the Bitcoin system itself is a consensus of deterministic rules.

P2SH is only possible because it takes things that were previously permitted and makes them not permitted—to old clients P2SH transactions look like "anyone who knows this hash puzzle can spend this coin" (BIP16/BIP12) or "anyone at all can spend this coin" (BIP17). Going the other way—from forbidden to permitted—would be akin to boiling the oceans.  We are very fortunate that Satoshi had the foresight to add many No-op instructions to the script in order to make additions like this possible.

In the case of P2SH, the development team could easily deploy this functionality against the will of the miners: they'd simply issue a new client that enforces the BIP16 rule and send an alert which would pop up a message for every bitcoin user telling them to update.  Miners that failed to update would eventually extend a chain containing a contradictory transaction and from that moment they would no longer be miners from the perspective of the majority of Bitcoin users,  no matter how many yottahashes they had.  Done.

(If users reject the change too—well, they can get themselves some new developers, but the miners never come into that picture except as users)

There are some reasons that this wouldn't be quite so simple. First—miners are Bitcoin users too, they are probably more technical than average, and change to Bitcoin needs to be adopted by the users by general consensus. Having their support is good and prudent. Secondly—P2SH is secure only if either >>50% of the miners have it or the vast majority of the clients do (thus making the miners who don't have it irrelevant). The former is easier to get (and easy to objectively measure, so long as people don't misrepresent the purpose of the coinbase tags), so it's a prudent path for making P2SH secure as fast as possible.

None of this translates into Bitcoin protocol being driven by a majority vote, and certainly not a majority vote of miners (who may or may not be well-aligned with the majority of the users).  

The next point which is irritating me is the false controversy being made here.  There is some minor disagreement, centered primarily on one person, over some technical minutia which was small enough that Genjix didn't bother to explain it and which is boring enough that you probably don't want to hear it from me an Nth time.

Among competent and involved parties there is pretty much consensus over the direction, though a little less about the timing.  This is partially due to the core development team being too busy developing and testing (and shooting the shit on IRC Sad ) to communicate effectively to the broader community. Luke has been building a useful matrix of involved developers' views.  Gavin has started making some better public-facing documentation of the thoroughness of the work so far, and Luke has created a parallel page for BIP17. I hope these measures and more like them will fill up some of the communications vacuum which has recently created a niche for a few uninformed hysteria promoters.

Cheers,
administrator
Activity: 5222
Merit: 13032
So, what happens if the developers make up their minds and choose one option over the other and 500,000 Bitcoin users who aren't even aware of the change fail to upgrade their clients?

That could only be a problem in the event that <50% of the mining power upgrades. This is nearly impossible because miners know that they will eventually lose when fighting against the development group. The percentage of clients ignoring the disagreeing miners' blocks will grow forever because everyone downloads the client from bitcoin.org. The development group could also send out alerts and get like 95% of users to upgrade in days, though this will probably not be necessary.

I can only see "turbulence" happening if the largest pool ops totally disregard their profitability in order to fight against the new rules. Hopefully no proposal bad enough to elicit this response would make it through the process.
hero member
Activity: 868
Merit: 1008
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.

So, what happens if the developers make up their minds and choose one option over the other and 500,000 Bitcoin users who aren't even aware of the change fail to upgrade their clients?  Maybe I'm misunderstanding something, but it seems like the developers would be attempting to fork the chain but (possibly) without the hashing power to sustain the fork.

So, please tell me what I missed because this seems somewhat likely.
At best, the committee would just be making a recommendation…the miners don't actually have to follow the recommendation.  Still, I think it's not a bad idea.  The miners could vote in proportion to their mining power to elect a committee to study and then make a recommendation.  The recommendation would also be made by a vote.  I suggested using the Condorcet method in another thread.  It could be used for both the election of the committee and the vote on the recommendation.  In another open source project I've participated in, we used it to elect an oversight board.  We used this tool for the administration of the vote: http://www.cs.cornell.edu/andru/civs.html   …it might be overkill for this issue, but something to keep in mind.
legendary
Activity: 1834
Merit: 1020
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.

So, what happens if the developers make up their minds and choose one option over the other and 500,000 Bitcoin users who aren't even aware of the change fail to upgrade their clients?  Maybe I'm misunderstanding something, but it seems like the developers would be attempting to fork the chain but (possibly) without the hashing power to sustain the fork.

So, please tell me what I missed because this seems somewhat likely.
legendary
Activity: 2184
Merit: 1056
Affordable Physical Bitcoins - Denarium.com
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.
legendary
Activity: 2184
Merit: 1056
Affordable Physical Bitcoins - Denarium.com
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.
legendary
Activity: 1232
Merit: 1076
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.
full member
Activity: 132
Merit: 100
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.
legendary
Activity: 1246
Merit: 1016
Strength in numbers
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.
legendary
Activity: 2576
Merit: 1186
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.
full member
Activity: 203
Merit: 100
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.
legendary
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
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.
hero member
Activity: 868
Merit: 1008
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.
Pages:
Jump to: