Topic: In re Bitcoin Devs are idiots - page 5. (Read 25449 times)

You are intentionally ignoring the real consequence.  It isn't that users are "forced to upgrade".  Devs have recommended security upgrades in the past.   It is that users who didn't upgrade (possibly because they are unaware) would have been easily "robbed".  Downgrading v0.8 has no lasting security implications.  Allowing the network to remain forked presented a real threat to the security of user's transactions.  It would be asinine to chose anything over the security of the network.  The news of this fork has been relatively muted.  Can you imagine if the decision to force through v0.8 had been made and thousands of users were robbed for millions of dollars worth of Bitcoins in 51% attack, accepting bogus generated coins, and even trivial no-hash power double spends. 

Which presents a real THREAT to the trust in the network.   The need to upgrade or lack thereof is a strawman.   My guess is you will now make another strawman attack about needing to upgrade as you have done twice now.  Don't worry I won't see it so you an "winz the internets".

That depends on whether or not you actually  consider the local branch manager as a banker. He's just an errand boy for bankers. Even Jamie Dimon is just a glorified boy Friday for the those that actually control the issuing of currency and credit in the US.

I think the job meant was pool operator, not miner as in, often enough, a mere hasher who does not even see the blocks being hashed. Such "miners" are more like bank tellers or even just folks who host an ATM machine for profit than actual bankers.

-MarkM-

The first sentence is as realistic as anyone can become a banker! *LOL*

smtp

Anyone can be a miner. Rothschild and cohorts are born to their monopoly.

Sorry, I can't resist. Such a good pattern/model/submission:

Well, our current bitcoin-world has also their "bankers", but they are called "miners".  

Whether they manipulate governments and markets, spread disinformation through the media, ... I can't judge (and personally I don't believe it)., but surely they are experts at their basic job:
They can be specified/defined for validation of transcations and get paid for this -- exactly like real-world bankers -- and monopolize this work!

smtp

I read the logs. Better yet: I was present, observing on #bitcoin-dev from the start of the incident until about 2 am EDT this morning.


I agree. Perhaps "forced" had the wong connotation. It was obviously persuasion, not coercion. My point is merely that you and the other respected developers used your influence to persuade the 0.8 miners to abandon the 0.8 fork. I simply suggest that this consumed some of your store of influence for future emergencies.

Not calling this horrible outcome for 0.7 users a "crash" is semantics. Call it what you will. It would have forced 0.7 users to upgrade immediately.

Yes. I heard you make the same argument last night. The answer is not cut and dried. Should we "fuck" the users a little bit now (by making them upgrade immediately) or should we patch clean efficient code (0.8 ) to protect buggy slow code (0.7), thus risking a more serious "fucking" in the future?

Do not misunderstand. In the heat of the moment I might well have made the same decision as you. But decisions have consequences: (1) Bad code was protected and (2) influence born of community respect was spent. By being aware of those consequences, you might be better prepared to guard against their potential repercussions.

You keep saying you want to get rid of magic numbers, how would you limit the size of blocks? Or would you just have unlimited block sizes?

I've suggested this before but maybe it's worth mentioning again.

Split bitcoind and bitcoin-Qt into completely independent components. Bitcoind stores a local copy of the blockchain, connects to the p2p network, relays blocks and transactions, and serves blockchain information to clients only. Bitcoin-Qt is a client application only that connects to a trusted bitcoind node. The default installation would install them in a pair, with bitcoind running all the time as a unix daemon (Windows service) and Bitcoin-Qt started on demand. Only one instance of bitcoind is needed on a typical home LAN, all the clients can just connect to it.

Once this is done Bitcoin-Qt can just focus on being the best client it can be, while bitcoind can focus on the blockchain and p2p network. It should also be extended to serve MultiBit, Armory and Electrum. Once the reference implementation is fully refactored into a client/server application it should make any attempt to develop an alternate implementation easier.

I don't have enough programming skill to do this, but I'd donate to anyone who does.

The point: Someone's going to throw a fit until the perfect cryptocurrency is developed by someone else because Bitcoin sucks so much.

No, I think many can see the point of this thread.

No, this is not about it being "clean".  Obviously if you specify a protocol after it's gone into widespread use, you have to consider compatibility issues.  The specification can be as complex as it needs to be to accommodate the mess, of course.

A protocol can still evolve from unspecified to specified if it's not a clean slate.  Many have.  Most of the successful protocols in use on the Internet evolved through a design phase to semi widespread use, then were specified and really took off.  I don't know of any long term successful protocols that remained unspecified for long.  Maybe some of the Adobe proprietary crap, but I assume that will die off soon.  Please learn a lesson from the hundreds of successful protocols in use today.  You are not special.  Yes, I know.  No, you're not special.

Isn't there some website somewhere you should be fixing for 27 Bitcoins?


