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.


Messages - nametooshort

Pages: [1] 2 3 4
1
这样以后买车就要先下载几个小时的区块链?中国的网速太不实际了 :(

2
中文 (Chinese) / Re: Dpos的优化设想
« on: July 30, 2014, 03:40:14 am »
轻钱包还是应该中心化的组织来做。一个恶意的节点成本不高,信任随机的几个节点肯定很危险。
可以用类似于共识机制的方法,每个新 seed node 都要有经过3i或其他 seed node 签名的证书才能加入网络。还可以让客户端选择使用哪一个 seed node。

4
大家都无聊到开始水贴的程度了么。。。
谁叫3i还不出产品。。。喷子们都没喷点了。。。

5
其实比赛结果也可以用共识机制确定,毕竟大家都知道比赛结果。

6
我认为是这样的,不晓得对不. 交易是广播给全网,但只有100个当前获得记账权限的节点NODE1- NODE100才接收交易清单,如当前轮到NODE 5 记账,记完块一发布,如果发现和其余51个节点对不上.
1.NODE5 发布的区块被否决;
2.NODE 5 被记大过 ,被踢出代表队伍.
3 NODE X马上生成新区块.
对上了把区快全网发布。

以上算法问题是,
1.51%攻击仍然有效.
2.如果实际控制了31% 节点.让别的40% 机器被DDOS攻击,是可以30台机器联合造假的. 实际概率很小(无IP记录,HASH值)。但时间久了,长期轮守的NODE,获取这些NODE IP是可能的。

我觉得系统还是应该有套应急机制, 建立分级候选代表制度(500NODE),这些代表平时可以接收交易清单缓存,记录但不记帐,对效率没有影响。一、随时进入100代表。二、是应急情况启动扩大代表投票(牺牲效率)。
1.新区块产生了60:40,或者80:20等反常情况。
2.10个以上的代表NODE无响应.
3.记帐记录3个以上节点出现相互混乱。
4 .连续轮换3个代表,多长时间,均不能产生新区快。

以上的阀值,触发应急系统,100个代表,扩大到600,替补代表参与区块产生,直到大于51% 达成一致。
你们都没考虑一个问题,DPoS是以区块为单位的,所以在不能产生区块或发生反常情况时还需要等下一个区块才能防止攻击所造成的影响。
兄弟,如果是挖矿,确实有这个问题。
如果是交易数据维护没问题, 我的意思是100个代表都保存了交易记录,但只有一个代表负责写,写完了区块广播出来,如果和100个代表中大多数的记录有差异,这个区块就被否决。
但是让整个网络接受踢出这个代表就需要下一个区块。

7
我认为是这样的,不晓得对不. 交易是广播给全网,但只有100个当前获得记账权限的节点NODE1- NODE100才接收交易清单,如当前轮到NODE 5 记账,记完块一发布,如果发现和其余51个节点对不上.
1.NODE5 发布的区块被否决;
2.NODE 5 被记大过 ,被踢出代表队伍.
3 NODE X马上生成新区块.
对上了把区快全网发布。

以上算法问题是,
1.51%攻击仍然有效.
2.如果实际控制了31% 节点.让别的40% 机器被DDOS攻击,是可以30台机器联合造假的. 实际概率很小(无IP记录,HASH值)。但时间久了,长期轮守的NODE,获取这些NODE IP是可能的。

我觉得系统还是应该有套应急机制, 建立分级候选代表制度(500NODE),这些代表平时可以接收交易清单缓存,记录但不记帐,对效率没有影响。一、随时进入100代表。二、是应急情况启动扩大代表投票(牺牲效率)。
1.新区块产生了60:40,或者80:20等反常情况。
2.10个以上的代表NODE无响应.
3.记帐记录3个以上节点出现相互混乱。
4 .连续轮换3个代表,多长时间,均不能产生新区快。

以上的阀值,触发应急系统,100个代表,扩大到600,替补代表参与区块产生,直到大于51% 达成一致。
你们都没考虑一个问题,DPoS是以区块为单位的,所以在不能产生区块或发生反常情况时还需要等下一个区块才能防止攻击所造成的影响。

8
中文 (Chinese) / Flappy DAC的设想
« on: April 06, 2014, 11:11:20 am »
这是我在bitcointalk上头脑风暴想出来的,版上的朋友不要喷啊……
Flappy DAC包含了一种新的区块产生机制。每一次区块产生的间隔相当于Flappy Bird中鸟跳起来的时间(每次5分钟的间隔相当于Flappy Bird中的大概0.5秒),每个区块保存每个参与游戏并且在线的地址的动作(跳或是不跳,不在线或暂时不想参与的节点不提交交易)。每个节点都以超慢速度(区块速度)模拟游戏,撞到柱子的鸟的分数归零。新区块一部分由PoW/PoS生成,一部分由Flappy Bird中分数最高的地址生成。当这个地址生成两个区块后,分数也归零。还可以通过Flappy机制实现Delegated PoS的透明挖矿,由分数最高的人生成PoS区块。

9
中文 (Chinese) / Re: 能不能搞个vpn功能dac
« on: April 05, 2014, 02:34:20 am »
vpn使用者会产生海量数据,比如上传或者下载youtube的视频,这些数据是不可能放入块链之内的。
如果离链提供vpn服务,块链只是提供计费或者匹配 ’服务交易‘ 的功能,在我看来这与传统vpn并没有什么本质区别,也未必能逃的过goverment的封杀。
可以通过只由几个节点转发的侧链来实现建立隧道,这样可以逃得过封杀,而且参与节点也可以得到回报。

10
中文 (Chinese) / Re: 能不能搞个vpn功能dac
« on: April 04, 2014, 10:08:55 am »
支付可以通过address-only的侧链和一套协商机制来实现,或许侧链还能用来传输数据,这样就不怕被封了 :)

