Quote from: Victorycoin on October 24, 2016, 12:49:35 PM

Quote from: milewilda on October 22, 2016, 02:46:08 AM

Quote from: kwest on October 21, 2016, 10:18:14 PM

Quote from: mtnsaa on October 21, 2016, 05:57:18 PM

Actually this will help the network long term but it's getting a little tiresome, let's see how the next fork goes and if there are any upcoming news with Casper. The price doesn't seem to be dropping below $10 anytime soon even with no news and regular attacks.

If any coin is to succeed in the long term it needs to be tested for safety and resilience. Trial by fire so to speak. So I'm actually glad that people are performing attacks, it's the only way to find out if the technology stands to survive or not on a larger scale.

Agree with this, human attacks to a certain technology could somehow a good move though in order to test a particular thing if it would survive for long . In the case of ETH i could somehow say that its quite a good coin for me inspite of all issues regarding into it into the past months and years.

ETH was actually going places before the attacks! Notwithstanding it did not lose all its shine and on the flip side, all these attacks can end up bringing to the fore the doggedness of the coin and people would count that as plus. ETH has been one coin that puts bitcoin on its toes and thus creating keen competition, which presents opportunities for profit making for the traders that are looking at the right pictures.

https://www.reddit.com/r/ethereum/comments/58i8e0/update_on_hf_2_and_client_optimizations/?st=iuqn0x15&sh=4621f3c6

Update on HF 2 and client optimizations

Geth developers are working on an optimization that will store a direct on-disk table representing account storage, allowing accounts to be accessed in O(1) leveldb reads instead of O(log(n)) leveldb reads as is the case now. Preliminary tests suggest a 5x speedup in processing account reads if this is done. This is a fairly large change to the client (not quite but almost as complex as journaling) so don't expect it out tomorrow, but it will make a large difference.
Simpler optimizations on the in-memory trie cache are achieving ~30% speedups.
We're looking at simple forms of state tree pruning to allow nodes to reduce their storage size without having to delete the DB and fast sync from scratch. This should increase processing time indirectly.
The main debate in the hard fork discussions is whether to implement EIP 158 with section 2 or with (1c) (there is little value in doing both). The two carry different risks; section 2 is more complex from an in-EVM consensus standpoint, whereas (1c) requires more substantial re-architectures in other areas of geth to implement, as iterating through all accounts is not a use case that needed to be supported in all nodes before.
We are considering adding replay protection, likely either EIP 155 or a simpler trick involving using the upper bits of the tx nonce as a chain ID, but nothing is yet finalized.