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.
Combining rewards
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?
It looks like current protocol already allows for the first option, Combining Rewards. There is a parameter, nCombineThreshold, which goes into determining what outputs get combined. It is currently set at 1/3 of the PoW reward, however as far as I know there are no protocol rules that prevent it from being increased to a large number. In addition, it only combines utxos that are at the same address. I think this function can be modified to do what we want, but also I believe that we need to impose additional protocol rules to prevent it from being abused as I mention in the OP. Specifically, I think the protocol rules should be as follows:
Max nCombineThreshold = 1/6 the number of coins used to mint, regardless of coindays
Total Coinstake transaction size = 1 KB
I choose 1/6 for 2 reasons:
Outputs that have a split tree where one branch is 3 splits deeper than the other will have outputs with 1/8 the size that can then be recombined. This allows the split/combine trees to be more flexible over time if there are large swings in PoS difficulty.
With a 60 day split frequency, recombining outputs that are 1/6 the size of an output split at 60 days will have a >50% chance of minting within 360 days (60*6=360, and the 90 day mint chance is greater than the 60 day mint chance).
The total coinstake transaction size is quite limiting for a number of applications. I chose it with mint pools in mind and with the idea that you could track input addresses directly to output addresses within the coinstake. This way, no one has to worry about who pays the fee (minters get 1 KB for free) and you can truly pool together outputs owned by different people that have their rewards paid to the correct address. This allows for seamless integration of a pool, potentially even just using the standard client software. However, you could achieve the same effect by making this simply a client rule, so it may not be necessary to promote this to the protocol level.
Maybe drop the Total Coinstake size as a protocol rule and add a ‘pooling’ option that restricts the total txn size to the minter budget and allows other addresses to join. So the default client will recombine smaller outputs within a single address, and you can turn on an option to mix other addresses into the coinstake, but preserve their amounts for the outputs. This way, the default does not give up anonymity, and we can rollout the ‘pooling’ option later in v0.10. As an example of how the default client would behave, if you go and buy a large output of peercoin and drop it into the same address you’ve been minting with, it would recombine the smaller outputs when it splits, so it achieves an equilibrium between small and large stakes. Then instead of one large output and a bunch of smaller outputs it would pull the smaller branches of the split tree back into the trunk and start splitting back down in unison.