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.