之前特意研究了一下如何计算STEEM系统总带宽以及如何计算用户可用带宽，尽管这玩意搞得真的很复杂，但是令人庆幸的是，最终我终于可以计算出以下内容：

• max_virtual_bandwidth: 系统的总带宽
• bandwidth_allowance: 用户分配到的带宽
• avg_bandwidth: 用户使用掉的带宽

其中avg_bandwidth在很多场合被称作用户平均带宽，但是需要澄清的是，这并不是系统参数，而是用户的参数，其中平均代表的是用户7日带宽使用均值，具体含义和计算方法可以参见文末相关文章。

你可能会问，费那么大劲，计算这个东西有意义吗？毕竟不能每个用户都安装Python环境，再装个steem-python库，再写一堆代码去算这个东西。没错，所以耗费了一点时间将之前写的Python代码用PHP重新实现了一下，然后集成到微信公众号中。

如何使用

秉承我们一贯的简单原则，可用带宽百分比直接在账户信息中显示。

例如：@oflyhigh

额，我这个还有100%的额度可用，拿来做例子不太适合。

关于Bandwidth

作用

很多朋友问我，这个有啥用。

简单来讲，你在STEEM区块链上的一切操作都耗费 Bandwidth，比如发帖、回复、点赞、转账、Power UP等等。内部市场交易也消耗Bandwidth，但是和发帖使用的Bandwidth是分开计算的。

一旦你的带宽剩0%，那么就无法做任何操作了。

影响因素

除了受整个系统的一些参数和运行状态影响外，对于个体而言，影响最大的无外乎以下几点：

• 你的有效SP
• 你的操作频度以及每次操作产生的数据量

有效SP = 你的SP + 别人代理给你的SP - 你代理给别人的SP

另外，操作越频繁，每次数据量越大，耗费的带宽越多。（比如文章中插很多没用的尾巴等）

公众号添加方法

• 方式一：
  进入微信通讯录->点击公众号->点右上角加号->搜索steemit，关注即可。

• 方式二：
  直接扫描以下二维码：
  
  欢迎大家多提宝贵意见啊。

相关链接

• How to: 如何计算 max_virtual_bandwidth / How to calculate the max_virtual_bandwidth?
• How to: 如何计算用户可用带宽 / How to calculate the user’s available bandwidth?
• 从代码看 Bandwidth 超限问题 & 如何避免和解决
• Always keep enough STEEM POWER / 账户内记得保留足够的SP

封面图源：pixabay

This page is synchronized from the post: 微信公众号支持查询STEEM用户Bandwidth remaining百分比啦

文件HASH

在升级轻钱包的过程中，我们会注意到轻钱包的发布页面上有类似如下内容：

文件名，我们懂，可是后边这一大串数字是啥东西呀？

去https://bitshares.org/download/ 页面查看，才知道原来是sha256

也就是说对文件使用sha256算法生成HASH值，通过对比这个值，可以判断文件是否被修改。这个是非常有意义的，比如说我重新打包生成一个轻钱包，加入一点自己的恶意代码，然后发给你，但是你和官网上的hash值一对比，就会发现我这个不是官网原装的，我的不良企图一下子就曝光了。

HASH函数生成HASH值的过程是单向且不可逆，不同的输入总是输出不同的HASH值，所以想修改文件并产生相同的HASH值几乎是可能的。

注：前些年山东大学的王小云教授找出了几组不同的输入可以输出相同的MD5值，所以现在推荐使用更加安全的sha256等算法。

如何校验

上边也说了，要对比生成的HASH值才能判断文件是否被更改。但是如何生成文件的HASH值呢？还记得我们之前学过的hashlib嘛？没错，用它就可以。

在Python交互环境下，示例代码如下：

1
2
3
4
5
6

import hashlib
f = open("./BitShares.Setup.2.0.180201.exe", "rb")
sha256 = hashlib.sha256()
sha256.update(f.read())
sha256.hexdigest()
f.close()

执行结果如下：

是不是超级简单？

对比一下网站上列出的文件HASH，完全一致，说明这文件来源可靠，未被篡改。

更进一步

使用Python交互环境可以胜任这个工作，但是每次都要敲代码终归有些繁琐。所以可以考虑把上述代码做成Python脚本，可以考虑支持三参数：

• 待校验的文件名
• 算法：默认为sha256
• HASH: 网站上给出的文件HASH

如果调用时只给出文件名，那么就生成sha256哈希并显示出来。如果给出了算法和文件HASH，则按指定算法生成HASH，显示出来。并且判断是否与网站列出的HASH值一致。

