大概四个月之前，学习了一下HIVE治理票中Delayed Votes（延迟投票）的相关内容，当时就有一个想法，在我的见证人列表工具中加上Delay Votes查询，让计算更为精准。 (图源 ：pixabay) 就像我很多想法都是拖呀拖一样，这个想法也一样，我总是能找到各种借口拖延，今天一早终于下定决心，一定要搞定这个功能。 首先，复习了一下Delayed

早晨起床手机上访问一下cutehive.com， 竟然发现无法打开，于是又去电脑上尝试访问了一下，还是打不开，这是怎么了啊？ (图源 ：pixabay) 电脑上的提示信息如下： 莫非是绑定此网站的VPS出故障了？当我准备登录VPS去检查时，突然想起来，这次出行之前曾经收到过域名即将到期的提示。然后计算了一下时间，我出行回来再续费是来得及的。

昨天的帖子说到升级VPS把网站(cutehive.com)搞崩溃，费了九牛二虎之力把PHP解析问题、curl_init问题、见证人列表的喂价显示问题解决掉了。 (图源 ：pixabay) HP委派查询出错 不过还剩一个问题，那就是PHP连接并使用MSSQL问题。我在HP委派查询工具中，连接到HiveSQL，这样可以查询委派进来（Delegations In)的HP。 至于委派进来（Delegations

之前因为新版本的HIVE节点（hived)对系统的最低要求为Ubuntu 20.04 LTS，我一狠心把编译机、测试机等都升级成Ubuntu 22.04 LTS了，想着这样一劳永逸，以后好几年不用关心系统的问题啦。 (图源 ：pixabay) 不过弄完hived的机器后，我发现我还有N台机器在运行Ubuntu 18.04 LTS以及Ubuntu 20.04 LTS，比如网站 20.04 LTS呢！

早在一个多月以前，就收到域名cutehive.com快要到期的提示，话说这注册商也够负责的，提前一个多月就开始持续地邮件轰炸，想忘掉续费几乎是不可能的。 (图源 ：pixabay) 当然cutehive.com这个域名我是不可能放弃的，续费一定要续费的，毕竟两年前注册这个域名时，我是打算用它做一番大事业呢。 但是拖延症又毫不意外地爆发了，既然还有一个多月到期，那我就等等吧，毕竟最早的邮件提示是这样的：

昨天发帖抱怨域名cutehive.com过期且续费遇到一堆问题，并提供了一个通过修改hosts文件临时访问的方案。今天偶然用手机测试了一下域名，发现竟然可以正常访问了。 (图源 ：pixabay) 要知道，手机上我是不知道怎么设置本地解析的，所以手机访问正常说明域名已经被正常续费了。 打开邮件看了一下，果然收到注册商那边的工单更新信息： 大意就是我的联系信息更新成功了，然后域名也续费成功啦。

4月15号时发文记录续费域名cutehive.com的问题，然后还在庆幸幸亏自己早早就发现问题，提前了10多天去办理续费，否则到期后还没续费好，域名就访问不了啦。 (图源 ：pixabay) 结果我没预料到的是，通过联系在线客服和发工单等各种方式，我这个域名到现在还没续费成功，然后域名昨天到期，现在已经访问不了啦😭，全是眼泪啊。 我大致说一下之前情况： 域名快到期了我去自助续费 然后发现无法续费成功

早在好多天以前，我就收到来自域名服务商的邮件，提示我域名cutehive.com要到期啦。然而我拖延症又爆发了，就一直拖啊拖啊，拖到今天。 (图源 ：pixabay) 讲真，我一直觉得我当前这个域名服务商的系统有些烂，不过因为以前养过上百个域名，更注重价格一些，所以系统的各种毛病我决定忍忍忍。

两年多以前，在还没有分叉的时候，我做过HP委派查询的工具，可以通过微信公众号或者网页版工具查询HP委派信息。 (图源 ：pixabay) 首先我简单介绍一下HP委派： 委托人(delegator)将股权(vesting_shares)委派给受托人(delegatee)，股权（vesting shares）仍由原始账户（委托人）所有，但是投票权、投票收益以及资源(rc)分配等权益被转移(委派)给受托者。

今天使用见证人列表工具查看一些信息，竟然发现一个BUG以及一些细节上的问题，作为一个追求完美的强迫症患者，是可忍熟不可忍，必须改！ (图源 ：pixabay) HIVE Power的计算： 先来说BUG，看图中箭头指向： 这个地方显示的是，见证人投票等同于HIVE POWER的数量，因为Vesting shares看起来不是那么直观，1000M或者2000M相当于多少HP啊？所以这块我加了这个功能。

