QQ 号被腾讯打劫走

前些天，我珍藏十数年的几个7位8位QQ号，被腾讯统统冻结了。
说神马发送非法信息，丫的找个借口都不优雅，你就直接说抢劫，简单粗暴，多好。

我合计冻结总归可以解冻吧，然而答案是： NO
又要填写历史密码，又要好友验证的
问题是我历史密码就一个呀，至于好友，我这些QQ里边还没有好友呢。
总之，就是我这组价值连城的7位8位号，就这么被腾讯抢走了
估计过一段时间，就会被包装成靓号出售吧

总之，在腾讯这样的强权帝国里，你的东西属不属于你，腾讯说了算!

基于区块链的聊天工具

对腾讯的行为我虽愤慨，但是无能为力！

然后我就想，有没有一种聊天工具，属于你的就是属于你的，谁也抢不走呢？除非你主动把它送给别人。

但是，但凡是中心化的聊天工具，总有这样的弊端，毕竟人家的地盘，你做不了主。
那么是不是也可以考虑去中心化呢？把聊天工具挪到区块链上来，似乎是个不错的想法呢 😀

可是神马乱七八糟的区块链的东西我都不熟悉啊，就知道STEEM和比特币、BTS、ETH、EOS
除了STEEM，后边几个也基本上处于仅仅知道的尴尬境地

那有没有可能弄一个基于STEEM区块链的聊天工具呢？

基于STEEM区块链的聊天工具

好，咱继续YY发挥想象力。

1) 利用发帖

说到STEEM，我们常做的行为就是发帖、回帖、点赞、转账等等
如果用发帖功能做聊天工具，呃，让我想想一下，打开STEEMIT首页，满屏幕都是

“你好”
“你好”
“你今天吃饭了吗？”
“吃了”
“你呢？”
“我也吃了”
…….

一句话一个帖子，画面太美，我不敢继续想象了

2) 利用回帖

既然利用发帖做聊天工具实施起来有些那啥（那啥是啥？），那么利用回帖呢？

然后，假设聊点敏感话题

今天我们去哪开房？
阳光宾馆215室？

完蛋了，大家都能看到，曝光了吧！

还有，回帖限制是20秒一个，这聊的也不痛快啊。

3) 利用转账

既然用发帖、回帖做聊天工具都不现实，那么还有啥办法？用点赞？用差评？别逗了，点赞咋传递文本信息啊？莫非把点赞百分比编码，比如1%代表A，2%代表B，那发送个”I love you”得点多少下啊，况且也没那么多帖子点啊。

想来想去，最靠谱的就是转账功能呢
重要的是，转账功能自带MEMO，我们可以在MEMO里传递信息啊
更重要的是，转账MEMO带加密功能，去宾馆开房再也不怕别人看到啦

基于STEEM 转账功能的聊天工具

好了，我们越来越能YY了，我们的思路越来越清晰了。

既然明确了可以用转帐功能实现聊天工具，那具体咋做呢？如果说登陆steemit 转账，那还用你说嘛？所以我们必须进一步YY

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

程序监控指定格式转账信息

要接到别人发来的聊天信息，我们必须监控到我们账户的转账信息。
当然为了和其它转账信息区别开来，我们可以加上特定的格式，举例说，以chat:开头

我们在程序中监控转账信息，并取得memo，当然了，如果是加密的就先解密好了
发现以chat:开头，哇， 有人找我聊天了耶，是要请我吃饭还是要开房？快显示出来看看
然后程序在窗口里显示出来聊天内容，哇，原来是讨债的，假装没看到好了

程序支持发起转账

既然是聊天工具，当然要能收能发，通过监控功能，我们已经能实现接收信息
那么收到了信息必须要回复啊（讨债的除外），否则多么不礼貌。

所以程序也要支持给别人转账
在输入框中 @你要传送消息的人，并附上文本内容即可
程序自动发起一条转账信息，并将文本内容替换成 chat: 文本内容附加在memo里
当然，你也可以设置成自动加密

程序支持高级功能

好了，YY到这里，分析到这里，我们已经有了个基于STEEM区块链的聊天工具。
但是这貌似功能挺低端啊

别急这只是基本功能嘛，在这个基础上，我们可以做好些事情呢？
我要开始放大招了，真的是放大招了，不骗你，大招来了

