Getting Paid to Increase Beta

[koeppelmann]

Buying more shares of all states does have the same practical effect as increasing b

I still think this is NOT true. The market never gets more "stable" when more shares are sold. The example you came up with [4,6] vs [40,60] is kind of misleading because it suggest that both markets result in the same price but the second on has a more stable one. But this is not true. In fact the first state is the same state as [0,2] and the second state is the same one as [0,20]. Thus the second one has a complete different price. And yes: it is true, the closer the price is to 0 or to 1 the more shares you need to buy to move it. But this is a hole different story than increasing the Beta.

All blame on me if I am wrong - but I am about 95% sure I am not.

[zack]

Price function from http://blog.oddhead.com/2006/10/30/implementing-hansons-market-maker/
price1 = e^(q1/B)/(e^(q1/B)+e^(q2/B))
using the magic of wolfram alpha
d/d(q1) price1=d/d(q2) price1= e^((q1+q2)/B)/(B*(e^(q1/B)+e^(q2/B)^2))
I try plugging in 100 for B and q1, and I graph for q2 in a range:
http://www.wolframalpha.com/share/clip?f=d41d8cd98f00b204e9800998ecf8427e1ukesc2vp8

It looks like Paul is right. So long as price isn't 0.5, the amount of money it costs to move the price 1% will increase as the total amount of money invested in the market increases.

Koeppelmann is right too. This is not identical to raising beta.

I am still not sure if a tool for increasing beta would be useful. Can't we run the same market in parallel? isn't that the same?

[koeppelmann]

Can't we run the same market in parallel? isn't that the same?

True, that would have the same effect as increasing the beta. Lets say you do a second market with the same Beta is would be the same as doubling the Beta since you can now buy at both markets. It can be covert by a UI so that users do not get bothered at all.

Good suggestions.

[psztorc]

I think we're having a miscommunication here.

I am not advising people to buy exactly the same number of shares of all states. These people should just use an increase-beta transaction to "donate liquidity" (which is as easy as any other transaction). I am just saying "more shares".

You are right that the MSRs, which need to get every full set (1 share of each state) paid a total of $1, essentially subtract out the minimum state, so adding +1 +1 to each market-state would do nothing.

