Author Topic: October 5 Test Network  (Read 127071 times)

0 Members and 1 Guest are viewing this topic.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
The object_database should always be within the data_dir.  I've noticed that sometimes it's created outside the data_dir, but I have not noticed that for a while.  If you have a way to make object_database outside the datadir happen reproducibly, please post in the ticket (if I see it in this thread, I'll post it there, but I don't read every page).
https://github.com/cryptonomex/graphene/issues/257#issuecomment-148187922
BitShares committee member: abit
BitShares witness: in.abit

EkremH

  • Guest
How to get market of any asset pair, get_market_history returns emty array []. Is there any possibility to get asks/bids, like in bitshares ?

Offline bytemaster

We changed how the genesis id is calculated :( 
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 Bhuz

  • Committee member
  • Sr. Member
  • *
  • Posts: 467
    • View Profile
  • BitShares: bhuz
Yep, was the same genesis file...

Offline Thom


We're preparing for release, the last tag on the testnet is https://github.com/cryptonomex/graphene/releases/tag/test6final

Commits on master after this tag are not compatible with the testnet and will be unable to sync.

Building test6final I got a different --chain-id after launching the witness, so it will not sync.

@theoretical

Are you using the same oct5-genesis.json file? Unless they built the genesis block into the test6final binary as theoretical described earlier in this thread it should have the same chainID (60..............df83).

I don't plan on rolling out a new test binary. Once I hear the master branch will become official graphene I will deploy it to all of the seed nodes.

Or, if cryptonomex publishes the binaries I will deploy those instead as deployment will be faster that way.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline Bhuz

  • Committee member
  • Sr. Member
  • *
  • Posts: 467
    • View Profile
  • BitShares: bhuz

We're preparing for release, the last tag on the testnet is https://github.com/cryptonomex/graphene/releases/tag/test6final

Commits on master after this tag are not compatible with the testnet and will be unable to sync.

Building test6final I got a different --chain-id after launching the witness, so it will not sync.

@theoretical
« Last Edit: October 12, 2015, 08:22:40 pm by Bhuz »

Offline Thom

The list of seed nodes to be available starting tomorrow for production are:

seed04.bitsharesnodes.com:1776
seed05.bitsharesnodes.com:1776
seed06.bitsharesnodes.com:1776
seed07.bitsharesnodes.com:1776

repost it here:
https://bitsharestalk.org/index.php/topic,18908.0.html
+5% Thanks!

Done. I changed the port number for seed04 to 2015
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
The list of seed nodes to be available starting tomorrow for production are:

seed04.bitsharesnodes.com:1776
seed05.bitsharesnodes.com:1776
seed06.bitsharesnodes.com:1776
seed07.bitsharesnodes.com:1776

repost it here:
https://bitsharestalk.org/index.php/topic,18908.0.html

Offline theoretical


We're preparing for release, the last tag on the testnet is https://github.com/cryptonomex/graphene/releases/tag/test6final

Commits on master after this tag are not compatible with the testnet and will be unable to sync.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline Thom

The genesis-json location is relative to cwd (where you launch the binary from), because we think about the genesis as being an external input to the system, while the datadir is the internal workings of the system.

The object_database should always be within the data_dir.  I've noticed that sometimes it's created outside the data_dir, but I have not noticed that for a while.  If you have a way to make object_database outside the datadir happen reproducibly, please post in the ticket (if I see it in this thread, I'll post it there, but I don't read every page).

I don't know what you mean by "...but I have not noticed that for a while.", it still happens with binaries built Saturday. Thanks for the tip about the "stale production" flag. I commented it out (the default is apparently off from looking at the output) but the witness still receives zillions of "stale" blocks on the testnet.

As I confirmed, the missing seed node (b/c it was offline -  not working) was the core problem I was having. I spent hours trying to unravel that problem and many others here were also clearly clueless as to the cause of the output we were seeing. I will avoid that issue by adding my working testnet witness node's IP as a seed node to the list, which will become a production seed node for tomorrow.


Unlike most people here I prefer to put as many options in the config.ini file rather than use comman line args. I would very much like to see more robustness in that approach. I recognize it's not a high priority item, but I have spent lots of hours fooling around developing a reproducable, consistent platform for graphene because of issues related to relying on the config.ini. I suppose you could also say better output messages could have saved me a large number of those hours. The change to a requirement for absolute paths for --data-dir where the config.ini resides was the first issue. The cwd being significant in some manor (don't thing anyone really has a complete handle on that yet) is the second.

