1051
中文 (Chinese) / Re: 以一点展开对价格的分析
« on: June 27, 2014, 04:49:16 am »有人收购 有人分析有不少理智的人,说明价格出入低谷区
无非是想维持住市场信心，让大家不要低于30出货
正如前几个月有个收购bts的网站
我把这一切当作自编自导自演的闹剧
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
1052
中文 (Chinese) / Re: 为什么总会分叉呢？
« on: June 27, 2014, 01:05:54 am »好消息，BM在为代表建立一个专属网络协议。A代表产生block后，首先传递给下一个上岗的代表，然后再在全网广播。
此网络协议应用了UDT协议。应该同时解决了ntp问题。
基于UDP的数据传输协议（UDP-based Data Transfer Protocol，简称UDT）是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。 顾名思义，UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。 由于UDT完全在UDP上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等。
比较担忧
1053
General Discussion / Re: Dry Run 6: Great Scott!
« on: June 26, 2014, 02:45:08 pm »what you mean ?
This is almost certainly a network / communication issue potentially caused by socket inactivity and TCP/IP connections going stale.
take follow fork yestoday occured , I was on the fork chain ,but information show I have 45 connection
1. 45 connections were inactivity,
2. 45 connection were activity ,but all 45 node I connected were on fork chain
which one you mean ?
Code: [Select]
"blockchain_head_block_num": 2633,
"blockchain_head_block_time": "20140625T062930",
"blockchain_head_block_time_rel": "28 minutes old",
"blockchain_confirmation_requirement": 303,
"blockchain_average_delegate_participation": 44.888888888888886,
"network_num_connections": 45,
"ntp_time": "20140625T065726.868608",
"ntp_error_seconds": -0.014512000000000001,
"wallet_unlocked_seconds_remaining": 0,
"wallet_next_block_production_time": null,
"wallet_seconds_until_next_block_production": null,
"wallet_local_time": "20140625T065726",
"blockchain_random_seed": "736362e9df6cd562307b713aae1eb75c3d11b88d",
"blockchain_shares": 199999351280463,
"network_num_connections_max": 200,
"network_protocol_version": 103,
"wallet_open": true,
"wallet_unlocked_until": "20140624T023103",
"wallet_version": 100
1055
General Discussion / Re: Dry Run 5: The Final Countdown
« on: June 25, 2014, 04:27:17 pm »
I list the transaction_history of same account in two computer , but the result is different
Code: [Select]
roy (unlocked) >>> wallet_account_transaction_history btsdac
BLK.TRX TIMESTAMP FROM TO MEMO AMOUNT FEE ID
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
954.0 2014-06-24T05:51:30 mao-delegate1 btsdac 100.00000 XTS 0.00000 XTS fbb58eb5
1125.0 2014-06-24T07:28:00 calyau btsdac cheers 22.00000 XTS 0.00000 XTS 1bcea32a
1209.0 2014-06-24T08:16:00 XTS5vPz2LsE1KkmR... btsdac test 2.00000 XTS 0.00000 XTS ac3f9ede
1379.0 2014-06-24T09:51:00 calyau btsdac more 100.00000 XTS 0.00000 XTS 77ebfa3b
3660.1 2014-06-25T16:16:30 btsdac btsdac02 10.00000 XTS 0.10000 XTS 6309495b
3660.2 2014-06-25T16:16:30 btsdac btsdac01 10.00000 XTS 0.10000 XTS e3f5beec
3660.0 2014-06-25T16:16:30 btsdac btsdac02 1.00000 XTS 0.10000 XTS 5fd5d73bCode: [Select]
roy (unlocked) >>> wallet_account_transaction_history btsdac
BLK.TRX TIMESTAMP FROM TO MEMO AMOUNT FEE ID
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
954.0 2014-06-24T05:51:30 mao-delegate1 btsdac 100.00000 XTS 0.00000 XTS fbb58eb5
1125.0 2014-06-24T07:28:00 calyau btsdac cheers 22.00000 XTS 0.00000 XTS 1bcea32a
1209.0 2014-06-24T08:16:00 XTS5vPz2LsE1KkmR... btsdac test 2.00000 XTS 0.00000 XTS ac3f9ede
1379.0 2014-06-24T09:51:00 calyau btsdac more 100.00000 XTS 0.00000 XTS 77ebfa3b
3054.0 2014-06-25T08:03:30 btsdac btsdac register btsdac 0.00000 XTS 0.10001 XTS 88060599
pending 2014-06-25T08:05:00 btsdac btsdac update btsdac 0.00000 XTS 0.10002 XTS 0cef7cd5
pending 2014-06-25T08:05:00 btsdac btsdac update btsdac 0.00000 XTS 0.10002 XTS bb15b624
3069.0 2014-06-25T08:15:00 btsdac btsdac register btsdac01 0.00000 XTS 0.10001 XTS c79fd85b
3078.0 2014-06-25T08:22:30 btsdac btsdac register btsdac02 as a delegate 0.00000 XTS 2.19724 XTS 3e584981
3086.0 2014-06-25T08:30:47 btsdac jeffreylee 10.00000 XTS 0.10000 XTS 47a41975
3602.0 2014-06-25T15:31:57 btsdac btsdac01 1.00000 XTS 0.10000 XTS a60ea647
3663.0 2014-06-25T16:18:23 btsdac btsdac01 10.00000 XTS 0.10000 XTS 62686cf6
1056
General Discussion / Re: Dry Run 5: The Final Countdown
« on: June 25, 2014, 06:56:28 am »We do not disconnect nodes that are on a fork at the moment. So you cannot use the connection count as an indicator of your fork status.I dont konw if you reply to me ,
Code: [Select]
"blockchain_head_block_num": 2633,
"blockchain_head_block_time": "20140625T062930",
"blockchain_head_block_time_rel": "28 minutes old",
"blockchain_confirmation_requirement": 303,
"blockchain_average_delegate_participation": 44.888888888888886,
"network_num_connections": 45,
"ntp_time": "20140625T065726.868608",
"ntp_error_seconds": -0.014512000000000001,
"wallet_unlocked_seconds_remaining": 0,
"wallet_next_block_production_time": null,
"wallet_seconds_until_next_block_production": null,
"wallet_local_time": "20140625T065726",
"blockchain_random_seed": "736362e9df6cd562307b713aae1eb75c3d11b88d",
"blockchain_shares": 199999351280463,
"network_num_connections_max": 200,
"network_protocol_version": 103,
"wallet_open": true,
"wallet_unlocked_until": "20140624T023103",
"wallet_version": 100
Code: [Select]
{
"bitshares_toolkit_revision": "5c7b143f810a60f168dcae3dbdb3099aa3dde1a0",
"bitshares_toolkit_revision_age": "32 hours ago",
"fc_revision": "3de924b33647a9a547b772a58415835f021f92b3",
"fc_revision_age": "83 hours ago",
"compile_date": "compiled on Jun 23 2014 at 20:33:28"
it is obviously that I am on a fork chain , but it seems that the clent did`t do any effort to back to main chain ."network_num_connections": 45
and I have 45 connections, it is close to max num of connections 50, I don`t konw if it weaken the ability of client to find new node that on the main chain
1057
General Discussion / Re: Dry Run 5: The Final Countdown
« on: June 25, 2014, 06:43:17 am »Dear BM and Toast@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.
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.
Code: [Select]
--- there are now 45 active connections to the p2p network
--- there are now 46 active connections to the p2p network
--- there are now 47 active connections to the p2p network
roy (unlocked) >>> info
{
"blockchain_head_block_num": 2633,
"blockchain_head_block_time": "20140625T062930",
"blockchain_head_block_time_rel": "8 minutes old",
"blockchain_confirmation_requirement": 303,
"blockchain_average_delegate_participation": 45.701357466063349,
"network_num_connections": 47,
"ntp_time": "20140625T063707.294604",
"ntp_error_seconds": -0.014511,
"wallet_unlocked_seconds_remaining": 0,
"wallet_next_block_production_time": null,
"wallet_seconds_until_next_block_production": null,
"wallet_local_time": "20140625T063707",
"blockchain_random_seed": "736362e9df6cd562307b713aae1eb75c3d11b88d",
"blockchain_shares": 199999351280463,
"network_num_connections_max": 200,
"network_protocol_version": 103,
"wallet_open": true,
"wallet_unlocked_until": "20140624T023103",
"wallet_version": 100
I think I am on a fork chain now ,but it seems that the client didn`t realize it , you can see this client have 46 p2p active connection,
if the client realize itself is in fork chain ,why he don`t ignore these 46 p2p active connection ,becasue these node all at the fork chain,
1058
General Discussion / Re: Dry Run 5: The Final Countdown
« on: June 25, 2014, 05:04:20 am »Dear BM and Toast@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.
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
1059
中文 (Chinese) / Re: stan真是具备舌战群儒的能力!佩服,佩服,翻译的不到位的地方,大家见谅.
« on: June 24, 2014, 02:47:45 pm »忍辱负重，挺过来就是英雄，bm绝对是天才，只是他不懂中国，不懂中国投资者，我一直在浏览英文贴，发现老外也是很不懂中国人，中国人无法很好的理解英语，中国投资者充满误会与谩骂，而且很多人是人云亦云。但老外一直很乐观淡定，也许这才是一个社区的氛围，才是bm想说什么就说什么的原因。他和英文社区的人是朋友，是战友。很有道理，BM很多都是讨论帖，只是要得到意见反馈而已，III虽然很多地方不尽如意，但绝对不会像很多人说的那么不堪，甚至说连山寨币都不如，我想这些都是情绪化的发泄，
1060
中文 (Chinese) / Re: 我对于Bitshares领导团队现阶段的建议和要求
« on: June 24, 2014, 12:22:57 pm »tapos 失败以后 iii就越来越踏实了，最近BM的效率很高了，我看到了stan的回复，我觉得如果我不是生活在中国的话，也许看到这些话会非常激动，很可惜，我生活在一个充斥着表决心和画未来的国度，所以我还是希望stan能够正面回答我的问题，而不是和我们阐述也许会有也许永远不会有的未来。如果bm一开始就是像你说的这样工作，相信就不会有今天的dpos了。dan说bm通过在论坛交流思考获得灵感，我很赞同。我很希望bm能继续在论坛交流自己的想法，不要影响开发就可以。
1. BM能否集中精力在开发，而不是在论坛回复，你们有没有能力管住他，还是公司没有任何人或者机制可以限制他在论坛上无休止的回帖。
2. BM时间是否充足到可以每天在论坛上发帖，而项目不需要他太多的精力？
3. Bitshares项目什么时候可以出来，有没有具体的时间节点和deadline? 在您40年的开发经验中，是否项目管理都是没
4. 在什么情况下我们可以认为项目开发已经失败或者失控？如果一旦发生，你们有没有后备计划？
请Stan正面回答我的问题，而不是继续说一些纯粹鼓舞的话，谢谢。
I very glad to see the Stan's answer, if i dont live in china, maybe i will so exciting to hear that. but so sorry, i'm living in china, we can hear this sentence everyday, so, i hope stan you can answer me question directly, not just draw great picture for us.
1. can BM focus on developing, don't waste too many time on reply posts. can you or 3I can control his reply, dont let him answer question too far, or he is out of control?
2. does BM have enough time to answer the question, you say he have so many time on developing, but we can see he put more time on forum
3. when bitshares will be seen a stable version? can you give me timetable or deadline? you said you have 40 years experience on R&D, is your project management all never have any timetable?
4. which situation we can consider that project is failure or out of control? when it happened, do you have any plan B?
sorry about me poor english , please answer me question directly first, thank you.
我不明白为什么在这个时刻拿bm的工作方式和开发效率说事？最近这段时间的开发节奏很好，效率也很高。
来自我的 HUAWEI P7-L00 上的 Tapatalk
1061
中文 (Chinese) / Re: 对于这次风波，个人认为3i已经讲清楚我们所关心的核心问题了
« on: June 24, 2014, 07:39:49 am »
事到如今 ,
III的确没有给我们任何惊喜, 但也没有那么不堪.
从TAPOS 到DPOS III是走了一个弯路, 最近的一个月来,开发很快..
股权稀释风波,现在已经澄清,BTS X 链不会有任何稀释.
III的确没有给我们任何惊喜, 但也没有那么不堪.
从TAPOS 到DPOS III是走了一个弯路, 最近的一个月来,开发很快..
股权稀释风波,现在已经澄清,BTS X 链不会有任何稀释.
1062
中文 (Chinese) / Re: 说沈波不干事一点不假，看看现在是中国的投资者都站出来了他在哪里
« on: June 24, 2014, 05:52:10 am »
大家都淡定一下, 体现一点投资者的素质来
1063
General Discussion / Re: Dry Run 5: The Final Countdown
« on: June 24, 2014, 04:22:52 am »btsdac is a unregistered account name, since I don't have XTS to registered it , can you send XTS to my address XTS7zkdnkqt4EQkWtBbB7SXmvJryBVBBRFUvJ8RpvxeoMZc7ceou7I can, but please give me your account name.Code: [Select]btsdac XTS7zkdnkqt4EQkWtBbB7SXmvJryBVBBRFUvJ8RpvxeoMZc7ceou7who can seed me a little XTS for tesing thanks
directly thanks
1064
中文 (Chinese) / Re: 我对于Bitshares领导团队现阶段的建议和要求
« on: June 24, 2014, 04:13:06 am »对于第四点，我的看法是，AGS当时说主要就是用于项目的开发，且在AGS发布完前预计产品可以出来。如果截至到AGS成熟的产品还不能拿出来，我们必须正视有可能开发失败的这一可能性，并且如果一旦发生这种可能，领导团队应该有这样的预案而不是反复强调开发难度。所谓的清算方案就是原来筹集资金的归还投资者，或者在全球悬赏新的开发团队，老开发团队全面移交之类的事宜。
总之，任何项目管理必须有明确的时间节点，大型项目的时间节点和管理更加是重中之重，一旦无法完成应该有后备方案，而不是无限期拖延和强调困难，这是对投资者的几大不负责任。当然，如果管理团队对投资者的诉求不予理睬，或者完全无视，霸占所有的项目资源不做贡献也不愿意放手，投资者只能找寻其他的解决手段。
第四点 应该是一个项目中完全有必要的预先条款, 可惜的是在AGS发布之初并没有规定AGS结束后必须要出钱包 ,所以如果现在强加,给人也中国投资者急功近利的话柄, 再者从代码上来,很多功能都实现,现在正是测试块链的节点上,这点提出是不是缓一缓, 是不是可以改成 让BM团队给出一个 BTS XT钱包的确切发布时间, 如果这个时间到了, BTS XT钱包还不能发布, 那就真证明团队真的不适合承担社区的任务.
1065
General Discussion / Re: Dry Run 5: The Final Countdown
« on: June 24, 2014, 01:34:34 am »Code: [Select]
btsdac XTS7zkdnkqt4EQkWtBbB7SXmvJryBVBBRFUvJ8RpvxeoMZc7ceou7 who can seed me a little XTS for tesing thanks
