Transactions with too low a nonce get immediately rejected.
Transactions with too high a nonce get placed in the transaction pool queue.
If transactions with nonces that fill the gap between the last valid nonce and the too high nonce are sent and the nonce sequence is complete, all the transactions in the sequence will get processed and mined.
A replay attack is a valid data transmission that is maliciously or fraudulently repeated or delayed.
Extending this to blockchains, a replay attack is taking a transaction on one blockchain, and maliciously or fraudulently repeating it on another blockchain.
For example, an attacker taking someone's testnet transaction, and repeating it on the "real" ...
This is an External Owned Account, so your normal ethereum address, not a wallet contract.
In general, there are two types of accounts: externally owned
accounts, controlled by private keys, and contract accounts,
controlled by their contract code.
Update Jun 02 2017
From WARNING: Do NOT Use SafeConditionalHFTransfer! Or Use It Correctly:
The SafeConditionalHFTransfer saved a lot of ethers being moved incorrectly on the wrong chain after The DAO hard fork. So far there has been 20549 txns + 16022 internalTxns passing through the SafeConditionalHFTransfer at ...
It means that a transaction that was valid on the Olympic testnet was still valid for next release (Frontier).
If you made a transaction T in Olympic that sends Ether from address A to B, and then reuse the key behind address A in the Frontier release, that transaction T could be broadcasted again (replayed) and the transfer from A to B would happen in ...
Yes, an account before the DAO-fork will have Ether on both chains: ETH and ETHC.
It's not a double spend in the usual sense, because when you send ETH to Alice, you cannot send the same ETH to Bob. You could send ETH to Alice, and ETHC to Bob, but they are separate blockchains (similar to how you could send BTC to Charlie, except that ETHC account ...
A general solution is EIP 155 Simple replay attack protection.
Starting with Geth 1.5.3 and Parity 1.4.4, they implement EIP 155 so that your ETH transactions should be safe from a replay attack on ETC. Create another account and move all your ETH to the new address. Don't forget to backup this new account (and don't delete the old account since it has ...
The easy, low-tech way to do this for ETH held in a regular Externally Owned Account is to create two new addresses, one for each chain, and send a transaction on each chain moving your ether to a different address. Once that's done any subsequent replayed transaction will be coming from an address with no ETH in it, and will therefore be invalid.
Each transaction requires a nonce (or sequence counter) value from your account. For each transaction you submit, the nonce is incremented. This is intentional to prevent replaying transactions.
So no, you cannot send the same signed transaction again once it has been accepted by the network because the nonce value will not match.
Ropsten clients such as Geth and Parity use EIP 155 Simple replay attack protection to protect against Ropsten transactions being replayed on mainnet.
Excerpt (EIP 155 has an actual example):
v = CHAIN_ID * 2 + 35 or v = CHAIN_ID * 2 + 36, then when computing
the hash of a transaction for purposes of signing or recovering,
instead of hashing only the ...
I am led to believe that Poloniex (who have listed both ETC and ETH) are replaying transactions intentionally so as to aid the technologically 'less well informed' in getting both balances on their platform.
@Nick Johnson mentioned (somewhere) that people might be also inadvertently replaying transactions. It is not necessarily an 'attack' per se.
To avoid replay attack use EIP155 transaction types which are available since block 2675000. They incorporate chainID to the transaction signature. Make sure your wallet software is EIP155 enabled and you will be safe
The signature only signs a specific message, so attackers can't use the same signature for a different message.
There is a class of attacks called replay attacks which apply to resending the same message when the user did not intend it. This can be discussed with regard to signing Ethereum transactions, or with regard to custom signing schemes created by ...
A guide specifically for protecting against replay attacks from the TheDAO hard fork, from https://blog.ethereum.org/2016/07/26/onward_from_the_hard_fork
Users who are interested in taking any actions with their ETC,
including creating and participating in applications, converting to
another asset, etc are advised to use the splitter contract at ...
If you use a new client, such as Geth 1.5.3, it implements EIP 155 Simple replay attack protection so that your ETH transactions should be safe from a replay attack on ETC.
Using Geth 1.5.3 (or later), you should create another account and move all your ETH to the new address. Don't forget to backup this new account (and don't delete the old account since ...
I'm assuming you are sending your transactions from the hard-forked ETH chain, and your transactions are being replayed on the non-hard-forked ETC chain.
If this is the case, your problem is most likely due to the error transaction on the ETC chain causing the transaction nonce (see 1 and 2) to be out of sync between the two chains.
When a user sends a transaction to your contract using Ethereum (ETH), if that user also has ETC in the same account in the Ethereum Classic Blockchain (ETC), then that transaction could be replayed in the Ethereum Classic Blockchain (ETC) with unexpected results.
To avoid this, you can upload your contract to both Blockchains with a modifier in your ...
The replay attack allows any transaction signed in a way that is valid on both chains to be executed. So, for example, if you have an account with 10 eth in the Classic chain and 1 eth in the Ethereum chain, a pre-EIP155 transaction would allow an attacker to replay any basic balance transfer from the Ethereum chain on the Classic; a balance transfer of >1 ...
A rather weak argument against your suggestion is the following: The deployer would have to use the same private key in both test and main net. This could be considered a security risk, as private keys in test net usually do not have to be stored and handled securely, while in main net they most definitely do. Mixing the two domains would, thus, blur the ...
Transactions are given a number, called the nonce. The rule is that an account may only have transactions happen in order of the nonce.
On the ETC chain, what's likely happened is that the too-high transaction has nonce X, and no transaction afterwards (nonce X+1, X+2...) will happen, due to the unprocessable earlier transaction.
All you need to do is, ...
There is no risk in receiving ETH to an account. The account will end up with a higher ETH balance than ETC balance.
Spending from the account is where one needs to be very careful of replay attacks. For example, even though the account has a smaller ETC balance, care needs to be taken against replays because anyone can fill up the account's ETC balance (...
If you use an older wallet that doesn't support EIP155, your transaction may be replayed across the two blockchains. Are you interested in this out of curiosity or do you actually want to send ETH and ETC to the same address? If you actually want to make this transaction, would it be acceptable to send the same transaction on the two blockchains separately? ...
An attacker cannot take a signed transaction, and change the destination address (to one that the attackers controls) since that would invalidate the signature.
However, here's an example of what could happen:
Mallory buys ETC from Alice.
Alice has not taken any precautions and sends the ETC to Mallory.
Mallory replays the transaction and gets the (...
So basically the replay attack is when an account on the ETH chain sends an TX but that TX is still valid on the ETC chain so it gets execute there also.
It depends where you got the ETH or ETC. If you got it from a big exchange they have likly already split it.
The refund contract on ETC for DAOc does not have a matching account on ETH so it will not be ...
Lets say we have this tx:
Take same input raw data and resubmit it without changing chaindId:
Lets take Raw tx data:
So we get:
I don't see how the code of that contract could have been affected by the hard fork. It should work in the same way as it did 1 week ago.
About the tutorial, I would suggest you to use a more updated version of Mist (the latest one)
You can use the ETC address of Poloniex.
TL;DR always use different address for ETH than you use for ETC.
If you have an address that contains both ETH and ETC funds, generally that's bad, and you should avoid it.
What happens is you transfer ETH from that account to some other account - and then replay attacks execute the exact same transaction on the ETC chain, so the same amount of ETC ...
So you assumed that Kraken does the split for you. I shortly looked up their official comm and it's confirmed
If you have not yet split your ETH and ETC into different wallets and
are worried about the replay attack, you can safely make an ETH
deposit to Kraken. The transaction will automatically be replayed on
the ETC network if possible and you ...