Developing a bitAsset research program

[biophil]

The worker proposal to fund this project is now on-chain!

Worker Announcement and discussion: https://bitsharestalk.org/index.php?topic=28542
Proposal: https://www.bitshares.foundation/workers/2019-07-uccs-research-project

[biophil]

In auction theory there is a bizarre fact called the "revenue equivalence theorem," which basically says that every possible auction mechanism earns the same revenue on average unless it's a deliberately stupid mechanism (such as awarding the object completely at random). The reason this is true is that if you have an auction that normally earns X revenue, and then you change some particulars of your auction mechanism to try to get more revenue out of it, the bidders will adjust their bids accordingly and once they equilibrate you'll still only get X revenue.

Do you think the revenue equivalence theorem applies between Dutch and double continuous auctions (where both buyers and sellers post bids to exchange)?

Do you have any thoughts on Gnosis' new market structure?

Thanks for your interest. BTS can benefit a lot from formal research and peer-review.

I'm almost positive that a typical Dutch auction fits the revenue equivalence model (which means that Dutch earns the same average revenue as, say, an Ebay auction), but the result might not carry over to a two-sided market, since the classical revenue equivalence result holds for a single seller and many buyers. I'd have to do more reading.

I haven't read about Gnosis's market in a long time, but I recall when they first proposed it, the idea was essentially to run a low-speed Dutch auction for low-liquidity tokens, is that right? It seemed like a reasonable idea at the time -- but I may look further into it. Also I bet the implementation has changed a fair amount since the initial proposals.

While I can't comment on Gnosis in particular, Dutch auctions are generally considered to be pretty smart auctions because the bidding strategies are easy to understand. One of the main takeaways of the revenue equivalence theorem is that "simple auctions are best": because your revenue doesn't depend on your mechanism, you might as well make the mechanism as user-friendly as possible. Hence the popularity of English and Dutch auctions.

[JohnR]

In auction theory there is a bizarre fact called the "revenue equivalence theorem," which basically says that every possible auction mechanism earns the same revenue on average unless it's a deliberately stupid mechanism (such as awarding the object completely at random). The reason this is true is that if you have an auction that normally earns X revenue, and then you change some particulars of your auction mechanism to try to get more revenue out of it, the bidders will adjust their bids accordingly and once they equilibrate you'll still only get X revenue.

Do you think the revenue equivalence theorem applies between Dutch and double continuous auctions (where both buyers and sellers post bids to exchange)?

Do you have any thoughts on Gnosis' new market structure?

Thanks for your interest. BTS can benefit a lot from formal research and peer-review.

[iamredbar]

Support. Maybe you can propose a whole new BitAsset system rather than solving current BitAsset problems.

That would be a very good outcome from this project. However, I have a feeling that the challenges faced by BitAsset systems aren't really implementation issues.

In auction theory there is a bizarre fact called the "revenue equivalence theorem," which basically says that every possible auction mechanism earns the same revenue on average unless it's a deliberately stupid mechanism (such as awarding the object completely at random). The reason this is true is that if you have an auction that normally earns X revenue, and then you change some particulars of your auction mechanism to try to get more revenue out of it, the bidders will adjust their bids accordingly and once they equilibrate you'll still only get X revenue.

The analogy to BitAssets only goes so far, but my point is that very likely, decentralized mechanisms for price-stable assets all inherit the same set of challenges, and we won't be able to move forward well until we have a better understanding of those challenges. That's the deeper goal of the project.

[biophil]

Support. Maybe you can propose a whole new BitAsset system rather than solving current BitAsset problems.

That would be a very good outcome from this project. However, I have a feeling that the challenges faced by BitAsset systems aren't really implementation issues.

In auction theory there is a bizarre fact called the "revenue equivalence theorem," which basically says that every possible auction mechanism earns the same revenue on average unless it's a deliberately stupid mechanism (such as awarding the object completely at random). The reason this is true is that if you have an auction that normally earns X revenue, and then you change some particulars of your auction mechanism to try to get more revenue out of it, the bidders will adjust their bids accordingly and once they equilibrate you'll still only get X revenue.

The analogy to BitAssets only goes so far, but my point is that very likely, decentralized mechanisms for price-stable assets all inherit the same set of challenges, and we won't be able to move forward well until we have a better understanding of those challenges. That's the deeper goal of the project.

[abit]

It didn't work.

What are the problems with the current bitshares program?  I know Bitshares X didn't work because of liquidity issues on the shorts side -- eg they are taking too much risks.

The problem is BTS's price is not high enough, thus holders are not rich enough.
Liquidity issue is still there to an extent. Risks are there as well. Higher BTS price would lead to more bitAssets supply thus better liquidity.

