瞎想:基于STEEM的用户验证机制

我们注册各种服务,使用各种软件时,经常要验证个人身份,比如说注册网站之类的使用邮件里的链接激活,注册Telegram啥的用短信内的验证码登陆(突然发现,STEEMIT把这两种机制都用了呢)。当然了,更复杂的涉及金钱的,比如一些网站绑定信用卡银行卡时或发起一笔操作,然后要求用户提供对应交易的备注码,这样即验证了卡状态是否正常,也验证了用户是否有卡的操作权限。


(图源 :pixabay)

我突然想,STEEM发展到一定程度之后,我们在STEEM的账户经营一段时间以后,这个账户无疑相当于我们在网上的身份,那么注册各种服务需要验证身份时,STEEM是不是也可以作为邮件、短信、银行卡之外的另一种身份验证机制呢?

想了想,这个不但可以,甚至比其它方式更加适合作为身份验证机制呢。我觉得可以从以下几点考虑:

  • STEEM上数据稳定响应迅速
  • STEEM上可以查询到用户的各种信息
  • 转账+MEMO机制提供技术实现的便利

由于网络或者邮件服务器不稳定或者误触发垃圾邮件防范机制,我们注册了网站或者服务,但是收不到激活邮件的事情时有发生。等了半天等不到激活邮件,重试无效后,就只能换信箱了,换来换去,劳心费力还不一定搞得定。短消息现在倒是稳定多了,但是偶尔注册国外的服务也有收不到验证码的时候。如果用STEEM呢?这些都将不是问题,STEEM 每三秒出一个块,数据上链,无论是数据可靠性和响应速度都堪称一流。

验证用户身份的目的何在呢?很多时候是防止用户滥用服务。比如现在流行一个词汇在薅羊毛,大致意思就是用户注册很多账户骗取系统的奖励等等。传统的邮件、短信等验证方式,都无法避免这个问题,因为邮件可以随便注册,短信可以找第三方平台。

那么如果使用STEEM做为用户验证机制会如何呢?因为STEEM所有数据公开可查,我们可以按任意规则来验证用户或者给用户分级。比如声望分高、账户持有SP多、注册时间长、活跃度高的,可以适当调高评级,反之声望分为负的、账户SP近乎0的、刚注册没两天的、从不活跃的,可以适当降低评分。然后我们再根据评分来给与用户不同的权限,这样可以有效避免薅羊毛等行为。


(图源 :pixabay)

从实现角度来讲,STEEM的转账以及加密MEMO功能,为实现提供了极大的便利,只需简单的代码就可以完成STEEM用户验证功能的集成。

举例来讲,比如说用户注册时输入STEEM账户然后要求用户转入0.001到指定账户,收到来自对应STEEM账户的转账,就意味着验证成功。

我们还可以换种方式,首先转给用户0.001并在加密MEMO中添加一个随机码,用户登陆STEEMIT获得转账中备注的随机码,然后在网站/程序中填写对应的随机码,即为验证成功。当然了,具体细节可能还需推敲。


(图源 :pixabay)

其实STEEM还可以有好多好玩的应用。当然了,如有STEEM用户越来越多,STEEM的发展越来越好,那么相应的玩法,也会更加具有实用性以及更加好玩啦。


This page is synchronized from the post: 瞎想:基于STEEM的用户验证机制

郢人 / Bosom friend

无聊翻看自己的QQ说说,竟然发现了很多好玩的内容,然后发现2010年11月19日我竟然在QQ说说里发了一段古文。我冥思苦想,也没能想起来8年前我受过什么刺激,否则为啥发牢骚呢?当然或许受得刺激太严重,大脑自我保护,封存了那段记忆。


(图源 :pixabay)

古文的内容如下:

庄子送葬,过惠子之墓,顾谓从者曰:“郢人垩漫其鼻端若蝇翼,使匠石斫之。匠石运斤成风听而斫之,尽垩而鼻不伤,郢人立不失容。宋元君闻之,召匠石曰:‘尝试为寡人为之。’匠石曰:‘臣则尝能斫之。虽然,臣之质死久矣!’自夫子之死也,吾无以为质矣,吾无与言之矣!”

