How offchain trading will work

If every trade is done on the blockchain it comes with some significant limitations: block times up to 1 minute already can be unacceptable for live betting on a tennis match. Also if Ethereum gets widely adopted gas costs might increase. Already today transaction fees of 1-3 $ cents are a significant proportion of a bet value for some micro betting applications. An app where every "tap" is equal to 50 cent bet would already suffer from the transaction fee. Another reason for off chain trading might be anonymity.

Fortunately there is a solution to this problems that does not need to compromise with trading without counterparty risk.

The abstract idea of offchain interaction can be described as a few steps and components:

1. two (or more) people lock up some tokens or any state description they totally control.
2. this state can only be updated on the blockchain with a signed message of all group members
3. the members of the group can internally do transactions by creating a new state and letting it sign by everyone. The new state also has a nonce (sequence number)
4. if members of the group stop cooperating the latest state can always be written on the blockchain
5. to write the state on the blockchain anyone can submit a signed state and a small security deposit - this will trigger a challenge period. During this period a newer state (higher nonce) can be submitted, in this case the first submitter would lose its deposit.
6. If a state remains unchallenged it will be written on the regular blockchain

In the case of a (prediction) market likely only two members would form such a group. They both lock up money.

Lets take an exmaple:
Locked up 100 each.
The first state would be 100ETH /100ETH . Now there is this Hillary clinton to be president event. A new state could be: 96ETH ,10HillaryYES/ 94ETH,10HillaryNO.
Note that in a prediction market the tokens of all possible outcomes in one market always have the value of 1. So the contract can issue all outcome for 1. So the new state describes that user 1 bought 10 YES shares for 4 units and user 2 bought 10 NO shares for 6 units. If this state would be submitted the contract would take the locked 200ETH and buy 10 shares of all outcomes (yes and no) of the Hillary event and than distribute the remaining money and the shares according to the state.
However - it is not necessary to submit the state to the chain. The 2 participants could do more trades or even wait until the event is resolved. Since (e.g.) Hillary is the winner the both can agree to just update the state in a way that the yes shares become ETH and the no shares are removed: (106/94).

See the implementation here: https://github.com/ConsenSys/gnosis/blob/oracle_platform/contracts/solidity/trading.sol
(sorry - for now ConsenSys members only)

I want to add that the signed state also includes a valid_until_block information, which is defined by the user. This is needed for the following reason: The value of a trade may change quickly over time, as the likelihoods for the outcomes change. The user who wants to do a trade is signing the transaction first, puts himself into an inferior position, because he has to wait until the state is signed by the market maker. However the market maker can just wait and see how the outcomes change and might never sign it. This is why the user has to enforce that the market maker signs the transaction in a specific period of time. The general workflow would be that:

1. User signs a trade first, which is valid for a couple of blocks and sends it to the market maker.
2. The market maker either sends this immediately to the chain or more likely signs it and sends it back to the user.
3. Now both parties can submit it within the given timeframe. Having this security the user signs the same state now with a much longer validity period and sends it to the market maker.
4. The user waits until the market maker sends the signed state back. If he doesn't, the user can still submit the previously signed state within the defined time frame.

Because both signed states have the same nonce, only one of them can be send to the blockchain. If the user has to send the transaction because the market maker doesn't reply anymore, the market maker cannot send his transaction anymore to the chain.

I reviewed the contracts and the design of the off-chain trading mechanism, and it all looks good to me.

I'm curious whether market participants will find the loss of their entire trading balance to be an acceptable punishment for submitting an earlier state than the last signed state. No honest participant would submit an earlier state, so it should be fine, but it's a potential issue.

As long as the state hasn't been settled to the blockchain, the market maker is forced to hold shares. I presume this differs from most market making opportunities where the market maker can instantly issue sell orders once they've purchased shares. Are we certain that the speed increase between the two parties is worth the speed decrease for the market maker? That is, will market makers actually use this functionality instead of an on-chain alternative? If so, how long do you expect market makers to hold a pending state before settling it?

I could see an off-chain trading pool with multiple participants being potentially attractive, though significantly more complicated. If owners can trade the shares after they've been created without the block delay, few would choose on-chain options. Users would only interact directly with the contract for deposits and settling signed states from off-chain.

I'm curious whether market participants will find the loss of their entire trading balance to be an acceptable punishment for submitting an earlier state than the last signed state. No honest participant would submit an earlier state, so it should be fine, but it's a potential issue.

We have to make sure honest participants don't accedentially post an earlier state. Depending on the channel we use we could save the latest nonce on an additional serivce and check before a user submits a state.

As long as the state hasn't been settled to the blockchain, the market maker is forced to hold shares. I presume this differs from most market making opportunities where the market maker can instantly issue sell orders once they've purchased shares. Are we certain that the speed increase between the two parties is worth the speed decrease for the market maker? That is, will market makers actually use this functionality instead of an on-chain alternative? If so, how long do you expect market makers to hold a pending state before settling it?

True, as soon as the Market Maker agrees to the trade he has to buy the shares of the other outcomes. They can be offset with other trades to the same user but in general he will have to keep most of the shares. Anyways the Market Maker can always post new sell offers for the other outcomes, because he knows he owns them. Knowing he owns the shares of all outcomes he can always use redeem all outcomes for a fixed price. Alternatively when settling states they can be submit in an order which requires less buy all outcome transactions becuase all orders can be offset with each other. Our contract does not offer this yet. We need to add a check if the market maker already holds shares of the outcome the user wants to buy and only buy the difference with buy all outcomes.

