很多新来的朋友，会比较重视钱包中的账户估值即Estimated Account Value。

STEEMIT网页上是这么描述的：

The estimated value is based on an average value of Steem in US dollars.

你看，说什么STEEM啥的，很难在心里形成一个直观的价值，但是说成US dollars，则明了多了，对于CN区的朋友也一样，大概乘以6.3就是人民币价值了，说账户值几万人民币，总比说值几百个STEEM要令人激动多了。

然而，事实果真如此吗？且听我慢慢扯来。

(图源 ：pixabay)

安全提示：O哥闲扯淡系列本就是闲扯淡，诸位千万别当真！

账户资产的组成

在分析这个问题之前，我们来看看账户资产都有哪些。

我能想到的，包括如下部分：

• STEEM POWER
• 流动性STEEM和SBD
• 存款(Savings)账户中的SBD和STEEM
• 内部市场(Market)中挂单的SBD和STEEM
• 转换(Conversion)中的SBD
• 已结算待收取(to be claimed)的收益
• 未结算的文章和点赞收益

对于未结算的文章，因为数值还没确定，如果不计算在内也很正常，预期收益不能算作资产，万一被踩就可能归零呢。点赞收益也是如此，因为点赞收益和文章收益的高度相关的，所以同理不能算作资产。

那一个账户的估值，主要应该由上边的这些部分组成。

STEEMIT钱包估值包含哪些部分？

既然我们已经知道了账户估值应包含这些部分，那么STEEMIT钱包中的账户估值是否包含了这些部分呢？答案是否定的。

很早以前，内部市场(Market)中挂单的SBD和STEEM 都没有被计算在内，我还提过一个建议，在钱包中显示一个locked 资金的条目，包括在内部市场挂单的资金。

现在，如果我们访问钱包且登陆钱包对应的账户，我们是可以看到类似XXX SBD Open Orders的项目，说明内部市场中的资产已经被计算在内了。然而如果我们没登陆或者访问别人的钱包，那么内部市场中的资金不显示也不被计算到估值当中。

另外已结算待收取(to be claimed)的收益也没有比计算在内。

不过其实也无所谓了，毕竟已结算待收取(to be claimed)的收益 随时收取就好，内部市场的嗯，我们也很少挂单，把流动性的和存款的显示并计算出来就好。

计算方式

好了，既然我们只要组成部分的大头主要部分，那么就不讨论组成部分的话题了。我们来看看STEEMIT的账户估值是如何计算的。

计算公式如下：

Estimated Account Value = (STEEM + SP) * current_median_history_price + SBD

其中STEEM 和 SBD 包含各种计算在内的资产（流动的、存款的、内部市场的、转换中的）

我们不谈组成，单谈这个公式，这计算出来的是啥玩意呢？

current_median_history_price这个是来自见证人喂价的3.5日均价，可以理解成STEEM的3.5日均价，单位是美元。

而STEEM的美元价值 + SBD，算出来的是啥东西？我觉得我很难解释。

为什么出现这个问题

你可能会问，为什么啊？是啊，这是为什么呢？

答案就是，STEEM设计的时候，SBD被设计成锚定1美元。如果锚定没出问题，上边的公式就很容易理解了，或者可以换成下边的方式：

Estimated Account Value = (STEEM + SP) * current_median_history_price + SBD * 1.00

但是SBD当前的实际价格约 5美元，所以实际上公式应该是：
Estimated Account Value = (STEEM + SP) * current_median_history_price + SBD * 5.00

看到差别了吧。

结论

因为SBD没有锚定 1美元，造成了STEEMIT计算账户估值出现严重偏差。取决于你SBD的多寡，SBD占的比例越大，这个账户估值偏差的越悬殊。

所以这个账户估值，是个缩水的估值，姑且就看看玩玩，实际你的账户比它显示的值钱的多呢，是不是很兴奋呀？

This page is synchronized from the post: O哥闲扯淡：账户估值是缩水的估值

这两天晚上出去溜达，看到到处都是缤纷的彩灯以及大红的灯笼，非常的漂亮，一片喜庆祥和的节日氛围。

