is the witness thing running under win?

[Miner9r]

As of July-12 (v2.0.160702) this bug is still present.  I'm building from source under Linux.

My blockchain sync is jammed on block 2821722,  presumably because, as roadscape found above, the next block 2821723 has a huge text (the bible -- typical graffiti  blockchain vandalism).

This needs to be fixed *immediately*,  or provide a workaround  in top level documentation. 

This seems like a CRITICAL bug, throttling the entire BitShares ecosystem,  *No New Users* !!  Everything seems to be working for the old-timers, who already have the chain, while new users are throwing up their hands and silently leaving (possibly in droves, over the last several months, SINCE JANUARY!!)   It's incredibly frustrating to follow official documentation (which is already scattered, incomplete, outdated) and run into inexplicable jams like this.

I've been hammering on it for week++, trying to bring up BitShares as a new user, and only tunneled this far with relatively high expertise and perseverance.

In a sense, we don't actually have a working software or blockchain at the moment.  It's a closed system,  no new users!

Please fix it!!

===

As further comment on the bug, how did that 1MB text get in there?  The protocol should have limits built in for all these fields,  and the rest of the code needs to enforce and handle up to those known edges.  As the user base expands, you can expect plenty of accidental and malicious error injection like this.

Also, the release process should include a complete source build and blockchain sync from scratch,  on "typical" hardware.   If that's too onerous to do for every platform, at least cycle through one platform each release.

It would also help to update the official build/sync documentation as part of the release process.

Thanks to everyone for this excellent, advanced cryptocoin, exchange, ecosystem !


BTS id:  miner9r   
(computing expert, new bts user, please send me donations for my informative or helpful postings)

==================
STATS FROM cli_wallet:

about
{
  "client_version": "v2.0.160702",
  "graphene_revision": "3f7bcddd2546b1a054c8d46193db4efa19eab3e3",
  "graphene_revision_age": "10 days ago",
  "fc_revision": "31adee49d91275cc63aa3a47b3a9e3c826baccca",
  "fc_revision_age": "16 weeks ago",
  "compile_date": "compiled on Jul 12 2016 at 11:35:42",
  "boost_version": "1.58",
  "openssl_version": "OpenSSL 1.0.2h  3 May 2016",
  "build": "linux 64-bit"
}


get_dynamic_global_properties
{
  "id": "2.1.0",
  "head_block_number": 2821722,
  "head_block_id": "002b0e5a206413b5f17ee209705b51b3cb90fa4c",
  "time": "2016-01-20T09:28:42",
  "current_witness": "1.6.38",
  "next_maintenance_time": "2016-01-20T10:00:00",
  "last_budget_time": "2016-01-20T09:00:00",
  "witness_budget": 94350000,
  "accounts_registered_this_interval": 0,
  "recently_missed_count": 0,
  "current_aslot": 2839861,
  "recent_slots_filled": "340282366920938463463374607431768211455",
  "dynamic_flags": 0,
  "last_irreversible_block_num": 2821705
}

info
{
  "head_block_num": 2821722,
  "head_block_id": "002b0e5a206413b5f17ee209705b51b3cb90fa4c",
  "head_block_age": "25 weeks old",
  "next_maintenance_time": "25 weeks ago",
  "chain_id": "4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8",
  "participation": "100.00000000000000000",
 ...
}

[abit]

I tested it and confirm the issue to do with low resources - ie low cpu power or bandwidth.

It's strange that it occurs on exactly same block: 2821722.

I replaced the blockchain folder on one node with a full backup, then it runs well. And the other node is catching up as well.

Trying to reproduce.

//Update:
Reproduced.
Most probably you're correct. Lots of these kind of entries in the log:

Code: [Select]

2016-04-21T12:03:29 p2p:message read_loop fetch_next_batch_of_ ] sync: sending a request for the next items after 002b0e5a206413b5f17ee209705b51b3cb90fa4c to peer 188.165.233.53:54674, (full request is ["002b0e48227e963b3fa7ebede652334b696e59d8","002b0e528f2ba15ab707c3646bb8b07a0007615f","002b0e571c3f3d9a9c7713ddacd69531c615ebe3","002b0e5966422ef475e20ef2c96acdaec7d51127","002b0e5a206413b5f17ee209705b51b3cb90fa4c"])                     node.cpp:2427

2016-04-21T12:03:30 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Disconnecting peer 188.165.233.53:54674 because they didn't respond to my request for sync item ids after ["002b0e48227e963b3fa7ebede652334b696e59d8","002b0e528f2ba15ab707c3646bb8b07a0007615f","002b0e571cf3d9a9c7713ddacd69531c615ebe3","002b0e5966422ef475e20ef2c96acdaec7d51127","002b0e5a206413b5f17ee209705b51b3cb90fa4c"]                   node.cpp:1403


I think it can be optimized. In the code :

Code: [Select]

        // set the ignored request time out to 1 second.  When we request a block
        // or transaction from a peer, this timeout determines how long we wait for them
        // to reply before we give up and ask another peer for the item.
        // Ideally this should be significantly shorter than the block interval, because
        // we'd like to realize the block isn't coming and fetch it from a different
        // peer before the next block comes in.  At the current target of 3 second blocks,
        // 1 second seems reasonable.  When we get closer to our eventual target of 1 second
        // blocks, this will need to be re-evaluated (i.e., can we set the timeout to 500ms
        // and still handle normal network & processing delays without excessive disconnects)
        fc::microseconds active_ignored_request_timeout = fc::seconds(1);
The timeout applies even when syncing (batch fetching), but 1 second is perhaps too short for that?
Further thinking: why it happens magically on block 2821722 ?
@cube @arhag @pc @theoretical @bytemaster

The block after this one contains a huge operation.. 1MB of text in the asset description field. Very likely the source of the problem.
http://cryptofresh.com/b/2821723

Good catch! Very likely.

[roadscape]

I tested it and confirm the issue to do with low resources - ie low cpu power or bandwidth.

It's strange that it occurs on exactly same block: 2821722.

I replaced the blockchain folder on one node with a full backup, then it runs well. And the other node is catching up as well.

Trying to reproduce.

//Update:
Reproduced.
Most probably you're correct. Lots of these kind of entries in the log:

Code: [Select]

