Starting from version after 1.4.11 release, development structure for this repository will change. When Classic was launched it was not clear how many people would volunteer. Now that the project has at least two releases and a growing community we will shift to a slower decentralized method of adding changes.

Commit Style
All commits should conform to the EF standard, this will allow the two communities to share work easily.

Example:
[release/1.4.6] eth: enable bad block reports

package: 80 word max description

Updates affecting both chains
Updates affecting both chains should be pushed to the upstream, however pull requests directly are welcome.

Pull requests for changes
Now that the project is stabilized, all new feature additions will require a pull request. One may work within a development branch on the project or within your own account but pulls to master and releases should be pull requests.

This structure is open to suggestions

I have removed the bug report template as this is not a bug. I have started the process of setting up a build environment for the ethereum classic project. Jetbrains has given the Ethereum Classic Github organization an Unlimited license for their TeamCity CI/CD server.

Thus far

1. the TeamCity server has been installed in AWS
2. Linux build agent has been installed and is running in AWS
3. Windows 2012 R2 build agent has been installed and is running in AWS
4. OSX build agent has been installed and is running
5. the OSX agent will be co-located shortly and will be offline during shipping
6. ETC github org (and projects underneath) is set up with Bintray as a CDN for artifacts generated by our build jobs

Specific Geth items done:

1. Build jobs for Linux and OSX are polling the develop branch and successfully building

Incomplete items specific to geth:

1. Build job for Windows is polling develop branch but the build is failing. Due to an environmental issue on the build node that remains to be troubleshot.
2. ARM Build agent needs to be built. Probably a co-located RPi 3
3. Teamcity needs additional configuration so that build artifacts from the develop branch jobs will be uploaded to Bintray
4. A TeamCity job needs/could to be created that builds release artifacts from tags? (See below re: signing)

Signing Release Artifacts

We need to decided on a strategy for signing release artifacts. We have several choices

1. Bintray is capable of signing uploaded artifacts using their own private key
2. we sign artifacts prior to upload, as part of the build job
3. we can generate a keypair which is encrypted and stored by Bintray. When we upload to Bintray we also provide a passphrase, which is used by Bintray to decrypt the key and sign the artifact. See (this link)
4. We don't automate release upload at all -- when releases are created/signed they can be uploaded to Bintray by the person that did the build, using the Bintray web interface

Having the TeamCity build server sign the releases is a non-starter in my opinion, for obvious security reasons. The first and third options involve private keys not fully under the control of trusted parties. The most secure option is the last one.

The Team City server can be reached at build.ethereumclassic.org. The (mostly empty) Bintray repo can be found here.

System information

Geth version: 1.4.10-stable-6aaf5f33
OS & Version: OSX 10.11.6

Expected behaviour

Using
geth --datadir "/path/to/another/ethereum/data/dir" attach
should open a JavaScript console attached to the running (if exists, and previous started) geth instance.

Actual behaviour

Even if a path is specified with the --datadir flag, geth starts using always the default value

if runtime.GOOS == "darwin" {
            return filepath.Join(home, "Library", "Ethereum")
        } else if runtime.GOOS == "windows" {
            return filepath.Join(home, "AppData", "Roaming", "Ethereum")
        } else {
            return filepath.Join(home, ".ethereum")
        }

Steps to reproduce the behaviour

Start a geth instance using a different datadir
geth --datadir "/tmp/differentdatadir"
then try to attach to it lunching another geth instance using "attach" command
geth --datadir "/tmp/differentdatadir" attach

System information

Geth version: Ethereum Classic 1.4.10
OS & Version: Linux
Commit hash : 6aaf5f3

Expected behavior

Receive ETC from valid transaction

Actual behaviour

Receive ETC and ETH from valid transaction

Steps to reproduce the behaviour

1. Create valid raw transaction
2. Broadcast to network by use web3.eth.sendRawTransaction() method

Backtrace

https://gastracker.io/tx/0xb35afc0c64cd46e32eb25cd45964babedc214f1aa76c61903ce40f2ced04dedb
http://etherscan.io/tx/0xb35afc0c64cd46e32eb25cd45964babedc214f1aa76c61903ce40f2ced04dedb

Following tests are failing on ARM, without giving any stacktrace:

• accounts.TestV1_2
• accounts.TestV3_PBKDF2_1
• accounts.TestV3_PBKDF2_2
• accounts.TestV3_PBKDF2_3
• accounts.TestV3_PBKDF2_4
• accounts.TestV3_Scrypt_1
• accounts.TestV3_Scrypt_2
• accounts.TestWatchNoDir

