In re Bitcoin Devs are idiots

[mobodick]

Let me take the opportunity to clarify some points of apparent confusion:

And did you ever pay these independant devs for fixing shit for you for free?

This question is malformed. If you are asking me whether they owe me, the answer is yes.

HAHA.
If they owe you then why cant you settle this on a personal matter?
Why the neeed for public support, why the call to arms?

Are they your wage slaves so you can demand that they do work for you or anyone else?

Yes, they are. This is what being a developer means in this context: that you are a servant. A slave, if you prefer that terminology. One who obeys. An inferior. A steward. Nobody, politically speaking. I'm running out of alternative ways to put this, but I would hope you get the idea.

Where do you get that idea from? Where is the contract that the bitcoin devs need to take this position in the way you describe so overly?
And what would enforce this status?

If someone is interested in becoming politically relevant, being part of the dev team is not only a waste of his time, it's a waste of everyone's time. That a number of the more socially inept kids are doing this (Amir Scarface Taaki, who has meanwhile thankfully been ejected, Weirdo Luke, Gregory Pointless Maxwell and on and on) doesn't make it workable. It just doesn't work.

This is inherent to such an open project like bitcoin.
People, including programmers, will have political opinions.
Anyone can contribute to the source and it shows deep misunderstanding of open source development when someone bluntly demands something of the development process without actually actively participating in it.

If someone is interested in becoming rich, being part of the dev team is not only a waste of his time, but a waste of everyone's time. It's just not how it works. Being part of the dev team is being part of the slaves, the servants, the stewards, the however you'd call them. This abject social position does not entitle them to immunity for their fuck-ups in any case. You may dislike that, and that's fine, but your likes and dislikes have no power to change this world.

I call them the creatives, the makers.
You're a shitty user and you have no actual power over the ones you call slaves.
You are nothing without them and you know it.
Show some respect.

Have you ever discussed your issues with the development team in a calm and adult manner?

You are not entitled to place limitations on the manner of my discourse. The correct question to ask here is, MP recently published an article about the problems in Bitcoin. Have the developers read it and noted this fact?

No, but i can take note of it and form an opinion.
You seem to communicate rather single sidedly, preferably by pamfletting. On an open platform like internet that actually deters from a direct discussion or participation.

Do you even have the capacity to understand what you ask of them? (your tone tells me you're oblivious
How much further does your understanding of the problem go besides: "It's fucked up! fixitfixitfixitfixit!!@@!@!!!!" ?)
And how would you consider devs being independend if you expect them to give in to your tantrums?

I would guess you probably haven't actually understood what's being discussed here at all. As a rule of thumb that may serve you well in the future: whenever things happen that don't make sense to you, it's likely because you've not understood what's actually happening. It's rarely because the people involved are wrong. This is because you are stupid.

As to the matter of "testing":

sipa   jgarzik: have we seen a block which affected 5000 transaction index entries?
jgarzik   sipa: I don't think so

Fuck you.

This is not testing. Stop releasing new clients, you don't have the license to do it, idiots.

I understand perfectly what is being discussed. And i know it hurts when someone holds up a mirror so i don't mind the swearing.
And as usual you neatly cycle around the difficult part.

How do you expect devs to be independent if you demand stuff from them?
Slaves are not independent, they are slaves.

[justusranvier]

this is fixable though

It is only fixable if fixed.

Does MPEx prefer problem to be fixed, or remain unfixed?

[VeeMiner]

There should be no need for a Kickstarter campaign at this point, one of the reasons for Bitcoin Foundation's existence is to "standardize bitcoin". I don't know how many coins they already collected from their Enterprise / Corporate members, but I hope that not all of them are spent on Gavin's salary and publicity tours.  Some should go towards funding the serious effort of extracting and publishing

BPS (Bitcoin Protocol Specification) version 1.0 and then targeting version 1.0 against the spec rather than declaring it to *be* the spec.

BPS 1.0 will be the Cambrian Explosion event of alternative implementations with the gene pool finally diversified across languages and dev teams.

P.S. Anecdotally, I personally know an extremely competent C++ programmer (who posts frequently in the forum) who is basically "already rich enough to retire" and who holds huge amount of bitcoins and who really really wanted to contribute to http://github.com/bitcoin/bitcoin but had to give up after seeing all the magic of that magic kingdom with all the magical creatures who live there, i.e.

