Bitcoin Forum
November 09, 2024, 06:06:18 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2] 3 4 »  All
  Print  
Author Topic: Deadlines and moving forward (BIP 16/17 support)  (Read 8941 times)
the joint
Legendary
*
Offline Offline

Activity: 1834
Merit: 1020



View Profile
January 31, 2012, 02:19:20 AM
 #21

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.
Steve
Hero Member
*****
Offline Offline

Activity: 868
Merit: 1008



View Profile WWW
January 31, 2012, 02:32:32 AM
 #22

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.

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

Activity: 5376
Merit: 13407


View Profile
January 31, 2012, 03:31:54 AM
 #23

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
January 31, 2012, 03:34:40 AM
Last edit: January 31, 2012, 05:34:27 AM by gmaxwell
 #24

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,
paraipan
In memoriam
Legendary
*
Offline Offline

Activity: 924
Merit: 1004


Firstbits: 1pirata


View Profile WWW
January 31, 2012, 03:52:03 AM
Last edit: January 31, 2012, 04:09:48 AM by paraipan
 #25

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.

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 755
Merit: 515


View Profile
January 31, 2012, 03:52:09 AM
 #26

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.  

Bitcoin Core, rust-lightning, http://bitcoinfibre.org etc.
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
the joint
Legendary
*
Offline Offline

Activity: 1834
Merit: 1020



View Profile
January 31, 2012, 03:56:25 AM
 #27

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

Activity: 2576
Merit: 1186



View Profile
January 31, 2012, 04:02:47 AM
 #28

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.

Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 755
Merit: 515


View Profile
January 31, 2012, 04:03:00 AM
Last edit: January 31, 2012, 04:16:13 AM by Matt Corallo
 #29

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

Bitcoin Core, rust-lightning, http://bitcoinfibre.org etc.
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 755
Merit: 515


View Profile
January 31, 2012, 04:06:17 AM
 #30

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.

Bitcoin Core, rust-lightning, http://bitcoinfibre.org etc.
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
Steve
Hero Member
*****
Offline Offline

Activity: 868
Merit: 1008



View Profile WWW
January 31, 2012, 04:17:21 AM
 #31

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.

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

Activity: 4270
Merit: 8805



View Profile WWW
January 31, 2012, 04:25:24 AM
Last edit: January 31, 2012, 04:36:11 AM by gmaxwell
 #32

We could have implemented the multiple key transaction at the cryptography level, like some other have already stated, multiplying ECDSA keys.

Man, I wish this were true, but it's not. (and I'm basically informed about EC math Smiley )

The problem we need to address with wallet security is this:  We can't trust a service provider to have control over our private keys (see mybitcoin) and (many users) can't really trust their own computers because of viruses and trojans (which even superhuman effort don't completely prevent unless you go the offline dedicated hardware route, with poor usability). These are also problems for traditional banking, but in traditional banking transactions are reversible— which stinks but hides a lot of security sins by user and the banking infrastructure.

You absolutely can have two people create a key in two parts which must be combined to sign via multiplication of the public/private parts (I use that property in the type-2 deterministic wallets I describe in the link above).  The problem is that they must actually be combined to use them, meaning that somewhere there must exist a single computer with the final private key in memory. ... but in our threat model above no such ultimately trustworthy computer exists.  People also have good reasons for needing things like "Two of {A,B,C}, or D" which doesn't fit into a simple combined key/threshold model. So we must use multisignature transactions for this purpose.

There do exist threshold signature schemes which allow for independent processing, but the ones I'm aware of have other compromises (like being large) and, more critically, aren't compatible with our ECDSA.   This is sad because as nice as multisig is, you couldn't do crazy things like have a transaction directly controlled by 50,001 out of 100,000 people with it (the spending transaction would be too big).

P2SH does nice things for other kinds of complicated transactions— not just multisignature. So even though multisignaure is the main end-user use for the here and now it's still a good direction independent of that.
Steve
Hero Member
*****
Offline Offline

Activity: 868
Merit: 1008



View Profile WWW
January 31, 2012, 04:31:25 AM
 #33

Pool owners have the biggest incentives to keep the network running smoothly.
Thats so far from the truth its not even funny.
Why?  A pool owner has everything to gain by preserving the value of bitcoin.  If the network isn't running smoothly the value of bitcoin drops and pool operators are out of business.  Also, if pool operators attempted a change that benefits them over everyone else (setting aside the practicality of actually doing such), you can be sure it would undermine the value of bitcoin.  Mind you, I'm not saying that it's not a good idea to disperse the hashing power that a pool controls…I would certainly like to see more control (especially over block creation) returned to the individual miners.

(gasteve on IRC) Does your website accept cash? https://bitpay.com
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 755
Merit: 515


View Profile
January 31, 2012, 05:28:41 AM
 #34

Pool owners have the biggest incentives to keep the network running smoothly.
Thats so far from the truth its not even funny.
Why?  A pool owner has everything to gain by preserving the value of bitcoin.  If the network isn't running smoothly the value of bitcoin drops and pool operators are out of business.  Also, if pool operators attempted a change that benefits them over everyone else (setting aside the practicality of actually doing such), you can be sure it would undermine the value of bitcoin.  Mind you, I'm not saying that it's not a good idea to disperse the hashing power that a pool controls…I would certainly like to see more control (especially over block creation) returned to the individual miners.
Sorry this is off topic (my fault).  Feel free to open up a new thread for discussion.

Bitcoin Core, rust-lightning, http://bitcoinfibre.org etc.
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
genjix
Legendary
*
expert
Offline Offline

Activity: 1232
Merit: 1076


View Profile
January 31, 2012, 05:34:27 AM
 #35

can we see theymos idea + non-backwards compatible new standard?

a blockchain fork will have to happen in the future.

see this as a good testbed, practice run or training level.

if we cannot get it right then bitcoin is doomed.
Andrew Vorobyov
Hero Member
*****
Offline Offline

Activity: 558
Merit: 500



View Profile
January 31, 2012, 08:41:14 AM
 #36

can we see theymos idea + non-backwards compatible new standard?

a blockchain fork will have to happen in the future.

see this as a good testbed, practice run or training level.

if we cannot get it right then bitcoin is doomed.

I can agree to this if there will be a mechanism to preserve "wealth" of current network and transfer it into the new one..

Really, can you, developers, come up with a script that does this? Like CTRL-C CTRL-V
gusti
Legendary
*
Offline Offline

Activity: 1099
Merit: 1000


View Profile
January 31, 2012, 09:51:39 AM
 #37

Though I'm far from understanding the technical details (I'm just a miner) I find this discussion fascinating, and the opportunity to setup a new decission making system for bitcoin, that will luckily attempt to enhance the corrupted "democratic" systems as we already know them.

