New BSIP: Prediction Market Improvements

[abitmore]

Related discussions:

• Prediction markets can suffer a black swan bitshares-core#460
• Understanding prediction markets bitshares-core#1776

Current behavior:

• When the outcome of a PM is 1, the issuer can globally settle with 1, the price feed producers can feed 1 as well (which will trigger a black swan event then globally settle at 1), the result is same.
• When the outcome of a PM is 0, the issuer can globally settle with 0, but
  • the price feed producers are unable to feed 0 (which is a bit complicated to fix),
  • even if they feed a very small price e.g. 0.0001, the market won't be globally settled since a small price won't trigger a black swan event.

The final fix would be:

• allow and only allow feeding 0 or 1
• when there are enough feeds, global settle at median feed price.

By the way, settling at 0 means the market fees collected by the asset issuer/creator and shared to referral program worth zero. That's not a good business.

Core exchange rate of PM need to be considered as well. I think the best approach is to claim all CORE asset from the fee pool thus prevent the asset from being used to pay fees.

[pmconrad]

allow and only allow feeding 0 or 1

IMO this cripples the usefulness of prediction markets. An example would be a PM that pays out in relation to the results of a poll. The idea is that the trade price is expected to close in on the actual poll result as the poll date approaches, and the PM in this way predicts the outcome of the poll (hence the name "prediction market").

It makes some sense to let feed producers define the payout of the PM. This would enable the use of feed producers as an external oracle "witnessing" the outcome of the event, and thus make the PM more trustless than letting the issuer alone decide on the payout. IMO this would require significant remodelling of the whole PM logic.

Changes to the feed logic for PMs must consider that the feed not only provides a "fair value" for the asset in terms of the underlying, but also defines the core exchange rate of the asset.

Finally, I'd like to question if we should tackle this at all. PMs are closer to gambling than anything else we have, which means we are opening up a totally separate set of regulatory problems. It might be wiser to leave this to a dedicated chain like Peerplays.

[ryanRfox]

What type of prediction market(s) can the protocol support today? What do we intend to support with this BSIP?

TYPES OF MARKETS

"Prediction markets have at least two outcomes. They can be binary (yes or no), categorical (who will win the World Cup?) or scalar (What will the price of FB be on December 31, 2018?). Categorical markets can have multiple outcomes. Using the World Cup example, choices could be a) France b) England c) Germany d) Argentina e) Brazil, etc. Scalar markets have two outcomes - long (the price will rise) and short (the price will fall)."

Reference: https://www.circle.com/marketing/pdfs/research/circle-research-prediction-markets.pdf

[pmconrad]

Scalar markets have two outcomes - long (the price will rise) and short (the price will fall).

I think this description makes no sense. Scalar markets have a (mathematically) unlimited range of outcomes. In practice, only a limited set of outcomes is possible.

Binary markets are a subset of scalar markets with only two possible outcomes.

A categorical market can be approximately represented by a set of scalar markets. (A real categorical market will have built-in restrictions for the possible outcomes that are not present in a set of scalar markets but can be externally enforced by the issuer. E. g. in the world cup example, one binary market per team could be set up, but there is no technical restriction that prevents two teams winning simultaneously.)

Thus, we currently support all three types of PMs, with the limitation that scalar markets can only have an outcome in the [0.1] range. Using scaling, it is still possible to represent scalar markets appropriately, making outcomes that cannot be represented very unlikely. E. g. it would be possible to create a PM backed by USD that pays out 1/1000 of the FB closing price on Dec 31, 2019 at NYSE. Only if the price goes above $1000, the PM pays out 1. Similarly, leveraged futures can be created in the form "this PM pays out $1 per $100 that the FB price is above $150 on Dec 31, and 0 if it drops below $150".

IMO feed-producers are not needed for PMs. The only thing that needs to be changed is that PMs can suffer a black swan, and because that is a bug we don't need a BSIP to fix it.

[thontron]

If there are no feed-producers how is the oracle function served?

[abitmore]

@thontron the asset issuer globally settle the asset at a price.

[thontron]

Okay thanks @abitmore

I think the term 'issuer' is confusing here because anyone can collateralize and issue/offer the event asset. So if I understand you, the controller of the asset parameters/id is the only entity that can resolve currently. But if we're thinking of bsip then we want more uniform settlement. Either a separate multi-signature account like committee or pure voting. We already ask BTS holders to vote for proxy/committee/witness - we could possibly add 'vote for settlement or not' for each PM. The asset creator could create a griefing process by which potential bad actors who give bad information can be penalized.

[abitmore]

My thoughts about the PM topic so far:

• Expiration
  • Add an expiration time to PMs, a PM can only be resolved after the expiration time.
  • Add an operation so the expiration time can be updated when needed, E.G. when an event got postponed. Only the resolver (see below) can update the expiration.
• Resolver (oracle)
  • Add a field to indicate who can resolve the PM, E.G. the issuer, witnesses, committee members, or another group of accounts.
    • the issuer is who benefits from the PM (E.G. market fees), the resolver is who works for the PM.
    • the resolver should be self-managed but not be update-able by the issuer after the PM "started" (E.G. total_supply > 0).
      • although when BSIP40 is ready, the issuer can specify another group of accounts to resolve the PM on behalf of herself, it's not ideal for the use case because the issuer would have the ability to update the resolver.
  • A threshold is needed if resolver is a group of accounts.
  • Need logic to deal with change of group members.
  • Implementation specific:
    • For witnesses and committee members, we can use witness-account and committee-account as resolver to get around the "change of group members" issue as well as the threshold issue, a con of this is the issuer can't decide the threshold.
    • Similarly, for another group of accounts, we can use account authority settings by creating another account and properly configure authorities of that account.
