Like Toast said, I'm not going to want to run the same script everyone else is.  As far as I am concerned, every delegate should run a script with private customizations not publicly disclosed, it's much harder to game 101 different algorithms whose details are unknown, than it is to game a single published algorithm that everybody uses.

In addition, I'm not comfortable giving a third-party script access to my delegate's private key.

I've started writing a feed script, but I want to make sure it is rock solid.  No feed at all is better than a feed script that's poorly tested.

But I am pretty busy doing actual work, and doing this is pretty far down on my list at the moment.  Maybe after 1.0 is out.

Experience with the peg in the early days (before price feeds) suggests that settlement will need to be enforced.

I was under the impression that we're under feature freeze until 1.0, so most of our development effort should be going toward testing existing features and moving toward release.

So I would suggest shelving this idea until after 1.0 launches.

FWIW, BitShares itself is most tested on Mac [1] and Ubuntu 14.04 LTS.  Windows is officially supported, but in practice is something of a second-class citizen because most of the highly active developers [2] and users use something else.  If using another distribution or Ubuntu version, your mileage may vary.  The amount of support the developers can give users on unsupported OS's is officially "none."  Unofficially we do occasionally look at Github tickets and forum posts from people running into issues with non-Ubuntu-LTS distributions (or toolchains) that aren't reproducible on the officially supported distro.

[1] Most of the other developers use Macs.  I'm about the only one who actually develops BitShares on Linux, although we have many internal and community deployments on Linux servers.

[2] With the notable exceptions of dnotestein and emfrias, who do most of our Windows support among many other things.

The "provocative" post [1] raises an interesting point.  Does publishing feeds with high frequency harm the network?

The idea is if everyone's publishing price feeds very frequently, the cost to manipulate the feed is small -- the attacker can simply dump BTS on exchanges, causing a dip in the price feed, then sell much larger BitUSD holdings into margin calls at artificially high prices.  A relatively small manipulation -- only needing to clear out the order book depth immediately available on the exchanges -- can be amplified into a much larger manipulation -- margin calls to force covering at inflated prices by the entire short float.

OTOH if you have a random update interval (with some known expected value), the attack is much more expensive.  E.g. if average feed publish interval is 8 hours, then (assuming all delegates are online and honestly reporting prices) it takes 4 hours to update the median feed, so the attacker would have to sustain his dump for 4 hours, making it more expensive.

Also, "reactive" publishing -- publishing after a sudden price movement -- would also have a downside, it would mean a lot of delegates would update at the moment the attack commences.

I think we should consider the possibility that feed updates need to be done more slowly so that traders have time to move funds into / across exchanges and force any dump to break through the all the actively trading capital in the ecosystem, not just whatever happened to be immediately available on the exchange(s) when the dump occurred.

The main cost is that if there's a news event at a single discrete point in time that causes a quick price change, margin positions may not immediately be liquidated and the price would have time to fall further before the feed caught up and the positions started to unwind.

Thoughts?

[1] https://bitsharestalk.org/index.php?topic=13865.0

Translation:
总的来说，是讨论受托人喂价是否应该频繁和即时的问题。如果受托人喂价是频繁的，那么在外盘就很容易通过砸穿外盘来带动内盘的实时连环反应。但如果受托人喂价是随机的、不及时的、受托人之间频率相差很大的话，那么在外盘砸盘就需要持续很久才能达到这个目的，也增大了恶意砸盘的成本。

楼主还感觉，如果喂价变化速度慢点，那么就有利于搬砖、套利等行为，从而制约恶意砸盘。

不过，楼主认为这个方法可能有一个缺陷，如果价格变化得太快，空头仓位不能及时被平仓，等缓慢节奏的喂价改变后，这时候空头仓位的抵押品可能就没有那么充足了。 大家有啥想法？

I am posting this in response to bingo branch initiated in the repo.  I think before we make any more implementation effort, we should consider how the DAC will be organized.

