search

ethereumproject / go-ethereum

Go language implementation of the original/classic design of the Ethereum protocol
GNU Lesser General Public License v3.0
443 stars 166 forks source link

Send both ETH and ETC to an address, wth happen ?. #17

Closed qhatgena closed 8 years ago

qhatgena commented 8 years ago

System information

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

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
yolandaruiz commented 8 years ago

The transaction is indeed valid on both chains. This is the expected behavior. Nodes are interoperables and will relay the transaction if it's valid for whatever chain they are working on. When you start your node you have peers on both networks.

You should split all your ether before considering any outgoing transaction.

chiro-hiro commented 8 years ago

I think that is not a good idea to broadcast to all nodes even it's ETH.

qhatgena commented 8 years ago

@yolandaruiz That answer is not acceptable.

arvicco commented 8 years ago

@qhatgena This is the way Ethereum Foundation implemented this fork. They have been told before the fork that such "partial network split" will result in replay attacks, creating problems for Ethereum users. They were fully aware, and they didn't care. There are mitigation strategies to deal with it: https://github.com/ethereumclassic/README/issues/3

qhatgena commented 8 years ago

Ok, that isn't ETC fault. It was so confuse.