[ATTENTION] STEALTH will come on 18th Feb?

[iHashFury]

"Knowledge is power" but it depends what you do with it!

[clayop]

Shareholders can subscribe to this link
https://github.com/bitshares/bitshares-2/subscription

To keep up-to-date

IMO this is naïve mind. Devs and witnesses can do that but normal users and business partners don't think a github tag is an announcement.
It's just a lazy manner I think. It only needs 10 min and user-friendly mind to write short announcements and newsletters.

It doesn't take 10 minutes.. a proper well authored document that is not torn apart for being unprofessional or having all kinds of mistakes takes hours.

https://bitsharestalk.org/index.php/topic,19040.30.html

[BunkerChainLabs-DataSecurityNode]

Shareholders can subscribe to this link
https://github.com/bitshares/bitshares-2/subscription

To keep up-to-date

IMO this is naïve mind. Devs and witnesses can do that but normal users and business partners don't think a github tag is an announcement.
It's just a lazy manner I think. It only needs 10 min and user-friendly mind to write short announcements and newsletters.

It doesn't take 10 minutes.. a proper well authored document that is not torn apart for being unprofessional or having all kinds of mistakes takes hours.

[clayop]

Shareholders can subscribe to this link
https://github.com/bitshares/bitshares-2/subscription

To keep up-to-date

IMO this is naïve mind. Devs and witnesses can do that but normal users and business partners don't think a github tag is an announcement.
It's just a lazy manner I think. It only needs 10 min and user-friendly mind to write short announcements and newsletters.

[iHashFury]

Shareholders can subscribe to this link
https://github.com/bitshares/bitshares-2/subscription

To keep up-to-date

[kenCode]

+5%Clayop is right, so is iamfox, who is calling for witnesses to vet the new release (i.e. test it) before it goes into production.

This has been taken for granted far too long. We need to allow time in the deployment schedule to allow witnesses to test a release, and until now this has not been done or much concern shown for it. We need to take deployment of new code seriously. It only serves to strengthen confidence, not just that we know what we're doing but also that we take such measures to protect the integrity of the BitShares network.

It would be nice to see some type of report from the devs that shows they have tested the release and signed off on it for production readiness.

The witnesses are discussing this on telegram now. It will take time for this discussion to make it's way through all the witnesses to get a commitment on gathering the resources (i.e. VPS nodes) required to devote to a testnet to serve as a staging area for pre-production testing.

 

[Thom]

 +5%Clayop is right, so is iamfox, who is calling for witnesses to vet the new release (i.e. test it) before it goes into production.

This has been taken for granted far too long. We need to allow time in the deployment schedule to allow witnesses to test a release, and until now this has not been done or much concern shown for it. We need to take deployment of new code seriously. It only serves to strengthen confidence, not just that we know what we're doing but also that we take such measures to protect the integrity of the BitShares network.

It would be nice to see some type of report from the devs that shows they have tested the release and signed off on it for production readiness.

The witnesses are discussing this on telegram now. It will take time for this discussion to make it's way through all the witnesses to get a commitment on gathering the resources (i.e. VPS nodes) required to devote to a testnet to serve as a staging area for pre-production testing.

[luckybit]

https://github.com/bitshares/bitshares-2/releases/tag/2.0.160216

I'm little sick of this kind of practice...

BM said the upgrade will be Thursday only in mumble. NO pre-announcement.

Theoretical post update Tuesday. NO announcement on forum or via email.

The devs should realize that Github notification is not an announcement. We need more formal and official one, to become a successful platform.

We are in the process of notifying exchanges and posting the update in the appropriate threads.  We cannot broadcast on all channels at the same time.  Also, it is helpful to have witnesses verify the code before we notify exchanges.

That makes sense. I maybe over sensitive, but we should notify all types of customers, not only exchanges, so that we need more specific channel IMHO.

http://mailchimp.com/

[Akado]