最最高级的功能，是我们可以通过设置金额门槛来实施消息过滤
啥意思？就是说，我设置5STEEM门槛，你转账1STEEM过来的聊天信息我统统忽略。

有啥意义？这你还不懂嘛？防骚扰利器啊！！！
想和我聊天，嗯哼，拿钱来！
5毛钱你是埋汰我，10块钱聊两条，陪聊明码实价喽
突然觉得我好庸俗……

好了，不谈钱，伤感情！
人家QQ啥的那么多表情啥的，你这个聊天工具干巴巴的，多没意思！
表情其实是很简单的啊，实现起来So easy啊，只要加个表情库，然后给个编码，比如大圆笑脸就是 /:ka，这不是很简单的事情嘛，各种表情包也是一个道理。

至于发照片，传文件也都可以，发个URL嘛，实际内容可以偷摸上传到steemit的图片服务器上去。

语音，视频这些都可以有
只是咋实现我就不懂啦。

面临的问题

唯一可能是障碍的就是现在STEEM是3秒中一个块
这样文本聊天达不到实时的要求，不过貌似不算啥大问题了
多给你一点时间思考，以免发出去不经过大脑过滤的内容

另外EOS上这个时间是不是变短了呢？
咱们这个聊天工具可以直接迁移到EOS上嘛

结论

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

哇，太完美了，你们谁去写个白皮书，ICO吧
记得若是发家了，分我一些啊

后记

写完之后，搜索了一下，居然发现一个叫ECHO的东西
简单了解一下，就是石墨烯加上IPFS，额，比我这个多了个IPFS

但是咱也不是没有优点啊，咱们的优点就是无需额外的弄什么ECHO了
有STEEM账户，有BTS账户，有EOS账户，就可以用我们的聊天工具
至于IPFS，加上呗(话说咋加?)

好了，大家都来用我们的聊天工具吧，炒鸡简单，炒鸡好用，炒鸡安全
你问我去那下载？
呃。好吧，我YY过头了……

This page is synchronized from the post: YY 一个基于STEEM区块链的聊天工具

在前一篇帖子中

• Python程序中使用集合计算简化问题处理
  我们聊到如何使用集合的差集功能筛查出用户组A中不属于用户组B的元素

并举了一个栗子：
找出用户组A中没有给帖子@oflyhigh/xxxx 投票的用户

你可能很惊讶，莫非O哥用技术手段排查不给他投票的用户，然后拉黑吗？
比如说台湾第一美女 @deanliu 老师就吓哭了

其实O哥没那么小气的啦

不过还真是用来查谁没投票的，至于用途嘛，暂且保密

然后恰逢 @jubi 小兄弟问到：

代码是看懂了，就是不知道这个list_user怎么得到 哈哈，我用上了我所有了编程知识了。:)
PS 我可是点赞了哟

就一并多说点。

获取帖子投票列表

获取帖子投票列表，我知道的至少有四种方法：
1) 使用SteemData
2) 使用官方Python库中的Post类
3) 使用API get_content
4) 使用API get_active_votes

当然其实还有JS, PHP, Ruby等各种库各种类，你可以选择你擅长的，我不懂的就不多说啦。

1. 使用SteemData

有关如何使用 SteemData
可以参考我以前的一些文章

• 简单介绍一下SteemData
• steemit 隐藏神技之: 富豪榜 / The rich list of steemit & How to get it from SteemData

使用SteemData 你可以有好多种方式来查询出投票列表
比如说从Posts中查询, 或者从Operations中查询，或者从AccountOperations中查询
比如我从Posts中查询Steemit上第一篇文章： Welcome to Steem!

部分投票如下：

是不是很好玩？
不过SteemData目前有个问题，就是数据延迟，说白了，不新鲜，这就尴尬了
人家给你投过了，你查出来没投，岂不是冤枉人了？
我在Github上反馈过这个问题，作者的答复是自建节点，值得期待啊

2. 使用官方Python库中的Post类

Post类其实是对API get_content的封装
用起来就不用太关心下边的东西啦
post = Post('@author/permlink')
这样就取到帖子啦

然后
post['active_votes']就是帖子的投票信息啦
以我之前一个测试的帖子为例, post['active_votes']部分如下：

1
2
3
4
5
6
7
8
9
10
11
12

