Author Topic: Dry Run 5: The Final Countdown  (Read 54037 times)

0 Members and 1 Guest are viewing this topic.

Offline bytemaster

I have made some updates to the client that appear to have reduced forks significantly.   TITAN transactions are relatively expensive to scan, if you have a wallet with even one account in it, then scanning a block with 1000 trxs could take several seconds.  If you have 100 accounts, it could take minutes. 

For this reason I have disabled the wallet scanning for wallets that have enabled delegates.   I do not recommend using your delegate account as a receiving account in the same wallet. 

We will be making optimizations in the future that will multi-thread this step and move it out of the critical path of block validation.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
appears a lot of people haven't updated since fork resolution code:

bts101/2/3
emski  ?
immortal ?
wackou?
asia?
taolj?

I've updated when i first saw this:
Quote
Dan just pushed a possible fix for the forking issue, please update
Then I went to sleep. I'll update again now and test.

You may add "angel" to the above list.

Offline muse-umum

  • Hero Member
  • *****
  • Posts: 717
  • BitShares everything
    • View Profile
toast. We have approval voting now. But I am still able to vote against some delegates (I know it won't take effect really). And do trust level 10,30,40 make any difference ?

Code: [Select]
heyddryrun5 (unlocked) >>> wallet_list_accounts
NAME (* delegate)                  KEY                                                             REGISTERED            FAVORITE       TRUST LEVEL   
bytemaster *                       XTS7AkLRGApanDEs8fUbpmJtjUn6sTFSC64AENVCqfshWZ2bPjnSy           2014-06-23T21:09:30   NO             -30       
sometimes-naive *                  XTS5kppbLHPT6JV7aGGXQ3Nu4TvtR1u388uau6Yqv1J9Ni64rnFnc           2014-06-24T02:12:30   NO             10       
too-simple *                       XTS5Def6N9bsueAX2YnvQNKHzbphG1Qx9syKthF9BFFSZZT5EkS3x           2014-06-24T02:12:30   NO             40       
too-young *                        XTS6Kp6598CtJhDVauQwQKVLBZZ34o9W55CR2vhCNRezvKL2KHQtB           2014-06-24T02:12:00   NO             30       
welk1n-b *                         XTS5Q9zjvW6WKBhxYT6oY5qmbywbKv8N4K2HkL8XHYxx41dpDsndm           2014-06-24T03:26:00   NO             -10       

Doesn't matter, either 0 or >= 0.
We will change to "true/false" soon.

Now I am trusting 3 delegates, will all of them get my votes every time I make a 'wallet_transfer' ?

If I am trusting more than 33 delegates, at most 33 of them get my votes per each transaction, right ?

When you make a transfer it never uses your full set of delegates (that would be like a fingerprint tying it all together)... instead it uses a random subset of your trusted delegates.

So in such case, my votes will go to one or two of the three positive trusted delegates, but never all of them, right ?

Offline bytemaster

toast. We have approval voting now. But I am still able to vote against some delegates (I know it won't take effect really). And do trust level 10,30,40 make any difference ?

Code: [Select]
heyddryrun5 (unlocked) >>> wallet_list_accounts
NAME (* delegate)                  KEY                                                             REGISTERED            FAVORITE       TRUST LEVEL   
bytemaster *                       XTS7AkLRGApanDEs8fUbpmJtjUn6sTFSC64AENVCqfshWZ2bPjnSy           2014-06-23T21:09:30   NO             -30       
sometimes-naive *                  XTS5kppbLHPT6JV7aGGXQ3Nu4TvtR1u388uau6Yqv1J9Ni64rnFnc           2014-06-24T02:12:30   NO             10       
too-simple *                       XTS5Def6N9bsueAX2YnvQNKHzbphG1Qx9syKthF9BFFSZZT5EkS3x           2014-06-24T02:12:30   NO             40       
too-young *                        XTS6Kp6598CtJhDVauQwQKVLBZZ34o9W55CR2vhCNRezvKL2KHQtB           2014-06-24T02:12:00   NO             30       
welk1n-b *                         XTS5Q9zjvW6WKBhxYT6oY5qmbywbKv8N4K2HkL8XHYxx41dpDsndm           2014-06-24T03:26:00   NO             -10       

Doesn't matter, either 0 or >= 0.
We will change to "true/false" soon.

Now I am trusting 3 delegates, will all of them get my votes every time I make a 'wallet_transfer' ?

If I am trusting more than 33 delegates, at most 33 of them get my votes per each transaction, right ?

When you make a transfer it never uses your full set of delegates (that would be like a fingerprint tying it all together)... instead it uses a random subset of your trusted delegates.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline muse-umum

  • Hero Member
  • *****
  • Posts: 717
  • BitShares everything
    • View Profile
toast. We have approval voting now. But I am still able to vote against some delegates (I know it won't take effect really). And do trust level 10,30,40 make any difference ?

Code: [Select]
heyddryrun5 (unlocked) >>> wallet_list_accounts
NAME (* delegate)                  KEY                                                             REGISTERED            FAVORITE       TRUST LEVEL   
bytemaster *                       XTS7AkLRGApanDEs8fUbpmJtjUn6sTFSC64AENVCqfshWZ2bPjnSy           2014-06-23T21:09:30   NO             -30       
sometimes-naive *                  XTS5kppbLHPT6JV7aGGXQ3Nu4TvtR1u388uau6Yqv1J9Ni64rnFnc           2014-06-24T02:12:30   NO             10       
too-simple *                       XTS5Def6N9bsueAX2YnvQNKHzbphG1Qx9syKthF9BFFSZZT5EkS3x           2014-06-24T02:12:30   NO             40       
too-young *                        XTS6Kp6598CtJhDVauQwQKVLBZZ34o9W55CR2vhCNRezvKL2KHQtB           2014-06-24T02:12:00   NO             30       
welk1n-b *                         XTS5Q9zjvW6WKBhxYT6oY5qmbywbKv8N4K2HkL8XHYxx41dpDsndm           2014-06-24T03:26:00   NO             -10       

Doesn't matter, either 0 or >= 0.
We will change to "true/false" soon.

Now I am trusting 3 delegates, will all of them get my votes every time I make a 'wallet_transfer' ?

If I am trusting more than 33 delegates, at most 33 of them get my votes per each transaction, right ?

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
toast. We have approval voting now. But I am still able to vote against some delegates (I know it won't take effect really). And do trust level 10,30,40 make any difference ?

Code: [Select]
heyddryrun5 (unlocked) >>> wallet_list_accounts
NAME (* delegate)                  KEY                                                             REGISTERED            FAVORITE       TRUST LEVEL   
bytemaster *                       XTS7AkLRGApanDEs8fUbpmJtjUn6sTFSC64AENVCqfshWZ2bPjnSy           2014-06-23T21:09:30   NO             -30       
sometimes-naive *                  XTS5kppbLHPT6JV7aGGXQ3Nu4TvtR1u388uau6Yqv1J9Ni64rnFnc           2014-06-24T02:12:30   NO             10       
too-simple *                       XTS5Def6N9bsueAX2YnvQNKHzbphG1Qx9syKthF9BFFSZZT5EkS3x           2014-06-24T02:12:30   NO             40       
too-young *                        XTS6Kp6598CtJhDVauQwQKVLBZZ34o9W55CR2vhCNRezvKL2KHQtB           2014-06-24T02:12:00   NO             30       
welk1n-b *                         XTS5Q9zjvW6WKBhxYT6oY5qmbywbKv8N4K2HkL8XHYxx41dpDsndm           2014-06-24T03:26:00   NO             -10       

Doesn't matter, either 0 or >= 0.
We will change to "true/false" soon.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline muse-umum

  • Hero Member
  • *****
  • Posts: 717
  • BitShares everything
    • View Profile
toast. We have approval voting now. But I am still able to vote against some delegates (I know it won't take effect really). And do trust level 10,30,40 make any difference ?

Code: [Select]
heyddryrun5 (unlocked) >>> wallet_list_accounts
NAME (* delegate)                  KEY                                                             REGISTERED            FAVORITE       TRUST LEVEL   
bytemaster *                       XTS7AkLRGApanDEs8fUbpmJtjUn6sTFSC64AENVCqfshWZ2bPjnSy           2014-06-23T21:09:30   NO             -30       
sometimes-naive *                  XTS5kppbLHPT6JV7aGGXQ3Nu4TvtR1u388uau6Yqv1J9Ni64rnFnc           2014-06-24T02:12:30   NO             10       
too-simple *                       XTS5Def6N9bsueAX2YnvQNKHzbphG1Qx9syKthF9BFFSZZT5EkS3x           2014-06-24T02:12:30   NO             40       
too-young *                        XTS6Kp6598CtJhDVauQwQKVLBZZ34o9W55CR2vhCNRezvKL2KHQtB           2014-06-24T02:12:00   NO             30       
welk1n-b *                         XTS5Q9zjvW6WKBhxYT6oY5qmbywbKv8N4K2HkL8XHYxx41dpDsndm           2014-06-24T03:26:00   NO             -10       

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
@bytemaster ;@toast
5轮测试后,看起来之前一直没有真正找到分岔的原因,真正定位到问题上。建议:
1.在测试版中,可以所有的代理接点连接到一个固定的接点,当代理接点生成一个块的时候,将生成的需要的LOG信息按顺序发送到这个固定的接点,这样在这个固定的接点上就可以很清楚了解什么时间,某个代表,导致了分岔,有一个整体的了解,配合代理接点更详细的LOG信息,真正定位问题点。
2.从已经开发的POS币上借鉴阻止分岔的好的设计方法。
3.如果在实际运行中发生了分岔,如何处理。

Each case of fork has been different. We have fixed all previous ones and discover new ones when we do more serious stress testing. Existing POS systems are too different for us to learn from them. Suggestion to have centralized server doesn't help because central server is just like a delegate - if server works then delegate works, if delegate doesn't then server wouldn't.
Dear BM and Toast
     I notice chain always have fork problem , I am not a programer,cannot been able to read C++ code. but can you explain some thing , maybe some question I ask are foolish.
1.how to judge which chain is the longer/main chain ?  chain honored by delegates have more voting/stake?
   
2.I think Dpos is a complicated algorithm, it many regulation,if all clients are honest,  which delegate have more chance to create block 
    (1).have more stake ?
    (2).have more voting ?
    (3).have network with more high speed ?
    (4).honest one ?
3.according to timestamp of block, does each client have the ability to judge if block itself received is the newest one  or very close to the newest ?  does client can judge if itself in a main chain or fork chain?
4.if a client/delegate doubt/find itself is in a fork chain , what itself can do now ?   inquiry from P2P network continually to find the main chain, or there is a seed node every clent/delegate can connect to check if itself is in main chain  if it doubt itself is in fork chain ?
5.if there are two chains in the P2P network.  and one client/delegate received two chains both , how to compare the two chains and select the longer one then broadcast longer one to P2P network again ,then make it much longer/longest.


Br
BTSDac

1) Longer simply means more blocks.
2) Each delegate in top 101 (elected by stake-vote) has a chance to produce a block once per round.
3) The client decides it is on the main chain if the most recent block has the most recent expected timestamp and it is the longest known chain. A client can know for sure it is on the main chain if more than half of the last round of delegates signed blocks on the chain it is currently on.
4) Just keep asking peers if they know a longer chain, just like bitcoin
5) Again, simply which chain is longer.


