Bitcoin Forum

This matter was apparently for the first time discussed here (https://bitcointalk.org/index.php?topic=101902.msg1601463#msg1601463), which is in itself ridiculously late, but the recent events illustrate the need of having the various issues much more clearly delineated.

Recently Bitcoin came close to unmitigated disaster, in the following way: Gavin diplomatically suggested that miners increase their block size, from the previous magic number of "250k" to something they themselves pick. This approach is flawed: the solution to the problem of having a magic number in the code is not passing the responsibility of choosing it to a larger group. It may work politically, in the sense that where large, vague groups are responsible for a bad move nobody will ever be hung. It does not work practically.

This point does not begin to get sufficient emphasis: stop thinking politically, stick to thinking practically. The political importance, usefulness or competence of a dev is nil. This is not your job, and more importantly this is one of the things you suck at the most. A casual skim through the -dev sessions is ample proof for this, more ridiculous dickwad posturing and knowshitism has never before been seen (outside of the mailing lists of some meanwhile failed open source projects). Snap out of it. Stick to writing code.

But we digress: as a result of a number of miners implementing their own version of a magic miner, a number of large blocks were created and mined by them, as long as they ran 0.8. Miners running 0.7 failed to mine these same blocks, and a fork developed.

The reason is that Bitcoin code sucks. It's not that "the blocksize", it's not that "the database", it's not that "nobody could have foreseen their using a plane like a rocket". That shit does not belong in this discussion, passing the buck is not and cannot be accepted in Bitcoin. The reason is that Bitcoin code sucks, and Bitcoin code sucks because people want to be Bitcoin devs, people want to call each other Bitcoin devs, people want to participate in idle irc chatter as if they in fact were Bitcoin devs, but those same people do not have either the ability or intellectual resources to write dependable, usable, good, clean code.

This is a problem, and this problem needs to be resolved, preferably by the people who are causing it. You know yourselves, I won't name and shame. Fix your heads. You won't be getting much more warning.

Today will go down in history as the day when Bitcoin nearly died, and its fate depended on BTC-Guild staying online. Stop and think for a minute. What are you doing here? Why are you here, really?

Talk about armchair quarterbacking. How easy it is for someone to just sit back and point the finger. Have you seen the Bitcoin software? Do you understand C++ code? It's complicated, and the rules which have evolved in response to strengthening the network are not so easily factored into neat code compartments.

Instead of bitching why don't you write your own client that has clean code?

Likewise, misterbigg.

Mhm.. Sell?

What doesn't kill you makes you stronger.

MPOE-PR, what are you doing here? Why are you really here?

Has MPEx considered hiring "good" programmers to work on the bitcoin code?

Considered, yes. One problem is the centralization issue stemming from that approach. The one correct way to handle Bitcoin development is exactly as designed: independent devs doing it. The problem is that instead of doing it they spend their time opining on things that utterly ain't their business.

Time to deversify into Ripple ledger chain, lol

Seriously, the bug was in old 0.7 version but it got a chance to manifest only because of an incomplete .8 rollout WHILE at the same time suggestion was made to increase soft block size limit.

Lesson: do only ONE major change at a time and let the dust settle before moving to the next one

Devs handled this like fucking pros. Bullish for bitcoin.

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.

Damn, you had to be the one to bring the bad news...  :-\

Be back in a minute, have to patch some software.

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". Meanwhile listen to these idiots:


MORE MAGIC NUMBERS.

It looks more like a lost cause than anything. And no, the fact that "we're fixing it" does not impress me in the slightest, and NO, they're not handling it "like pros".

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation

I guess that's your cue to leave. Don't let the door hit you on the way out!

And?

If you say you know what the problem is, and have the ability to correct it, why complain about it unless you're going to do something?

That would be correct. It's a huge issue.

Then you should develop your own cryptocoin with code that even a blind man could read. It sounds like you already have it figured out.

This is an experiment. Something like Bitcoin has never been done before. I don't recall getting any guarantee when I got my coins or sent transactions, do you?

This (and the rest of the mindless crap) has nothing to do with the matter. A guarantee or no guarantee doesn't make the lift eyelid insert fork person any less of an idiot.

Let's try and stick to the topic.

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

The topic is you calling a group pf people idiots that are doing something you can't do.

The whole attitude of only having a single full implementation.  

First off: BTC development is a free market.  This is the tragedy of the commons.  If MP is unsatisfied with the code he should stop leeching like a welfare queen and pay for development.

Secondly, maybe it's time to consider Google Chrome-esque updating for BTC clients?  There was already a game-breaking bug like this years ago with the integer overflow problem.  It really only improves the security of the network.

No cause we're too cool for testnet and elbow grease, gotta spend 16 hours a day on -dev talking about what we think of Satoshi Dice and how many whales fatass Gmaxwell could swallow whole.

The problem was with the old version of bitcoin. The mistake appears to have been not waiting for enough of the network to upgrade to the new version before enabling block sizes that were supposed to have been legal all this time.

Yes.  This will be the death of Bitcoin.  When a fully specified crypto currency comes along, it will leave Bitcoin behind.  "The implementation is the protocol specification" is wrong, and at Internet scale it is very wrong.

JGarzick warned us about this  ::). He literally suggested we leave the blocksize ALONE. BTW to all who defends the devs.Why do you want us to praise them when they do it right and now since they were total idiots you defend them? Have some consistency!

