I like moonstone ,I don`t understand what you said , don`t forget  BTS is a open ecosystem

hope they change their minds and decide to open source "moonstone" without the need to raise the $120000 first***...

I think moonstone can open code or not  , it is just his strategy.
I think we should less comment about it .

Quote from: BTSdac on May 13, 2015, 02:48:23 am

Quote from: xiaorui.dong on May 12, 2015, 06:53:51 am

   求助，我在本地搭建代理节点想测试代理出块的流程。可是总有几个代理不出块，查看代码
   在void wallet::sign_block( signed_block_header& header )函数里面的如下断言出出错。
   FC_ASSERT( fc::ripemd160::hash( header.previous_secret ) == *prev_secret_hash );

   求大神能告诉下，哪些情况会导致这两个hash不相等呢，从而导致校验不过呢？
   PS：最好能解释下这里的header.previous_secret和prev_secret_hash的含义和作用。原谅小白对这个签块模块机制不太明白。可以解释下最好

previous_secret :每个代理出块时候都需要发布一个随机种子, 每轮用所有101个随机种子组合成随机数, 来洗牌下轮代表顺序. 但为了防止代表知道其他人的随机数后,自己生成一个对自己有利的随机种子,所以代表都先提前一轮公布随机种子的HASH, 这样就算知道其他代表的随机种子后,也不能更改自己的随机种子.
所以这个随机种子也叫秘密随机种子.

prev_secret_hash: 秘密随机种子的HASH ,

那什么样的情况下会导致我发布的这个prev_secret_hash 跟head里面存的header.previous_secret算出来的hash不一样呢？
[/quote]
[/quote]
程序不诚实 ? 

地址余额小于10的忽略，奖励马上发。

不错啊，余额小于10 发0.2BTS，没意义，

我弄了一个背书币

you gays do not know marketing  ,stupid discussing

BTC 发布一年内也经常更新，

if we decrease block interval , it would decease confirm time, but it would increase block size, become each block is 188B size at least.
I `d like to introduce a block-chain model to decrease block interval  but never increase block size so much.
1.there is a buffer -chain parallel with main chain. the buffer chain include all TX as normal block-chain.
2.this buffer-chain only keep 1 day , it mean buffer chain 1 days ago would been discard.
3.block interval of buffer -chain is b1 second that is less than main-chain m1 second
4.as follow picture show head of each block in main chain have to include the previous block hash in main chain , also include the recently block in buffer chain, set m1/b1=integer,
5.include all translation in blocks in buffer-chain that between block in main -chain. , so all TX have been included in main-chain ,the we can discard the buffer chain now ,

Quote from: BTSdac on May 08, 2015, 05:46:56 pm

Quote from: planetlife on May 08, 2015, 04:29:55 pm

呵呵，又是投票问题，这个讨论过N遍了，也没见改进，我的意见罗列如下：
1、一票101投毫无该进的空间吗？说了N久，啥都没改进，这项规则导致一个大股东直接霸占所有的投票权。建议改成一票十投，可以支持不超过十个人受托人，有助于扼制一下大股东的滥投，给中等股东一些机会。每个人都有一定的认知范畴，超过对十个受托人的深刻了解，基本上不靠谱，从这点意义上来说，一票十投足矣。
2、系统无反对票设置，简单启用反对票可能会影响系统的稳定，但无反对票的危害已是历历在目了，建议设置反对票，反对票一票一投，并且反对票是半公开化的（受托人可以查看到反对者的账号），半公开化机制可以扼制一下随意乱投反对票的账户，毕竟反对一个受托人需要一定的理由。
3、建议设置一个投票有效期，譬如一年，一年后，投票失效，重新投票后可以有效一年。

我以前也是一直对投票机制感到困惑，但我最近好好了解了一下
1.如果一票10投，如果你持有1%的股份，如果你投满10个人的话，那么相当于你最大能投满10%的票，系统总最大投票数为10*100%=1000%，但每个委托人可以获得最高100%的投票，相当于他获得系统最大可能投票额的10%。如果有10个很厉害的委托人，他们就可以获得全部的系统投票，但还剩下其他91的委托人可能面临票很低的地步，如果实施自动投票的话，这样可能会对系统比较危险。
反过来一票101投 每个代表实际上只能最大获得1%的系统最大投票票数，而且每个代表都能获得这么多。说的有点绕，如果有心的话，可以慢慢安静下来想想。
和就和一个公司需要投票选101个员工一样，如果你只选一个人，那么你只使用了1/101的投票份额。 所有大家最好投满101个人，如果大家都投满101人话，BM就基本没有话语权。
2.直接反对票不可行，我已经解释了，
3.这个可以有，

1、假设的前提就不具有可行性，大部分BTS股东都认不全哪怕30个受托人，逞论101个受托人，让他们都滥投101个受托人的制度意义何在？此为其一，其二，按照你的逻辑，10个很厉害的委托人，在101投的机制下，可以轻松直接控制101个受托人，这个就是典型的黑天鹅事件；其三，美国总统精选的投票也不过50-60%这样子，可见对于责任分散模型下的投票，不要指望太高，事实证明BTS系统从诞生到现在投票率都没有超过25%，哥们，你打算怎么号召大家都去投票呢？对于一个不可能的假设前提，后面的推论都是毫无意义的。
2、在一票十投的前提下，反对票的意义更加彰显，很显然，股东们的一票否决权，有赖反对票来保障，反对票是一票一投，你相反对谁，你也是被严格限权的，那么，你肯定倾向于反对掉，你最讨厌的受托人，当然，你是股东，你可以这么做，反对权力的大小依赖的是你的股权数。而且你的反对票模型是建立在一票多投的情况下，已经不适合分析同意是一票十投，反对是一票一投的机制了。

对于 3%代表，他们的任务只有两条
1.正确的出块
2.使用更快的带宽和更好的CPU以最快的速度出块

每个股东不需要认识这些3%代表是谁，
1.每个股东的客户端可以验证这些代表是不是正确的出块的，
2.每个股东的客户端可以根据自己和代表的连接速度 来确定代表是不是以最快的速度出块
所以如果投票策略改成这种
1.投票给自己选定的代表
2.投票给和自己连接速度最快的 3%代表
3.投票给出块稳定率最高的3%代表，

3种方式优先级迭减。并且最后投满101 代表，这样的话，肯定投票率很快上升到30% 以上