http://build.ethereumclassic.org/viewLog.html?buildId=252&tab=buildResultsDiv&buildTypeId=GoEthereumClassic_Develop_TestArm

README was linking to non-existent Docker repo. I grabbed the ethereumproject namespace on Docker, so now it's a link to an empty repo instead. If someone wants to take Docker responsibilities, let me know and I'll make you owner.

These will need to be replaced with complementary contracts or re-evaluated.

https://github.com/ethereum/go-ethereum/blob/290e851f57f5d27a1d5f0f7ad784c836e017c337/common/registrar/registrar.go

Looks like these have not been released yet. It appears the changes have already been merged in though, I will go ahead and sign and release these builds after some testing. If anyone has any objections or comments please share them.

I'm still reading about the DOS attacks but I should have some fixes proposed as pull requests soon as I'm able to.

To help us maintain our own network and further limit issues with the ETHF chain we need to run our own bootstrap nodes.

If you can run a dedicated bootstrap node, a node which can stay connected 24/7, typically on servers dedicated to this purpose: please provide the enode, ip address/domain, and port of the node.

Example
enode://a979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c@52.16.188.185:30303"

System information

Geth version: 3.0.0

Backtrace

E1017 05:30:09.212822 core/blockchain.go:1137] Bad block #1179407 (0x9e363e48e790f6548ebbdb7e50cce5f37c1908108b3e111c4780b6af1ae9daf1)
E1017 05:30:09.212846 core/blockchain.go:1138]     gas used error (1246053 / 1245493)

Fixed after resync

A user reported Bad block #1803253 also

Please see https://www.reddit.com/r/EthereumClassic/comments/4ti33y/classic_miners_please_use_geth_149_for_now/d5hld7n

Because we cannot guarantee that all original chain miners move to 1.4.10, there is a possibility of spoofing attack. So, seems like upgrading only after block 192010 (when we can check that no spoofing happened) seems like a better choice, right?

I've started noticing warnings for "potential rewrite attack" in geth 1.4.10-stable-6aaf5f33

I0805 05:54:43.005168 eth/downloader/downloader.go:1195] Peer fd25cfe81d84cc67 [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 20s]: potential rewrite attack: #1921606 [00000000▒] <= #1921606 limit
I0805 05:55:47.687278 eth/downloader/downloader.go:1195] Peer 78e257fb2aa36dd4 [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 20s]: potential rewrite attack: #1921606 [00000000▒] <= #1921606 limit
I0805 05:55:51.751628 eth/downloader/downloader.go:1195] Peer 01b9089693c3bf39 [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 20s]: potential rewrite attack: #1921606 [00000000▒] <= #1921606 limit
I0805 05:56:11.468304 eth/downloader/downloader.go:1195] Peer 4b1f3a45968d9c89 [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 20s]: potential rewrite attack: #1921606 [00000000▒] <= #1921606 limit
I0805 05:56:18.668953 eth/downloader/downloader.go:1195] Peer a215d5fb6fdec8c5 [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 20s]: potential rewrite attack: #1921606 [00000000▒] <= #1921606 limit
I0805 05:56:27.672463 eth/downloader/downloader.go:1195] Peer f423653efe5fceda [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 20s]: potential rewrite attack: #1921606 [00000000▒] <= #1921606 limit
I0805 05:56:31.741424 eth/downloader/downloader.go:1195] Peer e56ac587e922a073 [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 20s]: potential rewrite attack: #1921606 [00000000▒] <= #1921606 limit
I0805 05:57:51.540899 eth/downloader/downloader.go:1195] Peer 3fc9fe134408d85e [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 20s]: potential rewrite attack: #1921606 [00000000▒] <= #1921606 limit
I0805 05:57:52.270435 eth/downloader/downloader.go:1195] Peer 37efa7e32ae675b8 [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 20s]: potential rewrite attack: #1921606 [00000000▒] <= #1921606 limit
I0805 05:58:28.838118 eth/downloader/downloader.go:1195] Peer 4b1f3a45968d9c89 [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 20s]: potential rewrite attack: #1921606 [00000000▒] <= #1921606 limit
I0805 05:59:24.985412 eth/downloader/downloader.go:1195] Peer 98f2b6ff1b2fd3d7 [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 11.829638946s]: potential rewrite attack: #1922167 [00000000▒] <= #1922167 limit
I0805 05:59:36.790843 eth/downloader/downloader.go:1195] Peer 4b1f3a45968d9c89 [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 11.829638946s]: potential rewrite attack: #1922167 [00000000▒] <= #1922167 limit
I0805 05:59:38.699549 eth/downloader/downloader.go:1195] Peer 5228df422a51dcec [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 11.829638946s]: potential rewrite attack: #1922167 [00000000▒] <= #1922167 limit
I0805 05:59:41.244206 eth/downloader/downloader.go:1195] Peer 0ed8a3a4636f5fc0 [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 20s]: potential rewrite attack: #1922167 [00000000▒] <= #1922167 limit
I0805 05:59:46.988710 eth/downloader/downloader.go:1195] Peer 39c0a789f3680708 [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 20s]: potential rewrite attack: #1922167 [00000000▒] <= #1922167 limit
I0805 05:59:55.412711 eth/downloader/downloader.go:1195] Peer c13ee7b82fd3898d [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 20s]: potential rewrite attack: #1922167 [00000000▒] <= #1922167 limit
I0805 06:00:03.302546 eth/downloader/downloader.go:1195] Peer 78129e171bb7484a [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 11.829638946s]: potential rewrite attack: #1922167 [00000000▒] <= #1922167 limit

