We need smart markets

Prediction markets are composed out of two things. First a mechanism to create tradable asses (shares/tokens) that gain in value if a specific event does happen or does not happen. The second component is a market place to trade those tokens. You could use a regular continuous double auction (simple sorted order book of bids and asks for one trading pair)

However - if you have ever traded cryptocurrencies you are well aware of the limitations and inefficiencies of such markets. Simplest example is a market with three trading pairs: ETH:BTC, BTC:USD and USD:ETH. Often you find situations where simple arbitrage is possible or at least the spread for one market is very big although a competitive spread could be constructed by the other two markets.

When we look at prediction markets this problem gets even bigger because the goal of prediction markets is to make more events tradable and this phenomenon occurs only in low liquidity markets when no one is incentivised to do arbitrage/market making. However, even if we would have those market makers it would be more favourable if this mechanic task is automatically done by the market place because this would increase the value people can get for their trades that do provide information.

There has been academic research on this topics ...

Features we should have:
1. Trader lock down assets € of A.
2. During a trading period they can make any kind of trades that consist of bid and offers of assest in A
3. After each trading period anyone can try to find a solution to this optimization problem of trades.

The solution should contain most importantly a single price for each asset and it should not violate any trades. If orders are set at a specific price (buy 100 ETH at $4) then the solution also have to include the quantity if the ETH price should be exactly at $4. However - the goal would be to make the solution in data size as small as possible. In addition it should contain the total trade volume and finally some a merkle root of all the trades with the state change this trades triggers as leaves. Building up the tree it should sum up the trade volume and make sure that all assets traded in total are equaling out.

With this structure it would be easy to check this merke root given the clearing prices and the needed trade volumes. Now everyone could challenge this result. If it is technically valid they can only challenge it by submitting a new result with higher volumes. If the merke root is not valid then it should be easy to challenge it. Challenges could be: a trade is not included although it should be given the clearing prices. The aggregates balances sheet of assest is not all 0 (assest are lost or created out of thin air in this trade result). The addition of trade volume in 2 trades is not correct.

The problem that I see is that if might need ln(n) challenges to prove that a given root is wrong - it would be nicer if one challenge would do it.

A more technical description will follow.

This is an article I can recommend very much: https://blog.ethereum.org/2016/02/17/smart-contracts-courts-not-smart-judges/ I explains the concept I am trying to use to verify the result in a general (and way more detailed) form.

This is beautiful. Thank you for sharing.

@zack - would you be interested working on it?

Yes, I will be adding this to Flying Fox, my state channel based cryptocurrency.
I can spend lightning payments from javascript already.
My scripting language will work well for this.

I am less confident about building it on ethereum. I am willing to try.

Interesting - I was thinking about how it can be combined with state channels (or other off chain stuff) The problem I saw is that you need a centralized place where all orders come in and it needs to be guaranteed that all orders are publicly known. If it shouldn't be a centralized entity it can only be the blockchain in my opinion although it could be a way more relaxed blockchain. With relaxed I mean it could be a write only blockchain where people can put any data they like in and the only thing that needs to be guaranteed is that this data is available.

Do we really need to wait for a new block to make each of the 100 txs? Why couldn't we put multiple of those txs into each block?

I was thinking about how it can be combined with state channels

oh, I didn't realize you could use this tech without state channels, but you are right. We could have all on-chain ethereum contracts execute this way too, which would reduce the cost of running code.
You lose the benefit of never posting the contract on-chain.
I want to have off-chain contracts that are gigabytes long. I would only ever have to post

If it shouldn't be a centralized entity it can only be the blockchain...

We can add all the properties from a blockchain that we need to the state channels.
A group of channels could contain the same merkle root of open orders. They could all get updated simultaniously by revealing a hash, like a lightning transaction.
The market manager could have to organize the channel state like a blockchain. Having a height, and signing over the height. He could commit to never signing over contradictory data at the same height. New trades are added to the state in batches, like adding a block of txs to the blockchain.
We could make the market manager commit to only updating the height when enough validators agree on the new state, or if enough POW is provided. We can rebuild any aspect of on-chain consensus off-chain.

In a sense, the channel method is centralized because of the one hub that manages all the channels. Since the relationship to the hub is trustless, and anyone can create a new hub that is just as good as the existing hub, it can also be thought of as decentralized.