升级本地EOS节点到v2.0.5 & 关注一下隔壁EOS

EOSIO 早在12天前就已经发布了v2.0.5,据说包含了EOS-VM重要的安全补丁,虽说官方说安全补丁影响所有的节点,但是想必自己本地玩的无所谓了,所以今天才想着升级一下。

升级

编译一如既往地慢,不过好在从不出问题:

image.png

编译完成后照例检查一下版本号:

nodeos --version

返回如下信息,版本号v2.0.5,看来没搞错。

image.png

因为之前已经升级到v2.0.4,所以还是替换nodeos程序即可,一切🆗!

打补丁

其实早在EOSIO正式发布v2.0.5之前,EOSIO已经联合TOP 21 BP们对出块节点进行了安全升级(打补丁)。

这样做防止v2.0.5正式发布,到出块节点升级完成这个时间差内,有人利用安全漏洞干坏事破坏网络。

所以,如果你去连接EOS上一些BP提供的公共API节点,你会发现有些当前版本为:v2.0.4-patch1,这就是补丁的版本喽。

其实尽管从v2.0.5的源码的修改中看出相关漏洞都咋影响网络,但是即便节点们都不升级,我也不知道咋利用漏洞,这算是一件悲催的事情吗?

网络

EOS网络最近运行平稳,很少有丢块的情况发生,和春节期间频繁丢块形成鲜明的对比。

image.png

BP合约执行时间也很稳定:

image.png

WPS 提案

在之前的文章中,我介绍了WPS / 工人提案系统,并且提及:

WPS要分四步部署,现在第一步第二步已经通过了多签,就差执行了。

然而有意思的是,这个EOS Nation发起的提案,竟然被B1否决了,之前BB倒是在推特上表示了对WPS可能导致腐败的担忧,但是直接被否,还是有点让人跌破眼镜。

这其中的内情,怕是只有B1知晓了吧?

价格

或许是资本的推动,或许是受减半预期的影响,最近BTC本身的价格一路反弹(今天略跌),EOS兑美元的价格也略有回升。

但是看EOS兑BTC价格走势,不难发现,EOS相对BTC还是跌的,说明现在不如BTC走势强劲啊。

image.png

总结

其实没啥好总结的,非要下个结论的话,那就是波澜不惊,EOS社区现在很多人对B1颇有怨言,感觉拿了几十亿美元没做什么大事。

还有就是早期B1投资的几个项目,现在都销声匿迹了,而现在运作较好的项目则没有拿社区一分钱。万众期待的Voice好像也没啥大进展。

这有点意思,这种抱怨会演变成实际行动吗?难道EOS那边会发生革命性的事件?拭目以待发吧。

相关链接


This page is synchronized from the post: ‘升级本地EOS节点到v2.0.5 & 关注一下隔壁EOS’

每天进步一点点:探索memo加密的理论基础

如果你在HIVE/STEEM上进行过转账操作,那么你一定知道我们转账操作的时候是可以加备注信息(memo)的,这个备注信息也往往用来让交易所判断充值操作的所属用户,那么你知道Memo是可以加密的吗?


(图源 :pixabay)

加密memo

如果在钱包里操作,在memo前边加一个#那么就会被识别为一条要消息的消息,并对其进行相应的加密处理。
(注一:并非所有的钱包都支持加密/解密操作)
(注二:有的交易所不支持加密memo,请慎用)

加密操作看起来很简单不是?另外别人发给我们的加密消息,貌似我们也不需要额外做什么其它工作,就可以直接看到了,这又是怎么回事呢?

实际上,memo加密解密还是个很复杂的事情呢!比如我发的一条加密消息,实际上是长成这样的:

image.png

memo部分的内容如下:

#C3JiuC9zrPkJRTK3bfz1HHJHvUuLPw4yiWS3bGYMABMvV84UYvmF7jqR58Hg5nor2F1uoSJjWMDsbuAjZJBxLyafj9byDqdvrH1izHePU9T8XZe53vCyvZc3NKPPrsRxw

想必你我都看不出来什么,其实简单来讲这段内容就是包含加密memo在内的数据的base58编码再加上前缀#

理论基础

既然加密,那就涉及到一个密码,而这个密码是如何获取的呢?这就涉及memo加密的理论基础了。

在好久之前,我学习bitshares的Python库的时候,写过一篇文章,里边写了我的学习的一些体会,似乎可以拿来直接用:

我们来了解一下Memo实现的核心机制,除了加密解密等乱七八糟的东西以外,核心的内容就是: shared secret,具有如下特性:

Pub(Alice) * Priv(Bob) = Pub(Bob) * Priv(Alice)

也就是说,无论是用Pub(Alice)以及 Priv(Bob)或者是Pub(Bob)以及 Priv(Alice)都是可以生成的。换句话讲,无论是加密memo还是解密memo,并不存在谁是发送者谁是接收者的问题!

这意味着什么呢?这意味着发送者可以用发送者的私钥以及接收者的公钥计算出来一个密码,而接收者可以用接收者的私钥和发送者的公钥计算出相同的密码。

这是不是非常之神奇啊?简直太过于巧妙了。

验证脚本

尽管理论上:

`Pub(Alice) Priv(Bob) = Pub(Bob) Priv(Alice)`

但是不经过验证,我心里还是没有底的,所以写一段简单的脚本测试一下:

image.png

代码中我生成了Alice和Bob对应的memo公私钥,然后测试是否符合上述条件,代码运行结果如下:

image.png

亦即:

Pub(Alice) * Priv(Bob) = Pub(Bob) * Priv(Alice)
Pub(Alice) * Priv(Alice) != Pub(Bob) * Priv(Bob)

说明memo加密的理论基础是正确无误的。

补充

Pub(Alice) * Priv(Bob) = Pub(Bob) * Priv(Alice)我们得知,其实任何配对的公私钥都可以,不一定非得用memo KEY,但是因为memo key不存在多签/多重授权,使用起来最为方便了,原则上则是可以使用owner/active/posting各级私钥的。

当然,使用其它私钥加密memo,也许会增加解密方的操作的复杂性(我觉得并不会)。


(图源 :pixabay)

还有一点就是因为解密memo要用到自己的memo私钥,而一旦修改密码,memo私钥也会随之修改,如果你不记得以前的密码或私钥,那么之前你收到的加密memo,可能就再也无法自己查看了。

相关链接


This page is synchronized from the post: ‘每天进步一点点:探索memo加密的理论基础’

恼人的邮件系统问题

早在十几年前,我就在独立服务器上搭建了自己邮件系统,虽然这些年迁移过几次服务器,但是每次邮件系统都是平滑迁移,这一切都要归功于cPanel/WHM。


(图源 :pixabay)

然而独立服务器价格不菲(每月数百美元),cPanel/WHM也不是让我免费用的,每月费用高达$25(据说还要涨价),原本有些业务,花点钱心里不慌,但是最近业务都停了,就打算把独服也停掉。

然而这些年自己也建了一堆乱七八糟的网站,虽然其实并没有什么价值,但是丢掉又感觉太过于可惜,打算弄个便宜的VPS迁移过去。

网站问题虽然可以解决,但是邮件问题让我犯了难,要知道,徒手搭建一个邮件系统,还是非常复杂的事情,要去配置MTA、MDA、IMAP/POP3 Server等等。

还要去配置证书、配置防火墙,设置邮件账户等等等等,就算这些都能搞定,最复杂的其实是加固和优化,一旦配置不好收到大量垃圾邮件是轻的,严重的话,可能被SPAMER利用大量外发垃圾邮件。

总之,一想到和一堆程序一堆配置文件,或者将来和一堆垃圾邮件以及一堆投诉信息打交道,就颇为头疼。

那咋办呢?难道还有为VPS买一份cPanel License,专门用来设置邮件服务器?看来一下,支持五个账户(空间)的License,费用竟然达到了$20美元,想想就很心疼。

image.png

又去考察了一下企业邮箱服务,网易的/腾讯的高级功能都需要收费,而且价格不菲,最关键的是,似乎只支持一个域名后缀?比如我在腾讯的企业邮箱注册了一下,又试了半天,楞没搞明白怎么加新域名:

image.png

image.png

image.png

Gmail啥的或许能用,不过在国内,爬上邮箱是一件很困难也很痛苦的事情,想想还是放弃了。

到底有啥好的邮箱方案呢?突然想起来,我用的域名注册商,好像是送邮局,但是一直没用过,不知道咋样,要不回头事实这个?


(图源 :pixabay)

现在回想起来,cPanel/WHM虽然初始配置复杂了点,但是配好之后,简直是太省心了,这十几年来,我就没为邮箱的事情操心过,而现在头发都愁白了。

相关链接


This page is synchronized from the post: ‘恼人的邮件系统问题’

每天进步一点点:comment_options 操作 & Power UP 100%

你注意到有些帖子设置了100% Power UP而不是默认的50%/50%分配比例嘛?你注意到网站首页有些项目方的帖子设置了拒绝收益嘛?你是不是很好奇,这些都都是如何设置的?