如果愿意再费点劲，可以考虑支持http开头或者https开头的文件名，程序中判断是网站链接，自动去下载文件再去完成上述步骤，或者弄个网页实现在线校验。

代码我就不去写了，以免写不出来或者写不好丢人😳。

参考链接

https://docs.python.org/3.6/library/hashlib.html
https://en.wikipedia.org/wiki/File_verification
https://en.wikipedia.org/wiki/Hash_function
https://en.wikipedia.org/wiki/Cryptographic_hash_function
https://en.wikipedia.org/wiki/MD5

封面图源：pixabay

This page is synchronized from the post: 文件HASH是什么东西？如何校验？

早晨起来看群里说bitshares发布新版本了，修复了一些BUG，并且增加和改进了一些功能，建议所有节点尽快升级。

原本想我的节点自己用，用着也还可以，那么就不用费力气升级啦，懒得不得了。但是看里边新增加了一个APIget_account_history_by_operations，看着就挺吸引人的，那就升级一下喽。另外，听官方的建议，总没错的。

升级节点

对这些指令傻傻的不懂，但是我有笨办法啊，重新来一遍好了。

重新编译

1
2
3
4
5
6
7
8

git clone https://github.com/bitshares/bitshares-core.git
cd bitshares-core
git checkout <LATEST_RELEASE_TAG>
git submodule update --init --recursive
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make witness_node cli_wallet

新版本的版本号为2.0.180202，所以<LATEST_RELEASE_TAG>处要做对应修改。

重启节点

编译完成后，先停掉原来的winess_node与cli_wallet
将新生成的winess_node与cli_wallet 复制到目标目录，覆盖原有文件。

重启witness_node
./witness_node --rpc-endpoint "1.2.3.4:8090"
其中1.2.3.4是服务器的IP，如果你只想本地使用，那么替换成127.0.0.1即可。

重启witness_node自动开始了replay-blockchain，虽然我没加 –replay-blockchain参数
这个可能和我替换了节点程序有关

等了一个小时replay-blockchain完成了77%，估摸还得至少半个小时，耐心等待好了
这期间，轻钱包只能用其中自带的其它节点喽

轻钱包

顺便看了一下，轻钱包也有升级，现在每次打开轻钱包，都会看到左下角有类似这样的提示强迫症表示不把它消掉受不了，那就升一下喽。

下载地址：
https://bitshares.org/download/
https://github.com/bitshares/bitshares-ui/releases/latest

当前最新版本是2.0.180201，因为我用的是Windows，所以下载BitShares.Setup.2.0.180201.exe就可以啦。

下载完成后直接运行就可以啦，如果当前轻钱包开着，会自动给关掉。

安装完成后自动打开轻钱包，里边的账户啥的还都在，不用重新导入。轻钱包界面上做了一些修改，比原来略顺眼。另外感觉交易界面买单卖单列表中的文字有点巨大，虽然看着清晰，但是我还是喜欢精细优雅点的。

这上下字号一对比，就觉得不优雅了，希望下一版本改进吧。

参考链接

• 尝试编译BitShares Core
• 开始同步节点数据
• 用上了bitshares轻钱包 + 私有节点
• BTS交易所对接指南（单节点版）by @abit
• https://github.com/bitshares/bitshares-core
• https://github.com/bitshares/bitshares-core/releases/tag/2.0.180202
• https://github.com/bitshares/bitshares-ui/releases/tag/2.0.180201

This page is synchronized from the post: 更新了一下bitshares节点以及轻钱包

虽然这两天BTS一直再跌，但我从未想过我会爆仓。因为，截至今天中午，BTS价格还在2.4以上，距离我1.75的爆仓触发价相隔甚远。另外某大户曾说要构建BTS 2元铁底的豪言还在耳旁，既然是铁底，当然是牢不可穿了。

(图源 ：pixabay)

结果下午三点多一看内盘，我晕，BTS已经跌到了1.6，喂价也跌到了1.8，距离我的爆仓触发价一步之遥。纠结了半天该如何操作：是转钱进来平仓，还是追加BTS提高抵押率，还是学 @deanliu 刘美女自己主动割肉？最后想来想去，决定还是放任不管，俗称挺尸。

没有出乎意料，很快BTS就跌到1.4X，喂价也降到了1.6X，于是很不幸的，我爆仓了。