11
中文 (Chinese) / Re: 动态加密
« on: March 30, 2014, 02:29:09 pm »
犯了密码学的大忌:自定义非公开加密算法。

  :-[ ,读得书少,不要见怪。

人类大脑计算出来的密码的长度根本不算安全啊……


这方面我不是好懂,我只是好奇,以后加密能否设计成这样。对于这动态密码每个时间段都不同的。特别是软件给出的动态数来运算。再加运算结果后面如果是小数可以忽略不要的话,更难了,依靠几个整数结果(密码)去破解一个有几个无知小数是多少的情况下。能反破解出运算方式不?没破出运算方式,你就永远不知道密码是多少。
但是把-9999999到9999999试一次用不了多少时间,破解15位数的静态密码反而需要更久

12
中文 (Chinese) / Re: 动态加密
« on: March 30, 2014, 07:16:15 am »
犯了密码学的大忌:自定义非公开加密算法。
人类大脑计算出来的密码的长度根本不算安全啊……

13
中文 (Chinese) / Re: 关于AGS的安全性确认
« on: March 30, 2014, 02:23:13 am »
其实对此我也有疑虑,因为AGS比较特殊,地址不可以变更,而在领取赠送时私钥必须连上网络,这就不能做到捐赠后确保冷存储。
建议钱包导入功能可以不仅仅是导入私钥,而是对特定信息的签名也可认作支付凭证。这样就能确保私钥离线而领取赠送。
可以直接把捐赠的钱包冷储存,到时候把钱包再复制出来导入

14
中文 (Chinese) / Re: keyhotee的建议-自我感觉很好
« on: March 24, 2014, 12:55:16 pm »
如果附件不进块 ,还能保密吗
非对称加密,要用对方的私钥解密。

15
中文 (Chinese) / Re: keyhotee的建议-自我感觉很好
« on: March 22, 2014, 05:57:51 am »
其实允许1M附件都是错误的决定,应找个云服务商合作,把附件存云服务商那里只把短连接+提取码+附件hash 记录进块链。
附件不是进块链的,是用类似于I2PBote的机制储存的。

Pages: [1] 2 3 4