(reserved)

Now I will discuss my ideas for the detailed mechanics for liquidation of short sales.

(Green Zone)  A short position is said to be "In the Green Zone" if it has at least 25% equity.  Green Zone short positions are not subject to involuntary liquidation.

(Yellow Zone)  The Yellow Zone consists of short positions with non-zero equity, but less equity than the Green Zone.  Yellow Zone short positions are subject to involuntary liquidation.

(Red Zone)  The Red Zone consists of short positions with zero or negative equity.  Red Zone short positions are subject to involuntary liquidation.  (If using Wipeout Elbow, negative equity is impossible.)

Note, the zone a given position is in depends on the Tracking Price.  Suppose Alice's position is in the Green Zone in the current block, based on the current tracking price.  If the tracking price rises in a later block, Alice's position may move into the Yellow or Red Zone.

In "normal" market conditions, poorly capitalized positions move into the Yellow Zone and are liquidated before they move into the Red Zone.  However, large movements in the tracking price within the space of a single block may cause positions to jump directly from the Green Zone to the Red Zone without an intervening stop in the Yellow Zone.

Wipeout Elbow and Strong Linearization give the same results in the Yellow Zone conditions, only the Red Zone handling is different.

The sequence of steps for liquidating shorts are as follows:

(1) The best bid and ask price for the previous block are used to determine the tracking price.

(2) For every position in the Red and Yellow Zone, a limit bid order is placed.  The order quantity is the size of the short position.  The equity less fee (elf) is the proportion of the proceeds to which the short holder is entitled, less liqfee = 5%, and is given by:

    elf = max(0, equity - liqfee)

The limit bid order's price is given by (1 - elf) * pie / quantity.

(3) Suppose some fraction z of this limit order is fulfilled.  Then BTS moves from the pie to the short position holder and the seller fulfilling the bid order.  The short holder gets elf * pie * z, and (1-elf) * pie * z goes to the seller.  The remaining money, pie * (1-z), goes back into the pie.

We'll deal with a single BitAsset, for convenience I will call it BitUSD, but this also applies to other BitAssets (e.g. BitGLD).  Each paragraph in the following is preceded by a term in parentheses; the goal of the paragraph is to define that term.

(Short Position)  Accounts can have positive or negative BitUSD balance.  A negative BitUSD balance is called a "short position."

(Short Sale)  A negative BitUSD balance can only be obtained through a short sale.  A "short sale" is a sale of BitUSD which results in a negative BitUSD balance in the seller's account.

(Market Price Lock)  A short sale can only occur by the fulfillment of a public Ask order (either market or limit order); thus, a short sale always occurs at the market price.  I call this the Market Price Lock.

(Collateral)  When a short sale occurs, "collateral" is set aside.  The collateral consists of the money the buyer used for the purchase (less fee), and some amount of the seller's money.

(Buyer Perspective Equivalence Principle)  From the buyer's point of view, there is no difference between buying from a short seller and buying from a long seller on the exchange.

(Pie)  The collateral is set aside into a container I'll call a Pie.  Each pie is tied to an account and a BitAsset.  So if Alice shorts BitUSD, and Charlie shorts BitUSD and BitGLD, there will be three pies:  Alice's BitUSD pie, Charlie's BitUSD pie, and Charlie's BitGLD pie.

(Margin Requirement)  The initial size of the pie divided by the buyer's contribution to the pie.  This is 2x in the BitShares whitepaper, but Bytemaster has proposed an increased margin requirement of 10x.

(Equity)  The piece of the pie that would be given to the attached account in a purely theoretical, "fair" unwinding of the short position.  Can be specified as either a percentage of the total pie, or a number.

(Total Win Principle)  When the Tracking Price of BitUSD is equal to zero, equity is one hundred percent.

(Weak Linearity of Short Position)  Equity decreases linearly as a function of Tracking Price, until reaching zero at the Wipeout Price.

(Tracking Price)  The price that is used to determine equity is called the Tracking Price.  I believe it is currently specified as the average of the best bid and the best ask, but am not 100% sure about that.

(Wipeout Price)  For a given pie, the Tracking Price at which equity becomes zero is called the Wipeout Price.

(Capitalization Principle)  When an account initiates a short position, its initial equity is equal to its contribution to the pie.

(Slope)  The Slope is the rate-of-change of equity position.  The Total Win Principle, the Weak Linearity of Short Position, and the Capitalization Principle combine to determine the Wipeout Price and Slope.

Quote from: drltc on January 30, 2014, 07:20:35 am

Why is this necessary at all?  What's wrong with just having every node do its own proof-of-stake on the set of transactions it knows about?

All nodes must AGREE on the next block to make sure the block chain doesn't diverge.  Bitcoin uses the lowest hash to decide what to agree on.

What's wrong with arbitrating between two different forks by accepting the one with the "better" proof-of-stake (compare hash divided by target for all competing forks)?

As a result bitcoin is centralized one block at a time.