尽管我忘记了因何而发,但是再次读起来竟然莫名的感伤——原来早在8年前,我就已经学会了无病呻吟。😭 不过讲真,这段古文我真的好喜欢。

这段古文讲了什么故事呢?其实这段古文讲的故事是庄子讲了一个故事的故事。大致翻译如下:

庄子送葬,路过惠子的坟墓,回头对随行的人员说:“有个楚国人在鼻尖上抹了一层薄如蝇翼的白垩泥,让石(人名)这个匠人将其削掉。石挥动锛子咔嚓一下就砍了过来,这个楚国人眼都不眨让他砍,鼻尖上的白垩泥砍得干干净净并且一点没有伤到鼻子,而这个楚国人站在那面不改色。宋元君(宋国国君)听到这个事,召见石,说:‘来给我表演一下。’石回答:‘我曾经能削掉鼻尖上的白垩泥,(即使这样)但是我的搭档已经死了好久了。’”。然后庄子又接着说:“自从惠子死后,我就没有什么人能可以做搭档了,我就没有什么人能用来辩论啦。”


(图源 :pixabay)

有没有觉得有点似曾相识的感觉,没错,有点像伯牙钟子期《列子·汤问》中记载:伯牙善奏、钟子期善听。《吕氏春秋》中更是写到:“钟子期死,伯牙破琴绝弦,终身不复鼓琴,以为世无足复为鼓琴者。”后人在此基础上,演绎出《俞伯牙摔琴谢知音》的故事。

岳飞曾在《小重山》中感慨:“欲将心事付瑶琴。知音少,弦断有谁听。” 大概也是受了伯牙钟子期故事的影响吧。


(图源 :pixabay)

呜呼哀哉,庄子和惠子的故事好感人,伯牙和钟子期的故事好好感人,郢人和匠石的故事好感人,不过这些又和我有什么关系呢?我还是看我的QQ说说吧,比如读到这段故事:

一天晚上,某程序员正在写代码,一美工同事急匆匆跑过来说:不好了,PM被绑架了,劫匪要10W赎人,不然就要用汽油烧他,现在正在募捐呢,要不咱们也捐点?程序员:好!大伙一般都捐多少?同事:看情况吧,有的捐5升,有的捐10升……

是不是也好感人呢?😭


This page is synchronized from the post: 郢人 / Bosom friend

O哥闲扯淡:买赞真的稳赚不赔吗?

微信上一个好友问我:“O哥,买赞真的是稳赚不赔吗?那是不是意味着我们可以猛劲买赞了?”。“额,何出此言,关于买赞,我不是写过好多文章吗?怎么会认为稳赚不赔呢?天底下哪有稳赚不赔的好事?” “可是我看坛子哥说稳赚啊?”

我找了一下,果然看到 @tumutanzi 的文章《让我们来认真地研究一下Steem买赞这件事》,文中通过一系列的计算,最后得出结论:

买赞大概率上不会亏,收益率有保障

文章底下也有一些朋友(@ericet, @fr3eze, @tvb, @yellowbird 等)回复表示了不同的看法,但 @tumutanzi 坚定地认为自己的结论有数据支撑,并没有算错。


(图源 :pixabay)

那么买赞真的稳赚不赔吗?听我细细扯来吧!

提示:O哥闲扯淡系列本就是闲扯淡,诸位千万别当真!

买赞时收益

其实关于买赞的文章,我也写过好多,但是文章中涉及的方方面面太多了,所以对于读者而言没法直观的得出一个结论,比如说到底是赚钱还是赔钱?这篇文章中,我们屏蔽其它乱七八糟的因素,光来数钱好了。

买赞后文章显示价格的增加是很直观的,比如投入10SBD,文章被买赞机器人点赞后,显示的金额增加了21 SBD,乍一看,白赚了11SBD。实际这个增加的金额只是个数字,做不得真。那么买赞被点赞后,大致增加了多少钱呢?可以用公众号估算一下:


注意第二个红色方框,这个指的是,按照当前喂价,帖子显示金额100SBD,去除点赞者奖励之后按照50%/50%规则发放奖励,实际奖励的价值折算成SBD的价格。

