In re Bitcoin Devs are idiots

[Uglux]

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

Careful with this. You are being the very same thing, claiming "to know the one and only truth":

This is not how the world works, currently (and past about 1800 or so). This is not how the world should work, either.

But your later proposals seem to be quite constructive...Only your "idiot-anger" is obscuring the view on things maybe sometimes. Nonetheless I agree with you, that this incident should be used as an opportunity to rethink/improve the "development process".

[MooC Tals]

On 2011 an external factor made Bitcoin nose dive...... Imagine what would happen this time.... Don't kid yourselves like some people in the IRC room. This is the biggest problem Bitcoin ever faced and it is waaaaay bigger than the MTGox. hack.

I am not pulling out I am just pissed off Bitcoin will suffer greatly because the DEVS MADE A MISTAKE! you dont freaking PUSH such things without proper testing. EVER HEARD OF TESTNET!!!!!!

Maybe we should have a form of crowd funding to keep them interested. We do need competent people working on this in a decentralized manner. I'm not saying they are not. I'm saying lets give them something thats a bit of an incentive.

As far as I am concerned they did a great job and need praise. They worked together and put aside their differences. That is something I enjoyed hearing about.

I'm amazed to see this get this far and as my thoughts on humanity go, well they're  less than impressive. My only concern is when bitcoin gets really big and greed begins to corrupt.

As for calling Dev idiots is quite harsh, maybe more foolish would be a better word.

[enquirer]

Studied the IRC logs, and it was Luke Jr who first uttered the 4 letter word starting with F, first proposed a viable solution, and first took practical steps to alleviate the problem. However crazy that guy appears to be, he's extremely smart. But I sometimes think his religious and tonal rants are just trolling.

[misterbigg]

Two points:

1. Even if the OP is making a valid point, the way in which shim resorts to insults and name calling cheapens the discussion and only serves to further soil their reputation (if that's even possible).

2. The lack of significant alternative implementations, lack of technical specifications, the developers' show of disdain for formal standards, and the apathy of the Bitcoin Foundation towards better process is a significant threat to the growth of Bitcoin.

I've put together a description of the development of the Gnutella protocol as an example of what Bitcoin development could and should be, here:

What Bitcoin Could Learn From Gnutella

[misterbigg]

...you seem to have several...

I second that. I would love to put MPOE-PR on ignore but unfortunately mixed in with the vitriol are valid points. Bitcoin is not served by having a representative of a Bitcoin business act like an immature jerk.

[MPOE-PR]

To the OP, while misterbigg cannot resist revealing his hypocritical nature

I'm not too concerned with that muppet's posturing. In general it's enough to point out his shady past and he goes away (at least for a little bit).

This thread would be so much more productive if you could act in a more civilized manner.

Understand something here: I am not interested in the problems of coding. It's not what we do, MPEx has its plate full (very, very full) just trying to bring some sense into Bitcoin finance. We can't be doing everything nor do we wish to do everything. The idea is that other people, blessed with the relatively much more common skillset of computer programming, keep an eye on things and at least grosso modo keep nonsense to a low roar.

By the time I have to talk about Bitcoin coding issues the ball has been dropped so far by so many people so many times it's not even funny anymore. So let's have a simple fix: PEOPLE QUIT BEING IDIOTS and I'll be happy to never have to post in this subsection of the forum ever again.

And conversely, when you see me talking here you know SHTF. Badly so.

Now go ahead have your useful discussion, discern important steps moving forward and make progress in improving Bitcoin.

That being said, thank you for being persistent on a few important points.

You're welcome. Hopefully it's the last time the world's greatest currency has to be thus helped by idiots like me. You know?

[kjj]

Holy fuck!  I'm talking WAY, WAY, WAY, WAY beyond my area of expertise.  I hope that I don't get humiliated by like 90 guys that actually understand what I'm talking about.

Shit.  You all beat me to it.

[niko]

(Snip)
2. The lack of significant alternative implementations, lack of technical specifications, the developers' show of disdain for formal standards, and the apathy of the Bitcoin Foundation towards better process
is a significant threat to the growth of Bitcoin.
(Snip)

It appears that some of developers' disdain for formalization of the protocol is rooted in self-interest to keep the heart of Bitcoin accessible to them exclusively. This may be related to several things - from elitist, self-centered power trips (some of them are cocky to say the least) to emotional attachment to their "child" and consequential need to protect the child from the chaos of inevitable promiscuity of the adulthood. Either way, it's pathological. Even if they are right in that Bitcoin is too young to be let in the wild for anyone to play with, they ought to work on helping it develop and grow healthy, rather than possesively protect it by letting it degenerate into an ever-worsening hairball of poorly documented details and unexpected consequences.

Seriously, if in the next three months I don't see serious and productive effort to formalize and specify the current protocol and future use cases, I'm out of here. It will only be a matter of time before chaotic, "organic" patching of old and new features leads to a total disaster.

[benjamindees]

However crazy that guy appears to be, he's extremely smart. But I sometimes think his religious and tonal rants are just trolling.

Did you know that Chinese weights (before metric) were based on a hexadecimal system?  I wonder how many merchants are still used to that system.

None of the Bitcoin developers are "idiots".  And they all have their own interests.  Luke just seems to be a bit more open about his, and takes a lot of crap for it.

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

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

It is a question of wording - if we assume everybody knows all facts: you may call it a bug in bitcoin, that the BDB was used misconfigured.

What configuration will work in all cases?  This may be impossible to tell, because it is impossible to prove if bitcoind and all it's components works correctly in all cases.  This follows from The Halting Problem described by Alan Turing.

Testing and avoiding bugs is important, but it is just as important to handle situations like this when they occur, and I think this one was handled very well.  A hard fork with two parallel blockchains going on forever was avoided.  Because bugs will happen.  No amount of testing or algorithm proving can eliminate all bugs.

Anyway, no need to insult people here from the very beginning of the thread - but this seems also a characteristic of this bitcoin forum(s) that this is tolerated. :-(

I have this user on ignore.  I am not alone, as you can see from the piss yellow background of his ignore link.  Nothing even remotely clueful, interesting or constructive comes from his keyboard.

[marcus_of_augustus]

It is not a bug. It is entirely predictable behaviour if anybody had bothered to read the documentation and run the test ... at any time in the last 4 years. (Including satosi nakamoto or mike hearn)

The max lock limit was hit ... do some reading on BDB tutorial.

https://bitcointalk.org/index.php?topic=152208.0

http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html

[markm]

Yes, but, the max lock limit impacts the size of blocks you can handle, because larger blocks are able to touch more transactions thus need more locks.

So presumably the size of blocks to allow miners to create should, if your theory of predictability holds water, be computable from the number of locks, in which case the -blockmaxsize RPC call ought not to have allowed miners to specify a block max size large enough to need more locks than the BDB had been configured to permit.

-MarkM-

[ShadowOfHarbringer]

This matter was apparently for the first time discussed here, which is in itself ridiculously late, but the recent events illustrate the need of having the various issues much more clearly delineated.

(...) blah blah blah (...)

(...) some bullshit (...)

From the posts of yours i would rather say that you are an idiot, not the devs. And a troll.

This is an open source project for a reason. Use the source, luke.
If you don't like the default Bitcoin client, make a better one yourself. Or pay for the features you want.

(Or you could just shut up & die).

[marcus_of_augustus]

Yes, but, the max lock limit impacts the size of blocks you can handle, because larger blocks are able to touch more transactions thus need more locks.

So presumably the size of blocks to allow miners to create should, if your theory of predictability holds water, be computable from the number of locks, in which case the -blockmaxsize RPC call ought not to have allowed miners to specify a block max size large enough need more locks than the BDB had been configured to permit.

-MarkM-

I think that size of the block (total size of all tx) and number of locks required is only loosely correlated ... so raising the block size limit made it more likely that the default lock limit would be hit, but not predictably.

If you constructed a block just so, i.e. it has more than 5000 locks required, it will predictably recreate a defective block.

In fact, if you were a malicious mining pool operator you could do that now with a pre-0.8 version and fork the chain the same as 0.8.

Bitcoin is vulnerable in the current state ... security through obscurity it seems, because someone would need to be arsed to figure out how these lock limits work so they can attack the chain.

I could go on but I think I might be saying too much already.

[markm]

There is a max number of inputs and/or outputs a block of a specified size could possibly contain, so that, plus the number of transactions it itself contains, bounds the number of transactions it could possibly touch. Double that to account for needing to process two blocks at the same time when doing a re-org. Then add some fudge factor, or double again or something, to account for any margin of error you think your calculations might have.

Hopefully the configuration even lets you specify the page size you want BDB to use, so that you don't have to know the block size of the underlying block-device in order to do these calculations.

As to being arsed, it is only an experiment and only involves less than a billion dollars or so so yeah, time enough for that when the experiment has determined whether there is any point in building a real implementation of something along the lines of what the experiment is attempting.

-MarkM-

[mobodick]

Instead you resort to taunts, name-calling, arrogance, and general pompous asshat dickery.

LOOOOOOOL
General pompous asshat dickery is EXACTLY what i have against MPOE-PR!

Generally the pompousness is dripping off of the OP in a peculiarly dickery matter.

And once such a tone is set you can expect people to pick up on it.
So if you want to address general pompous asshat dickery you may very well want to start at the root of the problem, the OP.

[MPOE-PR]

In fact, if you were a malicious mining pool operator you could do that now with a pre-0.8 version and fork the chain the same as 0.8.

Probably not, because all the pre-.8 clients would uniformly reject that block, which includes most of the miners since they've downgraded. A lock-blocking block could be manufactured just fine, but it would not likely end up as anything more than a 1 block deep orphan.

[jgarzik]

(copied from misterbigg's thread)

As Pieter wrote on bitcoin-development list,

The protocol is whatever the network enforces - and that is some mix of versions of the reference client right now, but doesn't need to remain that way.

I would very much like to have a text book of rules that is authorative, and every client that follows it would be correct. Unfortunately, that is not how a consensus system works. All (full) clients validate all rules, and all must independently come to the same solution. Consensus is of utmost importance, more than some theoretical "correctness". If we'd have a specification document, and it was discovered that a lot of nodes on the network were doing something different than the document, those nodes would be buggy, but it would be the specification that is wrong.

Or restated:  The fundamental problem being solved by bitcoin at a technical level, on a daily basis, is the distributed consensus problem (link).

We fully support the writing of specifications and documentation, which you can see here
    https://en.bitcoin.it/wiki/Protocol_specification

And changes to the existing protocol are formally documented here,
    https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

Ultimately the operational definition of consensus comes from what the network accepts/expects, not a theoretical paper.  Specification practices are healthy as a manual, human-based method of achieving consensus on network protocol rules.  Alternate client implementations (c.f. heterogeneous environment) are another good practice.

But the collective software rules are always the final specification, by definition.  That is what bitcoin does, achieve consensus.

A few other observations:

Gnutella had a business and project environment with co-motivated individuals working on a few key codebases.  The reference codebase in bitcoin, in contrast, has one paid developer (Gavin@BF) and a few part time unpaid volunteers.

All the big bitcoin businesses seem to either (a) contribute to BF, (b) use bitcoind without contributing back any testing/dev/specification resources, or (c) do their own thing entirely, not contributing back any testing/dev/specification resources.

Bitcoin is a thing, an invention, not a funded project with a built-in set of professionals paid to ensure full spec/dev/test engineering effort.  If you want something, DO IT.  You cannot expect the engineering resources to do X to magically appear, just because you complained on an Internet forum.

In an unfunded open source project, arguing all day about the lack of full-engineering-team rigor is entirely wasted energy.  Blame the dev team if that is your favorite target, that will not magically create extra time in the day or extra manpower to accomplish these extra tasks being demanded by non-contributors.

The time spent whining about what an unfunded effort fails to do could be better spent, say, creating a test network of full nodes running all known bitcoind versions, 0.3 through present.  And test, test, test changes through that.

[markm]

Okay, so, requirements specification:

1) Without producing zero-day exploits,

2) The network achieves consensus as to which blockchain fork is the "correct" one,

3) By means of ...