No, it is you that doesn't (really, really) get it. What you're displaying is precisely the sort of idiocy this thread was named for.

No matter how inconvenient it may be on the short term, for a plethora of reasons chief among which is the fact that some IDIOTS lose the jealously-preserved mystique of being "they who understand the nonsense they created for the purpose of having something only they can understand", specification HAS TO BE DONE.

Do you grasp this? Bitcoin will never exist as a toy for five idiots. You will never get to matter inasmuch as what you want to do is have this little black box the world reveres that only you are allowed to peer inside. This is not how the world works, currently (and past about 1800 or so). This is not how the world should work, either.

Specifying the code does not "result in fiascoes like this one". Your idiotic codebase results in in fiascoes like this one. Specification is the way out of it, and most importantly specification is the way out of having you idiots create fiascoes like this one randomly, one at a time, for the unforeseeable future.

Incredible how stupid self-centered people can be, seriously now.


Enough with the nonsense. You are missing the point by about a mile.


I do not really know what to make of your reply above. In any case, it'd seem consensus is emerging that indeed the devs are idiots (should you wish to more politely define that as "strategically myopic" or whatever other phrase). It'd seem the consensus also is emerging that indeed the way forward is,


As it happens, nobody asked them.

There are many examples of protocols which only became specified after an implementation as in widespread use.  Look at HTTP, look at ssh, look at OpenPGP.  These all have organic ecosystems of implementations, and were all specified after an implementation went into widespread use.  It is simply part of the maturation process.  Crypto currency is no different.  Lacking a spec actually prevents the "organic" nature you speak of, the same way that any other single-implementation unspecified "protocol" does.

Nope, not going to happen in Bitcoin.  And that will be its downfall.  The well specified crypto currency will have long term advantages that could well ensure it wins in the market, despite Bitcoin's first mover advantage.

Not going to happen within Bitcoin.  If we want such a thing, we are going to have to create it, and it is not Bitcoin.

A agree with you, but based on statements by Jeff, Gavin, and Mike, this will not happen.  If we want a well specified crypto currency with a wealth of implementations, we are going to have to create it.  Bitcoin is not that, and it is not going to become that.

It was never a founding principal for greater hashing power to resolve hard forks.  Hard forks by definition can't EVER be resolved by hashing power.  If a single node remains on an incompatible fork it exists as a parallel implementation of Bitcoin.  Creating a precedent for using hashing power to fork the network is horribly dangerous and will lead to intentionally putting bugs into the codebase to force a fork for profit.


You are completely uninformed.  v0.7 nodes didn't crash they simply rejected the block.  The risk is that v0.7 nodes would be vulnerable to attacks by double spends, 51% attacks and accepting newly generated coins from the incompatible v0.7 generation blocks.

The rational for rolling back to v0.7 was to prevent massive chaos, and loss of confidence and scammers and fraudsters looted the users of running older nodes.  Nobody is saying we will remain on BDB forever but the transistion can be better managed.

A v0.81 can be released which uses the new db format but prevents incompatible blocks.  older version users can be strongly encouraged to upgrade to the new version and warned of potential risks in staying with incompatible older version.  Where a vast super majority (not of miners but of ALL stakeholders, users, exchanges, merchants, service providers) are on the new platform a final critical warning can be released notifying users of older version they face significant risk of being forked away if they don't upgrade and then the incompatible block rules can be introduced.

TL/DR a planned transition instead of a "fork it and if people get fucked in the chaos, well too bad" attitude.  Which do you think will destroy trust in the Bitcoin network?

Read the chat logs before speaking about topics of which you know little.

The miners were not "forced" to do anything.  They could have chosen to stay on the 0.8 side of the fork.

Each miner (really, pool operator) votes with their collective hash power, deciding whether or not to support a mining-related decision like this.

suffice it to say there are hella layering violations in bitcoind and that is *bad* for bugs. can't really blame the devs tho, unless they helped write the original client from whence they inherited said issues.

MPOE-PR: Please do think from what I posted above that I defend the decision to forcibly accept the 0.7 fork and abandon the 0.8 fork, in violation of the bitcoin protocol's founding principle that greater hashing power always wins a dispute. Nobody asked me, of course, since I am neither developer nor mining pool manager. But as I see it, the final decision had two strong drawbacks and one weak upside.

The first strong drawback is that the decision forced a patch on clean efficient code (0.8 ) to conform to buggy slow code (0.7). In my experience this is never a good idea over the long pull.

Second, the decision burned up developers' political influence. A handful of developers used their deservedly high community respect to force a decision on the 0.8 miners. So be it. But the next emergency will see developer influence greatly reduced in consequence.

The weak upside? The decision prevented thousands of 0.7 users suffering crashes as their wallets choked on the offending block. This would have forced users around the world to stop dithering and upgrade to 0.8 immediately. So? What would have been wrong with that?