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-
Topic: In re Bitcoin Devs are idiots - page 2. (Read 25449 times)
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://bitcointalksearch.org/topic/no-recompilation-fix-for-the-lock-table-is-out-of-available-lock-entries-152208
http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html
The max lock limit was hit ... do some reading on BDB tutorial.
https://bitcointalksearch.org/topic/no-recompilation-fix-for-the-lock-table-is-out-of-available-lock-entries-152208
http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html
Right now there's no question that they deserve to be called idiots. What's happening now was easily preventable and shouldn't have ever happened under any circumstances.
It's actually fucking amazing that this is first MAJOR bug in 4 years.Testing and avoiding bugs is important, but it is just as important to handle situations like this when they occur, and I think this one was handled very well. A hard fork with two parallel blockchains going on forever was avoided. Because bugs will happen. No amount of testing or algorithm proving can eliminate all bugs.
Anyway, no need to insult people here from the very beginning of the thread - but this seems also a characteristic of this bitcoin forum(s) that this is tolerated. :-(
I have this user on ignore. I am not alone, as you can see from the piss yellow background of his ignore link. Nothing even remotely clueful, interesting or constructive comes from his keyboard. However crazy that guy appears to be, he's extremely smart. But I sometimes think his religious and tonal rants are just trolling.
Did you know that Chinese weights (before metric) were based on a hexadecimal system? I wonder how many merchants are still used to that system.
None of the Bitcoin developers are "idiots". And they all have their own interests. Luke just seems to be a bit more open about his, and takes a lot of crap for it.
(Snip)
2. The lack of significant alternative implementations, lack of technical specifications, the developers' show of disdain for formal standards, and the apathy of the Bitcoin Foundation towards better process
is a significant threat to the growth of Bitcoin.
(Snip)
It appears that some of developers' disdain for formalization of the protocol is rooted in self-interest to keep the heart of Bitcoin accessible to them exclusively. This may be related to several things - from elitist, self-centered power trips (some of them are cocky to say the least) to emotional attachment to their "child" and consequential need to protect the child from the chaos of inevitable promiscuity of the adulthood. Either way, it's pathological. Even if they are right in that Bitcoin is too young to be let in the wild for anyone to play with, they ought to work on helping it develop and grow healthy, rather than possesively protect it by letting it degenerate into an ever-worsening hairball of poorly documented details and unexpected consequences.2. The lack of significant alternative implementations, lack of technical specifications, the developers' show of disdain for formal standards, and the apathy of the Bitcoin Foundation towards better process
is a significant threat to the growth of Bitcoin.
(Snip)
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.
Holy fuck! I'm talking WAY, WAY, WAY, WAY beyond my area of expertise. I hope that I don't get humiliated by like 90 guys that actually understand what I'm talking about.
Shit. You all beat me to it.
To the OP, while misterbigg cannot resist revealing his hypocritical nature
I'm not too concerned with that muppet's posturing. In general it's enough to point out his shady past and he goes away (at least for a little bit).
This thread would be so much more productive if you could act in a more civilized manner.
Understand something here: I am not interested in the problems of coding. It's not what we do, MPEx has its plate full (very, very full) just trying to bring some sense into Bitcoin finance. We can't be doing everything nor do we wish to do everything. The idea is that other people, blessed with the relatively much more common skillset of computer programming, keep an eye on things and at least grosso modo keep nonsense to a low roar.
By the time I have to talk about Bitcoin coding issues the ball has been dropped so far by so many people so many times it's not even funny anymore. So let's have a simple fix: PEOPLE QUIT BEING IDIOTS and I'll be happy to never have to post in this subsection of the forum ever again.
And conversely, when you see me talking here you know SHTF. Badly so.
Now go ahead have your useful discussion, discern important steps moving forward and make progress in improving Bitcoin.
That being said, thank you for being persistent on a few important points.
You're welcome. Hopefully it's the last time the world's greatest currency has to be thus helped by idiots like me. You know?
...you seem to have several...
I second that. I would love to put MPOE-PR on ignore but unfortunately mixed in with the vitriol are valid points. Bitcoin is not served by having a representative of a Bitcoin business act like an immature jerk.
Two points:
1. Even if the OP is making a valid point, the way in which shim resorts to insults and name calling cheapens the discussion and only serves to further soil their reputation (if that's even possible).
2. The lack of significant alternative implementations, lack of technical specifications, the developers' show of disdain for formal standards, and the apathy of the Bitcoin Foundation towards better process is a significant threat to the growth of Bitcoin.
I've put together a description of the development of the Gnutella protocol as an example of what Bitcoin development could and should be, here:
What Bitcoin Could Learn From Gnutella
1. Even if the OP is making a valid point, the way in which shim resorts to insults and name calling cheapens the discussion and only serves to further soil their reputation (if that's even possible).
2. The lack of significant alternative implementations, lack of technical specifications, the developers' show of disdain for formal standards, and the apathy of the Bitcoin Foundation towards better process is a significant threat to the growth of Bitcoin.
I've put together a description of the development of the Gnutella protocol as an example of what Bitcoin development could and should be, here:
What Bitcoin Could Learn From Gnutella
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.
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!!!!!!
I am not pulling out I am just pissed off Bitcoin will suffer greatly because the DEVS MADE A MISTAKE! you dont freaking PUSH such things without proper testing. EVER HEARD OF TESTNET!!!!!!
Maybe we should have a form of crowd funding to keep them interested. We do need competent people working on this in a decentralized manner. I'm not saying they are not. I'm saying lets give them something thats a bit of an incentive.
As far as I am concerned they did a great job and need praise. They worked together and put aside their differences. That is something I enjoyed hearing about.
I'm amazed to see this get this far and as my thoughts on humanity go, well they're less than impressive. My only concern is when bitcoin gets really big and greed begins to corrupt.
As for calling Dev idiots is quite harsh, maybe more foolish would be a better word.
Incredible how stupid self-centered people can be, seriously now.
Careful with this. You are being the very same thing, claiming "to know the one and only truth":This is not how the world works, currently (and past about 1800 or so). This is not how the world should work, either.
But your later proposals seem to be quite constructive...Only your "idiot-anger" is obscuring the view on things maybe sometimes. Nonetheless I agree with you, that this incident should be used as an opportunity to rethink/improve the "development process".
It is also a huge issue that those suggesting we need the protocol spec are brushed off with the "you don't get it" nonsense by elitist devs.
Bits and pieces, some expired, are scattered around Wiki. Is that the best we can do?
@MP: would you be willing to lead the effort of formulating the current protocol spec?
You really, really don't get it. We can't have a protocol spec becasue the existing client has a whole bunch of unspecified and unintended behaviour that no-one knows about, and any divergence from that behaviour by any major implementation will result in fiascos like this one. This problem could just as easily have been caused by a independent third-party implementation of the client. The developers have been finding and documenting all the corner cases as thoroughly as possible, but some of them are - like this one - really subtle and hard to spot. I'm not sure anyone's managed to fully work out the circumstances under which 0.7 will fail to accept a block due to this bug.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?
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. 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.
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.
I am willing to donate bitcoins, and to help test changes by compiling and running a node on testnet.
To quote here:
Quote
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.
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.
Split bitcoind and bitcoin-Qt into completely independent components. Bitcoind stores a local copy of the blockchain, connects to the p2p network, relays blocks and transactions, and serves blockchain information to clients only. Bitcoin-Qt is a client application only that connects to a trusted bitcoind node. The default installation would install them in a pair, with bitcoind running all the time as a unix daemon (Windows service) and Bitcoin-Qt started on demand. Only one instance of bitcoind is needed on a typical home LAN, all the clients can just connect to it.
Once this is done Bitcoin-Qt can just focus on being the best client it can be, while bitcoind can focus on the blockchain and p2p network. It should also be extended to serve MultiBit, Armory and Electrum. Once the reference implementation is fully refactored into a client/server application it should make any attempt to develop an alternate implementation easier.
I don't have enough programming skill to do this, but I'd donate to anyone who does.
This would definitely be the first step out of the current insanity and finally bring some layering into the code base client UI === depends on ==> bitcoind but zero backward pointing dependencies.
This would be the first step on the long journey to the promised land of the BPS (Bitcoin Protocol Specification)
The position of MPEx is that the current dev team should release no further versions until a. Bitcoin is specified and b. The codebase is cleaned up.
Is MPEx going to do anything to help make this happen other than talk about it?See post #87 earlier.
The onus is on you to show that all of bitcoins core code can easily be compiled into human language.
You are very, very confused about how this "onus" thing works. Perhaps you'd be best served by following the advice given to usagi.
For that matter, the point you only seem to have grasped in #149 had in fact been my position since about #71. Try reading what I say twice before talking to me (or if you already are reading it twice, read it thrice from now on).
No, you are just very very confused about the position you take in this matter.
What i make of your point is that you want some specification. What i call you out on is your critique directed at grau's idea that the algorithm may not be easily specified at all. The normal situation is that not every problem can be specified easily. So please demonstrate why the bitcoin software can. The burden is yours.
*especially* Peter Vessenes (last one on the list) because he's also in charge of CoinLab and its future big wholesale deals with Wall Street hedge funds investing into bitcoin through Coinlab will live or die based on convincing them that Bitcoin can grow up and become an actual internet standard (i.e. BSP 1.0) and not just remain a C++ hairball with attendants.
*falls over laughing*
Yeah dood, totally. Once Bitcoin is specced properly Wall Street will move to Silicon Valley Bank. I can see it in mobodick's onus.
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.
I am willing to donate bitcoins, and to help test changes by compiling and running a node on testnet.
To quote here:
Quote
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.
See post #87 earlier.
Fair enough.
There Shalt Be a Spec. That's all there is to it.
The only question is what kind of pressure needs to be brought to bare and where to expedite that process.
Incorrect. The only question is who is willing to do it, and who is willing to support them.The only question is what kind of pressure needs to be brought to bare and where to expedite that process.
I am willing to donate bitcoins, and to help test changes by compiling and running a node on testnet.
The position of MPEx is that the current dev team should release no further versions until a. Bitcoin is specified and b. The codebase is cleaned up.
Is MPEx going to do anything to help make this happen other than talk about it?See post #87 earlier.
The onus is on you to show that all of bitcoins core code can easily be compiled into human language.
You are very, very confused about how this "onus" thing works. Perhaps you'd be best served by following the advice given to usagi.
For that matter, the point you only seem to have grasped in #149 had in fact been my position since about #71. Try reading what I say twice before talking to me (or if you already are reading it twice, read it thrice from now on).
*especially* Peter Vessenes (last one on the list) because he's also in charge of CoinLab and its future big wholesale deals with Wall Street hedge funds investing into bitcoin through Coinlab will live or die based on convincing them that Bitcoin can grow up and become an actual internet standard (i.e. BSP 1.0) and not just remain a C++ hairball with attendants.
*falls over laughing*
Yeah dood, totally. Once Bitcoin is specced properly Wall Street will move to Silicon Valley Bank. I can see it in mobodick's onus.
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 ...
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 ...
Jump to: