Million Ether Homepage

Storing Colors in a Pixel Grid

Million Ether Page Essential Smart Contract

Tip: Mining only when there are transactions

Tip: Using Remix IDE

Getting Started

Getting The Pixels and Ethereum Events

Building a DApp UI

Drawing in HTML Canvas

Using Websockets with Web3

Web3 and Events Over WebSockets

Drawing Pixels from the Blockchain

Viewing Pixels

Buying An Image -- Reading Pixels

Buying An Image -- Sending Transactions

Pixel bidding and structs

Payable Contracts, payable Functions

Contract Owner and require

Payable color pixel function

Buying Pixels

Sending funds from a contract

The safer way to send funds from a contract

The Pull Payment Pattern - Withdraw payments when outbid

Million Ether Homepage Summary

Auctioning Pixels

solidity

In this course, we'll build a DApp inspired by [The Million Dollar Homepage](https://en.wikipedia.org/wiki/The_Million_Dollar_Homepage). We'll build a 1 million pixel page, and each pixel can be colored by placing the highest bid.

In this course we'll walk through every step of writing a smart contract, deploying it, hosting auctions, and connecting it to the browser through web3. 

If you're looking to build real, full-stack ethereum Dapps, then this is a perfectly-sized example.

We'll build a DApp inspired by the Million Dollar Homepage, powered by an auction on the Ethereum blockchain

Let's get back to the million ether page contract. Now we that we have a grasp on how to send payments let's issue refunds when a pixel is outbid.

 function, the obvious solution would be, after we've verified that the new bid price is greater than the sold price, we should .send the funds back to the previous owner. 

  function colorPixel(uint x, uint y, bytes3 color) payable {
    Pixel storage pixel = pixels[x][y];

    // pixel.soldPrice will initialize to 0
    require(msg.value > pixel.soldPrice);

    pixel.owner.transfer(pixel.soldPrice); // --> what do you think?

    pixel.owner = msg.sender;
    pixel.soldPrice = msg.value;
    pixel.color = color;

    PixelChanged(x, y, pixel.owner, pixel.soldPrice, pixel.color);
  }

That looks pretty clean! But wait a second. What do you think about this code? Are there any problems or potential attacks? I can think of one. 

 will revert all changes if sending the funds fails. So if an attacker could craft a contract which buys the pixel and then always deliberately fails when you try to send it value, the result would be that no one could ever buy that pixel again!

Every time someone outbids them, this contract would fail to instate the new higher bid, because the transfer would fail. 

This problem shows up in Ethereum smart contracts all the time, so much so, that the solution has a name called the Pull-Payment pattern.

The idea applied here means that instead of sending the ether refund inline, we keep track of pending refunds internally. Then the account that receives the refund must submit 

---
title: The Pull Payment Pattern - Withdraw payments when outbid


slug: 'pull-payments-pattern-withdraw-payments-when-outbid'
thumbnail: https://embed-ssl.wistia.com/deliveries/d5c258048b0c77d107aad4e26cb8b0dfa43fb238.jpg

privateVideoUrl: https://fullstack.wistia.com/medias/m7fnlh2m6x



---

Let's get back to the million ether page contract. Now we that we have a grasp on how to send payments let's issue refunds when a pixel is outbid.

Taking a look at our `colorPixel` function, the obvious solution would be, after we've verified that the new bid price is greater than the sold price, we should .send the funds back to the previous owner. 

That code might look like this:

```javascript
  function colorPixel(uint x, uint y, bytes3 color) payable {
    Pixel storage pixel = pixels[x][y];

    // pixel.soldPrice will initialize to 0
    require(msg.value > pixel.soldPrice);

    pixel.owner.transfer(pixel.soldPrice); // --> what do you think?

    pixel.owner = msg.sender;
    pixel.soldPrice = msg.value;
    pixel.color = color;

    PixelChanged(x, y, pixel.owner, pixel.soldPrice, pixel.color);
  }
```

That looks pretty clean! But wait a second. What do you think about this code? Are there any problems or potential attacks? I can think of one. 

Remember that `.transfer` will revert all changes if sending the funds fails. So if an attacker could craft a contract which buys the pixel and then always deliberately fails when you try to send it value, the result would be that no one could ever buy that pixel again!

Every time someone outbids them, this contract would fail to instate the new higher bid, because the transfer would fail. 

This problem shows up in Ethereum smart contracts all the time, so much so, that the solution has a name called the Pull-Payment pattern.

The idea applied here means that instead of sending the ether refund inline, we keep track of pending refunds internally. Then the account that receives the refund must submit **a separate transaction** to pull the funds out.

Also note that any sort of math like this _should_ be checking for overflows, which we'll talk about later.

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Million Ether Homepage

WELCOMEIntroduction

Introduction:

Start Here

Module 1: Getting Started

Lesson 1: (3:23)

Million Ether Homepage

Lesson 2: (3:18)

Storing Colors in a Pixel Grid

Lesson 3: (4:29)

Million Ether Page Essential Smart Contract

Lesson 4: (1:56)

Tip: Mining only when there are transactions

Lesson 5: (7:08)

Tip: Using Remix IDE

Module 2: Viewing Pixels

Lesson 1: (6:08)

Getting The Pixels and Ethereum Events

Lesson 2: (7:15)

Gas

Lesson 3: (1:01)

Building a DApp UI

Lesson 4: (3:09)

Drawing in HTML Canvas

Lesson 5: (1:15)

Using Websockets with Web3

Lesson 6: (3:09)

Web3 and Events Over WebSockets

Lesson 7: (3:41)

Drawing Pixels from the Blockchain

Module 3: Buying Pixels

Lesson 1: (1:57)

Buying An Image -- Reading Pixels

Lesson 2: (4:51)

Buying An Image -- Sending Transactions

Lesson 3: (1:25)

Pixel bidding and structs

Lesson 4: (2:48)

Payable Contracts, payable Functions

Lesson 5: (3:35)

Contract Owner and require

Lesson 6: (2:38)

Payable color pixel function

Module 4: Auctioning Pixels

Lesson 1: (4:03)

Sending funds from a contract

Lesson 2: (3:26)

The safer way to send funds from a contract

Lesson 3: (4:37)

The Pull Payment Pattern - Withdraw payments when outbid

Lesson 4: (6:46)

Million Ether Homepage Summary

The Pull Payment Pattern - Withdraw payments when outbid