In the world of software, never give out dates (right Stan? ). I learned that lesson 30 years ago. Obviously though Thom, I took your comments very personal, so I sincerely apologize for my knee-jerk reaction. I am building things that have never been built before, so it's a bit tough to even hand out any timelines. I am well aware of what needs to be done, nobody has ever had to ask me for updates, and I do my best to detail our roadmap and progress right here on this lovely forum every week, so nothing more.

Apology accepted. I sincerely hope you realize I'm only trying to open discussion and understand where we are in this process. I am very glad to see the screenshots; you know what they say, a picture is worth a thousand words. They will help a lot for marketing.

Like I said tho, I'm not a marketer, let alone a professional one. My role at this point is simply to gather as much information as possible. Once enough info is known about how your "true and complete" stealth will work (at say a 1000 foot level) then some type of early marketing might be possible. You have provided the 100,000 foot view of how stealth will work, and the contrast of that view to the existing blinded transactions is quite dramatic.

Differences of perspective will always be present, so we all need to learn to work together without alienating one another. It serves none of us if we become divisive and locked into a "my way or the highway" mindset (not saying you're doing that ken).

Regarding the changes your making to the backend code. Those are what dictate whether a hardfork will be required, and IMO should be done very carefully. I agree with you ken, that the existing backend will require changes to implement a deep stealth that hides everything and also provides a backup mechanism for grandma's declining memory. If you can implement your true stealth without touching the existing blinded stealth code it will reduce the impact on testing and avoid issues with anyONE who might be using the old cli stealth code. I frankly don't see how you can avoid a hardfork to roll out your stealth, as it can't be accomplished in the UI / frontend codebase alone. How much of an impact your changes will have on existing operations is the key factor on how much testing will be required. You will also need to make changes (or at least additions) to the API so the UI can access the new stealth functionality.

Could the c-ipfs functionality for the backups be implemented in the frontend code only or will it require backend support as well? I ask b/c if the original wallet was completely stored in the browser I could imagine a direct interface between the UI code in the browser with IPFS, tho it would require porting the c-ipfs over to javascript.

As to when / if a spec will be required to facilitate a release that is up to the shareholders. None have been required in the past, so why should changes for stealth be any different? However, I tend to agree with xeroc's perspective that specs are very useful as a way to characterize functionality and as a tool to help insure test coverage is thorough. Writing a good spec is no guarantee of a successful product, and they do require time to do well.

IMO there are many aspects to the process of code development that could be improved greatly, both frontend AND backend. We will have to come to some type of consensus on what is and is not acceptable minimal standards for the future. I myself would like to see more specs, story boards and use cases as early in the development process as possible.

That is one thing the worker proposal system provides, a type of spec for work to be done. How loose or tight a proposal is and whether it meets minimal standards of acceptability are in the hands of the shareholders. I recall voicing my concerns about Bytemaster's stealth proposal not being adequate and turns out those concerns were valid. Since you have raised your own funds @kenCode the shareholder approval process is moved from the start to the end of the engineering phase, actually all the way to the final deployment phase. I would hate to see all your hard work go to waste due to a failure to convince shareholders of the soundness and reliability of your changes. 

Anyway, looking forward to a view out the window that becomes clearer as we descend from 100,000 feet down to the ground.  I have complete confidence in your abilities @kenCode to avoid the clouds and pilot this thing all the way down to the users on the ground.
 

Thanks @lafona for asking, and for your efforts.

I would  L O V E  to see tools everyone can use to visualize witness metrics. That's one big reason I was the first witness to adopt wackou's bts_tools.

More details on missed blocks and deviation from median price feed might be a good start. I would also like to see info for all witnesses in one place, and with sortable columns like the BitShares 0.9.x era block explorer that @svk built. Also links to each witness' "campaign" forum post or status reports, seed nodes and backup servers run by the witness or other info such as tools created, approach to feeds (algorithms or feed scripts used such as xeroc's, alts, wackou's etc).

Some way to characterize participation on the testnet might also be good, could start with a simple yes they did no they didn't, but more meaningful metrics would be even better.

Frequency and quality / depth of witness reports would be a quantifiable metric, tho to do that right a measurement standard or report template would help to normalize what the reports should / could contain. One example might be witness identity, real world ID or anonymous.

It was suggested that witnesses might be "bonded" with some type of collateral scheme, but IMO this specific point needs more discussion. How would that be done? What amount makes sense? How does that help the security of the DEX? Can the witness use the bond or is it locked, and if so who controls the locking? If not locked (some type of multisig?) perhaps contributions to a common pool for bonds, a witness bond fund, which might could be used as a legal defense fund. Some some ideas I recall have been mentioned before.

Not sure how best to display decentralization, both geographically as well as by hosting providers, but that's important to consider IMO.

Number of forum posts or activities in social media, active in telegram or Friday mumble etc might be useful to gauge community participation.

It would be great if we could come up with a "reputation formula" that aggregates all of the quantifiable metrics into a singe score, and have that plotted over time.

We don't have a "press kit" for marketing materials. You can get common images such as logos at various resolutions / sizes from images.google.com.

Hope that helps. Perhaps @cass or @svk will reply with pgotoshop files if they have any to offer. I don't know which tools they use to produce their graphics, or if they are willing to provide native files for GIMP, Photoshop, Inkscape etc.

Good luck in your search.

Nice job putting that tutorial together @fav, and quick too, as that feature was released only recently.

Quote from: kenCode on March 27, 2017, 01:17:14 pm

Rattling my cage will not make me work more than 18 hours per day, 6 to 7 days per week.

I'm confused...why the hostility? I haven't seen anyone rattling your cage at all, just some basic questions about stealth and suggestions for marketing ideas. Healthy discussion benefits everyone...right?

Exactly. Brings to mind a couple of truisms:

1) Good ideas don't need force to spread
2) People who become defensive when none is needed are fighting imaginary phantoms.

