I’ve taken this into account, and my idea is to sum all sends of the same asset/address and just do one send. This would be implementation-wise. Validation-wise an address/asset tuple with a cardinality > 1 would invalidate the MPMA send. Will clarify in the cip.
This is a bad idea imho. Bitcoin doesn’t limits how much i can use the same address in one send, why should we? Otoh, adding duplicate entries in the address-LUT table is a bad idea, would make 2 different versions of the same message valid consensus wise and make undeterministic what LUT index is picked for each asset/address send.
This is done already, a send of 0 invalidates the MPMA message, will clarify in the CIP.
Doesn’t makes sense. Adding an additional LUT will just be a wasteful use of space, as assets need only to be specified once per send. In fact, i will outline in the cip that specifying the same asset more than once would make the message invalid (for two reasons, spam/waste and making the message not determinist).
For MCAT asset groupings make sense too, the idea here just to include a way to specify source address (which i have an idea for)
The whole message, better be stringent on this than not.
This would need typification, MPMA would probably make nodes work harder. How hard? How often? that’s the real question.
IMO when a node transmits an MPMA envelope, it should abstain from sending more, as this is for batch sends purposes (i.e. a source address shoudn’t have more than one MPMA envelope in mempool at any time) and not time sensitive sends. Enforcing this protocol level would prevent a single party of accidentally spamming the network, which is desirable.
Malicious spam attacks are hard to predict, but a party trying to block the network could theoretically distribute assets into N source addresses and then mix them hard and fast. This would imply a high amount of BTC fees (probably) and would render the attack improbable in case of high mempool backlog conditions.