Our forking problems now are a result of two issues: long block production time and problems with transactions it thinks are duplicates when switching back to the main fork.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1
@bytemaster ;@toast
5轮测试后,看起来之前一直没有真正找到分岔的原因,真正定位到问题上。建议:
1.在测试版中,可以所有的代理接点连接到一个固定的接点,当代理接点生成一个块的时候,将生成的需要的LOG信息按顺序发送到这个固定的接点,这样在这个固定的接点上就可以很清楚了解什么时间,某个代表,导致了分岔,有一个整体的了解,配合代理接点更详细的LOG信息,真正定位问题点。
2.从已经开发的POS币上借鉴阻止分岔的好的设计方法。
3.如果在实际运行中发生了分岔,如何处理。

Each case of fork has been different. We have fixed all previous ones and discover new ones when we do more serious stress testing. Existing POS systems are too different for us to learn from them. Suggestion to have centralized server doesn't help because central server is just like a delegate - if server works then delegate works, if delegate doesn't then server wouldn't.
Dear BM and Toast
     I notice chain always have fork problem , I am not a programer,cannot been able to read C++ code. but can you explain some thing , maybe some question I ask are foolish.
1.how to judge which chain is the longer/main chain ?  chain honored by delegates have more voting/stake?
   
2.I think Dpos is a complicated algorithm, it many regulation,if all clients are honest,  which delegate have more chance to create block 
    (1).have more stake ?
    (2).have more voting ?
    (3).have network with more high speed ?
    (4).honest one ?
