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
2
3
4
5
6
7
8
9
10

{'expiration': '2020-04-16T09:30:55',
 'extensions': [],
 'operations': [['transfer',
                 {'amount': '0.001 HIVE',
                  'from': 'oflyhigh.test',
                  'memo': 'Hello',
                  'to': 'oflyhigh'}]],
 'ref_block_num': 54383,
 'ref_block_prefix': 2003201470,
 'signatures': []}

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 与签名错误’

院子里的郁金香开了，争奇斗艳，漂亮非凡，不过我觉得还没有路边的蒲公英小黄花好看呢？莫非这就是所谓的家花没有野花香吗？

除了郁金香和野花，外边的杏花也开得正艳，让我时不时地想起一句诗：

小楼一夜听春雨，深巷明朝卖杏花。

可惜的是，盼了好久好久，也没盼到春雨，倒是有几次疑似龙卷风。另外搞不懂的就是为什么会有人卖杏花，有人买吗？

如果有人买，我这倒是有好几树的杏花，想必可以卖不少钱吧？

This page is synchronized from the post: ‘万般红紫斗芳菲’

在我们之前的文章中，我们没少接触到transaction，里边的内容诸如expiration、operations看字面意思就能理解，但是其中的ref_block_num以及ref_block_prefix是什么东西呢？有些让人犯迷糊。

(图源 ：pixabay)

今天来探索一下这都是啥，看看能不能搞懂一点点。

refblock* & TaPos

在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来防止重播攻击等。

Python代码

虽然我找了大半天资料，但是其实我一点也不懂它们在说啥，不过没关系，不懂装懂就好了。简单来讲，就是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中这样做的好处是什么呢？

为什么不用head_block

虽然我不知道该咋回滚，但是据说没变成不可逆块（irreversible_block）的区块是有可能被回滚的（分叉时丢弃？）

假设微分叉(micro-fork)发生时，那么应该有两个头块，我们引用头块的话，就有二分之一的概率引到被废弃的分叉上的头块。

这样之后分叉出来的头块被丢弃，我们又引用了这个块，我们的transaction也将会被丢弃。所以steem-python中往前数三个块再引用的方法是相同安全的。

貌似更安全一些的方法是引用last_irreversible_block_num，首先用get_dynamic_global_properties获取last_irreversible_block_num，然后再用get_block读取出对应block中的block_id。

参考资料

• https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md#transaction-as-proof-of-stake-tapos
• https://github.com/steemit/steem/blob/master/libraries/protocol/include/steem/protocol/transaction.hpp
• https://github.com/bitshares/bitshares-core/blob/master/libraries/protocol/include/graphene/protocol/transaction.hpp
• https://github.com/steemit/steem-python

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: ‘将栽花进行到底’