No, it is separate from expiration. It means if the feed price goes above the call price and there are no asks in between, the margin order will execute and charge the 5% margin call fee.

Sent from my SCH-S720C using Tapatalk 2

Quote from: biophil on November 20, 2014, 08:53:56 pm

Can I also point out that any price feed script should add noise to the price feed, both in when it updates (so that nobody can predict exactly when it updates) and in what price it reports (so that nobody can predict exactly what price it will report). If the bid/ask spread is 1%, a price feed script should report a random variable whose mean is the mean of the spread, but that could take any value within there.

If people don't get it I'll post a stronger justification later.

How can you validate if the delegate is trying to manipulate that?
I don't think random numbers will help. Care to elaborate ?

Yeah, good question about delegate manipulation. That's a tricky one, but it seems to me that manipulation by delegates is a separate issue. Since there are so many delegates, there should be many feeds close to the median, so it should be difficult in general for one evil delegate to simultaneously be the median and manipulate the price. If he changes his price too much, he'll cease to be the median.

My thought with randomness is about minimizing manipulation by whales on external exchanges, which is what these Chinese guys are saying is happening.

If 90% of delegates use Alt's feed script and it publishes prices deterministically, a bad actor can tell precisely what the median price feed will be at all times. If they can tell what the feed will be, they can manipulate external prices and predict their precise effects on the median feed and profit at the expense of the credibility of the internal market.

Here's where randomness helps: if delegates don't report prices deterministically, but rather allow their reports to be randomly distributed around the true price, the bad actors will never be able to precisely predict the changes in the feed price, and their profit opportunities will be decreased.

I doubt this would completely solve the problem, but it would certainly help. I encourage all price feed script publishers to add randomness.

Sent from my SCH-S720C using Tapatalk 2

Quote from: sumantso on November 20, 2014, 08:56:47 pm

Quote from: Ander on November 20, 2014, 08:51:04 pm

Quote from: sumantso on November 20, 2014, 08:48:02 pm

I don't understand all these, but are you saying you expect the downtrend to continue?

He is saying the opposite.  He plans to sell bitUSD to buy BTS.

Yes he does, but because some have to close due to downtrend.

No, he is saying that he will has to close soon (in 6 days) due to the 30 days rule. For that person might be a wise decision to close even earlier to cut his losses.

Except that I am fairly certain that person shorted to himself, which means he has the bitUSD sitting around already to cover with. Which means I believe the impact on the market will be minimal.

Can I also point out that any price feed script should add noise to the price feed, both in when it updates (so that nobody can predict exactly when it updates) and in what price it reports (so that nobody can predict exactly what price it will report). If the bid/ask spread is 1%, a price feed script should report a random variable whose mean is the mean of the spread, but that could take any value within there.

If people don't get it I'll post a stronger justification later.

Not sure what you're asking. Are you trading in the GUI? Did you know you can "flip the market" so it shows prices upside down (I.e., bitUSD/BTS instead of BTS/bitUSD)? On a market screen, there's a little square icon up at the top near where it says bitUSD:BTS. Click it and you'll get a flipped market.

Or maybe you were asking something totally different. Could you give us an example of what you want to know?

Sent from my SCH-S720C using Tapatalk 2

Seems like "made them whole" made people think BM could somehow produce enough value to give as much as he gave nov 5th?

What he said was he would empty I3 DNS funds to give as much as possible to people who supported DNS. This means claimed balances, except that exchanges actually had a lot of "claimed" balances that hadn't moved.

At worst you should get 1/3rd of what you expected because we went from thinking we had to give 0 to people on exchanges to about 2/3rds of I3's money. But that is consistent with "making people whole with I3's entire stake."


Note I floated a proposal to use one of the dev fund keys for the bonus rather than deleting it and scaling up nov 5th holders (taking a few percent of BTS from nov 5th DNS holder to give bm's victims) but that got shot down.

Yeah, I'm not really being critical any more. You have enough to put up with as it is. It's just that saying "made them whole" was wildly ambiguous, and easy to interpret as "it'll be like BM's announcement never happened."

I remember your proposal about increasing the rescue funds; I liked it, but of course it got shot down. Did you really expect anything else? Changing an allocation after a snapshot will never be popular.

Ok so not generating the values for you was just lazy, my bad. The point was those values are a gift and can't be "wrong".

Despite cleaning out I3's DNS, this does not actually add up to much extra because BM underestimated how much stake exchanges had started trading but not claimed (buyers on BTC38).

Code: [Select]

bts to bonus: 5071959
bts for exchanges: 3381306
bts for on-chain: 1690653
total claimed DNS outside of exchanges 1402149418
BTS per DNS for normal claimed balances 0.00120575810763


Ah. yep, about 5% of what people thought they were going to get. It was a nice gesture, anyway.

Thanks for posting the numbers!