3.according to timestamp of block, does each client have the ability to judge if block itself received is the newest one  or very close to the newest ?  does client can judge if itself in a main chain or fork chain?
4.if a client/delegate doubt/find itself is in a fork chain , what itself can do now ?   inquiry from P2P network continually to find the main chain, or there is a seed node every clent/delegate can connect to check if itself is in main chain  if it doubt itself is in fork chain ?
5.if there are two chains in the P2P network.  and one client/delegate received two chains both , how to compare the two chains and select the longer one then broadcast longer one to P2P network again ,then make it much longer/longest.


Br
BTSDac
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Am I on the forked chain ?

Code: [Select]
heyddryrun5 (unlocked) >>> info
{
  "blockchain_head_block_num": 2808,
  "blockchain_head_block_time": "20140625T033200",
  "blockchain_head_block_time_rel": "14 seconds old",
  "blockchain_confirmation_requirement": 302,
  "blockchain_average_delegate_participation": 61.773700305810401,
  "network_num_connections": 16,
  "ntp_time": "NTP time not available",
  "ntp_error_seconds": "NTP time not available",
  "wallet_unlocked_seconds_remaining": 9884,
  "wallet_next_block_production_time": "20140625T033530",
  "wallet_seconds_until_next_block_production": 196,
  "wallet_local_time": "20140625T033214",
  "blockchain_random_seed": "2d4a4addb3152c514e1dc8bfbce50e75ca7c532a",
  "blockchain_shares": 199999336346077,
  "network_num_connections_max": 200,
  "network_protocol_version": 103,
  "wallet_open": true,
  "wallet_unlocked_until": "20140625T061658",
  "wallet_version": 100
}
heyddryrun5 (unlocked) >>> about
{
  "bitshares_toolkit_revision": "eb5bed05842718ac07ee26a20e264269f62efd42",
  "bitshares_toolkit_revision_age": "2 hours ago",
  "fc_revision": "3de924b33647a9a547b772a58415835f021f92b3",
  "fc_revision_age": "79 hours ago",
  "compile_date": "compiled on Jun 25 2014 at 02:29:00"
}
heyddryrun5 (unlocked) >>> blockchain_list_forks
[
  1842,
  2035,
  2577,
  2591,
  2606,
  2607,
  2744,
  2788,
  2805
]