I don't know how many times I need to say this before you actually believe it, but you ARE doing a great job @kenCode . All I would like you to hear is please give us a way to put all of the info you provide in your detailed reports into a rough schedule, something other projects call a roadmap. Ever heard of that concept?

No dammit we don't need you getting all defensive and upset. I hate that appears to be occurring but I am not in control of your emotions. I agree, you need to continue working towards your plan, your grand plan to achieve stealth. You probably have the most working knowledge of how to do it. I have seen NOTHING here on the forum that opposes your leadership and ability to manage the technicals, so I am totally puzzled where all this resistance is coming from.

I'm not "posturing", only trying to help all of your hard work @kenCode to be successful. I may not be a great leader or a professional marketer. All I'm doing is trying to stimulate a discussion which you are apparently opposed to. What confuses me is why? Why does this threaten you ken?

Why are you so opposed to providing us a view at a higher level, one that helps us see the bigger picture of the sequence of completion required to arrive at the stealth tech YOU are building, that YOU designed? I can only assume you have sat down and planned the course you're now on, and are not "flying by the seat of your pants" reacting to the technical issues as you figure out a design. Projects that are managed that way are chaotic and rarely on schedule and on budget and I don't believe that is your style. 

You obviously spend a not so insignificant amount of time to keep the community informed of all the detailed technical issues you & your team work on each week, so please just consider changing it up enough to show us how and when all those details fit together to achieve the stealth features you have in mind.  Don't make such a big deal of that request, it should not be that much of an effort to explain it. I don't believe you have explained that yet, and if I'm wrong and have overlooked that higher level plan you have in mind then just point that out. As you can see from this thread I'm not the only one that has questions about it. Forget about dates, just describe the sequence of elements that need to be built or are already complete.

You would be better served to save your words for describing your project plan than to use them accusing others of what they are doing. Using the strawman or red herring logical fallacies to avoid dealing with the substance of an argument. We all contribute in various ways. It's totally unfair to compare your contribution to mine and say mine is shit or I'm not doing enough. That is divisive and doesn't help.

Good point @lil_jay890. For the average, non-self reliant, authority seeking, sheeple that shy away from personal responsibility ALL digital currency projects are risky compared to mainstream institutions. It takes time for the tech to mature, for people's fear to reach a point they feel less safe continuing to trust in mainstream / status quo institutions than in the emerging alternatives such as digital currencies. They need to get educated on 1) the weaknesses of the existing money system, 2) what is digital currency, it's strengths & weaknesses.