我随手拍了一些照片，可惜手机晚上拍照的效果还是不太理想，大家将就看看吧。

会所旁边广场的彩灯。

我们把这个广场叫做陀螺广场，就是因为这个大陀螺哦。

大红灯笼。

拍摄完这组灯笼，返回路上的途中我撞到椅子上，险些把手机甩飞。

欢度佳节。

好多灯笼。

绵延起伏（这么形容恰当吗？）的彩灯。

快来快来数一数，二四六七八。

手机拍不出来那个绚丽的效果。

想起张也《万事如意》中的歌词

红灯照 照出全家福
红烛摇摇摇 摇来好消息
亲情乡情甜醉了中华儿女
一声声祝福
送给你万事如意

在这也一并祝大家万事如意喽，附《万事如意》的视频
http://www.kuwo.cn/mv/173039/

This page is synchronized from the post: 大红灯笼高高挂 / 缤纷彩灯

在前边的一篇文章《O哥闲扯淡： 硬叉19与平等》，我说到：

HF19的平等，其实它说的平等是有多少（等效）SP，就有多少平等对话的权利。或许这本就是HF19中平等的真正意义，只不过我们都曲解了罢了。

这里的等效SP，STEEM系统中叫做Effective SP，我有时候也翻译成有效SP，反正都是这玩意啦。

(图源 ：pixabay)

安全提示：O哥闲扯淡系列本就是闲扯淡，诸位千万别当真！

有效SP

有朋友问我，你说什么有效SP，难道对应的还有无效SP？Bingo，你都会举一反三了。为什么除了SP以外又搞出个Effective SP的概念了，就因为有了SP代理 / SP delegation。

SP delegation 又是啥东西呢？简单地将，就是你可以把你SP借给别人，包括和SP相关的一切权力和收益。既然把权力和收益都借出去了，那么对别人而言他在原本的SP基础上增加了对应的权力，对你而言对应的权力和收益必然减少，好像这么部分SP无效了。

计算公式： Effective SP = 你的SP + 别人代理给你的 - 你代理给别人的

有效SP与话语权

为什么说有效SP就意味着你的话语权呢，因为大多数来STEEM的人，都是为Money而来，而Effective SP 决定了你能为自己和别人的帖子创造多少钱，能创造的钱越多，当然越具有话语权。

说大多数人为钱而来，可能有些伤人，但是事实是HF18一段时间，大家的帖子收益都在几毛钱徘徊，而中文区每天的帖子数量有多少？不足20篇！

很多人会说，那时候我们不知道STEEM、不知道STEEMIT嘛。好吧，不提HF17之前有段时间每天上百篇帖子，就说HF19之后，一段时间每天都是近千篇，大家都纷纷表示热爱创作，热情高涨，然而后来中文区大福利都被撤掉，大多数帖子收益降到1 SBD以内，大家纷纷表示纵然很热爱创作，但是生活中还有更重要的事情要做，并且最近属实很忙~~。 然而冷清一段时间以后，由于STEEM和SBD价格的上涨，收益又变好了，于是乎生活中重要的事情也不那么重要了，最近也不忙了😀

好吧，大家都爱财，况且没偷没抢，没啥毛病。但是既然钱的重要性已经证实了，那么有效SP的重要性还用多说嘛？

增加有效SP的手段

增加有效SP的手段之一真金白银投入，购买SP，比如砸进来1000个比特币？

对与小户而言最常规的手段，就是发文、攒钱、换STEEM、存SP。

另外，可以考虑学utopian-io、dlive、dtube、dsound 等做一些对STEEM有价值的项目，然后拉赞助。这就要考验你的技术实力和社交手段了，缺一不可。

还有就是如果你有个大户好友，让他代理给你一些也有可能。这样的人你一定要珍惜，因为他把你们的友情看得比金钱还珍贵。

当然，还有一个手段就是花钱租SP，STEEMIT上很多小伙伴已经将这项技能掌握得炉火纯青，我就不多说啦。

有效SP排行榜

以下是全网有效SP的前30名，供大家参考。大家不难发现有些账户的声望分并不高，但是谁能说他们在STEEMIT上的声望不高呢？

