Publicly expressing my concern about the hard-coded hard fork to 2.0

[fav]

market the GUI as early beta / alpha and make it visible. and implement a feedback function asap.

as for the launch,

I only really care about

* Stable Network
* Referral Program

Affiliate Program will not be ready for the launch...

[wackou]

Please note that I do want to have it released as soon as possible, and I know the devs are doing everything humanly possible in order to achieve that. But I'd rather be on the "too cautious" side of things rather than "too optimistic".

Also, I think that my opinions (amongst others) have been clearly stated here, so I will stop posting in this thread, in the end it's Cryptonomex's decision and responsibility when to release and endlessly arguing will not change their mind. I do already have my fingers crossed, though, so that everything goes fine next week, and would be praying too if I believed it could make a difference...

[Pheonike]

At least make the wallet upgrade flawless. A new/ old user should not need CLI commands to upgrade to 2.0 . its already confusing enough with knowing the differences between wallets, keys and accounts.

[monsterer]

Can we please distinguish the UI from the Backend (blockchain)

The reason that the GUI doesn't fit everyone's needs is not good enough to not release the backend in time ..
We could run the blockchain .. let exchanges integrate with it and tag the UI "experimental" .. and we can do this by next week .. that's more than people around ethereum have running!

I am referring to the blockchain.

[wackou]

It's already released, it's called testnet. Beta is far different than alpha.

Can we please distinguish the UI from the Backend (blockchain)

The reason that the GUI doesn't fit everyone's needs is not good enough to not release the backend in time ..

I want to agree with you, but I can't. End users will not (and should not) care what is the root cause of the crashes that they will see. They will only care that it crashed, and that BitShares sucks... (note that I'm not talking about missing features but about stability here) And nobody is going to run the CLI client, everyone will be on the GUI client.

And even if we care only about the backend, then judging by the latest testnet thread and the github issues there are still some fundamental issues to be fixed. Just an example:

bitshares-argentina  can you please let me know if you have changed your software in any way because it appears your node is consistently producing blocks even though you are not in the set of active witnesses.

That doesn't inspire a lot of confidence that it will be industrial-strength in less than a week...

We could run the blockchain .. let exchanges integrate with it and tag the UI "experimental" .. and we can do this by next week ..

that's ok for a first release, not so much for a 2.0 release....

that's more than people around ethereum have running!

We should stop comparing ourselves to ethereum but rather to our former selves (BitShares 0.9.x). What if BitShares 2.0 is released and it's better than Ethereum, but worse than BitShares 0.9. Will this be a success or a failure?

[fav]

market the GUI as early beta / alpha and make it visible. and implement a feedback function asap.

as for the launch,

I only really care about

* Stable Network
* Referral Program

[jakub]

It's already released, it's called testnet. Beta is far different than alpha.

Can we please distinguish the UI from the Backend (blockchain)

The reason that the GUI doesn't fit everyone's needs is not good enough to not release the backend in time ..
We could run the blockchain .. let exchanges integrate with it and tag the UI "experimental" .. and we can do this by next week .. that's more than people around ethereum have running!

That would be the best way to handle it.
The GUI is not ready and it's easy for everyone to see - as of now it does not offer a full replacement of the previous GUI and even if the devs can somehow manage to finish it this week, it will not be thoroughly tested.

UX was meant to be our priority in 2.0 but the GUI has not been tested in a way that even remotely resembles the accuracy of the blockchain's tests.
 
As for the 2.0 blockchain itself, BM is in the best position to make that judgement so if he says we are good I'd trust him.

Therefore it's a good idea to release the blockchain on Oct 13th but give the GUI a couple of days to settle before announcing it publicly.

Apart from the UX aspect, the GUI is important as it handles the user's private keys.
If it does something stupid or unintended by the user (e.g. placing an order with a wrong price) it will hurt us badly.

[xeroc]

It's already released, it's called testnet. Beta is far different than alpha.

Can we please distinguish the UI from the Backend (blockchain)

The reason that the GUI doesn't fit everyone's needs is not good enough to not release the backend in time ..
We could run the blockchain .. let exchanges integrate with it and tag the UI "experimental" .. and we can do this by next week .. that's more than people around ethereum have running!

[monsterer]

then why not communicate this ? We could also publish as an alpha/beta version .. don't we ?
google mail was over 2 year in beta modus AFAIK

It's already released, it's called testnet. Beta is far different than alpha.

[cass]

as bytemaster said:  If we wait to release it when no "bugs" are present, we will never release it!
Time will not stop at 13 October, we will make more updates after this date, nothing wrong with that!

There is a HUGE gap between 'perfect' and 'alpha' quality - right now we have an 'alpha' quality product, which may not be fit for purpose.

then why not communicate this ? We could also publish as an alpha/beta version .. don't we ?
google mail was over 2 year in beta modus AFAIK

[wackou]

as bytemaster said:  If we wait to release it when no "bugs" are present, we will never release it!
Time will not stop at 13 October, we will make more updates after this date, nothing wrong with that!

There is a HUGE gap between 'perfect' and 'alpha' quality - right now we have an 'alpha' quality product, which may not be fit for purpose.