0.8 was a mistake. Fix it. Say you are sorry and were idiots. Bear the price nosedive and suck it up. Sleep it off.

- Lophie

That and the fact that we didnt even have an emergency plan for things like this, everyone just meeting in irc and it even took like 30mins for the first forum thread to show up. What a joke.

But then, i dont blame the devs, they are doing a great job, maybe we just need more people working on it?
I would have no problem paying like 1% of my Bitcoin earnings as donation to people working on Bitcoin.

Seriously now. Try and think things through before you post them. What difference does what I can or cannot do make in this discussion?

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.

We do (https://en.bitcoin.it/wiki/Contingency_plans). We just never considered this specific possibility, so we were limited to the fallback plan: Emergency rule change (https://en.bitcoin.it/wiki/Contingency_plans#Emergency_rule_change)

You're either a jackass braying by the side of the road or you're fixing the jackass's wagon. Which one are you?

Amen.

Except for the integer overflow bug and all those CVEs, sure.  You can't even say "this is the first prolifically visible major bug in 4 years" as the integer overflow bug holds that title.

Till now 12 blocks have passed. which is alot. Don't belittle the problem if I dined in mez grill 1 hours ago paying with Bitcoin. Then an hour later I double spent the coins with a v0.7 bitcoind. The transaction WILL NOT BE REVERSE ABLE as it got buried in a block and WILL be buried in two VERY soon, and I would SUCCESSFULLY pulled off double spent  without the need for 51% of the network to make it "possible"

Good luck promising the people this will never happen again and convincing the new comers that txs are irreversible. The mass follow adoption it is the few who follows over deep understanding and non-inflected belief in the system. You just lost the majority of the "normal" users today. Make no mistake about it, this IS the new nose dive of Bitcoin.

And how do you think this will look since we just passed the all time high..... expect news flashes... "It happened again" and "The future money that keeps on falling whenever it got high!".

Actually, to be more precise: this is a major bug rather than yet another opportunity for the disgusting circlejerk of patting each other on the back precisely because I said something.

I don't care and I don't want to hear stupid stories and even more stupid justification. This sort of incompetence is not acceptable for a half billion dollar thing.

If you earnestly believe this is the best you can do, leave.

Or keep your ideas to yourself and the forums. DONT SUBMIT (to the code base) THEM

ladies and gentlemen:

this is why the "bankers" make a LOT of money. they are EXTREMELY good at what they do and WAY more money is on the line every hour vs what bitcoin deals with in a year.

I don't disagree, but it's disappointing and discouraging that apparently this situation-- which is an important, obvious one!-- wasn't tested before the changes were rolled out. The best thing that can come from this is hopefully developers will be much more careful about these kinds of changes in the future.

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

Ya, bankers are experts.

Don't forget debt re-hypothication and lemon dancing debt between banks for interest. We are quite pissed off with what is happening but make no mistake sir. Banks are playing another league. This is the pro league.

That's not how it works. If you don't think it's acceptable, you either help fix the problem (something tells me you're not up to that) or YOU leave. If you think the devs are idiots, then I guess the biggest idiot is you, for investing in their work. Toodles.

Banks only play that league because they have the guns and the force of law. Recognizing that thugs are good at what they do doesn't mean that it has to be admired or emulated.

Won't work. All the 0.7 bitcoind node would have seen your previous transaction and would reject the new one. And some people here call the bitcoin devs idiots? They don't even know how the network works.

Smaller window, still possible. and BTW freshmen in software engineering knows that you shouldn't push a change without proper inspection and testing. that is what the testnet is for. My knowledge doesn't matter. Even if I was a monkey. What they did in 0.8 is IDIOCY.

