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