Nodes never automatically replace anything but the head block and only replace this with in a small window of time to account for 2 blocks being found 'at the same time'.   

Wouldn't there be a non-negligible probability of a fork, if for example a small subset of nodes becomes isolated from the network and produces two blocks in a row?

A fundamental design principle of Bitcoin is that the network can recover automatically from a fork caused by a network split; everyone picks the chain with more blocks.  Unless I'm missing something, your scheme always assumes the local fork is the correct one, and therefore any temporary split which causes a branch to get two blocks ahead becomes permanent.

In the thread about margin requirements, I made a detailed post about the mechanics of the market, which bytemaster said is not accurate [1].

The concern I'd like to raise is that, AFAICT, information at that level of detail exists nowhere, except perhaps in the code itself.

I believe that launching the BitShares network without a detailed specification of the intended mechanics of the market will unnecessarily endanger the security, stability, and reliability of the BitShares network.  Perhaps the specification will need to be revised as issues come up in the implementation, and perhaps parts of the specification can be developed by describing the behavior of the current code.

I firmly believe that it should be possible to understand the detailed mechanics of the market without diving into the code.  For example, I have strong objections to the proposed increase in margin requirement.  Bytemaster doesn't seem to be persuaded by my concerns.  If we had a common understanding of the market mechanics, I'm certain we could resolve this disagreement fairly efficiently.  However, without a specification, we are forced to make detailed explanations of each others' mental models of how the market works, find mismatches, and then analyze each mismatch in detail.  Also, there are many I3 or bytemaster videos, forum posts, etc., floating around.  Some of these are outdated or contradictory.  (In the linked thread, I discuss how there are currently no less than three mutually contradictory I3 / bytemaster claims about what interest short positions are charged, if any.)

It would be nice to have a single place to collect all of the currently official market mechanics.

After the specification is written, I would also like to ask for some time for the community to study and discuss it, before the launch.  Even if this means delaying the launch.  Because currently, I think only bytemaster really understands the detailed mechanics of the market.  Some changes (e.g. changing margin from 2x to 10x or vice versa) would be trivial to implement before launch, but really hard to implement after launch.  In particular, in the case of changes to the mechanics which will cause some investments to benefit and others to suffer, would be very politically risky for the maintainers to implement after launch.  Fixing bugs is an entirely appropriate task for the developers after launch; changing the terms of the system's financial instruments after people have bought them is not.

[1] https://bitsharestalk.org/index.php?topic=3015.msg42198#msg42198
 

How is my description not accurate?

My main objection is this:  What Bad Things would happen if you increased the margin requirement to 1000000x from 2x?

How do you know that 10x margin requirement isn't enough to make those Bad Things happen?

If nothing else, with 10x margin requirement, I'm thinking many investors will be scared away by the small upside and large downside.  The remaining capital will be stretched quite thinly, and most of it will be inefficiently deployed insuring extreme events.

In other words, I think 10x margin is so favorable to BitUSD holders that there won't be enough BitUSD short sellers to make the system work at any price.

Let me see if I understand the problem you're trying to solve in this thread.

Let's say Alice shorts 1000 BitUSD at a price of 0.1 BTS / BitUSD.  Bob has a pre-existing bid order which is matched to Alice's short sale.  Alice and Bob are each required to have 100 BTS in their account for this match to occur.  (For simplicity, I'm neglecting fees.)

The 200 BTS (100 each from Alice and Bob) is set aside into a "pie" that Alice initially "owns" 50% of.  Alice's equity -- her piece of the pie -- as a function of the BTS / BitUSD price is given by f(x) = 200 - 1000*x.  Initially her equity as given by this formula is f(0.1) = 100 BTS, exactly equal to the capital she contributed; it decreases as the price increases until Alice is "wiped out" (zero equity) when the price is 0.2 BTS.

My understanding is that Alice's position will be liquidated if the price rises above some liquidation threshold L.  (I think L is the average of the initial price and the wipeout price, 0.15 BTS, but I'm not sure about this.)  This means that, if the market price rises above L, a "liquidation" bid order will be placed on Alice's account automatically by the system.  If this order is matched, then the resulting purchase price is paid out of the 200 BTS "pie" set aside earlier, the negative dollars are wiped from Alice's account, and she receives the remaining BTS from the pie; the liquidation order is priced such that this remainder is exactly equal to her equity (again, I'm ignoring real-world complications like the 5% liquidation fee, or what happens if the liquidation order is only partially filled).

However, if the price rises above 0.2 BTS / BitUSD, then the liquidation bid order cannot be matched.

The fact that some BitUSD "escaped" being destroyed means that the total market capitalization (as determined by number of BitUSD in circulation times the market price) can potentially exceed its total collateral value (the sum of all the pies of all short accounts, minus the sum of all the short-holders' equity).

Is this a fair description of the problem?

Genesis.json was created by one of the open source services.

Does anybody have a link to these "open source services" which create genesis.json?

And anyone can recreate it.

Yes, if we know what parameters were used, e.g. what block the snapshot is based on.  Does anyone have that information?

I have a different solution to the SlingShot attack, which does not involve increasing margins.  I will summarize it in one sentence:

Put a speed limit on the change of the price seen by the logic which forces short positions to liquidate.

Then a temporary rise in price which lasts for a few blocks will only liquidate positions that were nearly out of capital anyway, no matter how high the price is pushed.  A great increase in price can still wipe out all existing shorts, but it happens gradually over hundreds of blocks, and in the beginning only poorly capitalized positions are liquidated.  The speed limit should make it much harder to cause a chain reaction.  People trading manually will have hours to notice what's going on and place profitable Ask orders (either selling BitUSD holdings or entering new, fully capitalized short positions at the higher price).  These new Ask orders will interrupt the positive feedback loop of price increase -> short liquidation -> bid orders -> upward price pressure -> price increase.

I wrote in great detail about this in a separate thread:  https://bitsharestalk.org/index.php?topic=3277.0

(reserved)

(reserved)