'active_votes': [{'percent': 5000,
                  'reputation': '129952225494384',
                  'rshares': '736202067284',
                  'time': '2017-07-23T08:43:33',
                  'voter': 'oflyhigh',
                  'weight': 875336},
                 {'percent': 5000,
                  'reputation': 0,
                  'rshares': 407577814,
                  'time': '2017-07-23T08:43:33',
                  'voter': 'eval',
                  'weight': 194}],

3. 使用API get_content

之前我们说过，Post类其实是对API get_content的封装，所以两者其实是类似的
Post类经过封装更易使用
而get_content更直截了当

API定义如下：
discussion get_content( string author, string permlink )const;

4. 使用API get_active_votes

你可能会问既然，有了1， 2，3 种方法，为何还要第四种呢？是不是没啥写的在凑字数？😡
呃，不是这样的

如果你使用过第二、第三种方法，就会发现它们返回好多信息，比如文章内容、作者信用、奖励信息等等。这些信息在做复杂的判断时非常有用，但是如果就是为了找到投票信息，读回来一火车的数据，岂不是浪费？

浪费是可耻的行为，既增加系统负载又费电，所以我们要杜绝浪费。
所以 get_active_votes 就勇敢的站了出来。
这个API 很好理解，就是拿出对应帖子的投票信息。

API 定义如下：
vector<vote_state> get_active_votes( string author, string permlink )const;

代码示例

超简单的哦

1
2
3
4
5
6
7
8
9
10

from steem import Steem
steem = Steem()

active_votes = steem.get_active_votes('oflyhigh', '4j3232-python')
list_voter = [vote['voter'] for vote in active_votes]
print(list_voter)

list_user = ['oflyhigh', 'laodr', 'deanliu', 'ace108', 'rivalhw', 'lemoojiang']
list_x = list(set(list_user) - set(list_voter))
print(list_x)

咳咳咳，后边三段代码是我不小心加上去的。我胸怀宽广，不会记仇的😕

This page is synchronized from the post: 获取帖子的投票用户列表(Voter list)

集合的运算

集合的概念你还记得的吗？
记得以前自学《普通逻辑》的时候研究的很明白，现在还能找到以前的笔记呢； 之后又自学《离散数学》对集合的各种操作了如指掌。然而时隔多年，除了一些非常非常基本的概念，基本都忘干净啦。先一起复习一下，为了搞明白，我可是20年前的古书都翻了出来。

集合的常见运算：

• 交(Intersection): A∩B={x|x∈A 且x∈B}
• 并(Union): A∪B={x|x∈A 或x∈B}
• 补(Supplement): A-B={x|x∈A 且x∉B}

其中补集又可以叫做差集，又分为相对补集和绝对补集，但是不影响我们要讨论的事情，所以不去详谈，感兴趣的可以自行去了解。

用在何处

既然我之前都说忘干净了，还翻出来干啥啊？集合有啥用呢？

引用百度百科集合条目中的一段话；

集合在数学领域具有无可比拟的特殊重要性。集合论的基础是由德国数学家康托尔在19世纪70年代奠定的，经过一大批卓越的科学家半个世纪的努力，到20世纪20年代已确立了其在现代数学理论体系中的基础地位，可以说，现代数学各个分支的几乎所有成果都构筑在严格的集合理论上。

额，好吧，我都看晕了，我又不研究数学，其实是和STEEMIT相关啦。

假设我有一些用户账户 A, B, C, D, E,F
那么我可以把他们看作一个集合 USERS
即： USERS = {A, B, C, D, E,F}
(数学表示，非代码)

然后，一个帖子， @oflyhigh/test_1_2_3
用户A、B、C、H、I、J，给我的这个帖子点赞，那么这些点赞者，我可以看作一个集合 VOTERS
即： VOTERS = {A, B, C, H, I, J}
(数学表示，非代码)

那么问题来，我想知道USERS中谁没给我点赞，该怎么办呢？
之前的处理方法，是使用两个列表，一个list_user, 一个list_voter
然后循环list_user中的元素，判断是否在list_voter中

先不说效率啥的，我感觉不优雅。不过好在能用。
于是我就想能不能换一种至少看起来优雅的方法呢？

仔细一想，这不就是差集嘛( B：USERS; A： VOTERS)

Python 对集合的支持

非常幸运的是，Python对集合运算提供了非常好的支持

来源： https://docs.python.org/2/library/sets.html#sets.Set

其中差集： new set with elements in s but not in t，即是我们想要的东东啦
操作比我们想象的还要简单

代码

