March 17th, 2018
Unable to figure out, why my multi-signature transactions are not working, needed to inspect the source code of steem. Good developers always read the manuals. That's our mantra RTFM. I'll let you figure out what the 'F' stands for.
Without good documentation it is impossible to determine the difference between the implentation and the intention of the developers. This even makes bugs hard to spot because you don't know if software is meant to work a certain way or not. Or someone might change behavior thinking it is not supposed to work a certain way when it was.
The problem is, at least for steem there is no manual that talks about the anatomy of a transaction. I don't know whether it is something wrong with the creation of the transaction, the implementation of Beem or the node that's answering questions.
Excerpt from libraries/protocol/transaction.cpp
void verify_authority( const vector<operation>& ops, const flat_set<public_key_type>& sigs,
const authority_getter& get_active,
const authority_getter& get_owner,
const authority_getter& get_posting,
uint32_t max_recursion_depth,
bool allow_committe,
const flat_set< account_name_type >& active_aprovals,
const flat_set< account_name_type >& owner_approvals,
const flat_set< account_name_type >& posting_approvals
)
After taking a real close look at this function in the 19.3 code and it seems to me that things are not being called as I expected. My perception is this should just work.
There is no prefered ordering to the signatures. The max_recursion_depth defaults to 2. get_active, get_owner, and get_posting, get the keys the names suggest. If the signatures were badly made normal non-multisignatures transfers wouldn't work. Well it is still a mystery what is wrong with the transactions being produced.
March 9th
March 8thDash XjzjT4mr4f7T3E8G9jQQzozTgA2J1ehMkV
LTC LLXj1ZPQPaBA1LFtoU1Gkvu5ZrxYzeLGKt
BitcoinCash 1KVqnW7wZwn2cWbrXmSxsrzqYVC5Wj836u
Bitcoin 1Q1WX5gVPKxJKoQXF6pNNZmstWLR87ityw (too expensive to use for tips)