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

Awesome report
Very professional and transparent!!

Quote from: nomoreheroes7 on April 02, 2016, 01:23:21 pm

Quote from: btswildpig on April 02, 2016, 01:14:36 pm

Have you looked at coinmarketcap recently ?
It doesn't take a company with funding to compete with BTS . A coin with a silly Doge face is doing it already .
Dogecoin is already doing it with zero features/zero funding .

Figure out how to beat Dogecoin , and I'll have a serious conversation with you . 

Of course, you will say ..."Dogecoin is pump and dump, market cap doesn't count”. But how can you talk about beating all the innovation projects by increasing dilution when you can't even beat a silly project called Doge ?

Oh come on, Doge is obviously an anomaly in the crypto-world -- it's purely for "fun" and speculation on how much others will find it "fun". That's not BTS. BTS won't magically become fun and community-driven if everyone just stops developing for it.

The name's not even funny -- BitShares.

So .... you mean to set a bar for beating Dogecoin is unfair for a light speed blockchain ?

Seriously?  We're comparing BitShares to Doge?
Doge is a copy coin with some (if any) tweaking to the protocol.  A vanilla currency... passed between two parties... that has nothing more than network effect,  only because they started at the right time and right place... the peak of the crypto hype!

Do they have...
A function Decentralized Exchange on their block chain?
A way to create UIA's?
Any Market Pegged Assets?
A complex GUI/Front end?
Any work being done for STEALTH?
Any voting capabilities?
A network with 3 sec TX times?
Any business that have built off their protocol?

So in other words, we have a SHIT TON of upkeep which BitShares requires to stay running and functional.  BitShares IS NOT a "set and forget" coin/token/crypto. 

That being said.  I'm not 100% for dilution either but, we must have some common sense realizing BitShares is not a vanilla coin.  It's literally a living and breathing eco-system which needs fostered and cared for by the community and devs alike.  And yes, devs/workers need some form of compensation to help maintain and grow our system!! 

Since we're on the subject of an Exchange abusing its voting powers... why can we not create specialized "Exchange Wallets".  I've always thought Bitshares should have a "modular" approach when it comes to users. 
Not ALL users are the same.  Not ALL users have the same goals for using BitShares. 
With the complexity that BitShares offers (the points mentioned above) along with the current Yunbi debacle, we really, really, really should look at providing specialized wallets that are tailored to fit the needs of each unique user.

For example,

A registered wallet for “Exchanges” --- would allow them to vote but, at a reduced weight ( 1:20 ratio?).  This way the voting system isn’t being abused as we’re seeing now, while still allowing them to voice their position, like the rest of us.  The wallet could also allow them to create sub accounts to fit any needs for interfacing with their front/back end functions (maybe allow up to 50 sub accounts (to keep blockchain RAM/bloat in check)).  In some manor, we should also incentivize the exchange wallet so there’s no incentive/reason to game the system by creating “fictitious” non-exchange wallets to circumvent the voting restriction.  Maybe no DeX Tx fees and charge a little higher wallet-to-wallet Tx fee? Maybe we could incentivize their registered wallet with some “dividends” from the fee pool also??

A registered wallet for “Point-of-Sale” --- would allow them to vote at full 1:1 ratio since these wallets will more than likely not have a “large” quantity of user’s funds in them as activity of this wallet would really only take advantage of our quick 3sec user-to-user transfer time and not necessarily holding customer funds for long periods of time.  This wallet could also include sub account creation (up to 50?) to fit their business needs for BitShares integration, like the exchange wallet. The incentive of this registered wallet would be to have NO wallet-to-wallet Tx fees and below normal DeX Tx fees.  There really should be no need to incentivize this style wallet other than no Tx transfer fees.

A registered wallet for “Standard Users”--- this wallet would stay the same as what we have available today in our current wallet (obviously 1:1 voting).  I personally would like to see a “Lite” and “Advanced” option within the BitShares default wallet and have it default to open in “Lite” view (or an option to choose default).   Obviously this is GUI related but, would like to see this ability in our main wallet none the less.
I feel having this discussion regarding different wallet structures is very important and needed. We, as a community cannot keep going through these major conundrums. It not only hurts community moral but also businesses looking to adopt Bitshares technology.
BitShares is not structured as a One-Size-Fits all, so please let’s make some sensible changes that won’t financially hurt each other and beneficial to all.

My 2BTS 

@kenCode @Chris4210
I received a question on the YouTube "Walk Through" video from Simon Feay and wasn't sure how to correctly answer it, so I'm going to paste it here in hope you could provide an answer.
Thank you!!

Can you tell me (in the app) where is the address for my account. I don't want the qr code to receive bitshares. I just want the actual alphanumeric walled address. Thanks

Sent pm with my email for invite. Thanks

Hello everyone,  has anyone heard or looked into http://mconf.org/    ?
They're a 3rd party software to BBB.  I glanced through their website and seems to be an active project. The big question is if they've been able to optimize BBB bandwidth, or at least  a work around to lighten the load? 
They also have a mobile app to plug into the meeting/conference... not sure if BBB had that or not.
Might be worth it to check into these guys.   I'm going to download a demo later to check it out.

Good call! Yes this would be a great interview/spot for OPENPOS and @kencode @chris4210
Another good episode would be with @fuzzy and @bytemaster show casing the beyond bitcoin format and it's weekly hangouts.

Great job @Chronos !!

Quote from: emailtooaj on March 15, 2016, 06:31:23 pm

Quote from: tbone on March 15, 2016, 06:03:51 pm

Quote from: emailtooaj on March 15, 2016, 04:34:53 pm

Damn, never thought syscoin would trade higher than BTS lol
That should get some motivation

What do you mean?  Our market cap is more than 5X theirs.

I was referring to per coin price. Yea our cap is larger, but sys always stayed around the 200 satoshi, 700-800 with last week's pump. Now its broke 1400. .

It's too bad.  They could have put that front end on bts for quite a bit less, and had a much  better product.

Can't disagree one bit!