The entrepreneurs consult Alice's older brother Adam, who is studying DAC's in accounting school.  Adam tells them:

"You're running this stand for a total of 30 days, right?  We give each of you one share a day, and you can trade in any number of shares at any time for a proportional fraction of the basket.  We're giving out a total of 60 shares, so each share will be worth 1/60 of a basket."

The next day, Adam's sister Alice is crying and mad at him because, while the stand earned $10 in profits, her lemonade share was only worth $0.17 which wasn't enough to buy either a candy bar or a soda, and this simply didn't seem right to Alice.  Adam assured her that the accounting math was solid, although the system might take a long time to reach equilibrium.

Thirty days later, Bob's pretty mad at Adam too, because he can't buy his $150 bike.  Bob's 30 shares, cashed in on the last day, were only worth $116.82 while he was expecting to earn $150.

Continued in the next post...

Assuming 2 different longs that each control 50% of the USD supply the first long cashes on on the last day... he would hold 50/110 of the USD and get a yield of $4.54 and the supply would now be 55.46 and the yield fund would have 5.46 in it.   The second long cashes out owning 50/55.46 of the USD supply and would receive a yield of $4.92... leaving the yield fund at $0.53 and the USD supply at $0.53 and the USD debt at $0.53. 

Using 110 as the divisor is the first accounting problem I see; the divisor should be 100.  A divisor of 110 would be based on an (incorrect) assumption that the dollars in the yield fund would themselves be eligible to receive yield.  You should compute the investor's share of the yield based on the total of all BitUSD held by investors (50 + 50 = 100), not investors plus network (50 + 50 + 10 = 110).  Then, after the first long's BitUSD plus yield are burned in the partial cover operation, the second long would hold 100% of the supply and receive 100% of the yield fund; each investor would have gotten exactly $5 in yield, which is the "right" behavior.

The second accounting problem, which is actually the complaint I had in mind, is based on the first long transferring his BitUSD to himself (or another person), collecting the yield and having the BitUSD remain in circulation.  My understanding is, if the first long transfers the BitUSD to himself, he would get $4.54 of the yield.  The supply would still be $110 (assuming fees are too small to matter).  The first long would hold 54.54 / 110 of the supply and the second long would hold 50 / 110 of the supply, but the yield fund is down to $4.56.  So the second long would get 50 / 110 of $4.56, or $2.07 in yield.  The remaining $3.37 in the yield fund is untouchable BitUSD, and it is a very substantial percentage of the fund.  Basically the problem is giving the first investor 50 / 110 of the equity in the fund both before and after the distribution.  The extra equity you're giving to the first long has to come from somewhere, and it comes from the second long.

Also, @bytemaster if you're reading this -- please contact me privately.  I've tried to reach you via PM and email, but haven't received any reply.  If you're still thinking about it, I'd appreciate at least knowing my message hasn't gotten caught in a spam filter.  Thanks

For me the above is the straight-way to solve this 'incorrectness' but:
-Is it really that easy to update the initial order on a blockchain? Or will we will end up carrying well too much pretty unnecessary info for a average interest of 0.20833% And deference of like less then 10% of that?

The blockchain itself will just contain two things (well not really, this is just a simplification, see [1] for the truth):

- On November 1, a transaction initiating the initial short.
- On November 16, a transaction executing the partial cover.

It's up to the client to compute the new margin call price from the information in these transactions, and figure out how much BitUSD liability the position has in the future when something else happens to it (which might be another partial cover, a full cover, a margin call, or expiration).

So the November 1 transaction remains the same forever (the blockchain is basically an append-only transaction log, that's kinda the whole point of having a blockchain).  The client's database record showing the open BitUSD short positions, OTOH, is a mutable record which is updated by transactions coming from the blockchain.  So when the November 16 transaction comes in, the client updates the principal amount in the database record for the open short position.

My point was that, if you have the client handle the partial cover transaction by updating its database record using the algorithm I described, you'll cause the existing logic to do exactly the right thing for any further operations on that short position (another partial cover, full cover, margin call, expiration).  Without requiring another column in the database.

[1] It actually doesn't even contain this much.  Basically the blockchain only contains the bare minimum information to tell the client how to update its database.  If the client can figure something out on its own from existing information, then that's what the client does.  It'd just be stupid and wasteful to use precious blockchain storage to store a copy of anything we could just have each client store locally.

In a little more detail:  From the answer vikram (one of the devs) gave to one of my questions this forum, BTSX does something called "virtual transactions."  Basically whenever market orders are matched, the resulting transaction is generated locally by the client and never exists on the blockchain itself.  So you'd have blockchain transactions for Alice entering the short order, and Bob entering the bid order.  The matching between Alice's and Bob's order wouldn't show up on the blockchain.  Instead, the client would figure out that the prices overlap, triggering the "virtual transaction" logic which is basically bunch of different database updates showing that Alice now has an active short position, Alice and Bob's BTSX has moved from their orders into the short position's collateral, Bob now has some newly printed BitUSD, and both of the orders are now gone (or maybe just one is gone if the quantity was unequal and one side got a partial fill).  The database updates caused by virtual transactions are only visible on the blockchain insofar as they affect what transactions are accepted in future blocks, i.e. if Bob tries to send BitUSD to Caitlin, it will now be accepted because every client will have performed the database update and every client's database will show that Bob has enough BitUSD (because of the update that happened when his bid overlapped Alice's short).  Whereas before the match, it might have failed because Bob would have had a smaller (maybe zero) BitUSD balance.

