Quote from: asenski on May 08, 2014, 09:21:08 pm

When designing a DPOS you have to assume that at some point the delegates may decide to act together and coordinate in their own interest and misrepresent information. Are there mechanisms in place to prevent that from happening?

Sent from my iPhone using Tapatalk

Assuming 51% of the delegates decide to collude they could block transactions just like a 51% in bitcoin.   However, they could not sign alternative blocks without getting fired.   If the average shareholder elects people that will collude to harm the network then the network will end up getting hard-forked and continue with new delegates... not pleasant but not the end of the world and certainly much better than Bitcoin mining pools colluding.   

If less than 51% are colluding they will get fired for signing false blocks and would certainly get caught.   

Light weight clients could query multiple delegates which are unlikely to collude to defraud them... this is a similar principle to Ripple.   

As the delegates have a stake in the network, an income stream, and their ability to retain control after attempting to harm the network is near 0 I don't see this as a legitimate threat.

The graph has X and DNS, and eventually will have others. It will show the snapshot relationship. It'll be much clearer when I can clean it up

Sent from my SCH-I535 using Tapatalk

This test was very helpful and we learned some critical details:

1) We learned our wallet data storage (flat-file JSON) is subject to corruption and catastrophic failure despite efforts to write a backup, move it into place, etc.  It also didn't scale well.   So I have created a new wallet that uses a database for managing the data.

2) Internal testing revealed some network-layer issues that we have been fixing and are now mostly fixed.

3) We are doing some studies now on network propagation delay to make sure that 30 second block intervals are safe.

4) We have identified a challenge in paying delegates... micro-payments from the transaction fees are 'unspendable' by normal means because the fees are higher than the output amount.   

5) While working to solve these issues in the background I was also thinking about how we were going to handle fees paid in BitUSD, etc.   

6) The trustee client crashed and was a single point of failure.  We are working on approaches to help our trustee (and delegates) rapidly recover from failure to keep the network running without delay or manual intervention.

Overall I am pleased to say that we have an updated framework in place that should be able to handle all of our chain forks and actually enable full up DPOS with delegate signing rather than relying on a trustee.   When integrated with the crash recovery code should provide a much better experience.

Quote from: sudo on May 07, 2014, 04:03:02 pm

Quote from: sfinder on May 07, 2014, 02:53:40 pm

Quote from: ripplexiaoshan on May 07, 2014, 02:42:09 pm

现在我最担心的绝不是3I的进度了，而是整个BTC市场的行情。BTC市场烂下去的话，就算BTS什么的都出来，还是没有用户量啊。

你目前在哪里，天朝地界应该只关心btc价格。美国加拿大目前应用越来越多，因为比特币技术目前最有吸引力的是小额支付，美国加拿大的便利小店如果用bitpay类似的pos终端，每天可以从支付公司处省90%的费用（100-500美元），对小生意人来说，是笔巨大的节约。


关于btc的价格一定要以年来计算，不能太短视。 btc价格的波动不影响其几乎无费用支付的特性。

bts的bitusd能把这块蛋糕抢来么？

这个不大可能，bts不侧重支付这块，bts只关心交易，价格锚定和DAC

Quote from: sudo on May 02, 2014, 06:10:36 am

比如block 0~10000  可以只让一部分重要节点去保留啊。
全网只保存hash即可。篡改的话 hash对不上。
新用户就不用从头开始同步了啊。
直接从block10001开始即可

hash只能保证不可篡改，数据的完整性和 原始数据的安全性谁来保证。