对点赞增加的金额也是如此,点赞多出21SBD,那么实际我们得到的约为:`2153.055% = 11.14 SBD`*,计算一下收益率高达11.4%,美死了。

不过,别高兴得太早,这只是按买赞时的状况计算的收益情况,那么7天后实际计算后会是什么情况呢?

结算后的收益

如果我们买赞的收益马上到账,那么按上述计算,似乎真的稳赚不赔,可是很多事情并不如我们所愿,帖子要7天以后结算,我们的买赞收益也要7天以后到账。有句话叫做夜长梦多,用在这似乎挺有意思的,到底7天后醒来是美梦还是噩梦呢?

要了解这个,我们需要了解帖子收益是怎么计算出来的。这个是个很复杂的事情,详情可以见我以前的帖子:《也论币价与帖子收益》,我们拿其中的结论直接用:

帖子显示的价格 = 帖子应得STEEM * 喂价

再来看这个图:

注意第一个方框,这个就是按照当前喂价,帖子显示金额100SBD,去除点赞者奖励之后,Power UP 100%帖子的应得STEEM POWER,也就是帖子内部用于核算的应得STEEM

这个STEEM会不会变呢?严格来讲,不变的是文章的net_rshares,根据奖励池的情况,文章的STEEM会时不时的变化,但是为了便于说明问题,我们假定它的变化对我们没有影响,假定它不变吧。

OK,文章的STEEM不变,那么影响文章收益的主要因素就变成了喂价。我们文章被点赞之后,喂价的变化,影响我们文章收益的变化。

来一个直观的例子,极端的例子,假设7天后喂价,变成了1.00,那么这个现在显示100 SBD的帖子,7天结算后收益是多少呢?计算起来很简单,我们将得价值 24.209 SBD的资产(一半SP,一半SBD)

那么再来算算买赞时给文章增加的 21SBD,最终我们收入是多少?答案是: `2124.209% = 5.08389 SBD`*。也就是说今天你投入10 SBD买赞,如果7天后喂价变成1.0,你的实际所得约为5SBD,亏损高达50%。

尽管这个例子很极端,但是谁敢说稳赚不赔?


(图源 :pixabay)

实际情况

因为喂价是在不断变化的,7天后是增加还是降低,一般来讲我们不好预测,所以买赞是赚是赔,这个也不好说。但是可以肯定的是:稳赚不赔肯定是不可能的

当然了,实际上还有很多因素,比如说为了推广帖子,比如说为了升级声望分,比如说为了人气,等等等等,实际是否要买赞,就见仁见智了。

参考链接


This page is synchronized from the post: O哥闲扯淡:买赞真的稳赚不赔吗?

十年生死两茫茫: 5·12汶川地震

十多年前,我给一家成都安全产品公司做网络维护以及一些后台程序开发,当然了也是在网上工作。因为涉及到主机、网站、在线支付处理、在线生成注册码以及客户管理等工作都和我有关,所以我时常和公司另外一个负责相关业务的女孩联系,久而久之成了好友。


(图源 :pixabay)

然后十年前的某一天,好友请假回老家给外婆庆祝生日。之后发生了震惊全世界的5·12汶川地震,我这个好友也变得音信皆无,gtalk联系不上、QQ也不上线、手机也打不通。全公司上下都尽各种可能疯狂的联系她,希望这个温柔善良的女孩没事。然而四五天后,我们都几乎不抱期望了,数据报道显示:5·12汶川地震,69227人遇难,374643人受伤,17923人失踪

大概6、7天后,她竟然奇迹般地上线了,和我们说地震发生时她正在灾区,幸运的是,没有牺牲也没有受伤,但是因为交通和通信完全中断,她虽然着急,但是也无法联系我们报平安。朋友安然无恙,这是个好消息,但是有几近10W的生命,再也回不来了,这又让人无法开心起来。

这10W人当中,有别人的父母、有别人的孩子、有别人的亲人、有别人的恋人、有别人的朋友…… 曾经以为自己失去朋友而伤心不已,那么那么失去父母、孩子、亲人、恋人、朋友的人,又该如何伤痛?