好了，现在来一段具体的代码演示一下
假设我已经拿到了 @oflyhigh/test_1_2_3 这个帖子的投票者列表
那么就用这段代码找一下谁没给我投票吧，哼 😕

1
2
3
4

list_user = ['oflyhigh', 'deanliu', 'ace108', 'laodr', 'rivalhw', 'lemoojiang']
list_voter = ['oflyhigh', 'ace108', 'laodr']
list_x = list(set(list_user) - set(list_voter))
print(list_x)

(中间使用了set将列表转换成集合，你也可以直接用集合)

好啊， @deanliu, @rivalhw, @lemoojiang, 竟然不给我@oflyhigh/test_1_2_3 这个帖子投票
被我抓出来了吧 😕

结论

在Python 中使用集合的差集功能，可以很优雅的找出谁没给我投票 处理一些技术问题，咳咳，言多必失，言多必失，这篇文章就此打住了。

参考链接

• https://docs.python.org/2/library/sets.html#sets.Set
• https://docs.python.org/3.6/library/stdtypes.html#set-types-set-frozenset
• 百度百科： 集合
• 百度百科： 差集
• 百度百科： 补集
• 百度百科：相对补集

This page is synchronized from the post: Python程序中使用集合计算简化问题处理

Bandwidth Limit Exceeded

如果你从未听说过见证人，也不知道见证人在STEEMIT网络中起到什么作用，那么可以看一下我的这篇文章：

• 📌重点在文末/ 见证人简介，如何为见证人投票以及设置见证人投票代理

假设你已经对见证人有了一些了解，那么你可能会有疑问，见证人和猫有啥关系？
这要从之前几天频繁发送的一个错误说起, 那就是Bandwidth Limit Exceeded

对于这个错误，我曾经写过两篇分析文章：

• 从代码看 Bandwidth 超限问题 & 如何避免和解决
• Steemd.com 改版了 & 被 Bandwidth Limit Exceeded 折磨的朋友有福了

第一篇文章所立的层次不够高远，完全从用户的角度分析，因为我觉得，系统相关的信息我们改变不了，我们改变的只能是我们自己。于是得出的结论是： 增加vshares占比 (买买买), 或 减小你的平均带宽占用(等、减)。先不说第二种方式减少操作次数，减少文本长度等带来的诸多不爽，方式一岂不是让STEEM变成一个金钱至上的网络了? (难道不是吗? 😲)

第二篇文章中，我才知道原来Bandwidth Limit Exceeded是由一个BUG所引起，这个BUG叫做溢出(Overflow)，这个BUG导致max_virtual_bandwidth 变得非常之少，进而导致用户正常操作受限。

如何处理BUG

那么既然有BUG了，我们修复了BUG，再升级到新版，就好了呗？
事情并非那么简单。

以我N年码农的经验，我是没少干过修复旧BUG引进新BUG的事情，尤其是对一个复杂的系统而言。有个词汇叫做牵一发而动全身，如果贸然升级就可能陷入修复BUG->升级->产生新BUG->修复BUG->升级->产生新BUG的怪圈。

@gtg 今天更新的 Witness log
其中有一句话很有意思： We’ve got trouble, we’ve made it double

他的文章中，提及了当Bandwidth Limit Exceeded 问题发生，见证人之一提出了将maximum_block_size修改为: 131072， 达到提升max_virtual_bandwidth 目的：

dgp.max_virtual_bandwidth = (dgp.maximum_block_size dgp.current_reserve_ratio STEEMIT_BANDWIDTH_PRECISION * STEEMIT_BANDWIDTH_AVERAGE_WINDOW_SECONDS) / STEEMIT_BLOCK_INTERVAL;

从上边公式来看，貌似没有问题。
然而，大家响应号召并修改maximum_block_size后，发现问题依然(或者变得更加严重)

然后，发现是溢出问题，大家又纷纷把maximum_block_size改回为: 65,536

那么如果使用官方释出的新代码升级呢? 这当然是方案之一，但是若有新BUG引入，就没来回改maximum_block_size参数这么简单了。

猫咪战队也参战

说了这么多，你可能会问，这和猫咪有啥关系呢？是呢，怎么看也和猫咪产生不了关联。

事实上是见证人之一@abit 提出并实施了一种非常有意思的方案，即解决(避免)了Overflow 的问题，又无需急于升级节点，岂不是美哉？