However, my opinion (nothing about equations) is that, in practice, as more shares are created, the distance between the Q(shares of min-share state) and Q(shares of max-share state) will increase, knocking the prices away from uniform (50% - 50%). This is why I bring up [4 6] vs [40 60] .... more activity means the distance is more likely to change from 2 to 20 (this is related to your earlier point about the market being "too" unstable (easier to get from the dull [4 6] to the more-extreme prices caused by [40 60]).

My major intuition for this is simply that all of our traditional markets (which do not use MSRs at all) become more liquid as there are more outstanding shares and a higher trading volume. Market liquidity seems to be directly a function of scale, at every other place, so why not here?

[koeppelmann]

My major intuition for this is simply that all of our traditional markets (which do not use MSRs at all) become more liquid as there are more outstanding shares and a higher trading volume. Market liquidity seems to be directly a function of scale, at every other place, so why not here?

Well, maybe this is the reason why MSR is not used at all In traditional markets it is possible to increase the liquidity by placing "open" orders. So there are open orders in the book that lead to a kind of stability. With the pure MSR market maker model it is not possible to place an "open order".

That is why I am arguing it should be possible to place traditional orders.


To make it very concrete: Lets have a look at your cool xlsx demo - the first minimal Example with Hillary becoming president.

However, my opinion (nothing about equations) is that, in practice, as more shares are created, the distance between the Q(shares of min-share state) and Q(shares of max-share state) will increase, knocking the prices away from uniform (50% - 50%). This is why I bring up [4 6] vs [40 60] .... more activity means the distance is more likely to change from 2 to 20 (this is related to your earlier point about the market being "too" unstable (easier to get from the dull [4 6] to the more-extreme prices caused by [40 60]).

Lets say the real prob for Hillary is right now 40%. A [40,20] distribution or a [20,0] will result in a price of 0.054/ 5.4%. THIS IS NOT GOING TO HAPPEN. Or the person who buy so much shares is not action rational at all. The only way larger trade can be done is by a huge sequence of small "buy_state_1/buy_state_2/buy_state_1/buy_state_2/...".

Well, in theory this can be build on top of the blockchain (I would be an external program that buys shares as soon as a certain price is reached) However - I think it is clearly preferable to have this inside the blockchain.

[psztorc]

Well, maybe this is the reason why MSR is not used at all In traditional markets it is possible to increase the liquidity by placing "open" orders. So there are open orders in the book that lead to a kind of stability. With the pure MSR market maker model it is not possible to place an "open order".

That is why I am arguing it should be possible to place traditional orders.

It is! I mention it in the whitepaper somewhere as "transferring" shares...(e) Trading Activity Section (4)

[psztorc]

But the order books themselves, surely you would agree would be madness to place into the blockchain...they would be flooded with orders.

One can still have their software open, ready to make trades, and have a lot of non-blockchain stuff happen, but the trade would be on-blockchain.

[koeppelmann]

As far as I understand NXT, Counterparty, and BitsharesX are having exactly this: a decentralized marketplace/order book and a automatic matching by the blockchain/the consensus mechanism.

So I guess it is possible.

It might be even possible to use this infrastructure for the cashcoin / share trading part. The distribution of the cash coins than need to be interpreted with the help of the votecoin blockchain. And it would be still possible to reward votecoin holders in the way you proposed in the paper.

[Bitcoinfan]

As far as I understand NXT, Counterparty, and BitsharesX are having exactly this: a decentralized marketplace/order book and a automatic matching by the blockchain/the consensus mechanism.

I think the comparison is not the same.  NXT, XCP and BTS are only expected to handle several thousand different assets. TC on the other hand, since it is a information market can accommodate for millions upon millions of different prediction markets.  This is the way I've thought about it.   I'm sure NXT, XCP, or BTS asset ledger handle this type of volume with code tweaks, improvements in bandwidth, hd capacity, etc, but a bid ask table is always going to be demanding and limiting on a blockchain.  LMSR can handle this stressed usage right from the start.

LMSR is a move forward because its as simple as things can get.

[koeppelmann]

Well, maybe this is the reason why MSR is not used at all In traditional markets it is possible to increase the liquidity by placing "open" orders. So there are open orders in the book that lead to a kind of stability. With the pure MSR market maker model it is not possible to place an "open order".

That is why I am arguing it should be possible to place traditional orders.

It is! I mention it in the whitepaper somewhere as "transferring" shares...(e) Trading Activity Section (4)

Ok, even if a LMSR only approach is used: if you can place orders like Paul says here - how is that different than a order book? I argue it would have the same size/ blockchain bloat.

[psztorc]

Because the actual trade itself is could look exactly like a Bitcoin tx, whereas the order books would have to contain this contingencies of potentially-canceled orders.

Having the blockchain contain the order book, instead of the orders, would be a little like Bitcoin containing not just a "credit card statement" list, but also a complete "shopping list" of everything I'd like to buy at various prices at which I'd like to buy those things. If I buy something, I actually moved money (it was useful and I paid a transaction fee), but I can make all the shopping lists I want at my house without bothering Bank of America.

You want to put order books and order matching into the blockchain? That seems like an insane amount of work (re: Flash Boys) for no benefit whatsoever. Will you charge tx-fee for each order placement? Will all placed-but-not-filled orders need to be 100% funded? What about cancelling orders? What if someone front-runs a cancelled order? We are going to freeze whatever algorithm you use permanently into the blockchain block-validation requirements?

It really doesn't even compare to an atomic single state update involving only one party (and no strategy), but you're free to code something up and show it to us, of course.

[zack]

If people are willing to pay their way in tx fees, then there is no harm in letting them use the blockchain as an order book.
Every additional tx fee paid makes the blockchain more valuable.

paul>You want to put order books and order matching into the blockchain?

yes, but not until we have at least one established truthcoin blockchain already with hundreds of users.

paul>  That seems like an insane amount of work (re: Flash Boys) for no benefit whatsoever.
It would be a lot of work, but I think there is a benefit. Prices are harder to manipulate, and more people are burning tx fees, so the currency raises in value faster.

paul> Will all placed-but-not-filled orders need to be 100% funded?
At first, yes.

paul> What about cancelling orders?
another tx with another fee.

paul> What if someone front-runs a cancelled order?
Whichever tx gets into a block first wins.

paul> We are going to freeze whatever algorithm you use permanently into the blockchain block-validation requirements?
Yes, that particular blockchain would be frozen with a particular algorithm for handling orders. Just like how every other algorithm in a blockchain is frozen.

I expect that I will write the order book software in ~2 years, depending upon how other stuff goes.
If someone else does it before me, I would appreciate it.