BitShares 账户备份小结

玩STEEM都知道,一旦账户密码忘记了,那么是无法找回的。BitShares也一样,一旦账户密码忘记了,那么你账户里的资产就没谁能冻得了啦,包括你自己。所以备份,在BitShare中也同样重要。


(图源 :pixabay)

在BitShares系统里,我们可能会接触如下概念,账户、密码、钱包、私钥,下边我介绍一下我的备份经验,供大家参考。

备份

账户密码模式

如果你注册和登陆bitshares钱包都使用的是账户密码模式,那么你备份的时候只需将账户密码保存下来即可。

帐户、密码在各个bitshares钱包都是可以直接使用的,比如说网页钱包、轻钱包、鼓鼓钱包等。

钱包模式

如果你使用的是钱包模式,那么你需要备份一个.bin文件,其中包含你钱包中所有账户的私钥。这个文件使用一个密码加密,这个密码用于解锁钱包。

如果你使用钱包模式,你只记下了密码,一旦你的网页钱包崩溃,并且之前没有备份,那么对不起,你的账户完蛋了,这时候密码啥用都没有。

一旦你钱包中的私钥发生了变化(增加、删除、修改等),那么你需要重新备份钱包。

钱包备份方法参见截图

私钥备份

我们之前说了,钱包备份生成的.bin文件中实际保存的是你钱包账户中的所有私钥。我们当然也可以直接备份私钥了。

私钥备份的方式为

  • 选择对应的账户(钱包模式中可能有多个账户)
    点钱包右上角的按钮,在弹出菜单中选择**Permissions*
  • 选择对应的权限Active Permissions/Owner Permissions
  • 按提示操作显示对应的私钥
  • 将私钥复制并保存好


保存私钥记得要保存完整,比如我们钱包中有多个账户,我们只保存了其中一个账户的Active私钥,那恢复的时候就只能恢复这个账户的Active Permissions了。

恢复

账户密码模式就不用说了,直接登陆就好了

钱包模式的恢复参加下图:

私钥备份的情况,我们在钱包中导入私钥就好:

总结

列个表格对比一下吧。

模式 备份对象 备注
账户密码 账户、密码 文本,可直接用于登陆
钱包模式 .bin文件、密码 .bin文件包含钱包中所有账户的私钥,密码用于解锁文件
私钥备份 私钥 文本,对应账户的不同权限

也就是说,上边三组信息你务必拥有并保存好一组,否则遇到麻烦的时候就欲哭无泪了。我曾经有一个账户,自己设置了一个密码,我以为我凭我的超强记忆力能记住呢,结果忘得干干净净!😭

还有一些其它备份方式就不去研究了。需要注意的是,备份生成的文件以及密码一定要保存好,别弄丢了,或者被人一锅端了。😳


This page is synchronized from the post: BitShares 账户备份小结

盲人摸象与STEEMIT

如果我自称币圈小白,那么肯定会被朋友们喷死。是的,我已经不白了,而且很黑,什么乱七八糟的问题我也可以装模做样的聊几句,其实无非是在别的群里看到高手们聊天,我默记下来,说不定哪天聊天的时候用得到,原封不动甩几句大神的名言,是不是显得逼格很高?最重要的是,谁也不知道是我剽窃来的。


(图源 :pixabay)

如果追溯起我在币圈的历史,那么有文字记载最早可以追溯到2011年5月27日,我在某论坛上感慨,用电脑挖了一整天比特币,毛都没挖出来。彼时比特币价格7美元每枚,耗费好多精力去挖矿,好多人都不屑去做。眼光长远格局大且懒惰的人,直接囤币。而像我这样小白,则浅尝辄止,错失发财良机。但是万一以后我发达了,这是可以写入历史的,比如说早在2011年就对比特币有过深入且系统的调研,至于真相是啥,就不重要了。

好吧,其实说这些,无外乎想表达,我真的是币圈小白,2011年尝试用电脑挖矿未遂后,比特币对我而言只不过是一个论坛上和新闻里大家热炒的词汇而已。周围的渣渣程序员们,也时常对此嗤之以鼻,有什么高大上的,无非是一段程序嘛。很长时间我都被这种论调所影响,直到接触了STEEMIT。

没错,对我而言,是STEEMIT而不是STEEM区块链。这就好比,我用QQ不用去关心它的数据库架构,什么几亿用户,几万同时在线啥的又与我有啥关系呢,我只要有人和我聊天就好了。初来STEEMIT也是如此,我以为这不过是个论坛,我的第一个帖子就一句话”咋玩啊?”,当时费了九牛二虎之力注册了之后,我确实不知道这玩意该咋玩。


(图源 :pixabay)