Changes for ECIP-1010 aren't applied to an existing chain. See utils/flags.go:794 (and below for empty chain)

We need to enabled DieHard if it wasn't disabled before

System information

Geth version: geth 1.4.17
OS & Version: Linux
Commit hash : (if develop)

hello

 i use geth1.4.17 right now with parameter --oppose-hard-fork
can i update version 3.0 base on geth1.4.17(eth)

thanks

I have built geth from the source (git cloned at 28 jul, 01:09).
I have the full blockchain downloaded.
BUT
geth is constantly warning about Bad block #1920000, and worse - it is filling my download channel almost to 100%.
Before I reached the last block this was rare event.
Applying screenshot - on the top is RX 1.54MiB/s, on the bottom TX ~50KiB/s.

UPDATE

The full download channel event lasted for an hour.
Now the warnings are still there but maybe this traffic is from the blocks. At the beginning I downloaded them in batches of 2048 (maybe compressed) and the traffic was very low.

UPDATE 2

Now I had peaceful period - 60 blocks without the warning and the traffic is low.
Attaching log.

geth.log.txt

UPDATE 3

As I am watching both the log and the traffic graph I can say - there is strong correlation between the warning "Bad block #1920000" and a traffic spike.

How a traffic spike looks:

We have pulled in fixes from the original maintainers and are currently testing.

If any golang enthusiasts want to take a whack at comparing un-synced changes between this repo and ETHF reach out.

Please post here if you would like to gain membership to the ethereumproject organization. Please introduce yourself, tell us your skillset and how you can contribute to the project.

We will try to remain open as possible but everyone will needed to be added on a trial basis to prevent potential abuse.

make geth does not work:
build/env.sh go build -i -v -ldflags '-X main.gitCommit=50dd6cf024ffa6bd363fec783bdf680b2bd3d2ae' -o build/bin/geth ./cmd/geth
cmd/geth/main.go:31:2: no buildable Go source files in /home/jbrown/go-ethereum/build/_workspace/src/github.com/ethereumproject/go-ethereum/Godeps/_workspace/src/github.com/ethereumproject/ethash
Makefile:16: recipe for target 'geth' failed
make: *** [geth] Error 1

Potential conflict when new forks are introduced. Always use fork configuration

Sometimes (but not always) geth.TestIPCAttachWelcome test fails on Linux