There's only so many hours in a day, and I realize you devs have far more important issues to address. Just an FYI, something to keep in mind for the future, just saying.

Today thanks to svk I validated my VPS installation script for witness nodes, including the use of wackou's bts_tools to build and launch witness and seed nodes.

I finally have worked out all of the kinks, assuming nothing else changes regarding command line args & how they're processed, cwd or path requirements.
I do notice a logs folder is no longer created, tho I haven't changed any config.ini settings related to logging.  The command line is simply:

Code: [Select]
/home/admin/BitShares2_bin/witness_node --data-dir /home/admin/BitShares2_seedor if using bts_tools:
Code: [Select]
bts2 run bts2      or       bts2 run seedthe only difference between those 2 is the data_dir used.

Here is the complete config.ini for a new seed node at 159.203.1.89:1776, but I will be taking that out of service later today after testing the scripts for the Debian 8.0 OS (it's currently running Ubuntu 14.04):

Code: [Select]
# Endpoint for P2P node to listen on
p2p-endpoint = 0.0.0.0:1776

# P2P nodes to connect to on startup (may specify multiple times)
#seed-node = 45.55.6.216:1776
#seed-node = 114.92.254.159:62015
seed-node = seed05.bitsharesnodes.com:1776
seed-node = seed07.bitsharesnodes.com:1776
seed-node = 188.165.233.53:1777
seed-node = 104.236.51.238:2005

# Pairs of [BLOCK_NUM,BLOCK_ID] that should be enforced as checkpoints.
# checkpoint =

# Endpoint for websocket RPC to listen on
rpc-endpoint = 127.0.0.1:8090

# Endpoint for TLS websocket RPC to listen on
# rpc-tls-endpoint =

# The TLS certificate file for this server
# server-pem =

# Password for this certificate                                             
# server-pem-password =

# File to read Genesis State from
genesis-json = oct5-genesis.json

# JSON file specifying API permissions
# api-access =

# Enable block production, even if the chain is stale.
#enable-stale-production = true

# Percent of witnesses (0-99) that must be participating in order to produce blocks
required-participation = false

# Allow block production, even if the last block was produced by the same witness.
#allow-consecutive = false

# ID of witness controlled by this node (e.g. "1.6.0", quotes are required, may specify multiple times)
#witness-id = "1.6.34"
# Tuple of [PublicKey, WIF private key] (may specify multiple times)
#private-key = [ "GPH", "5K" ]
#private-key = [ "GPH", "5H" ]
#private-key = [ "GPH", "5J" ]

# Account ID to track history for (may specify multiple times)
# track-account =

# Track market history by grouping orders into buckets of equal size measured in seconds specified as a
 JSON array of numbers
bucket-size = [15,60,300,3600,86400]

# How far back in time to track history for each bucket size, measured in the number of buckets (default: 1000)
history-per-size = 1000

# declare an appender named "stderr" that writes messages to the console
[log.console_appender.stderr]
stream=std_error

# declare an appender named "p2p" that writes messages to p2p.log
[log.file_appender.p2p]
filename=logs/p2p/p2p.log
# filename can be absolute or relative to this config file

# route any messages logged to the default logger to the "stderr" logger we
# declared above, if they are info level are higher
[logger.default]
level=info
appenders=stderr

# route messages sent to the "p2p" logger to the p2p appender declared above
[logger.p2p]
level=debug
appenders=p2p


The list of seed nodes to be available starting tomorrow for production are:

seed04.bitsharesnodes.com:1776
seed05.bitsharesnodes.com:1776
seed06.bitsharesnodes.com:1776
seed07.bitsharesnodes.com:1776
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline sudo

  • Hero Member
  • *****
  • Posts: 2255
    • View Profile
  • BitShares: ags
is it stable enough  for update bts1.0?

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
The object_database should always be within the data_dir.  I've noticed that sometimes it's created outside the data_dir, but I have not noticed that for a while.  If you have a way to make object_database outside the datadir happen reproducibly, please post in the ticket (if I see it in this thread, I'll post it there, but I don't read every page).

When I run this command './witness_node --rpc-endpoint 127.0.0.1:8090 --genesis-json ./oct5-genesis.json -d testnet6 -s 1 -s 104.236.51.238:2005' one directory above data_dir (testnet6), the object_database appears one directory above data_dir (ie it ends up in 'cwd').
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline bytemaster

why so many duplicate blocks?
Code: [Select]
587729ms th_a       application.cpp:401           handle_block         ] Got block: #185843 time: 2015-10-12T13:09:48 latency: 259 ms from: init2  irreversible: 185818 (-25)
587778ms th_a       application.cpp:401           handle_block         ] Got block: #185843 time: 2015-10-12T13:09:48 latency: 308 ms from: init2  irreversible: 185819 (-24)
590797ms th_a       application.cpp:401           handle_block         ] Got block: #185844 time: 2015-10-12T13:09:51 latency: 327 ms from: mindphlux.witness  irreversible: 185819 (-25)
593784ms th_a       application.cpp:401           handle_block         ] Got block: #185845 time: 2015-10-12T13:09:54 latency: 314 ms from: spartako  irreversible: 185820 (-25)
596672ms th_a       application.cpp:401           handle_block         ] Got block: #185846 time: 2015-10-12T13:09:57 latency: 202 ms from: delegate-clayop  irreversible: 185821 (-25)
599796ms th_a       application.cpp:401           handle_block         ] Got block: #185847 time: 2015-10-12T13:10:00 latency: 326 ms from: bitcube  irreversible: 185822 (-25)
599843ms th_a       application.cpp:401           handle_block         ] Got block: #185847 time: 2015-10-12T13:10:00 latency: 373 ms from: bitcube  irreversible: 185823 (-24)
602729ms th_a       application.cpp:401           handle_block         ] Got block: #185848 time: 2015-10-12T13:10:03 latency: 259 ms from: init9  irreversible: 185823 (-25)
602805ms th_a       application.cpp:401           handle_block         ] Got block: #185848 time: 2015-10-12T13:10:03 latency: 335 ms from: init9  irreversible: 185824 (-24)