It would take about a week to do a proper local setup including testnet before you can even beging to be confident in any of your own lines NOT to feel ashamed submitting it as a pull request.  Sadly, he gave up.

Yet, the real point is this once we have BPS, only then we can "let 1000 flowers bloom" until then it's all a circle-jerk, sorry.


Cheers ...

I agree with you mate, this should be done, we need BPS and it should be possible to fund it through the foundation.

It's sad that people that want to help out are discouraged by other developers.

[mobodick]

Try and stay on topic. Trying to find "bigger idiots" doesn't help anything, which is why politicians do it all the time.

I'm sorry, but i couldn't find a more adept swaxription of the situation.
You call the devs idiots, but you are the one that trusts that software or peoples intelligence or motivation will never fail.
If you were NOT an idiot yourself you could have known that software development never is perfect, open source development even more so.
Assuming you're not REALY an idiot i can only think that you must have known the risks when you invested your energy to build something on the substrate of bitcoin.
And if you knew then you should STFU.

[grau]

It IS fixable.  Let's see if this the latest episode provides enough motivation for devs and Bitcoin Foundation to start even talking about BPS 1.0, so far there's been clear lack of any will for a spec, instead all the usual ("we are all just victims of the original C++ hairball dropped on us by Satoshi", or "there is too many bugs we cannot ever fix b/c some ancient client might depend on them" are brought out and reheated over and over again)

I went through the self imposed pain of implementing the protocol from scratch and learned the hard way that the behavior of the Satoshi client is not captured by any written sources other than its code.

Documenting the protocol is a major effort and it would have to be code rather than text in quite a few details to be precise, but I think it is doable and should be done.

Yes, the foundation should fund the effort.

[MPOE-PR]

this is fixable though

It is only fixable if fixed.

Does MPEx prefer problem to be fixed, or remain unfixed?

The position of MPEx is that the current dev team should release no further versions until a. Bitcoin is specified and b. The codebase is cleaned up.

[alexkravets]

It IS fixable.  Let's see if this the latest episode provides enough motivation for devs and Bitcoin Foundation to start even talking about BPS 1.0, so far there's been clear lack of any will for a spec, instead all the usual ("we are all just victims of the original C++ hairball dropped on us by Satoshi", or "there is too many bugs we cannot ever fix b/c some ancient client might depend on them" are brought out and reheated over and over again)

I went through the self imposed pain of implementing the protocol from scratch and learned the hard way that the behavior of the Satoshi client is not captured by any written sources other than its code.

Documenting the protocol is a major effort and it would have to be code rather than text in quite a few details to be precise, but I think it is doable and should be done.

Yes, the foundation should fund the effort.

+1. See latest emails in bitcoin-dev mailing lists (another little refuge where "big guys" and "magicians" hangout)

[mobodick]

this is fixable though

It is only fixable if fixed.

Does MPEx prefer problem to be fixed, or remain unfixed?

The position of MPEx is that the current dev team should release no further versions until a. Bitcoin is specified and b. The codebase is cleaned up.

That, at least, is a reasonable wish.

[MPOE-PR]

Documenting the protocol is a major effort and it would have to be code rather than text

No, it would not.

Learn to separate design and implementation already, it's software design junior fodder.

[Timo Y]

Don't look a gift horse in the mouth.

You are too stupid to be here. Please leave.

Yeah, that's really persuasive.

[justusranvier]

The position of MPEx is that the current dev team should release no further versions until a. Bitcoin is specified and b. The codebase is cleaned up.

Is MPEx going to do anything to help make this happen other than talk about it?

[mobodick]

Documenting the protocol is a major effort and it would have to be code rather than text

No, it would not.

Learn to separate design and implementation already, it's software design junior fodder.

I want to point out to you that a successfull definition of entropy is the shortest possible computer code that produces a certain output.

So yes, it may very well be.

The onus is on you to show that all of bitcoins core code can easily be compiled into human language.

[alexkravets]

Guys,

Let's not muddy the waters here ...

There Shalt Be a Spec.  That's all there is to it.


The only question is what kind of pressure needs to be brought to bare and where to expedite that process.