And true engineers in computer science know that no amount of inspection and testing is enough when you want something perfect. Lookup "formal verification" and see for yourself that nobody gives any guarantee in the software industry because it would be so damn costly.

You do realize that the flaw was in 0.7 right.  Of course you tested this in v0.7 on testnet six months and posted a bug report right?  v0.7 has always had this flaw.  It wasn't detected or reported by anyone.

And the REASON it was neither detected nor reported is that some idiots THOUGHT it was a good idea to come up with a magic number and limit everything to 250k.

Just as SOMEONE thought it was a good idea to run Bitcoin with a plaintext wallet for 2 years.

The difference between the former and the latter is that I didn't say anything then, because back then nobody of any consequence gave two shits about your little bullshit project here.

And in fact, you probably to this day think running the wallet plaintext was ok.

Reality check. Seriously.

Then do something about it. Your business depends on this infrastructure so since you're so big you should be able to spare some investment into fixing the problems, not just identifying them.

You know what, talk is fucking cheap. You can bitch all day, or you can put some resources into pushing forward this little experiment of ours. You think the code sucks, or that there are painfully obvious flaws like unencrypted wallet files that go unaddressed for way too long? Fix it.

It's completely open.

Stop bitching, and fix it.

seems like a pretty clear-cut case of insufficient test coverage.

when testing code, it is especially important to test the corner cases. this sounds like one of those corners, even without looking at the details of the issue.

Yeah but apparently bitcoin millionaires cannot afford to get test suites made so it kind of sits there waiting for hard working coders and developers to find some spare time to work on such things.

-MarkM-

Spare me the circlejerking. If there's time to be flaming Bitcoin users because they're not using Bitcoin "correctly" then there is time to stfu, swallow cox and work the testnet to the bone.

I was here and there on IRC and since the storm started to settle and I started to really look at things the way they are without the nervousness.

I would like to apologize to you all. Especially the devs, They did good and saved the day. thank you. And I am sorry for calling you idiots. You rock. Keep it up  :)

So we can surmise that you didn't find this bug either because you were also busy talking?

Yes, you can surmise exactly that. IT IS MY JOB. I AM DOING MY JOB.

Guess who isn't, and guess what that makes them.

MPOE-PR: You seem to be under the mistaken impression that the hard fork was caused by something in 0.8. Not so. The block that 0.7 choked on was a valid block. The bug was lurking in 0.7 all along, and was merely uncovered by a 0.8 miner's block. You might as well blame the physician who taps your kneecap to check reflexes, for the bone cancer that he unexpectedly discovers there.

Maybe you should just be quiet until the grownups fix your toy.

Windows 8 hacked users forced to downgrade to Vista.   :P

Yeah, I know what you mean... your website have been down for weeks now :P

This was actually a good example of something a spec wouldn't help (though would still be good to have). The inconsistent behavior here arose out of 0.8 not faithfully implementing some implicit behavior in BDB. The behavior in question is not anywhere in the Bitcoin code itself, nor is it visible at the interface of BDB and Bitcoin.  If there were a spec it would make no mention of it— and yet the network would be broken all the same.

The key thing is that in a distributed consensus system the most important definition of right is "consistent", this is paramount to all other concerns. A spec is helpful to the extent that it makes it easier to achieve a bit identical consistent behavior in the validation of blocks across all nodes, but because the spec itself can't be executed a spec can never guarantee consistency, at least not in the real world. (well, unless the spec is code— which is effectively what we have, for worse or better)


(And seriously, shad0wbitz etc. Act like an adult here. Your comments are very uncool.)

I am not under any suck mistaken impression. Please read what's actually being said, it will help.

The presence of a 250k arbitrary block limit prevented the underlying problem of the db from being discovered until that moment when a perfect storm composed out of a db upgrade and the limit removal created two almost equal miner bases. This could have easily been avoided by simply not relying on magic numbers. It will ever be the case that whenever code contains arbitrary numbers based on arbitrary assumptions that code will break spectacularly.

MPOE-PR I am calling for Gavin to not get paid this month by the foundation, I would think your with me on that. Someone needs to take blame for this bug.

Maybe it wasn't the size of the block that was the problem.

https://bitcointalk.org/index.php?topic=152131.msg1614374#msg1614374 (https://bitcointalk.org/index.php?topic=152131.msg1614374#msg1614374)

Bitcoin is still beta software and untill recently no one got paid to do work on it.