Sure devs are expected to do that since they are more into those matters and have more info than us, but if it's a problem that big - just letting them know there will be a fork - why not just tell them ourselves too? The community also needs to be proactive. Sure any issues during an update that might appear (ie 1.0 to 2.0 update) should have a closer look from the devs and provide some help if necessary.

However if the problem is just informing them why can't the community do it too? Yesterday I just went to Polo and told a mod who said he would pass the info to the rest of the crew, what's the problem with that? 2m and it's done.

Yeah I already noticed polo two days ago via ticket (it took 3 min :p) But it's a matter of organizing things and services. What if they asked you where's the announcement they can read? Go and read the whole script of hangout?

GeezUp asked me for a link for the updates and I provided one that xeroc shared here, wasn't sure if it was that one lol but they know about it that's what matters, mission accomplished.

[clayop]

Sure devs are expected to do that since they are more into those matters and have more info than us, but if it's a problem that big - just letting them know there will be a fork - why not just tell them ourselves too? The community also needs to be proactive. Sure any issues during an update that might appear (ie 1.0 to 2.0 update) should have a closer look from the devs and provide some help if necessary.

However if the problem is just informing them why can't the community do it too? Yesterday I just went to Polo and told a mod who said he would pass the info to the rest of the crew, what's the problem with that? 2m and it's done.

Yeah I already noticed polo two days ago via ticket (it took 3 min :p) But it's a matter of organizing things and services. What if they asked you where's the announcement they can read? Go and read the whole script of hangout?

[Akado]

Sure devs are expected to do that since they are more into those matters and have more info than us, but if it's a problem that big - just letting them know there will be a fork - why not just tell them ourselves too? The community also needs to be proactive. Sure any issues during an update that might appear (ie 1.0 to 2.0 update) should have a closer look from the devs and provide some help if necessary.

However if the problem is just informing them why can't the community do it too? Yesterday I just went to Polo and told a mod who said he would pass the info to the rest of the crew, what's the problem with that? 2m and it's done.

[clayop]

https://github.com/bitshares/bitshares-2/releases/tag/2.0.160216

I'm little sick of this kind of practice...

BM said the upgrade will be Thursday only in mumble. NO pre-announcement.

Theoretical post update Tuesday. NO announcement on forum or via email.

The devs should realize that Github notification is not an announcement. We need more formal and official one, to become a successful platform.

We are in the process of notifying exchanges and posting the update in the appropriate threads.  We cannot broadcast on all channels at the same time.  Also, it is helpful to have witnesses verify the code before we notify exchanges.

That makes sense. I maybe over sensitive, but we should notify all types of customers, not only exchanges, so that we need more specific channel IMHO.

[bytemaster]

https://github.com/bitshares/bitshares-2/releases/tag/2.0.160216

I'm little sick of this kind of practice...

BM said the upgrade will be Thursday only in mumble. NO pre-announcement.

Theoretical post update Tuesday. NO announcement on forum or via email.

The devs should realize that Github notification is not an announcement. We need more formal and official one, to become a successful platform.

We are in the process of notifying exchanges and posting the update in the appropriate threads.  We cannot broadcast on all channels at the same time.  Also, it is helpful to have witnesses verify the code before we notify exchanges.

[clayop]

https://github.com/bitshares/bitshares-2/releases/tag/2.0.160216

I'm little sick of this kind of practice...

BM said the upgrade will be Thursday only in mumble. NO pre-announcement.

Theoretical post update Tuesday. NO announcement on forum or via email.

The devs should realize that Github notification is not an announcement. We need more formal and official one, to become a successful platform.

[abit]

Ben is preparing the release for stealth, we can set the hard fork date to any day we like, but the code should be frozen today with all changes merged to the Bitshares branch.

Sounds good.

We will give exchanges 1 week notice from the time we publish the final code.

Acceptable for me.

So how about public testing? Looks like fewer people cares (than the announcement/notice)?
Or at least do you have an internal testing report which can be publicized? @bytemaster

[noisy]

We should have public board with all our partners listed on it.

Also each partner should have status:

Legend:

- [Email Sent] - email (signed with PGP key) with information about upgrade to oficial email
- [Confirmation Of Receipt] - partner confirmed that he recived an email. (At least we know that we have up-to date email address). We are not assuming that partner is ready.
- [Concerns Raised - <link>] - in case when partner raised any concerns about procedure of upgrade. Partner then should create a thread on forum, there should be link to this thread next to status
- [Ready for upgrade] - partner confirmed, that he is ready for upgrade
- [Update In Progress - ETA: 12:00 CET, 29th Feb] - partner is in the middle of upgrade. ETA is known.
- [Upgrade Finished] - partner and users confirmed, that upgrade is finished.


We should also have list of our VIP partners. Hardfork should not be made it all VIP parter at least not confirm that they are aware about it.
If one of our VIP partner is not ready, we should put extra effor to help him.


Motivation for that:

As a user/shareholder of bitshares, I would like to know, which exchage is safe to trade bitshares. This information have to be public and in one place!

[karnal]

maybe I'm missing something... why is it important to inform exchanges about stealth?  Is it just important to inform them of any hardfork?  If they are not informed, will this prevent them from making BTS transfers?

It would be nice if they can provide a per-user option of sending funds in stealth mode only.

[xeroc]

I'm INCREDIBLY eager to have STEALTH features along with the hosted web wallet (with 2FA?).   But I agree with those on this thread expressing the great importance of giving our exchange partners some advance warning of this hard fork.

You can add 2FA not to your wallet but to your account with this: http://beta.peermit.com/

There is no 2FA for the wallet currently.

I see.  Interesting.  @xeroc mentioned that a 2FA solution would be ready along with the upcoming release of the new hosted web wallet.  I assume this is what he was referring to?

That is xerocs 2FA solution. I don't know if it is ready for integration into the wallet yet though. Yes though, this is what he would have been referring to. There are no others currently under development.

working on it .. not sure I can make it until then .. the React-JS stuff is a little different to code then python and takes some more time.
It will also stay in beta first so that I have a chance to spot and fix bugs in the backend stuff .. Also need an SSL cert and stuff like that first so that this actually WORKS in combination with the wallet ..
Gonna keep you posted ..

[BunkerChainLabs-DataSecurityNode]

I'm INCREDIBLY eager to have STEALTH features along with the hosted web wallet (with 2FA?).   But I agree with those on this thread expressing the great importance of giving our exchange partners some advance warning of this hard fork.

You can add 2FA not to your wallet but to your account with this: http://beta.peermit.com/

There is no 2FA for the wallet currently.

I see.  Interesting.  @xeroc mentioned that a 2FA solution would be ready along with the upcoming release of the new hosted web wallet.  I assume this is what he was referring to?

That is xerocs 2FA solution. I don't know if it is ready for integration into the wallet yet though. Yes though, this is what he would have been referring to. There are no others currently under development.

[tbone]

I'm INCREDIBLY eager to have STEALTH features along with the hosted web wallet (with 2FA?).   But I agree with those on this thread expressing the great importance of giving our exchange partners some advance warning of this hard fork.

You can add 2FA not to your wallet but to your account with this: http://beta.peermit.com/

There is no 2FA for the wallet currently.

I see.  Interesting.  @xeroc mentioned that a 2FA solution would be ready along with the upcoming release of the new hosted web wallet.  I assume this is what he was referring to?

[BunkerChainLabs-DataSecurityNode]

I'm INCREDIBLY eager to have STEALTH features along with the hosted web wallet (with 2FA?).   But I agree with those on this thread expressing the great importance of giving our exchange partners some advance warning of this hard fork.

You can add 2FA not to your wallet but to your account with this: http://beta.peermit.com/

There is no 2FA for the wallet currently.

[sudo]

test in devshares

[TravelsAsia]

I think if they are notified via skype, an email to the CTO's and even a phone call, then this close relationship will instill trust again.

   I'd also add a post to their official forum as Clayop mentioned earlier in the thread. 

[kenCode]

I think if they are notified via skype, an email to the CTO's and even a phone call, then this close relationship will instill trust again.