2016-04-21T12:03:29 p2p:message read_loop fetch_next_batch_of_ ] sync: sending a request for the next items after 002b0e5a206413b5f17ee209705b51b3cb90fa4c to peer 188.165.233.53:54674, (full request is ["002b0e48227e963b3fa7ebede652334b696e59d8","002b0e528f2ba15ab707c3646bb8b07a0007615f","002b0e571c3f3d9a9c7713ddacd69531c615ebe3","002b0e5966422ef475e20ef2c96acdaec7d51127","002b0e5a206413b5f17ee209705b51b3cb90fa4c"])                     node.cpp:2427

2016-04-21T12:03:30 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Disconnecting peer 188.165.233.53:54674 because they didn't respond to my request for sync item ids after ["002b0e48227e963b3fa7ebede652334b696e59d8","002b0e528f2ba15ab707c3646bb8b07a0007615f","002b0e571cf3d9a9c7713ddacd69531c615ebe3","002b0e5966422ef475e20ef2c96acdaec7d51127","002b0e5a206413b5f17ee209705b51b3cb90fa4c"]                   node.cpp:1403


I think it can be optimized. In the code :

Code: [Select]

        // set the ignored request time out to 1 second.  When we request a block
        // or transaction from a peer, this timeout determines how long we wait for them
        // to reply before we give up and ask another peer for the item.
        // Ideally this should be significantly shorter than the block interval, because
        // we'd like to realize the block isn't coming and fetch it from a different
        // peer before the next block comes in.  At the current target of 3 second blocks,
        // 1 second seems reasonable.  When we get closer to our eventual target of 1 second
        // blocks, this will need to be re-evaluated (i.e., can we set the timeout to 500ms
        // and still handle normal network & processing delays without excessive disconnects)
        fc::microseconds active_ignored_request_timeout = fc::seconds(1);
The timeout applies even when syncing (batch fetching), but 1 second is perhaps too short for that?
Further thinking: why it happens magically on block 2821722 ?
@cube @arhag @pc @theoretical @bytemaster

The block after this one contains a huge operation.. 1MB of text in the asset description field. Very likely the source of the problem.
http://cryptofresh.com/b/2821723

[abit]

I tested it and confirm the issue to do with low resources - ie low cpu power or bandwidth.

It's strange that it occurs on exactly same block: 2821722.

I replaced the blockchain folder on one node with a full backup, then it runs well. And the other node is catching up as well.

Trying to reproduce.

//Update:
Reproduced.
Most probably you're correct. Lots of these kind of entries in the log:

Code: [Select]

2016-04-21T12:03:29 p2p:message read_loop fetch_next_batch_of_ ] sync: sending a request for the next items after 002b0e5a206413b5f17ee209705b51b3cb90fa4c to peer 188.165.233.53:54674, (full request is ["002b0e48227e963b3fa7ebede652334b696e59d8","002b0e528f2ba15ab707c3646bb8b07a0007615f","002b0e571c3f3d9a9c7713ddacd69531c615ebe3","002b0e5966422ef475e20ef2c96acdaec7d51127","002b0e5a206413b5f17ee209705b51b3cb90fa4c"])                     node.cpp:2427

2016-04-21T12:03:30 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Disconnecting peer 188.165.233.53:54674 because they didn't respond to my request for sync item ids after ["002b0e48227e963b3fa7ebede652334b696e59d8","002b0e528f2ba15ab707c3646bb8b07a0007615f","002b0e571cf3d9a9c7713ddacd69531c615ebe3","002b0e5966422ef475e20ef2c96acdaec7d51127","002b0e5a206413b5f17ee209705b51b3cb90fa4c"]                   node.cpp:1403


I think it can be optimized. In the code :

Code: [Select]

        // set the ignored request time out to 1 second.  When we request a block
        // or transaction from a peer, this timeout determines how long we wait for them
        // to reply before we give up and ask another peer for the item.
        // Ideally this should be significantly shorter than the block interval, because
        // we'd like to realize the block isn't coming and fetch it from a different
        // peer before the next block comes in.  At the current target of 3 second blocks,
        // 1 second seems reasonable.  When we get closer to our eventual target of 1 second
        // blocks, this will need to be re-evaluated (i.e., can we set the timeout to 500ms
        // and still handle normal network & processing delays without excessive disconnects)
        fc::microseconds active_ignored_request_timeout = fc::seconds(1);
The timeout applies even when syncing (batch fetching), but 1 second is perhaps too short for that?
Further thinking: why it happens magically on block 2821722 ?
@cube @arhag @pc @theoretical @bytemaster

[cube]

I tested it and confirm the issue to do with low resources - ie low cpu power or bandwidth.

[abit]

@cube I setup 2 new nodes today and both run into same issue.
Ubuntu 14.04 64 bit.

At most time CPU is 100%.

gdb stack dump here.

Code: [Select]

(gdb) thread apply all bt

Thread 5 (Thread 0x7ffff56dc700 (LWP 5918)):
#0  __memcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:1572
#1  0x0000000000fa192e in fc::operator==(fc::ripemd160 const&, fc::ripemd160 const&) ()
#2  0x00000000010a72c7 in graphene::net::detail::node_impl::have_already_received_sync_item(fc::ripemd160 const&) ()
#3  0x00000000010d31ef in graphene::net::detail::node_impl::fetch_sync_items_loop() ()
#4  0x00000000010d3c2c in fc::detail::void_functor_run<graphene::net::detail::node_impl::connect_to_p2p_network()::{lambda()#3}>::run(void*, fc::detail::void_functor_run<graphene::net::detail::node_impl::connect_to_p2p_network()::{lambda()#3}>) ()
#5  0x0000000000eff0e4 in fc::task_base::run_impl() ()
#6  0x0000000000efcc3f in fc::thread_d::process_tasks() ()
#7  0x0000000000efcea1 in fc::thread_d::start_process_tasks(long) ()
#8  0x00000000011d0b01 in make_fcontext ()
#9  0x0000000000000000 in ?? ()

