Dry Run 4: A New Hope

[toast]

Thanks everyone!
We are going to reset to test out the new ~Approval Voting~! Hooray!

[sudo]

Code: [Select]

>> 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"
}

[clout]

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?

[alt]

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.

Code: [Select]

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
}


[vikram]

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.

Code: [Select]

delegate (unlocked) >>> blockchain_get_delegate_block_stats 299
....
  ],[
    4130,{
      "missed": false,
      "latency": 0
    }
  ],[
    4176,{
      "missed": true,
      "latency": null
    }
  ],[
    4231,{
      "missed": true,
      "latency": null
    }
  ]
]


Code: [Select]

delegate (unlocked) >>> blockchain_list_forks
....
  4174,
  4180,
  4182,
  4218,
  4227,
  4229
]


What is output of 'about' command?

[taoljj]

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.

[alt]

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.

Code: [Select]

delegate (unlocked) >>> blockchain_get_delegate_block_stats 299
....
  ],[
    4130,{
      "missed": false,
      "latency": 0
    }
  ],[
    4176,{
      "missed": true,
      "latency": null
    }
  ],[
    4231,{
      "missed": true,
      "latency": null
    }
  ]
]


Code: [Select]

delegate (unlocked) >>> blockchain_list_forks
....
  4174,
  4180,
  4182,
  4218,
  4227,
  4229
]


[bytemaster]

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.

[bytemaster]

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.

[Xeldal]

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.

[bytemaster]

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.

[puppies]

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

[Xeldal]

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"
}

[bytemaster]

    "addr": "176.9.234.167:8763",
    "addr": "180.153.142.115:8764",

[Xeldal]

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

[bytemaster]

Manually add a node


Sent from my iPhone using Tapatalk

[bytemaster]

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

[bytemaster]

This is a bug caused by importing wallets from different chains where the account ids were different. 




Sent from my iPhone using Tapatalk

[CLains]

Can you see it?

[toast]

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

[muse-umum]

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?

[clout]

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

[bitcoinerS]

There is a function

Code: [Select]

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

Code: [Select]

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

Code: [Select]

blockchain_account_vote_summary

[spartako]

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.)

Code: [Select]

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:

Code: [Select]

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 :

Code: [Select]

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.

[toast]

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.

[toast]

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.)

Code: [Select]

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:

Code: [Select]

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.

[sfinder]

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.)

Code: [Select]

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:

Code: [Select]

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 ?

[muse-umum]

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.)

Code: [Select]

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:

Code: [Select]

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 :

Code: [Select]

heyd (unlocked) >>> wallet_account_balance
spartako1:
    6.312270 XTS


[coolspeed]

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

[emski]

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

[bytemaster]

Updated version of OS X wallet is now out.

[bytemaster]

Transaction propagation bug appears to be resolved with latest commit.   Working on some others.

[liondani]

Code: [Select]

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


[bitcoinerS]

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.

Code: [Select]

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.

Code: [Select]

>>> 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
]



Code: [Select]

>>> 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,


[coolspeed]

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

[xeroc]

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

[emski]

This is what happens with late friday fixes/relases (: .
Go get some sleep and rest - Its weekend.

[wackou]

Take it easy, BM.
Rome was not built in a day.

[xeroc]

finally unelected-delegate-61 is producing blocks ... unelected-xeroc cannot produce blocks because its a name collision with my keyhotee ID 'xeroc' (same pubkeys)

[metalallen]

Take it easy, BM.
Rome was not built in a day.

[wackou]

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 

[bytemaster]

 

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.   

[bytemaster]

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.

[bytemaster]

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.

[wackou]

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...

[emski]

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"
  }

[wackou]

do you connect through 107.170.30.182:8763 ?

[emski]

"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,

[CalabiYau]

 "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

[wackou]

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?

[coolspeed]

It doesn't connect. Only for me? I've tried restarting it 6 to 7 times.
FYI, my VPS located in San Francisco.

Code: [Select]

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"
}




[xeroc]

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!?

[wackou]

I can't connect with the latest (991ec4), not in linux and not in osx either... 

seems like seed node is up, though:

Code: [Select]

$ 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!

[pgbit]

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.

[Harvey]

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

[emski]

I see one block signed by my delegate. And the same block missed by another one of my delegates.

[dexinwong]

Admin, plz see here  https://bitsharestalk.org/index.php?topic=5185.msg68172;topicseen#msg68172

[bitcoinerS]

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.

[emski]

How can I see a reason why a block was missed by my delegate?

[alexxy]

@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

[bitandrew]

who can send me some xts for test,when i register delegate,it tells me insufficient funds

here is my address:XTS7FCu7GrAsnLjc5ARuUszjLUY6k14CtVJtjVbm7afjmaCVvxDTP

thank you!

[fluxer555]

So, my OSX client auto-locked, and I missed my block as a delegate. That needs to be fixed.

[Fox]

I just issued TRUST on the blockchain.  I will transfer 1000 TRUST to those individuals willing to:

Code: [Select]

wallet_set_delegate_trust_level fox 1

[fluxer555]

That worked! This does not include the 'true' part, please update it:
https://github.com/BitShares/bitshares_toolkit/wiki/DPOS-Registering-Names-And-Delegates

[crazybit]

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" ?

[crazybit]

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.

[fluxer555]

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?

[fluxer555]

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.

[crazybit]

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

[laow]

Code: [Select]

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.

[bitcoinerS]

Trying to issue an asset.

Code: [Select]

>>> 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?

[toast]

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

[crazybit]

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

[welk1n]

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.

[toast]

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

[vikram]

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

[bytemaster]

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. 

[emski]

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

[zhangweis]

If you have less than 5 connections, shut down and reconnect.

Thanks and it works by restarting client.

[bytemaster]

If you have less than 5 connections, shut down and reconnect. 

[zhangweis]

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

[bytemaster]

Getting build errors

Code: [Select]

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.

[sfinder]

compile error at 99%-100%

Code: [Select]


[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


[Xeldal]

Getting build errors

Code: [Select]

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


[toast]

Can we use BIP to pay registration fee ? Has the BIP function been implemented ?

No, probably won't be for XT

[zhangweis]

I've seen 1 block now.
Can someone send me some fund to register as delegate? Thanks in advance.

XTS8eghNapYmPzsmweCn7EVQLDqUKH91hj3GCowusMm8vRhkLM5Zk

[sfinder]

Can we use BIP to pay registration fee ? Has the BIP function been implemented ?

[toast]

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!