我印象最深的一幕,一个在压在废墟下的青年,一直苦苦支撑,等待了近70小时以后,终于等来了救援人员。在被救援的间隙,他还和救援人员聊天:

“我不想我的小孩生下来就没有父亲。”

“我三天三夜没吃过一颗粮食,只喝了点水。但是我觉得我命还大,大难不死,必有后福。”

“说实话,头天晚上我真的差点坚持不过去了,我很想放弃自己的生命,但是我回头又想一下,我不能失去他们。我确实不想放弃我家里的任何一个人,所以说我要坚强。”

“我必须要坚强,为了每一个深爱我的人,一定要顽顽强强地活下去。”陈坚一直没有停止他的说话,他坚强得令人心痛。

“我的老婆叫谭小凤,我家是桑州的人。这辈子我没抱太大希望,只想我们两个和和睦睦地过一辈子就行了。”

电视中直播了救援全程,然而当他被解救出来以后,却再也没能回应救援人员的任何呼唤,与世长辞了。看到这里,我忍不住痛哭出声。


除了坚强乐观的陈坚,还有那用自己孱弱身躯护着孩子的母亲。各种感人的场景不能忘怀,不敢忘怀。

而今,十年已过,在他人那,或许5.12只是一串数字、一个日期,或许汶川地震只是网络上、百科里的一条词汇,用陶渊明的《挽歌》中的一段形容是很恰当的:

亲戚或馀悲,他人亦已歌。
死去何所道,托体同山阿。

然而对于那些地震中丧失了父母、孩子、亲人、恋人、朋友的人,那伤痛,又岂是时间所能抚平的呢?或许苏轼的《江城子·乙卯正月二十日夜记梦》能道出这部分人的心声吧:

十年生死两茫茫,不思量,自难忘。
千里孤坟,无处话凄凉。
纵使相逢应不识,尘满面,鬓如霜。

夜来幽梦忽还乡,小轩窗,正梳妆。
相顾无言,惟有泪千行。
料得年年肠断处,明月夜,短松冈。


(图源 :pixabay)

十年过去,弹指一挥间,痛定思痛,痛何如哉!然而除了写下这一篇不算悼文的文章,我们除了祈祷又能做些什么呢? 或许这种无力感,才是最让人伤痛的吧。


This page is synchronized from the post: 十年生死两茫茫: 5·12汶川地震

每天进步一点点:MFC中向Access 数据库插入数据

在之前的一个帖子中,学习了如何在MFC中使用Access数据库。好吧,尽管费了很大的周折,但是最终我在程序中连接到Access文件上,并且可以用SQL语句查询数据。如果单纯来读数据,貌似也可以继续完成程序的其它部分了。


(图源 :pixabay)

CDatabase::ExecuteSQL

然而,除了读数据,我还要写入数据啊。原本以为插入数据和查询数据一样,直接用CRecordset传入SQL就可以。调查一下之后发现,尽管使用CRecordset也可以写入数据,但是用的完全是一套不同的机制,就是说我没法利用CRecordset在程序中使用INSERT、UPDATA等SQL语句,看了一下帮助,里边关于lpszSQL的说明,彻底摧毁了我的幻想:

在我决定彻底弃坑之前,我决定再进一步调查一下,看看有没有什么办法,不然吐过这么多血,就这么放弃了,有点郁闷。最后我发现原来可以用CDatabase实例直接执行SQL。😳

其中部分说明如下:

Create the command as a null-terminated string. ExecuteSQL does not return data records. If you want to operate on records, use a recordset object instead.

Most of your commands for a data source are issued through recordset objects, which support commands for selecting data, inserting new records, deleting records, and editing records. However, not all ODBC functionality is directly supported by the database classes, so you may at times need to make a direct SQL call with ExecuteSQL.

ExecuteSQL 示例代码

文档中还给出了一段C++ 示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
try
{
m_dbCust.ExecuteSQL(
_T("UPDATE Taxes ")
_T("SET Rate = '36' ")
_T("WHERE Name = 'Federal'"));
}
catch(CDBException* pe)
{
// The error code is in pe->m_nRetCode
pe->ReportError();
pe->Delete();
}

