Cryptoeconomics.Study

Cryptoeconomics.Study

  • Course
  • Community
  • Contribute
  • Languages iconEnglish
    • 中文

›1.3 Replay Protection

Getting Started

  • Welcome
  • Development Setup
  • Course Overview

Ch1: Payment Processor

    1.0 Chapter Overview

    • Lecture

    1.1 Hashes and Signatures

    • Lecture
    • Code Challenge

    1.2 Payment Processor

    • Lecture
    • Code Challenge

    1.3 Replay Protection

    • Lecture
    • Code Challenge

    1.4 Account Model vs UTXOs

    • Lecture
    • Code Challenge

    1.5 Centralized Systems

    • Lecture
    • Code Challenge

Ch2: Network Models

    2.0 Chapter Overview

    • Lecture

    2.1 Networks and Synchrony

    • Lecture

    2.2 Double Spends

    • Lecture
    • Code Challenge

    2.3 Latency-Based Consensus

    • Lecture
    • Code Challenge

    2.4 Proof of Authority

    • Lecture
    • Code Challenge

Ch3 Proof of Work

    3.0 Chapter Overview

    • Lecture

    3.1 Decentralized Consensus and Blockchains

    • Lecture

    3.2 Bitcoin and Nakamoto Consensus

    • Lecture
    • Code Challenge

    3.3 Merkle Trees

    • Lecture
    • Code Challenge

    3.4 Game Thoery in Bitcoin

    • Lecture
    • Code Challenge

    3.5 Selfish Mining

    • Lecture
    • Code Challenge

More

  • Resources
  • Glossary
Edit

Lecture


Replay Protection

  • Protecting against undesired resubmission of transactions. Learn how signed messages can be used for unsavory ends! Replay protection is critical!





Slides

Google Sheets Link


Ch1.3 Overview

Replay Protection

What is replay protection?

  • making sure that a transaction can only be processed once (no double spends!)

What is a nonce?

  • A nonce is a number that is unique to every Ethereum account and attached to every transaction from that account. This number is incremented with every new transaction.

Why are nonces important?

  • Every transaction's signature is a hash of many things including the data of the transaction, the account nonce, and the account key. Thus every authentic transaction signature is unique and every unique transaction is recorded in the history. If someone tries to resend the same transaction twice, the signature will match another transaction in the history. According to the rules of Ethereum (the state transition function) this is invalid. Invalid transactions are not processed by the network. Because all nodes on the network follow the same rules, this works.

What if a node makes up their own rules?

  • Then it wouldn't be an Ethereum node because Ethereum nodes all follow the Ethereum protocol (state transition function) which determines what is and is not valid.
  • If a node goes rouge and tries to process invalid transactions they would have a different state than the rest of the blockchain. This would make all their future transactions and blocks different than the rest of the Ethereum nodes, and thus would be rejected by the blockchain.

What if the node really wants to do it anyways?

  • This is called a fork. Because nodes receive rewards for processing blocks that other nodes deem valid, it is in everyone's interest to follow the same rules. Yay cryptoeconomics.

Recommended Resources

Replay Attack - Wikipedia says it how it is.

Making Sense of Ethereum Nonce(sense) - A walkthrough of nonces in Ethereum.

What is a nonce? - Ethereum.StackExchange answer to the question: "what is a nonce?"

Ethereum Wiki - If you want a more detailed (and equaly dry) walkthrough of how exactly Ethereum uses nonces.


Last updated on 9/3/2019 by burrrata
← Code ChallengeCode Challenge →
  • Replay Protection
  • Recommended Resources
Course
Getting Started
Community
ForumContributors
More
BlogNewsletterGitHub
Copyright © 2019 Cryptoeconomics.Study