我一点点学会了如何发帖、如何加标签、如何上传图片(那时候只能用第三方图床)以及如何点赞,我清楚的记得我看别人文章写得挺好,那么我插个小旗标记一下,我理解这应该类似于我们上学时表现好,老师给我们贴的小红旗。

然后我学会了如何转账、如何在内部市场交易,如何使用SBD购买STEEM然后POWER UP,计算着Steem Power的增长率,按当时的数据,我记得一年下来应该可以翻12倍。于是我想如果我一直发帖,一直买STEEM,一直存SP,一直利滚利的翻下去,我是不是可以超越STEEM的创始人之一的马甲之一dantheman了?哦,前提是他的SP不增长。时至今日,我终于超越了dantheman,不是我的SP增长的如何迅猛,而是他快Power Down光了。

我还用shell脚本配合awk、sed等乱七八糟的东西写了一些程序去分析wang的点赞行为,期望找出他点赞的规律,不过自始自终,我没能钓到过wang这个当时的超级机器人。再到后来接触piston,尝试用python写了一些程序来玩STEEM。再到后来去读Piston的代码,从用到理解,去尝试了解STEEM内的很多机制。


(图源 :pixabay)

和别人聊天的时候,我自己总结,我玩STEEM的过程就好比是盲人摸象。尽管大神们不断帮我们描述大象是这个样子,那个样子的,让我们受益匪浅。但是作为一个“盲人”,看不见,总要摸得着才会心安。于是我不断的去摸,并结合大神们讲解,我总算对大象的一角有了一些肤浅的了解。

这一角或许是象鼻子或许是象耳朵也可能是象腿或者象尾巴,肯定不是大象的全貌。但这又如何呢?我会坚持不懈的去摸,直到有一天能够在脑海里构造出大象的轮廓来。这一天或许很远,但终会到来。


咦,为什么盲人摸象会是贬义词呢?如果它是贬义词,我水这么多还有什么意义,不行要我要为它翻案。明明是盲人,还锲而不舍地去了解大象,这是多么令人肃然起敬的事情啊。


This page is synchronized from the post: 盲人摸象与STEEMIT

用上了bitshares轻钱包 + 私有节点

在之前的文章中,我学习了编译BitShares Core以及同步节点数据,做完这些以后,我就可以用curl测试访问节点以及使用这个节点跑我自己写的脚本,一切都很顺利呢。

然后我就想在网页钱包中用我自己的这个节点,当然了,为了让我的节点能被访问到,我首先将节点RPC服务监听地址改成了公网IP,然后在家里的Linux电脑上测试可以用curl访问,也可以用cli_wallet访问,那么想必设在网页钱包里应该也不会有啥问题。

结果在网页钱包中无论我怎么设置都是显示节点不在线!明明节点列表里有一个ws://127.0.0.1:8090为啥我换成公网的节点就不好用了呢?并且明明我的节点都好用啊!去技术群里问了一下,好多大神热心地回复,答案是https网页钱包中不支持ws开头的节点,也就是说必须用加密的websockets(wss)。

弄了一上午证书,总算从comodo申请了一个证书,研究如何安装证书呢,大神提示为何不用轻钱包呢?是啊,我为啥不用轻钱包呢?答案是我没用过,不会用啊。那就把证书啥的丢一边,学习一下轻钱包吧。

下载

首先是找在哪下载轻钱包,翻了半天总算在这找到了
https://github.com/bitshares/bitshares-ui/releases

于此同时,我在费了半天劲打开的N多网页中也发现了官网主页就有下载链接
https://bitshares.org/download/
(竟然不首先去官网找,我的智商诶)

因为我用Windows,所以下载这个文件:
https://github.com/bitshares/bitshares-ui/releases/download/2.0.180115/BitShares.Setup.2.0.180115.exe
一共不到70M,还是很苗条的,难怪叫钱包

安装

看了一下下载的文件:

看名字应该是个安装包,那就安装一下吧,我做好了一步一步截图的准备 ,结果人家直接安装完毕运行起来了,这才叫效率啊😀

看了一下,它在桌面生成了一个快捷方式

轻钱包被安装到
C:\Users\xxxx\AppData\Local\Programs\BitShares2-light
里边包含一堆文件

运行

点击上述桌面快捷方式,启动轻钱包,有木有似曾相识的感觉啊?

没错,和网页钱包几乎完全一样,对于网页钱包用户而言,用起来没有一点障碍啊。

无论是创建新用户、还是使用用户名密码登陆、或者是导入并恢复钱包文件,都与网页钱包没啥不同,就不再赘述了。

设置节点

激动人心的时刻到了,是时候使用我自己的节点啦。

添加节点:

激活节点:

测试

转账测试

给自己转一个BTS玩

交易

卖俩BTS换点人民币花

结论

  • 网页钱包不支持非加密的websockets RPC节点
  • 轻钱包支持非加密的websockets RPC节点
  • 轻钱包使用和网页钱包没啥区别

