今天在一个网站(PyPI )注册账户，这个网站在我的判断中属于中等重要的网站，所以我选取了自己一个经常在中等重要网站上使用的密码。 (图源 ：pixabay) 按说在很多网站使用同一个密码不是一个好行为，不过要注册的网站那么多，都用不同的密码，哪里记得过来嘛，又不想用什么密码管理软件，所以就把网站分三六九等，重要的网站一站一密码，其它的视情况分配。 然而今天的密码输入后，竟然出现了如下提示： 文字内容如下：

帮朋友写一段短小的Python代码，其每次运行时会产生一个字符串，需要与上次运行时生成的结果字符串对比一下，来判断是否需要继续。 (图源 ：pixabay) 要想做到这点有很多办法，比如说读写数据库啊、读写配置文件啊，但是无论那样都觉得太麻烦了，毕竟我们没有太多的数据要存储，不过是一个字符串。 想来想去，最简单的办法莫过于直接写个文本文件了，因为既要读取又要写入，于是我直接写了如下打开文件的代码：

之前的帖子中提到了鲁迅小说《孔乙己》中茴香豆的四种写法，孔乙己这个人物让我印象深刻的还有一句话，那种就是：“窃书不能算偷……窃书！……读书人的事，能算偷么？” 说到窃书，前段时间还有人炫耀利用图书馆的规则漏洞，弄出来不少书，引发网络上的大争议，不过我今天要说的还真不是窃书，而且偷花。 别想歪，此偷花就是字面上上的偷花，而不是什么汪洋大盗采花淫贼啥的。

还记得鲁迅小说《孔乙己》中提到的茴香豆的“回字有四样写法”吗？孔乙己觉得自己掌握了茴香豆的几种写法，是一个有学识有文化的人。 (图源 ：pixabay) 今天在写一段HMAC代码时，直接就用了 digest = hmac.new(key.encode('utf-8'), msg.encode('utf-8'), digestmod='sha256').hexdigest() 然后突然想起来我以前习惯这样用：

这几天抽空把院子里大部分空地种上了，又是翻地，又是播种，有些秧苗还是开车跑了很远的地方去买回来的，累得腰酸背痛的。 先说说封面图，看这长势良好的油麦菜（请忽略后边埋汰扒拉的烧烤炉），你肯定以为这是我去年盛夏拍的吧，其实并不是。 去年夏末秋初，我看院子里这块地空着，就打算种点油麦菜，寻思即便长不大，但是只要能长出一些我就可以吃啊，结果等到冬天下雪，也没看到油麦菜的影子。

之前的文章中，我学习了如何创建订单，尽管有两种方法可以选择，但是最终我还是选择了一个便于理解的。但是新问题来了，订单创建后，我们如何查看？以及如何取消呢？ (图源 ：pixabay) 在说到查看与取消之前，我们先来看看fill_or_kill & expiration两个参数。 fill_or_kill fill_or_kill

今天去招商银行办事，在附近转了两圈才把车听到招行门口，事情很快办完了，想想费这么大劲停车就这么走了，有点亏得慌，恰巧招行对面有个小公园，不如去小公园转一圈吧。 原本以外因为疫情的缘故，人会很少，可是实际上人还真不少，在亭子里乘凉聊天的，在器材那边健身运动的，还有跳广场舞的，看来大家都憋闷坏了。