Failed
run_test.go:259: (stderr) I1001 15:12:35.103427 ethdb/database.go:82] Alloted 128MB cache and 1024 file handles to /home/ubuntu/TeamCityAgent/temp/buildTmp/geth-test388129057/chaindata
run_test.go:259: (stderr) I1001 15:12:35.123755 cmd/utils/flags.go:835] --------------------------------------------------------------------------------------------------------------
run_test.go:259: (stderr) I1001 15:12:35.124003 cmd/utils/flags.go:836] Loading blockchain: �[36mgenesis�[39m block "�[36m0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3�[39m".
run_test.go:259: (stderr) I1001 15:12:35.124149 cmd/utils/flags.go:837] 4 blockchain hard-forks associated with this genesis block:
run_test.go:259: (stderr) I1001 15:12:35.124294 cmd/utils/flags.go:851]  Homestead hard-fork at block 1150000 
run_test.go:259: (stderr) I1001 15:12:35.124341 cmd/utils/flags.go:851]  Diehard hard-fork at block 3000000 
run_test.go:259: (stderr) I1001 15:12:35.124384 cmd/utils/flags.go:851]  Explosion hard-fork at block 5000000 
run_test.go:259: (stderr) I1001 15:12:35.124428 cmd/utils/flags.go:851]  ETF hard-fork at block 1920000 resulted in a network split.
run_test.go:259: (stderr) I1001 15:12:35.124468 cmd/utils/flags.go:853] Geth is configured to use the �[32mEthereum (ETC) classic/original�[39m blockchain!
run_test.go:259: (stderr) I1001 15:12:35.124508 cmd/utils/flags.go:854] --------------------------------------------------------------------------------------------------------------
run_test.go:259: (stderr) I1001 15:12:35.124931 ethdb/database.go:169] closed db:/home/ubuntu/TeamCityAgent/temp/buildTmp/geth-test388129057/chaindata
run_test.go:259: (stderr) I1001 15:12:35.125889 ethdb/database.go:82] Alloted 128MB cache and 1024 file handles to /home/ubuntu/TeamCityAgent/temp/buildTmp/geth-test388129057/chaindata
run_test.go:259: (stderr) I1001 15:12:35.322127 ethdb/database.go:82] Alloted 16MB cache and 16 file handles to /home/ubuntu/TeamCityAgent/temp/buildTmp/geth-test388129057/dapp
run_test.go:259: (stderr) I1001 15:12:35.347339 eth/backend.go:172] Protocol Versions: [63 62], Network Id: 1
run_test.go:259: (stderr) I1001 15:12:35.347956 eth/backend.go:201] Blockchain DB Version: 3
run_test.go:259: (stderr) Fatal: Unable to attach to remote geth: dial unix /home/ubuntu/TeamCityAgent/temp/buildTmp/geth-test197874762/geth.ipc: connect: no such file or directory
run_test.go:149: Output mismatch at ◊:
    ---------------- (stdout text)
    ◊Fatal: Unable to attach to remote geth: dial unix /home/ubuntu/TeamCityAgent/temp/buildTmp/geth-test197874762/geth.ipc: connect: no such file or directory

    ---------------- (expected text)
    Welcome to the Geth JavaScript console!

    instance: Geth/v1.4.11-stable/linux/go1.7.1
    coinbase: 0x8605cdbbdb6d264aa742e77020dcbc58fcdce182
    at block: 0 (Wed, 31 Dec 1969 19:00:00 EST)
     datadir: /home/ubuntu/TeamCityAgent/temp/buildTmp/geth-test388129057
     modules: admin:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 shh:1.0 txpool:1.0 web3:1.0

http://build.ethereumclassic.org/viewLog.html?buildId=262&tab=buildResultsDiv&buildTypeId=GoEthereumClassic_Develop_TestLinux

Bunch of tests:

• geth.TestAccountNewBadRepeat
• geth.TestUnlockFlagAmbiguousWrongPassword
• geth.TestUnlockFlagPasswordFileWrongPassword
• geth.TestUnlockFlagWrongPassword
• geth.TestWalletImportBadPassword

And it seems there're same reasons, test code ignores one of the output lines (maybe because it goes to stderr). Notice that tests expects Fatal: Passphrases do not match, which is exists run_test.go:259: (stderr) Fatal: Passphrases do not match but got unnoticed by test

Failed
run_test.go:259: (stderr) Fatal: Passphrases do not match
run_test.go:149: Not enough output, got until ◊:
    ---------------- (stdout text)
    Your new account is locked with a password. Please give a password. Do not forget this password.
    !! Unsupported terminal, password will be echoed.
    Passphrase: 
    Repeat passphrase: 

    ---------------- (expected text)
    Your new account is locked with a password. Please give a password. Do not forget this password.
    !! Unsupported terminal, password will be echoed.
    Passphrase: 
    Repeat passphrase: 
    ◊Fatal: Passphrases do not match

http://build.ethereumclassic.org/viewLog.html?buildId=260&tab=buildResultsDiv&buildTypeId=GoEthereumClassic_Develop_TestWindows

Version 2.0.0 Die Hard

System information

Geth version: geth version1.4.10
OS & Version: Windows/
Commit hash : (if develop)