Of course there's also logic for fees, partial fills, yield, and lots of rounding going on.  Oh, and this also all has to be undoable to deal with forks, which can happen if a delegate is so late producing a block that the next delegate produces its own block, having decided that the first delegate is offline (but the first delegate did produce a block because it didn't get notified in time that the second delegate had produced a block).

In addition, the production BTSX client has to keep a copy of all previous versions of the market logic to figure out the database from blocks that happened before the current rules came into effect.  (On testnet, they just reset everything to the genesis state when they change the market engine, because testnet XTS / BitAssets are just "play money" and we don't care about resetting their ownership.)

Knowing about all of the machinery that has to exist, explains why I tend to be so patient and understanding when there are frequent updates to deal with various bugs

I am aware the issue and know that it does cost extra for partial covering.   You end up paying interest on your interest.... result: partial covering has fees associated with it that are magnified by the insane interest rate used in the example. 

The challenge is calculating the result without adding yet another data field to every order... to track the start date and end date. 

I suppose I might as well store extra data rather than using a crude approximation.

I thought about this issue some more.  I think you can solve it by just figuring out what part of the payment goes to principal, and updating the initial principal.

Consider our example, where $100 short has an interest rate of 10% / month and the user covers with $52.50 at 15 days.

We said that a full cover would be $105 at 15 days, $100 principal and $5 interest.  The partial cover payment goes to principal and interest in the same 100 : 5 proportion.  A $52.50 payment would pay $50 to principal and $2.50 to interest.  (A $50 payment would pay $47.62 to principal and $2.38 to interest.)  So if the user pays $52.50, just update the initial principal to $50.  In other words, you just replace the record that says they took out a $100 short at 10% interest 15 days ago, with a "back-dated" record that says they took out a $50 short at 10% interest 15 days ago.

Then they would need $52.50 to do a full cover right now, so the numbers are right for doing a partial cover quickly followed by a full cover.  In 30 days they'll need $55 to do a full cover, and linearly in between.  The back-dated record is an accounting fiction which happens to make the numbers come out exactly right without needing another database field.

I am aware the issue and know that it does cost extra for partial covering.   You end up paying interest on your interest.... result: partial covering has fees associated with it that are magnified by the insane interest rate used in the example. 

The challenge is calculating the result without adding yet another data field to every order... to track the start date and end date. 

I suppose I might as well store extra data rather than using a crude approximation.

If you do continuous compounding, then interest and principal dollars generate interest at the same rate and don't need to be tracked separately.  The amount payable is f(t) = initial_principal * (1+r)^t where t is the time in months and r=1.10 is the monthly rate.

Continuous compounding is technically doable.  I'll post an example of what the numbers would look like in another post.  I would actually recommend doing continuous compounding if the story ended there.  But there's more:  Linear compounding has one highly desirable feature that continuous compounding does not.  With linear interest, you can figure out per-block short interest income for the network as a whole:  Just keep track of the sum of the shorts' per-block interest!  We could (and I think we should) pay the interest income directly to the yield fund as it accrues, rather than waiting for shorts to close.

If you have a bunch of outstanding shorts using exponential compounding with different exponents and expiration dates, I think this immediate payment would be impossible for technical reasons [1] [2].

Therefore, my recommendation is to stick with linear compounding, and consider implementing paying the accrued interest to the yield fund immediately every block (not a super high priority, so we should probably testnet this first).

[1] It would theoretically be possible if we were willing to spend O(N) computation every block, where N is the number of shorts that exist.  We aren't willing to do that, as "not breaking the network" is a higher priority than "paying yield a little sooner"

[2] I don't think paying exact interest as it's accrued would be possible with exponential compounding, but you might be able to figure out some approximate lower bound that you only need to update when a short opens or covers.

Excellent idea.