BitShares Forum
Main => General Discussion => Topic started by: toast on June 09, 2014, 01:54:36 am
-
Here is the setup guide: https://github.com/BitShares/bitshares_toolkit/wiki/DPOS-initial-delegate-setup
Use this thread for issues related to getting your initial delegate running.
COMMON ISSUES, PLEASE READ:
* All delegates were registered with "init-delegate-N" as names, this is expected. These are pre-registered accounts and you do not need to make new accounts for anything, unless you want to.
* "wallet_list_receive_accounts" clips your names... for now type "enable_raw" before using your command to see the raw json dump with your names, I will fix the display tomorrow.
* for people trying to get this to work on debian and getting import errors for keys, make sure that you compile with gcc 4.8, as gcc 4.7 doesn't work (compiles correctly but then crashes randomly or fails importing keys in weird places...)
-
+5%
-
Not for Windows users?
-
Not for Windows users?
The client works on windows and all the CLI args are the same, I just don't have a windows machine to test the outside steps (does `screen` work on windows? IDK).
If you're a savvy user it should be pretty straightforward. Would love if someone could write up the parts that are different for windows.
-
Not for Windows users?
The client works on windows and all the CLI args are the same, I just don't have a windows machine to test the outside steps (does `screen` work on windows? IDK).
If you're a savvy user it should be pretty straightforward. Would love if someone could write up the parts that are different for windows.
No windows GUI right now... this is all bleeding edge stuff that we just got built today. The GUI is very experimental.
-
I'm ready, thank you :)
-
check in new code from git but not able to do cmake. please check following error message
-- signals
-- serialization
-- chrono
-- unit_test_framework
-- context
-- locale
-- coroutine
-- Setting up OpenSSL root and include vars to , /include
-- Finished fc module configuration...
-- Could NOT find Curses (missing: CURSES_LIBRARY CURSES_INCLUDE_PATH)
-- Using as BerkeleyDB root
-- Looking for: db_cxx-6.0
-- debug/usr/lib/x86_64-linux-gnu/libdb_cxx.sooptimized/usr/lib/x86_64-linux-gnu/libdb_cxx.so
-- Found BerkeleyDB: /usr/include
-- Enabling Bitcoin Core Wallet Imports
CMake Error at programs/client/CMakeLists.txt:8 (target_include_directories):
target_include_directories called with invalid arguments
-- Configuring incomplete, errors occurred!
-
What is your cmake --version?
cmake version 2.8.12.2
-
daniel@ubuntu:~/bitshares_toolkit$ cmake /V
cmake version 2.8.12.2
What is your cmake --version?
cmake version 2.8.12.2
May need to Temporarily set CURSES_USE_NCURSES to TRUE to force the use of NCURSES, rather than letting CMake try to find CURSES.
-
Toast, have you updated GIT? I guess everyone will have the same problem as i experienced
-
Name is cut off with ...
Xeldal-1 (unlocked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
init-delega... (delegate)0.000000 XTS XTS5iNWht2kEmdWNDf6cRz6HiVEs2zk3X61GpQvrQT1wQf66xucit 2014-06-01T00:00:00 0
"OK"
How to >>> wallet_get_account init-delega??
is there another way to find this name somewhere?
Edit: clarity
-
Troglodactyl_dw (unlocked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
troglodactyl-delegate-5 0.000000 XTS XTS66egtaE9cVPqzNYew5tu2zYjGMroFUTHJYZfRmUukezVxEQ7mF NO 0
init-delegate-65 0.000000 XTS XTS8TouigRWFaQ8Bxt5YrPQJwR77RKFuCmbs5hTtuiQbzgNexwzef NO 0
init-delegate-64 0.000000 XTS XTS5EVghckGywFQL4StpqMiYEiRJvpSKBUUe35ePL4RMyDcwk97ko NO 0
init-delegate-63 0.000000 XTS XTS8aNGydnsjGn2YH7xEvocgYF2tC6zTnuLosqYJ9DyD9n3sfrxGC NO 0
init-delegate-62 0.000000 XTS XTS5DmPZBzrAxmQ5CQHQxfZ5fLWKVJ1kDvdqcBYbwBm7nuqBEcFX2 NO 0
"OK"
Troglodactyl_dw (unlocked) >>> blockchain_list_registered_accounts init-delegate-62 4
NAME KEY REGISTERED VOTES FOR VOTES AGAINST TRUST LEVEL
init-delega... (delegate)XTS5DmPZBzrAxmQ5CQHQxfZ5fLWKVJ1kDvdqcBYbwBm7nuqBEcFX2 2014-06-01T00:00:00 86821738348 0 0
init-delega... (delegate)XTS8aNGydnsjGn2YH7xEvocgYF2tC6zTnuLosqYJ9DyD9n3sfrxGC 2014-06-01T00:00:00 117449299698 0 0
init-delega... (delegate)XTS5EVghckGywFQL4StpqMiYEiRJvpSKBUUe35ePL4RMyDcwk97ko 2014-06-01T00:00:00 111941118448 0 0
init-delega... (delegate)XTS8TouigRWFaQ8Bxt5YrPQJwR77RKFuCmbs5hTtuiQbzgNexwzef 2014-06-01T00:00:00 105192196131 0 0
Troglodactyl_dw (unlocked) >>>
My account registration seems to be inconsistent. Not sure what's going on there. I cleared my data and then re-imported the wallet files. I changed the names of the delegates that should be registered manually for consistency.
Does rescanning only check balances and not key registration?
-
@xeldal great point, totally need more room in display. For now you can use secret command "enable_raw" before "wallet_list_receive_accounts" to get a raw json dump and see your names. Will fix soon.
@trog looks fine to me. "blockchain_list_registered_accounts" shows ALL accounts, not just yours.
Yours were all pre-registered with 'init-delegate-N' and not the names you gave us.
-
@sfinder I'm not sure what's going on, have not encountered this issue yet on any build I tried. Which OS version?
-
@trog looks fine to me. "blockchain_list_registered_accounts" shows ALL accounts, not just yours.
Yours were all pre-registered with 'init-delegate-N' and not the names you gave us.
That isn't the issue. The issue is that my accounts don't seem to be properly linking to the blockchain registered accounts on rescanning, so it looks like my delegates are inactive even though I have their keys in the wallet and it's unlocked.
-
@trog looks fine to me. "blockchain_list_registered_accounts" shows ALL accounts, not just yours.
Yours were all pre-registered with 'init-delegate-N' and not the names you gave us.
That isn't the issue. The issue is that my accounts don't seem to be properly linking to the blockchain registered accounts on rescanning, so it looks like my delegates are inactive even though I have their keys in the wallet and it's unlocked.
What do you mean? I see your 4 accounts in both lists, they are in reversed order though.
It looks like you are producing blocks too (2 or 3 per delegate just now)
edit: the only thing I see is that "registered" is "NO" when it should be "YES" - this is a display bug only I think
-
How to be registered?
NAME BALANCE KEY REGISTERED TRUST LEVEL
welk1n-d-5 0.000000 XTS XTS6z7aMnBmXi7qL9uHfgWS6d1wedEpvQNTrwgeGb8h1MH9WVXtRC NO 0
welk1n-d-4 0.000000 XTS XTS7SDs7tmoYe96wjRzYqavAu4nehaMUTh3TbkGe9EPWNbA1P2XPA NO 0
welk1n-d-3 0.000000 XTS XTS7p56UNQLyWc3NB2yeT4VVtYhanf6wFC356c6vbfpvQ9CHUmg6X NO 0
welk1n-d-2 0.000000 XTS XTS5urryfpdjZgwavKwufJ9A1d816LFaPbSQLu5eP2G76B7hbtuxj NO 0
welk1n-d-1 0.000000 XTS XTS6f8fzmUDQp63nTYgsA2GQtvFoPvKrmTmuhkCvQUCnKUJwxTxtx NO 0
"OK"
-
How to be registered?
NAME BALANCE KEY REGISTERED TRUST LEVEL
welk1n-d-5 0.000000 XTS XTS6z7aMnBmXi7qL9uHfgWS6d1wedEpvQNTrwgeGb8h1MH9WVXtRC NO 0
welk1n-d-4 0.000000 XTS XTS7SDs7tmoYe96wjRzYqavAu4nehaMUTh3TbkGe9EPWNbA1P2XPA NO 0
welk1n-d-3 0.000000 XTS XTS7p56UNQLyWc3NB2yeT4VVtYhanf6wFC356c6vbfpvQ9CHUmg6X NO 0
welk1n-d-2 0.000000 XTS XTS5urryfpdjZgwavKwufJ9A1d816LFaPbSQLu5eP2G76B7hbtuxj NO 0
welk1n-d-1 0.000000 XTS XTS6f8fzmUDQp63nTYgsA2GQtvFoPvKrmTmuhkCvQUCnKUJwxTxtx NO 0
"OK"
Looks like "registered" status is buggy. Actually I see you made new accounts, you should not need to - if you just import your keys and rescan you will have pre-registered accounts "init-delegate-N". If you want to register new accounts you can use "wallet_account_register"
-
cgafeng (locked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
cgafeng (delegate) 670.177299 XTS XTS5V87vRKu7K9z3nBDEprCnyyxESaTZDZubUPVc9uhfEdY6hj4Us 2014-06-09T03:57:45 0
I use wallet_account_register to register as delegate, are my delegate name is cgafeng?
when i use blockchain_list_delegates, i don't find my name.
-
@sfinder I'm not sure what's going on, have not encountered this issue yet on any build I tried. Which OS version?
my os is ubuntu 14.04 and i got following CMAKE error
CMake Error at programs/client/CMakeLists.txt:8 (target_include_directories):
target_include_directories called with invalid arguments
daniel@ubuntu:~/bitshares_toolkit$ cmake .
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.8")
-- Configuring BitShares on Linux
-- Using as BerkeleyDB root
-- Looking for: db_cxx-6.0
-- debug/usr/lib/x86_64-linux-gnu/libdb_cxx.sooptimized/usr/lib/x86_64-linux-gnu /libdb_cxx.so
-- Found BerkeleyDB: /usr/include
-- Using custom FindBoost.cmake
-- Boost version: 1.54.0
-- Found the following Boost libraries:
-- thread
-- date_time
-- system
-- filesystem
-- program_options
-- signals
-- serialization
-- chrono
-- unit_test_framework
-- context
-- locale
-- Using custom FindBoost.cmake
-- Boost version: 1.54.0
-- Found the following Boost libraries:
-- coroutine
-- Configuring project fc located in: /home/daniel/bitshares_toolkit/libraries/f c
-- Configuring fc to build on Unix/Apple
-- Using custom FindBoost.cmake
-- Boost version: 1.54.0
-- Found the following Boost libraries:
-- thread
-- date_time
-- system
-- filesystem
-- program_options
-- signals
-- serialization
-- chrono
-- unit_test_framework
-- context
-- locale
-- coroutine
-- Setting up OpenSSL root and include vars to , /include
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libssl.a;/usr/lib/x86_64-linux-gnu/l ibcrypto.a (found version "1.0.1f")
** for a debug build: cmake -DCMAKE_BUILD_TYPE=Debug ..
-- Finished fc module configuration...
-- Found Curses: /usr/lib/x86_64-linux-gnu/libcurses.so
-- Found Readline: /usr/include
-- Using as BerkeleyDB root
-- Looking for: db_cxx-6.0
-- debug/usr/lib/x86_64-linux-gnu/libdb_cxx.sooptimized/usr/lib/x86_64-linux-gnu /libdb_cxx.so
-- Found BerkeleyDB: /usr/include
-- Enabling Bitcoin Core Wallet Imports
CMake Error at programs/client/CMakeLists.txt:8 (target_include_directories):
target_include_directories called with invalid arguments
-- Configuring incomplete, errors occurred!
-
cgafeng (locked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
cgafeng (delegate) 670.177299 XTS XTS5V87vRKu7K9z3nBDEprCnyyxESaTZDZubUPVc9uhfEdY6hj4Us 2014-06-09T03:57:45 0
I use wallet_account_register to register as delegate, are my delegate name is cgafeng?
when i use blockchain_list_delegates, i don't find my name.
No, everyone was registered with names "init-delegate-NN". You do not need to make new accounts, just import and rescan exactly as in the guide.
Your new name is registered as a delegate, but it has not votes and will not make blocks.
-
@sfinder I will look at your issue tomorrow, I have to sleep now. I cannot reproduce it easily
-
I'm getting the same build problem as sfinder. (also on ubuntu 14.04)
The last merge seems to have caused it.
bitshares_toolkit$ git log 035357b..2f8e2b1
commit 2f8e2b19632603d398bf000ced29f0a0b79cffb8
Merge: 035357b 6102b44
Author: Nikolai Mushegian <nikolai.mushegian@gmail.com>
Date: Sun Jun 8 23:04:12 2014 -0400
Merge pull request #238 from HackFisher/master
#233, import keyhotee id.
commit 6102b4478ef6d0d822383bcff81de7b5f09322f9
Author: HackFisher <hackfisher@gmail.com>
Date: Sun Jun 8 21:09:38 2014 -0400
modifile api description
commit c9dcc1c13fd975a1c2e333ad11be92ec28528bc3
Author: HackFisher <hackfisher@gmail.com>
Date: Sun Jun 8 21:07:32 2014 -0400
using keyhotee id as account name
commit 723e466ccb9dc87a08a3895a66c123e5aff529c8
Merge: c182d24 db48890
Author: HackFisher <hackfisher@gmail.com>
Date: Sun Jun 8 20:53:09 2014 -0400
Merge remote-tracking branch 'upstream/master'
commit c182d24ae7ee569f5c601a915bea317477d24c2c
Author: HackFisher <hackfisher@gmail.com>
Date: Sun Jun 8 20:52:51 2014 -0400
fixed 233, import keyhotee id.
-
@sfinder I will look at your issue tomorrow, I have to sleep now. I cannot reproduce it easily
check following link. problem was caused by hackfish committed cmakelist for Keyhotee. manually fix
https://github.com/BitShares/bitshares_toolkit/commit/c182d24ae7ee569f5c601a915bea317477d24c2c#diff-d3cc6a7d9369a54a5ed80c1cf4f996a7
-
@sfinder I will look at your issue tomorrow, I have to sleep now. I cannot reproduce it easily
check following link. problem was caused by hackfish committed cmakelist for Keyhotee. manually fix
https://github.com/BitShares/bitshares_toolkit/commit/c182d24ae7ee569f5c601a915bea317477d24c2c#diff-d3cc6a7d9369a54a5ed80c1cf4f996a7
Yes , diff the two files , you will find it.
-
How to be registered?
NAME BALANCE KEY REGISTERED TRUST LEVEL
welk1n-d-5 0.000000 XTS XTS6z7aMnBmXi7qL9uHfgWS6d1wedEpvQNTrwgeGb8h1MH9WVXtRC NO 0
welk1n-d-4 0.000000 XTS XTS7SDs7tmoYe96wjRzYqavAu4nehaMUTh3TbkGe9EPWNbA1P2XPA NO 0
welk1n-d-3 0.000000 XTS XTS7p56UNQLyWc3NB2yeT4VVtYhanf6wFC356c6vbfpvQ9CHUmg6X NO 0
welk1n-d-2 0.000000 XTS XTS5urryfpdjZgwavKwufJ9A1d816LFaPbSQLu5eP2G76B7hbtuxj NO 0
welk1n-d-1 0.000000 XTS XTS6f8fzmUDQp63nTYgsA2GQtvFoPvKrmTmuhkCvQUCnKUJwxTxtx NO 0
"OK"
Looks like "registered" status is buggy. Actually I see you made new accounts, you should not need to - if you just import your keys and rescan you will have pre-registered accounts "init-delegate-N". If you want to register new accounts you can use "wallet_account_register"
I just import the keys and rescan it, but the status is still no registered.
-
This is what I have so far：
harvey (unlocked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
harvey-delegate-5 0.000000 XTS XTS7ze619FTgRReQsYEKYj8CbuiWB17q629gCz34Q7aeqe4yMida5 NO 0
harvey-delegate-4 0.000000 XTS XTS7fzyfX657vDUP4UVXRHNxCMZsGpCCGkvP7rN5NKkuEjktg5sHd NO 0
harvey-delegate-3 0.000000 XTS XTS6LDMYp9UNEYLUEdpCqx5dCEkWwrpP67LE5Zu3sSYqjP6LraqTW NO 0
harvey-delegate-2 0.000000 XTS XTS7qQScYbuFqsffgH6AammYXWMkZ9jSYdsYW21zguc2k2N3hYnfN NO 0
harvey-delegate-1 0.000000 XTS XTS7Bsi43JASDcPdgcLaXSLQ7mVNJReUvG4rcQYHHaJ3Ca7SLPYyq NO 0
"OK"
-
wallet (unlocked) >>> enable_raw wallet get_receive_accounts
returns
wallet (unlocked) >>>
With no info.
To find my delegate numbers I started with
wallet (unlocked) >>> blockchain_get_account_record init-delegate-1
and increased the integer at the end by one. When you get to an return that does not list
"next_secret_hash": "0000000000000000000000000000000000000000",
but instead has a hex key inside the final " " you should have the value of your delegate.
Its possible that I am just stupid, and did not understand the instructions. (the brain power does fade this late at night)
**so. I have just tested this and have gotten next_secret_hash from keys I probably shouldn't have. Chances are I am the dumz. I will retry in the morning with the firepower of this fully ARMED and OPERATIONAL battle station!**
-
Also. If there are any nix masters out there. What is the purpose of splitting the screen -S and the running gdb?
It seems like I can get similar results from running
screen -S Bitshares ./bitshares_client
without the step of running gdb
from a theoretical viewpoint, I'd like to understand the difference.
**this is purely for my educational purposes, and is not at all important**
-
Why dont you state git revision the network should be used?
The head needs additional modification to make it work (see lib curses issue).
035357b7ffbcc394236fec5e2cb8d0e9bf707c97 seems to compile and run without issues on clean ubuntu server 14.04 installation and following the instructions.
-
Drat I just missed the key-registering window when I finally was able to access my pc late last night. Are there still open spots for registering as a delegate or are those locked down now?
Also. If there are any nix masters out there. What is the purpose of splitting the screen -S and the running gdb?
It seems like I can get similar results from running
screen -S Bitshares ./bitshares_client
without the step of running gdb
from a theoretical viewpoint, I'd like to understand the difference.
**this is purely for my educational purposes, and is not at all important**
gdb is the debugger, so in case of an error, the codemasters know what to work on. Apparently it is a lot more useful than the ubiquitous "It doesn' t work" bug report.
-
Also. If there are any nix masters out there. What is the purpose of splitting the screen -S and the running gdb?
It seems like I can get similar results from running
screen -S Bitshares ./bitshares_client
without the step of running gdb
from a theoretical viewpoint, I'd like to understand the difference.
**this is purely for my educational purposes, and is not at all important**
GDB is a debugger, if the client crashes for example GDB can give some meaningful info as to why that happened.
If all of my private keys give me:
10
registered_account:
{}
th_a wallet.cpp:777 import_private_key
{"account_name":""}
th_a wallet.cpp:812 import_private_key
{"account_name":""}
th_a wallet.cpp:831 import_wif_private_key
{}
th_a common_api_client.cpp:212 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:574 execute_command
mauritso (unlocked) >>>
That would mean that I am not an initial delegate right? (Is there a list somewhere?)
-
What commands do you run? You should aleays be able to import privekys to an account!
-
Create a wallet and import your keys:
(wallet closed) >>> wallet_create mywallet
passphrase:
passphrase (verify):
OK
mywallet (unlocked) >>> unlock 999999
passphrase:
OK
mywallet (unlocked) >>> wallet_import_private_key 5KdeCK6PcFuZqh9XBPBN2tYG2MsgXpYXG3vzPhLK1VA8ye6Ptwf
OK(repeat for each key - some will fail as we did not include all 5 for everyone)
mywallet (unlocked) >>> wallet_rescan_blockchain
...
Scan complete.
OK
Just followed the instructions and "(repeat for each key - some will fail as we did not include all 5 for everyone)" implies that all your keys will fail if you are not an initial delegate.
-
@sfinder I will look at your issue tomorrow, I have to sleep now. I cannot reproduce it easily
check following link. problem was caused by hackfish committed cmakelist for Keyhotee. manually fix
https://github.com/BitShares/bitshares_toolkit/commit/c182d24ae7ee569f5c601a915bea317477d24c2c#diff-d3cc6a7d9369a54a5ed80c1cf4f996a7
that fixed it for me .. thx
Delegate up an running in a few minutes
-
Also. If there are any nix masters out there. What is the purpose of splitting the screen -S and the running gdb?
It seems like I can get similar results from running
screen -S Bitshares ./bitshares_client
without the step of running gdb
from a theoretical viewpoint, I'd like to understand the difference.
**this is purely for my educational purposes, and is not at all important**
GDB is a debugger, if the client crashes for example GDB can give some meaningful info as to why that happened.
If all of my private keys give me:
10
registered_account:
{}
th_a wallet.cpp:777 import_private_key
{"account_name":""}
th_a wallet.cpp:812 import_private_key
{"account_name":""}
th_a wallet.cpp:831 import_wif_private_key
{}
th_a common_api_client.cpp:212 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:574 execute_command
mauritso (unlocked) >>>
That would mean that I am not an initial delegate right? (Is there a list somewhere?)
Maybe you can find the old wallets dir and copy it to the new wallets dir.
Then you can use command
>>> wallet_open $wallet_name
I just do like this, and now is working well.
-
@sfinder I will look at your issue tomorrow, I have to sleep now. I cannot reproduce it easily
check following link. problem was caused by hackfish committed cmakelist for Keyhotee. manually fix
https://github.com/BitShares/bitshares_toolkit/commit/c182d24ae7ee569f5c601a915bea317477d24c2c#diff-d3cc6a7d9369a54a5ed80c1cf4f996a7
that fixed it for me .. thx
Delegate up an running in a few minutes
+5% me too. Thx sfinder.
-
HELP!!
My first 4 importing of private keys were all OK. But when I import my 5th private key, it reported the following errors:
10
registered_account:
{}
th_a wallet.cpp:787 import_private_key
{"account_name":""}
th_a wallet.cpp:824 import_private_key
{"account_name":""}
th_a wallet.cpp:844 import_wif_private_key
{}
th_a common_api_client.cpp:212 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:576 execute_command
Can anyone tell me how I can fix this, or whether fixing this is a must.
Since the document syas:
If you want to stay voted in, you should probably create a new delegate to campaign as, as a nameless initial delegate is unlikely to stay a delegate for long.and the "DPOS Registering Names And Delegates " is not completed yet.
FYI, my fifth public key is:
XTS7XDCb4BEeEtbPtHWGCvx9xW3r5SGTrHr8PjnH3VbhtUFWsjArm
-
HELP!!
My first 4 importing of private keys were all OK. But when I import my 5th private key, it reported the following errors:
10
registered_account:
{}
th_a wallet.cpp:787 import_private_key
{"account_name":""}
th_a wallet.cpp:824 import_private_key
{"account_name":""}
th_a wallet.cpp:844 import_wif_private_key
{}
th_a common_api_client.cpp:212 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:576 execute_command
Can anyone tell me how I can fix this, or whether fixing this is a must.
Since the document syas:
If you want to stay voted in, you should probably create a new delegate to campaign as, as a nameless initial delegate is unlikely to stay a delegate for long.and the "DPOS Registering Names And Delegates " is not completed yet.
FYI, my fifth public key is:
XTS7XDCb4BEeEtbPtHWGCvx9xW3r5SGTrHr8PjnH3VbhtUFWsjArm
dan imported 4keys for one account
-
HELP!!
My first 4 importing of private keys were all OK. But when I import my 5th private key, it reported the following errors:
10
registered_account:
{}
th_a wallet.cpp:787 import_private_key
{"account_name":""}
th_a wallet.cpp:824 import_private_key
{"account_name":""}
th_a wallet.cpp:844 import_wif_private_key
{}
th_a common_api_client.cpp:212 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:576 execute_command
Can anyone tell me how I can fix this, or whether fixing this is a must.
Since the document syas:
If you want to stay voted in, you should probably create a new delegate to campaign as, as a nameless initial delegate is unlikely to stay a delegate for long.and the "DPOS Registering Names And Delegates " is not completed yet.
FYI, my fifth public key is:
XTS7XDCb4BEeEtbPtHWGCvx9xW3r5SGTrHr8PjnH3VbhtUFWsjArm
dan imported 4keys for one account
Thank you.
If I did not get you wrong, you mean it is all OK.
:)
-
I also have just 2 working keys ..
-
cgafeng (locked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
cgafeng (delegate) 670.177299 XTS XTS5V87vRKu7K9z3nBDEprCnyyxESaTZDZubUPVc9uhfEdY6hj4Us 2014-06-09T03:57:45 0
I use wallet_account_register to register as delegate, are my delegate name is cgafeng?
when i use blockchain_list_delegates, i don't find my name.
No, everyone was registered with names "init-delegate-NN". You do not need to make new accounts, just import and rescan exactly as in the guide.
Your new name is registered as a delegate, but it has not votes and will not make blocks.
Can I join dry test now if I missed the init delegate part?
-
daniel@ubuntu:~/bitshares_toolkit$ cmake /V
cmake version 2.8.12.2
What is your cmake --version?
cmake version 2.8.12.2
May need to Temporarily set CURSES_USE_NCURSES to TRUE to force the use of NCURSES, rather than letting CMake try to find CURSES.
When I use "cmake ." try to build bitshare toolkit, I met the problem" Could not find Curses(missing: CURESES_LIBRARY CURSES_INCLUDE_PATH)
How can I fix it ?
How to set CURSES_USE_NCURSES to TRUE?
-
daniel@ubuntu:~/bitshares_toolkit$ cmake /V
cmake version 2.8.12.2
What is your cmake --version?
cmake version 2.8.12.2
May need to Temporarily set CURSES_USE_NCURSES to TRUE to force the use of NCURSES, rather than letting CMake try to find CURSES.
When I use "cmake ." try to build bitshare toolkit, I met the problem" Could not find Curses(missing: CURESES_LIBRARY CURSES_INCLUDE_PATH)
How can I fix it ?
How to set CURSES_USE_NCURSES to TRUE?
Try to checkout this revision: 035357b7ffbcc394236fec5e2cb8d0e9bf707c97 .
It works for me without modifications.
-
Well looks like none of my private WIF keys are working. The public key list:
https://bitsharestalk.org/index.php?topic=4913.msg64544#msg64544
I guess missed the bus for this initial test.
-
daniel@ubuntu:~/bitshares_toolkit$ cmake /V
cmake version 2.8.12.2
What is your cmake --version?
cmake version 2.8.12.2
May need to Temporarily set CURSES_USE_NCURSES to TRUE to force the use of NCURSES, rather than letting CMake try to find CURSES.
When I use "cmake ." try to build bitshare toolkit, I met the problem" Could not find Curses(missing: CURESES_LIBRARY CURSES_INCLUDE_PATH)
How can I fix it ?
How to set CURSES_USE_NCURSES to TRUE?
Try to checkout this revision: 035357b7ffbcc394236fec5e2cb8d0e9bf707c97 .
It works for me without modifications.
What does revision mean? I can't understand 0353......7c97
Sorry
-
daniel@ubuntu:~/bitshares_toolkit$ cmake /V
cmake version 2.8.12.2
What is your cmake --version?
cmake version 2.8.12.2
May need to Temporarily set CURSES_USE_NCURSES to TRUE to force the use of NCURSES, rather than letting CMake try to find CURSES.
When I use "cmake ." try to build bitshare toolkit, I met the problem" Could not find Curses(missing: CURESES_LIBRARY CURSES_INCLUDE_PATH)
How can I fix it ?
How to set CURSES_USE_NCURSES to TRUE?
Try to checkout this revision: 035357b7ffbcc394236fec5e2cb8d0e9bf707c97 .
It works for me without modifications.
What does revision mean? I can't understand 0353......7c97
Sorry
git checkout 035357b7ffbcc394236fec5e2cb8d0e9bf707c97
It should give you the repository state as of this commit:
https://github.com/BitShares/bitshares_toolkit/commit/035357b7ffbcc394236fec5e2cb8d0e9bf707c97
-
Importing my PTS/BTC privkeys only worked after doing the following steps
1.) get wif for pts/btc address
2.) go to brainwallet and convert Base65Check privkey to hex
3.) use key_to_wif to convert brainwallet hex key to privkey
4.) Both priv keys differ in the last view bytes (i suspect thats the Check-part)
@Devs: Please doublecheck the CHECK-procedure of your WIF formats in the code!!!
-
Drat I just missed the key-registering window when I finally was able to access my pc late last night. Are there still open spots for registering as a delegate or are those locked down now?
Not too late, you can register as a delegate on the chain.. this is just a dry run to see what problems delegates have so we can smooth it out.
-
Importing my PTS/BTC privkeys only worked after doing the following steps
1.) get wif for pts/btc address
2.) go to brainwallet and convert Base65Check privkey to hex
3.) use key_to_wif to convert brainwallet hex key to privkey
4.) Both priv keys differ in the last view bytes (i suspect thats the Check-part)
@Devs: Please doublecheck the CHECK-procedure of your WIF formats in the code!!!
Thanks for the notice I will look into this: https://github.com/BitShares/bitshares_toolkit/issues/241
-
daniel@ubuntu:~/bitshares_toolkit$ cmake /V
cmake version 2.8.12.2
What is your cmake --version?
cmake version 2.8.12.2
May need to Temporarily set CURSES_USE_NCURSES to TRUE to force the use of NCURSES, rather than letting CMake try to find CURSES.
When I use "cmake ." try to build bitshare toolkit, I met the problem" Could not find Curses(missing: CURESES_LIBRARY CURSES_INCLUDE_PATH)
How can I fix it ?
How to set CURSES_USE_NCURSES to TRUE?
Try to checkout this revision: 035357b7ffbcc394236fec5e2cb8d0e9bf707c97 .
It works for me without modifications.
What does revision mean? I can't understand 0353......7c97
Sorry
This is just the version the number is the 'hash' of the state of the code.
-
@sfinder I'm not sure what's going on, have not encountered this issue yet on any build I tried. Which OS version?
my os is ubuntu 14.04 and i got following CMAKE error
CMake Error at programs/client/CMakeLists.txt:8 (target_include_directories):
target_include_directories called with invalid arguments
daniel@ubuntu:~/bitshares_toolkit$ cmake .
-- The C compiler identification is GNU 4.8.2
....
-- Found the following Boost libraries:
-- thread
ontext
-- locale
-- coroutine
-- Setting up OpenSSL root and include vars to , /include
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libssl.a;/usr/lib/x86_64-linux-gnu/l ibcrypto.a (found version "1.0.1f")
** for a debug build: cmake -DCMAKE_BUILD_TYPE=Debug ..
-- Finished fc module configuration...
-- Found Curses: /usr/lib/x86_64-linux-gnu/libcurses.so
-- Found Readline: /usr/include
-- Using as BerkeleyDB root
-- Looking for: db_cxx-6.0
-- debug/usr/lib/x86_64-linux-gnu/libdb_cxx.sooptimized/usr/lib/x86_64-linux-gnu /libdb_cxx.so
-- Found BerkeleyDB: /usr/include
-- Enabling Bitcoin Core Wallet Imports
CMake Error at programs/client/CMakeLists.txt:8 (target_include_directories):
target_include_directories called with invalid arguments
-- Configuring incomplete, errors occurred!
Eric tells me this is fixed now.
-
Importing my PTS/BTC privkeys only worked after doing the following steps
1.) get wif for pts/btc address
2.) go to brainwallet and convert Base65Check privkey to hex
3.) use key_to_wif to convert brainwallet hex key to privkey
4.) Both priv keys differ in the last view bytes (i suspect thats the Check-part)
@Devs: Please doublecheck the CHECK-procedure of your WIF formats in the code!!!
Thanks for the notice I will look into this: https://github.com/BitShares/bitshares_toolkit/issues/241
This has been resolved.
-
Well looks like none of my private WIF keys are working. The public key list:
https://bitsharestalk.org/index.php?topic=4913.msg64544#msg64544
I guess missed the bus for this initial test.
Try this now.
-
Can I join the dry run if I missed the public key generated part?
I just build the bitshares_toolkit successfully
-
I have run about 12 hours with 2 computer,
but I still produce 0 block.
Is this correct?
my account is init-delegate-17, init-delegate-18,init-delegate-19,init-delegate-20
-
Can I join the dry run if I missed the public key generated part?
I just build the bitshares_toolkit successfully
You can join and even register as delegate if you have funds to import but you will not be an active delegate unless you convince people to vote for you
-
I have run about 12 hours with 2 computer,
but I still produce 0 block.
Is this correct?
my account is init-delegate-17, init-delegate-18,init-delegate-19,init-delegate-20
I see that you are producing blocks, where do you see that you produced 0?
-
I successfully produced 18 blocks with 2 delegates each
-
Could some of you attempt to use this API call to import your keyhotee IDs:
wallet_import_keyhotee <firstname> <middlename> <lastname> <brainkey> <keyhoteeid>
-
I get the following error trying to launch client
Loading blockchain from "/root/.BitSharesXTS/chain"
------------ error --------------
10001
Unable to open database /root/.BitSharesXTS/chain/fork_number_db
IO error: lock /root/.BitSharesXTS/chain/fork_number_db/LOCK: Resource temporarily unavailable
{"db":"/root/.BitSharesXTS/chain/fork_number_db","msg":"IO error: lock /root/.BitSharesXTS/chain/fork_number_db/LOCK: Resource temporarily unavailable"}
th_a level_map.hpp:46 open
{"data_dir":"/root/.BitSharesXTS/chain"}
th_a chain_database.cpp:877 open
{"data_dir":"/root/.BitSharesXTS"}
th_a client.cpp:352 open
-
I get the following error trying to launch client
Loading blockchain from "/root/.BitSharesXTS/chain"
------------ error --------------
10001
Unable to open database /root/.BitSharesXTS/chain/fork_number_db
IO error: lock /root/.BitSharesXTS/chain/fork_number_db/LOCK: Resource temporarily unavailable
{"db":"/root/.BitSharesXTS/chain/fork_number_db","msg":"IO error: lock /root/.BitSharesXTS/chain/fork_number_db/LOCK: Resource temporarily unavailable"}
th_a level_map.hpp:46 open
{"data_dir":"/root/.BitSharesXTS/chain"}
th_a chain_database.cpp:877 open
{"data_dir":"/root/.BitSharesXTS"}
th_a client.cpp:352 open
You have the client running already. Did you use screen and then detach?
Try "screen -r delegate"
-
root@xt:~/bitshares_toolkit# screen -r delegate
There are screens on:
15988.delegate (06/09/2014 10:23:17 AM) (Attached)
13899.delegate (06/09/2014 09:59:52 AM) (Attached)
12728.delegate (06/08/2014 11:10:05 PM) (Attached)
12713.delegate (06/08/2014 11:08:16 PM) (Attached)
There is no screen to be resumed matching delegate.
-
I have run about 12 hours with 2 computer,
but I still produce 0 block.
Is this correct?
my account is init-delegate-17, init-delegate-18,init-delegate-19,init-delegate-20
I see that you are producing blocks, where do you see that you produced 0?
This is probably because we don't expose the delegate's pay which is separate from their normal balance. If delegates are looking for 'coinbase' transactions, they don't exist... your pay is a property of your account.
default (unlocked) >>> blockchain_get_account_record init-delegate-17
{
"id": 17,
"name": "init-delegate-17",
"public_data": null,
"owner_key": "XTS57VJ3pc85WWJWCwNzPBcwNHEqHstavbhgFfHgc8nTmCchXGJAM",
"active_key_history": [[
"19700101T000000",
"XTS57VJ3pc85WWJWCwNzPBcwNHEqHstavbhgFfHgc8nTmCchXGJAM"
]
],
"delegate_info": {
"votes_for": 91796978110,
"votes_against": 0,
"blocks_produced": 18,
"blocks_missed": 13,
"pay_balance": 80020,
"next_secret_hash": "8074d5a45dffa7031980c1188d853a514cab88c0",
"last_block_num_produced": 655
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null
}
-
root@xt:~/bitshares_toolkit# screen -r delegate
There are screens on:
15988.delegate (06/09/2014 10:23:17 AM) (Attached)
13899.delegate (06/09/2014 09:59:52 AM) (Attached)
12728.delegate (06/08/2014 11:10:05 PM) (Attached)
12713.delegate (06/08/2014 11:08:16 PM) (Attached)
There is no screen to be resumed matching delegate.
You can run all delegates in a single process...
You can reattach to these screens with:
screen -r -D 12713.delegate
-
That worked. Thanks
I created 4 different Wallets, 1 for each delegate. I wasn't clear on this.
Not sure how they ended up in different processes, not sure how to get them into 1.
Thanks.
-
Can I join the dry run if I missed the public key generated part?
I just build the bitshares_toolkit successfully
You can join and even register as delegate if you have funds to import but you will not be an active delegate unless you convince people to vote for you
What's the difference between initial delegate and delegate imported from funds?
-
Can I join the dry run if I missed the public key generated part?
I just build the bitshares_toolkit successfully
You can join and even register as delegate if you have funds to import but you will not be an active delegate unless you convince people to vote for you
What's the difference between initial delegate and delegate imported from funds?
Only that the initial delegates got votes by default until they are voted out.
-
Can I join the dry run if I missed the public key generated part?
I just build the bitshares_toolkit successfully
You can join and even register as delegate if you have funds to import but you will not be an active delegate unless you convince people to vote for you
What's the difference between initial delegate and delegate imported from funds?
Initial delegates are the first 97 in the genesis block.
You don't "import a delegate from funds", you just need some funds to register as a delegate so people can vote for you. Once you are voted in there is no difference.
-
That worked. Thanks
I created 4 different Wallets, 1 for each delegate. I wasn't clear on this.
Not sure how they ended up in different processes, not sure how to get them into 1.
Thanks.
Close down all but one process.
Import all private keys into that one process.
Done.
-
What are some commands that I can use to verify that my delegates are producing blocks properly and not just on it's own fork.
I used blockchain_get_blockcount which is currently showing 97
-
What are some commands that I can use to verify that my delegates are producing blocks properly and not just on it's own fork.
I used blockchain_get_blockcount which is currently showing 97
default (unlocked) >>> info
{
"blockchain_head_block_num": 1059,
"blockchain_head_block_time": "20140609T150800"
}
If you are on a fork... then we need to do a better job detecting and reporting this.
-
What are some commands that I can use to verify that my delegates are producing blocks properly and not just on it's own fork.
I used blockchain_get_blockcount which is currently showing 97
default (unlocked) >>> info
{
"blockchain_head_block_num": 1059,
"blockchain_head_block_time": "20140609T150800"
}
If you are on a fork... then we need to do a better job detecting and reporting this.
We will disable block production when a client has no connections... only makes sense.
-
Well looks like none of my private WIF keys are working. The public key list:
https://bitsharestalk.org/index.php?topic=4913.msg64544#msg64544
I guess missed the bus for this initial test.
Try this now.
Tried but no go. For some of the delegates now I keep getting:
10
false: Error parsing WIF private key
{}
th_a wallet.cpp:843 import_wif_private_key
{"account_name":""}
th_a wallet.cpp:845 import_wif_private_key
{}
th_a common_api_client.cpp:212 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:576 execute_command
whereas others seem to be giving the same old "registered" address error.
-
why only one of account "pan2pan-05" showing in my "wallet_list_receive_accounts"? I did import 5 private key to 5 accounts that I created in my wallet
pan2pan (unlocked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
pan2pan-05 0.000000 XTS XTS8T5M76CG8PFopcuSoAkvTfzkGhZMR44Dckd6JB5zYxxde1vqaU NO 0
init-delega... (delegate)0.000000 XTS XTS4u3cQJNLS9jDN1mCM9ynLNHQV9PuEVfwA2R95XnV7ZDNjJL89z 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS5vXkQbGLEwaye3ZsLAtMMEe6tkh724nr2zoGHHeAUCsvVeywvc 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
"OK"
-
why only one of account "pan2pan-05" showing in my "wallet_list_receive_accounts"? I did import 5 private key to 5 accounts that I created in my wallet
pan2pan (unlocked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
pan2pan-05 0.000000 XTS XTS8T5M76CG8PFopcuSoAkvTfzkGhZMR44Dckd6JB5zYxxde1vqaU NO 0
init-delega... (delegate)0.000000 XTS XTS4u3cQJNLS9jDN1mCM9ynLNHQV9PuEVfwA2R95XnV7ZDNjJL89z 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS5vXkQbGLEwaye3ZsLAtMMEe6tkh724nr2zoGHHeAUCsvVeywvc 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
"OK"
from op:
COMMON ISSUES, PLEASE READ:
* All delegates were registered with "init-delegate-N" as names, this is expected. These are pre-registered accounts and you do not need to make new accounts for anything, unless you want to.
Sorry it was confusing b/c we asked for your names
-
why only one of account "pan2pan-05" showing in my "wallet_list_receive_accounts"? I did import 5 private key to 5 accounts that I created in my wallet
pan2pan (unlocked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
pan2pan-05 0.000000 XTS XTS8T5M76CG8PFopcuSoAkvTfzkGhZMR44Dckd6JB5zYxxde1vqaU NO 0
init-delega... (delegate)0.000000 XTS XTS4u3cQJNLS9jDN1mCM9ynLNHQV9PuEVfwA2R95XnV7ZDNjJL89z 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS5vXkQbGLEwaye3ZsLAtMMEe6tkh724nr2zoGHHeAUCsvVeywvc 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
"OK"
We only used 4 out of 5 keys for some of you.
-
Here only 2 are working :(
-
but not able to see full name (check in red ) under my "wallet_list_receive_accounts"
init-delega... (delegate)0.000000 XTS XTS4u3cQJNLS9jDN1mCM9ynLNHQV9PuEVfwA2R95XnV7ZDNjJL89z 2014-06-01T00:00:00 0
why only one of account "pan2pan-05" showing in my "wallet_list_receive_accounts"? I did import 5 private key to 5 accounts that I created in my wallet
pan2pan (unlocked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
pan2pan-05 0.000000 XTS XTS8T5M76CG8PFopcuSoAkvTfzkGhZMR44Dckd6JB5zYxxde1vqaU NO 0
[b][color=red]init-delega... (delegate)0.000000 XTS [/color][/b] XTS4u3cQJNLS9jDN1mCM9ynLNHQV9PuEVfwA2R95XnV7ZDNjJL89z 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS5vXkQbGLEwaye3ZsLAtMMEe6tkh724nr2zoGHHeAUCsvVeywvc 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
"OK"
We only used 4 out of 5 keys for some of you.
-
I have run about 12 hours with 2 computer,
but I still produce 0 block.
Is this correct?
my account is init-delegate-17, init-delegate-18,init-delegate-19,init-delegate-20
I see that you are producing blocks, where do you see that you produced 0?
delegate (unlocked) >>> wallet_get_account init-delegate-19
{
"index": 7,
"id": 19,
"name": "init-delegate-19",
"public_data": null,
"owner_key": "XTS5siws5HRdVw8XYjPtq1S2536ahueJXcrXsjhnk3PAffhpkYzZd",
"active_key_history": [[
"19700101T000000",
"XTS5siws5HRdVw8XYjPtq1S2536ahueJXcrXsjhnk3PAffhpkYzZd"
]
],
"delegate_info": {
"votes_for": 106446310462,
"votes_against": 0,
"blocks_produced": 0,
"blocks_missed": 3,
"pay_balance": 0,
"next_secret_hash": "0000000000000000000000000000000000000000",
"last_block_num_produced": 4294967295
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null,
"account_address": "XTSLk7fjntLStdnJPyekwnenC3HBrgaPvjjE",
"trust_level": 0,
"private_data": null
}
-
toast, I got your PM.
But I failed to import the WIF private keys.
(wallet closed) >>> wallet_create delegatewallet
new_passphrase:
new_passphrase (verify):
OK
delegatewallet (unlocked) >>> unlock 100000
passphrase:
OK
Three of them with errors like this:
delegatewallet (unlocked) >>> wallet_import_private_key 5JyfiiE2XXX
10
false: Error parsing WIF private key
{}
th_a wallet.cpp:843 import_wif_private_key
{"account_name":""}
th_a wallet.cpp:845 import_wif_private_key
{}
th_a common_api_client.cpp:212 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:576 execute_command
The other two with errors like this:
delegatewallet (unlocked) >>> wallet_import_private_key 5JCrrj3XXXX
10
registered_account: the key must belong to a registered account or an account name must be specified
{}
th_a wallet.cpp:788 import_private_key
{"account_name":""}
th_a wallet.cpp:827 import_private_key
{"account_name":""}
th_a wallet.cpp:845 import_wif_private_key
{}
th_a common_api_client.cpp:212 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:576 execute_command
-
Well looks like none of my private WIF keys are working. The public key list:
https://bitsharestalk.org/index.php?topic=4913.msg64544#msg64544
I guess missed the bus for this initial test.
Try this now.
Tried but no go. For some of the delegates now I keep getting:
10
false: Error parsing WIF private key
{}
th_a wallet.cpp:843 import_wif_private_key
{"account_name":""}
th_a wallet.cpp:845 import_wif_private_key
{}
th_a common_api_client.cpp:212 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:576 execute_command
whereas others seem to be giving the same old "registered" address error.
Are you building with the latest code? Because I updated code related to this today.
-
toast, I got your PM.
But I failed to import the WIF private keys.
try pulling/rebuilding
-
It's weired, what's the different about blockchain_get_account_record and wallet_get_accout?
delegate (unlocked) >>> blockchain_get_account_record init-delegate-20
{
"id": 20,
"name": "init-delegate-20",
"public_data": null,
"owner_key": "XTS5iUxjeTmcdb2MrZBD32n73fLP1P1gBY4peWdaj1AZ6NrbBmr3y",
"active_key_history": [[
"19700101T000000",
"XTS5iUxjeTmcdb2MrZBD32n73fLP1P1gBY4peWdaj1AZ6NrbBmr3y"
]
],
"delegate_info": {
"votes_for": 102044686731,
"votes_against": 0,
"blocks_produced": 29,
"blocks_missed": 6,
"pay_balance": 208463,
"next_secret_hash": "4bd299df1efe25d68abec47f512dcf4af813d75c",
"last_block_num_produced": 747
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null
}
delegate (unlocked) >>> wallet_get_account init-delegate-20
{
"index": 9,
"id": 20,
"name": "init-delegate-20",
"public_data": null,
"owner_key": "XTS5iUxjeTmcdb2MrZBD32n73fLP1P1gBY4peWdaj1AZ6NrbBmr3y",
"active_key_history": [[
"19700101T000000",
"XTS5iUxjeTmcdb2MrZBD32n73fLP1P1gBY4peWdaj1AZ6NrbBmr3y"
]
],
"delegate_info": {
"votes_for": 102044478268,
"votes_against": 0,
"blocks_produced": 0,
"blocks_missed": 3,
"pay_balance": 0,
"next_secret_hash": "0000000000000000000000000000000000000000",
"last_block_num_produced": 4294967295
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null,
"account_address": "XTSGCyPiFjh7GicSTQFH7oDpTSAJM6qMCAnw",
"trust_level": 0,
"private_data": null
}
I have run about 12 hours with 2 computer,
but I still produce 0 block.
Is this correct?
my account is init-delegate-17, init-delegate-18,init-delegate-19,init-delegate-20
I see that you are producing blocks, where do you see that you produced 0?
This is probably because we don't expose the delegate's pay which is separate from their normal balance. If delegates are looking for 'coinbase' transactions, they don't exist... your pay is a property of your account.
default (unlocked) >>> blockchain_get_account_record init-delegate-17
{
"id": 17,
"name": "init-delegate-17",
"public_data": null,
"owner_key": "XTS57VJ3pc85WWJWCwNzPBcwNHEqHstavbhgFfHgc8nTmCchXGJAM",
"active_key_history": [[
"19700101T000000",
"XTS57VJ3pc85WWJWCwNzPBcwNHEqHstavbhgFfHgc8nTmCchXGJAM"
]
],
"delegate_info": {
"votes_for": 91796978110,
"votes_against": 0,
"blocks_produced": 18,
"blocks_missed": 13,
"pay_balance": 80020,
"next_secret_hash": "8074d5a45dffa7031980c1188d853a514cab88c0",
"last_block_num_produced": 655
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null
}
-
^ that seems like a bug, filing now.
But you're all good as far as being a delegate
-
What are some commands that I can use to verify that my delegates are producing blocks properly and not just on it's own fork.
I used blockchain_get_blockcount which is currently showing 97
default (unlocked) >>> info
{
"blockchain_head_block_num": 1059,
"blockchain_head_block_time": "20140609T150800"
}
If you are on a fork... then we need to do a better job detecting and reporting this.
If I run 2 clients with the same wallet, the block can be sent to only one instead of both?
here is output from 1 pc
delegate (unlocked) >>> info
{
"blockchain_head_block_num": 747,
"blockchain_head_block_time": "20140609T155615",
"blockchain_confirmation_requirement": 291,
"blockchain_average_delegate_participation": 21.453187823090179,
"network_num_connections": 0,
"wallet_balance": [[
0,
"XTS"
]
],
"wallet_unlocked_seconds_remaining": 992993,
"wallet_next_block_production_time": "20140609T160515",
"wallet_seconds_until_next_block_production": 144,
"wallet_local_time": "20140609T160251",
"blockchain_random_seed": "4f6c48246305a9821a1ffb97c5179d3f5544b7c5",
"blockchain_shares": 9999976500511,
"network_num_connections_max": 12,
"network_protocol_version": 101,
"wallet_open": true,
"wallet_unlocked_until": "20140621T035244.949127",
"wallet_version": 100
}
here is another
delegate (unlocked) >>> info
{
"blockchain_head_block_num": 446,
"blockchain_head_block_time": "20140609T155845",
"blockchain_confirmation_requirement": 291,
"blockchain_average_delegate_participation": 13.440551407237219,
"network_num_connections": 0,
"wallet_balance": [[
0,
"XTS"
]
],
"wallet_unlocked_seconds_remaining": 992876,
"wallet_next_block_production_time": "20140609T160315",
"wallet_seconds_until_next_block_production": 17,
"wallet_local_time": "20140609T160258",
"blockchain_random_seed": "a7d1d2491731fe9b6c47e5967913c0aeea1a9689",
"blockchain_shares": 9999973654990,
"network_num_connections_max": 12,
"network_protocol_version": 101,
"wallet_open": true,
"wallet_unlocked_until": "20140621T035054.138282",
"wallet_version": 100
}
-
Oh no no, do NOT put your private key on two different clients or else you will cause a fork.
Shut down the one on the minority fork
What are some commands that I can use to verify that my delegates are producing blocks properly and not just on it's own fork.
I used blockchain_get_blockcount which is currently showing 97
default (unlocked) >>> info
{
"blockchain_head_block_num": 1059,
"blockchain_head_block_time": "20140609T150800"
}
If you are on a fork... then we need to do a better job detecting and reporting this.
If I run 2 clients with the same wallet, the block can be sent to only one instead of both?
here is output from 1 pc
delegate (unlocked) >>> info
{
"blockchain_head_block_num": 747,
"blockchain_head_block_time": "20140609T155615",
"blockchain_confirmation_requirement": 291,
"blockchain_average_delegate_participation": 21.453187823090179,
"network_num_connections": 0,
"wallet_balance": [[
0,
"XTS"
]
],
"wallet_unlocked_seconds_remaining": 992993,
"wallet_next_block_production_time": "20140609T160515",
"wallet_seconds_until_next_block_production": 144,
"wallet_local_time": "20140609T160251",
"blockchain_random_seed": "4f6c48246305a9821a1ffb97c5179d3f5544b7c5",
"blockchain_shares": 9999976500511,
"network_num_connections_max": 12,
"network_protocol_version": 101,
"wallet_open": true,
"wallet_unlocked_until": "20140621T035244.949127",
"wallet_version": 100
}
here is another
delegate (unlocked) >>> info
{
"blockchain_head_block_num": 446,
"blockchain_head_block_time": "20140609T155845",
"blockchain_confirmation_requirement": 291,
"blockchain_average_delegate_participation": 13.440551407237219,
"network_num_connections": 0,
"wallet_balance": [[
0,
"XTS"
]
],
"wallet_unlocked_seconds_remaining": 992876,
"wallet_next_block_production_time": "20140609T160315",
"wallet_seconds_until_next_block_production": 17,
"wallet_local_time": "20140609T160258",
"blockchain_random_seed": "a7d1d2491731fe9b6c47e5967913c0aeea1a9689",
"blockchain_shares": 9999973654990,
"network_num_connections_max": 12,
"network_protocol_version": 101,
"wallet_open": true,
"wallet_unlocked_until": "20140621T035054.138282",
"wallet_version": 100
}
-
Oh no no, do NOT put your private key on two different clients or else you will cause a fork.
Shut down the one on the minority fork
What are some commands that I can use to verify that my delegates are producing blocks properly and not just on it's own fork.
I used blockchain_get_blockcount which is currently showing 97
default (unlocked) >>> info
{
"blockchain_head_block_num": 1059,
"blockchain_head_block_time": "20140609T150800"
}
If you are on a fork... then we need to do a better job detecting and reporting this.
If I run 2 clients with the same wallet, the block can be sent to only one instead of both?
here is output from 1 pc
delegate (unlocked) >>> info
{
"blockchain_head_block_num": 747,
"blockchain_head_block_time": "20140609T155615",
"blockchain_confirmation_requirement": 291,
"blockchain_average_delegate_participation": 21.453187823090179,
"network_num_connections": 0,
"wallet_balance": [[
0,
"XTS"
]
],
"wallet_unlocked_seconds_remaining": 992993,
"wallet_next_block_production_time": "20140609T160515",
"wallet_seconds_until_next_block_production": 144,
"wallet_local_time": "20140609T160251",
"blockchain_random_seed": "4f6c48246305a9821a1ffb97c5179d3f5544b7c5",
"blockchain_shares": 9999976500511,
"network_num_connections_max": 12,
"network_protocol_version": 101,
"wallet_open": true,
"wallet_unlocked_until": "20140621T035244.949127",
"wallet_version": 100
}
here is another
delegate (unlocked) >>> info
{
"blockchain_head_block_num": 446,
"blockchain_head_block_time": "20140609T155845",
"blockchain_confirmation_requirement": 291,
"blockchain_average_delegate_participation": 13.440551407237219,
"network_num_connections": 0,
"wallet_balance": [[
0,
"XTS"
]
],
"wallet_unlocked_seconds_remaining": 992876,
"wallet_next_block_production_time": "20140609T160315",
"wallet_seconds_until_next_block_production": 17,
"wallet_local_time": "20140609T160258",
"blockchain_random_seed": "a7d1d2491731fe9b6c47e5967913c0aeea1a9689",
"blockchain_shares": 9999973654990,
"network_num_connections_max": 12,
"network_protocol_version": 101,
"wallet_open": true,
"wallet_unlocked_until": "20140621T035054.138282",
"wallet_version": 100
}
wow, I have quit one...
but do we need to fix this?
-
Fixing it would require adding logic for master/slave clients which would sync with each other and make sure not to sign the same blocks. I think that's best left as a infrastructure tool rather than building it into the client itself
-
Can I still be a delegate?
Or will be punished by the network?
What shall I do to get all blocks? I have stop one node, but the other node still can't get all blocks.
-
i was late to paticipate in initial delegates network, what a pity
-
Can I still be a delegate?
Or will be punished by the network?
What shall I do to get all blocks? I have stop one node, but the other node still can't get all blocks.
Nobody is really voting for now. If you're stuck in a bad state you could try wiping all data dirs and re-importing
-
Hi TOAST,
since only partial delegate name shows on my list, could you please how to show full delegate name on my screen.
many thanks
but not able to see full name (check in red ) under my "wallet_list_receive_accounts"
init-delega... (delegate)0.000000 XTS XTS4u3cQJNLS9jDN1mCM9ynLNHQV9PuEVfwA2R95XnV7ZDNjJL89z 2014-06-01T00:00:00 0
why only one of account "pan2pan-05" showing in my "wallet_list_receive_accounts"? I did import 5 private key to 5 accounts that I created in my wallet
pan2pan (unlocked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
pan2pan-05 0.000000 XTS XTS8T5M76CG8PFopcuSoAkvTfzkGhZMR44Dckd6JB5zYxxde1vqaU NO 0
[b][color=red]init-delega... (delegate)0.000000 XTS [/color][/b] XTS4u3cQJNLS9jDN1mCM9ynLNHQV9PuEVfwA2R95XnV7ZDNjJL89z 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS5vXkQbGLEwaye3ZsLAtMMEe6tkh724nr2zoGHHeAUCsvVeywvc 2014-06-01T00:00:00 0
init-delega... (delegate)0.000000 XTS XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
"OK"
We only used 4 out of 5 keys for some of you.
-
Hi TOAST,
since only partial delegate name shows on my list, could you please how to show full delegate name on my screen.
many thanks
The most recent build does not clip the names.
If you don't want to rebuild, you can try to find your public keys in "blockchain_list_registered_accounts init-delegate"
-
toast, I got your PM.
But I failed to import the WIF private keys.
try pulling/rebuilding
Tried. But I got errors when building
[ 96%] Building CXX object programs/client/CMakeFiles/bitshares_client.dir/main.cpp.o
Linking CXX executable bitshares_client
../../libraries/net/libbts_net.a(upnp.cpp.o): In function `operator()':
/root/bitshares_toolkit/libraries/net/upnp.cpp:78: undefined reference to `upnpDiscover'
/root/bitshares_toolkit/libraries/net/upnp.cpp:86: undefined reference to `UPNP_GetValidIGD'
/root/bitshares_toolkit/libraries/net/upnp.cpp:146: undefined reference to `freeUPNPDevlist'
/root/bitshares_toolkit/libraries/net/upnp.cpp:149: undefined reference to `FreeUPNPUrls'
/root/bitshares_toolkit/libraries/net/upnp.cpp:96: undefined reference to `UPNP_GetExternalIPAddress'
/root/bitshares_toolkit/libraries/net/upnp.cpp:125: undefined reference to `strupnperror'
/root/bitshares_toolkit/libraries/net/upnp.cpp:120: undefined reference to `UPNP_AddPortMapping'
/root/bitshares_toolkit/libraries/net/upnp.cpp:136: undefined reference to `UPNP_DeletePortMapping'
/root/bitshares_toolkit/libraries/net/upnp.cpp:138: undefined reference to `freeUPNPDevlist'
/root/bitshares_toolkit/libraries/net/upnp.cpp:139: undefined reference to `FreeUPNPUrls'
collect2: error: ld returned 1 exit status
make[2]: *** [programs/client/bitshares_client] Error 1
make[1]: *** [programs/client/CMakeFiles/bitshares_client.dir/all] Error 2
make: *** [all] Error 2
Then I wiped all the files and cloned the codes and built. But still the same.
-
Hi TOAST,
since only partial delegate name shows on my list, could you please how to show full delegate name on my screen.
many thanks
The most recent build does not clip the names.
If you don't want to rebuild, you can try to find your public keys in "blockchain_list_registered_accounts init-delegate"
This clips the names as well. I'm not on the most recent build your mentioning. Just saying.
Xeldal-1 (locked) >>> blockchain_list_registered_accounts init-delegate
NAME KEY REGISTERED VOTES FOR VOTES AGAINST TRUST LEVEL
init-delega... (delegate)XTS6TMMu8B5MBEgj2kg9pGF8dzrWBtj5CpKHHQxM3x4EsvD4mJMUK 2014-06-01T00:00:00 74723548609 0 0
init-delega... (delegate)XTS7CoMc1xHodpiVYS8gukQRhmrpxaBEz7oMaUy434HBLbJegtFo1 2014-06-01T00:00:00 93319640569 0 0
init-delega... (delegate)XTS7kcfTvho6h7juwajcNxBQA9rmiqd5iSFMZYywwbWRk9wqjo2Np 2014-06-01T00:00:00 116560455820 0 0
init-delega... (delegate)XTS6yyGEujvofqgQRfwvwWxMjZiFJwE4kBE1BpXtGpmhZ8aC58Dmb 2014-06-01T00:00:00 120331315858 0 0
init-delega... (delegate)XTS8UTxLFKWaL2aFLxhwNC9C1JnTRrtDSpKTeAvB9yqNavVfFRkQ1 2014-06-01T00:00:00 100903299852 0 0
init-delega... (delegate)XTS5LGPcabhmv2Y3rpT5YP1Ba8nUFoU1P2GFrth81Za9TFV78EjBc 2014-06-01T00:00:00 105608768061 0 0
init-delega... (delegate)XTS6s5vsTDMJm429keEXJi4RSAHhgm2mf6GGuV7LnKvZYfPMeXFS1 2014-06-01T00:00:00 111855313678 0 0
init-delega... (delegate)XTS8djaCmGAU6VhQ6Ri1VEyr187cVaYar62if72rvTtUwNkvPCvqG 2014-06-01T00:00:00 96131884568 0 0
init-delega... (delegate)XTS57VJ3pc85WWJWCwNzPBcwNHEqHstavbhgFfHgc8nTmCchXGJAM 2014-06-01T00:00:00 91796978110 0 0
init-delega... (delegate)XTS613zBdL38aPmLyMPtiTxKHnqiD7eiFZUsAFdVPzZmx4aZ8c8wq 2014-06-01T00:00:00 100667487923 0 0
init-delega... (delegate)XTS5siws5HRdVw8XYjPtq1S2536ahueJXcrXsjhnk3PAffhpkYzZd 2014-06-01T00:00:00 106446396141 0 0
init-delega... (delegate)XTS7diW1nWPWrxkwuqXkwmxFN4qrQ7jyVNcRhqGqrriVvK2udynhD 2014-06-01T00:00:00 115183230426 0 0
init-delega... (delegate)XTS5iUxjeTmcdb2MrZBD32n73fLP1P1gBY4peWdaj1AZ6NrbBmr3y 2014-06-01T00:00:00 102044553598 0 0
init-delega... (delegate)XTS6DDBA3URydxP2EPPtTwJ6JcSV28ut7ukN2HCVgrDuH4UCxF9Jv 2014-06-01T00:00:00 110816962707 0 0
init-delega... (delegate)XTS8LLDp6tZzh4bt5mBJXrigaff76xJCHzU1uqJrEryJpiZFcW3Ac 2014-06-01T00:00:00 97417056050 0 0
init-delega... (delegate)XTS7CGASnpNRTnfcqMhTTGAgbmpstVS3U3mWfHoAmwAXQaer7BvUD 2014-06-01T00:00:00 92140666100 0 0
init-delega... (delegate)XTS6o9KsYFpuPLQy9HCZGJrsxhnSFrv4DN4C3XNmb3kknFXikBBPP 2014-06-01T00:00:00 117356802345 0 0
init-delega... (delegate)XTS8ZhbpwEgwgV1gjCNrYfMDxsB6diofNtsg1m4yN62Zii1EwpK7B 2014-06-01T00:00:00 101055284674 0 0
init-delega... (delegate)XTS6qTT13ykM2kshakrFS4M4o4TcpNPhkQuV1h8dL2UJbZyQU2yMd 2014-06-01T00:00:00 86692640227 0 0
init-delega... (delegate)XTS6SoXmqo5vdHYNXvyjxUoMQjeFFj2kXQHJKG4sK1JCESdmgJ7rt 2014-06-01T00:00:00 94288288585 0 0
init-delega... (delegate)XTS5BwuZQfFMpktrVsXLUDQxgnXg3iVY4EVQMbd1Y4BNz145kQdh6 2014-06-01T00:00:00 91564354875 0 0
init-delega... (delegate)XTS5TQbUB5UBmEG9ATLBhHe1Aw4AbctmTNji5QgHv9SFXX7rJAK64 2014-06-01T00:00:00 89110673193 0 0
init-delega... (delegate)XTS7bUdQ41J4vhNVBkmbqDKGiftrmQNrL1vCx881Fg4R2hE5r6P2Z 2014-06-01T00:00:00 104224442462 0 0
init-delega... (delegate)XTS6f8fzmUDQp63nTYgsA2GQtvFoPvKrmTmuhkCvQUCnKUJwxTxtx 2014-06-01T00:00:00 95353482465 0 0
init-delega... (delegate)XTS5urryfpdjZgwavKwufJ9A1d816LFaPbSQLu5eP2G76B7hbtuxj 2014-06-01T00:00:00 114694604820 0 0
init-delega... (delegate)XTS7p56UNQLyWc3NB2yeT4VVtYhanf6wFC356c6vbfpvQ9CHUmg6X 2014-06-01T00:00:00 102159373379 0 0
... Use "blockchain_list_registered_accounts <start_name> <count>" to see more.
Xeldal-1 (locked) >>>
I used "blockchain_get_account_record init-delegate-1"
and increased the delegate-(number) until i found my XTS ownerkeys
-
I am having troubles building on two Ubuntu machines, both running 14.04. Strangely they get different errors compiling same code.
using latest git pull
machine 1
[ 96%] Building CXX object programs/client/CMakeFiles/bitshares_client.dir/main.cpp.o
Linking CXX executable bitshares_client
../../libraries/net/libbts_net.a(upnp.cpp.o): In function `operator()':
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:78: undefined reference to `upnpDiscover'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:86: undefined reference to `UPNP_GetValidIGD'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:146: undefined reference to `freeUPNPDevlist'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:149: undefined reference to `FreeUPNPUrls'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:96: undefined reference to `UPNP_GetExternalIPAddress'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:125: undefined reference to `strupnperror'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:120: undefined reference to `UPNP_AddPortMapping'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:136: undefined reference to `UPNP_DeletePortMapping'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:138: undefined reference to `freeUPNPDevlist'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:139: undefined reference to `FreeUPNPUrls'
collect2: error: ld returned 1 exit status
make[2]: *** [programs/client/bitshares_client] Error 1
make[1]: *** [programs/client/CMakeFiles/bitshares_client.dir/all] Error 2
make: *** [all] Error 2
machine 2
[ 69%] Generating include/bts/api/common_api.hpp, ../rpc_stubs/common_api_rpc_server.cpp, ../rpc_stubs/common_api_rpc_client.cpp, ../rpc_stubs/common_api_client.cpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_rpc_server.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_rpc_client.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_client.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_overrides.ipp
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted
make[2]: *** [libraries/api/include/bts/api/common_api.hpp] Error 134
make[1]: *** [libraries/api/CMakeFiles/bts_api.dir/all] Error 2
make: *** [all] Error 2
-
I am having troubles building on two Ubuntu machines, both running 14.04. Strangely they get different errors compiling same code.
on latest git pull
machine 1
[ 96%] Building CXX object programs/client/CMakeFiles/bitshares_client.dir/main.cpp.o
Linking CXX executable bitshares_client
../../libraries/net/libbts_net.a(upnp.cpp.o): In function `operator()':
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:78: undefined reference to `upnpDiscover'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:86: undefined reference to `UPNP_GetValidIGD'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:146: undefined reference to `freeUPNPDevlist'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:149: undefined reference to `FreeUPNPUrls'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:96: undefined reference to `UPNP_GetExternalIPAddress'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:125: undefined reference to `strupnperror'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:120: undefined reference to `UPNP_AddPortMapping'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:136: undefined reference to `UPNP_DeletePortMapping'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:138: undefined reference to `freeUPNPDevlist'
/home/slava/local/bitshares_toolkit/libraries/net/upnp.cpp:139: undefined reference to `FreeUPNPUrls'
collect2: error: ld returned 1 exit status
make[2]: *** [programs/client/bitshares_client] Error 1
make[1]: *** [programs/client/CMakeFiles/bitshares_client.dir/all] Error 2
make: *** [all] Error 2
Same as mine.
Related to BM's commits?
Are you building with the latest code? Because I updated code related to this today.
-
Could some of you attempt to use this API call to import your keyhotee IDs:
wallet_import_keyhotee <firstname> <middlename> <lastname> <brainkey> <keyhoteeid>
Not successful yet, seems to misunderstand "é"
-
Error during the building on the latest code.
[ 96%] Building CXX object programs/client/CMakeFiles/bitshares_client.dir/main.cpp.o
Linking CXX executable bitshares_client
../../libraries/net/libbts_net.a(upnp.cpp.o): In function `operator()':
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:78: undefined reference to `upnpDiscover'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:86: undefined reference to `UPNP_GetValidIGD'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:146: undefined reference to `freeUPNPDevlist'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:149: undefined reference to `FreeUPNPUrls'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:96: undefined reference to `UPNP_GetExternalIPAddress'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:125: undefined reference to `strupnperror'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:120: undefined reference to `UPNP_AddPortMapping'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:136: undefined reference to `UPNP_DeletePortMapping'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:138: undefined reference to `freeUPNPDevlist'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:139: undefined reference to `FreeUPNPUrls'
collect2: error: ld returned 1 exit status
make[2]: *** [programs/client/bitshares_client] Error 1
make[1]: *** [programs/client/CMakeFiles/bitshares_client.dir/all] Error 2
make: *** [all] Error 2
-
Could some of you attempt to use this API call to import your keyhotee IDs:
wallet_import_keyhotee <firstname> <middlename> <lastname> <brainkey> <keyhoteeid>
I tryed to do so. It said OK, but i didnt see any changes in wallet
-
Could some of you attempt to use this API call to import your keyhotee IDs:
wallet_import_keyhotee <firstname> <middlename> <lastname> <brainkey> <keyhoteeid>
I tryed to do so. It said OK, but i didnt see any changes in wallet
try rescan
-
I'm getting some strange results:
** Inactive:
1 init-delegate-1 0.747238 %
299 spartako 0.056 %
emski2 (unlocked) >>> blockchain_get_account_record init-delegate-1
{
"id": 1,
"name": "init-delegate-1",
"public_data": null,
"owner_key": "XTS6TMMu8B5MBEgj2kg9pGF8dzrWBtj5CpKHHQxM3x4EsvD4mJMUK",
"active_key_history": [[
"19700101T000000",
"XTS6TMMu8B5MBEgj2kg9pGF8dzrWBtj5CpKHHQxM3x4EsvD4mJMUK"
]
],
"delegate_info": {
"votes_for": 74723633553,
"votes_against": 0,
"blocks_produced": 28,
"blocks_missed": 14,
"pay_balance": 394708,
"next_secret_hash": "2933b4ccec300ee301fcbf749fc1c7f1e6df32a6",
"last_block_num_produced": 1409
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null
}
delegate1 is shown as inactive, but he produces the same amount of blocks like others.
Any other of my delegates have > 1.00 % NET VOTES. They are running on the same machine and on the same process.
All of them behave almost identically except for the low NET VOTES count on delegate1 (and it is shown as inactive while producing the same amount of blocks).
Not a question here... just reporting what it seems like strange behavior for me.
-
Could some of you attempt to use this API call to import your keyhotee IDs:
wallet_import_keyhotee <firstname> <middlename> <lastname> <brainkey> <keyhoteeid>
I tryed to do so. It said OK, but i didnt see any changes in wallet
try rescan
Did that. It should import alexxy as keyhotee id, but i already has such account
-
do i need to save my wallet if i do rebuild?
Hi TOAST,
since only partial delegate name shows on my list, could you please how to show full delegate name on my screen.
many thanks
The most recent build does not clip the names.
If you don't want to rebuild, you can try to find your public keys in "blockchain_list_registered_accounts init-delegate"
-
Error during the building on the latest code.
[ 96%] Building CXX object programs/client/CMakeFiles/bitshares_client.dir/main.cpp.o
Linking CXX executable bitshares_client
../../libraries/net/libbts_net.a(upnp.cpp.o): In function `operator()':
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:78: undefined reference to `upnpDiscover'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:86: undefined reference to `UPNP_GetValidIGD'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:146: undefined reference to `freeUPNPDevlist'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:149: undefined reference to `FreeUPNPUrls'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:96: undefined reference to `UPNP_GetExternalIPAddress'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:125: undefined reference to `strupnperror'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:120: undefined reference to `UPNP_AddPortMapping'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:136: undefined reference to `UPNP_DeletePortMapping'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:138: undefined reference to `freeUPNPDevlist'
/root/bitsharesX/bitshares_toolkit/libraries/net/upnp.cpp:139: undefined reference to `FreeUPNPUrls'
collect2: error: ld returned 1 exit status
make[2]: *** [programs/client/bitshares_client] Error 1
make[1]: *** [programs/client/CMakeFiles/bitshares_client.dir/all] Error 2
make: *** [all] Error 2
fixed now, pull & rebuild
-
do i need to save my wallet if i do rebuild?
Hi TOAST,
since only partial delegate name shows on my list, could you please how to show full delegate name on my screen.
many thanks
The most recent build does not clip the names.
If you don't want to rebuild, you can try to find your public keys in "blockchain_list_registered_accounts init-delegate"
nope
-
blockchain_list_registered_accounts init-delegate clip the name as well
do i need to save my wallet if i do rebuild?
Hi TOAST,
since only partial delegate name shows on my list, could you please how to show full delegate name on my screen.
many thanks
nope
The most recent build does not clip the names.
If you don't want to rebuild, you can try to find your public keys in "blockchain_list_registered_accounts init-delegate"
-
Hi TOAST,
since only partial delegate name shows on my list, could you please how to show full delegate name on my screen.
many thanks
The most recent build does not clip the names.
If you don't want to rebuild, you can try to find your public keys in "blockchain_list_registered_accounts init-delegate"
This clips the names as well. I'm not on the most recent build your mentioning. Just saying.
Xeldal-1 (locked) >>> blockchain_list_registered_accounts init-delegate
NAME KEY REGISTERED VOTES FOR VOTES AGAINST TRUST LEVEL
init-delega... (delegate)XTS6TMMu8B5MBEgj2kg9pGF8dzrWBtj5CpKHHQxM3x4EsvD4mJMUK 2014-06-01T00:00:00 74723548609 0 0
init-delega... (delegate)XTS7CoMc1xHodpiVYS8gukQRhmrpxaBEz7oMaUy434HBLbJegtFo1 2014-06-01T00:00:00 93319640569 0 0
init-delega... (delegate)XTS7kcfTvho6h7juwajcNxBQA9rmiqd5iSFMZYywwbWRk9wqjo2Np 2014-06-01T00:00:00 116560455820 0 0
init-delega... (delegate)XTS6yyGEujvofqgQRfwvwWxMjZiFJwE4kBE1BpXtGpmhZ8aC58Dmb 2014-06-01T00:00:00 120331315858 0 0
init-delega... (delegate)XTS8UTxLFKWaL2aFLxhwNC9C1JnTRrtDSpKTeAvB9yqNavVfFRkQ1 2014-06-01T00:00:00 100903299852 0 0
init-delega... (delegate)XTS5LGPcabhmv2Y3rpT5YP1Ba8nUFoU1P2GFrth81Za9TFV78EjBc 2014-06-01T00:00:00 105608768061 0 0
init-delega... (delegate)XTS6s5vsTDMJm429keEXJi4RSAHhgm2mf6GGuV7LnKvZYfPMeXFS1 2014-06-01T00:00:00 111855313678 0 0
init-delega... (delegate)XTS8djaCmGAU6VhQ6Ri1VEyr187cVaYar62if72rvTtUwNkvPCvqG 2014-06-01T00:00:00 96131884568 0 0
init-delega... (delegate)XTS57VJ3pc85WWJWCwNzPBcwNHEqHstavbhgFfHgc8nTmCchXGJAM 2014-06-01T00:00:00 91796978110 0 0
init-delega... (delegate)XTS613zBdL38aPmLyMPtiTxKHnqiD7eiFZUsAFdVPzZmx4aZ8c8wq 2014-06-01T00:00:00 100667487923 0 0
init-delega... (delegate)XTS5siws5HRdVw8XYjPtq1S2536ahueJXcrXsjhnk3PAffhpkYzZd 2014-06-01T00:00:00 106446396141 0 0
init-delega... (delegate)XTS7diW1nWPWrxkwuqXkwmxFN4qrQ7jyVNcRhqGqrriVvK2udynhD 2014-06-01T00:00:00 115183230426 0 0
init-delega... (delegate)XTS5iUxjeTmcdb2MrZBD32n73fLP1P1gBY4peWdaj1AZ6NrbBmr3y 2014-06-01T00:00:00 102044553598 0 0
init-delega... (delegate)XTS6DDBA3URydxP2EPPtTwJ6JcSV28ut7ukN2HCVgrDuH4UCxF9Jv 2014-06-01T00:00:00 110816962707 0 0
init-delega... (delegate)XTS8LLDp6tZzh4bt5mBJXrigaff76xJCHzU1uqJrEryJpiZFcW3Ac 2014-06-01T00:00:00 97417056050 0 0
init-delega... (delegate)XTS7CGASnpNRTnfcqMhTTGAgbmpstVS3U3mWfHoAmwAXQaer7BvUD 2014-06-01T00:00:00 92140666100 0 0
init-delega... (delegate)XTS6o9KsYFpuPLQy9HCZGJrsxhnSFrv4DN4C3XNmb3kknFXikBBPP 2014-06-01T00:00:00 117356802345 0 0
init-delega... (delegate)XTS8ZhbpwEgwgV1gjCNrYfMDxsB6diofNtsg1m4yN62Zii1EwpK7B 2014-06-01T00:00:00 101055284674 0 0
init-delega... (delegate)XTS6qTT13ykM2kshakrFS4M4o4TcpNPhkQuV1h8dL2UJbZyQU2yMd 2014-06-01T00:00:00 86692640227 0 0
init-delega... (delegate)XTS6SoXmqo5vdHYNXvyjxUoMQjeFFj2kXQHJKG4sK1JCESdmgJ7rt 2014-06-01T00:00:00 94288288585 0 0
init-delega... (delegate)XTS5BwuZQfFMpktrVsXLUDQxgnXg3iVY4EVQMbd1Y4BNz145kQdh6 2014-06-01T00:00:00 91564354875 0 0
init-delega... (delegate)XTS5TQbUB5UBmEG9ATLBhHe1Aw4AbctmTNji5QgHv9SFXX7rJAK64 2014-06-01T00:00:00 89110673193 0 0
init-delega... (delegate)XTS7bUdQ41J4vhNVBkmbqDKGiftrmQNrL1vCx881Fg4R2hE5r6P2Z 2014-06-01T00:00:00 104224442462 0 0
init-delega... (delegate)XTS6f8fzmUDQp63nTYgsA2GQtvFoPvKrmTmuhkCvQUCnKUJwxTxtx 2014-06-01T00:00:00 95353482465 0 0
init-delega... (delegate)XTS5urryfpdjZgwavKwufJ9A1d816LFaPbSQLu5eP2G76B7hbtuxj 2014-06-01T00:00:00 114694604820 0 0
init-delega... (delegate)XTS7p56UNQLyWc3NB2yeT4VVtYhanf6wFC356c6vbfpvQ9CHUmg6X 2014-06-01T00:00:00 102159373379 0 0
... Use "blockchain_list_registered_accounts <start_name> <count>" to see more.
Xeldal-1 (locked) >>>
I used "blockchain_get_account_record init-delegate-1"
and increased the delegate-(number) until i found my XTS ownerkeys
-
importing wif keys doesnt work
false: Error parsing WIF private key
{}
th_a wallet.cpp:843 import_wif_private_key
{"account_name":""}
th_a wallet.cpp:845 import_wif_private_key
{}
th_a common_api_client.cpp:222 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:576 execute_command
EDIT: actualy it import key, but show this error
-
importing wif keys doesnt work
false: Error parsing WIF private key
{}
th_a wallet.cpp:843 import_wif_private_key
{"account_name":""}
th_a wallet.cpp:845 import_wif_private_key
{}
th_a common_api_client.cpp:222 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:576 execute_command
EDIT: actualy it import key, but show this error
bytemaster fixed that issue earlier today ... see above
Just recompile or do as I stated above (somewhere)
-
Could some of you attempt to use this API call to import your keyhotee IDs:
wallet_import_keyhotee <firstname> <middlename> <lastname> <brainkey> <keyhoteeid>
I tryed to do so. It said OK, but i didnt see any changes in wallet
try rescan
Did that. It should import alexxy as keyhotee id, but i already has such account
It was a bug to allow you to even create the account when one with that name was already registered. You'll probably have to wipe your wallet and then import your key again
-
importing wif keys doesnt work
false: Error parsing WIF private key
{}
th_a wallet.cpp:843 import_wif_private_key
{"account_name":""}
th_a wallet.cpp:845 import_wif_private_key
{}
th_a common_api_client.cpp:222 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:576 execute_command
EDIT: actualy it import key, but show this error
bytemaster fixed that issue earlier today ... see above
Just recompile or do as I stated above (somewhere)
Its on client build from git commit 91d857e916a4d8f9c54b11242ef86501a4a67af3
so its recompiled one
-
Could some of you attempt to use this API call to import your keyhotee IDs:
wallet_import_keyhotee <firstname> <middlename> <lastname> <brainkey> <keyhoteeid>
I tryed to do so. It said OK, but i didnt see any changes in wallet
try rescan
Did that. It should import alexxy as keyhotee id, but i already has such account
It was a bug to allow you to even create the account when one with that name was already registered. You'll probably have to wipe your wallet and then import your key again
Already tryed that. But it doesnt allow ti import keyhotee then. Saying that i should create account first
-
Could some of you attempt to use this API call to import your keyhotee IDs:
wallet_import_keyhotee <firstname> <middlename> <lastname> <brainkey> <keyhoteeid>
I tryed to do so. It said OK, but i didnt see any changes in wallet
try rescan
Did that. It should import alexxy as keyhotee id, but i already has such account
It was a bug to allow you to even create the account when one with that name was already registered. You'll probably have to wipe your wallet and then import your key again
Already tryed that. But it doesnt allow ti import keyhotee then. Saying that i should create account first
That is also a bug =P
filing now
-
"blocks_produced": 1,
"blocks_missed": 12,
"pay_balance": 2582,
pan2pan (locked) >>> wallet_get_account init-delegate-5
{
"index": 5,
"id": 5,
"name": "init-delegate-5",
"public_data": null,
"owner_key": "XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE",
"active_key_history": [[
"19700101T000000",
"XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE"
]
],
"delegate_info": {
"votes_for": 105200579812,
"votes_against": 0,
"blocks_produced": 1,
"blocks_missed": 12,
"pay_balance": 2582,
"next_secret_hash": "06f80f24eed63854c49fbaf0769268815c81f94c",
"last_block_num_produced": 148
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null,
"account_address": "XTSDF8yKeZHAMeJbTM9YtGRaoMUXR1bUECWD",
"trust_level": 0,
"private_data": null
}
-
I have found the 4 accounts
They are init-delegate-30 init-delegate-31 init-delegate-32 init-delegate-33.
And I check it with the command as follow, are they working well now?
welk1n (unlocked) >>> blockchain_get_account_record init-delegate-30
{
"id": 30,
"name": "init-delegate-30",
"public_data": null,
"owner_key": "XTS6f8fzmUDQp63nTYgsA2GQtvFoPvKrmTmuhkCvQUCnKUJwxTxtx",
"active_key_history": [[
"19700101T000000",
"XTS6f8fzmUDQp63nTYgsA2GQtvFoPvKrmTmuhkCvQUCnKUJwxTxtx"
]
],
"delegate_info": {
"votes_for": 95353683578,
"votes_against": 0,
"blocks_produced": 36,
"blocks_missed": 11,
"pay_balance": 504042,
"next_secret_hash": "f80e9fc97861a1c41c642065bdacef79627190c9",
"last_block_num_produced": 1553
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null
}
welk1n (unlocked) >>> blockchain_get_account_record init-delegate-31
{
"id": 31,
"name": "init-delegate-31",
"public_data": null,
"owner_key": "XTS5urryfpdjZgwavKwufJ9A1d816LFaPbSQLu5eP2G76B7hbtuxj",
"active_key_history": [[
"19700101T000000",
"XTS5urryfpdjZgwavKwufJ9A1d816LFaPbSQLu5eP2G76B7hbtuxj"
]
],
"delegate_info": {
"votes_for": 114694827064,
"votes_against": 0,
"blocks_produced": 38,
"blocks_missed": 10,
"pay_balance": 543807,
"next_secret_hash": "8f90fc58b18a207ef2cae267c2ecfe95d05829f6",
"last_block_num_produced": 1556
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null
}
-
importing wif keys doesnt work
false: Error parsing WIF private key
{}
th_a wallet.cpp:843 import_wif_private_key
{"account_name":""}
th_a wallet.cpp:845 import_wif_private_key
{}
th_a common_api_client.cpp:222 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:576 execute_command
EDIT: actualy it import key, but show this error
bytemaster fixed that issue earlier today ... see above
Just recompile or do as I stated above (somewhere)
Its on client build from git commit 91d857e916a4d8f9c54b11242ef86501a4a67af3
so its recompiled one
Would you please pull and try again? The Keyhotee imported info should be the same with you foundation registered, if you are importing a founder ID in genesis block.
-
Getting segfault on import of the keys I gave in the previous thread... All of the 5 give me a segfault.
https://github.com/BitShares/bitshares_toolkit/issues/253
-
Is anyone running their delegate on Digital Ocean servers?
-
I guess I'm on a fork as I can see that I'm the only delegate generating blocks.
get_info
{
"blockchain_head_block_num": 962,
"blockchain_head_block_time": "20140609T214430",
"blockchain_confirmation_requirement": 291,
"blockchain_average_delegate_participation": 19.696969696969695,
"network_num_connections": 7,
"wallet_unlocked_seconds_remaining": 9999999343,
"wallet_next_block_production_time": "20140609T215515",
"wallet_seconds_until_next_block_production": 119,
"wallet_local_time": "20140609T215316",
"blockchain_random_seed": "3a3a9e5f0ac5b5ebbfa4aeb0294a0c152af8efad",
"blockchain_shares": 9999979523473,
"network_num_connections_max": 12,
"network_protocol_version": 101,
"wallet_open": true,
"wallet_unlocked_until": "20181223T045058.320125",
"wallet_version": 100
}
I have below logs, does that prevent me connecting to other normal nodes?
3208214ms th_a p2p_network_connect_ ] I don't need any more connections, waiting forever until something changes node.cpp:684
3208214ms th_a bind ] Exception binding outgoing connection to desired local endpoint: bind: Address already in use tcp_socket.cpp:105
3208214ms th_a connect_to ] Failed to bind to desired local endpoint 0.0.0.0:45410, will connect using an OS-selected endpoint: {"code":0,"name":"exception","message":"unspecified","stack":[{"context":{"level":"error","file":"tcp_socket.cpp","line":106,"method":"bind","hostname":"","thread_name":"th_a","timestamp":"20140609T215328.214711"},"format":"error binding to ${endpoint}: ${what}","data":{"endpoint":"0.0.0.0:45410","what":"bind: Address already in use"}}]} node.cpp:483
Edit:
I started the client with --clear-peer-database and --resync-blockchain and got the similar but the block size is 422 and blockchain_get_config is like below:
blockchain_get_config
{
"blockchain_id": "964b38343dc7337f8d87a16323faaa7c63b95160c73739c6d0a276ef41f37312",
"block_interval": 15,
"max_block_size": 104857,
"target_block_size": 52428,
"block_reward": "0.104857 XTS",
"inactivity_fee_apr": 10,
"max_blockchain_size": 107374182400,
"symbol": "XTS",
"name": "BitShares XTS",
"version": 101,
"address_prefix": "XTS",
"min_block_fee": 1,
"delegate_num": 97,
"delegate_reg_fee": 10485700,
"delegate_reward_min": 104857,
"name_size_max": 63,
"symbol_size_max": 5,
"symbol_size_min": 3,
"data_size_max": 65536,
"asset_reg_fee": 10485700,
"asset_shares_max": 1000000000000000
}
I can see logs getting fork and switching but failed.
1861246ms th_a handle_message ] CLIENT: just received block 082e59b67949339ddaed7354ceadb965f9713f4b client.cpp:461
1861246ms th_a on_new_block ] Received block 1754 from the server, current head block is 427 client.cpp:421
1861246ms th_a store_and_index ] we already know about its previous: f38c12564894e1ac0deee676bd91b7ff957ddf97 chain_database.cpp:355
1861246ms th_a switch_to_fork ] switch from fork b7ea78344a5056476537428623d00899a3cead7d to 082e59b67949339ddaed7354ceadb965f9713f4b chain_database.cpp:425
1861246ms th_a get_fork_history ] chain_database.cpp:704
...
1861261ms th_a push_block ] attempt to switch to fork failed: 13
bad_weak_ptr:
{"what":"bad_weak_ptr"}
th_a chain_database.cpp:756 pop_block
{"block_id":"082e59b67949339ddaed7354ceadb965f9713f4b"}
th_a chain_database.cpp:438 switch_to_fork, reverting chain_database.cpp:1003
-
Can I still be a delegate?
Or will be punished by the network?
What shall I do to get all blocks? I have stop one node, but the other node still can't get all blocks.
Nobody is really voting for now. If you're stuck in a bad state you could try wiping all data dirs and re-importing
I mean if I make a fork, So I am a cheatting delegate
the other nodes should deny me automatic.
Did this work?
-
Can I still be a delegate?
Or will be punished by the network?
What shall I do to get all blocks? I have stop one node, but the other node still can't get all blocks.
Nobody is really voting for now. If you're stuck in a bad state you could try wiping all data dirs and re-importing
I mean if I make a fork, So I am a cheatting delegate
the other nodes should deny me automatic.
Did this work?
Nope. Also just having a fork is not auto-fire condition I would think - signing two blocks is.
-
Just rebuilt, now I'm getting an error importing private key
Xeldal-1 (unlocked) >>> wallet_import_private_key 5xxxxxWIF-Private-keyxxxxxxxxxxxxxxxx
10
false: Error parsing WIF private key
{}
th_a wallet.cpp:846 import_wif_private_key
{"account_name":""}
th_a wallet.cpp:848 import_wif_private_key
{}
th_a common_api_client.cpp:222 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:576 execute_command
Xeldal-1 (unlocked) >>>
-
I received PM with a message that at least some of my delegate keys were included in initial delegate list. I rebuilt following instructions from
https://github.com/BitShares/bitshares_toolkit/wiki/DPOS-initial-delegate-setup
and tried importing my keys. Getting errors on all 5. On first I get this error:
default (unlocked) >>> wallet_import_private_key <private key WIF format>
10
registered_account: the key must belong to a registered account or an account name must be specified
{}
th_a wallet.cpp:791 import_private_key
{"account_name":""}
th_a wallet.cpp:830 import_private_key
{"account_name":""}
th_a wallet.cpp:848 import_wif_private_key
{}
th_a common_api_client.cpp:222 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:576 execute_command
On the other 4 keys I get this error:
default (unlocked) >>> wallet_import_private_key <key goes here>
10
false: Error parsing WIF private key
{}
th_a wallet.cpp:846 import_wif_private_key
{"account_name":""}
th_a wallet.cpp:848 import_wif_private_key
{}
th_a common_api_client.cpp:222 wallet_import_private_key
{"command":"wallet_import_private_key"}
th_a cli.cpp:576 execute_command
-
@Xeldal and @bitcoinerS
I also had such "Error parsing WIF private key" errors. But if you get positive output using command wallet_list_receive_accounts, that means they've already got imported. My delegates are working now.
Positive output like this:
NAME BALANCE KEY REGISTERED TRUST LEVEL
init-delegate-NUMBER (delegate) 0.000000 XTS XTS5HHx85ASdW3b4UmyV8g2rLyYRXXXX 2014-06-01T00:00:00 0
init-delegate-NUMBER (delegate) 0.000000 XTS XTS5K6TmQjqReTUhWMg3EBjQ26VBXXXX 2014-06-01T00:00:00 0
init-delegate-NUMBER (delegate) 0.000000 XTS XTS5Q7j3ZAYwjGAuK6AfWiqDuahnahXXXX 2014-06-01T00:00:00 0
-
@Xeldal and @bitcoinerS
I also had such "Error parsing WIF private key" errors. But if you get positive output using command wallet_list_receive_accounts, that means they've already got imported. My delegates are working now.
Positive output like this:
NAME BALANCE KEY REGISTERED TRUST LEVEL
init-delegate-NUMBER (delegate) 0.000000 XTS XTS5HHx85ASdW3b4UmyV8g2rLyYRXXXX 2014-06-01T00:00:00 0
init-delegate-NUMBER (delegate) 0.000000 XTS XTS5K6TmQjqReTUhWMg3EBjQ26VBXXXX 2014-06-01T00:00:00 0
init-delegate-NUMBER (delegate) 0.000000 XTS XTS5Q7j3ZAYwjGAuK6AfWiqDuahnahXXXX 2014-06-01T00:00:00 0
I tried and get a new error:
wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
init-delegate-9 (delegate) 10
war.valid(): Unable to find Wallet Account 'init-delegate-9'
{"account_name":"init-delegate-9"}
th_a wallet.cpp:2086 get_balances
{"symbol":"XTS","account_name":"init-delegate-9"}
th_a wallet.cpp:2114 get_balances
-
@Xeldal and @bitcoinerS
I also had such "Error parsing WIF private key" errors. But if you get positive output using command wallet_list_receive_accounts, that means they've already got imported. My delegates are working now.
Positive output like this:
NAME BALANCE KEY REGISTERED TRUST LEVEL
init-delegate-NUMBER (delegate) 0.000000 XTS XTS5HHx85ASdW3b4UmyV8g2rLyYRXXXX 2014-06-01T00:00:00 0
init-delegate-NUMBER (delegate) 0.000000 XTS XTS5K6TmQjqReTUhWMg3EBjQ26VBXXXX 2014-06-01T00:00:00 0
init-delegate-NUMBER (delegate) 0.000000 XTS XTS5Q7j3ZAYwjGAuK6AfWiqDuahnahXXXX 2014-06-01T00:00:00 0
Strange. so the errors are bogus? or at least don't effect some proper function.?
I got the same thing. Positive results from "wallet_list_receive_accounts" and "wallet_get_account init-delegate-N"
Thanks.
-
I delete the .BitsharesXTS, open a new client just now.
But this node seems sync with a wrong fork. How to going on?
Maybe the logic of hanle with the fork event is not finish?
default (unlocked) >>> info
{
"blockchain_head_block_num": 460,
"blockchain_head_block_time": "20140610T003915",
"blockchain_confirmation_requirement": 291,
"blockchain_average_delegate_participation": 8.2407739161590836,
"network_num_connections": 8,
"wallet_unlocked_seconds_remaining": 0,
"wallet_next_block_production_time": null,
"wallet_seconds_until_next_block_production": null,
"wallet_local_time": "20140610T004748",
"blockchain_random_seed": "90f5d2fcf7bbe40afdeaf8b04a624f71d65d4697",
"blockchain_shares": 9999973591766,
"network_num_connections_max": 12,
"network_protocol_version": 101,
"wallet_open": true,
"wallet_unlocked_until": "19700101T000000",
"wallet_version": 100
}
-
Is anyone running their delegate on Digital Ocean servers?
I am
-
After latest git pull things are starting to work.
I was able to import 4 of my delegate private keys. However I am not seeing these delegates among receive accounts..
These accounts show up, but these are not public keys that correspond to my imported private keys.
wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
init-delegate-9 (delegate) XTS6sSu1DhZUxpnoLz1wYvwsowUQpa4zyHFkqo972fKnU6xrEKVx8 2014-06-01T00:00:00 0
init-delegate-7 (delegate) XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delegate-5 (delegate) XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
init-delegate-3 (delegate) XTS7bUdQ41J4vhNVBkmbqDKGiftrmQNrL1vCx881Fg4R2hE5r6P2Z 2014-06-01T00:00:00 0
"OK"
My public keys are:
XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z
XTS72Xc5wBYmWQrAqcPoU6RSEegB3CosNh82wbf4QkKquJtbhgPWL
XTS7DeMWhGV8P7oiKoigtGqFKDfauB83Nrxy5FpMwLEjMw7wC8UVe
XTS73iK3RkkijdfgzH5mioB4wzWFNsmsvwtsNPnkoHAApHK6cbMz3
Am I missing something?
-
look like we are sharing "init-delegate-5 (delegate) " and "init-delegate-7 (delegate)"
anyone can explain it ? must be a bug..... how can we both have the same keys in different wallet
wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
pan2pan-05 0.000000 XTS XTS8T5M76CG8PFopcuSoAkvTfzkGhZMR44Dckd6JB5zYxxde1vqaU NO 0
init-delegate-8 (delegate) 0.000000 XTS XTS4u3cQJNLS9jDN1mCM9ynLNHQV9PuEVfwA2R95XnV7ZDNjJL89z 2014-06-01T00:00:00 0
init-delegate-7 (delegate) 0.000000 XTS XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delegate-6 (delegate) 0.000000 XTS XTS5vXkQbGLEwaye3ZsLAtMMEe6tkh724nr2zoGHHeAUCsvVeywvc 2014-06-01T00:00:00 0
init-delegate-5 (delegate) 0.000000 XTS XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
After latest git pull things are starting to work.
I was able to import 4 of my delegate private keys. However I am not seeing these delegates among receive accounts..
These accounts show up, but these are not public keys that correspond to my imported private keys.
wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
init-delegate-9 (delegate) XTS6sSu1DhZUxpnoLz1wYvwsowUQpa4zyHFkqo972fKnU6xrEKVx8 2014-06-01T00:00:00 0
init-delegate-7 (delegate) XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delegate-5 (delegate) XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
init-delegate-3 (delegate) XTS7bUdQ41J4vhNVBkmbqDKGiftrmQNrL1vCx881Fg4R2hE5r6P2Z 2014-06-01T00:00:00 0
"OK"
My public keys are:
XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z
XTS72Xc5wBYmWQrAqcPoU6RSEegB3CosNh82wbf4QkKquJtbhgPWL
XTS7DeMWhGV8P7oiKoigtGqFKDfauB83Nrxy5FpMwLEjMw7wC8UVe
XTS73iK3RkkijdfgzH5mioB4wzWFNsmsvwtsNPnkoHAApHK6cbMz3
Am I missing something?
-
look like we are sharing "init-delegate-5 (delegate) " and "init-delegate-7 (delegate)"
anyone can explain it ? must be a bug..... how can we both have the same keys in different wallet
:o
...
:'(
and that is why we are having Sergio do an audit...
-
that is bizarre because we are using openssl which seeds the PRNG internally
-
look like we are sharing "init-delegate-5 (delegate) " and "init-delegate-7 (delegate)"
anyone can explain it ? must be a bug..... how can we both have the same keys in different wallet
wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
pan2pan-05 0.000000 XTS XTS8T5M76CG8PFopcuSoAkvTfzkGhZMR44Dckd6JB5zYxxde1vqaU NO 0
init-delegate-8 (delegate) 0.000000 XTS XTS4u3cQJNLS9jDN1mCM9ynLNHQV9PuEVfwA2R95XnV7ZDNjJL89z 2014-06-01T00:00:00 0
init-delegate-7 (delegate) 0.000000 XTS XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delegate-6 (delegate) 0.000000 XTS XTS5vXkQbGLEwaye3ZsLAtMMEe6tkh724nr2zoGHHeAUCsvVeywvc 2014-06-01T00:00:00 0
init-delegate-5 (delegate) 0.000000 XTS XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
After latest git pull things are starting to work.
I was able to import 4 of my delegate private keys. However I am not seeing these delegates among receive accounts..
These accounts show up, but these are not public keys that correspond to my imported private keys.
wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
init-delegate-9 (delegate) XTS6sSu1DhZUxpnoLz1wYvwsowUQpa4zyHFkqo972fKnU6xrEKVx8 2014-06-01T00:00:00 0
init-delegate-7 (delegate) XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delegate-5 (delegate) XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
init-delegate-3 (delegate) XTS7bUdQ41J4vhNVBkmbqDKGiftrmQNrL1vCx881Fg4R2hE5r6P2Z 2014-06-01T00:00:00 0
"OK"
My public keys are:
XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z
XTS72Xc5wBYmWQrAqcPoU6RSEegB3CosNh82wbf4QkKquJtbhgPWL
XTS7DeMWhGV8P7oiKoigtGqFKDfauB83Nrxy5FpMwLEjMw7wC8UVe
XTS73iK3RkkijdfgzH5mioB4wzWFNsmsvwtsNPnkoHAApHK6cbMz3
Am I missing something?
Me too
-
Can you both PM me your private keys for delegates 5 and 7? We can't use them in the real deal anyway.
Want to make sure they are the same and not just a UI bug.
-
that is bizarre because we are using openssl which seeds the PRNG internally
just let me know if you need any detail log for investigation
-
My real public keys, and I have found the account are init-delegate-30 init-delegate-31 init-delegate-32 init-delegate-33
welk1n-d-1:XTS6f8fzmUDQp63nTYgsA2GQtvFoPvKrmTmuhkCvQUCnKUJwxTxtx
welk1n-d-2:XTS5urryfpdjZgwavKwufJ9A1d816LFaPbSQLu5eP2G76B7hbtuxj
welk1n-d-3:XTS7p56UNQLyWc3NB2yeT4VVtYhanf6wFC356c6vbfpvQ9CHUmg6X
welk1n-d-4:XTS7SDs7tmoYe96wjRzYqavAu4nehaMUTh3TbkGe9EPWNbA1P2XPA
welk1n-d-5:XTS6z7aMnBmXi7qL9uHfgWS6d1wedEpvQNTrwgeGb8h1MH9WVXtRC
After the latest compiled project , and run it.
welk1n (unlocked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
init-delegate-12 (delegate) XTS6yyGEujvofqgQRfwvwWxMjZiFJwE4kBE1BpXtGpmhZ8aC58Dmb 2014-06-01T00:00:00 0
init-delegate-10 (delegate) XTS7CoMc1xHodpiVYS8gukQRhmrpxaBEz7oMaUy434HBLbJegtFo1 2014-06-01T00:00:00 0
init-delegate-8 (delegate) XTS4u3cQJNLS9jDN1mCM9ynLNHQV9PuEVfwA2R95XnV7ZDNjJL89z 2014-06-01T00:00:00 0
init-delegate-6 (delegate) XTS5vXkQbGLEwaye3ZsLAtMMEe6tkh724nr2zoGHHeAUCsvVeywvc 2014-06-01T00:00:00 0
init-delegate-4 (delegate) XTS6XtS7F5Fy3dUVSUKHJHN1dC66VaruRFkKmo8um6QB24Xsf2mzF 2014-06-01T00:00:00 0
"OK"
-
Ok looks like the code is in a bad state and "claiming" the wrong accounts... Your delegates still cannot sign for these wrong keys and so it should be fine to just keep stuff running.
Get back to you soon (might be tomorrow morning)
-
Can you both PM me your private keys for delegates 5 and 7? We can't use them in the real deal anyway.
Want to make sure they are the same and not just a UI bug.
These are not my keys. They just show up instead of the ones I imported.
This is what shows up
init-delegate-13 (delegate) XTS8UTxLFKWaL2aFLxhwNC9C1JnTRrtDSpKTeAvB9yqNavVfFRkQ1 2014-06-01T00:00:00 0
init-delegate-9 (delegate) XTS6sSu1DhZUxpnoLz1wYvwsowUQpa4zyHFkqo972fKnU6xrEKVx8 2014-06-01T00:00:00 0
init-delegate-7 (delegate) XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delegate-5 (delegate) XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
init-delegate-3 (delegate) XTS7bUdQ41J4vhNVBkmbqDKGiftrmQNrL1vCx881Fg4R2hE5r6P2Z 2014-06-01T00:00:00 0
These are the keys I imported:
XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z
XTS72Xc5wBYmWQrAqcPoU6RSEegB3CosNh82wbf4QkKquJtbhgPWL
XTS7DeMWhGV8P7oiKoigtGqFKDfauB83Nrxy5FpMwLEjMw7wC8UVe
XTS73iK3RkkijdfgzH5mioB4wzWFNsmsvwtsNPnkoHAApHK6cbMz3
-
Ok people who were importing others' keys:
I think we fixed it, wipe your data dir and re-import.
-
I guess I'm on a fork as I can see that I'm the only delegate generating blocks.
get_info
{
"blockchain_head_block_num": 962,
"blockchain_head_block_time": "20140609T214430",
"blockchain_confirmation_requirement": 291,
"blockchain_average_delegate_participation": 19.696969696969695,
"network_num_connections": 7,
"wallet_unlocked_seconds_remaining": 9999999343,
"wallet_next_block_production_time": "20140609T215515",
"wallet_seconds_until_next_block_production": 119,
"wallet_local_time": "20140609T215316",
"blockchain_random_seed": "3a3a9e5f0ac5b5ebbfa4aeb0294a0c152af8efad",
"blockchain_shares": 9999979523473,
"network_num_connections_max": 12,
"network_protocol_version": 101,
"wallet_open": true,
"wallet_unlocked_until": "20181223T045058.320125",
"wallet_version": 100
}
...
I guess I'm on a fork too.
tao (unlocked) >>> get_info
{
"blockchain_head_block_num": 217,
"blockchain_head_block_time": "20140610T034415",
"blockchain_confirmation_requirement": 291,
"blockchain_average_delegate_participation": 3.4504690729845762,
"network_num_connections": 1,
"wallet_balance": [[
0,
"XTS"
]
],
"wallet_unlocked_seconds_remaining": 9927654,
"wallet_next_block_production_time": "20140610T034530",
"wallet_seconds_until_next_block_production": 50,
"wallet_local_time": "20140610T034440",
"blockchain_random_seed": "d9f9c3801b1e1059decceebf9f8cb06132f1866b",
"blockchain_shares": 9999972116859,
"network_num_connections_max": 12,
"network_protocol_version": 101,
"wallet_open": true,
"wallet_unlocked_until": "20141003T012534.456867",
"wallet_version": 100
}
produce block is OK.
{
"id": 50,
"name": "init-delegate-50",
"public_data": null,
"owner_key": "XTS7xQtXcZuNn5RgyPdvtfsYAJXS8bysihvrCsvuNC6twdRNxPFA7",
"active_key_history": [[
"19700101T000000",
"XTS7xQtXcZuNn5RgyPdvtfsYAJXS8bysihvrCsvuNC6twdRNxPFA7"
]
],
"delegate_info": {
"votes_for": 100886340227,
"votes_against": 0,
"blocks_produced": 50,
"blocks_missed": 14,
"pay_balance": 103238,
"next_secret_hash": "fb447a2daf3892e83e510d21522658369ec92911",
"last_block_num_produced": 218
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null
}
tao (unlocked) >>> blockchain_get_account_record init-delegate-51
{
"id": 51,
"name": "init-delegate-51",
"public_data": null,
"owner_key": "XTS8NY1vLakvjzdJHmcia3CByapQJZCnNdk6hLMd1numLck6Tc9oc",
"active_key_history": [[
"19700101T000000",
"XTS8NY1vLakvjzdJHmcia3CByapQJZCnNdk6hLMd1numLck6Tc9oc"
]
],
"delegate_info": {
"votes_for": 98724719955,
"votes_against": 0,
"blocks_produced": 49,
"blocks_missed": 16,
"pay_balance": 102108,
"next_secret_hash": "fb3b57c09856f73b740c82f198dfa56ee3568d73",
"last_block_num_produced": 215
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null
}
-
My delegates were fine in the beginning.
But after I close and reopen the wallet, they become other's Keys:
init-delegate-9 (delegate) XTS6sSu1DhZUxpnoLz1wYvwsowUQpa4zyHFkqo972fKnU6xrEKVx8 2014-06-01T00:00:00 0
init-delegate-7 (delegate) XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delegate-5 (delegate) XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
init-delegate-3 (delegate) XTS7bUdQ41J4vhNVBkmbqDKGiftrmQNrL1vCx881Fg4R2hE5r6P2Z 2014-06-01T00:00:00 0
-
Ok people who were importing others' keys:
I think we fixed it, wipe your data dir and re-import.
ok. deleted ~/.BitSharesXTS and reimported keys. Now they show up.
wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
init-delegate-41 (delegate) XTS73iK3RkkijdfgzH5mioB4wzWFNsmsvwtsNPnkoHAApHK6cbMz3 2014-06-01T00:00:00 0
init-delegate-40 (delegate) XTS7DeMWhGV8P7oiKoigtGqFKDfauB83Nrxy5FpMwLEjMw7wC8UVe 2014-06-01T00:00:00 0
init-delegate-39 (delegate) XTS72Xc5wBYmWQrAqcPoU6RSEegB3CosNh82wbf4QkKquJtbhgPWL 2014-06-01T00:00:00 0
init-delegate-38 (delegate) XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z 2014-06-01T00:00:00 0
"OK"
What do I do next? Do I need to register name(s) for these delegates?
-
My delegates were fine in the beginning.
But after I close and reopen the wallet, they become other's Keys:
init-delegate-9 (delegate) XTS6sSu1DhZUxpnoLz1wYvwsowUQpa4zyHFkqo972fKnU6xrEKVx8 2014-06-01T00:00:00 0
init-delegate-7 (delegate) XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delegate-5 (delegate) XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
init-delegate-3 (delegate) XTS7bUdQ41J4vhNVBkmbqDKGiftrmQNrL1vCx881Fg4R2hE5r6P2Z 2014-06-01T00:00:00 0
we just fixed this - you got unlucky.
You have to wipe your wallet and re-import with the newest build
Ok people who were importing others' keys:
I think we fixed it, wipe your data dir and re-import.
ok. deleted ~/.BitSharesXTS and reimported keys. Now they show up.
wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
init-delegate-41 (delegate) XTS73iK3RkkijdfgzH5mioB4wzWFNsmsvwtsNPnkoHAApHK6cbMz3 2014-06-01T00:00:00 0
init-delegate-40 (delegate) XTS7DeMWhGV8P7oiKoigtGqFKDfauB83Nrxy5FpMwLEjMw7wC8UVe 2014-06-01T00:00:00 0
init-delegate-39 (delegate) XTS72Xc5wBYmWQrAqcPoU6RSEegB3CosNh82wbf4QkKquJtbhgPWL 2014-06-01T00:00:00 0
init-delegate-38 (delegate) XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z 2014-06-01T00:00:00 0
"OK"
What do I do next? Do I need to register name(s) for these delegates?
Your delegates are registered already, just leave your node online
-
Ok people who were importing others' keys:
I think we fixed it, wipe your data dir and re-import.
+5%
-
Ok. Now I have a working node on my desktop with 4 initial delegates loaded. Still waiting to see them produce blocks.. hopefully soon. But I am still having no luck compiling on a VPS server rented for the purpose of hosting this node. I signed up for a 2 GB RAM server on https://bitvps.com/ (Ubuntu 14.04) and tried compiling bitshares_toolkit. Getting this error:
[ 64%] Built target bts_api_generator
[ 64%] Generating include/bts/api/common_api.hpp, ../rpc_stubs/common_api_rpc_server.cpp, ../rpc_stubs/common_api_rpc_client.cpp, ../rpc_stubs/common_api_client.cpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_rpc_server.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_rpc_client.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_client.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_overrides.ipp
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted
make[2]: *** [libraries/api/include/bts/api/common_api.hpp] Error 134
make[1]: *** [libraries/api/CMakeFiles/bts_api.dir/all] Error 2
make: *** [all] Error 2
-
Ok. Now I have a working node on my desktop with 4 initial delegates loaded. Still waiting to see them produce blocks.. hopefully soon. But I am still having no luck compiling on a VPS server rented for the purpose of hosting this node. I signed up for a 2 GB RAM server on https://bitvps.com/ (Ubuntu 14.04) and tried compiling bitshares_toolkit. Getting this error:
[ 64%] Built target bts_api_generator
[ 64%] Generating include/bts/api/common_api.hpp, ../rpc_stubs/common_api_rpc_server.cpp, ../rpc_stubs/common_api_rpc_client.cpp, ../rpc_stubs/common_api_client.cpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_rpc_server.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_rpc_client.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_client.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_overrides.ipp
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted
make[2]: *** [libraries/api/include/bts/api/common_api.hpp] Error 134
make[1]: *** [libraries/api/CMakeFiles/bts_api.dir/all] Error 2
make: *** [all] Error 2
you can get more infomation with strace
cd /root/bitshares_toolkit/libraries/api && strace ./bts_api_generator --api-classname=common_api --api-interface-output-dir=/root/bitshares_toolkit/libraries/api --rpc-stub-output-dir=/root/bitshares_toolkit/libraries/rpc_stubs /root/bitshares_toolkit/libraries/api/types.json /root/bitshares_toolkit/libraries/api/blockchain_api.json /root/bitshares_toolkit/libraries/api/wallet_api.json /root/bitshares_toolkit/libraries/api/network_api.json /root/bitshares_toolkit/libraries/api/bitcoin_api.json /root/bitshares_toolkit/libraries/api/general_api.json
-
I guess I'm on a fork too.
tao (unlocked) >>> get_info
{
"blockchain_head_block_num": 217,
"blockchain_head_block_time": "20140610T034415",
"blockchain_confirmation_requirement": 291,
"blockchain_average_delegate_participation": 3.4504690729845762,
"network_num_connections": 1,
"wallet_balance": [[
0,
"XTS"
]
],
"wallet_unlocked_seconds_remaining": 9927654,
"wallet_next_block_production_time": "20140610T034530",
"wallet_seconds_until_next_block_production": 50,
"wallet_local_time": "20140610T034440",
"blockchain_random_seed": "d9f9c3801b1e1059decceebf9f8cb06132f1866b",
"blockchain_shares": 9999972116859,
"network_num_connections_max": 12,
"network_protocol_version": 101,
"wallet_open": true,
"wallet_unlocked_until": "20141003T012534.456867",
"wallet_version": 100
}
produce block is OK.
{
"id": 50,
"name": "init-delegate-50",
"public_data": null,
"owner_key": "XTS7xQtXcZuNn5RgyPdvtfsYAJXS8bysihvrCsvuNC6twdRNxPFA7",
"active_key_history": [[
"19700101T000000",
"XTS7xQtXcZuNn5RgyPdvtfsYAJXS8bysihvrCsvuNC6twdRNxPFA7"
]
],
"delegate_info": {
"votes_for": 100886340227,
"votes_against": 0,
"blocks_produced": 50,
"blocks_missed": 14,
"pay_balance": 103238,
"next_secret_hash": "fb447a2daf3892e83e510d21522658369ec92911",
"last_block_num_produced": 218
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null
}
tao (unlocked) >>> blockchain_get_account_record init-delegate-51
{
"id": 51,
"name": "init-delegate-51",
"public_data": null,
"owner_key": "XTS8NY1vLakvjzdJHmcia3CByapQJZCnNdk6hLMd1numLck6Tc9oc",
"active_key_history": [[
"19700101T000000",
"XTS8NY1vLakvjzdJHmcia3CByapQJZCnNdk6hLMd1numLck6Tc9oc"
]
],
"delegate_info": {
"votes_for": 98724719955,
"votes_against": 0,
"blocks_produced": 49,
"blocks_missed": 16,
"pay_balance": 102108,
"next_secret_hash": "fb3b57c09856f73b740c82f198dfa56ee3568d73",
"last_block_num_produced": 215
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null
}
seems it's another fork which is diferent with me.
I am wondering what's the rules to decide which chain is valid?
-
i compiled on my local ubuntu and upload /bitsharestoolkit folder to my amazon vps and successfully running under ec2 with 512mb ram
Ok. Now I have a working node on my desktop with 4 initial delegates loaded. Still waiting to see them produce blocks.. hopefully soon. But I am still having no luck compiling on a VPS server rented for the purpose of hosting this node. I signed up for a 2 GB RAM server on https://bitvps.com/ (Ubuntu 14.04) and tried compiling bitshares_toolkit. Getting this error:
[ 64%] Built target bts_api_generator
[ 64%] Generating include/bts/api/common_api.hpp, ../rpc_stubs/common_api_rpc_server.cpp, ../rpc_stubs/common_api_rpc_client.cpp, ../rpc_stubs/common_api_client.cpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_rpc_server.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_rpc_client.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_client.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_overrides.ipp
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted
make[2]: *** [libraries/api/include/bts/api/common_api.hpp] Error 134
make[1]: *** [libraries/api/CMakeFiles/bts_api.dir/all] Error 2
make: *** [all] Error 2
-
Ok. Now I have a working node on my desktop with 4 initial delegates loaded. Still waiting to see them produce blocks.. hopefully soon. But I am still having no luck compiling on a VPS server rented for the purpose of hosting this node. I signed up for a 2 GB RAM server on https://bitvps.com/ (Ubuntu 14.04) and tried compiling bitshares_toolkit. Getting this error:
[ 64%] Built target bts_api_generator
[ 64%] Generating include/bts/api/common_api.hpp, ../rpc_stubs/common_api_rpc_server.cpp, ../rpc_stubs/common_api_rpc_client.cpp, ../rpc_stubs/common_api_client.cpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_rpc_server.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_rpc_client.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_client.hpp, ../rpc_stubs/include/bts/rpc_stubs/common_api_overrides.ipp
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted
make[2]: *** [libraries/api/include/bts/api/common_api.hpp] Error 134
make[1]: *** [libraries/api/CMakeFiles/bts_api.dir/all] Error 2
make: *** [all] Error 2
you can get more infomation with strace
cd /root/bitshares_toolkit/libraries/api && strace ./bts_api_generator --api-classname=common_api --api-interface-output-dir=/root/bitshares_toolkit/libraries/api --rpc-stub-output-dir=/root/bitshares_toolkit/libraries/rpc_stubs /root/bitshares_toolkit/libraries/api/types.json /root/bitshares_toolkit/libraries/api/blockchain_api.json /root/bitshares_toolkit/libraries/api/wallet_api.json /root/bitshares_toolkit/libraries/api/network_api.json /root/bitshares_toolkit/libraries/api/bitcoin_api.json /root/bitshares_toolkit/libraries/api/general_api.json
cd /root/bitshares_toolkit/libraries/api && strace ./bts_api_generator --api-classname=common_api --api-interface-output-dir=/root/bitshares_toolkit/libraries/api --rpc-stub-output-dir=/root/bitshares_toolkit/libraries/rpc_stubs /root/bitshares_toolkit/libraries/api/types.json /root/bitshares_toolkit/libraries/api/blockchain_api.json /root/bitshares_toolkit/libraries/api/wallet_api.json /root/bitshares_toolkit/libraries/api/network_api.json /root/bitshares_toolkit/libraries/api/bitcoin_api.json /root/bitshares_toolkit/libraries/api/general_api.json
execve("./bts_api_generator", ["./bts_api_generator", "--api-classname=common_api", "--api-interface-output-dir=/root"..., "--rpc-stub-output-dir=/root/bits"..., "/root/bitshares_toolkit/librarie"..., "/root/bitshares_toolkit/librarie"..., "/root/bitshares_toolkit/librarie"..., "/root/bitshares_toolkit/librarie"..., "/root/bitshares_toolkit/librarie"..., "/root/bitshares_toolkit/librarie"...], [/* 18 vars */]) = 0
brk(0) = 0x2182000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd779ffe000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=32889, ...}) = 0
mmap(NULL, 32889, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fd779ff5000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0po\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=141574, ...}) = 0
mmap(NULL, 2217264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fd779bc0000
mprotect(0x7fd779bd9000, 2093056, PROT_NONE) = 0
mmap(0x7fd779dd8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x7fd779dd8000
mmap(0x7fd779dda000, 13616, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fd779dda000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libstdc++.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\265\5\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=979056, ...}) = 0
mmap(NULL, 3159072, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fd7798bc000
mprotect(0x7fd7799a2000, 2093056, PROT_NONE) = 0
mmap(0x7fd779ba1000, 40960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe5000) = 0x7fd779ba1000
mmap(0x7fd779bab000, 82976, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fd779bab000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20V\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=1071552, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd779ff4000
mmap(NULL, 3166568, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fd7795b6000
mprotect(0x7fd7796bb000, 2093056, PROT_NONE) = 0
mmap(0x7fd7798ba000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x104000) = 0x7fd7798ba000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260*\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=90080, ...}) = 0
mmap(NULL, 2185952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fd7793a0000
mprotect(0x7fd7793b6000, 2093056, PROT_NONE) = 0
mmap(0x7fd7795b5000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7fd7795b5000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\37\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1845024, ...}) = 0
mmap(NULL, 3953344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fd778fda000
mprotect(0x7fd779196000, 2093056, PROT_NONE) = 0
mmap(0x7fd779395000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bb000) = 0x7fd779395000
mmap(0x7fd77939b000, 17088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fd77939b000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd779ff3000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd779ff2000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd779ff0000
arch_prctl(ARCH_SET_FS, 0x7fd779ff0780) = 0
mprotect(0x7fd779395000, 16384, PROT_READ) = 0
mprotect(0x7fd7798ba000, 4096, PROT_READ) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd779fef000
mprotect(0x7fd779ba1000, 32768, PROT_READ) = 0
mprotect(0x7fd779dd8000, 4096, PROT_READ) = 0
mprotect(0x735000, 4096, PROT_READ) = 0
mprotect(0x7fd77a000000, 4096, PROT_READ) = 0
munmap(0x7fd779ff5000, 32889) = 0
set_tid_address(0x7fd779ff0a50) = 32216
set_robust_list(0x7fd779ff0a60, 24) = 0
futex(0x7fff4ac94a30, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7fd779ff0780) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0x7fd779bc69f0, [], SA_RESTORER|SA_SIGINFO, 0x7fd779bd0340}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7fd779bc6a80, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7fd779bd0340}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM64_INFINITY}) = 0
futex(0x7fd779bbd96c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7fd779bbd978, FUTEX_WAKE_PRIVATE, 2147483647) = 0
brk(0) = 0x2182000
brk(0x21a3000) = 0x21a3000
stat("/root/bitshares_toolkit/libraries/api/types.json", {st_mode=S_IFREG|0644, st_size=12705, ...}) = 0
open("/root/bitshares_toolkit/libraries/api/types.json", O_RDONLY) = 3
read(3, "{\n \"type_map\":\n [\n {\n "..., 8191) = 8191
read(3, "::wallet::pretty_transaction>\",\n"..., 8191) = 4514
close(3) = 0
stat("/root/bitshares_toolkit/libraries/api/blockchain_api.json", {st_mode=S_IFREG|0644, st_size=8537, ...}) = 0
open("/root/bitshares_toolkit/libraries/api/blockchain_api.json", O_RDONLY) = 3
read(3, "{\n \"category\": \"Blockchain Meth"..., 8191) = 8191
read(3, " : [\n {\n "..., 8191) = 346
close(3) = 0
stat("/root/bitshares_toolkit/libraries/api/wallet_api.json", {st_mode=S_IFREG|0644, st_size=32001, ...}) = 0
open("/root/bitshares_toolkit/libraries/api/wallet_api.json", O_RDONLY) = 3
read(3, "{\n \"category\": \"Wallet Methods\""..., 8191) = 8191
read(3, "isites\" : [\"no_prerequisites\"],\n"..., 8191) = 8191
read(3, " \"description\" : \"a"..., 8191) = 8191
read(3, "pe\" : \"std::string\",\n "..., 8191) = 7428
brk(0x21c4000) = 0x21c4000
brk(0x21c3000) = 0x21c3000
close(3) = 0
stat("/root/bitshares_toolkit/libraries/api/network_api.json", {st_mode=S_IFREG|0644, st_size=5373, ...}) = 0
open("/root/bitshares_toolkit/libraries/api/network_api.json", O_RDONLY) = 3
read(3, "{\n \"category\": \"Network Methods"..., 8191) = 5373
brk(0x21b5000) = 0x21b5000
close(3) = 0
stat("/root/bitshares_toolkit/libraries/api/bitcoin_api.json", {st_mode=S_IFREG|0644, st_size=18555, ...}) = 0
open("/root/bitshares_toolkit/libraries/api/bitcoin_api.json", O_RDONLY) = 3
read(3, "{\n \"category\" : \"Bitcoin Compat"..., 8191) = 8191
read(3, "ed\", \"wallet_open\"],\n \""..., 8191) = 8191
read(3, "ssage\",\n \"type\" : \""..., 8191) = 2173
close(3) = 0
stat("/root/bitshares_toolkit/libraries/api/general_api.json", {st_mode=S_IFREG|0644, st_size=2842, ...}) = 0
open("/root/bitshares_toolkit/libraries/api/general_api.json", O_RDONLY) = 3
read(3, "{\n \"category\": \"General Methods"..., 8191) = 2842
close(3) = 0
stat("/root/bitshares_toolkit/libraries/api/types.json", {st_mode=S_IFREG|0644, st_size=12705, ...}) = 0
open("/root/bitshares_toolkit/libraries/api/types.json", O_RDONLY) = 3
read(3, "{\n \"type_map\":\n [\n {\n "..., 8191) = 8191
read(3, "::wallet::pretty_transaction>\",\n"..., 8191) = 4514
close(3) = 0
stat("/root/bitshares_toolkit/libraries/api/blockchain_api.json", {st_mode=S_IFREG|0644, st_size=8537, ...}) = 0
open("/root/bitshares_toolkit/libraries/api/blockchain_api.json", O_RDONLY) = 3
read(3, "{\n \"category\": \"Blockchain Meth"..., 8191) = 8191
read(3, " : [\n {\n "..., 8191) = 346
close(3) = 0
stat("/root/bitshares_toolkit/libraries/api/wallet_api.json", {st_mode=S_IFREG|0644, st_size=32001, ...}) = 0
open("/root/bitshares_toolkit/libraries/api/wallet_api.json", O_RDONLY) = 3
read(3, "{\n \"category\": \"Wallet Methods\""..., 8191) = 8191
read(3, "isites\" : [\"no_prerequisites\"],\n"..., 8191) = 8191
read(3, " \"description\" : \"a"..., 8191) = 8191
read(3, "pe\" : \"std::string\",\n "..., 8191) = 7428
close(3) = 0
stat("/root/bitshares_toolkit/libraries/api/network_api.json", {st_mode=S_IFREG|0644, st_size=5373, ...}) = 0
open("/root/bitshares_toolkit/libraries/api/network_api.json", O_RDONLY) = 3
brk(0x21d6000) = 0x21d6000
read(3, "{\n \"category\": \"Network Methods"..., 8191) = 5373
brk(0x21d4000) = 0x21d4000
close(3) = 0
stat("/root/bitshares_toolkit/libraries/api/bitcoin_api.json", {st_mode=S_IFREG|0644, st_size=18555, ...}) = 0
open("/root/bitshares_toolkit/libraries/api/bitcoin_api.json", O_RDONLY) = 3
read(3, "{\n \"category\" : \"Bitcoin Compat"..., 8191) = 8191
read(3, "ed\", \"wallet_open\"],\n \""..., 8191) = 8191
read(3, "ssage\",\n \"type\" : \""..., 8191) = 2173
close(3) = 0
stat("/root/bitshares_toolkit/libraries/api/general_api.json", {st_mode=S_IFREG|0644, st_size=2842, ...}) = 0
open("/root/bitshares_toolkit/libraries/api/general_api.json", O_RDONLY) = 3
read(3, "{\n \"category\": \"General Methods"..., 8191) = 2842
close(3) = 0
stat("/root/bitshares_toolkit/libraries/api/include/bts/api", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/root/bitshares_toolkit/libraries/api/include/bts/api/common_api.hpp", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
writev(3, [{"// "..., 8185}, {" *\n", 7}], 2) = 8192
writev(3, [{" * @return optional_wallet_n"..., 8127}, {" * Sends given amount to the"..., 194}], 2) = 8321
writev(3, [{"\n *\n * @param amount_to_"..., 8081}, {"bts::blockchain::signed_transact"..., 212}], 2) = 8293
writev(3, [{" = 0;\n /**\n * Vote on a p"..., 8141}, {" * Attempts add or remove <n"..., 113}], 2) = 8254
writev(3, [{"\n *\n * @param node The n"..., 8190}, {"std::string bitcoin_signmessage("..., 87}], 2) = 8277
write(3, " = 0;\n /**\n * Return info"..., 3481) = 3481
close(3) = 0
stat("/root/bitshares_toolkit/libraries/rpc_stubs/include/bts/rpc_stubs", 0x7fff4ac93af0) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1607648, ...}) = 0
mmap(NULL, 1607648, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fd779e66000
close(3) = 0
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd779ffd000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2570
read(3, "", 4096) = 0
close(3) = 0
munmap(0x7fd779ffd000, 4096) = 0
open("/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
futex(0x7fd7795b5850, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "terminate called after throwing "..., 48terminate called after throwing an instance of ') = 48
write(2, "std::runtime_error", 18std::runtime_error) = 18
write(2, "'\n", 2'
) = 2
write(2, " what(): ", 11 what(): ) = 11
write(2, "locale::facet::_S_create_c_local"..., 48locale::facet::_S_create_c_locale name not valid) = 48
write(2, "\n", 1
) = 1
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(32216, 32216, SIGABRT) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=32216, si_uid=0} ---
+++ killed by SIGABRT +++
Aborted
-
seems your locale is not correct.
run " locale' to see what's locale you are use now.
run "locale -a " to see what's locale support in your system
then choose a correct locale, like:
export LC_ALL=POSIX
build again.
-
seems your locale is not correct.
run " locale' to see what's locale you are use now.
run "locale -a " to see what's locale support in your system
then choose a correct locale, like:
export LC_ALL=POSIX
build again.
that worked.
There is another problem. As soon I as restart bitshares_client wallet delegates seem to reset and wrong delegates show up.
wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
init-delegate-9 (delegate) XTS6sSu1DhZUxpnoLz1wYvwsowUQpa4zyHFkqo972fKnU6xrEKVx8 2014-06-01T00:00:00 0
init-delegate-7 (delegate) XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delegate-5 (delegate) XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
init-delegate-3 (delegate) XTS7bUdQ41J4vhNVBkmbqDKGiftrmQNrL1vCx881Fg4R2hE5r6P2Z 2014-06-01T00:00:00 0
If I delete ~/.BitsharesXTS and start over I can load private keys and all seems to work, but only till I restart client. Then wrong delegates show up again.
-
Yes, it works:
init-delegate-93 (delegate) XTS7fzyfX657vDUP4UVXRHNxCMZsGpCCGkvP7rN5NKkuEjktg5sHd 2014-06-01T00:00:00 0
init-delegate-92 (delegate) XTS6LDMYp9UNEYLUEdpCqx5dCEkWwrpP67LE5Zu3sSYqjP6LraqTW 2014-06-01T00:00:00 0
init-delegate-91 (delegate) XTS7qQScYbuFqsffgH6AammYXWMkZ9jSYdsYW21zguc2k2N3hYnfN 2014-06-01T00:00:00 0
init-delegate-90 (delegate) XTS7Bsi43JASDcPdgcLaXSLQ7mVNJReUvG4rcQYHHaJ3Ca7SLPYyq 2014-06-01T00:00:00 0
-
I have missed a critical step, and get an error importing the private keys I have generated:
mywallet2 (unlocked) >>> wallet_import_private_key 5Ke...................................................................etc "pgbit-delegate-1"
"You can only import keys into receive accounts"
Can anyone point me to instructions on sorting this one?
thanks.
-
I have all my delegates working (init-delegate-21,init-delegate-22,init-delegate-23,init-delegate-24) and it seems they are producing blocks correctly, but the commands wallet_get_account and blockchain_get_account_record returns different results:
default (unlocked) >>> wallet_get_account init-delegate-24
{
"index": 9,
"id": 24,
"name": "init-delegate-24",
"public_data": null,
"owner_key": "XTS6o9KsYFpuPLQy9HCZGJrsxhnSFrv4DN4C3XNmb3kknFXikBBPP",
"active_key_history": [[
"19700101T000000",
"XTS6o9KsYFpuPLQy9HCZGJrsxhnSFrv4DN4C3XNmb3kknFXikBBPP"
]
],
"delegate_info": {
"votes_for": 117356745667,
"votes_against": 0,
"blocks_produced": 20,
"blocks_missed": 15,
"pay_balance": 223970,
"next_secret_hash": "df60b5410b574fb0cde0e23d81122bdd28807db4",
"last_block_num_produced": 1088
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null,
"account_address": "XTSBCsSS9k3gX7mAPcPQM6Qg2Rpnisr4KWRi",
"trust_level": 0,
"private_data": null
}
default (unlocked) >>> blockchain_get_account_record init-delegate-24
{
"id": 24,
"name": "init-delegate-24",
"public_data": null,
"owner_key": "XTS6o9KsYFpuPLQy9HCZGJrsxhnSFrv4DN4C3XNmb3kknFXikBBPP",
"active_key_history": [[
"19700101T000000",
"XTS6o9KsYFpuPLQy9HCZGJrsxhnSFrv4DN4C3XNmb3kknFXikBBPP"
]
],
"delegate_info": {
"votes_for": 117357876741,
"votes_against": 0,
"blocks_produced": 59,
"blocks_missed": 15,
"pay_balance": 1355044,
"next_secret_hash": "bfbadf92bacf4846725b81e31f8b45123f4c6246",
"last_block_num_produced": 2708
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null
}
I think the blockchain_get_account_record is the correct one.
-
I guess I'm on a fork too.
...
seems it's another fork which is diferent with me.
I am wondering what's the rules to decide which chain is valid?
Now the correct blockchain is ？
-
Still failed from switching fork. Any idea?
1784976ms th_a switch_to_fork ] pop 83bdb2434ad8e1f02c043d33871b689a2049ce9e chain_database.cpp:432
1784978ms th_a push_block ] attempt to switch to fork failed: 13 St12bad_weak_ptr: bad_weak_ptr
bad_weak_ptr:
{"what":"bad_weak_ptr"}
th_a chain_database.cpp:758 pop_block
{"block_id":"4565f1d3b495212c59fea3390ef944c2fe973ca6"}
th_a chain_database.cpp:440 switch_to_fork, reverting chain_database.cpp:1005
-
Keyhotee import:
I registered with the name 'XeRoc'
Result:
default (unlocked) >>> wallet_import_keyhotee "Fabian" "" "NAME" "SECRET" "XeRoc"
10 assert_exception: Assert Exception
is_valid_account_name( keyhoteeid ):
{}
th_a wallet.cpp:2110 import_keyhotee
error creating private key using keyhotee info.
{"firstname":"Fabian","middlename":"","lastname":"NAME","brainkey":"SECRET","keyhoteeid":"XeRoc"}
th_a wallet.cpp:2121 import_keyhotee
{}
th_a common_api_client.cpp:272 wallet_import_keyhotee
{"command":"wallet_import_keyhotee"}
th_a cli.cpp:577 execute_command
I tried using lower case letters for the username:
default (unlocked) >>> wallet_import_keyhotee "Fabian" "" "NAME" "SECRET" "xeroc"
10 assert_exception: Assert Exception
!"Account name is already registered under a different key":
{}
th_a wallet.cpp:708 add_contact_account
{"account_name":"xeroc","key":"XTS6pspjV35izHwn5wKqDXeSbDWCoPTUunMP26NUMmQgGrAeMmdBA"}
th_a wallet.cpp:736 add_contact_account
{"account_name":"xeroc"}
th_a wallet.cpp:841 import_private_key
error creating private key using keyhotee info.
{"firstname":"Fabian","middlename":"","lastname":"NAME","brainkey":"SECRET","keyhoteeid":"xeroc"}
th_a wallet.cpp:2121 import_keyhotee
{}
th_a common_api_client.cpp:272 wallet_import_keyhotee
{"command":"wallet_import_keyhotee"}
th_a cli.cpp:577 execute_command
I suspect there is an issue with the letter-case as 'xeroc' is registered as founder, but I need to generate my key using 'XeRoc'?!?
-
I think its better to use founder code for keyhotee import =\
-
Either I was on a fork yesterday, producing several dozens of blocks,
or I am on a fork now (latest git-head) and produced only a few blocks
-
This is a problem/bug with the wallet account mixing up the "id" and "index".
All my delegates (26,27,28,29) had the id=(26,27,28,29) but the index=(3,5,7,9) so when the client is restarted they load with the wrong id (because it's using the index).
look like we are sharing "init-delegate-5 (delegate) " and "init-delegate-7 (delegate)"
anyone can explain it ? must be a bug..... how can we both have the same keys in different wallet
wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
pan2pan-05 0.000000 XTS XTS8T5M76CG8PFopcuSoAkvTfzkGhZMR44Dckd6JB5zYxxde1vqaU NO 0
init-delegate-8 (delegate) 0.000000 XTS XTS4u3cQJNLS9jDN1mCM9ynLNHQV9PuEVfwA2R95XnV7ZDNjJL89z 2014-06-01T00:00:00 0
init-delegate-7 (delegate) 0.000000 XTS XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delegate-6 (delegate) 0.000000 XTS XTS5vXkQbGLEwaye3ZsLAtMMEe6tkh724nr2zoGHHeAUCsvVeywvc 2014-06-01T00:00:00 0
init-delegate-5 (delegate) 0.000000 XTS XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
After latest git pull things are starting to work.
I was able to import 4 of my delegate private keys. However I am not seeing these delegates among receive accounts..
These accounts show up, but these are not public keys that correspond to my imported private keys.
wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
init-delegate-9 (delegate) XTS6sSu1DhZUxpnoLz1wYvwsowUQpa4zyHFkqo972fKnU6xrEKVx8 2014-06-01T00:00:00 0
init-delegate-7 (delegate) XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delegate-5 (delegate) XTS6tmvXdn2vJss4a4ADVUUi8GbAC37H6HJRcVeFyhzcsRUNyQJGE 2014-06-01T00:00:00 0
init-delegate-3 (delegate) XTS7bUdQ41J4vhNVBkmbqDKGiftrmQNrL1vCx881Fg4R2hE5r6P2Z 2014-06-01T00:00:00 0
"OK"
My public keys are:
XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z
XTS72Xc5wBYmWQrAqcPoU6RSEegB3CosNh82wbf4QkKquJtbhgPWL
XTS7DeMWhGV8P7oiKoigtGqFKDfauB83Nrxy5FpMwLEjMw7wC8UVe
XTS73iK3RkkijdfgzH5mioB4wzWFNsmsvwtsNPnkoHAApHK6cbMz3
Am I missing something?
Me too
-
(http://trappedinparadiseagain.files.wordpress.com/2014/04/wk27_bugs_life_a_two.jpg)
-
Still failed from switching fork. Any idea?
1784976ms th_a switch_to_fork ] pop 83bdb2434ad8e1f02c043d33871b689a2049ce9e chain_database.cpp:432
1784978ms th_a push_block ] attempt to switch to fork failed: 13 St12bad_weak_ptr: bad_weak_ptr
bad_weak_ptr:
{"what":"bad_weak_ptr"}
th_a chain_database.cpp:758 pop_block
{"block_id":"4565f1d3b495212c59fea3390ef944c2fe973ca6"}
th_a chain_database.cpp:440 switch_to_fork, reverting chain_database.cpp:1005
I can see it's caused by chain_database.cpp line 756 but no further idea.
if( _observer ) _observer->state_changed(undo_state.shared_from_this());
Edit:
I've temporarily bypassed this by changing it to below:
if( _observer ) _observer->state_changed((pending_chain_state_ptr&)undo_state);
-
I am just wondering why not have a dedicated chatroom for this. That way people can help out each other if there are repeated errors and faster resolution can happen. Not everyone need to be logged on all the time - BM/toast can keep working on their fixes and release them in the chatroom when they are ready.
-
we could start filling #bitshares @ freenode .. channel already exists .. no moderators yet, thougth
-
Fresh server rebuild, error on # make
Scanning dependencies of target wallet_tests
[100%] Building CXX object tests/CMakeFiles/wallet_tests.dir/wallet_tests.cpp.o
/root/bitshares_toolkit/tests/wallet_tests.cpp: In member function ‘void master test::test_method()’:
/root/bitshares_toolkit/tests/wallet_tests.cpp:93:100: error: call of overloade ‘public_key(bts::blockchain::public_key_type&)’ is ambiguous
config.balances.push_back( std::make_pair( pts_address((fc::ecc::public_ ey)delegate_account.owner), BTS_BLOCKCHAIN_INITIAL_SHARES/BTS_BLOCKCHAIN_NUM_DE EGATES) );
^
/root/bitshares_toolkit/tests/wallet_tests.cpp:93:100: note: candidates are:
In file included from /root/bitshares_toolkit/libraries/blockchain/include/bts/ lockchain/types.hpp:3:0,
from /root/bitshares_toolkit/libraries/blockchain/include/bts/ lockchain/chain_database.hpp:2,
from /root/bitshares_toolkit/tests/wallet_tests.cpp:3:
/root/bitshares_toolkit/libraries/fc/include/fc/crypto/elliptic.hpp:49:12: note fc::ecc::public_key::public_key(fc::ecc::public_key&&)
public_key( public_key&& pk );
^
/root/bitshares_toolkit/libraries/fc/include/fc/crypto/elliptic.hpp:41:12: note fc::ecc::public_key::public_key(const public_key_data&)
public_key( const public_key_data& v );
^
/root/bitshares_toolkit/libraries/fc/include/fc/crypto/elliptic.hpp:32:12: note fc::ecc::public_key::public_key(const fc::ecc::public_key&)
public_key(const public_key& k);
^
make[2]: *** [tests/CMakeFiles/wallet_tests.dir/wallet_tests.cpp.o] Error 1
make[1]: *** [tests/CMakeFiles/wallet_tests.dir/all] Error 2
make: *** [all] Error 2
-
Any idea WTF this is. Its happend after latest git pull
alexxy (unlocked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
rob XTS5UEnYkxWvjHRX4qe16KpYRdwiEBfK51TNJe9UB8FKKjmBkN9cw 2014-06-01T00:00:00 0
richard XTS75TAiDdzhZJQbw8aDtvXGwM1QV3PqbUgjwbEzQQqggJ5EQmiE5 2014-06-01T00:00:00 0
qq-com XTS7Jr9XcHVrvJYGek2FLaRrxz4xkzTyLkDyxVE998EHhwxTz1M1A 2014-06-01T00:00:00 0
init-delegate-7 (delegate) XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delegate-3 (delegate) XTS7bUdQ41J4vhNVBkmbqDKGiftrmQNrL1vCx881Fg4R2hE5r6P2Z 2014-06-01T00:00:00 0
Seems like its non uniq priv keys!
-
Any idea WTF this is. Its happend after latest git pull
alexxy (unlocked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
rob XTS5UEnYkxWvjHRX4qe16KpYRdwiEBfK51TNJe9UB8FKKjmBkN9cw 2014-06-01T00:00:00 0
richard XTS75TAiDdzhZJQbw8aDtvXGwM1QV3PqbUgjwbEzQQqggJ5EQmiE5 2014-06-01T00:00:00 0
qq-com XTS7Jr9XcHVrvJYGek2FLaRrxz4xkzTyLkDyxVE998EHhwxTz1M1A 2014-06-01T00:00:00 0
init-delegate-7 (delegate) XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delegate-3 (delegate) XTS7bUdQ41J4vhNVBkmbqDKGiftrmQNrL1vCx881Fg4R2hE5r6P2Z 2014-06-01T00:00:00 0
Seems like its non uniq priv keys!
This is a wallet sync bug. You don't actually own those key =P
But the bad news is that you will have to wipe your wallet after we fix it.
Seems like bitder found the bug:
This is a problem/bug with the wallet account mixing up the "id" and "index".
All my delegates (26,27,28,29) had the id=(26,27,28,29) but the index=(3,5,7,9) so when the client is restarted they load with the wrong id (because it's using the index).
-
This is a problem/bug with the wallet account mixing up the "id" and "index".
All my delegates (26,27,28,29) had the id=(26,27,28,29) but the index=(3,5,7,9) so when the client is restarted they load with the wrong id (because it's using the index).
Post a PTS address for a tip from BM!
-
Any idea WTF this is. Its happend after latest git pull
alexxy (unlocked) >>> wallet_list_receive_accounts
NAME BALANCE KEY REGISTERED TRUST LEVEL
rob XTS5UEnYkxWvjHRX4qe16KpYRdwiEBfK51TNJe9UB8FKKjmBkN9cw 2014-06-01T00:00:00 0
richard XTS75TAiDdzhZJQbw8aDtvXGwM1QV3PqbUgjwbEzQQqggJ5EQmiE5 2014-06-01T00:00:00 0
qq-com XTS7Jr9XcHVrvJYGek2FLaRrxz4xkzTyLkDyxVE998EHhwxTz1M1A 2014-06-01T00:00:00 0
init-delegate-7 (delegate) XTS5H3qwDsnjm8yoiN1CAQg6LKTnSNuXZDePeGAQSa5CiALSFRFQ8 2014-06-01T00:00:00 0
init-delegate-3 (delegate) XTS7bUdQ41J4vhNVBkmbqDKGiftrmQNrL1vCx881Fg4R2hE5r6P2Z 2014-06-01T00:00:00 0
Seems like its non uniq priv keys!
This is a wallet sync bug. You don't actually own those key =P
But the bad news is that you will have to wipe your wallet after we fix it.
Seems like bitder found the bug:
This is a problem/bug with the wallet account mixing up the "id" and "index".
All my delegates (26,27,28,29) had the id=(26,27,28,29) but the index=(3,5,7,9) so when the client is restarted they load with the wrong id (because it's using the index).
Sure its a bug =D there should be one fresh generated key. and 4 init-delegates-{78-81} keys
-
(http://trappedinparadiseagain.files.wordpress.com/2014/04/wk27_bugs_life_a_two.jpg)
+5%
-
This is a problem/bug with the wallet account mixing up the "id" and "index".
All my delegates (26,27,28,29) had the id=(26,27,28,29) but the index=(3,5,7,9) so when the client is restarted they load with the wrong id (because it's using the index).
Post a PTS address for a tip from BM!
Ps6LLRMBjiEMrikwdCKJ9sMDBTgB4GuVKe
Thanks.
-
I found I was on a forked chain half an hour ago. (I was the only one producing the blocks)
Then I wiped the .BitsharesXTS, git pull, cmake, make. Errors occurred:
[100%] Building CXX object tests/CMakeFiles/wallet_tests.dir/wallet_tests.cpp.o
/root/bitshares_toolkit/tests/wallet_tests.cpp: In member function 鈥榖ool test_file::compare_files()鈥
/root/bitshares_toolkit/tests/wallet_tests.cpp:210:21: error: variable 鈥榮td::ifstream lhs鈥has initializer but incomplete type
std::ifstream lhs(_result_file.string());
^
/root/bitshares_toolkit/tests/wallet_tests.cpp:211:21: error: variable 鈥榮td::ifstream rhs鈥has initializer but incomplete type
std::ifstream rhs(_expected_result_file.string());
^
/root/bitshares_toolkit/tests/wallet_tests.cpp: In member function 鈥榲oid regression_test::test_method()鈥
/root/bitshares_toolkit/tests/wallet_tests.cpp:320:35: error: variable 鈥榮td::ifstream test_config_file鈥has initializer but incomplete type
std::ifstream test_config_file("test.config");
^
/root/bitshares_toolkit/tests/wallet_tests.cpp:333:58: error: 鈥楥ommandLineToArgvA鈥was not declared in this scope
char** argv = CommandLineToArgvA(line.c_str(),&argc);
^
/root/bitshares_toolkit/tests/wallet_tests.cpp:338:34: error: variable 鈥榮td::ifstream input_stream鈥has initializer but incomplete type
std::ifstream input_stream(input_file.string());
^
/root/bitshares_toolkit/tests/wallet_tests.cpp:347:22: error: 鈥楪lobalFree鈥was not declared in this scope
GlobalFree(argv);
^
/root/bitshares_toolkit/tests/wallet_tests.cpp: In member function 鈥榖ool test_file::compare_files()鈥
/root/bitshares_toolkit/tests/wallet_tests.cpp:215:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
make[2]: *** [tests/CMakeFiles/wallet_tests.dir/wallet_tests.cpp.o] Error 1
make[1]: *** [tests/CMakeFiles/wallet_tests.dir/all] Error 2
make: *** [all] Error 2
-
I found I was on a forked chain half an hour ago. (I was the only one producing the blocks)
Then I wiped the .BitsharesXTS, git pull, cmake, make. Errors occurred:
[100%] Building CXX object tests/CMakeFiles/wallet_tests.dir/wallet_tests.cpp.o
/root/bitshares_toolkit/tests/wallet_tests.cpp: In member function 鈥榖ool test_file::compare_files()鈥
/root/bitshares_toolkit/tests/wallet_tests.cpp:210:21: error: variable 鈥榮td::ifstream lhs鈥has initializer but incomplete type
std::ifstream lhs(_result_file.string());
^
/root/bitshares_toolkit/tests/wallet_tests.cpp:211:21: error: variable 鈥榮td::ifstream rhs鈥has initializer but incomplete type
std::ifstream rhs(_expected_result_file.string());
^
/root/bitshares_toolkit/tests/wallet_tests.cpp: In member function 鈥榲oid regression_test::test_method()鈥
/root/bitshares_toolkit/tests/wallet_tests.cpp:320:35: error: variable 鈥榮td::ifstream test_config_file鈥has initializer but incomplete type
std::ifstream test_config_file("test.config");
^
/root/bitshares_toolkit/tests/wallet_tests.cpp:333:58: error: 鈥楥ommandLineToArgvA鈥was not declared in this scope
char** argv = CommandLineToArgvA(line.c_str(),&argc);
^
/root/bitshares_toolkit/tests/wallet_tests.cpp:338:34: error: variable 鈥榮td::ifstream input_stream鈥has initializer but incomplete type
std::ifstream input_stream(input_file.string());
^
/root/bitshares_toolkit/tests/wallet_tests.cpp:347:22: error: 鈥楪lobalFree鈥was not declared in this scope
GlobalFree(argv);
^
/root/bitshares_toolkit/tests/wallet_tests.cpp: In member function 鈥榖ool test_file::compare_files()鈥
/root/bitshares_toolkit/tests/wallet_tests.cpp:215:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
make[2]: *** [tests/CMakeFiles/wallet_tests.dir/wallet_tests.cpp.o] Error 1
make[1]: *** [tests/CMakeFiles/wallet_tests.dir/all] Error 2
make: *** [all] Error 2
someone broke the build -.-
try pulling again
-
https://dl.dropboxusercontent.com/u/26420542/outputcmakemakeOSX10.9.txt
[ 99%] Built target key_to_wif
Scanning dependencies of target wallet_tests
[100%] Building CXX object tests/CMakeFiles/wallet_tests.dir/wallet_tests.cpp.o
/Users/maurits/bitsharesxts/bitshares_toolkit/tests/wallet_tests.cpp:210:17: error: implicit instantiation of undefined template 'std::__1::basic_ifstream<char, std::__1::char_traits<char> >'
std::ifstream lhs(_result_file.string());
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iosfwd:131:33: note: template is declared here
class _LIBCPP_TYPE_VIS_ONLY basic_ifstream;
^
/Users/maurits/bitsharesxts/bitshares_toolkit/tests/wallet_tests.cpp:211:17: error: implicit instantiation of undefined template 'std::__1::basic_ifstream<char, std::__1::char_traits<char> >'
std::ifstream rhs(_expected_result_file.string());
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iosfwd:131:33: note: template is declared here
class _LIBCPP_TYPE_VIS_ONLY basic_ifstream;
^
/Users/maurits/bitsharesxts/bitshares_toolkit/tests/wallet_tests.cpp:320:19: error: implicit instantiation of undefined template 'std::__1::basic_ifstream<char, std::__1::char_traits<char> >'
std::ifstream test_config_file("test.config");
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iosfwd:131:33: note: template is declared here
class _LIBCPP_TYPE_VIS_ONLY basic_ifstream;
^
/Users/maurits/bitsharesxts/bitshares_toolkit/tests/wallet_tests.cpp:333:21: error: use of undeclared identifier 'CommandLineToArgvA'
char** argv = CommandLineToArgvA(line.c_str(),&argc);
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
5 errors generated.
make[2]: *** [tests/CMakeFiles/wallet_tests.dir/wallet_tests.cpp.o] Error 1
make[1]: *** [tests/CMakeFiles/wallet_tests.dir/all] Error 2
make: *** [all] Error 2
Build was indeed broken, trying again now. still broken it seems.
Posting the log just in case. Mac OS X 10.9.3.
430 warnings (a lot about deprecated functions, I know warnings don't mean that something is broken)
This happens with the most current version:
[100%] Building CXX object tests/CMakeFiles/wallet_tests.dir/wallet_tests.cpp.o
/Users/maurits/bitsharesxts/bitshares_toolkit/tests/wallet_tests.cpp:229:17: error: implicit instantiation of undefined template 'std::__1::basic_ifstream<char, std::__1::char_traits<char> >'
std::ifstream lhs(_result_file.string().c_str());
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iosfwd:131:33: note: template is declared here
class _LIBCPP_TYPE_VIS_ONLY basic_ifstream;
^
/Users/maurits/bitsharesxts/bitshares_toolkit/tests/wallet_tests.cpp:230:17: error: implicit instantiation of undefined template 'std::__1::basic_ifstream<char, std::__1::char_traits<char> >'
std::ifstream rhs(_expected_result_file.string().c_str());
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iosfwd:131:33: note: template is declared here
class _LIBCPP_TYPE_VIS_ONLY basic_ifstream;
^
/Users/maurits/bitsharesxts/bitshares_toolkit/tests/wallet_tests.cpp:339:19: error: implicit instantiation of undefined template 'std::__1::basic_ifstream<char, std::__1::char_traits<char> >'
std::ifstream test_config_file("test.config");
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iosfwd:131:33: note: template is declared here
class _LIBCPP_TYPE_VIS_ONLY basic_ifstream;
^
/Users/maurits/bitsharesxts/bitshares_toolkit/tests/wallet_tests.cpp:352:21: error: use of undeclared identifier 'CommandLineToArgvA'
char** argv = CommandLineToArgvA(line.c_str(),&argc);
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
5 errors generated.
make[2]: *** [tests/CMakeFiles/wallet_tests.dir/wallet_tests.cpp.o] Error 1
make[1]: *** [tests/CMakeFiles/wallet_tests.dir/all] Error 2
make: *** [all] Error 2
Same error as above, but other line numbers it seems.
-
someone broke the build -.-
try pulling again
Tried again, but still the same.
BTW. I don't understand why I was on the wrong chain. I haven't done anything special after I launched the delegates. Sorry for not catching log information.
-
Same here, same error.
-
This is strange. Why are there two similar functions
blockchain_get_account_record
and
wallet_get_account
and why are they showing different info about same delegates? wallet_get_account is showing 0 blocks produced, while blockchain_get_account_record is showing 23 blocks produced..
blockchain_get_account_record init-delegate-38
{
"id": 38,
"name": "init-delegate-38",
"public_data": null,
"owner_key": "XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z",
"active_key_history": [[
"20140610T070732",
"XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z"
]
],
"delegate_info": {
"votes_for": 111118188439,
"votes_against": 0,
"blocks_produced": 23,
"blocks_missed": 74,
"pay_balance": 857411,
"next_secret_hash": "b3e4da54b09f97e7a459637d9e97354d65f45fe9",
"last_block_num_produced": 2667
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null
}
default (unlocked) >>> wallet_get_account init-delegate-38
{
"index": 3,
"id": 38,
"name": "init-delegate-38",
"public_data": null,
"owner_key": "XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z",
"active_key_history": [[
"20140610T070732",
"XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z"
]
],
"delegate_info": {
"votes_for": 111117331028,
"votes_against": 0,
"blocks_produced": 0,
"blocks_missed": 74,
"pay_balance": 0,
"next_secret_hash": "0000000000000000000000000000000000000000",
"last_block_num_produced": 4294967295
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null,
"account_address": "XTS6VS3reBvjJMyeuiZTG1g7AexK2Kao1XBZ",
"trust_level": 0,
"private_data": null
}
-
This is strange. Why are there two similar functions
blockchain_get_account_record
and
wallet_get_account
and why are they showing different info about same delegates? wallet_get_account is showing 0 blocks produced, while blockchain_get_account_record is showing 23 blocks produced..
blockchain_get_account_record init-delegate-38
{
"id": 38,
"name": "init-delegate-38",
"public_data": null,
"owner_key": "XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z",
"active_key_history": [[
"20140610T070732",
"XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z"
]
],
"delegate_info": {
"votes_for": 111118188439,
"votes_against": 0,
"blocks_produced": 23,
"blocks_missed": 74,
"pay_balance": 857411,
"next_secret_hash": "b3e4da54b09f97e7a459637d9e97354d65f45fe9",
"last_block_num_produced": 2667
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null
}
default (unlocked) >>> wallet_get_account init-delegate-38
{
"index": 3,
"id": 38,
"name": "init-delegate-38",
"public_data": null,
"owner_key": "XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z",
"active_key_history": [[
"20140610T070732",
"XTS6ezsAe72hVoMq4mC4fnAAF2XYqprcpt4vZ5nkqUoZn8xsSWB5Z"
]
],
"delegate_info": {
"votes_for": 111117331028,
"votes_against": 0,
"blocks_produced": 0,
"blocks_missed": 74,
"pay_balance": 0,
"next_secret_hash": "0000000000000000000000000000000000000000",
"last_block_num_produced": 4294967295
},
"registration_date": "20140601T000000",
"last_update": "20140601T000000",
"meta_data": null,
"account_address": "XTS6VS3reBvjJMyeuiZTG1g7AexK2Kao1XBZ",
"trust_level": 0,
"private_data": null
}
this is known issue that the wallet not syn the delegate info.
-
someone broke the build -.-
try pulling again
Tried again, but still the same.
BTW. I don't understand why I was on the wrong chain. I haven't done anything special after I launched the delegates. Sorry for not catching log information.
ok, one more try. EDIT: actually wait a bit again... sigh
We should use chat for this. Link at top of forum.
-
Looks like my delegate node forked last night too. I was able to get it back to what I believe is the correct chain by clearing the data directory. Are the logs from my forked delegate worth anything?
-
Looks like my delegate node forked last night too. I was able to get it back to what I believe is the correct chain by clearing the data directory. Are the logs from my forked delegate worth anything?
Eric is actively working on setting up intentional fork generating tests. We will be able to handle this better soon.
-
Looks like my delegate node forked last night too. I was able to get it back to what I believe is the correct chain by clearing the data directory. Are the logs from my forked delegate worth anything?
Eric is actively working on setting up intentional fork generating tests. We will be able to handle this better soon.
One odd thing I noticed in the node that forked is that the logs show its own IP address as a peer. I haven't seen that in any of the logs of my other nodes. Anyways, I'm off to work. I'll keep as close of an eye on my nodes as I can.
-
Hi,
i wonder why do the net votes for delegates never change? Since some delegates producing blocks without missing a single opportunity, other delegates never produced a block at all.
I had the impression that delegate election is forced by the network itself?
-
Hi,
i wonder why do the net votes for delegates never change? Since some delegates producing blocks without missing a single opportunity, other delegates never produced a block at all.
I had the impression that delegate election is forced by the network itself?
Eventually it will be done by the client, and will be configurable per-user. There are no fixed blockchain rules.
-
Does importing keyhotee works?
-
PSA: for people trying to get this to work on debian and getting import errors for keys, make sure that you compile with gcc 4.8, as gcc 4.7 doesn't work (compiles correctly but then crashes randomly or fails importing keys in weird places...)
-
I think its already been said but "wallet_get_account" never seems to update
while "blockchain_get_account_record" and "blockchain_get_account_record_by_id" update just fine.
it looks like all the same data fields only "wallet_get_account" adds:
"index"
"account_address":
"trust_level"
"private_data"
-
I think its already been said but "wallet_get_account" never seems to update
while "blockchain_get_account_record" and "blockchain_get_account_record_by_id" update just fine.
it looks like all the same data fields only "wallet_get_account" adds:
"index"
"account_address":
"trust_level"
"private_data"
I thought this was fixed, are you on latest?
-
Hi,
i wonder why do the net votes for delegates never change? Since some delegates producing blocks without missing a single opportunity, other delegates never produced a block at all.
I had the impression that delegate election is forced by the network itself?
It is because there is almost no transaction volume by regular use.
-
I think its already been said but "wallet_get_account" never seems to update
while "blockchain_get_account_record" and "blockchain_get_account_record_by_id" update just fine.
it looks like all the same data fields only "wallet_get_account" adds:
"index"
"account_address":
"trust_level"
"private_data"
I thought this was fixed, are you on latest?
Xeldal (unlocked) >>> about
{
"bitshares_toolkit_revision": "26d5341e0fc5bf34971259141bec7e2468b862af",
"bitshares_toolkit_revision_age": "4 hours ago",
"fc_revision": "51de9e6abf1bc2fbd31794f7b625d83a82f67d3d",
"fc_revision_age": "24 hours ago",
"compile_date": "compiled on Jun 10 2014 at 18:24:51"
}
-
I think its already been said but "wallet_get_account" never seems to update
while "blockchain_get_account_record" and "blockchain_get_account_record_by_id" update just fine.
it looks like all the same data fields only "wallet_get_account" adds:
"index"
"account_address":
"trust_level"
"private_data"
I thought this was fixed, are you on latest?
Xeldal (unlocked) >>> about
{
"bitshares_toolkit_revision": "26d5341e0fc5bf34971259141bec7e2468b862af",
"bitshares_toolkit_revision_age": "4 hours ago",
"fc_revision": "51de9e6abf1bc2fbd31794f7b625d83a82f67d3d",
"fc_revision_age": "24 hours ago",
"compile_date": "compiled on Jun 10 2014 at 18:24:51"
}
Have you rescanned since the fix?
Rescan and then watch for changes - if it still gets out of sync then file an isse
-
Have you rescanned since the fix?
Rescan and then watch for changes - if it still gets out of sync then file an isse
After
Xeldal (unlocked) >>> wallet_rescan_blockchain
Rescanning blockchain...
|----------------------------------------------------------------------------------------------------|
|====================================================================================================|
Scan complete.
OK
I still get
Xeldal (unlocked) >>> blockchain_get_account_record_by_id 42
{
"id": 42,
"name": "init-delegate-42",
"public_data": null,
"owner_key": "XTS5iNWht2kEmdWNDf6cRz6HiVEs2zk3X61GpQvrQT1wQf66xucit",
...~
"blocks_produced": 20,
"blocks_missed": 103,
"pay_balance": 647337,
}
Xeldal (unlocked) >>> wallet_get_account init-delegate-42
{
"index": 4,
"id": 42,
"name": "init-delegate-42",
"public_data": null,
"owner_key": "XTS5iNWht2kEmdWNDf6cRz6HiVEs2zk3X61GpQvrQT1wQf66xucit",
...~
"votes_for": 88888017429,
"votes_against": 0,
"blocks_produced": 8,
"blocks_missed": 25,
"pay_balance": 76161,
I would file an issue but Im not at all familiar with how that is done.
-
I filed it, thanks for letting us know
-
FYI.
dumpprivkey function does not work.
-
Am I still on the main block chain?
harvey (unlocked) >>> get_info
{
"blockchain_head_block_num": 846,
"blockchain_head_block_time": "20140611T144330",
"blockchain_confirmation_requirement": 290,
"blockchain_average_delegate_participation": 5.7433808553971488,
"network_num_connections": 1,
"wallet_unlocked_seconds_remaining": 99999999841,
"wallet_next_block_production_time": "20140611T145845",
"wallet_seconds_until_next_block_production": 235,
"wallet_local_time": "20140611T145450",
"blockchain_random_seed": "5d454f22e86c8eeb0ac1505e1b70b68351a101ff",
"blockchain_shares": 9999977806267,
"network_num_connections_max": 12,
"network_protocol_version": 101,
"wallet_open": true,
"wallet_unlocked_until": "19880505T134930.027953",
"wallet_version": 100
}
-
My stats:
"blockchain_head_block_num": 5562,
"blockchain_head_block_time": "20140611T150630",
-
My stats:
"blockchain_head_block_num": 5562,
"blockchain_head_block_time": "20140611T150630",
here is mine..
get_info
{
"blockchain_head_block_num": 2892,
"blockchain_head_block_time": "20140611T151500",
-
"blockchain_head_block_num": 4360,
"blockchain_head_block_time": "20140611T151115",
-
UTC+8 23:26
"blockchain_head_block_num": 5624,
"blockchain_head_block_time": "20140611T151900",
-
Can anyone explain the difference in blockchain_head_block_num?
-
Can anyone explain the difference in blockchain_head_block_num?
Some people are on forks, eric is working on updating the fork resolution on another branch
-
seems like i'm on fork also
"blockchain_head_block_num": 5543,
"blockchain_head_block_time": "20140611T160700",
"blockchain_confirmation_requirement": 291,
"blockchain_average_delegate_participation": 28.877642155403393,
"network_num_connections": 3,
-
For now if you want to sync up you can save your wallet / wipe data dir / copy wallet back in
-
I have been late for registering as initial delegate.
So I tried to register on blockchain as mentioned by ByteMaster. When I tried "wallet_account_register", it said I have insufficient fund to register (as I have zero funding).
Did anyone try register on blockchain before? Or anyway to get sufficient fund to register?
-
For now if you want to sync up you can save your wallet / wipe data dir / copy wallet back in
I deleted wallet and reimported my delegate keys. Now get_info gets:
"blockchain_head_block_num": 5730,
"blockchain_head_block_time": "20140611T190730",
-
I just added a query to NTP to help keep all delegates on the same approximate time. This should help cut down of any forks caused for this reason and simplify the setup of delegates.
-
"blockchain_head_block_num": 5847,
"blockchain_head_block_time": "2014-06-11 T 19:43:15",
-
get_info
{
"blockchain_head_block_num": 5739,
"blockchain_head_block_time": "20140611T201700",
-
can't build because ntohl() in bitshares_toolkit/libraries/fc/src/network/ntp.cpp
add headfile
#include <arpa/inet.h>
-
fresh build and now i can't find ./bitshares_client
root@we:~/bitshares_toolkit/programs/client# gdb ./bitshares_client
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
./bitshares_client: No such file or directory.
(gdb) run
Starting program:
No executable file specified.
Use the "file" or "exec-file" command.
Edit: changed ~/bitshares_toolkit# to ~/bitshares_toolkit/programs/client#
-
fresh build and now i can't find ./bitshares_client
root@we:~/bitshares_toolkit# gdb ./bitshares_client
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
./bitshares_client: No such file or directory.
(gdb) run
Starting program:
No executable file specified.
Use the "file" or "exec-file" command.
The client is in ~/bitshares_toolkit/programs/client/
gdb ~/bitshares_toolkit/programs/client/bitshares_client
-
the newst code can't create wallet, here is the error msg
(wallet closed) >>> wallet_create default
new_passphrase:
new_passphrase (verify):
20015 brain_key_too_short: brain key is too short
{}
th_a client.cpp:686 wallet_create
{}
th_a common_api_client.cpp:212 wallet_create
{"command":"wallet_create"}
th_a cli.cpp:574 execute_command
-
I havent done anything since I've started the delegate 2 days ago.
Current situation:
"blockchain_head_block_num": 5892,
"blockchain_head_block_time": "20140611T202600",
Is there a convenient way to check If I'm on the "main" chain ? ( or at least with some confidence )
The number I have looks consistent with the one bytemaster shows. (it increased proportionally with time difference)
Does this mean that my delegate synchronized to the "main" blockchain ? (or at least the one bytemaster posted)
-
The client is in ~/bitshares_toolkit/programs/client/
~/bitshares_toolkit/programs/client/bitshares_client to run it.
I tried to ninja edit but you got me. Its not in that location either. At least not in my build.
-
I have rip the date
still in the fork chain
delegate (unlocked) >>> info
{
"blockchain_head_block_num": 2946,
"blockchain_head_block_time": "20140611T203545",
-
nevermind about my missing ./bitshares_client
I failed to notice it didn't finish # make
[ 39%] Building CXX object libraries/fc/CMakeFiles/fc.dir/src/network/ntp.cpp.o
/root/bitshares_toolkit/libraries/fc/src/network/ntp.cpp: In static member function ‘static fc::time_point fc::ntp::get_time()’:
/root/bitshares_toolkit/libraries/fc/src/network/ntp.cpp:40:70: error: ‘ntohl’ was not declared in this scope
return fc::time_point() + fc::seconds( ntohl((time_t)recv_buf[4]) - 2208988800U);
^
/root/bitshares_toolkit/libraries/fc/src/network/ntp.cpp:41:3: warning: control reaches end of non-void function [-Wreturn-type]
}
^
make[2]: *** [libraries/fc/CMakeFiles/fc.dir/src/network/ntp.cpp.o] Error 1
make[1]: *** [libraries/fc/CMakeFiles/fc.dir/all] Error 2
make: *** [all] Error 2
-
nevermind about my missing ./bitshares_client
I failed to notice it didn't finish # make
[ 39%] Building CXX object libraries/fc/CMakeFiles/fc.dir/src/network/ntp.cpp.o
/root/bitshares_toolkit/libraries/fc/src/network/ntp.cpp: In static member function ‘static fc::time_point fc::ntp::get_time()’:
/root/bitshares_toolkit/libraries/fc/src/network/ntp.cpp:40:70: error: ‘ntohl’ was not declared in this scope
return fc::time_point() + fc::seconds( ntohl((time_t)recv_buf[4]) - 2208988800U);
^
/root/bitshares_toolkit/libraries/fc/src/network/ntp.cpp:41:3: warning: control reaches end of non-void function [-Wreturn-type]
}
^
make[2]: *** [libraries/fc/CMakeFiles/fc.dir/src/network/ntp.cpp.o] Error 1
make[1]: *** [libraries/fc/CMakeFiles/fc.dir/all] Error 2
make: *** [all] Error 2
git submodule update?
-
https://bitsharestalk.org/index.php?topic=4928.msg65426#msg65426
nevermind about my missing ./bitshares_client
I failed to notice it didn't finish # make
[ 39%] Building CXX object libraries/fc/CMakeFiles/fc.dir/src/network/ntp.cpp.o
/root/bitshares_toolkit/libraries/fc/src/network/ntp.cpp: In static member function ‘static fc::time_point fc::ntp::get_time()’:
/root/bitshares_toolkit/libraries/fc/src/network/ntp.cpp:40:70: error: ‘ntohl’ was not declared in this scope
return fc::time_point() + fc::seconds( ntohl((time_t)recv_buf[4]) - 2208988800U);
^
/root/bitshares_toolkit/libraries/fc/src/network/ntp.cpp:41:3: warning: control reaches end of non-void function [-Wreturn-type]
}
^
make[2]: *** [libraries/fc/CMakeFiles/fc.dir/src/network/ntp.cpp.o] Error 1
make[1]: *** [libraries/fc/CMakeFiles/fc.dir/all] Error 2
make: *** [all] Error 2
-
https://bitsharestalk.org/index.php?topic=4928.msg65426#msg65426
Yes, I saw that.
I rebuilt with latest and it got through # make
Now I'm having issues creating wallet. I get "brain key is too short"
(wallet closed) >>> wallet_create Xeldal
new_passphrase:
new_passphrase (verify):
20015 brain_key_too_short: brain key is too short
{}
th_a client.cpp:686 wallet_create
{}
th_a common_api_client.cpp:212 wallet_create
{"command":"wallet_create"}
th_a cli.cpp:586 execute_command
(wallet closed) >>>
I'm using a 26 character passphrase.
-
https://bitsharestalk.org/index.php?topic=4928.msg65426#msg65426
Yes, I saw that.
I rebuilt with latest and it got through # make
Now I'm having issues creating wallet. I get "brain key is too short"
(wallet closed) >>> wallet_create Xeldal
new_passphrase:
new_passphrase (verify):
20015 brain_key_too_short: brain key is too short
{}
th_a client.cpp:686 wallet_create
{}
th_a common_api_client.cpp:212 wallet_create
{"command":"wallet_create"}
th_a cli.cpp:586 execute_command
(wallet closed) >>>
I'm using a 26 character passphrase.
I'm getting the same error on windows and ubuntu. I was able to copy my old wallet over into the .BitSharesXTS/wallets directory and open it just fine though.
-
Fixed brain key size issue.
-
can't build because ntohl() in bitshares_toolkit/libraries/fc/src/network/ntp.cpp
add headfile
#include <arpa/inet.h>
This should be fixed in latest builds.
-
Hi bm,
Is there a way to get private key out of my bitshares wallet. I accidentally lost the key that i imported to my wallet
-
Hi bm,
Is there a way to get private key out of my bitshares wallet. I accidentally lost the key that i imported to my wallet
not yet
-
it is on the todo list
-
watch here: https://github.com/BitShares/bitshares_toolkit/issues/275
-
Emmm. I re-installed Ubuntu 14.04. Then errors occurred when I was cloning the codes.
git submodule update
Cloning into 'libraries/fc'...
remote: Counting objects: 4972, done.
remote: Compressing objects: 100% (2245/2245), done.
remote: Total 4972 (delta 2585), reused 4716 (delta 2419)
Receiving objects: 100% (4972/4972), 2.81 MiB | 144.00 KiB/s, done.
Resolving deltas: 100% (2585/2585), done.
Checking connectivity... done.
fatal: reference is not a tree: 3d38c58691c1f4d3e93d94c30b655b17aa90a7b9
Cloning into 'programs/client/htdocs'...
remote: Reusing existing pack: 891, done.
remote: Counting objects: 315, done.
remote: Compressing objects: 100% (315/315), done.
remote: Total 1206 (delta 237), reused 0 (delta 0)
Receiving objects: 100% (1206/1206), 2.50 MiB | 91.00 KiB/s, done.
Resolving deltas: 100% (791/791), done.
Checking connectivity... done.
Submodule path 'programs/client/htdocs': checked out 'f316a1638927fb11eddb75d29df77ec43952fe4c'
Cloning into 'vendor'...
remote: Reusing existing pack: 171, done.
remote: Total 171 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (171/171), 345.64 KiB | 200.00 KiB/s, done.
Resolving deltas: 100% (2/2), done.
Checking connectivity... done.
Submodule path 'vendor': checked out 'f5a1391ae6e6b681f48fa14929de4acf075cb64d'
Unable to checkout '3d38c58691c1f4d3e93d94c30b655b17aa90a7b9' in submodule path 'libraries/fc'
-
cmake file broken again. please check following error message
-- Configuring incomplete, errors occurred!
See also "/home/daniel/bitshares_toolkit/CMakeFiles/CMakeOutput.log".
daniel@ubuntu:~/bitshares_toolkit$ cmake .
CMake Error at CMakeLists.txt:8 (include):
include could not find load file:
GetGitRevisionDescription
CMake Error at CMakeLists.txt:9 (get_git_head_revision):
Unknown CMake command "get_git_head_revision".
-- Configuring incomplete, errors occurred!
-
Go to libraries/fc
git checkout f01d25788e88d0a77520f192719bc2dd6898d6b7
-
[ 98%] Built target deterministic_signature_test
Scanning dependencies of target dev_tests
[ 98%] Building CXX object tests/CMakeFiles/dev_tests.dir/dev_tests.cpp.o
/data/bts/0612/bitshares_toolkit/tests/dev_tests.cpp:3:27: fatal error: dev_fixture.hpp: No such file or directory
#include "dev_fixture.hpp"
^
compilation terminated.
make[2]: *** [tests/CMakeFiles/dev_tests.dir/dev_tests.cpp.o] Error 1
make[1]: *** [tests/CMakeFiles/dev_tests.dir/all] Error 2
make: *** [all] Error 2
I compiled the project everyday and use the day time as folder name .
This error is occurred the first time. ( under the 0612 folder )
root@xxxx:/data/bts# ll
total 28
drwxr-xr-x 7 root root 4096 Jun 12 14:08 ./
drwxr-xr-x 3 root root 4096 Jun 8 09:36 ../
drwxr-xr-x 3 root root 4096 Jun 9 13:12 0609/
drwxr-xr-x 3 root root 4096 Jun 10 12:34 0610/
drwxr-xr-x 3 root root 4096 Jun 11 10:11 0611/
drwxr-xr-x 3 root root 4096 Jun 12 14:08 0612/
-
When are votes for a delegate counting??
I made a new delegate, voted for him and transmitted fund to that delegate:
default (unlocked) >>> wallet_list_unspent_balances
BALANCE OWNER VOTE
--------------------------------------------------------------------------------------------------------------------------
6000000000 XTS4zCs7x5h1cjLSouVH6LTKRvVTzyfnAuLt +xeroc-tmp
However no votes are counted:
default (unlocked) >>> blockchain_get_account_record xeroc-tmp
{
"id": 309,
"name": "xeroc-tmp",
"public_data": {},
"owner_key": "XTS5tc6NTjfE78hZAJYuZU8Q1uYSzAo48G6xHCdvY1JrBtHHFYgta",
"active_key_history": [[
"20140611T091000",
"XTS5tc6NTjfE78hZAJYuZU8Q1uYSzAo48G6xHCdvY1JrBtHHFYgta"
]
],
"delegate_info": {
"votes_for": 0,
"votes_against": 0,
"blocks_produced": 0,
"blocks_missed": 0,
"pay_balance": 0,
"next_secret_hash": "0000000000000000000000000000000000000000",
"last_block_num_produced": 4294967295
},
"registration_date": "20140611T091000",
"last_update": "20140611T091000",
"meta_data": null
}
-
[ 98%] Built target deterministic_signature_test
Scanning dependencies of target dev_tests
[ 98%] Building CXX object tests/CMakeFiles/dev_tests.dir/dev_tests.cpp.o
/data/bts/0612/bitshares_toolkit/tests/dev_tests.cpp:3:27: fatal error: dev_fixture.hpp: No such file or directory
#include "dev_fixture.hpp"
^
compilation terminated.
make[2]: *** [tests/CMakeFiles/dev_tests.dir/dev_tests.cpp.o] Error 1
make[1]: *** [tests/CMakeFiles/dev_tests.dir/all] Error 2
make: *** [all] Error 2
I compiled the project everyday and use the day time as folder name .
This error is occurred the first time. ( under the 0612 folder )
root@xxxx:/data/bts# ll
total 28
drwxr-xr-x 7 root root 4096 Jun 12 14:08 ./
drwxr-xr-x 3 root root 4096 Jun 8 09:36 ../
drwxr-xr-x 3 root root 4096 Jun 9 13:12 0609/
drwxr-xr-x 3 root root 4096 Jun 10 12:34 0610/
drwxr-xr-x 3 root root 4096 Jun 11 10:11 0611/
drwxr-xr-x 3 root root 4096 Jun 12 14:08 0612/
same for me here! Got same error first time now!
-
same for me here! Got same error first time now!
+ 1 from my side :-(
-
Scanning dependencies of target dev_tests
[ 98%] Building CXX object tests/CMakeFiles/dev_tests.dir/dev_tests.cpp.o
/Users/maurits/bitsharesxts/bitshares_toolkit/tests/dev_tests.cpp:3:10: fatal error: 'dev_fixture.hpp' file not found
#include "dev_fixture.hpp"
^
1 error generated.
make[2]: *** [tests/CMakeFiles/dev_tests.dir/dev_tests.cpp.o] Error 1
make[1]: *** [tests/CMakeFiles/dev_tests.dir/all] Error 2
make: *** [all] Error 2
Same here.
-
Scanning dependencies of target dev_tests
[ 98%] Building CXX object tests/CMakeFiles/dev_tests.dir/dev_tests.cpp.o
/Users/maurits/bitsharesxts/bitshares_toolkit/tests/dev_tests.cpp:3:10: fatal error: 'dev_fixture.hpp' file not found
#include "dev_fixture.hpp"
^
1 error generated.
make[2]: *** [tests/CMakeFiles/dev_tests.dir/dev_tests.cpp.o] Error 1
make[1]: *** [tests/CMakeFiles/dev_tests.dir/all] Error 2
make: *** [all] Error 2
Same here.
You can comment out the dev_tests in the CMakeLists.txt in the tests folder. Although I think if you pull the latest that fix has already been made.
#add_executable( dev_tests dev_tests.cpp )
#target_link_libraries( dev_tests deterministic_openssl_rand bts_client bts_cli bts_wallet bts_blockchain bts_net bitcoin fc ${BOOST_LIBRARIES} ${OPENSSL_LIBRARIES} ${PLATFORM_SPECIFIC_LIBS} ${crypto_library} ${rt_library} )
-
confirm .. latest git-head compiles smoothly
-
I am not sure what is going on with multiple blockchains being tracked by various clients. I have latest code, pulled today, running on two computers. One is a delegate node on VPS server and one is a desktop client. They seem to be on different blockchains.
delegate node
get_info
{
"blockchain_head_block_num": 6219,
"blockchain_head_block_time": "20140612T163445",
desktop client
get_info
{
"blockchain_head_block_num": 5993,
"blockchain_head_block_time": "20140612T155045",
-
I am not sure what is going on with multiple blockchains being tracked by various clients. I have latest code, pulled today, running on two computers. One is a delegate node on VPS server and one is a desktop client. They seem to be on different blockchains.
delegate node
get_info
{
"blockchain_head_block_num": 6219,
"blockchain_head_block_time": "20140612T163445",
desktop client
get_info
{
"blockchain_head_block_num": 5993,
"blockchain_head_block_time": "20140612T155045",
Yep... the chains are forking left and right because the network code doesn't know how to sync. Eric is working through bugs revealed in his testing and has some fixes developed but not yet verified. I think our problems are a combination of time sync and network latency. Once we have his code ready we will do another reset and check to make sure we have solved the forking issue.
-
I hope you will give a chance to register as delegate to other users that was too late for the latest test.
-
I hope you will give a chance to register as delegate to other users that was too late for the latest test.
The next test we will have everyone start voting on delegates like the real thing.
Anyone can register as a delegate at any time, this was just for *initial* delegates.
Whether or not you get voted in is another matter.
-
If we're not running into bugs, Is there anything special us non power users could do to help? Does it help to recompile and test the latest?
Sent from my SCH-I535 using Tapatalk
-
If we're not running into bugs, Is there anything special us non power users could do to help? Does it help to recompile and test the latest?
Sent from my SCH-I535 using Tapatalk
We are about to merge in the latest from Eric and relaunch the network and hopefully avoid forks this time.
-
Thanks for participating!
We are taking this network down and will be launching again soon. We will start helping people with their delegate campaigns during this next run.