今天HIVE出了一些小插曲，很多见证人丢块，据说原因是因为一次微分叉导致一些见证人跑偏了。也就是说丢块的见证人其实是在一条错误的链上继续出快呢。 (图源 ：pixabay) 这其中的技术细节以及具体原因见证人们正在分析，我也不过是一知半解，不过好在我的见证人节点以及备份节点都没跑偏，庆幸不已。 见证人投票

昨天使用自己的网页版代理查询工具，发现VESTS显示正常，但是HIVE POWER显示不正常都是0.000。另外发现一个历史遗留问题，那就是HP在表头上还显示为SP，今天决定抽时间把这几处错误修改一下。 (图源 ：pixabay) 首先，先来看一下当前的显示状态： 箭头指向处的SP应该修正为HP，方框中的数值应该是实际的数值而不应该为0.000。

昨天看了一眼提案列表，发现#133 我竟然还没投票Airdrop VESTS/HP: non DHF funds held in trust used to repay up-front correction 我竟然还没投，要知道Hive的二次空投修复操作都已经完成了，中文区受影响的小伙伴们都已经收到了空投。 (图源 ：pixabay)

获取账户信息是HIVE区块链最基本的功能之一，也是我们最常用到的功能。通过查询账户信息，我们可以知道账户的基本信息、账户的余额、账户的权限信息以及投票mana等等。 (图源 ：pixabay) 但是你知道吗？是不用不同的API，获取账户信息的返回还有些差异呢，我们这里简单来介绍一下。 对节点(hived)直接发起请求 获取账户信息最方便的方式是对自己的节点发起请求，我本地运行着一个轻节点，用来做测试那是极其便利的。

好久没有更新我的每天进步一点点系列了，因为最近太忙了，忙到连写代码和调程序的时间都几乎没有，所以每天进步一点点说起来很简单，但是实际要做到还真的挺难呢。 今天抽出些时间完成了HP委托这个功能，我们知道，HP就相当于你在HIVE上的股权，点赞能点出多少金额、踩人有多大力度、甚至你在HIVE上能用多少资源(RC)，这些都和你持有多少HP息息相关。 (图源 ：pixabay)

无论在文档还是代码中，对API的分类，差不多都是从插件层次进行的，比如说Database Api、Reputation Api、Follow Api等等，这样做的好处是一个插件对应一组API，但是缺点是不同功能混杂到一起。 (图源 ：pixabay) 那么如果要实现一个给用户使用的库，是否可以考虑从功能角度来给HIVE的API分类呢，我想了想，这样应该是可行的。我简单归纳总结一下，大致可以按如下模式划分。

通知功能(Notification)是HIVE上一个比较有用的功能，在通知列表(Notifications)中我们可以看到最近发生了哪些和自己账户相关的事情，比如说谁给我点赞点赞价值又是多少、谁转发了我的帖子、谁回复了我等等。 (图源 ：pixabay) 但是每当有新消息需要通知，我们的头像上就会多出来红色小椭圆，里边显示未读的消息数目，有时候几天不进通知列表里查看和设置已读，这个数字甚至会达到数千。

读了@blocktrades 关于去中心化黑名单的文章Hivemind API update to support decentralized blacklists后，觉得很受启发。 (图源 ：pixabay) 相比于之前单调的follow\unfollow\mute\unmute，去中心化的黑名单无疑适用于更多的场景，让我们操作起来更为简单。

昨天仓猝地上线了 帮我指出了一些旧链接的问题，@someguy123 帮我指出了SEO优化的问题 以及www 前缀访问的问题。 (图源 ：pixabay) 链接问题我知道导致问题的原因以及如何处理，所以当时就改正了；SEO的问题嘛，因为这个站点基本上应该就是HIVE的用户使用，所以并不着急优化；但是www访问给我自己也带来一些麻烦，所以这个必须及时处理。 www 访问

以前很多朋友反应过eztk.net这个域名不太好记忆，尽管我觉得四字母域名挺酷，但是对于其它人来讲，记忆几个看起来不相干的域名是挺麻烦的，所以我注册了一个新域名 (图源 ：pixabay) 前段时间，eztk.net 所在的独立服务器(Bare metal server)被取消掉，把eztk.net 放到一个虚拟主机上，又没有SSL证书，所以导致正常访问都很麻烦(只能用http而不能用https方式)。