[clayop]

We will give exchanges 1 week notice from the time we publish the final code.

Posting code is not an announcement. We must not assume that all business partners are  subscribing/monitoring our code-base.

I would suggest,

1. Make an announcement section in the forum or official site
2. Or use a newsletter to announce incoming hard forks (you may have the list for 2.0 launch)

[bytemaster]

We will give exchanges 1 week notice from the time we publish the final code.

[clayop]

maybe I'm missing something... why is it important to inform exchanges about stealth?  Is it just important to inform them of any hardfork?  If they are not informed, will this prevent them from making BTS transfers?

Absolutely it prevents. Deposit and withdraw will be suspended if they cannot follow hardfork.

[lil_jay890]

maybe I'm missing something... why is it important to inform exchanges about stealth?  Is it just important to inform them of any hardfork?  If they are not informed, will this prevent them from making BTS transfers?

[clayop]

Ben is preparing the release for stealth, we can set the hard fork date to any day we like, but the code should be frozen today with all changes merged to the Bitshares branch.

So will your team contact exchanges? Or leave them behind?

There is a skype group with many exchanges that has been created for this particular case (and for emergency fixes of course)
bytemaster is in that group as well

We will have many other service providers on BTS. Skype is not enough if we have numerous partners.  So it would be better to have an announcement page in the official site IMO.

[tbone]

I'm INCREDIBLY eager to have STEALTH features along with the hosted web wallet (with 2FA?).   But I agree with those on this thread expressing the great importance of giving our exchange partners some advance warning of this hard fork. 

[xeroc]

Ben is preparing the release for stealth, we can set the hard fork date to any day we like, but the code should be frozen today with all changes merged to the Bitshares branch.

So will your team contact exchanges? Or leave them behind?

There is a skype group with many exchanges that has been created for this particular case (and for emergency fixes of course)
bytemaster is in that group as well

[Akado]

They know I contacted one of the mods just now they will have the rest of the team know.

[clayop]

Ben is preparing the release for stealth, we can set the hard fork date to any day we like, but the code should be frozen today with all changes merged to the Bitshares branch.

So will your team contact exchanges? Or leave them behind?

[Akado]

Is it reasonable or neglectful to expect our partners to monitor proposal voting and set their plans accordingly?

If we were more respected we wouldn't have to go to them to make sure they were ready, they would just watch us and BE ready when necessary. I just don't think we should expect that, and we ought to make sure -- proactively -- that our partners are ready for any hardfork we might have in the pipeline.

It's EXTREMELY neglectful to expect partners/exchanges to be ready imo.

BTS lost a lot of value/momentum because the BTS 2.0 update wasn't properly communicated and planned with exchanges. The exchanges themselves lost little business overall and mostly maintained their BTS market share after too. So the only one that loses if BTS doesn't properly communicate and plan with exchanges/others is BTS itself.

I agree with this. You can have the luxury of not caring about that when you're too big like LTC and BTC. If you're not, you need to let others know. For some reason we're too small and depend on others, so why should we act like it doesn't matter us at all? Maybe we will be able to do that some day but for not that's a luxury.

The only ones who get hurt if we don't let others know is ourselves. Maybe in the future others will depend on us or will have incentives to care, right now, they don't. We only hurt ourselves.

[bytemaster]

Ben is preparing the release for stealth, we can set the hard fork date to any day we like, but the code should be frozen today with all changes merged to the Bitshares branch.

[Empirical1.2]

Is it reasonable or neglectful to expect our partners to monitor proposal voting and set their plans accordingly?

If we were more respected we wouldn't have to go to them to make sure they were ready, they would just watch us and BE ready when necessary. I just don't think we should expect that, and we ought to make sure -- proactively -- that our partners are ready for any hardfork we might have in the pipeline.

It's EXTREMELY neglectful to expect partners/exchanges to be ready imo.

