最近打算重新实现一下之前实现的获取共同操作账户某个操作的真实操作者的脚本，然后偶尔间发现一个API调用get_potential_signatures。
（标题中不让用get potential signatures，否则提示Markdown is not supported here，并且POST按钮是灰色的。愁人！）
(图源 ：pixabay)
get_potential_signatures
它的使用方式是传入一个签名的事务，然后返回可能用于这个签名这个事务的私钥对应的公钥：
curl -s --data '{"jsonrpc":"2.0", "method":"database_api.get_potential_signatures", "params":{"trx": {}}, "id":1}' http://127.0.0.1:8081
其中trx后对应的{}中应填入transaction的内容，例如：
于是我就想，如果直接能用这个调用获取签名对应的公钥，那么岂不是直接可以通过get_key_references获取对应的用户，两下子就解决我的问题了。并且都是API调用（读操作），不涉及签名、广播等操作，实现PHP脚本什么的也容易。
结果找了个授权个多个公钥的账户的一个操作(点赞)测试了一下，我期望是返回签名对应的公钥，结果却返回了所有的POSTING公钥，这就尴尬了，和我期望完全不一样啊。
于是读了一下get_potential_signatures实现代码：
大致就是从可用的私钥（active、owner、posting）中获取一组可用于对应操作的最小（最低）私钥集合。
也就是说跟对应事务中的签名是谁签的，一丁点关系都没有！那么文档的示例中给出的示例就没啥意义了。比如我使用如下代码清空签名，获取的结果还是一样的：
tx["signatures"].pop()
也就是说，真正有意义只是操作的类型！所以这个调用达成不了我的目的，哎，失望呀。
有趣的测试
尽管很失望，但是我还是做了一个有意思的测试，就是我之前一篇文章是用Active KEY发布的，那么我调用get_potential_signatures获取的会是active key还是posting key呢？
完整的调用如下：
curl -s --data '{"jsonrpc": "2.0", "method": "database_api.get_potential_signatures", "params": {"trx": {"ref_block_num": 12864, "ref_block_prefix": 901786240, "expiration": "2020-04-19T12:29:00", "operations": [{"type": "comment_operation", "value": {"parent_author": "", "parent_permlink": "test", "author": "oflyhigh.test", "permlink": "testpost", "title": "Test Active Key Post", "body": "Test Active Key Post, Hello World!", "json_metadata": ""}}], "extensions": [], "signatures": ["202e162abc10900c23fb22d11f2ab2f2a31c71a6c1c3d1db031c3698c7d816b0fa511dad561514007b4f9b20e7ffcec7e25ca3bc0914017dcc87a74de96d1335ed"]}}, "id": 1}' http://127.0.0.1:8081
返回内容如下：
{"jsonrpc":"2.0","result":{"keys":["STM8ME3Nh9umhZSrtbEngtbMXWduueuQFb7sfqh6btjvJmf7fE29R"]},"id":1}
对比一下我对应账户的权限数据：
不难看出，返回的还是POSTING KEY，这更验证了我之前的判断，这个调用和实际签名真的一丁点关系都没有！