Looks like no, you can tell from:    "blockchain_head_block_time_rel": "14 seconds old",
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline muse-umum

  • Hero Member
  • *****
  • Posts: 717
  • BitShares everything
    • View Profile
Am I on the forked chain ?

Code: [Select]
heyddryrun5 (unlocked) >>> info
{
  "blockchain_head_block_num": 2808,
  "blockchain_head_block_time": "20140625T033200",
  "blockchain_head_block_time_rel": "14 seconds old",
  "blockchain_confirmation_requirement": 302,
  "blockchain_average_delegate_participation": 61.773700305810401,
  "network_num_connections": 16,
  "ntp_time": "NTP time not available",
  "ntp_error_seconds": "NTP time not available",
  "wallet_unlocked_seconds_remaining": 9884,
  "wallet_next_block_production_time": "20140625T033530",
  "wallet_seconds_until_next_block_production": 196,
  "wallet_local_time": "20140625T033214",
  "blockchain_random_seed": "2d4a4addb3152c514e1dc8bfbce50e75ca7c532a",
  "blockchain_shares": 199999336346077,
  "network_num_connections_max": 200,
  "network_protocol_version": 103,
  "wallet_open": true,
  "wallet_unlocked_until": "20140625T061658",
  "wallet_version": 100
}
heyddryrun5 (unlocked) >>> about
{
  "bitshares_toolkit_revision": "eb5bed05842718ac07ee26a20e264269f62efd42",
  "bitshares_toolkit_revision_age": "2 hours ago",
  "fc_revision": "3de924b33647a9a547b772a58415835f021f92b3",
  "fc_revision_age": "79 hours ago",
  "compile_date": "compiled on Jun 25 2014 at 02:29:00"
}
heyddryrun5 (unlocked) >>> blockchain_list_forks
[
  1842,
  2035,
  2577,
  2591,
  2606,
  2607,
  2744,
  2788,
  2805
]