这个方案的思路就是通过在溢出即将发生的时候，往steem上发送一些超长内容，拉高average_block_size。而在0.19.0及以前版本中，average_block_size 的变化会作用到current_reserve_ratio，代码中说明如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/**
 *  Average block size is updated every block to be:
 *
 *     average_block_size = (99 * average_block_size + new_block_size) / 100
 *
 *  This property is used to update the current_reserve_ratio to maintain approximately
 *  50% or less utilization of network capacity.
 */
int32_t    average_block_size = 0;

/**
 *   Any time average_block_size <= 50% maximum_block_size this value grows by 1 until it
 *   reaches STEEMIT_MAX_RESERVE_RATIO.  Any time average_block_size is greater than
 *   50% it falls by 1%.  Upward adjustments happen once per round, downward adjustments
 *   happen every block.
 */
int64_t current_reserve_ratio = 1;

所以超长内容，拉高average_block_size, 让其大于50% maximum_block_size 就会降低 current_reserve_ratio， 让其回归, 进而避免引起Overflow

说了这么多，🐱 猫在哪里呢？
其实就是 @abit 的超长回复里用了各种猫图。

比如说来自以下来源的：
http://www.ascii-art.de/ascii/c/cat.txt
https://github.com/melaniecebula/cat-ascii-faces
http://textart.io/art/tag/cat/1

比如这货(STEEMIT行高的问题，胖猫变高了，但依然很胖)：

       .                .                    
       :"-.          .-";                    
       |:`.`.__..__.'.';|                    
       || :-"      "-; ||                    
       :;              :;                    
       /  .==.    .==.  \                    
      :      _.--._      ;                   
      ; .--.' `--' `.--. :                   
     :   __;`      ':__   ;                  
     ;  '  '-._:;_.-'  '  :                  
     '.       `--'       .'                  
      ."-._          _.-".                   
    .'     ""------""     `.                 
   /`-                    -'\                
  /`-                      -'\               
 :`-   .'              `.   -';              
 ;    /                  \    :              
