In re Bitcoin Devs are idiots

[MPOE-PR]

It's practically impossible for that to happen unless you have access to the hardware. In which case, your wallet is screwed.

Bitcoin does not transfer the private keys anywhere, you also do not know when someone is making a transaction, only when someone pushes a transaction.

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

You really, really don't get it. We can't have a protocol spec becasue the existing client has a whole bunch of unspecified and unintended behaviour that no-one knows about, and any divergence from that behaviour by any major implementation will result in fiascos like this one. This problem could just as easily have been caused by a independent third-party implementation of the client. The developers have been finding and documenting all the corner cases as thoroughly as possible, but some of them are - like this one - really subtle and hard to spot. I'm not sure anyone's managed to fully work out the circumstances under which 0.7 will fail to accept a block due to this bug.

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.

I'm not a coder but even I know this. It is what it is. Whoever wrote the code wrote it as proof of concept and then they went back and explained what they did. That's Bitcoin, like or not.

I have to say you all are very patient in the face of the spoiled brat brigade that are yelling for you all to modify their hot rod while the mechanics marvel at how its staying on the road in the first place.

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

MPOE-PR: Please do think from what I posted above

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,

A. immediately start work on specification, which is the only priority, and release no further versions until such specification is complete

B. immediately start work on removing all magic numbers and assorted code smelliness from the UNreference implementation of crap, and not release any further version before a clean implementation was released

The order is important, all that's left is for the devs to obey. Which is exactly what happens, in the real world, among sane people and where actual developers are involved. If we have a brigade of spoiled brats pretending to be devs here then indeed we have a problem.

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.

As it happens, nobody asked them.

[bullioner]

This. So much this. Dublin Core and RDF/RDA container formats are excellent examples of standards that in all of their lenitive documentation provide an example of moving the database details out of the software implementation.

This idea is from an alternate world where you don't have to worry about breaking existing users' software and data to the point that they cannot spend their own money.

Bug-for-bug compatibility is not a choice made joyfully and willingly.

Engineers always prefer a clean slate, a clean interface.  That works here, only with a little help from science fiction's time machines.

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.

[Severian]

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

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.

[justusranvier]

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.

[Peter Lambert]

What's stopping your company from hiring one developer to do nothing but code cleanups and submitting them to GitHub? There's nothing centralized about that.

Because cleanups would require very deep reaching changes. If we hired a cleanup dev his #1 task would be "find and remove all magic numbers anywhere in the codebase".

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?

[coqui33]

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

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.

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.

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.

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

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.

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?

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.

[smtp]

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

ladies and gentlemen:

this is why the "bankers" make a LOT of money. they are EXTREMELY good at what they do

Manipulate governments and markets, spread disinformation through the media and rig the currency to their benefit?

Ya, bankers are experts.

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

[Severian]

They can be specified/defined for validation of transcations and get paid for this -- exactly like real-world bankers -- and monopolize this work!

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

[smtp]

They can be specified/defined for validation of transcations and get paid for this -- exactly like real-world bankers -- and monopolize this work!

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

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

smtp

[markm]

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-

[Severian]

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

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.

[DeathAndTaxes]

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

[MPOE-PR]

What's stopping your company from hiring one developer to do nothing but code cleanups and submitting them to GitHub? There's nothing centralized about that.

Because cleanups would require very deep reaching changes. If we hired a cleanup dev his #1 task would be "find and remove all magic numbers anywhere in the codebase".

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?

This issue has already been discussed, and consensus has already been reached.

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.

Let's elaborate on that a little. Bitcoin's #1 pool is trading while insolvent at the present time because it just got hit by the double whammy of:

1. Oh, you made the mistake of updating to our most recent version? Well here you go, redownload the chain, pay submitted work as if difficulty were negative for a while. That's what hot wallets and autopayments are for right?

2. Oh, you made the mistake of updating to our most recent version? Well...revert. Oh, you need an old chain because the new chain you just paid half your house for is no good? Awww. Here, lose 16 blocks on top of the 1.1k BTC you lost before. We really want you to lose the whole house, not just half of it.

The entire "miners vote" is a sham and a total red weasel currently. Miners don't vote, miners just sheepishly follow around because "devs say so". And incidentally, a willingness to do the soviet thing and pretend this sort of crap is covered by "popular vote" when no actual voting took place speaks volumes as to the moral integrity of the pretenders. Ugly stuff.

If the miners had half a clue they'd have told Idiot Co-op exactly where to stuff it, and here's the beauty of it: with the arrival of ASICs and their significant capital cost, the odds that the sort of feelgood ninnies currently involved in mining will still be around are nil.

This is what money does, it shakes out the deadwood and culls the herd. Next time you do something because "Mike" said you should may very well be the last time you get to do anything. That little tidbit isn't too likely to pass unnoticed seeing how universal the conservation instinct is.

In other words: next time this happens devteam is gone, for the simple reason that miners will not revert, or even talk to those "devs" again.

[bitcoinBull]

That is not correct.  v0.7 nodes accepted a 1MB block on testnet.  The issue was more complex then just the size of the block.  By the protocol the block which was rejected by some nodes SHOULD have been accepted.  The 250kb soft limit was simply a default for block construction.  Even with it in place nodes should have accepted properly constructed blocks up to the 1MB limit.  It also appears not all v0.7 nodes were affected.  Some accepted the problem block and some didn't.  The defect/limit in BDB wasn't documented and didn't occur in all versions/platforms.   It appears the number of transactions being changed as a result of the block validation crossed some "magic code" not in the Bitcoin source code but undocumented in some implementations of BDB.