Thread 4 (Thread 0x7ffff4edb700 (LWP 5919)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x0000000000fc5580 in boost::asio::detail::task_io_service::run(boost::system::error_code&) ()
#2  0x0000000000fc80c9 in boost_asio_detail_posix_thread_function ()
#3  0x00007ffff7bc4182 in start_thread (arg=0x7ffff4edb700) at pthread_create.c:312
#4  0x00007ffff6aa247d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7ffff5edd700 (LWP 5917)):
#0  0x00007ffff6aa2b13 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81
#1  0x0000000000fbf867 in boost::asio::detail::epoll_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&) ()
#2  0x0000000000fc547f in boost::asio::detail::task_io_service::run(boost::system::error_code&) ()
#3  0x000000000108275c in fc::asio::default_io_service_scope::default_io_service_scope()::{lambda()#1}::operator()() const ()
#4  0x0000000001189dba in thread_proxy ()
#5  0x00007ffff7bc4182 in start_thread (arg=0x7ffff5edd700) at pthread_create.c:312
#6  0x00007ffff6aa247d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7ffff66de700 (LWP 5916)):
---Type <return> to continue, or q <return> to quit---
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
#1  0x0000000000efaf4b in boost::cv_status boost::condition_variable::wait_until<boost::chrono::steady_clock, boost::chrono::duration<long, boost::ratio<1l, 1000000000l> > >(boost::unique_lock<boost::mutex>&, boost::chrono::time_point<boost::chrono::steady_clock, boost::chrono::duration<long, boost::ratio<1l, 1000000000l> > > const&) ()
#2  0x0000000000efce4e in fc::thread_d::process_tasks() ()
#3  0x0000000000efcea1 in fc::thread_d::start_process_tasks(long) ()
#4  0x00000000011d0b01 in make_fcontext ()
#5  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7ffff7fe9780 (LWP 5912)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
#1  0x0000000000efaf4b in boost::cv_status boost::condition_variable::wait_until<boost::chrono::steady_clock, boost::chrono::duration<long, boost::ratio<1l, 1000000000l> > >(boost::unique_lock<boost::mutex>&, boost::chrono::time_point<boost::chrono::steady_clock, boost::chrono::duration<long, boost::ratio<1l, 1000000000l> > > const&) ()
#2  0x0000000000efce4e in fc::thread_d::process_tasks() ()
#3  0x0000000000efcea1 in fc::thread_d::start_process_tasks(long) ()
#4  0x00000000011d0b01 in make_fcontext ()
#5  0x0000000000000000 in ?? ()



[cube]

Did you remove object and blockchain data folders before running the witness node?

Edit:  The new logging function reduces log output to console significantly.  And so, what you are seeing at the console seems normal.  The way to check whether you are progressing is from the cli_wallet , eg:

Code: [Select]

{
  "head_block_num": 4033345,

Are the head block numble increasing?

[tonyk]

You can try this (latest version compile) - https://github.com/btscube/bitshares-2/releases/tag/2.0.160223

I got it to work under similar condition as yours.  If this worked for you, let me know.

same 

[cube]

You can try this (latest version compile) - https://github.com/btscube/bitshares-2/releases/tag/2.0.160223

I got it to work under similar condition as yours.  If this worked for you, let me know.

[tonyk]

bump...

[cube]

well, mine is indeed stuck...the head block number stays the same and matches the one from the pic above "head_block_num": 2821722,

info
{
  "head_block_num": 2821722,
  "head_block_id": "002b0e5a206413b5f17ee209705b51b3cb90fa4c",
  "head_block_age": "13 days old",
  "next_maintenance_time": "13 days ago",
  "chain_id": "4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8"
,
  "participation": "100.00000000000000000",
  "active_witnesses": [

Well we are coming close to an answer now.  You did manage to sync up to a certain point - "head_block_num": 2821722,

Now a few things to do:

1) What is your Internet bandwidth?
2) Is your system clock up to date/time?
3) Compress C:\Program Files\BitShares 2\bin\witness_node_data_dir\logs\p2p\p2p.log and share the compressed file out. PM me the link.  We would need to send the relevant info to the dev via github issue report.

[tonyk]

I downloaded the latest official binary and tried the witness_node, as if I am a layman.  Surprisingly, I got the same result as you - ie the witness_node.exe seemed to be stuck.  The witness node output information seems to be changed.  It becomes quiet, possibly to be less spamy.

Here is what you can do:

1) Follow what xeldal advised:  make a shortcut with "C:\Program Files\BitShares 2\bin\witness_node.exe" --rpc-endpoint "127.0.0.1:8090" as the target.
Run this shortcut as Administrator

2) make a shortcut with "C:\Program Files\BitShares 2\bin\cli_wallet.exe" -H 127.0.0.1:8092 -s ws://127.0.0.1:8090 as the target.
Run this shortcut as Administrator

3) When the wallet runs, enter 'info' at the 'new' prompt.  You will get to see a number of stuff.  Look out for 'head_block_num'.  This number will be increasing even though the witness_node seems to be stuck with no new output from it.  But it is not stuck.  It is working quietly.

well, mine is indeed stuck...the head block number stays the same and matches the one from the pic above "head_block_num": 2821722,
I did not believe that running it from the shortcut will make a difference from doing the same from cmd but tried anyway.

Maybe yours is moving because it is indeed down loading blocks before that one # 2821722... or it is something with my whole setting and the witness_node.exe is fine..

Code: [Select]