Trying to reach a mainstream audience and convincing them crypto is safer is a huge burden to undertake as you pointed out at this stage of evolution. We need to come up with a plan to break all of those challenges into smaller, manageable pieces and work on them in parallel to the extent possible. The "working on them in parallel" is going on (look at all of the crypto projects out there) but there is no overall plan or coordinated effort among them; each project is working to achieve their own goals independently, and that is natural and as it should be. May the best effort as evaluated by the free market be successful.

Planing within the BitShares ecosystem is another matter. There isn't much. We need a project roadmap with explicit goals, both short term AND long term, both pointing to increasing adoption, marketcap and shareholder ROI, doing so by providing greater and greater utility. We have a lot of functionality but not so much utility. Some of that is due to lagging documentation and the difficulty of getting up to speed on how to use BitShares. Ease of use is steadily improving, as are the docs and tools that make it easier to put BitShares to use. We definitely need a plan to get the word out.

Oh and as for fears concerning keyloggers, that is a threat to everyone whether they know it or not. They can compromise the security of everything, including mainstream infrastructure. How many people use "Internet Banking" thru mainstream institutions? It's not just a threat to crypto projects.

When I think about the average person's knowledge of computer tech and contrast it with what even I know is possible, the gap is monsterous. That gap represents how advanced tech is over people's ability to use it to help themselves AND society at large, between technology and psychological maturity. The public are young children in adult bodies so to speak. Their knowledge is immature compared with the maturity of the tools at their disposal. 

Thoughts on utilizing a BOINC project to distribute the load generating software required to push the tx/s to new heights? https://steemit.com/beyondbitcoin/@cm-steem/brainstorming-boinc-projects-006#@cm-steem/re-cm-steem-brainstorming-boinc-projects-006-20170326t013749374z

Mentioned the idea on beyondbitcoin #200 too: https://steemit.com/beyondbitcoin/@glitterfart/beyond-bitcoin-radioshow-2017-03-24-gridcoin-raw-recording-for-impatients

What I took away from that conversation is that BOINC would not be suitable for the BitShares testnet to spam the network for testing b/c BOINC projects are geared towards problems where longer term application of CPU resources is required, as opposed to the burst requirements of the testnet. Testing on the testnet is not a continuous, ongoing operation.

I'm not very knowledgeable about BOINC, just commenting on what I heard in the mumble last Friday.

@kenCode, take a chill pill man. I agree there's no reason to rush and botch the implementation to meet some arbitrary deadline. We also need to be cautious about what we say prior to release. Not sure why you responded in such a defensive manor, everybody including myself think you're doing a great job. All I'm saying is please give us a ballpark roadmap on the completion dates for various goals to be achieved along the way, so we don't have to serialize marketing with development. They need to be coordinated, and that obviously hasn't happened yet.

The idea of waiting for every single little aspect of stealth to be ready AND tested BEFORE we begin to market is IMO a big mistake. Software is never perfect, there are always tweaks to do. You said it yourself, stealth has been many months in the making, so we need to start thinking about who and how we will market it. Dash says target audience is grandma, so do you.

Fuzzy mentioned there may be a test version coming out for the testnet as early as 3 weeks. Can you confirm that? If not can you estimate when such a test version might first appear on the testnet?

I'm trying to give the marketing people some substance so they can at least start to plan a marketing approach.

Thx

Quote from: Thom on March 24, 2017, 04:54:43 pm

Let's not let this opportunity slip away!

Well duh.
 
We're just now starting to test transactions and create the first API. Remember how many months it has taken us just to write all the crypto? Remember the months it has taken us on the "trustless setup" algo? Remember the months it has taken us to develop the C-IPFS implementation for the automated Stealth backups?
 
In a few months when Stealth has been thoroughly tested by us, AND all of the components above, AND by the public, then we can think about advertising. Until that time, guess what? Like we used to say in the military, hurry up and wait. I'm not going to rush Stealth at all. At, all.
 
If you want me to stop posting weekly updates on our progress so that you feel better, I will.