Market Makers and User should hold the pending state until they run into liquidity issues. But in general it is up to them.

In principal it would be acceptable I think but this scheme comes with a big downside. To make the whole thing work in principal user and market maker (or user 2 - they are both equal) have to monitor the blockchain 24/7 so watch for invalid states to potentially react with the punishment transaction. Since normal user will not have their own server running they will most likely outsource this job. However - that would mean that they have to give the signed states to a third party. The problem now is, if they sign a newer state the third party potentially still holds the old invalid state. If the third party would now collude with the market maker/ (user 2) they could steal the users funds/shares by submitting the invalid state in the users behalf and than doing the punishment transaction.

So to make the use of a third party trustless I suggest two changes:
1) anyone can submit the requestSettlement transaction (the state now has to be signed by both) but the submitter has to add a bounty/security deposit.
2) Anyone can do the punishment transaction with a newer signed state (singed again by both) and with this claim the security deposit from step one.

With this architecture both (user 1 and user 2) could give the signed states to a third party. The third party would have a direct incentive to do the "punishment transaction" if possible since it can claim the security deposit. On the other hand no one else but user 1 and user 2 can safely do the request settlement transaction since otherwise user1 and user2 can just agree on a new (even unchanged) state to claim the security deposit.

So I would not call it slower but more capital intensive (what might be the same). To solve this problem market makers should be interconnected to trade/transfer shares off chain. We haven't figured out the solution for this but this would clearly be very beneficial. However - if the market maker has very big liquidity it is not an issue so for a first version (for example of the sport bet skin) this solution seems good enough.

We have added the ability to our contract to hold any kind of tokens. (that implement the tokens interface)

In principal that means if there would exists a token for Bitcoin and/or $ this contract could do instant lightning network like $ or Bitcoin transfers or even trades.
Of course everything can be combined with trades on the prediction market.

Having offchain trading between more than 2 people is very easy. Just add a hashlock to every bet. If 2 bets are hashlocked with the same secret_hash, then they will either both be valid, or neither will. A hub in the middle collects arbitrage and connects many traders together without ever holding customer's funds or taking risk. Many such hubs compete in parallel.

It is best if people can bet on things that haven't been created as events on the chain yet. That way the topics for betting are more private. The gamblers should only reveal what they were betting on if they disagree, and they should usually only reveal to the judge, not to the blockchain.

Ok - A and B have money locked and B and C have money locked. Now A wants to bet against C.

Indeed - this is how we want to do it. The only downside is that the "hub" needs to have a lot of liquidity (more than theoretically would be necessary) but I guess that is the reason they can take a fee.

This is also possible with our approach. The bet (we call them events) is described in a text but only the hash of it would be on the blockchain. However - since the identifier of the event and its tokens are deterministic agreements to trade on them can be made without creating the event. Only in a conflict case the event needs to be created so that the agreements/ trades/ bets can be fulfilled.

@zack: We problem we have come across with decentralized off chain trading: someone needs to make a binding offer first - now the problem is that the other party can exploit this by waiting for the price to move in one direction and than exploiting this knowledge.

Our solution are bids that are only valid until a certain block. Than both parties can expand the validity of this state so that the state needs to be never written to the chain if they cooperate. Another solution is to start with very small amounts and only make a new offer for another small amount once the first is accepted.

Those are both great ideas.

I am glad you allow betting on off-chain events, but I think you can take it even further. It is better if the oracle can judge on the outcome of a bet off-chain, so that the gamblers can see what the result of the bet would be if they put it on-chain. Then the gamblers can make the fully informed off-chain decision about the result of the bet.

The value that is destroyed by hubs locking up liquidity is used to maintain consensus in Flying Fox. Instead of POW. One of the 2 channel participants is delegated as a validator. He has a small probability of being chosen to sign each block based on how much money is in the channel.

If the rewards for being validator are high enough, and limit for the amount of money you can accept through your channel is low enough, then the hub will be paying fees to the off-line customer who opened a channel with him.
This is a form of POS mining where your computer is turned off.

This is a very good writeup about off-chain transactions that is very similar to our current implementation:

A solution to the liquidity problem:

When bets are held off-chain, if you use a 1-step lightning connection through a hub, you are using twice as much liquidity as necessary.
If it is a 2-step lightning connection, then you are using 3 times as much liquidity as necessary.

Building bets in the lightning network is a great solution to front-running. You only tell your bet to a single person, and you can grow your bet in tiny increments so that one person has minimal advantage.
But the cost of liquidity is too much.

With a hashlock, we could trustlessly move bets from one channel connection to another.

If you want to bet with someone you aren't directly connected to, you can use the hub's spare liquidity to make bets with them immediately. After enough time has passed to create a new channel, you move the bet from the long-path to the new direct path.

If there are too many channels, we can analyse the network to find a smaller set of channels capable of encoding the same bets. Nodes can trustlessly move the bets to the optimal paths.

We should charge a per-channel per-block tax to encourage people to use less channels when possible.

Having an open bet in the system is bad. Limit orders are free options. A couple proposed solutions:
1) increment your bet a little at a time, so your partner doesn't have much control.
2) increment the time limit the bet can exist for a little at a time, so your partner doesn't have much control.

Casey's talk on Thursday at DevCon1 proposed a new solution that may be superior:
He thinks we should process bets in batches at a uniform price.

The auctioneer who has payment channels with all the betters can use hashlock to trustlessly orchestrate batches.