I'm not intending to give an exact proposal of how this voting system would be, but only a few guidelines that will be enhanced by more intelligent people.

Decision makers should be :

- Satoshi (if he ever shows again)
- Developers
- Miners
- Pool owners
- Users

Keeping in mind that bitcoin WILL be attacked hard, assign a proper percentage to each of them, making it impossible for any individual or group of individuals to collude or being obliged to collude, to do any harm to bitcoin.

Changes on bitcoin fundamentals should not be easy, if not impossible. We need a stable, predictive and, why not, very conservative system, making it almost impossible for any individual or group of individuals to change bitcoin for their own benefit.


     

   

If you don't own the private keys, you don't own the coins.
makomk
Hero Member
*****
Offline Offline

Activity: 686
Merit: 564


View Profile
January 31, 2012, 10:50:56 AM
 #38

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.
This is only true so long as you assume that people would go on and continue to use a version of Bitcoin when they know that there's more than enough miners hostile to its existence that a small proportion of them could execute a 51% double-spend attack and that they have an incentive to do so. In fact, if 100% of current miners leave even a small proportion of them could just block all transactions from getting confirmed.

As you've pointed out elsewhere, in order for Bitcoin to work miners need an incentive to co-operate rather than defect. Once they've all announced they're planning to defect from the developer-approved version it's likely to get screwed badly.

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.
Of course, getting users to upgrade seems to be even harder than getting miners to upgrade, which is presumably why you're not doing it this way. Plus, the uncertainty as to which version to use would probably be hugely disruptive in itself - the only safe thing to do would be to just stop using Bitcoin until the dust settled and everyone had agreed on which side of the resulting fork to use, because if the miners are hostile and have a financial incentive to destroy the developer's side of the chain fork...

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
Technomage
Legendary
*
Offline Offline

Activity: 2184
Merit: 1056


Affordable Physical Bitcoins - Denarium.com


View Profile WWW
January 31, 2012, 11:23:29 AM
 #39

The bottom line is that non-technical people should have no say in an issue that is purely technical. This is technocratic democracy and it's simply the best way. All technical people should be invited to the discussion and then they can vote amongst themselves, simple as that. Then the results are made public and the miners will upgrade based on that, if the team decided to go forward with either BIP. There should of course be a vote for "neither".

If people are afraid that this technical team can misuse their power either now or in the future, it's important to remember that the miners have the ultimate decision in the end. In most cases they should support the decision that the devs made but if there is reason to believe that they are doing something very suspicious, they can always refuse to upgrade.

If this issue is handled in any other way, I will seriously lose confidence in Bitcoin. The public debates need to end, they are not helping to solve the issue, instead they are just adding doubt in people's minds.

Denarium closing sale discounts now up to 43%! Check out our products from here!
EhVedadoOAnonimato
Hero Member
*****
Offline Offline

Activity: 630
Merit: 500



View Profile
January 31, 2012, 12:38:20 PM
 #40

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.
This is only true so long as you assume that people would go on and continue to use a version of Bitcoin when they know that there's more than enough miners hostile to its existence that a small proportion of them could execute a 51% double-spend attack and that they have an incentive to do so. In fact, if 100% of current miners leave even a small proportion of them could just block all transactions from getting confirmed.

I was going to say the same thing. Those "NOTHING"s up there are too bold... the stronger miners could just attack the weaker network. We've seen Eligius being used to attack an alt chain, so these kind of violent behaviors should be expected.

But I agree with gmaxwell that this democracy analogy is perhaps not very adequate.
Pages: « 1 [2] 3 4 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!