MPOE-PR should stfu and contribute.

I bet they havent even donated to the bitcoin foundation  :P

Hurr Durr look how much money we made off free software.

That one requires more explanation for sure. What exactly?

I respectfully disagree.  

A real protocol specification would enable a whole ecosystem of alternative and interoperable implementations to appear in Scala, Java, Go, C, etc.  

These implementations would NOT use the same flawed 3rd party libraries and there would be a real diversity in Bitcoin land, instead of the monoculture of C++ with all of its "magic" and "folklore".

Once no individual implementation had large enough fraction of the hash rate, then such forks would NOT occur, instead, bugs in a given implementation would only affect some miners, merchants & users but the chain would be just fine.

Let us hope and pray that eventually there will be some effort ( funded perhaps by the Bitcoin Foundation ) to extract and publish such a spec from the C++ hairball formal enough for viable alternative implementations to appear and to interoperate.


Cheers ...

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.  

Never donated, never will donate. Things don't work like "here's a foundation we made, give us money".

For that matter, we didn't go to Taaki's stupidferences either.

Does this not argue for a diversity of implementations with different underlying 3rd party libraries ? Clearly it does. But this cannot happen until and unless there is actually a formal-enough spec to enable those to be written w/o ever "groking" all that C++ folklore, which is a moving target anyways ...

Notwithstanding that blocks of 1mb should have been accepted if valid, the limit prevented too many of them from being made.

If the limit had been removed at a reasonable time, those blocks would have occasionally been made, and the overall problem would have been much contained.

I would like to also point out that the alexkravets idea re specification is sound. The only way forward for the dev team, provided they wish to preserve a shred of dignity, is a. immediately start work on specification, which is the only priority, and release no further versions until such specification is complete and b. immediately start work on removing all magic numbers and assorted code smelliness from their UNreference implementation of crap, and not release any further version before they've released a clean one.

In that order.

I agree on that 100%.  It is inevitable that to survive Bitcoin will need to be move beyond a monoculture.  Right now all the clients share the same "DNA".  If there is a fatal genetic flaw in it then the network will not survive.   This time the "landmine" was accidental, next time it may be planted.

Whoa... All of this... Agreement...

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.

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

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 ?

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

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

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-

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?

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-

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.

With all due respect, MPOE, i do realize i am a newbie here, but my conscience forces me to make two observations of fact, and one suggestion.

Fact 1: The developers are NOT idiots. If they were, you and 80,000 other's would not be so engrossed in the going's on here.

Fact 2: You do have some valid points, but they are overshadowed by your lack of constructive criticism and insistence on personal character attacks on the developers intelligence. They are human! What they have accomplished should be praised.

One suggestion: from experience, i have learned that if you're smart enough to identify a problem, then your'e smart enough to identify at least ONE possible solution--not necessarily, THE solution, but A solution. And depending upon your experience, understanding of the problem domain and ability to organize effectively, you actually have the responsibility to move the initiative forward. leadership is not born into someone, or granted by top-down organizations--where everyone fits nicely in a box on some org-chart hanging on the wall--but simply belongs to she/he who is running the fastest. so my suggestion would be to let your frustration and passion turn into something positive. put together some testing framework suggestions, work with developers to setup qa and staging environments, write detailed explanations of required unit tests and work with developers to push those changes..whatever it takes to realize your vision! I'ld wager that if you took up such an initiative with the same spirit you carry on this petty attack, you would be a significant part of what is sure to be the coming bitcoin revolution we all know is inevitable at some point. united, that time is now. divided, forget it!

Shaman

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.

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

Sez MP:

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! :)

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

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

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.

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.

MPOE-PR: Please do think from what I posted above that I defend the decision to forcibly accept the 0.7 fork and abandon the 0.8 fork, in violation of the bitcoin protocol's founding principle that greater hashing power always wins a dispute. Nobody asked me, of course, since I am neither developer nor mining pool manager. But as I see it, the final decision had two strong drawbacks and one weak upside.

The first strong drawback is that the decision forced a patch on clean efficient code (0.8 ) to conform to buggy slow code (0.7). In my experience this is never a good idea over the long pull.

Second, the decision burned up developers' political influence. A handful of developers used their deservedly high community respect to force a decision on the 0.8 miners. So be it. But the next emergency will see developer influence greatly reduced in consequence.

The weak upside? The decision prevented thousands of 0.7 users suffering crashes as their wallets choked on the offending block. This would have forced users around the world to stop dithering and upgrade to 0.8 immediately. So? What would have been wrong with that?

