Criticizing 0.8 for not emulating an unknown bug (let alone that it was in 3rd-party software) is itself FUD.
For the last time IT WAS NOT A BUG! http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html0.8 levelDB as implemented by Mike Hearn (who also propagated the "just bump you block limit meme with the miners) did not faithfully emulate BDB, which it was minimally required to do. Come on, such obscure limit was not known by anyone in Bitcoin-world up until it blew yesterday. You may claim it's not a bug on BDB side*, what's arguable, but it is definitely a bug on bitcoin implementation side. Everybody should be able to handle blocks up until 1Mb. That was the general agreement, the protocol spec if you will. The particular implementation of Satoshi client <= 0.7 was not capable of following such protocol specification as it should. 0.8 onward was. If anything, 0.8 is the "correct version". Bringing everybody back to 0.7 was an "emergency plan" since pushing everybody to 0.8 was believed to be much harder to accomplish (and likely truly would be). * And bug or not, the fact that nobody here even knew about it just shows how much we cannot rely on BDB - not a single person among all the brilliant minds on the core dev team understands fully how this thing works (and neither did Satoshi) . Moving out of BDB is certainly a desirable thing. Now with this even more crippling block size limit, it's pretty much urgent. How can it be a bug if it is a clearly defined behaviour in the documentation of the s/ware dependency? The fact that the devs (or anyone) seems to have never read the documentation of the standard dependencies is more the worry, in my opinion. |
|
|
|
Some people have massive and expensive infrastructure built around pre-0.8 bitcoind, scripts, supporting code, etc. 0.8 levelDB bitcoin needs to be backwardly compatible for better or worse, for now and the foreseeable future.
Everyone can't go on being bug compatible with 0.7 forever just because some people may have painted themselves into a corner. And why 0.7? I'm sure the same argument applied to 0.3 too. Pre-0.8 does NOT have a bug, it was 0.8 that was not backwardly compatible ... do some reading. |
|
|
|
"I think what will happen now is going to be a good test of the community," says Hearn. "We have to get as many people upgraded to 0.8 as possible, as fast as possible, and then go through a deliberate hard fork much earlier than we had planned." I wish Mike Hearn wasn't out there saying stuff like this in the press. This is purely his opinion. People have this thing called 'freedom of expression' we all enjoy. Ooops!!  Also if we don't allow people to defend themselves we are like denying some of their human rights.  Bitcoin is much about freedom, we should never forget this.  Disagreeing with another one's opinion is perfectly cool though  As long as we stay away from Ad Hominem and such  Yes, he is free to say whatever he likes ... but since he is one of main devs. people listen to him ... even if he is a loose canon, imho  |
|
|
|
Um, is it just me or are they really SUPPORTING the network with the fees they are paying on transactions? In 16 - 20 years this is going to be our bread and butter tx fees will likely hit 25+ bitcoins per block within that time frame if my math is even close to correct. (not showing my math here, because it is filled with a lot of conjecture and guesstimation and I really don't feel like having it picked apart.) If we think competition for blocks is harsh now. Just wait until we are looking at 10-100k tx per block and fees that are 5x+ what the generated coins are, also consider that bitcoins will likely be in the $100-$1500 range by then (likely higher) as long as the network stays strong. The adoption is there now. We just need to keep stability in the network. We need to get this shit figured out with larger blocks, because eventually with fees being the major source of income, no one will want to LIMIT block size.
Miners will certainly want to limit free transactions, since they cost money to store. There is also the argument that with unlimited block size we will have a tragedy of the commons situation where everyone uses minimal fees. If there is a limit, transactors will compete for the available slots, driving up fees. It's not as simple as you seem to think. The fees and block limits discussion is long past due, they are intricately connected. Tighter limits on blocks will lead to more competition for scare resources and thus higher bids (fees) paid to process transactions. User pays. Expanding block limits to ridiculous sizes will ensure that blockchain maintenance becomes a rich man's only game .. i.e. only Google, Facebook and Citigroup can afford to maintain full blockchains. Conversely it will keep fees relatively lower for longer .... decisions, decisions. But better we are kept aware of the impending changes before being rushed into them by an employee of Google. there also exists the "amicable separation" solution and to split into a little persons chain BDB and big guys chain levelDB? |
|
|
|
No, you misunderstand the problem and in the process spreading FUD. 0.8 LevelDB was required to emulate BDB behaviour and it didn't.
Rushing everyone onto 0.8 is asking for problems.
Deepbit has been prudent and a pillar of defending the blockchain and you are pressuring them to do what exactly?
Criticizing 0.8 for not emulating an unknown bug (let alone that it was in 3rd-party software) is itself FUD. For the last time IT WAS NOT A BUG! http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html0.8 levelDB as implemented by Mike Hearn (who also propagated the "just bump you block limit meme with the miners) did not faithfully emulate BDB, which it was minimally required to do. Like I said, you do not fully understand the problem so are not qualified to comment any further. |
|
|
|
"I think what will happen now is going to be a good test of the community," says Hearn. "We have to get as many people upgraded to 0.8 as possible, as fast as possible, and then go through a deliberate hard fork much earlier than we had planned." I wish Mike Hearn wasn't out there saying stuff like this in the press. This is purely his opinion. Colour me skeptical, but we need to remember that Mike H. put in a major effort to upgrade reference client to the levelDB database, the database widely used by his employer Google. Mike is not an independent (non-conflicted) actor when it comes to wishing everyone would just upgrade to "his" software, 0.8 levelDB. Some people have massive and expensive infrastructure built around pre-0.8 bitcoind, scripts, supporting code, etc. 0.8 levelDB bitcoin needs to be backwardly compatible for better or worse, for now and the foreseeable future. |
|
|
|
Watching.
Seems BDB's MAX_LOCK needs to be taken into account also, for backward compatibility.
Yes. All miners should be migrating to v0.8 as soon as possible (while maintaining default limits), so that the above is no longer a factor. General question. Is Deepbit too conservative for its own good? They are refusing to upgrade from version 0.3. Deepbit, please prove me wrong! No, you misunderstand the problem and in the process spreading FUD. 0.8 LevelDB was required to emulate BDB behaviour and it didn't. Rushing everyone onto 0.8 is asking for problems. Deepbit has been prudent and a pillar of defending the blockchain and you are pressuring them to do what exactly? |
|
|
|
Lol ^ they said the same thing about IPv4 when it was invented, who would need more than 4,294,967,296 IP addresses? Time for "Bitcoin-IPv6" databases, which 0.8 already uses.
In 0.8 BerkeleyDB was replaced with LevelDB. ^ exactly my point but levelDB implementation didn't faithfully reproduce BDB behaviour, which is what it was minimally asked to do ... and that is what caused the fork. 0.7 and BDB is still king ... for now, for better or worse, for richer or poorer, etc ... bitcoiners are wedded to it. |
|
|
|
Sweet summary ... , levity is always useful at times like these too ... after all it's just bitcoin, who needs em? |
|
|
|
Here's the Berkeley DB tutorial for anyone who might want to do some reading on sizing your database correctly and lock limits. http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.htmlThe maximum number of locks required by an application cannot be easily estimated. It is possible to calculate a maximum number of locks by multiplying the maximum number of lockers, times the maximum number of lock objects, times two (two for the two possible lock modes for each object, read and write). However, this is a pessimal value, and real applications are unlikely to actually need that many locks. Reviewing the Lock subsystem statistics is the best way to determine this value. |
|
|
|
I'm glad they addressed the issues quickly and in a professional manner though.
Doesn't look resolved to me. The limit is still there. OK you can configure 0.8 to reject troublesome blocks to make it same as 0.7. But the limit is still there. So I guess the devs will have to wait till 0.7 miners are, say, 1% of the network before releasing a v0.8.1 without the limit. But then the 0.8 miners are being limited by configuration right now. So again the 0.8.1 miners will need to have some sort of logic that makes them wait till they are a large majority, before accepting larger blocks. Pre-0.8 nodes can up their limit voluntarily via Berkeley DB config file settings, so there does not have to be this rush to upgrade, or rush for the exits .... There just needs to be a consensus (and enforcement) on what those limits need to be set at instead of this "default" behaviour (implicit network rule). Edit: http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.htmlThis link is for you Mike H. ^^ |
|
|
|
Good to see BitPay is taking care of concerns.
Are your systems using version 0.7 or 0.8 bitcoind backends?
we were on 0.7 bitcoind (and still are) Thanks Tony ... you and your team should probably know about this if using 0.7 |
|
|
|
|
Good to see BitPay is taking care of concerns.
Are your systems using version 0.7 or 0.8 bitcoind backends?
|
|
|
|
|
Watching.
Seems BDB's MAX_LOCK needs to be taken into account also, for backward compatibility.
|
|
|
|
...
Please don't!You will only make the things worse. Changing this setting is useless if the majority doesn't apply it, and you can even end up on a blockchain fork by yourself. Don't you think it is about time the "majority" decided what is best for the blockchain? The reference implementation allows it. Upgrading via a hard fork is not the answer. The block limit needs to be decided by a consensus of the mining power and it is high time this issue was sorted out ... unless SatoshiDICE wants to do the right thing. |
|
|
|
Your concerns have been duely noted, Atlas. However, you have little knowledge of what is really going on here, so I consider your perspectives discounted. Just don't upgrade yourself, and if others do and are harmed by it, you will be able to say "I told you so" because you have. I haven't followed the trials and tribulations of Atlas. But, yeah, you can't go wrong by promoting caution in upgrading Bitcoin. Personally, I am glad that the developers and the mining community decided to do the right thing, and to scuttle the upgrade fork. Pushing ahead with 0.8.0 would have called their judgment into question in my opinion. It is not over yet ... they are going to be pushing extremely hard to rush everyone onto 0.8 ASAP ... https://bitcointalk.org/index.php?topic=152030.msg1615347#msg1615347 |
|
|
|
Semantics ... in essence he was absolutely correct
Your grasping at straws. He was very clear about what he feared: that the different storage format would somehow corrupt the data it stored. This is exactly the opposite that happened: the previous storage format had a flaw and couldn't store data everyone supposed was valid. His contention was that the database upgrade would cause a hard fork, which is exactly what just happened. No straws needed to see that. |
|
|
|
Nothing to do with what happened here. The problem is that there is a bug in 0.7 that isn't present in 0.8: 0.7 refuses good data, 0.8 doesn't put bad data in the blockchain... Semantics ... in essence he was absolutely correct and got abused for suggesting it ... maybe he is an asshole but so are some of the devs imho, they are just better at hiding it. |
|
|
|
What is the best place to buy gold? I checked out Coinabul but the prices seem a little steep. Also, I would prefer a seller in EU.
I figured this is the place to ask, and it could be helpful for newbies who are following this thread.
Heard good things about these guys, think they are based in Europe (germany?) http://bitcoincommodities.com/index.php |
|
|
|
|
Show Posts