用上轻钱包,腰不酸了、腿不疼了,一口气上六楼都不费劲


This page is synchronized from the post: 用上了bitshares轻钱包 + 私有节点

大脑也需要时常备份/ 来STEEM备份你的大脑吧

以前不止一次提过,上了年纪,记忆力衰减得厉害,很多今天处理过的事情,明天就忘记了。而作为了一个渣渣程序员最悲哀的事情,就是经常要解决一些相同的问题。比如说搭建开发环境、又比如说处理类似的BUG、还比如说在不同的程序中实现类似的功能。


(图源 :pixabay)

年少时记忆力奇佳,我的大脑就像个高效的数据库,什么信息都可以往里扔,从来不用担心数据库空间不够用,也不用担心数据量大了查询效率降低。数据库自带超高效率索引,无论什么需要提取什么信息,都能在千分之一秒内定位然后读取。

可是随着年纪的增长,我发现这个数据库的查询效率越来越低,原本定位信息只需千分之一秒,后来变成的百分之一,十分之一,一秒。然而这还不是最悲催的,悲催的是,数据库查询引擎定位了半天之后,定位到了数据,然后提示我,对不起,有部分数据缺失,无法读取。

刚开始我怀疑是数据库引擎有BUG,或者是数据库存储部分有毛病,导致写入到大脑的数据部分缺失。可是时间长了,我方明了,这不是数据库的问题,是我的磁盘(大脑)碎片太多,并且有坏道了。


(图源 :pixabay)

如果大脑也如同电脑一样,有CPU、有内存、有磁盘、有IO,现在IO先不说了,CPU、内存虽然还属于286时代,但是依旧能用,但是磁盘用久了,还真不行。对,没错,大脑的磁盘部分已经不堪重负了。

可惜电脑硬盘有碎片可以优化、有坏道可以屏蔽,甚至实在嫌慢嫌故障率高可以换硬盘,换成SSD或者M2啥的,嗷嗷快。以前的数据复制过去就行,不用担心丢啥。可是大脑也换不了啊,好吧,即便能换,数据怎么COPY过去?这真是个令人伤感的事情。

不过,我想到了一个办法, 虽然大脑硬盘没法换,但是电脑可以用移动硬盘,可以用NAS,为啥我们不能借鉴一下呢?大脑里的数据总丢失,那么我可以把数据备份出来啊。

和电脑备份数据一样,备份到移动硬盘上有可能移动硬盘坏掉,大脑备份数据我们当然要找一个非常可靠的备份方案,最好是备份介质永远不会消失,被备份的数据永远不会被篡改,数据上最好有时间戳,还要有一些诸如标签之类的方便查找,咦,这不是STEEM区块链吗?

没错,STEEM区块链是大脑数据备份的不二之选,你想要的它都会给你。妈妈再也不用担心我大脑空间不够用啦,担心我大脑丢数据啦,只是担心我备份的不够多不够及时。


(图源 :pixabay)

当大脑数据备份到STEEM上之后,我们需要的调阅的时候只需来steemit翻一下,或者搜索引擎找一下,或者用专门的搜索工具查一下,数据完美呈现在你眼前。举例说吧,我25天以前在STEEM上备份了这个内容如何在Linode VPS (Ubuntu 16.04 LTS )上安装 Python 3.6.4,今天我又用到了,直接翻出来,指令复制一下,粘贴一下,完美搞定。


那么,还犹豫啥,快来备份吧,况且这备份不收你钱,还给你钱呢!


This page is synchronized from the post: 大脑也需要时常备份/ 来STEEM备份你的大脑吧

节点同步数据完成/ 内存、磁盘占用、运行应用、测试插件

之前尝试了编译BitShares Core,并且在昨晚10点以后开始已最精简的方式同步节点数据


(图源 :pixabay)

原本以为会同步很久,都计划按3、5天准备了,并且心里也在担忧8G内存到底够不够用呢?结果早晨上来一看,呀,竟然已经完成数据同步了,还真给了我一个大大的惊喜。

内存、磁盘占用

用pmap查看了一下内存占用

什么,你没看错,内存占用竟然只需要2G出头的样子

换htop指令再试

看到没有,整个vps实际再用的不过才1.1G

再来看一下空间占用

只占了11G

运行应用

还记得我们之前弄的抵押率排行榜之类的东东吗?在改进之后,读取100条的记录耗时约3秒。

为了对比明显,我这次生成1500条记录试试看。


使用第三方节点,耗时约为16.5秒


使用本地节点,耗时仅为2秒出头,效率大幅提升呀

再来测试一下内部市场订单列表

使用第三方节点,耗时约为3秒


使用本地节点,耗时竟然不到0.02秒,震惊

