front running and the lightning network

[zack]

Truthcoin is partially able to stop front running at this time. It's current solution is inefficient.

The truthcoin whitepaper describes their answer to this problem on the bottom of page 40. It involves doing POW for every bet. People with the fastest computers will be able to trade faster, so this method funds the creation of miners, and encourages traders to make bets through those miners to bet faster, which means those miners will be able to see every bet before it is published.

The only solution to front running I like so far is to do a lightning bet through a hub. Some people have been incorrectly assuming that lightning bets use more liquidity than on-chain bets. This is not true.

At first, the bet does lock up extra liquidity. But later on, we can trustlessly move the bet from the indirect path to a direct path that doesn't lock up liquidity. My recent post on Martin's forum explains http://forum.groupgnosis.com/t/how-offchain-trading-will-work/63/11

Flying Fox and Groupgnosis are both being designed for lightning betting.

[psztorc]

The only solution to front running I like so far is to do a lightning bet through a hub. Some people have been incorrectly assuming that lightning bets use more liquidity than on-chain bets. This is not true.

How do you prevent the hub-operator from front-running all of your trades?

[zack]

I prefer the batch-trading at uniform price method explained by Casey Detrio on Thursday at ethereum's devcon1. https://youtu.be/lmsOP1D8zNs?t=1h15m27s
He has contributed to this forum too.

The idea is that there are rounds of equal length of time, the rounds come at a regular frequency. When people make bets during the same round, the hub has to give them all the same price.

Different markets should have different frequencies. If you only check the markets once a day, it is in your interest to use markets with frequency of about 1 per day. Otherwise any open trades you leave are free options for traders who go online more frequently.
If all the traders can put their computers into the same building, then it will be more efficient to have the frequency be 10 per second or faster.

On-chain markets are limited by the speed of blocks. Ethereum is 12 seconds per block. It is possible to have markets with slower frequency, but not faster.

If your blockchain is the kind that forks (all POW blockchains, and Flying Fox, but not tendermint), then trades aren't finalized until they are enough confirmations deep. So on-chain trading is at risk of being front run by the miners.

Off-chain markets don't have these limitations. Trading can be as fast as sending messages. We can have markets at whatever frequency the customers want.
Hubs can self-impose rules that couldn't be imposed on miners.
It is possible to commit to promises in the channels. So if the hub breaks one of the self-imposed rules, then it loses all it's money in all the channels. All the rules can be wrapped in a merkle structure, so the proof that the hub broke a rule can be concise, even if the number of rules is very long.
Verifying proofs like this doesn't need turing completeness. Flying Fox's language is similar to bitcoin script.

There are many sets of off-chain rules that result in batch-trading at uniform price. One list of rules to achieve this:
* the hub agrees to include a bet in a particular round before he knows how many or the price at which the customer gambles.
* if the hub fails to include a bet that he agreed to include, then the hub and gambler both lose money.
* bets that are matched in the same round must all be at the same price.
* the off-chain state of each round must include the hash of the round before. That way we know that the rounds are ordered in time.
* if the hub signs 2 different channel states at the same round height, then he loses everything. That way the hub can't fork the market.

A benefit to off-chain markets is that we can update the list of off-chain rules that powers markets without having to modify the blockchain consensus code.

[psztorc]

Hubs can self-impose rules that couldn't be imposed on miners.
It is possible to commit to promises in the channels. So if the hub breaks one of the self-imposed rules, then it loses all it's money in all the channels. All the rules can be wrapped in a merkle structure, so the proof that the hub broke a rule can be concise, even if the number of rules is very long.
Verifying proofs like this doesn't need turing completeness. Flying Fox's language is similar to bitcoin script.

Well, that sounds promising. I think it would be most useful to build this as a "layer 2", you know a "Lightning Exchange" or some such thing. Ideally, users would be able to both [1] use LMSR trades at the protocol layer, and [2] deposit into a time-locked channel with new rules.

[zack]

I have been thinking of it as a layer too.

Ideally, users would be able to both [1] use LMSR trades at the protocol layer

By "protocol layer" I am assuming you mean on-chain.
The lightning network is part of the on-chain protocol. Spending money is part of the on-chain protocol.
If a LMSR was written onto the off-chain network, that would be part of an off-chain protocol.

Creating and maintaining a line of on-chain protocol costs about 100x as much as a line of off-chain protocol, because updating the code is identical to launching a new blockchain and converting the users from the old one.

Sunk costs is a powerful and destructive force.
How does it benefit the users to put LMSR on-chain?
Can you give an example of a user who would prefer to do his betting on-chain?

[psztorc]

Off-chain things are only possible because on-chain functionality exist.

LN transactions do not happen "on chain"...the blockchain has no way of knowing if they happened or not.

[zack]

Off-chain things are only possible because on-chain functionality exist.

There is a choice ahead of you.
Calling the 2 options "on-chain" vs "off-chain" was my mistake.
Instead I will call it "naive" vs "correct".

The naive choice looks like this:
trading is broken up into multiple independent interactions with the blockchain. Creating the market, trading, closing the market.
The blockchain needs to remember the state of a market between all these steps.
This choice involves writing code into the consensus protocol to manage the state of the market.
Market scoring rule, and the auctioneer, and the oracle consensus would be written into the blockchain consensus protocol. So none can be updated later.

The correct choice looks like this:
reporting on the outcome of trading is a single interaction with the blockchain that occurs between a pair of users. Creating the market, trading, and closing the market all happens as one step.
The blockchain doesn't need to remember anything about the state of any market.
This choice adds a couple words to the scripting language, very little code needs be added to the blockchain consensus protocol.
The market scoring rule, the auctioneer, and the oracle consensus protocol would be written using the scripting language, so we can update them later.

Maintaining a line of code in the blockchain consensus protocol is about 100x as expensive as maintaining a line of code in the scripting language.

[psztorc]

I'm going to go with the naive choice.