:    :                    ;    ;             
;    ;                    :    :             
':_:.'                    '.;_;'             
   :_                      _;                
   ; "-._                -" :`-.     _.._    
   :_          ()          _;   "--::__. `.  
    \"-                  -"/`._           :  
   .-"-.                 -"-.  ""--..____.'  
  /         .__  __.         \               
 : / ,       / "" \       . \ ; bug          
  "-:___..--"      "--..___;-"               

为什么用猫图

其实我也不清楚为何用猫图
或者是因为： “不管黑猫白猫，能抓住耗子 BUG 的就是好猫？”

总结

• Bandwidth Limit Exceeded 的问题困扰好多新老用户
• STEEMIT官方以及诸多见证人纷纷行动起来
• @abit 凭借对代码的深刻理解，用猫咪们避免了溢出(Overflow)问题

本来是很精彩的事情，写完后发现即没能展现出来精彩，也没能把相关的技术问题解释清楚，实在是能力有限。但我依然决定发出来，让大家了解在STEEM平稳运行的背后，见证人们所做的付出。 这就是见证人们，让我们一起向他们致敬吧!

Image source: 1

This page is synchronized from the post: “不管黑猫白猫，能抓住BUG的就是好猫”， 从Bandwidth Limit Exceeded说起

每天进步一点点

今天学习了

• 将多个操作(operation)放入一个事务中(transaction)

有朋友问，这有什么用处呢？
现在用处来了，比如给大家发奖.

STEEMIT UI 转账功能目前为止，尚不支持给多人转账，或者同时操作多笔转账。
只能一笔一笔的操作，要输入账户、金额、MEMO，以及ACTIVE KEY
如果涉及多人，极其繁琐，反复输密码还容易出错。

于是在我学会了将多个操作放入一个事务中
这些转账，一次搞定，SO EASY 有木有？之前的一二等奖转账，可是累的我吐血啊

所以，我要努力学习
现在是往出赚钱省心不少，啥时候进钱也极其省心，就爽了

中奖号码解密

然后，之前不是发个帖子嘛

• 💰💰(Reputation 70+, Followers 1000+, SP 10000+) 二： 烤箱没有，活动来了, 奖励为 （💰100个STEEM ）

其实主要是让大家热闹一下，顺便探索一下有没有形成一种抽奖机制的可能。

中奖号码其实是内定的
哈哈，别激动，我说的是中奖号码，不是中奖者

1
2
3
4
5
6

>>> hashlib.sha1(bytes('一等奖中奖密码:6', 'utf-8')).hexdigest()
'fcc420adc5de61752db7ecfa837564f45c47852b'
>>> hashlib.sha1(bytes('二等奖中奖密码:8', 'utf-8')).hexdigest()
'69bc4460aaab914869fa8209da3d06f1494ea62d'
>>> hashlib.sha1(bytes('三等奖中奖密码:1', 'utf-8')).hexdigest()
'0e756e1b5d7dc2bab3d86b3d490d3801b904f929'

获奖名单

一二等奖

恭喜 @ace108 获得一等奖
恭喜 @wilkinshui 以及 @thomaskikansha 两位朋友获得二等奖
奖金已经送上

三等奖

恭喜 @pakyeechan @wilkinshui (咦，How old are you? 怎么老是你??)
以及 @nationalpark @xiaoxijie 获得三等奖，奖金已经送上

三等奖还有4个名额没人要，我理解是大家准备留给我买西瓜解暑的，谢谢大家啦

特别奖

恭喜 @pakyeechan(咦，How old are you? 怎么老是你??) 以及 @deanliu
获得特别奖，奖金已经送上

关于特别奖

我相信三是虚指，比如说三人行，必有我师焉
所以三个机器人代表我们CN区大家庭，或者整个STEEMIT上的朋友，对吗？
你是希望大家都玩得很开心，谢谢你啦。

我被你编故事的能力深深地震撼了。

好啦，就这样啦，我要去努力学习啦。

This page is synchronized from the post: 每天进步一点点 (批量操作) & 派奖公告

操作、事务、区块 以及区块链

先来简单介绍一下操作、事务以及区块

• 操作(operation)： 你在steemit上的每一项活动，发帖、回复、点赞、转账等都是操作
• 事务(transaction): 事务中包含一个或者几个操作(可能是不同人不同种类操作)
• 区块(block): 每个区块中可能包含一组(0组)或者N组事务
• 区块链(blockchain): 一系列不断增加（3秒每个)的区块，就构成了STEEM区块链。

亦即：
区块链由区块组成、区块中包含事务，事务中包含操作，操作是我们在STEEM上活动的基本单位。

STEEMIT 一个事务中两个操作的例子

Image source

以发帖为例，我们发表帖子，可以选择发帖的同时投票，也可以选择不投票。

如果勾选了箭头所示的单选框，就会在发帖的同时给帖子投票。

发帖、投票是两个独立的操作，
发帖的同时给帖子投票就是把两个操作放到一个事务中

以我的帖子为例，发帖和投票在一个事务中有相同的transaction_id

如果我们在steemd上打开这个transaction就会看到里边有两项操作，发帖和投票。

Python 库处理发帖并投票的实现

Steemit Python 库也支持发帖的同时投票。
如果设置了对应参数，则在发帖操作以外

1
2
3
4
5
6
7
8
9
10

post_op = operations.Comment(
    **{"parent_author": parent_author,
       "parent_permlink": parent_permlink,
       "author": author,
       "permlink": permlink,
       "title": title,
       "body": body,
       "json_metadata": json_metadata}
)
ops = [post_op]

额外增加了投票操作

1
2
3
4
5
6
7
8
9

if self_vote:
    vote_op = operations.Vote(
        **{'voter': author,
           'author': author,
           'permlink': permlink,
           'weight': 10000,
           }
    )
ops.append(vote_op)

通过这个例子可知，Python库是支持把多个操作放到一个事务中的

将多个操作放到一个事务中的例子

Steem 官方Python 库同时提供了一个将多个操作放到一个事务中的例子
详情可以参考这里：

https://github.com/steemit/steem-python/blob/master/docs/examples.rst

Batching Operations

Most of the time each transaction contains only one operation (for example, an upvote, a transfer or a new post). We can however cram multiple operations in a single transaction, to achieve better efficiency and size reduction.

This script will also teach us how to create and sign transactions ourselves.

代码太长，感兴趣的朋友自己去看吧。

我的测试

我修改了这个例子，并针对我的一个回复进行测试：

(两个操作在一个事务中，相同的transaction_id)

(两个操作在一个事务中，详情)

结论

使用使用官方Python库，将多个操作(operation)放入一个事务中(transaction)是切实可行的。

This page is synchronized from the post: 将多个操作(operation)放入一个事务中(transaction)