BitShares Forum
Main => 中文 (Chinese) => Topic started by: HackFisher on May 23, 2014, 08:51:09 am
-
https://bitcointalk.org/index.php?topic=364218.msg3888740#msg3888740 (https://bitcointalk.org/index.php?topic=364218.msg3888740#msg3888740)
https://bitsharestalk.org/index.php?topic=4677.0 (https://bitsharestalk.org/index.php?topic=4677.0)
https://bitsharestalk.org/index.php?topic=4164.0 (https://bitsharestalk.org/index.php?topic=4164.0)
对细节感兴趣的可以看一下
-
以前听说要投票选择代表，现在可以自动随机选择，那效率确实高。
如果能做到公平 随机的选择代表出来，有效防止各个代表串通，那确实非常了不起。
有这种机制做基础 将来是可以搞出很多现实应用
-
以前听说要投票选择代表，现在可以自动随机选择，那效率确实高。
如果能做到公平 随机的选择代表出来，有效防止各个代表串通，那确实非常了不起。
有这种机制做基础 将来是可以搞出很多现实应用
抱歉，可能原来是标题误解了，Top的代表仍然是投票选择的，只是现在是随机判断下一个delegate，而不是按照顺序执行
其实我觉得原来那样one by one的顺序执行，delegate容易被定点DOS攻击(Deny of Service)
-
以前听说要投票选择代表，现在可以自动随机选择，那效率确实高。
如果能做到公平 随机的选择代表出来，有效防止各个代表串通，那确实非常了不起。
有这种机制做基础 将来是可以搞出很多现实应用
抱歉，可能原来是标题误解了，Top的代表仍然是投票选择的，只是现在是随机判断下一个delegate，而不是按照顺序执行
其实我觉得原来那样one by one的顺序执行，delegate容易被定点DOS攻击(Deny of Service)
虽然IP是不暴露的，只有pubkey暴露，但是连接到网络中，IP还是有暴露的可能，增加了delegate运行成本，现在这种方式留给DOS的时间窗口很短
-
以前听说要投票选择代表，现在可以自动随机选择，那效率确实高。
如果能做到公平 随机的选择代表出来，有效防止各个代表串通，那确实非常了不起。
有这种机制做基础 将来是可以搞出很多现实应用
抱歉，可能原来是标题误解了，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)
-
以前听说要投票选择代表，现在可以自动随机选择，那效率确实高。
如果能做到公平 随机的选择代表出来，有效防止各个代表串通，那确实非常了不起。
有这种机制做基础 将来是可以搞出很多现实应用
抱歉，可能原来是标题误解了，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)
是
来自我的 GT-N7100 上的 Tapatalk
-
Top的代表仍然是投票选择的，只是现在是随机判断下一个delegate，而不是按照顺序执行。
哦 现在执行的顺序是随机 那也不错，我还有几个问题 一直不明白：
一共可能是100个代表，每笔交易可能都会去这100个代表的账簿里面核对，现在核对的顺序变成随机了。
那是否要完全执行完这100个代表呢，还是 只要随机执行其中50%就行
还有 如果某些代表的电脑 down机 又是如何处理的。我估计如果发现down那可能会自动跳过。
那么是否有一种机制 每个几分钟去寻找下 有多少个代表在线，因为如果代表只有10个，那就太少了，是否有后补代表什么的。自动切换后补代表。
-
只有100个代表，按30秒一块，一个特定代表1个小时内都没轮上的概率为0.299。
所以盯住一个代表ddos攻击的话，命中率也不算低。
-
当然这样只是骚扰一下，没办法让整个网络停摆。
-
不知道100这个数是否可变的，一些规模小或者没盈利空间的DAC，有可能找不出100个代表。
-
一个代表可以担任多个dac的代表，硬件成本类似，可以摊低。
来自我的 HUAWEI P6-C00 上的 Tapatalk
-
只有100个代表，按30秒一块，一个特定代表1个小时内都没轮上的概率为0.299。
所以盯住一个代表ddos攻击的话，命中率也不算低。
其实对100个节点同时发起攻击，成本也不少太高
-
Top的代表仍然是投票选择的，只是现在是随机判断下一个delegate，而不是按照顺序执行。
哦 现在执行的顺序是随机 那也不错，我还有几个问题 一直不明白：
一共可能是100个代表，每笔交易可能都会去这100个代表的账簿里面核对，现在核对的顺序变成随机了。
那是否要完全执行完这100个代表呢，还是 只要随机执行其中50%就行
还有 如果某些代表的电脑 down机 又是如何处理的。我估计如果发现down那可能会自动跳过。
那么是否有一种机制 每个几分钟去寻找下 有多少个代表在线，因为如果代表只有10个，那就太少了，是否有后补代表什么的。自动切换后补代表。
Top 100目前的实现貌似是每个一轮(100个快)会刷新一下vote，每笔交易不需要去代表的账簿里面核对，这个没有太明白你的问题。
有候补代表
-
只有100个代表，按30秒一块，一个特定代表1个小时内都没轮上的概率为0.299。
所以盯住一个代表ddos攻击的话，命中率也不算低。
其实对100个节点同时发起攻击，成本也不少太高
这个也有应对办法，每个delegate因为只需要可以签名然后将块广播出去OK，所以可以选择一个pubkey 运行一些匿名节点，实际上100个delegate可能不止100个节点。
-
review了代码，有个问题不太明白，如何保证产生块的delegate是随机的？现在似乎是从list里随机拿出一个跟自己的id对比，如果match则产生块，不是则跳过，假如我的客户端是custermized的，而我又是delegate,我是否就可以跳过这个 checking直接产生块,如何防止这种情况？
-
DPOS好啊 :'( :'( :'(
-
review了代码，有个问题不太明白，如何保证产生块的delegate是随机的？现在似乎是从list里随机拿出一个跟自己的id对比，如果match则产生块，不是则跳过，假如我的客户端是custermized的，而我又是delegate,我是否就可以跳过这个 checking直接产生块,如何防止这种情况？
就是 https://bitsharestalk.org/index.php?topic=4164.0 (https://bitsharestalk.org/index.php?topic=4164.0) 里面提到的算法，每个delegate先publish secret_hash，下一轮reveal secret，由这些secrets哈希值来更新随机数。
之前的实现有一个漏洞，最新的实现每一轮delegate的顺序仍然是随机的，但是只在这一轮开始的时候刷新一下随机顺序，不是随机确定下一个delegate，而是随机确定下一轮delegate顺序。
-
review了代码，有个问题不太明白，如何保证产生块的delegate是随机的？现在似乎是从list里随机拿出一个跟自己的id对比，如果match则产生块，不是则跳过，假如我的客户端是custermized的，而我又是delegate,我是否就可以跳过这个 checking直接产生块,如何防止这种情况？
就是 https://bitsharestalk.org/index.php?topic=4164.0 (https://bitsharestalk.org/index.php?topic=4164.0) 里面提到的算法，每个delegate先publish secret_hash，下一轮reveal secret，由这些secrets哈希值来更新随机数。
之前的实现有一个漏洞，最新的实现每一轮delegate的顺序仍然是随机的，但是只在这一轮开始的时候刷新一下随机顺序，不是随机确定下一个delegate，而是随机确定下一轮delegate顺序。
谢谢解答，但是在块产生代码里我还是没看到你说的实现算法（https://github.com/BitShares/bitshares_toolkit/blob/ab177ba65f4355af9805b4e7451ed9f7dba8a0b7/libraries/client/client.cpp#L70#L104 (https://github.com/BitShares/bitshares_toolkit/blob/master/libraries/client/client.cpp#L67#L108)）能否指出具体实现在哪里？
-
review了代码，有个问题不太明白，如何保证产生块的delegate是随机的？现在似乎是从list里随机拿出一个跟自己的id对比，如果match则产生块，不是则跳过，假如我的客户端是custermized的，而我又是delegate,我是否就可以跳过这个 checking直接产生块,如何防止这种情况？
就是 https://bitsharestalk.org/index.php?topic=4164.0 (https://bitsharestalk.org/index.php?topic=4164.0) 里面提到的算法，每个delegate先publish secret_hash，下一轮reveal secret，由这些secrets哈希值来更新随机数。
之前的实现有一个漏洞，最新的实现每一轮delegate的顺序仍然是随机的，但是只在这一轮开始的时候刷新一下随机顺序，不是随机确定下一个delegate，而是随机确定下一轮delegate顺序。
谢谢解答，但是在块产生代码里我还是没看到你说的实现算法（https://github.com/BitShares/bitshares_toolkit/blob/ab177ba65f4355af9805b4e7451ed9f7dba8a0b7/libraries/client/client.cpp#L70#L104 (https://github.com/BitShares/bitshares_toolkit/blob/master/libraries/client/client.cpp#L67#L108)）能否指出具体实现在哪里？
https://github.com/BitShares/bitshares_toolkit/blob/master/libraries/blockchain/chain_database.cpp#L509 (https://github.com/BitShares/bitshares_toolkit/blob/master/libraries/blockchain/chain_database.cpp#L509)
-
:) +5%
-
什么时候BTS能出来啊，半成品啊！