ExecuteSQL 测试

接下来要在程序中测试一下喽。


首先随便创建个表:Table1,添加一个文本字段:Field1。(不要像我这样懒惰,我就是随便测试啦)

然后在我的程序中加入下列代码:

1
2
3
4
5
6
7
8
9
10
11
12
CString Sql_Templete = TEXT("insert into %s(%s) Values('data_%d')");
CString sql;
try {
for (int i = 0; i < 10000; i++) {
sql.Format(Sql_Templete, TEXT("Table1"), TEXT("Field"), i);
m_db.ExecuteSQL(sql);
}
}
catch (CDBException * e) {
e->ReportError();
e->Delete();
}

执行程序,然后用Access打开数据库,我们可以看到对应的表的对应字段,已经成功的插入了10000条数据。


(自增长ID的序号从1开始)

总结

尽管用MFC和Access 坑挺多,但是目前看来还是可以实现我的需求的。基本上无外乎两点:

  • 读数据用CRecordset执行查询语句
  • 插入/更新/删除使用CDatabase::ExecuteSQL

嗯,这样一来,我就不用跟那些乱七八糟的函数打交道了。不过我还是有点小纠结,要不要换成SQLite3呢?哎,让我先冷静一会吧。

参考链接


This page is synchronized from the post: 每天进步一点点:MFC中向Access 数据库插入数据

为者常成,行者常至

今天有朋友在我一个帖子底下回复让我介绍一下: Steem Messenger.


(图源 :pixabay)

Steem Messenger.

说到这个Steem Messenger,8天之前有个热门帖子:《Introducing: Steem Messenger (Beta) 》,作者是:@therealwolf,这个帖子宣布了Steem Messenger的诞生。它的机制就是使用STEEM区块链的转账MEMO功能来实现聊天。

我大致看了一下,功能很强大, 界面很美观。但是对于这类第三方的应用我总是很谨慎的,因为聊天是基于转账MEMO,所以免不了要提供并保存Active Key,来对转账操作进行签名。当然了,保存可能保存在本地,但是无论怎样,我还是没去测试。没有测试就没有发言权,所以对于这个应用是否安全,我不做过多评价。

我想说的是,10个月以前,我曾经构想过一个类似的项目,详情可以参考《YY 一个基于STEEM区块链的聊天工具》,并做出如下结论:

  • 通过STEEM转账功能实现聊天工具(IM)应该是可行的
  • 可以利用MEMO加密功能来实现消息加密
  • 可以通过转账金额限制来实现防骚扰等高级功能
  • 可以方便的移植到BTS或者EOS上

我还在帖子中构想了:

必须要有桌面端和移动端APP,网页版的也要开发,这样才显得高端大气上档次,低调奢华有内涵!

然而十个月过去了,我的基于STEEM区块链的聊天工具并没有写出哪怕一行代码,而别人,却已经做出了完善的产品。


(图源 :pixabay)

为者常成,行者常至

不由得想起一个成语:为者常成,行者常至,出处如下:

梁丘据谓晏子曰:“吾至死不及夫子矣!”晏子曰:“婴闻之,为者常成,行者常至。婴非有异于人也。常为而不置,常行而不休者,故难及也?”
——《晏子春秋》

大意是:梁丘据对晏子(晏婴)说:“我倒死也赶不上你啊!” 晏子回答:“我听说,努力去做事,就常常能成功;努力去赶路,就常常能到达。我和别人也没啥两样啦,总是努力不中断,总是前行不停止,还有啥干不成的呢?”

话说人家夸你,晏子你就不能谦虚一下啊。这段话,再简化一下就是:人家夸晏子:你真了不起。晏子说:其实也没啥,我就是比别人更努力一些了吧。

晏子谦虚与否我们不去八卦了,但是为者常成,行者常至,真是真理假不得。这就是实干家与空想家的区别,而最终取得成功的往往都是实干家,空想家只能空悲切了,就比如说我。😭


(图源 :网络图片)


This page is synchronized from the post: 为者常成,行者常至

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×