Can anyone share your get_info? I can see the following in my log but 0 connections in get_info.

177019ms       th_a p2p_network_connect_ ] Starting an iteration of p2p_network_connect_loop().                 node.cpp:561
177020ms       th_a display_current_conn ] Currently have 1 of 8 connections                    node.cpp:861
177020ms       th_a display_current_conn ]    my id is 281b1a748c848d873d54b8a6ec5832cd4a5fbe70                 node.cpp:862
177020ms       th_a display_current_conn ]    handshaking: 107.170.30.182:5678 with 0000000000000000000000000000000000000000  [outbound]                       node.cpp:870


(wallet closed) >>> get_info
{
  "balance": 0,
  "unlocked_until": "19700101T000000",
  "version": 100,
  "protocolversion": 100,
  "walletversion": 100,
  "chain_id": "ed2c3dba64a343002734f782bb3bc831a99a14c80490b85bfbf33751793469cc",
  "symbol": "XTS",
  "interval_seconds": 30,
  "blocks": 0,
  "current_share_supply": 80000000000000,
  "shares_per_bip": 0,
  "random_seed": "0000000000000000000000000000000000000000000000000000000000000000",
  "connections": 0,
  "rpc_port": 0,
  "_node_id": "281b1a748c848d873d54b8a6ec5832cd4a5fbe70",
  "_fc_revision": "9f6b52eac2221f398896b318bd46824ee54623e0",
  "_bitshares_toolkit_revision": "f82d0df05f66af9fcbb4035c909046aa9202daa1"
}

Quote from: zhao150 on May 23, 2014, 09:30:27 am

以前听说要投票选择代表，现在可以自动随机选择，那效率确实高。
如果能做到公平 随机的选择代表出来，有效防止各个代表串通，那确实非常了不起。
有这种机制做基础 将来是可以搞出很多现实应用

抱歉，可能原来是标题误解了，Top的代表仍然是投票选择的，只是现在是随机判断下一个delegate，而不是按照顺序执行

其实我觉得原来那样one by one的顺序执行，delegate容易被定点DOS攻击(Deny of Service)

除了防DDOS，还可以防止delegate作弊（比如控制连续几个delegate id,然后可以在一定时间内排除某些交易，达到短期控制市场交易价格的母的）和delegate lotto作弊。(https://bitsharestalk.org/index.php?topic=4164.msg53450#msg53450)

锚定成功 &大量的服务商接受bitcny支付的话 就不需要换成cny了

单是锚定成功就足够了。如果锚定成功，“大量的服务商接受bitcny支付”是很自然的事。

以后的PTS是不是要改成POS模式？

PTS本身应该不会变了。

@CrazyBit 给我送了10,000个bips做测试，我给你转了1234个，你看看，应该很快就到账的。

到账了，多谢。
我试了试reserve_name就花掉我229,心痛死了。测试的都这么不经用。

我的地址是BFL73TtraijmhJ457ba1NTrePDNN9p6vG，谁能给我发1个bts试试？

同求测试BTS,地址N94JT5RdUJJbUL8UzoUquTe9vTGA4W6ds

BTS wallet's approach seems to be HD wallet.
Refer https://en.bitcoin.it/wiki/Deterministic_wallet

From the code from wallet.cpp(wallet::new_public_key), I think that it will generate the same series of keys if you start from the same wallet key password and the same encrypted_base_key.

We discussed this yesterday a little bit. It has several benefits but it makes resolving forks more complicated.

Do you mean http://bitshares.org/documentation/group__dpos.html#dpos_conflict_resolution ?

I guess there won't be much differences between randomness one and 1,2,3,4 one.

Let's say the next miner is decided by RGN(N-2) % 100 and the results are like [2,3,1]. In this case, A,B,C is [2,3,1] and all the same rules in that doc work with [A:2,B:3,C:1] just like [A:1,B:2,C:3]. Notice that I used N-2 which means that it's already decided when current block is not generated yet and the next miner can be ready waiting to resolve the conflicts when it happens. In the worst case, we can use N-100 but I think N-3 could be fine as the possibility of both miners are down is low and in that case the next miner (decided by RGN of last 99)  just picks up.

Edit:
In case that one miner doesn't produce block, it's just like ranking changes because we need to choose next next miner by using RNG of last 99. So there's really not much differences between the two from conflict resolving point of view.