suffice it to say there are hella layering violations in bitcoind and that is *bad* for bugs. can't really blame the devs tho, unless they helped write the original client from whence they inherited said issues.

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

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.

It was never a founding principal for greater hashing power to resolve hard forks.  Hard forks by definition can't EVER be resolved by hashing power.  If a single node remains on an incompatible fork it exists as a parallel implementation of Bitcoin.  Creating a precedent for using hashing power to fork the network is horribly dangerous and will lead to intentionally putting bugs into the codebase to force a fork for profit.


You are completely uninformed.  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.

The rational for rolling back to v0.7 was to prevent massive chaos, and loss of confidence and scammers and fraudsters looted the users of running older nodes.  Nobody is saying we will remain on BDB forever but the transistion can be better managed.

A v0.81 can be released which uses the new db format but prevents incompatible blocks.  older version users can be strongly encouraged to upgrade to the new version and warned of potential risks in staying with incompatible older version.  Where a vast super majority (not of miners but of ALL stakeholders, users, exchanges, merchants, service providers) are on the new platform a final critical warning can be released notifying users of older version they face significant risk of being forked away if they don't upgrade and then the incompatible block rules can be introduced.

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?

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.

Not going to happen within Bitcoin.  If we want such a thing, we are going to have to create it, and it is not Bitcoin.

Nope, not going to happen in Bitcoin.  And that will be its downfall.  The well specified crypto currency will have long term advantages that could well ensure it wins in the market, despite Bitcoin's first mover advantage.

There are many examples of protocols which only became specified after an implementation as in widespread use.  Look at HTTP, look at ssh, look at OpenPGP.  These all have organic ecosystems of implementations, and were all specified after an implementation went into widespread use.  It is simply part of the maturation process.  Crypto currency is no different.  Lacking a spec actually prevents the "organic" nature you speak of, the same way that any other single-implementation unspecified "protocol" does.

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


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.


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


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,


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.


As it happens, nobody asked them.

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.

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.

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.

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?

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.


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.

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.

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.

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

Well, our current bitcoin-world has also their "bankers", but they are called "miners".  ;D

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

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

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-

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.

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

This issue has already been discussed, and consensus has already been reached (https://bitcointalk.org/index.php?topic=140233.msg1503470#msg1503470).


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.

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 (https://bitcointalk.org/index.php?topic=152208.msg1615346).

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

Take it to the BDB forums!

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

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

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.

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

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

If core developers are firm in this, i.e. their refusal to even entertain having a spec extracted from C++ warts and all, then we'll just have to live with sadness for a while ... until somebody like Ripple comes along and "does it right" ... we'll see how this goes ...

You are wrong. Devs'/devzombs' first reaction was that "BDB bug" because a. they are idiots and b. they think their shit doesn't stink.

Fact of the matter is, they just failed to configure the BDB. Because a.

Nice trying to hide behind the Jesus of your faith, but it won't wash.

And to add to #114 above, seems OKpay got swindled for 10k or so too.

How much money do you expect people to contribute to the "propping dev arrogance" fund? The unencrypted wallet cost millions. This thing costs however much. How much more is needed? How long are we going to hear "it's not our fault" and "Satoshi did it"?

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.

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

smtp

As far I've read (which includes this whole thread of course), consensus is emerging that the devs are doing a good to very good job overall. You are the only one calling them idiots in this thread, which is wrong, insensitive, and counter-productive. Most of your comments let me think you have no idea what quality management is in software engineering, and what "0 defect" means in this field. You might wonder why Amazon cloud can be unreachable during a whole, why Gmail can lose mails and be unable to restore them from backups, and why NASA shuttles crash.
I would advise you to stop calling people names because they are not delivering that free unicorn to you.

I would say you grossly overestimate the importance of some irrelevant foundation thingee. It's a case of Rome, Alabama talking itself into the "center of Christian faith".


Then you need to learn to read.

And re "heroics": there were no heroics involved here. The in extremis forcing of a downgrade is not heroic. People doing it are not cool.

It is idiocy, and the people doing it were idiots. Yes, they had no choice. Guess why they had no choice, and guess who puts themselves in the situation of having no choice.

Let me make this perfectly clear: the current hard fork is the death of Bitcoin unless the consensus reached here (ie, no more bitcoin client releases until spec, first release code-cleaning release) is implemented exactly.

This is not up for discussion, it is a fact.

And did you ever pay these independant devs for fixing shit for you for free?
Are they your wage slaves so you can demand that they do work for you or anyone else?
Have you ever discussed your issues with the development team in a calm and adult manner?
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?
Reality is you need the devs and you have absolutely nothing to say about what they do or how they do it. That is why you come crying here on the forum to get souls for your case. Boehoe. You are turning a technical thing into a political thing. Which is quite ironic because it is exactly what you accuse the developers of. I wonder why you so readily wield tools that you want to deny others.

In any case, if you don't like bitcoin go make your own. Bitcoin does not need you. But you propably won't because you are enjoying the benefits that are made possible by the bitcoin development team and the community that emerged around the system?

As usual a lot of dumb arrogant shit packaged in expensive words.
 ::)

Or you need to learn to read. I'm not sure that sentence brings us anywhere.
Same thing with "This is not up for discussion, it is a fact". This sentence only serves to prove your lack of open-mindedness.

Why are you speaking about the word "heroics" ? Did I mention it ?
I still disagree with you about the devs being idiots, this mistake was human, and mistakes DO happen, whatever the amount of ressources and good will you throw at development.

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)