info
{
  "head_block_num": 2821722,
  "head_block_id": "002b0e5a206413b5f17ee209705b51b3cb90fa4c",
  "head_block_age": "13 days old",
  "next_maintenance_time": "13 days ago",
  "chain_id": "4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8"
,
  "participation": "100.00000000000000000",
  "active_witnesses": [
    "1.6.1",
    "1.6.3",
    "1.6.4",
    "1.6.5",
    "1.6.6",
    "1.6.7",
    "1.6.8",
    "1.6.9",
    "1.6.10",
    "1.6.11",
    "1.6.12",
    "1.6.13",
    "1.6.14",
    "1.6.15",
    "1.6.16",
    "1.6.17",
    "1.6.18",
    "1.6.19",
    "1.6.20",
    "1.6.21",
    "1.6.22",
    "1.6.23",
    "1.6.24",
    "1.6.25",
    "1.6.26",
    "1.6.27",
    "1.6.28",
    "1.6.29",
    "1.6.32",
    "1.6.33",
    "1.6.34"
  ],
  "active_committee_members": [
    "1.5.0",
    "1.5.2",
    "1.5.4",
    "1.5.5",
    "1.5.6",
    "1.5.7",
    "1.5.8",
    "1.5.9",
    "1.5.10",
    "1.5.11",
    "1.5.1"
  ]
}
locked >>> info
info
{
  "head_block_num": 2821722,
  "head_block_id": "002b0e5a206413b5f17ee209705b51b3cb90fa4c",
  "head_block_age": "13 days old",
  "next_maintenance_time": "13 days ago",
  "chain_id": "4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8"
,
  "participation": "100.00000000000000000",
  "active_witnesses": [
    "1.6.1",
    "1.6.3",
    "1.6.4",
    "1.6.5",
    "1.6.6",
    "1.6.7",
    "1.6.8",
    "1.6.9",
    "1.6.10",
    "1.6.11",
    "1.6.12",
    "1.6.13",
    "1.6.14",
    "1.6.15",
    "1.6.16",
    "1.6.17",
    "1.6.18",
    "1.6.19",
    "1.6.20",
    "1.6.21",
    "1.6.22",
    "1.6.23",
    "1.6.24",
    "1.6.25",
    "1.6.26",
    "1.6.27",
    "1.6.28",
    "1.6.29",
    "1.6.32",
    "1.6.33",
    "1.6.34"
  ],
  "active_committee_members": [
    "1.5.0",
    "1.5.2",
    "1.5.4",
    "1.5.5",
    "1.5.6",
    "1.5.7",
    "1.5.8",
    "1.5.9",
    "1.5.10",
    "1.5.11",
    "1.5.1"
  ]
}
locked >>> info
info
{
  "head_block_num": 2821722,
  "head_block_id": "002b0e5a206413b5f17ee209705b51b3cb90fa4c",
  "head_block_age": "13 days old",
  "next_maintenance_time": "13 days ago",
  "chain_id": "4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8"
,
  "participation": "100.00000000000000000",
  "active_witnesses": [
    "1.6.1",
    "1.6.3",
    "1.6.4",
    "1.6.5",
    "1.6.6",
    "1.6.7",
    "1.6.8",
    "1.6.9",
    "1.6.10",
    "1.6.11",
    "1.6.12",
    "1.6.13",
    "1.6.14",
    "1.6.15",
    "1.6.16",
    "1.6.17",
    "1.6.18",
    "1.6.19",
    "1.6.20",
    "1.6.21",
    "1.6.22",
    "1.6.23",
    "1.6.24",
    "1.6.25",
    "1.6.26",
    "1.6.27",
    "1.6.28",
    "1.6.29",
    "1.6.32",
    "1.6.33",
    "1.6.34"
  ],
  "active_committee_members": [
    "1.5.0",
    "1.5.2",
    "1.5.4",
    "1.5.5",
    "1.5.6",
    "1.5.7",
    "1.5.8",
    "1.5.9",
    "1.5.10",
    "1.5.11",
    "1.5.1"
  ]
}
locked >>> info
info
{
  "head_block_num": 2821722,
  "head_block_id": "002b0e5a206413b5f17ee209705b51b3cb90fa4c",
  "head_block_age": "13 days old",
  "next_maintenance_time": "13 days ago",
  "chain_id": "4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8"
,
  "participation": "100.00000000000000000",
  "active_witnesses": [
    "1.6.1",
    "1.6.3",
    "1.6.4",
    "1.6.5",
    "1.6.6",
    "1.6.7",
    "1.6.8",
    "1.6.9",
    "1.6.10",
    "1.6.11",
    "1.6.12",
    "1.6.13",
    "1.6.14",
    "1.6.15",
    "1.6.16",
    "1.6.17",
    "1.6.18",
    "1.6.19",
    "1.6.20",
    "1.6.21",
    "1.6.22",
    "1.6.23",
    "1.6.24",
    "1.6.25",
    "1.6.26",
    "1.6.27",
    "1.6.28",
    "1.6.29",
    "1.6.32",
    "1.6.33",
    "1.6.34"
  ],
  "active_committee_members": [
    "1.5.0",
    "1.5.2",
    "1.5.4",
    "1.5.5",
    "1.5.6",
    "1.5.7",
    "1.5.8",
    "1.5.9",
    "1.5.10",
    "1.5.11",
    "1.5.1"
  ]
}
locked >>> info
info
{
  "head_block_num": 2821722,
  "head_block_id": "002b0e5a206413b5f17ee209705b51b3cb90fa4c",
  "head_block_age": "13 days old",
  "next_maintenance_time": "13 days ago",
  "chain_id": "4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8"
,
  "participation": "100.00000000000000000",
  "active_witnesses": [
    "1.6.1",
    "1.6.3",
    "1.6.4",
    "1.6.5",
    "1.6.6",
    "1.6.7",
    "1.6.8",
    "1.6.9",
    "1.6.10",
    "1.6.11",
    "1.6.12",
    "1.6.13",
    "1.6.14",
    "1.6.15",
    "1.6.16",
    "1.6.17",
    "1.6.18",
    "1.6.19",
    "1.6.20",
    "1.6.21",
    "1.6.22",
    "1.6.23",
    "1.6.24",
    "1.6.25",
    "1.6.26",
    "1.6.27",
    "1.6.28",
    "1.6.29",
    "1.6.32",
    "1.6.33",
    "1.6.34"
  ],
  "active_committee_members": [
    "1.5.0",
    "1.5.2",
    "1.5.4",
    "1.5.5",
    "1.5.6",
    "1.5.7",
    "1.5.8",
    "1.5.9",
    "1.5.10",
    "1.5.11",
    "1.5.1"
  ]
}
locked >>>

............
unlocked >>> info
info
{
  "head_block_num": 2821722,
  "head_block_id": "002b0e5a206413b5f17ee209705b51b3cb90fa4c",
  "head_block_age": "13 days old",
  "next_maintenance_time": "13 days ago",
  "chain_id": "4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8"
,
  "participation": "100.00000000000000000",
  "active_witnesses": [
    "1.6.1",
    "1.6.3",
    "1.6.4",
    "1.6.5",
    "1.6.6",
    "1.6.7",
    "1.6.8",
    "1.6.9",
    "1.6.10",
    "1.6.11",
    "1.6.12",
    "1.6.13",
    "1.6.14",
    "1.6.15",
    "1.6.16",
    "1.6.17",
    "1.6.18",
    "1.6.19",
    "1.6.20",
    "1.6.21",
    "1.6.22",
    "1.6.23",
    "1.6.24",
    "1.6.25",
    "1.6.26",
    "1.6.27",
    "1.6.28",
    "1.6.29",
    "1.6.32",
    "1.6.33",
    "1.6.34"
  ],
  "active_committee_members": [
    "1.5.0",
    "1.5.2",
    "1.5.4",
    "1.5.5",
    "1.5.6",
    "1.5.7",
    "1.5.8",
    "1.5.9",
    "1.5.10",
    "1.5.11",
    "1.5.1"
  ]
}
unlocked >>>


