BitShares Forum
Main => General Discussion => Topic started by: bytemaster on October 05, 2015, 02:23:40 pm
-
https://github.com/cryptonomex/graphene/releases/tag/test6
The goal of this test network is to test blockchain features rather than network throughput. The network code has been intentionally rate limited by latency by only fetching one transaction at a time from each peer. Low latency connections (10 ms) may be able to push up to 100 TPS along their link whereas high-latency connections (250ms) will only be able to push 4 TPS per second across their link. This effectively rate limits how fast each PEER can broadcast. The actual rate at which a witness can receive transactions will depend upon how many peers they are connected to, the latency to those peers, and the total number of unique transactions those peers know about.
A side effect of this rate limiting is that "flood attacks" could cause a traffic jam that prevent new transactions from getting included before they expire. Users will have to try again later when the network is less busy. If there was a sustained flood attack it would generate significant revenue for the network so it should be welcomed.
-
use this:
cmake -DBOOST_ROOT="$BOOST_ROOT" -DCMAKE_BUILD_TYPE=Release
-
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Configuring incomplete, errors occurred!
anybody a quick tip?
-
sudo apt-get install doxygen
but read the top of the bash output as its probably boost
I will have a 2 CPU VPS witness up tonight
-
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Configuring incomplete, errors occurred!
anybody a quick tip?
Doxygen shouldn't be required. What other errors did cmake throw?
-
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Configuring incomplete, errors occurred!
anybody a quick tip?
Doxygen shouldn't be required. What other errors did cmake throw?
I had some errors before days with some librarys (libxc or something like that but I insaleed them ) thanks
-
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Configuring incomplete, errors occurred!
anybody a quick tip?
Doxygen shouldn't be required. What other errors did cmake throw?
thanks
-
after
BOOST_ROOT=$HOME/opt/boost_1_57_0
problems solved.... I thought I had do that ???
.... now building ;)
-
@bytemaster
change the title to October 6 Test (instead 5) ;)
-
@bytemaster
change the title to October 6 Test (instead 5) ;)
Today is Oct 5 ;)
-
Compiling now at 70% ...
BTW, isn't the release the default type? (cmake . == cmake -D CMAKE_BUILD_TYPE=Release)
-
after
BOOST_ROOT=$HOME/opt/boost_1_57_0
problems solved.... I thought I had do that ???
.... now building ;)
works for me too - thank you :)
-
stats.bitshares.eu is up-to-date
-
@bytemaster when will be the best time for the (last) stress test? I am planning 100 TPS for 1 hours.
-
@bytemaster when will be the best time for the (last) stress test? I am planning 100 TPS for 1 hours.
make it 101 TPS for 1 hour for obvious reasons :P
-
I need some CORE to register my witness (plus for stress test) Please send some to 'delegate-clayop'
Thanks in advance.
-
@bytemaster when will be the best time for the (last) stress test? I am planning 100 TPS for 1 hours.
make it 101 TPS for 1 hour for obvious reasons :P
There is no "best time" for this test. I would recommend doing it at several different points in time because with the latest code there should be no way for you to overload the network.
-
There is a Mac GUI full node available now on the release page.
Light GUI downloads for Mac and Windows will be available later today.
Windows Full Node will be available someday ;)
-
There is a Mac GUI full node available now on the release page.
Light GUI downloads for Mac and Windows will be available later today.
Windows Full Node will be available someday ;)
Great! We are getting there .. 2.0.
-
Can someone send 5k Core to dele-puppy?
-
Can someone send 5k Core to dele-puppy?
Sent
-
spartako (1.6.18) ready and waiting for votes (set proxy to 'dan')
get_witness spartako
{
"id": "1.6.18",
"witness_account": "1.2.73135",
}
-
Can someone send 5k core to bitcube?
-
delegate-clayop (1.6.17) is ready.
-
roadscape (1.6.20) is ready
-
compiling .
can someone send 5000core to bue? Thanks
-
dele-puppy is ready.
-
Can someone send 5k core to bitcube?
2015-10-05T15:51:57 Transfer 5000 CORE from spartako to bitcube (Fee: 20 CORE)
-
Can someone send 5k core to bitcube?
2015-10-05T15:51:57 Transfer 5000 CORE from spartako to bitcube (Fee: 20 CORE)
Got it. Thanks!
bitcube is ready. Please vote.
"id": "1.6.21",
"witness_account": "1.2.8055",
-
compiling .
can someone send 5000core to bue? Thanks
2015-10-05T15:57:30 Transfer 5000 CORE from spartako to bue (Fee: 20 CORE)
-
I was trying to import a bts account but it failed with not accepting certain a character. I have a special char in my password.
Unexpected char '11111111' in ""
{"c":111111111,"s":""}
th_a json_relaxed.hpp:738 variant_from_stream
{"str":"import_accounts backup.json xxxxx"}
th_a json.cpp:494 variants_from_string
Note: password and invalid char code are masked.
-
Forgot to mention vps specs
2 vCPUs, 7.5 GB memory
-
clayop, your delegate is missing blocks
edit:
how do I quit witness_node cleanly thru gdb?
-
pmc up and running - please vote.
-
Now what? Where does this code expect to see the json file, has that changed?
Does it have to do with the Release type?
@Bytemaster - is cmake . == cmake -D CMAKE_BUILD_TYPE=Release ???
Anyone? Tell me if I will have to recompile...
ANSWERS please ????
626991ms th_a witness.cpp:112 plugin_initialize ] 11 eof_exception: End Of File
stringstream
{}
th_a sstream.cpp:109 peek
{"str":""}
th_a json.cpp:478 from_string
626992ms th_a main.cpp:183 main ] Exiting with error:
11 eof_exception: End Of File
stringstream
{}
th_a sstream.cpp:109 peek
{"str":""}
th_a json.cpp:478 from_string
rethrow
{}
th_a witness.cpp:112 plugin_initialize
-
Now what? Where does this code expect to see the json file, has that changed?
Does it have to do with the Release type?
@bytemaster - is cmake . == cmake -D CMAKE_BUILD_TYPE=Release ???
Anyone? Tell me if I will have to recompile...
ANSWERS please ????
626991ms th_a witness.cpp:112 plugin_initialize ] 11 eof_exception: End Of File
stringstream
{}
th_a sstream.cpp:109 peek
{"str":""}
th_a json.cpp:478 from_string
626992ms th_a main.cpp:183 main ] Exiting with error:
11 eof_exception: End Of File
stringstream
{}
th_a sstream.cpp:109 peek
{"str":""}
th_a json.cpp:478 from_string
rethrow
{}
th_a witness.cpp:112 plugin_initialize
Looks like a typo in your commandline args (is gensis file path correct?)
-
Looks like a typo in your commandline args (is gensis file path correct?)
Thanks BM. Path is correct. I did rename the file to conform to previous testnet name formats, just so I wouldn't have to fiddle with scripts on 4 systems.
I can't imagine the name is hard coded in tho.
I am using some of wackous automation to launch, but that hasn't changed all weekend. I edit a yaml config file with new seed IP:port, chainID and genesis file. It has always been used from the root of the account folder, but I also put in the data-dir file along with the config.
I take it the answer to my question is the cmake lines are the same, or that type = Release is the default.
-
My witness is randomly missing blocks and I don't know why.
-
Now what? Where does this code expect to see the json file, has that changed?
Does it have to do with the Release type?
@Bytemaster - is cmake . == cmake -D CMAKE_BUILD_TYPE=Release ???
Anyone? Tell me if I will have to recompile...
ANSWERS please ????
626991ms th_a witness.cpp:112 plugin_initialize ] 11 eof_exception: End Of File
stringstream
{}
th_a sstream.cpp:109 peek
{"str":""}
th_a json.cpp:478 from_string
626992ms th_a main.cpp:183 main ] Exiting with error:
11 eof_exception: End Of File
stringstream
{}
th_a sstream.cpp:109 peek
{"str":""}
th_a json.cpp:478 from_string
rethrow
{}
th_a witness.cpp:112 plugin_initialize
have you download the new genesis.json file?
cd ~/graphene/programs/witness_node
wget https://github.com/cryptonomex/graphene/releases/download/test6/oct5-genesis.json.zip
unzip oct5-genesis.json.zip
./witness_node --rpc-endpoint "127.0.0.1:8090" --genesis-json oct5-genesis.json -d test_net_6 -s "104.236.51.238:2001"
-
delegate.baozi(1.6.23) is ready
-
have you download the new genesis.json file?
cd graphene
wget https://github.com/cryptonomex/graphene/releases/download/test6/oct5-genesis.json.zip
unzip oct5-genesis.json.zip
./witness_node --rpc-endpoint "127.0.0.1:8090" --genesis-json oct5-genesis.json -d test_net_6 -s "104.236.51.238:2001"
Yes I did. That's not it. Is there a config file option for chainID? I'll just launch it directly. I know there's a cmd line arg for the chainID, but prefer to put as much as I can in the config.ini Everything you have on your cmd line liondani I have in my config.ini. I don't even see a chainID arg for witness_node --help ?
-
OK guys, something else has changed. Now this IS the first time I've compiled on the VPS, but I saw no errors. Eliminating wackou's tools I invoked directly and got the same error:
/home/admin/.BitShares2_bin/witness_node --rpc-endpoint "127.0.0.1:8090" --genesis-json ~/oct-05-testnet-genesis.json -d ~/.BitShares2 -s "104.236.51.238:2005"
I'm compiling on my dev machine to see if there is something related to that, bit it will take 30 minutes to complete and another 15 to upload the binary to the VPS. Bummer. Should have been ready to go. If I get the same result from dev machine build there's something besides the build host, b/c I use the same script to build in both cases. Actually I use wackou's build tools. It's a pretty straightforward build process, even if it's done manually.
Besides, it look like a silly "can't read the json file" error, and unless the VPS host is using an odd library should be extremely stable code. If the build was using a dynamic lib not available it would be a different error.
-
Your test net Genesis file is wrong
Sent from my iPhone using Tapatalk
-
Requesting CORE for delegate registration. Please send to fox.
Thanks in advance.
-
Your test net Genesis file is wrong
Sent from my iPhone using Tapatalk
No it's not. Read more of my posts. I renamed it. Look at the date...
Size of genesis file: 61385650 bytes unzipped.
-
Your test net Genesis file is wrong
Sent from my iPhone using Tapatalk
No it's not. Read more of my posts. I renamed it. Look at the date...
Size of genesis file: 61385650 bytes unzipped.
I got the same error when i misspelled the genesis file.
I think maybe you are designating the wrong location.
You are telling it to look in root when the file, according to your prior post, is in the ~/graphene/ directory.
try -d ~/graphene/oct-05-testnet-genesis.json
edit: try --genesis-json ~/graphene/oct-05-testnet-genesis.json
-
can I get 5000 CORE from someone. Thanks send to "xeldal"
I imported a couple balances but they did not show up. nvrmind, bad syntax
-
Your test net Genesis file is wrong
Sent from my iPhone using Tapatalk
No it's not. Read more of my posts. I renamed it. Look at the date...
Size of genesis file: 61385650 bytes unzipped.
I got the same error when i misspelled the genesis file.
I think maybe you are designating the wrong location.
You are telling it to look in root when the file, according to your prior post, is in the ~/graphene/ directory.
try -d ~/graphene/oct-05-testnet-genesis.json
Thanks for responding Xedal, but if you look closer you'll see the binaries are in the .BitShares2_bin folder and the --data-dir (i.e. -d) folder is .BitShares2. I put copies of the genesis file in both the root (~/.oct....) AND the .BitShares2 folder, so it should find it either way. The config.ini file is located in the .BitShares2 folder and also has a genesis file definition without a path. I went ahead and renamed the file BACK to the name BM provided to avoid any further confusion when I post. As I said tho, I would be surprised if that specific name was hard coded in. Renaming the file back to BM's name had no affect of course.
-
xeldal is up and ready for your vote. 1.6.24
2core 4GB VPS
-
xeldal is up and ready for your vote. 1.6.24
2core 4GB VPS
Voted :)
-
witness mr.agsexplorer (1.6.25) is ready
-
Please vote for my witness, hosted on a dedicated server with 8 cores and 16gb of ram and a 100mbit line:
get_witness mindphlux.witness
{
"id": "1.6.26",
"witness_account": "1.2.91505",
"last_aslot": 0,
"signing_key": "GPH7kQ7HhW5RVzoNhAeV8LPcoWFR1WSfzeMrpCeRHm3C3VHG7MEQR",
"vote_id": "1:36",
"total_votes": 0,
"url": "true",
"total_missed": 0,
"last_confirmed_block_num": 0
}
Thanks!
-
I'm built, synced and
<nearly> ready to produce blocks. I'm looking for 5000+ CORE to complete:
create_witness fox "" true
Thanks in advance.
-
Sent!
-
Hmm still don't know why I was missing blocks.
Edit: Stupid of me.. I forgot replace old witness node file with newly built version. I am rebuilding now and will post once I'm ready.
-
What the bleep is going on! Dam if it's not one thing it's another.
admin@seed06:~/.BitShares2_bin$ ls -ls
total 822568
0 lrwxrwxrwx 1 admin admin 38 Oct 5 18:38 cli_wallet -> cli_wallet_2015-10-05_test6-1-g60b5228
79456 -rwxr-xr-x 1 admin admin 81361534 Oct 5 17:01 cli_wallet_2015-10-05_test6
80464 -rwxr-xr-x 1 admin admin 82394008 Oct 5 18:32 cli_wallet_2015-10-05_test6-1-g60b5228
32304 -rw-r--r-- 1 admin admin 33079187 Oct 5 18:51 test6bin.tgz
0 lrwxrwxrwx 1 admin admin 40 Oct 5 18:38 witness_node -> witness_node_2015-10-05_test6-1-g60b5228
76960 -rwxr-xr-x 1 admin admin 78803733 Oct 5 17:01 witness_node_2015-10-05_test6
78172 -rwxr-xr-x 1 admin admin 80045408 Oct 5 18:32 witness_node_2015-10-05_test6-1-g60b5228
Major difference in the binaries between those produced on the VPS vs my dev machine. Thought for sure that was the issue, but NOT!
I had no issues before with the build methodology I used for the testnet, now all lthe sudden shit is different. Ultra bummer.
There has got to be a silly stupid change made somewhere. I am going to compile test5 again and see if the binaries differ and if it runs. If it does then whatever is different is not on my end. You all will hear some explitives if that is the case. I doubt it is but I've spent WAY too much time dealing with this today and must go now. If test5 is built and runs without this silly json read error I know something else is the problem.
The only thing that may be the cause on my end I could see is the release flag, since nobody has bothered to answer THAT question. It will SUCK if it turns out that is the culprit. It really wouldn't surprise me tho. It just would be nice if I could get a straight answer. It will require changing wackou's code to fix that, which is not a big deal to do but the point is it shouldn't be necessary and it has cost me alot of time that those tools are supposed to save. The flags he uses to build the code have always worked before.
If the -D CMAKE_BUILD_TYPE=Release definition is so crucial and is not the same as not defining it why is that so damned hard to answer? The build default should be release and the exception debug. Reversing it (if that is what has been done) has screwed at least 2 people.
Edit: just to make sure it wasn't the json file itself I used an old one, but still got the same error.
-
What the bleep is going on! Dam if it's not one thing it's another.
admin@seed06:~/.BitShares2_bin$ ls -ls
total 822568
0 lrwxrwxrwx 1 admin admin 38 Oct 5 18:38 cli_wallet -> cli_wallet_2015-10-05_test6-1-g60b5228
79456 -rwxr-xr-x 1 admin admin 81361534 Oct 5 17:01 cli_wallet_2015-10-05_test6
80464 -rwxr-xr-x 1 admin admin 82394008 Oct 5 18:32 cli_wallet_2015-10-05_test6-1-g60b5228
32304 -rw-r--r-- 1 admin admin 33079187 Oct 5 18:51 test6bin.tgz
0 lrwxrwxrwx 1 admin admin 40 Oct 5 18:38 witness_node -> witness_node_2015-10-05_test6-1-g60b5228
76960 -rwxr-xr-x 1 admin admin 78803733 Oct 5 17:01 witness_node_2015-10-05_test6
78172 -rwxr-xr-x 1 admin admin 80045408 Oct 5 18:32 witness_node_2015-10-05_test6-1-g60b5228
Major difference in the binaries between those produced on the VPS vs my dev machine. Thought for sure that was the issue, but NOT!
I had no issues before with the build methodology I used for the testnet, now all lthe sudden shit is different. Ultra bummer.
There has got to be a silly stupid change made somewhere. I am going to compile test5 again and see if the binaries differ and if it runs. If it does then whatever is different is not on my end. You all will hear some explitives if that is the case. I doubt it is but I've spent WAY too much time dealing with this today and must go now. If test5 is built and runs without this silly json read error I know something else is the problem.
The only thing that may be the cause on my end I could see is the release flag, since nobody has bothered to answer THAT question. It will SUCK if it turns out that is the culprit. It really wouldn't surprise me tho. It just would be nice if I could get a straight answer. It will require changing wackou's code to fix that, which is not a big deal to do but the point is it shouldn't be necessary and it has cost me alot of time that those tools are supposed to save. The flags he uses to build the code have always worked before.
If the -D CMAKE_BUILD_TYPE=Release definition is so crucial and is not the same as not defining it why is that so damned hard to answer? The build default should be release and the exception debug. Reversing it (if that is what has been done) has screwed at least 2 people.
Edit: just to make sure it wasn't the json file itself I used an old one, but still got the same error.
At the risk of beating that poor horse, forgive me, : ) I still believe it may have to do with the location of your json file.
put the .json file in ~/graphene/programs/witness_node directory and launch without specifying an explicit location
for example
cd ~/graphene/programs/witness_node
wget https://github.com/cryptonomex/graphene/releases/download/test6/oct5-genesis.json.zip
unzip oct5-genesis.json.zip
./witness_node --rpc-endpoint "127.0.0.1:8090" --genesis-json oct5-genesis.json -d oct5 -s "104.236.51.238:2005"
I also changed nothing about my build process and I did not have any issues. Hope that helps. : )
-
dump_private_key does not show my witness key. Anyone had similar experience? (fortunately I memoed the private key, so ready for producing blocks)
-
Can someone publish price feeds for USD?
-
I need an instruction of updating signing key. First of all, how to generate a new signing key?
-
Please vote for spartako
-
Okay. I updated my signing key (Thanks spartako) Ready for producing blocks again.
-
dump_private_key does not show my witness key. Anyone had similar experience? (fortunately I memoed the private key, so ready for producing blocks)
same here.
there is a get_private_key , but I don't know how to use it.
I need an instruction of updating signing key. First of all, how to generate a new signing key?
suggest_brain_key
[Edit] import_key <account-name> <priv-key-5XX> [\Edit]
use they public key from above in:
update_witness <account-name> "" <pub-key-GPH> true
use the key pair from the suggest_brain_key above to launch witness
-
What is this error?
unlocked >>> list_account_balances clayoptest22
list_account_balances clayoptest22
895630ms th_a wallet.cpp:529 get_account ] my account id 1.2.91534 different from blockchain id 1.2.91532
200000 TESTCLAY
-
suggest_brain_key
import_key <account-name> <priv-key-5XX>
use they public key from above in:
update_witness <account-name> "" <pub-key-GPH> true
use the key pair from the suggest_brain_key above to launch witness
-
suggest_brain_key
import_key <account-name> <priv-key-5XX>
use they public key from above in:
update_witness <account-name> "" <pub-key-GPH> true
use the key pair from the suggest_brain_key above to launch witness
hmm. it works without that step, but may be why its not listed with dump_private_keys
-
Tried to publish USD price feed but found these errors in my wallet:
2262976ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id 217e4833af8610feb5123055c9a7776de038b6ac
2361319ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id f961b0bc6c433dedf4542d6144b26d31034a3cd3
2393349ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id 9ceb05f12b6f66cd97304771fd6a68efb29375bf
2411975ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id 21a9fe768744116519fe9a490c0be256e16c112a
Also, please vote in roadscape
My VPS has 4 cores, 6GB
edit- more details
{}
th_a asset_evaluator.cpp:463 do_evaluate
{"o":{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":3225424,"asset_id":"1.3.285"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":3225424,"asset_id":"1.3.285"}}},"extensions":[]}}
th_a asset_evaluator.cpp:471 do_evaluate
{}
th_a evaluator.cpp:42 start_evaluate
{}
th_a db_block.cpp:622 apply_operation
{"trx":{"ref_block_num":6715,"ref_block_prefix":3264209362,"expiration":"2015-10-05T19:47:12","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":3225424,"asset_id":"1.3.285"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":3225424,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures":["*snip*"]}}
th_a db_block.cpp:605 _apply_transaction
-
Next stress test will take plact at 2015/10/5 21:00 UTC.
The goal is maintaining 100 tps on average for 30 min (Since I don't have enough CORE, I cannot run for 1 hour)
-
Error while tring to create the witness
unlocked >>> create_witness bhuz "" true
create_witness bhuz "" true
3137186ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id ea4080ccb2848b7772f28e43ad5c421253c19817
0 exception: unspecified
10 assert_exception: Assert Exception
db().get(op.witness_account).is_lifetime_member():
{}
th_a witness_evaluator.cpp:29 do_evaluate
{"op":{"fee":{"amount":500000000,"asset_id":"1.3.0"},"witness_account":"1.2.7174","url":"","block_signing_key":"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ"}}
th_a witness_evaluator.cpp:31 do_evaluate
{}
th_a evaluator.cpp:42 start_evaluate
{}
th_a db_block.cpp:622 apply_operation
{"trx":{"ref_block_num":6819,"ref_block_prefix":1189634312,"expiration":"2015-10-05T19:52:45","operations":[[20,{"fee":{"amount":500000000,"asset_id":"1.3.0"},"witness_account":"1.2.7174","url":"","block_signing_key":"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ"}]],"extensions":[],"signatures":["203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393"]}}
th_a db_block.cpp:605 _apply_transaction
{"trx":{"ref_block_num":6819,"ref_block_prefix":1189634312,"expiration":"2015-10-05T19:52:45","operations":[[20,{"fee":{"amount":500000000,"asset_id":"1.3.0"},"witness_account":"1.2.7174","url":"","block_signing_key":"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ"}]],"extensions":[],"signatures":["203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393"]}}
th_a db_block.cpp:214 push_transaction
{"error":"10 assert_exception: Assert Exception\ndb().get(op.witness_account).is_lifetime_member(): \n {}\n th_a witness_evaluator.cpp:29 do_evaluate\n\n {\"op\":{\"fee\":{\"amount\":500000000,\"asset_id\":\"1.3.0\"},\"witness_account\":\"1.2.7174\",\"url\":\"\",\"block_signing_key\":\"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ\"}}\n th_a witness_evaluator.cpp:31 do_evaluate\n\n {}\n th_a evaluator.cpp:42 start_evaluate\n\n {}\n th_a db_block.cpp:622 apply_operation\n\n {\"trx\":{\"ref_block_num\":6819,\"ref_block_prefix\":1189634312,\"expiration\":\"2015-10-05T19:52:45\",\"operations\":[[20,{\"fee\":{\"amount\":500000000,\"asset_id\":\"1.3.0\"},\"witness_account\":\"1.2.7174\",\"url\":\"\",\"block_signing_key\":\"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ\"}]],\"extensions\":[],\"signatures\":[\"203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393\"]}}\n th_a db_block.cpp:605 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":6819,\"ref_block_prefix\":1189634312,\"expiration\":\"2015-10-05T19:52:45\",\"operations\":[[20,{\"fee\":{\"amount\":500000000,\"asset_id\":\"1.3.0\"},\"witness_account\":\"1.2.7174\",\"url\":\"\",\"block_signing_key\":\"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ\"}]],\"extensions\":[],\"signatures\":[\"203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393\"]}}\n th_a db_block.cpp:214 push_transaction","data":{"id":1565,"error":{"code":1,"message":"10 assert_exception: Assert Exception\ndb().get(op.witness_account).is_lifetime_member(): \n {}\n th_a witness_evaluator.cpp:29 do_evaluate\n\n {\"op\":{\"fee\":{\"amount\":500000000,\"asset_id\":\"1.3.0\"},\"witness_account\":\"1.2.7174\",\"url\":\"\",\"block_signing_key\":\"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ\"}}\n th_a witness_evaluator.cpp:31 do_evaluate\n\n {}\n th_a evaluator.cpp:42 start_evaluate\n\n {}\n th_a db_block.cpp:622 apply_operation\n\n {\"trx\":{\"ref_block_num\":6819,\"ref_block_prefix\":1189634312,\"expiration\":\"2015-10-05T19:52:45\",\"operations\":[[20,{\"fee\":{\"amount\":500000000,\"asset_id\":\"1.3.0\"},\"witness_account\":\"1.2.7174\",\"url\":\"\",\"block_signing_key\":\"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ\"}]],\"extensions\":[],\"signatures\":[\"203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393\"]}}\n th_a db_block.cpp:605 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":6819,\"ref_block_prefix\":1189634312,\"expiration\":\"2015-10-05T19:52:45\",\"operations\":[[20,{\"fee\":{\"amount\":500000000,\"asset_id\":\"1.3.0\"},\"witness_account\":\"1.2.7174\",\"url\":\"\",\"block_signing_key\":\"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ\"}]],\"extensions\":[],\"signatures\":[\"203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393\"]}}\n th_a db_block.cpp:214 push_transaction","data":{"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"witness_evaluator.cpp","line":29,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-05T19:52:17"},"format":"db().get(op.witness_account).is_lifetime_member(): ","data":{}},{"context":{"level":"warn","file":"witness_evaluator.cpp","line":31,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-05T19:52:17"},"format":"","data":{"op":{"fee":{"amount":500000000,"asset_id":"1.3.0"},"witness_account":"1.2.7174","url":"","block_signing_key":"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ"}}},{"context":{"level":"warn","file":"evaluator.cpp","line":42,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-05T19:52:17"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":622,"method":"apply_operation","hostname":"","thread_name":"th_a","timestamp":"2015-10-05T19:52:17"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":605,"method":"_apply_transaction","hostname":"","thread_name":"th_a","timestamp":"2015-10-05T19:52:17"},"format":"","data":{"trx":{"ref_block_num":6819,"ref_block_prefix":1189634312,"expiration":"2015-10-05T19:52:45","operations":[[20,{"fee":{"amount":500000000,"asset_id":"1.3.0"},"witness_account":"1.2.7174","url":"","block_signing_key":"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ"}]],"extensions":[],"signatures":["203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393"]}}},{"context":{"level":"warn","file":"db_block.cpp","line":214,"method":"push_transaction","hostname":"","thread_name":"th_a","timestamp":"2015-10-05T19:52:17"},"format":"","data":{"trx":{"ref_block_num":6819,"ref_block_prefix":1189634312,"expiration":"2015-10-05T19:52:45","operations":[[20,{"fee":{"amount":500000000,"asset_id":"1.3.0"},"witness_account":"1.2.7174","url":"","block_signing_key":"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ"}]],"extensions":[],"signatures":["203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393"]}}}]}}}}
th_a state.cpp:38 handle_reply
{"owner_account":"bhuz","broadcast":true}
th_a wallet.cpp:1378 create_witness
-
Error while tring to create the witness
unlocked >>> create_witness bhuz "" true
create_witness bhuz "" true
3137186ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id ea4080ccb2848b7772f28e43ad5c421253c19817
0 exception: unspecified
10 assert_exception: Assert Exception
db().get(op.witness_account).is_lifetime_member():
{}
th_a witness_evaluator.cpp:29 do_evaluate
{"op":{"fee":{"amount":500000000,"asset_id":"1.3.0"},"witness_account":"1.2.7174","url":"","block_signing_key":"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ"}}
th_a witness_evaluator.cpp:31 do_evaluate
{}
th_a evaluator.cpp:42 start_evaluate
{}
th_a db_block.cpp:622 apply_operation
{"trx":{"ref_block_num":6819,"ref_block_prefix":1189634312,"expiration":"2015-10-05T19:52:45","operations":[[20,{"fee":{"amount":500000000,"asset_id":"1.3.0"},"witness_account":"1.2.7174","url":"","block_signing_key":"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ"}]],"extensions":[],"signatures":["203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393"]}}
th_a db_block.cpp:605 _apply_transaction
{"trx":{"ref_block_num":6819,"ref_block_prefix":1189634312,"expiration":"2015-10-05T19:52:45","operations":[[20,{"fee":{"amount":500000000,"asset_id":"1.3.0"},"witness_account":"1.2.7174","url":"","block_signing_key":"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ"}]],"extensions":[],"signatures":["203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393"]}}
th_a db_block.cpp:214 push_transaction
{"error":"10 assert_exception: Assert Exception\ndb().get(op.witness_account).is_lifetime_member(): \n {}\n th_a witness_evaluator.cpp:29 do_evaluate\n\n {\"op\":{\"fee\":{\"amount\":500000000,\"asset_id\":\"1.3.0\"},\"witness_account\":\"1.2.7174\",\"url\":\"\",\"block_signing_key\":\"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ\"}}\n th_a witness_evaluator.cpp:31 do_evaluate\n\n {}\n th_a evaluator.cpp:42 start_evaluate\n\n {}\n th_a db_block.cpp:622 apply_operation\n\n {\"trx\":{\"ref_block_num\":6819,\"ref_block_prefix\":1189634312,\"expiration\":\"2015-10-05T19:52:45\",\"operations\":[[20,{\"fee\":{\"amount\":500000000,\"asset_id\":\"1.3.0\"},\"witness_account\":\"1.2.7174\",\"url\":\"\",\"block_signing_key\":\"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ\"}]],\"extensions\":[],\"signatures\":[\"203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393\"]}}\n th_a db_block.cpp:605 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":6819,\"ref_block_prefix\":1189634312,\"expiration\":\"2015-10-05T19:52:45\",\"operations\":[[20,{\"fee\":{\"amount\":500000000,\"asset_id\":\"1.3.0\"},\"witness_account\":\"1.2.7174\",\"url\":\"\",\"block_signing_key\":\"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ\"}]],\"extensions\":[],\"signatures\":[\"203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393\"]}}\n th_a db_block.cpp:214 push_transaction","data":{"id":1565,"error":{"code":1,"message":"10 assert_exception: Assert Exception\ndb().get(op.witness_account).is_lifetime_member(): \n {}\n th_a witness_evaluator.cpp:29 do_evaluate\n\n {\"op\":{\"fee\":{\"amount\":500000000,\"asset_id\":\"1.3.0\"},\"witness_account\":\"1.2.7174\",\"url\":\"\",\"block_signing_key\":\"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ\"}}\n th_a witness_evaluator.cpp:31 do_evaluate\n\n {}\n th_a evaluator.cpp:42 start_evaluate\n\n {}\n th_a db_block.cpp:622 apply_operation\n\n {\"trx\":{\"ref_block_num\":6819,\"ref_block_prefix\":1189634312,\"expiration\":\"2015-10-05T19:52:45\",\"operations\":[[20,{\"fee\":{\"amount\":500000000,\"asset_id\":\"1.3.0\"},\"witness_account\":\"1.2.7174\",\"url\":\"\",\"block_signing_key\":\"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ\"}]],\"extensions\":[],\"signatures\":[\"203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393\"]}}\n th_a db_block.cpp:605 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":6819,\"ref_block_prefix\":1189634312,\"expiration\":\"2015-10-05T19:52:45\",\"operations\":[[20,{\"fee\":{\"amount\":500000000,\"asset_id\":\"1.3.0\"},\"witness_account\":\"1.2.7174\",\"url\":\"\",\"block_signing_key\":\"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ\"}]],\"extensions\":[],\"signatures\":[\"203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393\"]}}\n th_a db_block.cpp:214 push_transaction","data":{"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"witness_evaluator.cpp","line":29,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-05T19:52:17"},"format":"db().get(op.witness_account).is_lifetime_member(): ","data":{}},{"context":{"level":"warn","file":"witness_evaluator.cpp","line":31,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-05T19:52:17"},"format":"","data":{"op":{"fee":{"amount":500000000,"asset_id":"1.3.0"},"witness_account":"1.2.7174","url":"","block_signing_key":"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ"}}},{"context":{"level":"warn","file":"evaluator.cpp","line":42,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-05T19:52:17"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":622,"method":"apply_operation","hostname":"","thread_name":"th_a","timestamp":"2015-10-05T19:52:17"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":605,"method":"_apply_transaction","hostname":"","thread_name":"th_a","timestamp":"2015-10-05T19:52:17"},"format":"","data":{"trx":{"ref_block_num":6819,"ref_block_prefix":1189634312,"expiration":"2015-10-05T19:52:45","operations":[[20,{"fee":{"amount":500000000,"asset_id":"1.3.0"},"witness_account":"1.2.7174","url":"","block_signing_key":"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ"}]],"extensions":[],"signatures":["203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393"]}}},{"context":{"level":"warn","file":"db_block.cpp","line":214,"method":"push_transaction","hostname":"","thread_name":"th_a","timestamp":"2015-10-05T19:52:17"},"format":"","data":{"trx":{"ref_block_num":6819,"ref_block_prefix":1189634312,"expiration":"2015-10-05T19:52:45","operations":[[20,{"fee":{"amount":500000000,"asset_id":"1.3.0"},"witness_account":"1.2.7174","url":"","block_signing_key":"GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ"}]],"extensions":[],"signatures":["203c043c7e58b76ce08bc22dc1690fe93ab75b4f4fffbb0679e51ffda7c4f3dc6a07cd1a12c266a40dfa02e17453efcfa659f7408d3403b94adf0c37bae3179393"]}}}]}}}}
th_a state.cpp:38 handle_reply
{"owner_account":"bhuz","broadcast":true}
th_a wallet.cpp:1378 create_witness
Only lifetime members can create accounts. Upgrade your account first.
-
There are some new light wallets available for Mac and Windows
https://github.com/cryptonomex/graphene/releases
-
Only lifetime members can create accounts. Upgrade your account first.
I was pretty sure I already done that, but I was wrong xD
get_witness bhuz
{
"id": "1.6.28",
"witness_account": "1.2.7174",
"last_aslot": 0,
"signing_key": "GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ",
"vote_id": "1:38",
"total_votes": 0,
"url": "",
"total_missed": 0,
"last_confirmed_block_num": 0
}
voting proxy set to dan
-
Next stress test will take plact at 2015/10/5 21:00 UTC.
The goal is maintaining 100 tps on average for 30 min (Since I don't have enough CORE, I cannot run for 1 hour)
Oops.. I probably made a mistake. I will reschedule it later
-
in.abit (1.6.29) is ready.
4 Cores 16G RAM Server.
Will publish price feeds once got voted in.
-
clayop, your delegate is missing blocks
edit:
how do I quit witness_node cleanly thru gdb?
CTRL+C
Then type "signal SIGINT", return.
-
There are some new light wallets available for Mac and Windows
https://github.com/cryptonomex/graphene/releases
welcome to the future.
Edit: will there be a standalone version? I'd like to use the lightwallet on a usb stick
-
Can dele-puppy get some votes?
Running on a quad core Xeon with 16gb ram.
-
What the bleep is going on! Dam if it's not one thing it's another.
admin@seed06:~/.BitShares2_bin$ ls -ls
total 822568
0 lrwxrwxrwx 1 admin admin 38 Oct 5 18:38 cli_wallet -> cli_wallet_2015-10-05_test6-1-g60b5228
79456 -rwxr-xr-x 1 admin admin 81361534 Oct 5 17:01 cli_wallet_2015-10-05_test6
80464 -rwxr-xr-x 1 admin admin 82394008 Oct 5 18:32 cli_wallet_2015-10-05_test6-1-g60b5228
32304 -rw-r--r-- 1 admin admin 33079187 Oct 5 18:51 test6bin.tgz
0 lrwxrwxrwx 1 admin admin 40 Oct 5 18:38 witness_node -> witness_node_2015-10-05_test6-1-g60b5228
76960 -rwxr-xr-x 1 admin admin 78803733 Oct 5 17:01 witness_node_2015-10-05_test6
78172 -rwxr-xr-x 1 admin admin 80045408 Oct 5 18:32 witness_node_2015-10-05_test6-1-g60b5228
Major difference in the binaries between those produced on the VPS vs my dev machine. Thought for sure that was the issue, but NOT!
I had no issues before with the build methodology I used for the testnet, now all lthe sudden shit is different. Ultra bummer.
There has got to be a silly stupid change made somewhere. I am going to compile test5 again and see if the binaries differ and if it runs. If it does then whatever is different is not on my end. You all will hear some explitives if that is the case. I doubt it is but I've spent WAY too much time dealing with this today and must go now. If test5 is built and runs without this silly json read error I know something else is the problem.
The only thing that may be the cause on my end I could see is the release flag, since nobody has bothered to answer THAT question. It will SUCK if it turns out that is the culprit. It really wouldn't surprise me tho. It just would be nice if I could get a straight answer. It will require changing wackou's code to fix that, which is not a big deal to do but the point is it shouldn't be necessary and it has cost me alot of time that those tools are supposed to save. The flags he uses to build the code have always worked before.
If the -D CMAKE_BUILD_TYPE=Release definition is so crucial and is not the same as not defining it why is that so damned hard to answer? The build default should be release and the exception debug. Reversing it (if that is what has been done) has screwed at least 2 people.
Edit: just to make sure it wasn't the json file itself I used an old one, but still got the same error.
At the risk of beating that poor horse, forgive me, : ) I still believe it may have to do with the location of your json file.
put the .json file in ~/graphene/programs/witness_node directory and launch without specifying an explicit location
for example
cd ~/graphene/programs/witness_node
wget https://github.com/cryptonomex/graphene/releases/download/test6/oct5-genesis.json.zip
unzip oct5-genesis.json.zip
./witness_node --rpc-endpoint "127.0.0.1:8090" --genesis-json oct5-genesis.json -d oct5 -s "104.236.51.238:2005"
I also changed nothing about my build process and I did not have any issues. Hope that helps. : )
Forgive me.. I always build with -D CMAKE_BUILD_TYPE=Debug.
No issue.
-
clayop, your delegate is missing blocks
edit:
how do I quit witness_node cleanly thru gdb?
CTRL+C
Then type "signal SIGINT", return.
Awesome, thanks :)
in.abit (1.6.29) is ready.
4 Cores 16G RAM Server.
Will publish price feeds once got voted in.
I've got your feed script running, but I'm getting errors when I try to broadcast.
Is that because my witness is inactive, or did I miss a step?
-
I've got your feed script running, but I'm getting errors when I try to broadcast.
Is that because my witness is inactive, or did I miss a step?
I think that is because you're not voted in.
-
Alright I have voted for many of you so hopefully you will get in at the next counting in 5 min.
-
How can I run the witness in gdb?
Edit: Maybe I have to specify all the path for the witness node instead of just ./witness_node etc?
-
I need votes. 2 vCPU Ivy bridge, 7.5G memory. All binaries and key are up to date.
-
Price feeding is active.
-
Please vote for wackou, running on a 2-core 4GB vultr instance
get_witness wackou
{
"id": "1.6.30",
"witness_account": "1.2.83710",
"last_aslot": 0,
"signing_key": "GPH8C1Cz3LDu732VT74bYvNE2G25NLghV96zcMnFwLd4Z6aXWup9i",
"vote_id": "1:41",
"total_votes": 0,
"url": "http://digitalgaia.io",
"total_missed": 0,
"last_confirmed_block_num": 0
}
-
get_witness bhuz
{
"id": "1.6.28",
"witness_account": "1.2.7174",
"last_aslot": 0,
"signing_key": "GPH6wV9VeA5RabRaQi1Dwn94BcpcYNxZ51XQmJ3NVAdpziZaxffZJ",
"vote_id": "1:38",
"total_votes": 0,
"url": "",
"total_missed": 0,
"last_confirmed_block_num": 0
}
voting proxy set to dan
Please vote for bhuz, 2core 4GB on digitalocean
-
How can I run the witness in gdb?
Edit: Maybe I have to specify all the path for the witness node instead of just ./witness_node etc?
(gdb) file path_and_file_name_of_your_witness_node_file
(gdb) set args your_starting_parameters
(gdb) run
-
bhuz, clayop and wackou have been voted for.
-
puppy is being a very bad boy. No blocks, no treats.
-
@puppies "dele-puppy" is missing blocks
-
100 TPS / 30 min stress test will begin in 45 min (22:10 UTC). If you can donate some CORE, please send them to 'clayop'
-
(gdb) file path_and_file_name_of_your_witness_node_file
(gdb) set args your_starting_parameters
(gdb) run
Thank you :D
Sorry to keep asking stupid questions...but, I was trying to edit xeroc scrypt for feed, and vim seems stuck. There is --INSERT --recording at the end, but I cannot write or even quit... Hint?
-
(gdb) file path_and_file_name_of_your_witness_node_file
(gdb) set args your_starting_parameters
(gdb) run
Thank you :D
Sorry to keep asking stupid questions...but, I was trying to edit xeroc scrypt for feed, and vim seems stuck. There is --INSERT --recording at the end, but I cannot write or even quit... Hint?
Try press ESC ESC ESC, then ':q!'?
-
(gdb) file path_and_file_name_of_your_witness_node_file
(gdb) set args your_starting_parameters
(gdb) run
Thank you :D
Sorry to keep asking stupid questions...but, I was trying to edit xeroc scrypt for feed, and vim seems stuck. There is --INSERT --recording at the end, but I cannot write or even quit... Hint?
Hit ESC and then type :wq to write and quit.. or :q! to quit without saving changes
-
100 TPS / 30 min stress test will begin in 45 min (22:10 UTC). If you can donate some CORE, please send them to 'clayop'
sent you 250K. How much spamming time does that buy? :)
-
puppy is being a very bad boy. No blocks, no treats.
Sorry. Id10t error on my part. I got it fixed.
-
Would someone mind sending delegate-1.lafona 5000 CORE, thanks.
Also vps has been upgraded to 2 CPU and 4 GiB
-
Pressing ESC nothing change, still says -- INSERT --recording at the bottom, and I can't send any command
-
Would someone mind sending delegate-1.lafona 5000 CORE, thanks.
Also vps has been upgraded to 2 CPU and 4 GiB
Done
-
Would someone mind sending delegate-1.lafona 5000 CORE, thanks.
Sent you some
-
Pressing ESC nothing change, still says -- INSERT --recording at the bottom, and I can't send any command
try just 'q'
-
Nice clean test clayop, a steady 10 TPS
-
try just 'q'
Nothing :(
-
100 TPS / 30 min stress test will begin in 45 min (22:10 UTC). If you can donate some CORE, please send them to 'clayop'
sent you 250K. How much spamming time does that buy? :)
I already set timer for 30 min. Next time it extends 10 minutes I think :)
-
Nice clean test clayop, a steady 10 TPS
The TPS may be higher than I expected. 10 TPS * 24 VPS = 200-250 TPS... will it be okay?
-
try just 'q'
Nothing :(
ctrl-q worked xD thanks !
-
delegate-1.lafona is up and ready to be voted in, thanks
-
(gdb) file path_and_file_name_of_your_witness_node_file
(gdb) set args your_starting_parameters
(gdb) run
Thank you :D
Sorry to keep asking stupid questions...but, I was trying to edit xeroc scrypt for feed, and vim seems stuck. There is --INSERT --recording at the end, but I cannot write or even quit... Hint?
Try press ESC ESC ESC, then ':q!'?
I would humbly suggest using
ulimit -c unlimited
this will enable core dumps for witness_node
and hence no need to run it in gdb.
Backtrace can be generated from coredump.
I hope I'm not missing something, I'm not an expert on debugging bin. apps.
-
witness 'delegate.ihashfury'
Up and ready for votes - proxy 'dan' - 2core 4GB
get_witness delegate.ihashfury
{
"id": "1.6.32",
"witness_account": "1.2.22411",
"last_aslot": 0,
"signing_key": "GPH5ao66g4Dg7uWtwMbwrxCpP1Wt7X9fXWeNAHaNsSBmcPMY5Naup",
"vote_id": "1:43",
"total_votes": 0,
"url": "http://bit.ly/ihashfury",
"total_missed": 0,
"last_confirmed_block_num": 0
}
-
get_witness jtm1
{
"id": "1.6.31",
"witness_account": "1.2.91556",
ready. The vps is
2core 2GB RAM, 1Gbit network
I will move within some hours to
4core 4GB RAM, 1Gbit network vps
so it will meet the min. specs.
-
Publishing feeds...
my machine specs are:
Digital ocean in London:
16GBMemory
8 CoreProcessor
160GBSSD Disk
6TBTransfer
-
looks like we are averaging 119 trx/sec with no significant problems.
-
I ended up on a fork. Resync-blockchain in progress. Back soon...
-
I ended up on a fork. Resync-blockchain in progress. Back soon...
A fork you couldn't recover from automatically?
-
2-core 4GB vultr instance holding good, although I did miss 11 blocks... (about half)
(http://smewt.com/downloads/oct5-spamtest.png)
-
Besides "total_missed" in get_witness, what other infos should I check to see that I am signing blocks, how many, if I am not on a fork, and other important things?
-
...and the storm is over!
It seems though that cpu usage is consistently higher than before the test although there are no transactions happening in the network.
(http://smewt.com/downloads/oct5-spamtest-after.png)
-
2 seed nodes up - feeds on the way
-
What the bleep is going on! Dam if it's not one thing it's another.
admin@seed06:~/.BitShares2_bin$ ls -ls
total 822568
0 lrwxrwxrwx 1 admin admin 38 Oct 5 18:38 cli_wallet -> cli_wallet_2015-10-05_test6-1-g60b5228
79456 -rwxr-xr-x 1 admin admin 81361534 Oct 5 17:01 cli_wallet_2015-10-05_test6
80464 -rwxr-xr-x 1 admin admin 82394008 Oct 5 18:32 cli_wallet_2015-10-05_test6-1-g60b5228
32304 -rw-r--r-- 1 admin admin 33079187 Oct 5 18:51 test6bin.tgz
0 lrwxrwxrwx 1 admin admin 40 Oct 5 18:38 witness_node -> witness_node_2015-10-05_test6-1-g60b5228
76960 -rwxr-xr-x 1 admin admin 78803733 Oct 5 17:01 witness_node_2015-10-05_test6
78172 -rwxr-xr-x 1 admin admin 80045408 Oct 5 18:32 witness_node_2015-10-05_test6-1-g60b5228
Major difference in the binaries between those produced on the VPS vs my dev machine. Thought for sure that was the issue, but NOT!
I had no issues before with the build methodology I used for the testnet, now all lthe sudden shit is different. Ultra bummer.
There has got to be a silly stupid change made somewhere. I am going to compile test5 again and see if the binaries differ and if it runs. If it does then whatever is different is not on my end. You all will hear some explitives if that is the case. I doubt it is but I've spent WAY too much time dealing with this today and must go now. If test5 is built and runs without this silly json read error I know something else is the problem.
The only thing that may be the cause on my end I could see is the release flag, since nobody has bothered to answer THAT question. It will SUCK if it turns out that is the culprit. It really wouldn't surprise me tho. It just would be nice if I could get a straight answer. It will require changing wackou's code to fix that, which is not a big deal to do but the point is it shouldn't be necessary and it has cost me alot of time that those tools are supposed to save. The flags he uses to build the code have always worked before.
If the -D CMAKE_BUILD_TYPE=Release definition is so crucial and is not the same as not defining it why is that so damned hard to answer? The build default should be release and the exception debug. Reversing it (if that is what has been done) has screwed at least 2 people.
Edit: just to make sure it wasn't the json file itself I used an old one, but still got the same error.
At the risk of beating that poor horse, forgive me, : ) I still believe it may have to do with the location of your json file.
put the .json file in ~/graphene/programs/witness_node directory and launch without specifying an explicit location
for example
cd ~/graphene/programs/witness_node
wget https://github.com/cryptonomex/graphene/releases/download/test6/oct5-genesis.json.zip
unzip oct5-genesis.json.zip
./witness_node --rpc-endpoint "127.0.0.1:8090" --genesis-json oct5-genesis.json -d oct5 -s "104.236.51.238:2005"
I also changed nothing about my build process and I did not have any issues. Hope that helps. : )
The stench from that horse is pretty rank >:(
I got it working. I don't know why that part of the code changed but it is very obvious now that it indeed has. THANKS FOR THE NOTICE!!!!! >:( >:( >:( >:(
It wasn't until I changed the -d option value to literally "-d oct5" that it started to work. If I changed it to ~/test6data it failed, even tho that folder exists and has the very same config.ini in it.
Here are the first few lines of output:
admin@seed06:~/graphene/programs/witness_node$ ./witness_node --rpc-endpoint "127.0.0.1:8090" --genesis-json oct5-genesis.json -d oct5 -s "104.236.51.238:2005"3002247ms th_a main.cpp:120 main ] Writing new config file at /home/admin/graphene/programs/witness_node/oct5/config.ini
3002248ms th_a witness.cpp:83 plugin_initialize ] witness plugin: plugin_initialize() begin
I then launched in the .BitShares2_build/programs/witness_node folder with the exact same cmd line and that worked OK too. The issue is how that --data-dir (-d) command line parameter is processed and what it does with it -- THAT IS WHAT WAS CHANGED!!! If a full pathname starting from the root is specified it also works, but not with a ~ OR not with a hidden folder (/home/admin/.BitShares2 does not work either) as it did before.
@BM : This change renders the tools wackou built to launch the witness unusable without modification, and why? If this is simply an oversight / mistake I can accept that answer, but if not please explain why this change was done, why it's necessary and why no notice was provided.
BTW - my witness is up and running now, but I can't seem to upgrade it to lifetime member, tho I have > 20K CORE in the account:
unlocked >>> upgrade_account delegate.verbaltech true
upgrade_account delegate.verbaltech true
10 assert_exception: Assert Exception
!account_obj.is_lifetime_member():
{}
th_a wallet.cpp:898 upgrade_account
{"name":"delegate.verbaltech"}
th_a wallet.cpp:909 upgrade_account
Did the parameters change or is it still 15K CORE to create a witness AND upgrade the status?
-
I ended up on a fork. Resync-blockchain in progress. Back soon...
A fork you couldn't recover from automatically?
Yes, the node failed to find the main chain while actively producing blocks. I've not yet reviewed the logs to determine when the fork occurred. We should see a number of blocks that fox produced and were rejected by the network. I noticed the block_head_age was minutes old, so restarted the node. It failed to sync upon reboot, so I --resync-blockchain.
-
@Thom
It looks like that account is already upgraded:
get_account delegate.verbaltech
{
"id": "1.2.22441",
"membership_expiration_date": "1969-12-31T23:59:59",
"registrar": "1.2.22441",
"referrer": "1.2.22441",
"lifetime_referrer": "1.2.22441",
...
Try to create your witness:
create_witness delegate.verbaltech "Your URL here" true
-
I don't know why I can't upgrade the account, never the less would somebody please vote delegate.verbaltech in?
Thanks!
-
need 5000 core for my account to be wittiness : bue
spartako sent me 5000 core but i used it for register and my current balance is not enough for witness registration
compiling .
can someone send 5000core to bue? Thanks
2015-10-05T15:57:30 Transfer 5000 CORE from spartako to bue (Fee: 20 CORE)
-
Thanks Fox, I did create the witness:
get_witness delegate.verbaltech
{
"id": "1.6.34",
"witness_account": "1.2.22441",
"last_aslot": 0,
"signing_key": "GPH6oUevPDj52JK67E199jBAMBuh6CQBQGgkyLtoXKiAvTVCpvYU7",
"vote_id": "1:45",
"total_votes": 0,
"url": "https://bitsharestalk.org/index.php/topic,13837.0.html",
"total_missed": 0,
"last_confirmed_block_num": 0
}
but when I tried to upgrade it I got this error:
unlocked >>> upgrade_account delegate.verbaltech true
upgrade_account delegate.verbaltech true
10 assert_exception: Assert Exception
!account_obj.is_lifetime_member():
{}
th_a wallet.cpp:898 upgrade_account
{"name":"delegate.verbaltech"}
th_a wallet.cpp:909 upgrade_account
unlocked >>> list_account_balances delegate.verbaltech
list_account_balances delegate.verbaltech
20027 CORE
See that ! in there, that leads me to believe the account is NOT (!) a lifetime member. The cmd did produce an exception. If it meant it was ALREADY a lifetime member the message is fucked. Just one more to add to the list I guess!
-
I don't know why I can't upgrade the account, never the less would somebody please vote delegate.verbaltech in?
Thanks!
I've not checked the genesis file, but suspect your IsLifetimeMember flag was set to TRUE for this go.
I see the witness now:
get_witness delegate.verbaltech
{
"id": "1.6.34",
"witness_account": "1.2.22441",
"last_aslot": 0,
"signing_key": "GPH6oUevPDj52JK67E199jBAMBuh6CQBQGgkyLtoXKiAvTVCpvYU7",
"vote_id": "1:45",
"total_votes": 0,
"url": "https://bitsharestalk.org/index.php/topic,13837.0.html",
"total_missed": 0,
"last_confirmed_block_num": 0
}
-
Thanks Fox, I did create the witness:
get_witness delegate.verbaltech
{
"id": "1.6.34",
"witness_account": "1.2.22441",
"last_aslot": 0,
"signing_key": "GPH6oUevPDj52JK67E199jBAMBuh6CQBQGgkyLtoXKiAvTVCpvYU7",
"vote_id": "1:45",
"total_votes": 0,
"url": "https://bitsharestalk.org/index.php/topic,13837.0.html",
"total_missed": 0,
"last_confirmed_block_num": 0
}
but when I tried to upgrade it I got this error:
unlocked >>> upgrade_account delegate.verbaltech true
upgrade_account delegate.verbaltech true
10 assert_exception: Assert Exception
[glow=red,2,300]!account_obj.is_lifetime_member(): [/glow]
{}
th_a wallet.cpp:898 upgrade_account
{"name":"delegate.verbaltech"}
th_a wallet.cpp:909 upgrade_account
unlocked >>> list_account_balances delegate.verbaltech
list_account_balances delegate.verbaltech
20027 CORE
See that ! in there, that leads me to believe the account is NOT (!) a lifetime member. The cmd did produce an exception. If it meant it was ALREADY a lifetime member the message is fucked. Just one more to add to the list I guess!
If you can create witness, you are already a lifetime member.
-
need 5000 core for my account to be wittiness : bue
spartako sent me 5000 core but i used it for register and my current balance is not enough for witness registration
compiling .
can someone send 5000core to bue? Thanks
2015-10-05T15:57:30 Transfer 5000 CORE from spartako to bue (Fee: 20 CORE)
Done.
-
Thx abit. That is yet another departure from xeroc's "how to become a witness" doc.
Anybody get the impression I'm a bit frustrated? (not with anybody in particular, just been one of those days!)
Could I get a little love sent my way -- I could use some votes to so I can start producing blocks...
-
need 5000 core for my account to be wittiness : bue
Done. [EDIT: I suppose not, I think I was on my own private chain]
If someone needs some CORE, I have abit more this time around, please ask.
My witness will be up any minute...
-
thanks bhuz.
witness bue is ready for getting votes ...
please vote bue to the witness list
need 5000 core for my account to be wittiness : bue
spartako sent me 5000 core but i used it for register and my current balance is not enough for witness registration
compiling .
can someone send 5000core to bue? Thanks
2015-10-05T15:57:30 Transfer 5000 CORE from spartako to bue (Fee: 20 CORE)
Done.
-
Great test, some witnesses went off on a temporary fork, but after the flooding was over they recovered automatically.
Fox, you probably would have been OK had you let it auto-resolve.
The challenge we had was that during the flood syncing of new nodes (or forked nodes) was impaired.
-
If someone would be so kind as to send riverhead 5000 CORE?
-
If someone would be so kind as to send riverhead 5000 CORE?
I will. Send to riverhead?
Just tried, but I'm apparently too fatigued to know how:
transfer delegate.verbaltech riverhead 5000 BTS "There ya be! :)" true
Which fails, not sure what syntactical error I've made... :'(
-
If someone would be so kind as to send riverhead 5000 CORE?
I will. Send to riverhead?
Just tried, but I'm apparently too fatigued to know how:
transfer delegate.verbaltech riverhead 5000 BTS "There ya be! :)" true
Which fails, not sure what syntactical error I've made... :'(
Try CORE instead of BTS
May I have +5000 CORE on bitshaers-argentina to register witness and some tx fees?
-
If someone would be so kind as to send riverhead 5000 CORE?
I will. Send to riverhead?
Just tried, but I'm apparently too fatigued to know how:
transfer delegate.verbaltech riverhead 5000 BTS "There ya be! :)" true
Which fails, not sure what syntactical error I've made... :'(
Try CORE instead of BTS
May I have +5000 CORE on bitshaers-argentina to register witness and some tx fees?
Doh!
-
If someone would be so kind as to send riverhead 5000 CORE?
I will. Send to riverhead?
Just tried, but I'm apparently too fatigued to know how:
transfer delegate.verbaltech riverhead 5000 BTS "There ya be! :)" true
Which fails, not sure what syntactical error I've made... :'(
Try CORE instead of BTS
May I have +5000 CORE on bitshaers-argentina to register witness and some tx fees?
Sent
-
Great test, some witnesses went off on a temporary fork, but after the flooding was over they recovered automatically.
Fox, you probably would have been OK had you let it auto-resolve.
The challenge we had was that during the flood syncing of new nodes (or forked nodes) was impaired.
+5%
-
If someone would be so kind as to send riverhead 5000 CORE?
I will. Send to riverhead?
Just tried, but I'm apparently too fatigued to know how:
transfer delegate.verbaltech riverhead 5000 BTS "There ya be! :)" true
Which fails, not sure what syntactical error I've made... :'(
Try CORE instead of BTS
May I have +5000 CORE on bitshaers-argentina to register witness and some tx fees?
Send it to where?
to bitshares-argentina, thank you
-
There was a typo in your address ;)
-
Is there anyone out there with voting clout?
-
get_witness 'delegate.ihashfury' feeds are ready. Just need a few votes.
Its 02:13 here so I will catch up tomorrow.
-
Thank you Thom. riverhead (1.6.36) is up and running.
-
NP James.
How'd you get voted in so fast? I'm still waiting...
If I were on a fork I couldn't have sent funds. But info AND get_global_properties show that witness 1.6.33 is the highest. IIRC BM said the maintenance interval is like 5 minutes for this test.
-
NP James.
How'd you get voted in so fast? I'm still waiting...
I'm not in. Just created the witness.
-
same ask and please vote for bue --witness-id '"1.6.35"'
dump question.... how many witness in total as final agree upon ? still 101?
Is there anyone out there with voting clout?
-
**************************************************************************************************
EDIT: PLEASE Disregard this whole post, I think I was on a private chain pretty much on my own.
**************************************************************************************************
Witness 'spectral' is up. I think.
EDIT: The witness is running on 2 Cores, 4GB RAM, 100GB SSD
get_witness spectral
{
"id": "1.6.12",
"witness_account": "1.2.73210",
"last_aslot": 0,
"signing_key": "GPH8ZWNd9K82gPqKVDbkK8etaYTBMQ3ME3MTQ6HqF586ZbMLrZ5DH",
"vote_id": "1:22",
"total_votes": 0,
"url": "bitspace.no",
"total_missed": 0,
"last_confirmed_block_num": 0
}
BUT I'm somewhat confused right now. After creating the witness and getting the witness ID, I closed down the cli_wallet, and fixed the witness config file. Good.
When I started up the witness again, it complained that there were no blocks received. So I closed it and tried to restart it with --resync-blockchain. That didn't fix it, but I waited abit and it fixed itself. Problem solved, I thought.
So now I try to fire up the cli_wallet again: I can't see any balances in my account. When I try "get_witness spectral" I get this output:
get_witness spectral
0 exception: unspecified
No account or witness named spectral
{"account":"spectral"}
th_a wallet.cpp:1310 get_witness
{"owner_account":"spectral"}
th_a wallet.cpp:1314 get_witness
I'm not sure if it will fix itself, or has something gone terribly wrong and i should remake the wallet?
btw, witness output is looking like this:
1419531ms th_a application.cpp:432 handle_transaction ] Got transaction from network
1419684ms th_a application.cpp:432 handle_transaction ] Got transaction from network
1419799ms th_a application.cpp:388 handle_block ] Got block #12018 with time 2015-10-06T00:23:39 from network with latency of 800 ms from init1
1419904ms th_a application.cpp:518 get_item ] Serving up block #12018
1420505ms th_a application.cpp:518 get_item ] Serving up block #12018
1421324ms th_a application.cpp:518 get_item ] Serving up block #12018
1422000ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
1422276ms th_a application.cpp:388 handle_block ] Got block #12019 with time 2015-10-06T00:23:42 from network with latency of 278 ms from roadscape
1422370ms th_a application.cpp:518 get_item ] Serving up block #12019
1425000ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
1425201ms th_a application.cpp:388 handle_block ] Got block #12020 with time 2015-10-06T00:23:45 from network with latency of 202 ms from init5
1428000ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
1428056ms th_a application.cpp:388 handle_block ] Got block #12021 with time 2015-10-06T00:23:48 from network with latency of 57 ms from bhuz
1428150ms th_a application.cpp:518 get_item ] Serving up block #12021
1431000ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
1431202ms th_a application.cpp:388 handle_block ] Got block #12022 with time 2015-10-06T00:23:51 from network with latency of 203 ms from init3
1434000ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
1434203ms th_a application.cpp:388 handle_block ] Got block #12023 with time 2015-10-06T00:23:54 from network with latency of 205 ms from init9
1437000ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
1437203ms th_a application.cpp:388 handle_block ] Got block #12024 with time 2015-10-06T00:23:57 from network with latency of 204 ms from init4
**************************************************************************************************
EDIT: PLEASE Disregard this whole post, I think I was on a private chain pretty much on my own.
**************************************************************************************************
-
same ask and please vote for bue --witness-id '"1.6.35"'
dump question.... how many witness in total as final agree upon ? still 101?
Is there anyone out there with voting clout?
You mean how many will be used for initial launch on the 13th?
Last I heard it was 17.
-
There was a typo in your address ;)
doh! thanks
bitshares-argentina is ready, please vote:
"id": "1.6.37",
"witness_account": "1.2.8517"
Not enough core to set_voting_proxy tx fee
-
(gdb) file path_and_file_name_of_your_witness_node_file
(gdb) set args your_starting_parameters
(gdb) run
Thank you :D
Sorry to keep asking stupid questions...but, I was trying to edit xeroc scrypt for feed, and vim seems stuck. There is --INSERT --recording at the end, but I cannot write or even quit... Hint?
Try press ESC ESC ESC, then ':q!'?
I would humbly suggest using
ulimit -c unlimited
this will enable core dumps for witness_node
and hence no need to run it in gdb.
Backtrace can be generated from coredump.
I hope I'm not missing something, I'm not an expert on debugging bin. apps.
You need to test that and make sure your system is not going to take the core file and do something silly like send it to the Ubuntu bug reporting server. Apt
-
Finally, witness is up! Please vote for witness 'spectral'
get_witness spectral
{
"id": "1.6.38",
"witness_account": "1.2.73210",
"last_aslot": 0,
"signing_key": "GPH8ZWNd9K82gPqKVDbkK8etaYTBMQ3ME3MTQ6HqF586ZbMLrZ5DH",
"vote_id": "1:49",
"total_votes": 0,
"url": "bitspace.no",
"total_missed": 0,
"last_confirmed_block_num": 0
}
This witness is running on a "dedicated" VPS located in Oslo, Norway.
Specs:
Ubuntu 14.04
2 cores
4 GB RAM
100 GB SSD
Vote me in, and tomorrow I will focus on setting up price feeds.
I think my problem earlier was that I was connected to a private chain all by myself when I first created the witness, and later, when I joined the slightly more popular chain, it was like I had never been there! The only syntax difference I could find from the log was that I used port 2001 on the seed node instead of 2005, SAME IP!!! Sneaky little bug there! :)
And if someone wants some CORE, I finally have access to some.
Oh, and
set_voting_proxy spectral dan true
-
delegate.baozi need some votes.
Intel(R) Xeon(R) CPU E5-2680 * 2 CPU
2G mem
delegate.baozi(1.6.23) is ready
-
I missed the spams and all its activities while I was in my dreamland. It was 2am, way past my usual sleeping time. The testnet passed the spam with flying colours!
bitcube is up and ready for votes. Please vote for bitcube - 1.6.21.
2core 4GB VPS.
-
Thanks thom . so we are getting 17 witnesses on 2.0 live chain.
please vote for bue --witness-id '"1.6.35"'
AMD FX 6300 six cores processor
with 4GB RAM 100 GB SSD on ubuntu 14.04
same ask and please vote for bue --witness-id '"1.6.35"'
dump question.... how many witness in total as final agree upon ? still 101?
Is there anyone out there with voting clout?
You mean how many will be used for initial launch on the 13th?
Last I heard it was 17.
-
Was anyone able to see which nodes dealt with the spam the best? I'd like to know what their specs are.
-
elmato is ready but need some votes.
VPS: 4gb / 2 cores
get_witness elmato
{
"id": "1.6.39",
"witness_account": "1.2.26472",
"last_aslot": 0,
"signing_key": "GPH7TrF5cDX66egLWPLJ7YCnZD5vHeFTgNbPChV8MDQnVKMzDfPrK",
"vote_id": "1:50",
"total_votes": 0,
"url": "http://about:blank",
"total_missed": 0,
"last_confirmed_block_num": 0
}
-
Was anyone able to see which nodes dealt with the spam the best? I'd like to know what their specs are.
Prob you or spartako 8)
-
Seems like quite a few here need votes to become functional witnesses.
Who has the voting power in this test chain? I know BM does but I think it's past his bedtime 8) Speaking of which I think it's about time for mine tonight.
Good luck to the night shift, I'll see where we are the morning.
BTW my VPS is a 4GB RAM, dual core CPU I mentioned earlier today, seed06.
-
I turned off cpu throttling on my server. Hopefully we can get some more spam at some point. I'd like to see if it makes a difference.
-
DigitalOcean VPS, Amsterdam 2 region - 2 Cores, 4GB RAM - 4GB swap file, SSD.
xeroc's pricefeeds script ready. Waiting for votes.
bitshares-argentina
"id": "1.6.37"
"witness_account": "1.2.8517"
-
When I try to connect the cli_wallet to my local witness node it crashes with the following segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff4f86700 (LWP 7101)]
0x0000000000ed7d98 in websocketpp::processor::hybi13<fc::http::detail::asio_with_stub_log>::consume(unsigned char*, unsigned long, std::error_code&) ()
(gdb) backtrace
#0 0x0000000000ed7d98 in websocketpp::processor::hybi13<fc::http::detail::asio_with_stub_log>::consume(unsigned char*, unsigned long, std::error_code&) ()
#1 0x0000000000eb92a9 in websocketpp::connection<fc::http::detail::asio_with_stub_log>::handle_read_frame(std::error_code const&, unsigned long) ()
#2 0x0000000000e8af24 in websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::handle_async_read(boost::system::error_code const&, unsigned long) ()
#3 0x0000000000ea1825 in boost::asio::detail::completion_handler<boost::asio::detail::binder2<std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::system::error_code, unsigned long> >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#4 0x0000000000ea1a96 in void boost::asio::detail::strand_service::dispatch<boost::asio::detail::binder2<std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::system::error_code, unsigned long> >(boost::asio::detail::strand_service::strand_impl*&, boost::asio::detail::binder2<std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::system::error_code, unsigned long>&) ()
#5 0x0000000000ea1bc1 in std::_Function_handler<void (boost::system::error_code const&, unsigned long), boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::asio::detail::is_continuation_if_running> >::_M_invoke(std::_Any_data const&, boost::system::error_code const&, unsigned long&&) ()
#6 0x0000000000ea2e8d in boost::asio::detail::read_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_at_least_t, websocketpp::transport::asio::custom_alloc_handler<std::function<void (boost::system::error_code const&, unsigned long)> > >::operator()(boost::system::error_code const&, unsigned long, int) ()
#7 0x0000000000ea344d in boost::asio::detail::reactive_socket_recv_op<boost::asio::mutable_buffers_1, boost::asio::detail::read_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_at_least_t, websocketpp::transport::asio::custom_alloc_handler<std::function<void (boost::system::error_code const&, unsigned long)> > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#8 0x0000000000e2d475 in boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#9 0x0000000000ee72f6 in fc::asio::default_io_service_scope::default_io_service_scope()::{lambda()#1}::operator()() const ()
#10 0x000000000102fa35 in thread_proxy ()
#11 0x00007ffff774a4a4 in start_thread () from /usr/lib/libpthread.so.0
#12 0x00007ffff5e4912d in clone () from /usr/lib/libc.so.6
All it needs for me is run ./programs/cli_wallet/cli_wallet -s ws://127.0.0.1:8090 (which gets stuck after wdata.ws_user: wdata.ws_password:)
-
When I try to connect the cli_wallet to my local witness node it crashes with the following segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff4f86700 (LWP 7101)]
0x0000000000ed7d98 in websocketpp::processor::hybi13<fc::http::detail::asio_with_stub_log>::consume(unsigned char*, unsigned long, std::error_code&) ()
(gdb) backtrace
#0 0x0000000000ed7d98 in websocketpp::processor::hybi13<fc::http::detail::asio_with_stub_log>::consume(unsigned char*, unsigned long, std::error_code&) ()
#1 0x0000000000eb92a9 in websocketpp::connection<fc::http::detail::asio_with_stub_log>::handle_read_frame(std::error_code const&, unsigned long) ()
#2 0x0000000000e8af24 in websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::handle_async_read(boost::system::error_code const&, unsigned long) ()
#3 0x0000000000ea1825 in boost::asio::detail::completion_handler<boost::asio::detail::binder2<std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::system::error_code, unsigned long> >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#4 0x0000000000ea1a96 in void boost::asio::detail::strand_service::dispatch<boost::asio::detail::binder2<std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::system::error_code, unsigned long> >(boost::asio::detail::strand_service::strand_impl*&, boost::asio::detail::binder2<std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::system::error_code, unsigned long>&) ()
#5 0x0000000000ea1bc1 in std::_Function_handler<void (boost::system::error_code const&, unsigned long), boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::asio::detail::is_continuation_if_running> >::_M_invoke(std::_Any_data const&, boost::system::error_code const&, unsigned long&&) ()
#6 0x0000000000ea2e8d in boost::asio::detail::read_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_at_least_t, websocketpp::transport::asio::custom_alloc_handler<std::function<void (boost::system::error_code const&, unsigned long)> > >::operator()(boost::system::error_code const&, unsigned long, int) ()
#7 0x0000000000ea344d in boost::asio::detail::reactive_socket_recv_op<boost::asio::mutable_buffers_1, boost::asio::detail::read_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_at_least_t, websocketpp::transport::asio::custom_alloc_handler<std::function<void (boost::system::error_code const&, unsigned long)> > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#8 0x0000000000e2d475 in boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#9 0x0000000000ee72f6 in fc::asio::default_io_service_scope::default_io_service_scope()::{lambda()#1}::operator()() const ()
#10 0x000000000102fa35 in thread_proxy ()
#11 0x00007ffff774a4a4 in start_thread () from /usr/lib/libpthread.so.0
#12 0x00007ffff5e4912d in clone () from /usr/lib/libc.so.6
All it needs for me is run ./programs/cli_wallet/cli_wallet -s ws://127.0.0.1:8090 (which gets stuck after wdata.ws_user: wdata.ws_password:)
No errors here, cli connects both to local and testnet witness
-
Besides "total_missed" in get_witness, what other infos should I check to see that I am signing blocks, how many, if I am not on a fork, and other important things?
Anyone? :D
plus: I got these Switching to fork...is that normal?
2142521ms th_a db_block.cpp:134 _push_block ] Switching to fork: 00005533af820b6f366ed2f11e3044d3943ad047
2322180ms th_a db_block.cpp:134 _push_block ] Switching to fork: 0000556f7cfaf73f72dfca8e1a026db30d8d4121
-
Please vote for witness 'spectral' (Ubuntu 14.04, 2 Cores, 4GB RAM, 100 GB SSD)
Also, I assume we want as many users as possible to vote. I would like to place some votes, and I find that there is a certain threshold in knowledge and time expenditure to get started on this. Is there a guide for voters somewhere? For example, how can I get a quick overview of all registered witnesses?
-
Do witnesses need to be voted in to publish feeds?
I am getting this wallet error
371145ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id d1715aaf27490593e64500143a944efe82cda849
-
I just added several more of you to the slate I am voting for. You should be in on the hour.
-
I just added several more of you to the slate I am voting for. You should be in on the hour.
Thanks for the votes and support
-
will there be a test of the referral system in this test net?
-
will there be a test of the referral system in this test net?
If you do so .. then there will :D
-
will there be a test of the referral system in this test net?
If you do so .. then there will :D
does the ?r=id thingy work?
-
does the ?r=id thingy work?
nop .. you need to manually register another account and set yourself as referrar/registrar .. than you can use the new account and should see a payback in your original account
-
I just added several more of you to the slate I am voting for. You should be in on the hour.
Thank you! bitcube is producing blocks.
will there be a test of the referral system in this test net?
If you do so .. then there will :D
does the ?r=id thingy work?
Have you tried the graphene create user account command (at the cli_wallet)? It has the referrer part.
-
I just added several more of you to the slate I am voting for. You should be in on the hour.
Thank you! bitcube is producing blocks.
will there be a test of the referral system in this test net?
If you do so .. then there will :D
does the ?r=id thingy work?
Have you tried the graphene create user account command (at the cli_wallet)? It has the referrer part.
no doubt about the blockchain level. I and I guess many others need to prepare for next week. and not knowing how to craft links is a major roadblock for marketers
-
I just added several more of you to the slate I am voting for. You should be in on the hour.
Thank you! bitcube is producing blocks.
will there be a test of the referral system in this test net?
If you do so .. then there will :D
does the ?r=id thingy work?
Have you tried the graphene create user account command (at the cli_wallet)? It has the referrer part.
no doubt about the blockchain level. I and I guess many others need to prepare for next week. and not knowing how to craft links is a major roadblock for marketers
I see. You are looking for faucet or web-wallet referral links. I think the devs are busy with the blockchain development and testing. The ref link probably comes after it.
-
Random question. I know that fees have been lowered in the testnet and can be dynamically altered. Would it be preferable to maintain low fees in the initial launch and increase fees later on as an incentive to onboard new users?
-
Witness delegate.verbaltech is ready to start producing blocks if I can get some votes...
-
Witness delegate.verbaltech is ready to start producing blocks if I can get some votes...
I would like to send a few votes your way! However, I remember @bytemaster saying something about the need to vote for the total number of witnesses you want to allow..? Until I figure out exactly what I need to be doing when voting, I have my votes proxied to dan.
-
can witness mr.agsexplorer (1.6.25) have some votes? Thanks.
-
running xeroc's pricefeed scrypt every 45 min
-
I'm not really sure what is going on (getting to be a typical response from me in this thread).
I'm not seeing much activity here today.
I would have thought it would be important to get as many people learning how to be a witness so the number of people with that type of ability will have actual experience in doing it.
It has been quite a learning curve and continues to be. The code continues to evolve as well, so it's a moving target.
Since I figured out how to work around the problems I discovered yesterday (still don't know yet their cause), I have managed to migrate a balance from 0.9.x into this testnet, create a witness account and be ready to get voted in. I see quite a few others here who are at the same spot but as yet are not voted in.
Why not? Are there not several people participating that have enough voting power to make that happen?
When BM started this test he described the parameters and the primary purpose for this phase of testing. Glad to see that. Setting goals is the first requirement for measuring success. We should be doing more of that on all fronts. Each of us should also have personal goals for our participation in these tests.
My goals are to help the project, partly through my partnership with wackou to create quality infrastructure that serves as a reliable, low latency platform to run witness, seed and backbone nodes on, and partly to strengthen my technical prowess to manage such infrastructure.
I find my personal goals somewhat blocked at the moment, waiting on my partner (his candle is being burnt on both ends this week) and the other participants in this test (I still need some votes). I don't see that I have any direct control over those things at the moment.
All I can do is express my intentions and appeal to others. It's rather like campaigning!
In the mean time I continue to streamline the tools we need to deploy a fully functional VPS with the least amount of manual steps and effort. Staying current with the changes is just one part of that. Communication is another. That's what I'm doing here.
-
Need some votes, I forgot to mentioned it here, :o :o :o
-
My witness is publishing pricefeeds now.
-
I'm not really sure what is going on (getting to be a typical response from me in this thread).
I'm not seeing much activity here today.
I would have thought it would be important to get as many people learning how to be a witness so the number of people with that type of ability will have actual experience in doing it.
It has been quite a learning curve and continues to be. The code continues to evolve as well, so it's a moving target.
Since I figured out how to work around the problems I discovered yesterday (still don't know yet their cause), I have managed to migrate a balance from 0.9.x into this testnet, create a witness account and be ready to get voted in. I see quite a few others here who are at the same spot but as yet are not voted in.
Why not? Are there not several people participating that have enough voting power to make that happen?
When BM started this test he described the parameters and the primary purpose for this phase of testing. Glad to see that. Setting goals is the first requirement for measuring success. We should be doing more of that on all fronts. Each of us should also have personal goals for our participation in these tests.
My goals are to help the project, partly through my partnership with wackou to create quality infrastructure that serves as a reliable, low latency platform to run witness, seed and backbone nodes on, and partly to strengthen my technical prowess to manage such infrastructure.
I find my personal goals somewhat blocked at the moment, waiting on my partner (his candle is being burnt on both ends this week) and the other participants in this test (I still need some votes). I don't see that I have any direct control over those things at the moment.
All I can do is express my intentions and appeal to others. It's rather like campaigning!
In the mean time I continue to streamline the tools we need to deploy a fully functional VPS with the least amount of manual steps and effort. Staying current with the changes is just one part of that. Communication is another. That's what I'm doing here.
The last testnet you needed to set dan to be your voting proxy
set_voting_proxy <youraccountname> dan true
just wait for bytemaster to come around here and check who else needs voting / check his proxy list
-
The last testnet you needed to set dan to be your voting proxy
set_voting_proxy <youraccountname> dan true
just wait for bytemaster to come around here and check who else needs voting / check his proxy list
I must have missed that. Proxy is now set.
I just scanned the wallet commands (I dumped them all into an editor for easy reference) for proxy and slate, but I only see one item for setting the proxy.
How can I see what Dan's slate is from the cli_wallet interface?
-
Random question. I know that fees have been lowered in the testnet and can be dynamically altered. Would it be preferable to maintain low fees in the initial launch and increase fees later on as an incentive to onboard new users?
I agree and it should be a % of the transfer ( a fraction) so even micro transfer's would increase.
What about for example 0.2%(or whatever) with a maximum cap? Just saying....
-
I would appreciate votes too, proxy set
jtm1
{
"id": "1.6.31",
"witness_account": "1.2.91556"
-
How can I see what Dan's slate is from the cli_wallet interface?
I think this
get_account dan
-
The last testnet you needed to set dan to be your voting proxy
set_voting_proxy <youraccountname> dan true
just wait for bytemaster to come around here and check who else needs voting / check his proxy list
I must have missed that. Proxy is now set.
I just scanned the wallet commands (I dumped them all into an editor for easy reference) for proxy and slate, but I only see one item for setting the proxy.
How can I see what Dan's slate is from the cli_wallet interface?
You can check it here:
https://graphene.bitshares.org/#/account/dan/voting
Currently "delegate.verbaltech" is not on BM's list:
bhuz
bitcube
bue
dele-puppy
delegate-1.lafona
delegate-clayop
delegate.baozi
delegate.btsnow
delegate.ihashfury
elmato
fox
in.abit
mindphlux.witness
roadscape
spartako
spectral
wackou
xeldal
-
Thanks Spectral / jakub
-
How can I see what Dan's slate is from the cli_wallet interface?
I think this
get_account dan
Not sure if this confirms he added me to his proxy or not, but running that command produces this list (partial dump of the commands output):
"options": {
"memo_key": "GPH8JvEXv853AzosCgJEpHLDreNG3pDwr9uxYeA86cL587ooKLmJG",
"voting_account": "1.2.5",
"num_witness": 29,
"num_committee": 0,
"votes": [
"1:0",
"1:1",
"1:2",
"1:3",
"1:4",
"1:5",
"1:6",
"1:7",
"1:8",
"1:9",
"1:10",
"1:22",
"1:27",
"1:28",
"1:29",
"1:30",
"1:31",
"1:33",
"1:34", <-- delegate.verbaltech
"1:36",
"1:37",
"1:38",
"1:39",
"1:41",
"1:43",
"1:44",
"1:46",
"1:49",
"1:50"
],
If so no votes have accrued and I am not producing blocks yet. Maybe need to wait for the maintenance interval to occur, which looks like it's every hour. If that has remained the same I think everyone will be voted in near the top of the hour.
:) Thanks BM!
-
I just added you a second before you checked :) Wait 20 minutes for the next vote counting.
-
I just added you a second before you checked :) Wait 20 minutes for the next vote counting.
Yep, that's what I figured. Thanks again!
-
I've missed every block so far. Could it be a network latency issue, or is is about what most of you are seeing?
312206ms th_a application.cpp:388 handle_block ] Got block #35015 with time 2015-10-06T20:05:12 from network with latency of 207 ms from dele-puppy
315256ms th_a application.cpp:388 handle_block ] Got block #35016 with time 2015-10-06T20:05:15 from network with latency of 257 ms from spartako
318104ms th_a application.cpp:388 handle_block ] Got block #35017 with time 2015-10-06T20:05:18 from network with latency of 105 ms from init4
321369ms th_a application.cpp:388 handle_block ] Got block #35018 with time 2015-10-06T20:05:21 from network with latency of 370 ms from spectral
324104ms th_a application.cpp:388 handle_block ] Got block #35019 with time 2015-10-06T20:05:24 from network with latency of 105 ms from init6
327244ms th_a application.cpp:388 handle_block ] Got block #35020 with time 2015-10-06T20:05:27 from network with latency of 244 ms from roadscape
330276ms th_a application.cpp:388 handle_block ] Got block #35021 with time 2015-10-06T20:05:30 from network with latency of 277 ms from bhuz
333301ms th_a application.cpp:388 handle_block ] Got block #35022 with time 2015-10-06T20:05:33 from network with latency of 302 ms from fox
336305ms th_a application.cpp:388 handle_block ] Got block #35023 with time 2015-10-06T20:05:36 from network with latency of 305 ms from bitcube
339105ms th_a application.cpp:388 handle_block ] Got block #35024 with time 2015-10-06T20:05:39 from network with latency of 105 ms from init5
339274ms th_a application.cpp:518 get_item ] Serving up block #35024
342238ms th_a application.cpp:388 handle_block ] Got block #35025 with time 2015-10-06T20:05:42 from network with latency of 239 ms from in.abit
-
Please vote for "pmc" (1.6.22). Thanks!
-
I've missed every block so far. Could it be a network latency issue, or is is about what most of you are seeing?
312206ms th_a application.cpp:388 handle_block ] Got block #35015 with time 2015-10-06T20:05:12 from network with latency of 207 ms from dele-puppy
315256ms th_a application.cpp:388 handle_block ] Got block #35016 with time 2015-10-06T20:05:15 from network with latency of 257 ms from spartako
318104ms th_a application.cpp:388 handle_block ] Got block #35017 with time 2015-10-06T20:05:18 from network with latency of 105 ms from init4
321369ms th_a application.cpp:388 handle_block ] Got block #35018 with time 2015-10-06T20:05:21 from network with latency of 370 ms from spectral
324104ms th_a application.cpp:388 handle_block ] Got block #35019 with time 2015-10-06T20:05:24 from network with latency of 105 ms from init6
327244ms th_a application.cpp:388 handle_block ] Got block #35020 with time 2015-10-06T20:05:27 from network with latency of 244 ms from roadscape
330276ms th_a application.cpp:388 handle_block ] Got block #35021 with time 2015-10-06T20:05:30 from network with latency of 277 ms from bhuz
333301ms th_a application.cpp:388 handle_block ] Got block #35022 with time 2015-10-06T20:05:33 from network with latency of 302 ms from fox
336305ms th_a application.cpp:388 handle_block ] Got block #35023 with time 2015-10-06T20:05:36 from network with latency of 305 ms from bitcube
339105ms th_a application.cpp:388 handle_block ] Got block #35024 with time 2015-10-06T20:05:39 from network with latency of 105 ms from init5
339274ms th_a application.cpp:518 get_item ] Serving up block #35024
342238ms th_a application.cpp:388 handle_block ] Got block #35025 with time 2015-10-06T20:05:42 from network with latency of 239 ms from in.abit
get_witness delegate.verbaltech shows missed blocks?
have you started the witness with --witness-id '"your_id"' --private-key '["signing_key","private_key"]' ?
-
I've missed every block so far. Could it be a network latency issue, or is is about what most of you are seeing?
That does not seem normal. I currently have 0 missed blocks. Did you start up the witness with the correct witness ID and keys in the ini file?
Edit: Or, what Bhuz wrote.
-
triox-delegate requesting core asset for registration.
4core/16GB/120GB SSD physical rig.
-
I stopped the witness_node with ^C, waited for it to shut down, checked the config.ini and it was empty. I copied the correct one into the /home/admin/BitShares2 folder and restarted with the exact same cmd line. If failed. I restarted a second time, this time tacking on a --replay-blockchain. When it got to 96% complete it detected a black swan and died:
admin@seed06:~/.BitShares2_build/programs/witness_node$ ./witness_node --rpc-endpoint ""127.0.0.1:8090" --genesis-json oct5-genesis.json -d /home/admin/BitShares2 -s "104.236.51.238:2005" --replay-blockchain
918602ms th_a witness.cpp:83 plugin_initialize ] witness plugin: plugin_initialize(begin 918616ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH6oUevPDj52$
K67E199jBAMBuh6CQBQGgkyLtoXKiAvTVCpvYU7","5KJQMshbWeKadB4uxpxtbH7qZL7nSgtLhsARUbciP13TLo4Enux"]
918617ms th_a witness.cpp:111 plugin_initialize ] witness plugin: plugin_initialize(end
918619ms th_a application.cpp:296 startup ] Replaying blockchain on user reques.
918619ms th_a application.cpp:242 operator() ] Initializing database...
1018360ms th_a db_management.cpp:45 reindex ] reindexing blockchain
1018391ms th_a db_management.cpp:98 wipe ] Wiping database
1018658ms th_a object_database.cpp:81 wipe ] Wiping object_database.
1077220ms th_a db_debug.cpp:79 debug_dump ] total_balances[asset_id_type()].value: 14239376866944 core_asset_data.current_supply.value: 271289987694689
1077220ms th_a db_debug.cpp:82 debug_dump ] core_in_orders: 14239376866944 reported_core_in_orders: 14239376866944
1077336ms th_a db_management.cpp:147 open ] last_block->id(): 000088fb03959ca7ebdcaf0b0063934b15bb64d last_block->block_num(): 35067
1077337ms th_a db_management.cpp:59 reindex ] Replaying blocks...
1078422ms th_a db_maint.cpp:153 update_active_witnes ] wits.size(): 11 witness_count*2+1: 1
1079155ms th_a db_maint.cpp:153 update_active_witnes ] wits.size(): 11 witness_count*2+1: 1
1080589ms th_a db_maint.cpp:153 update_active_witnes ] wits.size(): 11 witness_count*2+1: 1
5.70337% 2000 of 35067
1082433ms th_a db_maint.cpp:153 update_active_witnes ] wits.size(): 11 witness_count*2+1: 1
1084996ms th_a db_maint.cpp:153 update_active_witnes ] wits.size(): 11 witness_count*2+1: 1
11.4067% 4000 of 35067
1086057ms th_a db_maint.cpp:153 update_active_witnes ] wits.size(): 13 witness_count*2+1: 13
1087364ms th_a db_maint.cpp:153 update_active_witnes ] wits.size(): 15 witness_count*2+1: 15
17.1101% 6000 of 35067
1195306ms th_a db_maint.cpp:153 update_active_witnes ] wits.size(): 29 witness_count*2+1: 29
...
96.9573% 34000 of 35067
1195823ms th_a db_update.cpp:241 check_for_blackswan ] Black Swan detected:
Least collateralized call: 759.92759999999998399 0.00131591483188662
Settle Price: 0.00414700000000000 241.13817217265491877
Max: 0.00414700000000000 241.13817217265491877
1197847ms th_a db_maint.cpp:153 update_active_witnes ] wits.size(): 31 witness_count*2+1: 31
1198184ms th_a db_management.cpp:93 reindex ] Done reindexing, elapsed time: 120.84660200000000430 sec
1198399ms th_a thread.cpp:95 thread ] name:ntp tid:140590755026688
1198400ms th_a thread.cpp:95 thread ] name:p2p tid:140590736144128
1198649ms th_a application.cpp:122 reset_p2p_node ] Adding seed node 104.236.51.238:2005
1198680ms th_a application.cpp:122 reset_p2p_node ] Adding seed node 104.236.51.238:2005
1198688ms th_a application.cpp:337 startup ] 90003 already_connected_to_requested_peer: already connected to requested peer
Trying to figure out out why it won't restart...
-
I just added you a second before you checked :) Wait 20 minutes for the next vote counting.
Can you add bitshares-argentina? "id": "1.6.37".
Thanks.
-
get_witness delegate.verbaltech shows missed blocks?
have you started the witness with --witness-id '"your_id"' --private-key '["signing_key","private_key"]' ?
I put as many parameters in the config.ini as I can. I used the exact same command line as before, when there was an empty config.ini, which explains why I was missing blocks.
I will try to restart, this time removing the cmd line params (like seed node) which are in the config. The witness_node apparently doesn't need a chainID, only the cli_wallet?
Looks like I'm producing blocks now. I guess the witness_node got confused with duplicate parameters on the command line AND in the config.ini file.
So my command line is simply: ./witness_node -d /home/admin/BitShares2
-
The witness_node apparently doesn't need a chainID, only the cli_wallet?
witness_node needs --jenesis-json
cli_wallet needs --chain-id
-
triox-delegate requesting core asset for registration.
4core/16GB/120GB SSD physical rig.
transfer spectral triox-delegate 20000 CORE "nice specs" true
{
"ref_block_num": 35854,
For some reason a subsequent call to the 'get_account_history' function returns some errors concerning the memo... is this normal?
get_account_history spectral 100
3353392ms th_a wallet.cpp:2321 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k not in this wallet.
{"k":"GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k"}
th_a wallet.cpp:2314 operator()
3353410ms th_a wallet.cpp:2321 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw not in this wallet.
{"k":"GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw"}
th_a wallet.cpp:2314 operator()
3353416ms th_a wallet.cpp:2321 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k not in this wallet.
{"k":"GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k"}
th_a wallet.cpp:2314 operator()
3353443ms th_a wallet.cpp:2321 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw not in this wallet.
{"k":"GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw"}
th_a wallet.cpp:2314 operator()
-
Is your wallet unlocked when you make those calls?
-
Participation has dropped to 50% and all init witnesses stopped producing blocks.
-
Is normal that publishing feeds consist in 4 asset_publish_feed_operation ?
Why 4?
-
Is your wallet unlocked when you make those calls?
Good question. I think it must have been unlocked, because I made the call right after the transfer, otherwise I would get an error message on the transfer call?
It seems that the issue is repeatable, I am making the call right now and getting the same output:
unlocked >>> get_account_history spectral 100
get_account_history spectral 100
2174484ms th_a wallet.cpp:2321 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k not in this wallet.
{"k":"GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k"}
th_a wallet.cpp:2314 operator()
2174502ms th_a wallet.cpp:2321 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw not in this wallet.
{"k":"GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw"}
th_a wallet.cpp:2314 operator()
2174515ms th_a wallet.cpp:2321 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k not in this wallet.
{"k":"GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k"}
th_a wallet.cpp:2314 operator()
2174545ms th_a wallet.cpp:2321 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw not in this wallet.
{"k":"GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw"}
th_a wallet.cpp:2314 operator()
2015-10-06T21:24:00 asset_publish_feed_operation spectral fee: 1 CORE
2015-10-06T21:24:00 asset_publish_feed_operation spectral fee: 1 CORE
2015-10-06T21:24:00 asset_publish_feed_operation spectral fee: 1 CORE
2015-10-06T21:24:00 asset_publish_feed_operation spectral fee: 1 CORE
2015-10-06T20:51:09 Transfer 20000 CORE from spectral to triox-delegate -- could not decrypt memo (Fee: 20.89843 CORE)
It would be interesting to know if the transfer went through, and the account history from triox-delegate. Maybe I've messed up something...
I made a test transfer to you Dan, with the following output:
transfer spectral dan 10 CORE "testmessage" true
{
"ref_block_num": 36654,
"ref_block_prefix": 724632219,
and the same problem in the account history, I can't decrypt the memo.
get_account_history spectral 100
2535952ms th_a wallet.cpp:2321 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH8JvEXv853AzosCgJEpHLDreNG3pDwr9uxYeA86cL587ooKLmJG not in this wallet.
{"k":"GPH8JvEXv853AzosCgJEpHLDreNG3pDwr9uxYeA86cL587ooKLmJG"}
th_a wallet.cpp:2314 operator()
2535956ms th_a wallet.cpp:2321 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k not in this wallet.
{"k":"GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k"}
th_a wallet.cpp:2314 operator()
2535972ms th_a wallet.cpp:2321 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw not in this wallet.
{"k":"GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw"}
th_a wallet.cpp:2314 operator()
2535981ms th_a wallet.cpp:2321 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH8JvEXv853AzosCgJEpHLDreNG3pDwr9uxYeA86cL587ooKLmJG not in this wallet.
{"k":"GPH8JvEXv853AzosCgJEpHLDreNG3pDwr9uxYeA86cL587ooKLmJG"}
th_a wallet.cpp:2314 operator()
2535987ms th_a wallet.cpp:2321 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k not in this wallet.
{"k":"GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k"}
th_a wallet.cpp:2314 operator()
2536015ms th_a wallet.cpp:2321 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw not in this wallet.
{"k":"GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw"}
th_a wallet.cpp:2314 operator()
2015-10-06T21:41:36 Transfer 10 CORE from spectral to dan -- could not decrypt memo (Fee: 20.89843 CORE)
2015-10-06T21:24:00 asset_publish_feed_operation spectral fee: 1 CORE
2015-10-06T21:24:00 asset_publish_feed_operation spectral fee: 1 CORE
2015-10-06T21:24:00 asset_publish_feed_operation spectral fee: 1 CORE
2015-10-06T21:24:00 asset_publish_feed_operation spectral fee: 1 CORE
2015-10-06T20:51:09 Transfer 20000 CORE from spectral to triox-delegate -- could not decrypt memo (Fee: 20.89843 CORE)
Additional information: I also tried publishing a price feed through xeroc's script and that returned no error message.
And witness shows no missed blocks.
-
My witness started to missing blocks and give this errors....resyncing
3291849ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 00008eb6eadbeb4a8ddf3f411786e9e7750c9d0b,
36534
3291850ms th_a fork_database.cpp:58 push_block ] Head: 36713, 00008f69e3262839ea3e10cdda6e40e0f2286dcc
3291850ms th_a application.cpp:416 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:79 _push_block
{"new_block":{"previous":"00008eb5f524cc47c58abeb93f70252edf73e288","timestamp":"2015-10-06T21:28:09","witness":"1.6.33","transaction_merkle_root":"0f95eeb9a1b32e56
1ca3b3212f438f0e9b0377cc","extensions":[],"witness_signature":"1f27a9b5176289037cd61d42f071b7e35a0a89abf8e5e524c876dd7e22e4486be73ec05247429c38578b4907f8fd4d5695d1590e2
1fb9aaeea0470b6a1cc9ba841","transactions":[{"ref_block_num":36528,"ref_block_prefix":3755663456,"expiration":"2015-10-06T21:28:12","operations":[[33,{"fee":{"amount":10
0000,"asset_id":"1.3.0"},"vesting_balance":"1.13.13","owner":"1.2.17269","amount":{"amount":"40000000000","asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f2c7956
9ddd9f2c819fef84d04722eb59e958ad5e3f7d91fdcdbe8ec2329a0eb52896e1817deb0b414e79bd83f33a17d7afdc9e45da89d5f04a1f365cfeb33517"],"operation_results":[[0,{}]]}]}}
th_a db_block.cpp:195 _push_block
-
I'm in sync now even if I see this error:
3456827ms th_a application.cpp:419 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
item->num > std::max<int64_t>( 0, int64_t(_head->num) - (_max_size) ): attempting to push a block that is too old
{"item->num":36717,"head":36876,"max_size":33}
th_a fork_database.cpp:71 _push_block
{"new_block":{"previous":"00008f6c7b1e63e5645dc3ea16cdc146c87a53ae","timestamp":"2015-10-06T21:57:36","witness":"1.6.12","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"204d32a97bff59567fcc5b585ae7ef777115f245fbb6fa9e28e8a475c705cf0e8b17d942f9065ff9d262afead638e8bc77f7bc732f0e3fc1f618193ce16928ea66","transactions":[]}}
th_a db_block.cpp:195 _push_block
-
3456827ms th_a application.cpp:419 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
item->num > std::max<int64_t>( 0, int64_t(_head->num) - (_max_size) ): attempting to push a block that is too old
{"item->num":36717,"head":36876,"max_size":33}
th_a fork_database.cpp:71 _push_block
{"new_block":{"previous":"00008f6c7b1e63e5645dc3ea16cdc146c87a53ae","timestamp":"2015-10-06T21:57:36","witness":"1.6.12","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"204d32a97bff59567fcc5b585ae7ef777115f245fbb6fa9e28e8a475c705cf0e8b17d942f9065ff9d262afead638e8bc77f7bc732f0e3fc1f618193ce16928ea66","transactions":[]}}
th_a db_block.cpp:195 _push_block
Got that error too
Getting also some Switching to fork like
546364ms th_a db_block.cpp:134 _push_block ] Switching to fork: 000090d3acad2d699b38e6f161be0ad42c3c4a99
-
Next small test in 15 min (22:25 UTC). 30 TPS for 1 hour.
-
I have been borrowing assets starting with 1000 CORE as collateral but then lowering till 0 and finally a blackswan event triggered.
borrow_asset delmoro 1 CNY 0.0000 true
(This actually works)
787848ms th_a db_update.cpp:241 check_for_blackswan ] Black Swan detected:
Least collateralized call: 0.10109393536387817 9.89179020878545856
Settle Price: 0.00316518505364101 315.93729372937292510
Max: 0.00316518505364101 315.93729372937292510
@bytemaster
-
Is your wallet unlocked when you make those calls?
Good question. I think it must have been unlocked, because I made the call right after the transfer, otherwise I would get an error message on the transfer call?
@bytemaster. Another piece of info: I just remembered that recently, before this whole mess, I made a transfer call where I reversed the parameters, so that I did
transfer 20000 CORE <from> <to> "memo"
and it returned an ugly error message that I didn't log. I don't know if this might have influenced the wallet state. Is there a way to check if the wallet or keys have become corrupted somehow?
-
2015-10-06T20:51:09 Transfer 20000 CORE from spectral to triox-delegate -- could not decrypt memo (Fee: 20.89843 CORE)
It would be interesting to know if the transfer went through, and the account history from triox-delegate. Maybe I've messed up something...
2015-10-06T20:51:09 Transfer 20000 CORE from spectral to triox-delegate -- Memo: nice specs (Fee: 20.89843 CORE)
Thanks!
and ready (I believe) to be voted in
"id": "1.6.41",
"witness_account": "1.2.79789",
-
delegate.verbaltech
jtm1
delegate.baozi
roadscape
They showed low performance in generating blocks. (under 20 txs per block).
-
Participation has dropped to 50% and all init witnesses stopped producing blocks.
The init witnesses along with btsnow and a few others went off on a minority fork until I restarted the init witnesses and it rejoined the proper fork.
Upon looking into the issue with Eric (btsnow) we discovered his chain was in an inconsistent state where get_block failed to find random blocks between the last_irreversible_block and the head_block.
The fact that his blockchain was missing blocks in its history meant it was unable to switch back to the proper fork.
It would have been far less dramatic if the init witnesses were not on a single node.
-
Oops... Fund ran out than my expectation :P Anyway it showed stable 30 TPS.
(http://imgur.com/skUHD3S.png)
-
delegate.verbaltech
jtm1
delegate.baozi
roadscape
They showed low performance in generating blocks. (under 20 txs per block).
It may be low-performance in FETCHING transactions which depends upon how far they are from where the transactions are produced.
-
I can't sync with my witness node anymore:
2905588ms th_a application.cpp:865 startup ] 10 assert_exception: Assert Exception
head_block_num() == 0: last block ID does not match current chain state
{}
th_a db_management.cpp:150 open
rethrow
.
.
.
{}
th_a application.cpp:337 startup
2905588ms th_a main.cpp:183 main ] Exiting with error:
10 assert_exception: Assert Exception
head_block_num() == 0: last block ID does not match current chain state
{}
.
.
.
.
rethrow
{}
th_a application.cpp:337 startup
-
I can't sync with my witness node anymore:
2905588ms th_a application.cpp:865 startup ] 10 assert_exception: Assert Exception
head_block_num() == 0: last block ID does not match current chain state
{}
th_a db_management.cpp:150 open
rethrow
.
.
.
{}
th_a application.cpp:337 startup
2905588ms th_a main.cpp:183 main ] Exiting with error:
10 assert_exception: Assert Exception
head_block_num() == 0: last block ID does not match current chain state
{}
.
.
.
.
rethrow
{}
th_a application.cpp:337 startup
remove the witness_node_data_dir and start again
-
remove the witness_node_data_dir and start again
thanks that made the trick ;)
-
remove the witness_node_data_dir and start again
thanks that made the trick ;)
actually it didn't!
I don't see witnesses that produce blocks....
only this....
111446ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
111536ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755","0000250b70b9f0c1937c428ab2fcd26ba874e073","00002512dd3acd6c943530eb77aeb18a22e38da6","0000251685ee39db919acd931bcd8b751c8e43da","0000251846ce0e1e63e924ce8d3540fbce68f26c"]
111542ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
112132ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
112150ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
112197ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
112349ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
112413ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
112974ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
113008ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
113226ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
113250ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755","0000250b70b9f0c1937c428ab2fcd26ba874e073","00002512dd3acd6c943530eb77aeb18a22e38da6","0000251685ee39db919acd931bcd8b751c8e43da","0000251846ce0e1e63e924ce8d3540fbce68f26c"]
113344ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
113688ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
113786ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f
-
BM, I think there are now 3 witnesses waiting to be voted in:
bitshares-argentina
triox-delegate
pmc
-
delegate.verbaltech
jtm1
delegate.baozi
roadscape
They showed low performance in generating blocks. (under 20 txs per block).
It may be low-performance in FETCHING transactions which depends upon how far they are from where the transactions are produced.
Interesting. I've missed 3 blocks in the last hour. The VPS running delegate.verbaltech is located in LA, 4GB RAM dual core, KVM virt.
I just looked at top, see nothing unusual:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9567 admin 20 0 814064 300080 13628 S 9.0 7.4 30:17.59 witness_node
-
All of the latencies are quite high, with only a few slightly less than 300ms, some as high as 690ms.
The specs of this VPS node are pretty good, but I'll try to run the delegate on another host later tonight and we'll see how that looks.
-
Price feeds are now enabled every 15min on witness 'spectral'.
But I'm seeing strange output from the witness-node. I have a ~100K log file here, if that is of interest, @bytemaster
https://drive.google.com/file/d/0BzEEZBS7b6xPSVR5cmpaOXduUzA/view?usp=sharing
Btw, have you guys seen the latencies on the BTS1 network? Up to 10 seconds at worst. Is the network under attack or what's going on?
http://bitsharesblocks.com/delegates (http://bitsharesblocks.com/delegates)
-
All of the latencies are quite high, with only a few slightly less than 300ms, some as high as 690ms.
The specs of this VPS node are pretty good, but I'll try to run the delegate on another host later tonight and we'll see how that looks.
do you have ntp installed?
-
remove the witness_node_data_dir and start again
thanks that made the trick ;)
actually it didn't!
I don't see witnesses that produce blocks....
only this....
111446ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
111536ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755","0000250b70b9f0c1937c428ab2fcd26ba874e073","00002512dd3acd6c943530eb77aeb18a22e38da6","0000251685ee39db919acd931bcd8b751c8e43da","0000251846ce0e1e63e924ce8d3540fbce68f26c"]
111542ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
112132ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
112150ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
112197ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
112349ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
112413ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
112974ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
113008ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
113226ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
113250ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755","0000250b70b9f0c1937c428ab2fcd26ba874e073","00002512dd3acd6c943530eb77aeb18a22e38da6","0000251685ee39db919acd931bcd8b751c8e43da","0000251846ce0e1e63e924ce8d3540fbce68f26c"]
113344ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
113688ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f20f676755"]
113786ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["000024fc0c9cea2edf68e565cafb83f
should I reinstall graphene ?
-
should I reinstall graphene ?
Can you post the complete command line you are using for ./witness_node ...... ?
-
All of the latencies are quite high, with only a few slightly less than 300ms, some as high as 690ms.
The specs of this VPS node are pretty good, but I'll try to run the delegate on another host later tonight and we'll see how that looks.
do you have ntp installed?
Yes, it is.
-
All of the latencies are quite high, with only a few slightly less than 300ms, some as high as 690ms.
The specs of this VPS node are pretty good, but I'll try to run the delegate on another host later tonight and we'll see how that looks.
do you have ntp installed?
Yes, it is.
Do you need another stress test? If so, please let me know your preferred time slot.
-
Lets focus on features and marketing s not perf
Sent from my iPhone using Tapatalk
-
All of the latencies are quite high, with only a few slightly less than 300ms, some as high as 690ms.
The specs of this VPS node are pretty good, but I'll try to run the delegate on another host later tonight and we'll see how that looks.
do you have ntp installed?
Yes, it is.
Do you need another stress test? If so, please let me know your preferred time slot.
What exactly does your stress test do clayop? Does it just flood the network with many transactions in a short period of time?
It's 8:48 here right now. If you want to try at around 9:10 - 9:15 I'll watch. But don't do it on my account only, or if others would prefer to not do it (because it may screw up their testing efforts).
And if nobody objects and you decide to do one then, everybody be forewarned!
-
All of the latencies are quite high, with only a few slightly less than 300ms, some as high as 690ms.
The specs of this VPS node are pretty good, but I'll try to run the delegate on another host later tonight and we'll see how that looks.
do you have ntp installed?
Yes, it is.
Do you need another stress test? If so, please let me know your preferred time slot.
What exactly does your stress test do clayop? Does it just flood the network with many transactions in a short period of time?
It's 8:48 here right now. If you want to try at around 9:10 - 9:15 I'll watch. But don't do it on my account only, or if others would prefer to not do it (because it may screw up their testing efforts).
And if nobody objects and you decide to do one then, everybody be forewarned!
I will start 30 TPS test at 9:15 (your time)
-
Latency numbers have gone up dramatically. Haven't seen any less than 1 second, most are 2- 3 seconds. Highest was 5106 so far.
Worst number come from Bitcube, delegate.btsnow and clayop (of course). Lowest was from lafona at 1047ms.
According to get_witness, I still haven't missed any more blocks for over an hour, probably close to 2 hrs.
-
Latency numbers have gone up dramatically. Haven't seen any less than 1 second, most are 2- 3 seconds. Highest was 5106 so far.
Worst number come from Bitcube, delegate.btsnow and clayop (of course). Lowest was from lafona at 1047ms.
According to get_witness, I still haven't missed any more blocks for over an hour, probably close to 2 hrs.
My server is located in Asia.
-
Not sure what's going on, I see a number of "switching to fork..." not nearly as may latency times from named witnessed (still some) but get_witness still shows only 31 missed blocks. It hasn't gone up.
-
Min is in USA / LA currently. Just missed a block, now at 32. No, now at 35.
Let us know when the test is finished. I suspect it will become obvious, but let us know to confirm.
-
The lowest latency yet is:
2015-10-07T02:39:15 from network with latency of 1001 ms from delegate.baozi
See this from time to time:
2458927ms th_a db_block.cpp:134 _push_block ] Switching to fork: 0000a447
fec2f156319361a2ac76e7675b22e88b
2459085ms th_a witness.cpp:194 block_production_loo ] Not producing block because
node didn't wake up within 500ms of the slot time.
-
When the test started I had a missed block count of 31. After the test I missed a total of 53 blocks or 22 in the hour for an avg of 1 missed block every 16 seconds. I won't be able to test on another VPS tonight, that will have to wait.
OK it's 35 minutes into this test clayop. I have missed an additional 10 blocks in that time. Latencies are still very high. Here is the last report I'll offer:
2647054ms th_a application.cpp:388 handle_block ] Got block #42106 with time
2015-10-07T02:44:03 from network with latency of 4052 ms from init8
2647056ms th_a fork_database.cpp:57 push_block ] Pushing block to fork datab
ase that failed to link: 0000a47a1e4da98d4c9662b2663486cc7e16e88f, 42106
2647057ms th_a fork_database.cpp:58 push_block ] Head: 42104, 0000a47893b182
28040a981ad7b6a7e45cbaa2b5
2647140ms th_a application.cpp:416 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:79 _push_block
{"new_block":{"previous":"0000a47913f78e81d2fb20612724b0b574fa1f73","timestamp":"2015-10-07T02:44
:03","witness":"1.6.9","transaction_merkle_root":"8a517b0dee41247227aa3d66356da3fbf25a6717","extensio
ns":[],"witness_signature":"20679fe2af2e5626a1bd0212841cee73747b36b08e0dad7995b242b242f38013e83aa3091
293bc427b385b884746c269b7b6b7fcf6a3a142111d98869c0f6e575b","transactions":[{"ref_block_num":42104,"re
f_block_prefix":1882093648,"expiration":"2015-10-07T02:44:31","operations":[[1,{"fee":{"amount":50000
0,"asset_id":"1.3.0"},"seller":"1.2.91519","amount_to_sell":{"amount":1,"asset_id":"1.3.570"},"min_to
_receive":{"amount":100000,"asset_id":"1.3.0"},"expiration":"2015-10-07T02:45:37","fill_or_kill":fals
e,"extensions":[]}]],"extensions":[],"signatures":["1f4aa4cf7c25f1a66e49403ee7785575cbc34deb29bca18b8
a099129eb50f3804756c84b90ffb29aafdee075693827782c0069edfa0727ed85e0502c3544d645bc"],"operation_result
s"
-
The test will last an hour
-
it was on around 30tps. +5%
The test will last an hour
-
should I reinstall graphene ?
Can you post the complete command line you are using for ./witness_node ...... ?
./witness_node -d oct5 --genesis-json oct5-genesis.json -s "104.236.51.238:2005"
-
I'm still getting alot of errors in the witness output, but 0 missed blocks on 'get_witness spectral'
Here is some output (see also https://drive.google.com/file/d/0BzEEZBS7b6xPSVR5cmpaOXduUzA/view?usp=sharing (https://drive.google.com/file/d/0BzEEZBS7b6xPSVR5cmpaOXduUzA/view?usp=sharing))
3326001ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
3326003ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 00008eb40c0906ca30d1951c7a5fafa2a14bbb5e, 36532
3326004ms th_a fork_database.cpp:58 push_block ] Head: 37229, 0000916d69b73cf7eafa7dd73a8f3fa4eb828aa2
3326004ms th_a application.cpp:416 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:79 _push_block
{"new_block":{"previous":"00008eb3fb9009a4509dd7c20d0623cc7b6abefb","timestamp":"2015-10-06T21:28:03","witness":"1.6.9","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"2021ea9c0723a65d6870f7e91dfdbafcfb6dbb67bf35e1e3ce7ac2fd6fc52ec36700f1295edc88869525b0c9bfee4bd1b20be52d8c260e3a21b0e66a1f9dfc1789","transactions":[]}}
th_a db_block.cpp:195 _push_block
3326016ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["00008e93a89d2f23dd3c756349ba22f0286add41"]
Should I do something? restart/reinstall?
-
I'm still getting alot of errors in the witness output, but 0 missed blocks on 'get_witness spectral'
Here is some output (see also https://drive.google.com/file/d/0BzEEZBS7b6xPSVR5cmpaOXduUzA/view?usp=sharing (https://drive.google.com/file/d/0BzEEZBS7b6xPSVR5cmpaOXduUzA/view?usp=sharing))
3326001ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
3326003ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 00008eb40c0906ca30d1951c7a5fafa2a14bbb5e, 36532
3326004ms th_a fork_database.cpp:58 push_block ] Head: 37229, 0000916d69b73cf7eafa7dd73a8f3fa4eb828aa2
3326004ms th_a application.cpp:416 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:79 _push_block
{"new_block":{"previous":"00008eb3fb9009a4509dd7c20d0623cc7b6abefb","timestamp":"2015-10-06T21:28:03","witness":"1.6.9","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"2021ea9c0723a65d6870f7e91dfdbafcfb6dbb67bf35e1e3ce7ac2fd6fc52ec36700f1295edc88869525b0c9bfee4bd1b20be52d8c260e3a21b0e66a1f9dfc1789","transactions":[]}}
th_a db_block.cpp:195 _push_block
3326016ms th_a application.cpp:699 get_blockchain_synop ] synopsis: ["00008e93a89d2f23dd3c756349ba22f0286add41"]
Should I do something? restart/reinstall?
have the same problem....
I have deleted "oct5" folder and "object_database" and tried again but same results.... (could it be the router's firewall?)
-
Are yours latency good?
-
have the same problem....
I have deleted "oct5" folder and "object_database" and tried again but same results.... (could it be the router's firewall?)
I think a core dev or someone with intimate insight into the code needs to assess this output, e.g. @bytemaster...
Are yours latency good?
How can I see the latency of my own witness or the others? (see my output, it has no info on that anymore)
-
Woke up this morning to witness not producing blocks. Looks like it might have been on a fork.
2907580ms th_a db_block.cpp:134 _push_block ] Switching to fork: 0000a4ae2e624ed370d37ab44ab50082f5eb9b71
2907585ms th_a application.cpp:419 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
second_branch_itr != _index.get<block_id>().end():
{}
th_a fork_database.cpp:198 fetch_branch_from
{"first":"0000a4ae2e624ed370d37ab44ab50082f5eb9b71","second":"0000a3d3d8e5e0d1f70d13aa2e3f2a3f1574bfa8"}
th_a fork_database.cpp:229 fetch_branch_from
I am currently having trouble getting it sync back up with the chain, I have tried deleting the oct5 and object_database directories and it still seems to get stuck at block 45158. I am uploading the logs to google drive right now and can share the link as soon as they are ready. Is there another seed node up I can try connecting too?
-
Should I do something? restart/reinstall?
Ok, I must have been stuck on a fork. closed the witness node, deleted the object_database and oct5 directories. The witness now starts up and provides normal output.
On calling get_witness it now shows plenty of missed blocks.
get_witness spectral
{
"id": "1.6.38",
"witness_account": "1.2.73210",
"last_aslot": 54941,
"signing_key": "GPH8ZWNd9K82gPqKVDbkK8etaYTBMQ3ME3MTQ6HqF586ZbMLrZ5DH",
"pay_vb": "1.13.64",
"vote_id": "1:49",
"total_votes": "7827836627013",
"url": "bitspace.no",
"total_missed": 507,
"last_confirmed_block_num": 51294
}
Don't take this the wrong way, I'm certainly not complaining, but anyone on the proper chain could've easily checked that calling get_witness on spectral. So I guess I should have asked someone to check that. Something to remember for later.
-
Woke up this morning to witness not producing blocks. Looks like it might have been on a fork.
2907580ms th_a db_block.cpp:134 _push_block ] Switching to fork: 0000a4ae2e624ed370d37ab44ab50082f5eb9b71
2907585ms th_a application.cpp:419 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
second_branch_itr != _index.get<block_id>().end():
{}
th_a fork_database.cpp:198 fetch_branch_from
{"first":"0000a4ae2e624ed370d37ab44ab50082f5eb9b71","second":"0000a3d3d8e5e0d1f70d13aa2e3f2a3f1574bfa8"}
th_a fork_database.cpp:229 fetch_branch_from
I am currently having trouble getting it sync back up with the chain, I have tried deleting the oct5 and object_database directories and it still seems to get stuck at block 45158. I am uploading the logs to google drive right now and can share the link as soon as they are ready. Is there another seed node up I can try connecting too?
I am in the same state. My nodes are unable to --resync-blockchain beyond block 45158 using seed node "104.236.51.238:2005"
-
Don't take this the wrong way, I'm certainly not complaining, but anyone on the proper chain could've easily checked that calling get_witness on spectral. So I guess I should have asked someone to check that. Something to remember for later.
Sorry but I am new to all these and didn't think to check that
I am in the same state. My nodes are unable to --resync-blockchain beyond block 45158 using seed node "104.236.51.238:2005"
You are keep missing blocks
Have you deleted the object_database and oct5 directories as Spectral did?
-
If you are are seeing very high latency try restarting your witness to see if it lowers your latency.
-
just checked again and it is now synced up with the network. I didn't change anything though...
-
If you are are seeing very high latency try restarting your witness to see if it lowers your latency.
How can I see my own latency?
-
How can I see my own latency?
On the witness_node you should see at the end of the Got block line
for example:
2796111ms th_a application.cpp:388 handle_block ] Got block #53313 with time 2015-10-07T12:46:36 from network with latency of 110 ms from init9
2799000ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
2799568ms th_a application.cpp:388 handle_block ] Got block #53314 with time 2015-10-07T12:46:39 from network with latency of 567 ms from in.abit
2802000ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
2802111ms th_a application.cpp:388 handle_block ] Got block #53315 with time 2015-10-07T12:46:42 from network with latency of 109 ms from init4
-
How can I see my own latency?
On the witness_node you should see at the end of the Got block line
for example:
2796111ms th_a application.cpp:388 handle_block ] Got block #53313 with time 2015-10-07T12:46:36 from network with latency of 110 ms from init9
2799000ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
2799568ms th_a application.cpp:388 handle_block ] Got block #53314 with time 2015-10-07T12:46:39 from network with latency of 567 ms from in.abit
2802000ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
2802111ms th_a application.cpp:388 handle_block ] Got block #53315 with time 2015-10-07T12:46:42 from network with latency of 109 ms from init4
Is that my own witness latency? I thought that was the latency of the others.
Or maybe it is composite latency...
-
If you are are seeing very high latency try restarting your witness to see if it lowers your latency.
it may be caused by network resource limitations. I had same problem while using home internet from bell and getting much better after moving my server to hosting data center
-
bitshares-argentina can you please let me know if you have changed your software in any way because it appears your node is consistently producing blocks even though you are not in the set of active witnesses.
Everyone else, please update your witness to the latest master before block 58500 (about 4 hours).
-
Have you deleted the object_database and oct5 directories as Spectral did?
Historically all that I have done is issue --resync-blockchain and the witness connects to the seed(s) to rebuild the chain. Upon witeness startup the console logs:
483498ms th_a witness.cpp:111 plugin_initialize ] witness plugin: plugin_initialize() end
483500ms th_a db_management.cpp:98 wipe ] Wiping database
483513ms th_a object_database.cpp:81 wipe ] Wiping object_database.
484226ms th_a application.cpp:242 operator() ] Initializing database...
However, "Wiping object_database" does not seem to be occurring as expected, as the witness was unable to get blocks beyond 45158.
I did take the advise to manually remove both the object_database and data_dir directories from the witness, leaving only the genesis.json file. This of course forces the node to start from a clean state. This resulted in a proper sync to the main chain.
This seems like a bug to me, but will defer to development to review if that is as designed functionality. If so, please advise what the best practice is to force the witness to start from a clean state using command line options, as I'd rather not script from shell.
Best,
Fox
-
Everyone else, please update your witness to the latest master before block 58500 (about 4 hours).
Can someone please tell me how to update the witness without stop it?
Can I copy the current "graphene" folder, rename it to "current-graphene", update the copied "graphene", restart the witness in this new folder?
Do I have to use update_witness when launching the updated one? How does it works?
Thanks xD
-
bitshares-argentina can you please let me know if you have changed your software in any way because it appears your node is consistently producing blocks even though you are not in the set of active witnesses.
Everyone else, please update your witness to the latest master before block 58500 (about 4 hours).
spartako updated to the lastest master
-
spectral updated to latest master
366235ms th_a application.cpp:388 handle_block ] Got block #54845 with time 2015-10-07T14:06:06 from network with latency of 236 ms from init1
369000ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
369181ms th_a application.cpp:388 handle_block ] Got block #54846 with time 2015-10-07T14:06:09 from network with latency of 182 ms from init10
375000ms th_a witness.cpp:176 block_production_loo ] Generated block #54848 with timestamp 2015-10-07T14:06:15 at time 2015-10-07T14:06:15
375031ms th_a application.cpp:518 get_item ] Serving up block #54848
375034ms th_a application.cpp:518 get_item ] Serving up block #54848
375037ms th_a application.cpp:518 get_item ] Serving up block #54848
375039ms th_a application.cpp:518 get_item ] Serving up block #54848
375040ms th_a application.cpp:518 get_item ] Serving up block #54848
375042ms th_a application.cpp:518 get_item ] Serving up block #54848
375043ms th_a application.cpp:518 get_item ] Serving up block #54848
375044ms th_a application.cpp:518 get_item ] Serving up block #54848
375045ms th_a application.cpp:518 get_item ] Serving up block #54848
375047ms th_a application.cpp:518 get_item ] Serving up block #54848
375049ms th_a application.cpp:518 get_item ] Serving up block #54848
375086ms th_a application.cpp:518 get_item ] Serving up block #54848
375109ms th_a application.cpp:518 get_item ] Serving up block #54848
375110ms th_a application.cpp:518 get_item ] Serving up block #54848
375127ms th_a application.cpp:518 get_item ] Serving up block #54848
375141ms th_a application.cpp:518 get_item ] Serving up block #54848
375141ms th_a application.cpp:518 get_item ] Serving up block #54848
375143ms th_a application.cpp:518 get_item ] Serving up block #54848
375147ms th_a application.cpp:518 get_item ] Serving up block #54848
375192ms th_a application.cpp:518 get_item ] Serving up block #54848
375209ms th_a application.cpp:518 get_item ] Serving up block #54848
375214ms th_a application.cpp:518 get_item ] Serving up block #54848
375220ms th_a application.cpp:518 get_item ] Serving up block #54848
375248ms th_a application.cpp:518 get_item ] Serving up block #54848
375289ms th_a application.cpp:518 get_item ] Serving up block #54848
375290ms th_a application.cpp:518 get_item ] Serving up block #54848
375350ms th_a application.cpp:518 get_item ] Serving up block #54848
375600ms th_a application.cpp:518 get_item ] Serving up block #54848
375840ms th_a application.cpp:518 get_item ] Serving up block #54848
378000ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
378179ms th_a application.cpp:388 handle_block ] Got block #54849 with time 2015-10-07T14:06:18 from network with latency of 180 ms from init5
381000ms th_a witness.cpp:182 block_production_loo ] Not producing block because it isn't my turn
And I have a few of questions concerning this output:
1. Is it normal that serving up block is repeated so many times, and is that the output indicating that my witness is producing a block?
2. How can I check if my feeds are transacted correctly?
3. Can somebody check how my latency is doing compared to other witnesses?
-
Witness mindphlux.witness has been updated to latest master.
-
bue is updating
-
[...]
Everyone else, please update your witness to the latest master before block 58500 (about 4 hours).
Update complete:
cd ~/graphene
git checkout master
git pull
git submodule update --init --recursive --force
#cmake -DCMAKE_BUILD_TYPE=Debug .
cmake -D CMAKE_BUILD_TYPE=Release .
make -j4
-
How so many witnesses are not online。That seems not to be good.
-
It seems init* are down
-
Everyone else, please update your witness to the latest master before block 58500 (about 4 hours).
Can someone please tell me how to update the witness without stop it?
Can I copy the current "graphene" folder, rename it to "current-graphene", update the copied "graphene", restart the witness in this new folder?
Do I have to use update_witness when launching the updated one? How does it works?
Thanks xD
I've used a few different strategies. Most often what I have done is
1) build a fresh build on a different box.
2) get it set up and running with a secondary public private key pair (more on this below)
3) switch block production to this second key pair
4) build on my main box and restart witness node
5) switch block production back.
This time I am trying something new. I have created a secondary build directory on my main box and have launched a second witness_node running with a secondary key pair. Once the build is complete on the local box that has all of my balances I will switch over production, shut down the first build, and rebuild it.
In order to switch between witnesses you will need at least two sets of public private key pairs. You can generate these key pairs with the wallet command suggest_brain_keyI recommend saving the output of that command to a file so you can reference it later. On your secondary box you will replace the current active public private key pair, with this new public private key pair. I suggest doing this in the config.ini, but you can also do it all in command line. Once both boxes are up and running with different key pairs, you can switch between them with the wallet command
update_witness <witness_account> <url> <public key> true
you should be able to use "" if you want an empty url.
Hope this cleared things up and didn't just confuse you further.
-
1. Is it normal that serving up block is repeated so many times, and is that the output indicating that my witness is producing a block?
Yes, and sort of. "Serving up block" just means you are telling other p2p nodes about a block. You should get one for every node you're connected to when you produce a block (because none of them know about your shiny new block until you tell them), so you'll see a bunch of them when you produce. But you'll also get a few of them for every block you see -- all that means is you heard about some block before some of your peers, so you get to be the one to tell those peers about the block. You might even see a large number of consecutively numbered "serving up block" messages for a bunch of blocks in the past, if a peer is syncing from you.
None of this matters if you build from 8e96d9c89cd24a733d4838901f781af0315ec667 or later, as the "serving up block" message is removed (it is sort of spammy and not all that informative).
2. How can I check if my feeds are transacted correctly?
For now, use your account history at https://graphene.bitshares.org/#/account/spectral/overview
If you are using the CLI wallet, you can do
get_account_history spectral 10
-
wackou updated to latest master
-
jtm1 updated
-
bitcube is updated to master.
-
roadscape updated to master
-
wintness 'delegate.ihashfury' and nodes - updated to latest master
-
The most recent master has a fix for failure to switch to the proper fork. We are resolving a few other issues so there may be additional updates.
My apologies for the rapid fixes.
-
It is appraching midnight (and bedtime) here in asia. I hope I am not going to miss any update.
-
My apologies for the rapid fixes.
Wait .. what ???
-
I have switched to a fork after update to master
-
I have switched to a fork after update to master
I realised I went into a fork too. I am trying to resync.
Edit: resynced.
-
dele-puppy is now fully updated.
-
spartako updated to last master
-
bue updated to last master
-
get back after update to the latest master
I have switched to a fork after update to master
I realised I went into a fork too. I am trying to resync.
Edit: resynced.
-
elmato updated to master.
-
Everyone else, please update your witness to the latest master before block 58500 (about 4 hours).
Can someone please tell me how to update the witness without stop it?
Can I copy the current "graphene" folder, rename it to "current-graphene", update the copied "graphene", restart the witness in this new folder?
Do I have to use update_witness when launching the updated one? How does it works?
Thanks xD
I've used a few different strategies. Most often what I have done is
1) build a fresh build on a different box.
2) get it set up and running with a secondary public private key pair (more on this below)
3) switch block production to this second key pair
4) build on my main box and restart witness node
5) switch block production back.
This time I am trying something new. I have created a secondary build directory on my main box and have launched a second witness_node running with a secondary key pair. Once the build is complete on the local box that has all of my balances I will switch over production, shut down the first build, and rebuild it.
In order to switch between witnesses you will need at least two sets of public private key pairs. You can generate these key pairs with the wallet command suggest_brain_keyI recommend saving the output of that command to a file so you can reference it later. On your secondary box you will replace the current active public private key pair, with this new public private key pair. I suggest doing this in the config.ini, but you can also do it all in command line. Once both boxes are up and running with different key pairs, you can switch between them with the wallet command
update_witness <witness_account> <url> <public key> true
you should be able to use "" if you want an empty url.
Hope this cleared things up and didn't just confuse you further.
I am running on a different VPS today, and I tried to start it using the above as a guide. From the looks of things I wasn't successful, as I see errors pushing blocks.
What I was unclear of is which node should the update_witness cmd be run on, the old chain or the new one?
I was running the cli directly in the bin folder so my trouble may be the wallet. I copied the wallet.json and one other file (it was created on the 5th) to the new VPS and used -w and the other file to launch the cli. When I started the cli it opened with correct password and get_witness agreeed with the same command on the old VPS.
Anyway I'm stopping the witness as it doesn't seem to be working. Before I do I will revert to the old keys, if possible. I may have to restart the old witness to do that.
-
How do I withdraw the vested balance for my witness?
The command below seems to work but I'm not seeing those 1000 CORE on any account. What am I doing wrong?
unlocked >>> withdraw_vesting mindphlux.witness 1000 CORE true
withdraw_vesting mindphlux.witness 1000 CORE true
{
"ref_block_num": 57826,
"ref_block_prefix": 1642589200,
"expiration": "2015-10-07T17:01:39",
"operations": [[
33,{
"fee": {
"amount": 100000,
"asset_id": "1.3.0"
},
"vesting_balance": "1.13.41",
"owner": "1.2.91505",
"amount": {
"amount": 100000000,
"asset_id": "1.3.0"
}
}
]
],
"extensions": [],
"signatures": [
"1f578fe8df3796f443b969aaa2c2d4502d48df14b132676e29b95721fc50c2a35455745a743e388aec7fbff4b8ac1565ca6f034047b67c4889342d1a74650008f8"
]
}
-
xeldal is updated to master
-
delegate.verbaltech is updated to master, running on a vew VPS and a new signing key in Singnapore. Current missed block count is 98. See lots of errors pushing blocks, but mu missed block count is not going up.
I've gotta run to an appointment now tho, so hopefully it's working as it should.
BTW, what's that msg about updating the date on the genesis.json all about?
-
@puppies Thank you so much!
bhuz running on latest master
-
mr.agsexplorer is updated to latest master, needs to be voted in, @bytemaster
-
upgrade latest, need votes :D
-
updated (observer) witness_node to latest.
-
I am getting this sometimes
3033114ms th_a db_block.cpp:191 _push_block ] Failed to push new block:
10 assert_exception: Assert Exception
next_block.witness == scheduled_witness: Witness produced block at wrong time
{"block witness":"1.6.37","scheduled":"1.6.24","slot_num":1}
th_a db_block.cpp:646 validate_block_header
{"next_block.block_num()":58718}
th_a db_block.cpp:511 _apply_block
3033116ms th_a application.cpp:425 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
next_block.witness == scheduled_witness: Witness produced block at wrong time
{"block witness":"1.6.37","scheduled":"1.6.24","slot_num":1}
th_a db_block.cpp:646 validate_block_header
{"next_block.block_num()":58718}
th_a db_block.cpp:511 _apply_block
{"new_block":{"previous":"0000e55de39c07283d1779c89018c18206bfa9f2","timestamp":"2015-10-07T17:50:33","witness":"1.6.37","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f19b73fc82aa7519e28f34b1f8e10f63da27365c8e5699fd9f77c0ee1f4c4b02841560af821e3ec8e71f72264934140c7fb2cdd78e0f91920edc7b8cba9c33cfb","transactions":[]}}
th_a db_block.cpp:197 _push_block
-
I am getting this sometimes
3033114ms th_a db_block.cpp:191 _push_block ] Failed to push new block:
10 assert_exception: Assert Exception
next_block.witness == scheduled_witness: Witness produced block at wrong time
{"block witness":"1.6.37","scheduled":"1.6.24","slot_num":1}
th_a db_block.cpp:646 validate_block_header
{"next_block.block_num()":58718}
th_a db_block.cpp:511 _apply_block
3033116ms th_a application.cpp:425 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
next_block.witness == scheduled_witness: Witness produced block at wrong time
{"block witness":"1.6.37","scheduled":"1.6.24","slot_num":1}
th_a db_block.cpp:646 validate_block_header
{"next_block.block_num()":58718}
th_a db_block.cpp:511 _apply_block
{"new_block":{"previous":"0000e55de39c07283d1779c89018c18206bfa9f2","timestamp":"2015-10-07T17:50:33","witness":"1.6.37","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f19b73fc82aa7519e28f34b1f8e10f63da27365c8e5699fd9f77c0ee1f4c4b02841560af821e3ec8e71f72264934140c7fb2cdd78e0f91920edc7b8cba9c33cfb","transactions":[]}}
th_a db_block.cpp:197 _push_block
I see the same. Perhaps something wrong wrong 1.6.37.
updated to latest master again (jtm1).
-
I am getting this sometimes
3033114ms th_a db_block.cpp:191 _push_block ] Failed to push new block:
10 assert_exception: Assert Exception
next_block.witness == scheduled_witness: Witness produced block at wrong time
{"block witness":"1.6.37","scheduled":"1.6.24","slot_num":1}
th_a db_block.cpp:646 validate_block_header
{"next_block.block_num()":58718}
th_a db_block.cpp:511 _apply_block
3033116ms th_a application.cpp:425 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
next_block.witness == scheduled_witness: Witness produced block at wrong time
{"block witness":"1.6.37","scheduled":"1.6.24","slot_num":1}
th_a db_block.cpp:646 validate_block_header
{"next_block.block_num()":58718}
th_a db_block.cpp:511 _apply_block
{"new_block":{"previous":"0000e55de39c07283d1779c89018c18206bfa9f2","timestamp":"2015-10-07T17:50:33","witness":"1.6.37","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f19b73fc82aa7519e28f34b1f8e10f63da27365c8e5699fd9f77c0ee1f4c4b02841560af821e3ec8e71f72264934140c7fb2cdd78e0f91920edc7b8cba9c33cfb","transactions":[]}}
th_a db_block.cpp:197 _push_block
I see the same. Perhaps something wrong wrong 1.6.37.
updated to latest master again (jtm1).
This particular witness has been producing blocks at the wrong time this whole time and fortunately helped us identify a bug that we fixed with a hard fork that took effect and is now generating these error messages.
-
Updated.
Is it still the case that "total_votes" shows zero until the candidate is voted in?
-
delegate.verbaltech witness crashed around 12:25 CST, 30 minutes or so after I started it. 98 missed blocks then, 154 now after I just restarted it. Noticed several black swan events and witness producing blocks at the wrong time:
55.24% 32000 of 57929 [445/1942]
58.6925% 34000 of 57929
1777187ms th_a db_update.cpp:241 check_for_blackswan ] Black Swan detected:
Least collateralized call: 759.92759999999998399 0.00131591483188662
Settle Price: 0.00414700000000000 241.13817217265491877
Max: 0.00414700000000000 241.13817217265491877
62.145% 36000 of 57929
1779453ms th_a db_update.cpp:241 check_for_blackswan ] Black Swan detected:
Least collateralized call: 60900.10198737338214414 0.00001642033374932
Settle Price: 0.00003138000000000 31867.43148502230542363
Max: 0.00003138000000000 31867.43148502230542363
65.5975% 38000 of 57929
69.05% 40000 of 57929
72.5025% 42000 of 57929
75.955% 44000 of 57929
79.4076% 46000 of 57929
82.8601% 48000 of 57929
86.3126% 50000 of 57929
1824293ms th_a db_update.cpp:241 check_for_blackswan ] Black Swan detected:
Least collateralized call: 69.44539226603158966 0.01439980346239816
Settle Price: 0.03222000000000000 31.03662321539416524
Max: 0.03222000000000000 31.03662321539416524
Looks pretty stable now tho, no problems since:
2004762ms th_a application.cpp:394 handle_block ] Got block: #59514 time: 201
5-10-07T18:33:24 latency: 768 ms from: delegate.btsnow irreversible: 59492 (-22)
Also noticed this - how can this be correct?:
5-10-07T18:40:51 latency: -23 ms from: bitcube irreversible: 59631 (-26)
2454409ms th_a application.cpp:394 handle_block ] Got block: #59658 time: 201
Latency times are all over the place: -22ms from bitcube, 110ms from clayop, 700ms from init6, 762ms from bitshares-argentina. They do seem to corelate with being in Singnapore tho.
-
BM, I think there are now 3 witnesses waiting to be voted in:
bitshares-argentina
triox-delegate
pmc
Voted. Any others?
-
delegate.verbaltech witness crashed around 12:25 CST, 30 minutes or so after I started it. I just restarted it. Noticed several black swan events and witness producing blocks at the wrong time:
55.24% 32000 of 57929 [445/1942]
58.6925% 34000 of 57929
1777187ms th_a db_update.cpp:241 check_for_blackswan ] Black Swan detected:
Least collateralized call: 759.92759999999998399 0.00131591483188662
Settle Price: 0.00414700000000000 241.13817217265491877
Max: 0.00414700000000000 241.13817217265491877
62.145% 36000 of 57929
1779453ms th_a db_update.cpp:241 check_for_blackswan ] Black Swan detected:
Least collateralized call: 60900.10198737338214414 0.00001642033374932
Settle Price: 0.00003138000000000 31867.43148502230542363
Max: 0.00003138000000000 31867.43148502230542363
65.5975% 38000 of 57929
69.05% 40000 of 57929
72.5025% 42000 of 57929
75.955% 44000 of 57929
79.4076% 46000 of 57929
82.8601% 48000 of 57929
86.3126% 50000 of 57929
1824293ms th_a db_update.cpp:241 check_for_blackswan ] Black Swan detected:
Least collateralized call: 69.44539226603158966 0.01439980346239816
Settle Price: 0.03222000000000000 31.03662321539416524
Max: 0.03222000000000000 31.03662321539416524
Looks pretty stable now tho, no problems since:
2004762ms th_a application.cpp:394 handle_block ] Got block: #59514 time: 201
5-10-07T18:33:24 latency: 768 ms from: delegate.btsnow irreversible: 59492 (-22)
Also noticed this - how can this be correct?:
5-10-07T18:40:51 latency: -23 ms from: bitcube irreversible: 59631 (-26)
2454409ms th_a application.cpp:394 handle_block ] Got block: #59658 time: 201
The accuracy of each individual computers clock can be off by up to 300 ms. It just means that your local clock is ahead of the other peer by 23 ms plus the network latency in fetching the block.
-
are we able to set up a bunch of witnesses with 36 cores (with > 10Mbit/s bandwidth) and test out higher TPS? We can pay $100 for a month for say 17 witnesses for a cost of $1700 to prove to the world we can do 100k TPS on a stable testnet.
-
are we able to set up a bunch of witnesses with 36 cores (with > 10Mbit/s bandwidth) and test out higher TPS? We can pay $100 for a month for say 17 witnesses for a cost of $1700 to prove to the world we can do 100k TPS on a stable testnet.
It isn't just a matter of getting high end servers, we need to actually change the P2P protocol before we can hope to achieve those speeds.
-
pmc updated to latest master.
-
bitshares-argentina can you please let me know if you have changed your software in any way because it appears your node is consistently producing blocks even though you are not in the set of active witnesses.
BM, does this strange event have an explanation now or is it still unclear what happened?
-
bitshares-argentina can you please let me know if you have changed your software in any way because it appears your node is consistently producing blocks even though you are not in the set of active witnesses.
Everyone else, please update your witness to the latest master before block 58500 (about 4 hours).
Hi dan, I didn't change anything. Neither played with uncommon settings as far as I remember .
Running from master branch with last commit db84a492b9a2cf290f92a3987b59c11808138d56
How can I help debugging?
-
The accuracy of each individual computers clock can be off by up to 300 ms. It just means that your local clock is ahead of the other peer by 23 ms plus the network latency in fetching the block.
So there is a margin of error of 300ms in latency numbers?
That makes it pretty tough to get an accurate picture. I thought ntp would take care of that, not so?
-
I am getting this sometimes
3033114ms th_a db_block.cpp:191 _push_block ] Failed to push new block:
10 assert_exception: Assert Exception
next_block.witness == scheduled_witness: Witness produced block at wrong time
{"block witness":"1.6.37","scheduled":"1.6.24","slot_num":1}
th_a db_block.cpp:646 validate_block_header
{"next_block.block_num()":58718}
th_a db_block.cpp:511 _apply_block
3033116ms th_a application.cpp:425 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
next_block.witness == scheduled_witness: Witness produced block at wrong time
{"block witness":"1.6.37","scheduled":"1.6.24","slot_num":1}
th_a db_block.cpp:646 validate_block_header
{"next_block.block_num()":58718}
th_a db_block.cpp:511 _apply_block
{"new_block":{"previous":"0000e55de39c07283d1779c89018c18206bfa9f2","timestamp":"2015-10-07T17:50:33","witness":"1.6.37","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f19b73fc82aa7519e28f34b1f8e10f63da27365c8e5699fd9f77c0ee1f4c4b02841560af821e3ec8e71f72264934140c7fb2cdd78e0f91920edc7b8cba9c33cfb","transactions":[]}}
th_a db_block.cpp:197 _push_block
I see the same. Perhaps something wrong wrong 1.6.37.
updated to latest master again (jtm1).
This particular witness has been producing blocks at the wrong time this whole time and fortunately helped us identify a bug that we fixed with a hard fork that took effect and is now generating these error messages.
@bytemaster let me know if I should update 1.6.37 now or if you need it for debugging
-
This particular witness has been producing blocks at the wrong time this whole time and fortunately helped us identify a bug that we fixed with a hard fork that took effect and is now generating these error messages.
@bytemaster let me know if I should update 1.6.37 now or if you need it for debugging
You should upgrade to the latest master and reindex.
-
BM, I think there are now 3 witnesses waiting to be voted in:
bitshares-argentina
triox-delegate
pmc
Voted. Any others?
betaxtrade (please)
-
The accuracy of each individual computers clock can be off by up to 300 ms. It just means that your local clock is ahead of the other peer by 23 ms plus the network latency in fetching the block.
So there is a margin of error of 300ms in latency numbers?
That makes it pretty tough to get an accurate picture. I thought ntp would take care of that, not so?
The built in NTP client pings an NTP server and updates an internal offset if the delta time between the request and response is less than 300 ms. So if you can ping the NTP server in 0 ms then you can have up to 300 ms in error. If your ping time to the NTP server is 100 ms, then you will only have 200 ms of error.
Technically it is possible to get a more accurate time sync than this.
NTP v4 with kernel mods to support it, is capable of much better than 1ms accuracy, possibly as good as 1ns. According to [Dave Mills] article, NTP v3 is accurate to 1-2ms in a LAN and 10s of ms in WAN nets. http://www.cis.udel.edu/~mills/ntp.html
Other articles suggest that with an accurate time source, such as a GPS time source, NTP is accurate to 50us, but the links on the Linux kernel support say that accuracy of a few ms are possible. http://www.atomic-clock.galleon.eu.com/support/ntp-time-server-accuracy.html
Another article says that it is dependent on the predictability of network delays (i.e. a low jitter network). http://www.postel.org/pipermail/end2end-interest/2003-April/002925.html
In other words, highly paid witnesses could configure their local clocks with higher quality NTP solutions and get down to under 100 ms. It would be a lot of work to get the internal NTP to be more accurate.
-
I see. Thanks for the thorough explanation.
The accuracy of each individual computers clock can be off by up to 300 ms. It just means that your local clock is ahead of the other peer by 23 ms plus the network latency in fetching the block.
So there is a margin of error of 300ms in latency numbers?
That makes it pretty tough to get an accurate picture. I thought ntp would take care of that, not so?
The built in NTP client pings an NTP server and updates an internal offset if the delta time between the request and response is less than 300 ms. So if you can ping the NTP server in 0 ms then you can have up to 300 ms in error. If your ping time to the NTP server is 100 ms, then you will only have 200 ms of error.
Technically it is possible to get a more accurate time sync than this.
NTP v4 with kernel mods to support it, is capable of much better than 1ms accuracy, possibly as good as 1ns. According to [Dave Mills] article, NTP v3 is accurate to 1-2ms in a LAN and 10s of ms in WAN nets. http://www.cis.udel.edu/~mills/ntp.html
Other articles suggest that with an accurate time source, such as a GPS time source, NTP is accurate to 50us, but the links on the Linux kernel support say that accuracy of a few ms are possible. http://www.atomic-clock.galleon.eu.com/support/ntp-time-server-accuracy.html
Another article says that it is dependent on the predictability of network delays (i.e. a low jitter network). http://www.postel.org/pipermail/end2end-interest/2003-April/002925.html
In other words, highly paid witnesses could configure their local clocks with higher quality NTP solutions and get down to under 100 ms. It would be a lot of work to get the internal NTP to be more accurate.
-
Would PTP (http://blog.meinbergglobal.com/2013/11/22/ntp-vs-ptp-network-timing-smackdown/) be a viable option?
-
bitshares-argentina can you please let me know if you have changed your software in any way because it appears your node is consistently producing blocks even though you are not in the set of active witnesses.
Everyone else, please update your witness to the latest master before block 58500 (about 4 hours).
Hi dan, I didn't change anything. Neither played with uncommon settings as far as I remember .
Running from master branch with last commit db84a492b9a2cf290f92a3987b59c11808138d56
How can I help debugging?
Can you post your config file and command line arguments.
-
bitshares-argentina can you please let me know if you have changed your software in any way because it appears your node is consistently producing blocks even though you are not in the set of active witnesses.
Everyone else, please update your witness to the latest master before block 58500 (about 4 hours).
Hi dan, I didn't change anything. Neither played with uncommon settings as far as I remember .
Running from master branch with last commit db84a492b9a2cf290f92a3987b59c11808138d56
How can I help debugging?
Can you post your config file and command line arguments.
./witness_node -d oct5-2 --genesis-json oct5-genesis.json -s "104.236.51.238:2005"
# Enable block production, even if the chain is stale.
enable-stale-production = false
# Percent of witnesses (0-99) that must be participating in order to produce blocks
required-participation = false
# ID of witness controlled by this node (e.g. "1.6.5", quotes are required, may specify multiple times)
witness-id = "1.6.37"
# Tuple of [PublicKey, WIF private key] (may specify multiple times)
private-key = ["GPH7vyDvX1dxcPvXs63A4cctf8ZFRcb7a3QGWoQYdX6ckuKJonbyx","5Kxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"]
updated but not producing blocks. Now when I dump_private_keys there's no priv key for the signing key. I'll try on a new wallet.
-
BM, I think there are now 3 witnesses waiting to be voted in:
bitshares-argentina
triox-delegate
pmc
Voted. Any others?
yep, I think I got voted out by this (had only my votes) 1.6.31
-
It isn't just a matter of getting high end servers, we need to actually change the P2P protocol before we can hope to achieve those speeds.
When you are not busy, could you read my post about witnesses signing blocks in General Discussion?
-
60 TPS / 20 min test will begin at 21:00 UTC
Add: CORE donation to 'clayop' is more than welcome :D
-
60 TPS / 20 min test will begin at 21:00 UTC
Add: CORE donation to 'clayop' is more than welcome :D
Sent you 4000 CORE
-
60 TPS / 20 min test will begin at 21:00 UTC
Add: CORE donation to 'clayop' is more than welcome :D
Oops.... made a mistake. The test will begin at 21:25 UTC. Sorry about that.
Thanks Thom!
-
bitshares-argentina can you please let me know if you have changed your software in any way because it appears your node is consistently producing blocks even though you are not in the set of active witnesses.
Everyone else, please update your witness to the latest master before block 58500 (about 4 hours).
Hi dan, I didn't change anything. Neither played with uncommon settings as far as I remember .
Running from master branch with last commit db84a492b9a2cf290f92a3987b59c11808138d56
How can I help debugging?
Can you post your config file and command line arguments.
It seems to be the same issue with the time:
1272283ms th_a db_block.cpp:189 _push_block ] Failed to push new block:
10 assert_exception: Assert Exception
next_block.witness == scheduled_witness: Witness produced block at wrong time
{"block witness":"1.6.37","scheduled":"1.6.39","slot_num":1}
th_a db_block.cpp:644 validate_block_header
{"next_block.block_num()":62650}
th_a db_block.cpp:509 _apply_block
1272290ms th_a application.cpp:425 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
next_block.witness == scheduled_witness: Witness produced block at wrong time
{"block witness":"1.6.37","scheduled":"1.6.39","slot_num":1}
th_a db_block.cpp:644 validate_block_header
{"next_block.block_num()":62650}
th_a db_block.cpp:509 _apply_block
{"new_block":{"previous":"0000f4b90fc8a15cc975aa571539d3e7f9053b6f","timestamp":"2015-10-07T21:21:12","witness":"1.6.37","transaction_merkle_root":"aa42913b2a226f9132200a3cb19aa076e3c0d7b4","extensions":[],"witness_signature":"20449d3e22302d92dd18f54cd2406de08678774e6648073db27409ea25bdcd4425561a3a7e75a484ee161eab4e02ba806147824747553537ed57c964af3261e330","transactions":[{"ref_block_num":62648,"ref_block_prefix":1109897537,"expiration":"2015-10-07T21:21:36","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":3327214,"asset_id":"1.3.285"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":3327214,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures":["1f3a600a648a94885229e3b4cc91a8f8ea3d6cb368f555bf52ba233a44e648e08170d12c36bca47097846b6cd334c69392bc15a2796d87b620172235bd5bff705c"],"operation_results":[[0,{}]]},{"ref_block_num":62648,"ref_block_prefix":1109897537,"expiration":"2015-10-07T21:21:36","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.218","feed":{"settlement_price":{"base":{"amount":21452528,"asset_id":"1.3.218"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":21452528,"asset_id":"1.3.218"}}},"extensions":[]}]],"extensions":[],"signatures":["1f7e6481ccef5712d331e5613cfa706e4f6821fffd58ab88a3b05a7c1d18b2bda80487e0b2007369d6c10eeb8453f07573717c7cf15f3e5b4d17db45c6347cc49e"],"operation_results":[[0,{}]]},{"ref_block_num":62648,"ref_block_prefix":1109897537,"expiration":"2015-10-07T21:21:36","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.536","feed":{"settlement_price":{"base":{"amount":523393,"asset_id":"1.3.536"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":523393,"asset_id":"1.3.536"}}},"extensions":[]}]],"extensions":[],"signatures":["203cb740ed1f1706d0f0e0b273234fb3902ef987a28271d3005d613a3e9582075a4f1f2010d7ef27af1e2dbc2e78ecded4a66d1f5afb110333fc83eb84b52bccb3"],"operation_results":[[0,{}]]},{"ref_block_num":62648,"ref_block_prefix":1109897537,"expiration":"2015-10-07T21:21:36","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.330","feed":{"settlement_price":{"base":{"amount":465809,"asset_id":"1.3.330"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":465809,"asset_id":"1.3.330"}}},"extensions":[]}]],"extensions":[],"signatures":["1f0e44bd90670d6d35ad25202d54ec45968422d6315db6eb611c785f6dbc9c239d03b1da1049e9f429fce90e6ba6cc3c0e034e2803b04dd76ab72b3d53ad872082"],"operation_results":[[0,{}]]}]}}
th_a db_block.cpp:195 _push_block
plus, mine seem to needed a wipe and resync of the database...
-
It seems that the stress testing is being handled by the witnesses, it is just the UI that has some random freezes.
-
During the stress test, all inits are forked. Are they on the same machine?
-
During the stress test, all inits are forked. Are they on the same machine?
as bytemaster mentioned yesterday, yes.
-
During the stress test, all inits are forked. Are they on the same machine?
as bytemaster mentioned yesterday, yes.
They shouldn't be on the real net :(
-
60 TPS / 20 min test will begin at 21:00 UTC
Add: CORE donation to 'clayop' is more than welcome :D
20000 CORE sent
-
During the stress test, all inits are forked. Are they on the same machine?
as bytemaster mentioned yesterday, yes.
They shouldn't be on the real net :(
Let's see if they manage to come back in as soon as the stress ends :)
-
is the web sockeds backed tcp loadbalanced? how many backend servers are used? To avoid the freezing, if an issue with the backed.
If it is an issue with the frontend can we delay response to the ui, or is it already throtle based on the tps / current screen.
Also I seemed to need to refresh the browser a couple of times to get the latest block whilst doing the load test.
-
During the stress test, all inits are forked. Are they on the same machine?
as bytemaster mentioned yesterday, yes.
They shouldn't be on the real net :(
Let's see if they manage to come back in as soon as the stress ends :)
Wow the network is really resilient. They are coming back.
-
Init witnesses forked because our whole office lost internet connection and not because of the flooding.
That said, they did come back on their own. Yes they are all on one machine.
-
is the web sockeds backed tcp loadbalanced? how many backend servers are used? To avoid the freezing, if an issue with the backed.
If it is an issue with the frontend can we delay response to the ui, or is it already throtle based on the tps / current screen.
Also I seemed to need to refresh the browser a couple of times to get the latest block whilst doing the load test.
Currently the backend pushes ALL state changes to the GUI whether or not the GUI cares about that particular state. This was a shortcut taken to maximize reliability of the front end receiving updates. We already have the filters in place to throttle this back to only the data the GUI has previously requested.
So the GUI infrastructure is not well suited for these flood tests, but is well suited to serving 1000+ simultaneous users at normal transaction volumes.
-
bitshares-argentina can you please let me know if you have changed your software in any way because it appears your node is consistently producing blocks even though you are not in the set of active witnesses.
Everyone else, please update your witness to the latest master before block 58500 (about 4 hours).
Hi dan, I didn't change anything. Neither played with uncommon settings as far as I remember .
Running from master branch with last commit db84a492b9a2cf290f92a3987b59c11808138d56
How can I help debugging?
Can you post your config file and command line arguments.
It seems to be the same issue with the time:
1272283ms th_a db_block.cpp:189 _push_block ] Failed to push new block:
10 assert_exception: Assert Exception
next_block.witness == scheduled_witness: Witness produced block at wrong time
{"block witness":"1.6.37","scheduled":"1.6.39","slot_num":1}
th_a db_block.cpp:644 validate_block_header
{"next_block.block_num()":62650}
th_a db_block.cpp:509 _apply_block
1272290ms th_a application.cpp:425 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
next_block.witness == scheduled_witness: Witness produced block at wrong time
{"block witness":"1.6.37","scheduled":"1.6.39","slot_num":1}
th_a db_block.cpp:644 validate_block_header
{"next_block.block_num()":62650}
th_a db_block.cpp:509 _apply_block
{"new_block":{"previous":"0000f4b90fc8a15cc975aa571539d3e7f9053b6f","timestamp":"2015-10-07T21:21:12","witness":"1.6.37","transaction_merkle_root":"aa42913b2a226f9132200a3cb19aa076e3c0d7b4","extensions":[],"witness_signature":"20449d3e22302d92dd18f54cd2406de08678774e6648073db27409ea25bdcd4425561a3a7e75a484ee161eab4e02ba806147824747553537ed57c964af3261e330","transactions":[{"ref_block_num":62648,"ref_block_prefix":1109897537,"expiration":"2015-10-07T21:21:36","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":3327214,"asset_id":"1.3.285"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":3327214,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures":["1f3a600a648a94885229e3b4cc91a8f8ea3d6cb368f555bf52ba233a44e648e08170d12c36bca47097846b6cd334c69392bc15a2796d87b620172235bd5bff705c"],"operation_results":[[0,{}]]},{"ref_block_num":62648,"ref_block_prefix":1109897537,"expiration":"2015-10-07T21:21:36","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.218","feed":{"settlement_price":{"base":{"amount":21452528,"asset_id":"1.3.218"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":21452528,"asset_id":"1.3.218"}}},"extensions":[]}]],"extensions":[],"signatures":["1f7e6481ccef5712d331e5613cfa706e4f6821fffd58ab88a3b05a7c1d18b2bda80487e0b2007369d6c10eeb8453f07573717c7cf15f3e5b4d17db45c6347cc49e"],"operation_results":[[0,{}]]},{"ref_block_num":62648,"ref_block_prefix":1109897537,"expiration":"2015-10-07T21:21:36","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.536","feed":{"settlement_price":{"base":{"amount":523393,"asset_id":"1.3.536"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":523393,"asset_id":"1.3.536"}}},"extensions":[]}]],"extensions":[],"signatures":["203cb740ed1f1706d0f0e0b273234fb3902ef987a28271d3005d613a3e9582075a4f1f2010d7ef27af1e2dbc2e78ecded4a66d1f5afb110333fc83eb84b52bccb3"],"operation_results":[[0,{}]]},{"ref_block_num":62648,"ref_block_prefix":1109897537,"expiration":"2015-10-07T21:21:36","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.330","feed":{"settlement_price":{"base":{"amount":465809,"asset_id":"1.3.330"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":465809,"asset_id":"1.3.330"}}},"extensions":[]}]],"extensions":[],"signatures":["1f0e44bd90670d6d35ad25202d54ec45968422d6315db6eb611c785f6dbc9c239d03b1da1049e9f429fce90e6ba6cc3c0e034e2803b04dd76ab72b3d53ad872082"],"operation_results":[[0,{}]]}]}}
th_a db_block.cpp:195 _push_block
plus, mine seem to needed a wipe and resync of the database...
If you see this again, can you post the block number and output of
get_object 2.12.0
It will let me know if your witness has a different shuffling.
-
is the web sockeds backed tcp loadbalanced? how many backend servers are used? To avoid the freezing, if an issue with the backed.
If it is an issue with the frontend can we delay response to the ui, or is it already throtle based on the tps / current screen.
Also I seemed to need to refresh the browser a couple of times to get the latest block whilst doing the load test.
Currently the backend pushes ALL state changes to the GUI whether or not the GUI cares about that particular state. This was a shortcut taken to maximize reliability of the front end receiving updates. We already have the filters in place to throttle this back to only the data the GUI has previously requested.
So the GUI infrastructure is not well suited for these flood tests, but is well suited to serving 1000+ simultaneous users at normal transaction volumes.
+5% very nice. Prioritization of requirements but well thought out architecture. Also now the client is not a major issue, being a web wallet you can do continuous releases.
-
I keep getting these:
1320597ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e5f7f08e5cb01d5de1cee93e005447e29d, 63461
1320597ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320606ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e4de13bc0878fd684d7cf434a9f527dfde","timestamp":"2015-10-07T22:14:06","witness":"1.6.30","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f5046c64faf845e027e25ae05ef6b4837f22587e8d06bca11204b559679c14de45e96852d50123d04f1e062f61e8ae3e5276c73cd2f591e2ebfdcf75a790d20b8","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320607ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e63816b8b72183f76d418d9be0c778fb91, 63462
1320607ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320617ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e5f7f08e5cb01d5de1cee93e005447e29d","timestamp":"2015-10-07T22:14:09","witness":"1.6.8","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"2032e0250f672b893e51a18748d6f4c58dda8b5beea2bd9c7af09d48bfc0e47a294a02cc2920410654cef00dddb3cbd0067c450f015ff5b9657d069a890db5b364","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320619ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e737562f094e061a43446ad6958b2d681b, 63463
1320619ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320632ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e63816b8b72183f76d418d9be0c778fb91","timestamp":"2015-10-07T22:14:15","witness":"1.6.35","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"20151fdaf0786206e717d917f30e4d7b46d27035dc812e65056448dbac7e80daab309b85b0102f726c514263084df83c42392f46fcfc31937b88d28b2b7f2b58a5","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320634ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e86ed61243a7d820d3710862966c099480, 63464
1320634ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320648ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e737562f094e061a43446ad6958b2d681b","timestamp":"2015-10-07T22:14:18","witness":"1.6.24","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f6abbde2d9f9cfc8d61647e72864ea497faa2ca2fded3a9036ee2be6e9f4b2183724e420fe74258142e054779e5f68405d796f987929c5d14f810d44f8821fecb","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320649ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e9e20d7289c66b4b132c6ccfbbec011865, 63465
1320649ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320663ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e86ed61243a7d820d3710862966c099480","timestamp":"2015-10-07T22:14:27","witness":"1.6.29","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f0a88ac998c931c9622175c6824636307f2fea2866bc13670bac2242ceaf85abd64328132fc7ec5bfb5b189af8745722b37f3ff16b197eaa9a81b4411c9c3006e","transactions":[]}}
th_a db_block.cpp:197 _push_block
info
{
"head_block_num": 63389,
"head_block_id": "0000f79d286062943a634c0fc401d4204fa2187b",
"head_block_age": "17 minutes old",
"next_maintenance_time": "35 minutes in the future",
"chain_id": "60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83",
"participation": "93.75000000000000000",
-
I keep getting these:
1320597ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e5f7f08e5cb01d5de1cee93e005447e29d, 63461
1320597ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320606ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e4de13bc0878fd684d7cf434a9f527dfde","timestamp":"2015-10-07T22:14:06","witness":"1.6.30","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f5046c64faf845e027e25ae05ef6b4837f22587e8d06bca11204b559679c14de45e96852d50123d04f1e062f61e8ae3e5276c73cd2f591e2ebfdcf75a790d20b8","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320607ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e63816b8b72183f76d418d9be0c778fb91, 63462
1320607ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320617ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e5f7f08e5cb01d5de1cee93e005447e29d","timestamp":"2015-10-07T22:14:09","witness":"1.6.8","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"2032e0250f672b893e51a18748d6f4c58dda8b5beea2bd9c7af09d48bfc0e47a294a02cc2920410654cef00dddb3cbd0067c450f015ff5b9657d069a890db5b364","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320619ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e737562f094e061a43446ad6958b2d681b, 63463
1320619ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320632ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e63816b8b72183f76d418d9be0c778fb91","timestamp":"2015-10-07T22:14:15","witness":"1.6.35","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"20151fdaf0786206e717d917f30e4d7b46d27035dc812e65056448dbac7e80daab309b85b0102f726c514263084df83c42392f46fcfc31937b88d28b2b7f2b58a5","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320634ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e86ed61243a7d820d3710862966c099480, 63464
1320634ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320648ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e737562f094e061a43446ad6958b2d681b","timestamp":"2015-10-07T22:14:18","witness":"1.6.24","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f6abbde2d9f9cfc8d61647e72864ea497faa2ca2fded3a9036ee2be6e9f4b2183724e420fe74258142e054779e5f68405d796f987929c5d14f810d44f8821fecb","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320649ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e9e20d7289c66b4b132c6ccfbbec011865, 63465
1320649ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320663ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e86ed61243a7d820d3710862966c099480","timestamp":"2015-10-07T22:14:27","witness":"1.6.29","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f0a88ac998c931c9622175c6824636307f2fea2866bc13670bac2242ceaf85abd64328132fc7ec5bfb5b189af8745722b37f3ff16b197eaa9a81b4411c9c3006e","transactions":[]}}
th_a db_block.cpp:197 _push_block
You may have gotten those when the INIT witnesses reconnected and attempted to push their fork to you. We haven't updated the network code to refuse to fetch blocks older than the last irreversible block yet instead it fetches the blocks and then discards them because they are too old.
Let me know if it is stuck doing that or if it was just for a short burst.
-
me too.
First time
494825ms th_a application.cpp:394 handle_block ] Got block: #63389 time: 2015-10-07T22:08:15 latency: -190 ms from: triox-delegate irreversible: 63362 (-27)
498006ms th_a db_block.cpp:191 _push_block ] Failed to push new block:
10 assert_exception: Assert Exception
_index[space_id].size() > type_id:
{"space_id":0,"type_id":0,"index[space_id].size":0}
th_a object_database.cpp:51 get_index
{"next_block.block_num()":63390}
th_a db_block.cpp:511 _apply_block
498007ms th_a witness.cpp:169 block_production_loo ] Got exception while generating block:
10 assert_exception: Assert Exception
_index[space_id].size() > type_id:
{"space_id":0,"type_id":0,"index[space_id].size":0}
th_a object_database.cpp:51 get_index
{"next_block.block_num()":63390}
th_a db_block.cpp:511 _apply_block
{"new_block":{"previous":"0000f79d286062943a634c0fc401d4204fa2187b","timestamp":"2015-10-07T22:08:18","witness":"1.6.39","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"205983d1ceac18551fb1af51fa528eb58200f1edf51dbd16ba71962172dd13b38812fecd00ed6e77130073efdc41155b945da86e70cd7b5b2d0e2cbe8da7b77de0","transactions":[]}}
th_a db_block.cpp:197 _push_block
{"witness_id":"1.6.39"}
th_a db_block.cpp:385 _generate_block
499000ms th_a witness.cpp:194 block_production_loo ] Not producing block because node didn't wake up within 500ms of the slot time.
500000ms th_a witness.cpp:194 block_production_loo ] Not producing block because node didn't wake up within 500ms of the slot time.
504131ms th_a application.cpp:394 handle_block ] Got block: #63390 time: 2015-10-07T22:08:24 latency: 114 ms from: delegate-1.lafona irreversible: 63362 (-28)
504131ms th_a db_block.cpp:191 _push_block ] Failed to push new block:
After that i keep getting
0000000000000000000000000000000000000000","extensions":[],"witness_signature":"2009e548be4ce7163a947f717111002488980e6689f10dbec75f5b988f88800b5167338b56dbdf0f8eaf0ea5d5a10c2f1f83d7486e2512d2778c4ae903c0e60ec6","transactions":[]}}
th_a db_block.cpp:197 _push_block
1465610ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7c3a522d45a005d1a4f59e3aabbf163f74a, 63427
1465611ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79eec1813e57d0544c21a31cf44636c365c
1465616ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7c2a93093fc0776afc37d471fa154e97ec4","timestamp":"2015-10-07T22:11:30","witness":"1.6.1","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"2050e19ecea80c42d4f70403b393b405f5f01c314c26cde4465e45d6c613fdd7d8015977876a960029d23196170d843361ea4972207c0cb3b5386113d7e953f4d5","transactions":[]}}
th_a db_block.cpp:197 _push_block
1465617ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7c46a8302fd0c3bd58ec6fb65bfff36e64b, 63428
1465617ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79eec1813e57d0544c21a31cf44636c365c
1465623ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7c3a522d45a005d1a4f59e3aabbf163f74a","timestamp":"2015-10-07T22:11:33","witness":"1.6.29","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"204a3e7b90308e6bd1fecff1cb0104995a432c8d70d15000ff116ceb93b9e051290e365f4b6c8931a129199b1de113132345b7534cc9fb51c943beb7a6bf3424a3","transactions":[]}}
1465623ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7c50bc45f49c4b64de33bff9ef5511cb89f, 63429
1465623ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79eec1813e57d0544c21a31cf44636c365c
1465629ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
-
I keep getting these:
1320597ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e5f7f08e5cb01d5de1cee93e005447e29d, 63461
1320597ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320606ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e4de13bc0878fd684d7cf434a9f527dfde","timestamp":"2015-10-07T22:14:06","witness":"1.6.30","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f5046c64faf845e027e25ae05ef6b4837f22587e8d06bca11204b559679c14de45e96852d50123d04f1e062f61e8ae3e5276c73cd2f591e2ebfdcf75a790d20b8","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320607ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e63816b8b72183f76d418d9be0c778fb91, 63462
1320607ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320617ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e5f7f08e5cb01d5de1cee93e005447e29d","timestamp":"2015-10-07T22:14:09","witness":"1.6.8","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"2032e0250f672b893e51a18748d6f4c58dda8b5beea2bd9c7af09d48bfc0e47a294a02cc2920410654cef00dddb3cbd0067c450f015ff5b9657d069a890db5b364","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320619ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e737562f094e061a43446ad6958b2d681b, 63463
1320619ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320632ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e63816b8b72183f76d418d9be0c778fb91","timestamp":"2015-10-07T22:14:15","witness":"1.6.35","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"20151fdaf0786206e717d917f30e4d7b46d27035dc812e65056448dbac7e80daab309b85b0102f726c514263084df83c42392f46fcfc31937b88d28b2b7f2b58a5","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320634ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e86ed61243a7d820d3710862966c099480, 63464
1320634ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320648ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e737562f094e061a43446ad6958b2d681b","timestamp":"2015-10-07T22:14:18","witness":"1.6.24","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f6abbde2d9f9cfc8d61647e72864ea497faa2ca2fded3a9036ee2be6e9f4b2183724e420fe74258142e054779e5f68405d796f987929c5d14f810d44f8821fecb","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320649ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e9e20d7289c66b4b132c6ccfbbec011865, 63465
1320649ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320663ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e86ed61243a7d820d3710862966c099480","timestamp":"2015-10-07T22:14:27","witness":"1.6.29","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f0a88ac998c931c9622175c6824636307f2fea2866bc13670bac2242ceaf85abd64328132fc7ec5bfb5b189af8745722b37f3ff16b197eaa9a81b4411c9c3006e","transactions":[]}}
th_a db_block.cpp:197 _push_block
You may have gotten those when the INIT witnesses reconnected and attempted to push their fork to you. We haven't updated the network code to refuse to fetch blocks older than the last irreversible block yet instead it fetches the blocks and then discards them because they are too old.
Let me know if it is stuck doing that or if it was just for a short burst.
Edit: I keep getting those
plus:
info
{
"head_block_num": 63389,
"head_block_id": "0000f79d286062943a634c0fc401d4204fa2187b",
"head_block_age": "17 minutes old",
"next_maintenance_time": "35 minutes in the future",
"chain_id": "60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83",
"participation": "93.75000000000000000",
-
It seems we both are stuck on the same block.
info
{
"head_block_num": 63389,
"head_block_id": "0000f79d286062943a634c0fc401d4204fa2187b",
"head_block_age": "22 minutes old",
"next_maintenance_time": "30 minutes in the future",
"chain_id": "60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83",
"participation": "93.75000000000000000",
"active_witnesses": [
-
What should we do?
Restart the witness with --resync-blockchain?
-
It seems we both are stuck on the same block.
info
{
"head_block_num": 63389,
"head_block_id": "0000f79d286062943a634c0fc401d4204fa2187b",
"head_block_age": "22 minutes old",
"next_maintenance_time": "30 minutes in the future",
"chain_id": "60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83",
"participation": "93.75000000000000000",
"active_witnesses": [
Also spartako_bot stuck on the same block and was not able to notify the missed blocks...now it is restored
-
It seems that a lot of witnesses that were working ok during the flood are now out of sync.
https://graphene.bitshares.org/#/explorer/witnesses
-
Restarted the witness with --resync, back to normal.
-
I get this all the time without stopping.
I have deleted folders like "oct5", object_database",
I tried to --resync
./witness_node -d oct5 --genesis-json oct5-genesis.json -s "104.236.51.238:2005" --resync
I reinstalled graphene
but the same output >:(
312984ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["00001c34043f8cd77a774029c3297b709b9e5055"]
313603ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["00001c6a27a3c5fc9740ac594df500c4d48ebb04"]
314088ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["00001c7e18d092590a343d135490890111fea2c1"]
315198ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["00001cb60b30e0ebfc734ca945560ffd4b280e45"]
316069ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["00001f69c32224c394502ea4ae13e12d1ba91c02"]
316642ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["00002199ee5fb42c3c10a56f80e20aafa4c6236a"]
319179ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714","000022c5e914910801e93f9a74d0c3588e247eab","000022c90cb122db11a6fe6b7dc1720af6ef4dca","000022cb5d94abf4b0699cdb50fee429f177cdc5","000022ccff1d23f9b1b9df19e5ae8412ff4d9a0e"]
319184ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714","000022c5e914910801e93f9a74d0c3588e247eab","000022c90cb122db11a6fe6b7dc1720af6ef4dca","000022cb5d94abf4b0699cdb50fee429f177cdc5","000022ccff1d23f9b1b9df19e5ae8412ff4d9a0e"]
319189ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714","000022c5e914910801e93f9a74d0c3588e247eab","000022c90cb122db11a6fe6b7dc1720af6ef4dca","000022cb5d94abf4b0699cdb50fee429f177cdc5","000022ccff1d23f9b1b9df19e5ae8412ff4d9a0e"]
319209ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714","000022c5e914910801e93f9a74d0c3588e247eab","000022c90cb122db11a6fe6b7dc1720af6ef4dca","000022cb5d94abf4b0699cdb50fee429f177cdc5","000022ccff1d23f9b1b9df19e5ae8412ff4d9a0e"]
319250ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714","000022c5e914910801e93f9a74d0c3588e247eab","000022c90cb122db11a6fe6b7dc1720af6ef4dca","000022cb5d94abf4b0699cdb50fee429f177cdc5","000022ccff1d23f9b1b9df19e5ae8412ff4d9a0e"]
319314ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714","000022c5e914910801e93f9a74d0c3588e247eab","000022c90cb122db11a6fe6b7dc1720af6ef4dca","000022cb5d94abf4b0699cdb50fee429f177cdc5","000022ccff1d23f9b1b9df19e5ae8412ff4d9a0e"]
320023ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
320068ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
320216ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
320346ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714","000022c5e914910801e93f9a74d0c3588e247eab","000022c90cb122db11a6fe6b7dc1720af6ef4dca","000022cb5d94abf4b0699cdb50fee429f177cdc5","000022ccff1d23f9b1b9df19e5ae8412ff4d9a0e"]
320390ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
320563ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
320564ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714","000022c5e914910801e93f9a74d0c3588e247eab","000022c90cb122db11a6fe6b7dc1720af6ef4dca","000022cb5d94abf4b0699cdb50fee429f177cdc5","000022ccff1d23f9b1b9df19e5ae8412ff4d9a0e"]
320565ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
320579ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714","000022c5e914910801e93f9a74d0c3588e247eab","000022c90cb122db11a6fe6b7dc1720af6ef4dca","000022cb5d94abf4b0699cdb50fee429f177cdc5","000022ccff1d23f9b1b9df19e5ae8412ff4d9a0e"]
320929ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
321017ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714","000022c5e914910801e93f9a74d0c3588e247eab","000022c90cb122db11a6fe6b7dc1720af6ef4dca","000022cb5d94abf4b0699cdb50fee429f177cdc5","000022ccff1d23f9b1b9df19e5ae8412ff4d9a0e"]
321240ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714","000022c5e914910801e93f9a74d0c3588e247eab","000022c90cb122db11a6fe6b7dc1720af6ef4dca","000022cb5d94abf4b0699cdb50fee429f177cdc5","000022ccff1d23f9b1b9df19e5ae8412ff4d9a0e"]
321280ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
321359ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
321364ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
321372ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714","000022c5e914910801e93f9a74d0c3588e247eab","000022c90cb122db11a6fe6b7dc1720af6ef4dca","000022cb5d94abf4b0699cdb50fee429f177cdc5","000022ccff1d23f9b1b9df19e5ae8412ff4d9a0e"]
321844ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714","000022c5e914910801e93f9a74d0c3588e247eab","000022c90cb122db11a6fe6b7dc1720af6ef4dca","000022cb5d94abf4b0699cdb50fee429f177cdc5","000022ccff1d23f9b1b9df19e5ae8412ff4d9a0e"]
321937ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
322070ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
322718ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
322733ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
322762ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
322839ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
323110ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
323386ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
323405ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
323793ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
323851ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022bcbf0a696df8916d0477af2df6639c8714"]
324085ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000022d498d16481c794a4643e7f2a7e0acefd64"]
324449ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["0000233f874bacc359f2a54fd47d64f28a6a7401"]
325033ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000023463acb5ea5775b135e43c5d2e5162e2f69"]
325793ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["0000234903cb2307e8f0496992202f55e9e1373a"]
326656ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000024f6f5f2b206490a11269f2a1ce0dfaf48f8"]
327512ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["000024f6f5f2b206490a11269f2a1ce0dfaf48f8"]
PS I have this problems on my server @home not on the vps located in Germany.... Could it be because of latency problems? Is there some kind of latency limit to the witness node to work?
-
./witness_node -d oct5 --genesis-json oct5-genesis.json -s "104.236.51.238:2005" --resync
try --resync-blockchain
Edit: and look, on the cli_wallet, the sync progression with "info". we are at block #64300 ish
-
./witness_node -d oct5 --genesis-json oct5-genesis.json -s "104.236.51.238:2005" --resync
try --resync-blockchain
Edit: and look, on the cli_wallet, the sync progression with "info". we are at block #64300 ish
same result :'(
-
witness spectral updated to latest master
Just to make sure that I'm "cmaking" correctly. I use the following line. Is that what everyone else does?
cmake -DBOOST_ROOT="$BOOST_ROOT" -DCMAKE_BUILD_TYPE=Release .
For now, use your account history at https://graphene.bitshares.org/#/account/spectral/overview
Thank you for your answers. They were very informative. And I have to say, the graphene web-interface looks really good!
The cli-wallet shows only what my client believes is correct, and cannot be trusted when I'm off on a fork or something. And I still get those memo decrypt errors that I documented a few pages back.
@liondani:
How long have you waited. If I remember correctly, that output is normal at startup...? Also, have you remembered to put your config file back in the oct5 folder after resyncing the blockchain, and then restarting your witness?
-
@liondani:
How long have you waited. If I remember correctly, that output is normal at startup...? Also, have you remembered to put your config file back in the oct5 folder after resyncing the blockchain, and then restarting your witness?
more than half hour.
yes I have put back the config.ini file
can you post your config.ini entrys here (except your keys of-course :))
to compare them with mine
-
I'm one of the node out of sync. and both of my two nodes are out of sync from block 63389.
here is something from log.
got block 63389 correct
2015-10-07T22:08:15 p2p:message read_loop process_block_during ] received a block from peer 108.61.173.111:50696, passing it to client node.cpp:3290
a>2015-10-07T22:08:15 p2p:message read_loop process_block_during ] Successfully pushed block 63389 (id:0000f79d286062943a634c0fc401d4204fa2187b) node.cpp:3312
2015-10-07T22:08:15 p2p:message read_loop process_block_during ] client validated the block, advertising it to other peers node.cpp:3336
get block 63390 correct, but failed to push it.
2015-10-07T22:08:24 p2p:message read_loop process_block_during ] received a block from peer 52.89.36.4:39219, passing it to client node.cpp:3290
b>2015-10-07T22:08:24 p2p:message read_loop process_block_during ] Failed to push block 63390 (id:0000f79e741dd849af4e69a62a425f11497ce433), client rejected block sent
by peer node.cpp:3404
2015-10-07T22:08:24 p2p:message read_loop process_block_during ] disconnecting client 52.89.36.4:39219 because it offered us the rejected block node.cpp:3426
2015-10-07T22:08:30 p2p:send_sync_block_to_node_delegate send_sync_block_to_n ] Failed to push sync block 63390 (id:0000f79e741dd849af4e69a62a425f11497ce433): client rejected sync block sent by peer: {"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"object_database.cpp", "line":51,"method":"get_index","hostname":"","thread_name":"th_a","timestamp":"2015-10-07T22:08:30"},"format":"_index[space_id].size() > type_id: ","data":{"space_id" :0,"type_id":0,"index[space_id].size":0}},{"context":{"level":"warn","file":"db_block.cpp","line":511,"method":"_apply_block","hostname":"","thread_name":"th_a","time stamp":"2015-10-07T22:08:30"},"format":"","data":{"next_block.block_num()":63390}},{"context":{"level":"warn","file":"db_block.cpp","line":197,"method":"_push_block", "hostname":"","thread_name":"th_a","timestamp":"2015-10-07T22:08:30"},"format":"","data":{"new_block":{"previous":"0000f79d286062943a634c0fc401d4204fa2187b","timestam p":"2015-10-07T22:08:24","witness":"1.6.33","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"202007dd6bd3169d 71387c0c9d2f9feaa441ee291eff70d33d02d1d5b2de45f3c41502af9bb41773fd20b7f73aa8daee842cacf9d6501b0bb9bc397a8fad61ecb4","transactions":[]}}},{"context":{"level":"warn","f ile":"application.cpp","line":434,"method":"handle_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-07T22:08:30"},"format":"","data":{"blk_msg":{"block" :{"previous":"0000f79d286062943a634c0fc401d4204fa2187b","timestamp":"2015-10-07T22:08:24","witness":"1.6.33","transaction_merkle_root":"000000000000000000000000000000 0000000000","extensions":[],"witness_signature":"202007dd6bd3169d71387c0c9d2f9feaa441ee291eff70d33d02d1d5b2de45f3c41502af9bb41773fd20b7f73aa8daee842cacf9d6501b0bb9bc3 97a8fad61ecb4","transactions":[]},"block_id":"0000f79e741dd849af4e69a62a425f11497ce433"},"sync_mode":true}}]} node.cpp:3017
It synced after I delete the chain directory and restart node.
It seems that a lot of witnesses that were working ok during the flood are now out of sync.
https://graphene.bitshares.org/#/explorer/witnesses
-
can you post your config.ini entrys here (except your keys of-course :))
sure:
# Endpoint for P2P node to listen on
# p2p-endpoint =
# P2P nodes to connect to on startup (may specify multiple times)
# seed-node =
# Pairs of [BLOCK_NUM,BLOCK_ID] that should be enforced as checkpoints.
# checkpoint =
# Endpoint for websocket RPC to listen on
# rpc-endpoint =
# 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 =
# Block signing key to use for init witnesses, overrides genesis file
# dbg-init-key =
# JSON file specifying API permissions
# api-access =
# Enable block production, even if the chain is stale.
enable-stale-production = false
# Percent of witnesses (0-99) that must be participating in order to produce blocks
required-participation = false
# ID of witness controlled by this node (e.g. "1.6.5", quotes are required, may specify multiple times)
witness-id = "1.6.38"
# Tuple of [PublicKey, WIF private key] (may specify multiple times)
private-key = [""]
# 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
To start the witness_node I use the following command:
./witness_node --rpc-endpoint "127.0.0.1:8090" --genesis-json oct5-genesis.json -d oct5 -s "104.236.51.238:2005"
-
can you post your config.ini entrys here (except your keys of-course :))
sure:
# Endpoint for P2P node to listen on
# p2p-endpoint =
# P2P nodes to connect to on startup (may specify multiple times)
# seed-node =
# Pairs of [BLOCK_NUM,BLOCK_ID] that should be enforced as checkpoints.
# checkpoint =
# Endpoint for websocket RPC to listen on
# rpc-endpoint =
# 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 =
# Block signing key to use for init witnesses, overrides genesis file
# dbg-init-key =
# JSON file specifying API permissions
# api-access =
# Enable block production, even if the chain is stale.
enable-stale-production = false
# Percent of witnesses (0-99) that must be participating in order to produce blocks
required-participation = false
# ID of witness controlled by this node (e.g. "1.6.5", quotes are required, may specify multiple times)
witness-id = "1.6.38"
# Tuple of [PublicKey, WIF private key] (may specify multiple times)
private-key = [""]
# 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
To start the witness_node I use the following command:
./witness_node --rpc-endpoint "127.0.0.1:8090" --genesis-json oct5-genesis.json -d oct5 -s "104.236.51.238:2005"
what commands did you use to update graphene today?
-
Restarted the witness with --resync, back to normal.
--resync worked great, thanks
-
What is the cause of th is fork? IMO it should be dealt seriously..
-
My nodes (in.abit and an observer node) are running well. Maybe have been on a fork but switched back successfully.
Updated to latest commit. Switched to another process by command 'update_witness'.
-
I was at this commit fe552a42d0e6a29f48c39dfca44d02a9a2548698 (removing unnecessary assert)
but there is a new one bfef440968e98219612a9bbd24e715e8835ad975 (fork_database.cpp: Fix overflow)
I will update and see if it goes back to the main chain.
-
I was at this commit fe552a42d0e6a29f48c39dfca44d02a9a2548698 (removing unnecessary assert)
but there is a new one bfef440968e98219612a9bbd24e715e8835ad975 (fork_database.cpp: Fix overflow)
I will update and see if it goes back to the main chain.
After upgrading to latest master (bfef440968e98219612a9bbd24e715e8835ad975)
I tried.
./witness_node -d oct5 --genesis-json oct5-genesis.json -s "104.236.51.238:2005" --rpc-endpoint 127.0.0.1:8090 --witness-id '"1.6.39"' --private-key '["GPH7TrF5cDX66egLWPLJ7YCnZD5vHeFTgNbPChV8MDQnVKMzDfPrK","51111111111111111111111111111"]' --replay-blockchain
without success .. then
./witness_node -d oct5 --genesis-json oct5-genesis.json -s "104.236.51.238:2005" --rpc-endpoint 127.0.0.1:8090 --witness-id '"1.6.39"' --private-key '["GPH7TrF5cDX66egLWPLJ7YCnZD5vHeFTgNbPChV8MDQnVKMzDfPrK","51111111111111111111111111111"]' --resync-blockchain
without success .. then
rm -rf oct5 object_database
./witness_node -d oct5 --genesis-json oct5-genesis.json -s "104.236.51.238:2005" --rpc-endpoint 127.0.0.1:8090 --witness-id '"1.6.39"' --private-key '["GPH7TrF5cDX66egLWPLJ7YCnZD5vHeFTgNbPChV8MDQnVKMzDfPrK","51111111111111111111111111111"]' --resync-blockchain
And i'm finally on track again.
-
what commands did you use to update graphene today?
I did
git checkout master
git pull
git submodule update --init --recursive
BOOST_ROOT=$HOME/opt/boost_1_57_0
cmake -DBOOST_ROOT="$BOOST_ROOT" -DCMAKE_BUILD_TYPE=Release .
make
then
- backuped up config.ini
- deleted oct5 and object_database
- started witness
- quit witness
- copied config.ini into oct5
- started witness
-
what commands did you use to update graphene today?
I did
git checkout master
git pull
git submodule update --init --recursive
BOOST_ROOT=$HOME/opt/boost_1_57_0
cmake -DBOOST_ROOT="$BOOST_ROOT" -DCMAKE_BUILD_TYPE=Release .
make
then
- backuped up config.ini
- deleted oct5 and object_database
- started witness
- quit witness
- copied config.ini into oct5
- started witness
you might be on a previous commit as ElMato posted just above. Look on which commit you are with git show and follow ElMato steps after updating (remove object_database, start with a new datadir and resync)
-
What is the cause of th is fork? IMO it should be dealt seriously..
I think this was the cause
I keep getting these:
1320597ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e5f7f08e5cb01d5de1cee93e005447e29d, 63461
1320597ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320606ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e4de13bc0878fd684d7cf434a9f527dfde","timestamp":"2015-10-07T22:14:06","witness":"1.6.30","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f5046c64faf845e027e25ae05ef6b4837f22587e8d06bca11204b559679c14de45e96852d50123d04f1e062f61e8ae3e5276c73cd2f591e2ebfdcf75a790d20b8","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320607ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e63816b8b72183f76d418d9be0c778fb91, 63462
1320607ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320617ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e5f7f08e5cb01d5de1cee93e005447e29d","timestamp":"2015-10-07T22:14:09","witness":"1.6.8","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"2032e0250f672b893e51a18748d6f4c58dda8b5beea2bd9c7af09d48bfc0e47a294a02cc2920410654cef00dddb3cbd0067c450f015ff5b9657d069a890db5b364","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320619ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e737562f094e061a43446ad6958b2d681b, 63463
1320619ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320632ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e63816b8b72183f76d418d9be0c778fb91","timestamp":"2015-10-07T22:14:15","witness":"1.6.35","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"20151fdaf0786206e717d917f30e4d7b46d27035dc812e65056448dbac7e80daab309b85b0102f726c514263084df83c42392f46fcfc31937b88d28b2b7f2b58a5","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320634ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e86ed61243a7d820d3710862966c099480, 63464
1320634ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320648ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e737562f094e061a43446ad6958b2d681b","timestamp":"2015-10-07T22:14:18","witness":"1.6.24","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f6abbde2d9f9cfc8d61647e72864ea497faa2ca2fded3a9036ee2be6e9f4b2183724e420fe74258142e054779e5f68405d796f987929c5d14f810d44f8821fecb","transactions":[]}}
th_a db_block.cpp:197 _push_block
1320649ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f7e9e20d7289c66b4b132c6ccfbbec011865, 63465
1320649ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
1320663ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f7e86ed61243a7d820d3710862966c099480","timestamp":"2015-10-07T22:14:27","witness":"1.6.29","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f0a88ac998c931c9622175c6824636307f2fea2866bc13670bac2242ceaf85abd64328132fc7ec5bfb5b189af8745722b37f3ff16b197eaa9a81b4411c9c3006e","transactions":[]}}
th_a db_block.cpp:197 _push_block
You may have gotten those when the INIT witnesses reconnected and attempted to push their fork to you. We haven't updated the network code to refuse to fetch blocks older than the last irreversible block yet instead it fetches the blocks and then discards them because they are too old.
Let me know if it is stuck doing that or if it was just for a short burst.
-
100 TPS / 1 hour test will take place at 10/8 18:00 UTC (14:00 EST, 11:00 PST)
-
btc38 and yunbi seems to be rejecting @xeroc pricefeeds script to fetch tickers:
python3 pricefeeds.py
[Starting Threads]: (yunbi)(btc38)(btcavg)(poloniex)(yahoo)(bittrex)
Error fetching results from btc38! (HTTPConnectionPool(host='api.btc38.com', port=80): Max retries exceeded with url: /v1/ticker.php?mk_type=btc&c=all (Caused by <class 'socket.gaierror'>: [Errno -2] Name or service not known))
Error fetching results from yunbi! (HTTPSConnectionPool(host='yunbi.com', port=443): Max retries exceeded with url: /api/v2/tickers.json (Caused by <class 'socket.gaierror'>: [Errno -2] Name or service not known))
......Update required! Forcing now!
publishing feeds for delegate: bitshares-argentina
Both api are up:
http://api.btc38.com/v1/ticker.php?c=all&mk_type=btc (http://api.btc38.com/v1/ticker.php?c=all&mk_type=btc)
https://yunbi.com/api/v2/tickers.json (https://yunbi.com/api/v2/tickers.json)
running last version of python-graphenelib. I made just 3 or 4, not an api call limit I guess.
Anyone else having this problem?
-
btc38 and yunbi seems to be rejecting @xeroc pricefeeds script to fetch tickers:
python3 pricefeeds.py
[Starting Threads]: (yunbi)(btc38)(btcavg)(poloniex)(yahoo)(bittrex)
Error fetching results from btc38! (HTTPConnectionPool(host='api.btc38.com', port=80): Max retries exceeded with url: /v1/ticker.php?mk_type=btc&c=all (Caused by <class 'socket.gaierror'>: [Errno -2] Name or service not known))
Error fetching results from yunbi! (HTTPSConnectionPool(host='yunbi.com', port=443): Max retries exceeded with url: /api/v2/tickers.json (Caused by <class 'socket.gaierror'>: [Errno -2] Name or service not known))
......Update required! Forcing now!
publishing feeds for delegate: bitshares-argentina
Both api are up:
http://api.btc38.com/v1/ticker.php?c=all&mk_type=btc (http://api.btc38.com/v1/ticker.php?c=all&mk_type=btc)
https://yunbi.com/api/v2/tickers.json (https://yunbi.com/api/v2/tickers.json)
running last version of python-graphenelib. I made just 3 or 4, not an api call limit I guess.
Anyone else having this problem?
They have a rate limitation per ip ..
you should not fetch pricea from them more then 10 to 15 times per hour IIRC
-
Witness this morning in a loop:
2408404ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0000f81c4cb25eb5192a4e4ac3105f3a720cb85a, 63516
2408404ms th_a fork_database.cpp:58 push_block ] Head: 63390, 0000f79e741dd849af4e69a62a425f11497ce433
2408424ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0000f81b7ee45582a87b6cfe1dfb8bfb8f67d7f8","timestamp":"2015-10-07T22:18:33","witness":"1.6.34","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f484fa82a8f2f8422564b7578984a825337d75e47ff582f7e081bc224d78533a44a1c1870670013b8bd3070bba1c8e810bf6d65c615f6eaa003152b405882cc8a","transactions":[]}}
th_a db_block.cpp:197 _push_block
"head_block_num": 63389,
"head_block_id": "0000f79d286062943a634c0fc401d4204fa2187b",
"head_block_age": "8 hours old",
was not recovering ==> restart
-
I suggest to everyone stuck to double check if his witness is updated to the latest master commit.
Then to remove the witness data and object db folders and start again.
-
can't switch to correct chain, even restart witness_node(build from bfef440968e98219612a9bbd24e715e8835ad975),
get block 70872, but failed to push sync block
here is the error message from log file:
2015-10-08T06:31:23 p2p:send_sync_block_to_node_delegate send_sync_block_to_n ] Failed to push sync block 70872 (id:000114d879ab3c305edeaaae837c2b68b7da64d2): client rejected sync block sent by peer: {"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"vesting_balance_evalu ator.cpp","line":103,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"vbo.is_withdraw_allowed( now, op.amount ): ","data":{"now":"2015-10-08T05:43:09","op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"as set_id":"1.3.0"}},"vbo":{"id":"1.13.60","owner":"1.2.8517","balance":{"amount":202500000,"asset_id":"1.3.0"},"policy":[1,{"vesting_seconds":86400,"start_claim":"1970- 01-01T00:00:00","coin_seconds_earned":"3290619000000","coin_seconds_earned_last_update":"2015-10-08T05:43:06"}]}}},{"context":{"level":"warn","file":"vesting_balance_ evaluator.cpp","line":109,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"","data":{"op":{"fee":{"amount":10000 0,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}}},{"context":{"level":"warn","file":"evaluator.c pp","line":42,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"","data":{}},{"context":{"level":"warn","file" :"db_block.cpp","line":625,"method":"apply_operation","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"","data":{}},{"context":{"level" :"warn","file":"db_block.cpp","line":608,"method":"_apply_transaction","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"","data":{"trx" :{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance ":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a0 0d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"]}}},{"context":{"level":"warn","file":"db_block.cpp","line":511,"method":"_apply_block" ,"hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"","data":{"next_block.block_num()":70872}},{"context":{"level":"warn","file":"db_bloc k.cpp","line":197,"method":"_push_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"","data":{"new_block":{"previous":"000114d73b cdebf717450d1a45e7ea119844b22e","timestamp":"2015-10-08T05:43:15","witness":"1.6.10","transaction_merkle_root":"05b459df123ff6baf5dbc44890e6ae3e8a8caaf6","extensions" :[],"witness_signature":"20232fc2bb2ead0cbc644d78e4462881dc812787ad28f1517229cc346c252acb2904cb13139a8e957c8087d8b03790f12f5c2ef0dbb2cfceead7a47521f75f0950","transact ions":[{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_b alance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b25050 7262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"],"operation_results":[[0,{}]]}]}}},{"context":{"level":"warn","file":"application .cpp","line":434,"method":"handle_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"","data":{"blk_msg":{"block":{"previous":"000 114d73bcdebf717450d1a45e7ea119844b22e","timestamp":"2015-10-08T05:43:15","witness":"1.6.10","transaction_merkle_root":"05b459df123ff6baf5dbc44890e6ae3e8a8caaf6","exte nsions":[],"witness_signature":"20232fc2bb2ead0cbc644d78e4462881dc812787ad28f1517229cc346c252acb2904cb13139a8e957c8087d8b03790f12f5c2ef0dbb2cfceead7a47521f75f0950","t ransactions":[{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"ve sting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af1 1b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"],"operation_results":[[0,{}]]}]},"block_id":"000114d879ab3c305edeaaae837c2 b68b7da64d2"},"sync_mode":true}}]} node.cpp:3017
output from console
1883626ms th_a db_block.cpp:191 _push_block ] Failed to push new block:
10 assert_exception: Assert Exception
vbo.is_withdraw_allowed( now, op.amount ):
{"now":"2015-10-08T05:43:09","op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":
"1.3.0"}},"vbo":{"id":"1.13.60","owner":"1.2.8517","balance":{"amount":202500000,"asset_id":"1.3.0"},"policy":[1,{"vesting_seconds":86400,"start_claim":"1970-01-01T00:0
0:00","coin_seconds_earned":"3290619000000","coin_seconds_earned_last_update":"2015-10-08T05:43:06"}]}}
th_a vesting_balance_evaluator.cpp:103 do_evaluate
{"op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}}
th_a vesting_balance_evaluator.cpp:109 do_evaluate
{}
th_a evaluator.cpp:42 start_evaluate
{}
th_a db_block.cpp:625 apply_operation
{"trx":{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting
_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b25050
7262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"]}}
th_a db_block.cpp:608 _apply_transaction
{"next_block.block_num()":70872}
th_a db_block.cpp:511 _apply_block
-
periodically this msg:
597589ms th_a application.cpp:425 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
item->num > std::max<int64_t>( 0, int64_t(_head->num) - (_max_size) ): attempting to push a block that is too old
{"item->num":71004,"head":72258,"max_size":37}
th_a fork_database.cpp:71 _push_block
{"new_block":{"previous":"0001155bb592a4a8a15edca185dfaa328227e3d4","timestamp":"2015-10-08T07:09:57","witness":"1.6.17","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"2051b143c9581670b9e5155a9c6de976ed9da95001e21f937abece464f5938a3c829b8e1e74adbdbc5dad43fee6546d3bbbeb49756cbac270002ae03e33baea66e","transactions":[]}}
th_a db_block.cpp:197 _push_block
702659ms th_a application.cpp:425 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
item->num > std::max<int64_t>( 0, int64_t(_head->num) - (_max_size) ): attempting to push a block that is too old
{"item->num":71007,"head":72283,"max_size":32}
th_a fork_database.cpp:71 _push_block
{"new_block":{"previous":"0001155e93cb0255cde3f5ea32d3c8b4f289a9fd","timestamp":"2015-10-08T07:11:42","witness":"1.6.17","transaction_merkle_root":"d828ee5a36ba9cc670ff5032f35fe9aed2060e16","extensions":[],"witness_signature":"1f7b008386cc0b839f93f7b1205ef6576c56124f53a822732314e0272c025a89456b0a4ab5090d480af0cc19a292285dcb8ac0cdc9cab4b127d250ad932514e594","transactions":[{"ref_block_num":5470,"ref_block_prefix":1426246547,"expiration":"2015-10-08T07:11:27","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.39026","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":3330975,"asset_id":"1.3.285"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":3330975,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures":["1f6211b4dc0851f0c1ade14a840c5dc675390eb497ee1c622fdf5699184458b5cc239b10f2ea6c40c55d3d4576da7f6506f44caae2466d54ce9089ac3498fe815e"],"operation_results":[[0,{}]]},{"ref_block_num":5470,"ref_block_prefix":1426246547,"expiration":"2015-10-08T07:11:27","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.39026","asset_id":"1.3.218","feed":{"settlement_price":{"base":{"amount":21157829,"asset_id":"1.3.218"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":21157829,"asset_id":"1.3.218"}}},"extensions":[]}]],"extensions":[],"signatures":["1f6b972c400697919c695057e8fd3c4dec36301d08d7eaecec7fd51f495034ec3b3624d1ee5e3d69821878bf08e70f7168f9a259df6e88fb9b69cfaf49dbd25a76"],"operation_results":[[0,{}]]},.........//..............
seems to be the same witness "witness":"1.6.17"
edit: sometimes also 1.6.23 / 1.6.29
-
periodically this msg:
597589ms th_a application.cpp:425 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
item->num > std::max<int64_t>( 0, int64_t(_head->num) - (_max_size) ): attempting to push a block that is too old
{"item->num":71004,"head":72258,"max_size":37}
th_a fork_database.cpp:71 _push_block
{"new_block":{"previous":"0001155bb592a4a8a15edca185dfaa328227e3d4","timestamp":"2015-10-08T07:09:57","witness":"1.6.17","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"2051b143c9581670b9e5155a9c6de976ed9da95001e21f937abece464f5938a3c829b8e1e74adbdbc5dad43fee6546d3bbbeb49756cbac270002ae03e33baea66e","transactions":[]}}
th_a db_block.cpp:197 _push_block
702659ms th_a application.cpp:425 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
item->num > std::max<int64_t>( 0, int64_t(_head->num) - (_max_size) ): attempting to push a block that is too old
{"item->num":71007,"head":72283,"max_size":32}
th_a fork_database.cpp:71 _push_block
{"new_block":{"previous":"0001155e93cb0255cde3f5ea32d3c8b4f289a9fd","timestamp":"2015-10-08T07:11:42","witness":"1.6.17","transaction_merkle_root":"d828ee5a36ba9cc670ff5032f35fe9aed2060e16","extensions":[],"witness_signature":"1f7b008386cc0b839f93f7b1205ef6576c56124f53a822732314e0272c025a89456b0a4ab5090d480af0cc19a292285dcb8ac0cdc9cab4b127d250ad932514e594","transactions":[{"ref_block_num":5470,"ref_block_prefix":1426246547,"expiration":"2015-10-08T07:11:27","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.39026","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":3330975,"asset_id":"1.3.285"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":3330975,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures":["1f6211b4dc0851f0c1ade14a840c5dc675390eb497ee1c622fdf5699184458b5cc239b10f2ea6c40c55d3d4576da7f6506f44caae2466d54ce9089ac3498fe815e"],"operation_results":[[0,{}]]},{"ref_block_num":5470,"ref_block_prefix":1426246547,"expiration":"2015-10-08T07:11:27","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.39026","asset_id":"1.3.218","feed":{"settlement_price":{"base":{"amount":21157829,"asset_id":"1.3.218"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":21157829,"asset_id":"1.3.218"}}},"extensions":[]}]],"extensions":[],"signatures":["1f6b972c400697919c695057e8fd3c4dec36301d08d7eaecec7fd51f495034ec3b3624d1ee5e3d69821878bf08e70f7168f9a259df6e88fb9b69cfaf49dbd25a76"],"operation_results":[[0,{}]]},.........//..............
seems to be the same witness "witness":"1.6.17"
edit: sometimes also 1.6.23 / 1.6.29
may it be an issue with ntp? what's the output of ntpq -p
just guessing, you can try service ntp reload and then resync
-
may it be an issue with ntp? what's the output of ntpq -p
just guessing, you can try service ntp reload and then resync
Thx, ntp is running o.k., chain stays synced. Actually running well - latency related ?
-
CMake Error at CMakeLists.txt:36 (include):
include could not find load file:
GetGitRevisionDescription
CMake Error at CMakeLists.txt:37 (get_git_head_revision):
Unknown CMake command "get_git_head_revision".
-- Configuring incomplete, errors occurred!
See also "/home/ekrem/Desktop/testnet/graphene-test6/CMakeFiles/CMakeOutput.log".
Does anyone has any idea how to solve this?
-
what was the command you gave prior this output?
have you installed boost?
andi prior make
BOOST_ROOT=$HOME/opt/boost_1_57_0
-
is the "irreversible" output something it must noticed?
3173604ms th_a application.cpp:394 handle_block ] Got block: #75925 time: 2015-10-08T10:52:54 latency: -398 ms from: triox-delegate irreversible: 75892 (-33)
3180219ms th_a application.cpp:394 handle_block ] Got block: #75926 time: 2015-10-08T10:53:00 latency: 216 ms from: init10 irreversible: 75892 (-34)
3185689ms th_a application.cpp:394 handle_block ] Got block: #75927 time: 2015-10-08T10:53:06 latency: -313 ms from: delegate-1.lafona irreversible: 75893 (-34)
3189138ms th_a application.cpp:394 handle_block ] Got block: #75928 time: 2015-10-08T10:53:09 latency: 135 ms from: mindphlux.witness irreversible: 75893 (-35)
3192219ms th_a application.cpp:394 handle_block ] Got block: #75929 time: 2015-10-08T10:53:12 latency: 217 ms from: init2 irreversible: 75893 (-36)
3195793ms th_a application.cpp:394 handle_block ] Got block: #75930 time: 2015-10-08T10:53:15 latency: 790 ms from: fox irreversible: 75893 (-37)
3198140ms th_a application.cpp:394 handle_block ] Got block: #75931 time: 2015-10-08T10:53:18 latency: 137 ms from: jtm1 irreversible: 75893 (-38)
3201413ms th_a application.cpp:394 handle_block ] Got block: #75932 time: 2015-10-08T10:53:21 latency: 410 ms from: bitcube irreversible: 75894 (-38)
3204146ms th_a application.cpp:394 handle_block ] Got block: #75933 time: 2015-10-08T10:53:24 latency: 143 ms from: spectral irreversible: 75894 (-39)
3207154ms th_a applic
-
CMake Error at CMakeLists.txt:36 (include):
include could not find load file:
GetGitRevisionDescription
CMake Error at CMakeLists.txt:37 (get_git_head_revision):
Unknown CMake command "get_git_head_revision".
-- Configuring incomplete, errors occurred!
See also "/home/ekrem/Desktop/testnet/graphene-test6/CMakeFiles/CMakeOutput.log".
Does anyone has any idea how to solve this?
git submodule update --init --recursive
-
I have followed this steps:
BOOST_ROOT=$HOME/opt/boost_1_57_0
git submodule update --init --recursive
cmake -DBOOST_ROOT="$BOOST_ROOT" -DCMAKE_BUILD_TYPE=Release
but still there is that error
-
is the "irreversible" output something it must noticed?
3173604ms th_a application.cpp:394 handle_block ] Got block: #75925 time: 2015-10-08T10:52:54 latency: -398 ms from: triox-delegate irreversible: 75892 (-33)
3180219ms th_a application.cpp:394 handle_block ] Got block: #75926 time: 2015-10-08T10:53:00 latency: 216 ms from: init10 irreversible: 75892 (-34)
3185689ms th_a application.cpp:394 handle_block ] Got block: #75927 time: 2015-10-08T10:53:06 latency: -313 ms from: delegate-1.lafona irreversible: 75893 (-34)
3189138ms th_a application.cpp:394 handle_block ] Got block: #75928 time: 2015-10-08T10:53:09 latency: 135 ms from: mindphlux.witness irreversible: 75893 (-35)
3192219ms th_a application.cpp:394 handle_block ] Got block: #75929 time: 2015-10-08T10:53:12 latency: 217 ms from: init2 irreversible: 75893 (-36)
3195793ms th_a application.cpp:394 handle_block ] Got block: #75930 time: 2015-10-08T10:53:15 latency: 790 ms from: fox irreversible: 75893 (-37)
3198140ms th_a application.cpp:394 handle_block ] Got block: #75931 time: 2015-10-08T10:53:18 latency: 137 ms from: jtm1 irreversible: 75893 (-38)
3201413ms th_a application.cpp:394 handle_block ] Got block: #75932 time: 2015-10-08T10:53:21 latency: 410 ms from: bitcube irreversible: 75894 (-38)
3204146ms th_a application.cpp:394 handle_block ] Got block: #75933 time: 2015-10-08T10:53:24 latency: 143 ms from: spectral irreversible: 75894 (-39)
3207154ms th_a applic
The irreversible block is the last block that your node has that has been confirmed by 2/3 of the witnesses. The "-X" represents how many blocks ago that was.
-
I have followed this steps:
BOOST_ROOT=$HOME/opt/boost_1_57_0
git submodule update --init --recursive
cmake -DBOOST_ROOT="$BOOST_ROOT" -DCMAKE_BUILD_TYPE=Release
but still there is that error
just in case install cmake again and try again:
sudo apt-get install cmake
edit:
and this please:
sudo apt-get update
sudo apt-get install doxygen
sudo apt-get install automake
-
I upgraded cmake to version 3.2.2. But there is still the same error. Just to notice than git after executing submodule update --init --recursive command nothing happens.
edit:
I have done also apt-get update, doxygen and automake are also installed
-
What about
git submodule update --init --recursive --force
-
before
git submodule update --init --recursive
have you(?)
git checkout master
and are you on the graphene folder?
-
I've downloaded the source code from https://github.com/cryptonomex/graphene/releases and I'm inside graphene folder and master branch too
-
I've downloaded the source code from https://github.com/cryptonomex/graphene/releases and I'm inside graphene folder and master branch too
have you properly installed git on your machine? :o
nothing to loose:
sudo apt-get update
sudo apt-get install git
and make the same steps....
-
i don't think git is the problem. Should I download source code from last snapshot or to get graphene from git. Maybe there is the error, because all you say I have done before. I have set up graphene before too
-
grab it from git master, anything else will cause problems.
-
Have new commits beeb made that require a new build?
I found my witness crashed hard and I was going to try to restart it but then see this.
I'll start a new build now, just in case.
Looks like there were only 2 new commits since my last build. Are they crucial to incorporate before I restart my witness?
-
what commands did you use to update graphene today?
I did
git checkout master
git pull
git submodule update --init --recursive
BOOST_ROOT=$HOME/opt/boost_1_57_0
cmake -DBOOST_ROOT="$BOOST_ROOT" -DCMAKE_BUILD_TYPE=Release .
make
then
- backuped up config.ini
- deleted oct5 and object_database
- started witness
- quit witness
- copied config.ini into oct5
- started witness
you might be on a previous commit as ElMato posted just above. Look on which commit you are with git show and follow ElMato steps after updating (remove object_database, start with a new datadir and resync)
I'm on the same commit as ElMato, and I don't seem to have any problems right now. So the above procedure should work well.
-
i don't think git is the problem. Should I download source code from last snapshot or to get graphene from git. Maybe there is the error, because all you say I have done before. I have set up graphene before too
In case it may be helpful, here is the whole procedure I have used:
sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install gcc-4.9 g++-4.9 cmake make libbz2-dev libdb++-dev libdb-dev libssl-dev openssl libreadline-dev autoconf libtool git unzip ntp
BOOST_ROOT=$HOME/opt/boost_1_57_0
sudo apt-get update
sudo apt-get install autotools-dev build-essential g++ libbz2-dev libicu-dev python-dev
wget -c 'http://sourceforge.net/projects/boost/files/boost/1.57.0/boost_1_57_0.tar.bz2/download' -O boost_1_57_0.tar.bz2
[ $( sha256sum boost_1_57_0.tar.bz2 | cut -d ' ' -f 1 ) == "910c8c022a33ccec7f088bd65d4f14b466588dda94ba2124e78b8c57db264967" ] || ( echo 'Corrupt download' ; exit 1 )
tar xjf boost_1_57_0.tar.bz2
cd boost_1_57_0/
./bootstrap.sh "--prefix=$BOOST_ROOT"
./b2 install
cd ..
git clone https://github.com/cryptonomex/graphene.git
cd graphene
git submodule update --init --recursive
BOOST_ROOT=$HOME/opt/boost_1_57_0
cmake -DBOOST_ROOT="$BOOST_ROOT" -DCMAKE_BUILD_TYPE=Release .
make
-
Every day so many witnesses are not online, what is the reason?
-
Every day so many witnesses are not online, what is the reason?
Running backup nodes with alternative signing keys (update_witness) is a good start. As far as I've tested you can kill/update/resync a node and another will start signing instantly without loosing a single block.
-
Every day so many witnesses are not online, what is the reason?
Running backup nodes with alternative signing keys (update_witness) is a good start. As far as I've tested you can kill/update/resync a node and another will start signing instantly without loosing a single block.
Witnesses could also use spartako_bot (https://bitsharestalk.org/index.php/topic,18642.msg241988.html#msg241988) on Telegram to monitor their witness.
-
Mine crashed hard last night, restarting now.
Perhaps some major flood tests were done during the night?
Don't know what is going on today, looks like all of my votes have gone away today and weird latency times are being reported:
5-10-06T15:35:45 latency: 170343383 ms from: delegate-1.lafona irreversible: 29967 (-33)
3290282ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["00007a0955f3d8a
5-10-07T00:48:21 latency: 137213378 ms from: init2 irreversible: 39975 (-25)
3317386ms th_a application.cpp:705 get_blockchain_synop ] synopsis: ["0000a17900f4304
Interesting. When I restarted with the new binary I wiped the old object_database, blockchain, logs & p2p. Did NOT change the config.ini or the wallet. When the witness restarted it was complaining it didn't have the private key for delegate.verbaltech (it said for xxxx pub key actually), which was the old / original key. Yesterday I updated the witness and was operating all day with the new key.
Can someone explain why it reverted to using the old key?
I think I'm back in the game, all latency times are back to normal now. However, I'm missing blocks fairly regularly (Not sure, but with 35 active witnesses at 3 secs / block each round would be 105 seconds. So approximately every minute.45 each witness should produce a block. That is roughly how frequently I see my missed block count being incremented, so it looks like I'm missing every block - ??????????????????)
-
Every day so many witnesses are not online, what is the reason?
Running backup nodes with alternative signing keys (update_witness) is a good start. As far as I've tested you can kill/update/resync a node and another will start signing instantly without loosing a single block.
Could you explain this in more detail? I was using puppies post to do this but today my signing keys are reverted back to the originals. See my earlier post. It looks like I'm consistently missing blocks today, but get_witness delegate.verbaltech shows votes for the old keys and none for the new, tho I was signing blocks with the new key yesterday.
-
Mine crashed hard last night ...
The Mystery of the Flood Test
(http://www.nowcultured.com/images/2013/10/18-goofy-south-park-characters/hardly-boys-brothers-solving-mysteries.jpg)
I needed to lower the IQ of this thread to participate.
-
Every day so many witnesses are not online, what is the reason?
Running backup nodes with alternative signing keys (update_witness) is a good start. As far as I've tested you can kill/update/resync a node and another will start signing instantly without loosing a single block.
Witnesses could also use spartako_bot (https://bitsharestalk.org/index.php/topic,18642.msg241988.html#msg241988) on Telegram to monitor their witness.
+5%
There are 7 witnesses that are using the bot and nobody is missing blocks now...
-
Mine crashed hard last night ...
The Mystery of the Flood Test
(http://www.nowcultured.com/images/2013/10/18-goofy-south-park-characters/hardly-boys-brothers-solving-mysteries.jpg)
I needed to lower the IQ of this thread to participate.
Indeed, mysteries abound around here it seems. I know I can't explain why I'm missing blocks today. What have I changed? This:
1) new binaries, looks like only 2 commits since last build yesterday morning (at least that's what git reported)
2) wiped everything except config.ini and cli wallet
What is different? This:
1) witness complained upon starting the new binary that it didn't have the signing keys listed in the config.ini, tho they weren't changed.
2) delegate.verbaltech appears to be missing every block.
That's all I know. Would appreciate any insight anybody might have that can explain this.
-
Every day so many witnesses are not online, what is the reason?
Running backup nodes with alternative signing keys (update_witness) is a good start. As far as I've tested you can kill/update/resync a node and another will start signing instantly without loosing a single block.
Witnesses could also use spartako_bot (https://bitsharestalk.org/index.php/topic,18642.msg241988.html#msg241988) on Telegram to monitor their witness.
+5%
There are 7 witnesses that are using the bot and nobody is missing blocks now...
You mean of those 7 right? I can confirm that doesn't apply to me.
-
Mine crashed hard last night ...
The Mystery of the Flood Test
(http://www.nowcultured.com/images/2013/10/18-goofy-south-park-characters/hardly-boys-brothers-solving-mysteries.jpg)
I needed to lower the IQ of this thread to participate.
Indeed, mysteries abound around here it seems. I know I can't explain why I'm missing blocks today. What have I changed? This:
1) new binaries, looks like only 2 commits since last build yesterday morning (at least that's what git reported)
2) wiped everything except config.ini and cli wallet
What is different? This:
1) witness complained upon starting the new binary that it didn't have the signing keys listed in the config.ini, tho they weren't changed.
2) delegate.verbaltech appears to be missing every block.
That's all I know. Would appreciate any insight anybody might have that can explain this.
Did you build the latest master? And used release mode instead of debugging mode?
-
Every day so many witnesses are not online, what is the reason?
Running backup nodes with alternative signing keys (update_witness) is a good start. As far as I've tested you can kill/update/resync a node and another will start signing instantly without loosing a single block.
Witnesses could also use spartako_bot (https://bitsharestalk.org/index.php/topic,18642.msg241988.html#msg241988) on Telegram to monitor their witness.
+5%
There are 7 witnesses that are using the bot and nobody is missing blocks now...
You mean of those 7 right? I can confirm that doesn't apply to me.
Sure, there are 5 witnesses are missing blocks now and they are not using the bot
-
Mine crashed hard last night ...
The Mystery of the Flood Test
(http://www.nowcultured.com/images/2013/10/18-goofy-south-park-characters/hardly-boys-brothers-solving-mysteries.jpg)
I needed to lower the IQ of this thread to participate.
Indeed, mysteries abound around here it seems. I know I can't explain why I'm missing blocks today. What have I changed? This:
1) new binaries, looks like only 2 commits since last build yesterday morning (at least that's what git reported)
2) wiped everything except config.ini and cli wallet
What is different? This:
1) witness complained upon starting the new binary that it didn't have the signing keys listed in the config.ini, tho they weren't changed.
2) delegate.verbaltech appears to be missing every block.
That's all I know. Would appreciate any insight anybody might have that can explain this.
Did you build the latest master? And used release mode instead of debugging mode?
Thanks for the reply clayop.
I used the exact same process to build asI always do, which doesn't use debug mode, always fetches from master. Today's build finished at 9:22 CDT and only 2 new commits were incorporated, as I said previously. Any other ideas?
-
What is the output of your witness?
-
Thanks for the reply clayop.
I used the exact same process to build asI always do, which doesn't use debug mode, always fetches from master. Today's build finished at 9:22 CDT and only 2 new commits were incorporated, as I said previously. Any other ideas?
Have you tried restarting with the old binary and try to see the differences from the console log?
-
Recent witness output. What does the irreversible message indicate?
609200ms th_a application.cpp:394 handle_block ] Got block: #82384 time: 2015-10-08T17:10:09 latency: 197 ms from: init3 irreversible: 82359 (-25)
612313ms th_a application.cpp:394 handle_block ] Got block: #82385 time: 2015-10-08T17:10:12 latency: 310 ms from: bue irreversible: 82360 (-25)
618195ms th_a application.cpp:394 handle_block ] Got block: #82386 time: 2015-10-08T17:10:18 latency: 193 ms from: init10 irreversible: 82361 (-25)
621168ms th_a application.cpp:394 handle_block ] Got block: #82387 time: 2015-10-08T17:10:21 latency: 166 ms from: bitshares-argentina irreversible: 82362 (-25)
639346ms th_a application.cpp:394 handle_block ] Got block: #82392 time: 2015-10-08T17:10:39 latency: 344 ms from: xeldal irreversible: 82367 (-25)00141cd4896630ecde14ee302b91402b54b14b8","000141d1a0843adbfe97ac2bb9dd09972af2e06e","000141d3e35ca391661bb1a33c30d8c86aaf2bc9"]
627190ms th_a application.cpp:394 handle_block ] Got block: #82388 time: 2015-10-08T17:10:27 latency: 187 ms from: init2 irreversible: 82363 (-25)
630351ms th_a application.cpp:394 handle_block ] Got block: #82389 time: 2015-10-08T17:10:30 latency: 348 ms from: roadscape irreversible: 82364 (-25)
633198ms th_a application.cpp:394 handle_block ] Got block: #82390 time: 2015-10-08T17:10:33 latency: 195 ms from: init9 irreversible: 82365 (-25)
642055ms th_a application.cpp:394 handle_block ] Got block: #82393 time: 2015-10-08T17:10:42 latency: 52 ms from: bhuz irreversible: 82368 (-25)
Edit: Sorry for repost
-
is the "irreversible" output something it must noticed?
3173604ms th_a application.cpp:394 handle_block ] Got block: #75925 time: 2015-10-08T10:52:54 latency: -398 ms from: triox-delegate irreversible: 75892 (-33)
3180219ms th_a application.cpp:394 handle_block ] Got block: #75926 time: 2015-10-08T10:53:00 latency: 216 ms from: init10 irreversible: 75892 (-34)
3185689ms th_a application.cpp:394 handle_block ] Got block: #75927 time: 2015-10-08T10:53:06 latency: -313 ms from: delegate-1.lafona irreversible: 75893 (-34)
3189138ms th_a application.cpp:394 handle_block ] Got block: #75928 time: 2015-10-08T10:53:09 latency: 135 ms from: mindphlux.witness irreversible: 75893 (-35)
3192219ms th_a application.cpp:394 handle_block ] Got block: #75929 time: 2015-10-08T10:53:12 latency: 217 ms from: init2 irreversible: 75893 (-36)
3195793ms th_a application.cpp:394 handle_block ] Got block: #75930 time: 2015-10-08T10:53:15 latency: 790 ms from: fox irreversible: 75893 (-37)
3198140ms th_a application.cpp:394 handle_block ] Got block: #75931 time: 2015-10-08T10:53:18 latency: 137 ms from: jtm1 irreversible: 75893 (-38)
3201413ms th_a application.cpp:394 handle_block ] Got block: #75932 time: 2015-10-08T10:53:21 latency: 410 ms from: bitcube irreversible: 75894 (-38)
3204146ms th_a application.cpp:394 handle_block ] Got block: #75933 time: 2015-10-08T10:53:24 latency: 143 ms from: spectral irreversible: 75894 (-39)
3207154ms th_a applic
The irreversible block is the last block that your node has that has been confirmed by 2/3 of the witnesses. The "-X" represents how many blocks ago that was.
-
Flooding nodes are forked :'( I have to setup them again... I will notice the next test schedule soon.
-
100 TPS / 1 hour test will begin at 10/8 20:00 UTC (in 25 min)
-
Please hold off testing the current network. We are working on some things we would like to deploy before the next set of forks.
-
Please hold off testing the current network. We are working on some things we would like to deploy before the next set of forks.
Ok I stopped my servers.
-
I got a couples of:
getObjects without subscribe callback??
What is it?
-
dele-puppy will be intermittently missing blocks as I am testing a failover script.
-
Witness node crashed.
463719ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0001159f760df617a20b8b8091820f229d707e17, 71071
463719ms th_a fork_database.cpp:58 push_block ] Head: 71200, 00011620289c0a9af56a59ba52e88f1841fcc5bf
463719ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0001159efd84ad55e9ec8ececf862be1b33b5d40","timestamp":"2015-10-08T05:55:45","witness":"1.6.1","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f2d5c37139be7915ed09fe135a7364a97b3194ac66dfdfa273aa18b30c87d80fd39a12848c7ca16ad03305c376544d39bb469e8b88a18c758a6bc1023212d9fd8","transactions":[]}}
th_a db_block.cpp:197 _push_block
witness_node: /app/bts/graphene-test6.1/libraries/net/node.cpp:1594: void graphene::net::detail::node_impl::schedule_peer_for_deletion(const peer_connection_ptr&): Assertion `_closing_connections.find(peer_to_delete) == _closing_connections.end()' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff3581700 (LWP 7034)]
0x00007ffff6c01cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
-
I got a couples of:
getObjects without subscribe callback??
What is it?
Don't worry with that message.
The witness node logs that when there is no subscription and a getobject requirements comes in.
-
dele-puppy will be intermittently missing blocks as I am testing a failover script.
Im interested in that script, will you make it public?
-
here is my automatic failover script powered by xerocs python-graphenelib. I am a noob at teh programming, and if I did anything wrong I would love the feedback.
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys
import json
from grapheneapi import GrapheneWebsocket, GrapheneWebsocketProtocol
import time
import config
rpc = GrapheneWebsocket("localhost", 8092, "", "")
publickeys = config.publickeys
witnessname = config.witnessname
def getmissed(witnessname):
witness = rpc.get_witness(witnessname)
missed = witness["total_missed"]
return missed
missed = getmissed(config.witnessname)
def switch(witnessname, publickeys, missed):
keynumber = missed % len(publickeys)
key = publickeys[keynumber]
rpc.update_witness(witnessname, "", key, "true")
print("witness down switching to " + key)
print ("Nothing in this window will change unless a block is missed")
while True:
if missed < getmissed(config.witnessname):
missed = getmissed(config.witnessname)
switch(witnessname, publickeys, missed)
else:
time.sleep(3)
You need to add two lines to your config.py file. witnessname as a string and publickeys as strings in a tuple of the public keys you want to switch between. those lines look like this in my case.
witnessname = "dele-puppy"
publickeys = ("GPH75xxKG4ZeztPpnhmFch99smunUWMvDy9mB6Le497vpAA3XUXaD", "GPH8Sj81ncf8PK5QwJZvhWsvwp6m4bXzTFvp4bKycNNFvHaJpZSnH")
The wallet this script is running through needs to be unlocked, and must contain the owner key (I think its the owner key, rather than the active key) of the witness.
-
Every day so many witnesses are not online, what is the reason?
We've identified an issue where the assignment of new object ID's is inconsistent (we use a hashed index with an undefined iteration order). Fortunately the testnet's main fork has them in increasing order (I suspect it has to do with the memory allocator tending to put things allocated later at higher addresses), in the next hardfork this condition will be enforced (by replacing most of our hashed indexes with ordered indexes). We suspect some witnesses are getting their state wrong when they assign an ID differently from the main network, if someone publishes a transaction using that ID then the wrong state turns into a desync (they'll no longer sign or pay attention to blocks on the main fork because they think the main fork has an illegal transaction.)
If you get stuck and the first error message mentions a vesting balance object, this is almost certainly what's happening to you.
The next hardfork will fix this issue, and in addition, I'm working on a tool to help us find if there are any similar issues.
The transactions being executed by the community testers have been incredibly helpful to us.
-
here is my automatic failover script powered by xerocs python-graphenelib. I am a noob at teh programming, and if I did anything wrong I would love the feedback.
The wallet this script is running through needs to be unlocked, and must contain the owner key (I think its the owner key, rather than the active key) of the witness.
Awesome! This gives me an idea for an "industrial strength" version.
The active key should be sufficient.
-
My observer node got out of sync as well.
3194926ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 00011598c1a67b75aca7dc775fcc5b782ca0b7ff, 71064
3194926ms th_a fork_database.cpp:58 push_block ] Head: 71282, 00011672235d57fc149ead58202df2cf641d3d303194926ms th_a application.cpp:422 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"00011597d7e7e8b0cd788f563e024a0f9ce9e686","timestamp":"2015-10-08T05:55:15","witness":"1.6.26","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f729beb5475b4d0f378f0e8bf7420404d88b765b4a507ac38f1989e6ca23c62940987e48052760d61ef2fe387d99af55fe6f3f1f0760675418d08bf8c659f2d15","transactions":[]}}
th_a db_block.cpp:197 _push_block
...
...
3480154ms th_a application.cpp:522 get_item ] Couldn't find block 000114d83dc5f7ad03d3c90fbdc74d1d6d3e2288 -- corresponding ID in our chain is 000114d83dc5f7ad03d3c90fbdc74d1d6d3e2288
Looks like it's stuck at the fork produced by delegate.baozi ???
-
We have successfully managed to resolve a number of issues without requiring the test network to be reset. Please upgrade to the latest master branch and verify that you can still sync.
Issues Resolved:
1. Replaced Hash Indexes with Ordered Indexes because there are places where we iterate over the Hash Index and the iteration order was not deterministic
2. Fix reference to deleted memory during margin call evaluation
3. Cover some corner cases for rational math overflows
4. Fix for publishing invalid price feeds
-
My observer node got out of sync as well.
Looks like it's stuck at the fork produced by delegate.baozi ???
Caused by:
2015-10-08T05:43:09 th_a:invoke handle_block handle_block ] Got block: #70871 time: 2015-10-08T05:43:09 latency: 573 ms from:
elmato irreversible: 70846 (-25) application.cpp:394
2015-10-08T05:43:13 th_a:invoke handle_transaction handle_transaction ] Got transaction from network application.cp
p:438
2015-10-08T05:43:15 th_a:invoke handle_block handle_block ] Got block: #70872 time: 2015-10-08T05:43:15 latency: 398 ms from: init9 irreversible: 70847 (-25) application.cpp:394
2015-10-08T05:43:15 th_a:invoke handle_block _push_block ] Failed to push new block:
10 assert_exception: Assert Exception
vbo.is_withdraw_allowed( now, op.amount ):
{"now":"2015-10-08T05:43:09","op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}},"vbo":{"id":"1.13.60","owner":"1.2.8517","balance":{"amount":197500000,"asset_id":"1.3.0"},"policy":[1,{"vesting_seconds":86400,"start_claim":"1970-01-01T00:00:00","coin_seconds_earned":"3341610000000","coin_seconds_earned_last_update":"2015-10-08T05:43:06"}]}}
th_a vesting_balance_evaluator.cpp:103 do_evaluate
{"op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}}
th_a vesting_balance_evaluator.cpp:109 do_evaluate
{}
th_a evaluator.cpp:42 start_evaluate
{}
th_a db_block.cpp:625 apply_operation
{"trx":{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"]}}
th_a db_block.cpp:608 _apply_transaction
{"next_block.block_num()":70872}
th_a db_block.cpp:511 _apply_block db_block.cpp:191
-
We have successfully managed to resolve a number of issues without requiring the test network to be reset. Please upgrade to the latest master branch and verify that you can still sync.
Issues Resolved:
1. Replaced Hash Indexes with Ordered Indexes because there are places where we iterate over the Hash Index and the iteration order was not deterministic
2. Fix reference to deleted memory during margin call evaluation
3. Cover some corner cases for rational math overflows
4. Fix for publishing invalid price feeds
Wow.. lots of updates.
Rebuilding.
-
here is my automatic failover script powered by xerocs python-graphenelib. I am a noob at teh programming, and if I did anything wrong I would love the feedback.
The wallet this script is running through needs to be unlocked, and must contain the owner key (I think its the owner key, rather than the active key) of the witness.
Awesome! This gives me an idea for an "industrial strength" version.
The active key should be sufficient.
Thanks theoretical. Its nice to be able to contribute.
-
can't switch to correct chain, even restart witness_node(build from bfef440968e98219612a9bbd24e715e8835ad975),
get block 70872, but failed to push sync block
here is the error message from log file:
2015-10-08T06:31:23 p2p:send_sync_block_to_node_delegate send_sync_block_to_n ] Failed to push sync block 70872 (id:000114d879ab3c305edeaaae837c2b68b7da64d2): client rejected sync block sent by peer: {"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"vesting_balance_evalu ator.cpp","line":103,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"vbo.is_withdraw_allowed( now, op.amount ): ","data":{"now":"2015-10-08T05:43:09","op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"as set_id":"1.3.0"}},"vbo":{"id":"1.13.60","owner":"1.2.8517","balance":{"amount":202500000,"asset_id":"1.3.0"},"policy":[1,{"vesting_seconds":86400,"start_claim":"1970- 01-01T00:00:00","coin_seconds_earned":"3290619000000","coin_seconds_earned_last_update":"2015-10-08T05:43:06"}]}}},{"context":{"level":"warn","file":"vesting_balance_ evaluator.cpp","line":109,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"","data":{"op":{"fee":{"amount":10000 0,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}}},{"context":{"level":"warn","file":"evaluator.c pp","line":42,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"","data":{}},{"context":{"level":"warn","file" :"db_block.cpp","line":625,"method":"apply_operation","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"","data":{}},{"context":{"level" :"warn","file":"db_block.cpp","line":608,"method":"_apply_transaction","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"","data":{"trx" :{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance ":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a0 0d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"]}}},{"context":{"level":"warn","file":"db_block.cpp","line":511,"method":"_apply_block" ,"hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"","data":{"next_block.block_num()":70872}},{"context":{"level":"warn","file":"db_bloc k.cpp","line":197,"method":"_push_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"","data":{"new_block":{"previous":"000114d73b cdebf717450d1a45e7ea119844b22e","timestamp":"2015-10-08T05:43:15","witness":"1.6.10","transaction_merkle_root":"05b459df123ff6baf5dbc44890e6ae3e8a8caaf6","extensions" :[],"witness_signature":"20232fc2bb2ead0cbc644d78e4462881dc812787ad28f1517229cc346c252acb2904cb13139a8e957c8087d8b03790f12f5c2ef0dbb2cfceead7a47521f75f0950","transact ions":[{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_b alance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b25050 7262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"],"operation_results":[[0,{}]]}]}}},{"context":{"level":"warn","file":"application .cpp","line":434,"method":"handle_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T06:31:23"},"format":"","data":{"blk_msg":{"block":{"previous":"000 114d73bcdebf717450d1a45e7ea119844b22e","timestamp":"2015-10-08T05:43:15","witness":"1.6.10","transaction_merkle_root":"05b459df123ff6baf5dbc44890e6ae3e8a8caaf6","exte nsions":[],"witness_signature":"20232fc2bb2ead0cbc644d78e4462881dc812787ad28f1517229cc346c252acb2904cb13139a8e957c8087d8b03790f12f5c2ef0dbb2cfceead7a47521f75f0950","t ransactions":[{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"ve sting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af1 1b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"],"operation_results":[[0,{}]]}]},"block_id":"000114d879ab3c305edeaaae837c2 b68b7da64d2"},"sync_mode":true}}]} node.cpp:3017
output from console
1883626ms th_a db_block.cpp:191 _push_block ] Failed to push new block:
10 assert_exception: Assert Exception
vbo.is_withdraw_allowed( now, op.amount ):
{"now":"2015-10-08T05:43:09","op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":
"1.3.0"}},"vbo":{"id":"1.13.60","owner":"1.2.8517","balance":{"amount":202500000,"asset_id":"1.3.0"},"policy":[1,{"vesting_seconds":86400,"start_claim":"1970-01-01T00:0
0:00","coin_seconds_earned":"3290619000000","coin_seconds_earned_last_update":"2015-10-08T05:43:06"}]}}
th_a vesting_balance_evaluator.cpp:103 do_evaluate
{"op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}}
th_a vesting_balance_evaluator.cpp:109 do_evaluate
{}
th_a evaluator.cpp:42 start_evaluate
{}
th_a db_block.cpp:625 apply_operation
{"trx":{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting
_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b25050
7262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"]}}
th_a db_block.cpp:608 _apply_transaction
{"next_block.block_num()":70872}
th_a db_block.cpp:511 _apply_block
Same issue here. My build was bfef440968e98219612a9bbd24e715e8835ad975 "fork_database.cpp: Fix overflow".
delegate.baozi, in.abit and delegate-clayop were on the same fork.
Anyway I'm rebuilding with latest commit now. It should be fixed by this:
Every day so many witnesses are not online, what is the reason?
We've identified an issue where the assignment of new object ID's is inconsistent (we use a hashed index with an undefined iteration order). Fortunately the testnet's main fork has them in increasing order (I suspect it has to do with the memory allocator tending to put things allocated later at higher addresses), in the next hardfork this condition will be enforced (by replacing most of our hashed indexes with ordered indexes). We suspect some witnesses are getting their state wrong when they assign an ID differently from the main network, if someone publishes a transaction using that ID then the wrong state turns into a desync (they'll no longer sign or pay attention to blocks on the main fork because they think the main fork has an illegal transaction.)
If you get stuck and the first error message mentions a vesting balance object, this is almost certainly what's happening to you.
The next hardfork will fix this issue, and in addition, I'm working on a tool to help us find if there are any similar issues.
The transactions being executed by the community testers have been incredibly helpful to us.
-
Building...
When is the next hardfork?
-
Building...
When is the next hardfork?
About 20 hours from now.
-
Every day so many witnesses are not online, what is the reason?
We've identified an issue where the assignment of new object ID's is inconsistent (we use a hashed index with an undefined iteration order). Fortunately the testnet's main fork has them in increasing order (I suspect it has to do with the memory allocator tending to put things allocated later at higher addresses), in the next hardfork this condition will be enforced (by replacing most of our hashed indexes with ordered indexes). We suspect some witnesses are getting their state wrong when they assign an ID differently from the main network, if someone publishes a transaction using that ID then the wrong state turns into a desync (they'll no longer sign or pay attention to blocks on the main fork because they think the main fork has an illegal transaction.)
If you get stuck and the first error message mentions a vesting balance object, this is almost certainly what's happening to you.
The next hardfork will fix this issue, and in addition, I'm working on a tool to help us find if there are any similar issues.
The transactions being executed by the community testers have been incredibly helpful to us.
Running with latest commit (e68e99ed3ae11ddac607e983e7549e8278fdecc4), but it can't go over block 70872
2015-10-08T21:37:17 p2p:send_sync_block_to_node_delegate send_sync_block_to_n ] Failed to push sync block 70872 (id:000114d879ab3c305edeaaae837c2b68b7da64d2): client rejected sync block sent by peer: {"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"vesting_balance_evaluator.cpp","line":103,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"vbo.is_withdraw_allowed( now, op.amount ): ","data":{"now":"2015-10-08T05:43:09","op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}},"vbo":{"id":"1.13.60","owner":"1.2.8517","balance":{"amount":197500000,"asset_id":"1.3.0"},"policy":[1,{"vesting_seconds":86400,"start_claim":"1970-01-01T00:00:00","coin_seconds_earned":"3341610000000","coin_seconds_earned_last_update":"2015-10-08T05:43:06"}]}}},{"context":{"level":"warn","file":"vesting_balance_evaluator.cpp","line":109,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}}},{"context":{"level":"warn","file":"evaluator.cpp","line":42,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":628,"method":"apply_operation","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":611,"method":"_apply_transaction","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"trx":{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"]}}},{"context":{"level":"warn","file":"db_block.cpp","line":514,"method":"_apply_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"next_block.block_num()":70872}},{"context":{"level":"warn","file":"db_block.cpp","line":197,"method":"_push_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"new_block":{"previous":"000114d73bcdebf717450d1a45e7ea119844b22e","timestamp":"2015-10-08T05:43:15","witness":"1.6.10","transaction_merkle_root":"05b459df123ff6baf5dbc44890e6ae3e8a8caaf6","extensions":[],"witness_signature":"20232fc2bb2ead0cbc644d78e4462881dc812787ad28f1517229cc346c252acb2904cb13139a8e957c8087d8b03790f12f5c2ef0dbb2cfceead7a47521f75f0950","transactions":[{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"],"operation_results":[[0,{}]]}]}}},{"context":{"level":"warn","file":"application.cpp","line":441,"method":"handle_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"blk_msg":{"block":{"previous":"000114d73bcdebf717450d1a45e7ea119844b22e","timestamp":"2015-10-08T05:43:15","witness":"1.6.10","transaction_merkle_root":"05b459df123ff6baf5dbc44890e6ae3e8a8caaf6","extensions":[],"witness_signature":"20232fc2bb2ead0cbc644d78e4462881dc812787ad28f1517229cc346c252acb2904cb13139a8e957c8087d8b03790f12f5c2ef0dbb2cfceead7a47521f75f0950","transactions":[{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"],"operation_results":[[0,{}]]}]},"block_id":"000114d879ab3c305edeaaae837c2b68b7da64d2"},"sync_mode":true}}]} node.cpp:3043
2015-10-08T21:37:17 p2p:send_sync_block_to_node_delegate send_sync_block_to_n ] disconnecting client 104.236.51.238:2005 because it offered us the rejected block node.cpp:3157
-
Every day so many witnesses are not online, what is the reason?
We've identified an issue where the assignment of new object ID's is inconsistent (we use a hashed index with an undefined iteration order). Fortunately the testnet's main fork has them in increasing order (I suspect it has to do with the memory allocator tending to put things allocated later at higher addresses), in the next hardfork this condition will be enforced (by replacing most of our hashed indexes with ordered indexes). We suspect some witnesses are getting their state wrong when they assign an ID differently from the main network, if someone publishes a transaction using that ID then the wrong state turns into a desync (they'll no longer sign or pay attention to blocks on the main fork because they think the main fork has an illegal transaction.)
If you get stuck and the first error message mentions a vesting balance object, this is almost certainly what's happening to you.
The next hardfork will fix this issue, and in addition, I'm working on a tool to help us find if there are any similar issues.
The transactions being executed by the community testers have been incredibly helpful to us.
Running with latest commit (e68e99ed3ae11ddac607e983e7549e8278fdecc4), but it can't go over block 70872
2015-10-08T21:37:17 p2p:send_sync_block_to_node_delegate send_sync_block_to_n ] Failed to push sync block 70872 (id:000114d879ab3c305edeaaae837c2b68b7da64d2): client rejected sync block sent by peer: {"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"vesting_balance_evaluator.cpp","line":103,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"vbo.is_withdraw_allowed( now, op.amount ): ","data":{"now":"2015-10-08T05:43:09","op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}},"vbo":{"id":"1.13.60","owner":"1.2.8517","balance":{"amount":197500000,"asset_id":"1.3.0"},"policy":[1,{"vesting_seconds":86400,"start_claim":"1970-01-01T00:00:00","coin_seconds_earned":"3341610000000","coin_seconds_earned_last_update":"2015-10-08T05:43:06"}]}}},{"context":{"level":"warn","file":"vesting_balance_evaluator.cpp","line":109,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}}},{"context":{"level":"warn","file":"evaluator.cpp","line":42,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":628,"method":"apply_operation","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":611,"method":"_apply_transaction","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"trx":{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"]}}},{"context":{"level":"warn","file":"db_block.cpp","line":514,"method":"_apply_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"next_block.block_num()":70872}},{"context":{"level":"warn","file":"db_block.cpp","line":197,"method":"_push_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"new_block":{"previous":"000114d73bcdebf717450d1a45e7ea119844b22e","timestamp":"2015-10-08T05:43:15","witness":"1.6.10","transaction_merkle_root":"05b459df123ff6baf5dbc44890e6ae3e8a8caaf6","extensions":[],"witness_signature":"20232fc2bb2ead0cbc644d78e4462881dc812787ad28f1517229cc346c252acb2904cb13139a8e957c8087d8b03790f12f5c2ef0dbb2cfceead7a47521f75f0950","transactions":[{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"],"operation_results":[[0,{}]]}]}}},{"context":{"level":"warn","file":"application.cpp","line":441,"method":"handle_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"blk_msg":{"block":{"previous":"000114d73bcdebf717450d1a45e7ea119844b22e","timestamp":"2015-10-08T05:43:15","witness":"1.6.10","transaction_merkle_root":"05b459df123ff6baf5dbc44890e6ae3e8a8caaf6","extensions":[],"witness_signature":"20232fc2bb2ead0cbc644d78e4462881dc812787ad28f1517229cc346c252acb2904cb13139a8e957c8087d8b03790f12f5c2ef0dbb2cfceead7a47521f75f0950","transactions":[{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"],"operation_results":[[0,{}]]}]},"block_id":"000114d879ab3c305edeaaae837c2b68b7da64d2"},"sync_mode":true}}]} node.cpp:3043
2015-10-08T21:37:17 p2p:send_sync_block_to_node_delegate send_sync_block_to_n ] disconnecting client 104.236.51.238:2005 because it offered us the rejected block node.cpp:3157
Did you do --replay-blockchain? What OS?
-
Every day so many witnesses are not online, what is the reason?
We've identified an issue where the assignment of new object ID's is inconsistent (we use a hashed index with an undefined iteration order). Fortunately the testnet's main fork has them in increasing order (I suspect it has to do with the memory allocator tending to put things allocated later at higher addresses), in the next hardfork this condition will be enforced (by replacing most of our hashed indexes with ordered indexes). We suspect some witnesses are getting their state wrong when they assign an ID differently from the main network, if someone publishes a transaction using that ID then the wrong state turns into a desync (they'll no longer sign or pay attention to blocks on the main fork because they think the main fork has an illegal transaction.)
If you get stuck and the first error message mentions a vesting balance object, this is almost certainly what's happening to you.
The next hardfork will fix this issue, and in addition, I'm working on a tool to help us find if there are any similar issues.
The transactions being executed by the community testers have been incredibly helpful to us.
Running with latest commit (e68e99ed3ae11ddac607e983e7549e8278fdecc4), but it can't go over block 70872
2015-10-08T21:37:17 p2p:send_sync_block_to_node_delegate send_sync_block_to_n ] Failed to push sync block 70872 (id:000114d879ab3c305edeaaae837c2b68b7da64d2): client rejected sync block sent by peer: {"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"vesting_balance_evaluator.cpp","line":103,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"vbo.is_withdraw_allowed( now, op.amount ): ","data":{"now":"2015-10-08T05:43:09","op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}},"vbo":{"id":"1.13.60","owner":"1.2.8517","balance":{"amount":197500000,"asset_id":"1.3.0"},"policy":[1,{"vesting_seconds":86400,"start_claim":"1970-01-01T00:00:00","coin_seconds_earned":"3341610000000","coin_seconds_earned_last_update":"2015-10-08T05:43:06"}]}}},{"context":{"level":"warn","file":"vesting_balance_evaluator.cpp","line":109,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}}},{"context":{"level":"warn","file":"evaluator.cpp","line":42,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":628,"method":"apply_operation","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":611,"method":"_apply_transaction","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"trx":{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"]}}},{"context":{"level":"warn","file":"db_block.cpp","line":514,"method":"_apply_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"next_block.block_num()":70872}},{"context":{"level":"warn","file":"db_block.cpp","line":197,"method":"_push_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"new_block":{"previous":"000114d73bcdebf717450d1a45e7ea119844b22e","timestamp":"2015-10-08T05:43:15","witness":"1.6.10","transaction_merkle_root":"05b459df123ff6baf5dbc44890e6ae3e8a8caaf6","extensions":[],"witness_signature":"20232fc2bb2ead0cbc644d78e4462881dc812787ad28f1517229cc346c252acb2904cb13139a8e957c8087d8b03790f12f5c2ef0dbb2cfceead7a47521f75f0950","transactions":[{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"],"operation_results":[[0,{}]]}]}}},{"context":{"level":"warn","file":"application.cpp","line":441,"method":"handle_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"blk_msg":{"block":{"previous":"000114d73bcdebf717450d1a45e7ea119844b22e","timestamp":"2015-10-08T05:43:15","witness":"1.6.10","transaction_merkle_root":"05b459df123ff6baf5dbc44890e6ae3e8a8caaf6","extensions":[],"witness_signature":"20232fc2bb2ead0cbc644d78e4462881dc812787ad28f1517229cc346c252acb2904cb13139a8e957c8087d8b03790f12f5c2ef0dbb2cfceead7a47521f75f0950","transactions":[{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"],"operation_results":[[0,{}]]}]},"block_id":"000114d879ab3c305edeaaae837c2b68b7da64d2"},"sync_mode":true}}]} node.cpp:3043
2015-10-08T21:37:17 p2p:send_sync_block_to_node_delegate send_sync_block_to_n ] disconnecting client 104.236.51.238:2005 because it offered us the rejected block node.cpp:3157
Did you do --replay-blockchain? What OS?
I was running with a backup chain folder which is created about 16 hours ago, so I don't think it's need to replay.
Ubuntu 14.04 LTS 64 bit.
Linux 3.16.0-44-generic #59~14.04.1-Ubuntu SMP Tue Jul 7 15:07:27 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Anyway I'll try replay.
-
Every day so many witnesses are not online, what is the reason?
We've identified an issue where the assignment of new object ID's is inconsistent (we use a hashed index with an undefined iteration order). Fortunately the testnet's main fork has them in increasing order (I suspect it has to do with the memory allocator tending to put things allocated later at higher addresses), in the next hardfork this condition will be enforced (by replacing most of our hashed indexes with ordered indexes). We suspect some witnesses are getting their state wrong when they assign an ID differently from the main network, if someone publishes a transaction using that ID then the wrong state turns into a desync (they'll no longer sign or pay attention to blocks on the main fork because they think the main fork has an illegal transaction.)
If you get stuck and the first error message mentions a vesting balance object, this is almost certainly what's happening to you.
The next hardfork will fix this issue, and in addition, I'm working on a tool to help us find if there are any similar issues.
The transactions being executed by the community testers have been incredibly helpful to us.
Running with latest commit (e68e99ed3ae11ddac607e983e7549e8278fdecc4), but it can't go over block 70872
2015-10-08T21:37:17 p2p:send_sync_block_to_node_delegate send_sync_block_to_n ] Failed to push sync block 70872 (id:000114d879ab3c305edeaaae837c2b68b7da64d2): client rejected sync block sent by peer: {"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"vesting_balance_evaluator.cpp","line":103,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"vbo.is_withdraw_allowed( now, op.amount ): ","data":{"now":"2015-10-08T05:43:09","op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}},"vbo":{"id":"1.13.60","owner":"1.2.8517","balance":{"amount":197500000,"asset_id":"1.3.0"},"policy":[1,{"vesting_seconds":86400,"start_claim":"1970-01-01T00:00:00","coin_seconds_earned":"3341610000000","coin_seconds_earned_last_update":"2015-10-08T05:43:06"}]}}},{"context":{"level":"warn","file":"vesting_balance_evaluator.cpp","line":109,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}}},{"context":{"level":"warn","file":"evaluator.cpp","line":42,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":628,"method":"apply_operation","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":611,"method":"_apply_transaction","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"trx":{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"]}}},{"context":{"level":"warn","file":"db_block.cpp","line":514,"method":"_apply_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"next_block.block_num()":70872}},{"context":{"level":"warn","file":"db_block.cpp","line":197,"method":"_push_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"new_block":{"previous":"000114d73bcdebf717450d1a45e7ea119844b22e","timestamp":"2015-10-08T05:43:15","witness":"1.6.10","transaction_merkle_root":"05b459df123ff6baf5dbc44890e6ae3e8a8caaf6","extensions":[],"witness_signature":"20232fc2bb2ead0cbc644d78e4462881dc812787ad28f1517229cc346c252acb2904cb13139a8e957c8087d8b03790f12f5c2ef0dbb2cfceead7a47521f75f0950","transactions":[{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"],"operation_results":[[0,{}]]}]}}},{"context":{"level":"warn","file":"application.cpp","line":441,"method":"handle_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"blk_msg":{"block":{"previous":"000114d73bcdebf717450d1a45e7ea119844b22e","timestamp":"2015-10-08T05:43:15","witness":"1.6.10","transaction_merkle_root":"05b459df123ff6baf5dbc44890e6ae3e8a8caaf6","extensions":[],"witness_signature":"20232fc2bb2ead0cbc644d78e4462881dc812787ad28f1517229cc346c252acb2904cb13139a8e957c8087d8b03790f12f5c2ef0dbb2cfceead7a47521f75f0950","transactions":[{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"],"operation_results":[[0,{}]]}]},"block_id":"000114d879ab3c305edeaaae837c2b68b7da64d2"},"sync_mode":true}}]} node.cpp:3043
2015-10-08T21:37:17 p2p:send_sync_block_to_node_delegate send_sync_block_to_n ] disconnecting client 104.236.51.238:2005 because it offered us the rejected block node.cpp:3157
Did you do --replay-blockchain? What OS?
I was running with a backup chain folder which is created about 16 hours ago, so I don't think it's need to replay.
Ubuntu 14.04 LTS 64 bit.
Linux 3.16.0-44-generic #59~14.04.1-Ubuntu SMP Tue Jul 7 15:07:27 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
It absolutely needs to replay because prior to the last hour or two the master branch was producing non-deterministic ID allocation and your old backup probably imported that.
-
Every day so many witnesses are not online, what is the reason?
We've identified an issue where the assignment of new object ID's is inconsistent (we use a hashed index with an undefined iteration order). Fortunately the testnet's main fork has them in increasing order (I suspect it has to do with the memory allocator tending to put things allocated later at higher addresses), in the next hardfork this condition will be enforced (by replacing most of our hashed indexes with ordered indexes). We suspect some witnesses are getting their state wrong when they assign an ID differently from the main network, if someone publishes a transaction using that ID then the wrong state turns into a desync (they'll no longer sign or pay attention to blocks on the main fork because they think the main fork has an illegal transaction.)
If you get stuck and the first error message mentions a vesting balance object, this is almost certainly what's happening to you.
The next hardfork will fix this issue, and in addition, I'm working on a tool to help us find if there are any similar issues.
The transactions being executed by the community testers have been incredibly helpful to us.
Running with latest commit (e68e99ed3ae11ddac607e983e7549e8278fdecc4), but it can't go over block 70872
2015-10-08T21:37:17 p2p:send_sync_block_to_node_delegate send_sync_block_to_n ] Failed to push sync block 70872 (id:000114d879ab3c305edeaaae837c2b68b7da64d2): client rejected sync block sent by peer: {"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"vesting_balance_evaluator.cpp","line":103,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"vbo.is_withdraw_allowed( now, op.amount ): ","data":{"now":"2015-10-08T05:43:09","op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}},"vbo":{"id":"1.13.60","owner":"1.2.8517","balance":{"amount":197500000,"asset_id":"1.3.0"},"policy":[1,{"vesting_seconds":86400,"start_claim":"1970-01-01T00:00:00","coin_seconds_earned":"3341610000000","coin_seconds_earned_last_update":"2015-10-08T05:43:06"}]}}},{"context":{"level":"warn","file":"vesting_balance_evaluator.cpp","line":109,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}}},{"context":{"level":"warn","file":"evaluator.cpp","line":42,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":628,"method":"apply_operation","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":611,"method":"_apply_transaction","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"trx":{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"]}}},{"context":{"level":"warn","file":"db_block.cpp","line":514,"method":"_apply_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"next_block.block_num()":70872}},{"context":{"level":"warn","file":"db_block.cpp","line":197,"method":"_push_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"new_block":{"previous":"000114d73bcdebf717450d1a45e7ea119844b22e","timestamp":"2015-10-08T05:43:15","witness":"1.6.10","transaction_merkle_root":"05b459df123ff6baf5dbc44890e6ae3e8a8caaf6","extensions":[],"witness_signature":"20232fc2bb2ead0cbc644d78e4462881dc812787ad28f1517229cc346c252acb2904cb13139a8e957c8087d8b03790f12f5c2ef0dbb2cfceead7a47521f75f0950","transactions":[{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"],"operation_results":[[0,{}]]}]}}},{"context":{"level":"warn","file":"application.cpp","line":441,"method":"handle_block","hostname":"","thread_name":"th_a","timestamp":"2015-10-08T21:37:17"},"format":"","data":{"blk_msg":{"block":{"previous":"000114d73bcdebf717450d1a45e7ea119844b22e","timestamp":"2015-10-08T05:43:15","witness":"1.6.10","transaction_merkle_root":"05b459df123ff6baf5dbc44890e6ae3e8a8caaf6","extensions":[],"witness_signature":"20232fc2bb2ead0cbc644d78e4462881dc812787ad28f1517229cc346c252acb2904cb13139a8e957c8087d8b03790f12f5c2ef0dbb2cfceead7a47521f75f0950","transactions":[{"ref_block_num":5335,"ref_block_prefix":4159425851,"expiration":"2015-10-08T05:43:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":45300000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["1f6f7ea6a4188c8fc36aaf457b5fe4433fb74af11b250507262a00d909af025ad065c03ef0f61925070489d1630a3fbe459795b265200544de9ba1694414fefbcf"],"operation_results":[[0,{}]]}]},"block_id":"000114d879ab3c305edeaaae837c2b68b7da64d2"},"sync_mode":true}}]} node.cpp:3043
2015-10-08T21:37:17 p2p:send_sync_block_to_node_delegate send_sync_block_to_n ] disconnecting client 104.236.51.238:2005 because it offered us the rejected block node.cpp:3157
Did you do --replay-blockchain? What OS?
I was running with a backup chain folder which is created about 16 hours ago, so I don't think it's need to replay.
Ubuntu 14.04 LTS 64 bit.
Linux 3.16.0-44-generic #59~14.04.1-Ubuntu SMP Tue Jul 7 15:07:27 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
It absolutely needs to replay because prior to the last hour or two the master branch was producing non-deterministic ID allocation and your old backup probably imported that.
The backup is at block 65916. Replaying.
//Update:
in sync now.
It took 67 seconds to replay a 87261-block chain.
-
I can replay it on my machine in:
456696ms th_a db_management.cpp:93 reindex ] Done reindexing, elapsed time: 6.88446099999999994 sec
-
I can replay it on my machine in:
456696ms th_a db_management.cpp:93 reindex ] Done reindexing, elapsed time: 6.88446099999999994 sec
I built with -DCMAKE_BUILD_TYPE=Debug, that would be the reason.
-
I can replay it on my machine in:
456696ms th_a db_management.cpp:93 reindex ] Done reindexing, elapsed time: 6.88446099999999994 sec
I built with -DCMAKE_BUILD_TYPE=Debug, that would be the reason.
:-[
-
spartako and spartako_bot (for witness notification) updated to latest master
-
delegate-clayop updated to the latest master
-
delegate.ihashfury and nodes updated to latest master
running on x64, i686 and ARM
Cubox is still keeping up and publishing price feeds :)
Awesome coding 8)
-
witness spectral is up-to-date
-
delegate.baozi update
-
Does everyone need to be updated?mine only missed one block since last update
-
Does everyone need to be updated?mine only missed one block since last update
Yes, there will be an hardfork in about 17 hours.
bhuz on latest master, publishing feeds
-
delegate-1.lafona on latest master and publishing feeds
-
2 quick graphene questions:
1) How do you shutdown cleanly
2) How do you export a wallet for use on another node?
-
witness updated.
replayed 91924 blocks in 20.7 seconds : )
97.907% 90000 of 91924
3551919ms th_a db_management.cpp:93 reindex ] Done reindexing, elapsed time: 20.73896500000000032 sec
@puppies your failover script worked great, instantly switched block production to backup node on first missed block.
-
bitcube updated to latest.
-
here is my automatic failover script powered by xerocs python-graphenelib. I am a noob at teh programming, and if I did anything wrong I would love the feedback.
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys
import json
from grapheneapi import GrapheneWebsocket, GrapheneWebsocketProtocol
import time
import config
rpc = GrapheneWebsocket("localhost", 8092, "", "")
publickeys = config.publickeys
witnessname = config.witnessname
def getmissed(witnessname):
witness = rpc.get_witness(witnessname)
missed = witness["total_missed"]
return missed
missed = getmissed(config.witnessname)
def switch(witnessname, publickeys, missed):
keynumber = missed % len(publickeys)
key = publickeys[keynumber]
rpc.update_witness(witnessname, "", key, "true")
print("witness down switching to " + key)
print ("Nothing in this window will change unless a block is missed")
while True:
if missed < getmissed(config.witnessname):
missed = getmissed(config.witnessname)
switch(witnessname, publickeys, missed)
else:
time.sleep(3)
You need to add two lines to your config.py file. witnessname as a string and publickeys as strings in a tuple of the public keys you want to switch between. those lines look like this in my case.
witnessname = "dele-puppy"
publickeys = ("GPH75xxKG4ZeztPpnhmFch99smunUWMvDy9mB6Le497vpAA3XUXaD", "GPH8Sj81ncf8PK5QwJZvhWsvwp6m4bXzTFvp4bKycNNFvHaJpZSnH")
The wallet this script is running through needs to be unlocked, and must contain the owner key (I think its the owner key, rather than the active key) of the witness.
Nice!
-
Sorry, neglected to post earlier: nodes are updated.
-
I'm planning 100 TPS test at 10/9 21:00 (about 4 hours after the next hardfork). Is it reasonable?
-
mr.agsexplorer is updated to latest master
needs to be voted in
-
After upgrading, I'm unable to download blocks - I deleted all data dirs etc to be sure, used --resync-blockchain etc too.
It's stuck at
482000ms th_a witness.cpp:179 block_production_loo ] Not producing block because production is disabled until we receive a recent block (see: --enable-stale-production)
Is the seednode not sending blocks? Is there another seed node I can try?
-
After upgrading, I'm unable to download blocks - I deleted all data dirs etc to be sure, used --resync-blockchain etc too.
It's stuck at
482000ms th_a witness.cpp:179 block_production_loo ] Not producing block because production is disabled until we receive a recent block (see: --enable-stale-production)
Is the seednode not sending blocks? Is there another seed node I can try?
Try resync blocks without block production. After fully synced, restart witness node with block production option.
-
elmato updated to latest master
-
Try resync blocks without block production. After fully synced, restart witness node with block production option.
Tried that too, no blocks are coming my way.
-
After upgrading, I'm unable to download blocks - I deleted all data dirs etc to be sure, used --resync-blockchain etc too.
It's stuck at
482000ms th_a witness.cpp:179 block_production_loo ] Not producing block because production is disabled until we receive a recent block (see: --enable-stale-production)
Is the seednode not sending blocks? Is there another seed node I can try?
seednode is fine, just synced from it quite quickly. But I'm not yet on latest master.
-
It didn't work for me. I had to choose another peer node to sync from, I guess the seed node is not on the latest master yet maybe.
mindphlux.witness is back up & on the latest master.
-
It didn't work for me. I had to choose another peer node to sync from, I guess the seed node is not on the latest master yet maybe.
mindphlux.witness is back up & on the latest master.
I helped mindphlux searching a new seed node in my logs, I tried the network_get_connected_peers command but give me a permission error probably because it is a restricted API (I will try to specify apiaccess file in config.ini)
-
I have my main node getting blocks from the seednode, and a backup node being rejected from the same seed. Both nodes updated to last master. This is the log from the one out of sync:
2015-10-09T07:09:26 p2p:dump_node_status_task dump_node_status ] ----------------- PEER STATUS UPDATE -------------------- node.cpp:4644
2015-10-09T07:09:26 p2p:dump_node_status_task dump_node_status ] number of peers: 0 active, 1, 0 closing. attempting to mainta
in 20 - 200 peers node.cpp:4647
2015-10-09T07:09:26 p2p:dump_node_status_task dump_node_status ] handshaking peer 104.236.51.238:2005 in state ours(disconnect
ed) theirs(disconnected) node.cpp:4662
2015-10-09T07:09:26 p2p:dump_node_status_task dump_node_status ] --------- MEMORY USAGE ------------ node
.cpp:4665
2015-10-09T07:09:26 p2p:dump_node_status_task dump_node_status ] node._active_sync_requests size: 0 node.cpp:466
6
2015-10-09T07:09:26 p2p:dump_node_status_task dump_node_status ] node._received_sync_items size: 0 node.cpp:466
7
2015-10-09T07:09:26 p2p:dump_node_status_task dump_node_status ] node._new_received_sync_items size: 0 node
.cpp:4668
2015-10-09T07:09:26 p2p:dump_node_status_task dump_node_status ] node._items_to_fetch size: 0 node.cpp:466
9
2015-10-09T07:09:26 p2p:dump_node_status_task dump_node_status ] node._new_inventory size: 0 node.cpp:467
0
2015-10-09T07:09:26 p2p:dump_node_status_task dump_node_status ] node._message_cache size: 0 node.cpp:467
1
2015-10-09T07:09:26 p2p:dump_node_status_task dump_node_status ] --------- END MEMORY USAGE ------------ node
.cpp:4681
2015-10-09T07:09:32 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Forcibly disconnecting from handshaking peer 104.
236.51.238:2005 due to inactivity of at least 5 seconds node.cpp:1339
2015-10-09T07:09:32 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Peer's negotiating status: connecting, bytes sent
: 0, bytes received: 0 node.cpp:1343
2015-10-09T07:09:32 p2p:connect_to_task connect_to ] fatal: error connecting to peer 104.236.51.238:2005: 0 exception: u
nspecified
Operation canceled
{"message":"Operation canceled"}
asio asio.cpp:38 operator() peer_connection.cpp:254
2015-10-09T07:09:32 p2p:connect_to_task display_current_conn ] Currently have 0 of [20/200] connections node.cp
p:1725
2015-10-09T07:09:32 p2p:connect_to_task display_current_conn ] my id is 5ae3d9e6271d1901b807a0d0c7e09aaf18d2b21710cc3d6a7b1a30d4b2
560f3cd3 node.cpp:1726
2015-10-09T07:09:32 p2p:connect_to_task trigger_p2p_network_ ] Triggering connect loop now node.cpp:982
2015-10-09T07:09:32 p2p:connect_to_task schedule_peer_for_de ] scheduling peer for deletion: 104.236.51.238:2005 (this will not block
) node.cpp:1634
2015-10-09T07:09:32 p2p:connect_to_task schedule_peer_for_de ] asyncing delayed_peer_deletion_task to delete 1 peers node.cpp:1639
2015-10-09T07:09:32 p2p:delayed_peer_deletion_task delayed_peer_deletio ] beginning an iteration of delayed_peer_deletion_task with 1 i
n queue node.cpp:1598
2015-10-09T07:09:32 p2p:delayed_peer_deletion_task destroy ] calling close_connection() peer_connection
.cpp:121
2015-10-09T07:09:32 p2p:delayed_peer_deletion_task destroy ] close_connection completed normally peer_co
nnection.cpp:123
2015-10-09T07:09:32 p2p:delayed_peer_deletion_task destroy ] canceling _send_queued_messages task peer_co
nnection.cpp:136
2015-10-09T07:09:32 p2p:delayed_peer_deletion_task destroy ] cancel_and_wait completed normally peer_co
nnection.cpp:138
2015-10-09T07:09:32 p2p:delayed_peer_deletion_task destroy ] canceling accept_or_connect_task peer_co
nnection.cpp:151
2015-10-09T07:09:32 p2p:delayed_peer_deletion_task destroy ] Unexpected exception from peer_connection's accept_or_connect
_task : {"code":0,"name":"exception","message":"unspecified","stack":[{"context":{"level":"error","file":"asio.cpp","line":38,"method":
"operator()","hostname":"","thread_name":"asio","timestamp":"2015-10-09T07:09:32"},"format":"${message} ","data":{"message":"Operation
canceled"}}]} peer_connection.cpp:157
2015-10-09T07:09:32 p2p:delayed_peer_deletion_task destroy_connection ] in destroy_connection() for message_oriente
d_connection.cpp:280
2015-10-09T07:09:32 p2p:delayed_peer_deletion_task destroy_connection ] in destroy_connection() for message_oriente
d_connection.cpp:280
2015-10-09T07:09:32 p2p:delayed_peer_deletion_task delayed_peer_deletio ] leaving delayed_peer_deletion_task node.cp
-
Try resync blocks without block production. After fully synced, restart witness node with block production option.
Tried that too, no blocks are coming my way.
same here
-
Try resync blocks without block production. After fully synced, restart witness node with block production option.
Tried that too, no blocks are coming my way.
same here
Use the seed node 188.165.233.53:1777
-
When I try to connect the cli_wallet to my local witness node it crashes with the following segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff4f86700 (LWP 7101)]
0x0000000000ed7d98 in websocketpp::processor::hybi13<fc::http::detail::asio_with_stub_log>::consume(unsigned char*, unsigned long, std::error_code&) ()
(gdb) backtrace
#0 0x0000000000ed7d98 in websocketpp::processor::hybi13<fc::http::detail::asio_with_stub_log>::consume(unsigned char*, unsigned long, std::error_code&) ()
#1 0x0000000000eb92a9 in websocketpp::connection<fc::http::detail::asio_with_stub_log>::handle_read_frame(std::error_code const&, unsigned long) ()
#2 0x0000000000e8af24 in websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::handle_async_read(boost::system::error_code const&, unsigned long) ()
#3 0x0000000000ea1825 in boost::asio::detail::completion_handler<boost::asio::detail::binder2<std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::system::error_code, unsigned long> >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#4 0x0000000000ea1a96 in void boost::asio::detail::strand_service::dispatch<boost::asio::detail::binder2<std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::system::error_code, unsigned long> >(boost::asio::detail::strand_service::strand_impl*&, boost::asio::detail::binder2<std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::system::error_code, unsigned long>&) ()
#5 0x0000000000ea1bc1 in std::_Function_handler<void (boost::system::error_code const&, unsigned long), boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::asio::detail::is_continuation_if_running> >::_M_invoke(std::_Any_data const&, boost::system::error_code const&, unsigned long&&) ()
#6 0x0000000000ea2e8d in boost::asio::detail::read_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_at_least_t, websocketpp::transport::asio::custom_alloc_handler<std::function<void (boost::system::error_code const&, unsigned long)> > >::operator()(boost::system::error_code const&, unsigned long, int) ()
#7 0x0000000000ea344d in boost::asio::detail::reactive_socket_recv_op<boost::asio::mutable_buffers_1, boost::asio::detail::read_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_at_least_t, websocketpp::transport::asio::custom_alloc_handler<std::function<void (boost::system::error_code const&, unsigned long)> > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#8 0x0000000000e2d475 in boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#9 0x0000000000ee72f6 in fc::asio::default_io_service_scope::default_io_service_scope()::{lambda()#1}::operator()() const ()
#10 0x000000000102fa35 in thread_proxy ()
#11 0x00007ffff774a4a4 in start_thread () from /usr/lib/libpthread.so.0
#12 0x00007ffff5e4912d in clone () from /usr/lib/libc.so.6
All it needs for me is run ./programs/cli_wallet/cli_wallet -s ws://127.0.0.1:8090 (which gets stuck after wdata.ws_user: wdata.ws_password:)
Did you find a solution to that problem? It started happening to me last night, and now it won't connect at all (fails with the exact same error, same stack trace every single time).
-
Try resync blocks without block production. After fully synced, restart witness node with block production option.
Tried that too, no blocks are coming my way.
same here
Use the seed node 188.165.233.53:1777
thx - this one is o.k.
-
Could someone send some large amount of CORE to dummy9?
I guess this account is used to send the initial 1000 CORE to newly registered users and now it stopped doing that as it has no CORE.
-
Could someone send some large amount of CORE to dummy9?
I guess this account is used to send the initial 1000 CORE to newly registered users and now it stopped doing that as it has no CORE.
I just sent 100K to dummy9
-
Many delegates went in a big minor fork (~35% partecipations) and also spartako and spartako_bot
I removed the blockchain and resynced with the main chain using this seed node:
188.165.233.53:1777
This is the error then I found:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"00018aeac52ac578eead894ddaefb832bab051d0","timestamp":"2015-10-09T10:10:21","witness":"1.6.19","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f6a191cc3c9f8ea6d06f1e3546931a35873961b0b0defe5689a35de504c448ddc3818793a52abbe65da08faa70b5700df2c13088629dd9c1c43a13a2f3ac9fc8c","transactions":[]}}
th_a db_block.cpp:197 _push_block
901261ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 00018aec0d81d4f086eaffcecc9a028749483c49, 101100
901262ms th_a fork_database.cpp:58 push_block ] Head: 101115, 00018afb2ccf99a7986cf678b67613061ba56d0f
901262ms th_a application.cpp:429 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
-
When I try to connect the cli_wallet to my local witness node it crashes with the following segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff4f86700 (LWP 7101)]
0x0000000000ed7d98 in websocketpp::processor::hybi13<fc::http::detail::asio_with_stub_log>::consume(unsigned char*, unsigned long, std::error_code&) ()
(gdb) backtrace
#0 0x0000000000ed7d98 in websocketpp::processor::hybi13<fc::http::detail::asio_with_stub_log>::consume(unsigned char*, unsigned long, std::error_code&) ()
#1 0x0000000000eb92a9 in websocketpp::connection<fc::http::detail::asio_with_stub_log>::handle_read_frame(std::error_code const&, unsigned long) ()
#2 0x0000000000e8af24 in websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::handle_async_read(boost::system::error_code const&, unsigned long) ()
#3 0x0000000000ea1825 in boost::asio::detail::completion_handler<boost::asio::detail::binder2<std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::system::error_code, unsigned long> >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#4 0x0000000000ea1a96 in void boost::asio::detail::strand_service::dispatch<boost::asio::detail::binder2<std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::system::error_code, unsigned long> >(boost::asio::detail::strand_service::strand_impl*&, boost::asio::detail::binder2<std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::system::error_code, unsigned long>&) ()
#5 0x0000000000ea1bc1 in std::_Function_handler<void (boost::system::error_code const&, unsigned long), boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, std::_Bind<std::_Mem_fn<void (websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config>::*)(boost::system::error_code const&, unsigned long)> (std::shared_ptr<websocketpp::transport::asio::connection<fc::http::detail::asio_with_stub_log::transport_config> >, std::_Placeholder<1>, std::_Placeholder<2>)>, boost::asio::detail::is_continuation_if_running> >::_M_invoke(std::_Any_data const&, boost::system::error_code const&, unsigned long&&) ()
#6 0x0000000000ea2e8d in boost::asio::detail::read_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_at_least_t, websocketpp::transport::asio::custom_alloc_handler<std::function<void (boost::system::error_code const&, unsigned long)> > >::operator()(boost::system::error_code const&, unsigned long, int) ()
#7 0x0000000000ea344d in boost::asio::detail::reactive_socket_recv_op<boost::asio::mutable_buffers_1, boost::asio::detail::read_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_at_least_t, websocketpp::transport::asio::custom_alloc_handler<std::function<void (boost::system::error_code const&, unsigned long)> > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#8 0x0000000000e2d475 in boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#9 0x0000000000ee72f6 in fc::asio::default_io_service_scope::default_io_service_scope()::{lambda()#1}::operator()() const ()
#10 0x000000000102fa35 in thread_proxy ()
#11 0x00007ffff774a4a4 in start_thread () from /usr/lib/libpthread.so.0
#12 0x00007ffff5e4912d in clone () from /usr/lib/libc.so.6
All it needs for me is run ./programs/cli_wallet/cli_wallet -s ws://127.0.0.1:8090 (which gets stuck after wdata.ws_user: wdata.ws_password:)
Did you find a solution to that problem? It started happening to me last night, and now it won't connect at all (fails with the exact same error, same stack trace every single time).
Still terminating :(
-
Many delegates went in a big minor fork (~35% partecipations) and also spartako and spartako_bot
I removed the blockchain and resynced with the main chain using this seed node:
188.165.233.53:1777
This is the error then I found:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"00018aeac52ac578eead894ddaefb832bab051d0","timestamp":"2015-10-09T10:10:21","witness":"1.6.19","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f6a191cc3c9f8ea6d06f1e3546931a35873961b0b0defe5689a35de504c448ddc3818793a52abbe65da08faa70b5700df2c13088629dd9c1c43a13a2f3ac9fc8c","transactions":[]}}
th_a db_block.cpp:197 _push_block
901261ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 00018aec0d81d4f086eaffcecc9a028749483c49, 101100
901262ms th_a fork_database.cpp:58 push_block ] Head: 101115, 00018afb2ccf99a7986cf678b67613061ba56d0f
901262ms th_a application.cpp:429 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
syncing from 104.236.51.238:2005 with latest master witout any problem
it requires a bit patience until it stops writing
1831000ms th_a witness.cpp:179 block_production_loo ] Not producing block because production is disabled until we receive a
recent block (see: --enable-stale-production)
1832000ms th_a witness.cpp:179 block_production_loo ] Not producing block because production is disabled until we receive a
recent block (see: --enable-stale-production)
and starts syncing.
-
could the witnesses please give their opinion on this matter?
https://bitsharestalk.org/index.php/topic,18831.0.html
-
I updated last night at 9PM, so I am ready for the hard fork. Witness is working again on the original keys. Not sure why I can't switch to new keys with update_witness as I did on Wednesday, but I'll find out why after this morning's mumble.
I missed only 1 block since 9PM last night.
-
What is happening? I'm not seeing regular updates in the witness. I did see this:
1586211ms th_a application.cpp:529 get_item ] Couldn't find block 00018ad
87629d33a99b65f537b4ddbb1af721828 -- corresponding ID in our chain is 00018ad87629d33a99b65f537b4ddbb
1af721828
Did the chainID change without an announcement of a new test?
I have not stopped the witness since I updated the binaries. It was fine a few minutes ago, but now nothing.
-
out of sync, here is the message from console
1620572ms th_a application.cpp:432 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
item->num > std::max<int64_t>( 0, int64_t(_head->num) - (_max_size) ): attempting to push a block that is too old
{"item->num":101080,"head":101594,"max_size":26}
th_a fork_database.cpp:71 _push_block
{"new_block":{"previous":"00018ad7f147314df8c447b22372334d234a0a34","timestamp":"2015-10-09T10:09:12","witness":"1.6.31","transaction_merkle_root":"caf15e1e8bc32121
d59466e207d7ff1d6096775b","extensions":[],"witness_signature":"1f572637a607a85deada8e2af3e482083a80137e1d32865882b6c0c5c5ab44aff73b03f2da3854556a70dd4503b16a6611b61f1b9
05e409fd90d912b2098c9b17d","transactions":[{"ref_block_num":35543,"ref_block_prefix":1295075313,"expiration":"2015-10-09T10:09:39","operations":[[33,{"fee":{"amount":10
0000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":800000000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["2010951608daa
e48abcc6a9c9c6c43fe449803bf4af875602c02556915d9c680e32d808c391b128858f7e9f72b6d0dfd54036abe2852eabba55f3d479ebd0ee25f"],"operation_results":[[0,{}]]}]}}
th_a db_block.cpp:197 _push_block
1620573ms th_a application.cpp:432 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
item->num > std::max<int64_t>( 0, int64_t(_head->num) - (_max_size) ): attempting to push a block that is too old
{"item->num":101081,"head":101594,"max_size":26}
th_a fork_database.cpp:71 _push_block
{"new_block":{"previous":"00018ad8150b29e0a9278acb90fe7c592f4ec15c","timestamp":"2015-10-09T10:09:15","witness":"1.6.35","transaction_merkle_root":"0000000000000000
000000000000000000000000","extensions":[],"witness_signature":"202d638e8938d8fde6e107105b4e95edc26068af86d68894199480ae6dbb7d16052e8ec457759e5b70f3866bfd6afcb1d8f2e5526
bb17af292fbb56d1542058ce8","transactions":[]}}
th_a db_block.cpp:197 _push_block
1620574ms th_a application.cpp:432 handle_block ] Error when pushing block:
10 assert_exception: Assert Exception
item->num > std::max<int64_t>( 0, int64_t(_head->num) - (_max_size) ): attempting to push a block that is too old
{"item->num":101082,"head":101594,"max_size":26}
th_a fork_database.cpp:71 _push_block
-
xeldal is updated to master
-
I'm planning 100 TPS test at 10/9 21:00 (about 4 hours after the next hardfork). Is it reasonable?
Could you do it a couple of hours earlier?
-
When I try to connect the cli_wallet to my local witness node it crashes with the following segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff4f86700 (LWP 7101)]
0x0000000000ed7d98 in websocketpp::processor::hybi13<fc::http::detail::asio_with_stub_log>::consume(unsigned char*, unsigned long, std::error_code&) ()
(gdb) backtrace
#0 0x0000000000ed7d98 in websocketpp::processor::hybi13<fc::http::detail::asio_with_stub_log>::consume(unsigned char*, unsigned long, std::error_code&) ()
All it needs for me is run ./programs/cli_wallet/cli_wallet -s ws://127.0.0.1:8090 (which gets stuck after wdata.ws_user: wdata.ws_password:)
Filed as https://github.com/cryptonomex/graphene/issues/365 , seems to be due to upstream https://github.com/zaphoyd/websocketpp/issues/395
-
Many delegates went in a big minor fork (~35% partecipations) and also spartako and spartako_bot
I removed the blockchain and resynced with the main chain using this seed node:
188.165.233.53:1777
This is the error then I found:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"00018aeac52ac578eead894ddaefb832bab051d0","timestamp":"2015-10-09T10:10:21","witness":"1.6.19","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f6a191cc3c9f8ea6d06f1e3546931a35873961b0b0defe5689a35de504c448ddc3818793a52abbe65da08faa70b5700df2c13088629dd9c1c43a13a2f3ac9fc8c","transactions":[]}}
th_a db_block.cpp:197 _push_block
901261ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 00018aec0d81d4f086eaffcecc9a028749483c49, 101100
901262ms th_a fork_database.cpp:58 push_block ] Head: 101115, 00018afb2ccf99a7986cf678b67613061ba56d0f
901262ms th_a application.cpp:429 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
syncing from 104.236.51.238:2005 with latest master witout any problem
it requires a bit patience until it stops writing
1831000ms th_a witness.cpp:179 block_production_loo ] Not producing block because production is disabled until we receive a
recent block (see: --enable-stale-production)
1832000ms th_a witness.cpp:179 block_production_loo ] Not producing block because production is disabled until we receive a
recent block (see: --enable-stale-production)
and starts syncing.
I have been hours trying to sync with that... :(
@spartako thanks for the seed node 188.165.233.53:1777 !!
-
Is there any possibility to get market history or how to get asks/bids. I tried with get_market_history but there always is an empty array []
-
bue has updated to latest master with 28 new commits
-
here is my automatic failover script powered by xerocs python-graphenelib. I am a noob at teh programming, and if I did anything wrong I would love the feedback.
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys
import json
from grapheneapi import GrapheneWebsocket, GrapheneWebsocketProtocol
import time
import config
rpc = GrapheneWebsocket("localhost", 8092, "", "")
publickeys = config.publickeys
witnessname = config.witnessname
def getmissed(witnessname):
witness = rpc.get_witness(witnessname)
missed = witness["total_missed"]
return missed
missed = getmissed(config.witnessname)
def switch(witnessname, publickeys, missed):
keynumber = missed % len(publickeys)
key = publickeys[keynumber]
rpc.update_witness(witnessname, "", key, "true")
print("witness down switching to " + key)
print ("Nothing in this window will change unless a block is missed")
while True:
if missed < getmissed(config.witnessname):
missed = getmissed(config.witnessname)
switch(witnessname, publickeys, missed)
else:
time.sleep(3)
You need to add two lines to your config.py file. witnessname as a string and publickeys as strings in a tuple of the public keys you want to switch between. those lines look like this in my case.
witnessname = "dele-puppy"
publickeys = ("GPH75xxKG4ZeztPpnhmFch99smunUWMvDy9mB6Le497vpAA3XUXaD", "GPH8Sj81ncf8PK5QwJZvhWsvwp6m4bXzTFvp4bKycNNFvHaJpZSnH")
The wallet this script is running through needs to be unlocked, and must contain the owner key (I think its the owner key, rather than the active key) of the witness.
Nice!
I would not assume that all missed blocks are the fault of your witness or an indication that you need to switch nodes. I would probably use the "last_confirmed_block_num" property on the witness and only switch if it is more than 3 rounds behind the head block number.
-
Witness spectral stopped producing blocks and started producing error messages at the witness output. Here is a log from the screen buffer of the witness output:
https://drive.google.com/file/d/0BzEEZBS7b6xPUnJvQXFZUHZQZW8/view?usp=sharing (https://drive.google.com/file/d/0BzEEZBS7b6xPUnJvQXFZUHZQZW8/view?usp=sharing)
Did this also happen to the others?
I deleted oct5 and object_database, restarted witness, and it's back to producing blocks and price feed.
-
Use the seed node 188.165.233.53:1777
that helped me to sync the chain!
Thanks,
Can somebody mention more seed nodes? So we are not depended on a single seed node?
How can we run a dedicated seed-node and give them a specific port available to others? (without using it for block production)
-
Witness spectral stopped producing blocks and started producing error messages at the witness output. Here is a log from the screen buffer of the witness output:
https://drive.google.com/file/d/0BzEEZBS7b6xPUnJvQXFZUHZQZW8/view?usp=sharing (https://drive.google.com/file/d/0BzEEZBS7b6xPUnJvQXFZUHZQZW8/view?usp=sharing)
Did this also happen to the others?
I deleted oct5 and object_database, restarted witness, and it's back to producing blocks and price feed.
Looks like we missed the real error.
-
I would not assume that all missed blocks are the fault of your witness or an indication that you need to switch nodes. I would probably use the "last_confirmed_block_num" property on the witness and only switch if it is more than 3 rounds behind the head block number.
Wouldn't waiting for 3 missed blocks before switching have the same effect? Either way the number of missed blocks before you switch could pretty easily be configured in the config.
***edit*** I do get that 3 missed blocks will not always be equal to 3x active witnesses since last generated block. I was just curious if there is a reason why measuring missed blocks by number of rounds completed since last block is a better way of measuring.
-
Stress test will begin at
19:00 19:30 UTC (in 2 hours). I expect to see the performance of the new code!
-
Stress test will begin at 19:00 UTC (in 2 hours).
Can you postpone it to 19:10 UTC or so? Some new code goes into effect at 18:45 UTC, and 19:00 UTC will be the first maintenance interval after the new code goes into effect. It might be helpful for debugging to have a way to tell the difference between witnesses going down due to the new code (18:45-19:10) and witnesses going down due to the stress (19:10 or later).
-
Stress test will begin at 19:00 UTC (in 2 hours).
Can you postpone it to 19:10 UTC or so? Some new code goes into effect at 18:45 UTC, and 19:00 UTC will be the first maintenance interval after the new code goes into effect. It might be helpful for debugging to have a way to tell the difference between witnesses going down due to the new code (18:45-19:10) and witnesses going down due to the stress (19:10 or later).
Sure. What about 19:30 UTC?
-
Can't seem to get another instance up and running. I've verified all of the wallets, config and binaries with md5sum to working versions. I've deleted the object_database and blockchain. I've tried --resync-blockchain, --replay-blockchain options. Everytime I start the witness I get this output:
2114494ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000019a905fb92
2c6c7c8e72d1b09c04425e0c1"]
2114531ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000019a905fb92
2c6c7c8e72d1b09c04425e0c1"]
2118682ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000019a905fb92
2c6c7c8e72d1b09c04425e0c1","000001a1895e7bb499ff3f12bd5eda0a050488de","000001a4236eb3795a2cfa9c5d9f00177fd0b14c","000001a64a8f85ec0c46910dc9eb8ad1ad6a5d10"]
2118852ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000019a905fb922c6c7c8e72d1b09c04425e0c1","000001a1895e7bb499ff3f12bd5eda0a050488de","000001a4236eb3795a2cfa9c5d9f00
177fd0b14c","000001a64a8f85ec0c46910dc9eb8ad1ad6a5d10"]
cli_wallet does not show correct "info" at all. Using the same seed as working VPS (104.236.51.238:2005)
I will repeat the attempt on another VPS with the same exact files and see what happens. I will make one last attempt to restart this VPS as a seed.
BTW - I still haven't found a way to stop the witness cleanly. The only way I know to stop it at all is with ^C. Sometimes it reports "Aborted ..." in the output but most of the time when it is restarted it complains it was shutdown uncleanly.
Is there a signal that will do it properly? St least in the old code there was a "quit" command, although it often resulted in a corrupted blockchain database. Can this fundamental issue not be fixed?
-
Can't seem to get another instance up and running. I've verified all of the wallets, config and binaries with md5sum to working versions. I've deleted the object_database and blockchain. I've tried --resync-blockchain, --replay-blockchain options. Everytime I start the witness I get this output:
2114494ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000019a905fb92
2c6c7c8e72d1b09c04425e0c1"]
2114531ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000019a905fb92
2c6c7c8e72d1b09c04425e0c1"]
2118682ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000019a905fb92
2c6c7c8e72d1b09c04425e0c1","000001a1895e7bb499ff3f12bd5eda0a050488de","000001a4236eb3795a2cfa9c5d9f00177fd0b14c","000001a64a8f85ec0c46910dc9eb8ad1ad6a5d10"]
2118852ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000019a905fb922c6c7c8e72d1b09c04425e0c1","000001a1895e7bb499ff3f12bd5eda0a050488de","000001a4236eb3795a2cfa9c5d9f00
177fd0b14c","000001a64a8f85ec0c46910dc9eb8ad1ad6a5d10"]
cli_wallet does not show correct "info" at all. Using the same seed as working VPS (104.236.51.238:2005)
I will repeat the attempt on another VPS with the same exact files and see what happens. I will make one last attempt to restart this VPS as a seed.
Can you post your build commands?
-
Stress test will begin at 19:00 UTC (in 2 hours). I expect to see the performance of the new code!
(http://memecrunch.com/meme/2DCZS/tps-reports/image.jpg?w=1024&c=1)
-
Stress test will begin at 19:00 UTC (in 2 hours). I expect to see the performance of the new code!
(http://memecrunch.com/meme/2DCZS/tps-reports/image.jpg?w=1024&c=1)
Hopefully, the network won't be broken :P
-
I am on commit: e68e99ed3ae11ddac607e983e7549e8278fdecc4 by BM, I miss the last two from emfrias... are they important for the hardfork?
-
Can you post your build commands?
Hey clayop, thanks for the response. To answere your question, no, not easily. I'm using a python script (bts_tools) and some of it is buried in the config files.
Besides, I don't think that's relevant, given that the binaries are in operation now and I haven't missed a block in several hours on VPS seed07 in Singnapore.
Also, as I mentioned, I verified the binaries, config etc were all transfered from seed07 to seed06 in LA without changes using md5sum.
I just tried to start it as a seed node on seed06 (no block production) and it fails in the same way, but I expected that.
I will try to start a seed on another VPS in Germany and see if I can get it to sync. If I can it will be some issue on the VPS, in which case I'll rebuild it from scratch. All 4 of the VPSs should be the same, but I have noticed subtle differences in the images each host uses, tho they are all Ubuntu 14.04, and I used the same setup script on each one.
It's been fast pace work, and I may have overlooked something tho. It only goes to show if it's this difficult to determine why I can't bring up a new witness instance with all of these checks and verifications it's not only a suble difference but also that the voluminous withness_node output is not easy to distill information from.
-
Can you post your build commands?
Hey clayop, thanks for the response. To answere your question, no, not easily. I'm using a python script (bts_tools) and some of it is buried in the config files.
Besides, I don't think that's relevant, given that the binaries are in operation now and I haven't missed a block in several hours on VPS seed07 in Singnapore.
Also, as I mentioned, I verified the binaries, config etc were all transfered from seed07 to seed06 in LA without changes using md5sum.
I just tried to start it as a seed node on seed06 (no block production) and it fails in the same way, but I expected that.
I will try to start a seed on another VPS in Germany and see if I can get it to sync. If I can it will be some issue on the VPS, in which case I'll rebuild it from scratch. All 4 of the VPSs should be the same, but I have noticed subtle differences in the images each host uses, tho they are all Ubuntu 14.04, and I used the same setup script on each one.
It's been fast pace work, and I may have overlooked something tho. It only goes to show if it's this difficult to determine why I can't bring up a new witness instance with all of these checks and verifications it's not only a suble difference but also that the voluminous withness_node output is not easy to distill information from.
Okay. Here's how I build. Can you compare it with yours?
git clone https://github.com/cryptonomex/graphene.git
cd graphene
git submodule update --init --recursive
cmake -DCMAKE_BUILD_TYPE=Release
make witness_node cli_wallet
-
Can't seem to get another instance up and running. I've verified all of the wallets, config and binaries with md5sum to working versions. I've deleted the object_database and blockchain. I've tried --resync-blockchain, --replay-blockchain options. Everytime I start the witness I get this output:
2114494ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000019a905fb92
2c6c7c8e72d1b09c04425e0c1"]
2114531ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000019a905fb92
2c6c7c8e72d1b09c04425e0c1"]
2118682ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000019a905fb92
2c6c7c8e72d1b09c04425e0c1","000001a1895e7bb499ff3f12bd5eda0a050488de","000001a4236eb3795a2cfa9c5d9f00177fd0b14c","000001a64a8f85ec0c46910dc9eb8ad1ad6a5d10"]
2118852ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000019a905fb922c6c7c8e72d1b09c04425e0c1","000001a1895e7bb499ff3f12bd5eda0a050488de","000001a4236eb3795a2cfa9c5d9f00
177fd0b14c","000001a64a8f85ec0c46910dc9eb8ad1ad6a5d10"]
cli_wallet does not show correct "info" at all. Using the same seed as working VPS (104.236.51.238:2005)
How does the info command output look incorrect? If you are doing --resync-blockchain then it nukes all the downloaded blocks and starts at the beginning, so you will see block times / block numbers in the past until you've finished downloading the chain. The get_blockchain_synop messages are normal, they show your node exchanging block ID's with peers.
BTW - I still haven't found a way to stop the witness cleanly. The only way I know to stop it at all is with ^C. Sometimes it reports "Aborted ..." in the output but most of the time when it is restarted it complains it was shutdown uncleanly.
Yeah, our shutdown code isn't that robust. I filed a ticket.
Is there a signal that will do it properly? St least in the old code there was a "quit" command, although it often resulted in a corrupted blockchain database. Can this fundamental issue not be fixed?
SIGINT is your best bet.
-
I got this on my cli_wallet, in red:
7364ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id 0be4839dfa602f3be290b7d2a5524a318f889e50
Still, it is not crashed...
-
Okay. Here's how I build. Can you compare it with yours?
git clone https://github.com/cryptonomex/graphene.git
cd graphene
git submodule update --init --recursive
cmake -DCMAKE_BUILD_TYPE=Release
make witness_node cli_wallet
Yep, the std way like everybody else that doesn't use some type of automation.
But like I said, irrelevant for the reasons stated.
-
How does the info command output look incorrect? If you are doing --resync-blockchain then it nukes all the downloaded blocks and starts at the beginning, so you will see block times / block numbers in the past until you've finished downloading the chain. The get_blockchain_synop messages are normal, they show your node exchanging block ID's with peers.
I see that it does make sense if the blockchain is not yet synced:
unlocked >>> info [24/1938]
info
{
"head_block_num": 271,
"head_block_id": "0000010f433d8be806b267a237c6a81f176168a3",
"head_block_age": "4 days old",
"next_maintenance_time": "4 days ago",
"chain_id": "60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83",
"participation": "85.93750000000000000",
"active_witnesses": [
"1.6.1",
"1.6.2",
"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"
],
"active_committee_members": [
"1.5.0",
"1.5.1",
"1.5.2",
"1.5.3",
"1.5.4",
"1.5.5",
"1.5.6",
"1.5.7",
"1.5.8",
"1.5.9",
"1.5.10"
]
}
I was confused, and thought the replay was done before it was. I have seen the % reports along the way but then those stop & I get this voluminous output, plus I see no witness / irreversible block reports and it takes a really long time. I'll just let it go and see if it eventually syncs up.
If it doesn't (and just crashes) could it be due to the flood test, or is that irrelevant and not stressful in a replay scenario?
Still seeing tons of these "get_blockchain_synop" lines in the witness output, and occasionally one of these:
3184761ms th_a witness.cpp:188 block_production_loo ] Not producing block because
I don't have the private key for GPH6oUevPDj52JK67E199jBAMBuh6CQBQGgkyLtoXKiAvTVCpvYU7
If it's still in the replay phase why would that show up? That surely can't be part of the reply could it? It is going on 20 minutes and I see no change to the witness output. I've not seen any reports that others have taken this long. It really seems abnomal. However, the output of info looks OK now, generally.
-
I got this on my cli_wallet, in red:
7364ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id 0be4839dfa602f3be290b7d2a5524a318f889e50
Still, it is not crashed...
Once again
1804914ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id 57a9c867a04e5adb669e208325606f02c204bc9e
What are they?
-
Any chance we can end the flood tests a tad early? It is interfering with my ability to test other features.
It seems like the network is holding up fine under load with high participation and high throughput of over 100 TPS.
-
Any chance we can end the flood tests a tad early? It is interfering with my ability to test other features.
It seems like the network is holding up fine under load with high participation and high throughput of over 100 TPS.
Sure. Just tell me when do I have to stop it.
-
Ive set up another seed node at 104.236.144.84:1776
This will be my seed node on the main chain as well. Is there a good reason to use a different ip/port once we go live?
-
If it was only replaying it never caught up. It just ended in a firey crash:
237745ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd20f0f688d88c6ecafa73e9396da128575e","0000dd2ddbe5e2f349056489807735ee69a72f64","0000dd3361101334b8cd482d158f26075aa19cda","0000dd36f4282b71818c080ed38b031694afacc9","0000dd388f8db8edf41e928637f20e2720b34082"]
237755ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd20f0f688d88c6ecafa73e9396da128575e","0000dd2ddbe5e2f349056489807735ee69a72f64","0000dd3361101334b8cd482d158f26075aa19cda","0000dd36f4282b71818c080ed38b031694afacc9","0000dd388f8db8edf41e928637f20e2720b34082"]
237789ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd20f0f688d88c6ecafa73e9396da128575e","0000dd2ddbe5e2f349056489807735ee69a72f64","0000dd3361101334b8cd482d158f26075aa19cda","0000dd36f4282b71818c080ed38b031694afacc9","0000dd388f8db8edf41e928637f20e2720b34082"]
237792ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd20f0f688d88c6ecafa73e9396da128575e","0000dd2ddbe5e2f349056489807735ee69a72f64","0000dd3361101334b8cd482d158f26075aa19cda","0000dd36f4282b71818c080ed38b031694afacc9","0000dd388f8db8edf41e928637f20e2720b34082"]
237800ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd20f0f688d88c6ecafa73e9396da128575e","0000dd2ddbe5e2f349056489807735ee69a72f64","0000dd3361101334b8cd482d158f26075aa19cda","0000dd36f4282b71818c080ed38b031694afacc9","0000dd388f8db8edf41e928637f20e2720b34082"]
237856ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd20f0f688d88c6ecafa73e9396da128575e"]
witness_node: /home/deletech/BitShares2_build/libraries/fc/src/thread/thread_d.hpp:370: bool fc::thread_d::start_next_fiber(bool): Assertion `std::current_exception() == std::exception_ptr()' failed.
Aborted
This was an attempt to start from scratch. Wiped object_database, blockchain, p2p, logs. No --replay-blockchain or --resync-blockchain. No cmd line params except --data-dir, everything is in the config.ini file. All essentials from config noted in my previous posts.
Here's the start of another attempt. This time left everything intact from the run that crashed except I removed the object_database folder AND I used puppies seed instead of the :2005 seed.
973661ms th_a witness.cpp:111 plugin_initialize ] witness plugin: plugin_initialize() end
973662ms th_a application.cpp:302 startup ] Detected unclean shutdown. Replaying blockchain...
973662ms th_a application.cpp:243 operator() ] Initializing database...
1073034ms th_a db_management.cpp:45 reindex ] reindexing blockchain
1073047ms th_a db_management.cpp:98 wipe ] Wiping database
1073179ms th_a object_database.cpp:81 wipe ] Wiping object_database.
1133390ms th_a db_debug.cpp:79 debug_dump ] total_balances[asset_id_type()].value: 14239376866944 core_asset_data.current_supply.value: 271289987694689
1133406ms th_a db_debug.cpp:82 debug_dump ] core_in_orders: 14239376866944 reported_core_in_orders: 14239376866944
1133477ms th_a db_management.cpp:147 open ] last_block->id(): 0000dd388f8db8edf41e928637f20e2720b34082 last_block->block_num(): 56632
1133477ms th_a db_management.cpp:59 reindex ] Replaying blocks...
3.53157% 2000 of 56632
7.06314% 4000 of 56632
10.5947% 6000 of 56632
14.1263% 8000 of 56632
17.6579% 10000 of 56632
21.1894% 12000 of 56632
24.721% 14000 of 56632
28.2526% 16000 of 56632
31.7842% 18000 of 56632
35.3157% 20000 of 56632
38.8473% 22000 of 56632
42.3789% 24000 of 56632
45.9104% 26000 of 56632
49.442% 28000 of 56632
52.9736% 30000 of 56632
56.5052% 32000 of 56632
60.0367% 34000 of 56632
1272503ms th_a asset_evaluator.cpp:553 do_evaluate ] USD feed pub with wrong ass
et by wackou in block 34129
1272511ms th_a asset_evaluator.cpp:618 do_apply ] Ignoring bad feed
1272603ms th_a asset_evaluator.cpp:553 do_evaluate ] SEK feed pub with wrong asset by wackou in block 34215
1272616ms th_a asset_evaluator.cpp:618 do_apply ] Ignoring bad feed
63.5683% 36000 of 56632
1279203ms th_a asset_evaluator.cpp:553 do_evaluate ] SILVER feed pub with wrong asset by wackou in block 36010
1279220ms th_a asset_evaluator.cpp:618 do_apply ] Ignoring bad feed
67.0999% 38000 of 56632
70.6314% 40000 of 56632
74.163% 42000 of 56632
77.6946% 44000 of 56632
81.2262% 46000 of 56632
84.7577% 48000 of 56632
1425106ms th_a asset_evaluator.cpp:553 do_evaluate ] EUR feed pub with wrong ass
et by wackou in block 49903
1425118ms th_a asset_evaluator.cpp:618 do_apply ] Ignoring bad feed
88.2893% 50000 of 56632
1427034ms th_a asset_evaluator.cpp:553 do_evaluate ] RUB feed pub with wrong ass
et by wackou in block 50353
1427045ms th_a asset_evaluator.cpp:618 do_apply ] Ignoring bad feed
91.8209% 52000 of 56632
95.3525% 54000 of 56632
98.884% 56000 of 56632
1459060ms th_a db_management.cpp:93 reindex ] Done reindexing, elapsed ti
me: 325.58274599999998600 sec
1459300ms th_a thread.cpp:95 thread ] name:ntp tid:14049966996044
8
1459327ms th_a thread.cpp:95 thread ] name:p2p tid:14049965107788
8
1459390ms th_a application.cpp:123 reset_p2p_node ] Adding seed node 104.236.14
4.84:1776
1459394ms th_a application.cpp:135 reset_p2p_node ] Configured p2p node to list
en on 0.0.0.0:1776
1459419ms th_a application.cpp:185 reset_websocket_serv ] Configured websocket rpc to
listen on 127.0.0.1:8090
1459435ms th_a witness.cpp:116 plugin_startup ] witness plugin: plugin_sta
rtup() begin
1459435ms th_a witness.cpp:123 plugin_startup ] Launching block production
for 1 witnesses.
1459435ms th_a witness.cpp:134 plugin_startup ] witness plugin: plugin_sta
rtup() end
1459435ms th_a main.cpp:167 main ] Started witness node on a c
hain with 56632 blocks.
1459435ms th_a main.cpp:168 main ] Chain ID is 60e21871125ea99
95fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83
1459450ms ntp ntp.cpp:177 read_loop ] ntp_delta_time updated to -
23481 us
1459561ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd388f8db8e
df41e928637f20e2720b34082"]
1459627ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd388f8db8e
df41e928637f20e2720b34082"]
1459678ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd388f8db8e
df41e928637f20e2720b34082"]
1459724ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd388f8db8e
df41e928637f20e2720b34082"]
1459774ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd388f8db8e
df41e928637f20e2720b34082"]
1459823ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd388f8db8e
df41e928637f20e2720b34082"]
Note that it never gets to 100%, but I see now that these percentages aren't for the replay but rather for the reindexing. If the replay is still in progress and the blockchain is yet to be synced, why does it consistently fail and crash? I notice these "get_blockchain_synop" lines also appear quite frequently in the witness node that is working properly and signing blocks.
At least I think it's working properly, I don't see my missed blocks count increasing and I do see blocks from other witnesses and these lines:
2748001ms th_a witness.cpp:176 block_production_loo ] Generated block #111989 with timestamp 2015-10-09T20:45:48 at time 2015-10-09T20:45:48
Which tell me all is well.
-
Witness spectral stopped producing blocks and started producing error messages at the witness output. Here is a log from the screen buffer of the witness output:
https://drive.google.com/file/d/0BzEEZBS7b6xPUnJvQXFZUHZQZW8/view?usp=sharing (https://drive.google.com/file/d/0BzEEZBS7b6xPUnJvQXFZUHZQZW8/view?usp=sharing)
Did this also happen to the others?
I deleted oct5 and object_database, restarted witness, and it's back to producing blocks and price feed.
Looks like we missed the real error.
Yes... I will enable file logging on screen, so next time it happens, the log should include everything.
I checked the CLI now, and it seems something is not right. Feeds do not publish anymore, since 2 hours ago. Here's the cli_wallet output:
3007026ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id b75bf74af11ab7210e24e79b665fddb77a70b37b
4117ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id d83a159834150bfb4f6ba6ae767b6e6b2187fbdf
606929ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id 3375e940443eb7b123a4d905a23e86cb475b7761
1204093ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id 9eea37c7051673a6e0e6e8bda816ac682ddf7312
1806802ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id ae4e7532a0024a244a2b431e834aa4487304fa40
2405192ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id d70a6e10be5f7f45a000efe1c945fab97cfc6cf4
3007726ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id 1c61a0c93fe43ce1080e7e617d8173ec034e1786
6366ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id 314093bb2434cd1ac9322bdfb01ed15549860cb3
605558ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id 67d051fbe2795f7ad61f8f4bb15fcdae2c894511
1205379ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id eb4c2e45fe8e129586a422c41caa0f476a17b806
1804573ms th_a wallet.cpp:1717 sign_transaction ] Caught exception while broadcasting transaction with id a362dd39f7768bcc07d56f7a964bb1e2bba361fb
unlocked >>> get_witness spectral
get_witness spectral
{
"id": "1.6.38",
"witness_account": "1.2.73210",
"last_aslot": 123874,
"signing_key": "GPH8ZWNd9K82gPqKVDbkK8etaYTBMQ3ME3MTQ6HqF586ZbMLrZ5DH",
"pay_vb": "1.13.64",
"vote_id": "1:49",
"total_votes": "7774534618288",
"url": "bitspace.no",
"total_missed": 958,
"last_confirmed_block_num": 111813
}
unlocked >>>
get_witness seems right, so does the witness_output.
-
If it was only replaying it never caught up. It just ended in a firey crash:
237745ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd20f0f688d88c6ecafa73e9396da128575e","0000dd2ddbe5e2f349056489807735ee69a72f64","0000dd3361101334b8cd482d158f26075aa19cda","0000dd36f4282b71818c080ed38b031694afacc9","0000dd388f8db8edf41e928637f20e2720b34082"]
237755ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd20f0f688d88c6ecafa73e9396da128575e","0000dd2ddbe5e2f349056489807735ee69a72f64","0000dd3361101334b8cd482d158f26075aa19cda","0000dd36f4282b71818c080ed38b031694afacc9","0000dd388f8db8edf41e928637f20e2720b34082"]
237789ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd20f0f688d88c6ecafa73e9396da128575e","0000dd2ddbe5e2f349056489807735ee69a72f64","0000dd3361101334b8cd482d158f26075aa19cda","0000dd36f4282b71818c080ed38b031694afacc9","0000dd388f8db8edf41e928637f20e2720b34082"]
237792ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd20f0f688d88c6ecafa73e9396da128575e","0000dd2ddbe5e2f349056489807735ee69a72f64","0000dd3361101334b8cd482d158f26075aa19cda","0000dd36f4282b71818c080ed38b031694afacc9","0000dd388f8db8edf41e928637f20e2720b34082"]
237800ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd20f0f688d88c6ecafa73e9396da128575e","0000dd2ddbe5e2f349056489807735ee69a72f64","0000dd3361101334b8cd482d158f26075aa19cda","0000dd36f4282b71818c080ed38b031694afacc9","0000dd388f8db8edf41e928637f20e2720b34082"]
237856ms th_a application.cpp:712 get_blockchain_synop ] synopsis: ["0000dd20f0f688d88c6ecafa73e9396da128575e"]
witness_node: /home/deletech/BitShares2_build/libraries/fc/src/thread/thread_d.hpp:370: bool fc::thread_d::start_next_fiber(bool): Assertion `std::current_exception() == std::exception_ptr()' failed.
Aborted
This was an attempt to start from scratch. Wiped object_database, blockchain, p2p, logs. No --replay-blockchain or --resync-blockchain. No cmd line params except --data-dir, everything is in the config.ini file. All essentials from config noted in my previous posts.
For starters you built in DEBUG mode, but you didn't run it in gdb so I don't have a stack trace.
I have just made some commits to *fc* that should attempt to prevent that particular crash.
-
Can't public feed too
-
If it was only replaying it never caught up. It just ended in a firey crash:
witness_node: /home/deletech/BitShares2_build/libraries/fc/src/thread/thread_d.hpp:370: bool fc::thread_d::start_next_fiber(bool): Assertion `std::current_exception() == std::exception_ptr()' failed.
Aborted
I've had the same thing happen to me, see https://github.com/cryptonomex/graphene/issues/332 -- but I've never been able to reproduce it.
Note that it never gets to 100%, but I see now that these percentages aren't for the replay but rather for the reindexing. If the replay is still in progress and the blockchain is yet to be synced, why does it consistently fail and crash? I notice these "get_blockchain_synop" lines also appear quite frequently in the witness node that is working properly and signing blocks.
At least I think it's working properly, I don't see my missed blocks count increasing and I do see blocks from other witnesses and these lines:
2748001ms th_a witness.cpp:176 block_production_loo ] Generated block #111989 with timestamp 2015-10-09T20:45:48 at time 2015-10-09T20:45:48
Which tell me all is well.
Looks fine to me. It doesn't show 100% because the print is just printing every 10,000th block, the message when it's done doesn't say 100%, rather the "Done reindexing" message is what indicates the reindex is finished.
In Graphene terminology, "reindexing" and "replaying" are the same thing. They both mean starting the chain state database in the genesis state, then applying your previously saved blocks to advance the chain state. You say "these percentages aren't for the replay but rather for the reindexing" as if "replay" and "reindexing" are different things. They're actually the same thing.
I agree the get_blockchain_synop message is spammy and we should probably get rid of it.
-
@Spectral @Bhuz
If you guys are having trouble publishing feeds, could you update to latest master and try again? I made the error message you're getting more informative.
-
If it was only replaying it never caught up. It just ended in a firey crash:
witness_node: /home/deletech/BitShares2_build/libraries/fc/src/thread/thread_d.hpp:370: bool fc::thread_d::start_next_fiber(bool): Assertion `std::current_exception() == std::exception_ptr()' failed.
Aborted
I've had the same thing happen to me, see https://github.com/cryptonomex/graphene/issues/332 -- but I've never been able to reproduce it.
I was able to bring up another node on a different VPS, it synced up just fine. I'm about to do an update_witness to verify the switching process.
Don't know what it is about that particular VPS in LA, but I cannot get it working today. I will resinstall the OS from scratch and use it for VPS setup script testing.
In Graphene terminology, "reindexing" and "replaying" are the same thing. They both mean starting the chain state database in the genesis state, then applying your previously saved blocks to advance the chain state. You say "these percentages aren't for the replay but rather for the reindexing" as if "replay" and "reindexing" are different things. They're actually the same thing.
I agree the get_blockchain_synop message is spammy and we should probably get rid of it.
Yes, I thought they were different. If they are truly the same thing, why bother having 2 separate command line args?
I bet you guys just like to confuse us for fun! ;)
-
In Graphene terminology, "reindexing" and "replaying" are the same thing.
Yes, I thought they were different. If they are truly the same thing, why bother having 2 separate command line args?
I bet you guys just like to confuse us for fun! ;)
There's also "resyncing" which is different. Reindexing / replaying just nukes the chain state DB, but keeps the blocks and reads them off the local disk. Resyncing nukes the blocks too, and re-downloads them from the network.
rm -Rf witness_node_data_dir/blockchain/object_database # this is what reindex / replay does
rm -Rf witness_node_data_dir/blockchain # this is what resync does
-
In Graphene terminology, "reindexing" and "replaying" are the same thing.
Yes, I thought they were different. If they are truly the same thing, why bother having 2 separate command line args?
I bet you guys just like to confuse us for fun! ;)
There's also "resyncing" which is different. Reindexing / replaying just nukes the chain state DB, but keeps the blocks and reads them off the local disk. Resyncing nukes the blocks too, and re-downloads them from the network.
rm -Rf witness_node_data_dir/blockchain/object_database # this is what reindex / replay does
rm -Rf witness_node_data_dir/blockchain # this is what resync does
Coolness, thanks for the info theoretical!
I just switched production to to another VPS, which worked well and quickly. That was an excellent and very important enhancement! With just a bit of automation we can detect and switch to alternate witness nodes in case of attack or any other reason. Nice!
-
@Spectral @Bhuz
If you guys are having trouble publishing feeds, could you update to latest master and try again? I made the error message you're getting more informative.
I had similar error messages... turns out the hard drive was full (p2p logs)
-
Ok, disk space wasn't the issue.. I'm getting the following when I try to publish feeds:
grapheneapi.grapheneapi.RPCError: 0 exception: unspecified
10 assert_exception: Assert Exception
o.feed.settlement_price.base.asset_id == o.feed.core_exchange_rate.base.asset_id:
{}
th_a asset_evaluator.cpp:590 do_evaluate
{"o":{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":3596211,"asset_id":"1.3.285"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":3596211,"asset_id":"1.3.285"}}},"extensions":[]}}
th_a asset_evaluator.cpp:610 do_evaluate
{}
th_a evaluator.cpp:42 start_evaluate
{}
th_a db_block.cpp:628 apply_operation
{"trx":{"ref_block_num":48293,"ref_block_prefix":2029125297,"expiration":"2015-10-09T22:26:39","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":3596211,"asset_id":"1.3.285"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":3596211,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures [........]
Updating to master.. my last build was about 20 hours ago
-
Would you guys mind doing some trading in the USD/CORE market? We have price history charts working now but the data is a bit sparse, would like some more to evaluate the charts.
-
@Spectral @Bhuz
If you guys are having trouble publishing feeds, could you update to latest master and try again? I made the error message you're getting more informative.
done.
$ git describe --tags
test6-41-g837e4f2
I tried running the price feed script again, and the cli_wallet produced the following output:
2595660ms th_a wallet.cpp:1719 sign_transaction ] Caught exception while broadcasting tx 53a3e9f8dc2e0205e20eafd845d7f6022575b0bc: 0 exception: unspecified
10 assert_exception: Assert Exception
o.feed.settlement_price.base.asset_id == o.feed.core_exchange_rate.base.asset_id:
{}
th_a asset_evaluator.cpp:599 do_evaluate
{"o":{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.73210","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":86,"asset_id":"1.3.285"},"quote":{"amount":23547,"asset_id":"
1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":24724,"asset_id":"1.3.0"},"quote":{"amount":86,"asset_id":"1.3.285"}}},"extensions":[
]}}
th_a asset_evaluator.cpp:623 do_evaluate
{}
th_a evaluator.cpp:42 start_evaluate
{}
th_a db_block.cpp:629 apply_operation
{"trx":{"ref_block_num":48609,"ref_block_prefix":3433226527,"expiration":"2015-10-09T22:43:42","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.73210","asset_id":"1.3.285
","feed":{"settlement_price":{"base":{"amount":86,"asset_id":"1.3.285"},"quote":{"amount":23547,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_r
ate":{"base":{"amount":24724,"asset_id":"1.3.0"},"quote":{"amount":86,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures":["205c37c634a4e49c5d6a8e6cb47b00a51e9bd97df56cae1c96d92a1c2c35
9e05881989c26aa7e5494620202f5c478fb12d7260b16ea932f3b0ff6bcf5450bba744"]}}
th_a db_block.cpp:612 _apply_transaction
{"trx":{"ref_block_num":48609,"ref_block_prefix":3433226527,"expiration":"2015-10-09T22:43:42","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.73210","asset_id":"1.3.285
","feed":{"settlement_price":{"base":{"amount":86,"asset_id":"1.3.285"},"quote":{"amount":23547,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_r
ate":{"base":{"amount":24724,"asset_id":"1.3.0"},"quote":{"amount":86,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures":["205c37c634a4e49c5d6a8e6cb47b00a51e9bd97df56cae1c96d92a1c2c35
9e05881989c26aa7e5494620202f5c478fb12d7260b16ea932f3b0ff6bcf5450bba744"]}}
th_a db_block.cpp:216 push_transaction
{"error":"10 assert_exception: Assert Exception\no.feed.settlement_price.base.asset_id == o.feed.core_exchange_rate.base.asset_id: \n {}\n th_a asset_evaluator.cpp:599 do_evaluate\n\n {\"o\"
:{\"fee\":{\"amount\":100000,\"asset_id\":\"1.3.0\"},\"publisher\":\"1.2.73210\",\"asset_id\":\"1.3.285\",\"feed\":{\"settlement_price\":{\"base\":{\"amount\":86,\"asset_id\":\"1.3.285\"},\"quote\":{\"amo
unt\":23547,\"asset_id\":\"1.3.0\"}},\"maintenance_collateral_ratio\":1750,\"maximum_short_squeeze_ratio\":1500,\"core_exchange_rate\":{\"base\":{\"amount\":24724,\"asset_id\":\"1.3.0\"},\"quote\":{\"amou
nt\":86,\"asset_id\":\"1.3.285\"}}},\"extensions\":[]}}\n th_a asset_evaluator.cpp:623 do_evaluate\n\n {}\n th_a evaluator.cpp:42 start_evaluate\n\n {}\n th_a db_block.cpp:629 apply_oper
ation\n\n {\"trx\":{\"ref_block_num\":48609,\"ref_block_prefix\":3433226527,\"expiration\":\"2015-10-09T22:43:42\",\"operations\":[[19,{\"fee\":{\"amount\":100000,\"asset_id\":\"1.3.0\"},\"publisher\":
\"1.2.73210\",\"asset_id\":\"1.3.285\",\"feed\":{\"settlement_price\":{\"base\":{\"amount\":86,\"asset_id\":\"1.3.285\"},\"quote\":{\"amount\":23547,\"asset_id\":\"1.3.0\"}},\"maintenance_collateral_ratio
\":1750,\"maximum_short_squeeze_ratio\":1500,\"core_exchange_rate\":{\"base\":{\"amount\":24724,\"asset_id\":\"1.3.0\"},\"quote\":{\"amount\":86,\"asset_id\":\"1.3.285\"}}},\"extensions\":[]}]],\"extensio
ns\":[],\"signatures\":[\"205c37c634a4e49c5d6a8e6cb47b00a51e9bd97df56cae1c96d92a1c2c359e05881989c26aa7e5494620202f5c478fb12d7260b16ea932f3b0ff6bcf5450bba744\"]}}\n th_a db_block.cpp:612 _apply_transac
tion\n\n {\"trx\":{\"ref_block_num\":48609,\"ref_block_prefix\":3433226527,\"expiration\":\"2015-10-09T22:43:42\",\"operations\":[[19,{\"fee\":{\"amount\":100000,\"asset_id\":\"1.3.0\"},\"publisher\":\
"1.2.73210\",\"asset_id\":\"1.3.285\",\"feed\":{\"settlement_price\":{\"base\":{\"amount\":86,\"asset_id\":\"1.3.285\"},\"quote\":{\"amount\":23547,\"asset_id\":\"1.3.0\"}},\"maintenance_collateral_ratio\
":1750,\"maximum_short_squeeze_ratio\":1500,\"core_exchange_rate\":{\"base\":{\"amount\":24724,\"asset_id\":\"1.3.0\"},\"quote\":{\"amount\":86,\"asset_id\":\"1.3.285\"}}},\"extensions\":[]}]],\"extension
s\":[],\"signatures\":[\"205c37c634a4e49c5d6a8e6cb47b00a51e9bd97df56cae1c96d92a1c2c359e05881989c26aa7e5494620202f5c478fb12d7260b16ea932f3b0ff6bcf5450bba744\"]}}\n th_a db_block.cpp:216 push_transactio
n","data":{"id":30,"error":{"code":1,"message":"10 assert_exception: Assert Exception\no.feed.settlement_price.base.asset_id == o.feed.core_exchange_rate.base.asset_id: \n {}\n th_a asset_evaluator
.cpp:599 do_evaluate\n\n {\"o\":{\"fee\":{\"amount\":100000,\"asset_id\":\"1.3.0\"},\"publisher\":\"1.2.73210\",\"asset_id\":\"1.3.285\",\"feed\":{\"settlement_price\":{\"base\":{\"amount\":86,\"asset_
id\":\"1.3.285\"},\"quote\":{\"amount\":23547,\"asset_id\":\"1.3.0\"}},\"maintenance_collateral_ratio\":1750,\"maximum_short_squeeze_ratio\":1500,\"core_exchange_rate\":{\"base\":{\"amount\":24724,\"asset
_id\":\"1.3.0\"},\"quote\":{\"amount\":86,\"asset_id\":\"1.3.285\"}}},\"extensions\":[]}}\n th_a asset_evaluator.cpp:623 do_evaluate\n\n {}\n th_a evaluator.cpp:42 start_evaluate\n\n {}\n
th_a db_block.cpp:629 apply_operation\n\n {\"trx\":{\"ref_block_num\":48609,\"ref_block_prefix\":3433226527,\"expiration\":\"2015-10-09T22:43:42\",\"operations\":[[19,{\"fee\":{\"amount\":100000,\"as
set_id\":\"1.3.0\"},\"publisher\":\"1.2.73210\",\"asset_id\":\"1.3.285\",\"feed\":{\"settlement_price\":{\"base\":{\"amount\":86,\"asset_id\":\"1.3.285\"},\"quote\":{\"amount\":23547,\"asset_id\":\"1.3.0\
"}},\"maintenance_collateral_ratio\":1750,\"maximum_short_squeeze_ratio\":1500,\"core_exchange_rate\":{\"base\":{\"amount\":24724,\"asset_id\":\"1.3.0\"},\"quote\":{\"amount\":86,\"asset_id\":\"1.3.285\"}
}},\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"205c37c634a4e49c5d6a8e6cb47b00a51e9bd97df56cae1c96d92a1c2c359e05881989c26aa7e5494620202f5c478fb12d7260b16ea932f3b0ff6bcf5450bba744\"]}}\n th_
a db_block.cpp:612 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":48609,\"ref_block_prefix\":3433226527,\"expiration\":\"2015-10-09T22:43:42\",\"operations\":[[19,{\"fee\":{\"amount\":100000,\"ass
et_id\":\"1.3.0\"},\"publisher\":\"1.2.73210\",\"asset_id\":\"1.3.285\",\"feed\":{\"settlement_price\":{\"base\":{\"amount\":86,\"asset_id\":\"1.3.285\"},\"quote\":{\"amount\":23547,\"asset_id\":\"1.3.0\"
}},\"maintenance_collateral_ratio\":1750,\"maximum_short_squeeze_ratio\":1500,\"core_exchange_rate\":{\"base\":{\"amount\":24724,\"asset_id\":\"1.3.0\"},\"quote\":{\"amount\":86,\"asset_id\":\"1.3.285\"}}
},\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"205c37c634a4e49c5d6a8e6cb47b00a51e9bd97df56cae1c96d92a1c2c359e05881989c26aa7e5494620202f5c478fb12d7260b16ea932f3b0ff6bcf5450bba744\"]}}\n th_a
db_block.cpp:216 push_transaction","data":{"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"asset_evaluator.cpp","line":599,"method":"do_eval
uate","hostname":"","thread_name":"th_a","timestamp":"2015-10-09T22:43:15"},"format":"o.feed.settlement_price.base.asset_id == o.feed.core_exchange_rate.base.asset_id: ","data":{}},{"context":{"level":"wa
rn","file":"asset_evaluator.cpp","line":623,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-09T22:43:15"},"format":"","data":{"o":{"fee":{"amount":100000,"asset_id":"1.3.0"}
,"publisher":"1.2.73210","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":86,"asset_id":"1.3.285"},"quote":{"amount":23547,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximu
m_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":24724,"asset_id":"1.3.0"},"quote":{"amount":86,"asset_id":"1.3.285"}}},"extensions":[]}}},{"context":{"level":"warn","file":"evaluator.cp
p","line":42,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-09T22:43:15"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":629,"method":"ap
ply_operation","hostname":"","thread_name":"th_a","timestamp":"2015-10-09T22:43:15"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":612,"method":"_apply_transaction","hostn
ame":"","thread_name":"th_a","timestamp":"2015-10-09T22:43:15"},"format":"","data":{"trx":{"ref_block_num":48609,"ref_block_prefix":3433226527,"expiration":"2015-10-09T22:43:42","operations":[[19,{"fee":{
"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.73210","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":86,"asset_id":"1.3.285"},"quote":{"amount":23547,"asset_id":"1.3.0"}},"mainten
ance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":24724,"asset_id":"1.3.0"},"quote":{"amount":86,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions"
:[],"signatures":["205c37c634a4e49c5d6a8e6cb47b00a51e9bd97df56cae1c96d92a1c2c359e05881989c26aa7e5494620202f5c478fb12d7260b16ea932f3b0ff6bcf5450bba744"]}}},{"context":{"level":"warn","file":"db_block.cpp",
"line":216,"method":"push_transaction","hostname":"","thread_name":"th_a","timestamp":"2015-10-09T22:43:15"},"format":"","data":{"trx":{"ref_block_num":48609,"ref_block_prefix":3433226527,"expiration":"20
15-10-09T22:43:42","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.73210","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":86,"asset_id":"1.3.285"},"quote":
{"amount":23547,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":24724,"asset_id":"1.3.0"},"quote":{"amount":86,"asset_id"
:"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures":["205c37c634a4e49c5d6a8e6cb47b00a51e9bd97df56cae1c96d92a1c2c359e05881989c26aa7e5494620202f5c478fb12d7260b16ea932f3b0ff6bcf5450bba744"]}}}]}}}}
th_a state.cpp:38 handle_reply
I'm also still having some strange problem with the transaction memos not decrypting. Output from the get_account_history command:
2989476ms th_a wallet.cpp:2323 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k not in this wallet.
{"k":"GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k"}
th_a wallet.cpp:2316 operator()
2989495ms th_a wallet.cpp:2323 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw not in this wallet.
{"k":"GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw"}
th_a wallet.cpp:2316 operator()
2990094ms th_a wallet.cpp:2323 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k not in this wallet.
{"k":"GPH8jnprUyAGGJ4M2HGD1kKNN5NgE85anQEdsvrFpLX4nvQ4CxA2k"}
th_a wallet.cpp:2316 operator()
2990122ms th_a wallet.cpp:2323 operator() ] Error when decrypting memo: 10 assert_exception: Assert Exception
wallet._keys.count(op.memo->to): Memo is encrypted to a key GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw not in this wallet.
{"k":"GPH7B4bszRYW5SKGFUKuM6ta95MUR81ZsjUTyxLAn4Pezu5Ck9xsw"}
th_a wallet.cpp:2316 operator()
wallet is unlocked.
-
@Spectral @Bhuz
If you guys are having trouble publishing feeds, could you update to latest master and try again? I made the error message you're getting more informative.
Done
2081915ms th_a wallet.cpp:1719 sign_transaction ] Caught exception while broadcasting tx 33ab1b89f6e9e2ccfbf31cc48cd49d18ece1bc90: 0 exception: unspecified
10 assert_exception: Assert Exception
o.feed.settlement_price.base.asset_id == o.feed.core_exchange_rate.base.asset_id:
{}
th_a asset_evaluator.cpp:599 do_evaluate
{"o":{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.7174","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":353,"asset_id":"1.3.285"},"quote":{"amount":96703,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":101538,"asset_id":"1.3.0"},"quote":{"amount":353,"asset_id":"1.3.285"}}},"extensions":[]}}
th_a asset_evaluator.cpp:623 do_evaluate
{}
th_a evaluator.cpp:42 start_evaluate
{}
th_a db_block.cpp:629 apply_operation
{"trx":{"ref_block_num":53074,"ref_block_prefix":2214551896,"expiration":"2015-10-10T02:35:09","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.7174","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":353,"asset_id":"1.3.285"},"quote":{"amount":96703,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":101538,"asset_id":"1.3.0"},"quote":{"amount":353,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures":["203cee9971e3ecbcbcb53cf0a31b00a0c10d81efc54f1ee9fa26407de9c08f868e739669a7c6342673284a11a75e147bc2900e2c6e93e82fba3316c70337e9ec42"]}}
th_a db_block.cpp:612 _apply_transaction
{"trx":{"ref_block_num":53074,"ref_block_prefix":2214551896,"expiration":"2015-10-10T02:35:09","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.7174","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":353,"asset_id":"1.3.285"},"quote":{"amount":96703,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":101538,"asset_id":"1.3.0"},"quote":{"amount":353,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures":["203cee9971e3ecbcbcb53cf0a31b00a0c10d81efc54f1ee9fa26407de9c08f868e739669a7c6342673284a11a75e147bc2900e2c6e93e82fba3316c70337e9ec42"]}}
th_a db_block.cpp:216 push_transaction
{"error":"10 assert_exception: Assert Exception\no.feed.settlement_price.base.asset_id == o.feed.core_exchange_rate.base.asset_id: \n {}\n th_a asset_evaluator.cpp:599 do_evaluate\n\n {\"o\":{\"fee\":{\"amount\":100000,\"asset_id\":\"1.3.0\"},\"publisher\":\"1.2.7174\",\"asset_id\":\"1.3.285\",\"feed\":{\"settlement_price\":{\"base\":{\"amount\":353,\"asset_id\":\"1.3.285\"},\"quote\":{\"amount\":96703,\"asset_id\":\"1.3.0\"}},\"maintenance_collateral_ratio\":1750,\"maximum_short_squeeze_ratio\":1500,\"core_exchange_rate\":{\"base\":{\"amount\":101538,\"asset_id\":\"1.3.0\"},\"quote\":{\"amount\":353,\"asset_id\":\"1.3.285\"}}},\"extensions\":[]}}\n th_a asset_evaluator.cpp:623 do_evaluate\n\n {}\n th_a evaluator.cpp:42 start_evaluate\n\n {}\n th_a db_block.cpp:629 apply_operation\n\n {\"trx\":{\"ref_block_num\":53074,\"ref_block_prefix\":2214551896,\"expiration\":\"2015-10-10T02:35:09\",\"operations\":[[19,{\"fee\":{\"amount\":100000,\"asset_id\":\"1.3.0\"},\"publisher\":\"1.2.7174\",\"asset_id\":\"1.3.285\",\"feed\":{\"settlement_price\":{\"base\":{\"amount\":353,\"asset_id\":\"1.3.285\"},\"quote\":{\"amount\":96703,\"asset_id\":\"1.3.0\"}},\"maintenance_collateral_ratio\":1750,\"maximum_short_squeeze_ratio\":1500,\"core_exchange_rate\":{\"base\":{\"amount\":101538,\"asset_id\":\"1.3.0\"},\"quote\":{\"amount\":353,\"asset_id\":\"1.3.285\"}}},\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"203cee9971e3ecbcbcb53cf0a31b00a0c10d81efc54f1ee9fa26407de9c08f868e739669a7c6342673284a11a75e147bc2900e2c6e93e82fba3316c70337e9ec42\"]}}\n th_a db_block.cpp:612 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":53074,\"ref_block_prefix\":2214551896,\"expiration\":\"2015-10-10T02:35:09\",\"operations\":[[19,{\"fee\":{\"amount\":100000,\"asset_id\":\"1.3.0\"},\"publisher\":\"1.2.7174\",\"asset_id\":\"1.3.285\",\"feed\":{\"settlement_price\":{\"base\":{\"amount\":353,\"asset_id\":\"1.3.285\"},\"quote\":{\"amount\":96703,\"asset_id\":\"1.3.0\"}},\"maintenance_collateral_ratio\":1750,\"maximum_short_squeeze_ratio\":1500,\"core_exchange_rate\":{\"base\":{\"amount\":101538,\"asset_id\":\"1.3.0\"},\"quote\":{\"amount\":353,\"asset_id\":\"1.3.285\"}}},\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"203cee9971e3ecbcbcb53cf0a31b00a0c10d81efc54f1ee9fa26407de9c08f868e739669a7c6342673284a11a75e147bc2900e2c6e93e82fba3316c70337e9ec42\"]}}\n th_a db_block.cpp:216 push_transaction","data":{"id":42,"error":{"code":1,"message":"10 assert_exception: Assert Exception\no.feed.settlement_price.base.asset_id == o.feed.core_exchange_rate.base.asset_id: \n {}\n th_a asset_evaluator.cpp:599 do_evaluate\n\n {\"o\":{\"fee\":{\"amount\":100000,\"asset_id\":\"1.3.0\"},\"publisher\":\"1.2.7174\",\"asset_id\":\"1.3.285\",\"feed\":{\"settlement_price\":{\"base\":{\"amount\":353,\"asset_id\":\"1.3.285\"},\"quote\":{\"amount\":96703,\"asset_id\":\"1.3.0\"}},\"maintenance_collateral_ratio\":1750,\"maximum_short_squeeze_ratio\":1500,\"core_exchange_rate\":{\"base\":{\"amount\":101538,\"asset_id\":\"1.3.0\"},\"quote\":{\"amount\":353,\"asset_id\":\"1.3.285\"}}},\"extensions\":[]}}\n th_a asset_evaluator.cpp:623 do_evaluate\n\n {}\n th_a evaluator.cpp:42 start_evaluate\n\n {}\n th_a db_block.cpp:629 apply_operation\n\n {\"trx\":{\"ref_block_num\":53074,\"ref_block_prefix\":2214551896,\"expiration\":\"2015-10-10T02:35:09\",\"operations\":[[19,{\"fee\":{\"amount\":100000,\"asset_id\":\"1.3.0\"},\"publisher\":\"1.2.7174\",\"asset_id\":\"1.3.285\",\"feed\":{\"settlement_price\":{\"base\":{\"amount\":353,\"asset_id\":\"1.3.285\"},\"quote\":{\"amount\":96703,\"asset_id\":\"1.3.0\"}},\"maintenance_collateral_ratio\":1750,\"maximum_short_squeeze_ratio\":1500,\"core_exchange_rate\":{\"base\":{\"amount\":101538,\"asset_id\":\"1.3.0\"},\"quote\":{\"amount\":353,\"asset_id\":\"1.3.285\"}}},\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"203cee9971e3ecbcbcb53cf0a31b00a0c10d81efc54f1ee9fa26407de9c08f868e739669a7c6342673284a11a75e147bc2900e2c6e93e82fba3316c70337e9ec42\"]}}\n th_a db_block.cpp:612 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":53074,\"ref_block_prefix\":2214551896,\"expiration\":\"2015-10-10T02:35:09\",\"operations\":[[19,{\"fee\":{\"amount\":100000,\"asset_id\":\"1.3.0\"},\"publisher\":\"1.2.7174\",\"asset_id\":\"1.3.285\",\"feed\":{\"settlement_price\":{\"base\":{\"amount\":353,\"asset_id\":\"1.3.285\"},\"quote\":{\"amount\":96703,\"asset_id\":\"1.3.0\"}},\"maintenance_collateral_ratio\":1750,\"maximum_short_squeeze_ratio\":1500,\"core_exchange_rate\":{\"base\":{\"amount\":101538,\"asset_id\":\"1.3.0\"},\"quote\":{\"amount\":353,\"asset_id\":\"1.3.285\"}}},\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"203cee9971e3ecbcbcb53cf0a31b00a0c10d81efc54f1ee9fa26407de9c08f868e739669a7c6342673284a11a75e147bc2900e2c6e93e82fba3316c70337e9ec42\"]}}\n th_a db_block.cpp:216 push_transaction","data":{"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"asset_evaluator.cpp","line":599,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-10T02:34:41"},"format":"o.feed.settlement_price.base.asset_id == o.feed.core_exchange_rate.base.asset_id: ","data":{}},{"context":{"level":"warn","file":"asset_evaluator.cpp","line":623,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-10T02:34:41"},"format":"","data":{"o":{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.7174","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":353,"asset_id":"1.3.285"},"quote":{"amount":96703,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":101538,"asset_id":"1.3.0"},"quote":{"amount":353,"asset_id":"1.3.285"}}},"extensions":[]}}},{"context":{"level":"warn","file":"evaluator.cpp","line":42,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2015-10-10T02:34:41"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":629,"method":"apply_operation","hostname":"","thread_name":"th_a","timestamp":"2015-10-10T02:34:41"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":612,"method":"_apply_transaction","hostname":"","thread_name":"th_a","timestamp":"2015-10-10T02:34:41"},"format":"","data":{"trx":{"ref_block_num":53074,"ref_block_prefix":2214551896,"expiration":"2015-10-10T02:35:09","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.7174","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":353,"asset_id":"1.3.285"},"quote":{"amount":96703,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":101538,"asset_id":"1.3.0"},"quote":{"amount":353,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures":["203cee9971e3ecbcbcb53cf0a31b00a0c10d81efc54f1ee9fa26407de9c08f868e739669a7c6342673284a11a75e147bc2900e2c6e93e82fba3316c70337e9ec42"]}}},{"context":{"level":"warn","file":"db_block.cpp","line":216,"method":"push_transaction","hostname":"","thread_name":"th_a","timestamp":"2015-10-10T02:34:41"},"format":"","data":{"trx":{"ref_block_num":53074,"ref_block_prefix":2214551896,"expiration":"2015-10-10T02:35:09","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.7174","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":353,"asset_id":"1.3.285"},"quote":{"amount":96703,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":101538,"asset_id":"1.3.0"},"quote":{"amount":353,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures":["203cee9971e3ecbcbcb53cf0a31b00a0c10d81efc54f1ee9fa26407de9c08f868e739669a7c6342673284a11a75e147bc2900e2c6e93e82fba3316c70337e9ec42"]}}}]}}}}
th_a state.cpp:38 handle_reply
-
After updating I still get the same error publishing feeds:
1205725ms th_a wallet.cpp:1719 sign_transaction ] Caught exception while broadcasting tx 5656846e0b9426246f4a21fee5e79ceca9941f0a: 0 exception: unspecified
10 assert_exception: Assert Exception
o.feed.settlement_price.base.asset_id == o.feed.core_exchange_rate.base.asset_id:
{}
th_a asset_evaluator.cpp:599 do_evaluate
{"o":{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":3606173,"asset_id":"1.3.285"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":3606173,"asset_id":"1.3.285"}}},"extensions":[]}}
th_a asset_evaluator.cpp:623 do_evaluate
{}
th_a evaluator.cpp:42 start_evaluate
{}
th_a db_block.cpp:629 apply_operation
{"trx":{"ref_block_num":53953,"ref_block_prefix":773159248,"expiration":"2015-10-10T03:20:33","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":3606173,"asset_id":"1.3.285"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":3606173,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures":[" [.......]
-
I'm unable to publish price feed too.
-
After updating I still get the same error publishing feeds:
1205725ms th_a wallet.cpp:1719 sign_transaction ] Caught exception while broadcasting tx 5656846e0b9426246f4a21fee5e79ceca9941f0a: 0 exception: unspecified
10 assert_exception: Assert Exception
o.feed.settlement_price.base.asset_id == o.feed.core_exchange_rate.base.asset_id:
{}
th_a asset_evaluator.cpp:599 do_evaluate
{"o":{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":3606173,"asset_id":"1.3.285"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":3606173,"asset_id":"1.3.285"}}},"extensions":[]}}
th_a asset_evaluator.cpp:623 do_evaluate
{}
th_a evaluator.cpp:42 start_evaluate
{}
th_a db_block.cpp:629 apply_operation
{"trx":{"ref_block_num":53953,"ref_block_prefix":773159248,"expiration":"2015-10-10T03:20:33","operations":[[19,{"fee":{"amount":100000,"asset_id":"1.3.0"},"publisher":"1.2.67704","asset_id":"1.3.285","feed":{"settlement_price":{"base":{"amount":3606173,"asset_id":"1.3.285"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1500,"core_exchange_rate":{"base":{"amount":1000000000,"asset_id":"1.3.0"},"quote":{"amount":3606173,"asset_id":"1.3.285"}}},"extensions":[]}]],"extensions":[],"signatures":[" [.......]
The price ratio of either the settlement price or the core exchange rate is inverted. In effect what is going on is this:
Settlement price: X USD / CORE
Core Exchange Rate: Y CORE / USD
The requirement enforced by the transaction is that both prices must be in the same orientation.
-
The price ratio of either the settlement price or the core exchange rate is inverted. In effect what is going on is this:
Settlement price: X USD / CORE
Core Exchange Rate: Y CORE / USD
The requirement enforced by the transaction is that both prices must be in the same orientation.
Based on your feedback, I made some workaround changes to xeroc's script pricefeeds.py (until he is back to fix the script) and it seems to work.
Witnesses, please try out the changes and see if they work for you.
line 478:
#availableAssets = [ core_symbol, "BTC" ]
#for coin in availableAssets :
# if float(result[coin.lower()+"cny"]["ticker"]["last"]) < config.minValidAssetPrice:
# print("Unreliable results from yunbi for %s"%(coin))
# continue
# price["CNY"][ coin ].append(float(result[coin.lower()+"cny"]["ticker"]["last"]))
# volume["CNY"][ coin ].append(float(result[coin.lower()+"cny"]["ticker"]["vol"])*config.yunbi_trust_level)
line 415: disable all exchanges except yunbi and poloniex. BTW, btc38 is returning a 'failed' message.
#mythreads["yahoo"] = threading.Thread(target = fetch_from_yahoo)
mythreads["yunbi"] = threading.Thread(target = fetch_from_yunbi)
#mythreads["btc38"] = threading.Thread(target = fetch_from_btc38)
#mythreads["bter"] = threading.Thread(target = fetch_from_bter)
mythreads["poloniex"] = threading.Thread(target = fetch_from_poloniex)
#mythreads["bittrex"] = threading.Thread(target = fetch_from_bittrex)
#mythreads["btcavg"] = threading.Thread(target = fetch_bitcoinaverage)
line 362: enables only USD and BTC
#_all_bts_assets = ["CNY", "BTC", "EUR", "USD"]
_all_bts_assets = ["USD", "BTC"]
#_bases =["CNY", "USD", "BTC", "EUR"]
_bases =["USD", "BTC"]
#_yahoo_base = ["USD","EUR", "CNY"]
_yahoo_base = ["USD", "BTC"]
#_yahoo_quote = ["USD","EUR", "CNY"]
_yahoo_quote = ["USD", "BTC"]
Edit: The Graphene webwallet node (graphene.bitshares.org) seems to be in a fork.
-
The price ratio of either the settlement price or the core exchange rate is inverted. In effect what is going on is this:
Settlement price: X USD / CORE
Core Exchange Rate: Y CORE / USD
The requirement enforced by the transaction is that both prices must be in the same orientation.
Based on your feedback, I made some workaround changes to xeroc's script pricefeeds.py (until he is back to fix the script) and it seems to work.
Witnesses, please try out the changes and see if they work for you.
line 478:
#availableAssets = [ core_symbol, "BTC" ]
#for coin in availableAssets :
# if float(result[coin.lower()+"cny"]["ticker"]["last"]) < config.minValidAssetPrice:
# print("Unreliable results from yunbi for %s"%(coin))
# continue
# price["CNY"][ coin ].append(float(result[coin.lower()+"cny"]["ticker"]["last"]))
# volume["CNY"][ coin ].append(float(result[coin.lower()+"cny"]["ticker"]["vol"])*config.yunbi_trust_level)
line 415: disable all exchanges except yunbi and poloniex. BTW, btc38 is returning a 'failed' message.
#mythreads["yahoo"] = threading.Thread(target = fetch_from_yahoo)
mythreads["yunbi"] = threading.Thread(target = fetch_from_yunbi)
#mythreads["btc38"] = threading.Thread(target = fetch_from_btc38)
#mythreads["bter"] = threading.Thread(target = fetch_from_bter)
mythreads["poloniex"] = threading.Thread(target = fetch_from_poloniex)
#mythreads["bittrex"] = threading.Thread(target = fetch_from_bittrex)
#mythreads["btcavg"] = threading.Thread(target = fetch_bitcoinaverage)
line 362: enables only USD and BTC
#_all_bts_assets = ["CNY", "BTC", "EUR", "USD"]
_all_bts_assets = ["USD", "BTC"]
#_bases =["CNY", "USD", "BTC", "EUR"]
_bases =["USD", "BTC"]
#_yahoo_base = ["USD","EUR", "CNY"]
_yahoo_base = ["USD", "BTC"]
#_yahoo_quote = ["USD","EUR", "CNY"]
_yahoo_quote = ["USD", "BTC"]
Edit: The Graphene webwallet node (graphene.bitshares.org) seems to be in a fork.
thank you for the update cube, I'll test it in a while. Indeed webwallet node seems to be in a fork.
Is @triox running the webwallet node? he is the only witness on that chain. Stuck ~2000 blocks behind so far
-
Seema more work needs to be spend for the feed script ..
Btw .. the current master does require manual confirmation of the feed prices .. hence you cant put it unto a cronjob
-
Is @triox running the webwallet node? he is the only witness on that chain. Stuck ~2000 blocks behind so far
I'm not running it.
I'm back on the main chain now.
-
Is @triox running the webwallet node? he is the only witness on that chain. Stuck ~2000 blocks behind so far
I'm not running it.
I'm back on the main chain now.
Thanks for the fast answer. Could you share your log? It might help as it seems that only you and the wallet node gone into that fork. did you have to replay or resync blockchain or it just recovered alone? on what commit are you running your witness?
-
wallet message (if you don't know already)
(http://snag.gy/drMCp.jpg)
-
Is @triox running the webwallet node? he is the only witness on that chain. Stuck ~2000 blocks behind so far
I'm not running it.
I'm back on the main chain now.
Thanks for the fast answer. Could you share your log? It might help as it seems that only you and the wallet node gone into that fork. did you have to replay or resync blockchain or it just recovered alone? on what commit are you running your witness?
Your post was the first thing I saw after waking up, so thanks : )
I recovered by - first - springing out of bed, then deleting the blockchain folder and starting with --replay-blockchain.
I'm on
git describe --tags
test6-30-g7fe0e64commit 7fe0e64a5e38df88c5dea32ae35f371e5c425010
Author: Eric Frias <efrias@syncad.com>
Date: Fri Oct 9 11:42:56 2015 -0400
Tell me what to look for in the logs.
-
Is @triox running the webwallet node? he is the only witness on that chain. Stuck ~2000 blocks behind so far
I'm not running it.
I'm back on the main chain now.
Thanks for the fast answer. Could you share your log? It might help as it seems that only you and the wallet node gone into that fork. did you have to replay or resync blockchain or it just recovered alone? on what commit are you running your witness?
Your post was the first thing I saw after waking up, so thanks : )
I recovered by - first - springing out of bed, then deleting the blockchain folder and starting with --replay-blockchain.
I'm on
git describe --tags
test6-30-g7fe0e64commit 7fe0e64a5e38df88c5dea32ae35f371e5c425010
Author: Eric Frias <efrias@syncad.com>
Date: Fri Oct 9 11:42:56 2015 -0400
Tell me what to look for in the logs.
You are 11 commits behind last master. Can't say if that's related with your witness not recovering from a fork.
You can look inside your datadir/logs/p2p/p2p.log.20151010T040000
maybe searching for block 120718 can help to see if there's a relation, that's where the webwallet node got stuck.
Or see if there's any error message near 2015-10-10T04:24:15
I still understand just a fraction of what logs say but this might help devs to debug this issue.
-
@cube
I modified the scrupt, and i get this output
[Starting Threads]: (poloniex)(yunbi)..Error in asset USD: no median for empty data
Error in asset BTC: no median for empty data
Update required! Forcing now!
publishing feeds for delegate: bhuz
But on the cli_wallet side there are no asset_publish_feed_operation in the account history, and the balance is always the same
-
@cube
I modified the scrupt, and i get this output
[Starting Threads]: (poloniex)(yunbi)..Error in asset USD: no median for empty data
Error in asset BTC: no median for empty data
Update required! Forcing now!
publishing feeds for delegate: bhuz
But on the cli_wallet side there are no asset_publish_feed_operation in the account history, and the balance is always the same
The changes are not working. I reverted to the original script and made the following changes instead. This time it gets through.
You will need to revert to original script and apply the changes below.
Only disable bter
mythreads["yahoo"] = threading.Thread(target = fetch_from_yahoo)
mythreads["yunbi"] = threading.Thread(target = fetch_from_yunbi)
#mythreads["btc38"] = threading.Thread(target = fetch_from_btc38)
#mythreads["bter"] = threading.Thread(target = fetch_from_bter)
mythreads["poloniex"] = threading.Thread(target = fetch_from_poloniex)
mythreads["bittrex"] = threading.Thread(target = fetch_from_bittrex)
mythreads["btcavg"] = threading.Thread(target = fetch_bitcoinaverage)
under price feed, swap the lines involving the asset ids
"core_exchange_rate": {
"quote": {
"asset_id": "1.3.0",
"amount": int(denominator * 1.05) # 5% extra
},
"base": {
"asset_id": assets[asset]["id"],
"amount": numerator
}
}
I put up the modified copy here - http://pastebin.com/E9d60Htp
-
Working great, thanks cube
-
You are 11 commits behind last master. Can't say if that's related with your witness not recovering from a fork.
You can look inside your datadir/logs/p2p/p2p.log.20151010T040000
maybe searching for block 120718 can help to see if there's a relation, that's where the webwallet node got stuck.
Or see if there's any error message near 2015-10-10T04:24:15
I still understand just a fraction of what logs say but this might help devs to debug this issue.
That's more than I do. The file's in here:
https://s3.amazonaws.com/logsharebucket/p2p.log.20151010T040000 (https://s3.amazonaws.com/logsharebucket/p2p.log.20151010T040000)
if anyone wants to have a look.
-
@cube
I modified the scrupt, and i get this output
[Starting Threads]: (poloniex)(yunbi)..Error in asset USD: no median for empty data
Error in asset BTC: no median for empty data
Update required! Forcing now!
publishing feeds for delegate: bhuz
But on the cli_wallet side there are no asset_publish_feed_operation in the account history, and the balance is always the same
The changes are not working. I reverted to the original script and made the following changes instead. This time it gets through.
You will need to revert to original script and apply the changes below.
Only disable bter
mythreads["yahoo"] = threading.Thread(target = fetch_from_yahoo)
mythreads["yunbi"] = threading.Thread(target = fetch_from_yunbi)
#mythreads["btc38"] = threading.Thread(target = fetch_from_btc38)
#mythreads["bter"] = threading.Thread(target = fetch_from_bter)
mythreads["poloniex"] = threading.Thread(target = fetch_from_poloniex)
mythreads["bittrex"] = threading.Thread(target = fetch_from_bittrex)
mythreads["btcavg"] = threading.Thread(target = fetch_bitcoinaverage)
under price feed, swap the lines involving the asset ids
"core_exchange_rate": {
"quote": {
"asset_id": "1.3.0",
"amount": int(denominator * 1.05) # 5% extra
},
"base": {
"asset_id": assets[asset]["id"],
"amount": numerator
}
}
I put up the modified copy here - http://pastebin.com/E9d60Htp
had to change delegate_name to delegate_list on config and add brackets.
throws an exception but seems to publish:
[Starting Threads]: (yahoo)USDUSD=X,EURUSD=X,CNYUSD=X
(bittrex)(yunbi)(btcavg)(poloniex)USD
1.0
EUR
1.1358
CNY
0.1576
USDEUR=X,EUREUR=X,CNYEUR=X
USD
0.8804
EUR
1.0
CNY
0.1387
USDCNY=X,EURCNY=X,CNYCNY=X
Exception in thread Thread-3:
Traceback (most recent call last):
File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
self.run()
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "pricefeeds.py", line 144, in fetch_from_poloniex
if float(result["BTC_"+coin]["last"]) > config.minValidAssetPrice:
AttributeError: 'module' object has no attribute 'minValidAssetPrice'
USD
6.3467
EUR
7.2088
CNY
1.0
indices:
..
Error fetching results from yunbi! (HTTPSConnectionPool(host='yunbi.com', port=443): Max retries exceeded with url: /api/v2/tickers.json (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7fe7479a8898>: Failed to establish a new connection: [Errno -2] Name or service not known',)))
...Error in this asset CNY: no median for empty data
Error in this asset BTC: no median for empty data
Error in this asset EUR: no median for empty data
Error in this asset USD: no median for empty data
Update required! Forcing now!
publishing feeds for delegate: bitshares-argentina
-
@cube
I modified the scrupt, and i get this output
[Starting Threads]: (poloniex)(yunbi)..Error in asset USD: no median for empty data
Error in asset BTC: no median for empty data
Update required! Forcing now!
publishing feeds for delegate: bhuz
But on the cli_wallet side there are no asset_publish_feed_operation in the account history, and the balance is always the same
The changes are not working. I reverted to the original script and made the following changes instead. This time it gets through.
You will need to revert to original script and apply the changes below.
Only disable bter
mythreads["yahoo"] = threading.Thread(target = fetch_from_yahoo)
mythreads["yunbi"] = threading.Thread(target = fetch_from_yunbi)
#mythreads["btc38"] = threading.Thread(target = fetch_from_btc38)
#mythreads["bter"] = threading.Thread(target = fetch_from_bter)
mythreads["poloniex"] = threading.Thread(target = fetch_from_poloniex)
mythreads["bittrex"] = threading.Thread(target = fetch_from_bittrex)
mythreads["btcavg"] = threading.Thread(target = fetch_bitcoinaverage)
under price feed, swap the lines involving the asset ids
"core_exchange_rate": {
"quote": {
"asset_id": "1.3.0",
"amount": int(denominator * 1.05) # 5% extra
},
"base": {
"asset_id": assets[asset]["id"],
"amount": numerator
}
}
I put up the modified copy here - http://pastebin.com/E9d60Htp
had to change delegate_name to delegate_list on config and add brackets.
throws an exception but seems to publish:
[Starting Threads]: (yahoo)USDUSD=X,EURUSD=X,CNYUSD=X
(bittrex)(yunbi)(btcavg)(poloniex)USD
1.0
EUR
1.1358
CNY
0.1576
USDEUR=X,EUREUR=X,CNYEUR=X
USD
0.8804
EUR
1.0
CNY
0.1387
USDCNY=X,EURCNY=X,CNYCNY=X
Exception in thread Thread-3:
Traceback (most recent call last):
File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
self.run()
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "pricefeeds.py", line 144, in fetch_from_poloniex
if float(result["BTC_"+coin]["last"]) > config.minValidAssetPrice:
AttributeError: 'module' object has no attribute 'minValidAssetPrice'
USD
6.3467
EUR
7.2088
CNY
1.0
indices:
..
Error fetching results from yunbi! (HTTPSConnectionPool(host='yunbi.com', port=443): Max retries exceeded with url: /api/v2/tickers.json (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7fe7479a8898>: Failed to establish a new connection: [Errno -2] Name or service not known',)))
...Error in this asset CNY: no median for empty data
Error in this asset BTC: no median for empty data
Error in this asset EUR: no median for empty data
Error in this asset USD: no median for empty data
Update required! Forcing now!
publishing feeds for delegate: bitshares-argentina
Your output error:
"Error fetching results from yunbi! (HTTPSConnectionPool(host='yunbi.com', port=443): Max retries exceeded with url: /api/v2/tickers.json (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7fe7479a8898>: Failed to establish a new connection: [Errno -2] Name or service not known',)))"
It seems to be due to yunbi not accepting your IP due to too many retries (ie exceeded the number of connection attempts allowed by yunbi for any IP address). Please try it after an hour or two so that yunbi allows for connection from your machine's IP.
There is another error on 'config.minValidAssetPrice'. It should not be because this variable should be in config.py. There may be a syntax error in your config.py Have you checked it? Can you post it here?
-
There is another error on 'config.minValidAssetPrice'. It should not be because this variable should be in config.py. There may be a syntax error in your config.py Have you checked it? Can you post it here?
I renamed that variable to make clear its in BTC .. please update your config file
-
@cube
I modified the scrupt, and i get this output
[Starting Threads]: (poloniex)(yunbi)..Error in asset USD: no median for empty data
Error in asset BTC: no median for empty data
Update required! Forcing now!
publishing feeds for delegate: bhuz
But on the cli_wallet side there are no asset_publish_feed_operation in the account history, and the balance is always the same
The changes are not working. I reverted to the original script and made the following changes instead. This time it gets through.
You will need to revert to original script and apply the changes below.
Only disable bter
mythreads["yahoo"] = threading.Thread(target = fetch_from_yahoo)
mythreads["yunbi"] = threading.Thread(target = fetch_from_yunbi)
#mythreads["btc38"] = threading.Thread(target = fetch_from_btc38)
#mythreads["bter"] = threading.Thread(target = fetch_from_bter)
mythreads["poloniex"] = threading.Thread(target = fetch_from_poloniex)
mythreads["bittrex"] = threading.Thread(target = fetch_from_bittrex)
mythreads["btcavg"] = threading.Thread(target = fetch_bitcoinaverage)
under price feed, swap the lines involving the asset ids
"core_exchange_rate": {
"quote": {
"asset_id": "1.3.0",
"amount": int(denominator * 1.05) # 5% extra
},
"base": {
"asset_id": assets[asset]["id"],
"amount": numerator
}
}
I put up the modified copy here - http://pastebin.com/E9d60Htp
had to change delegate_name to delegate_list on config and add brackets.
throws an exception but seems to publish:
[Starting Threads]: (yahoo)USDUSD=X,EURUSD=X,CNYUSD=X
(bittrex)(yunbi)(btcavg)(poloniex)USD
1.0
EUR
1.1358
CNY
0.1576
USDEUR=X,EUREUR=X,CNYEUR=X
USD
0.8804
EUR
1.0
CNY
0.1387
USDCNY=X,EURCNY=X,CNYCNY=X
Exception in thread Thread-3:
Traceback (most recent call last):
File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
self.run()
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "pricefeeds.py", line 144, in fetch_from_poloniex
if float(result["BTC_"+coin]["last"]) > config.minValidAssetPrice:
AttributeError: 'module' object has no attribute 'minValidAssetPrice'
USD
6.3467
EUR
7.2088
CNY
1.0
indices:
..
Error fetching results from yunbi! (HTTPSConnectionPool(host='yunbi.com', port=443): Max retries exceeded with url: /api/v2/tickers.json (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7fe7479a8898>: Failed to establish a new connection: [Errno -2] Name or service not known',)))
...Error in this asset CNY: no median for empty data
Error in this asset BTC: no median for empty data
Error in this asset EUR: no median for empty data
Error in this asset USD: no median for empty data
Update required! Forcing now!
publishing feeds for delegate: bitshares-argentina
Your output error:
"Error fetching results from yunbi! (HTTPSConnectionPool(host='yunbi.com', port=443): Max retries exceeded with url: /api/v2/tickers.json (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7fe7479a8898>: Failed to establish a new connection: [Errno -2] Name or service not known',)))"
It seems to be due to yunbi not accepting your IP due to too many retries (ie exceeded the number of connection attempts allowed by yunbi for any IP address). Please try it after an hour or two so that yunbi allows for connection from your machine's IP.
yep yunbi doesnt like my ip I guess, rejected to fetch their ticker from the first time. waited 2 days removing them from the script but still I'm still banned. I've commented that line again.
-
There is another error on 'config.minValidAssetPrice'. It should not be because this variable should be in config.py. There may be a syntax error in your config.py Have you checked it? Can you post it here?
I renamed that variable to make clear its in BTC .. please update your config file
thank you both. this is my config.py
################################################################################
## RPC-client connection information (required)
################################################################################
host = "localhost"
port = 8092
user = ""
passwd = ""
unlock = ""
################################################################################
## Delegate Feed Publish Parameters
################################################################################
delegate_list = ["bitshares-argentina"]
maxAgeFeedInSeconds = 60*60 # 1hour
################################################################################
## Fine tuning
################################################################################
discount = 0.995
core_exchange_factor = 1.05 # 5% surplus if paying fees in bitassets
minValidAssetPriceInBTC = 0.00001
change_min = 0.5
## trust level for exchanges (if an exception happens and level is 0.8 script
## will quit with a failure)
btc38_trust_level = 0.9
bter_trust_level = 0.5
poloniex_trust_level = 1.0
bittrex_trust_level = 0.5
yunbi_trust_level = 0.8
-
There is another error on 'config.minValidAssetPrice'. It should not be because this variable should be in config.py. There may be a syntax error in your config.py Have you checked it? Can you post it here?
I renamed that variable to make clear its in BTC .. please update your config file
thank you both. this is my config.py
################################################################################
## RPC-client connection information (required)
################################################################################
host = "localhost"
port = 8092
user = ""
passwd = ""
unlock = ""
################################################################################
## Delegate Feed Publish Parameters
################################################################################
delegate_list = ["bitshares-argentina"]
maxAgeFeedInSeconds = 60*60 # 1hour
################################################################################
## Fine tuning
################################################################################
discount = 0.995
core_exchange_factor = 1.05 # 5% surplus if paying fees in bitassets
minValidAssetPriceInBTC = 0.00001
change_min = 0.5
## trust level for exchanges (if an exception happens and level is 0.8 script
## will quit with a failure)
btc38_trust_level = 0.9
bter_trust_level = 0.5
poloniex_trust_level = 1.0
bittrex_trust_level = 0.5
yunbi_trust_level = 0.8
just removed InBTC and works great : )
-
There is another error on 'config.minValidAssetPrice'. It should not be because this variable should be in config.py. There may be a syntax error in your config.py Have you checked it? Can you post it here?
I renamed that variable to make clear its in BTC .. please update your config file
I see where is the confusion now. I made the workaround changes to an older script which is based on this commit 'https://github.com/xeroc/python-graphenelib/commit/11a69e983cdeac16335faba69b4e4251da1be079'.
There are newer codes in your script and this means those witnesses using the latest script would have problem with my modified python script. I am downloading your latest script and see if I can work something out.
Edit: The latest script is cool! It has a page of nice stats. Great work, xeroc! :)
I apply the same workaround changes to the script and here it is:
http://pastebin.com/vhhXYqjJ
The modified script has the prompt removed. I need to run it 'automated'. :P
-
Went in a fork
2692190ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0001f3c7fb5083376d42f2dcb6a073f33601eab2, 127943
2692190ms th_a fork_database.cpp:58 push_block ] Head: 127878, 0001f3860c23981bb2f70d2dec46b6d900626c38
2692191ms th_a application.cpp:430 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0001f3c6779d5dae33e64c0d1a625c957d72c53b","timestamp":"2015-10-10T10:43:51","witness":"1.6.17","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"204bce3ab7b13ba06f1abb0b24fdfd61b0ea542b3c7cbafeab68e0123979225aff3006c975c3523de16a0767123e4b53e47cedcc270269d9280712f10ac7a3c677","transactions":[]}}
th_a db_block.cpp:197 _push_block
2692191ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0001f3c8f86ff14e9935f81721b80339e80e4529, 127944
2692191ms th_a fork_database.cpp:58 push_block ] Head: 127878, 0001f3860c23981bb2f70d2dec46b6d900626c38
2692192ms th_a application.cpp:430 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0001f3c7fb5083376d42f2dcb6a073f33601eab2","timestamp":"2015-10-10T10:43:54","witness":"1.6.41","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f09332976528689bef3d0b1b76fc5edb5b9d0c308ecaea0e2ec96358cf129b83f05cd32ce0d15ef6ca41de0c4e310ba30452c80d4c28e3759e312aea1ed9600a2","transactions":[]}}
th_a db_block.cpp:197 _push_block
Now I am back on the main chain, after restarting the witness with --replay-blockchain
-
just removed InBTC and works great : )
Wonderful!
Regarding the yunbi error, have you tried contacting them to request for an unban of your ip? Their contact - https://yunbi.com/documents/contact
-
There is another error on 'config.minValidAssetPrice'. It should not be because this variable should be in config.py. There may be a syntax error in your config.py Have you checked it? Can you post it here?
I renamed that variable to make clear its in BTC .. please update your config file
I see where is the confusion now. I made the workaround changes to an older script which is based on this commit 'https://github.com/xeroc/python-graphenelib/commit/11a69e983cdeac16335faba69b4e4251da1be079'.
There are newer codes in your script and this means those witnesses using the latest script would have problem with my modified python script. I am downloading your latest script and see if I can work something out.
Edit: The latest script is cool! It has a page of nice stats. Great work, xeroc! :)
I apply the same workaround changes to the script and here it is:
http://pastebin.com/vhhXYqjJ
The modified script has the prompt removed. I need to run it 'automated'. :P
Love it! You guys are great
.
+--------+-----------------+-----------------+------------------+-------------------+---------------+-----------------------+---------------------------------+
| asset | BTS/base | my mean | median exchanges | blockchain median | % change (my) | % change (blockchain) | last update |
+--------+-----------------+-----------------+------------------+-------------------+---------------+-----------------------+---------------------------------+
| BTC | 42589.10921864 | 42360.54428105 | 42376.16367255 | 42948.10202889 | 0.62553 | 0.84292 | 0:42:47.235001 ago |
| SILVER | 2737.45746835 | 2723.13484479 | 2723.77018101 | 2750.70000000 | -100.03653 | 0.48375 | 16718 days, 16:09:17.235794 ago |
| GOLD | 200435.96318184 | 199387.12877564 | 199433.78336593 | 201405.00000000 | -100.00050 | 0.48346 | 16718 days, 16:09:17.236788 ago |
| TRY | 59.45636514 | 59.14678788 | 59.15908331 | 59.75000000 | -101.68191 | 0.49387 | 16718 days, 16:09:17.237815 ago |
| SGD | 124.13697894 | 123.48921899 | 123.51629405 | 124.73731343 | -100.80556 | 0.48361 | 16718 days, 16:09:17.238832 ago |
| HKD | 22.34259461 | 22.22644861 | 22.23088163 | 22.45135802 | -104.47576 | 0.48680 | 16718 days, 16:09:17.239849 ago |
| RUB | 2.80400818 | 2.79099955 | 2.78998814 | 2.82104516 | -135.66323 | 0.60759 | 16718 days, 16:09:17.241723 ago |
| SEK | 21.10440258 | 20.99916266 | 20.99888056 | 21.21022727 | -104.73835 | 0.50143 | 16718 days, 16:09:17.242603 ago |
| NZD | 115.79657411 | 115.19304310 | 115.21759124 | 116.35312500 | -100.86358 | 0.48063 | 16718 days, 16:09:17.243549 ago |
| CNY | 27.28315335 | 27.14237861 | 27.14673758 | 27.94131054 | 0.56690 | 2.41232 | 0:42:47.244503 ago |
| MXN | 10.53816929 | 10.48552510 | 10.48547844 | 10.59433249 | -109.48931 | 0.53295 | 16718 days, 16:09:17.245995 ago |
| CAD | 133.73664451 | 133.03782546 | 133.06796129 | 134.37666667 | -100.74774 | 0.47857 | 16718 days, 16:09:17.246878 ago |
| CHF | 179.98646550 | 179.04983277 | 179.08653318 | 180.86818182 | -100.55560 | 0.48988 | 16718 days, 16:09:17.247826 ago |
| AUD | 126.97837755 | 126.31701855 | 126.34348567 | 127.59078947 | -100.78754 | 0.48230 | 16718 days, 16:09:17.248825 ago |
| GBP | 265.38402236 | 263.99847247 | 264.05710225 | 266.66538462 | -100.37681 | 0.48283 | 16718 days, 16:09:17.249853 ago |
| JPY | 1.43889946 | 1.43123981 | 1.43170497 | 1.44557692 | -169.49756 | 0.46407 | 16718 days, 16:09:17.250834 ago |
| EUR | 196.67865003 | 195.65458606 | 195.69525678 | 201.85945946 | 0.56754 | 2.63415 | 0:42:47.252809 ago |
| USD | 173.15588349 | 172.24631374 | 172.29010407 | 177.46909091 | 0.55467 | 2.49094 | 0:42:47.254692 ago |
| KRW | 0.15203558 | 0.15273384 | 0.15127540 | 0.15306607 | -757.74077 | 0.67780 | 16718 days, 16:09:17.256245 ago |
+--------+-----------------+-----------------+------------------+-------------------+---------------+-----------------------+---------------------------------+
Feeds for SILVER too old! Force updating!
Update required! Forcing now!
publishing feeds for delegate: bitshares-argentina
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.218', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 8603}, 'base': {'asset_id': '1.3.218', 'amount': 202}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 9033}, 'base': {'asset_id': '1.3.218', 'amount': 202}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['1f2d8b39ba7f6ec733800ba67a22e0c9876641b6b8cb28eb999eccf05c63559d915c5d7e1567fd40ca59aadac65bcb7fcd1986f32384768afcdb154545f5ee0e17'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.481', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 54749}, 'base': {'asset_id': '1.3.481', 'amount': 2}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 57486}, 'base': {'asset_id': '1.3.481', 'amount': 2}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['1f3a31b255ea26201fc6a7fb50521f5c66bed7c0fdb68e64cc670c972e953451a80e4fc1410e922fa3fb4aed1c9214b483f460a6f1701da69b3ad1418ae44ff420'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.366', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 60131}, 'base': {'asset_id': '1.3.366', 'amount': 3}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 63137}, 'base': {'asset_id': '1.3.366', 'amount': 3}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['1f29d9416b8613314cb924d8b11524b7083540e9bf534bb23c6eff3bd1c6a015e928ec09a108f7cfca107bb47df3c762082fac07eac7059311e97df67deeffb024'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.529', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 32701}, 'base': {'asset_id': '1.3.529', 'amount': 55}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 34336}, 'base': {'asset_id': '1.3.529', 'amount': 55}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['1f40ff4b4d391d7f08ae66f31dd9a552c4905bcac33aeb2920e008eae7181d72a94552c7e3215e5ade062df92ba7a73f041b923fa1f96cb38bbf9454250cf8252c'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.473', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 90620}, 'base': {'asset_id': '1.3.473', 'amount': 73}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 95151}, 'base': {'asset_id': '1.3.473', 'amount': 73}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['1f04ccc572cfea4d26b7f8af8892340a87f981fc01a1b2d040669045b8a20958cb00818be6a0115a7184d109e457eb59dde38319c6d12ae2f5a5c36d83f92f9da0'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.375', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 12065}, 'base': {'asset_id': '1.3.375', 'amount': 54}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 12668}, 'base': {'asset_id': '1.3.375', 'amount': 54}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['203851c2821e19d75a284b277030778f5f60a6c1fbedff13d2afdc5dacd6e852b6485c1f1319e97b5a880f9df39b61cb46de8a4458391c87c637fa272b52cf5c90'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.468', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 68558}, 'base': {'asset_id': '1.3.468', 'amount': 2445}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 71985}, 'base': {'asset_id': '1.3.468', 'amount': 2445}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['2050ab528c8d465b679c2e268b4ac54e7922649572520d7eef7e293a03abc5944e22a8d6a7b19404aba76fa0d1a57da889f5d00c848d4d0e8f410104ccd013f6d9'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.471', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 33556}, 'base': {'asset_id': '1.3.471', 'amount': 159}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 35233}, 'base': {'asset_id': '1.3.471', 'amount': 159}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['1f59aaafb37fe11edf75d72652f99274b419ba3f6427bad23d42c97b273bf8a90c72884b5d0dae321bd6c4480c533d5309e9cc52f87503bc9a6a49a3e1046b8e00'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.428', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 33581}, 'base': {'asset_id': '1.3.428', 'amount': 29}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 35260}, 'base': {'asset_id': '1.3.428', 'amount': 29}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['2032d02d8a4dec9ad1b2671af3aa67a9fa9d80d57516481ade99885dc3d4e2dc3e05a63ca6122cebc05a61469bf3df8366fd199b03b7f7258e6dfa957be94f8125'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.285', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 76120}, 'base': {'asset_id': '1.3.285', 'amount': 279}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 79926}, 'base': {'asset_id': '1.3.285', 'amount': 279}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['1f483c978185f14da3c93322f7e527044aa1684969cd140854383bd028c5475f7f3168d066f78ea7ebb7c080748f7d3a771335c79d1116f5bf792a6eeb9710b164'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.415', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 61016}, 'base': {'asset_id': '1.3.415', 'amount': 579}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 64066}, 'base': {'asset_id': '1.3.415', 'amount': 579}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['1f608f78785dffd5afb5e0b39d8f921a15ae0e21d0e4854a020a7e6d4945999a53331d28ce49ba4bd1882bbcafab31ee53ebf3809e09b4fb5382f79298b9f605bc'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.261', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 40121}, 'base': {'asset_id': '1.3.261', 'amount': 30}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 42127}, 'base': {'asset_id': '1.3.261', 'amount': 30}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['1f0934e7574f9f4b77b7b4bbc342bdcc6ba2a77108f61b908892090465efd0f56a14a8380029e7892d75f1ef8b91540d7bd8832a42f9ef932f91f28c5d9fbcf6a7'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.279', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 66595}, 'base': {'asset_id': '1.3.279', 'amount': 37}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 69924}, 'base': {'asset_id': '1.3.279', 'amount': 37}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['1f503222b179005644d46a860995e6572523d1473d90292036d1962cdf8488db9e3a0579cf1d3e841aa06434456fc8cda38a48e34cd58ef03329546c6aa6012f1f'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.27', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 46982}, 'base': {'asset_id': '1.3.27', 'amount': 37}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 49331}, 'base': {'asset_id': '1.3.27', 'amount': 37}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['202a674bbf7355a9a2fb9928f1f669d92af0a403ad23c9e3ec4456a2b04b3f61ff66a01d96b45eac12e7b98664f51f5c7df8a4763ec5fda72f2f8e4f8e9973a2a3'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.359', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 66346}, 'base': {'asset_id': '1.3.359', 'amount': 25}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 69663}, 'base': {'asset_id': '1.3.359', 'amount': 25}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['1f1b3fe14cc628c67bf8a3f2af56c965a75b3f478626793e05380760b69c2dfc4e335202e746a73388c45e672b7be3378d9794832dcd935975f737a356d8d3c0bf'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.386', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 14389}, 'base': {'asset_id': '1.3.386', 'amount': 10}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 15108}, 'base': {'asset_id': '1.3.386', 'amount': 10}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['2063f692491a59262fb83d74918ae2d93db87ae99b4002c72f61d6c45c891a7014350d5daad2c71797f215a76318e808b068cb3ec18bcfa1cd50c07d5bcf308bb8'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.330', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 92439}, 'base': {'asset_id': '1.3.330', 'amount': 47}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 97060}, 'base': {'asset_id': '1.3.330', 'amount': 47}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['1f5bcf9a7e41081ff0fc206205f56047f0fe6bbd906f0ceaecc0f791a4a5ba5fa91d84f705bfe9121a6cea5bc92ee69a03d25eda016a2c20c25fe07a54b2dd1871'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.536', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 58873}, 'base': {'asset_id': '1.3.536', 'amount': 34}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 61816}, 'base': {'asset_id': '1.3.536', 'amount': 34}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['1f30c4f927ff6d6d743f59e467a714c5134f6d90ae42909023bc69af03b314e1ac669ca74f48132b951964989075ecb41c09e0a0082f53c6fb330c8c7fb31c810a'], 'ref_block_prefix': 3011637927}
Update result: {'ref_block_num': 62884, 'expiration': '2015-10-10T11:09:45', 'operations': [[19, {'fee': {'asset_id': '1.3.0', 'amount': 100000}, 'asset_id': '1.3.390', 'publisher': '1.2.8517', 'feed': {'settlement_price': {'quote': {'asset_id': '1.3.0', 'amount': 54523}, 'base': {'asset_id': '1.3.390', 'amount': 35862}}, 'maximum_short_squeeze_ratio': 1500, 'core_exchange_rate': {'quote': {'asset_id': '1.3.0', 'amount': 57249}, 'base': {'asset_id': '1.3.390', 'amount': 35862}}, 'maintenance_collateral_ratio': 1750}, 'extensions': []}]], 'extensions': [], 'signatures': ['1f56be773befe02fbf2ff807bfa5d207a70affd7ba01d372e4f3fda9f77dc57fc51c12cbd76d6a257847da431bfddb138e76504f28a15e16c784476168ed5dcc93'], 'ref_block_prefix': 3011637927}
-
rm -Rf witness_node_data_dir/blockchain # this is what resync does
that means when we do :
--resync-blockchain
we loose also our initial config.ini file with our custom settings and it's replaced with the default config.ini ???
-
just removed InBTC and works great : )
Wonderful!
Regarding the yunbi error, have you tried contacting them to request for an unban of your ip? Their contact - https://yunbi.com/documents/contact
I will do that, and also ask for their api call limits so we are all aware. Thank you for the advise.
-
rm -Rf witness_node_data_dir/blockchain # this is what resync does
that means when we do :
--resync-blockchain
we loose also our initial config.ini file with our custom settings and it's replaced with the default config.ini ???
No. --resync-blockchain does not remove your config.ini
-
running some tests of the failover script. sorry about the missed blocks
-
Edit: The latest script is cool! It has a page of nice stats. Great work, xeroc! :)
I apply the same workaround changes to the script and here it is:
http://pastebin.com/vhhXYqjJ
The modified script has the prompt removed. I need to run it 'automated'. :P
That did the trick, the feed published now. Thank you!
And also +5% to xeroc!
-
So. Am I the only one that gets a left margin when I copy from pastebin? It messes up the python whitespace. Is there a way to copy without it?
Also I will be missing blocks as I will be testing an updated failover script.
-
I update my observer node to the latest master I was not able to publish the feed for SILVER.
I got a strange error that you can find here:
https://github.com/cryptonomex/graphene/issues/371
Thanks to bitcube that helped me on telegram (thanks a lot!!!) I switched to a previous commit e68e99ed3ae11ddac607e983e7549e8278fdecc4 and I was able to broadcast the tx but my witness producer started to missing blocks.
So I suspect that if some witness producer update to latest master risk going into a fork.
-
So. Am I the only one that gets a left margin when I copy from pastebin? It messes up the python whitespace. Is there a way to copy without it?
Did you try downloading the raw file?
-
So. Am I the only one that gets a left margin when I copy from pastebin? It messes up the python whitespace. Is there a way to copy without it?
Did you try downloading the raw file?
Nope. That worked. Thanks. I'm very new to pastebin.
-
I swapped the base/quote as in the patch in the last commit .. would someone tell me if that is all you need for now?
-
I swapped the base/quote as in the patch in the last commit .. would someone tell me if that is all you need for now?
That's all :)
-
Having trouble getting feeds going. Using https://python-graphenelib.readthedocs.org/en/latest/pricefeed.html
In launching the wallet I get the following error:
:~/graphene/programs/cli_wallet# ./cli_wallet -w test_wallet --chain-id 60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83 -H 127.0.0.1:8092 -s "127.0.0.1:8090"
Logging RPC to file: logs/rpc/rpc.log
638120ms th_a main.cpp:114 main ] key_to_wif( committee_private_key ): 5...W
638121ms th_a main.cpp:118 main ] nathan_pub_key: GPH...V
638121ms th_a main.cpp:119 main ] key_to_wif( nathan_private_key ): 5...3
638122ms th_a main.cpp:166 main ] wdata.ws_server: 127.0.0.1:8090
10 assert_exception: Assert Exception
uri.substr(0,3) == "ws:":
{}
th_a websocket.cpp:600 connect
{"uri":"127.0.0.1:8090"}
th_a websocket.cpp:621 connect
I have witness running with this command:
./witness_node --rpc-endpoint "127.0.0.1:8090" --genesis-json oct5-genesis.json -d oct5 -s "104.236.51.238:2005" -s "104.236.144.84:1776" --witness-id '"1.6.24"' --private-key '["GPH...t","5...5"]'
I assume the issue is where I define -s "<ip-of-full/witness-node:port>" from the directions:
programs/cli_wallet/cli_wallet --rpc-http-endpoint="127.0.0.1:8092" -s "<ip-of-full/witness-node:port>"
but I can't find anything that makes it happy here.
-
I updated my failover script. It is posted here https://bitsharestalk.org/index.php/topic,18875.new.html#new (https://bitsharestalk.org/index.php/topic,18875.new.html#new) to keep this thread less crowded.
-
I assume the issue is where I define -s "<ip-of-full/witness-node:port>" from the directions:
programs/cli_wallet/cli_wallet --rpc-http-endpoint="127.0.0.1:8092" -s "<ip-of-full/witness-node:port>"
but I can't find anything that makes it happy here.
I use this
./cli_wallet -w oct5_w0 --chain-id 60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83 -s ws://127.0.0.1:8090 -H 127.0.0.1:8092
-
I assume the issue is where I define -s "<ip-of-full/witness-node:port>" from the directions:
programs/cli_wallet/cli_wallet --rpc-http-endpoint="127.0.0.1:8092" -s "<ip-of-full/witness-node:port>"
but I can't find anything that makes it happy here.
I use this
./cli_wallet -w oct5_w0 --chain-id 60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83 -s ws://127.0.0.1:8090 -H 127.0.0.1:8092
That did it. Thank you Spectral.
-
I assume the issue is where I define -s "<ip-of-full/witness-node:port>" from the directions:
programs/cli_wallet/cli_wallet --rpc-http-endpoint="127.0.0.1:8092" -s "<ip-of-full/witness-node:port>"
but I can't find anything that makes it happy here.
I use this
./cli_wallet -w oct5_w0 --chain-id 60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83 -s ws://127.0.0.1:8090 -H 127.0.0.1:8092
That did it. Thank you Spectral.
Why are you guys launching cli_wallet with the -s flag? I just launch with ./cli_wallet --chain-id 60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83 -H 127.0.0.1:8092does the -s flag give you access to the other apis?
-
With -s you can specify another witness to connect to .. is has to be prepended with ws:// or wss:// (need to fix the docs) .. if no -s is present then default is localhost:8090
-
With -s you can specify another witness to connect to .. is has to be prepended with ws:// or wss:// (need to fix the docs) .. if no -s is present then default is localhost:8090
Gotcha, thanks.
-
Can somebody running the real thing check the transaction history for core/USD. From the light wallet GUI it seems the transactions are matched but the 'sell Core' order remains on the order book.
Thanks
-
Did anything change again with the witness command line arguments, like the location of the genesis json file?
The md5 of the json file matches my active witness so I know that's OK. Permissions are fine too.
/home/admin/BitShares2_bin/witness_node --data-dir /home/admin/BitShares2 --genesis-json /home/admin/oct5-genesis.json
That cmd line produces this error, looks to me like it can't read the genesis.json file:
admin@seed06:~$ /home/admin/BitShares2_bin/witness_node --data-dir /home/admin/BitShares2 --genesis-json /home/admin/oct5-genesis.json
3157079ms th_a witness.cpp:83 plugin_initialize ] witness plugin: plugin_initialize() begin
3157093ms th_a witness.cpp:112 plugin_initialize ] 11 eof_exception: End Of File
stringstream
{}
th_a sstream.cpp:109 peek
{"str":""}
th_a json.cpp:478 from_string
3157093ms th_a main.cpp:183 main ] Exiting with error:
11 eof_exception: End Of File
stringstream
{}
th_a sstream.cpp:109 peek
{"str":""}
th_a json.cpp:478 from_string
rethrow
{}
th_a witness.cpp:112 plugin_initialize
Edit: grabbed the wrong cmd history
-
Crashed again with error: Assertion `_closing_connections.find(peer_to_delete) == _closing_connections.end()' failed..
Commit e68e99ed3ae11ddac607e983e7549e8278fdecc4. Any changes after that?
I've encountered same error several times already. Due to my high latency?
2530767ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 00018ad9d0532f33aca1e0d35e97e2d8c7503630, 101081
2530767ms th_a fork_database.cpp:58 push_block ] Head: 102059, 00018eab29598c6da18be3a60c9ee321861f180c
2530862ms th_a application.cpp:429 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"00018ad8150b29e0a9278acb90fe7c592f4ec15c","timestamp":"2015-10-09T10:09:15","witness":"1.6.35","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"202d638e8938d8fde6e107105b4e95edc26068af86d68894199480ae6dbb7d16052e8ec457759e5b70f3866bfd6afcb1d8f2e5526bb17af292fbb56d1542058ce8","transactions":[]}}
th_a db_block.cpp:197 _push_block
witness_node: /app/bts/graphene-test6.2/libraries/net/node.cpp:1611: void graphene::net::detail::node_impl::schedule_peer_for_deletion(const peer_connection_ptr&): Assertion `_closing_connections.find(peer_to_delete) == _closing_connections.end()' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff3532700 (LWP 14836)]
0x00007ffff6c01cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
-
Every day so many witnesses are not online, what is the reason?
We've identified an issue where the assignment of new object ID's is inconsistent (we use a hashed index with an undefined iteration order). Fortunately the testnet's main fork has them in increasing order (I suspect it has to do with the memory allocator tending to put things allocated later at higher addresses), in the next hardfork this condition will be enforced (by replacing most of our hashed indexes with ordered indexes). We suspect some witnesses are getting their state wrong when they assign an ID differently from the main network, if someone publishes a transaction using that ID then the wrong state turns into a desync (they'll no longer sign or pay attention to blocks on the main fork because they think the main fork has an illegal transaction.)
If you get stuck and the first error message mentions a vesting balance object, this is almost certainly what's happening to you.
The next hardfork will fix this issue, and in addition, I'm working on a tool to help us find if there are any similar issues.
The transactions being executed by the community testers have been incredibly helpful to us.
@bytemaster @theoretical The 'vesting balance' issue happened again on my node. Is it normal? So, in order to prevent this from happening again, I have to manually replay before the hard fork? What block number is the hard fork?
2015-10-09T10:09:12 th_a:invoke handle_block handle_block ] Got block: #101080 time: 2015-10-09T10:09:12 latency: 299 ms from: jtm1 irreversible: 101055 (-25) application.cpp:401
2015-10-09T10:09:12 th_a:invoke handle_block _push_block ] Failed to push new block:
10 assert_exception: Assert Exception
vbo.is_withdraw_allowed( now, op.amount ):
{"now":"2015-10-09T10:09:09","op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":800000000,"asset_id":"1.3.0"}},"vbo":{"id":"1.13.60","owner":"1.2.8517","balance":{"amount":1128200000,"asset_id":"1.3.0"},"policy":[1,{"vesting_seconds":86400,"start_claim":"1970-01-01T00:00:00","coin_seconds_earned":"68174256300000","coin_seconds_earned_last_update":"2015-10-09T10:08:03"}]}}
th_a vesting_balance_evaluator.cpp:103 do_evaluate
{"op":{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":800000000,"asset_id":"1.3.0"}}}
th_a vesting_balance_evaluator.cpp:109 do_evaluate
{}
th_a evaluator.cpp:42 start_evaluate
{}
th_a db_block.cpp:628 apply_operation
{"trx":{"ref_block_num":35543,"ref_block_prefix":1295075313,"expiration":"2015-10-09T10:09:39","operations":[[33,{"fee":{"amount":100000,"asset_id":"1.3.0"},"vesting_balance":"1.13.60","owner":"1.2.8517","amount":{"amount":800000000,"asset_id":"1.3.0"}}]],"extensions":[],"signatures":["2010951608daae48abcc6a9c9c6c43fe449803bf4af875602c02556915d9c680e32d808c391b128858f7e9f72b6d0dfd54036abe2852eabba55f3d479ebd0ee25f"]}}
th_a db_block.cpp:611 _apply_transaction
{"next_block.block_num()":101080}
th_a db_block.cpp:514 _apply_block db_block.cpp:191
-
spartako_bot went in a minor fork and started to notify false alarm to witnesses (spartako witness producer was in the main fork and didn't missed any blocks), this is the error that I found:
2606729ms th_a fork_database.cpp:57 push_block ] Pushing block to fork database that failed to link: 0002315c15ad904d17192c8080121ba774c1a962, 143708
2606729ms th_a fork_database.cpp:58 push_block ] Head: 143799, 000231b77729fe84f473d51aabdbf31e530d1b82
2606730ms th_a application.cpp:429 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:78 _push_block
{"new_block":{"previous":"0002315b615b561c0ea5eab6aa74aee790f5de0c","timestamp":"2015-10-11T00:28:30","witness":"1.6.11","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f6551667be1ad32fe674e9f4df852f0afe69450ccb396036026e97f468de4af7d1d0613c69ef2d9d35125e7a2bd7098dbc2fa1d44dff9aaa20a6a2cfa04fa5d2f","transactions":[]}}
th_a db_block.cpp:197 _push_block
Tomorrow I will change the code of spartako_bot adding a backup nodes list for prevent this type of problems.
-
The witness that lost contact today is at the same time.I think it's not a question of the witness.
-
Witness spectral crashed (version test6-41-g837e4f2). Log:
https://drive.google.com/file/d/0BzEEZBS7b6xPRWhHeU9pZDROd0E/view?usp=sharing
And I can't seem to reconnect to the network (version test6-42-g9c650bd). Log:
https://drive.google.com/file/d/0BzEEZBS7b6xPb2pQZXNzaFktU1E/view?usp=sharing
-
Witness spectral crashed (version test6-41-g837e4f2). Log:
https://drive.google.com/file/d/0BzEEZBS7b6xPRWhHeU9pZDROd0E/view?usp=sharing
And I can't seem to reconnect to the network (version test6-42-g9c650bd). Log:
https://drive.google.com/file/d/0BzEEZBS7b6xPb2pQZXNzaFktU1E/view?usp=sharing
-s 188.165.233.53:1777
-
When you start the witness, what determines the chainID it runs on?
I don't see any specific cmd line options for a witness to act as a seed node, is that just a matter of not enabling block production and changing the --p2p-endpoint arg it will listen on?
When I do that it provides some (arbitrary, self-generated?) chainID, could each seed node theoretically represent it's own chain that other witness nodes could join to form their own P2P network?
I can easily see why the cli_wallet needs a chainID parameter, just not sure how it is determined for each witness.
Can anyone help clarify this?
-
-s 188.165.233.53:1777
Thanks. That worked.
Is the other seed node down? Is there a list of seed nodes somewhere? How could i have known about this if clayop didn't post it here?
-
When you start the witness, what determines the chainID it runs on?
I don't see any specific cmd line options for a witness to act as a seed node, is that just a matter of not enabling block production and changing the --p2p-endpoint arg it will listen on?
When I do that it provides some (arbitrary, self-generated?) chainID, could each seed node theoretically represent it's own chain that other witness nodes could join to form their own P2P network?
I can easily see why the cli_wallet needs a chainID parameter, just not sure how it is determined for each witness.
Can anyone help clarify this?
Isn't the chain ID deterministic based on the genesis state?
EDIT: Confirmed.
/**
* Get the chain_id corresponding to this genesis state.
*
* This is the SHA256 serialization of the genesis_state.
*/
chain_id_type compute_chain_id() const;
chain_id_type genesis_state_type::compute_chain_id() const
{
return fc::sha256::hash( *this );
}
The chain ID is just the hash of the genesis state.
-
+5% Thanks Troglodactyl, greatly appreciated!
-
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 made the assumption that everything is relative to the --data-dir folder where the config.ini is found.
Now that you mention it, I noticed a config.ini in this directory:
/graphene/witness_node_data_dir
Is this a template that is used automatically when a new data directory is created? Can it be used to keep a default config.ini that will be copied at first startup?
-
I made the assumption that everything is relative to the --data-dir folder where the config.ini is found.
Now that you mention it, I noticed a config.ini in this directory:
/graphene/witness_node_data_dir
Is this a template that is used automatically when a new data directory is created? Can it be used to keep a default config.ini that will be copied at first startup?
witness_node_data_dir is created when you don't specify a --data-dir.. i.e., not a template, just a default data dir name
-
I made the assumption that everything is relative to the --data-dir folder where the config.ini is found.
Now that you mention it, I noticed a config.ini in this directory:
/graphene/witness_node_data_dir
Is this a template that is used automatically when a new data directory is created? Can it be used to keep a default config.ini that will be copied at first startup?
@spectral: As roadscape says, the witness_node_data_dir is the default folder if you don't specify one with -d or --data-dir on the command line. It will put an empty (more or less, it could be considered a template I guess) config.ini in that folder. I don't know about most of the witnesses here, but since I'm not building the code on the VPS that runs it I only move the executable binaries to the VPS; I do not use the graphene/programs/witness_node folder structure, which is probably why I am having so many difficulties, tho that shouldn't matter.
However I have discovered things still are changing related to the basic command line / config file processing that require I verify many things to be certain I haven't made a silly mistake. I am constantly going back and forth between using automation scripts to launch and launching directly on the command line to investigate the behavior I see. Like this for example:
- witness_node and cli_wallet binaries are in the path (only 1 version in path).
- all files confirmed the same as working witness node with md5sum.
- known good config.ini and oct5-genesis.json in ~BitShares2 folder.
- cd BitShares2 and run the following:
- witness_node --data-dir /home/admin/BitShares2 --genesis-json /home/admin/BitShares2/oct5-genesis.json
Produces this output:
admin@seed08:~/BitShares2$ witness_node --data-dir /home/admin/BitShares2 --genesis-json /home/admin/BitShares2
2374823ms th_a main.cpp:115 main ] Error parsing logging config from config file /home/admin/BitShares2/config.ini, using default config
2374823ms th_a witness.cpp:83 plugin_initialize ] witness plugin: plugin_initialize() begin
2374824ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH1...","5K..."]
2374824ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH2...","5K..."]
2374824ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH3...","5K..."]
2374824ms th_a witness.cpp:111 plugin_initialize ] witness plugin: plugin_initialize() end
2385370ms th_a thread.cpp:95 thread ] name:ntp tid:139919911945984
2385372ms th_a thread.cpp:95 thread ] name:p2p tid:139919825561344
2385400ms th_a application.cpp:123 reset_p2p_node ] Adding seed node 104.236.51.238:2005
2385402ms th_a application.cpp:135 reset_p2p_node ] Configured p2p node to listen on 0.0.0.0:1776
2385403ms th_a application.cpp:185 reset_websocket_serv ] Configured websocket rpc to listen on 127.0.0.1:8090
2385404ms th_a witness.cpp:116 plugin_startup ] witness plugin: plugin_startup() begin
2385404ms th_a witness.cpp:123 plugin_startup ] Launching block production for 1 witnesses.
********************************
* *
* --------- NEW CHAIN -------- *
* - Welcome to Graphene! - *
* ------------------------------------ *
* *
********************************
Your genesis seems to have an old timestamp
Please consider using the --genesis-timestamp option to give your genesis a recent timestamp
2385406ms th_a witness.cpp:134 plugin_startup ] witness plugin: plugin_startup() end
2385407ms th_a main.cpp:167 main ] Started witness node on a chain with 0 blocks.
2385408ms th_a main.cpp:168 main ] Chain ID is 9f8faf7d8e4919364d1a14169bb1ac4c0ec8001929f8dbee1026d3a54b298b81
2385507ms ntp ntp.cpp:177 read_loop ] ntp_delta_time updated to 5344 us
2623923ms asio main.cpp:163 operator() ] Caught ^C attempting to exit cleanly
I can't explain it. The following questions come to mind:
- Why does it report "Error parsing logging config from config file" with a verified copy of a known good config.ini in use on another VPS?
- If it is using a default config as it says, where is it coming up with the seed, the 3 private-key pairs, witness-id and other values?
- If it can read the genesis.json file to determine the timestamp is old, why does it have the wrong chainID?
I am trying to get a reproducible installation script to establish the VPS platform to run graphene, but it is proving to be quite time consuming and rather difficult. I know there may be some variations in the OS image for "Ubuntu 14.04" each VPS company provides, but I wouldn't think they would impact the run time operation of the code in the ways I observe. If the binaries don't run at all or produce immediate errors perhaps a package wasn't installed or is the wrong version, but I wouldn't attribute output like the above to missing dependencies or subtle OS differences.
At this stage of development I wouldn't expect to see this type of "anomolous" behavior. I don't know if others observe it too and just don't mention it here or they don't see these things because they continue to use the same exact environment everytime. I post these "reports" not only to find answers but also b/c that's what I thought this thread is all about. If I'm missing something right in front of my nose I hope somebody can point it our to me.
-
I made the assumption that everything is relative to the --data-dir folder where the config.ini is found.
Now that you mention it, I noticed a config.ini in this directory:
/graphene/witness_node_data_dir
Is this a template that is used automatically when a new data directory is created? Can it be used to keep a default config.ini that will be copied at first startup?
@spectral: As roadscape says, the witness_node_data_dir is the default folder if you don't specify one with -d or --data-dir on the command line. It will put an empty (more or less, it could be considered a template I guess) config.ini in that folder. I don't know about most of the witnesses here, but since I'm not building the code on the VPS that runs it I only move the executable binaries to the VPS; I do not use the graphene/programs/witness_node folder structure, which is probably why I am having so many difficulties, tho that shouldn't matter.
However I have discovered things still are changing related to the basic command line / config file processing that require I verify many things to be certain I haven't made a silly mistake. I am constantly going back and forth between using automation scripts to launch and launching directly on the command line to investigate the behavior I see. Like this for example:
- witness_node and cli_wallet binaries are in the path (only 1 version in path).
- all files confirmed the same as working witness node with md5sum.
- known good config.ini and oct5-genesis.json in ~BitShares2 folder.
- cd BitShares2 and run the following:
- witness_node --data-dir /home/admin/BitShares2 --genesis-json /home/admin/BitShares2/oct5-genesis.json
Produces this output:
admin@seed08:~/BitShares2$ witness_node --data-dir /home/admin/BitShares2 --genesis-json /home/admin/BitShares2
2374823ms th_a main.cpp:115 main ] Error parsing logging config from config file /home/admin/BitShares2/config.ini, using default config
2374823ms th_a witness.cpp:83 plugin_initialize ] witness plugin: plugin_initialize() begin
2374824ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH1...","5K..."]
2374824ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH2...","5K..."]
2374824ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH3...","5K..."]
2374824ms th_a witness.cpp:111 plugin_initialize ] witness plugin: plugin_initialize() end
2385370ms th_a thread.cpp:95 thread ] name:ntp tid:139919911945984
2385372ms th_a thread.cpp:95 thread ] name[emoji14]2p tid:139919825561344
2385400ms th_a application.cpp:123 reset_p2p_node ] Adding seed node 104.236.51.238:2005
2385402ms th_a application.cpp:135 reset_p2p_node ] Configured p2p node to listen on 0.0.0.0:1776
2385403ms th_a application.cpp:185 reset_websocket_serv ] Configured websocket rpc to listen on 127.0.0.1:8090
2385404ms th_a witness.cpp:116 plugin_startup ] witness plugin: plugin_startup() begin
2385404ms th_a witness.cpp:123 plugin_startup ] Launching block production for 1 witnesses.
********************************
* *
* --------- NEW CHAIN -------- *
* - Welcome to Graphene! - *
* ------------------------------------ *
* *
********************************
Your genesis seems to have an old timestamp
Please consider using the --genesis-timestamp option to give your genesis a recent timestamp
2385406ms th_a witness.cpp:134 plugin_startup ] witness plugin: plugin_startup() end
2385407ms th_a main.cpp:167 main ] Started witness node on a chain with 0 blocks.
2385408ms th_a main.cpp:168 main ] Chain ID is 9f8faf7d8e4919364d1a14169bb1ac4c0ec8001929f8dbee1026d3a54b298b81
2385507ms ntp ntp.cpp:177 read_loop ] ntp_delta_time updated to 5344 us
2623923ms asio main.cpp:163 operator() ] Caught ^C attempting to exit cleanly
I can't explain it. The following questions come to mind:
- Why does it report "Error parsing logging config from config file" with a verified copy of a known good config.ini in use on another VPS?
- If it is using a default config as it says, where is it coming up with the seed, the 3 private-key pairs, witness-id and other values?
- If it can read the genesis.json file to determine the timestamp is old, why does it have the wrong chainID?
I am trying to get a reproducible installation script to establish the VPS platform to run graphene, but it is proving to be quite time consuming and rather difficult. I know there may be some variations in the OS image for "Ubuntu 14.04" each VPS company provides, but I wouldn't think they would impact the run time operation of the code in the ways I observe. If the binaries don't run at all or produce immediate errors perhaps a package wasn't installed or is the wrong version, but I wouldn't attribute output like the above to missing dependencies or subtle OS differences.
At this stage of development I wouldn't expect to see this type of "anomolous" behavior. I don't know if others observe it too and just don't mention it here or they don't see these things because they continue to use the same exact environment everytime. I post these "reports" not only to find answers but also b/c that's what I thought this thread is all about. If I'm missing something right in front of my nose I hope somebody can point it our to me.
Hard to say without also seeing your config.json. Do you have a seed nodes specified in there? If not you need one..
I've been launching the witness_node the same way for several months and never ran into issues like you had, both building locally and copying to a VPS. One thing that did bug me a few times was an incorrect genesis path, that error message really is unclear...
-
I can't explain it.
There are probably others who can help you better than me... and I'm one of those who compile and run from source.
..but what comes to mind is that you said that the paths must be relative to the binary. Do you see the same problem if you place the genesis file together with the binary, and specify datadir as a simple directory name? Could there be a problem with OS permissions?
What happens if you don't specify the datadir at all?
-
@svk:
#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 = 104.236.51.238:2005
# Pairs of [BLOCK_NUM,BLOCK_ID] that should be enforced as checkpoints.
# checkpoint =
# ChainID
# 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
#genesis-json = oct-05-testnet-genesis.json
#genesis-json = oct-02-testnet-genesis.json
#genesis-json = aug-14-test-genesis.json
#genesis-json = aug-19-puppies-test-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 = [ "GPH1", "..." ]
private-key = [ "GPH2", "..." ]
private-key = [ "GPH", "..." ]
# 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
As I said, this was copied and verified from another VPS which is running just fine.
-
I've been launching the witness_node the same way for several months and never ran into issues like you had, both building locally and copying to a VPS. One thing that did bug me a few times was an incorrect genesis path, that error message really is unclear...
Yeah that one bit me in the ass so hard I still can't sit without pain :)
It was changed from a relative path that processed ~ for example to an absolute one.
-
I've been launching the witness_node the same way for several months and never ran into issues like you had, both building locally and copying to a VPS. One thing that did bug me a few times was an incorrect genesis path, that error message really is unclear...
Yeah that one bit me in the ass so hard I still can't sit without pain :)
It was changed from a relative path that processed ~ for example to an absolute one.
sometimes it is helpful to see what files are opened or atempted to open using strace
strace -f ./witness_node_startup_script 2>&1 | grep open
-
sometimes it is helpful to see what files are opened or atempted to open using strace
strace -f ./witness_node_startup_script 2>&1 | grep open
Thanks for that jtme. I haven't been real heavy into coding for years so I'm quite out of practice and my memory isn't what it used to be, so tips like this are greatly appreciated. I could compare the output if that on my troublesome VPS to one that works and see if the libs are the same for example. Here's what it produced up to the point of opening the blockchain:
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libreadline.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libncurses.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/x86_64-linux-gnu/libstdc++.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/ssl/openssl.cnf", O_RDONLY) = 3
open("/home/admin/BitShares2/config.ini", O_RDONLY) = 3
open("/home/admin/BitShares2/config.ini", O_RDONLY) = 3
openat(AT_FDCWD, "/home/admin/BitShares2/blockchain", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/home/admin/BitShares2/blockchain/db_version", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/2", O_RDONLY) = 3
I looked at the main.cpp of the code and noticed one boost method is used which is related to the config file logging error, so I reinstalled boost again but it didn't matter.
-
That invalid log in config error always happens btw, you can safely ignore it.
-
That invalid log in config error always happens btw, you can safely ignore it.
Good to know. I thought maybe it might indicate a deeper problem, so glad that isn't the case.
I'm not seeing the genesis file open in the strace output, but clearly it opened it if it determined the timestamp in it was wrong, and I've seen errors reported many times when the file can't be found.
Here's the complete output:
admin@seed08:~/BitShares2$ strace -f witness_node --data-dir /home/admin/BitShares2 --genesis-json /home/admin/BitShares2/oct5-genesis.[58/1850]
| grep open
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libreadline.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libncurses.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/x86_64-linux-gnu/libstdc++.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/ssl/openssl.cnf", O_RDONLY) = 3
open("/home/admin/BitShares2/config.ini", O_RDONLY) = 3
open("/home/admin/BitShares2/config.ini", O_RDONLY) = 3
openat(AT_FDCWD, "/home/admin/BitShares2/blockchain", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/home/admin/BitShares2/blockchain/db_version", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/2", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/3", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/4", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/5", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/6", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/7", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/8", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/10", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/11", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/12", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/13", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/14", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/1/15", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/0", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/1", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/3", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/4", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/5", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/6", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/7", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/8", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/9", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/10", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/11", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/12", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/2/13", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/object_database/5/1", O_RDONLY) = 3
open("/home/admin/BitShares2/blockchain/database/block_num_to_block/index", O_RDWR) = 3
open("/home/admin/BitShares2/blockchain/database/block_num_to_block/blocks", O_RDWR) = 4
[pid 2358] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
[pid 2358] open("/lib/x86_64-linux-gnu/tls/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/lib/x86_64-linux-gnu/tls/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/lib/x86_64-linux-gnu/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/lib/x86_64-linux-gnu/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/usr/lib/x86_64-linux-gnu/tls/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/usr/lib/x86_64-linux-gnu/tls/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/usr/lib/x86_64-linux-gnu/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/usr/lib/x86_64-linux-gnu/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/lib/tls/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/lib/tls/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/lib/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/lib/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/usr/lib/tls/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/usr/lib/tls/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/usr/lib/x86_64/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/usr/lib/libCSUNSAPI.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 2358] <... open resumed> ) = 10
[pid 2358] open("/lib/x86_64-linux-gnu/libswift.so", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 2358] <... open resumed> ) = -1 ENOENT (No such file or directory)
[pid 2362] open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 9
[pid 2362] open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 9
[pid 2362] open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 9
[pid 2358] open("/usr/lib/x86_64-linux-gnu/libswift.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/lib/libswift.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/usr/lib/libswift.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2362] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 2362] <... open resumed> ) = 9
[pid 2362] open("/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 9
[pid 2362] open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 9
[pid 2362] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
[pid 2362] open("/lib/x86_64-linux-gnu/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 9
[pid 2362] open("/lib/x86_64-linux-gnu/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 9
[pid 2358] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 2358] <... open resumed> ) = 9
[pid 2362] open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 2362] <... open resumed> ) = 10
[pid 2358] open("/lib/x86_64-linux-gnu/libnfhwcrhk.so", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 2358] <... open resumed> ) = -1 ENOENT (No such file or directory)
[pid 2358] open("/usr/lib/x86_64-linux-gnu/libnfhwcrhk.so", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 2358] <... open resumed> ) = -1 ENOENT (No such file or directory)
[pid 2358] open("/lib/libnfhwcrhk.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/usr/lib/libnfhwcrhk.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2358] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
[pid 2358] open("/lib/x86_64-linux-gnu/libSureWareHook.so", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 2358] <... open resumed> ) = -1 ENOENT (No such file or directory)
[pid 2358] open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 10
[pid 2361] open("/home/admin/BitShares2/p2p/node_config.json", O_RDONLY) = 10
[pid 2361] open("/home/admin/BitShares2/p2p/peers.json", O_RDONLY) = 10
[pid 2362] open("/etc/gai.conf", O_RDONLY|O_CLOEXEC) = 9
[pid 2361] open("/home/admin/BitShares2/p2p/node_config.json", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 10
-
Could be it's using the built in genesis which only has 10 or so accounts in it.
Did you triplecheck the genesis file is in the right location? ;) and are you using a seed node in config.ini?
-
I can't explain it.
There are probably others who can help you better than me... and I'm one of those who compile and run from source.
..but what comes to mind is that you said that the paths must be relative to the binary. Do you see the same problem if you place the genesis file together with the binary, and specify datadir as a simple directory name? Could there be a problem with OS permissions?
What happens if you don't specify the datadir at all?
First, I didn't say "the paths must be relative to the binary", I said they must be relative to where the binary is launched. The object_database marks the folder from which the binary is launched. My binaries reside in a totally different folder than where I launch them from.
If I don't specify a datadir at all it will create the witness_node_data_dir and place a config.ini "template" in it along with the blockchain, logs and p2p folders.
If I launch it from some other folder here's what happens:
admin@seed08:~/BitShares2$ mkdir ../test
admin@seed08:~/BitShares2$ cd ../test/
admin@seed08:~/test$ witness_node --genesis-json /home/admin/BitShares2/oct5-genesis.json
1877558ms th_a main.cpp:120 main ] Writing new config file at /home/admin/test/witness_node_data_dir/config.ini
1877560ms th_a witness.cpp:83 plugin_initialize ] witness plugin: plugin_initialize() begin
1877561ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3"]
1877561ms th_a witness.cpp:111 plugin_initialize ] witness plugin: plugin_initialize() end
1877561ms th_a db_management.cpp:131 open ] Old database version detected, reindex is required
1877561ms th_a db_management.cpp:98 wipe ] Wiping database
1877574ms th_a object_database.cpp:81 wipe ] Wiping object_database.
1877574ms th_a application.cpp:243 operator() ] Initializing database...
1914624ms th_a db_debug.cpp:79 debug_dump ] total_balances[asset_id_type()].value: 14239376866944 core_asset_data.current_supply.value: 271289987694689
1914624ms th_a db_debug.cpp:82 debug_dump ] core_in_orders: 14239376866944 reported_core_in_orders: 14239376866944
1914706ms th_a thread.cpp:95 thread ] name:ntp tid:140160123512576
1914721ms th_a thread.cpp:95 thread ] name:p2p tid:140160087664384
1914729ms th_a application.cpp:135 reset_p2p_node ] Configured p2p node to listen on 0.0.0.0:49818
1914732ms th_a witness.cpp:116 plugin_startup ] witness plugin: plugin_startup() begin
1914733ms th_a witness.cpp:133 plugin_startup ] No witnesses configured! Please add witness IDs and private keys to configuration.
1914733ms th_a witness.cpp:134 plugin_startup ] witness plugin: plugin_startup() end
1914734ms th_a main.cpp:167 main ] Started witness node on a chain with 0 blocks.
1914734ms th_a main.cpp:168 main ] Chain ID is 60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83
1915008ms ntp ntp.cpp:177 read_loop ] ntp_delta_time updated to -3504 us
Notice the chainID? It is correct now. Weird things going on related to that config file!
-
Could be it's using the built in genesis which only has 10 or so accounts in it.
Did you triplecheck the genesis file is in the right location? ;) and are you using a seed node in config.ini?
Yes on all counts. I posted the full config.ini below (above).
-
Could be it's using the built in genesis which only has 10 or so accounts in it.
Did you triplecheck the genesis file is in the right location? ;) and are you using a seed node in config.ini?
Yes on all counts. I posted the full config.ini below (above).
Sorry missed that post. Try commenting out the p2p-endpoint line, I remember that was preventing me from connecting to the testnet when we first launched it.
Tbh I used to run using config.ini but now I just set everything in the command line, much easier to reproduce...
I launch like this, with the genesis file in the same directory, works every time:
./witness_node --rpc-endpoint "127.0.0.1:8090" --genesis-json oct5-genesis.json -d oct-5 -s "104.236.51.238:2005"
-
First, I didn't say "the paths must be relative to the binary", I said they must be relative to where the binary is launched. The object_database marks the folder from which the binary is launched. My binaries reside in a totally different folder than where I launch them from.
I see, I didn't think of that possibility. If you launch from the same dir as the witness binary is located, does that make a difference?
-
Could be it's using the built in genesis which only has 10 or so accounts in it.
Did you triplecheck the genesis file is in the right location? ;) and are you using a seed node in config.ini?
Yes on all counts. I posted the full config.ini below (above).
my strace shows
open("genesis.json", O_RDONLY) = 3
if you do not have it in the output, it is not opened then.
-
Could be it's using the built in genesis which only has 10 or so accounts in it.
Did you triplecheck the genesis file is in the right location? ;) and are you using a seed node in config.ini?
Yes on all counts. I posted the full config.ini below (above).
Sorry missed that post. Try commenting out the p2p-endpoint line, I remember that was preventing me from connecting to the testnet when we first launched it.
Tbh I used to run using config.ini but now I just set everything in the command line, much easier to reproduce...
I launch like this, with the genesis file in the same directory, works every time:
./witness_node --rpc-endpoint "127.0.0.1:8090" --genesis-json oct5-genesis.json -d oct-5 -s "104.236.51.238:2005"
I just deleted the blockchain, logs, p2p folders from the test/witness_node_data_dir, and the object_database from the test folder.
I am using the exact same config.ini file I posted before, which I copied to the test/witness_node_data_dir. I am not using a -d or --data-dir option.
I then restarted using "admin@seed08:~/test$ witness_node --genesis-json /home/admin/BitShares2/oct5-genesis.json".
Here is the output so far:
admin@seed08:~/test$ witness_node --genesis-json /home/admin/BitShares2/oct5-genesis.json
3176759ms th_a main.cpp:115 main ] Error parsing logging config from config file /home/admin/test/witness_node_data_
dir/config.ini, using default config
3176759ms th_a witness.cpp:83 plugin_initialize ] witness plugin: plugin_initialize() begin
3176760ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH6oUevPDj52JK67E199jBAMBuh6CQBQGgkyLtoXKiAvTVCpvYU7","5KJ
QMshbWeKadB4uxpxtbH7qZL7nSgtLhsARUbciP13TLo4Enux"]
3176760ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH842NwZzwMQTKp2RwJbBT4wN8szPmXX5fHnrLLi741TrkT3dFFu","5KL
QSDsdFvWHZbPwh5cc8CyywFZpUfDwtcecBM3fEqeXdXCMvwd"]
3176760ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH7AoEUMSJUx1DzVqkVBbdeC88tpcQn8AQPdmNDVJJmH4dnXjrhZ","5JP
rHDRamk6V2KHtHMtg58XDMnFjQASdsyCPcniV6TKRuyoFPE2"]
3176761ms th_a witness.cpp:111 plugin_initialize ] witness plugin: plugin_initialize() end
3176761ms th_a db_management.cpp:131 open ] Old database version detected, reindex is required
3176761ms th_a db_management.cpp:98 wipe ] Wiping database
3176769ms th_a object_database.cpp:81 wipe ] Wiping object_database.
3176770ms th_a application.cpp:243 operator() ] Initializing database...
3212666ms th_a db_debug.cpp:79 debug_dump ] total_balances[asset_id_type()].value: 14239376866944 core_asset_data.current_sup
ply.value: 271289987694689
3212666ms th_a db_debug.cpp:82 debug_dump ] core_in_orders: 14239376866944 reported_core_in_orders: 14239376866944
3212766ms th_a thread.cpp:95 thread ] name:ntp tid:140683677284096
3212785ms th_a thread.cpp:95 thread ] name:p2p tid:140683641435904
3212821ms th_a application.cpp:123 reset_p2p_node ] Adding seed node 104.236.51.238:2005
3212822ms th_a application.cpp:135 reset_p2p_node ] Configured p2p node to listen on 0.0.0.0:1776
3212823ms th_a application.cpp:185 reset_websocket_serv ] Configured websocket rpc to listen on 127.0.0.1:8090
3212823ms th_a witness.cpp:116 plugin_startup ] witness plugin: plugin_startup() begin
3212823ms th_a witness.cpp:123 plugin_startup ] Launching block production for 1 witnesses.
********************************
* *
* ------- NEW CHAIN ------ *
* - Welcome to Graphene! - *
* ------------------------ *
* *
********************************
Your genesis seems to have an old timestamp
Please consider using the --genesis-timestamp option to give your genesis a recent timestamp
3212823ms th_a witness.cpp:134 plugin_startup ] witness plugin: plugin_startup() end
3212823ms th_a main.cpp:167 main ] Started witness node on a chain with 0 blocks.
3212824ms th_a main.cpp:168 main ] Chain ID is 60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83
3212920ms ntp ntp.cpp:177 read_loop ] ntp_delta_time updated to 1537 us
Everythink looks correct, but it seems to take longer than I recall from a clean (no databases) state. We'll see...
-
Could be it's using the built in genesis which only has 10 or so accounts in it.
Did you triplecheck the genesis file is in the right location? ;) and are you using a seed node in config.ini?
Yes on all counts. I posted the full config.ini below (above).
my strace shows
open("genesis.json", O_RDONLY) = 3
if you do not have it in the output, it is not opened then.
I don't disagree, but then how do you answer the questions I asked here: https://bitsharestalk.org/index.php/topic,18751.msg243253.html#msg243253 (https://bitsharestalk.org/index.php/topic,18751.msg243253.html#msg243253)
It clearly opens the config.ini file, reads a number of values from it, and a genesis file is one of those. The md5sum of that config.ini matches exactly with the one I copied from a working witness node on another VPS.
Weird bug?
-
Could be it's using the built in genesis which only has 10 or so accounts in it.
Did you triplecheck the genesis file is in the right location? ;) and are you using a seed node in config.ini?
Yes on all counts. I posted the full config.ini below (above).
Sorry missed that post. Try commenting out the p2p-endpoint line, I remember that was preventing me from connecting to the testnet when we first launched it.
Tbh I used to run using config.ini but now I just set everything in the command line, much easier to reproduce...
I launch like this, with the genesis file in the same directory, works every time:
./witness_node --rpc-endpoint "127.0.0.1:8090" --genesis-json oct5-genesis.json -d oct-5 -s "104.236.51.238:2005"
I just deleted the blockchain, logs, p2p folders from the test/witness_node_data_dir, and the object_database from the test folder.
I am using the exact same config.ini file I posted before, which I copied to the test/witness_node_data_dir. I am not using a -d or --data-dir option.
I then restarted using "admin@seed08:~/test$ witness_node --genesis-json /home/admin/BitShares2/oct5-genesis.json".
Here is the output so far:
admin@seed08:~/test$ witness_node --genesis-json /home/admin/BitShares2/oct5-genesis.json
3176759ms th_a main.cpp:115 main ] Error parsing logging config from config file /home/admin/test/witness_node_data_
dir/config.ini, using default config
3176759ms th_a witness.cpp:83 plugin_initialize ] witness plugin: plugin_initialize() begin
3176760ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH6oUevPDj52JK67E199jBAMBuh6CQBQGgkyLtoXKiAvTVCpvYU7","5KJ
QMshbWeKadB4uxpxtbH7qZL7nSgtLhsARUbciP13TLo4Enux"]
3176760ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH842NwZzwMQTKp2RwJbBT4wN8szPmXX5fHnrLLi741TrkT3dFFu","5KL
QSDsdFvWHZbPwh5cc8CyywFZpUfDwtcecBM3fEqeXdXCMvwd"]
3176760ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH7AoEUMSJUx1DzVqkVBbdeC88tpcQn8AQPdmNDVJJmH4dnXjrhZ","5JP
rHDRamk6V2KHtHMtg58XDMnFjQASdsyCPcniV6TKRuyoFPE2"]
3176761ms th_a witness.cpp:111 plugin_initialize ] witness plugin: plugin_initialize() end
3176761ms th_a db_management.cpp:131 open ] Old database version detected, reindex is required
3176761ms th_a db_management.cpp:98 wipe ] Wiping database
3176769ms th_a object_database.cpp:81 wipe ] Wiping object_database.
3176770ms th_a application.cpp:243 operator() ] Initializing database...
3212666ms th_a db_debug.cpp:79 debug_dump ] total_balances[asset_id_type()].value: 14239376866944 core_asset_data.current_sup
ply.value: 271289987694689
3212666ms th_a db_debug.cpp:82 debug_dump ] core_in_orders: 14239376866944 reported_core_in_orders: 14239376866944
3212766ms th_a thread.cpp:95 thread ] name:ntp tid:140683677284096
3212785ms th_a thread.cpp:95 thread ] name:p2p tid:140683641435904
3212821ms th_a application.cpp:123 reset_p2p_node ] Adding seed node 104.236.51.238:2005
3212822ms th_a application.cpp:135 reset_p2p_node ] Configured p2p node to listen on 0.0.0.0:1776
3212823ms th_a application.cpp:185 reset_websocket_serv ] Configured websocket rpc to listen on 127.0.0.1:8090
3212823ms th_a witness.cpp:116 plugin_startup ] witness plugin: plugin_startup() begin
3212823ms th_a witness.cpp:123 plugin_startup ] Launching block production for 1 witnesses.
********************************
* *
* ------- NEW CHAIN ------ *
* - Welcome to Graphene! - *
* ------------------------ *
* *
********************************
Your genesis seems to have an old timestamp
Please consider using the --genesis-timestamp option to give your genesis a recent timestamp
3212823ms th_a witness.cpp:134 plugin_startup ] witness plugin: plugin_startup() end
3212823ms th_a main.cpp:167 main ] Started witness node on a chain with 0 blocks.
3212824ms th_a main.cpp:168 main ] Chain ID is 60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83
3212920ms ntp ntp.cpp:177 read_loop ] ntp_delta_time updated to 1537 us
Everythink looks correct, but it seems to take longer than I recall from a clean (no databases) state. We'll see...
No that does not look correct, the big NEW CHAIN welcome is suspicious, you're trying to start a new chain there...
Try this:
witness_node --genesis-json /home/admin/BitShares2/oct5-genesis.json -d test-folder -s "104.236.51.238:2005"
BTW. Did you try removing the p2p-endpoint like I said?
-
When you start the witness, what determines the chainID it runs on?
I don't see any specific cmd line options for a witness to act as a seed node, is that just a matter of not enabling block production and changing the --p2p-endpoint arg it will listen on?
When I do that it provides some (arbitrary, self-generated?) chainID, could each seed node theoretically represent it's own chain that other witness nodes could join to form their own P2P network?
I can easily see why the cli_wallet needs a chainID parameter, just not sure how it is determined for each witness.
Can anyone help clarify this?
Chain ID is just the hash of the Genesis file.
Sent from my iPhone using Tapatalk
-
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
-
-s 188.165.233.53:1777
Thanks. That worked.
Is the other seed node down? Is there a list of seed nodes somewhere? How could i have known about this if clayop didn't post it here?
You could look through your logs for previously connected peers.
104.236.144.84:1776 is my seed node and is the node I plan on using as a seed node on the real chain.
-
No that does not look correct, the big NEW CHAIN welcome is suspicious, you're trying to start a new chain there...
Try this:
witness_node --genesis-json /home/admin/BitShares2/oct5-genesis.json -d test-folder -s "104.236.51.238:2005"
BTW. Did you try removing the p2p-endpoint like I said?
It may be supicious, but look at it - it is the correct chainID. I do not know why the marque is shown. Have you never seen that? It's just another thing odd about this. You're right tho, it isn't running correctly. I've been away for 3 hours and there has been no other output. It clearly thinks it's a new chain, but why?
It seems pretty clear it's reading values from the config.ini file and they appear in the output, but what else it's doing who the fork knows?
I tried your suggestion and here are the results"
admin@seed08:~/test$ witness_node --genesis-json /home/admin/BitShares2/oct5-genesis.json -d test-folder -s "104.236.51.238:2005"
3239509ms th_a main.cpp:120 main ] Writing new config file at /home/admin/test/test-folder/config.ini
3239510ms th_a witness.cpp:83 plugin_initialize ] witness plugin: plugin_initialize() begin
3239511ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3"]
3239511ms th_a witness.cpp:111 plugin_initialize ] witness plugin: plugin_initialize() end
3239511ms th_a db_management.cpp:131 open ] Old database version detected, reindex is required
3239511ms th_a db_management.cpp:98 wipe ] Wiping database
3239523ms th_a object_database.cpp:81 wipe ] Wiping object_database.
3239524ms th_a application.cpp:243 operator() ] Initializing database...
3272050ms th_a db_debug.cpp:79 debug_dump ] total_balances[asset_id_type()].value: 14239376866944 core_asset_data.current_supply.value: 271289987694689
3272050ms th_a db_debug.cpp:82 debug_dump ] core_in_orders: 14239376866944 reported_core_in_orders: 14239376866944
3272135ms th_a thread.cpp:95 thread ] name:ntp tid:140378487215872
3272154ms th_a thread.cpp:95 thread ] name:p2p tid:140378451367680
3272207ms th_a application.cpp:123 reset_p2p_node ] Adding seed node 104.236.51.238:2005
3272209ms th_a application.cpp:135 reset_p2p_node ] Configured p2p node to listen on 0.0.0.0:50072
3272211ms th_a witness.cpp:116 plugin_startup ] witness plugin: plugin_startup() begin
3272211ms th_a witness.cpp:133 plugin_startup ] No witnesses configured! Please add witness IDs and private keys to configuration.
3272211ms th_a witness.cpp:134 plugin_startup ] witness plugin: plugin_startup() end
3272212ms th_a main.cpp:167 main ] Started witness node on a chain with 0 blocks.
3272212ms th_a main.cpp:168 main ] Chain ID is 60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83
3272340ms ntp ntp.cpp:177 read_loop ] ntp_delta_time updated to 3374 us
I suspect that's the last output we'll see from this witness_node until I press ^C. Using your cmd line created a new folder in /home/admin/test, since that is where I ran your command line. Of course since nothing existed it created the default folder and placed the default (i.e. mostly everything commented config.ini) in there. Why does it ignore the seed cmd line arg?
I did a second attempt with your cmd line identical to before but I edited the mostly commented config.ini and added the same seed mode definition used on the command line. It crashed and died a firey death, but it did report that it added a seed:
1008672ms th_a application.cpp:123 reset_p2p_node ] Adding seed node 104.236.51.238:2005
-
No that does not look correct, the big NEW CHAIN welcome is suspicious, you're trying to start a new chain there...
Try this:
witness_node --genesis-json /home/admin/BitShares2/oct5-genesis.json -d test-folder -s "104.236.51.238:2005"
BTW. Did you try removing the p2p-endpoint like I said?
It may be supicious, but look at it - it is the correct chainID. I do not know why the marque is shown. Have you never seen that? It's just another thing odd about this. You're right tho, it isn't running correctly. I've been away for 3 hours and there has been no other output. It clearly thinks it's a new chain, but why?
It seems pretty clear it's reading values from the config.ini file and they appear in the output, but what else it's doing who the fork knows?
I tried your suggestion and here are the results"
admin@seed08:~/test$ witness_node --genesis-json /home/admin/BitShares2/oct5-genesis.json -d test-folder -s "104.236.51.238:2005"
3239509ms th_a main.cpp:120 main ] Writing new config file at /home/admin/test/test-folder/config.ini
3239510ms th_a witness.cpp:83 plugin_initialize ] witness plugin: plugin_initialize() begin
3239511ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3"]
3239511ms th_a witness.cpp:111 plugin_initialize ] witness plugin: plugin_initialize() end
3239511ms th_a db_management.cpp:131 open ] Old database version detected, reindex is required
3239511ms th_a db_management.cpp:98 wipe ] Wiping database
3239523ms th_a object_database.cpp:81 wipe ] Wiping object_database.
3239524ms th_a application.cpp:243 operator() ] Initializing database...
3272050ms th_a db_debug.cpp:79 debug_dump ] total_balances[asset_id_type()].value: 14239376866944 core_asset_data.current_supply.value: 271289987694689
3272050ms th_a db_debug.cpp:82 debug_dump ] core_in_orders: 14239376866944 reported_core_in_orders: 14239376866944
3272135ms th_a thread.cpp:95 thread ] name:ntp tid:140378487215872
3272154ms th_a thread.cpp:95 thread ] name:p2p tid:140378451367680
3272207ms th_a application.cpp:123 reset_p2p_node ] Adding seed node 104.236.51.238:2005
3272209ms th_a application.cpp:135 reset_p2p_node ] Configured p2p node to listen on 0.0.0.0:50072
3272211ms th_a witness.cpp:116 plugin_startup ] witness plugin: plugin_startup() begin
3272211ms th_a witness.cpp:133 plugin_startup ] No witnesses configured! Please add witness IDs and private keys to configuration.
3272211ms th_a witness.cpp:134 plugin_startup ] witness plugin: plugin_startup() end
3272212ms th_a main.cpp:167 main ] Started witness node on a chain with 0 blocks.
3272212ms th_a main.cpp:168 main ] Chain ID is 60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83
3272340ms ntp ntp.cpp:177 read_loop ] ntp_delta_time updated to 3374 us
I suspect that's the last output we'll see from this witness_node until I press ^C. Using your cmd line created a new folder in /home/admin/test, since that is where I ran your command line. Of course since nothing existed it created the default folder and placed the default (i.e. mostly everything commented config.ini) in there. Why does it ignore the seed cmd line arg?
I did a second attempt with your cmd line identical to before but I edited the mostly commented config.ini and added the same seed mode definition used on the command line. It crashed and died a firey death, but it did report that it added a seed:
1008672ms th_a application.cpp:123 reset_p2p_node ] Adding seed node 104.236.51.238:2005
OK I just tested on my macbook which hadn't been updated in a while. I deleted everything and just started from scratch.
The issue you're having is quite simple: the seed node you're using isn't working (either it's refusing more connections or it's down, who knows)
I first tried the command I gave you, and same result as you (empty chain with nothing happening after first init)
I then added a seed node, and it started syncing right away. Here's the new command I used:
./witness_node --rpc-endpoint "0.0.0.0:8090" --genesis-json oct5-genesis.json -d oct-5 -s "104.236.118.105:1776" -s "188.165.233.53:1777"
-
Seed node is back to normal.
-
why so many duplicate blocks?
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)
-
My witness has lost sync once and crashed twice in the last 36 hours.
I was running the witness on ubuntu 15.04x64 before this for many days with no issues but 15.04 had compatibility issues with xerocs feed script dependencies so I switched to 14.04x64 and ran the script. Since switching to 14.04 and running the feed, I've repeatedly had these issues.
I'm not saying they're related, just making note of it. I'm switching back to 15.04 now to see if it crashes in the time we have left for testnet.
-
No that does not look correct, the big NEW CHAIN welcome is suspicious, you're trying to start a new chain there...
Try this:
witness_node --genesis-json /home/admin/BitShares2/oct5-genesis.json -d test-folder -s "104.236.51.238:2005"
BTW. Did you try removing the p2p-endpoint like I said?
It may be supicious, but look at it - it is the correct chainID. I do not know why the marque is shown. Have you never seen that? It's just another thing odd about this. You're right tho, it isn't running correctly. I've been away for 3 hours and there has been no other output. It clearly thinks it's a new chain, but why?
It seems pretty clear it's reading values from the config.ini file and they appear in the output, but what else it's doing who the fork knows?
I tried your suggestion and here are the results"
admin@seed08:~/test$ witness_node --genesis-json /home/admin/BitShares2/oct5-genesis.json -d test-folder -s "104.236.51.238:2005"
3239509ms th_a main.cpp:120 main ] Writing new config file at /home/admin/test/test-folder/config.ini
3239510ms th_a witness.cpp:83 plugin_initialize ] witness plugin: plugin_initialize() begin
3239511ms th_a witness.cpp:93 plugin_initialize ] key_id_to_wif_pair: ["GPH6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3"]
3239511ms th_a witness.cpp:111 plugin_initialize ] witness plugin: plugin_initialize() end
3239511ms th_a db_management.cpp:131 open ] Old database version detected, reindex is required
3239511ms th_a db_management.cpp:98 wipe ] Wiping database
3239523ms th_a object_database.cpp:81 wipe ] Wiping object_database.
3239524ms th_a application.cpp:243 operator() ] Initializing database...
3272050ms th_a db_debug.cpp:79 debug_dump ] total_balances[asset_id_type()].value: 14239376866944 core_asset_data.current_supply.value: 271289987694689
3272050ms th_a db_debug.cpp:82 debug_dump ] core_in_orders: 14239376866944 reported_core_in_orders: 14239376866944
3272135ms th_a thread.cpp:95 thread ] name:ntp tid:140378487215872
3272154ms th_a thread.cpp:95 thread ] name:p2p tid:140378451367680
3272207ms th_a application.cpp:123 reset_p2p_node ] Adding seed node 104.236.51.238:2005
3272209ms th_a application.cpp:135 reset_p2p_node ] Configured p2p node to listen on 0.0.0.0:50072
3272211ms th_a witness.cpp:116 plugin_startup ] witness plugin: plugin_startup() begin
3272211ms th_a witness.cpp:133 plugin_startup ] No witnesses configured! Please add witness IDs and private keys to configuration.
3272211ms th_a witness.cpp:134 plugin_startup ] witness plugin: plugin_startup() end
3272212ms th_a main.cpp:167 main ] Started witness node on a chain with 0 blocks.
3272212ms th_a main.cpp:168 main ] Chain ID is 60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83
3272340ms ntp ntp.cpp:177 read_loop ] ntp_delta_time updated to 3374 us
I suspect that's the last output we'll see from this witness_node until I press ^C. Using your cmd line created a new folder in /home/admin/test, since that is where I ran your command line. Of course since nothing existed it created the default folder and placed the default (i.e. mostly everything commented config.ini) in there. Why does it ignore the seed cmd line arg?
I did a second attempt with your cmd line identical to before but I edited the mostly commented config.ini and added the same seed mode definition used on the command line. It crashed and died a firey death, but it did report that it added a seed:
1008672ms th_a application.cpp:123 reset_p2p_node ] Adding seed node 104.236.51.238:2005
OK I just tested on my macbook which hadn't been updated in a while. I deleted everything and just started from scratch.
The issue you're having is quite simple: the seed node you're using isn't working (either it's refusing more connections or it's down, who knows)
I first tried the command I gave you, and same result as you (empty chain with nothing happening after first init)
I then added a seed node, and it started syncing right away. Here's the new command I used:
./witness_node --rpc-endpoint "0.0.0.0:8090" --genesis-json oct5-genesis.json -d oct-5 -s "104.236.118.105:1776" -s "188.165.233.53:1777"
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?
-
It may be supicious, but look at it - it is the correct chainID. I do not know why the marque is shown. Have you never seen that? It's just another thing odd about this.
The "NEW CHAIN -- Welcome to graphene!" message should only display:
- If the blockchain is empty
- And --enable-stale-production is set
We do not recommend running with --enable-stale-production except in very specific (and unusual) circumstances: If you're creating an entirely new blockchain, or if you're trying to resurrect a blockchain which has not had new blocks in a long time (for example if you control a witness for an older testnet that nobody's used for days / weeks and want to resume producing blocks on that testnet for whatever reason).
You might have enable-stale-production set in your config file, if so, I recommend removing it; the banner should go away.
-
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).
-
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:
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:
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.
-
why so many duplicate blocks?
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.
-
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').
-
is it stable enough for update bts1.0?
-
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:
/home/admin/BitShares2_bin/witness_node --data-dir /home/admin/BitShares2_seedor if using bts_tools:
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):
# 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
-
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.
-
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
-
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
-
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
-
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.
-
Yep, was the same genesis file...
-
We changed how the genesis id is calculated :(
-
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 ?
-
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