v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened.   Nobody was saying/thinking oh yeah if you make a block with more than x transaction it will abort, cause a rollback, and result in a rejection.  It was a landmine.  

The problem was lack of a DB_CONFIG file in the bitcoin application directory. Without that file, BDB simply chose to use default settings. The default setting of 10000 for set_lk_max_locks is not enough to handle larger blocks with many transactions (inputs and outputs). Easy fix.

[MPOE-PR]

The problem was lack of a DB_CONFIG file in the bitcoin application directory. Without that file, BDB simply chose to use default settings. The default setting of 10000 for set_lk_max_locks is not enough to handle larger blocks with many transactions (inputs and outputs). Easy fix.

Oh no, Berkeley is broken. How could you say Bitcoin Devs are just clueless? What heresy is this!

Take it to the BDB forums!

[smtp]

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.

Yes, the common/general "banker"-word can surely subdivided in many specific categories. Currently "miners" can't really, perhaps only into these 2 (raw miner, pool operator), but as longer as mining evolutes as more specific sub-work jobs will show up, like in bank-business, IMHO. Compare bitcoin-age with bank-business, say, 1000 years ago. :-)
But nevertheless, the general/principle equivalence/relation "banker" <--> "miner" holds perfectly. Probably, the miner-community likes to avoid the word "banker" for themselves because of psychological reasons.
smtp

[smtp]

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

Hmm .. the bug (or do you call it a hidden feature?)  effectively touched bitcoin-miners and not directly(!) bitcoin-users. So the other obvious solution, which Pieter also suggested at first, was to push the longer chain, the one which grew faster and not to conceal/press effectively bitminers to do an effectively 51%-attack for the "good" of the network on this chain, because the 0.7-fork is "correct". This dubious politic is highly questionable, IMHO. On the other hand, effectively convincing/forcing miners to switch to 0.8 would surely have had the advantage of a much more equal code base for almost all miners afterwards.

Appendum: Again a very important issue, which reflects a real-time behaviour is: how can one estimate which approach (if we restrict us two only these 2 alternatives) will succeed significant earlier?

smtp

[sturle]

Right now there's no question that they deserve to be called idiots. What's happening now was easily preventable and shouldn't have ever happened under any circumstances.

It's actually fucking amazing that this is first MAJOR bug in 4 years.

AND, as all critics ignore because they are clueless and it invalidates their criticism, the bug isn't in bitcoin at all!  It is in some versions of BDB on some platforms.  The developers wisely chose a better database for 0.8, but unfortunately the bug manifested itself in a bad way (it could have been worse, e.g. if the bug in BDB made remote code execution or altering old blocks possible) before almost all nodes had upgraded.

AFAIK none of the current developers are involved in BDB development, and BDB was chosen by Satoshi.  Satoshi made a few errors, but I wouldn't call him an idiot.  Shut up or do a better job.

[justusranvier]

Right now there's no question that they deserve to be called idiots. What's happening now was easily preventable and shouldn't have ever happened under any circumstances.

It's actually fucking amazing that this is first MAJOR bug in 4 years.

AND, as all critics ignore because they are clueless and it invalidates their criticism, the bug isn't in bitcoin at all!  It is in some versions of BDB on some platforms.  The developers wisely chose a better database for 0.8, but unfortunately the bug manifested itself in a bad way (it could have been worse, e.g. if the bug in BDB made remote code execution or altering old blocks possible) before almost all nodes had upgraded.

I've seen at least one thread claiming that it's not a bug in BDB as much as a misconfiguration.

[alexkravets]

It is always entertaining to watch non-contributors opine about completely obvious solutions that the devs are silly to have overlooked.

The interesting thing about bitcoin is its organic nature.  The bitcoin codebase, warts and all, was dumped into the Internet's collective lap.  Reality does not give anyone a chance to pause, wait for a specification to be polished, to wait for every single edge case to be tested (if that were even possible), etc.

Almost half a billion dollars in market cap, and the dev team is still largely unpaid volunteers, trailing behind events, cleaning up the messes reality leaves behind.

I am not sure how to read your post.  Are you suggesting the current state of affairs is a good thing or a bad thing ?  Obviously the original Satoshi client was a fact on the ground.  And "reality" hasn't given anybody a chance to pause, but can we not take a small time out now and actually define a 1.0 spec and THEN implement a backwards compatible version from 0.8 today to that 1.0 ?

It's not like every pull request on GitHub is a do-it-now-or-bitcoin-dies urgent fix, actually most of them are trying to refactor, fix & alter the existing single implementation, and some like pruning and bloom filters add huge new features with *more* latent semantics sprinkled around the C++ instead of being in the spec.

I hope the gods on mount Bitcoin Foundation are listening once in a while, but Bitcoin's monoculture of a single "magical" C++ implementation whose code serves as the spec cannot go on forever.

I wanted to create an independent implementation from scratch in Scala, but soon realized that not only there wasn't enough documentation for protocol messages on the wiki, but worse, their semantics were constantly moving targets, potentially with every github pull request being committed.  At that point I gave up.

I haven't heard of a from scratch C-based libbitcoin library much lately ... not sure if its author also had to throw in the towel after a while ... that would just be sad.

Guys, the time for heroics is great, but if you want Bitcoin to be Money of IP (as it's being advertised) then it has to be a network/message protocol spec that people can go away and implement in language X and interoperated with you.

In this Bitcoin will either follow in the successful tradition of TCP/IP, SMTP, HTTP, TLS, etc or it will be a series of heroic battles by "the community" to "save bitcoin" from future "genetic defects" found in its sole C++ implementation or one of third party libraries.

Cheers ...