|
I was going to respond but then I realized there is absolutely nothing factual in the entire post. What a waste of bits.
Please read what a 51% attack entails. No 51% attack occurred yesterday.
|
|
|
|
Asking miners to volentarily change to a different version of the client software for the good of the network = "51% attack"? Really? That is your tortured definition. How about the real one ... https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_powerAttacker has a lot of computing power
An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:
Reverse transactions that he sends while he's in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
Prevent some or all transactions from gaining any confirmations
Prevent some or all other miners from mining any valid blocks |
|
|
|
Is this issue fixed or do we still have 2 blockchains running?
Fixed? U call 51% attack organized by Bitcoin Foundation "a fix"? :facepalm: What 51% attack? Do you even know what "51% attack" means? Hint: it isn't the Bitcoin equivalent of the boogeyman. |
|
|
|
v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with either the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened. It was a landmine.
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 ... 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. |
|
|
|
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.
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. 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. |
|
|
|
If nothing else the next year is going to be interesting. I tendered my letter of resignation last Friday. Since August of last year I along with my business partner and investors have build Tangible Cryptography, LLC from an idea to an enterprise executing almost a million dollars a week in transactions. To date we have done this without any full time staff, just a lot of out of the box thinking and clever back end automation. It is time to make a leap of faith so starting in April I will be working full time for the company I helped build. I have lots of exciting ideas to bring to the Bitcoin community and soon Tangible Cryptography will have both the funding and resources to make them happen. When I first read Satoshi's paper back in 2011 I never imagined that the next chapter of my career would be connected to Bitcoin. It has been an exciting couple years and I am confident that there are only bigger and better opportunities over the horizon.
Gerald Davis (DeathAndTaxes)
Executive Manager
Tangible Cryptography, LLC
You have a wonderful sense of timing. Yeah you could say that. |
|
|
|
If they did that, all 0.7 clients would have been left dead in the water, unable to rejoin the main chain and forcing end users to upgrade on the spot. 0.8 clients can rejoin the 0.7 chain so this was why it was preferred.
In hindsight I bet it will turn out that sticking with 0.8 would have resulted in a more rapid resolution. I'm not sure. The only way to resolve this was to force *all* 0.7 users to upgrade. Here only 2 pool ops (slush and Eleuthria) could single-handedly put the 0.7 hashrate ahead by downgrading their bitcoind nodes which will solve the problem for everybody in the following hours. Plus there was no risk in downgrading but given enough time eventually all 0.7 users would be vulnerable to a nasty and no hashpower double spend attack. That would have created chaos, confusion, and damaged the credibility of the network. |
|
|
|
Is it concerning at all that the devs and the large mining pools just colluded to do a 51% attack ? No. Then again that didn't happen and 51% attack obviously doesn't mean what you think it means. |
|
|
|
You of course tested both v0.7 and 0.8 on testnet found the flaw and reported it to the development team. When they ignored you, you went viral sharing the incompatibility with everyone you knew. Thanks goodness we had you ... er wait you didn't do any testing. Most of the developers are unpaid volunteers. Given your extensive testing experience why aren't YOU doing something?
Gavin is paid, I think this month his payment should be revoked for this bug getting thru. Or not. |
|
|
|
|
You of course tested both v0.7 and 0.8 on testnet found the flaw and reported it to the development team. When they ignored you, you went viral sharing the incompatibility with everyone you knew. Thanks goodness we had you ... er wait you didn't do any testing. Most of the developers are unpaid volunteers. Given your extensive testing experience why aren't YOU doing something?
|
|
|
|
|
Too bad v0.7 was incompatible with v0.8 then right? Developers should have just recommend pushing ahead and fuck those who hadn't upgraded. You are aware that v0.8 had the majority of the hashing power right?
|
|
|
|
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. 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. |
|
|
|
Advanced recreation of my trading account for the last hour or so.  People really got that scared? The panic seemed to accelerate even after there was news on fix and the limited scope of the problem. |
|
|
|
Well, this is timely. About an hour ago, there was a blockchain fork due to a subtle difference in the 0.7 and 0.8 clients. The offending block was 225430. Around the time block 225433 was mined, all the biggest mining pool operators were contacted and told to revert back to the 0.7 chain while the issue was being looked into.
Meaning, if you had accepted a transaction with only 4 confirmations using an 0.8 client, your transaction would have later disappeared. Waiting six confirmations is a hedge for when stuff like this comes up.
Well not exactly. The transaction would exist on the 0.7 chain as well. It may not be a block yet but it would at the very least exists as an unconfirmed tx. |
|
|
|
|
If nothing else the next year is going to be interesting. I tendered my letter of resignation last Friday. Since August of last year I along with my business partner and investors have build Tangible Cryptography, LLC from an idea to an enterprise executing almost a million dollars a week in transactions. To date we have done this without any full time staff, just a lot of out of the box thinking and clever back end automation. It is time to make a leap of faith so starting in April I will be working full time for the company I helped build. I have lots of exciting ideas to bring to the Bitcoin community and soon Tangible Cryptography will have both the funding and resources to make them happen. When I first read Satoshi's paper back in 2011 I never imagined that the next chapter of my career would be connected to Bitcoin. It has been an exciting couple years and I am confident that there are only bigger and better opportunities over the horizon.
Gerald Davis (DeathAndTaxes)
Executive Manager
Tangible Cryptography, LLC
|
|
|
|
out of interest, would this be a good time to discuss fees in general?
0.01 btc seems a lot to me, the original white paper talked about fees of a cent per transaction. 0.01 BTC (per kb) isn't required for any tx. just my 0.0005 btc Ironically that is the mandatory fee for low priority tx (high priority tx have no mandatory fee). https://en.bitcoin.it/wiki/Transaction_fees |
|
|
|
I've been around IT long enough to know that predictions are the funnies for the next generation! Going on the history of cryptography, an algorithm has a lifespan of about 40 years before brute force is practical, so I would say that if you lose your private key, you are in for a good new year in 2050 or so!  Lets at least keep the terminology correct. A brute force on a 256 bit key is impossible by the thermodynamic limit. It is impossible today, it will be impossible in fourty years, and in all likelihood baring some as of yet completely undiscovered energy breakthrough will still be impossible in 40,000 years. It isn't that we haven't yet built fast enough computers it is that even a perfect computer would take more energy than is available in our solar system. If someone sent a 256 bit private key on a spaceship to the nearest star system it would take less energy to simply go retrieve it, then it would to try an brute force it. Now it is possible that ECDSA has a cryptographic flaw, and in the coming years/decades this flaw will be discovered which will allow attacks FASTER THAN brute force attacks which render ECDSA vulnerable. However even if that happens a brute force attack on 256 bit keys will still be impossible. It is also possible no viable attack on ECDSA will be discovered in our lifetime. |
|
|
|
|
You are assuming the trials are dependent. That the failure of one hash reduces the search space and increases the chance of future hashes being correct (like removal of cards from blackjack deck). The reality is hashes are independent*. If difficulty is one million the odds of each hash valid are 1/(one million * 2^32). This is more like rolling a pair of fair dice. If you fail to roll "12" ten trillion times in a row the chance of the next roll being "12" is still the same. Likewise if you hash one trillion hashes above the target the odds of the next hash being valid is still 1/(one million * 2^32). Note the expected outcome is just that expected. It is entirely possible that the "long run" will never arrive in your lifetime (or the lifetime of the human race). The actual outcome could be more or less than expected for a nearly infinite amount of time.
* Technically they aren't independent because the search space is finite. However for a given block height (thus prior block hash, difficulty, and version are fixed) the search space is 2^320 which for all practical purposes is infinite. While Bob may complete twice as many hashes before the block both Bob and Alice will complete roughly ~0% of the search space.
|
|
|
|
patch it with this  |
|
|
|
|
Show Posts