不过别急(哦，貌似我无需自己安慰自己)，既然已经爆了，那么我们来好好研究一下爆仓，难得有这种实战的机会。以往就知道爆仓很可怕，但是可怕在哪，爆了啥后果，自己一点也不清楚。

强平触发价

强迫触发价，亦即BTS兑CNY的喂价低于这个价格时，将会触发强制平仓(俗称爆仓)。这个价格就是你抵押的BTS的价值是你借出CNY价值的1.75倍时BTS的价格。

强迫触发价 = 借出CNY总量 * 1.75 / 抵押的BTS

所以，以我抵押15WBTS借出15W人民币来计算：
我的强平触发价 = 150000 * 1.75 / 150000 等于 1.75元

强制平仓价

爆仓之后是怎么处理的？是直接没收抵押物平掉债务？还是把抵押物都按市场价卖出？这个问题困扰我好久，直到我这次爆仓。

爆仓之后，会以强制平仓价挂出与你借款等值的BTS。

所以这里又冒出个强制平仓价

强制平仓价即为：清算价/强制平仓比例上限

以我截图时为例：
清算价(即喂价)为：1.6819 bitCNY/BTS
强制平仓比例上限为：110%
所以强制平仓价为： 1.6819 / 110% = 1.529 bitCNY/BTS

挂单原则

我之前说过，爆仓时，会以强制平仓价挂出与你借款等值的BTS

以我的账户为例，我借款15W，强平触发价为1.529

那么就以1.529的价格挂出等值15W CNY的BTS.

数量计算方法为：借款数量 / 强制平仓价

在我这里就是：150000 / 1.529 = 98103.33
(因为之前计算喂价时没算小数点后内容，所以算出来的值略有偏差)

价格数量调整

因为喂价时刻在变，所以导致强制平仓价时刻在变，进而导致挂单数量时刻在变

所以说，挂单价格和数量不是一成不变的。

比如此可的挂单价格和数量和之前对比都有了变化。

成交顺序

按照我们上述分析，我们可以得出所有的爆仓单在同一时刻都以相同的强制平仓价挂单出售，那么哪个先成交呢？

经过我的分析，应该是按抵押率排行榜，先吃掉抵押率低的

至于为啥前两个抵押率高反而在前边？那是因为它被吃掉了一部分，导致了抵押率变化，而非挂单时抵押率高。（我猜测的，不知道是否正确，仅供参考）

复活原则

尽管已经爆仓，但是因为成交有先后顺序，所以如果爆仓之后没有马上被成交出去，那么还是有机会复活的。

复活和爆仓的机制恰恰相反
爆仓：喂价这个强平触发价时，将会被触发
复活：喂价高于强平触发价时，将会复活

如果想在被吃掉之前复活，无外乎等喂价涨，或者增加抵押物，或者减少债务这几个操作。

比如上图排第一的就调整了债务，强平触发价调整到了1.5244，暂时就没风险了。

不过他在复活之前，已经被吃掉6000W CNY，也不是个小数目了。

结局

我最终没能等到复活，顶在我前边的几个大户都调整了债仓，跑路了，于是我顶到了最前边，很快骨头都被吃光了。

好在我上边的分析的结论是正确的爆仓之后，会以强制平仓价挂出与你借款等值的BTS，所以我爆掉了10W BTS顶掉了15W的债务。

无债一身轻吗？未必如此，其实相当不爽。估计我爆掉之后，应该开始涨了，真正的死在黎明前。不过难道不是贪心惹的祸吗？哎，既然如此，就别怨天尤人了。

This page is synchronized from the post: 比特股(BTS)爆仓“实战教程” / 都是贪心惹的祸

不同于STEEM中用户名即账户名，Bitshares中用户ID才是用户核心标志，用户名只是用户的一个属性(当然了，这个属性可能没法修改)。其实BitShares中好多东东都使用ID来代表，比如是BitCNY的ID是"1.3.113"，BTS的ID则为："1.3.0"。

(图源 ：pixabay)

你可能会问，管它核心不核心的，我知道用户名就可以做一且操作了，用户ID啥的与我又有何关系？这或许没错，知道了用户名，我们就可以查询信息，转账给他，等等等等。但是你知道吗，BitShares的好多API以及操作都是依赖于用户ID的，也就是说你只是没直接用到它而已。

你可能又问，既然没直接用，对我透明，那么还关心它干啥？额，也没错，答案是它对我不是透明的啊。我很多操作要用到用户ID。

一般需要用到用户ID时，我会去网页钱包或者区块链浏览器中查看对应用户的ID是多少。我也写了个简单的脚本来显示对应用户的ID，但是每次找脚本执行一下，我总觉得很繁琐。于是我突然想到干脆在公众号里加上ID显示算了，于是就加上了。