Interesting, that could happen if the first request had a timeout and a second request from a different peer was made.
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 theoretical

Until now I didn't realize the object_database and genesis.json file location (if it is provided in the config.ini and not the --genesis-json cmd line arg) are relative to the folder from which the witness_node binary is executed.

I made the assumption that everything is relative to the --data-dir folder where the config.ini is found. Although I noticed the genesis.json and object_database were in a different location than the blockchain, config.ini etc, it never occured to me why, since I always launched from the same place each time.

I realize this is a very low priority request, but may I suggest the code be changed to "chroot" (so to speak) the location of all files to the value provided by the --data-dir (-d) command line argument. What would the reason be for not doing that, or not putting the object_database in the same place as the blockchain? Perhaps there is a good reason, but I can't think of any.
I believe it's related to a bug which hasn't been fixed, probably due to low priority.
https://github.com/cryptonomex/graphene/issues/257

The genesis-json location is relative to cwd (where you launch the binary from), because we think about the genesis as being an external input to the system, while the datadir is the internal workings of the system.

The object_database should always be within the data_dir.  I've noticed that sometimes it's created outside the data_dir, but I have not noticed that for a while.  If you have a way to make object_database outside the datadir happen reproducibly, please post in the ticket (if I see it in this thread, I'll post it there, but I don't read every page).

As in BTS 0.x, Graphene allows you to embed a genesis file in the binary.  You can do this with a cmake define of the GRAPHENE_EGENESIS_JSON variable:

Code: [Select]
cmake -DGRAPHENE_EGENESIS_JSON=path/to/genesis -DCMAKE_BUILD_TYPE=Release .

If you're like me and build in-tree, you may have to purge leftovers of previous builds before running the above command:

Code: [Select]
make clean
rm -f CMakeCache.txt
find . -name CMakeFiles | xargs rm -Rf

Obviously, you'll have to redefine other cmake settings you use if you purge your cmake files (I use BOOST_ROOT and CMAKE_INSTALL_PREFIX, plus a bunch of Qt-related stuff you probably don't need to worry about right now).

Any witness_node built with egenesis will use the built-in genesis if you don't specify --genesis-json (but you still can in case you want a custom genesis).  Any cli_wallet built like this will have the chain-id of the built-in genesis so you don't have to specify that either.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical

Confirmed. Changed the seed node to puppies and everything was fine.
The config.ini states multiple seed node definitions are OK. Does that mean if one fails (as in yesterday) the code will use another one if it is defined?

The set of seed nodes you specify is simply what "bootstraps" the initial list of peers you connect to.  There's nothing "special" about the seed node, when starting a witness_node you just need to specify an IP / port for an already-running witness_node.

Specifying multiple seed nodes will connect to all of them simultaneously (well, up to the p2p code's max connection limit).
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk