动动鼠标,解决困扰已久的问题,做人不能太懒惰

由于工作的缘故,我经常使用Putty来访问各地的服务器或者VPS。


(图源 :pexels.com)

打开Putty的第一件事,就是输入用户名密码,用户名毫无疑问的都是由英文字母或者字母+数字组成。

但是我经常遇到打开SSH的登录窗口时,输入法处于中文状态,然后一不小心在用户名处打入中文字符,这时候即使用退格修正也无法解决,只能重新开启窗口,然后切换输入法,再次输入。

输入中文字符的状态:

使用退格修正后,把正常的字符都弄没了:

这个问题困扰我好久,即便我把输入法设置成默认为英文:

但是只要我不小心切换到拼音状态,这时候尽管输入语言依旧是英文:

但是只要我打开Putty的登录窗口,自动就会帮我切换成为中文拼音:

我完全找不到它切换的规律,晕得不得了,于是今天特意调查了一下,发现可以在上边的小图标上点击右键,进拼音输入法中,设置一下默认输入语言:

把Chinese改成English就可以啦,经过测试,发现完美地解决了我的问题。

原来只需动动鼠标就能解决的事情,我竟然忍耐了许久,看来做人真的不能太懒惰啊。


Vote For Me As Witness
https://steemit.com/~witnesses type in oflyhigh and click VOTE

Vote @oflyhigh via Steemconnect
Thank you!

This page is synchronized from the post: ‘动动鼠标,解决困扰已久的问题,做人不能太懒惰’

到底什么是重播(Replay)?我的理解

我们都知道,每当有影响steem区块链数据的共识升级(HardFork),或者当前运行的节点状态数据遭到破坏时,都要进行重播(Replay),在steemit官方github中也叫做reindexing.


(图源 :pexels.com)

重播(Replay)到底是做什么操作的呢?

区块链的状态

简单来讲,区块链是由一堆首尾相连区块排列组成,这些块中包含着用户所作的操作等等(Oprations),比如编号888的区块中张三转账一笔钱给李四小红点赞了小刚的一个帖子,等等等。

那么我们能从888区块中读出李四现在有了多少钱?小刚的那个帖子收益几何?小红还剩多少点赞能量?答案是显然不能。

所以我们需要按照一定的规则来处理区块数据,比如上述888区块中,张三的账户减掉一笔钱加到李四账户上,小红减掉一些点赞能量,小刚的帖子收益相应增加一些,等等等等。

这些随着区块的增加,被不断地处理,使得应用程序一直能够查询到区块的最新状态,比如说现在就可以用get_accounts来查询我的账户:

{"jsonrpc": "2.0", "method": "condenser_api.get_accounts", "params": [["oflyhigh"]], "id": 1}

在我撰写本文时,上述API调用可以查询到我的SP(vesting_shares)等资产:

限于篇幅,不贴长图了。

同理,还可以用其它API查询帖子收益、查询内部市场行情等等等等,这些都依赖于区块链最新状态,假如我们查询的节点状态不是最新,那么得到的数据可能就是陈旧过时的数据,可见这个最新状态多么重要。

什么是重播(Replay)?

好了,讲了这么多,好像也没说到底什么是重播(Replay)?

说到了区块链的状态,如果因为共识升级,区块链的之前的状态需要做一些修改,或者我们不小心把保存区块链状态的内存/文件破坏掉,这时候想简单的恢复状态是做不到的。

那么又要如何操作呢?简单来讲就是从创世块开始重新计算状态,一个块一个块的计算下去,比如第10个块,系统创建了@oflyhigh账户账户余额为0,第100个块@deanliu转给我10SBD,把所有的区块中的所有操作都重新计算一遍,建立起最新的状态。

这个从头把所有区块重新计算一遍来建立最新状态的过程,好像把区块链的过往操作重新上演了一遍,就叫做重播。

形象的比喻

