Author Topic: [ATTENTION] STEALTH will come on 18th Feb?  (Read 9856 times)

0 Members and 1 Guest are viewing this topic.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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

Offline Akado

  • Hero Member
  • *****
  • Posts: 2752
    • View Profile
  • BitShares: akado
They know I contacted one of the mods just now they will have the rest of the team know.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline clayop

  • Hero Member
  • *****
  • Posts: 2033
    • View Profile
    • Bitshares Korea
  • BitShares: 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?
Bitshares Korea - http://www.bitshares.kr
Vote for me and see Korean Bitshares community grows
delegate-clayop

Offline Akado

  • Hero Member
  • *****
  • Posts: 2752
    • View Profile
  • BitShares: 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.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline 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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Empirical1.2

  • Hero Member
  • *****
  • Posts: 1366
    • View Profile

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.

« Last Edit: February 15, 2016, 07:33:00 pm by Empirical1.2 »
If you want to take the island burn the boats

Offline 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.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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

Offline lil_jay890

  • Hero Member
  • *****
  • Posts: 1197
    • View Profile
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?

Offline CLains

  • Hero Member
  • *****
  • Posts: 2606
    • View Profile
  • BitShares: clains
Such stealth. Much attention.  +5%

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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

Offline lil_jay890

  • Hero Member
  • *****
  • Posts: 1197
    • View Profile
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.

Offline Akado

  • Hero Member
  • *****
  • Posts: 2752
    • View Profile
  • BitShares: 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.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
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.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
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?
BitShares committee member: abit
BitShares witness: in.abit