(图源 :pixabay)

当然,从网站界面上/或者APP设置中,实现这样的操作都很简单,但是你想知道这背后的机制是什么嘛?

comment_options

或许聪明的你已经猜到了,没错,这背后都使用了一个叫做comment_options的操作,直白点翻译/解释,就是设置文章的选项。

我们知道,发表文章要使用comment操作,以前我应该分享过comment操作大致长什么样,如果忘记了,我们这里再复习一下:

1
2
3
4
5
6
7
8
9
op_comment = ['comment',{
'author': '',
'body': '',
'json_metadata': '',
'parent_author': '',
'parent_permlink': '',
'permlink': '',
'title': ''
}]

里边内容极其简单,就不过多解释了,但是你会注意到,这里边并没有设置100% POWER UP以及拒绝收益的地方。

所以要想设置这些内容,我们需要另外一个独立的Operation:

1
2
3
4
5
6
7
8
9
op_comment_options = ['comment_options',{
'author': '',
'permlink': '',
'max_accepted_payout': '',
'percent_steem_dollars': 10000,
'allow_votes': True,
'allow_curation_rewards': True,
'extensions': []
}]

理论上来讲,这个操作可以在任何时候广播到网络上,但是实际上是有一些限制的,比如说:

  • max_accepted_payout只能减少不能增加
  • percent_steem_dollars只能减少不能增加
  • beneficiaries设置的时候,必须没有投票
  • ……

所以,最佳的方式,是把comment以及comment_options两个operations 放到一个transaction中,这样就不必去考虑那些复杂的约束条件了。

测试 comment_options

为了简便,我将comment以及comment_options两个操作分别命名op以及op_co(请原谅我的命名水平):

文章链接、标题、内文等基本信息如下:

permlink = "testpost15"
title = "测试100% Power UP"
body = "这只是个测试,本文作者收益100% Power UP!"

关于op的基本操作为:

op[1]["author"] = "oflyhigh.test"
op[1]["permlink"] = permlink
op[1]["parent_permlink"] = "test"
op[1]["title"] = title
op[1]["body"] = body

关于op_co的基本操作为:

op_co[1]["author"] = "oflyhigh.test"
op_co[1]["permlink"] = permlink
op_co[1]["max_accepted_payout"] = HIVE_ASSET('1000.000 HBD')
op_co[1]["percent_steem_dollars"] = 0
op_co[1]["allow_votes"] = True

将两个操作追加到transaction并广播:

trx.append_op(op)
trx.append_op(op_co)
trx.sign_digest(wif)
trx.broadcast()

广播出去的transaction大概长成这样:

image.png

