In Bitcoin, the BTC accounting system is based on UTXOs (Unspent Transaction Outputs), which prevents the same BTC from being spent multiple times. I heard that Ethereum has a simpler account balance system, but I do not know the details. How does Ethereum's account balance work?

If I have a message sending 1 ETH from Alice to Bob, what is preventing that same message to be used more than once? Is there a sequence number system (like TCP)?

If Alice first signs a message sending 1 ETH from Alice to Bob, and then signs a message sending 1 ETH from Alice to Charlie, can the second message be confirmed before the first?

up vote 13 down vote accepted

Each account has a globally accessible nonce which prevents same-chain replay attacks and double spends. The nonce is the sequence number, which miners check, because a block that has a transaction with an incorrect nonce is an invalid block (other miners won't build on top of it). (The nonce does not protect against cross-chain replay attacks.)

Second message (with higher nonce) can't be confirmed before the first.

See this for complementary details such as:

a global state stores a list of accounts with balances, code, and internal storage

a transaction is valid if the sending account has enough balance to pay for it, in which case the sending account is debited and the receiving account is credited with the value

  • 1
    On node A I have account x at nonce n. On node B I have account x at nonce n i.e. I have copied the keystore. At the same moment in time I execute a call to contract C on Node A to pay all funds to Alice and on node B to pay Bob all funds. Both nodes execute the code locally analyse the global store and see that I can pay both, but because the current block has not yet been mined, neither node can yet be aware of the other execution. When it comes to mining the block only one should be included, but the nonce is not yet incremented because they are both competing for the same block. – T9b Mar 10 '16 at 14:49
  • 1
    ... so I'm asking how this would be resolved? – T9b Mar 10 '16 at 14:53
  • 1
    It's resolved by other miners, who choose whether to extend the blockchain presented by node A, or the one presented by node B. If there are no other miners, you will have 2 chains, like running multiple private blockchains or testnets. – eth Mar 10 '16 at 15:55
  • 1
    I think this question deserves a testcase, because your answer presumes that both node A and Node B are mining nodes, and that they have successfully mined their own transaction causing a fork. In reality both nodes may not have mined anything, (they may not even be mining nodes) which would mean that until a block is mined both transactions would circulate the network, and both could end up being mined into the same block.. – T9b Mar 10 '16 at 16:31
  • 1
    One point to keep in mind when thinking about double spend prevention is that ethereum is a decentralized network, and (quite often) you're going to have portions of the network that have a view of the blockchain that clashes with other portions. If node A broadcasted its txn in China and node B in Brazil, then different miners will accept A's and reject B's, and vice versa. In the end, one miner will mine a block and it will ONE OF A's or B's txn in it. If it had both, it would not be valid, no other nodes would accept it, and the miner has wasted electricity mining an invalid block. – almel Mar 20 '17 at 18:12

I am not providing an answer here but I am elaborating on a small discussion with @eth which is relevant to the OP's question, and I wanted to share what I have learnt, thanks to @eth and a bit of reading around.

The misunderstanding that I had was that all nodes execute code when a transaction invokes that code, and therefore assumed that the result of the execution of the code was then circulated to the network, collected and mined into a block.

This process of transaction, transmission, collection and mining to confirm, is how bitcoin blockchain works, but it is not how ethereum blockchain works and is the reason why I misunderstood why double-spends are not possible on the ethereum blockchain. The mechanism is not immediately obvious, so I wanted to explain it.

In ethereum, it is true that all nodes execute the code, but this is especially true of mining nodes. Each mining node determines the transactions it wants to execute and as it executes them it is also searching for the next block at the same time.

This means that when a mining node is lucky enough to discover the next block it has already chosen the transaction that has won and it will not execute two competing transactions with the same nonce.

In other words any given address and nonce combination can only be executed once per node and if, on the occasion it is executed, and the node is successful at finding the block the nonce would be incremented. This would cause all other nodes to reject the competing transaction because the global registry of addresses and nonces, would say that the nonce was too low, thereby excluding all double spend attempts.

I hope this helps others understand why this works.

  • This sounds like an answer to me... The question is what mechanism prevents double spends. The answer is that the miner gets to decide which transactions are included in the block, and accounts have a globally accessible nonce. – Tjaden Hess Mar 11 '16 at 1:55
  • +1 for this answer. (Original question didn't explicitly ask about double spends and I tried making question clearer. But then I didn't extend answer so thanks for explaining it.) – eth Mar 11 '16 at 19:13
  • @TjadenHess Thanks for your precise explanation: used "globally accessible nonce" to improve the other answer. – eth Jul 22 '16 at 4:31

I think I am little late for this, but this has been already answered in the following question

What is nonce in Ethereum? How does it prevent double spending?

Have a look.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.