Here's my theory. The problem is that the payout of the collateral is not handled in the same place as the actual filling of the cover.

The manual cover transaction is created by transaction_builder::submit_cover. That adds a cover operation to the transaction and deducts the cover amount from the transaction balance. It also computes the interest to be paid at the end of the transaction expiration time, and only if the cover amount covers both interest and the balance to be covered it also adds a deposit operation for the collateral.

After the cover tx has been included in the blockchain, the cover operation is executed by cover_operation::evaluate. This computes the interest owed at the current block time, and if the cover amount covers both interest and principal the cover_order is deleted.

The problem here is the different times used for interest calculation. The default transaction expiration time is 1 hour, while the actual transaction evaluation takes place only a few seconds after the transaction was created. The transaction builder computed the interest owed one hour in the future and came to the conclusion that the cover amount was not sufficient, and therefore it did not create the deposit_operation for the collateral. The transaction evaluation calculated the interest owed now, saw the the cover amount was sufficient and closed the cover_operation.

This is a serious bug, IMO. I'll have to check my TX history, this may have happened more than once.

Actually I've already started thinking about how to do this. :-)

It should be comparatively simple to reconstruct a wallet balance at a given point in time by adding up all the records in the wallet's transaction ledger. I could implement an API call for that which can be used either on the console or via RPC. The GUI part should be handled by someone else if you want that.

If the TX ledger idea works 200 USD is a fair price.

I think you have note paid the small amount of interest you owe on your short.

What is the return now of:

wallet_market_order_list BTC BTS
?

Good thought. In fact that has happened before, i. e. after paying off the full amount there was still 1 satoshi left. But in that case the uncovered satoshi was shown by wallet_market_order_list. Here's the current output:

trader (unlocked) >>> wallet_market_order_list BTC BTS
TYPE                QUANTITY            PRICE                         BALANCE             COST                COLLATERAL          LIMIT               ID                                         OWNER               
==================================================================================================================================================================
cover_order         127,631.97525 BTS   0.000017627723132021 BTC / BTS2.99981483 BTC      2.24986112 BTC      255,263.95050 BTS   NONE                2c6f285f6a1eb878f484062902bf75ddf3917333   BTS84qcvLzQVyc2U2WMZe2qNd3ARJ6JTLEmJ
ask_order           0.00032 BTS         0.0000361752752312 BTC / BTS  0.00032 BTS         0.00000001 BTC      N/A                 NONE                402621d669a668fff24325e838879cc20914f7c4   BTS2hwFxMAdyZb3fPQnwwAYQC3e5arcTs9BU
ask_order           87,027.17231 BTS    0.0000361955916255 BTC / BTS  87,027.17231 BTS    3.14999998 BTC      N/A                 NONE                e8ead8c107d31d1864e452160188e2c80d793038   BTSP4uVggqTEwFoTgZRWsiT71HPm3ChmoWgh

Note that the open cover_order belongs to a different owner than the one I covered - this was from an unrelated short.

It will use the collateral to buy BitGOLD at the price feed or up to 10% above. If you want to avoid that, you have to find BitGOLD elsewhere - one option is shorting to yourself again. Note that your collateral stays locked until the cover is fully paid up.

0.6.0 is the latest version and https://github.com/BitShares/bitshares/archive/bts/0.6.0.zip is the source code, right?

Actually it's 0.6.1 now.

Is BitShares code based on Bitcoin? If yes, is BitShares networking code based on Bitcoin?

No, BitShares is written from scratch. (Although it does borrow a few things from 3rd party code.)

If no, is there a textual description of the peer communication protocol (reading code written in a language I'm not familiar with is not very easy)?

Many details about BitShares are still in flux, so I doubt there is up-to-date documentation on technical details. Have you checked these wikis:
https://github.com/BitShares/bitshares/wiki
http://wiki.bitshares.org/index.php/Main_Page

Weren't you saying that delegate pay was nowhere near enough for your time? What changed?

A 100% delegate does not pay for my full time, and this hasn't changed. My proposal offers part-time work.

But for someone who has no coding skills, could you explain what you can get done in 18 hours a month? (Current market cap)

Is it enough to make a big enough of a dent in cleaning up the GitHub issues?

I really don't know how to explain. My proposal mentions the GitHub issues mostly as a workload indicator, not as an actual problem. The amount of work hiding behind a single issue can vary wildly, so it is not possible to say that I need X hours per issue. And even a single issue can be handled in qualitatively different ways - for example an issue describing a bug can be resolved by fixing the bug only, or by creating a test case for reproducing the bug, then creating the actual fix, then verifying that the fix works by re-running the test. Creating regression tests takes more time obviously, but is also more future-proof.

I think in the end the most fair way to evaluate my work will be to check a) if I provide quality work, and b) if the time I need for producing these results is adequate. Fortunately the nature of this project makes such evaluation possible for anyone (or at least for anyone with coding skills).

I listened to the mumble recording from last Friday where the below topics were discussed, too.

There is ideas bouncing around on Nullstreet about adding a Bitcoin receive address to a rebranded BitShares lightweight wallet along with support for Shapeshift and Metaexchange. Is this in your wheel house?

I think conceptionally it is pretty clear what needs to be done for this. In such a project I could achieve a high level of efficiency, because it largely consists of modular functionality that is mostly independent from what others are working on. And even if my delegate pay is not sufficient for implementing the whole thing in a short time I can (for example) provide modules for handling BTC transactions and/or communicating with a BTC API server, and leave the rest to someone else.

So yes, I think this is a good suggestion, but since I want to take load off the core devs I will select projects and coordinate priorities with them once I've been elected.

There's also a great discussion about what it would take to add a prediction market in the general thread.

This is also a very interesting project. But in my understanding this is BM's baby (or one of his many ;-) ). Also, conceptionally it seems to be in an early design stage, and this will impact a lot of core functionality. So IMO this is not a project that would be suitable for my position.

above in terms of the GUI, below in terms of the CLI.