[cube]

I downloaded the latest official binary and tried the witness_node, as if I am a layman.  Surprisingly, I got the same result as you - ie the witness_node.exe seemed to be stuck.  The witness node output information seems to be changed.  It becomes quiet, possibly to be less spamy.

Here is what you can do:

1) Follow what xeldal advised:  make a shortcut with "C:\Program Files\BitShares 2\bin\witness_node.exe" --rpc-endpoint "127.0.0.1:8090" as the target.
Run this shortcut as Administrator

2) make a shortcut with "C:\Program Files\BitShares 2\bin\cli_wallet.exe" -H 127.0.0.1:8092 -s ws://127.0.0.1:8090 as the target.
Run this shortcut as Administrator

3) When the wallet runs, enter 'info' at the 'new' prompt.  You will get to see a number of stuff.  Look out for 'head_block_num'.  This number will be increasing even though the witness_node seems to be stuck with no new output from it.  But it is not stuck.  It is working quietly.

[tonyk]

The screenshot shows your node was able to perform an initial network communication with seeds but died off soon after (0 network IO).  So the question is why? Did it die off because it was blocked or did it encounter some logic errors?  Was it a network timeout because of too congested pipe/too small bandwidth?

To know that:

1) Did you disable Firewall?   Disable it.  At least enable local port 1777

2) Do a 'netstat -a' to show the network socket state with seed nodes

3) Show the last 20 to 30 lines of p2p.log.  This gives an idea what the node was doing. Eg was it killing off some socket connections? And why?

" initial network communication with seeds but died off soon after (0 network IO). "
This is just a snapshot... it is very active on and off.

I can send you all the logs if you point me to where.

[cube]

The screenshot shows your node was able to perform an initial network communication with seeds but died off soon after (0 network IO).  So the question is why? Did it die off because it was blocked or did it encounter some logic errors?  Was it a network timeout because of too congested pipe/too small bandwidth?

To know that:

1) Did you disable Firewall?   Disable it.  At least enable local port 1777

2) Do a 'netstat -a' to show the network socket state with seed nodes

3) Show the last 20 to 30 lines of p2p.log.  This gives an idea what the node was doing. Eg was it killing off some socket connections? And why?

[tonyk]

A lot of activity is going on...but the withness_node still stuck.

[abit]

Looks like you run into a strange state. The active witness list and active committee member list are incorrect. But the block id of head block 2821722 is correct. (This should be able to be solved via --replay-blockchain).