测试插件

我们在运行witness_node的时候,只运行了witness插件,相当于禁用了account_history以及market_history插件功能,那我们就来试试有没有什么影响。

我们来随便测试一个API: get_market_history_buckets
它无需参数,我比较喜欢

使用第三方节点:
curl --data '{"jsonrpc": "2.0", "method": "call", "params": ["history", "get_market_history_buckets", []], "id": 1}' https://ws.gdex.top

返回如下

可见是可以正常使用滴

使用本地节点
curl -s --data '{"jsonrpc": "2.0", "method": "call", "params": ["history", "get_market_history_buckets", []], "id": 1}' http://127.0.0.1:8090/rpc

虽然提示信息有些难以理解,但是我们还是可以得出API调用失败的结论。

其它的account_history以及market_history的API就不用试啦,没启用还想好用,做梦呢啊?

参考链接


This page is synchronized from the post: 节点同步数据完成/ 内存、磁盘占用、运行应用、测试插件

开始同步节点数据

在上午的文章中,我尝试了编译BitShares Core,但是编译完了总要用起来试试嘛,可惜我被从VPS踢下线了。原本计划等网络恢复正常不烦我了,我就登陆上去搞搞,结果等啊等,始终上不去。于是只好从另外一台VPS上跳上来玩了,真是烦。

witness_node

查看帮助
./witness_node --help
好多选项,看不懂,以后慢慢研究吧。

生成数据目录
./witness_node -d witness_node_data_dir
如果我们不手动指定数据目录,它会在witness_node 同级目录下生成witness_node_data_dir

数据目录中包含一个文件和两个目录
blockchain config.ini logs
看了一下config.ini,好多配置选项,昏迷。

生成数据目录的目的是生成config.ini配置文件,有了配置文件,我们就可以对witness_node进行诸多设置了。

减少内存、磁盘占用

关闭p2p日志
在config.ini中注释掉:filename=logs/p2p/p2p.log

–plugins

如果不指定–plugins参数,那么节点默认加载下列插件

  • witness
  • account_history
  • market_history

我们可以用--plugins witness来只启用witness插件,或者用--plugins witness account_history启用witness和account_history两个插件,插件名称之前用空格分隔

account_history plugin

account_history插件可以设置如下选项
选项|值|说明
—-|—-|—-
–track-account|arg| Account ID to track history for (may specify multiple times)
–partial-operations|arg|Keep only those operations in memory that are related to account history tracking
–max-ops-per-account|arg|Maximum number of operations per account will be kept in memory

market_history plugin

market_history 也有一些选项
选项|值|说明
—-|—-|—
–bucket-size| arg (=[60,300,900,1800,3600,14400,86400]) |Track market history by grouping orders into buckets of equal size measured in seconds specified as a JSON array of numbers
–history-per-size| arg (=1000) |How far back in time to track history for each bucket size, measured in the number of buckets (default: 1000)
–max-order-his-records-per-market|arg (=1000)| Will only store this amount of matched orders for each market in order history for querying, or those meet the other option, which has more data (default: 1000)
–max-order-his-seconds-per-market|arg (=259200)|Will only store matched orders in last X seconds for each market in order history for querying, or those meet theother option, which has more data(default: 259200 (3 days))

听说这些选项不但影响运行时的内存占用,同样影响同步的速度,所以我计划只启用witness插件,这样就会有最小的内存占用以及同步效率。(待实践验证)

同步节点

试了半天,开始同步数据吧:

./witness_node --rpc-endpoint "127.0.0.1:8090" --plugins "witness" --replay-blockchain

其中:--rpc-endpoint "127.0.0.1:8090"开启节点 API 服务


好像似乎大概要很久。

测试

来试一下API服务
curl --data '{"jsonrpc": "2.0", "method": "call", "params": [0, "get_accounts", [["1.2.0"]]], "id": 1}' http://127.0.0.1:8090/rpc

晕,表示结果一团糟,一堆字符挤一起去了。

将结果格式化一下,这样看起来美美的:

再来
curl --data '{"jsonrpc": "2.0", "method": "call", "params": ["database", "get_block", [1000]], "id": 1}' http://127.0.0.1:8090/rpc

curl --data '{"jsonrpc": "2.0", "method": "call", "params": ["database", "get_block", [10000000]], "id": 1}' http://127.0.0.1:8090/rpc

额,急功冒进了吧,还没同步到10000000呢。

其它

测试这功夫看了一下,已经同步了300多万个块,现在一共呢接近2400万个块,照此计算貌似应该很快啊😍。不过好像前期的块中没啥数据,后期数据量大了,估计同步起来就慢了。

慢慢等吧,等它同步完,我再去深入了解一下。

参考链接


This page is synchronized from the post: 开始同步节点数据

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×