Expected behaviour

Actual behaviour

Steps to reproduce the behaviour

Backtrace

[backtrace]

Error every 12 hours . System eror

System information

Geth version: 2.0
OS & Version: /Linux ubutu 14.0.4
Commit hash : (if develop)

Expected behaviour

sync blockChain

Actual behaviour

stop sync at 172778 block, total may 242xxxx

Steps to reproduce the behaviour

./build/bin/geth --rpc --cache=512 --unlock 0xf28cc406d38ecb861973xxxxxxxxxxxxxxxxxxxx

Backtrace

[backtrace]

what 's wrong with geth ? it runs normally two days before, it cannot sync from yesterday, how to fix it?

I have started merging in release/1.4

• Move fork data into a standard structure to remove the hard coding
• Disconnect from peers on other side of split
• ...

A recent feature that was added to Bitcoin which increases peer privacy significantly.

Just got following when tried to continue an existing chain.

github.com/ethereumproject/go-ethereum/core.(*ChainConfig).IsExplosion(0xc820875100, 0xc8203f6760, 0xc820012300)
    go-ethereum/build/_workspace/src/github.com/ethereumproject/go-ethereum/core/config.go:72 +0x8d
github.com/ethereumproject/go-ethereum/core.CalcDifficulty(0xc820875100, 0x58047383, 0x57fcb6f1, 0xc8201f2b80, 0xc8201f2ba0, 0x0)
    go-ethereum/build/_workspace/src/github.com/ethereumproject/go-ethereum/core/block_validator.go:263 +0xcd
github.com/ethereumproject/go-ethereum/miner.(*worker).commitNewWork(0xc8202b06c0)
    go-ethereum/build/_workspace/src/github.com/ethereumproject/go-ethereum/miner/worker.go:464 +0x62d
github.com/ethereumproject/go-ethereum/miner.newWorker(0xc820875100, 0x0, 0x0, 0x0, 0x6b173a8, 0xc8202b0240, 0x6b173a8)
    go-ethereum/build/_workspace/src/github.com/ethereumproject/go-ethereum/miner/worker.go:151 +0x5b6
github.com/ethereumproject/go-ethereum/miner.New(0x6b173a8, 0xc8202b0240, 0xc820875100, 0xc82119fb60, 0x6b170f8, 0xc82000aa90, 0x6b170f8)
    go-ethereum/build/_workspace/src/github.com/ethereumproject/go-ethereum/miner/miner.go:55 +0x5d
github.com/ethereumproject/go-ethereum/eth.New(0xc8211a42c0, 0xc8202b0000, 0x4029b58, 0x0, 0x0)
    go-ethereum/build/_workspace/src/github.com/ethereumproject/go-ethereum/eth/backend.go:276 +0x183c
github.com/ethereumproject/go-ethereum/cmd/utils.MakeSystemNode.func1(0xc8211a42c0, 0x0, 0x0, 0x0, 0x0)
    go-ethereum/build/_workspace/src/github.com/ethereumproject/go-ethereum/cmd/utils/flags.go:747 +0x46
github.com/ethereumproject/go-ethereum/node.(*Node).Start(0xc820208780, 0x0, 0x0)
    go-ethereum/build/_workspace/src/github.com/ethereumproject/go-ethereum/node/node.go:167 +0x43b
github.com/ethereumproject/go-ethereum/cmd/utils.StartNode(0xc820208780)
    go-ethereum/build/_workspace/src/github.com/ethereumproject/go-ethereum/cmd/utils/cmd.go:73 +0x2d
main.startNode(0xc820396a00, 0xc820208780)

It seems to be because this was a development chain that can have an invalid forks config.

Just wanted to check if it is now possible to run geth on the Classic chain using a fast block , if doing this will put on the wrong chain, or if it just doesn't work.

If it is not working yet, it is straightforward to create such a block and add it to the client? Presumably we could use block 2000000 which is a long way downstream of the fork.

Users on reddit were asking about this, does not yet seem to be added yet.

ethereum/go-ethereum#2608

It should be easy to add if it does not get added to upstream soon.

points to ethereumproject.github.io

This is a useful tool for development, https://github.com/whatisgravity/badblocks.ethdev.com

I think we should clone the geth wiki too, so it can be read and edited.

The suggestion was made to migrate to the name getc, which makes sense and will help avoid future confusion when dealing with multiple chains.

Similar to /tests/files/BlockchainTests/TestNetwork/bcEIP150Test.bak.json

