In many client programs, a signature failure occurs when an operation such as a transfer is performed.
(图源 :pixabay)
A temporary and useful solution is to replace symbols such as “HIVE” and “HBD” in operations (such as transfer) with “STEEM” and “SBD”. But it feels strange.
Today I’m trying to figure out what’s causing this problem.
I created a transaction like this one:
1 | {'expiration': '2020-04-16T09:30:55', |
Then use get_transaction_hex
to serialize it. I got the result like this one:
Hex b’o\xd4\xbemfw\xcf%\x98^\x01\x02\roflyhigh.test\x08oflyhigh\x01\x00\x00\x00\x00\x00\x00\x00\x03STEEM\x00\x00\x05Hello\x00\x00’
It’s not hard to see “oflyhigh”, “oflyhigh.test”, “Hello”, etc., but why the “STEEM” character? Shouldn’t it be the HIVE character?
I tried to sign and broadcast on top of that, what happened? It worked!
Therefore, it is not difficult to conclude that the server-side (chain side) serialized token symbol is “STEEM” “SBD”, which also explains why many client programs have errors like “Missing Active Authority”.
Because on the client side, “HIVE” and “HBD” are typically used as token symbols and serialized on the client side, The result of serialization is not the same as that of the server-side (chain side) .
So the best approach is not to replace “HIVE” &” HBD” with “STEEM” &”SBD” in the client script, but to solve the problem completely on the server-side (chain side) .
But as far as I know it’s a super complicated thing and there’s nothing I can do about it.😳
This page is synchronized from the post: ‘Wrong serialization result 与签名错误’
在我们之前的文章中,我们没少接触到transaction,里边的内容诸如expiration、operations看字面意思就能理解,但是其中的ref_block_num
以及ref_block_prefix
是什么东西呢?有些让人犯迷糊。
(图源 :pixabay)
今天来探索一下这都是啥,看看能不能搞懂一点点。
在STEEM/HIVE的文档和代码中找了大半天,也没找到说明,比如steem的transaction结构代码中:
把变量往那一扔,谁管你来龙去脉的,好在steem和bitshares是一脉相承的,所以最终在bitshares的代码中找到两句说明:
其中关于ref_block_num
的说明:
Least significant 16 bits from the reference block number. If @ref relative_expiration is zero, this field must be zero as well.
其中关于ref_block_prefix
的说明:
The first non-block-number 32-bits of the reference block ID. Recall that block IDs have 32 bits of block number followed by the actual block hash, so this field should be set using the second 32 bits in the @ref block_id_type.
在EOS中,白皮书中把相关内容说的更明了一些了:
简单来讲通过ref_block_num
以及ref_block_prefix
指向之前已经存在的一个块与hash来防止重播攻击等。
虽然我找了大半天资料,但是其实我一点也不懂它们在说啥,不过没关系,不懂装懂就好了。简单来讲,就是ref_block_num
以及ref_block_prefix
是transaction的重要组成部分,没有或者不正确,transaction就没法成功广播道网络上去。
接下来,我们只要研究咋把这两个值弄出来就好了。
最简便的一种方法是直接取head_block的head_block_number
以及head_block_id
来生成。而相关信息可以通过get_dynamic_global_properties
来获取。
大致代码如下:
tx["ref_block_num"] = dgp["head_block_number"]& 0xFFFF
tx["ref_block_prefix"] = struct.unpack_from("<I", unhexlify(dgp["head_block_id"]), 4)[0]
(之所以从第4个字节取起,是因为block_id的前4个字节就是block_num本身)
再回头看steem-python中是如何做的:
通过代码可以得出,他取得是head_block往前数第三个块的block_num
以及block_id
来计算head_block_number
和head_block_id
。
取往前数第二个块的previous
结果应该和取往前数第三个块的block_id
是一样的,有些费解,steem-python中这样做的好处是什么呢?
虽然我不知道该咋回滚,但是据说没变成不可逆块(irreversible_block
)的区块是有可能被回滚的(分叉时丢弃?)
假设微分叉(micro-fork)发生时,那么应该有两个头块,我们引用头块的话,就有二分之一的概率引到被废弃的分叉上的头块。
这样之后分叉出来的头块被丢弃,我们又引用了这个块,我们的transaction也将会被丢弃。所以steem-python中往前数三个块再引用的方法是相同安全的。
貌似更安全一些的方法是引用last_irreversible_block_num
,首先用get_dynamic_global_properties
获取last_irreversible_block_num
,然后再用get_block
读取出对应block中的block_id
。
This page is synchronized from the post: ‘每天进步一点点:探索transaction中的refblock*’
之前的文章里说过驾驶证容缺换证,证已经发下来了,但是体检证明一直没提交,交警中心一直发短信提醒补交身体条件证明,说是不补交的话以后办理业务将会受限。
(图源 :pixabay)
虽然因为疫情的缘故,我实在是不想去医院体检,不过一直拖着也不是办法,于是今早果断决定去医院体检。
不到9点的时候,我带了两层口罩,开车出门去医院,原本想着疫情的缘故,去医院的人肯定非常少,停车不会是问题。结果到了以后在地下停车场转了半天才在负二层找到一个车位,实在是太难了。
从停车场进入到医院电梯还有人把守,要先登记和测量体温,我晕啊,大家公用一个笔登记,这样真的好吗?不过不登记就不让进入,只好登记喽。
体检中心在负一层,到那让我出示身份证和驾驶证,然后弄一张空白表格给我,让我去检查视力和辨色力,哎,最近整天对着电脑和手机,眼睛都花了,好不容易才通过。
检查完视力和辨色力回来,又让我坐到椅子上,把口罩摘掉,双手放胸前,对着他们的电脑拍个照,哎,咋感觉像似对待罪犯呢?
弄完之后,去一层缴费20元,然后再回来之后,他们打印了一个报告给我,这就算完毕啦。
回来之后,我第一时间把两层口罩都丢进垃圾桶,然后用香皂反复洗手洗脸多次,用消毒湿巾把手机反复擦了好多遍,这样才放心一点。
(图源 :pixabay)
哎,疫情期间还要去医院体检真是伤不起,不过既然去了,还是多注意防范一点吧,安全第一。
This page is synchronized from the post: ‘疫情期间去医院体检’
辛苦培育了一年多的韭菜终于长到可以割的程度啦!什么,你说我根本没有付出什么辛苦?难道你忘记了我给你从贫瘠之地移栽过来,给你浇水、给你施肥、给你拔草、给你除虫了嘛?
好吧,其实我也忘记我是否做过这些事情了,不是你在我的土地上,既然可以吃了,现在别的菜又那么贵,那我就毫不客气啦。
先来一张茁壮成长的图(额, 里边的杂草暴露了我疏于伺弄的真相)
割韭菜利器来了,其实最好的方式是用小镰刀,镰刀一割一大片,那才叫过瘾。据说镰刀用的好,连自己都可以割:
其实在韭菜还没有长大成人的时候,我就已经割了无数次了。韭菜之所以这么被人喜爱,就是因为割完一茬过段时间可以再割一茬,一茬又一茬,永无止境。
辉煌的战果,必须再秀一次
韭菜韭菜,快到盆里来,我给你找了好朋友——鸡蛋
怕你们觉得冷,给你们放到平底锅里取暖
给你们换新衣服了,焦黄焦黄,是不是很好看?
哈哈,鲜嫩的韭菜就这样变成了美味的韭菜盒子,难怪都喜欢割韭菜呢。不过割韭菜虽好,作为韭菜被割就不爽啦。
This page is synchronized from the post: ‘割韭菜啦,韭菜是如何变成韭菜盒子的?’
之前在院子外边的花园里移栽了一些鸢尾,在院子里边的花盆里栽了一些重牛。可是感觉院子外边的花园里还是有些空荡荡的,这在我拔掉一些干枯的绿化树后愈发明显。
于是跑了一趟花市,买了一下花种和几盆花,先将这几盆花移栽到院外的花园里吧。
花市,并没有因为疫情的缘故不摆摊
买的几盆花之中的两盆,卖家说是玫瑰,我觉得是月季
挖俩坑,后来发觉挖深了,有填回去一半
把小花放到里边去,刚刚好
两盆花都放进去,填好土
来个特写一
来个特写二
给它们喝足水
另外两盆花,一个是康乃馨,另外一个不知道,反正很漂亮是了
《悯农》里写:
锄禾日当午,汗滴禾下土。
谁知盘中餐,粒粒皆辛苦。
挖坑栽花也好辛苦啊,还剩一盆玛格丽特,明天再栽,还有买了一堆花种,明天研究一下一并播种下去,但愿我的小花园变得五彩缤纷吧。
This page is synchronized from the post: ‘将栽花进行到底’
Update your browser to view this website correctly. Update my browser now
咋玩呀,哈哈 This page is synchronized from the post: 咋玩? document.querySelectorAll('.not-gallery-item') .forEach(el => { if (!el.dataset.src) { return; } c
十几年前,因为工作的缘故接触Linux系统。 作为Windows盗版系统的“受益者”,除了学校《操作系统》课程接触的ls、cd、dir、pwd等几个有限的命令,实在是想不起再多的内容了。IBM社区上有一些很经典的Linux系统教程,不得不说从中受益匪浅。然而,工作需要,系统的了解和学习依旧迫在眉睫。
Almost all of the articles are illustrated on Steemit.So I try to figure out how to insert pictures in steemit articles? Then I found two ways: (Maybe
当年错失参与比特币的大好时机,时也命也! 往者不可谏,来者犹可追。按照X网几位比特币和区块链技术的布道者,steemit.com有望成为新的一轮革命。 作为一枚懒散的宅男,是拒绝接受新事物的(其实本质是懒)但是眼见着铺天盖地的讨论,各种前景展望,内心无法保持波澜不惊了。 对赚钱的期望有,但不是那么强
作为一个社交媒体平台,内容毫无疑问是最重要的元素。想象如果这个平台充斥着广告、水贴、色情与暴力等垃圾信息,那么想必离死亡非常接近了。 作为去中心化的平台,尽管顶贴(点赞)等机制会尽量筛选出优质内容呈现在我们眼前,但作为参与的每一个个体,都应当尽量去生产有价值的内容。如果参与者不但会从发文、点赞等行为