I endorse writing a specification over new client releases.

MPOE-PR:

Irrespective of them being idiots or not, the bitcoin devs owe nothing to you.

Don't look a gift horse in the mouth. If you feel strongly that something needs to be done urgently, then start a Kickstarter campaign to hire a team of "real" developers to clean up the code and write a specification.

This is like saying Garry Kasparov is a shitty chess player. Then saying "By the way, I don't know how to play chess."

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


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


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.

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.

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.


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?


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


Fuck you.

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

But who is the bigger idiot?
The idiot making the flawed software or the idiot trusting the software?
LOL.

You are too stupid to be here. Please leave.


See above.


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

this is fixable though

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

+1

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)

It is only fixable if fixed.

I'm amazed at your ability to spit on the very people that did the job and brought you a piece of software you are relying on daily.
In essence, your reasoning seems to be the following :
- Dev job does not make you rich
- Thus, devs are lower-class humans, slaves
- You are in the political class
- Thus, you are a higher-class human
- From this you deduce that devs are entitled to free work for you, and if that free work is not perfect, you are entitled to call them names.

Until this last post of yours I hadn't understood you have the brain level of a 5 year old child. No no no sorry, I know a lot of 5 year old children with higher moral grounds. More accurately, you are at the level of a 12 to 18 months baby, a period of life at which you still think other people should definitely satisify all your needs just because they are "the outside" of your persona.

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

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.


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.


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.

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

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.

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.

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.

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.

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

That, at least, is a reasonable wish.

No, it would not.

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

Yeah, that's really persuasive.

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

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.

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

See post #87 (https://bitcointalk.org/index.php?topic=152027.msg1614847#msg1614847) earlier.


You are very, very confused about how this "onus" thing works. Perhaps you'd be best served by following the advice given to usagi (https://bitcointalk.org/index.php?topic=141503.msg1607217#msg1607217).

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


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

Fair enough.

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:


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.

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.

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

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.

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.

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


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

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.

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.

Two points:

1. Even if the OP is making a valid point, the way in which shim (http://www.urbandictionary.com/define.php?term=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 (https://bitcointalk.org/index.php?topic=152498.0)

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.

I'm not too concerned with that muppet's posturing. In general it's enough to point out his shady past (https://bitcointalk.org/index.php?topic=101902.msg1132132#msg1132132) and he goes away (at least for a little bit).


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.


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?

Shit.  You all beat me to it.

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.

Did you know that Chinese weights (before metric) were based on a hexadecimal system (http://en.wikipedia.org/wiki/Suanpan#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.

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 (http://en.wikipedia.org/wiki/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.

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.

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 (https://bitcointalk.org/index.php?topic=152208.0)

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

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-

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

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.

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

-MarkM-

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.

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.

(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 (http://en.wikipedia.org/wiki/Consensus_%28computer_science%29)).

We fully support the writing of specifications and documentation, which you can see here
    https://en.bitcoin.it/wiki/Protocol_specification (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 (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 (http://en.wikipedia.org/wiki/Heterogeneous_computing)) 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.

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-

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.

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://bitcointalk.org/index.php?topic=134318.msg1621672#msg1621672

Cheers ...

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

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

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.

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.

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

Attacking me doesn't make idiots less idiotic.

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

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.

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 (https://bitcointalk.org/index.php?topic=134318.msg1615241#msg1615241) if you are interested.

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.