2020.6.13讨论话题 关键字 贡献协议的修改完成、fchwallet.com支持导出私钥了、 知识库协议的修改、重放攻击漏洞讨论、基于fch的 类似google验证码这样的服务讨论。



  • 2020.6.13讨论话题 关键字 贡献协议的修改完成、fchwallet.com支持导出私钥了、 知识库协议的修改、重放攻击漏洞讨论、基于fch的 类似google验证码这样的服务讨论、
    一棵树上@昌用CID:CY_vpAv :贡献大概什么时候好,有个问题 转账金额 0.00011000 报错 dust 64.。然后把 转账金额 改成 0.00021000 转账成功。 但是接下来的 0.00011 转账 又能执行成功 是为什么了?
    刘教授回复:可能是看总额,总输入总输出。贡献协议改好了:https://shimo.im/docs/Gzfm4F96eG8xZGd4/  《FOCP1V5_贡献填报》,我再改改知库协议,发现了一些问题。
    一棵树上提问:我看了下那个协议文档 需要表格。 
    刘教授回复:@一棵树上 贡献协议,freedrive数据里,metadata增加一项:语言,language。我在协议中已经改了。
    一棵树上回复:好的。zh_cn?
    85973FF5-54AD-499C-9B7E-385FBD017E1F.jpeg
    刘教授回复一棵树上: chinese,japanese 。
    pisa@昌用CID:CY_vpAv 说道:fchwallet.com 支持导出私钥了,可以看下。选择某个地址即可,
    BA36BB2B-8FF6-44A2-88B4-81439F7E4DD6.jpeg
    刘教授回复@pisa_n5oN:好的,我通知用户。
    刘教授回复一棵树上:这是贡献的第5版相对于第4版的全部改动供参考。
    一棵树回复:https://shimo.im/docs/Gzfm4F96eG8xZGd4/ 以这个为准是吧。
    刘教授回复:是的,上面的比较文档,把改动全部显示出来了。
    一棵树上回复:好的。
    刘教授@大师CID:master_SAe7 @一棵树上 :《知库》的逻辑和数据结构我做了调整,可以先不更新,审核一下,有问题讨论修改。https://shimo.im/docs/YANuwfI5qAEYu9AO/  《FOCP3V2_知库》,从1版升级到2版的修改内容。整个流程更清晰了。商业逻辑删掉了,这个恐怕要应用去慢慢摸索,现在还不好设计。
    一棵树上回复:https://shimo.im/docs/YANuwfI5qAEYu9AO/  这里也更新了吧。
    刘教授回复:这是最新的。bbs论坛的列表我会随时更新:https://bbs.cash/category/20/ 另外,我正在写协议体系的创建使用协议,用主链和freedrive存储各种协议,并形成较为规范的协议发布、更新、实现等流程。目标是,实现一个有序自由竞争的协议市场。
    李国荣提议:FCH有没有类似BTC、BCH、BSV存在的bip143导致的重放攻击漏洞?微博有文章猜最近的天价手续费事件就是黑客在利用这个漏洞在进行勒索。各位技术大拿,FCH有没有类似BTC、BCH、BSV存在的bip143导致的重放攻击漏洞?微博有文章猜最近的天价手续费事件就是黑客在利用这个漏洞在进行勒索。
    刘教授回复:看巴比特上文章说是隔离见证交易存在的问题。细节还不了解。如果你的软件或流程允许你使用硬件钱包来花费隔离见证(segwit)输入,请检查你的系统是否与钱包的最新固件更新保持兼容。如果只是隔离见证交易才有,对fch是好事。fch的离线签名方案更有市场。
    李国荣回复:比特派钱包的技术文章说是因为bip143协议,所有沿用或copy此协议的链,包括bch分叉时也沿用了这个协议,都有此漏洞。fch也是copy的bch,我怕它也沿用了这个bip143协议。这个微博有比较详细分析,https://m.weibo.cn/5166192059/4514745930431085 
    刘教授回复:大概明白了,主要针对冷钱包。但密签不受影响,密签每次签名的utxo是用户选择和检查后签名的,不存在在线端构造假utxo反复欺骗用户的问题。对主流冷钱包算是个漏洞。他们冷热两端封装utxo,用户只确认金额,不管utxo,密签麻烦些,但确实安全,是用户自己能够掌控的安全。我们的各种协议要求op_return内容可读也是为了这种安全性。用户知道自己签名的是什么。
    李国荣回复:看来不是协议的问题,而是应用的问题。fch和密签的优势,应该利用这次漏洞事件进行一轮宣传。
    刘教授回复:可以的。
    刘教授@facjas @随心 @比特邹 @一棵树上:这四个公众号已经建的有模样了,可以列入门户里了。
    pisa_n5oN提议:我们可否做一个,基于fch的 类似google验证码这样的服务?最近在写freedrive的接口的时候,@一棵树上 18.cash 向我们反馈我们我们签名这块逻辑的问题,我们仔细想了下,也许有更好的方案。 所以想到基于区块链的类似google验证的方案。
    Skeyil1lLiaeyr₿ch问到:google的otp验证码那样的吗?
    pisa_n5oN回复:是的,google 是 30秒过期,我们可以1个区块过期,
    , 交互验证码可以用 基于tx的 ecdh逻辑来做。而且,未来,我们应用很多后,其实大量依赖签名验证服务。freedrive 就那么几个接口,我感觉每个接口都需要签名验证。当前做法是,让用户签名data, 但是签名data 有2个问题:
    1,data大小的问题,会让实现成本变大
    2,如果data一样,其实签名还是一样的,存证泄露的问题,第一点,是@一棵树上 给我们反馈的,虽然问题不是特别大,但是还有点点别扭。
    第二点,天然存在,包括现在大家用CID登陆的时候,签名的 10个字符串的问题。拿freedrive来说,我们是要如果A 拿到 B 对 data的签名的数据,实际上,A可以以B的身份来提交B的数据,而这个时候我们还以为是B。而通过,freedrive的中心化服务器,返回一个待签名的 msg 让提交的人签名,也是可以的,但是这样做总感觉不好。想了下这样做的好处,可以让实现成本低一些,待签名的数据,不是以明文形式传输,是算出来的,这样大大降低泄露的可能性。所以这个返回待签名的服务,如果能做到去中心化,就更好了,过期时间,就按1个确认或者几个确认。 还有一点,能利用区块链“见证”的特性。目前只是一个初步想法还没有想清楚。
     一棵树回复:签名登录 建议 tx字符 需要平台处理。能先把文件大小改下?5m放不了一个视频改成20m刚好。图片还能压缩下,视频不知道怎么处理了。
    pisa_n5oN回复:5M -> 20M 得我们把计费功能做好哈, 让大家付fch。
     一棵树回复:既然收费。那就利用txid把。做签名,一步到位。
    pisa_n5oN回复:当做文件读入。恩,想清楚,把连带的几个问题,看看能不能一并考虑了,反正现在还是先前的那样。
    一棵树上回复:我现在还是从服务器上直接拿文件。 等到七月份在解析你的数据。
    pisa_n5oN回复:可以,大家一起互相推动优化。
    刘教授@pisa_n5oN :我对freedrive的存取流程还不太清楚。开放去中心的方向是没错的。
    pisa_n5oN回复:freedrive本身是去中心或者弱中心的,不会因为我们不在了,数据丢失。只是大家现在还没体会到。
    刘教授回复:现在的在线私钥不适合在多个应用之间共享。考虑一下如何消除在线私钥中心化的安全性问题。
    pisa_n5oN回复:没变,只是在讨论方案。
    一棵树上回复:另外有个建议,知识库内容那块。直接html数据结构。别搞什么#分割。处理也麻烦。
    一棵树提议:像这里 #分割。 程序处理还需要分割 直接html的表单。 多好。还有那个类型。 直接tag就行。
    pisa_n5oN回复:这个是应用协议,未来应该可以用markdown格式。freedrive不解析应用协议,可以,不过其他币没cid,优势不明显。cid不是技术问题,是方向选择问题。
    刘教授回复:协议在应用过程中不断优化,我主要考虑粗的逻辑,技术细节你们实现时多打磨。
    一棵树上回复:Data type 应该标注的是 文件类型。比如文字 图片 视频 doc文档 压缩包 之类的获取到数据,根据对应的文件类型 执行对应的操作应该边标注在metadata哪里。 解析方便些。然后data区域,只放数据。这样就不用分割文本。因为到时候, 分割一个几十几百m的文本。 程序处理也需要时间。很耗内存。
    刘教授回复:知库不一样,你说的是文件引用。
    一棵树上回复:https://shimo.im/docs/YANuwfI5qAEYu9AO/read 没看到。
    刘教授回复:知库的data里面的type指的不是文件类型,是知识类型。
    一棵树回复:这个也放到metadata里面去吧,Data数据太大,文件分割。很耗资源。想下其他办法解决。
    刘教授回复:内容不是单个文件 类型应该是数据的一部分。目前知库的data部分都是文本。
    李国荣提问:data里标记一下文件类型,放到开头,行不?
    刘教授回复:知库的data数据量真不大。里面如果涉及到图片视频,是通过文件引用协议存到其他地方的。文件的类型都已经放在metadata了知库的data里的type讲的是知识的类型,不是文件的类型,里面也没有文件。
    一棵树上回复:author|type|title|content 假如这个,我需要分割成数组。 然后才能取得content。
    刘教授回复:是的,只有content,没有title也没用啊。而且这个是freedrive的存储,并不用”|"分割。
    一棵树上回复:放到metadata 可以直接拿了。
    刘教授回复:freedrive的存储方式你问@pisa_n5oN。freedrive的各种存取规则的细节还是要放在知库协议里,否则会乱。主链的存储,我能够写的很清晰了。freedrive这部分需要细到,开发者不用问你,就能直接开发。写一次,就可以放在各个相关协议了。
    刘教授@一棵树上 :数据采取变长加填充方式。变长:通过前导的长度字段来限定内容的起止位置,而长度字段本身的长度由协议规定。填充:是指某个字段为空的时候,内容部分填充0x00标识这个字段内容为空,这个时候长度字段为0x01, 表示一个字节长度的空内容。主链和freedrive的存储规则不一样,各是各的。主链要求用户可读,可识别。freedrive现在用到的有两类,一种是存单个文件,比如文件引用,协议存证,这时所有的文件属性放在metadata里。一种是文本数据,比如贡献和知识,每条贡献或知识有几个字段,这些字段都放在data里。freedrive主要面向开发者,注重效率。
    263E7CFA-7AFB-45FE-9405-7B89F23A74A6.jpeg
    刘教授回复:需要解决"便利不安全,安全不便利"的问题,在安全便利之间不断寻找更优的解决方案。
    Skeyil1lLiaeyr₿ch回复:谷歌的类似于 私钥+时间戳 的哈希吧。那就可以用 私钥+当前区块hash 的形式了。
    刘教授@大师CID:master_SAe7 @一棵树上: 可以以知库为例,测试一下不同平台的数据是否一致,是否能实现跨平台操作。
    大师跟一棵树回复:收到。
    pisa_n5oN提出:这个里面提到的未来学校,学习中心,知库可以形成一个 FCH版本的未来学习中心。https://item.jd.com/48162042613.html 区块链学习开发,我们从一开始,逐行看比特币代码开始,趟过很多坑,有时候还是没明白很多概念。 有些东西需要点拨,光是堆叠知识内容,如果方向思想不对,只会是负担。
    刘教授回复:确实,教育也要变了,知库是底层,做起来,后面的知识传播系统也要变。希望大家能够在fch的开发过程中多交流。创新的领域,创始人也没有成熟的知识体系,需要更多人协作探索。
    pisa_n5oN提出:特别有意思。注意他不是说区块链哈。但是我们可以多想想,知库的建设上,也许可以借鉴思路。
    刘教授回复:可以借鉴,学分的认证可以是去中心化的。依靠认证方在生态中的信誉获得公信力。
    刘教授说道:fch社区是一个免费的学校,带实操实习,我把7年经验和教训倾囊相授其他人也是类似学到的人也愿意教给别人,像海波和小宝这样,这才是信息世界应有的状态因为,信息本来就是越传播越有价值这个变化太大了,理论也肯定会有巨大变化稀缺性不再是信息经济的逻辑起点想想看,后面会带来多少变化?我都没顾上细想要做的事太多了,需要更多人参与我的感觉是,发现了一个宝库,一个人根本拿不了,希望更多人一起搬。经济行为变了,后面的政治、社会、文化活动都会变一定要准备好接受变革的头脑,才能装下新的财富。


Log in to reply