Topic: In re Bitcoin Devs are idiots (Read 25449 times)

jgarzik

Is this what is supporting bitcoin? What happens when they all decide they want to work on some other project? I know I am not fully understanding bit coin but someone who like driving a bus and wants to drive a bus better be driving the bus.

I'm amazed it has gotten this far to be honest.

anyways you all can go back to ignoring the noob.

Actually this is incorrect.  The Satoshi client goes into safe mode when it notices that a branch it believes is invalid has become the longest one by more than 6 blocks.  This actually happened to the 0.7 clients, which is what Pieter Wuille is talking about here in the original fork announcement:


Some more details and links to the code are here if you are interested.

I don't hold myself responsible for your endless string of presupositions. You think they're true, that's fine, I don't happen to care and it doesn't happen to matter.


I am giving them *some* respect.

Rehashing a defeated (and mostly nonsensical) argument in new terms doesn't lead it more credence.

I don't argue a given horse.
I argue that if someone volunteers to do programming for a whole community you should give them some respect. The more because you do not or cannot do this work. This whole community, including you, voluntarily uses the fruits of their labour mostly without compensating them.
 Calling them idiots and slaves like you did is just pretty fucking disrespectfull.

What does this even mean? "independent devs doing it". Dependent on what/whom? If you'd had 100 variants of the original Satoshi client all being developed and bug fixed separately and 100 variants of the mining software all being developed and bug fixed separately then we'd have had many more hardforks by now, with no-one really knowing anymore which is the true bitcoin. Do you go by the first version of the client which allowed anyone to give themselves a billion (well, a lot) bitcoins? Or some arbitrary version someone developed based on that? It simply wouldn't work. Bitcoin needs a majority client in order to not hard fork, and therefore in this sense, it can never be decentralised. The developers of this majority client will always have the power and can make decisions to change what bitcoin is whenever they like. For example, let's say they decide to increase the blocksize from 1MB to 10MB. Who's going to stop them? The users downloading bitcoin-qt? I suspect not. Most people just download it and use it without caring what changes are going on. Yes, we were supposed to be able to vote with our feet, but the people who actually do that are usually in the minority and so will lose.

I thought we got past the "gift horse in the mouth" argument a while back.

Attacking me doesn't make idiots less idiotic.

Noone is actually forcing you to talk about this stuff. Using bitcoin is entirely your own choice and your own risk.
Unless you actually contribute you're nothing but a joke when you bitch about stuff not being fixed.
Fix it yourself or STFU and GTFO...

Nobody needs you.
Let me rephrase this:
The bitcoin community does not need you or your bitching.
In fact, i bet this community will be better off without narcissistical personalities like yours that see idiots everywhere except in the mirror.

Smartass, this thread is actually earlier than the devteam announcement. Stopped to think about that for a second?


That's kinda the plan, roughly speaking.

@MPOE-PR
What about making the reference some text sticking to RFC rules? I really think this is not easy but worth the effort.
You even could go for support of the BF to do this.

Due to the recent changes implemented by theymos I would not trust to post in a thread I've not started. Sorry.

Just an FYI, "the real" to-spec-or-not-to-spec discussion has probably moved back into its newly re-activated "canonical" BPS Thread

Here https://bitcointalksearch.org/topic/m.1621672

Cheers ...

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


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.


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

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-

(copied from misterbigg's thread)

As Pieter wrote on bitcoin-development list,


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.

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.

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.

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-

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.

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