Ethereum (ETH) - POW/POS - Ethash

  • Ethereum (ETH) dev update - Roundup Q2

    Thanks to all the developers and team leads who contributed to the sections on their projects

    In the last month and a half, the Ethereum network went through a rapid growth in usage, to the point that it now processes as many transactions per second as Bitcoin. To accommodate the increased load, which has on a few occasions reached the network’s full capacity for hours at a time, the community independently came together and miners voted to increase the gas limit to 6.7 million. We at the Foundation have been rapidly putting additional resources toward increasing the efficiency of the network, alongside planning longer-term changes that will greatly increase the network’s scalability.


    • The Ethereum research team and discussed various topics to do with Casper, sharding and Ethereum protocol economics.

    The pyethereum client has seen a substantial revamp, and version 2.0 has been released. See for download; in Ubuntu you can also do “sudo pip install ethereum”. Additionally, we have implemented experimental versions of:

    Metropolis testing

    Metropolis testing is rapidly moving forward. We are actively seeking additional help with finishing testing. See:

    We have started a substantial cross-client benchmarking effort to identify places that are in greatest need of performance improvement. See some preliminary results for opcode benchmaking in geth here:

    Ethereum core developer meetings #15-#19 took place. Notes and audio/video of the meetings can be found here:

    Mist team

    In May-June, the Mist team had a team meetup: for one week the team had face to face meetings, some members for the first time, in which we sat together to share details on projects we were working on and to talk about the current codebase and future roadmap. While we have a long list of features we are working on, we realized that most of the issues reported on github were related to two main issues: slow synchronization and lost account private keys/passwords. We outlined features that we could implement to help prevent user errors and other related issues, including more options for node switching (including Infura support) and better options for account management (including HD wallets and mnemonic seeds – but with a twist).

    • Many of those new issues require some changes on how the signing process is done to make Mist more independent of Geth, which is being worked on as a standalone signer.
    • We have also done some research on refactoring parts of the Mist codebase to make it more modular and easier to maintain.
    • Victor Maia presented some research on how to make apps load quicker and be more reliable and we are currently testing some of these concepts as either pieces of the main codebase and/or an alternative web-based product.
    • Progress has been made on ENS integration: we have added ENS support to our address component, meaning that any of the apps we have built in meteor (wallet and ens registrar app) will accept a name in any field where it would usually expect an ethereum address. We are also working on making a web component for generic input types for ethereum addresses, so any webapp developer can use an input field with support for ENS, checksum and ethereum identicons. With swarm now using the main net registrar, it also means that Mist will accept ENS addresses on the url as soon as the swarm branch is merged..
    • Swarm integration has been tested and is a lot more stable than it has been even a few weeks ago. We predict it will finally be ready to release soon.


    Web3.js is  coming along well. The new whisper API was recently added to the old 0.x.x and the new 1.0.0 version. Whisper v5 is currently only available in geth and needs to be started using –shh.  We are currently adding swarm.js and finishing the JavaScript account management. If everything goes well, an alpha release will happen soon.

    You can already test the new web3.js 1.0 here:


    We have received several bounty submissions for vulnerabilities in EthereumJS, Solidity and Cpp-ethereum. See the leaderboard for the current stats.

    We now have pyethereum on board on the cross-client blackbox consensus testing in Hive, which continuously performs over 10K tests on each client. See As a lightweight alternative to Hive, we’ve also started a project to perform fuzz testing directly on the virtual machines, starting with Geth, Parity and Python. In the same vein, we’ve also set up an automated AFL-based fuzzing of Solidity.

    In preparation for Metropolis, a benchmarking suite for the Geth EVM has been implemented to ensure that the gas prices for new opcodes and precompiles are within reasonable bounds, so as to not constitute DoS-vectors at a later point.

    EVM 1.5

    The “EVM 1.5” proposals are now EIP drafts for “Subroutines and Static Jumps for the EVM #615,” and “SIMD Operations for the EVM #616”.  Discussion and critique are welcome at the conversations.


    The ethereumJS team is still looking for community contributors Intro to Core Development with Ethereumjs-vm” has been released.

    Light Client

    New algorithms have been designed and implemented in order to improve log searching performance in the next version of the LES protocol. Promising R&D work has been done toward achieving quick and trustless initial syncing without hardcoded checkpoints. We have put some efforts into finalizing the topic discovery protocol, which helps clients to find suitable LES servers as it is currently a somewhat weak point in the experimental light client service.


    The main Remix feature in the last month is the alpha release of Remixd:

    Formal Verification

    The progress in the eth-isabelle project was mostly from external contributions. In particular,  the better separation logic tactics, which were externally contributed allow much shorter proofs about Ethereum contracts.

    • Better separation logic tactics (contributed)
    • Coq build fixed, and added in the continuous integration
    • Removing unmaintained files, and `Annotation` structure not needed anymore (PR pending)
    • Running Blockchain Tests (in progress; ecdsa recover implementation in OCaml wanted).


    • The compiler is generating bytecode for all initial examples
    • Syntax perfection following community feedback
    • End-to-end testing of the compiler (in progress)


    The Solidity project has been quite active in the last months, although most of the updates is not yet directly visible on the user side. We saw a lot more engagement by the community and now have volunteers regularly contributing both to the core code as well documentation including translation, mainly into Spanish.


    We added a feature that allows export of the full abstract syntax tree with all type annotations, which makes it much easier to write tools that would otherwise need a custom-made parser. The next feature will be to also re-import this data after potential modifications, which would allow things like mutation testing.

    We extended the inline assembly language with structured elements (for, switch and functions) and deprecated manual jumps. This new inline assembly language will become a new intermediate language (together with type information), which allows Solidity to be more transparent in its compilation, more efficient (we will be able to add much more sophisticated optimizer routines) and more portable (it can already compile to EVM, EVM1.5 and some eWASM). We are currently rewriting the ABI encoder in this intermediate language which will include structs and nested dynamic objects.

    Finally, we are adding an automated compile-time overflow and assertion checkerbugfixes and smaller features.


    The swarm team has onboarded new members and held an in-person Swarm Summit in Berlin in June, 2017. The week-long event brought together Ethereum team members, community contributors andspecial guests representing projects and companies interested in swarm. More than twenty talks and tutorial sessions were recorded. The edited videos will be published soon on the swarm summit website. Our public alpha test saw a great community response allowing us to gather more information on prospective user base needs and what the typical usage patterns might be. The high churn of nodes requires an explicit distinction between nodes that can and cannot commit to being available for a longer period of time to provide sufficient storage and bandwidth resources for the network. To support noncommiting nodes and mobile clients, swarm will offer various light modes of operation.

    We have developed a suite of example applications highlighting the architectural and implementational peculiarities of Swarm-hosted distributed web applications that are quite a departure from the traditional client-server model. In particular, the building blocks of a distributed functional equivalent of dropbox are being developed, such as a web-interface providing a file-system view of swarm-hosted volumes, ENS integration, Mist-integration, FUSE mounting of swarm-volumes and privacy protections.

    We added a new protocol, pss (bzz whispered) allowing internode messaging with deterministic routing based on the relaying kademlia network topology of swarm. The protocol uses whisper envelopes and offers udp-like protocol communication between nodes that are not directly connected.

    Furthermore, we have developed a network testing and simulation framework in which we can model and benchmark a broad range of scenarios emerging from the interaction of a potentially large number of  nodes. This framework includes both scripting and visualization capabilities.

    In cooperation with the Remix team, the implementation of a fully distributed integrated contract development environment is underway.

    The next major release, POC 0.3 is scheduled to come out around Metropolis and will include  obfuscation support for plausible deniability, a rewrite of the swap peer-to-peer accounting for bandwidth incentivisation among other things.


    Vitalik Buterin

  • Ethereum (ETH) Release AYTABTU (Geth v1.6.7)

    Geth v1.6.7 (All Your Transaction Are Belong To Us) is another fine maintenance release:

    • The transaction pool now tracks 'local' transactions based on sender address (#14737).
      • Transactions sent by local addresses are exempt from gas pricing- and overall queue size limits.
    • Docker images are smaller because consensus tests are no longer included (#14734, #14792).
    • Extend RPC formatting error messages with field details to better describe the failure (#14686).
    • Add Whisper v5 CLI flags to Geth and add a Whisper Go client library (#14540).

    Important notice to projects running public nodes (MyEtherWallet, Etherscan, Infura, etc): The sender address of any transaction submitted via RPC will be considered a local address, and all transactions from such addresses will be exempt of the gas price and pool size enforcement. To avoid DOS attacks due to the exemption algorithm, please run with --txpool.nolocals to disable special exemptions for local accounts.

    For other minor changes in this release, see the 1.6.7 milestone.

    Binaries and mobile libraries are available on our Download Page

  • Ethereum (ETH) Release Mist v0.9.0


  • Ethereum core devs meeting update (July 14, 2017)

    All Core Devs Meeting #20

    Ethereum Foundation’s core developers meeting was streamed live on youtube. yesterday , July 14, 2017.


    • Metropolis updates/EIPs.  a. Any “subtleties” or questions we need to work out.  -Split metropolis into 2 forks? Leave out EIP 86/208 in fork #1.  b. Updates to testing.  c. Details and implementations of EIPs.
    1. Updates from client teams. geth — ethereum/go-ethereum#14337 Parity — paritytech/parity#4833 cpp-ethereum — ethereum/cpp-ethereum#4050 yellowpaper — ethereum/yellowpaper#229 pyethapp Other clients
    2. Determining gas prices for new opcodes & pre-compiles d. Review time estimate for testing/release.

    Main outcomes of the meeting (as reported by Souptacular):

    • Splitting Metropolis into 2 hard forks.

    Part A — Aug / Sep 2017

    Part B — Jan / Feb 2018

    • These dates are still entirely guesses and subject to change depending on how testing goes and what EIPs are decided to add to Metro. B.
    • Delaying EIP 86 until Metro HF 2.  The reasoning is that EIP 86 is a significant change to the underlying way accounts are created and recently there has been extensive discussion (summarized here) about the concerns and challenges of safely implementing it. At this point completing the analysis and testing of 86 would delay Metropolis further than necessary, especially considering that the other EIPs that are to be added are nearly all finalized, implemented in clients, and have tests developed for them.
    • In short, no other EIP going into metro is reliant on EIP 86 so to make sure Metropolis as a whole goes smoothly we want to give ourselves plenty of time to evaluate the recently discussed issues surrounding EIP 86’s design.
    • Likely adding miner block reward deduction to Metro HF 1.
    • Block time estimates calculated today (subject to change):

    22 sec. — end of July

    27 sec. — Aug. 26

    35 sec. — Sept. 27

    45 sec. — Nov. 6th

    • EIP649 (difficulty bomb delay) is planned for HF1.
    • Nick/Vitalik working on EIP 96, 98, and addressing concerns with gas scheduling in 198.
    • EIP for miner reward reduction (will be combined with ethereum/EIPs#669 likely)
    • Put ice age changes in 669.
    • Martin H.S will bring new opcode gas data next time.
    • Parity team to supply benchmarks to compare with Martin’s geth ones.

    Why are block times increasing?

    As explained by PoliticalDissidents, “It’s the difficulty bomb. Difficulty was programmed to increase exponentially beyond what is warranted to account for increasing hashrate. This means block time keeps getting longer and longer and doing so at an exponentially increasing rate.

    This was designed as a suicide pill for Etheruem as the plan all along was to fork later in the the future (primarily due to a plan to Implement POS) so the difficulty bomb exists to make it so that the current chain will die regardless of if miners want to keep it alive or not because eventually difficulty will get so high that block time will become so long that it’s no longer a viable currency to use and it dies off.”

    Further details related to this meeting are available at GitHub.

    For more updates, technical blogs and general discussion on Blockchain Technology and Ethereum, please join us at our Website, reddit, Facebook, Medium, steemit and follow us at Twitter. Please feel free to share this post, email us with your suggestions and connect at LinkedIn.

  • EtherWorld’s weekly: July 16, 2017


    Project updates

    New Projects

    • Graphene Operating System (GEOS) — a fully decentralised operating system for blockchain applications.
    • Mattereum — Internet of Agreements infrastructure project.
    • LocalEthereum — Ether’s local private marketplace.
    • Orocrypt — When the Ethereum blockchain meets the precious metals.
    • Decentraland — Moving towards a decentralized future.
    • Ujo- A look under the hood.
    • Weipoint- Address verification
    • Coral- Secure platf0rm for tokensales
    • Doma- Platform for networked home ownership

    Hiring and Bounty

    Developer’s Update

    ICO / Token sale updates

    Upcoming Events

    For more updates, technical blogs and general discussion on Blockchain Technology and Ethereum, please join us at our Website, reddit, Facebook, Medium, Slack and follow us at Twitter. Please feel free to share this post, email us with your suggestions.

    #Ethereum #blockchain #FinTech #cryptocurrency #hackathon #bounty #EEA #ICO

    Originally published at localhost on July 16, 2017.

  • Ethereum (ETH) Security Alert

    Parity Multisig Wallet Hack

    Severity: Critical

    Product affected: Parity Wallet

    Affected implementations: Parity 1.5 or later

    Summary: A vulnerability in Parity Wallet's variant of the standard multi-sig contract has been found.

    Affected users: Any user with assets in a multi-sig wallet created in Parity Wallet prior to 19/07/17 23:14:56 CEST.

    Mitigation steps: Immediately move assets contained in the multi-sig wallet to a secure address.

    UPDATE (20/07/17, 00:26 CEST): Future multi-sig wallets created by versions of Parity are secure (Fix in the code is

Log in to reply

Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.