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.
I completed all my steps to register as a delegate, however the last step of enabling block production is throwing me this:have you tried "wallet_enable_delegate_block_production fluxer true" ?Quote>> wallet_enable_delegate_block_production fluxer
Command aborted.
EDIT: It seems to have worked, I'm in the delegates list. Going to leave my computer on tonight to hopefully make some blocks.
2 issue about the asset creation,
1)create the HSBC asset cost me 20.9XTS, but the fee cannot show in the transaction history
2)after the asset create successfully, try to issue the asset but failed, when i check the balance, 20.9 more XTS is deducted from my account
"blockchain_head_block_num": 141,
"blockchain_head_block_time": "20140621T002330",
"blockchain_head_block_time_rel": "26 seconds old",
"blockchain_confirmation_requirement": 299,
"blockchain_average_delegate_participation": 36.434108527131784,
"network_num_connections": 5,
"ntp_time": "20140621T002356.302544",
"ntp_error_seconds": -0.92658399999999996,
"wallet_unlocked_seconds_remaining": 0,
"wallet_next_block_production_time": null,
"wallet_seconds_until_next_block_production": null,
"wallet_local_time": "20140621T002356",
"blockchain_random_seed": "6295afbd488cfd9cb1e3f31dc05e560b3e94abd6",
"blockchain_shares": 9999182227629,
"network_num_connections_max": 12,
"network_protocol_version": 103,
"wallet_open": true,
"wallet_unlocked_until": "20140621T001900",
"wallet_version": 100
这是当然，增加系统的功能，必须比原先消耗多些资源，我这只是鸡蛋里挑骨头而已。
------------------ 原始邮件 ------------------
发件人: "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扩展而来，但是主要用途和原理暂时还没弄不明白。
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,这就会出现问题，数据结构改变了，之前产生的块反序列化会失败。大家对这个问题怎么看？
希望基于toolkit的DAC早日爆发
There are delegates with negative "VOTES FOR".
66 unelected-testz1 -885053986 106224251086 -1.071245313 % 0 4
Some of the initial delegates lack unelected prefix.
41 crazybit 9215 106210341099 -1.06225431 % 2 2
40 coolspeed 0 109830374550 -1.09845984 % 0 4
28 delegate-alt 6927 104666022311 -1.046808958 % 3 1
https://raw.githubusercontent.com/BitShares/bitshares_toolkit/master/libraries/blockchain/genesis.json
How to import PTS wallet?
I see the bitcoin, electrum, multibit, armory, and keyhotee import commands.
Is there no command for PTS yet?
, don't want to spend too much of your time.fc::optional<wallet_master_key_record> wallet_master_key;
unordered_map< address, wallet_key_record > keys;
unordered_map< address, address > btc_to_bts_address;
unordered_map< address, int32_t > address_to_account_wallet_record_index;
unordered_map< account_id_type, int32_t > account_id_to_wallet_record_index;
map< string, int32_t > name_to_account_wallet_record_index;
unordered_map<address,wallet_market_order_status_record> market_orders;
/** maps wallet_record_index to accounts */
unordered_map< int32_t,wallet_account_record > accounts;
unordered_map< transaction_id_type, wallet_transaction_record > transactions;
unordered_map< balance_id_type,wallet_balance_record > balances;
map<string,wallet_asset_record> assets;
map<property_enum, wallet_property_record> properties;
map< string, wallet_setting_record > settings;
i found there are many mapping in the wallet db,would you please describe a bit more about the wallet data structure?
same question here.... anyone knows the answeri have registered account "crazybit" and "james", when tried to export the private key of "james" and import to the account "crazybit" , it can be done without error, is that expected? if yes, will the balance of account "james" combined to the account "crazybit"?
suppose there is something wrong , how can a name map to 2 different private keys?
Every account has the 'account key' and under the account key are any number of 'balance keys' that are generated when someone sends you a titan transaction or you import keys into the account from an external source.
In theory no funds should be sent directly to an 'account key', but only to a key derived from the account key.
Importing the key into two places will probably confuse the wallet right now.
same question here.... anyone knows the answeri have registered account "crazybit" and "james", when tried to export the private key of "james" and import to the account "crazybit" , it can be done without error, is that expected? if yes, will the balance of account "james" combined to the account "crazybit"?
