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

[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.