BTS lost a lot of value/momentum because the BTS 2.0 update wasn't properly communicated and planned with exchanges. The exchanges themselves lost little business overall and mostly maintained their BTS market share after too. So the only one that loses if BTS doesn't properly communicate and plan with exchanges/others is BTS itself.

[Thom]

Nevertheless, abit's concerns are valid, in terms of what WE do to inform our partners to be ready.

Is it reasonable or neglectful to expect our partners to monitor proposal voting and set their plans accordingly?

If we were more respected we wouldn't have to go to them to make sure they were ready, they would just watch us and BE ready when necessary. I just don't think we should expect that, and we ought to make sure -- proactively -- that our partners are ready for any hardfork we might have in the pipeline.

As for testing, I agree some type of test plan should have been created, and any infrastructure required to implement the test plan put in place. Can xeroc's testnet serve that purpose? How much time should be given to test this feature?

I totally agree with you abit, we need to be **more** professional than we have been in the past. This just looks like yet another ad hoc roll out to me, perhaps motivated by schedule issues rather than any concern for partners preparedness.

Once we get to be a certain size or have gained enough respect in the crypto community this "hand holding" on our part to make sure partners are informed & ready will go away.

[xeroc]

The hardfork has been approved via voting of the STEALTH worker.
Anyone wanting to read into FBA, can already do so from the graphene/develop code. AFAIK most of FBA and STEALTH (mostly API calls) are already there

Is this the code kept in github?  Is this also in the help section of the wallet?  Do you have a link?

https://github.com/cryptonomex/graphene/branches

this is a set of "branches" that carry different features. Most of what is needed for the FBA (if I understand correctly) is in the "buyback" branch.
The upgrades for the wallet are here
https://github.com/cryptonomex/graphene-ui/branches
in the "650-stealth-wallet" branch

[lil_jay890]

The hardfork has been approved via voting of the STEALTH worker.
Anyone wanting to read into FBA, can already do so from the graphene/develop code. AFAIK most of FBA and STEALTH (mostly API calls) are already there

Is this the code kept in github?  Is this also in the help section of the wallet?  Do you have a link?

[CLains]

Such stealth. Much attention. 

[xeroc]

The hardfork has been approved via voting of the STEALTH worker.
Anyone wanting to read into FBA, can already do so from the graphene/develop code. AFAIK most of FBA and STEALTH (mostly API calls) are already there

[lil_jay890]

I think it is supposed to be ready by the 18th. If it is, it doesn't mean we need to fork it asap, let it be ready and once we have talked with everyone, it's done. I recall BM mentioning one of the devs was to schedule the hardfork however atm I dont remember if it is already decided to be on the 18th or if everything is ready on the 18th but it will be forked later.

Either way what matters is it's ready, then we can wait and plan the fork accordingly so it shouldn't be a problem.

He said the hardfork will be this thursday.

[Akado]

I think it is supposed to be ready by the 18th. If it is, it doesn't mean we need to fork it asap, let it be ready and once we have talked with everyone, it's done. I recall BM mentioning one of the devs was to schedule the hardfork however atm I dont remember if it is already decided to be on the 18th or if everything is ready on the 18th but it will be forked later.

Either way what matters is it's ready, then we can wait and plan the fork accordingly so it shouldn't be a problem.

[kenCode]

yeah, this one is a doozie.
do NOT announce fba or stealth to the world until the bts community here can beat the hell out of it and the gui for it first.

[abit]

I heard that a new release of BitShares will come on 18th Feb, which will contain the STEALTH and FBA features. It's said that @bytemaster "announced" it in last Friday's mumble hangout. I haven't listened to the recording of that hangout so I'm not sure what actually it is. Just post some concerns here.

1. It seems no "official announcement" has been posted on the forum about the release. We'd better have at least a schedule: when will release, when is the hard fork and etc, so our PARTNERS and the community can plan accordingly in advance.

2. Will we do public testing before the final release? IMHO we'd better do it. However, here comes a challenge that how to judge whether the product is fully tested. Do we need a testing report? Who will provide the report? How much time do we need to audit the report?  Who will audit?

In short, let's be professional.

Thoughts?