46
General Discussion / Re: [ANN] Keyhotee users and Delegate requests for KeyID.
« on: August 13, 2014, 02:35:28 pm »
When is the deadline for this request? I may not decide on my Keyhotee ID till this weekend..
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.
47
中文 (Chinese) / Re: 比特股彩票投入使用了
« on: August 12, 2014, 05:32:04 am »
1. 有才。
2. 返奖率就是返奖率，有明确的概念，不用混淆，当然，比国内彩票的返奖率是高多了。。
3. 赚钱本身天经地义。不过这里有市场竞争，而"fork"你这个不费吹灰之力。。。你得考虑如何提高复制者的成本。(话说到这里，我已经有点心动了。。)
2. 返奖率就是返奖率，有明确的概念，不用混淆，当然，比国内彩票的返奖率是高多了。。
3. 赚钱本身天经地义。不过这里有市场竞争，而"fork"你这个不费吹灰之力。。。你得考虑如何提高复制者的成本。(话说到这里，我已经有点心动了。。)
48
中文 (Chinese) / 受托人之为责任——DACWIN团队成立
« on: August 10, 2014, 01:32:32 pm »
受托人之为责任——DACWIN团队成立
DPOS作为加密货币产业的最新创举，其最重要的创新之处，就在于“D—Delegated”即受托人机制。随着BTSX的正式启动及其平稳、高效的运行，后续BitAssets(比特资产)功能和BTS DNS、BTS Voting等DAC的推出时间表也已越来越清晰，整个DPOS系列DAC的宏伟计划开始逐步实现，受托人投票机制、DAC发行模型、受托人股权激励机制等问题也顺理成章的成为了社区讨论热点。而究其实质，这些问题真正的核心是受托人的职责。
顾名思义，受托人受DAC持股人之托，代表(Delegate)DAC持股人的利益，其职责总结如下：
一，维护DAC系统平稳、高效运行。确保不丢块，出块及时无延迟，区块信息收纳公平、准确、充分。无论是否排名在当前出块受托人范围内，保证100%在线率，随时做好出块准备。
二，致力于DAC生态圈基础建设。充分利用受托人资源，为DAC的开发、维护、推广做长期努力。应该有，但不限于以下工作：DAC方案研究讨论，DAC开发测试、DAC运行维护、DAC新功能开发、各种渠道的DAC推广包括翻译、主题网站、线上和线下讲座、日常答疑解惑，等等。
秉持着以上对DPOS受托人职责的认识，作为BTS社区从早期开始一直以来的参与、推广、建设者，我们组成了DACWIN团队，并从今天——2014年8月10日起运行BTSX受托人节点，履行受托人职责。
受托人节点：now.dacwin / future.dacwin
我们将确保节点的性能与表现，并投入更大资源进行DAC生态圈建设。
我们对自己有信心，对DAC有信心，对你们即将给予我们的信任有信心！
DAC WIN NOW and FUTURE！让我们一起：赢在当下，放眼未来！
DACWIN团队——coolspeed，logxing，yidaidaxia_郝晓曦 *
敬上
coolspeed——服务器端软件工程师，DAC爱好者。是国内早期接受并译介DAC理论、资讯的传播者之一，有兴趣共同见证DAC产业的可能性。参与BTSX网络测试，且具备较丰富的受托人节点运维经验。
logxing——程序员，创业者。致力于DAC的推广普及与技术研究。相信DAC是一次深刻的信息技术革命，必将使大众受益，并促使大众对自由和权利进行全新的思考。
yidaidaxia_郝晓曦——加密数字资产爱好者、研究者、传播者，BTSX白皮书、DPOS白皮书中文版译者，比特坊成员，资深项目经理。
* 以ID首字母排序
附：BTSX投票教程 http://www.bts.hk/bitshares-delegates-vote.html
PDF版阅读效果体验更佳: http://pan.baidu.com/s/1hqtarSo
DPOS作为加密货币产业的最新创举，其最重要的创新之处，就在于“D—Delegated”即受托人机制。随着BTSX的正式启动及其平稳、高效的运行，后续BitAssets(比特资产)功能和BTS DNS、BTS Voting等DAC的推出时间表也已越来越清晰，整个DPOS系列DAC的宏伟计划开始逐步实现，受托人投票机制、DAC发行模型、受托人股权激励机制等问题也顺理成章的成为了社区讨论热点。而究其实质，这些问题真正的核心是受托人的职责。
顾名思义，受托人受DAC持股人之托，代表(Delegate)DAC持股人的利益，其职责总结如下：
一，维护DAC系统平稳、高效运行。确保不丢块，出块及时无延迟，区块信息收纳公平、准确、充分。无论是否排名在当前出块受托人范围内，保证100%在线率，随时做好出块准备。
二，致力于DAC生态圈基础建设。充分利用受托人资源，为DAC的开发、维护、推广做长期努力。应该有，但不限于以下工作：DAC方案研究讨论，DAC开发测试、DAC运行维护、DAC新功能开发、各种渠道的DAC推广包括翻译、主题网站、线上和线下讲座、日常答疑解惑，等等。
秉持着以上对DPOS受托人职责的认识，作为BTS社区从早期开始一直以来的参与、推广、建设者，我们组成了DACWIN团队，并从今天——2014年8月10日起运行BTSX受托人节点，履行受托人职责。
受托人节点：now.dacwin / future.dacwin
我们将确保节点的性能与表现，并投入更大资源进行DAC生态圈建设。
我们对自己有信心，对DAC有信心，对你们即将给予我们的信任有信心！
DAC WIN NOW and FUTURE！让我们一起：赢在当下，放眼未来！
DACWIN团队——coolspeed，logxing，yidaidaxia_郝晓曦 *
敬上
coolspeed——服务器端软件工程师，DAC爱好者。是国内早期接受并译介DAC理论、资讯的传播者之一，有兴趣共同见证DAC产业的可能性。参与BTSX网络测试，且具备较丰富的受托人节点运维经验。
logxing——程序员，创业者。致力于DAC的推广普及与技术研究。相信DAC是一次深刻的信息技术革命，必将使大众受益，并促使大众对自由和权利进行全新的思考。
yidaidaxia_郝晓曦——加密数字资产爱好者、研究者、传播者，BTSX白皮书、DPOS白皮书中文版译者，比特坊成员，资深项目经理。
* 以ID首字母排序
附：BTSX投票教程 http://www.bts.hk/bitshares-delegates-vote.html
PDF版阅读效果体验更佳: http://pan.baidu.com/s/1hqtarSo
49
KeyID / Re: wondering if toast has a go-live timeline for DNS?
« on: August 10, 2014, 12:28:55 am »thanks Toast. I found all the doc below.
http://dotp2p.io
Keep in mind that is outdated, new site with updated docs is coming in 1 week or less.
Great！I am having below questions for DNS parameters and posted in another threat but have not got your response it. I think it will be covered in the docu. of the new site you metioned? Looking forward to all the details then.
Quote
@toast, would you pls update/clarify what's Auction Specification you are going to implement when BTS DNS launch?
I actually translated the "DNS .p2p Auction Specification (https://github.com/BitShares/bitshares_toolkit/wiki/DNS-.p2p-Auction-Specification)" the day before yesterday then I found there is some errors in the content then I notice it's an early June article then I went through this thread just now and found what I just introduced to Chinese community is really totally out of date......
I know Agent86's proposal and I know it might use another DLS and get implemented when BitAssets available.
So you may help me on below quesions:
Quote
D will be 0 and no 1) The initial required bid is 0.
2) Your required_bid is equal to (previous_bid + (R*(previous_bid - previous_required_bid))
3) When you place a bid, (D*(your_bid - previous_bid)) goes to dividends and (previous+bid + (1 - D)*(your_bid - previous_bid)) goes to previous bidder.
The initial required_bid will not be 0 and will decided by Delegates? So it will vary by different Delegates and how?
Will R still be 1 or a bit lower than 1 or very small like 0.1 or 0.2?
D is likely to be 1 and you will not have kickbacks when you are outbid, correct? The original bid you put will be returned to you totally or just a fraction of it (like 90% )?
What's the condition for a auction to be end? a specific time after it starts?(then how long?) A specific quantity of blocks produced after it starts(then how many?) or other condition set by Delegates or the sellor?
How renewal rate to be set?
And I think we will reserve top current famous domains for maximize system value by deliver/sell them to the related company in future, so what's the detailed plan? top 100? 1,000? 10,000?
Thanks.
50
中文 (Chinese) / Re: 看看在3I的世界中国人是怎么死的，欢迎各位仁人志士，喷子，小白，二年级的渣渣也敢吃辣条？
« on: August 06, 2014, 01:07:43 pm »一票一投必须建立在不能投反对票的原则下。但我真的看不懂比目前的方式有多少改善
是，还是需要仔细分析各种方案的利弊，在此基础上展开讨论才有意义。强调中国人等等，没什么意思。
51
KeyID / Re: .p2p auction parameter discussion
« on: August 05, 2014, 12:48:15 pm »
@toast, would you pls update/clarify what's Auction Specification you are going to implement when BTS DNS launch?
I actually translated the "DNS .p2p Auction Specification (https://github.com/BitShares/bitshares_toolkit/wiki/DNS-.p2p-Auction-Specification)" the day before yesterday then I found there is some errors in the content then I notice it's an early June article then I went through this thread just now and found what I just introduced to Chinese community is really totally out of date......
I know Agent86's proposal and I know it might use another DLS and get implemented when BitAssets available.
So you may help me on below quesions:
The initial required_bid will not be 0 and will decided by Delegates? So it will vary by different Delegates and how?
Will R still be 1 or a bit lower than 1 or very small like 0.1 or 0.2?
D is likely to be 1 and you will not have kickbacks when you are outbid, correct? The original bid you put will be returned to you totally or just a fraction of it (like 90% )?
What's the condition for a auction to be end? a specific time after it starts?(then how long?) A specific quantity of blocks produced after it starts(then how many?) or other condition set by Delegates or the sellor?
How renewal rate to be set?
And I think we will reserve top current famous domains for maximize system value by deliver/sell them to the related company in future, so what's the detailed plan? top 100? 1,000? 10,000?
Thanks.
I actually translated the "DNS .p2p Auction Specification (https://github.com/BitShares/bitshares_toolkit/wiki/DNS-.p2p-Auction-Specification)" the day before yesterday then I found there is some errors in the content then I notice it's an early June article then I went through this thread just now and found what I just introduced to Chinese community is really totally out of date......
I know Agent86's proposal and I know it might use another DLS and get implemented when BitAssets available.
So you may help me on below quesions:
Quote
D will be 0 and no 1) The initial required bid is 0.
2) Your required_bid is equal to (previous_bid + (R*(previous_bid - previous_required_bid))
3) When you place a bid, (D*(your_bid - previous_bid)) goes to dividends and (previous+bid + (1 - D)*(your_bid - previous_bid)) goes to previous bidder.
The initial required_bid will not be 0 and will decided by Delegates? So it will vary by different Delegates and how?
Will R still be 1 or a bit lower than 1 or very small like 0.1 or 0.2?
D is likely to be 1 and you will not have kickbacks when you are outbid, correct? The original bid you put will be returned to you totally or just a fraction of it (like 90% )?
What's the condition for a auction to be end? a specific time after it starts?(then how long?) A specific quantity of blocks produced after it starts(then how many?) or other condition set by Delegates or the sellor?
How renewal rate to be set?
And I think we will reserve top current famous domains for maximize system value by deliver/sell them to the related company in future, so what's the detailed plan? top 100? 1,000? 10,000?
Thanks.
52
中文 (Chinese) / Re: 谁能从数学上比较一下一票一投和目前的Approval Voting的区别
« on: August 04, 2014, 09:08:58 am »
看了楼上定量公式。觉得很有必要先谈一下定性分析。
一票一投
优点：
没有一票多投，大户间的联合不存在
缺点：
只要掌握了20亿/101的选票，就不会掉出前101。实际过程中由于投票率问题，稳当代表的门槛比理论值低很多，会进一步放大这个缺点。引入反对票可以多少改善下这个问题，但投票率还是绕不开。并且，大户也可以用反对票封禁特定代表。
一票多投
优点：
大幅提高了理论绝对代表权的门槛，投票率问题对两者的影响是一样的，所以这种提高是实际上的提高。
缺点：大户间联合成为可能。
我的建议：
一，保持一票多投，但是增加随机性。亦即你仍然可以选择向多个代理投赞成票，但是在交易发生后，实际得票代表仅为你所选择的代表的三分之一，随机选定。上限还是101人，但是规定下限，比如30人。这样仍然可以发挥当前投票规则对代表权门槛的限制，也可以减弱大户联合的能力。
二，尽快引入自动开除机制，从程序上设立代表硬指标，比如，连续miss 10个块就失去代表资格。uptime率下限。或者其他可以想到的指标。当然，这些硬指标不宜定得要求太高，重在识别代表发生变故或者蓄意作恶。因为投票机制响应速度有限，而有些特定的代表负面表现是需要系统自动采取行动应该不难在社区达成共识（我指肯定会有争议，但部分条件肯定不难达成共识）。当然不可能指望自动开除机制解决所有问题，否则也不用投票了，甚至有些潜在大问题也不是自动开除可以解决的，但是肯定能解决部分问题，提高系统效率。
当然，我以上的提议只是抛砖引玉，需要细化，而细化的话需要一些定量分析。所以后面可以尽量不要歪楼。另外，提醒大家讨论中注意，肯定没有完美的方案，我们要追寻的是一个切实可行的，各方面尽可能均衡的方案。就好比大户联合和绝对代表权门槛，两者至少在我看来是矛盾的，那么就要在其间找到平衡点。
一票一投
优点：
没有一票多投，大户间的联合不存在
缺点：
只要掌握了20亿/101的选票，就不会掉出前101。实际过程中由于投票率问题，稳当代表的门槛比理论值低很多，会进一步放大这个缺点。引入反对票可以多少改善下这个问题，但投票率还是绕不开。并且，大户也可以用反对票封禁特定代表。
一票多投
优点：
大幅提高了理论绝对代表权的门槛，投票率问题对两者的影响是一样的，所以这种提高是实际上的提高。
缺点：大户间联合成为可能。
我的建议：
一，保持一票多投，但是增加随机性。亦即你仍然可以选择向多个代理投赞成票，但是在交易发生后，实际得票代表仅为你所选择的代表的三分之一，随机选定。上限还是101人，但是规定下限，比如30人。这样仍然可以发挥当前投票规则对代表权门槛的限制，也可以减弱大户联合的能力。
二，尽快引入自动开除机制，从程序上设立代表硬指标，比如，连续miss 10个块就失去代表资格。uptime率下限。或者其他可以想到的指标。当然，这些硬指标不宜定得要求太高，重在识别代表发生变故或者蓄意作恶。因为投票机制响应速度有限，而有些特定的代表负面表现是需要系统自动采取行动应该不难在社区达成共识（我指肯定会有争议，但部分条件肯定不难达成共识）。当然不可能指望自动开除机制解决所有问题，否则也不用投票了，甚至有些潜在大问题也不是自动开除可以解决的，但是肯定能解决部分问题，提高系统效率。
当然，我以上的提议只是抛砖引玉，需要细化，而细化的话需要一些定量分析。所以后面可以尽量不要歪楼。另外，提醒大家讨论中注意，肯定没有完美的方案，我们要追寻的是一个切实可行的，各方面尽可能均衡的方案。就好比大户联合和绝对代表权门槛，两者至少在我看来是矛盾的，那么就要在其间找到平衡点。
53
中文 (Chinese) / [翻译]DNS .p2p 竞标说明书
« on: August 03, 2014, 04:07:24 pm »
edit8/4: 诸位，我再次检视这篇文章发现原文行文有描述不当的地方，造成原文和译文都比较难理解，准备明天白天调整下并加下详细例子。谢谢。
诚如南宫宫宫所言，DAC的内容比分配方式更重要，正好想起了前段看到的DNS竞拍规则，觉得很有意思，设计巧妙，故译出。供大家参考，探讨。谢谢。
DNS .p2p 竞标说明书
作者：Nikolai Mushegian
翻译：试手补天yidaidaxia http://weibo.com/u/1776463184
.p2p域名竞标
域名通过一种在很多方面与一般拍卖不同的竞标型机制出售。
首先，如果你的投标被超过了，不但你原来的投标额将被退回，而且新投标与你的投标之间的差额的一部分也将支付给你。这将激励对售价过低的域名进行投标。
第二个不同之处是，由于竞标机制激励投机者出售亏本的不佳投标，刚刚售出的域名将很可能很快重新出现在市场上。最终结果是，很少有域名会在那些不好好将其利用的人们手上滞留。
如果一个域名从未被投标或者已经过期了，那么任何人都可以启动该域名的第一次投标。如果你拥有一个域名，你可以在任何时候出售它。域名更新（译注：亦即重新注册，避免过期）是免费的（耗费一笔按字节计的转账费）。
以下是投标和支付规则：
最低加价额：
• 新域名的初始最低加价额是0。如果你拥有一个域名，你可以用任意初始最低加价额开始一场投标。
• 之后，最低加价额将是前中标额减去前最低加价额(previous_bid - previous_required_bid)。
支付：
• 如果是一个新域名，所有的初始中标额将会作为系统红利。如果是某人出售的域名，那么初始中标额将会付给出售者。
• 之后，下一份中标额将会按以下方式分配：
o 前中标额(previous_bid)将退回给前投标胜出者。
o 当前中标额与前中标额之间差额的一半((current_bid - previous_bid) * 0.5)也将付给前投标胜出者。
o 当前中标额与前中标额之间差额的另一半((current_bid - previous_bid) * 0.5)将作为系统红利。
这一竞赛具有以下特性：
• 如果你是第一个投标某一域名的人，并且你确实想买下它使用，那么竞拍机制会激励你按你愿意出的最高价付款。
o 如果没人在这之后投标超越你，那么你就是按你愿意支付的价格买下了该域名。
o 如果你没有赢得该域名，那么你可以拿回你的投标额，以及外加你投标额的50%，因为你的投标额(your_bid)和初始最低加价额(initial_required_bid)的差额总是等于你的投标额(your_bid)。
• 如果看到一个在售域名明显被低估，竞拍机制会激励你投标并且因此赢得报酬。你可以使你的投标额不超过最低加价额太多，这将让其他人比较容易地超越你并开启一场域名争夺战，而这么做则使你能将你的风险控制在一定范围内。
• 如果你投机性地投标而没有人超越你，（现在已经确定高估了该域名）你确定损失的机会成本将是持有等值股份(domainshares)所带来的红利。
由两个部分组成的投标
投标需要两笔交易：一笔委托交易和一笔开标交易。投标按委托排序，每笔委托必须引用前一次开标。这意味着，由于和你参与同一场竞标的某个人可能比你先委托但是比你晚开标，所以直到委托与开标之间的时间间隔过去后，一笔开标交易才能正式生效。
一笔委托交易简单地包含将公钥，投标，输出信息三者进行打包处理后的哈希值(H(pubkey, bid, output_ref))，这里的公钥(pubkey)就是用来生成委托交易花费地址的那个公钥——该公钥将在该委托被声明之后揭示(译注：即解密公开)，然后可以作为钱包能重新产生的随机数(nonce)。
译者说明：原文是Bitshares英文wiki的一部分。译文则应是bitshares中文wiki的一部分，中文wiki主体部分目前由麦可猫翻译，浮壹白校对，本人有幸参与其中翻译了这篇自己特别感兴趣的章节，尤其是有感于两位一直以来对社区的贡献，特此鸣谢。
中文wiki链接：http://wiki.bitshares.org/index.php/(zh)Main_Page
英文原文链接：https://github.com/BitShares/bitshares_toolkit/wiki/DNS-.p2p-Auction-Specification
首发比特股之家，链接：http://www.bts.hk/dns-p2p-auction-specification.html
诚如南宫宫宫所言，DAC的内容比分配方式更重要，正好想起了前段看到的DNS竞拍规则，觉得很有意思，设计巧妙，故译出。供大家参考，探讨。谢谢。
DNS .p2p 竞标说明书
作者：Nikolai Mushegian
翻译：试手补天yidaidaxia http://weibo.com/u/1776463184
.p2p域名竞标
域名通过一种在很多方面与一般拍卖不同的竞标型机制出售。
首先，如果你的投标被超过了，不但你原来的投标额将被退回，而且新投标与你的投标之间的差额的一部分也将支付给你。这将激励对售价过低的域名进行投标。
第二个不同之处是，由于竞标机制激励投机者出售亏本的不佳投标，刚刚售出的域名将很可能很快重新出现在市场上。最终结果是，很少有域名会在那些不好好将其利用的人们手上滞留。
如果一个域名从未被投标或者已经过期了，那么任何人都可以启动该域名的第一次投标。如果你拥有一个域名，你可以在任何时候出售它。域名更新（译注：亦即重新注册，避免过期）是免费的（耗费一笔按字节计的转账费）。
以下是投标和支付规则：
最低加价额：
• 新域名的初始最低加价额是0。如果你拥有一个域名，你可以用任意初始最低加价额开始一场投标。
• 之后，最低加价额将是前中标额减去前最低加价额(previous_bid - previous_required_bid)。
支付：
• 如果是一个新域名，所有的初始中标额将会作为系统红利。如果是某人出售的域名，那么初始中标额将会付给出售者。
• 之后，下一份中标额将会按以下方式分配：
o 前中标额(previous_bid)将退回给前投标胜出者。
o 当前中标额与前中标额之间差额的一半((current_bid - previous_bid) * 0.5)也将付给前投标胜出者。
o 当前中标额与前中标额之间差额的另一半((current_bid - previous_bid) * 0.5)将作为系统红利。
这一竞赛具有以下特性：
• 如果你是第一个投标某一域名的人，并且你确实想买下它使用，那么竞拍机制会激励你按你愿意出的最高价付款。
o 如果没人在这之后投标超越你，那么你就是按你愿意支付的价格买下了该域名。
o 如果你没有赢得该域名，那么你可以拿回你的投标额，以及外加你投标额的50%，因为你的投标额(your_bid)和初始最低加价额(initial_required_bid)的差额总是等于你的投标额(your_bid)。
• 如果看到一个在售域名明显被低估，竞拍机制会激励你投标并且因此赢得报酬。你可以使你的投标额不超过最低加价额太多，这将让其他人比较容易地超越你并开启一场域名争夺战，而这么做则使你能将你的风险控制在一定范围内。
• 如果你投机性地投标而没有人超越你，（现在已经确定高估了该域名）你确定损失的机会成本将是持有等值股份(domainshares)所带来的红利。
由两个部分组成的投标
投标需要两笔交易：一笔委托交易和一笔开标交易。投标按委托排序，每笔委托必须引用前一次开标。这意味着，由于和你参与同一场竞标的某个人可能比你先委托但是比你晚开标，所以直到委托与开标之间的时间间隔过去后，一笔开标交易才能正式生效。
一笔委托交易简单地包含将公钥，投标，输出信息三者进行打包处理后的哈希值(H(pubkey, bid, output_ref))，这里的公钥(pubkey)就是用来生成委托交易花费地址的那个公钥——该公钥将在该委托被声明之后揭示(译注：即解密公开)，然后可以作为钱包能重新产生的随机数(nonce)。
译者说明：原文是Bitshares英文wiki的一部分。译文则应是bitshares中文wiki的一部分，中文wiki主体部分目前由麦可猫翻译，浮壹白校对，本人有幸参与其中翻译了这篇自己特别感兴趣的章节，尤其是有感于两位一直以来对社区的贡献，特此鸣谢。
中文wiki链接：http://wiki.bitshares.org/index.php/(zh)Main_Page
英文原文链接：https://github.com/BitShares/bitshares_toolkit/wiki/DNS-.p2p-Auction-Specification
首发比特股之家，链接：http://www.bts.hk/dns-p2p-auction-specification.html
54
中文 (Chinese) / Re: 决定一个dac生死的不是初期如何分配，而是他有什么毛用
« on: August 03, 2014, 08:59:06 am »
后续增发部分好比是保障系统安全高效及后续改进的资金池，并且该资金池不由特定中心化组织控制，而是通过动态市场竞争获得。所以我绝对支持资金向受托人倾斜。只是比例及发行曲线问题肯定人人想法不同，毕竟除了资金池比例，通胀率，受托人成本/收益外，还有一个法币股价这个难以预料的因素在，没法真正量化测算。如果换成我，可能考虑增发50%，然后平均每年释放当前剩余增发资金的1/3（注意是当前剩余，所以是递减）。也没什么特别的计算，只是觉得这个比例可以兼顾资金池和市场预期
55
KeyID / Re: [ SNAPSHOT: 8/21 ] DNS
« on: August 02, 2014, 09:07:50 am »Anyone here thing the 7bn delegate subsidy is too high ? Lots of people in Chinese community complain about it.
I feel it's ok, we need resource to secure the network, and we don't know what's the best proportion. But 5bn(or a little bit lower) for delegates, others for public distribution(including PTSer/AGSer) should be a better balance between net security and public communication now... Anyway, let the market itself to verify how good this proposal is
56
中文 (Chinese) / Re: vote dac会很有前途
« on: August 02, 2014, 05:23:53 am »这个dac成功后，会应用很广怎么对应到选民呢？
大家想想，如果美国大选用这个是什么宣传效果
要是美国大选用这个，全世界也会用。
到时候，市值超越1000亿美元，很容易
来自我的 HUAWEI P7-L00 上的 Tapatalk
苦苦下载白皮书中。奈何下了半天没反应。。
57
中文 (Chinese) / Re: 建议：如果pts快照是快照后再宣布大家觉得如何？
« on: August 02, 2014, 03:56:43 am »Btsx就是过早发布快照时间，可见并不能解决问题，而是带来严重问题。bm事后曾经说过今后决不过早发布快照时间，而是等到快发布产品时再发布快照时间。但我看这样也仍然无法避免228的情形。
事后公布是从保护新人，支持者和新dac的角度出发的。而且此举并非干预市场，这条规则本身也是透明的，它会成为市场构成要素之一，最终和市场反应融为一体。
至于内部保密这个隐患，我愿意付出信任给开发团队，总是要衡量利弊的。和带来的好处相比较，这个事还是值得做。
228的问题非常明显，应该尝试一些新规则改善它，完善市场规则，而不该一成不变坐视漏洞，到头来损失的是我们自己。我希望能提供给新人，支持者和新dac最大程度的保护。
快照可以在一个时间段，由区块生成随机数，随机快照，到期解密。
找一种办法，从区块比如bts区块，任何人都不知道的取一个随机数，来决定新DAC的快照区块or时间。
比如9.1~9.30之间的某一时间节点。 9.30后加密自动解锁，公布快照区块。
这样没有人能预知何时快照，DAC开发者都不行，多好。
不用先生成再解密那么麻烦。看我前面提的建议
58
中文 (Chinese) / Re: 建议：如果pts快照是快照后再宣布大家觉得如何？
« on: August 02, 2014, 03:37:05 am »log老弟的建议很好，不过市场还是需要投机者在，否则就不热闹了。我觉得log的方案和目前确定发布时间的做法相比较，没有很显著的优势，反而让内部人士有机可乘
log老弟的建议很好，不过市场还是需要投机者在，否则就不热闹了。我觉得log的方案和目前确定发布时间的做法相比较，没有很显著的优势，反而让内部人士有机可乘
内部人士永远有机可乘，即使有快照提前宣布也还是可以提前布局，某种程度上，快照提前宣布带来的波动性对内部人士更有利。。我也觉得快照事后公布好，但是需要引入随机函数减少人为因素。建议: 每次等某dac做好了发布准备时，宣布取未来某一特定btsx区块链生成的随机数作为快照函数的输入，由此推算出一个过去的时间点作为快照时间，当然，该时间取值范围应该合理，比如一个月内。这样可以在减少快照波动的同时最小化人为因素。
59
Keyhotee / Re: Keyhotee Status Update
« on: July 26, 2014, 12:16:28 pm »If you're getting a different public key, you haven't successfully regenerated your account. To get the correct public key regenerated, you need the exact profile data previously entered (and the exact same KeyhoteeId).Help!1) It sounds like you successfully regenerated your key. If the public key you got matches your old one, then you have regenerated your key sucessfully.
I'm a Keyhotee founder ID user and I'm sure that I registered it suscessfully with 0.7 version. Actually, my founder ID is "Mike HAO" which is listed in btsx genesis block acount list as "mikeh-hao".
My problem is, when I try to log in on my computer today for getting the private key to claim the ID in BTSX, I found I forget my Keyhotee login password, actually I think I remember it but anyway I tried hundreds times but failed.
So per my understanding of the mechanism of Keyhotee ID, I created a new acount w/ exactly same register profile info and brain key so that I believe I could re-generate my acount to get the into it and get the private key for BTSX. I think I succeed to get my acount re-generated since when I create a "new identity" w/ "Mike HAO", system remind me that I've created a similar ID before.. I notice that, both of mail network and btsx network status in right bottom concern of the client is both "disconnected". So maybe that's why my "Mike HAO" ID not shows in the client now...?
So in summary, my question is:
1. As I described above, did I re-generated my acount sucessfully? If not, how can I do?
2. If yes to first quesion, no ID in the re-generated account now is due to no network? If no, then why no ID in the list?
3. If yes to second question, when could we have the newwork available then I could access to my "Mike HAO" ID and get the private key for BTSX...
BTW, at that time, I posted my public key "5cU7QvmB7ZLxcVjm1bwmvSmgZxduqZGFBgMDh8TPhkdYMnjSgS" here and you confirmed it recorded, which is true because it's in BTSX genesis block now. And I'm using the last release windows verions(0.7.230-win32) now.
Appreciated if you could look it and provide me your advice..
Thanks a lot.
2) it's quite possible the mail server for KH is down right now, I've not been involved with mail server handling for a few months now. I logged on to the server just now, and it "appears" to not be running for some reason, don't know why.
3) You don't need the mail server to access your private key. Your private key is stored in your Keyhotee client itself along with your public key. You just need to export this key to your bitshares client. I haven't done this yet myself, but the procedure for it is here:
http://wiki.bitshares.org/index.php/BitShares_X_Solutions#How_to_import_Keyhotee_IDs
Thanks for quick response.
1. The new public key does not match the old one. But the client remind me that I've registered this ID(Mike HAO), and does not allow me to "save" it. The new public key is "76UX9KAnd4Au6d6EDqRSKQQjsLBDqvk8j6UpjaswatEreSVkMb", while the old one is "5cU7QvmB7ZLxcVjm1bwmvSmgZxduqZGFBgMDh8TPhkdYMnjSgS". I still think I've succeeded to re-generate mu account, otherwise how system could identify I(my acount) already had ID "Mike HAO" when the client not being sync to the newwork.
2. I know the process to claim my ID on BTSX, but I could not access to ID "Mike HAO" now, since there is no ID in my new re-generated account and I could not re-create "Mike HAO" in this account due to system identify it's as duplicated... and no private key could be exported...
Any further advice...? Thanks.
quesiont: is login password part of "profile data" ?
60
Keyhotee / Re: Keyhotee Status Update
« on: July 25, 2014, 04:27:38 pm »Help!1) It sounds like you successfully regenerated your key. If the public key you got matches your old one, then you have regenerated your key sucessfully.
I'm a Keyhotee founder ID user and I'm sure that I registered it suscessfully with 0.7 version. Actually, my founder ID is "Mike HAO" which is listed in btsx genesis block acount list as "mikeh-hao".
My problem is, when I try to log in on my computer today for getting the private key to claim the ID in BTSX, I found I forget my Keyhotee login password, actually I think I remember it but anyway I tried hundreds times but failed.
So per my understanding of the mechanism of Keyhotee ID, I created a new acount w/ exactly same register profile info and brain key so that I believe I could re-generate my acount to get the into it and get the private key for BTSX. I think I succeed to get my acount re-generated since when I create a "new identity" w/ "Mike HAO", system remind me that I've created a similar ID before.. I notice that, both of mail network and btsx network status in right bottom concern of the client is both "disconnected". So maybe that's why my "Mike HAO" ID not shows in the client now...?
So in summary, my question is:
1. As I described above, did I re-generated my acount sucessfully? If not, how can I do?
2. If yes to first quesion, no ID in the re-generated account now is due to no network? If no, then why no ID in the list?
3. If yes to second question, when could we have the newwork available then I could access to my "Mike HAO" ID and get the private key for BTSX...
BTW, at that time, I posted my public key "5cU7QvmB7ZLxcVjm1bwmvSmgZxduqZGFBgMDh8TPhkdYMnjSgS" here and you confirmed it recorded, which is true because it's in BTSX genesis block now. And I'm using the last release windows verions(0.7.230-win32) now.
Appreciated if you could look it and provide me your advice..
Thanks a lot.
2) it's quite possible the mail server for KH is down right now, I've not been involved with mail server handling for a few months now. I logged on to the server just now, and it "appears" to not be running for some reason, don't know why.
3) You don't need the mail server to access your private key. Your private key is stored in your Keyhotee client itself along with your public key. You just need to export this key to your bitshares client. I haven't done this yet myself, but the procedure for it is here:
http://wiki.bitshares.org/index.php/BitShares_X_Solutions#How_to_import_Keyhotee_IDs
Thanks for quick response.
1. The new public key does not match the old one. But the client remind me that I've registered this ID(Mike HAO), and does not allow me to "save" it. The new public key is "76UX9KAnd4Au6d6EDqRSKQQjsLBDqvk8j6UpjaswatEreSVkMb", while the old one is "5cU7QvmB7ZLxcVjm1bwmvSmgZxduqZGFBgMDh8TPhkdYMnjSgS". I still think I've succeeded to re-generate mu account, otherwise how system could identify I(my acount) already had ID "Mike HAO" when the client not being sync to the newwork.
2. I know the process to claim my ID on BTSX, but I could not access to ID "Mike HAO" now, since there is no ID in my new re-generated account and I could not re-create "Mike HAO" in this account due to system identify it's as duplicated... and no private key could be exported...
Any further advice...? Thanks.
