Make MsgMultiSend single sender

[ValarDragon]

Summary

cref #12397 , currently MsgMultiSend is complex / complicates further features state machine side due to its accomodation of many senders and many receivers. Theres no known users of the multi-sender functionality [Citation Needed], only users of the multi-recipient functionality.

If this is the case, we should restrict the MsgMultiSend state machine side to only have at most 1 sender.

Proposal

Change the MsgMultiSend validate basic, to require the senders (AKA inputs) to be of length 1

---

For Admin Use

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

[julienrbrt]

Already implemented by #12610.

[AlexTroshkin]

Hi all. There must be a lot of potential users of this feature. If we don't know about them, it doesn't mean they don't exist.
At least this feature is needed all exchangers and exchanges because they take the funds to a separate address for each user / for each exchange. And this feature allows you to send a single transaction in case the user requested the amount which is not entirely at any deposit address (without this you have to periodically collect funds from many addresses to one address for payment). And in general it allowed to send much less transactions respectively save on commissions and transaction overhead (one transaction even with description of many inputs and outputs surely takes less bytes than many separate transactions). In this context bitcoin with its model of inputs and outputs is an ideal example

I understand that this carries a complication on the underlying mechanisms and support costs, but I don't have enough context to compare them to the lack of this functionality for the users described

However, if you approach the problem from another angle, I can offer another solution to the described user case. For MsgSend module Bank could add some "payment identificator" and then it would be possible to determine from which user the transfer came and due to this receive all funds to one address and send also from one address without carrying out clearing operation

[likhita-809]

Hey @AlexTroshkin the use case you mentioned makes sense to me but it raises few doubts. What's your take on collecting funds from many addresses to fund one address, are you going to collect them equally from all addresses to get required payment, in this case I suppose we wouldn't need any identifier. But if not what's your approach and how are you going to use payment identifier there?

[AlexTroshkin]

Good afternoon, @likhita-809. There are two options for working with funds.

1. Deposit / exchange (funds come from the user)
2. Payment (funds come from us to the user)

Payment ID directly helps only in the first case, affecting the second. Thanks to it, we can make one address to accept deposits and by identifier identify which user made this deposit (it also requires acceptance to be added to wallets and other exchanges, because users do not send msg manually :D).
And here we come to the second option. Since we have all the funds at the same address we can easily manage them. This address always has native currency to pay commission and no costs associated with the collection of funds from multiple addresses to one.

Something similar is used in XRP and TON

Perhaps don't mix it up with the MsgSend / MsgMultisend function, but consider some sort of invoicing mechanism

However, it is preferable to keep the funds in separate addresses for each user, but manage all the funds from one single address from which the fee is paid. It's safer than keeping everything at one address - MsgMultisend with more than 1 input was ideal :D

[ValarDragon]

@AlexTroshkin none of this interferes with the usecase your providing as far as I can tell.

You can have a single tx, with one address as fee payer, and many other actions (e.g. individual sends from different accounts) included.

[likhita-809]

pinging @alexanderbez @tac0turtle for more visibility

[AlexTroshkin]

@AlexTroshkin none of this interferes with the usecase your providing as far as I can tell.

You can have a single tx, with one address as fee payer, and many other actions (e.g. individual sends from different accounts) included.

Hi. There is a need to send simultaneously from many senders to many recipients. This avoids creating transactions that send all funds from senders to a single address from which funds are sent to the user. That's a lot less transactions, less commissions. There is another bad variant when the sender addresses only have tokens without native currency and then the number of transactions doubles - first you have to send native currency to all those addresses so that they can pay the fee for sending funds to a single address

[tac0turtle]

i still think your use case doesnt show why a multisend needs to be supported, all the use cases are supported via a multimsg tx. This is what i think you are describing as well.