区块链浏览器(https://hiveblocks.com/)上可以看到我们的transaction:

image.png

这里可以看到我们的帖子:

image.png

那个红色的小LOGO就表示这个文章Power UP 100% 哦,欢迎大家去给文章点赞哦。(^_^)

相关链接


This page is synchronized from the post: ‘每天进步一点点:comment_options 操作 & Power UP 100%’

“香椿”变臭椿

大概不到两年前,院子的正中央突然长出一根小树苗,看样子像极了香椿树。要知道香椿树的嫩芽是一种美味又极富营养的食物,所以尽管这棵树的位置不太正,我还是没有把它移除掉。

image.png

没想到,这棵“香椿”树发育的极其迅猛,一年的时间就从一掌高的小树苗长到了一米多高,而今年则感觉超过了两米八,估计再过几年就能涨到天际。

这让我感到有些奇怪,我后院的香椿树感觉长得没这么迅猛啊,这棵树真的是香椿树吗?来,发张竖版照片感受一下它有多高。

image.png

不过是不是香椿树其实很好判断,这不是春天了嘛,树上长满了嫩芽,我决定把嫩芽掰下来,弄一盘香椿炒蛋。

然而嫩芽嫩则嫩矣,怎么感觉闻起来没有香椿的味道呢?为了避免吃错食物中毒,我决定还是先用小程序的识别软件识别一下,识别的结果竟然是臭椿。

image.png

我晕,以为它是香椿,所以让它在院子中间自由自在地生长了两年,结果它竟然是冒牌货,既然是冒牌货,我就不必对它客气了,果断铲除。

废了九牛二虎之力,总算把丫挖了出来,放花架上展示一下它有多高。嗯,长得倒是很直,貌似可以用来当竹竿用?

image.png

除了这棵冒充香椿的臭椿树,一并被我铲除的还有一根长在郁金香中央的白蜡树,我一直以为它是一根果树呢,顺便识别了一下,才发现是冒牌货。

也展示一下,哎,貌似我的石桌桌面有点脏,不过没关系,水管就快修好了,明天我就可以好好冲洗一下了。

image.png

感谢微信小程序识花君,让我一下子甄别出这两棵冒牌的树木。

其实生活中又有多少冒牌的人和事呢?当成香椿去对待,结果却是臭椿。然而生活中却没有识花君这样的软件帮我们分辨,这真是遗憾啊。


This page is synchronized from the post: ‘“香椿”变臭椿’

每天进步一点点:witness_update 以及witness_set_properties

我们都知道,见证人在HIVE/STEEM系统中是很重要的角色,除了打包出块、提供喂价以外,见证人还决定网络中一些参数的设定,比如说账户创建费用/区块大小等等。


(图源 :pixabay)

而这些参数的设定,就是通过witness_update这个操作完成的。当然了,参数如何起作用是一个复杂的话题,不是一个见证人自己修改就可以的,这也保证了网络的安全。

witness_update除了设置网络参数外,还可以对自己的见证人信息进行一些设置,比如说设置自己的见证人URL,又比如说见证人上线/下线,要知道,在分叉之初,我可以是被见证人上线/下线问题搞得头大无比呢。

witness_update 操作

在这里,我们先不去讨论参数的意义以及如何生效,先来学习一下如何设置参数吧,首先witness_update操作大概长这样:

1
2
3
4
5
6
7
8
9
10
11
op = ['witness_update', {
'owner': '',
'url': '',
'block_signing_key': '',
'props': {
'account_creation_fee': '',
'maximum_block_size': 65536,
'sbd_interest_rate': 0
},
'fee':''
}]

看起来很简单是不是?甚至props都可以缩减成'props':{}这个样子,然后在代码中设置即可。

根据传入的参数,做如下设置:

op[1]['owner'] = owner
op[1]['url'] = url
op[1]['block_signing_key'] = block_signing_key
op[1]['props'] = props
op[1]['fee'] = HIVE_ASSET(fee)

然后将Operation追加到transaction并广播(使用active key):

trx.append_op(op)
trx.sign_digest(wif)
trx.broadcast()

witness_update 测试

我使用@oflyhigh.test 进行测试,props设置如下:

1
2
3
4
5
props ={
'account_creation_fee': HIVE_ASSET('3.000 HIVE'),
'maximum_block_size': 65536,
'sbd_interest_rate':0
}

block_signing_key设置为空私钥(全零)对应的公钥:

block_signing_key = 'STM1111111111111111111111111111111114T1Anm'

成功广播出去:

image.png

https://hiveblocks.com/ 可以查到数据已经更新到链上:

image.png

见证人注册

对于一个原本不是witness的账户,调用了witness_update操作,会是怎样呢?

其实@oflyhigh.test就是这种情况,事实告诉我们,非见证人账户进行witness_update操作,相当于在链上注册了一个新的见证人账户

image.png

揭开神秘面纱后,原来注册见证人账户这么简单,不过注册账户虽然简单,把见证人服务跑起来可不是件容易的事情呢!

更新一个参数

通过上边的学习,我们知道witness_update涉及很多参数,如果我们只想改动其中一两个而不动其它,应该怎么办呢?难道还要把其它参数传入一遍吗?

答案是,还真的重新传入一遍,但是也不是没有取巧的方法,比如我们可以先读取原来见证人的参数,然后只修改我们要改动的,其它的原样传入就好。

程序中的默认值

测试的时候突发奇想,如果把 props设置为{}并传入,会是如何呢?说干就干:

image.png

结果上链数据如下,看来这些是程序中的默认值喽:

image.png

witness_set_properties

现在我们基本上把witness_update操作搞明白了,不过HF20之后,又引入了一个新操作 witness_set_properties,这又是什么鬼呢?

从文档给出的示例结构中,我们不难看出它能设置更多的内容,甚至包括喂价。

image.png

文档中对其的描述为:

This operation was added in Steem v0.20.0 to replace the witness_update_operation which was not easily extendable. While it is recommended to use witness_set_properties_operation, witness_update_operation will continue to work.

不过,目前为止,我觉得witness_update_operation对我而言已经足够啦,另外搞明白这些真好,再也不用为见证人上线/下线等事情头大了。

相关链接


This page is synchronized from the post: ‘每天进步一点点:witness_update 以及witness_set_properties’

Your browser is out-of-date!

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

×