• Price feed
  • decouple price feeding from global-settlement of the PM (in other words, fix the bug about black swan event);
  • price feed is still useful for maintaining CER, but the issuer can decide whether to use this feature
• Resolution
  • The resolver resolves the PM by globally settling.
    • Implementation specific: if we design multiple accounts as resolver, but not one multi-auth account as resolver, we may need logic to handle the threshold and etc.
  • Allow PMs to be settled between 0 and 1 to allow more use cases.
    • Perhaps add a type field, the issuer decides the type of the PM when starting the PM (able to update when total_supply == 0). If a PM is pre-defined as "binary" prediction market, it can only be settled at 0 or 1.
  • Add an option to "cancel" the PM E.G. when a scheduled event is cancelled. The implementation can be globally settling at 0.5.

[abitmore]

@thontron the word "asset issuer" is broadly used because it's the name of a data field in the code. It does lead to confusion. Actually we tend to call the account as "asset owner", but it's also a bit confusing because it's similar to "asset holder" (an account that "owns" an amount of that asset).

[thontron]

For Resolver: don't we already have that capability? In asset page there are toggles for committee/witness price feed - or manually add witnesses.

[abitmore]

@thontron they're "price feed producers" which is described in OP. There is a bug which led to this discussion.

[pmconrad]

IMO these suggestions lead in the wrong direction. (Except for the bugfix of course.)

PMs are mostly a business opportunity. A business would create PMs, promote their use, earn income from trading fees. Such a business would want to retain control over assets and their resolution, and would be unlikely to hand resolution over to an independent oracle. OTOH a business will be unlikely to cheat on its users by resolving wrongly because that would instantly destroy its reputation and all potential for future revenue, so an oracle does not add much trust for the users. In the same way I don't see that an expiration date would serve a useful purpose.

For cancelling a PM, how would you imagine that to work? You can't roll back all transactions that have been made on a given PM. I think the best option is to resolve the PM to a "fair" value - where "fair" cannot be determined by the chain but will in the end be decided by the business owner.

What I think is MUCH more important for a business is a possibility to re-use PMs after resolution. This is difficult though, see discussion is BSIP-17.

[abitmore]

a business would want to retain control over assets and their resolution

In my suggestion, the option that the asset owner or a group controlled by the asset owner to resolve/manage the PM still exists, so it doesn't harm the use case you described. Adding independent oracles is for other potential use cases (I do admit it's my assumption based on discussions in Telegram).

[thontron]

@pmconrad To me leaving the PM toolkit open and hoping businesses build a business for PMs is a missed opportunity for the network to grow itself. Obstacles to a PM business on BitShares:

1. PMs are hard to explain to public
2. PMs are illegal in most jurisdictions so a real-world entity would face significant and maybe prohibitory regulatory risk
3. A sophisticated firm that could offer this service would probably be better served on one of the larger smart-contract/PM platforms with more users/attention.

@abitmore I like this idea. It would be great to have a dynamic account like the stealth account that is managed by the holders of a free floating token.

[pmconrad]

@thontron so you're saying we should remove PMs in order for the network to grow?
I agree with your point 1, but it also holds for most of the cryptosphere.
I doubt 2 - I would think they are regulated but not illegal. Complying with regulation is what the business must care about (which is another reason why PMs are mostly for businesses).
3 is also true for everything we do here, but not a reason to stop everything.

Also, this issue here is about improving prediction markets. Having accounts managed by holders of a token is an entirely separate thing.

I do not mind PM outcomes be controlled by a distributed oracle. I just don't see a use-case that justifies the required effort.

[thontron]

@pmconrad Thanks for thoughtful reply.

I don't suggest removing PMs. I want PMs to run more organically on the BTS network and prefer PMs not go the "gateway" model. Think this is not controversial - why push value to edge/private company when can keep on protocol itself.. Sort of a meaningless distinction between regulated and illegal in this case. The only PM exemption in the US was granted to University of Iowa Electronic Markets explicitly because they agreed to limit the number of users and total amount of value.

The dynamic account is not a separate thing at all - it goes to the integrity of the PM itself.

I can share my experience creating a PM on the outcome of a football game. UMATS - little activity because the simple dynamics of 'selling potential outcomes' is perhaps not intuitive without a financial background. Even further, why should anyone trust me or my business - especially if PMs are successful on BTS - the provider will always be subject to $5 wrench attack. I am very curious to know of another way to implement distributed oracle on BTS without the dynamic token holder controlled account.

[pmconrad]

The price feed is a distributed oracle that doesn't rely on a dynamic token holder controlled account. If we want the distributed oracle, the natural way to implement it would be to make use of the price feed infrastructure, like @abitmore suggested.

[abitmore]

@thontron found a new bug: https://github.com/bitshares/bitshares-core/issues/1981. I'll update OP. Update: it's a UI bug.

[abitmore]

Sorry, I was wrong. https://github.com/bitshares/bitshares-core/issues/1981 is a UI bug.