Your target list of people to pressure / influence is here https://bitcoinfoundation.org/about/board  *especially* Peter Vessenes (last one on the list) because he's also in charge of CoinLab and its future big wholesale deals with Wall Street hedge funds investing into bitcoin through Coinlab will live or die based on convincing them that Bitcoin can grow up and become an actual internet standard (i.e. BSP 1.0) and not just remain a C++ hairball with attendants.

Cheers ...

[MPOE-PR]

The position of MPEx is that the current dev team should release no further versions until a. Bitcoin is specified and b. The codebase is cleaned up.

Is MPEx going to do anything to help make this happen other than talk about it?

See post #87 earlier.

The onus is on you to show that all of bitcoins core code can easily be compiled into human language.

You are very, very confused about how this "onus" thing works. Perhaps you'd be best served by following the advice given to usagi.

For that matter, the point you only seem to have grasped in #149 had in fact been my position since about #71. Try reading what I say twice before talking to me (or if you already are reading it twice, read it thrice from now on).

*especially* Peter Vessenes (last one on the list) because he's also in charge of CoinLab and its future big wholesale deals with Wall Street hedge funds investing into bitcoin through Coinlab will live or die based on convincing them that Bitcoin can grow up and become an actual internet standard (i.e. BSP 1.0) and not just remain a C++ hairball with attendants.

*falls over laughing*

Yeah dood, totally. Once Bitcoin is specced properly Wall Street will move to Silicon Valley Bank. I can see it in mobodick's onus.

[justusranvier]

See post #87 earlier.

Fair enough.

There Shalt Be a Spec.  That's all there is to it.


The only question is what kind of pressure needs to be brought to bare and where to expedite that process.

Incorrect. The only question is who is willing to do it, and who is willing to support them.

I am willing to donate bitcoins, and to help test changes by compiling and running a node on testnet.

[MPOE-PR]

Incorrect. The only question is who is willing to do it, and who is willing to support them.

I am willing to donate bitcoins, and to help test changes by compiling and running a node on testnet.

To quote here:

<mircea_popescu> jurov anyway, the problem isn't as much the drama, but moreover that a single-source codebase is both non-bitcoiny and suspect.
<mircea_popescu> but i think if we can get one (or ideally multiple) people to summarize the code
<mircea_popescu> we can pretty much derive a spec from there.
<mircea_popescu> this wouldn't take much longer than a few weeks for a first draft, which can then be argued and refined
<mircea_popescu> in my experience any devteam resists such an effort like cats resist washing, because coders love to write but hate having to read code.
<mircea_popescu> hiowever, once it's complete there's a few day's worth of facepalming and going "wait, we are doing W?HAT ?!"
<mircea_popescu> after which everything's much better.
<mod6> this is a solid plan.
<mircea_popescu> mod6 in experience it tends to work.
<mircea_popescu> of course it has to first get the cat into the washing machine.

There wouldn't really be need for much testnetting, at least originally (ie, for the first draft).

What there's need for is people to sit down with a cup of coffee and a (preferably printed) copy of the code and just read it through. This can be done in bits as long as the bits aren't arbitrarily segmented (it's ok to summarize a procedure, it's not ok to summarize between lines 520 and 545). Once we have a few of these completed we're already very far down the road.

Then the work of merging them into a spec emerges, where a lot of arguments will for sure be had ("no, it doesn't do that"/"yes it does") at which point there may be a need to whip out the testnets but not necessarily. Then a ton of drama and hurt feelers, and then that's it, once everyone is beaten into a pulp we have the spec.

Ideally this would include people other than the current dev team, not because the current dev team is made of idiots (which mostly it is) but because people tend to read what they think should be there and in general skip over the unflattering bits.

In fact this can be started today.

[mobodick]

The position of MPEx is that the current dev team should release no further versions until a. Bitcoin is specified and b. The codebase is cleaned up.

Is MPEx going to do anything to help make this happen other than talk about it?

See post #87 earlier.

The onus is on you to show that all of bitcoins core code can easily be compiled into human language.

You are very, very confused about how this "onus" thing works. Perhaps you'd be best served by following the advice given to usagi.

For that matter, the point you only seem to have grasped in #149 had in fact been my position since about #71. Try reading what I say twice before talking to me (or if you already are reading it twice, read it thrice from now on).