(and I'm sorry that my assumptions of wrong version was incorrect but I kept insisting it)

In regards to the stuck issue, if you don't have another program running and listening on port 8090 or some other required ports, or for some reason the port isn't released cleanly, so current node is blocked from listening on the port / connecting to the network.. maybe p2p.log will help. Or a reboot.

[tonyk]

@tonky: could you please run the cli against your witness and execute "about" in the cli?

Code: [Select]

unlocked >>> about
about
{
  "client_version": "2.0.160128",
  "graphene_revision": "c1c37df31a5dab9beff5f169a00852b87b0d2039",
  "graphene_revision_age": "4 days ago",
  "fc_revision": "6495004302239ae0c775f05a0e78780c3b189502",
  "fc_revision_age": "16 weeks ago",
  "compile_date": "compiled on Jan 30 2016 at 15:34:20",
  "boost_version": "1.58",
  "openssl_version": "OpenSSL 1.0.1g 7 Apr 2014",
  "build": "win32 64-bit"
}
unlocked >>>

Code: [Select]

info
{'active_witnesses': ['1.6.1', '1.6.3', '1.6.4', '1.6.5', '1.6.6', '1.6.7', '1.6.8', '1.6.9', '1.6.10', '1.6.11', '1.6.12', '1.6.13', '1.6.14', '1.6.15', '1.6.16', '1.6.17', '1.6.18', '1.6.19', '1.6.20', '1.6.21', '1.6.22', '1.6.23', '1.6.24', '1.6.25', '1.6.26', '1.6.27', '1.6.28', '1.6.29', '1.6.32', '1.6.33', '1.6.34'], 'chain_id': '4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8', 'head_block_id': '002b0e5a206413b5f17ee209705b51b3cb90fa4c', 'active_committee_members': ['1.5.0', '1.5.2', '1.5.4', '1.5.5', '1.5.6', '1.5.7', '1.5.8', '1.5.9', '1.5.10', '1.5.11', '1.5.1'], 'next_maintenance_time': '12 days ago', 'head_block_num': 2821722, 'head_block_age': '13 days old', 'participation': '100.00000000000000000'}


[xeroc]

@tonky: could you please run the cli against your witness and execute "about" in the cli?

[cube]

Stupid question maybe, but do you have enough disk space left?

193 G under win, 183 G under Linux

Update.... weird enough, stuck at exactly the same point under Ubuntu. [only difference it stuck a few blocks earlier 2821705..i.e 05 instead of 22

Granted I just ran it, then ran it with --replay-blockchain

At least this is the more supported OS so probably more people can help.

Well, you have not provided the netstats info for seed communication and the p2p log.  We cannot rule out a firewall or a network communication problem.

[abit]

Stupid question maybe, but do you have enough disk space left?

193 G under win, 183 G under Linux

Update.... weird enough, stuck at exactly the same point under Ubuntu. [only difference it stuck a few blocks earlier 2821705..i.e 05 instead of 22

Granted I just ran it, then ran it with --replay-blockchain

At least this is the more supported OS so probably more people can help.

Can I login to your Linux machine and take a look? Or windows? I suspect from the beginning that you're using a wrong version, and still think so. Might be stupid reasons.

[tonyk]

Stupid question maybe, but do you have enough disk space left?

193 G under win, 183 G under Linux

Update.... weird enough, stuck at exactly the same point under Ubuntu. [only difference it stuck a few blocks earlier 2821705..i.e 05 instead of 22

Granted I just ran it, then ran it with --replay-blockchain

At least this is the more supported OS so probably more people can help.

[xeroc]

Stupid question maybe, but do you have enough disk space left?

[tonyk]

[update]
sorry for being somewhat slow with this...

ran the cube's exe.

same result. stuck at the same point - [blochchain ID and block#]

given up more or less on getting this thing working

When you're posting there is another hard fork. No exe file has been released so far. Perhaps you can try to compile by yourself. This guide: https://github.com/neura-sx/neura-sx.github.io/blob/master/BUILD_WIN64.md

yeeh... but thanks.
As I posted moments ago I did listen to today's mumble's recording.
 So... I do  think my internet cannot handle the 'requirements'*  to run a witness node... 

*700 empty blocks... to say nothing if an asshole or two overloads the blockchain with a transaction or 2 every 10,000 blocks...

What is your Internet bandwidth?

I faced similar issue recently during the hard fork - ie blockchain download stuck.   But when I added a working seed node. It started downloading. So all is well.
The recent hard fork caused the binary to be invalid.  I will upload a new binary if the devs have not done so by then.

Edit: Latest Win tools binary is uploaded here - https://github.com/btscube/bitshares-2/releases/tag/20160129
Add a valid seed to the command line arguments eg -s 185.25.22.21:1776

CNX has released latest windows cli tools.
Cube: you didn't update the source/branch of your github repo to newest commit, it looks strange.

Still stuck at the same point as before. (not like Xeldal)
started with --replay-blockchain, btw.

[abit]

[update]
sorry for being somewhat slow with this...

ran the cube's exe.

same result. stuck at the same point - [blochchain ID and block#]

given up more or less on getting this thing working

When you're posting there is another hard fork. No exe file has been released so far. Perhaps you can try to compile by yourself. This guide: https://github.com/neura-sx/neura-sx.github.io/blob/master/BUILD_WIN64.md

yeeh... but thanks.
As I posted moments ago I did listen to today's mumble's recording.
 So... I do  think my internet cannot handle the 'requirements'*  to run a witness node... 

*700 empty blocks... to say nothing if an asshole or two overloads the blockchain with a transaction or 2 every 10,000 blocks...

What is your Internet bandwidth?

I faced similar issue recently during the hard fork - ie blockchain download stuck.   But when I added a working seed node. It started downloading. So all is well.
The recent hard fork caused the binary to be invalid.  I will upload a new binary if the devs have not done so by then.

Edit: Latest Win tools binary is uploaded here - https://github.com/btscube/bitshares-2/releases/tag/20160129
Add a valid seed to the command line arguments eg -s 185.25.22.21:1776

CNX has released latest windows cli tools.
Cube: you didn't update the source/branch of your github repo to newest commit, it looks strange.

[cube]

[update]
sorry for being somewhat slow with this...

ran the cube's exe.

same result. stuck at the same point - [blochchain ID and block#]

given up more or less on getting this thing working

When you're posting there is another hard fork. No exe file has been released so far. Perhaps you can try to compile by yourself. This guide: https://github.com/neura-sx/neura-sx.github.io/blob/master/BUILD_WIN64.md

yeeh... but thanks.
As I posted moments ago I did listen to today's mumble's recording.
 So... I do  think my internet cannot handle the 'requirements'*  to run a witness node... 

*700 empty blocks... to say nothing if an asshole or two overloads the blockchain with a transaction or 2 every 10,000 blocks...

What is your Internet bandwidth?

I faced similar issue recently during the hard fork - ie blockchain download stuck.   But when I added a working seed node. It started downloading. So all is well.
The recent hard fork caused the binary to be invalid.  I will upload a new binary if the devs have not done so by then.

Edit: Latest Win tools binary is uploaded here - https://github.com/btscube/bitshares-2/releases/tag/20160129
Add a valid seed to the command line arguments eg -s 185.25.22.21:1776

[tonyk]

[update]
sorry for being somewhat slow with this...

ran the cube's exe.

same result. stuck at the same point - [blochchain ID and block#]

given up more or less on getting this thing working

When you're posting there is another hard fork. No exe file has been released so far. Perhaps you can try to compile by yourself. This guide: https://github.com/neura-sx/neura-sx.github.io/blob/master/BUILD_WIN64.md

yeeh... but thanks.
As I posted moments ago I did listen to today's mumble's recording.
 So... I do  think my internet cannot handle the 'requirements'*  to run a witness node... 

*700 empty blocks... to say nothing if an asshole or two overloads the blockchain with a transaction or 2 every 10,000 blocks...

[abit]

[update]
sorry for being somewhat slow with this...

ran the cube's exe.

same result. stuck at the same point - [blochchain ID and block#]

given up more or less on getting this thing working

When you're posting there is another hard fork. No exe file has been released so far. Perhaps you can try to compile by yourself. This guide: https://github.com/neura-sx/neura-sx.github.io/blob/master/BUILD_WIN64.md

[tonyk]

[update]
sorry for being somewhat slow with this...

ran the cube's exe.

same result. stuck at the same point - [blochchain ID and block#]

given up more or less on getting this thing working

[abit]

  However you can try my compiled binary just to test it out. Remember to remove the blockchain and object folders.

https://github.com/btscube/bitshares-2/releases

Testing right now...

Did you change your repository in the last 2 mo. or so? I specifically checked, during this ordeal (last 2-3 days) to see if you have any compilation of your own and I did not see any.

[edit] ...and the same result...same chain ID as in the pic above...

Sorry Tony I didn't understand what you've said.

If you problem hasn't get solved yet, it might be a really stupid human error.

You reinstalled cli tools? the file date changed or still 1/4?
what's the path of the files (in the picture)?
what's your exact command for starting witness_node?

By the way I'm using cube's binary file and it works fine.

[tonyk]

  However you can try my compiled binary just to test it out. Remember to remove the blockchain and object folders.

https://github.com/btscube/bitshares-2/releases

Testing right now...

Did you change your repository in the last 2 mo. or so? I specifically checked, during this ordeal (last 2-3 days) to see if you have any compilation of your own and I did not see any.

[edit] ...and the same result...same chain ID as in the pic above...

[cube]

104.236.144.84:1777,   -> 104.236.144.84:1777 last seen 2016-01-26T18:37:49

This is puppies's seed. It would b e interesting to see what it sent you in the p2p log.

This one 84.200.17.129 from above is a  seed node. The communication went something like...

Code: [Select]

active: 84.200.17.129:1779 with 97ea3e6a4056decd6d44868e43cb444d883f875cebedfd00a48159a23a95c0b67f   [outbound]

eer 84.200.17.129:1779 because they didn't respond to my request for sync item ids after ["002b0e5966422ef475e20ef2c96acdaec7d51127","002b21e06bbd170a778f9cbc8891fa73f51764b1...

nnection.cpp:202
2016-01-26T19:00:36 p2p:message read_loop on_connection_closed ] Remote peer 84.200.17.129:1779 closed their connection to us

node.cpp:985
2016-01-26T19:00:36 p2p:message read_loop schedule_peer_for_de ] scheduling peer for deletion: 84.200.17.129:1779 (this will not block)

handshaking: 84.200.17.129:1779 with 000000000000000000000000000000000000000000000000000000000000000000  [unknown]

handshaking: 84.200.17.129:1779 with 97ea3e6a4056decd6d44868e43cb444d883f875cebedfd00a48159a23a95c0b67f  [outbound]
84.200.17.129:1779 last seen 2016-01-26T19:00:50


You may like to find out why seed 84.200.17.129 is not responding to your node. Is it blocked?

What about other seeds' communication? Do you have the info?

some active communications with some non-seed nodes
from p2p.log2016012T1800000

Code: [Select]

node.cpp:2522
2016-01-26T18:37:51 p2p:message read_loop fetch_next_batch_of_ ] sync: sending a request for the next items after 002b2d966b7cf344032b787762760e770e22c90d to peer 159.203.101.247:54765, (full request is ["002b0e5966422ef475e2...

node.cpp:2424
2016-01-26T18:37:51 p2p:message read_loop           on_message ] handling message blockchain_item_ids_inventory_message_type 57179945df4926db3b90931eafa6834ba1213ce8 size 40010 from peer 159.203.101.247:5
node.cpp:1754
2016-01-26T18:37:51 p2p:message read_loop on_blockchain_item_i ] sync: received a list of 2000 available items from 159.203.101.247:54765
node.cpp:1754
2016-01-26T18:37:51 p2p:message read_loop on_blockchain_item_i ] sync: received a list of 2000 available items from 159.203.101.247:54765

Since you can retrieve the p2p log, the most recent 20 to 30 lines of debug information (before and just after it got stuck) should give some clues. Post them here.

PS
and the witness node spit a new line (for the first time) after 2h or so later:

Code: [Select]

2095358ms ntp        ntp.cpp:177                   read_loop            ] ntp_de
lta_time updated to 950002 us

You can ignore them. They are updating the internal clock.

I doubt the devs tagged the release wrongly and provided an 'old' binary.  However you can try my compiled binary just to test it out. Remember to remove the blockchain and object folders.

https://github.com/btscube/bitshares-2/releases

[tonyk]

@abit same results after the last instruction - rescan blockchain and all

I'm sure you're running with an old version.

Release date 1/04/2016

Those exes of version 0103b are built at least one week after the release. See https://github.com/cryptonomex/graphene/issues/514
@tonyk dates of your files are 1/4, so won't be the newest version.
Try install again.

well if this is the case... you should have simply informed me that if I have not build them myself from source...they are likely old...

anyways... Thanks everyone.

[abit]

@abit same results after the last instruction - rescan blockchain and all

I'm sure you're running with an old version.

Release date 1/04/2016

Those exes of version 0103b are built at least one week after the release. See https://github.com/cryptonomex/graphene/issues/514
@tonyk dates of your files are 1/4, so won't be the newest version.
Try install again.

[tonyk]

@abit same results after the last instruction - rescan blockchain and all

I'm sure you're running with an old version.

Release date 1/04/2016

[abit]

@abit same results after the last instruction - rescan blockchain and all

I'm sure you're running with an old version.

[tonyk]

@abit same results after the last instruction - rescan blockchain and all

@cube - yes I see connections to several seed nodes... on and off



104.236.144.84:1777,   -> 104.236.144.84:1777 last seen 2016-01-26T18:37:49

here are data from 3 different times later on... mostly non-seed nodes as far as I can tell.

Code: [Select]

TCP    xxx.154.1.146:58678    23-95-43-126-host:50696  ESTABLISHED
 TCP    xxx.154.1.146:58678    45:1779                ESTABLISHED
 TCP    xxx.154.1.146:58678    cpe-70-114-143-108:48173  SYN_SENT
 TCP    xxx.154.1.146:58678    104.236.144.84:1777    TIME_WAIT
 TCP    xxx.154.1.146:58678    114.92.254.159:62015   LAST_ACK
 TCP    xxx.154.1.146:58678    115.29.36.189:35897    ESTABLISHED
 TCP    xxx.154.1.146:58678    178.62.88.151:60335    TIME_WAIT
 TCP    xxx.154.1.146:58678    witness:35718          LAST_ACK
 TCP    xxx.154.1.146:58718    a23-72-60-161:https    CLOSE_WAIT


 TCP    xxx.154.1.146:58678    162.243.138.215:40124  ESTABLISHED
 TCP    xxx.154.1.146:58678    178.62.88.151:60335    ESTABLISHED

 TCP    xxx.154.1.146:58678    li699-30:44223         ESTABLISHED
 TCP    xxx.154.1.146:58678    69.30.232.146:52002    ESTABLISHED
 TCP    xxx.154.1.146:58678    84.200.17.129:1779     ESTABLISHED
 TCP    xxx.154.1.146:58678    104.236.144.84:1777    ESTABLISHED
 TCP    xxx.154.1.146:58678    li611-150:42665        TIME_WAIT
 TCP    xxx.154.1.146:58678    115.29.36.189:35897    ESTABLISHED

This one 84.200.17.129 from above is a  seed node. The communication went something like...

Code: [Select]

active: 84.200.17.129:1779 with 97ea3e6a4056decd6d44868e43cb444d883f875cebedfd00a48159a23a95c0b67f   [outbound]

eer 84.200.17.129:1779 because they didn't respond to my request for sync item ids after ["002b0e5966422ef475e20ef2c96acdaec7d51127","002b21e06bbd170a778f9cbc8891fa73f51764b1...

nnection.cpp:202
2016-01-26T19:00:36 p2p:message read_loop on_connection_closed ] Remote peer 84.200.17.129:1779 closed their connection to us

node.cpp:985
2016-01-26T19:00:36 p2p:message read_loop schedule_peer_for_de ] scheduling peer for deletion: 84.200.17.129:1779 (this will not block)

handshaking: 84.200.17.129:1779 with 000000000000000000000000000000000000000000000000000000000000000000  [unknown]

handshaking: 84.200.17.129:1779 with 97ea3e6a4056decd6d44868e43cb444d883f875cebedfd00a48159a23a95c0b67f  [outbound]
84.200.17.129:1779 last seen 2016-01-26T19:00:50



some active communications with some non-seed nodes
from p2p.log2016012T1800000

Code: [Select]

node.cpp:2522
2016-01-26T18:37:51 p2p:message read_loop fetch_next_batch_of_ ] sync: sending a request for the next items after 002b2d966b7cf344032b787762760e770e22c90d to peer 159.203.101.247:54765, (full request is ["002b0e5966422ef475e2...

node.cpp:2424
2016-01-26T18:37:51 p2p:message read_loop           on_message ] handling message blockchain_item_ids_inventory_message_type 57179945df4926db3b90931eafa6834ba1213ce8 size 40010 from peer 159.203.101.247:5
node.cpp:1754
2016-01-26T18:37:51 p2p:message read_loop on_blockchain_item_i ] sync: received a list of 2000 available items from 159.203.101.247:54765
node.cpp:1754
2016-01-26T18:37:51 p2p:message read_loop on_blockchain_item_i ] sync: received a list of 2000 available items from 159.203.101.247:54765
PS
and the witness node spit a new line (for the first time) after 2h or so later:

Code: [Select]

2095358ms ntp        ntp.cpp:177                   read_loop            ] ntp_de
lta_time updated to 950002 us

