Two more problems I have with that announcment, Miners/mining pool operators
And if you are creating blocks and cannot upgrade to version 0.8.1 for some reason, you should not set_lk_max_locks in a DB_CONFIG file until May 15th; if you increase locks before then you run the risk of creating or building on blocks incompatible with the rest of the network. Correct me if I'm wrong, but this is not exactly true, is it ? If enough miners decide to start mining an alt blockchain now that is only compatible with the 0.8's there will just be another reorg on May 15 and their chain will become the main one. They actually stand to benefit from this. Why this is necessary
A bug caused a temporary block chain fork on 11 March, 2013. After investigating that bug, we determined that the bug can happen even if the entire network was still running old versions of Bitcoin-Qt/bitcoind. How ? 0.7 can in fact create blocks that 0.7 will reject. By increasing the number of locks, 0.7 will create the very blocks other 0.7 clients would reject. Both statements are therefore true. |
|
|
|
32 days, 6 hours and 11 minutes I need to get a girlfriend  . |
|
|
|
I don't think this has anything to do with legality.
This is about regulation: The bureaucrats weapon of choice.
You act as if this is a bad thing. |
|
|
|
2. Shouldn't the last situation have produced only normal number of unconfirmed transactions? There were two chains, but since there was mining going on in both of them, transactions should have been confirmed in both chains?
The two chains split the hashrate, making blocktime longer. The 0.7 chain was at ~15% of total hashrate and so would have had ~7 times the regular amount of unconfirmed transactions. |
|
|
|
|
2103 should be 2013.
I won't be personally donating, but it is encouraging to see even minority views accepting donations in Bitcoin.
|
|
|
|
Artificial selection can have the same effect as natural selection. Most of our current breeds of dogs or cats came from artificial selection. If people use the AI software that is better than other AI software, this is evolution.
Which "AI software"? My premise is that there doesn't exist any yet which deserves that name. Also it seems to me that this kind of "artifical selection" is detrimental. If the poodle is to be released into the wild again, it's less likely to survive than the wolf. Any software which has an internal state that can differentiate its actions (when compared to a copy of such software with a different state) and modify its own state is a "living" software. "Living" software differ from inert software in that their purpose can be tailored to the user, in this case a human. Although most current "living" software does not have the capability to reproduce or mutate on its own accord, they can do so with the assistance of humans. For example, imagine an open-source speech-to-text software that can be trained for a specific person. If this software is more useful to humans that previous speech-to-text software, it will displace that software. In doing so, it attracts developers, who are humans that assist its mutation, and users, who are humans that assist its reproduction. Different copies of this software will naturally have different internal states. If some humans modify ("mutate") the software through forking it, and the mutation is favourable (the software becomes more useful to humans), there would have been some limited evolution through artificial selection. Fast-forward 10 years into the future, and visualize the far descendents of this software. When compared to today's software, these descendents (which originally shared its codebase) are more useful to humans and more differentiated from each other. Although their specialization means that they use relatively few concepts of "intelligence", the software does not really need any more (and, indeed, software that becomes excessively intelligent is simply bloated and will be artificially selected against). This software is neither reproducing on its own accord or actively attempting to preserve or improve itself beyond a basic level of machine learning. Even so, it has become more intelligent, effectively undergoing evolution. Although it is an eventual process, thanks to improved research in artificial intelligence, eventually software will acquire multiple facets of intelligence, including certain traits that resemble "self-preservation". Speculating the future is difficult, but a cursory guess indicates that these traits and behaviours may include marketing one's species, maximizing income for one's developers, detecting and reporting one's own deficiencies, etc. |
|
|
|
Our intelligence comes from learning. Learning comes from motivation. Motivation comes from desire. Desire comes from instinct of survival and self-preservation. This instinct comes from evolution.
Machines do not have all of the latter. That's why the concept of "Artificial Intelligence" is questionable because machines do not have any intrinsic desire to learn anything. They never experienced evolutionary pressure and never had to go through natural selection. It's the instinct of self-preservation that would have to be programmed into them. Artificially. Fine, artificial self-preservation then. But I guess if it works at all, it would essentially have to be a chaos-theoretical system, and the consequences of such an experiment would be unpredictable.
Artificial selection can have the same effect as natural selection. Most of our current breeds of dogs or cats came from artificial selection. If people use the AI software that is better than other AI software, this is evolution. |
|
|
|
No. This is a myth. See this thread for a more in-depth explanation. Whilst it is true that Bitcoiners tend to reject the Keynesian school of economics, the world's dominant school has no reason to fear Bitcoin. Bitcoin does not eliminate the Federal Reserve; rather, it contemplates it. Many Bitcoin supporters see Bitcoin not a challenge to central banks, but rather a novel way of sending currency the central banks issue. Companies like Bitpay advocate for holding zero Bitcoin, and instead using it as a system to instantly send money from one hemisphere to another. The beauty of Bitcoin is that it can be used how one wishes. Many Bitcoin supporters identify with pro-Fed political factions, such as the Republicans. In fact, Bitcoiners represent a wide political spectrum; there are socialists, liberals, greens, libertarians, conservatives, and just about any other party represented. See this study to better reflect upon the diverse political beliefs of Bitcoiners. In conclusion, Bitcoin is apolitical. It is fantastical to assume that all Bitcoin users identify with Ron Paul or other anti-fiat factions. |
|
|
|
As far as I understood it, the forks were not very far apart (~60% of hashing power on the 0.8 fork) so probably Gavin's alert was published to the net before this could take effect. Anyways, I guess someone else who actually was online/awake at that time can say more to this. It took effect, but only on the 0.7 nodes that did not need to downgrade. This was because 0.8 nodes only noticed a shorter, also valid chain, which is not unusual as orphans happen often. 0.7 nodes noticed a longer but invalid chain and displayed the notice. |
|
|
|
Even if the problem hadn't been found during testing, if miners had gradually rolled out the change to 0.8 (with a built-in bigger block-size limit), then when the problem cropped up, as long as 51% of the mining power hadn't been on the new "big block 0.8 release", there would not have been a hard fork.
The problem that cropped up is a hard fork, so by definition it would have happened. It's clear now that a hard fork is unavoidable. The only question is when does it happen and who will lose out because of it. If only a few miners had been on "big block 0.8 release", they could have produced a block the rest of the world didn't understand. But, wouldn't the rest of the world continued on without that block? A single orphan block. I don't exactly consider this a "hard fork". Am I missing something, here? The problem was that 51% of the miners were running an essentially untested combination of software and blocksize. Without manual intervention, the fork that evolved would have continued forever. *This* is what I call a "hard fork". It's not that simple More than 51% of the miners were running 0.8. One single pool with a large block size created a valid block that all 0.8's accepted. All the 0.7 miners and users rejected it due to the lock table overflow. I don't believe this can happen again because >51% of miners are now on 0.7. Even if a solo 0.8 miner recreates a block that causes 0.7 to freak out on, it will find itself automatically orphaned. Last night slush's pool was running 0.8 with the large txn blacklisted in order to get back onto the 0.7 chain. That helped converge the chains but doesn't count towards the ongoing "> 51% on 0.7" goal - it would have accepted a "new" 0.7-breaker txn as valid and contributed to that fork. If no miners mined on 0.7, the users would not get any confirmations on their fork and would upgrade as soon as they noticed, without loss of money. The problem lies in how there were significant numbers of miners on older versions, and those would be exactly those that would be hard to reach and encourage to upgrade. |
|
|
|
The options I listed in my first post are still the only options. If you don't want to filter out SD transactions then the default "do nothing" option means that transactions will become very expensive, and small quantities of Bitcoin won't be spendable at all.
Not really. Just expensive enough so SD is not viable. Say, 0.03 or so. For a moderate quantity it's not expensive. For micropayments, BTC is never going to scale to global scale as to accommodate micropayments. It's simple math really... I don't think BTC is ready for fees so high. That's going to shut out a lot of commerce, not just SD. It's going to force the evolution that will need to happen sooner or later anyway. Ripple or whatever other overlay system is required for micropayments. Free transactions in the blockchain are not going to last too long. Exactly, and i just hope the devs are intelligent enough not to try to 'fix' that problem by making the blocksize much larger. At least not untill everyone really got 10x faster/bigger CPU/HD/Internet compared to today. Everyone should be able to run a full node through slow broadband internet (or Tor). I don't believe in full nodes anymore after the last chain split. It's clear that many people don't understand the responsibility involved with running a full node rather than an SPV or a FAN node. Full nodes need to be upgraded as soon as possible, or the network will break like it did yesterday. Just like mining is no longer a business one can get in with their GPU or CPU, I feel that full nodes should be moved out of the hands of the ignorant consumer and even the average merchant. I would prefer a Bitcoin client that offered the user 5 types of nodes: Supernodes, that run two or more full nodes to ensure consistency. Should be upgraded ASAP, and uses the most resources but also provides the most security. Full nodes, the current default for Bitcoin-QT. Should be upgraded ASAP. Uses a lot of resources for good security. FAN nodes, which are no yet implemented AFAIK. Can be left at an older version. Uses a lot of resources for good security, but not as good as a full node. SPV nodes, which download and verify only headers. Can be left at an older version. Light on resources for adequate security. Server nodes, which use a server to communicate transactions. Can be left at an older version. Very light on resources for acceptable security. |
|
|
|
This is not accurate.
There was, indeed, testing on the testnet with a full (1 MB) block. This was accepted by both the 0.7 and 0.8 versions. There is no concern here.
Slush's block should have produced the same valid block. However, the block was structured carefully as to expose a problem in 0.7 that was never discovered. Not only was this an extremely difficult problem to catch, but its finding would in fact not have been accelerated with a mixed testnet. The introduction of 0.8 into the equation would actually delay finding the bug, as it would mean less time spent testing edge cases on 0.7.
Source? @dree12: Do you mean it was done on purpose? Source? From IRC, all said by gmaxwell: I'd rather it go to the 250k level while we don't know. I'm not certian that it couldn't be triggered by a somewhat smaller block.
Seems to indicate that smaller blocks could trigger it. or 0.7 had another dumb implicit limit + which we didn't discover because our tests were inadequate to discover + and miners were encouraged to crank their block targets up when other than a few testnet blocks only a few max size blocks had ever been created.
Testnet blocks were at max size, so that type of testing could not have caught the issue. There are some with >2000 TXN and such, but they don't have large numbers of txins because I was spending 50 tnbtc blocks.
This seems to indicate that not even a large number of transactions specifically causes the issue, but rather a large number of txins. we don't have it fully measured and determined yet, but its most likely the number of transaction outputs being spent plus the number of outputs being created.
This supports the idea that only specific blocks could cause this. we have tests that make maximum sized blocks... but not one that makes large numbers of both inputs and outputs.
In conclusion, it seems that it was not in fact a "big block" that caused this. A small block could in theory cause it if the tx-ins or tx-outs were small, which is entirely possible thanks to compressed public keys. I did not mean my statement "structured carefully" to mean that someone has intentionally done so, but rather that the block's structure was rare and unique. |
|
|
|
So what is the procedure for those (regular users) who want to continue using 0.8.0 without causing issues? Is there a database config variable to set or something?
Downgrading seems like a bad idea for regular users.
Don't downgrade. You aren't a concern unless you are a miner. |
|
|
|
I suppose you forgot already why this thread started - we ran out of block space and transactions started stacking up, unconfirmed. This almost immediately caused lots of user complaints.
Exactly because people did NOT upgrade to Bitcoin 0.8 fast enough, which fixed the bug in 0.7 and below, now we are now back to square one - stuck with blocks that are too small to meet demand for transactions. Expect the complaints to start again soon unless filtering of SD becomes common.
The options I listed in my first post are still the only options. If you don't want to filter out SD transactions then the default "do nothing" option means that transactions will become very expensive, and small quantities of Bitcoin won't be spendable at all.
The fork is certainly a big problem: unfortunately, nobody realized it would happen. It's not even clear yet what kind of testing would have revealed this issue. Simply making big blocks is apparently not enough to trigger it. That said, we knew that BDB was generally a rats nest of weird problems which is one reason why I ported Bitcoin to LevelDB. If the block sizes had been raised a few months from now, we'd probably have just abandoned the 0.7 users to their fate, but we got unlucky with the timing.
Assuming we want Bitcoin to scale up, we'll have to fork 0.7 and lower off the chain sooner rather than later and then raise the block size limits again.
Testing compatibility with a bug in a previous version would require knowing about a bug in the first place, so I assume that the testing should have been conducted on older versions of Bitcoin, not 0.8. |
|
|
|
|
This is not accurate.
There was, indeed, testing on the testnet with a full (1 MB) block. This was accepted by both the 0.7 and 0.8 versions. There is no concern here.
Slush's block should have produced the same valid block. However, the block was structured carefully as to expose a problem in 0.7 that was never discovered. Not only was this an extremely difficult problem to catch, but its finding would in fact not have been accelerated with a mixed testnet. The introduction of 0.8 into the equation would actually delay finding the bug, as it would mean less time spent testing edge cases on 0.7.
|
|
|
|
Please stand by. There was a past event yesterday that may be added to the list. The recent chain fork has not only affected miner revenue, but may also have caused double-spending attacks. Mining cost: 748.18715667 BTCDouble-spend: Preliminary total: 960.09645667 BTCFinal update: No other double-spend attacks have been reported. The event therefore does not qualify for inclusion. |
|
|
|
|
Am I correct that we will need upgrades for every version of the Bitcoin client, because 0.7 and lower throw exceptions when parsing any block that breaks the DB? Could this be used as a DOS attack?
So that means the versions to upgrade to will be:
0.8.1, which somehow simulates the bug in 0.7 and lower.
0.7.3, which stops throwing the exception and flat out rejects the blocks the bug breaks.
0.6.5, as 0.7.3
0.6.0.11, as above
0.5.8, as above
0.4.9, as above
0.3.25, as above
I assume there will be no need to upgrade 0.2 or below.
|
|
|
|
incompatibility between versions should be called (at least) an issue imho...
My point was that exhaustive testing of 0.8 would never have revealed the bug in 0.7 that nobody knew about. Unit testing to make sure the code was actually capable of operating at the protocol limits would have caught the problem had it been performed on 0.7 Indeed, the testing should have been conducted in the three years since Bitcoin was released. It's appalling how the edge conditions were never tested. Not sure backward compatibility is an edge case.... generally its a big deal you plan a transition for. What happened here was a rushed satoshi dice bailout with much discussion on filtering out their transactions while a real solution could be worked on.... which now leaves everyone feeling the pain instead of a single entertainment site. The edge condition is referring to the blocks that were rejected even before 0.8 was released. A perfectly valid block could be rejected by every Bitcoin node. Isn't this something that should never happen? A block rejected by all nodes is by definition invalid. Someone wil produce a new valid one, and the building will continue as normal. Is there any evidence that all nodes would reject it? It looks like, according to Pieter's preliminary statement, that certain configurations will (correctly) accept the blocks. Immediate solution is upgrading to 0.8, or manually setting the number of
lock objects higher in your database. I'll follow up with more concrete
instructions.
|
|
|
|
incompatibility between versions should be called (at least) an issue imho...
My point was that exhaustive testing of 0.8 would never have revealed the bug in 0.7 that nobody knew about. Unit testing to make sure the code was actually capable of operating at the protocol limits would have caught the problem had it been performed on 0.7 Indeed, the testing should have been conducted in the three years since Bitcoin was released. It's appalling how the edge conditions were never tested. Not sure backward compatibility is an edge case.... generally its a big deal you plan a transition for. What happened here was a rushed satoshi dice bailout with much discussion on filtering out their transactions while a real solution could be worked on.... which now leaves everyone feeling the pain instead of a single entertainment site. The edge condition is referring to the blocks that were rejected even before 0.8 was released. A perfectly valid block could be rejected by every Bitcoin node. Isn't this something that should never happen? |
|
|
|
|
Show Posts