This one contains state changes related to TheDao fork on block #8, so it cannot be used as is. I think it's better to remove block 8 and 9, and use block 10 instead (hashes must be fixed).

As soon as file will be fixed and renamed to bcEIP150Test.bak.json it will be accepted by block_test.go for testing.

Rel #59

RunBlockTest expects fork blocks as parameters, which doesn't make sense as we have forks configuration data. This left from EF code (as they "don't have" any forks, so prefer to pass 3 fork block numbers as parameters everywhere). Refactor it

I've tried:
http://keys.gnupg.net/
https://pgp.mit.edu/
http://keyserver.pgp.com/
and searching Google, but there doesn't seem to be a way download the public key.

There're 3 additional tests in EF Geth: Exploit, ShanghaiLove, SuicideIssue in tests/block_test.go, we need to add them to our code

System information

Geth version: geth version
OS & Version: Windows/Linux/OSX
Commit hash : (if develop)

Expected behaviour

What possible reason do you have for not choosing 'ethereumclassic' (which is bad enough) as your github name? The only reason that I can think of is pure ill-willed deception. Shame on you.

Actual behaviour

Steps to reproduce the behaviour

Backtrace

[backtrace]

In commit [15e5b90] coming from Forked Geth there're following line in .travis.yml:

- go run build/ci.go debsrc -signer "Felix Lange (Geth CI Testing Key) <[email protected]>" -upload ppa:lp-fjl/geth-ci-testing

Which should probably be changed to our configs

I propose we defuse the difficulty "bomb" in the next updates.

Code: https://github.com/ethereumproject/go-ethereum/blob/master/core/block_validator.go#L303

Remove lines 305-309 and it should be alright.

Toughts?

Setup and install version oracle contract

Review ways it can be controlled in a decentralized way

Provide a special command line option to select chain to follow (existing ETH, ETC, testnet or a custom private chain)

• named configs
• testnet config
• select chain from command line option
• own subdir for each chain (./chaindata -> ./chaindata-classic, ./testnet -> ./chaindata-testnet, and so on) - #100
• read chain config from external JSON file - #131

The 1.4.11 release is now available, builds for each system need to be compiled and signed.

Then work can continue on the first release of Mist using 1.4.11 geth.

Instead of using if ctx.GlobalBool(TestNetFlag.Name) and params.MainNetHomesteadBlock everywhere move block configuration to testnet fork config.

It's important to show current version, as we have series of incompatible version/forks.

Expected startup screen:

I1015 23:56:25.936791 cmd/utils/flags.go:853] --------------------------------------------------------------------------------------------------------------
I1015 23:56:25.936807 cmd/utils/flags.go:873] Using Geth 3.0.0-stable-2284da90 configured to use the Ethereum (ETC) classic/original blockchain
I1015 23:56:25.936812 cmd/utils/flags.go:854] Loading blockchain: genesis block "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3".
I1015 23:56:25.936822 cmd/utils/flags.go:855] 4 blockchain hard-forks associated with this genesis block:
I1015 23:56:25.936835 cmd/utils/flags.go:871]  Homestead hard-fork at block 1150000
I1015 23:56:25.936846 cmd/utils/flags.go:871]  ETF hard-fork at block 1920000 resulted in a network split (support: false)
I1015 23:56:25.936854 cmd/utils/flags.go:871]  GasReprice hard-fork at block 2500000
I1015 23:56:25.936862 cmd/utils/flags.go:871]  Diehard hard-fork at block 3000000
I1015 23:56:25.936874 cmd/utils/flags.go:874] --------------------------------------------------------------------------------------------------------------

• [2cd7a03] - trie: fix regression that linked all downloaded nodes together
• [40cdcf1] - trie, core/state: improve memory usage and performance
• [3c836dd] - core/state: optimize GetState
• [90fce8b] - core/state: rename Delete/IsDeleted to Suicide/HasSuicided (refactor)
• [1f1ea18] - core/state: implement reverts by journaling all changes

When started for Testnet app doesn't show information banner with forks/version details

System information

Geth version: geth-ARM-20160727-1.4.10-6aaf5f3
OS & Version: Ubuntu Mate 16.10 ARM

Expected behaviour

The tarred/zipped binary to extract

Actual behaviour

tar -zxvf geth-ARM-20160727-1.4.10-6aaf5f3.tar.gz
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

Steps to reproduce the behaviour

tar -zxvf the latest binary of geth classic