Messages

There are two equivalent methods for LMSR markets. One seems to be favoured by Hanson where users set probability distributions and pay for these changes according to the worst-case difference in their  log score and the previous bet's. Alternatively, there's a buying and selling of shares interface, which is closer to the usual perception of market makers. I'm wondering if you all have any thoughts on the relative benefits of each, in terms of costs and the usability in tandem with SIB.

That's more or less how I'm doing things now (the example ethereum currency contracts support that with addresses instead of names) but the problem is that in ethereum there doesn't seem to be an obvious way to loop over the user/balance pairs without already having a list/array of all the user addresses. So you can access the balances for an address iff you have the balance for that address already.  If I'm solving it on the currency side, a solution might be to store balances in a different way. Since the contract storage is just one big array, I could have it so each address links to an index that stores the relevant balance, rather than just the balance itself. This way all relevant info is accessible to the redistribution process.

I'm currently storing votecoins using ints. As a side note, Ethereum won't support floating-point calculations, and doesn't support fixed-point calculations yet, so there's a fair amount of DIY fixed-point calculation going on at the moment. Ints are stored as 32 byte values, so assuming we start with 10¹⁸ coins, it takes >1400 voting rounds to exceed the amount it's possible to store. With 12 ballots a year, it ends up being about 118 years before it breaks. I expect something else would break the system before we reach that point.

An alternative to avoid this might be to count the last ballot that the user participated in, and updating balances by 0.9^(last ballot run - last ballot participated in) before resetting the missed ballots count to 0. This avoids some of the previously mentioned problems.

I'm not sure how to automatically cast blank ballots and still have the permissions for changing them work out well, so it might be a touch complicated for just getting it running.

I've reached a point in developing an Ethereum version of the votecoin system where I'm trying to figure out how to appropriately reward voters for participation. The problem I'm facing is that the ballot and redistribution component only has access to the votecoin addresses and balances for those who voted, making it difficult to penalise non-voters. I could refactor the system such that the ballot can query the full list of addresses, but that seems unnecessarily expensive.

The alternative is to increase the money supply by 1/9th each round, so the relative power of non-voters is reduced by 10%. It seems to work, but I'd appreciate any thoughts on this. Thanks.

What do you think the benefits of this would be, compared to implementing VoteCoin-style functionality via ethereum contracts? I've played around with the code a little, and it seems possible (and relatively simple) to implement a reputation currency, a contract to create and register decisions, and a contract to manage the ballots and voting. I've made a little headway with regards to this already, though it's likely I'll come across some obstacles.

The author of a market is partially paid according to the liquidity they provide to the market. Someone increasing Beta should probably be rewarded with trading fees proportional to the amount of liquidity they've provided. So if, say, 25% of trading fees go to the market author, after someone pays to increase Beta they get the amount they paid to increase beta, over the total maximum loss of the market maker.

So let's say the initial author provides 2000 TRU of liquidity to set the initial beta, they get 25% of all trading fees up until the point where someone increases the Beta via another 500 TRU, after which point the author receives 20% of trading fees after that point, and the other liquidity provider gets 5% of trading fees after that point.

Not sure how much sense this makes, I haven't checked out the math yet with regards to how much beta is shifted.

BMM has some interesting benefits, but they do not outweigh the costs.

I came across the same paper when I was considering experimentation with the liquidity-sensitive version of LMSR, but its utter failure to respond to market shocks as demonstrated here definitely put me off. LMSR has a lot of desirable properties, and with good trading interfaces its shortcomings are well worth the benefits it offers with regards to bounded loss, multidimensionality, etc.

Does anyone have thoughts on fixed ballot sizes vs. fixed ballot intervals?

So in a fixed ballot size, a ballot is created whenever, say, 30 decisions mature.

Off the top of my head, some benefits would be:

• Always a sufficient number of decisions in a ballot to limit perverse incentives
• Never an unmanageably large number of decisions in a ballot

And potential downsides:

• Uncertainty regarding ballot dates
• Problems with appropriate weighting of coin redistribution
• Exploitation via. creating decisions to make collusion for 51% attacks easier

I'm not sure if those benefits outweigh the downsides.