[George_Bitspark]

Sounds great from the paper, looking forward to it and support your work 

[axismoto]

It didn't work.

What are the problems with the current bitshares program?  I know Bitshares X didn't work because of liquidity issues on the shorts side -- eg they are taking too much risks.

[BTSMoon]

Support. Maybe you can propose a whole new BitAsset system rather than solving current BitAsset problems.

[abit]

This is awesome.  On a similar note, I have been research myself into this regarding the evolution of Bitshares from when the peg first broke in 2014 August.  Can someone point out or know by memory how the orgininal Bitshares X worked when the peg was first introduced?  I always felt that was the most viable model for stablecoins.  Not sure why Bytemaster went off of it.

You're talking about the original oracle-free mechanism? I don't recall the specifics, but one of the reasons Dan abandoned it was that it allowed for large deviations from the peg which resulted directly from BTS price swings. In principle, those deviations would eventually correct themselves, but it wasn't meeting the goals of accurate price-pegging. There was certainly some controversy over the change and allegations that it wasn't fully tested.

I'm interested in your paper and look forward to your written work. I've been looking back through the threads and coming up with a timeframe of how Bitshares evolved and what led to the changes.  Seems like:

July 2014 - Original Bitshares launched without feed.

August 08, 2014 - Bitshares X proposed with introduction of a live feed. 

The price you short at is the "median price feed"

September 17, 2014 - Second set of changes proposed to Bitshares Market Engine. 

prioritize shorts based upon collateral rather than fee.   All short sell orders with the min limit below the feed execute *at the feed price* prioritized by collateral.

September 30, 2014 - Bytemaster adds 30 days shorts (note this is where I thought things went downhill in terms of functionality of the market engine)

When your short order is executed you will be given 30 days until a mandatory cover (without fee) is executed.

January 27, 2015 - Changes to Cover Rules - Eliminate 5% fee

(Note: shorters take on asymmetric risk of shorting + 5% fee, so bytemaster thinks removing it will help attract more shorters to bitshares)

April 16, 2015 - Bitshares 2.0 changes are proposed. This is more or less what Bitshares currently has today if I am not mistaken.

Allowing forced settlement that is initiated by LONGS after a certain number of days; the short with the least amount of collateral is forced to cover.  This LONGS get guaranteed floor on the value of BitUSD of $1.00. Forced settling merely keeps the peg closer than without it.

There is a daily limit to forced settlement; i think around 1%.

Anyhow I have the links of the actual postings if anyone wants it.  Let me know if this is all correct or not.

The margin call mechanism is missed in your description, which plays an important role.

how the orgininal Bitshares X worked when the peg was first introduced?

It didn't work.

[axismoto]

This is awesome.  On a similar note, I have been research myself into this regarding the evolution of Bitshares from when the peg first broke in 2014 August.  Can someone point out or know by memory how the orgininal Bitshares X worked when the peg was first introduced?  I always felt that was the most viable model for stablecoins.  Not sure why Bytemaster went off of it.

You're talking about the original oracle-free mechanism? I don't recall the specifics, but one of the reasons Dan abandoned it was that it allowed for large deviations from the peg which resulted directly from BTS price swings. In principle, those deviations would eventually correct themselves, but it wasn't meeting the goals of accurate price-pegging. There was certainly some controversy over the change and allegations that it wasn't fully tested.

I'm interested in your paper and look forward to your written work. I've been looking back through the threads and coming up with a timeframe of how Bitshares evolved and what led to the changes.  Seems like:

July 2014 - Original Bitshares launched without feed.

August 08, 2014 - Bitshares X proposed with introduction of a live feed. 

The price you short at is the "median price feed"

September 17, 2014 - Second set of changes proposed to Bitshares Market Engine. 

prioritize shorts based upon collateral rather than fee.   All short sell orders with the min limit below the feed execute *at the feed price* prioritized by collateral.

September 30, 2014 - Bytemaster adds 30 days shorts (note this is where I thought things went downhill in terms of functionality of the market engine)

When your short order is executed you will be given 30 days until a mandatory cover (without fee) is executed.

January 27, 2015 - Changes to Cover Rules - Eliminate 5% fee

(Note: shorters take on asymmetric risk of shorting + 5% fee, so bytemaster thinks removing it will help attract more shorters to bitshares)

April 16, 2015 - Bitshares 2.0 changes are proposed. This is more or less what Bitshares currently has today if I am not mistaken.