假如你我有很多资金往来,今天我转给你一笔钱,明天你转给我一笔钱,后天我又转你一笔钱但是你又给我转回来一部分,每天转钱后我们都知道你欠我多少钱。

这里的每一天就好比一个区块,每天当中我们做的转钱操作就是Oprations(打包在transaction中,为了便于理解,不过多讲解),经过N天的操作后,你欠我多少钱,这个就是最新状态。

如果正常操作,我只需每天在前一天的状态上加减响应的金额,就会得到当前的最新状态。

但是有一天你不承认这个最新状态了,说这个不对,已经受到了破坏。这时候咋办?我们只需找到我们每天的转账记录,从第一天开始,一笔笔核对,计算每天的最新状态,直到今天。

这个从第一天开始核实转账记录最终算出当前最新状态的过程,就是重播。


以上为个人理解,如有错误,烦请不吝指正。


Vote For Me As Witness
https://steemit.com/~witnesses type in oflyhigh and click VOTE

Vote @oflyhigh via Steemconnect
Thank you!

This page is synchronized from the post: ‘到底什么是重播(Replay)?我的理解’

Steem的源码中普通版本和和不带(No MIRA)字样版本的区别?

STEEMIT的官方github最近每次发布新版本都至少同时发布两个。


(图源 :pexels.com)

比如最近一次HardFork的版本就分别为:

  • Steem 0.22.0
  • Steem 0.22.0 (No MIRA)

MIRA我知道是啥,其实是Multi Index RocksDB Adapter首字母的缩写,简单来讲就是通过数据库技术,降低节点的内存等开销。

DENABLE_MIRA = [OFF/ON] 选项

那么这两套代码是完全不同的东西嘛?显然是不可能的,其实就是通过一些宏定义开关或者选择一些功能,比如这段代码:

那么既然如此,steem直接发布一套代码,然后提供一个编译选项让大家自己设定是否开启就可以了啊?事实上steem的代码中确实可以设置这样的选型,那就是:

DENABLE_MIRA = [OFF/ON]

比如我们想编译带MIRA支持的程序,那么就要传入DENABLE_MIRA = ON;反之,传入DENABLE_MIRA = OFF或者不传任何参数即可,因为OFF是默认选项,这个选项所作的工作如下:

简单来讲就是在编译过程中,给编译程序传入DENABLE_MIRA,其实就是相当于代码中加入了如下语句:

#define ENABLE_MIRA

v0.22.0 v0.22.0-no-mira 版本区别

好了,我们知道了MIRA是什么,也知道了开启MIRA支持的神奇选项(DENABLE_MIRA = [OFF/ON]),那么问题来了,STEEMIT发布的两套源代码到底有什么区别?

莫非是一套里边默认启用了MIRA(DENABLE_MIRA = ON),另一套里边默认关闭的了MIRA(DENABLE_MIRA = OFF),我一直是这么认为的,不过不确认一下不放心啊!

如何确认呢?只需使用如下命令即可:

git diff v0.22.0 v0.22.0-no-mira --stat

返回信息如下:

原来就差了一个文件啊,也就是下图中箭头指向处文件:

我们可以直接用如下命令查看具体差异:

git diff v0.22.0 v0.22.0-no-mira -- Dockerfile

返回如下:

也就是说v0.22.0的Dockerfile中启用了MIRA(DENABLE_MIRA = ON),而v0.22.0-no-mira中默认关闭的了MIRA(DENABLE_MIRA = OFF)

不过好像对不使用Docker的用户没啥影响,那些用Docker的用户,要好好研究喽,毕竟弄错Mira是否启用,可能会导致长时间的Replay啊,哈哈。

总算搞懂了困扰已久的问题。

相关链接


Vote For Me As Witness
https://steemit.com/~witnesses type in oflyhigh and click VOTE

Vote @oflyhigh via Steemconnect
Thank you!

This page is synchronized from the post: ‘Steem的源码中普通版本和和不带(No MIRA)字样版本的区别?’

EpicDice因为被掏空而暂停 & 简单分析一下来龙去脉