I propose to have a separate asset type ("chips") for wagering.  Chips would be backed by BitUSD.  Before we begin bingo operation, chips should be issued or redeemed for $1 / chip, those BitUSD are put aside into the chip backing pool.  When 1000 chips are in existence, the bingo operation begins.  Winning bets are paid in newly created chips, losing bets result in destroyed chips.  The chip redemption value would then fluctuate based on winnings and losses, it would always be equal to the number of chips in existence divided by BitUSD in the backing pool.  This is equivalent to a bingo parlor where the commodity for wagering is equity shares in the bingo parlor.

For risk management purposes, the total of all bingo cards in play at a time can be at most 20% of the chips in existence, and players can bet at most 2% of the chips in existence on a single bingo card.  These numbers are just guesstimates, and should be re-evaluated using the Kelly criterion once a concrete pay table is constructed.

If we want chips to have a pegged redemption value (1 chip = $1), then we can have a separate assets representing equity (receive profits / losses from operations) and debt (chips).  If the house is losing, without an equity pool chips will fall below $1 (winnings paid by inflating chips come from all other players).  With an equity pool, BitUSD will flow into the chip backing pool from the equity pool to prop the value back up.  Investors will voluntarily contribute to the equity pool because the reverse flow is also possible.  If the house is winning, without an equity pool chips will grow above $1 (losses paid by destroying chips will distribute the value to all other players).  With an equity pool, the excess value will flow into the equity pool and be returned to its investors (equity pool shares will be creatable / redeemable for proportional fractions of the backing just like chips).

Current internal discussions at I3 have focused on a bingo DAC with only one investor, the yield pool.  I think bingo will have much more potential to attract new investors if we allow them a way to buy a piece of the house (i.e. put capital into equity), not to mention more capital will allow our payout table to have lower risk (or be able to offer larger prizes).

Also, note that there is nothing specific to bingo here.  We can implement other games of chance.  In fact, if we have only delegates validate chip creation / destruction, new games of chance would only require delegates to upgrade, not normal users (but all nodes would still validate all BitUSD flows and could validate chip creation / destruction from publicly available information).

I'm by no means an expert in the applicable regulatory framework, but I believe the law in much of the US treats games without rake more favorably.  And if we use the first model (where the equity in the bingo parlor is what is wagered) it could certainly be argued that players are playing against each other and the game should be legal for the same reason that private no-rake poker games are legal in many states.

Now, in the era of paid delegates, we have a lot of delegates which are being *heavily scrutinized*.  Every paid delegate is under the watchful eye of shareholders, demanding that the see evidence that the delegate has the best interests of Bitshares at heart.
We have already voted out one paid delegate, blackwavelabs, who the community noticed was not providing updates, and we were not sure if he was creating any value.

Interesting point.  If a delegate is merely a block signing provider, their service is an interchangeable commodity which doesn't individualize them very much.  If each delegate is providing unique business services, their service is no longer a commodity for which equivalent services are readily obtainable.

Where can we find the source code for the mobile wallet thin client?

Our current plan for mobile is to build the Qt light wallet as a mobile app.  The source is available at https://github.com/BitShares/bitshares/tree/develop/libraries/light_wallet

Please keep in mind this is a very early developer version.  It is still undergoing heavy development, is not documented, and I recommend using it only on testnet until it is more mature.

we would very much like to start working on this.

We always welcome community contributions.

We would appreciate any help and guidance too!

Core developers are fairly active on Skype, forum and github.

I'm trying to keep up  with the bid ask rules,  We're getting an average of 1% yield right now.  There were expectations that this would be 5% floor that was the minimum.

I don't believe a rate floor was ever implemented.  The question is, what happens when the "natural" price is below but the "nominal" price can't fall that low because of the rate floor?  In that case I think you'll see shorts demanding a premium above the feed in order to short.  I was going to say this would disrupt the peg, but on further consideration I think the effect would only be about one-twelfth of 5% (since shorts expire in a month and 5% is an APR).