之前说到Power Up，并且实现了Power UP 功能，然而Power UP需要有流动性HIVE才行，如果只有HBD，那么就需要用到内部市场来交易成HIVE了。 (图源 ：pixabay) 同样，之前的交易我是用cli_wallet完成的，命令格式为： create_order(string owner, uint32_t order_id, condenser_api::legacy_asset

大概十几天以前，我的一个客户站点无法访问，然后我调查半天没调查明白，奇怪的是服务器上其它站点都正常。 (图源 ：pixabay) 服务器是IBM公有云中的裸金属(我一直以为这个翻译怪怪的）其实就是独立服务器。于是想着登录一下它们的后台看看到底发生了什么事情。

昨天在测试memo的时候，放了几段长长的古文，比如《得道多助，失道寡助》之类的，结果用力过猛，@oflyhigh.test RC不够用了。 (图源 ：pixabay) RC告急 看着这段提示就很闹心，何况还要等很久等RC恢复，这我不能忍受😳 'plugin exception:Account: oflyhigh.test has 436004956 RC, needs 535083479 ' 'RC.

经过了几个昼夜的学习和测试，终于搞定了memo的加密解密。原本以为这块不会有多复杂，但是实际沉浸下去才发现涉及的内容还很多。 (图源 ：pixabay) 涉及内容 简单回顾一下涉及的主要内容： 理论基础：Pub(Alice) * Priv(Bob) = Pub(Bob) * Priv(Alice) 内容加密：AES (Advanced Encryption Standard)，CBC模式

想必大家都知道或者接触过蜂巢快递柜，有时候家里无人或者什么情况不便接收快递的时候用快递柜特别方便，尤其是在疫情期间，快递柜做无接触配送的一种方式，更是立下了汗马功劳。 (图源 ： 然而不知道是因为快递员懒惰还是因为和快递柜有合作关系，明明家中有人，配送也极其方便的情况下，他们还是把快递包裹投递到快递柜。

大概春节疫情刚起的时候，都推荐用酒精消毒，导致酒精难以购买得到。考虑到酒精和白酒的主要成分都是酒精，于是我买了几箱二锅头用来消毒。 (图源 ：pixabay) 当然了，后来按专家们的说法，白酒达不到酒精的浓度，什么渗透压一堆乱七八糟的术语，什么没法突破细胞壁云云，什么会在细胞表明形成保护层，总之总结起来就是一句话：白酒没法消毒。

在处理memo的时候，发现steem-python 以及 beem 等，都是假定编码后的字符串长度值可以存储在一个字节内，这样memo的长度只能限制在255个字节以内了。 (图源 ：pixabay) memo 长度问题 比如steem-python中处理message的部分代码如下： 那么memo到底支持多长的内容呢？在微信群中提出这个问题后，@abit 指出memo可以支持任意长度(受限于区块大小，RC等）

4、5月份是播种的季节，然而我这两天为买秧苗犯了愁，虽然大概10公里以外有一个农贸大集，但是沿途特别堵车，到了地方也很难找到停车位，愁啊。 (图源 ：pixabay) 上午的时候，去附近的露天市场看了一下，发现有卖菜的、卖水果的、卖鱼卖肉的、甚至还发现卖花的，就是没有发现卖秧苗的，看来哪天免不了跑一趟了。

在Memo使用AES加密的过程中，除了使用到shared_secret外，还涉及到两个数值：分别是nonce以及check。 (图源 ：pixabay) nonce & check 其中nonce是一个64位的随机数(8字节)，在BM的一篇文章中曾有提及： The purpose of the 'nonce' field is to generate a unique encryption

院子里的鸢尾花开正浓，紫色的、黄色的，争奇斗艳，仿佛都想把对方比下去，然而却又不相伯仲。 有意思的是，往年鸢尾花，黄色开完紫色才开的，貌似花期不在同一时间，而今年或是因为雨水充足的缘故，都一齐冒了出来呢。 除了鸢尾，我之前栽种的重牛也在一直地开啊开，一点不甘示弱，不过我总觉得重牛完全是为了开花而开花，太过于辛苦了。 院子外边我移栽了一些鸢尾，终于有了效果，用过路阿姨说的话：幸苦耕耘总算有了收获。

通过之前的文章，我们已经知晓了Memo的大致工作原理，那就是： 发送者利用发送方的私钥和接收方的公钥生成共享密码，而接收者用接收方的私钥和发送方的公钥同样可以获取共享密码。 (图源 ：pixabay) 当然了，共享密码生成还是需要经过一系列的处理，并且发送/接收方要按相同的流程和规范生成，这样才能正确地加密/解密。 那么问题来来了，明文有了，密码有了，我们用什么手段加密明文呢?

说到光头，理过几次光头，不过不仅冬天冷冻脑袋不说，夏天光头也没有想想中的那么舒服，一旦热的出汗，没有头发帮忙挥发，黏糊糊的贴在头皮上更难受。 (图源 ：pixabay) 况且前端时间我又办了理发卡，不去发廊理发就觉得卡白办了一样，所以一段时间内都是去发廊，嗯，顺便弄个造型，看起来舒服那么一丢丢。

在之前的文章中，我们学习并测试了Memo加密的原理，一个关键性结论就是： Pub(Alice) * Priv(Bob) = Pub(Bob) * Priv(Alice) (图源 ：pixabay) 而这个乘积就是被当作Memo加密的密钥来用的，一般代码中称其为：shared_secret。 错误的探索