昨天看了刘美女@deanliu的帖子[EpicDice] 內心不夠亂,暫時停止營業,我不由得想起了一首老歌《我的心太乱》。


(图源 :pexels.com)

我的心太乱
要一些空白
你若是明白
让我暂时的离开
我的心太乱
不敢再贪更多爱
想哭的我
却怎么哭也哭不出来

扯远了,不知道EpicDice的人 @epicdice是不是想哭,是不是想哭却怎么也哭不出来?😳

综合一下刘美女的帖子以及@themarkymark 的帖子Epic Dice shut down due to witness cheating 还有@mys 自辩贴How ‘Above 99’ player outplayed Epic Dice 我大致理清了来龙去脉。

漏洞原理

首先,一定是EpicDice为了可证明的公平(Provably-fair)公布了验证程序,这很正常,如果投注和开奖不可验证,那么服务提供商就有可能在后台控制开奖结果,就没有所谓的公平可言了。

而这整个开奖/验证机制呢,都是基于区块链上一个不可更改的条目,就是操作的transaction ID,简称txid,举例说我发文章或者投票等操作,都会生成一个txid,当广播到区块链上,这个东西被写入区块就再也无法修改了。并且txid的生成具有一定的随机性,所以看起来很适合做掷色子应用。

不过问题就出在这里,尽管txid的生成有一定的随机性,但是txid这个东西是在广播到网络之前就被生成的,也就是说是在本地生成的。

举例说做一个猜大小游戏,规则是我生成一个10以内的随机数,然后告诉你,然后大于等于5我赢,小于5你赢。但是我生成随机数之前过滤一下,生成小的我再重新生成一次,再告诉你,那这样我就稳赢。

来龙去脉

@mys 就是用的类似操作,在本地构造转账(投注)交易,然后去生成transaction,然后去判断生成的txid是否符合中奖规则,符合中奖规则就广播,否则就重新生成,这样就是稳赚了。

至于生成txid的原理,我在之前的一篇文章中曾经有过介绍:如何从steem transaction 获取txid?

也就是说,将Signed_Transaction的签名部分清空,序列号后生成摘要,取摘要的前20个字节,并转换成16进制字符串形式(40个字节)。

尽管我的文章中说的是从transaction中计算出txid,但是自己构造transaction并计算txid其实是一样的,至于同样的transaction为什么可以生成不同的txid,这个其实也很简单,只要修改expiration这个时间因素就可以

@mys的文章中公布了代码,是用beem实现的,非常简单。

所以简单总结一下就是:

  • EpicDice 使用txid作为计算中奖的依据
  • txid可以本地生成,生成符合中奖条件的txid再广播,就会稳中
  • @mys利用这个漏洞稳赚了一笔
  • 任何人都可以这样操作

至于@mys这么做是否厚道,本文不做评论。

我只想说的是,这事真的和见证人没有一毛钱关系,见证人不背这锅。

安全性的思索

受@john371911提问的启发,我想了一下,怎样才能更安全?

或许把算法中f(txid)改成f(next_block_hash+txid),其中next_block_hash为投注区块的下一区块的块hash,这样见证人想作弊也要傻眼吧?

比如hash(next_block_hash+txid)替代以前的txid

就算见证人想利用出块作弊,你能控制得了自己的出块,还能控制下一个块不成? 不过换个角度,前一个块广播txid,我这个块再生成指定hash就有机会了。😏

看来我这想法还是不成熟,抛砖引玉吧。

相关链接


Vote For Me As Witness
https://steemit.com/~witnesses type in oflyhigh and click VOTE

Vote @oflyhigh via Steemconnect
Thank you!

This page is synchronized from the post: ‘EpicDice因为被掏空而暂停 & 简单分析一下来龙去脉’

HardFork 22于block 35974326 成功激活 / HF21或成为STEEM史上最短命的HardFork

北京时间2019年8月29日23时,STEEM区块链HardFork 22成功激活。

