Apps that don’t work in Ethereum

why I will never play cards on the blockchain

Last month, a friend asked me if I’d heard of Ethereum. She had just been to an event where someone demoed a decentralized poker app, to get around gambling laws. If that was the case, my friend asked, was Ethereum legal? I had two immediate problems with this — one legal, and one technical.

As we were discussing this more, I realized that an important distinction is talking about what does and doesn’t work in distributed apps / smart contracts:

Riddle-Solver: an example which *does* work but is tricky

In this imaginary Ethereum app, the game has a riddle, and money is awarded to the first person to submit the answer (such as “the sphinx”).

The Solidity source code of Ethereum apps is public and distributed to all of the computers in the network to run in the same way. Our first task, then: hiding the answer from someone looking at our source code. We can store it as a hardcoded SHA-3 hash. If a guess is right, a hash of the guess will match the riddle’s solution-hash.

In a related post on Ethereum forums, chriseth comments that the submitter’s guess will be a public transaction, so a determined cheater could try to copy and pre-empt their solution in the blockchain. There is no such thing as a private message between two smart contracts, because third-party computers need to run the code and come up with identical results (deterministic programs). The idea proposed in the linked post feels incomplete to me.

My solution would be to divide the guess into two transactions.

• The first ‘record my time’ message (T#1) is a hash of (solution + submitter account). The app stores the submitter’s account and their message.
• Once we’re confident that T#1 has a confirmed place in the blockchain, the second message (T#2) is their answer in plaintext. The game checks T#2 to verify it’s the right solution. Then it checks the T#1 messages to find the first correct answer (not necessarily the account that sent T#2).

Storing T#1's can be messy. Solidity supports dynamically-sized arrays, but they have a considerable cost (gas) to include in a program. The docs tell us to avoid them if possible. There’s no incentive to send a false T#1, but people could do it and make us store bogus data. I’d recommend charging a fee to submit T#1, so it only benefits the solver.

A downside to all of these options is that we must trust that the game-creator is fair. If I solve the riddle and answer “the sphinx”, but the solution-hash only matches “accomplice’s secret code” or was typed incorrectly, then the game will collect fees and never pay out. If a riddle is unsolved, I would likely check the blockchain for previous answers first, to make sure I’m not cheated.

Hangman

The riddle-solver program worked, but Hangman, a seemingly similar game, cannot. The program would need to know letters and their positions. It cannot hide them with hashes, because I can quickly look up hashes for all 26 letters, or combinations like (letter-1-A, letter-2-P, letter-3-P).

The Super Bowl

Going back to the idea of avoiding gambling laws by playing with Ethereum, suppose that a smart contract allows us to place bets on the Super Bowl.

Here we run into a difference between ‘fact’ and ‘cryptographic proof’. The winner of the Super Bowl will be obvious and published in several reliable sources, but our code cannot access external information. Something external needs to tell the contract who won. Bettors cannot be trusted, majority vote could be rigged — we need to have one club-owner who tells the app which side to pay out. From a security perspective, this is little different from starting an office betting pool, and giving cash to one person to handle pay outs.

One idea that I had, is that the Solidity source code might be set up such that it *must* pay out to one of two winners. This prevents the club-owner from cashing out directly, or creating a fake third team and becoming the sole winner. But they could decide not to send a win-message, and keep the money sitting in the account.

Another concern is how the club-owner fairly closes betting before the game begins. There is a way to get Unix time out of a recent block, but it could be manipulated. There is growing interest in a project called Open Timestamps which we could rely on. The most surefire method would be to trust the club-owner to send a message to close betting. The owner needs incentive to do this before the game starts, so bettors should be allowed to add or remove funds up until closing occurs. Unfortunately this means bettors need to check back once at kickoff and make sure things are handled properly.
A particularly smart gambling site might ask for bets days in advance, and use Ethereum Alarm Clock to cut off bets at a block-number that we’re confident will be mined before the game.

Updated Dec 2018: prediction markets with cryptocurrency have been settled in misleading and false ways:

https://www.reddit.com/r/Buttcoin/comments/aao5al/augur_just_resolved_a_market_incorrectly/ [Augur may have been correct here — the disputed storm made landfall as a tropical storm]

And this one:

Augur House Elections Market: Alleged Reporter Says Republicans Won The Market

Card games

I mentioned the poker game at the beginning of the essay. My first issue was that it could keep your domain/server/account from being seized, but you can’t be sure that it will shield you from legal troubles. Cryptocurrencies won’t give away your identity, but in the process of building, promoting, and withdrawing cash from Bitcoin, many smart people have gotten found out. Someone already went to a meetup and talked about this project publicly. But the technical problems are much more concerning:

There’s no randomization in Solidity, because all of the computers need to run the same code in the same way. So either A) the deck of cards is hard-coded in a public program, B) a deck of cards is sent by public message, or C) some kind of random seed is sent by public message. In each of these cases, anyone on the blockchain could peek in and determine the location of every card in the deck.

What if the cards are secretly shuffled by a dealer app, outside of Ethereum/Solidity, and dealt into the game? We put a lot of trust into the dealer here. Even then, when they deal a card by a transaction, it will be publicly visible. So the only option is that everyone installs non-Ethereum apps, and only uses the blockchain as a medium for sending encrypted messages. This avoids the need for a central server (once everyone has downloaded your app), but doesn’t strike me as trustworthy.

There is a StackOverflow post which recommends using a particular encryption scheme and have shuffling and dealing occur on a machine which doesn’t know the identity of the cards. This still trusts the dealer to send in a full deck of cards, and relies on messaging for communication and payment— not smart contracts.

Thought Experiments

Could you make an ID verifiable via the blockchain?

A QR code and a blockchain must verify a unique, authorized, unaltered, non-transferred ID.

• You shouldn’t publish personal info on the blockchain.
• You could publish a hash of personal info on the blockchain, but if your message is predictable (for example, “Nick|mapmeld”), it’s possible for someone to find the record. They could even find out new information if it’s predictable enough (“Nick|mapmeld|15-Apr”). So add random noise or a URL before hashing.
• You don’t have enough bytes to store a photo, even on Ethereum. So you would need to create a set of trusted servers outside of the blockchain, and include a URL on the QR code.
• To avoid counterfeit IDs, you would look at who sent the ID-making transaction, and have an official list to see if the ID-maker was registered there.

Could you make a trusted payroll app?

An app which handles my pay, and warns me if pay changes are made, or if the account might not make payroll on the upcoming payday.

• The company cannot be allowed to drain the account, reduce my pay, or remove my account during a pay period.
• The company can add employees or raise pay during a pay period, but not enough to exceed the money needed on the next payday.
• The account must always have enough money on hand to message all of the employees, if for example it does payday and the account now has no money for the next payday.
• The timing of payday must be specific, so some trusted time-keeping bot must be issuing pay messages, and setting days to remove people from the next pay period.