Releases: ethereum/go-ethereum
Come at me Bro (1.4.15)
Geth 1.4.15 is a hotfix release to address two DoS attack vectors abused on the mainnet:
- Wasted CPU resources by abusing the EVMs JUMPDEST cache's key generation.
- Huge memory and CPU consumption by abusing quadratic contract state dirty tracking.
Please update ASAP. Further optimizations will most probably follow as we comb the code for bottlenecks.
What else should we rewrite? (1.4.14)
This is a Geth pre-release to counter the network DoS attacks from yesterday and those detected today. It is a prerelease (to help people get back on track fast) with further updates coming soon. As always, please keep an eye on your nodes while using as it features a new bleeding edge caching mechanism.
Note, initial attack blocks may process slower as cold data is loaded from the disk, but the longer Geth runs the less impact such transactions should have.
Being a pre-release, we won't land this code just yet in the master branch, also inherently meaning we won't be providing stable binaries from the usual channels (brew, ppa, chocolatey), however cross builds are available for testing below. Mist builds containing the pre-release will also be available.
🔩 [xgo build bot] Published geth 1.4.14-prerelease (f88bca7) - release/1.4 branch
Disclaimer: All of these binaries have been cross-compiled from Linux. Their primary goal is to provide access to unsupported or experimental platforms. We cannot guarantee that a cross compiler will produce the same performing code as a native build will. For any issues found, please contact @karalabe.
Into the Woods (1.4.13)
This patch is a hotfix release to mitigate last weeks DoS attacks, and those ongoing currently against Geth nodes in the network.
This patch should still be considered bleeding-edge. We advise exchanges and other users running business-critical applications that intend to run this release to simultaneously run a different client node and trigger a circuit breaker in case there is another DoS vulnerability or consensus failure. Users should continue to be on the alert for new patches and attacks against the network. Once enough nodes run the patch and the situation sufficiently stabilizes we will advise miners to slowly raise the gas limit.
There will be an additional patch created over the next several weeks to implement some more permanent fixes including cache journaling and cache-miss mitigation.
From Shanghai, with love (1.4.12)
Hotfix release for a network DOS attack! Please update ASAP.
Minor Text Fixes (1.4.11)
This release fixes the following issues:
- Preparing for a new build system #2726 #2896
- Fixes concurrent map access in filtering #2711
- Cancel DAO challenge on peer drop #2833
- Removed eth/61 protocol #2842
- Downloader improvements #2855 #2861 #2867 #2868 #2866
- Removed ECRECOVER log message #2892
- Added support for MIPS64 #2682
- Fixed a temporal anomaly in the blockchain when inserting blocks #2873
- Minor text fixes...
Return of the ETH (1.4.10)
Looking for the latest Ethereum Wallet/Mist? See here
Geth 1.4.10 "Return of the ETH" is the go-ethereum team's DAO hard-fork implementation. It enables anyone to choose whether they would like to support the DAO hard-fork or oppose it, and take them to their blockchain of choice.
- To support the DAO hard-fork, start Geth with
--support-dao-fork - To oppose the DAO hard-fork, start Geth with
--oppose-dao-fork
On startup (on the main network) Geth will print the currently configured choice, which you can freely change with the appropriate flag at any time. If neither of the above flags is specified, the previous configuration is used. If no fork choice was ever provided, Geth will default to supporting the fork per the majority vote.
Please note, fast sync and light clients do not verify state transitions, only perform header validations and PoW checks. As such, a fork unaware client (i.e. non-updated one) will always fast-sync to the longest chain, as it doesn't have the necessary information on what to look for in the headers. Even if you oppose the fork, please update so your client knows what chain to avoid.
References:
- Hard fork spec: https://blog.slock.it/hard-fork-specification-24b889e70703#.cumx78uqu
- Implementation details: #2814
The network strikes back (1.4.9)
Geth 1.4.9 is a reversal release to undo the code changes that went into the 1.4.8 "DAO Wars" soft-fork release, as the soft-fork was deemed too vulnerable to DOS attacks, opening up the entire Ethereum network to resource abuse by malicious users.
Most importantly, this release reverts a data race introduced by the rushed soft-fork that can lead to miners crashing if they are running transactions simultaneously with importing blocks from the network. Thank you @9600- for finding this!
Additionally, the previously release's soft-fork code required a non-insignificant performance impact even when the soft-fork is not enacted, making this current release at the same time a minor performance boost compared to 1.4.8.
DAO Wars (1.4.8)
This release should be considered nuked. The soft-fork turned out to violate a system invariant leading to potential DOS attack vectors, and the rushed code contains a data race that can sometime lead to miner crashes. Please either use 1.4.7 or 1.4.9 instead (they are equivalent).
Version 1.4.8 is a small patch release to give the community a voice to decide whether to temporarily freeze TheDAOs v1.0 from releasing funds or not. If the community decides to freeze the funds, only a few whitelisted accounts can retrieve the blocked funds and return them to previous owners.
Note: If the soft-fork passes, it will block all DAOs from releasing funds, not just the ones the community considers attacked. This is understandably undesired for all legitimately split DAOs. As such – if the community votes to enact the soft-fork – we propose a follow up patch to the soft-fork that will whitelist all DAOs split according to the intent upheld by the enacted soft-fork.
How to use this release?
Miners supporting the DAO soft-fork can do so by starting Geth with --dao-soft-fork. This will cause the block gas limits to be lowered towards Pi million until the deciding block 1800000 (approx. 6 days from now) is reached. If the gas limit of this block is below or equal 4M, the soft-fork goes into effect and (all updating) miners will start blocking DAO transactions that release funds.
Miners not supporting the DAO soft-fork can run Geth normally without any extra arguments needed. They will try to keep the block gas limits at the current 4.7 million. If the gas limit of the decisive block will be above 4M, the soft-fork is denied and (all updating) miners will accept DAO transactions that release funds.
Note: All updating clients will agree upon the outcome of the vote and will adhere to that decision. If the soft-fork vote passes, miners voting against it will start blocking transactions too; whereas if the soft-fork is denied, miners voting for it will also accept all transactions.
What if I don't update?
Miners who do not update by definition vote against the soft-fork as they will continue the current logic of keeping the gas limit above the vote threshold. If the soft-fork is accepted by the majority, non-updating miners will still accept blocked transactions. In that case, non-updating miners will either fork off their own Ethereum network, diverging from the majority, or will forfeit any blocks they mined (since it's not accepted by the majority, overruling the minority blocks).
Should non-miners (nodes, wallets, mist, etc) update?
From the perspective of non-miners, this update has little relevance. Either outcome of the vote is equally valid from a plain node's perspective, so plain nodes will accept the heavier chain miners decide on without having to know anything about the soft-fork mechanism or results.
Epilogue
This release implements a soft-fork. A soft-fork is perfectly compatible with all protocol rules and requires only the consensus of the majority of miners to enact. It is temporary and can be removed/amended at any point in time upon miner consensus. It does not break protocol rules; it does not roll back any executed transactions/blocks; and it does not change any blockchain state outside of the original protocol capabilities.
Note: This release does not represent a consent to hard-fork the network. It is a means to give people more time to come up with the best solution.
Colourise (1.4.7)
Version 1.4.7 is a tiny patch release mainly to address a Windows console colour issue and to fix a few miscellaneous annoyances.
- Fix Windows console colour output #2669
- Fix console to not choke on parentheses in strings #2670
- Work around some CI and build server issues #2671 and #2687
- Fix typo in the
geth accountsubcommand help #2673 - Update the CLI package dependencies #2677 and #2681
- Fix ABI number encoding issues for native Dapps #2653 and #2680
- Fix EVM debug traces for same-block contract suicides #2686
- Extend
evmutility tool with contract creation support #2693 - Fix whitespace typos during chain import/export #2697
EDGE (1.4.6)
As Ethereum got more popular, the peer-to-peer networking infrastructure became extremely versatile (we have 3G peers in New Zealand and Satellite peers in the US). Certain assumptions that Geth made about the network when we've launched became untrue in the last months, especially with TheDAO bringing in an unexpected number of new users and environments. In this newly expanded network, the original assumptions caused Geth to be too aggressive with which peers are useful and which are not.
Geth 1.4.6 "EDGE" aims to solve the synchronization issues resulting from this newly found heterogeneity: it introduces a lot more download concurrency to avoid bottlenecks caused by badly connected remote machines, and also introduces adaptive quality-of-service tuning to make peer selection less aggressive for users with more restricted connectivity.
The result is a newly polished sync mechanism that can churn out a 7-8MB/s download speed in the current Ethereum main network (if your connectivity allows it), but also provide a solid and stable stream for all users, verified for as low as EDGE connections (440ms latency, 200 kbps upstream, 220kbps downstream).
We'd like to shout out a big thanks to @ellis2323 for the tireless benchmarking and re-benchmarking of our polishes on high end machines and connectivity (reaching 3 hours full sync times and 20 minutes fast sync times) as well as to @JasonCoombs for verifying connectivity and sync stability on extremely high latency satellite links.
A breakdown of the sync changes:
- Concurrent header retrievals to prevent sync bottlenecks #2315
- Disable transaction processing during initial sync cycle #2574, #2649
- Download state trie concurrently with blockchain during fast sync #2627
- Adaptive quality of service tuning for restricted connectivity #2630
- Fast-sync critical-section download failure resiliency #2647
- Enterprise grade hand-tuned multi-level heuristic smart caching
#2585
Polishes and bugfixes:
- Refactor JavaScript console for external library reuse #2535, #2656
- Re-enable bad block reporting to track any strange activity #2614
- Fix a transaction pool data-race for extreme tests #2655
- Fix eth_getTransactionCount on the testnet for non existent accounts #2626
- Fix compiler path and listing for Solidity compilation #2613, #2612
- Fix an extremely rare downloader hang after a successful sync #2637
- Fix a CI server
go vetannoyance with mutex copying #2580