Topic: In re Bitcoin Devs are idiots - page 6. (Read 25432 times)

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.

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.

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.

Thank you. I do not think I am actually far afield from Gavin, as I am pretty sure I have read him and/or other core devs discussing blockchain validator tools each of which would validate a certain range (by "height") of blocks.

In other words, no time machine going back and changing the historical past, just no repeating of the errors of the past in the future.

Basically the spec that tells us certain configurations, versions or implementations of BDB are not up to spec would be the spec for the new thing, the Real Bitcoin. The fact that the Satoshi node wasn't up to that spec gets enshrined not in the historically non-normative block-creation spec/code going forward but, rather, in the normative "validate a certain period of blockchain history's blocks" blockchain-checkers that I read some core devs discuss once upon a time.

An RFC could comment on details where certain builds of the Satoshi client on certain platforms failed to meet the new thing spec, and block heights could be targetted for the block height at which such builds will be orphaned, unsupported, deprecated, unable to function as part of "the Real Bitcoin" aka the new thing from that point on.

This is all old news / old ideas to Gavin et al I am pretty darn sure, which is why I am not in a panic over block sizes nor was in a panic yesterday evening over certain builds of Berkely DB on certain platforms in certain builds of the Satoshi node failing to perform to [ex]spec[tation].

So nyah nyah nyah circle jerk time group hugs for the geeks and techies, sorry if the PR folk aren't into that.

-MarkM-

It's ok Jeff, if this new thing will have to be the Real Bitcoin then this new thing WILL be the Real Bitcoin.

Point blank: money will never tolerate the sort of crap that has been pouring out of devtroop for the past while. I don't care you(*)'ve been dorking around with it for years and nobody told you it's wrong, that doesn't make it right, that just makes the little coven irrelevant enough.

If current Bitcoin can't be made into good Bitcoin then sucks for current Bitcoin, it is no different from Novacoin or whatever flavor of the week failed altchain.

(*) Impersonal you. Very, very impersonal you. As in, I'm not talking about you (and I'm not talking about Gavin - in fact, you know who I'm talking about).

jgarzik, i completely agree...i would be more inclined to take their criticisms seriously if they were actual contributors. but then again, i am not a contributor either (yet). Nevertheless, the core developers at least deserve the respect they've worked so hard to earn! None of this would even matter without them. i guess now is the time for the 'rats' to abandon ship, while the 'crew' works to right the ship and keep her afloat!

Sez MP:

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.

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.

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.

The spec should simply describe exact format and formal-enough semantics of all valid network messages.

That's it.  

Need examples of such specs ?

1. TCP/IP
2. HTTP/1.1 (with extensions)
3. TLS

etc.

Lets drop the bug for bug compatible idea too while we're at it.

Tolerate any existing buggy blocks over 120 blocks old or that predate the last hardcoded checkpoint or something but don't make a religion of emulating the bugs going forward.

BDB shouldn't even be part of the spec, the spec should abstract the actual database implementation details and just maybe talk about whether it should have atomic transactions, whether we should be able to roll those back, under what circumstances to roll them back and so on.

Enshrining some bug in some particular implementation of "database back end" should be anathema, our spec should basically be telling us "BDB isn't up to spec, don't use versions of it that aren't able to perform as we need them to".

-MarkM-

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?

No problem, I'll leave Gavin to it and get on with doing other stuff that isn't already on the paid developer's to-do list.

LIke altcoins maybe, since bitcoin is already on the paid developer's to-do list.

Hmm, or Open Transactions maybe. So much to do, so little time to do it all.

-MarkM-

Read up on http://en.wikipedia.org/wiki/Side_channel_attack ...

SOMEHOW? Private keys? They're all on your client and are never transferred anywhere else.

There is another 10+ hidden genetic flaws either in the C++ code itself or in one of the underlying libraries.

Imagine that next time instead of a fork split that can be healed, we end up leaking private key information through some side channel because of some bug in SSL libraries and the leakage gets embedded in the blockchain somehow ?

Such leakage cannot be repaired ... that will NOT be fixable and will simply lead to loss of confidence and extinction.

There's hundreds of deadly scenarios you can imagine here ...

Is anybody in the blessed circle of C++ magicians listening to this ?  

Bitcoin Foundation, is there any plan to extract the spec ?

No, it won't. If no action were taken people will just need to upgrade to 0.8.

MPOE-PR, your attitude makes me sick.
You've been yelling and calling developers names without having even understood what the technical issue is.
You pretend you deserve a perfect codebase and do not even spend resources towards this goal.
My opinion it that your childish rants hurt good-willed and hard-working people.
If your job is politics, then my opinion is that you suck at that job, because bitcoin as a whole does not benefit from someone technically incompetent throwing random blame around.

I, for one, do want to give a bucket of congrats to the devs for all the work done so far and for the quick response to the current problem.

One thing is interesting in this thread, it's the need for a formal spec of the protocol. alexkravets nails it real good in his posts.