@dannotestein then let's continue to discuss this at the end of April, have a good holiday.

@BunkerChain Labs yes I think this work proposal have chance to continue, if the price can be limited in a relatively reasonable level, we should support useful and efficient work, if it is not over paid.

sounds good

Ok, very sorry for the problem, our wallet went off on a fork (that's a first for us), so we're re-initiating all the false transactions now. Here's the trx to credit you:
https://bitshares.openledger.info/#/block/5004379

First, check two things: 1) if your wallet is synced (a large number of people had synch problems today, probably because some hardfork-related event finally occurred) and 2) you have enough BTS to pay for LTM (from http://www.cryptofresh.com/fees it costs 17,612). Also, if you have more than 1 account in your wallet (this is not common), make sure the appropriate amount of BTS is in the account you are upgrading.

Annual memberships were buggy and have been discontinued (only like 2 or so ever got purchased, I think).

Making transactions default blinded sounds like a great idea, IMO. Currently I think transactions are a little "too public".

March just ended, so I figured it was a good time to put together this report. This worker just got voted out, so if you think this was useful work and you're not currently voting for this worker, you should consider doing so. No one should panic, IMO, about this, however. While I think the work being done here was important, I'm sure the chain is stable enough to survive "as-is". Like ByteMaster, I think the most critical worker to keep on the payroll is SVK, since he's maintaining the front-facing interface and getting a GUI right takes a lot of time.

I've never really weighed in on most worker proposals, but I personally have always favored the relatively low-cost "maintenance/update/docs/support" workers versus the higher-dollar higher-risk "new feature" proposals. The FBA idea is a great way that such high-risk new features can be paid for, so the chain has that option for major innovations, without risking the funds of those who don't like a particular idea and without creating the conflict that can divide our community. Unfortunately, it seems that even the maintenance worker charges are big enough to be a problem, and I think this ultimately stems from a difference in global salary ranges and thus is hard to overcome. I do want to say that I don't feel any animosity towards those voting against the workers: I understand their position and have even agreed with some of their arguments, although I think voting against all worker proposals is short-sighted.

Ok, personal views/insights aside, on to the report, beginning with pay distribution, since this is the issue that seems to be of the most concern. I've made two draws from the vesting balance over the past 7 weeks since the worker began. Since we're primarily paying contractors in USD, I value it in USD on that day.

03/05/16 1450K BTS (estimated $6172 USD on that day)
03/18/16 772.5K BTS (estimated $4275 USD on that day)
Total USD value: $10447

The worker has a remaining balance of 760K BTS, part of which will be paid to Abit for work he's performed (he has requested to be paid in BTS), and the remaining held in the vesting balance for possible "emergency" work that needs to be done before the worker can be voted in again.

I've divided the payment into 2 periods: the last 3 weeks of February, when the worker began, and March.

Contractor            Feb (3wks)          March
------------------------------------------------------------------------
Cryptonomex       3750 USD           5000 USD (nearly fulltime for Theoretical + some time from Valentine and Michael)
SynaptiCAD            700 USD           1000 USD (Dan and Eric)
Abit                                                     250K BTS (plus another 250K BTS payment which I will be holding contingent on inclusion of a tested version of the rate-limited free trx code)

Here's a list of work that's been done during these periods, on a "per-release" basis. Note that the version numbers can be used to determine the periods during which the work was included in the release (e.g. release 2.0.160223 was completed on 02/23/2016 for example).

Released in 2.0.160216

- Implement new market API #503
- Add a cryptography API #500
- Handle exception in open() by re-indexing #492
- Don't update bitasset_data_object force_settled_volume every block unless needed #540
- Cap auto-cancel fees at deferred_fee #549
- Fix integer overflow bug in unit test framework when waiting for zero blocks #559
- Fix for #557: check BTC/PTS addresses on balance import including compressed/uncompressed versions
- Remove active_witnesses from global_property_object #562
- Saves change address in the wallet when transfering from blind to an account #564
- Fix #586 - decoding memo for sender in CLI wallet
- Take mia as reference, not copy, in clear_expired_orders(), maybe fix #485
- Expose whitelisted_accounts, fix #489
- Implement rough Python regular expression based reflection checker #562
- Fix withdraw_permission_object.hpp reflection #562
- Replace ordered_non_unique indexes with composite keys / ordered_unique, using object_id as tiebreaker.
- Reflect ID of force_settlement_object, fix #575
- Fix #492 - database corruption when closing
- Move account_options::validate() implementation from account_object.cpp #498
- Disable skip_validate #505
- Remove libraries/wallet/cache.cpp #510
- Give different object types their own individual header files #466
- Add break to every case in get_relevant_accounts #513
- Remove unused ancient implementation of operation_get_required_authorities #537
- Remove evaluation_observer #550
- Make some casts more explicit.
- Remove type_serializer, re-implement minimal functionality needed by cli_wallet #553
- Optionally disable database unity build #509
- Generate hardfork.hpp from hardfork.d directory #511
- Improve account_balance indexing #529
- Improve vote counting implementation #533
- Defer something-for-nothing culling for taker orders until the order is unmatched #555
- Make is_authorized_asset a free-floating method #566
- Log a lot of information if clear_expired_orders() is iterating too much, maybe useful to diagnose #485

Released in 2.0.160223

- Fix outdated price ticker in new market API #592
- Fix problems building from source on Windows and Mac

Released in 2.0.160316

- All annual members received a free upgrade to lifetime membership.  Discussion [here](https://bitsharestalk.org/index.php/topic,21846.0.html)
- Negative votes for workers were disabled.  Discussion [here](https://github.com/cryptonomex/graphene/issues/607)
- Improved account history with `get_relative_account_history` API call #477
- Fixes to new `get_ticker` market API call #592
- Implement debug_node #606
- Disable negative worker votes #607
- Minor code cleanup of voting code #611
- Deprecate annual memberships #613
- Fix incorrect condition for updating feeds which leads to object spam and excessive GUI bandwidth usage #615
- Optional websocket compression #619

Released in 2.0.160328

- Fix an incorrect asset ID returned by `cli_wallet` for non-BTS vesting balances #625
- Fix a bug causing multisig to (incorrectly) fail in some cases #631
- Restore p2p shutdown logic fix which was unintentionally excluded from the previous release #598 #637

I suggest to not use names bitUSD and bitCNY (in dropdowns). Those smartcoins are available in wallet as USD and CNY. Do not confuse people even more.

I take a different view on this. In my opinion, the symbols in the wallet should have been BitUSD and BitCNY and not USD and CNY. They are not equivalent to USD or CNY (not exchangeable 1-1 in practice), so I think this is a much greater source of potential confusion. And in fact, all discussions of them on this forum refer to them as BitUSD and BitCNY. I actually originally thought that all Bit Asset symbols would be prefixed with Bit, but somewhere along the way this got lost during implementation.

I have no idea who "for-gary" was voting for, but it's quite obvious that "garylarimer" wasn't voting for anyone, since it just claimed its funds 6 hours ago...
http://cryptofresh.com/u/garylarimer

I think it's a good time to summarize when a new release is out (which means some maintenance work has been done).

I'm making payouts at end of the month (next week), so planning to summarize work at that time.