No, you are just very very confused about the position you take in this matter.
What i make of your point is that you want some specification. What i call you out on is your critique directed at grau's idea that the algorithm may not be easily specified at all. The normal situation is that not every problem can be specified easily. So please demonstrate why the bitcoin software can. The burden is yours.

*especially* Peter Vessenes (last one on the list) because he's also in charge of CoinLab and its future big wholesale deals with Wall Street hedge funds investing into bitcoin through Coinlab will live or die based on convincing them that Bitcoin can grow up and become an actual internet standard (i.e. BSP 1.0) and not just remain a C++ hairball with attendants.

*falls over laughing*

Yeah dood, totally. Once Bitcoin is specced properly Wall Street will move to Silicon Valley Bank. I can see it in mobodick's onus.

I'm sorry, but i was still holding up the mirror..
 

[justusranvier]

Incorrect. The only question is who is willing to do it, and who is willing to support them.

I am willing to donate bitcoins, and to help test changes by compiling and running a node on testnet.

To quote here:

<mircea_popescu> jurov anyway, the problem isn't as much the drama, but moreover that a single-source codebase is both non-bitcoiny and suspect.
<mircea_popescu> but i think if we can get one (or ideally multiple) people to summarize the code
<mircea_popescu> we can pretty much derive a spec from there.
<mircea_popescu> this wouldn't take much longer than a few weeks for a first draft, which can then be argued and refined
<mircea_popescu> in my experience any devteam resists such an effort like cats resist washing, because coders love to write but hate having to read code.
<mircea_popescu> hiowever, once it's complete there's a few day's worth of facepalming and going "wait, we are doing W?HAT ?!"
<mircea_popescu> after which everything's much better.
<mod6> this is a solid plan.
<mircea_popescu> mod6 in experience it tends to work.
<mircea_popescu> of course it has to first get the cat into the washing machine.

There wouldn't really be need for much testnetting, at least originally (ie, for the first draft).

What there's need for is people to sit down with a cup of coffee and a (preferably printed) copy of the code and just read it through. This can be done in bits as long as the bits aren't arbitrarily segmented (it's ok to summarize a procedure, it's not ok to summarize between lines 520 and 545). Once we have a few of these completed we're already very far down the road.

Then the work of merging them into a spec emerges, where a lot of arguments will for sure be had ("no, it doesn't do that"/"yes it does") at which point there may be a need to whip out the testnets but not necessarily. Then a ton of drama and hurt feelers, and then that's it, once everyone is beaten into a pulp we have the spec.

Ideally this would include people other than the current dev team, not because the current dev team is made of idiots (which mostly it is) but because people tend to read what they think should be there and in general skip over the unflattering bits.

In fact this can be started today.

Another approach is to write the spec while refactoring the reference implementation into something more documentable. Any superfluous functionality than can be removed from bitcoind and moved to the clients is less functionality a fully-compliant alternate implementation is required to implement.

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.

This would definitely be the first step out of the current insanity and finally bring some layering into the code base client UI === depends on ==> bitcoind but zero backward pointing dependencies.

This would be the first step on the long journey to the promised land of the BPS (Bitcoin Protocol Specification)

[MPOE-PR]

Another approach is to write the spec while refactoring the reference implementation into something more documentable. Any superfluous functionality than can be removed from bitcoind and moved to the clients is less functionality a fully-compliant alternate implementation is required to implement.

Yes, but the disadvantage of that method is the (possible? probable?) leak of things that don't belong into the spec draft. In general doing multiple things at the time should be avoided as much as possible.

[niko]

It is also a huge issue that those suggesting we need the protocol spec are brushed off with the "you don't get it" nonsense by elitist devs.
Bits and pieces, some expired, are scattered around Wiki. Is that the best we can do?
@MP: would you be willing to lead the effort of formulating the current protocol spec?

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.

You're right, I really don't get it.  "Any divergence from that behavior... will result in fiascos like this one." Breaking news: this little fiasco was the result of a bug in the reference client, not any "divergence" of alternative implementations. You want to base a technology handling billions of dollars on a black box that, according to your words, "has a whole bunch of unspecified and unintended behavior that no-one knows about" FYI, someone will get to know some of these things, and some of that will become zero-day exploits. If your kind of sentiment and irrational justifications continues to prevail among developers, I am going all out of Bitcoin. I still don't understand how any sane person can try to defend voodoo black box approach to defining the protocol.