Offline ebit

  • Committee member
  • Hero Member
  • *
  • Posts: 1905
    • View Profile
  • BitShares: ebit
I can not use bitsharexts windows wallet now . always blocks are syncing .
who have available windows wallet.

none
telegram:ebit521
https://weibo.com/ebiter

Offline yangsbo

  • Full Member
  • ***
  • Posts: 101
    • View Profile
I can not use bitsharexts windows wallet now . always blocks are syncing .
who have available windows wallet.

Offline bytemaster

not able to compile . any comments

Code: [Select]
Scanning dependencies of target udt_client
[ 47%] Building CXX object libraries/fc/CMakeFiles/udt_client.dir/tests/udt_client.cpp.o
/home/daniel/bitshares_toolkit/libraries/fc/tests/udt_client.cpp: In function 鈥榠nt main()鈥

              /home/daniel/bitshares_toolkit/libraries/fc/tests/udt_client.cpp:17:41: error: 鈥榤emset鈥was not declared in this scope
    memset(&(serv_addr.sin_zero), '\0', 8);
                                         ^
/home/daniel/bitshares_toolkit/libraries/fc/tests/udt_client.cpp:26:18: warning: deprecated conversion from string constant to 鈥榗har*鈥[-Wwrite-strings]
    char* hello = "hello world! 3\n";
                  ^
/home/daniel/bitshares_toolkit/libraries/fc/tests/udt_client.cpp:27:59: error: 鈥榮trlen鈥was not declared in this scope
    if (UDT::ERROR == UDT::send(client, hello, strlen(hello) + 1, 0))
                                                           ^
make[2]: *** [libraries/fc/CMakeFiles/udt_client.dir/tests/udt_client.cpp.o] Error 1
make[1]: *** [libraries/fc/CMakeFiles/udt_client.dir/all] Error 2
make: *** [all] Error 2

I'll comment that stuff out...

git pull
git submodule update
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline bytemaster

not able to compile . any comments

Code: [Select]
Scanning dependencies of target udt_client
[ 47%] Building CXX object libraries/fc/CMakeFiles/udt_client.dir/tests/udt_client.cpp.o
/home/daniel/bitshares_toolkit/libraries/fc/tests/udt_client.cpp: In function 鈥榠nt main()鈥

              /home/daniel/bitshares_toolkit/libraries/fc/tests/udt_client.cpp:17:41: error: 鈥榤emset鈥was not declared in this scope
    memset(&(serv_addr.sin_zero), '\0', 8);
                                         ^
/home/daniel/bitshares_toolkit/libraries/fc/tests/udt_client.cpp:26:18: warning: deprecated conversion from string constant to 鈥榗har*鈥[-Wwrite-strings]
    char* hello = "hello world! 3\n";
                  ^
/home/daniel/bitshares_toolkit/libraries/fc/tests/udt_client.cpp:27:59: error: 鈥榮trlen鈥was not declared in this scope
    if (UDT::ERROR == UDT::send(client, hello, strlen(hello) + 1, 0))
                                                           ^
make[2]: *** [libraries/fc/CMakeFiles/udt_client.dir/tests/udt_client.cpp.o] Error 1
make[1]: *** [libraries/fc/CMakeFiles/udt_client.dir/all] Error 2
make: *** [all] Error 2

I'll comment that stuff out...
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.