[cube]

Thanks everyone.
1) I am running this
BitShares-2.0.160103b-x64-cli-tools.exe

It is the latest for win that I see up there. Is there newer version somewhere?

2)Specifically allowed the witness_node.exe through the firewall. (and turning it off completely - with same results)...
 

Code: [Select]

TCP    0.0.0.0:52122          Inspiron_i5:0          LISTENING


This is allowing port 52122. What about other ports? Are they opened? Do turn off firewall completely to eradicate this as a possible issue.

3) I believe I have a connection to this seed node:

 

Code: [Select]

TCP    xxx.156.1.146:52122    188.166.188.206:1779   ESTABLISHED
edit: I thought it was visible from the pic above but it seems not. anyway 188.166.188.206:1779   is one of the seed nodes witness_node.exe is trying to connect to.

What to try next? I believe I was running the witness node during the last hard fork time if this changes anything somehow.

Do you see other seed nodes established?   Once we know seeds and peers are communicating with your node, the next thing is to find out if they are indeed sending out information to it.

[abit]

Thanks everyone.
1) I am running this
BitShares-2.0.160103b-x64-cli-tools.exe

It is the latest for win that I see up there. Is there newer version somewhere?

2)Specifically allowed the witness_node.exe through the firewall. (and turning it off completely - with same results)...
 

