Is there a particular reason this should be invalid? It's just a no-op that the user has no control over and the spec allows other no-ops.

This begs the question: what info about the result of the tx is made available (e.g. # of addresses that received a portion, list of addresses and how much each one received, addresses that were shut out due to rounding), and how?

So just to clarify you're saying it should be valid, but not move any tokens, nor burn any MSC?

As for details of the tx, same as any other - return value is a TXID. You would then pump said txid through something like getdividend_MP txid to get the specifics, though that RPC call may not make it in by live date meaning user may not be able to get any information about their sent dividend until a little after live - I've raised my objections to that so won't rehash here.

Thanks
Z

@zathras-crypto I don't see why it's inherently invalid. We let tx21 orders match with orders from the same address - nothing useful accomplished there. (Note a tx22 accept offer has to come from a different address than the one that issued the tx20 sell offer.)

For the case you cite, the user doesn't have a way to know definitively that his address is the only holder of the tokens to be disbursed. I think it's more informative to the user (and others) to know that all the tokens are/were held in that user's address, rather than having to infer that after ruling out other possible reasons why the tx was invalid.

As for burning MSC - perhaps there should be a base tx fee plus the per recipient fee for Send to Owners. So there's a cost even if the sending address holds all the tokens, and a meaningful cost even if only a small number of owners receive something.

@ripper234 @CraigSellars @dacoinminster others - thoughts?

I'm good either way, I don't think it's critical one way or the other.
I say we choose for the choice that requires minimal changes.

1 Invalidating the tx will save the sender from an accidental send (If not invalidated the funds will be deducted from senders account and will be in limbo?)

@marv-engine the fee for send to owner can be ranged based. Fee calculated based on 'maximum available msc' ('max msc total' less 'burned msc')

Ex. If 'max available msc'
< 500k, fee is 0.5 msc per owner, (fee is charged to the sender)
<400k , fee is 0.4
<300k , fee 0.3
Etc.

The pull request looks good, has no merge conflict and matches the current behavior of Omni Core.

Ready to go!