Beem-0.19.54: Serialization of transactions in the appbase format

in utopian-io •  4 months ago

Project Information

A GitHub issue wasn created and a fix could be provided. Holger merged the fix into beem-0.19.55.

Expected behavior

Beem's Signed_Transaction class should be able to handle transaction data as retrieved from the blockchain and should be able to calculate the transaction signer's pubkey from the signature. This should work for appbase and non-appbase nodes.This functionality is, among others, used in the beempy verify command.

Actual behavior

The actual problem only showed over time. Initially, an exception was discovered when loading an appbase-transaction with beneficiaries with the Signed_Transaction class. The same could be reproduced with beempy verify. Later on, it was observed that the beempy verify command additionally gives empty results whenever asset amounts in the appbase-format are contained in the operations.

How to reproduce

The following snippet was used to reproduce the problem with the exception:

from beem import Steem
from beem.nodelist import NodeList
from beem.blockchain import Blockchain
from beembase.signedtransactions import Signed_Transaction

s = Steem(node=NodeList().get_nodes(appbase=True, normal=False))
b = Blockchain(steem_instance=s)
for block in b.blocks(start=25304468, stop=25304468):
    for trx in block.transactions:
            st = Signed_Transaction(trx.copy())
        except Exception:

The same problem could then be reproduced with beempy verify:

$ beempy set nodes
$ beempy verify --trx 3 25304468
  File "/usr/local/lib/python3.6/site-packages/beembase/", line 268, in __init__
    raise Exception("Unknown CommentOptionExtension")
Exception: Unknown CommentOptionExtension

In that context, it turned out that transactions with amounts give empty results:

$ beempy verify --trx 5 25304468
| trx | Signer key | Account |
| 5   | []         | []      |


The problem was with the serialization of the transactions. An appbase beneficiary extension has the following format:

'extensions': [{
  'type': 'comment_payout_beneficiaries', 
  'value': {
    'beneficiaries': [
      {'account': 'steempress', 'weight': 1500}

The same data from a non-appbase node looks like this:

'extensions': [[
  0, [{'account': 'steempress', 'weight': 1500}]

Beem was expecting only the non-appbase format and serialized the type/value keys instead of their values in the appbase-case. By adding a check for the appbase format and extracting the values behind the keys, beem could serialize the transaction without raising an exception. However, the recovery of the transaction signer still gave emtpy results due to the serialization of appbase amounts contained in the same operation.

While beem correctly identified the appbase-format for amounts, it serialized the NAI number instead of the asset symbol. By implementing a look-up of the symbol from the NAI via the list of known chains, this could be fixed as well.

With both changes in place, the transaction with the beneficiaries can be loaded and the signer key can be extracted:

# beempy set nodes
# beempy verify --trx 3 25304468
| trx | Signer key                                            | Account      |
| 3   | STM8UsiAQE3nCAjs719SJ3cBTJzH8KQ5jwAemcrn6DVVCphQvjH2j | buffalo-goku |

One aspect that needs to be further investigated is the behavior with custom chain parameters provided via the Steem() constructor. Those are not contained in the static known chain list and may, therefore, fail to resolve asset symbols correctly.

GitHub Account

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

Hi @stmdev thanks for making this contribution

I see the issue was fixed in this commit made by you. It's always a joy to read your bug contributions. The post adds significant value to the open source community.

  1. The post title contained sufficient information and followed the Utopian naming convention.
  2. The expected and actual behaviors were thoroughly explained, enough to tell the discrepancy in the actual behavior.
  3. The "How to reproduce" section of the post was very informative, with every grey area carefully explained.

I look forward to your next contribution.

Your contribution has been evaluated according to Utopian policies and guidelines, as well as a predefined set of questions pertaining to the category.

To view those questions and the relevant answers related to your post, click here.

Need help? Write a ticket on
Chat with us on Discord.


Thank you for your review, @fego!

So far this week you've reviewed 4 contributions. Keep up the good work!

Hey, @stmdev!

Thanks for contributing on Utopian.
Congratulations! Your contribution was Staff Picked to receive a maximum vote for the bug-hunting category on Utopian for being of significant value to the project and the open source community.

We’re already looking forward to your next contribution!

Get higher incentives and support!
Simply set as a 5% (or higher) payout beneficiary on your contribution post (via SteemPlus or Steeditor).

Want to chat? Join us on Discord

Vote for Utopian Witness!

Hi @stmdev!

Your post was upvoted by @steem-ua, new Steem dApp, using UserAuthority for algorithmic post curation!
Your post is eligible for our upvote, thanks to our collaboration with @utopian-io!
Feel free to join our @steem-ua Discord server