BitShares Forum
Main => 中文 (Chinese) => Topic started by: crazybit on June 11, 2014, 11:48:56 am
-
对编程有兴趣并有志于将来从事dac开发的程序员，bitshares toolkit绝对是一个宝藏，里面涉及p2p网络编程，块链技术，密码学，系统架构等知识，本着共同学习共同进步的宗旨，特开一群(群号码：341632119 )专注于bitshares toolkit学习与研究，为保证群员质量，第一次申请加入会暂时被拒绝要求回答关于toolkit 的一些问题。在此诚邀对Bitshares toolkit 有一定了解的程序员加入。
-
+5%
-
我有个建议，你们程序员在群里研讨的结果或者成果，到时能不能定期拿到论坛上让我们这些不懂程序的人看看，分享一下？
也许别人能够从经济、投资、风险等方面给予评价和建议。
先别怕有人会剽窃你的创意，大家都有眼看的。
比特股中国社区需要开放的态度。 +5% +5%
-
我有个建议，你们程序员在群里研讨的结果或者成果，到时能不能定期拿到论坛上让我们这些不懂程序的人看看，分享一下？
也许别人能够从经济、投资、风险等方面给予评价和建议。
先别怕有人会剽窃你的创意，大家都有眼看的。
比特股中国社区需要开放的态度。 +5% +5%
当然，如果有成型的成果，一定会分享出来，这也正是去中心化的思想。不过现阶段主要还是处于学习研讨阶段，toolikit确实博大精深，跟那些技术大牛比起来，我们现在还只有学习的份。
-
对java熟悉，可以加入吗
-
对java熟悉，可以加入吗
为保证群质量，需要对toolkit有一定了解。
-
一定了解是什么意思
-
一定了解是什么意思
每个人的了解的程度都不一样，我想最低程度要看过toolkit源码，并了解其中的一些原理。
-
不懂程序……lz看过源码了？感觉是个NB的东西吗？
-
:'(其实我进了群也看不懂你们说些啥
-
不太喜欢QQ群，能不能搞个邮件列表？ 我愿意顶力支持。
-
+5% +5% +5% +5% +5%
-
有兴趣，如果是邮件列表更方便探讨，而且也能上班时使用，QQ上班时不好用
对编程有兴趣并有志于将来从事dac开发的程序员，bitshares toolkit绝对是一个宝藏，里面涉及p2p网络编程，块链技术，密码学，系统架构等知识，本着共同学习共同进步的宗旨，特开一群(群号码：341632119 )专注于bitshares toolkit学习与研究，为保证群员质量，第一次申请加入会暂时被拒绝要求回答关于toolkit 的一些问题。在此诚邀对Bitshares toolkit 有一定了解的程序员加入。
-
这个提议很好啊，我先报名。 +5%
-
有兴趣，如果是邮件列表更方便探讨，而且也能上班时使用，QQ上班时不好用
对编程有兴趣并有志于将来从事dac开发的程序员，bitshares toolkit绝对是一个宝藏，里面涉及p2p网络编程，块链技术，密码学，系统架构等知识，本着共同学习共同进步的宗旨，特开一群(群号码：341632119 )专注于bitshares toolkit学习与研究，为保证群员质量，第一次申请加入会暂时被拒绝要求回答关于toolkit 的一些问题。在此诚邀对Bitshares toolkit 有一定了解的程序员加入。
邮件列表最好了。方便查询
-
会创建邮件列表供群员交流讨论。
-
BTS什么时候正式出来啊？
-
对被拒绝加入该群的哥们表示歉意，只是希望这群不要沦为吹水的水潭，而更多的是对bitshares toolkit有点技术含量的的讨论。所以申请加入的人需要对bitshares toolkit有一定了解。加的人很多，但是愿意回答验证问题的人并不多，所以通过验证的并不多。虽然暂时人数不多，但是论坛里的几位技术大神都应邀加入。现已经创建了google group 讨论组，希望更多的程序员能加入讨论，如果你对bitshares toolkit有一定的了解，也可以直接pm 我QQ号并简单描述一下bitshare toolkit,如果验证通过，我将直接邀请你加入。
-
希望基于toolkit的DAC早日爆发
-
希望基于toolkit的DAC早日爆发
整天说500刀妥妥的是没用的，还是要应用起来了才能体现价值。bitshares底层框架确实设计的很扎实，只要有一个DAC稳定运行，其他的都会很快。
-
分享两个组内主题讨论，内容还没整理过，比较凌乱，凑合看吧， 再次邀请对bitshares toolkit有了解的程序员加入讨论。加群时请标注论坛ID
Bitshare toolkit 中密码学相关应用的学习分享与讨论
这是当然，增加系统的功能，必须比原先消耗多些资源，我这只是鸡蛋里挑骨头而已。
------------------ 原始邮件 ------------------
发件人: "coolspeed";<jinxionglong@gmail.com>;
发送时间: 2014年6月17日(星期二) 晚上11:22
收件人: "James"<273593465@qq.com>;
抄送: "Denny Wang"<hackfisher@gmail.com>; "BitsharesToolkit"<BitsharesToolkit@googlegroups.com>;
主题: Re: Bitshare toolkit 中密码学相关应用的学习分享与讨论
总体时间复杂度没变，就可以认为性能在控制之下。
CrazyBit <273593465@qq.com>于2014年6月18日星期三写道：
op的大小没有改变，只是数量增加了。validate trx()调用次数跟非TITAN横向比较是没有区别，但是多了解密op环节，这个时间是比非TITAN多出来的，256位 密钥的AES解密还是挺耗时间的。
------------------ 原始邮件 ------------------
发件人: "coolspeed";<jinxionglong@gmail.com>;
发送时间: 2014年6月17日(星期二) 晚上11:06
收件人: "James"<273593465@qq.com>;
抄送: "Denny Wang"<hackfisher@gmail.com>; "BitsharesToolkit"<BitsharesToolkit@googlegroups.com>;
主题: Re: Bitshare toolkit 中密码学相关应用的学习分享与讨论
无非op1(a)变成op2(a)，调用次数（validate transaction() ）跟非titan没区别阿。
CrazyBit <273593465@qq.com>于2014年6月17日星期二写道：
算法本身的时间复杂度是常数,但是扫描一个block所需时间不是常数啊，block有大小，xts刚开始block数量少，单个block里的trx也少，但是这两个在后期都会逐渐增大，加入在初期，block A 里有10个trx,每个trx有10个op, 那一共需要扫描100个 op,而后期的block b里有100个trx,每个trx里有100个op，那总共就需要扫描10000个op了。
------------------ 原始邮件 ------------------
发件人: "coolspeed";<jinxionglong@gmail.com>;
发送时间: 2014年6月17日(星期二) 晚上8:41
收件人: "James"<273593465@qq.com>;
抄送: "Denny Wang"<hackfisher@gmail.com>; "BitsharesToolkit"<BitsharesToolkit@googlegroups.com>;
主题: Re: Bitshare toolkit 中密码学相关应用的学习分享与讨论
效率不是问题，时间复杂度是常数。
CrazyBit <273593465@qq.com>于2014年6月17日星期二写道：
多谢hackfisher 提供的资料，非常详细，基本弄明白extended_private_key的原理，看完后我想说，TITAN真是牛B到没没朋友。如果真要真要鸡蛋里跳骨头的话，不知道以下的问题有没有可能是隐患1.extended_private_key虽然是geek的智慧结晶，但是未经过大规模实践验证2.我相信未来xts的交易会非常大，当每个block 的operation非常大的时候，client 在扫描的时候要解密每个operation，不知道效率会不会是一个问题。
---原始邮件---
发件人: "Denny Wang"<hackfisher@gmail.com>
发送时间: 2014年06月17日 12:15:25
收件人: "James"<273593465@qq.com>;
抄送: "BitsharesToolkit"<BitsharesToolkit@googlegroups.com>;
主题: Re: 回复： Bitshare toolkit 中密码学相关应用的学习分享与讨论
TITAN: Transfer Invisible To Any Name (Anonymous)
简单来说，就是利用类似HD Wallet的非对称加密原理，引入了一个one_time key，用receiver的public key和one_time_private_key做混合，生成invisible 的地址，只有拥有private_key的receiver才能看到知道是发送给自己的，其他人无法观察。
DarkCoin貌似有类似机制，但是BM想出这个点子时并不知道已经有其他Coin的类似想法
2014-06-17 0:04 GMT-04:00 CrazyBit <273593465@qq.com>:
资料很详细，谢谢！ 谁能通俗易懂的说一说TITAN 吗？
------------------ 原始邮件 ------------------
发件人: "Denny Wang"<hackfisher@gmail.com>
发送时间: 2014年6月17日(星期二) 凌晨1:37
收件人: "James"<273593465@qq.com>;
抄送: "BitsharesToolkit"<BitsharesToolkit@googlegroups.com>;
主题: Re: Bitshare toolkit 中密码学相关应用的学习分享与讨论
关于extended_private_key, 你可以看一下HD Wallet
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Extended_keys
它是有一个private_key和一个chaincode产生，可以产生一个private_key branch.
Bitshares toolkit 的TITAN wallet用到了和HD wallet类似的原理
https://bitsharestalk.org/index.php?topic=4699.msg60198#msg60198
TEMP_PRIVATE_KEY * EXTENDED_PUBLIC_KEY => SECRET
EXTENDED_PUBLIC_KEY.child( SECRET ) =>? RECEIVER_PUBLIC_KEY => RECEIVER_ADDRESS
You then broadcast a transaction that includes TEMP_PUBLIC_KEY + RECEIVER_ADDRESS?
The receiver then does the following:?
TEMP_PUBLIC_KEY * EXTENDED_PRIVATE_KEY => SECRET?
EXTENDED_PRIVATE_KEY.child( SECRET ) => RECEIVER_PRIVATE_KEY => RECEIVER_PUBLIC_KEY => RECIEVER_ADDRESS
2014-06-16 10:17 GMT-04:00 CrazyBit <273593465@qq.com>:
密码学在bitshare toolkit的应用是非常广泛的，其中涉及了不少的加密解密算法，如果要深入讨论，每个算法都可以用大篇幅的论述，以下我抛砖引玉，列举一些主要算法及其大概的应用原理。欢迎大家补充，如有不对，也请指正。谢谢
ECC: 椭圆曲线非对称加密算法，在bitshares toolkit中主要有两大应用，第一是产生一一对应的公私钥密码对，私钥经过运算产生可以产生公钥，反之则不然，而公钥通过一系列哈希运算和base58转换就可以形成我们常用的地址，拥有私钥就可以声明公钥的所有权。第二是签名与验证，利用私钥对文本摘要加密运算产生一个签名，可以将签名和公钥一同广播出去，接收方通过公钥和签名可以进行归属性和有效性验证。
AES：高级加密标准对称加密算法，所谓对称就是双向算法,通过密码来进行加密解密，bitshares toolkit里主要用来加密解秘以上ECC算法中所产生的私钥。
Hash256/Hash512/Ripemd160: 这几个单向不可逆散列算法算法可以归为一类，区别是运算过程和散列结果所占空间不同，在bitshares中的应用，主要有: 1.公钥通过散列运算产生地址所需数据。 2.产生各种唯一id, block id, transaction id,record id等. 3.产生各种摘要，transaction的摘要，block的摘要等。transaction和block的接受方可以利用摘要和发送方的公钥进行有效性验证。
base58/hex:?编码转换算法，base58跟base64类似，是在bitcoin里引进的算法，主要用途是剔除地址中容易混淆的数字"0"，字母大写"O"，字母大写"I"，和字母小写"l". hex ，二进制转16进制。
另外还有一些不明白的地方，希望弄懂的人可以分享一下。主要是是bitshare toolkit里的 extended_public_key和extended_private_key，大概知道是从ECC扩展而来，但是主要用途和原理暂时还没弄不明白。
关于Bitshare toolkit序列化存储的扩展性问题
schema-free 的 NoSQL 数据库才更好扩展啊。例如 MongoDB，直接存储json。berkeleydb, leveldb 也都可以直接存json，或是等价的二进制形式。MongoDB存的其实也不是json而是其等价形式的bson。
所以问题只是如何序列化与反序列化的问题。
在 2014年6月15日 上午12:06，coolspeed <jinxionglong@gmail.com>写道：
而且mongo不能嵌入式使用吧。
coolspeed <jinxionglong@gmail.com>于2014年6月15日星期日写道：
nxt是h2。xcp不知道。既然是python很可能sqlite？mongo很占内存。
CrazyBit <273593465@qq.com>于2014年6月14日星期六写道：
为了增强系统的扩展性，是应该考虑转关系型数据库，据我所知，NXT，XCP也是关系型数据库。
------------------ 原始邮件 ------------------
发件人: "Denny Wang"<hackfisher@gmail.com>;
发送时间: 2014年6月14日(星期六) 中午12:40
收件人: "reactionism"<reactionism@gmail.com>;
抄送: "BitsharesToolkit"<BitsharesToolkit@googlegroups.com>; "James"<273593465@qq.com>;
主题: Re: 关于Bitshare toolkit序列化存储的扩展性问题
不好意思，手机发送的不小心按到了。
BM前两天有说过考虑转成其他db, 比如mongodb或关系数据库
2014-6-14 AM12:35于 "CrazyBit " <273593465@qq.com>写道：
以现在bitshare toolkit的系统架构，分区块高度启用新的反序列化逻辑是不可行的。
2014-6-14 AM12:35于 "her0" <reactionism@gmail.com>写道：
群里讨论是分区块高度解决，快照。
在 2014年6月13日星期五UTC+8上午10时34分04秒，"CrazyBit " 写道：
我们普通使用的数据库是二维表多列结构,想扩展表结构是比较容易。但是Bishares toolkit的块链存储是使用google的level db ,而level db的表结构只有两列，就是key-value，现在bitshares的块信息存储是将整个业务模型内存中的对象（e.g. balance record,name record,block)序列化后整个存入数据库表的value列，取出时在反序列化成内存中的逻辑对象。现在可以预见的问题是，假入在Bitshares XTS正式发布之后，想修改某些逻辑业务模型的成员，比如说我想在name record加一个mail address,这就会出现问题，数据结构改变了，之前产生的块反序列化会失败。大家对这个问题怎么看？
-
请加群人标注论坛id+toolkit的简单描述。如果验证通过，可以省去答问环节，节省时间。
-
这段时间没空,等过段时间研究下toolkit,再加入讨论群. 非常支持这样的学习和讨论. 也希望群主不时地分享下你们的讨论...
-
已经申请，看不到验证问题。api刚开始研究。我主要是想着怎么用java调用。
-
这几天准备学习下toolkit 的数据p2p传播部份，有兴趣的一起学习探讨下。
-
希望lotto类百花齐放啊
-
支持支持！！！！！！！！！！！！！