Allowing forced settlement that is initiated by LONGS after a certain number of days; the short with the least amount of collateral is forced to cover.  This LONGS get guaranteed floor on the value of BitUSD of $1.00. Forced settling merely keeps the peg closer than without it.

There is a daily limit to forced settlement; i think around 1%.

Anyhow I have the links of the actual postings if anyone wants it.  Let me know if this is all correct or not.

[biophil]

This sounds very interesting. You'll get my support. Looking forward to more outcome from your research. Do you have a schedule about the research, e.g. at what time you will publish what?

Thanks for your support! I have no formal proposed schedule yet, but here are some preliminary thoughts:

When the project launches, I expect to dedicate 1-2 months of my own time right at the beginning to refine the research questions and bring the student up to speed. In this time, I'd like to write two preliminary papers myself and submit them for publishing within the first 5 months of the project. These papers would serve to clarify some of the core problems and begin disseminating preliminary solutions among the community. Different parts of the academic publishing world run at different timescales, so the time between submitting a paper (to a conference) and its publication/presentation can be anywhere from 3 months (in the highly-competitive world of systems security) to 9 months (in the mature field of feedback control theory), and any time you submit a paper you run the risk that is is rejected for various reasons.

Because of these long timelines, I envision a two-track approach where we informally release information within the BitShares community far in advance of its publication in a formal academic venue. Then, as results are workshopped in the Bitshares community, we'll simultaneously prepare them formally to publish.

Welcome Philip, expect that your research will bring suggestive ideas to BTS.
I just wrote down some of my thoughts on smartcoin evolution, maybe you are also interested in the topics https://bitsharestalk.org/index.php?topic=28367.0

Thanks very much; I'll give it a good read. And this summer I'll also set up some one-on-one discussions with core community members to start gathering input on various problems.

[bitcrab]

Welcome Philip, expect that your research will bring suggestive ideas to BTS.
I just wrote down some of my thoughts on smartcoin evolution, maybe you are also interested in the topics https://bitsharestalk.org/index.php?topic=28367.0

[abit]

Here are some discussions which are maybe useful for your research:
https://github.com/bitshares/bsips/issues/164
https://github.com/bitshares/bsips/issues/161
https://github.com/bitshares/bsips/issues/160
https://github.com/bitshares/bsips/issues/135
https://github.com/bitshares/bsips/issues/156

[abit]

Thanks for the warm welcome back.

To answer a few questions:

The only thing that concerns me is it seems that you don't have a clear economy-related background, so possibly an average Joe (who don't understand computer science nor game theory nor economy) won't believe you nor your research results.

Messaging to average Joes is one of my favorite things to do -- check out my "Game Theory of Steem" series I published on Steemit a couple years back. As to my background, I actually do have training in economic thinking -- more than most computer science/engineering people, and one of my key research areas is developing algorithmic incentive mechanisms to influence human behavior. The topic of MPA/bitassets is fundamentally interdisciplinary, so anyone working on it needs access to a range of background material, and this is something I bring. In addition, the PhD student who will likely be working on the project is a software engineer with trading experience, so he brings some good relevant diversity as well.

When talking about economy, bitAsset is impacted by the impossible trinity theory. More discussions are linked below:
https://bitsharestalk.org/index.php?topic=27203.msg322852#msg322852
https://bitsharestalk.org/index.php?topic=11946.0
Looking forward to your inputs about this.

Yes, I'm aware of the impossible trinity and I'm looking forward to formalizing that kind of concept for bitassets in particular. More about my thoughts on this in the future.

Good to see you are preparing to do deep research on bitAsset, it is very necessary indeed. However, is there any specific target?  or we can we expect from your future research?

You can find a very brief summary of the project goals here. In a nutshell, we'll do two things:

• We'll ask BTS-specific questions: How should MSSR be selected? Could dynamic collateral requirements be helpful? What is the right way to eliminate global settlement as an undercollateralization safety mechanism?
• We'll ask broader price-stable-asset questions, focusing on the fundamental design tradeoffs in the space. My favorite question here concerns risk: there is a complex interplay between the behavior of bitasset shorts and the risk assumed by bitasset longs. The system can only work if the shorts assume most of the longs' risk, and yet in BTS bear markets, the shorts want to assume as little of that risk as possible. However, if the shorts offload the risk back to the longs, then the bitasset may un-peg and thus lose its value proposition, which in turn harms the value of BTS, ultimately hurting the shorts as well. Thus, the system must be designed so that this long-term risk is somehow directly "priced in" to the shorts' incentives.

This sounds very interesting. You'll get my support. Looking forward to more outcome from your research. Do you have a schedule about the research, e.g. at what time you will publish what?