BitShares Forum
Main => General Discussion => Topic started by: toast on June 20, 2014, 08:46:34 pm
-
Hey everyone I am sad to report that we have to reset this dry run due to a major flaw in the initial condition setup resulting in the negative votes-for everyone saw. Unfortunately I cannot fix this without a reset.
New chain has launched that fixes this issue and the double registration issue.
Let's begin!
* Step 1 **REQUIRED**: Open this in another tab https://www.youtube.com/watch?v=_D0ZQPqeJkk
* Step 2: Wipe all your old data-dirs. Note that you might have both ~/.BitSharesXTS and ~/BitShares\ XTS - kill them all.
* Step 3: Pull latest and build.
* Optional Step 4: If you are an initial delegate and a good citizen, do what you did before (import old private keys, make sure to wallet_enable_delegate_block_production). Details are sparse on purpose, since you probably want to skip this and go straight to 5.
* Step 5: Follow this guide: https://github.com/BitShares/bitshares_toolkit/wiki/DPOS-Registering-Names-And-Delegates
You will notice that you need funds to register your name / register as delegate. You have two options:
* import a key with funds
* ask someone nicely
This is the tech support thread. We'll open another related to delegate campaigns in the next day or two.
Edit: Blocks will be reaaaal slow near the start. Initial delegates, get online!
-
Can we use BIP to pay registration fee ? Has the BIP function been implemented ?
-
I've seen 1 block now.
Can someone send me some fund to register as delegate? Thanks in advance.
XTS8eghNapYmPzsmweCn7EVQLDqUKH91hj3GCowusMm8vRhkLM5Zk
-
Can we use BIP to pay registration fee ? Has the BIP function been implemented ?
No, probably won't be for XT
-
Getting build errors
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 function ‘boost::unit_test::test_suite* init_unit_test_suite(int, char**)’:
/root/bitshares_toolkit/tests/wallet_tests.cpp:597:62: error: base operand of ‘->’ has non-pointer type ‘fc::directory_iterator’
if ( fc::is_directory( *directory_itr ) && (directory_itr->filename().string()[0] != '_') )
^
/root/bitshares_toolkit/tests/wallet_tests.cpp:604:85: error: base operand of ‘->’ has non-pointer type ‘fc::directory_iterator’
directory_itr->filename().string());
^
/root/bitshares_toolkit/tests/wallet_tests.cpp:609:85: error: base operand of ‘->’ has non-pointer type ‘fc::directory_iterator’
directory_itr->filename().string());
^
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
-
compile error at 99%-100%
[100%] Building CXX object tests/CMakeFiles/wallet_tests.dir/wallet_tests.cpp.o
/home/daniel/bitshares_toolkit/tests/wallet_tests.cpp: In function 鈥榖oost::unit_test::test_suite* init_unit_test_suite(int, char**)鈥
/home/daniel/bitshares_toolkit/tests/wallet_tests.cpp:597:62: error: base operand of 鈥>鈥has non-pointer type 鈥榝c::directory_iterator鈥
if ( fc::is_directory( *directory_itr ) && (directory_itr->filename().string()[0] != '_') )
^
/home/daniel/bitshares_toolkit/tests/wallet_tests.cpp:604:85: error: base operand of 鈥>鈥has non-pointer type 鈥榝c::directory_iterator鈥
directory_itr->filename().string());
^
/home/daniel/bitshares_toolkit/tests/wallet_tests.cpp:609:85: error: base operand of 鈥>鈥has non-pointer type 鈥榝c::directory_iterator鈥
directory_itr->filename().string());
^
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
-
Getting build errors
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 function ‘boost::unit_test::test_suite* init_unit_test_suite(int, char**)’:
/root/bitshares_toolkit/tests/wallet_tests.cpp:597:62: error: base operand of ‘->’ has non-pointer type ‘fc::directory_iterator’
if ( fc::is_directory( *directory_itr ) && (directory_itr->filename().string()[0] != '_') )
^
/root/bitshares_toolkit/tests/wallet_tests.cpp:604:85: error: base operand of ‘->’ has non-pointer type ‘fc::directory_iterator’
directory_itr->filename().string());
^
/root/bitshares_toolkit/tests/wallet_tests.cpp:609:85: error: base operand of ‘->’ has non-pointer type ‘fc::directory_iterator’
directory_itr->filename().string());
^
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
Known issue... safe to ignore, it is just one of the tests.
-
I got something like below, notice the wallet_seconds_until_next_block_production is -14. Any idea?
default (unlocked) >>> get_info
{
"blockchain_head_block_num": 4,
"blockchain_head_block_time": "20140620T212300",
"blockchain_head_block_time_rel": "2 minutes old",
"blockchain_confirmation_requirement": 244,
"blockchain_average_delegate_participation": 13.333333333333334,
"network_num_connections": 4,
"ntp_time": "20140620T212514.774930",
"ntp_error_seconds": -0.033466000000000003,
"wallet_unlocked_seconds_remaining": 99999796,
"wallet_next_block_production_time": "20140620T212500",
"wallet_seconds_until_next_block_production": -14,
"wallet_local_time": "20140620T212514",
"blockchain_random_seed": "afeecdf51c48e6d33f41a334e0e57d554cdcd86f",
"blockchain_shares": 9999853094228,
"network_num_connections_max": 12,
"network_protocol_version": 103,
"wallet_open": true,
"wallet_unlocked_until": "20170821T070830",
"wallet_version": 100
}
Edit:
seems like caused by this error:
network_get_connection_count() >= _min_delegate_connection_count: Client must have 5 connections before you may produce blocks
-
If you have less than 5 connections, shut down and reconnect.
-
If you have less than 5 connections, shut down and reconnect.
Thanks and it works by restarting client.
-
I've enabled all my delegates.
And I've registered few more.
However I still see some negative VOTES FOR. Is this expected?
6 unelected-delegate-6 -104917529 102557509978 -1.026658773 % 0 1
-
I've enabled all my delegates.
And I've registered few more.
However I still see some negative VOTES FOR. Is this expected?
6 unelected-delegate-6 -104917529 102557509978 -1.026658773 % 0 1
I only fixed half the issue... we can ignore it for this run (it is a harmless bug...). There were two places in the code that needed to change and I only got one of them. I have checked in a fix that should go into effect the next dry run. For now we will just ignore it.
The bug should only effect the unelected initial delegates.
-
I got something like below, notice the wallet_seconds_until_next_block_production is -14. Any idea?
default (unlocked) >>> get_info
{
"blockchain_head_block_num": 4,
"blockchain_head_block_time": "20140620T212300",
"blockchain_head_block_time_rel": "2 minutes old",
"blockchain_confirmation_requirement": 244,
"blockchain_average_delegate_participation": 13.333333333333334,
"network_num_connections": 4,
"ntp_time": "20140620T212514.774930",
"ntp_error_seconds": -0.033466000000000003,
"wallet_unlocked_seconds_remaining": 99999796,
"wallet_next_block_production_time": "20140620T212500",
"wallet_seconds_until_next_block_production": -14,
"wallet_local_time": "20140620T212514",
"blockchain_random_seed": "afeecdf51c48e6d33f41a334e0e57d554cdcd86f",
"blockchain_shares": 9999853094228,
"network_num_connections_max": 12,
"network_protocol_version": 103,
"wallet_open": true,
"wallet_unlocked_until": "20170821T070830",
"wallet_version": 100
}
Edit:
seems like caused by this error:
network_get_connection_count() >= _min_delegate_connection_count: Client must have 5 connections before you may produce blocks
This is a known issue; cause unknown: https://github.com/BitShares/bitshares_toolkit/issues/362
-
network_get_connection_count() >= _min_delegate_connection_count: Client must have 5 connections before you may produce blocks
This is a known issue; cause unknown: https://github.com/BitShares/bitshares_toolkit/issues/362
I think zhangweis identified the issue - we just need better reporting
-
Hi
I have register 2 delegates(welk1n, well) on dry run 3 yesterday.
But could not import the private key on dry run 4, both of the 2 new accounts and the 4 init-delegates (welk1n-d-1,2,3,4)
I pm toast yet, please have a look.
Thanks.
-
the delegate is enabled to produce the block and connection count is 5, but the wallet_next_block_production_time still shown null
"blockchain_head_block_num": 141,
"blockchain_head_block_time": "20140621T002330",
"blockchain_head_block_time_rel": "26 seconds old",
"blockchain_confirmation_requirement": 299,
"blockchain_average_delegate_participation": 36.434108527131784,
"network_num_connections": 5,
"ntp_time": "20140621T002356.302544",
"ntp_error_seconds": -0.92658399999999996,
"wallet_unlocked_seconds_remaining": 0,
"wallet_next_block_production_time": null,
"wallet_seconds_until_next_block_production": null,
"wallet_local_time": "20140621T002356",
"blockchain_random_seed": "6295afbd488cfd9cb1e3f31dc05e560b3e94abd6",
"blockchain_shares": 9999182227629,
"network_num_connections_max": 12,
"network_protocol_version": 103,
"wallet_open": true,
"wallet_unlocked_until": "20140621T001900",
"wallet_version": 100
-
the delegate is enabled to produce the block and connection count is 5, but the wallet_next_block_production_time still shown null
"blockchain_head_block_num": 141,
"blockchain_head_block_time": "20140621T002330",
"blockchain_head_block_time_rel": "26 seconds old",
"blockchain_confirmation_requirement": 299,
"blockchain_average_delegate_participation": 36.434108527131784,
"network_num_connections": 5,
"ntp_time": "20140621T002356.302544",
"ntp_error_seconds": -0.92658399999999996,
"wallet_unlocked_seconds_remaining": 0,
"wallet_next_block_production_time": null,
"wallet_seconds_until_next_block_production": null,
"wallet_local_time": "20140621T002356",
"blockchain_random_seed": "6295afbd488cfd9cb1e3f31dc05e560b3e94abd6",
"blockchain_shares": 9999182227629,
"network_num_connections_max": 12,
"network_protocol_version": 103,
"wallet_open": true,
"wallet_unlocked_until": "20140621T001900",
"wallet_version": 100
You might not be in the active round yet. Wait until next shuffle @ block 202
-
Trying to issue an asset.
>>> wallet_asset_issue 1000000 BEE bitcoiners "Bees are people too"
10 assert_exception: Assert Exception
my->_blockchain->is_valid_symbol( symbol ):
What am I doing wrong?
-
250.0 2014-06-21T01:56:30 bts101 bts101 update bts101 as a delegate 0.000000 XTS 20.981502 XTS 321fca43
pending 2014-06-21T01:56:30 bts101 bts101 update bts101 as a delegate 0.000000 XTS 20.981502 XTS 51f69ce4
double spent when register a delegate， is it a bug?
I just run "wallet_account_update_registration bts101 bts101 null true" once.
-
2 issue about the asset creation,
1)create the HSBC asset cost me 20.9XTS, but the fee cannot show in the transaction history
2)after the asset create successfully, try to issue the asset but failed, when i check the balance, 20.9 more XTS is deducted from my account
-
I completed all my steps to register as a delegate, however the last step of enabling block production is throwing me this:
>> wallet_enable_delegate_block_production fluxer
Command aborted.
EDIT: It seems to have worked, I'm in the delegates list. Going to leave my computer on tonight to hopefully make some blocks.
-
When I leave the client idle, it gives me a warning that I'm going to be logged out if I don't click it in X seconds. Does this mean I'll stop producing blocks if I leave my computer on inactive?
-
2 issue about the asset creation,
1)create the HSBC asset cost me 20.9XTS, but the fee cannot show in the transaction history
2)after the asset create successfully, try to issue the asset but failed, when i check the balance, 20.9 more XTS is deducted from my account
second issue is false alarm,pls ignore it.
-
I completed all my steps to register as a delegate, however the last step of enabling block production is throwing me this:
>> wallet_enable_delegate_block_production fluxer
Command aborted.
EDIT: It seems to have worked, I'm in the delegates list. Going to leave my computer on tonight to hopefully make some blocks.
have you tried "wallet_enable_delegate_block_production fluxer true" ?
-
That worked! This does not include the 'true' part, please update it:
https://github.com/BitShares/bitshares_toolkit/wiki/DPOS-Registering-Names-And-Delegates
-
I just issued TRUST on the blockchain. I will transfer 1000 TRUST to those individuals willing to:
wallet_set_delegate_trust_level fox 1
-
So, my OSX client auto-locked, and I missed my block as a delegate. That needs to be fixed.
-
who can send me some xts for test,when i register delegate,it tells me insufficient funds
here is my address:XTS7FCu7GrAsnLjc5ARuUszjLUY6k14CtVJtjVbm7afjmaCVvxDTP
thank you!
-
@toast @bytemaster
does name collision fixed? or i still cannot import my keyhotee due to delegate renames? alexxy vs unelected-alexxy?
BAD NEWS for ME : still not fixed in current genesis block
I filled issue #382 (https://github.com/BitShares/bitshares_toolkit/issues/382)
-
How can I see a reason why a block was missed by my delegate?
-
How can I see a reason why a block was missed by my delegate?
Same here. I see a few blocks were missed, but now why.
-
Admin, plz see here https://bitsharestalk.org/index.php?topic=5185.msg68172;topicseen#msg68172
-
I see one block signed by my delegate. And the same block missed by another one of my delegates.
-
Night gathers, and now my watch begins.
NAME (* delegate) KEY REGISTERED TRUST LEVEL BLOCK PRODUCTION ENABLED
harvey-longclaw * XTS6wirNprN84XuLQRYxbxRUYwvVJ1vEcXRfe74umqQF37iQnGUYq 2014-06-21T07:47:00 100 YES
harvey-needle * XTS4xYrU6Nc62xsyY955MNNUGNpcDobMxx4ophXKcPjNGTxS5ejWC 2014-06-21T07:47:00 100 YES
harvey-oathkeeper * XTS7g8WfW4wBi1WorzPco4unA2HXRZHowvJh24m1bEgZNr5F7YPo5 2014-06-21T07:47:00 100 YES
-
What are the broadband requirements for running this at the moment? How might this change as delegates become busier? Just wanting to know how important connection speed is / and what the data volumes are likely to be eg in Gb / month.
-
I can't connect with the latest (991ec4), not in linux and not in osx either... :(
seems like seed node is up, though:
$ ping 107.170.30.182
PING 107.170.30.182 (107.170.30.182): 56 data bytes
64 bytes from 107.170.30.182: icmp_seq=0 ttl=47 time=132.586 ms
64 bytes from 107.170.30.182: icmp_seq=1 ttl=47 time=132.939 ms
64 bytes from 107.170.30.182: icmp_seq=2 ttl=47 time=133.373 ms
maybe it's full and doesn't accept connections anymore? Someone else has a public ip seed node I could connect to? Cheers!
-
keyhotee ID - initial delegate issue
I have to accounts with the same key: 'xeroc' (keyhotee id) and unelected-xeroc ...
in my account list 'xeroc' appeared as non-delegate .. so I updated that account to a delegate ... transactions pending for 60 minutes now ..
$ get_info results in
10 assert_exception: Assert Exception
delegate_record.valid() && delegate_record->is_delegate():
{}
th_a wallet.cpp:1256 next_block_production_time
{}
th_a wallet.cpp:1266 next_block_production_time
{}
th_a common_api_client.cpp:1192 get_info
{"command":"get_info"}
th_a cli.cpp:529 execute_command
I suggest to remove all keyhotee-ids initial delegation! and vote for 0 as default!!
Would you please confirm!?
-
It doesn't connect. Only for me? I've tried restarting it 6 to 7 times.
FYI, my VPS located in San Francisco.
bitshares_toolkit/programs/client$ ./bitshares_client
Loading blockchain from "/home/coolspeed/.BitSharesXTS/chain"
Initializing genesis state from built-in genesis file
Loading config "/home/coolspeed/.BitSharesXTS/config.json"
Not starting RPC server, use --server to enable the RPC interface
Attempting to map P2P port 8763 with UPNP...
Listening for P2P connections on port 8763
Attempting to connect to peer 107.170.30.182:8763
(wallet closed) >>> info
{
"blockchain_head_block_num": 0,
"blockchain_head_block_time": "20140621T115909",
"blockchain_head_block_time_rel": "0 second old",
"blockchain_confirmation_requirement": 202,
"blockchain_average_delegate_participation": 0,
"network_num_connections": 0,
"ntp_time": "20140621T115909.387689",
"ntp_error_seconds": -0.035317000000000001,
"wallet_unlocked_seconds_remaining": 0,
"wallet_next_block_production_time": null,
"wallet_seconds_until_next_block_production": null,
"wallet_local_time": "20140621T115909",
"blockchain_random_seed": "0000000000000000000000000000000000000000",
"blockchain_shares": 9999999984056,
"network_num_connections_max": 12,
"network_protocol_version": 103,
"wallet_open": false,
"wallet_unlocked_until": "",
"wallet_version": 100
}
(wallet closed) >>> about
{
"bitshares_toolkit_revision": "991ec4da17429395aacd65a373ead21084848338",
"bitshares_toolkit_revision_age": "10 hours ago",
"fc_revision": "331e6aac7d1ac7a6fd7c0b0fa092099eb25c99a1",
"fc_revision_age": "20 hours ago",
"compile_date": "compiled on Jun 21 2014 at 20:04:39"
}
-
It doesn't connect. Only for me? I've tried restarting it 6 to 7 times.
FYI, my VPS located in San Francisco.
doesn't connect for me either, same git revision, VPS in France. I'm thinking maybe the seed node (seems there's only one in this dry run) has reached his maximum number of connections and doesn't accept new ones?
-
"blockchain_head_block_num": 1064,
"blockchain_head_block_time": "20140621T121700",
"blockchain_head_block_time_rel": "12 seconds old",
"blockchain_confirmation_requirement": 299,
"blockchain_average_delegate_participation": 61.811505507955935,
"network_num_connections": 11,
seems to connect here in Switzerland
-
"blockchain_head_block_num": 1070,
"blockchain_head_block_time": "20140621T122530",
"blockchain_head_block_time_rel": "24 seconds old",
"blockchain_confirmation_requirement": 303,
"blockchain_average_delegate_participation": 61.585365853658537,
"network_num_connections": 40,
"ntp_time": "20140621T122554.457943",
"ntp_error_seconds": -0.0040379999999999999,
-
do you connect through 107.170.30.182:8763 ?
-
do you connect through 107.170.30.182:8763 ?
,{
"addr": "107.170.30.182:38519",
"addrlocal": "xxx.xxx.xxx.xxx:xxxxx",
"services": "00000001",
"lastsend": 1403353891,
"lastrecv": 1403353921,
"bytessent": 121024,
"bytesrecv": 82512,
"conntime": "20140620T214351.588474",
"pingtime": "",
"pingwait": "",
"version": "",
"subver": "bts::net::node",
"inbound": false,
"firewall_status": "not_firewalled",
"startingheight": "",
"banscore": "",
"syncnode": "",
"bitshares_git_revision_sha": "e724df5e08f57522cc69406c7b8f3164952cdacf (different from ours)",
"bitshares_git_revision_unix_timestamp": "20140620T203400",
"bitshares_git_revision_age": "16 hours ago (older than ours)",
"fc_git_revision_sha": "accb6fddcbde110600edaf46de4a749130b90046 (same as ours)",
"fc_git_revision_unix_timestamp": "20140619T195141",
"fc_git_revision_age": "41 hours ago (same as ours)",
"platform": "linux"
}
-
tried git e724df5e, doesn't connect either...
tried on osx with NAT in Spain (upnp says port mapping is successful) and on a linux VPS with a public ip in France, but none of them connects...
-
It doesn't connect. Only for me? I've tried restarting it 6 to 7 times.
FYI, my VPS located in San Francisco.
doesn't connect for me either, same git revision, VPS in France. I'm thinking maybe the seed node (seems there's only one in this dry run) has reached his maximum number of connections and doesn't accept new ones?
There are currently 43 out of 100 connections on the first seed node.
-
I see one block signed by my delegate. And the same block missed by another one of my delegates.
My delegates are missing blocks as well, I am looking into this issue.
-
(http://ho.rebelsquadrons.org/images/alderaan.jpg)
Looks like Alderaan just got blown up... this dry run appears to be a disaster with the following issues:
0) I only partially fixed the negative vote issue
1) Seed node apparently ended upon on a fork it couldn't escape from
2) Seed node started disconnecting peers for inactivity of 5 seconds during the handshake
3) Forks left, right and center.
4) Delegates were missing blocks despite being connected to the network (may be forks)
5) Transactions don't appear to be propagating properly.
We are aware of these issues and are tracking them down. :'( :'( :'(
-
don't worry, it's just another dry run, although the name of this one (a new hope) was maybe not so well chosen ;)
announcing: dry run 5: a walk into Mordor :P
-
Take it easy, BM.
Rome was not built in a day. +5% +5%
-
finally unelected-delegate-61 is producing blocks ... unelected-xeroc cannot produce blocks because its a name collision with my keyhotee ID 'xeroc' (same pubkeys)
-
Take it easy, BM.
Rome was not built in a day. +5% +5%
+5%
-
This is what happens with late friday fixes/relases (: .
Go get some sleep and rest - Its weekend.
-
Having issues registering xeroc-delegate ..
default (unlocked) >>> wallet_account_update_registration xeroc-delegate founder {} true
10 assert_exception: Assert Exception
account.valid(): No such account: xeroc-delegate
{"acct":"xeroc-delegate"}
th_a wallet.cpp:1964 update_registered_account
{"account_to_update":"xeroc-delegate","pay_from_account":"founder","public_data":{},"new_active_key":null,"as_delegate":true,"sign":true}
th_a wallet.cpp:2005 update_registered_account
{}
th_a common_api_client.cpp:542 wallet_account_update_registration
{"command":"wallet_account_update_registration"}
th_a cli.cpp:529 execute_command
default (unlocked) >>> wallet_account_register xeroc-delegate founder {} true
32007 account_already_registered: account already registered
{"name":"xeroc-delegate"}
th_a account_operations.cpp:32 evaluate
{"*this":{"name":"xeroc-delegate","public_data":{},"owner_key":"XTS5znE4mcMULP3iei3QEVBD9kWSwGWGTMauvfyarRvh1LsuW6WvM","active_key":"XTS5znE4mcMULP3iei3QEVBD9kWSwGWGTMauvfyarRvh1LsuW6WvM","is_delegate":true,"meta_data":null}}
th_a account_operations.cpp:69 evaluate
{"op":{"type":"register_account_op_type","data":{"name":"xeroc-delegate","public_data":{},"owner_key":"XTS5znE4mcMULP3iei3QEVBD9kWSwGWGTMauvfyarRvh1LsuW6WvM","active_key":"XTS5znE4mcMULP3iei3QEVBD9kWSwGWGTMauvfyarRvh1LsuW6WvM","is_delegate":true,"meta_data":null}}}
th_a operation_factory.hpp:51 evaluate
{"trx":{"expiration":null,"delegate_id":null,"operations":[{"type":"register_account_op_type","data":{"name":"xeroc-delegate","public_data":{},"owner_key":"XTS5znE4mcMULP3iei3QEVBD9kWSwGWGTMauvfyarRvh1LsuW6WvM","active_key":"XTS5znE4mcMULP3iei3QEVBD9kWSwGWGTMauvfyarRvh1LsuW6WvM","is_delegate":true,"meta_data":null}},{"type":"withdraw_op_type","data":{"balance_id":"XTSLTb7gFoGgwW2zeGRu8AiwJc9D8drADmSy","amount":20981502,"claim_input_data":""}}],"signatures":["1f82caa7b4fcf303cb4fb06fba4bccb286a3c9b3e4a1b39b4c4cb693cc4ecbd2d63b902182233bc5bfa02542fde49e20754c469828a02604749911e8e2b57c56c8"]}}
th_a transaction_evaluation_state.cpp:149 evaluate
{"trx":{"expiration":null,"delegate_id":null,"operations":[{"type":"register_account_op_type","data":{"name":"xeroc-delegate","public_data":{},"owner_key":"XTS5znE4mcMULP3iei3QEVBD9kWSwGWGTMauvfyarRvh1LsuW6WvM","active_key":"XTS5znE4mcMULP3iei3QEVBD9kWSwGWGTMauvfyarRvh1LsuW6WvM","is_delegate":true,"meta_data":null}},{"type":"withdraw_op_type","data":{"balance_id":"XTSLTb7gFoGgwW2zeGRu8AiwJc9D8drADmSy","amount":20981502,"claim_input_data":""}}],"signatures":["1f82caa7b4fcf303cb4fb06fba4bccb286a3c9b3e4a1b39b4c4cb693cc4ecbd2d63b902182233bc5bfa02542fde49e20754c469828a02604749911e8e2b57c56c8"]}}
th_a chain_database.cpp:1006 evaluate_transaction
{"trx":{"expiration":null,"delegate_id":null,"operations":[{"type":"register_account_op_type","data":{"name":"xeroc-delegate","public_data":{},"owner_key":"XTS5znE4mcMULP3iei3QEVBD9kWSwGWGTMauvfyarRvh1LsuW6WvM","active_key":"XTS5znE4mcMULP3iei3QEVBD9kWSwGWGTMauvfyarRvh1LsuW6WvM","is_delegate":true,"meta_data":null}},{"type":"withdraw_op_type","data":{"balance_id":"XTSLTb7gFoGgwW2zeGRu8AiwJc9D8drADmSy","amount":20981502,"claim_input_data":""}}],"signatures":["1f82caa7b4fcf303cb4fb06fba4bccb286a3c9b3e4a1b39b4c4cb693cc4ecbd2d63b902182233bc5bfa02542fde49e20754c469828a02604749911e8e2b57c56c8"]}}
th_a chain_database.cpp:1345 store_pending_transaction
{"account_name":"xeroc-delegate","data":{}}
th_a client.cpp:2229 wallet_account_register
{}
th_a common_api_client.cpp:522 wallet_account_register
{"command":"wallet_account_register"}
th_a cli.cpp:529 execute_command
default (unlocked) >>> wallet_account_update_registration xeroc-delegate founder {} true
10 assert_exception: Assert Exception
account.valid(): No such account: xeroc-delegate
{"acct":"xeroc-delegate"}
th_a wallet.cpp:1964 update_registered_account
{"account_to_update":"xeroc-delegate","pay_from_account":"founder","public_data":{},"new_active_key":null,"as_delegate":true,"sign":true}
th_a wallet.cpp:2005 update_registered_account
{}
th_a common_api_client.cpp:542 wallet_account_update_registration
{"command":"wallet_account_update_registration"}
th_a cli.cpp:529 execute_command
-
Could you please turn my delegate name "coolspeed" to "unelected-coolspeed" or something else to let me use it in the real chain?
UPDATE:
If what bytemaster infers in the following is what I am reporting, then just ignore me. Hope it be fixed next time. Thanks.
0) I only partially fixed the negative vote issue
-
This is strange. Some delegates don't miss any blocks, others miss many. My delegate node (bitcoiners) seems to be missing a lot of blocks despite being constantly on.
blockchain_list_delegates 0 10
ID NAME VOTES FOR VOTES AGAINST NET VOTES BLOCKS PRODUCED BLOCKS MISSED
323 btsjohn 10474081729 0 0.1047640741 % 19 0
340 bitcoiners 2816857644 300000 0.02817183174 % 6 12
There seem to be a lot of forks though, maybe this is the reason for missed blocks.
>>> list_errors
default (unlocked) >>> list_forks
[
570,
582,
618,
634,
640,
691,
705,
724,
777,
793,
818,
829,
832,
834,
880,
883,
885,
939,
944,
958,
993,
1038,
1041,
1043,
1096,
1099,
1102,
1141,
1144,
1178,
1200,
1203,
1219,
1226,
1239,
1255,
1286,
1299,
1318,
1333,
1341
]
>>> get_info
{
"blockchain_head_block_num": 1354,
"blockchain_head_block_time": "20140621T162730",
"blockchain_head_block_time_rel": "59 seconds old",
"blockchain_confirmation_requirement": 302,
"blockchain_average_delegate_participation": 63.046192259675408,
"network_num_connections": 6,
-
blockchain_list_delegates 0 10
ID NAME VOTES FOR VOTES AGAINST NET VOTES BLOCKS PRODUCED BLOCKS MISSED
323 btsjohn 10474081729 0 0.1047640741 % 19 0
340 bitcoiners 2816857644 300000 0.02817183174 % 6 12
(http://4.bp.blogspot.com/-kOW34fxaSFk/U6W3156GJKI/AAAAAAAAC4c/qCA28O98-4k/s1600/Screenshot+2014-06-21+19.38.17.png)
-
Transaction propagation bug appears to be resolved with latest commit. Working on some others.
-
Updated version of OS X wallet is now out.
-
One of my test delegates that I intentionally made misbehaving is not getting downvotes although he has 35 missed blocks.
322 secondtester 89026995 0 0.0008904976421 % 0 35
-
Could you please turn my delegate name "coolspeed" to "unelected-coolspeed" or something else to let me use it in the real chain?
UPDATE:
If what bytemaster infers in the following is what I am reporting, then just ignore me. Hope it be fixed next time. Thanks.
0) I only partially fixed the negative vote issue
If I did not get it wrong, the name "coolspeed" has not been registered as an initial delegate, or what with a bunch of down votes. That time, the names such as mine and "crazybit" etc. were all registered for electing.
FYI.
Sent from my iPhone using Tapatalk
-
I think I've found something really strange.
I built with the latest codes one hour ago, then restored the wallet files backed up two days ago after dry run 4 was started.
Guess what? I have accounts spartako1 , spartako3, spartako4 in my wallet, all of which were NOT created by me, I swear. (unelected-heyd-1, unelected-heyd-2, unelected-heyd-3 are the ones in the genesis json file while vote-heyd was created by me actually.)
heyd (unlocked) >>> wallet_list_my_accounts
NAME (* delegate) KEY REGISTERED TRUST LEVEL BLOCK PRODUCTION ENABLED
spartako1 * XTS68Ab5SG3sz6miKjFQ3B9FdZojk8FZeK1rtuQzzHnbi4Shv971w 2014-06-21T02:50:00 10 YES
spartako3 * XTS6zv9T6DTya4jhDRrtWq24rPafisZE2NKbqAkhZHzxdeTmqvcnK 2014-06-21T02:50:00 10 YES
spartako4 * XTS8j75dYvJVV5KgxrNDjeppEwTqyTCJH7hPMebm2PPAJnuWe83Ry 2014-06-21T02:50:00 10 YES
unelected-heyd-1 * XTS5Q7j3ZAYwjGAuK6AfWiqDuahnah9MVHXxGAr8yjsxWwuEAX9xg 2014-06-20T00:00:00 0 YES
unelected-heyd-2 * XTS5K6TmQjqReTUhWMg3EBjQ26VB6r26jMn4r2VEG2ykWh2xFkUpP 2014-06-20T00:00:00 0 YES
unelected-heyd-3 * XTS5HHx85ASdW3b4UmyV8g2rLyYRfHeTj8aH6E1DTE11jFUBr96as 2014-06-20T00:00:00 0 YES
vote-heyd XTS6AVvY9Ri2FJb6vazyHpgDq4CyzYLcATF4pC3qvra1KF7RcC318 NO 0 N/A
I couldn't believe my eyes. Then I tried to export the private keys/public keys of these three 'new' accounts. Here is what I got:
heyd (unlocked) >>> wallet_account_export_private_key spartako1
"5KNGqS4irbpH6tZQQ(**********)"
heyd (unlocked) >>> wallet_account_export_private_key spartako3
"5Ju42xu7knENxhy4m(**********)"
heyd (unlocked) >>> wallet_account_export_private_key spartako4
"5Je7QTfXBZmehcC1b(**********)"
@spartako , Could you please check whether the first parts of these private keys match the delegates created by you ?
Actually these private keys are the ones of delegates heyd-young, heyd-naive, heyd-simple.
Interesting :
heyd (unlocked) >>> wallet_account_balance
spartako1:
6.312270 XTS
-
i experienced the same problem 2 days ago on RUN 3 and Toast asked me to create a new wallet and re-import my own private key.
I suspect it is a security bug and BM/Toast should look deep into it
I think I've found something really strange.
I built with the latest codes one hour ago, then restored the wallet files backed up two days ago after dry run 4 was started.
Guess what? I have accounts spartako1 , spartako3, spartako4 in my wallet, all of which were NOT created by me, I swear. (unelected-heyd-1, unelected-heyd-2, unelected-heyd-3 are the ones in the genesis json file while vote-heyd was created by me actually.)
heyd (unlocked) >>> wallet_list_my_accounts
NAME (* delegate) KEY REGISTERED TRUST LEVEL BLOCK PRODUCTION ENABLED
spartako1 * XTS68Ab5SG3sz6miKjFQ3B9FdZojk8FZeK1rtuQzzHnbi4Shv971w 2014-06-21T02:50:00 10 YES
spartako3 * XTS6zv9T6DTya4jhDRrtWq24rPafisZE2NKbqAkhZHzxdeTmqvcnK 2014-06-21T02:50:00 10 YES
spartako4 * XTS8j75dYvJVV5KgxrNDjeppEwTqyTCJH7hPMebm2PPAJnuWe83Ry 2014-06-21T02:50:00 10 YES
unelected-heyd-1 * XTS5Q7j3ZAYwjGAuK6AfWiqDuahnah9MVHXxGAr8yjsxWwuEAX9xg 2014-06-20T00:00:00 0 YES
unelected-heyd-2 * XTS5K6TmQjqReTUhWMg3EBjQ26VB6r26jMn4r2VEG2ykWh2xFkUpP 2014-06-20T00:00:00 0 YES
unelected-heyd-3 * XTS5HHx85ASdW3b4UmyV8g2rLyYRfHeTj8aH6E1DTE11jFUBr96as 2014-06-20T00:00:00 0 YES
vote-heyd XTS6AVvY9Ri2FJb6vazyHpgDq4CyzYLcATF4pC3qvra1KF7RcC318 NO 0 N/A
I couldn't believe my eyes. Then I tried to export the private keys of these three 'new' accounts. Here is what I got:
heyd (unlocked) >>> wallet_account_export_private_key spartako1
"5KNGqS4irbpH6tZQQ(*****deleted*****)"
heyd (unlocked) >>> wallet_account_export_private_key spartako3
"5Ju42xu7knENxhy4m(*****deleted*****)"
heyd (unlocked) >>> wallet_account_export_private_key spartako4
"5Je7QTfXBZmehcC1b(*****deleted*****)"
@spartako , Could you please check whether these private keys match the delegates created by you ?
-
i experienced the same problem 2 days ago on RUN 3 and Toast asked me to create a new wallet and re-import my own private key.
I suspect it is a security bug and BM/Toast should look deep into it
I think I've found something really strange.
I built with the latest codes one hour ago, then restored the wallet files backed up two days ago after dry run 4 was started.
Guess what? I have accounts spartako1 , spartako3, spartako4 in my wallet, all of which were NOT created by me, I swear. (unelected-heyd-1, unelected-heyd-2, unelected-heyd-3 are the ones in the genesis json file while vote-heyd was created by me actually.)
heyd (unlocked) >>> wallet_list_my_accounts
NAME (* delegate) KEY REGISTERED TRUST LEVEL BLOCK PRODUCTION ENABLED
spartako1 * XTS68Ab5SG3sz6miKjFQ3B9FdZojk8FZeK1rtuQzzHnbi4Shv971w 2014-06-21T02:50:00 10 YES
spartako3 * XTS6zv9T6DTya4jhDRrtWq24rPafisZE2NKbqAkhZHzxdeTmqvcnK 2014-06-21T02:50:00 10 YES
spartako4 * XTS8j75dYvJVV5KgxrNDjeppEwTqyTCJH7hPMebm2PPAJnuWe83Ry 2014-06-21T02:50:00 10 YES
unelected-heyd-1 * XTS5Q7j3ZAYwjGAuK6AfWiqDuahnah9MVHXxGAr8yjsxWwuEAX9xg 2014-06-20T00:00:00 0 YES
unelected-heyd-2 * XTS5K6TmQjqReTUhWMg3EBjQ26VB6r26jMn4r2VEG2ykWh2xFkUpP 2014-06-20T00:00:00 0 YES
unelected-heyd-3 * XTS5HHx85ASdW3b4UmyV8g2rLyYRfHeTj8aH6E1DTE11jFUBr96as 2014-06-20T00:00:00 0 YES
vote-heyd XTS6AVvY9Ri2FJb6vazyHpgDq4CyzYLcATF4pC3qvra1KF7RcC318 NO 0 N/A
I couldn't believe my eyes. Then I tried to export the private keys of these three 'new' accounts. Here is what I got:
heyd (unlocked) >>> wallet_account_export_private_key spartako1
"5KNGqS4irbpH6tZQQ(*****deleted*****)"
heyd (unlocked) >>> wallet_account_export_private_key spartako3
"5Ju42xu7knENxhy4m(*****deleted*****)"
heyd (unlocked) >>> wallet_account_export_private_key spartako4
"5Je7QTfXBZmehcC1b(*****deleted*****)"
@spartako , Could you please check whether these private keys match the delegates created by you ?
It is a wallet sync bug. I'm confident you do not have access to those private keys.
-
What happens is the wallet says "hey, those accounts belong to me, because they match wallet ID ###". But the wallet ID is wrong. But it still populates it with your own local keys, it doesn't magically know the other private keys.
-
I think I've found something really strange.
I built with the latest codes one hour ago, then restored the wallet files backed up two days ago after dry run 4 was started.
Guess what? I have accounts spartako1 , spartako3, spartako4 in my wallet, all of which were NOT created by me, I swear. (unelected-heyd-1, unelected-heyd-2, unelected-heyd-3 are the ones in the genesis json file while vote-heyd was created by me actually.)
heyd (unlocked) >>> wallet_list_my_accounts
NAME (* delegate) KEY REGISTERED TRUST LEVEL BLOCK PRODUCTION ENABLED
spartako1 * XTS68Ab5SG3sz6miKjFQ3B9FdZojk8FZeK1rtuQzzHnbi4Shv971w 2014-06-21T02:50:00 10 YES
spartako3 * XTS6zv9T6DTya4jhDRrtWq24rPafisZE2NKbqAkhZHzxdeTmqvcnK 2014-06-21T02:50:00 10 YES
spartako4 * XTS8j75dYvJVV5KgxrNDjeppEwTqyTCJH7hPMebm2PPAJnuWe83Ry 2014-06-21T02:50:00 10 YES
unelected-heyd-1 * XTS5Q7j3ZAYwjGAuK6AfWiqDuahnah9MVHXxGAr8yjsxWwuEAX9xg 2014-06-20T00:00:00 0 YES
unelected-heyd-2 * XTS5K6TmQjqReTUhWMg3EBjQ26VB6r26jMn4r2VEG2ykWh2xFkUpP 2014-06-20T00:00:00 0 YES
unelected-heyd-3 * XTS5HHx85ASdW3b4UmyV8g2rLyYRfHeTj8aH6E1DTE11jFUBr96as 2014-06-20T00:00:00 0 YES
vote-heyd XTS6AVvY9Ri2FJb6vazyHpgDq4CyzYLcATF4pC3qvra1KF7RcC318 NO 0 N/A
I couldn't believe my eyes. Then I tried to export the private keys/public keys of these three 'new' accounts. Here is what I got:
heyd (unlocked) >>> wallet_account_export_private_key spartako1
"5KNGqS4irbpH6tZQQ(**********)"
heyd (unlocked) >>> wallet_account_export_private_key spartako3
"5Ju42xu7knENxhy4m(**********)"
heyd (unlocked) >>> wallet_account_export_private_key spartako4
"5Je7QTfXBZmehcC1b(**********)"
@spartako , Could you please check whether the first parts of these private keys match the delegates created by you ?
Actually these private keys are the ones of delegates heyd-young, heyd-naive, heyd-simple.
Interesting :
heyd (unlocked) >>> wallet_account_balance
spartako1:
6.312270 XTS
Confirmed it is a wallet sync bug. My private keys are different and also the spartako1 balance is different.
-
There is a function
wallet_account_vote_summary
Delegate For Against
--------------------------------------------------------------
bits 4850000 0
to get allocation of votes by account in user's wallet.
Also, there is a function
blockchain_get_account_record bits
Record for 'bits' -- Registered on 2014-Jun-21 02:10:00, last update was 40 hours ago
Owner's key: XTS7TiXSdc4HzMdA1TE4t6p1cADfkbjcGTUL3g6FFmcG95VPhPwtX
VOTES FOR VOTES AGAINST NET VOTES BLOCKS PRODUCED BLOCKS MISSED PRODUCTION RATIO LAST BLOCK # TOTAL PAY
----------------------------------------------------------------------------------------------------------------------------------------------------
0.01021002% 0% 0.01021002% 27 20 0.5745 3278 2.938955 XTS
to get info about a registered account or delegate.
I wonder if there is a way to look up what accounts (public addresses or registered accounts) allocated votes toward a delegate.
Maybe a new function is needed
blockchain_account_vote_summary
-
Why might my computer be canceling connections? I can't connect to the network at all anymore. I just rebuilt the client and I still cannot connect. Sorry for missing a ton of blocks
-
What happens is the wallet says "hey, those accounts belong to me, because they match wallet ID ###". But the wallet ID is wrong. But it still populates it with your own local keys, it doesn't magically know the other private keys.
How can I have them changed to the right names?
-
What happens is the wallet says "hey, those accounts belong to me, because they match wallet ID ###". But the wallet ID is wrong. But it still populates it with your own local keys, it doesn't magically know the other private keys.
How can I have them changed to the right names?
Not easily... export all your private keys, delete the wallet, and rescan.
BM is working on new wallet architecture which should make bugs like this much less common
-
Can you see it?
(http://t2.gstatic.com/images?q=tbn:ANd9GcRGxhfuUqenePnV8hqnZzj0Zb1-3nlU-ANZrQPRU0_J6UyRj2oGpg)
-
This is a bug caused by importing wallets from different chains where the account ids were different.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
Why might my computer be canceling connections? I can't connect to the network at all anymore. I just rebuilt the client and I still cannot connect. Sorry for missing a ton of blocks
Known bug that Eric is working on.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
Manually add a node
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
network_add_node "180.153.142.115:8764" add
network_add_node "162.243.127.243:33933" add
network_add_node "84.238.140.192:8763" add
network_add_node "107.170.30.182:8763" add
network_add_node "107.170.170.214:40767" add
network_add_node "107.170.211.129:48199" add
network_add_node "176.9.234.167:8763" add
network_add_node "107.170.30.182:8764" add
network_add_node "106.185.24.234:48807" add
network_add_node "58.246.76.58:54229" add
network_add_node "178.191.198.168:59448" add
network_add_node "162.243.153.227:8763" add
network_add_node "137.117.246.253:1024" add
network_add_node "106.185.26.162:8761" add
network_add_node "106.187.91.24:8763" add
network_add_node "216.252.204.39:8763" add
network_add_node "46.252.21.49:40653" add
network_add_node "120.43.49.199:58073" add
Edit: updated
-
"addr": "176.9.234.167:8763",
"addr": "180.153.142.115:8764",
-
inconsistency.
blockchain_get_delegate_block_stats shows results for many different delegates
307 xeldal
xeldal-w (unlocked) >>> blockchain_get_delegate_block_stats 307
[[
...
],[
3667,{
"missed": false,
"latency": 0
}
],[
3731,{
"missed": false,
"latency": 0
}
],[
3786,{
"missed": false,
"latency": 0
}
]
]
xeldal-w (unlocked) >>> blockchain_get_signing_delegate 3667
"xeldal"
xeldal-w (unlocked) >>> blockchain_get_signing_delegate 3731
"xeldal"
xeldal-w (unlocked) >>> blockchain_get_signing_delegate 3786
"batman"
xeldal-w (unlocked) >>> about
{
"bitshares_toolkit_revision": "24b41c1c879af8847d910572c3711b59e87053d9",
"bitshares_toolkit_revision_age": "6 hours ago",
"fc_revision": "3de924b33647a9a547b772a58415835f021f92b3",
"fc_revision_age": "28 hours ago",
"compile_date": "compiled on Jun 22 2014 at 15:35:42"
}
-
I've got the same results as Xeldal. blockchain_get_delegate_block_stats 311 returns block 3593 with a "missed": false flag, but a blockchain_get_signing_delegate 3593 returns bitcoiners as the signing delegate.
blockchain_get_delegate_block_stats 340 (bitcoiners) also shows block 3593, but has some blocks that show different names with blockchain_get_signing_delegate
-
inconsistency.
blockchain_get_delegate_block_stats shows results for many different delegates
307 xeldal
xeldal-w (unlocked) >>> blockchain_get_delegate_block_stats 307
[[
...
],[
3667,{
"missed": false,
"latency": 0
}
],[
3731,{
"missed": false,
"latency": 0
}
],[
3786,{
"missed": false,
"latency": 0
}
]
]
xeldal-w (unlocked) >>> blockchain_get_signing_delegate 3667
"xeldal"
xeldal-w (unlocked) >>> blockchain_get_signing_delegate 3731
"xeldal"
xeldal-w (unlocked) >>> blockchain_get_signing_delegate 3786
"batman"
xeldal-w (unlocked) >>> about
{
"bitshares_toolkit_revision": "24b41c1c879af8847d910572c3711b59e87053d9",
"bitshares_toolkit_revision_age": "6 hours ago",
"fc_revision": "3de924b33647a9a547b772a58415835f021f92b3",
"fc_revision_age": "28 hours ago",
"compile_date": "compiled on Jun 22 2014 at 15:35:42"
}
Are you not confused by the double negative?
It says the 307 didn't miss blocks 3667, 3731, or 3786.... and it also says that he is the one who signed it. In other words, perfectly consistent.
-
Are you not confused by the double negative?
It says the 307 didn't miss blocks 3667, 3731, or 3786.... and it also says that he is the one who signed it. In other words, perfectly consistent.
I don't follow.
It says xeldal: 307 didn't miss block 3786 and yet says "batman" signed 3786 batman ID: 321 not 307
What am I missing?
from the last 8 entries in blockchain_get_delegate_block_stats the block number corresponds via blockchain_get_signing_delegate to 5 different delegates. that's not consistent when I expect them to all be the same delegate.
-
Are you not confused by the double negative?
It says the 307 didn't miss blocks 3667, 3731, or 3786.... and it also says that he is the one who signed it. In other words, perfectly consistent.
I don't follow.
It says xeldal: 307 didn't miss block 3786 and yet says "batman" signed 3786 batman ID: 321 not 307
What am I missing?
from the last 8 entries in blockchain_get_delegate_block_stats the block number corresponds via blockchain_get_signing_delegate to 5 different delegates. that's not consistent when I expect them to all be the same delegate.
Right... sorry I miss read it.
-
Are you not confused by the double negative?
It says the 307 didn't miss blocks 3667, 3731, or 3786.... and it also says that he is the one who signed it. In other words, perfectly consistent.
I don't follow.
It says xeldal: 307 didn't miss block 3786 and yet says "batman" signed 3786 batman ID: 321 not 307
What am I missing?
from the last 8 entries in blockchain_get_delegate_block_stats the block number corresponds via blockchain_get_signing_delegate to 5 different delegates. that's not consistent when I expect them to all be the same delegate.
Right... sorry I miss read it.
Looking at the code I found the cause... the blockchain_get_delegate_block_stats is likely wrong as a result of fork processing code. This data is not used for block validation so is likely a cosmetic bug, but one that should be resolved none the less. I will have vikram work on it tomorrow.
-
some fork happend strange.
Just now, I found my delegate alt && dorian begin to miss block.
So I wait until next block generate.
first I see the block generate normaly, block ID is 4231.
after a minutes, when block 4232 is sync.
I check block 4231 again, it's different with before, means dorian create block 4231 but refuse by the main chain.
dorian lose block 4176 && 423, at that time, forked occured at 4174 && 4229.
after restart the client, everything is ok now.
delegate (unlocked) >>> blockchain_get_delegate_block_stats 299
....
],[
4130,{
"missed": false,
"latency": 0
}
],[
4176,{
"missed": true,
"latency": null
}
],[
4231,{
"missed": true,
"latency": null
}
]
]
delegate (unlocked) >>> blockchain_list_forks
....
4174,
4180,
4182,
4218,
4227,
4229
]
-
some fork happend strange.
Just now, I found my delegate alt && dorian begin to miss block.
So I wait until next block generate.
first I see the block generate normaly, block ID is 4231.
...
I found dorian missed 2 blocks,art missed 1 block.
-
some fork happend strange.
Just now, I found my delegate alt && dorian begin to miss block.
So I wait until next block generate.
first I see the block generate normaly, block ID is 4231.
after a minutes, when block 4232 is sync.
I check block 4231 again, it's different with before, means dorian create block 4231 but refuse by the main chain.
dorian lose block 4176 && 423, at that time, forked occured at 4174 && 4229.
after restart the client, everything is ok now.
delegate (unlocked) >>> blockchain_get_delegate_block_stats 299
....
],[
4130,{
"missed": false,
"latency": 0
}
],[
4176,{
"missed": true,
"latency": null
}
],[
4231,{
"missed": true,
"latency": null
}
]
]
delegate (unlocked) >>> blockchain_list_forks
....
4174,
4180,
4182,
4218,
4227,
4229
]
What is output of 'about' command?
-
sorry I miss the version information.
I can get info from console.log.
this show I run client from 20140622T000013
and I think I must pull code and build before this time.
info
{
"blockchain_head_block_num": 1935,
"blockchain_head_block_time": "20140621T235930",
"blockchain_head_block_time_rel": "43 seconds old",
"blockchain_confirmation_requirement": 299,
"blockchain_average_delegate_participation": 60.953530476765238,
"network_num_connections": 0,
"ntp_time": "20140622T000013.254594",
"ntp_error_seconds": -0.0028019999999999998,
"wallet_unlocked_seconds_remaining": 99999998,
"wallet_next_block_production_time": "20140622T000530",
"wallet_seconds_until_next_block_production": 317,
"wallet_local_time": "20140622T000013",
"blockchain_random_seed": "615f964e82892c016eafbfafd924fbef7ead51cd",
"blockchain_shares": 9997580403788,
"network_num_connections_max": 999,
"network_protocol_version": 103,
"wallet_open": true,
"wallet_unlocked_until": "20170822T094651",
"wallet_version": 100
}
-
how do you specify where you want votes to go from a given transaction? or can you not override the wallets automated allocation of votes?
-
>> blockchain_list_forks
[
777,
811,
818,
853,
872,
874,
900,
944,
1178,
1219,
2147,
2148,
2149
]
>> about
{
"bitshares_toolkit_revision": "9de0540ba6b911560ae0ab0fe2fe9b8d83a7d4ec",
"bitshares_toolkit_revision_age": "65 hours ago",
"fc_revision": "331e6aac7d1ac7a6fd7c0b0fa092099eb25c99a1",
"fc_revision_age": "73 hours ago",
"compile_date": "compiled on Jun 20 2014 at 17:08:18"
}
-
Thanks everyone!
We are going to reset to test out the new ~Approval Voting~! Hooray!