Quote from: abit on February 20, 2016, 07:58:10 pm

It's not too good if one winner wins all prizes.
Some improvements:
* to be qualify for reward, the price should be within say 3% of feed price
* when distributing the reward, weight by for example duration*quantity but not by quantity only (what if a whale places orders every block? so a minimum duration is needed? if 10 minutes is too long, how about 1 minute?)
* weight by log(quantity) instead of quantity so smaller participants will earn relatively more rewards than whales (decreasing edge effect). (but what if a whale places thousands of orders?)

Thoughts?

//update: edited the 2nd rule

very good ideas. i like the log weighting, not too excited about any time duration requirement since we could have far more active markets in the future (which we should all plan for now), and i def like the radius from feed price concept to encourage higher value liquidity on the margin. 

Has anyone worried about "self trading" sat down and attempted to strategize how they would do this in a market with at least two market makers competing for the reward?

Assume a market with a price of 1:1 and a spread of 5% on both sides.

Alice places an order at .95 and must wait 10 minutes before she qualifies for a reward.
After 9 minutes, Bob places his order at .95001. 
Alice is now unable to match herself without buying out Bob first.
Not wanting to let Bob grab the liquidity reward, Alice moves her order to .95002 and the clock resets for 10 more minutes.

This back and forth will continue until the spread is greatly reduced. The narrower the spread, the riskier the market making becomes. Who is going to place a huge wall at the top off the book?

Any rewards paid do not cover 100% of market risks which means market makers will still have to maintain a reasonable spread and there will be MANY orders in front of them.

Go ahead and attempt to name a strategy that works to abuse the rewards in light of market competition.

Lastly assume a 3rd actor, someone who knows market makers are attempting to pump fake volume just to get a reward. This actor will place their orders just in front of the market maker just to collect the spread on the market makers "back and forth" selling.

Quote from: abit on February 20, 2016, 11:01:35 am

I'm curious why the modified operation structures are compatible with old transactions. @pc ?

Good question. I'd guess that so far the extensions haven't been used anywhere, and that the serialized representation of an empty set is the same as that of an empty struct? (Except in JSON, which is what's causing the problem here.)

Quote from: onceuponatime on February 18, 2016, 03:50:19 am

Thanks a lot for your help!

First line is not legible enough. Could you outline it, or darken it or somehow make it stand out just a little more? And the "a"s and "o"s appear to be virtually the same. Can they be more distinguishable?

The whole thing is too "busy". Please try combining 3rd line into 2nd line, drop the "now", and make the 2nd line's font size smaller than top line:  BitShares 2.0 with Privacy Mode

I think that would do it. I appreciate your efforts!

I tried a few different fonts regarding the A and O but nothing looked better.. In the end I spaced it out a bit more and I think it helps define them. Also darkened the background like u asked and everything else.

Quote from: abit on February 17, 2016, 09:14:26 am

so when will you upload the Windows binaries of latest release (2.0.160216)? Thanks.

It's up now, we just had to finish testing it.

For forced settlement what about using the average BTS price over the following 24 hours as opposed to the BTS price in 24 hours?

I think it would be much harder for someone who wanted to manipulate their settlement price if they had to do it for an entire day as opposed to at a specific point in time. (Circa 24 hours after requesting forced settlement.)