[Proposal Improvements] Add fee paying account to available_active_approvals

[vikramrajkumar]

From @xeroc on December 13, 2015 17:38

Let's say we have a user account Alice that is secured by a second factor service.
The active authorities of Alice requires 2 signatures, one for each

• Bob
• 2FA

Now, I'd like to have Bob propose a transaction and only have 2FA add his approval to have the proposal withdrawing from Alice be valid. That would GREATLY improve user experice and does not open up any security holes since Bob needs to be in the active authority any way.

The only difference is that to verify the proposal, you also need to include the proposals signature (e.g. fee paying account).

However, I think this feature request requires a hard fork.
I am open for discussion

Copied from original issue: cryptonomex/graphene#479

[vikramrajkumar]

From @xeroc on December 14, 2015 21:34

An alternative way to improve user experience would be to allow proposal_create_operation (and proposal_update_operation) with only partial active authority signatures ..

Say Alice's account is multisig with a key and account Bob .. then Alice can't even create a proposal to spend from her own account. If we allowed proposal_*_operations with only one instead of two signatures, Alice wouldn't need to propose a transaction from an other account (to pay the proposal fee)

[vikramrajkumar]

From @theoreticalbts on December 15, 2015 16:56

Your first comment is basically saying have the publisher of a proposal automatically approve it. Very early in the design of Graphene we had planned for a way to backreference ID's created by earlier ops, however, it was cut from the feature list basically on the grounds of "it's too hard" (a decision I personally disagreed with). With such a backreference your proposal would be as simple as creating a transaction with two ops, one to create it and one to add the active approval of the creator. The second op needs to use backreferencing to be atomic, because if a malicious witness (or indeed random chance) caused a proposal to be inserted before the transaction, Bob would end up approving a proposal he didn't intend to approve and not approving the proposal he did intend to approve.

This can still be done, however, it is more complicated:

• User indicates desire to publish and approve proposal
• Wallet sends tx to publish proposal to the network
• When publish proposal appears in a block, wallet sends second tx to approve proposal with TaPoS indicating block where published proposal appeared
• If network forks, wallet may need to re-publish 0, 1, or 2 of the above two tx's depending on when the fork occurred

So this is still a wallet-level thing, however it requires a level of sophistication in wallet implementation with careful handling of dependent sequences (or in the most general case, DAG's?) of transactions, where each transaction potentially references ID's in a the transaction(s) on which it depends. Which requires careful management of TaPoS and awareness of forks to be sure the wallet correctly executes the user intent in all cases. This sophisticated wallet behavior AFAIK does not exist in current wallets.

Your second comment is basically saying give the user one account with multisig and a locked-down balance, and another account with no multisig. And a wallet could implement it that way under the hood, but again it requires a level of sophistication in wallets which doesn't exist in current implementations (each user must have a second "hidden" account which keeps the balance for publishing, or all users of a certain wallet are allowed to use a centralized fee paying account to publish their proposals, subject to anti-spam, rate-limiting, CAPTCHA, etc.).

[vikramrajkumar]

From @xeroc on December 15, 2015 17:50

Having the approval in the same transaction is difficult to implement. I understand that.

But what is the reason that I cannot take the account that signs the proposal_create_operation as an implicit approval. If someone proposes a transaction for an account that has no say in that account you see a worthless implicit approval.

If, however, you create the proposal from an account that is part of the spending account's active authorities, an implicit approval due to the signature of the create_proposal_operation is figuratively and implicit approval, isn't it?

[vikramrajkumar]

From @theoreticalbts on December 15, 2015 18:22

We discussed this issue during the design of Graphene. The justification for the current behavior was that a committee member might want a way to express "I don't support this idea, but I would like to put it up for a vote."

[vikramrajkumar]

From @theoreticalbts on December 15, 2015 18:26

If this is implemented at all, it should either be by:

• Generic backreferencing of ID's. It would then be up to each wallet whether to include the second op by default, which ID's to include in the second op by default, and whether/how to give the user a way to override the default.
• Extension to proposal_create_op containing the account ID's of active/owner approvals to add to the newly created proposal. It would then be up to each wallet whether to include the extension by default, which ID's to include in the extension by default, and whether/how to give the user a way to override the default.

[vikramrajkumar]

From @xeroc on December 15, 2015 19:37

We discussed this issue during the design of Graphene. The justification for the current behavior was that a committee member might want a way to express "I don't support this idea, but I would like to put it up for a vote."

That was the missing piece in the puzzle .. thanks for the clarification

[vikramrajkumar]

From @xeroc on January 20, 2016 9:39

So .. thinking about the

don't support this idea, but I would like to put it up for a vote

what prevents people from just using a new account to create a proposal for the committee that way.
IMHO, the reason for this limitation is not worth it.
From usability perspective, having this implicit approval would make things alot easier (and cheaper)

Please reconsider this!

[abitmore]

@xeroc or anyone else have time to write a BSIP for this feature?

[xeroc]

https://github.com/bitshares/bsips/blob/master/bsip-0039.md

[abitmore]

@xeroc bitshares/bsips#71