Future Hardfork Feature: Signing with Merged Authority

inertia(74)
Published in
#steemd
Words
352
Reading
2 min
Listen
Play
7y

As an application developer on Steem, I would like to be able to use elevated authority to sign transactions with operations that require a mix of valid authorities, so that I can do "all or nothing" transactions.

Here's a scenario. Say I want to send a vote op followed by a transfer. I can do this by adding the vote op to a transaction and signing it with the posting authority and broadcast followed by adding the transfer to a transaction and signing it with the active authority and broadcast.

A less common scenario is to do the same thing as above with the active authority. That works because the active authority has a higher privileges than the posting authority.

However, if I want to ensure that the vote and transfer happen in the same transaction, thereby ensuring that the vote and transfer are both accepted or both rejected, we have a small problem.

The current implementation will not accept a combination of operations that have different authorities. According to the source code:

/**
 *  Transactions with operations required posting authority cannot be combined
 *  with transactions requiring active or owner authority. This is for ease of
 *  implementation. Future versions of authority verification may be able to
 *  check for the merged authority of active and posting.
 */

See: transaction_util.hpp, original appearance: transaction.cpp

I would like for the "future versions" case mentioned above to be implemented.

This "merged authority" feature would be useful to app developers. I can envision other situations where custom_json requires active authority combined with a comment op that only requires posting authority, for example, if a hypothetical sidechain contract would need to look for that comment op, but you don't want it to execute if the comment op isn't included, and you don't want to broadcast a comment that requires the sidechain to do something with it (all or nothing).

Basically, it provides additional flexibility. I really can't see the downside, except perhaps additional complexity and evaluation resources.

In terms of urgency, we've gone this long without it. I don't think it would hurt to add it to HF21, but if it's too complicated, I can understand waiting until after HF21.


If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.

Future Hardfork Feature: Signing with Merged Authority | Ecency