I see what you're trying to say, but only because I think (earlier in this thread, or maybe somewhere else) you said that a single miner can "dictate" a block.  This is true, but it's a strength, not a weakness.  If you have some transaction T that a censor wants the network to permanently reject [1] [2] , with UNL it suffices for the censor to control some fraction of the UNL (maybe a majority, maybe a supermajority, maybe less -- need a simulation or detailed mathematical analysis to say for sure).  With PoS, we can assume 50% of the PoS-power will accept T [3], so the probability that T is not included in any of the next n blocks is at most (1/2)^n, which of course rapidly goes to zero.  Why allow a transaction censorship attack to succeed by compromising the UNL, when we can force them to meet the much higher bar of a 51% attack?

Bitcoin is also centralized by 10 mining pools which approve 90% of the blocks and just 2 or 3 are required for 51% or more of the blocks. 

I thought that PoS is supposed to be resistant to this phenomenon, because it's much harder to accumulate a significant fraction of a cryptocoin in circulation than it is to pool mining hardware.

[1] For example, the censor is a democratic government who believes, through due process of law, including good evidence obtained by Constitutionally approved methods and presented to an impartial judge / grand jury, that this transaction should be suppressed because it will be used for some despicable criminal activity.

[2] For example, the censor is an oppressive government whose intelligence service wants to invade privacy on a global scale by data-mining every financial transaction performed by every person in the world, and believes that this transaction should be suppressed because it does not contain sufficiently detailed information for its data mining system to confidently identify the sender, recipient, and nature of the transaction.  NB, technology cannot distinguish this case from [1].

[3] If 51% of nodes reject the transaction the censor wants to be rejected, then the censor has successfully carried out a 51% attack.  Because a 51% attack on PoS system implies that 51% of the money agrees with the censor, I would say this situation is better described as "the network voluntarily complied with the censor's desired policy" than "the censor launched a successful attack".

I buy that Bitcoin's de facto centralization is something to be avoided if possible.  But I also want to be sure that your cure isn't worse than the disease, hence the skeptical questions.

If I'm wasting your time with elementary questions, and there's documentation where this is already explained, please, feel free to point me to those resources instead.

Okay, so here are my next questions:

- How do nodes outside the UNL know what has been approved by the UNL?  Do UNL nodes have hardcoded keys as well as hardcoded network addresses?  Or is a connection to a UNL node necessary for a client to function?

- Say I'm a node outside the UNL.  One of my peers feeds me a block that has a parent I've accepted and passes proof-of-stake signature, transaction validation, etc., but contains some transaction the UNL has never heard of.  How do I establish that the UNL has never heard of it?  What do I do with the block -- accept it, discard it, hold it for a while and see if the UNL eventually decides to like the transactions it contains, or something else?

- It seems like you might need a condition along the lines of "Most of the regular nodes (outside UNL) have to have nearly identical UNL lists" in order to avoid a fork.  Is this true?  If it is true, doesn't that mean your argument that "players can change the UNL" should be amended to disclose "players can change their UNL, but risk causing a hard-fork"?

- Shouldn't we build some kind of simulator or run a bunch of instances on localhost or something to observe e.g. the nodes reaching consensus?

- With respect to step 6 ("Once all transactions in my published proposal have at least 70% of the weighted vote convergence is guaranteed...")  What precisely is meant by convergence, and how is convergence guaranteed?  Mathematical proof, empirical simulation, practical experience (Ripple?), gut feeling, something else?

1) Every node publishes their initial transaction set to all other nodes in the UNL
2) A node will then tally the votes each transaction got as a percentage of the maximum (a vote from every node)
3) A node will then calculate the average "consensus" of each proposal by every other node (the average of the values calculated in step 2 for each proposal.   This average will then be used as the weight given to that transactions in that nodes proposal.  The result is that proposals with higher average consensus get a higher weight than proposals with lower average consensus.  If nodes want their opinion to carry weight they need to increase their average consensus in their next proposal.
4) I then recalculate the proposal for the current node by tallying the weighted votes each transaction got based upon the proposals it was included in.
5) I then take all transactions in the top 25% by weighted vote and publish them as my new proposal to all other nodes.
6) Once all transactions in my published proposal have at least 70% of the weighted vote convergence is guaranteed and a block can be produced and the process starts over.

Let's say a transaction is "popular" if it's in a lot of nodes' proposals, "unpopular" if only exists in a few nodes' proposals.

Won't your algorithm make unpopularity stable over time?

In other words, let's say there's a transaction that only exists on one node.  Won't other nodes always choose not to include it in their proposals because it's unpopular?

Of course, in a real network, pretty much all transactions enter the network from a single node.  So this analysis means no transaction will ever be accepted by any node other than its originator, and the network will be totally useless!  This absurd result tells me my analysis is wrong -- but how is it wrong?

I think that this idea doesn't reduce the implementation complexity; it merely moves the complexity to the part of the code that deals with short sales.

Traditional investment brokerages charge interest to people who short stocks.

I thought from reading the whitepaper that the BitShares equivalent is implemented by denying the dividends from collateral to short sellers.  And I also thought this was not an optional feature, but an important market mechanism to maintain price stability, since any downward price movement will cause existing short positions to want to buy, covering the short and taking the profit, and possibly (but not necessarily) enter a new short position with less collateral.

So with Dividends 2.0, what would fulfill this role?

To put it a different way, a simple UI change suffices when the dividends are being delivered "fairly" to everyone who owns BTS.  But it's not obvious what should happen with short sellers.

Also, if transaction fees are destroyed instead of uniformly distributed, won't that eventually interfere with divisibility?