-MarkM-

[MPOE-PR]

Pieter is wrong. Point blank. It would be the implementation, not the specification, that is broken.

But the collective software rules are always the final specification, by definition.  That is what bitcoin does, achieve consensus.

This is a red herring. In a heterogenous environment your statement would stand. In a broken single-implementation that you folks have by now become painfully unable to maintain, this is not at all true. Currently, the "rules" is what you manage to con irresponsible pool operators into implementing (and they ARE irresponsible, and mining power should not be concentrated with the sort of clueless noobs either, but that is a different discussion).

Again, the fact that you happen to be buddy-buddy with Tammany Hall Guild does NOT lend your mistaken, misguided and ultimately idiotic pseudosolutions the veneer of some sort of democratic or distributed process. Claiming otherwise is at the very best naive, but even then it's awfully selfinterested naiveté.

Stop claiming that the broken code you people keep spewing is "solving" anything. It is not, and especially not lofty things such as the dcp. So far you have trouble configuring the world's simplest, cheapest and most widely deployed database system.

And when that failure of yours comes to bite you in the ass the response is that BDB was buggy? At this level one could hire a better dev team just by trolling general ubuntu support forums and teaming up all the douches with unanswered support questions.

Forget the delusions of grandeur. See a and b above, #71.

Okay, so, requirements specification:

1) Without producing zero-day exploits,

2) The network achieves consensus as to which blockchain fork is the "correct" one,

3) By means of ...

-MarkM-

...by means of having a specification that is independently implemented so that broken implementations such as each and every version so far produced of this so called "reference" client fail to cause the massive problems that they have so far caused on each and every release.

I'm not sure this is getting through the fog of their own farts, but the group of power rangers has so far:

1. Not produced one single brilliant solution to any actual problem.
2. Stepped in a majority of the holes, landmines and caltrops available.

1 is of particular concern, especially because it is so easily disprovable.