can't agree more. If there are some bugs (crashes, UI problems, etc...) we, the already existing BitShares community, won't mind that much (I know I won't), but people from the outside, to whom we've told that 2.0 is going to be better in all aspects than 0.9.x, more stable, better UI, etc. will probably think that we're a bunch of incompetent, under-delivering guys when they see that their wallet crashes not even 1 day after installing it. As discussed at length in other threads, it's all about perception, and I'm really worried that 1 week is not enough to fix everything left that's required to give you that "wow!" effect that we promised.

There are a *lot* of people watching for the 2.0 release, and I think "better safe than sorry" should be a guiding principle as to when to do the release. And we should talk about it now, because if current delegates have to downgrade to 0.9.2 (or upgrade to 0.9.4 that removes the hard-fork with stopped block production after the deadline), then we should be preparing for that already.

[monsterer]

as bytemaster said:  If we wait to release it when no "bugs" are present, we will never release it!
Time will not stop at 13 October, we will make more updates after this date, nothing wrong with that!

There is a HUGE gap between 'perfect' and 'alpha' quality - right now we have an 'alpha' quality product, which may not be fit for purpose.

[liondani]

as bytemaster said:  If we wait to release it when no "bugs" are present, we will never release it!
Time will not stop at 13 October, we will make more updates after this date, nothing wrong with that!

[jakub]

It would hurt bts much more if we delayed... The product needs to be released in the 13th

Apart from the known issues there are important aspects that have never been tested outside CNX, e.g. the referral program, going through the full cycle of collateral positions, market charts.
It's quite certain that there will be bugs popping up so it's just a matter of guessing how critical these bugs will be.

For me the main point of BTS 2.0 is to prove that we've learned our lessons. And one of the main lessons was about bad UX hurting us a lot.
And now we are going to release a GUI that looks and feels great but has never been fully tested in all major aspects. That's a lesson we did not learn.

[lil_jay890]

It would hurt bts much more if we delayed... The product needs to be released in the 13th

[jakub]

I urge you to reconsider your launch date.

I really have to side with Monsterer here.

I don't doubt that you (bytemaster) feel confident, and I usually trust your judgement, but in this very particular case (BTS 2.0 launch with a *lot* of people watching us) I really believe that we need a fully-featured testnet running flawlessly for at least 2 weeks before even trying to attempt a release. I know that you guys got a lot of flak in the past for missed deadlines, but this time you promised really strong stability of the network and you should aim for that rather than the promised deadline.

Maybe a meager 2 additional weeks would be more than enough, depending on how the current testnet goes, but there are still very problematic issues to be solved and they keep popping up. Frequency and severity keeps dropping, of course (which indeed means we're getting closer to a stable release by the day), but when you still have a hard-fork-requiring issue popping up less than a week from final release, this seems overly optimistic (https://github.com/cryptonomex/graphene/issues/355, nothing in particular against this issue, it's just an example)

That's my feeling too, judging by the progress on the GUI side.

Since yesterday's upgrade I've reported several issues on github, some of them causing the GUI to crash completely, e.g.
https://github.com/cryptonomex/graphene-ui/issues/286

The GUI is definitely not ready and there is no way it can be within these couple of days that are left.
People will be complaining if we launch like this and it will hurt our reputation more than postponing for a week or two.

[wackou]

I urge you to reconsider your launch date.

I really have to side with Monsterer here.

I don't doubt that you (bytemaster) feel confident, and I usually trust your judgement, but in this very particular case (BTS 2.0 launch with a *lot* of people watching us) I really believe that we need a fully-featured testnet running flawlessly for at least 2 weeks before even trying to attempt a release. I know that you guys got a lot of flak in the past for missed deadlines, but this time you promised really strong stability of the network and you should aim for that rather than the promised deadline.

Maybe a meager 2 additional weeks would be more than enough, depending on how the current testnet goes, but there are still very problematic issues to be solved and they keep popping up. Frequency and severity keeps dropping, of course (which indeed means we're getting closer to a stable release by the day), but when you still have a hard-fork-requiring issue popping up less than a week from final release, this seems overly optimistic (https://github.com/cryptonomex/graphene/issues/355, nothing in particular against this issue, it's just an example)

[xeroc]

No need to worry guys. BTS 2.0 will run smoothly and we should not release it any later than planned. Go Cryptonomex! /s

^ This!

[NewMine]

I don't think so. Dev team changed transaction throughput 50x and due to this network dies. I had a test before the test and it was quite stable.

How long did that 'stable' test network live? More than 10 days?

IIRC, it was the longest testnet.

That's what she said.

[NewMine]

We are ready.  If we are concerned about a spam attack on the live network we can alway start with a smaller blocksize.

How come yet another new testnet has started, then? I'm not sure I agree with your definition of 'ready'.

Will you quit your FUDing! Your comments are counterproductive. Instead of fixing things the devs are here wasting their time responding to your legitimate concerns. You are such a troll for bumping this 2 week old thread and having worries based on the current status and direction of a promised unreleased product that has a direct link to one of your investments worth.

No need to worry guys. BTS 2.0 will run smoothly and we should not release it any later than planned. Go Cryptonomex! /s

[dichalcog3nid3]

I believe it was more than 10 days during which time more than a half million transactions were pushed through the network with many flooding attempts.   

We made a few small changes to the vote counting, but have implemented unit tests for it and the last testnet (the one the crashed and burned) verified those changes worked fine (it crashed and burned for a different reason).  Perhaps the biggest reason it crashed was that 10 witnesses were on the SEED node and the seed node crashed (looks like it was due to insufficient memory on a barebones VPS) and I wasn't around for a day.   In a real network no more than one witness would be on a machine and it would have been restarted.   In other words, the test network was run less carefully than a real network would have been because we were testing different things.

Perhaps the most important feature we have right now is the "last irreversible block" concept which gives all participants a guarantee that even if the real network has some unscheduled down time that the last irreversible block will never be undone after the network gets back up.

All I care about is that the blockchain is RECOVERABLE in the event that consensus is disrupted.   If we aim for 100% perfection on launch it will never happen.

https://www.youtube.com/watch?v=UUdjV5ElOuk

[bytemaster]

I don't think so. Dev team changed transaction throughput 50x and due to this network dies. I had a test before the test and it was quite stable.

How long did that 'stable' test network live? More than 10 days?

I believe it was more than 10 days during which time more than a half million transactions were pushed through the network with many flooding attempts.   

We made a few small changes to the vote counting, but have implemented unit tests for it and the last testnet (the one the crashed and burned) verified those changes worked fine (it crashed and burned for a different reason).  Perhaps the biggest reason it crashed was that 10 witnesses were on the SEED node and the seed node crashed (looks like it was due to insufficient memory on a barebones VPS) and I wasn't around for a day.   In a real network no more than one witness would be on a machine and it would have been restarted.   In other words, the test network was run less carefully than a real network would have been because we were testing different things.

Perhaps the most important feature we have right now is the "last irreversible block" concept which gives all participants a guarantee that even if the real network has some unscheduled down time that the last irreversible block will never be undone after the network gets back up.

All I care about is that the blockchain is RECOVERABLE in the event that consensus is disrupted.   If we aim for 100% perfection on launch it will never happen.

[clayop]

I don't think so. Dev team changed transaction throughput 50x and due to this network dies. I had a test before the test and it was quite stable.

How long did that 'stable' test network live? More than 10 days?

IIRC, it was the longest testnet.

[monsterer]

I don't think so. Dev team changed transaction throughput 50x and due to this network dies. I had a test before the test and it was quite stable.

How long did that 'stable' test network live? More than 10 days?

[clayop]

If by "bunch of changes" you mean changing a configurable constant in the P2P code?

It doesn't matter how big the change was - something was changed, therefore all previous testing is null and void.

I don't think so. Dev team changed transaction throughput 50x and due to this network dies. I had a test before the test and it was quite stable.

[monsterer]

If by "bunch of changes" you mean changing a configurable constant in the P2P code?

It doesn't matter how big the change was - something was changed, therefore all previous testing is null and void.

[bytemaster]

The last test network was like "crash testing" a car.   We intentionally stressed it until it did break so we knew where our limits were.   The current test network has scaled things back to a "safe" level.  A level that had previously been tested and found stable.

I have no doubts about the final BTS 2 network being stable.

Nevertheless, it died and you made a bunch of changes and now there is a new version, which will only have just over 1 week of full testing before launch. You're asking multiple businesses to put their trust and finances behind in a product with only 1 week of testing!

I urge you to reconsider your launch date.

If by "bunch of changes" you mean changing a configurable constant in the P2P code? 

[monsterer]

The last test network was like "crash testing" a car.   We intentionally stressed it until it did break so we knew where our limits were.   The current test network has scaled things back to a "safe" level.  A level that had previously been tested and found stable.

I have no doubts about the final BTS 2 network being stable.

Nevertheless, it died and you made a bunch of changes and now there is a new version, which will only have just over 1 week of full testing before launch. You're asking multiple businesses to put their trust and finances behind in a product with only 1 week of testing!

I urge you to reconsider your launch date.

[bytemaster]

So my definition of ready in that particular comment was "ready to launch on the 13"

Despite the fact that the last testnet blew up and a new one has been started less than 10 days from launch? Like I say, your definition of 'ready' is broken.

The last test network was like "crash testing" a car.   We intentionally stressed it until it did break so we knew where our limits were.   The current test network has scaled things back to a "safe" level.  A level that had previously been tested and found stable.

I have no doubts about the final BTS 2 network being stable.

[monsterer]

So my definition of ready in that particular comment was "ready to launch on the 13"

Despite the fact that the last testnet blew up and a new one has been started less than 10 days from launch? Like I say, your definition of 'ready' is broken.

[puppies]

We are ready.  If we are concerned about a spam attack on the live network we can alway start with a smaller blocksize.

How come yet another new testnet has started, then? I'm not sure I agree with your definition of 'ready'.

It was a response to sudo asking if we're ready to launch on the 13th

so are we ready release bts2.0 in Oct 13?  about a week later?

We are ready.  If we are concerned about a spam attack on the live network we can alway start with a smaller blocksize. 

So my definition of ready in that particular comment was "ready to launch on the 13"

[monsterer]

We are ready.  If we are concerned about a spam attack on the live network we can alway start with a smaller blocksize.

How come yet another new testnet has started, then? I'm not sure I agree with your definition of 'ready'.

[clayop]

so are we ready release bts2.0 in Oct 13?  about a week later?

We are ready.  If we are concerned about a spam attack on the live network we can alway start with a smaller blocksize.

 

[monsterer]

Clayop has published a poll asking what TPS goal should the next testnet strive for, but I'm not sure throughput and high performance should be the focus right now. On the other hand perhaps that is exactly the best approach to uncover bugs that threaten the reliability and robustness of the network.

This. Performance must be a secondary concern to stability.

[puppies]

so are we ready release bts2.0 in Oct 13?  about a week later?

We are ready.  If we are concerned about a spam attack on the live network we can alway start with a smaller blocksize. 

[sudo]

so are we ready release bts2.0 in Oct 13?  about a week later?

[cube]

I think the spam tests so far has strenthened and not weakened the idea that graphene would be ready for 13 Oct.  The current 'fund transfer operation' spam tests are discovering bugs which BM and team are actively solving.  graphene is not and should not be built on theoretical transaction limit but based on close-to real-world tests.  The bitshare community is actively supporting and working with the dev team to make this happen. 

We are now at 1000TPS limit (based on transfer operation) but we are going to break this limit when BM is back from his weekend rest.  And when the other load test scripts are ready (soon), we would be showing to the public that bitshares 2.0 is ready for some real-world bashing.

[Thom]

Still planning a release on the 13th? How long has the most recent testnet lasted?

Although BM has expressed his strong confidence for a 10/13 hard fork release, I too share some of your reservations monsterer. There are a myriad of details yet to be completed. The time is getting very short and I for one would like to see a test strategy for the testnet and advanced notice of what the goals are for all tests to be done before launch.

"spamming" tests that clayop is doing have revealed some weaknesses and your point about how long lasting a given test is able to be sustained before the test must be restarted or a new checkpoint established is not very long.

If these transaction flooding tests are killing the network at only 10% of our published throughput claims that won't play well for us in the marketplace. It could only serve to weaken our already weak standing in the crypto world.

Clayop has published a poll asking what TPS goal should the next testnet strive for, but I'm not sure throughput and high performance should be the focus right now. On the other hand perhaps that is exactly the best approach to uncover bugs that threaten the reliability and robustness of the network.

I would like to see a set of several VPSs setup as seed nodes and witnesses configured with failover tested. I haven't explicitly looked for it but I would love to see docs or forum threads talking about how to best implement failover for graphene witnesses. Wackou and I have some ideas, not only for DDoS protection and small world backbone + seed configuration, but also how to monitor failures and what to do when they are detected.

BM indicated in last Friday's mumble there isn't time to address the code changes wackou has proposed before the 13th, but we need to get busy and get a testnet in place that is robust enough to be a live production setup if it had to be.

Xeroc is busy working on documentation, and has written a migration document that described quite well how to export a json file from 0.9.3 for the purpose of importing account balances into graphene. I was under the impression users would not be required to perform an export / import operation, all accounts and their balances will be migrated automatically so long as they are in a fully synced wallet with no outstanding transactions pending. Perhaps I've misunderstood the purpose of those docs, maybe they are not intended for the general public.

It may not be possible or considered important enough but I would very much like to see cli wallet commands documented individually like they were in the 0.9.2 client rather than the entire list splatted to the screen. I can appreciate that hasn't been a priority, and not be  very important to do before release, but I really miss the way it used to be in 0.9.x.

[jsidhu]

Wouldn't it be simpler to request the exchanges suspend BTS deposits and withdrawals on the 13th?

This way their internal exchange can stay functioning and there should be issues while they upgrade to 2.0 as well.

That doesnt stop insider trading

[monsterer]

Still planning a release on the 13th? How long has the most recent testnet lasted?

[bobmaloney]

Wouldn't it be simpler to request the exchanges suspend BTS deposits and withdrawals on the 13th?

This way their internal exchange can stay functioning and there should be issues while they upgrade to 2.0 as well.

[Akado]

Couldn't we ask the Exchanges to explicitly mention which kind of Bitshares they would be trading? After the snapshot, BitShares of the old chain would be called BitShares 1.0 and the BitShares in the new chain would be called BitShares 2.0

That would only require the exchanges to open a new market for BitShares 2.0 I guess? People would see  BitShares1.0/BTC and BitShares2.0/BTC markets and would mostly trade the 2.0 since they would associate it with a more recent version. Could they do that?

Different chains would mean different coins right? Then they would be like any other coin out there.

[maqifrnswa]

Just for the record, my personal view of morality is that it is dishonest to sell something you know to be worthless to unsuspecting people who didn't get the news about the upgrade.

yeah, I was tempted to sell those PTS - but in the end it just didn't feel right!

[bytemaster]

that means that they are confident that everything will go just fine and that's a very  good sign...

hmmm no, that's not really what it means... I fully agree with Monsterer here, this release seems a bit premature and setting up a time-bomb like this feels *very* dangerous. I have the impression that what this means is that it was done to please investors and people who keep complaining about shifts in the release date, to show them that it will happen on that date for sure. But what if the network isn't stable by then? You have to have a plan B, and "release 0.9.4 a couple of days before to fix it" doesn't seem like a very good one to me.

This also puts an enormous pressure on the devs, which is not necessarily what you want to have to be able to focus clearly on coding (it's effectively a sword of Damocles hanging above their head...) I'd rather have an undefined release date that slips by a month (heck, even 3 months is very little compared to what this sets up to be) and have a rock-stable release then.

But let's see how the next testnet goes, if it runs really smooth then maybe the release can still be made on time. I trust that Stan will find some magic potion that he will feed to all core devs so they write bug-free code during the next 2 weeks

I agree completely with this perspective.  Bytemaster just announced on mumble that devshares will not be initialized for grahpene until the snapshot is taken for going live. So it looks like the testing model will be the adhoc testnet. Whether that will be adequate remains to be seen. The next testnet will have 3 second block times and be open to nodes around the world.

BM also strongly encouraged all 1.0 delegates that wish to be 2.0 witnesses to participate in the next testnet if they wish to have BM's vote.

He also said initially there will only be 16 CNX witnesses on launch, meaning all current non-CNX delegates will NOT be active when 2.0 launches.

To be fair, my plan is to vote in alternative witnesses as soon as possible to complete the handoff to the community.

[jsidhu]

Allowing trading up to the creation of genesis is allowing insider trading and pretty much giving free btc

Do we not know when genesis creation will take place? At snapshot time? No? Am I missing something? 

Done manually after snapshot time

[Thom]

that means that they are confident that everything will go just fine and that's a very  good sign...

hmmm no, that's not really what it means... I fully agree with Monsterer here, this release seems a bit premature and setting up a time-bomb like this feels *very* dangerous. I have the impression that what this means is that it was done to please investors and people who keep complaining about shifts in the release date, to show them that it will happen on that date for sure. But what if the network isn't stable by then? You have to have a plan B, and "release 0.9.4 a couple of days before to fix it" doesn't seem like a very good one to me.

This also puts an enormous pressure on the devs, which is not necessarily what you want to have to be able to focus clearly on coding (it's effectively a sword of Damocles hanging above their head...) I'd rather have an undefined release date that slips by a month (heck, even 3 months is very little compared to what this sets up to be) and have a rock-stable release then.

But let's see how the next testnet goes, if it runs really smooth then maybe the release can still be made on time. I trust that Stan will find some magic potion that he will feed to all core devs so they write bug-free code during the next 2 weeks

I agree completely with this perspective.  Bytemaster just announced on mumble that devshares will not be initialized for grahpene until the snapshot is taken for going live. So it looks like the testing model will be the adhoc testnet. Whether that will be adequate remains to be seen. The next testnet will have 3 second block times and be open to nodes around the world.

BM also strongly encouraged all 1.0 delegates that wish to be 2.0 witnesses to participate in the next testnet if they wish to have BM's vote.

He also said initially there will only be 16 CNX witnesses on launch, meaning all current non-CNX delegates will NOT be active when 2.0 launches.

[xeroc]

Allowing trading up to the creation of genesis is allowing insider trading and pretty much giving free btc

Do we not know when genesis creation will take place? At snapshot time? No? Am I missing something? 

In theory you could instantly initialize BTS2.0 at snapshot time .. in practise the devs will need to do some manual work first and ensure the genesis is correctly build .. otherwise they may just screw up the whole thing .. once the genesis is out, there is no going back .. not even for BM

[liondani]

Allowing trading up to the creation of genesis is allowing insider trading and pretty much giving free btc

Do we not know when genesis creation will take place? At snapshot time? No? Am I missing something? 

[puppies]

Hi friends,

I have bitshares on Poloniex and plan to transfer to the  bitshares 2.0 web wallet at launch.  A moderator on Poloniex said that a snapshot would be taken so I am confident that there will be a smooth transition to 2.0 on the exchange.  Thoughts?

Best regards.

Your plan should work just fine.  I prefer to keep my crypto locked up with keys I own, but that's never quite as convenient.  At least until bts2.0

[jsidhu]

Id like the exchanges to shutdown trading to avoid the dev team from dumping their shares on the exchanges after they manually create the genesis block to bts 2.0... since there is some manual steps there they have an advantage perhaps also did this with PTS.. I'd hope this time around they learned from that and applied proper precautions.. if not will look like greedy scammers IMO.

theoretical that's not fair either... how do you know there is not a minority that want's to continue to support the "old"  blockchain ? They are not obligated to make a statement about their intentions about it!
Why to shut them down? If some delegates stay on 0.9.2 we must assume they want it alive... The only thing that we must do is to clearly state on bitshares.org, bitsharestalk etc. what exactly will happen so nobody can accuse us after the snapshot for anything! Everybody must have easy access to informations about the snapshot.The exchanges should just describe on the bts market what will happen so all investors can acting accordingly having the same information's even like  "insiders" have.

No we all know majority will switch and we also know they will create genesis block manually.. Allowing trading up to the creation of genesis is allowing insider trading and pretty much giving free btc

[nickelback70]

Hi friends,

I have bitshares on Poloniex and plan to transfer to the  bitshares 2.0 web wallet at launch.  A moderator on Poloniex said that a snapshot would be taken so I am confident that there will be a smooth transition to 2.0 on the exchange.  Thoughts?

Best regards.

[liondani]

Id like the exchanges to shutdown trading to avoid the dev team from dumping their shares on the exchanges after they manually create the genesis block to bts 2.0... since there is some manual steps there they have an advantage perhaps also did this with PTS.. I'd hope this time around they learned from that and applied proper precautions.. if not will look like greedy scammers IMO.

theoretical that's not fair either... how do you know there is not a minority that want's to continue to support the "old"  blockchain ? They are not obligated to make a statement about their intentions about it!
Why to shut them down? If some delegates stay on 0.9.2 we must assume they want it alive... The only thing that we must do is to clearly state on bitshares.org, bitsharestalk etc. what exactly will happen so nobody can accuse us after the snapshot for anything! Everybody must have easy access to informations about the snapshot.The exchanges should just describe on the bts market what will happen so all investors can acting accordingly having the same information's even like  "insiders" have.

[jsidhu]

It is very important that every exchange is ready for the transition.  That is, prior to the release of 2.0, they disable deposits and withdrawals, then they do the 2.0 transition, and then they reenable deposits and withdrawals on the new chain.

That way there is no exchange accepting or trying to give out BTS tokens from the 0.9.2 chain. 
If this occurs, no one will be able to dump worthless old bts on unsuspecting people, and there wont be a division between people who got screwed and want to make old BTS worth somehting, and everyone else.

Most importantly we need poloniex and btc38 to follow this.  I am pretty sure CCEDK will since they are a partner.  I dont think there is much BTS on the other exchanges anymore.  I bet at least one of bter, bittrex, and cryptsy will fail in some way in the 2.0 transition, but it will mostly just be a black eye for them.

You probably want to avoid trading of those IOU tokens aswell because otherwise people would transfer days before and dump right after genesis block (people who create genesis block and their friends get first dibs) and then they can sit and wait until  withdrawing is enabled again to get free BTC out.
With PTS it stopped at the time of the snapshot... instead it would be better to stop a long time before.. and a few hours after everything is done.

[Ander]

Just for the record, my personal view of morality is that it is dishonest to sell something you know to be worthless to unsuspecting people who didn't get the news about the upgrade.

Obviously it would be different if there was a serious minority that intended to continue to support and compete via the old chain.  (In which case, you wouldn't be selling something totally worthless.)

So the next step is the "serious" (acting) minority to show up before the snapshot take place... Like the last time with Bitshares PTS

I havent seen anyone trying to keep the old chain around like alphabar was doing with PTS.  This is a good thing.

Of course, it is essential that the new chain is absolutely working prior to the transition.  We must ensure this is the case. 

[Ander]

It is very important that every exchange is ready for the transition.  That is, prior to the release of 2.0, they disable deposits and withdrawals, then they do the 2.0 transition, and then they reenable deposits and withdrawals on the new chain.

That way there is no exchange accepting or trying to give out BTS tokens from the 0.9.2 chain. 
If this occurs, no one will be able to dump worthless old bts on unsuspecting people, and there wont be a division between people who got screwed and want to make old BTS worth somehting, and everyone else.

Most importantly we need poloniex and btc38 to follow this.  I am pretty sure CCEDK will since they are a partner.  I dont think there is much BTS on the other exchanges anymore.  I bet at least one of bter, bittrex, and cryptsy will fail in some way in the 2.0 transition, but it will mostly just be a black eye for them.

[jsidhu]

Id like the exchanges to shutdown trading to avoid the dev team from dumping their shares on the exchanges after they manually create the genesis block to bts 2.0... since there is some manual steps there they have an advantage perhaps also did this with PTS.. I'd hope this time around they learned from that and applied proper precautions.. if not will look like greedy scammers IMO.

[liondani]

Just for the record, my personal view of morality is that it is dishonest to sell something you know to be worthless to unsuspecting people who didn't get the news about the upgrade.

Obviously it would be different if there was a serious minority that intended to continue to support and compete via the old chain.  (In which case, you wouldn't be selling something totally worthless.)

So the next step is the "serious" (acting) minority to show up before the snapshot take place... Like the last time with Bitshares PTS

[fav]

how about the web wallet? will the brain key work smoothly in 2.0?

you can download a backup under advanced. that's how I did it and it worked on the testnet.

[skystone]

how about the web wallet? will the brain key work smoothly in 2.0?

[phillyguy]

What is the recommended course of action for someone who wants to HODL their BTS straight through from BTS 0.9.2 through BTS 2.0 (Graphene) ?

wait until 2.0 is operational and import your keys. migration is easy

Thanks guys. Sorry to hijack the thread temporarily.

[fav]

What is the recommended course of action for someone who wants to HODL their BTS straight through from BTS 0.9.2 through BTS 2.0 (Graphene) ?

wait until 2.0 is operational and import your keys. migration is easy

[Riverhead]

What is the recommended course of action for someone who wants to HODL their BTS straight through from BTS 0.9.2 through BTS 2.0 (Graphene) ?

Continue to HODL. No action required.

[phillyguy]

What is the recommended course of action for someone who wants to HODL their BTS straight through from BTS 0.9.2 through BTS 2.0 (Graphene) ?

[lil_jay890]

Changing the release date based on forum member "fears" would be extemely detrimental to BTS.  If the devs find a bug that MUST be squashed before the release date then that is the only reason a delay should occur.

[fuzzy]

that's why it is unwise to update to 0.9.3 prior we test bts2.0 with devshares!

Then why was the upgrade released and then announced?

https://github.com/bitshares/bitshares/releases/tag/bts%2F0.9.3
https://bitcointalk.org/index.php?topic=1182483.0

Also, people are actively being encouraged to upgrade on this forum:

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

Can't we just release DevShares 2.0 and run that for a month before BitShares 2.0 is released then?

[tonyk]

This upgrade is voluntary and should not have introduced any other hard-forking changes from 0.9.2.   Any delegate that does not think we the upgrade should occur can continue to run 0.9.2.   This release is for those of us who are actively preparing for the scheduled upgrade date.

But the snapshot happens on that date - those who do not upgrade and continue to use the old chain will be double spending.

you are not right.why double spending? 2 different chains will be in existence after the snapshot !  bts1.0 & bts2.0

Like pre and post upgrade of PTS. Most people dumped their PoW PTS post snapshot. I suspect the same will happen here with pre and post Graphene BTS.

I must have missed on this great dumping opportunity,  As I could not find a single exchange where to do it.  And as my unauthorized autobiography ghost writer knows  - This will be one of my greatest shames. 

Just for the record, my personal view of morality is that it is dishonest to sell something you know to be worthless to unsuspecting people who didn't get the news about the upgrade.

Obviously it would be different if there was a serious minority that intended to continue to support and compete via the old chain.  (In which case, you wouldn't be selling something totally worthless.)

Just for the record, my personal view of morality is that it is pretty bad to include twisted and/or untrue facts while writing unauthorized autobiography. Including the above will be at least a true fact. The only thing left for twisting and misinterpretation will be the motives for doing what I did.
And just to clarify that-"Buyer beware" - I would expect someone buying something to have clear picture why he is buying .So he must have an idea what he is gonna do with them POW PTS.

[Stan]

This upgrade is voluntary and should not have introduced any other hard-forking changes from 0.9.2.   Any delegate that does not think we the upgrade should occur can continue to run 0.9.2.   This release is for those of us who are actively preparing for the scheduled upgrade date.

But the snapshot happens on that date - those who do not upgrade and continue to use the old chain will be double spending.

you are not right.why double spending? 2 different chains will be in existence after the snapshot !  bts1.0 & bts2.0

Like pre and post upgrade of PTS. Most people dumped their PoW PTS post snapshot. I suspect the same will happen here with pre and post Graphene BTS.

I must have missed on this great dumping opportunity,  As I could not find a single exchange where to do it.  And as my unauthorized autobiography ghost writer knows  - This will be one of my greatest shames. 

Just for the record, my personal view of morality is that it is dishonest to sell something you know to be worthless to unsuspecting people who didn't get the news about the upgrade.

Obviously it would be different if there was a serious minority that intended to continue to support and compete via the old chain.  (In which case, you wouldn't be selling something totally worthless.)

[tonyk]

This upgrade is voluntary and should not have introduced any other hard-forking changes from 0.9.2.   Any delegate that does not think we the upgrade should occur can continue to run 0.9.2.   This release is for those of us who are actively preparing for the scheduled upgrade date.

But the snapshot happens on that date - those who do not upgrade and continue to use the old chain will be double spending.

you are not right.why double spending? 2 different chains will be in existence after the snapshot !  bts1.0 & bts2.0

Like pre and post upgrade of PTS. Most people dumped their PoW PTS post snapshot. I suspect the same will happen here with pre and post Graphene BTS.

I must have missed on this great dumping opportunity,  As I could not find a single exchange where to do it.  And as my unauthorized autobiography ghost writer knows  - This will be one of my greatest shames. 

[jsidhu]

This upgrade is voluntary and should not have introduced any other hard-forking changes from 0.9.2.   Any delegate that does not think we the upgrade should occur can continue to run 0.9.2.   This release is for those of us who are actively preparing for the scheduled upgrade date.

But the snapshot happens on that date - those who do not upgrade and continue to use the old chain will be double spending.

you are not right.why double spending? 2 different chains will be in existence after the snapshot !  bts1.0 & bts2.0

Like pre and post upgrade of PTS. Most people dumped their PoW PTS post snapshot. I suspect the same will happen here with pre and post Graphene BTS.

we should delay trading on eschanges with volume for a few hours pre and post fork

[monsterer]

you are not right.why double spending? 2 different chains will be in existence after the snapshot !  bts1.0 & bts2.0

If that is true, why is 0.9.3 a scuppering upgrade?

[Riverhead]

This upgrade is voluntary and should not have introduced any other hard-forking changes from 0.9.2.   Any delegate that does not think we the upgrade should occur can continue to run 0.9.2.   This release is for those of us who are actively preparing for the scheduled upgrade date.

But the snapshot happens on that date - those who do not upgrade and continue to use the old chain will be double spending.

you are not right.why double spending? 2 different chains will be in existence after the snapshot !  bts1.0 & bts2.0

Like pre and post upgrade of PTS. Most people dumped their PoW PTS post snapshot. I suspect the same will happen here with pre and post Graphene BTS.

[liondani]

This upgrade is voluntary and should not have introduced any other hard-forking changes from 0.9.2.   Any delegate that does not think we the upgrade should occur can continue to run 0.9.2.   This release is for those of us who are actively preparing for the scheduled upgrade date.

But the snapshot happens on that date - those who do not upgrade and continue to use the old chain will be double spending.

you are not right.why double spending? 2 different chains will be in existence after the snapshot !  bts1.0 & bts2.0

[monsterer]

This upgrade is voluntary and should not have introduced any other hard-forking changes from 0.9.2.   Any delegate that does not think we the upgrade should occur can continue to run 0.9.2.   This release is for those of us who are actively preparing for the scheduled upgrade date.

But the snapshot happens on that date - those who do not upgrade and continue to use the old chain will be double spending.

[bytemaster]

This upgrade is voluntary and should not have introduced any other hard-forking changes from 0.9.2.   Any delegate that does not think we the upgrade should occur can continue to run 0.9.2.   This release is for those of us who are actively preparing for the scheduled upgrade date.

[wackou]

that means that they are confident that everything will go just fine and that's a very  good sign...

hmmm no, that's not really what it means... I fully agree with Monsterer here, this release seems a bit premature and setting up a time-bomb like this feels *very* dangerous. I have the impression that what this means is that it was done to please investors and people who keep complaining about shifts in the release date, to show them that it will happen on that date for sure. But what if the network isn't stable by then? You have to have a plan B, and "release 0.9.4 a couple of days before to fix it" doesn't seem like a very good one to me.

This also puts an enormous pressure on the devs, which is not necessarily what you want to have to be able to focus clearly on coding (it's effectively a sword of Damocles hanging above their head...) I'd rather have an undefined release date that slips by a month (heck, even 3 months is very little compared to what this sets up to be) and have a rock-stable release then.

But let's see how the next testnet goes, if it runs really smooth then maybe the release can still be made on time. I trust that Stan will find some magic potion that he will feed to all core devs so they write bug-free code during the next 2 weeks

[liondani]

that's why it is unwise to update to 0.9.3 prior we test bts2.0 with devshares!

Then why was the upgrade released and then announced?

https://github.com/bitshares/bitshares/releases/tag/bts%2F0.9.3
https://bitcointalk.org/index.php?topic=1182483.0

Also, people are actively being encouraged to upgrade on this forum:

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

that means that they are confident that everything will go just fine and that's a very  good sign...
but that doesn't mean that all delegates must blindly follow the "orders" before evaluating them-self the situation and actually testing the bts2.0 chain...
Because in that case it's like we have a "one-point failure" possibility. We should eliminate even that tiny possibility...
It's not wise we upgrade all simultaneously ... we can do it slowly as we reach .... 13 of October 2015 (potentially a historically day!) 

[monsterer]

that's why it is unwise to update to 0.9.3 prior we test bts2.0 with devshares!

Then why was the upgrade released and then announced?

https://github.com/bitshares/bitshares/releases/tag/bts%2F0.9.3
https://bitcointalk.org/index.php?topic=1182483.0

Also, people are actively being encouraged to upgrade on this forum:

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

[liondani]

that's why it is unwise to update to 0.9.3 prior we test bts2.0 with devshares!
I personally suggest we upgrade near the snapshot date... (normaly couple of days before snapshot everything will be smooth so nobody will make a second thought's about upgrading)...
The worst case scenario would be to delay the hard fork without needing to downgrade our clients to 0.9.2 again!!!!

PS I will be more confident after the "official" devshares2.0 test net.... so i wait a bit for the upgrade.

[cass]

i'm intend to agree on testnet run for min. 1 month before fork!
But to be honest, i'm currently not that into .. how difficult these problems on wallet currently are!

[escalicha]

Very good post. Fix a date of work with testnet with bug its little dangerous... 

[wuyanren]

No windows？

[monsterer]

Now that the 0.9.3 scuppering upgrade has been released (https://github.com/bitshares/bitshares/releases/tag/bts%2F0.9.3), the hard-fork is set in stone, which means, ready or not, the chain will expire on the October 13th.

The testnet for 2.0 isn't working yet (https://bitsharestalk.org/index.php/topic,17962.msg236734.html#msg236734). This is a huge concern. These things are extremely complicated, and done wrong, or rushed out the door, this could completely undermine confidence in the platform.

In my opinion, the testnet should have been running fully functional,  and without bugs, for 1 month at least before scheduling any kind of hard fork.