A concern was brought up that with rfc11 and rfc12, it might be a good idea to allow small outputs to band together in a mint pool in order to combine their chances of finding a block. I will outline several possible directions one might go in when thinking of a solution to this, and identify some of their drawbacks. Ultimately, this may be an impossible venture, but it is worth documenting anyway.
The most naive answer is that when a stake finds a block, you could just add other outputs to that coinstake and get the reward for all of them. The issue with this is that it will decrease the PoS difficulty because the other outputs did nothing to increase the frequency of block creation, but their coindays are still consumed in the process. This identifies one of the key problems with pooling coinstakes: PoS difficulty is based on block frequency, not coindays destroyed. So we must seek to maintain block frequency given a certain number of coindays destroyed.
Hashing multiple coinstakes
The next possibility is to add together the mint chances of each output and come out with a total probability of finding a block as a unit. The issue here is that if you are able to hash them together as well as separately, you are motivated to try both simultaneously and thereby increase your chances of finding a block. This is very easily manipulated via a stake grind attack, and so is untenable.
Special transaction: combining stake
Using a special transaction mode to identify the intent to combine stake into a single unit allows you to avoid the multiplicity issues of hashing multiple coinstakes. Indeed, a simple transaction that truly combines multiple outputs into a single output is obviously allowed under current protocol. The use of the special kind of pooling transaction, on the other hand, would be when the outputs are owned by different users, i.e. using rfc12 mint keys. Perhaps this transaction could be done entirely using mint keys to combine the outputs into a virtual single minting output, without affecting the underlying separation of their spend keys. We would have to disallow minting these outputs separately in order to allow them to mint together, or we wind up right back at the issues with hashing multiple coinstakes. Clearly, this solution has a lot of possible drawbacks, for example that if one of the constituent outputs is spent then the entire unit is now invalid. However, I think it is a good place to start discussion on this topic.
Is there an elegant way to pool coinstakes, or is this a fools errand?