如何使用

秉承我们一贯的简单原则，ID直接在账户余额项中显示：

请忽略上边的🆔图标，那个确切的讲应该叫“帐户名”；请忽略布局，我实在是没法让它更好看一些。

实现原理

其实实现起来很简单，就是个API调用啦
curl --data '{"jsonrpc": "2.0", "method": "call", "params": ["database", "get_account_by_name", ["test2018"]], "id": 1}' http://127.0.0.1:8090/rpc

再从返回数据中拿出’id’就可以啦

应用场景

以后遇到API中需要账户ID的，我就可以直接用公众号来查啦

比如：
curl --data '{"jsonrpc": "2.0", "method": "call", "params": ["database", "get_accounts", [["1.2.534782"]]], "id": 1}' http://127.0.0.1:8090/rpc

又比如：
curl --data '{"jsonrpc": "2.0", "method": "call", "params": ["database", "get_account_balances", ["1.2.534782", []]], "id": 1}' http://127.0.0.1:8090:8090/rpc

也就是说公众号不但是生活助手，还可以成为开发助手呢😀

公众号添加方法

• 方式一：
  进入微信通讯录->点击公众号->点右上角加号->搜索steemit，关注即可。

• 方式二：
  直接扫描以下二维码：
  

欢迎大家多提宝贵意见啊。
相关链接

This page is synchronized from the post: 微信公众号支持查询Bitshares账户id啦！

放在路由器旁边的IPhone 4S手机，我用它挂微信机器人，随着我的机器人关闭，这个手机已经很少用了。偶然拿起，发现本地还保存了不少歌曲，比如《Careless Whisper》、《Right Here Waiting》、《Big Big World》、《River of Babylon》当然了还有《Yesterday Once More》……

听着这些熟悉的旋律，真的好似乘坐了时光机，感觉自己一下子回到了过去。

想起了几年前我的好友结婚，他拿着麦克边走边唱《Right Here Waiting》闪亮登场，全场惊呼一片。好多女孩子眼中都冒出了闪亮的星星。事后闲聊时，我夸他，说没想到他还有这样的唱歌天赋。他笑着告诉我，他那是录播+假唱。额，你们城里人真会玩。不过录播也挺了不起了，我想换我上去，即便是录播也会吓跑观众吧。

又想起当年和朋友一起聊《Careless Whisper》，脚踏两只船，被女友发现，这故事都能编个歌火起来，真的灰常了不起。不过说起来，这歌，这旋律还真好听。尤其是听到男主人公挽留女友Please stay，真的是闻者伤心听者落泪啊。不过脚踏两只船的时候咋没想着伤心呢？后来据说主唱之一出轨了，弯了，看来《Careless Whisper》的故事该改编了，不过可惜作词的才情已逝，未能盼到大作问世，甚为遗憾。

又想起20年前流行的《Big Big World》，其实最早在伙伴中流行起来的是阿雅的《世界无限大》里边以主播的口吻介绍的这个《Big Big World》。当年一个身高马大的好友整天带着耳机哼唱阿雅的《世界无限大》，额，原本的温柔女主播同样的台词从他嘴里哼出来，让所有人都起一身鸡皮疙瘩。后来我特意买了一张Emilia的专辑，不过每次听《Big Big World》就情不自禁地想起我那个好友，这歌是毁了。

又想起《River of Babylon》，当初第一次听这个是我搞到一个英文经典萨克斯的CD，一下子就喜欢上这首歌大气恢弘且欢快的曲子。然后我一直脑补成这是个歌颂巴比伦河的欢快的歌曲。直到后来我听到带歌词的这首歌并仔细看了这首歌的歌词，我才知道这首歌唱的是犹太人被奴役、背井离乡、处境悲惨的事实。对比这首歌优美流畅明快奔放的旋律，更显凄凉。

当然还有《Yesterday Once More》，想起一朋友K歌时唱着唱着这歌，嚎啕大哭的场景。她当时想起了什么，她现在如何，我都不得而知。不知道如果她再听这歌时，会不会回想起当年那个泪雨滂沱瞬间，犹如昨日重现。

歌曲链接

给大家找了一下这个歌曲的链接，感兴趣的可以去听听哦

• Yesterday Once More
• Right Here Waiting
• Big Big World
• Rivers Of Babylon
• Careless Whisper

This page is synchronized from the post: 昨日重现