scientaster's comments

Unfortunately, since everything is off chain in third parties' hands, bitcoin is slowly becoming what it meant to replace.

Good analysis of the code, and nice correction. Agreed that you should always check your sends' return values, too! In this example you have to send more than the last guy, so I think a recursive call would still put in more ether than would be withdrawn. Still undesired though.

If it were fleshed out more it should probably return the ether to the last depositor instead of the purchaser.

Thanks for the feedback!; I'm tempted to turn this into an example Dapp later today.

It's not equivalent to what OP made, the logic is slightly different. It took 5 minutes and it was just to demonstrate how easy it would be to make something similar. If you wanted to mirror OP you could build out the pixel struct to have a color to value mapping.

The penny auction one is even easier:

  bytes3[10000][10000] board;
  function colorPixel(uint x, uint y, bytes3 color) onBoard(x, y) { 
    board[x][y] = color;
  }

Users would only have to pay the gas cost of using the ethereum network, the contract wouldn't hold any funds itself. Again, it's pretty much whatever you make out of it. You're not really constrained when it comes to building in logic into these contracts, anything (logically) you can do with any other languages is possible here.

Would have been much easier with an ethereum smart contract. No gimmicky address list, it's a crowdsourced picture in the blockchain.

  contract Place {
    struct Pixel {
      bytes3 color;
      uint lastPayment;
    }

    Pixel[10000][10000] board;

    modifier onBoard(uint x, uint y) {
      if (x > 10000 || y > 10000) {
        throw;
      } 
      _;
    }

    // Accepts funds, if the funds sent are greater than funds for that pixel last, change the color.
    function colorPixel(uint x, uint y, bytes3 color) payable onBoard(x, y) { 
      Pixel p = board[x][y];
      if (msg.value > p.lastPayment) {
        msg.sender.send(p.lastPayment); // refund previous price of pixel
        p.color = color;                // set the color
        p.lastPayment = msg.value;      // set new cost to whatever the person sent in
      } else {
        throw;
      }
    }
  }

May contain an error or two, but that's the general gist of it.

While I haven't read the contract, that is a definite possibility. Most applications that require an 'Oracle' (a trusted source of information i.e the bot) can be written in a way that a deadlock would occur if their service was down, for example. That being said, a smart-contract can be written to give refunds in the case of an expiration, disallow the maintainer from cashing his own pull requests (though he could make another account), and other logic like that.

It's very powerful; but when the smart-contract world interfaces with the unpredictable outside sometimes the logic doesn't line up.

Basically a github maintainer can add their project to commiteth so that whenever someone posts an issue with a label "bounty" a bot posts an address. That address is an ethereum smart contract. People all around can send ETH to that address in order to add incentive to the fix. In Ethereum, contracts can have balances just like wallets.

When a pull request comes in that says it fixes that issue, the bot sees that. Through the smart contract it authorizes the package maintainer to disburse the funds to the fixer at the maintainer's discretion.