Test Net for Advanced Users

[Riverhead]

Are we still using the Aug-20 genesis file? What's the current chain ID?

[sudo]

we should still use 10 seconds first, and release a user friendly wallet.
and we can begin the marketing work.
then we try 5 seconds, then 3 secs, then 2 secs, then 1 secs
every time we make an improve,  we should look it as a big thing,  it's a chance to push the marketing work.

in fact we have make so many great things.
but we give it to public too easy,
people don't  cherish when they get it too easy.

In the interest of not slipping the release date we are going to fall back to 3 or 5 second blocks using the current P2P code.   Then after we update the P2P code we can increase the block rate to 2 and ultimately 1 second block times.

Ben is in the process of preparing instructions for committee members on how to change the block interval and we plan to dynamically update the test network to prove that we can do this on a live network.

  step by step

good idea
as soon as possibile to release  brand new BTS2.0 &keep testing

[abit]

Hmm, the latest build seems much more stable than before. BTW, is flood_network command disabled? I got a segmentation fault error.

Not so stable for me.. I still encounter segment fault error frequently. Like https://github.com/cryptonomex/graphene/issues/261. Perhaps because of my unstable network connection?

Anyway re-indexing is much faster than before, that's good.

[alt]

thanks, it's sync now

can't build now, seems the new p2p source code can't work, but you have add this line at CMakeLists.txt:

+add_subdirectory( p2p )

try to checkout aeebb1be099fd325f014f4f35aa9e90bf2431839

make witness_node cli_wallet

[clayop]

can't build now, seems the new p2p source code can't work, but you have add this line at CMakeLists.txt:

+add_subdirectory( p2p )

try to checkout aeebb1be099fd325f014f4f35aa9e90bf2431839

make witness_node cli_wallet

[alt]

can't build now, seems the new p2p source code can't work, but you have add this line at CMakeLists.txt:

+add_subdirectory( p2p )

try to checkout aeebb1be099fd325f014f4f35aa9e90bf2431839

[Riverhead]

Hmm, the latest build seems much more stable than before. BTW, is flood_network command disabled? I got a segmentation fault error.

Did for me as well. Rebuilding the newest version now that I'm back from vacation. Nice to see a big "pull" response

[rnglab]

Indeed, witness_schedule_refactor builds ok and seems to run stable.

Should we start testing on this branch?

Edit: sorry, I should have read this first: https://bitsharestalk.org/index.php/topic,18126.0.html
devs, let us know if some tests helps to decide.

[clayop]

Hmm, the latest build seems much more stable than before. BTW, is flood_network command disabled? I got a segmentation fault error.

[bytemaster]

I don't know if it's the right place to ask but since we're talking about nodes. Will BitShares 2.0 allow -even if later through a worked proposal-  for nodes with limited storage space, to store parts or slices of the blockchain history? Imagine storing only X latest blocks. Could allow for more people with limited storage space to join in I guess? Or would this only contribute to less nodes hosting the full blockchain? Since people could think and we know this is common: "someone else will do it".

The transaction history is not part of "chain state" and therefore, there is no requirement for any node to have anything other than the enough history to handle forking / reorganizing, less than 1000 blocks all kept in ram.

No hard fork required. 

[Akado]

I don't know if it's the right place to ask but since we're talking about nodes. Will BitShares 2.0 allow -even if later through a worked proposal-  for nodes with limited storage space, to store parts or slices of the blockchain history? Imagine storing only X latest blocks. Could allow for more people with limited storage space to join in I guess? Or would this only contribute to less nodes hosting the full blockchain? Since people could think and we know this is common: "someone else will do it".

[CLains]

5, 2, 1 is good

Rule of 3.
Avoids 4 (China).
Avoids starting too low (BM said 3-5).
Each time it halves or more (including from where we are: 10s).

[clayop]

we should still use 10 seconds first, and release a user friendly wallet.
and we can begin the marketing work.
then we try 5 seconds, then 3 secs, then 2 secs, then 1 secs
every time we make an improve,  we should look it as a big thing,  it's a chance to push the marketing work.

in fact we have make so many great things.
but we give it to public too easy,
people don't  cherish when they get it too easy.

IMO, 5 sec is also a good starting point.

[BTSdac]

we should still use 10 seconds first, and release a user friendly wallet.
and we can begin the marketing work.
then we try 5 seconds, then 3 secs, then 2 secs, then 1 secs
every time we make an improve,  we should look it as a big thing,  it's a chance to push the marketing work.

in fact we have make so many great things.
but we give it to public too easy,
people don't  cherish when they get it too easy.

I support this idea 

Me too ..

 

maybe I 

[cass]

we should still use 10 seconds first, and release a user friendly wallet.
and we can begin the marketing work.
then we try 5 seconds, then 3 secs, then 2 secs, then 1 secs
every time we make an improve,  we should look it as a big thing,  it's a chance to push the marketing work.

in fact we have make so many great things.
but we give it to public too easy,
people don't  cherish when they get it too easy.

I support this idea 

Me too ..