<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Gates Hillman Prediction Market: The Movie</title>
	<atom:link href="http://blog.oddhead.com/2010/03/27/gates-hillman-prediction-market-movie/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.oddhead.com/2010/03/27/gates-hillman-prediction-market-movie/</link>
	<description>Musings of a computer scientist on predictions, odds, and markets</description>
	<lastBuildDate>Thu, 09 Feb 2012 08:47:34 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: David Pennock</title>
		<link>http://blog.oddhead.com/2010/03/27/gates-hillman-prediction-market-movie/#comment-2318</link>
		<dc:creator>David Pennock</dc:creator>
		<pubDate>Tue, 30 Mar 2010 12:06:32 +0000</pubDate>
		<guid isPermaLink="false">http://blog.oddhead.com/?p=1334#comment-2318</guid>
		<description>We started with Todd Preobsting&#039;s idea to charge transaction fees and feed those back into the liquidity parameter b. But what Abe came up with was much more elegant. The b parameter automatically increases proportionally to trading volume and everything fits into one closed-form cost function. Prices sum to greater than 1, but that makes sense: it&#039;s an implicit form of transaction fee (&quot;vig&quot; in bookmakers&#039; terminology). If prices do not end up too extreme, the market maker is provably revenue positive. With this market maker, liquidity is &quot;scale free&quot;. Paper should be available April 1.</description>
		<content:encoded><![CDATA[<p>We started with Todd Preobsting&#8217;s idea to charge transaction fees and feed those back into the liquidity parameter b. But what Abe came up with was much more elegant. The b parameter automatically increases proportionally to trading volume and everything fits into one closed-form cost function. Prices sum to greater than 1, but that makes sense: it&#8217;s an implicit form of transaction fee (&#8220;vig&#8221; in bookmakers&#8217; terminology). If prices do not end up too extreme, the market maker is provably revenue positive. With this market maker, liquidity is &#8220;scale free&#8221;. Paper should be available April 1.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Hibbert</title>
		<link>http://blog.oddhead.com/2010/03/27/gates-hillman-prediction-market-movie/#comment-2284</link>
		<dc:creator>Chris Hibbert</dc:creator>
		<pubDate>Sun, 28 Mar 2010 03:20:32 +0000</pubDate>
		<guid isPermaLink="false">http://blog.oddhead.com/?p=1334#comment-2284</guid>
		<description>I&#039;d be interested in seeing Abe&#039;s approach.  My approach to increasing liquidity with an AMM was just to &lt;a href=&quot;http://pancrit.org/2007/01/integrating-book-orders-and-market.html&quot; rel=&quot;nofollow&quot;&gt;integrate the AMM with a book order market&lt;/a&gt;.  As more people enter the market, the number of orders in the book increases, too, which gives more chances for someone to find a matching order, so the AMM doesn&#039;t end up doing all the selling.  

Of course, this is much harder to do when you want oodles of outcomes.  The implementation in the article cited above only works for binary markets.  I&#039;m currently working (in the background) on an implementation for multi-outcome markets.  But I&#039;m not sure my new solution would be a reasonable approach in the cases of oodles of markets.</description>
		<content:encoded><![CDATA[<p>I&#8217;d be interested in seeing Abe&#8217;s approach.  My approach to increasing liquidity with an AMM was just to <a href="http://pancrit.org/2007/01/integrating-book-orders-and-market.html" rel="nofollow">integrate the AMM with a book order market</a>.  As more people enter the market, the number of orders in the book increases, too, which gives more chances for someone to find a matching order, so the AMM doesn&#8217;t end up doing all the selling.  </p>
<p>Of course, this is much harder to do when you want oodles of outcomes.  The implementation in the article cited above only works for binary markets.  I&#8217;m currently working (in the background) on an implementation for multi-outcome markets.  But I&#8217;m not sure my new solution would be a reasonable approach in the cases of oodles of markets.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

