Author Topic: Publicly expressing my concern about the hard-coded hard fork to 2.0  (Read 20233 times)

0 Members and 1 Guest are viewing this topic.

Offline puppies

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

Offline 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'.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline clayop

  • Hero Member
  • *****
  • Posts: 2033
    • View Profile
    • Bitshares Korea
  • BitShares: 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.

 +5%
Bitshares Korea - http://www.bitshares.kr
Vote for me and see Korean Bitshares community grows
delegate-clayop

Offline 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.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline puppies

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

Offline sudo

  • Hero Member
  • *****
  • Posts: 2255
    • View Profile
  • BitShares: ags
so are we ready release bts2.0 in Oct 13?  about a week later?

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
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.
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

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

Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
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
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline monsterer

Still planning a release on the 13th? How long has the most recent testnet lasted?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline 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.
"The crows seemed to be calling his name, thought Caw."
- Jack Handey (SNL)

Offline Akado

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

Offline maqifrnswa

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
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!
maintains an Ubuntu PPA: https://launchpad.net/~showard314/+archive/ubuntu/bitshares [15% delegate] wallet_account_set_approval maqifrnswa true [50% delegate] wallet_account_set_approval delegate1.maqifrnswa true

Offline 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 :D

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

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
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
Hired by blockchain | Developer
delegate: dev.sidhujag