(图源 ：pixabay)

相关链接

• O哥闲扯淡： 硬叉19与平等
• 微信公众号支持查询SP委派/代理(SP delegation)信息啦！

This page is synchronized from the post: O哥闲扯淡： 有效SP（Effective SP）就是你的话语权

在 @steemitdev 3天前的文章《AppBase: The next step forward for the Steem blockchain (let the testing begin)》 主要提到了两个东东，AppBase 以及 condenser_api。

AppBase 我一直以为是App 仓库呢，还以为steemit也要搞个类似应用商店一样的东西呢，结果后来我看到下边这个图，才知道他说的是系统架构，捂脸😳。

(图片来源：Steem Blockchain Update August 2017)

从这个图中我们可以看到无论AppBase 还是 condenser_api都是半年以前就计划的东西啦，还好我们终于看到影子啦，那么AppBase 就没啥说的了，来试试condenser_api吧。

新condenser_api

在 Steem Equality 0.19.4 (Appbase) Release Notes着重提到了这个condenser_api，说的是它包含当前在用的所有API中的所有方法。让你的程序跑到AppBase上最便捷的方法就是把api 都换成 condenser_api。

我们之前讲过通过RPC调用STEEM API，比如我们前几篇文章中举过的例子：

curl --data '{"jsonrpc": "2.0", "method": "call", "params": ["account_by_key_api", "get_key_references", [["STM6MGdForcZ8HskcguP84QSCb8udgz7W9yUPU5jtsAKQAxth3U16"]]], "id": 1}' https://api.steemit.com

其中account_by_key_api 需要我们显式的指定，类似情况还有follow_api, tag_api等等，参考上图。到了Steem 0.19.4以后呢，原来这些API都可以用condenser_api代替啦。

上边的命令，就可以改成如下模式

curl --data '{"jsonrpc": "2.0", "method": "call", "params": ["condenser_api", "get_key_references", [["STM6MGdForcZ8HskcguP84QSCb8udgz7W9yUPU5jtsAKQAxth3U16"]]], "id": 1}' https://api.steemitdev.com

注意节点的变更，开发节点当前是0.19.4版本。
返回结果如下：

API methods 列表

可以通过调用jsonrpc.get_methods返回支持的API以及方法列表，有以下三种调用方法：

curl --data '{"jsonrpc": "2.0", "method": "jsonrpc.get_methods", "id": 1}' https://api.steemitdev.com

curl --data '{"jsonrpc": "2.0", "method": "jsonrpc.get_methods", "params": {}, "id": 1}' https://api.steemitdev.com

curl --data '{"jsonrpc": "2.0", "method": "call", "params": ["jsonrpc", "get_methods", {}], "id": 1}' https://api.steemitdev.com

返回列表的部分内容：

需要注意的一点是，列表中列出的一些API，并非都已经实现的😳
也可以看这个列表，感觉就是把这个打印了出来。

流水线语法

就是说调用，可以用这个形式：
{"jsonrpc":"2.0", "id":0, "method":"call", "params":["api","function",[ARGS]]}

也可以用这个形式：
{"jsonrpc":"2.0", "id":0, "method":"api.function", "params":[ARGS]}

在 API methods 列表 小节中，我演示了这两种以及第三种不含参数的调用方式，所以无需赘述了。

其它

{"jsonrpc":"2.0", "method":"jsonrpc.get_signature", "params":{"method":"database_api.get_active_witnessess"}, "id":1}

发布说明中的这个我没运行起来，提示消息：

"message":"Assert Exception:method_itr != api_itr->second.end(): Method database_api.get_active_witnessess does not exist"

检查了一下，官网的文档中多写了个s，get_active_witnessess 应为 get_active_witnesses，修正后执行

{'id': 1, 'jsonrpc': '2.0', 'result': {'args': {}, 'ret': {'witnesses': []}}}

然而我并没有搞懂它表达的是啥意思呢？迷糊了，不研究了。

结论

