Guys!

As the stealth feature development approaches completion (@kenCode, we need to get as close an estimate as possible on the ETA for stealth),
we need to have our marketing approach thought out and started, so we build anticipation in the market that peaks when the feature becomes available.

@kenCode, you provide lots of detail in your updates, but in order to create a marketing plan and begin executing it we need to have:

  1) a stealth-specific roadmap (i.e. feature element schedule) of milestones that marketing can use to create a marketing plan that coincides with it

  2) screenshots, docs / design elements / use cases and other "bits" for the stealth design for which videos and marketing materials can be produced

We need to start coordinating stealth development with marketing NOW, to build anticipation and capitalize on the demand for stealth in the marketplace.

Let's not let this opportunity slip away!

Yep, it is now, thanks fav!

I initially looked at it 25 minutes after your post, probably was too fast. Maintenance is ever hour now I believe.

It's been quite awhile since I updated the community on activities of the BitShares verbaltech2 witness.

As I described in the thread topic about increasing witness pay, I am committed to increasing my involvement and stepping up my game.

I participated in the recent testnet by building the code, and deploying 2 new fullnodes (8GB, 32GB RAM). I was online in mumble throughout the testing.

I have registered a new domain name for all full nodes (seed nodes, witness nodes and redundant witness nodes) and created a pull request in github to update applications.cpp which contain the seed node definitions.

I have upgraded the node in Australia to an 8GB, quad core CPU to handle the increased trading activity on the DEX. I will also be upgrading another node to 8GB (probably the one in Singapore) later this week.

I have deployed the latest build of the witness_node to all of the nodes.

I began to notice an increase in my missed block count over the last couple of months. Since January 15th 4 blocks have been missed. Reviewing the server load I can see no obvious cause for it. Keep in mind this represents a very low failure rate of only 0.3%. Network latency is reasonable, even for the nodes in Singapore and Australia at between 300 and 400ms. 

I am also coming up to speed on Python, and I will be looking into why the latest 0.4.8 version of bts_tools fails to successfully build the witness software from source. It's not a must-have feature of the tools, as the build is pretty easy to do manually now, but it will serve as an aid to getting more proficient with Python as well as contribute a bug fix to wackou's most excellent bts_tools. After that I will turn my attention to python-bitshares. and uptick.

Excellent xeroc! I hope this concept takes hold and it becomes a more reliable and superior method to fund workers.

What is the ETA on the Foundation becoming operational?

Update

A couple minutes ago, we have process the first "combo-proposal" in order to
1.) Obtain the worker pay
2.) Obtain 4350 bitUSD from the BTS:USD market
3.) Send the USD to chainsquad (in 4 chunks according to the proposal)

The script that generated the combo-proposal can be found here:
https://github.com/xeroc/worker-proposals/blob/master/2017-02-claim-1.py

Obviously, it uses python-bitshares.

As a remark, after the approval of the proposal by 3 parties in the multisig group, the transaction executed instantly and created some volume in the DEX.

This is the message I have sent to the people involved in the multisig group

Quote

It's time to continue our little multisig experiment. I have created a proposal that a) claims all BTS from the worker, buys USD and sends USD to chainsquad: 1.10.1457.

I would appreciate your approval.

All points in the first milestone (https://github.com/xeroc/worker-proposals/blob/master/2017-02.md) have been reached, code is published and working (the proposal has been created with that library) - milestone 2 is almost ready, except for the trading algorithm specific code.

Feedback is welcome. Please approve the proposal until "2017-03-21T11:27:23" (UTC) .. then we can see if everything works as expected ..

PS. this is not meant for the public as I don't want anyone to take advantage of the rather big USD-buy order that this proposal is going to create (+fill)

I'd say, the whole setup works nicely and I recommend to consider it more actively fro future workers.

Regards
 -- Faban

Timing is such a crucial aspect of success in business.

In an arena such as crypto software, an emerging market with tons of competition (1000s of coins to choose from), there are so many variables to consider.

Software is "never complete", and there are always things that can be refined and improved upon. I've generally seen things more from the perspective @kenCode shared, that being not to release a product until it resolves all known high priority issues and is "feature complete". What constitutes feature complete is the difficult part of the equation, as that is not limited only to product functionality and technical issues.

Feature complete also involves evaluating if the product is functional for the target users and their use cases. That requires knowing your users, the market they are found in. In a traditional company it also involves projected revenue, product lifespan and support costs.

Kencode and the montra coming from the Dash community is, 'Is it easy enough for grandma to use'? Is grandma a sophisticated trader or does she just want to send her grandchildren something for "school supplies"? How do we identify the "typical" grandma use cases? A better though more broad question is who is our target audience? How to we quantify our target demographic of users?

"Mainstream" as a target audience definition is extremely general and diverse. We need to be more explicit. Before we can mount a marketing champagne the fundamental question of who our target audience is must be answered, which yields a range of use cases which are used to evaluate if the software is feature complete.

I liked the thought that @JohnnyBitcoin put into the OP, and I agree with him the time is ripe now or soon will be to begin full all out marketing of BitShares like we've never seen before.

@kenCode, consider how Dash has been hyping their features (i.e. marketing) before they are ready. We don't need to have everything "finished and functional" before we start marketing. However, that's where you need to be as clear as day about when you expect to have features that work and ready for release. That is where a roadmap is useful, as it helps the marketing effort to stay grounded in reality and when a marketing "surge" might even be useful to create a heightened sense of urgency and thus stimulate emotions favorable to product adoption.

Based on your progress reports @kenCode I believe we need to refine our plans for  a marketing push. The work on the marketing side is to define our target audience in detail, and a strategy to reach them. On the engineering side of the fence a product / feature delivery roadmap needs to be created that marketing will use in devising their marketing strategy.

So perhaps this thread can continue on by focusing on a definition for our target audience. IMO I think we need to look at it as comprising 3 primary classes of users:

• Basic users like granma that just need an easy way to buy & sell BTS and transfer assets like BTS and BitUSD to other people, say from a contact list
• Everyday users, generally more sophisticated than grandma who may dabble in trading but are not "day-traders". Think how can the BitShares ecosystem replace typical banking - remittances, savings, mutual funds / CD instruments (i.e. simple, mainstream investments)
• Day traders and sophisticated investors, API users, bot users. I see this as a crypto-centric demographic, but might evolve into institutional investors over time

I'm sure that I have Solved the switch technology  between the main produce server and backup servers.
I running a script to change my witness's signing_key auto.
Please vote me, let my witness run again！
==========================================
My witness accounts: public-witness-one

Thank everyone！

Care to share your algorithm? Several people have claimed to be able to automatically change the signing keys to provide robust fail-over, only to come back later and add qualifiers or limitations when their approach won't work.

I am skeptical of the claim, but if it's possible you would do the community a great service to disclose how you do it. If after that if the community can't find a way where it WON'T work, it would become best practice.

If you choose not to disclose your algorithm, which I argue is well within your rights to do, the approach will not be validated and I will remain skeptical.

Welcome, and thanks for letting us know how your enthusiasm will contribute to the ecosystem.

Looking forward to seeing your progress!

Quote from: Thom on March 10, 2017, 05:53:27 pm

Why promote a centralized scheme? What value is provided through it that can't be provided in a decentralized way?

The scheme is not centralized, though it makes the involvement of centralized components possible. That being said, what those centralized components would bring are speed and low weight of execution, and convenience in production.

You said:

Now, the model I propose assumes a central server...

Thus it's centralized. How is it not?