Rework client.TxBuilder

[robert-zaremba]

Summary

client.TxBuilder and it's implementation (x/auth/tx.wrapper) are badly implemented:

• We can't easily observe a state of TxBuilder
• Client signing (client/tx.Sign) functionality is twisted and requires a use of external object (txFactory) which may be in conflict with txBuilder state.
• Using builder and factory at the same time is error prone.

Context:

• fix: Signature only flag bug on tx sign command 7632 #8106 (comment)
• fix: Signature only flag bug on tx sign command 7632 #8106 (comment)

Proposal

Usage of txBuilder should be investigated.
Redesign client.TxBuilder interface and reimplement tx.wrapper .

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[robert-zaremba]

Copying a conversation related to the signing issue:

We have a problem with off-chain transaction signing in the DIRECT mode.

In #8106 (fix: Signature only flag bug on tx sign command) we had a lengthy discussion about expected use case of CLI signing. The main user story is:

1. someone generates the transaction and send it to the users
2. users sign it
3. someone collects the signatures, put them in a transaction and send to a blockchain.

A variant of the above is a sequential process, where users sign and pass from one to another the transaction.

This doesn't work after launchpad. Few reasons:

• Refactore of tx.Sign - the function assumes a single signer only. We changed it this week to allow aggregation of signatures, but it won't work on multiple users signing in a direct mode.
• current implementation of Sign_mode_direct: it requires each user to sign any other user public key and singing mode. Moreover, the signing mode has to be the same for all users and exactly the same as the one set on the chain (AnteHandler.SigVerificationDecorator uses it's own signing mode variable).
• Signing order is defined during transaction creation and it can't be altered unless we change the implementation of AnteHandler.SigVerificationDecorator and review other places where we relay on that order.

We made it working for a single signature use case, but for multiple signatures the process is more constrained as explained above.

[aaronc]

Let's make sure we address ADR 031 TxBuilder UX (see #8728 (comment))

[clevinson]

As part of this we should also be looking at whatever is leftover from #7357

[educlerici-zondax]

this will be on hold until the implementation of ADR071 is completed.
After that, we can assess the possibility of applying these changes.

[educlerici-zondax]

As this is part of the txFactory refactor in this PR #20623, i close this issue.
However, the new client/v2/tx functions still need to be wired in autocli, in this issue #22926