Code: [Select]

TCP    0.0.0.0:52122          Inspiron_i5:0          LISTENING


3) I believe I have a connection to this seed node:

 

Code: [Select]

TCP    xxx.156.1.146:52122    188.166.188.206:1779   ESTABLISHED
edit: I thought it was visible from the pic above but it seems not. anyway 188.166.188.206:1779   is one of the seed nodes witness_node.exe is trying to connect to.

What to try next? I believe I was running the witness node during the last hard fork time if this changes anything somehow.

1. Reinstall BitShares-2.0.160103b-x64-cli-tools.exe and take a look at C:\Program Files\BitShares 2\bin\, make sure it's the newest one.
2. start witness_node.exe with parameter "--replay-blockchain"

[tonyk]

Thanks everyone.
1) I am running this
BitShares-2.0.160103b-x64-cli-tools.exe

It is the latest for win that I see up there. Is there newer version somewhere?

2)Specifically allowed the witness_node.exe through the firewall. (and turning it off completely - with same results)...
 

Code: [Select]

TCP    0.0.0.0:52122          Inspiron_i5:0          LISTENING


3) I believe I have a connection to this seed node:

 

Code: [Select]

TCP    xxx.156.1.146:52122    188.166.188.206:1779   ESTABLISHED
edit: I thought it was visible from the pic above but it seems not. anyway 188.166.188.206:1779   is one of the seed nodes witness_node.exe is trying to connect to.

What to try next? I believe I was running the witness node during the last hard fork time if this changes anything somehow.

[abit]

A few things to check:

1) You are running the latest witness_node (what is the version release?)
2) Your firewall is not blocking witness_node (disable firewall temporary to check)
3) You are connected to at least one seed node and not blocked  (show result of command 'netstat -a' here).

I'm sure @tonyk is running with an old version. The newest version contains a hard fork logic at block #2821745 on Jan. 3.

[cube]

well, I run it as administrator as it is (I suppose using a link to do so will not change much), the problem is it just hangs ..after finding the longest chain to hook up to (something like 2.8 mil blocks as of Jan something)...it just hangs somewhere shortly after.


[edit]

A few things to check:

1) You are running the latest witness_node (what is the version release?)
2) Your firewall is not blocking witness_node (disable firewall temporary to check)
3) You are connected to at least one seed node and not blocked  (show result of command 'netstat -a' here).

[tonyk]

For Witness:
I make a shortcut with "C:\Program Files\BitShares 2\bin\witness_node.exe" --rpc-endpoint "127.0.0.1:8090"
as the target.
Run as Administrator

For wallet:
I make a shortcut with "C:\Program Files\BitShares 2\bin\cli_wallet.exe" -H 127.0.0.1:8092 -s ws://127.0.0.1:8090
as the target.
Run as Administrator

well, I run it as administrator as it is (I suppose using a link to do so will not change much), the problem is it just hangs ..after finding the longest chain to hook up to (something like 2.8 mil blocks as of Jan something)...it just hangs somewhere shortly after.


[edit]

[Xeldal]

For Witness:
I make a shortcut with "C:\Program Files\BitShares 2\bin\witness_node.exe" --rpc-endpoint "127.0.0.1:8090"
as the target.
Run as Administrator

For wallet:
I make a shortcut with "C:\Program Files\BitShares 2\bin\cli_wallet.exe" -H 127.0.0.1:8092 -s ws://127.0.0.1:8090
as the target.
Run as Administrator

[tonyk]

as per thread title - anybody able to run the latest witness node under windows and if 'yes', how?

Thanks.

@cube ...@pc  ?