感觉 Steem 0.19.4 发布的有些仓促，除了加了个 condenser_api，并没有多少新内容，而jsonrpc.get_methods 中列出的东西好多都没有实现。

另外 condenser_api与其说是Steem 0.19.4的新功能，不如说是jussi的功能，至少我在steem源代码中找不到一行代码含 condenser_api的字样呢。

不过不管咋说，STEEM在不断进步，这是我们大家所喜闻乐见的，祝STEEM越来越好吧！

参考链接

• AppBase: The next step forward for the Steem blockchain (let the testing begin)
• Steem Blockchain Update August 2017
• Steem Equality 0.19.4 (Appbase) Release Notes

This page is synchronized from the post: 体验一下 Steem 0.19.4 & condenser_api

有些新来STEEMIT的朋友，会问我这样一个问题，“O哥，30分钟有什么特殊的意义吗？为什么感觉好多帖子都是在30分钟以内点上来的？而过了30分钟，点赞的人就非常少了，这都是什么原因呢？”

(图源 ：pixabay)

这个问题说起来要涉及监护奖励、早鸟惩罚、机器人点赞等几个问题，我慢慢扯。

安全提示：O哥闲扯淡系列本就是闲扯淡，诸位千万别当真！

监护奖励

在STEEMIT上，除了发帖可以获取奖励以外，还可以获得监护奖励(Curation Rewards)。所谓的监护奖励(Curation Rewards)就是发现好帖子并通过点赞来使好帖子让更多人发现所获得的奖励，也就是我们常说的点赞奖励。

点赞奖励的金额(以SP形式发放)，是帖子总奖金的1/4，也就是25%。举个例子来讲，一个帖子得到了1000SBD，那么要扣除250 SBD分给全部点赞者，剩下的750 SBD分给作者。
(注：这个例子不涉及收益分享/Comment Reward Beneficiaries)

之前我们说过帖子线性奖励机制，就是说你有多少有效SP，用对于点贴的话，就可以给帖子增加相应的收益。那么也就意味着，原则上你可以拿到你给帖子增加金额的25%的点赞奖励。

但是，事实是，按照程序算法，越早点赞的人获取的奖励比例越高，也就是说早点赞的会获取超过25%的收益，晚点赞的收益会低于25%。（具体计算方法见代码吧，我没研究过，但不影响我们这个帖子要表达的内容）

早鸟惩罚

那么就会有人问了，既然越早点赞的人获取的奖励比例越高，那么我在作者帖子发布的第一时间就去点赞，岂不是爽歪歪。但是手工去点，总不能一直盯着新帖子发布，否则点赞钱赚不赚到不说，估计人会累昏迷，所有有人就打起了程序点赞的心思。

没错，这就是点赞机器人诞生的缘由。但是官方显然也清楚的意识到这一点。如果让机器人得逞，还有人类什么事情了，额，不对，如果点赞收益都被机器人抢去，那么对于其它内容发现者不公平呀。所以，这又有一个新的概念，叫“早鸟惩罚”。

所谓的早鸟惩罚，就是在30分钟以内点赞的，点赞收益按时间递减以线性比例分给作者。比如0分钟，100%都给作者，10分钟66.66%给作者，20分钟33.33%，30分钟则不用给分成了。

思考的机器人

监护奖励是越早越多，抢在别人前边（尤其是大户前边）最好了，但是早鸟惩罚又导致太早点赞要将奖励分配给作者。那么如何权衡这两点是机器人们要思考的问题（机器人会思考吗？）

监护奖励的机制和早鸟惩罚的措施，使得点赞收益具有了无限可能性，也就是说没有啥简单的策略让收益最大化。

但是有一点可以确定，30分钟之后，没有了早鸟惩罚机制，那么点赞就是越早越好喽，这肯定是没悬念的。所以很多机器人会扎堆在30分钟点赞。

但是考虑到很多机器人扎堆在30分钟点赞，如果早一些会得到后来点赞机器人的抬轿，所以呢，机器人们开始将这个时间前移再前移。所以就造成了30分钟以内集中点赞的现象。

如何操作