虽然说庆祝有些为时过早,也许这两天还会有其它的大大小小BUG被发现,但是Hardfork 22的激活,也彰显了STEEMIT公司以及STEEM见证人团队的执行力。

毕竟HF21刚刚于两天前同一时间被激活,而后出问题导致STEEM区块链停转数个小时,以TOP20为核心的见证人们通宵达旦排查故障、修复BUG、解决问题,让STEEM区块链在停掉数小时后重新运转。

而见证人们甚至还没有好好补觉,之前修复的BUG刚刚被合并至v0.21.1,大部分见证人甚至没来得及去打这个补丁或者升级至v0.21.1,Hardfork 22突然就来了。

不过睡眠什么的不能阻止STEEM见证人这帮战士战斗,HF22硬分叉之前,TOP20见证人无一缺席,全部更新至到了新版本。

这敬业度、这战斗力的见证人团队,除了点赞👍,还能说啥?

STEEM史上最短命的HardFork

HardFork 22的成功应用,也让HF21或成为STEEM史上最短命的HardFork,只不过上线了两天,就被新的分叉取代了。

而且这上线的两天中,还有小半天处于停摆状态。

所以尽管见证人团队很敬业,战斗力很强,STEEMIT公司能及时地打补丁,能及时地推出新版本,等等等等这些都很让人赞赏,但是如果代码Review再细致一些,测试再充分一些,是不是就不会出这样的问题了?

当然了,代码Review,测试等等,每个见证人都有责任,我也应该参与,奈何水平有限,参与的太少太少,或许这也是我见证人排名低下的原因吧。😳

不管如何,但愿这种短命的Hardfork越来越少,每一次Hardfork都是功能多多诚意满满,顺利应用。

相关链接


Vote For Me As Witness
https://steemit.com/~witnesses type in oflyhigh and click VOTE

Vote @oflyhigh via Steemconnect
Thank you!

This page is synchronized from the post: ‘HardFork 22于block 35974326 成功激活 / HF21或成为STEEM史上最短命的HardFork’

程序已经升级,咖啡已经备好,坐等Hardfork 22

虽然Hardfork 21之后就应该是Hardfork 22,不过我已经那应该是许久以后,并且会是引入SMT特性的新版本,但是没想到Hardfork 22来得这么快,快到让人猝不及防。

早晨看到很多见证人升级到0.21.1版本,于是去steem的Github上看了一下,原来不过是把downvote-overflow-fix 这个补丁合并到0.21.0并更新了一下版本号。所以虽然我的版本显示的是0.21.0,但是实际上与0.21.1并无区别,松了一口气。

可是这口气没松多久,就看到@steemitblog的新帖子:Delegation Issue 大意是有个bug导致某些情况下检查 downvote mana返回错误的值,进而导致无法代理给其它用户SP(主要影响SP大户,比如steemit,这样就无法创建新账户了)。

然后怎么解决呢?那就是再来一次硬分叉,只是这HF来的比较急:

We have spoken with the Witnesses and come to a consensus that the best time to execute this hardfork is 11:00 AM EDT. Because this is another hardfork it will be named 0.22.0 (or Hardfork 22).

五小时之前STEEMIT的Github释出了新版本v0.22.0,又有的忙了

有个搞笑插曲是steemit忙中出错,把硬分叉时间写出了8月27日,这是穿越了嘛?@ety001 发现并汇报了这个问题,Github上很快修改过来了。

没啥说的,编译喽:

然后替换掉当前正在运行的steemd,据说不用replay,还好一切正常。

然后就是等待HF22了,这次应该会很顺利吧?我弱弱地预测😳 反正咖啡已经准备好了,大不了再战一夜。( ╯□╰ )

相关链接


Vote For Me As Witness
https://steemit.com/~witnesses type in oflyhigh and click VOTE

Vote @oflyhigh via Steemconnect
Thank you!

This page is synchronized from the post: ‘程序已经升级,咖啡已经备好,坐等Hardfork 22’

Your browser is out-of-date!

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

×