至此，为什么点赞大多集中在30分钟的问题，大致说清楚了。其实HF19之后，机器人们已经变成的更加聪明了，30分钟这个问题，变得越来越不明显了。

不管这些，你可能更关注，自己应该如何操作？这其实可以分成两个方面，是想利益最大化，还是发现好文章以及交朋友？

如果想点赞利益最大化呢，那么就去研究代码，分析各种策略，使用点赞机器人服务或者自己写程序点赞。后者则非常简单，看到好文章就去点赞，不计较得失。

有句古话叫做： 有心栽花花不开，无心插柳柳成荫，如何选择，见仁见智吧，本文不构成任何操作建议。

另外，硬叉20之后有些规则要改变，本文不做探讨了，详情可以参考文末链接。

(图源 ：pixabay)

相关链接

• 聊聊点赞机器人的点赞策略 /The Policies of Curation Bots
• 非正式翻译：硬叉20 “速度”开发进展 / Informal translation：Hardfork 20 (“Velocity”) development update

This page is synchronized from the post: O哥闲扯淡： 30分钟是个神奇的时间

在文章《O哥闲扯淡： 转发才是真爱粉吗？》中，我提到我以前对转发进行了一些研究，比如说做了一个丑陋无比的检查谁转发了你的文章的网页工具以及测试了如何使用SteemConnect转发7天以上的文章。

（图源：bing.com）

当时写这篇O哥闲扯淡的时候，我突然就想，我怎么没测试一下使用steem-python来测试转发功能呢？回头一定要补上，今天终于抽出时间来把这个补上喽。

安装和导入私钥

安装

现在有两个版本的steem-python，分别是

• https://github.com/Netherdrake/steem-python
• https://github.com/steemit/steem-python

我个人推荐使用 Netherdrake (@furion)的版本，或者官网的早期版本，官网的新版本加了很多功能，但是同样也使得这个库变得复杂和臃肿。

选择你要使用的版本，安装见对应github链接的安装说明即可。

导入私钥

在STEEMIT上，进入Wallet->Permissions->Show private key获取你的POSTING 私钥。

在命令行使用
steempy addkey
按提示导入私钥即可，如果是首次创建钱包，会提示你为钱包设置密码。

使用steempy转发文章

安装完steem-python库以后，就可以使用steempy命令行工具了。

比如使用：steempy --help 查看帮助
或者使用：steempy resteem --help查询关于转发的详细帮助

有了这些准备后，我们就可以用它来转发文章了，比如转发《O哥闲扯淡： 转发才是真爱粉吗？》到oflyhigh.test账户下：

指令： steempy resteem --account oflyhigh.test @oflyhigh/o

按提示输入钱包密码后提示如下，说明操作成功了。

我们可以用同样的方式转发8个月以前的文章
steempy resteem --account oflyhigh.test @oflyhigh/19-informal-translation-hf19-equality-coming-soon-linear-rewards

进入 @oflyhigh.test 的主页，可以看到两篇转发的文章

使用 python 脚本转发

除了使用命令行，使用python脚本来操作也一样简单。
比如我要转发这篇《那年夏天》，那么最简单的脚本示例如下：

1
2
3
4
5
6
7

from steem import Steem

identifier = '@oflyhigh/341nku'
account = 'oflyhigh.test'

steem = Steem()
steem.commit.resteem(identifier, account)

脚本执行成功后，再访问我们的 @oflyhigh.test 的主页

耶，成功了！

结论

无论使用steempy还是python脚本转发文章都非常简单，重要的是，我们可以转发7天以前(任意时间)的文章，而不像在steemit上，我们要受到只能7天以内文章的限制。

尽管如下，我依然建议大家读读《O哥闲扯淡： 转发才是真爱粉吗？》，慎重的转发有价值的内容，而不要见啥转啥。

关联阅读

• O哥闲扯淡： 转发才是真爱粉吗？
• Who resteemed/rebloged your posts? / 谁转发了你的文章？
• 📌 How to reblog/resteem articles which posted 7 days ago with SteemConnect? / 使用SteemConnect转发7天以上的文章

This page is synchronized from the post: 使用steempy / steem-python 转发7天以前的帖子